  |
はてなキーワード: 保証とは
横だが。
NFT化されたコンテンツのコピーが別のNFTプラットフォーム上でNFT化されたらオリジナルが二つ存在することになるのか？
そもそもデジタルデータは(NFT化されていても)完全なコピー可能なので、
そういう意味で「オリジナルが二つ存在することになるのか？」というのは、
だとしたらNFT化する意味がなくなると思うが実際はどうなのか
NFT単体では意味は無い。
NFTは「そのNFTの最新の所有者は誰々である」という情報を確定できるデータに過ぎず、
それを結びつけるにはNTFとは別に、法律にのっとった契約や、NFTを参照してその所有権に従うシステムを作る必要がある。
チェックできないし、そんな保証は無い。
せいぜい1ヶ月かこそらでしょ
いきなり1ヶ月休職してその後復帰させてもらえる仕事はそんなに多くないだろうなあ。
1ヶ月休むために退職するかどうかという選択になるだろうね。しかも1ヶ月で終わる保証も同じことがもう起こらない保証もないし。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
視野の狭さが若者って感じで微笑ましいな。「良い大学に行けなくても大丈夫」という意味ではなく「良い大学に入った程度では人生の成功なんて何一つ保証されない」という意味で。
実際パブリックエネミー側だから選挙だとボコボコに負けるのでは？
内容は保証しませんが，それなりに時間かけて聞き取ったし，誠実に書き下したつもりなので読んで♡
cf. https://twitter.com/ganrim_/status/1484435293985853441
（注：って感じにところどころ脚注入れてあるけど，気にせんといてくれや）
（音声全体では１８分２１秒ある．山内さんが部屋に到着し，会話が聞こえ始めたのは音声 04:00 ~）
中井「こんばんは～どうぞ」
中井「ありがとうございますお時間いただきまして…本学の～～～」
（注：～～はよく聞き取れなかった）
中井「実はですね…〈北村紗衣〉先生という方の弁護人から本学あてに連絡がございまして……（不鮮明なもにょもにょ）～～けども…」
（紙をペラペラとめくる音）
山内「それで…なんですか？伺いたいことってのは？」
（数十秒の沈黙）
学部長「いくつか確認させていただきたいことがあるんですけれども……えーと正論……雑誌の『正論』ですね，正論の６月号に『ポリコレ派への共感 強制する社会の歪み』という記事が出ていまして，〈山内雁琳〉さんという方；甲南大学の非常勤の方が書いているということなんですけれども，それは山内さんということで間違い無いですか？」
（注：https://www.fujisan.co.jp/product/1482/b/2109118/ ）
学部長「間違いないですね？」
山内「はい，それは私自身の写真が転載されていますから，ハイ」
学部長「次にですね，この山内雁琳という記事を書かれた方の Clubhouse が横にあるんですけれども，山内先生ご自身だということで間違いありませんか？」
（注： https://clubhousedb.com/user/ganrim_ ）
学部長「そうしますと，ここにある〈雁琳（がんりん）〉さんですね，Twitter のアカウントの @ganrin さん……これ最後Nですけれども，そこで言及されているアカウント名の雁琳さんともほぼ一致してくるわけなんですけれども，この Twitter も先生のアカウントということでよろしいですか？」
（注：文書を参照しながら喋っている様子が伺える，そこでは @ganrin_ と表記されているように聞こえるが，実際には最後がMという表記の @ganrim_ が山内さんのアカウント；なお @ganrin というスクリーンネームも実在している）
山内「あの…こちらから質問するのはNGかもしれないンですけれど，これはどういった確認なんですか？？私は一応寄稿はしました…で，この確認がなんについての確認なのか？っていうことです」
中井「大学あてに，もし雁琳さんという方のこのアカウントで書かれているような，このような人格を攻撃するような…ぁ，あの学問的な中身どうこうということは全く書いておりませんので……この３ページ目に書かれているような言葉を実際に使って Twitter で発信されておられるとすれば，それは性的なハラスメントにあたるのでやめてください！ということを先方から大学 / 学園として求められておりますので……，私達の判断としてもこの言葉を使うっていうことはよくないことだと考えますので，もし先生がほんとうにこの方なのであればやめてくださいということを申し上げるための確認でございます」
山内「なるほど……あの～～弁護士さんに相談して持ち帰ってもいいですかこの話？」
中井「こちらからも何かをするとか……訴訟をするとかなんとか向こうも云っておられるわけではなくって……本当にもしこれが先生なんだったら「やめてください」ということを申し出てくれということを求めておられますので，それを受けた学長としては，先生なんであれば「やめてください」と本当にお願いしたい……」
山内「なるほどねぇ……」
中井「この言葉を，私が見てもいけない言葉だと…学問的な中身の話ではありませんので，そこでどんな主張が展開されるということには，私も学者の端くれですので口を突っ込むつもりはございません」
山内「ちょっとぉ……今ここでお答えはいたしかねますね！……私の方からもう一回弁護士さんにこういうのが来ていると相談させていただきたいんですよ．ようは人格権を侵害するということを先方の方がおっしゃっているわけですよね？それが果たして本当にそうなのかどうかとか，ちょっと僕も法律の専門家ではないので……あの一回持ち帰って弁護士さんに相談させてもらうことになるんですけど……今，先生がおっしゃった話でいうとそれはここでなにか私に対して「やめろ」って言うこと以外はおっしゃらないという形になるんですか？」
中井「もちろんですもちろんです！そんな権限は私達にはありません．ただ，向こうの弁護士さんが大学 / 学園あてに云ってきておりますので，受けた大学としてはまず先生であるかどうかを確認させていただき，先生に〈お願いをする〉と，それ以上でもそれ以下でもございません」
山内「なるほど，つまりこういう連絡が来ているので私の方に “取次をしていただいた” という理解でよろしいですか？」
中井「はい，はい……で大学に求めておりますので…，３ページ目最後の二行ですが……本学から山内先生に “今後他大学の教授に対する性差別的な誹謗中傷を継続しないよう” ……まぁこの…３行上の言葉ですね，書いてある通り」
（注：「計画しないよう」 → 「継続しないよう」 へと表記を変更）
中井「これを申し入れていただくことを “求めて” おられますので」
山内「代理人，そうですね依頼人の方の代理人である，この法律事務所の方が求めておられると，いうことですか……なるほど」
中井「あのこちらからも積極的にこれ以上これをお受け取りした以外になにかアクションは取っておりませんので」
山内「ということは，あれですよね……甲南大学さまの方から私に対するなにかお願いがあるというよりは，私の勤務先である甲南大学の学長先生だったり学科長先生に，この依頼人の方がこの連絡を私に通達しろということで，今日のお話の機会を設けた……そういうことになりますかね？その理解でよろしいですか？」
中井「はい，ですので私は通達させていただきますので……「やめてください」というお願いですので…」
山内「はい…………ちょっとあの，ここでどうこうって，ちょっと答えかねます……私の方で今答えることはできないです．一旦これは弁護士さんに多分相談しないといけない案件なので……おそらく大学の方というよりも，この先方の方ですよね，この方とのやりとりになるのかなぁなんてことを思ってはいるんですけども，まぁ先生のおっしゃることはわかりました」
中井「まぁ，こんなこと…どうですかねあの……武蔵大学の先生ですけどね，本学とも結びつきのある大学ということで，”まずは” こういう手を取ってこられたんだろうと思います」
山内「なるほど」
中井「お願いを……誹謗中傷を “継続しないよう” 申し入れていただく……ここまでで結構ですというか，まぁ大学に求める対応としてはそういうことですという……もちろん私達としても当然，求められてもそれ以上できるものではございませんので………先生でいらっしゃるならば，これが書かれたもの……本当にもう一度～～させていただきます」
（注：～～は聞き取れず）
（注：「計画しないよう」 → 「継続しないよう」 へと表記を変更）
山内「なるほど……そうですねぇ，どうやってこのアカウントが私であるのかどうかをわかったのか私には理解できないですけれど，まぁ私がこれであるとそう予測されて，これをされてるわけですよね」
中井「そうですね，だから先程学部長が『正論』に寄稿されましたかというところから～… 山内「あぁもちろんそこはそうです！」…～ この雁琳のところに，こういう研究があったので，ということなんです」
（注：ここ山内さんが食い気味に大声過ぎて聞き取れず）
学部長「これも山内先生がこれだということも間違いないということなので…ただ，その Twitter のアカウントについては先生が使われたかどうか，ここではお答えできないということですか？」
山内「それをどうやって特定されるのかよくわからないですねぇ…えぇ」
学部長「先生がそれというのは，認められるつもりはないということでよろしいですか？」
山内「いや，だってTwitter は匿名ですからねぇ！私はその…私自身がこういう者であると申し上げたことはありませんからねぇ……Twitterに関していまここでも……Twitterのアカウントがこれだ！と言ったこともないので，ハイ」
中井「あの，そちらのペーパーの２枚めの下なんですが，私達がさっきまで伺っていたのはここにあるんですが，”雁琳とは『正論』２０２１年６月号に寄稿しておるその中でそう名乗っておられます” ということなので，Twitter の中で『正論』に書きましたよ～というようなことを…
山内「ほょ～はいはいはい……まぁ，そうかもしれないんですけど，これが本当にそうなのかどうかっていうのは，またちょっと第三者の方に判断していただかないとわからないじゃないですかねぇ」
学部長「先生ご自身もわからないということでよろしいですか？」
山内「まぁ，こうやって特定されておられるわけですけどぉ……まぁこの方もそうなんですけどｗ」
学部長「〈誰か〉がこれを書いているんじゃないかと，先生はお考えであると」
学部長「 “答えられない” ……，ご本人かどうかを？」
山内「そうですねぇ」
（………長めの沈黙………）
中井「このお答えは，弁護士の方を通じてなり，もしくはまた先生からお答えいただけるんですか？」
中井「Yes か No かのお答えをいただかないと，私達はこの最後の〈求め〉に応じられないことになってしまいますので……」
山内「ふむふむ……これがわからないとってことですか……あぁ～まぁそうなりますねそういう話ですと……私がこれをそうだと，まぁ仮に答えたとして，それで終わりになるんですか？」
中井「終わりです」
山内「はぁ～ん……それはでも，依頼人の方にその話が行くんですよね？」
中井「はい，大学として申し入れを行ないました；申し入れしていただくことを認められておりますと」
学部長「答えられない？」
中井「わかりました，じゃあご相談いただいて改めてお返事はいただけると，そういうことで」
山内「わかりました，はい……これは，それだけになるんですかね？」
中井「そうです～それだけしか求められておりませんので……今日はもうそれだけ」
山内「なるほどなるほど～わかりました」
中井「これは学園あてのものですので，一旦あの，回収はさせていただきます」
（注：山内さん確認中…………会話から少なくとも３ページはある印刷物だが，おおよそ２０秒弱程度沈黙が流れる）
中井「ありがとうございました～～そうしたらまた，お待ちしてますので」
山内「すいませんわざわざお時間とって頂いて…これはまたそちらからお伝えがあるんですか？」
中井「いえいえ，あのわからないことあったら～～～XXXXしてください」
（注：退席時の衣擦れ音により全く聞き取れない）
山内「わかりましたわかりました～……あのちょっとわからないんですけど，そんなでもおまたせすることでも～ないのかもしれないですね」
（注：以降衣擦れで不鮮明．別れの挨拶をいくらか交わして終了）
＞ “今後他大学の教授に対する性差別的な誹謗中傷を計画しないよう”
は，そう聞こえないこともないけど，文脈と社会常識から「誹謗中傷を『継続』しないよう」がただしい気がしてきたので変更します．
流石に〈計画すること〉それ自体をやめるように求めるってのは "内心の自由を制限しにきてるようなもの" なので，代理人弁護士がそんなことをやるとも思えませんし……
このエントリを一次資料にされたら困っちゃうけど，広くいろいろな人々がサクッと知るためにはこういう文書として残すのも必要よね．
他にもなんか間違いありそうだったらご指摘いただけると幸いです……
お前はGoogleFormsに連絡先入力欄を設置することすらできないのか。
ただ、貴殿が書いてる「記名（名前文字列が掲載）されている人々の意思に基づいている（真正である）ことを証明する」行為を唯一可能にしてるのがChange.orgなんだよね。
Change.orgにそんな証明機能は無いし、そもそも電子署名法と全く無関係じゃねーか。
Change.orgはメールアドレスでアカウント登録できるが、[yamada@example.com = 080-8888-8888]の持ち主が山田太郎なのか金正恩なのか確認してねーだろ。
例のオープンレターはGoogle Form使ったらしいけど、あれだと匿名で署名できてしまうし、主催者に投稿者情報はわたらないしでこの要件を満たしません。
せめてchange.org使えば、二要素認証はあるし、万一なりすましがあっても主催者のみに署名者の連絡先が公開されるので、身元確認は後からでも可能。
あのなぁ、https://www.change.org/l/jp/authenticity-and-anti-spam-policy を読めば分かるとおり、Change.orgは２段階認証を導入しただけのことで、その認証された相手のメアド＋携帯番号セットがどこの誰のものであるかは何ら保証していない。
それだったらGoogle Formsで十分な量の個人情報を入力させた上でリアルワールドで本人確認する方がよっぽど証明力があるんだよ。
お前なぁ、「電子署名法第3条関係はもっと知られるべき」なんてタイトルで記事書いて、法律の条文を引いてるくせに文書の成立と立証をまるっきり混同した見当違いなことを書いた挙句、ちゃんと設計すれば成立の真正を十分に証明できる形で文書作成する情報収集ツールとなるGoogle Formsについて
なんて書いておきながらChange.orgなんかを推奨してるって、法的にも技術的にも見当違いにも程があるわ。
ああやって他人様の名前を文書名義人にする「オープンレター」をやりたかったら、入り口はGoogle FormsでもtwitterのDMでも何でもいいから、届いた賛同者情報に基づいて個別に本人確認する必要があったんだよ。
もちろんオミクロン株自体が感染力が強いというのもあるだろう。
けど、世界中で感染拡大しているのは「みんな我慢に疲れてしまった」というのも大きいだろう。
その結果、過去の我慢がつらかったのだというのを改めて実感として持ってしまった。
あとは、オフラインのB2Cやってる商売人は正に死活問題でもある。
また碌な補償もない行動制限を受け入れられるかというと無理だろう。
いろんな面で限界が来ている。
おそらくだけど、なし崩し的にウィズコロナが進んでいくのではないかと思ってる。
COVID-19の治療薬が出来たとして、変異株に継続して効果があるなんて保証もない。
ワクチンにしろ治療薬にしろ、基本的に後手に回る対応しかできないから。
結局のところ、「検査で見つけて治療する」以外の道なんかない。
けど、諸外国はともかく、総人口が減っていく日本ではそれは難しい事だ。
医療機関には過負荷でダメージを与え、オフラインB2Cには閑古鳥でダメージを与える。
オフラインB2C廃業で失業者が増えても人が足りない医療機関に流し込むというわけにもいかない。
治療薬が承認され流通したら少しはこの状況は緩和するのかもしれないが、
変異し続けるウィルスに治療薬はどこまで追随出来るのか、不安は尽きない。
つくづく、凄い時代に生きてるんだと実感させられるな。
同じ研究室の卒論なんぞまあまああてにならない（書いたのは君らとほぼ同じ状況だった人たちだぞ）のだから、参考にするならせめて修論以上にしとけ。
過去の卒論なんて「あの先輩これで卒業したのか」以上の知見は無いし、お前がそれを上回れる保証もないだろ。役に立つとしたら、せいぜい概要と参考文献くらいだ。
嬉しいことがあったけど、知人には言えないからここに書いて捨てる。
出会って10年、結婚8年目の夫の年収が1000万円を超えた。
うちは共働きで、私の年収は500万円くらいなので世帯年収1500万円である。
豪勢な暮らしとまではいかなくとも、都内建売住宅のローンを払いつつ、子供を希望する学校に入れたり、時々旅行に連れて行ったりしながら、老後の貯えも少しはできるかな…という感じで、
元々貧乏暮らし出身で、贅沢するタイプではない私には充分過ぎる額だと思う。
10数年前に転勤で東京から夫の故郷のある地方に住むことになり、趣味のつながりで夫と出会った。
当時の彼は、社員数50人くらいの地元企業勤めで年収400万円くらい。
口下手で女慣れしてなくて、全身サイズの微妙に大きいユニクロの服を着ており、特にモテるタイプではなかったんだけど(後で聞いたら私が初めての恋人だった)、
自分の好きなものを淡々と好きでいて精神が安定しており、私の話をちゃんと聞いて、私の気持ちを尊重してくれるところに惹かれた。
しばらくして私は東京に戻ることになり、遠距離恋愛後、結婚することに。
私は仕事を辞めたくなかったので「結婚に伴って転職するなら彼の地元よりは東京の方がチャンスが多い」と彼を説得して、東京に来てもらうことになった。
その際に色んな人に色んな事を言われた。
「(彼の地元)に来てくれないような我儘な嫁はうまくいかない」
更に彼の転職活動がなかなか上手く進まず、結婚式を無職で迎えてしまったので
「今からでも遅くないので考え直せ」「絶対失敗する」と非難轟々だった。
社員数300人くらいの会社で、彼の経験がそのまま活かせそうなのと、前職の年収(400万円)を保証してくれると言うので良かった、とほっとした。
そしたら、その転職先がちょうど事業を拡大する時期だったようで、あれよあれよという間に1000数百人規模まで大きくなった。
彼も一生懸命頑張ったしタイミングも良かったみたいで、ちょうど定年退職で空いたポストに抜擢されてとんとん拍子で出世した。
結婚したとき私の年収は600万円くらいだったので、2人併せて1000万円あれば大丈夫！私が頑張る！と思ってたんだけど、
子供の送り迎えと働き方改革で残業が激減した結果、私の年収が下がった。
私の希望で夫にはいろんなことを強いてしまってずっと引け目を感じていたので、本当に良かった。ものすごく安心した。
という話でした。ありがとうございました。
https://font-da.hatenablog.jp/entry/2022/01/18/223359 より引用
直接のきっかけは、例の「オープンレター」です。はてなもやはり、その話題で持ちきりのようですし、見るたびに精神状態が悪くなるので距離を置こうと思いました。また、今も私が書いた記事に反応がありますし、揶揄的なコメントがつけられたりすることもありました。誰を責めたいわけでもなく、コップに注がれていった溜まりに溜まって水が溢れてしまったように、「やめよう」と思ったに至ります。これまで何度も炎上してきた私が、なぜ、この件に関してだけひどく落ち込むのかは、大学外の方にはわかりにくいと思います。とにかく、私にとってはこの件は受け止めきれない出来事でした。女性が研究者として日本のアカデミアで生きていくことの困難を突きつけられたからです。
また、これまで個人的に関わったセクハラの問題でも、同じようなことを目にしてきたことがあります。みな、最初は被害者に同情的ですが、だんだんと被害者の行動を咎め始め、そのうち「加害者こそが〈本当の被害者〉なのだ」と言う人が現れます。最初は両手をあげて被害者を支持すると言っていた人たちが、次々と沈む船から逃げるネズミのごとく離脱していきます。「被害者に寄り添う」というのは美しい言葉ですが、最後までそれを完遂する人はほとんどいません。いつも同じことが起きます。みんな、「声をあげてほしい」と被害者に言うのに、いざ、自分に火の粉がかかるとわかれば手のひらを返すのです。わかっていても、それを目にするのはしんどいことです。
いったいどこの誰が火の粉が降りかかるとわかれば手のひらを返したのか。
沈む船を沈めたのは誰のどういった行いだったか、本当に理解できているのか。
セクシャルハラスメントの被害者であればいついかなる時も無謬を永久保証されるのか。
自分の思い通りにいかなかったから、自分の間違いを指摘されたからといってすべてをセクシャルハラスメントに結びつけるのはおかしい。
呉座勇一氏のセクシャルハラスメントはそれ相応の非難をされてしかるべきだが、北村紗衣氏やid:font-da のオープンレター無断名義使用問題に対する態度も非常に度し難い。
頭に障害があるらしい。
27歳の時わかった。高卒で入った会社でパワハラといじめに負けて鬱病になって退職。それから5年の事だった。5年何をしてたかと言うと小説を書いていた。医者からもう普通の仕事は無理だと言われていて、就労不可だと言われてきたから障害年金で生きながらえていた。小説を書いてたのは文章を書くのが好きだったからと、もしかしたらデビュー出来るかも＝職につけるかもと思ったから。25の時に別の媒体でデビュー出来たけど即打ち切りになった。その程度の実力。
その後生活保護になる。生活保護が嫌だったので医者に頼み込んで就労許可出してもらった。27歳の時だ。よし就活するぞの時にわかった。知的障害があると。
つまりは才能が無いってことだ。
知的障害と言っても重度じゃない。見た目は普通。質疑応答が出来ない。日常生活も無駄話したらあれ？こいつ変だぞ？って思われるレベルだ。結構大概。
でも障害者施設にぶち込まれるのは嫌だった。若い時に精神障害者に関わってとんでもなく怖い目にあったからだ。それも1度や2度じゃない。精神障害者と関わって実質住所不定になったこともあった。なので障害者専門の就職はしなかった。精神障害者ってめっちゃ怖い。俺も他人から見たらそう思われてんのかな。
小説を書くようになった。
これしかやれることがなかった。
受からない。
それでもやるしかなかった。
32の時、心が折れた。
友人がデビューしたからだ。友人は初めて書いた作品で、結構大きい賞を取った。友人は20代の時に結婚している。持ち家もある。
天は二物を与えずとか言うがアレは嘘だ。
別の友人を経由してそれを知った時、自殺をしようとした。薬が足りなくて未遂で終わった。ぐっすり寝ただけ。死ぬ才能もなかったらしい。
なあ、もう俺頑張ったよな？
もう諦めていいよな？
生活保護とか障害年金ってさ、すっっごく生きてるのが申し訳なくなるんだ。
でさ、働こうとしても皆止めてくるんだ。やめてくださいまた死ぬ気ですか！？ってさ。俺は普通になりたいだけなのにな。あと生活保護は働くと何故か返納金が大変な額になる。なんでだろうな。
国に飼い殺しってプライドがズタズタになるんだ。なんで生きてるんだろって思うんだ。最低生活の保証はされてるから、本当に何もしなくていい。そういう時、なんでか涙が出てくるんだ。
もうやめていいよな。
俺頑張ったよな？
税金で養う奴が1人減る、これが俺が出来る最大の事っていうか、俺はもしかしてそのために生まれてきたのかなと思うとなんだか笑えてきて、人生って案外意味ないんだな。
はっきり言ってあなたの母親と兄弟はまともじゃないからどうやっても穏便に別れることはできない
その環境から脱出してまともな生活を送るためにはこの先の人生で二度と近付かない近付けさせない覚悟と脱出するために体力を使う覚悟がいる
デモデモダッテしているうちにどんどん状況は悪化するから、こんな場所でも相談できた今が最高のタイミングだと思って動いてほしい
社会人なら銀行カードの無担保ローンが契約できるだろ。30万借りて今すぐ賃貸を契約して引っ越せ
もし無担保ローンが付いてないなら新規口座を開いてそれに付けろ。今持ってる口座に付けるより早い
30万あれば敷金手数料前金有りの部屋でも契約できるから部屋の選択肢が拡がるし、少し頑張るだけで完済できる金額だ
賃貸契約で保証人が必要と言われたら家賃保証会社を紹介してもらえ、今はどこの不動産屋でも提携してる
契約したら印鑑、通帳、自分の保険証、免許証、あと大事な物だけ持ってすぐ実家を脱出しろ
睡眠は生活の基盤だから、まず安心して眠れる巣を確保することが大事。DV受けてるんだから引っ越し先は家族には絶対に言うな
部屋を借りたら可能な限り急いで転居届を出す、その時に「DV等支援措置の申出」をすること
これは仕事を休んでもやるべき、優先度は高い
転居した後からでもいいからDV相談した機関の意見を申込書に書いてもらって提出する
会社には「付き合ってた男がストーカーっぽくなって引っ越した、男は家族とも仲良しだから家族から問い合わせがあっても教えるな」と頼めばいい
他にもいろいろやるべきことはあるけどDV相談した機関が教えてくれるだろう
早期脱出できることを祈る
