  |
はてなキーワード: 信頼性とは
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
オープンソースで活動してる人間です。気になる点があるのでいくつかピックアップ
OSMを元に作られてはいない。地図データとしてOSMを利用しているだけ。かつてはGoogleMapを利用していた。OSMより使い勝手の良い地図データがあれば乗り換える可能性もある。
ただ乗りを許さない！というのであれば、ライセンスを変更すれば良い。貢献がマストではないのに「貢献していない！ただ乗りだ！」はお気持ち表明に過ぎない。
改ざん動機が何にあるにせよ、そもそも信頼性の薄い、登録したばかりでコミュニティの貢献度の少ない参加者がダイレクトに本番データを修正できる点を考え直した方が良い。
新人は報告するにとどまり地図データは編集権限のある者が修正するなど、改ざんを防ぐ方法はある。OSMも規模が大きくなっているのだから、時代に応じた運用を考えるべきだ。
お気持ち表明はわかった。ただ、オープンソースの運営はお願いだけでは厳しい現実がある。wikipediaだってそうだろう。
niantecに問題がある・ただ乗りするなと叫ぶより、この件をきっかけにしてオープンソース運営を見直すきっかけにすれば良い。
だからもし、法定通貨が打ちのめされてブロックチェーンが覇権をとったら面白いと思う。
RDBのボトルネックを解決するかもしれないブロックチェーン技術というのにもかなり興味を持ってる。
いつかは必ずこっちが勝つとは思うんだけど、、、、
今の界隈に関して少し違和感がある部分に関してまとめておく。
よく批判に挙がる早い者勝ちとかガス代に対する批判は個人的には別にそんなに気にならない。
どんな市場も早い者勝ちだし、ガス代だってある程度歪でも広まっているんだから問題ないし、ビットコインの信頼性を担保に法定通貨が取引されてる現状だって、個人的には全然ブロックチェーンの勝利だと思っている。
それよりも、ブロックチェーン需要はどこにあるのか？というのに違和感がある。
以前からdappsと呼ばれるものには興味があるんだけれど、dappsの多くは需要ドリブンで利用されてるんだろうか？？
ゲーム自体が楽しいからやるのではなくて、投機目的でアイテムを手に入れたいとかってゲームをやってたりしないだろうか？
Defiもそう。供給側がたくさんの価値のある通貨を持っていたり、なんらかの市場に対する投機なり投資目的で参入してきていないかな？
ここまでの認識が間違ってるなら間違ってるって教えてほしい。
でも、間違ってないなら、ちょっと供給過多な市場って気がするんだよね。
もちろん、一部では優れたゲームやブロックチェーンベースならではの優れたdefiの仕組みがあるなら教えてほしい。
Braveやaudiusは需要ドリブンになっていそうでおもしろいなぁと思っている。
ウェブサイトの広告以外の収益源はずっと課題だし、アーティストにとってSpotifyやiTunes収益分配は課題だと思う。
ブロックチェーンって需要はこうやってみるとそんなにないかもなぁって気がするんだけど、DXという需要は確実にあるよね。例えば電帳法の改正とかは確実に需要がある。
で、これらって技術的にはブロックチェーンが得意な分野だと思うんだけど、普通のWebアプリで解決しちゃう人が多いと思うんだよね。Web3で解決しようぜ！っていう人も中にはいるかもしれないけれど、需要がWeb3までまだ辿り着いていないんだと思う。
Web3はどんどん盛り上がってほしいと思うけれど、「素人が手を出してこれ全然役に立たない！最悪」って空気にはなってほしくないんだよな。
逆にプロの人にはどういう需要に対して、何を解決できるか？というのを真剣に考えて、いい感じに市場にしてほしいなぁと思います！
婚活したくない
・パーティは高いし参加者はガチャ。7，8人と10分弱話して5000円。
高くて疲れるのはコストだからまだいいとして、たいして条件のいい女がいなくても、パーティで競わされると一番条件のいい女をゲットしたくなるし、それを他の男にもっていかれると普通に悔しい。
マスクで顔が隠れてるから、なんとかマッチングしても、外してみたら全然タイプじゃないなんてこともあり
・マッチングサイトは反応なしやお断りが大多数、お断りは「一応送っとくか」程度の女にされてもなんかむかつくし、反応なしは単純に無礼で待ってる時間が嫌。
おまけにあってみたら顔が写真と違うこともある。
女を奪い合う男側にしても年収爆盛りしたりしてる不誠実な男と競わされるのがキツい。
・結婚相談所も入会金だ活動費用だで平気で2桁万円が吹き飛ぶのがキツい。情報や写真の信頼性は増すが、高くて疲れるしゲットできるまでフラれつづけるには変わらず、婚活パーティより全体的に苦痛が多そう。
・今の生活より生活レベルを落とすのは耐えられない。生活のアップデートの一貫として世帯年収を増やしたり登場人物を追加していきたいのが主。
・子供は特に考えていないができてしまったら仕方ないと思う。ただ、それは完全に親のエゴなので、産むなら不自由ない環境や容姿を与えてやらないと貧困の再生産になる。
自分が受けた親からの投資と同じぐらいかけられないなら産むべきではないと思う。
・なので女側にも共働き、同程度の年収を望むが、女は自分の年収より高い男を選ぶ傾向にあるようで難しい（相談所の人間に聞いたところ、自分より年収の低い男は「尊敬できない」と思われるのだという）
・年収のある女を探す場合必然的に歳はかなり上になるようだが、容姿や肉体の価値は加齢に応じて低減していくので、結婚をしてまでその価値が低い状態の女を確保しておくのはデメリット。
あの程度の価値の女としか結婚できなかったのか、と他者に思われるのもきついし、結婚相手でマウントをとられる要素はできるだけなくしたい。
・同程度の年収かつ共働き前提で、かつ容姿の価値が高い状態の相手なら結婚しても（万一子供ができても）いいかなと思うのだが、なかなか難しい。
朝起きたら「結婚して良かった」と思える程度の容姿の女が横にいて、金銭的にも不自由なく生活できて初めて、現在と同程度に幸せになれるのだと思う。
かといって非婚を選ぶこともしたくない
・非婚化が進んでいるといっても結婚できている人間は周囲にも世間にもたくさんいるので、「結婚できなかったやつ」と思われたくもない。
・現在の生活はそれなりに気に入っているが、何かすごく熱中したり名を遺せている分野があるわけでもないので、非婚を選んでまでやりたいことというのもない。
・趣味なども基本一人で行うものなので、結婚しないと他人とのつながりがなくなり、近いうちに孤立するのは予測できる。しかし、それをよしとできるほど完全に人間とのかかわりを遮断して生きていけるとも思えない。
・今はそれなりに良い生活を一人で送っているが、それが一生続くことが幸せであるとも断言できるほどではない。
こうして書いていると結婚すべきではないタイプの人間だとも思う
・女を条件でしか見ていない、手段としてしか見ていないという指摘があるだろうが、おそらくその通りで、「何もかもを投げ出して自己犠牲にしてでもつなぎ止めたい」と思うほどの相手に出会ったことがない。
・そもそも男女問わず、そこまで強い感情や興味を他人に抱いたことがない。
・このままだと結婚しても幸せにはなれないだろうとも思うが、しかし結婚しなかったとしても幸せになれないだろうことに変わりはなく、ならせめて他人からは幸せに見える程度の体裁は確保しておきたい。
・結婚すべき人間でないから結婚しなかったとして、それで結婚できた人間ほど他者や世間は自分を認めてくれないと思う。
その他気になること
・自分にしか関心がない、というのは一般的でないのかもしれない。もしかしたら、他者の人格や人となりに興味を持ったり魅力を感じたりすることが一般的なのだろうか。
そう考えると、結婚できないのは条件面で負けているというよりは、人間関係構築のスキルが育っていないからだといえる。が、今更どうしろというのか。
・女が自分より年収の高い男しか愛せないというのは、要は「獲物をとってきたり他の部族と戦って自己犠牲してくれるオスを選ぶ」ということなのだろう。自己犠牲を強いることが男性の性的搾取とどこかで見たが、実際そうだと思う。
・共働きをしたくない女もまだいると聞いてウワーとなるが、共働きしないといけないのは女の年収を低く据え置きしている社会のせいであって、その責任をなぜ俺が引き受けなければならないのか。
・婚活系のサービスは結婚したい男女から搾取しているように感じてしまい辟易する。機会や情報を提供される価値はあるとは思っているのだが、にしても高いしつかれる。
・趣味で結婚相手を探せば、と言われたこともあるが、女に対して彼氏がいるか等の情報をそれとなく聞き出すのも大変だし、他の男よりサークル内で優位に立って自分をアピールしたり、人間関係のパワーゲームをやるのも非常に面倒。
・ここまで出てきた「他者」とか「世間」は、本当のところ自分に内在する規範意識やプライドだという自覚はある。だからどうって話なのだけど。
総合して
・他人に興味がないこと
どれを解消するにせよかなりの時間がかかる。その間にどんどん年をとり外見も衰え、周囲にはもっと高年収の競争相手が増えて、自分の条件は相対的に悪くなっていくことは想像に難くない。
質の悪いことに、婚活には終わりがない。試験や就活のように、あなたはこのレベルなのでここでおしまい、と決めてくれる存在がいない。
例えば「賃貸 探し方」で調べると上位表示されるのはSEO対策をふんだんに盛り込んだ大手企業運営メディアの誘導記事や不動産サイト登録のインセンティブ目当てのいかがでしたアフィ記事で埋め尽くされるが、
「賃貸 探し方 なんJ」で調べると5chの過去ログやまとめサイトが出てくるので
「○○(大手企業運営の不動産検索サイト)は釣り物件だらけでゴミ」
「使いにくいけど□□を使うと不動産会社が使ってる検索システムに近い情報が手に入るから掘り出し物件がよく見つかる」みたいな生に近い声を手に入れやすくなるということらしい。
5chまとめサイトはそれはそれでアフィブログとして嫌われてるけど、それでもいかがでしたブログよりは情報に価値があると思われてるとか。
ビジネスや教育現場において、ときには1000台以上のパソコン端末を管理しなくてはならないケースがあります。この際、各端末を一元管理するために用いられるのが「ネットワークブート（＝ネットブート）」です。
今回は、大学や専門学校などの教育現場にも採用されることが多い一元管理システム「ネットワークブート」の概要と導入するメリットについて紹介します。
通常、コンピューターを使用するためにはWindowsやmacOSなどのオペレーティングシステム（OS）を各端末に導入する必要があります。これに対して、情報処理のほとんどをサーバーで行い、ユーザーが操作する端末自体の処理を必要最小限にする運用方法を「シンクライアント」といいます。「ネットワークブート」はシンクライアントの方式の1種であり、構築したネットワークを通じて、サーバーからOSなどの情報を取得して起動するシステムのことです。原則、ログイン情報を打ち込むだけでネットワーク内のどの端末からでも、アプリやファイルなどの環境を再現できるため、パソコン教室に設置するデスクトップパソコンなど不特定多数が使う環境に適しており、教育機関に採用されやすい理由の1つです。
ネットワークブートと同じ意味で使われることが多い「ネットブート（Net Boot）」ですが、厳密にはネットブートはmacOSの機能の1つで、macOS Serverからの指示によって構築したネットワーク上のMacを起動・操作するシステムのことです。
この機能によって遠隔からのソフトウェアのインストールなども行えます。
ネットワークブート型と比較されることが多いシンクライアント方式の1つです。仮想環境に作成したデスクトップ環境をネットワーク環境下の各端末に転送して操作する方法で、ネットワークブート型よりもカスタマイズ性が高いことが特長です。また、ネットワークブート型よりも少ないリソースで運用が可能である一方、サーバー上で処理しなければならないのでサーバーの負荷やライセンス料が増大する傾向があります。
教育機関での利用においては、基本的に生徒は全員同じ環境で授業を受けたり、作業したりする可能性が高いため、VDI型の高いカスタマイズ性は必要ないケースが多く、ネットワークブート型が採用されることが多いです。
シンクライアントソリューションである「ネットワークブート」は、データなどをサーバー側で一元管理できるので、活用することでセキュリティ面や管理の効率化などに大きなメリットを得られます。
パフォーマンスが高い
端末側のCPU・メモリで実行するので、導入したiMacなどの性能を十分に活用できます。ネットワーク環境のPC台数が増えても、高速ブートが可能なので高いパフォーマンスが期待できます。
インストールするアプリケーションや端末側で利用する周辺機器に、原則、制限がなく使い勝手が良いのもネットワークブートのメリットです。「ローカルディスクがないPC」という感覚で利用できます。
管理が容易
詳細は導入先やシステムによって異なりますが、ネットワークブートと運用管理システムを組み合わせて一元管理することで、各端末の状態を簡単に把握できるほか、ログの採取、サーバー設定・更新の自動反映などが可能になります。これにより、少数の担当者でも運用管理が容易になるでしょう。
セキュリティの向上
近年、ネットブートが注目されている理由の1つが、セキュリティ性が高いことが挙げられます。各端末のデータはサーバーで管理するため、ユーザーが利用する端末にはデータは残りません。このため、データの流出などを未然に防ぐことができます。
これらのメリットに加えて、教育現場ではクラス替えなどがあって従来とは違う端末を生徒が使うケースでも問題なく、同じ環境で利用することができるほか、必要台数分の有料アプリケーションなどを購入すれば良いので、全生徒分のライセンス料などを払わなくて良いといった特長もあります。
ネットブート環境を構築するためには、導入先の独自のシステムとの連携や構築方法をしっかりと把握して仕様書にまとめる必要があります。規模によっては検討から運用供給まで1～2年かかるケースもあるので、ネットブート環境の構築の豊富な実績と経験がある業者選びが重要になります。三谷商事は1000台以上の大規模ネットブートを構築するなど、教育機関への導入実績を長年にわたって積み重ねています。大学や高等専門学校への導入事例をまとめているので興味のある方は確認してください。
※関連ページ：導入事例
厄介で関わりたくない人間を見つけて、避けたい、と言う状況を念頭に置くとして、
ミュートてさ、「自分から相手が見えなくなる」のはいいけど、「相手から自分が見える」のは変わらないんだよね。
だから「厄介な人間から自分が観測・補足されて絡まれるリスク」は減ってないんですよ。
ブロックなら「自分から相手が見えなくなる」かつ「相手から自分が見えなくなる」んですよね～。
ただしキーワードやハッシュタグ検索ではブロックされてる・してる人のツイートもヒットすることもあるんですが、そいでプロフィール見に行くとブロックされてることが分かるんですけど。そこで逆ギレされるリスクはあるっちゃある。
シャドーバンとか検索漏れとか、ツイッターってイマイチ信頼性がなくってしばしば取りこぼすんですよねー。ブロックやミュートと無関係でツイートやら通知を取りこぼすことがよくあるんですけど。
「ブロックすると逆上されることがあるのでお勧めしません」っていうガイドをしてる人も一理あるのはわかるんですが、「自分のツイートを厄介者に観測されてしまう機会を減らすこと」と、「偶然ブロックに気づかれてキレられる」こと、そのリスクを天秤にかけてどっちが安全なんだろう？ってのはあるよね。ツイッターアルゴリズムが謎なので何とも言えない感じ。
アルファツイッタラーとか、ある程度有名な人間は、スクショやブログ引用等の様々なTwitter以外の手段で自分のツイートが流通してしまいがちなので、ブロックに気づかれてキレられるリスクは高くなるような気がする。
逆に言えば無名な人間はブロックのほうがリスクが低くできる…かも知れない。
厄介者の思考回路は推測が難しいんだけど、「有名人にブロックされるとムカつくが、無名人にブロックされても何も感じない」んじゃないかなあ。わからんけど
中国の自動車メーカー、上汽通用五菱汽車の格安電気自動車（EV）「宏光MINI EV」が中国の地方都市・農村を中心に好調に売れている。名古屋大学の山本真義教授らが分解調査したところ、ブレーキや冷却システムを簡素化し、半導体などは既存品を転用することで50万円強の安値を実現していることが分かった。仕様の徹底的な割り切りによる同社の手法は、EV開発の常識を変える可能性がある。
インバーター基板の写真見て噴き出した技術者多いんじゃないかなと思うよ。
Casper-01(@MOTRA_3x2) - 44分前
もし高速で前を走っていたら離れないと…
NFK(@NFKgamer) - 13:00
やはり、人の命が安い国は違うなあ
平日狭いんです 💉💉7ヶ月経過(@xjfb314) - 12:36
ガソリンスタンドすら未整備な地域が多い。住民は自宅で充電できるゴルフ場のカートのような低速EVを足代わりに使っている。宏光MINI EVはその役割の代替に成功」
シュレディンガーの箱(@penguin__b) - 12:21
アプローチは全く違うけど、既存技術を組み替えて新製品に仕立てる手法はiPhoneに通じるものがある
amerio(@amerio28515428) - 11:53
》
「仕様の徹底的な割り切り」は信頼性を確保できるのかな。そう簡単には問題が顕在化しないのが困りものかもね。
5年後に路上で大量立ち往生しても「安いから仕方がないだろ」で終わるんだろうけど。
-------
jaway(@jawayjaway) - 11:13
専用品ではなく、汎用電子部品を選択、故障個所はモジュールごと交換と割り切ってるのか／
.陳(@naichin) - 11:04
日本製部品が全く使われていないというのが衝撃。全く完全に商機に携われていないのか。
日本には安全性認証などのコスト問題で入ってこないようだが、この低価格は魅力的で世界中でニーズがありそう。
ぽろ(@champoro1) - 10:46
低価格で機能を削ぎ落としたEV車市場は、日本で普及する可能性が高いが、この車の部品に日本製は採用されてない。
これを日本で販売する為に、安全上の法規制をクリアする必要がある。
普及させないために、法規制を強化してさらなるガラパゴス化に邁進する日本が透ける
質屋の七つ屋 鎌倉大船店(@7tsuyaofuna) - 10:11
専用設計せず既製品を使う、半導体は家電用のものを使う、回生ブレーキを載せない、、、ある意味潔い作りやね。
しやちく(@leemanoid) - 09:56
電気自動車の普及には電力スタンドインフラが問題に挙がるが、電気は各家庭に配備されているのでターゲット顧客を絞ればスタンドは不要となる。
ShonanITcare🐬ITC × TAKKEN × ENTREPRENEUR(@shonanitcare) - 09:47
「電装品は欧米有力メーカー製、耐久性が高い車載仕様ではなく家電用半導体を転用。交換しやすい設計で修理の手間は少ない。壊れやすいが直しやすい設計で価格破壊EV」・・短距離、家庭充電でインフラも必要無し
HIROSHIGE_COLOR(@simo_yan) - 09:41
"仕様の徹底的な割り切りによる同社の手法は、EV開発の常識を変える可能性がある。"
鉄馬(@tetsumah) - 09:36
•回生ブレーキなし
•部品は家電用を流用で寿命は短いが交換しやすい。壊れたら直せば良いの精神
回生ブレーキまで削ってるのか…
好き勝手に車を語るアカウント(@talking_car) - 09:20
山本 真義＠名古屋パワエレ武道会(@YamamotoPENU) - 09:03
日本では非常識な機能省略でも、これが低価格EVのデファクトスタンダードになりえるんじゃないかと。
Ken Kimura(@ken_glyph) - 08:58
ブレーキや冷却システムを簡素化し、半導体などは既存品を転用することで50万円強の安値を実現していることが分かった。仕様の徹底的な割り切りによる手法は、EV開発の常識を変える可能性がある。
パベルジャパン╱中国・アジア圏のリサーチ(@pabeljapan) - 08:53
自動車としてはやや怖い感じがするが、割り切りが凄い
井上雅史＠ものづくり企業 経営コンサル 上席コンサルタント(@masashi_i) - 08:52
自動車産業。欧州が脱炭素を謳い新技術で日本車のシェアを奪うなか、中国は簡素化と転用でローコスト化でアップサイクルを実現する戦略に。
「MINI EVは「壊れやすいが直しやすい」割り切りの設計思想で価格破壊を実現したEVといえそうだ」
ラテママ ♡フンモモFC No.69(@miwa_mz) - 08:43
悔しいが圧倒的じゃないか。
Mt.富士(@urrjb7PYbKJnUxO) - 08:29
.ver(@varjon_jp) - 08:27
中国の50万円EV「宏光MINI EV」を分解し、コスト構造を解析したリポートです。中国製の割安な部品をフル活用しているのはさることながら、EVで常識とされる再生ブレーキ・水冷システムを省いたことのコスト効果が大きいようです。
日経ASIA-TECH(@Nikkei_ASIATEC) - 08:24
車は耐久消費財だから売り出されただけでは評価できない。メンテナンスや性能の持続がなければ駄目。継続してウォッチする必要がありそうだ。安かろう悪かろう…では困るよ。
CIM / ｺﾝｽﾄﾗｸｼｮﾝｲﾝﾍﾞｽﾄﾒﾝﾄﾏﾈｼﾞｬｰｽﾞ株式会社(@CIM_coltd) - 08:14
せから🌟クラブ(@sekara_kurabu) - 08:13
命は軽視？
車検は通るの？
渡辺綱(@4604ydbc1) - 08:13
コストがかからない工夫と、壊れやすいが直しやすいというのが妙でした。
→
takechiri_00(@Takechiri0) - 08:01
kacchi25(@kacchi25) - 07:54
コストダウンという観点からすると、彼らは世界一の技術を持っているのかもしれない。『壊れやすいが直しやすい』という発想は日本企業では考えつかない。（というか、法的に許されない。）この発想を逆手に取ることで競争力強化に繋がる可能性も。
ご安全に‼︎⛑ 💪Lime-rofushi Fan Club No.819(@nomoto1985) - 07:43
Kiyo Chinzei(@kchinzei) - 07:09
中国の自動車メーカー、上汽通用五菱汽車の格安電気自動車（EV）「宏光MINI EV」が中国の地方都市・農村を中心に好調に売れている。
みるきぃ@投資で資産価値アップ(@musiclover0517) - 07:07
学ぶべきところは学んでおきたいですね。
ブレーキや冷却システムを簡素化し、半導体などは既存品を転用することで50万円強の安値を実現している
稲川 雅彦(@doyoda86) - 07:05
"耐久性が高い車載仕様ではなく、家電用の半導体を転用している。電装品は当然、故障しやすくなるが、モジュールごと交換しやすい設計なので修理の手間は少ない"
壊れたら交換すればええやん、さすがです
利用者の本当のニーズを考えると、こういう車もある。そこを攻めるならそれはアリ。家電や100均などでもそういうのを得意としてきたのだから、日本もやるところが出てきてもいいと思うのだが。
のとみい(@noto_mii) - 06:57
中国の自動車メーカー、上汽通用五菱汽車の格安電気自動車（EV）「宏光MINI EV」が中国の地方都市・農村を中心に好調に売れている。
龍ノ髭🄬🌟🌸🌈☀(@HotheartTake) - 06:48
家電同様、”無駄に高性能”な日本製EVでは到底太刀打ちできないなぁ（嘆）
アシスト🍜(@byassist) - 05:18
以上
若くないし、数学を学びなおすには遅すぎると思って尻ごみしていたが、そこを一念発起。
というか軽い気持ちで。ぶっちゃけると分散分析とやらに興味を持ったから。
統計的に有意差があったといわれてもその意味がさっぱりだった。
一応、理系の大学を出てるので、有意差という単語をちょいちょい耳にはしていたが、
「よくわかんないけどt検定とかいうやつやっとけばいいんでしょ？」
くらいの理解だった。
で、ありがちな多重比較の例で、3群以上の比較にt検定は使っちゃダメだよっていう話を聞いて、なんか自分だけ置いてけぼりが悔しくなって、Amazonをポチッとしたのが全ての始まり。
あと、あの頃はライン作業の工員だったから、脳が疲れてなかったし。
みんな数学とかプログラミング、とくにPythonの無料講座は無言ブックマークしてるから興味あるっぽいので、参考になれば。
アドバイスとかくれると嬉しい。
いきなり当たりを引いた。
軽妙な語り口で、懇切丁寧。受験の参考書の実況中継シリーズをわかりやすくした感じ。
何者だと思ったら元航空幕僚長。
手を動かさずとも数式を追えるくらいの丁寧な式変形。かゆいところへのフォロー。
前述の「実験計画と分散分析のはなし」よりも易しめの「統計のはなし」「統計解析のはなし」から始まり、「QC数学のはなし」「信頼性工学のはなし」「ORのはなし」「予測のはなし」「論理と集合のはなし」までぶっ通し。
しかし、やっぱり「実験計画と分散分析のはなし」が一番印象に残ってるのは、その後の勉強に役立っていったからだと思う。
余談だけど、最近亡くなったそうだ。ご冥福をお祈り申し上げます。
それと、
本当は、回帰分析編を買うつもりだったんだけど、マーケットプレイスから間違えてこっちが届いた。
大村さんの本はぶっちぎりでわかりやすいんだけど、あと一歩踏み込みたい。
共分散分析、平行線検定法、プロビット法、自分の住む業界で聞いたことがある単語が大村さんの本にはのってない。
そんなわけで頼ったのがこのページ。
統計学入門
http://www.snap-tck.com/room04/c01/stat/stat.html
t検定くらいならExcelでも一発でp値を出してくれる関数があるけれど、そこから一歩二歩踏み込んでいくと、自分で「あれの平方和を計算して」、「あっちの平方和を計算して」、「サンプルサイズが不揃いだから平均値で代用して自由度で補正して」、ということをExcel上でやらにゃならなかった。
1行に1レコードの形式じゃないとやり難いなぁ。そうじゃないとサンプルサイズが変わるごとに計算列が変わって困る。
と、おぼろげながらtidyデータの概念に気づく手前に来てた。
勉強ブームは2013から2014年くらいまで。そこからしばらくはなんもやってない。
そんななか、2018年ごろ、タグチメソッドの入門書と出会う。
「Excelでできるタグチメソッド解析法入門」広瀬 健一 , 上田 太一郎
これがまた面白い。
有意差があるかどうかじゃなくて、それを使ってどう改良するかか！
ついでに、その中で使ってる手法からコンジョイント分析にも興味が出る。
ははーん、人文科学の世界でも使えるんだね、分散分析と実験計画。と。
（分散分析をコンジョイント分析と呼ぶと怒られるけど、許して）
と読み進む。
この辺から、行列の計算が出てきてExcelでは限界を感じるようになる。
後編に続く
https://japanese.engadget.com/microsoft-edge-try-stop-user-download-chrome-050051364.html
※タイトルはあくまで時間軸的な前後関係を示しています。因果関係の有無を論じるものではありません。
この日記には、あくまで私の私見しか書かない。この日記をもって、何かをディスってやろうとか、政治的な動きをやろうなどという意図は持っていないことを先に記す。
8月半ば、私は流行病のワクチンを接種した。何の病かは、前後の文脈や記事の投稿時期を見て察して欲しい。自治体の集団接種会場でP社のものだった。1度目の接種はあっけないほどにすぐ終わり、副反応も「接種した側の腕を動かしにくい」というような、軽微なものだった。
9月初旬、2度目のワクチンを接種した。もちろんP社製である。しばらくすると1度目と同様に腕が痛くなり、今度は37.5℃程度の微熱が出た。しかし2日ほどですぐに収まった。「39℃近くの熱が出た」とか「全身が痛んで辛すぎる」とか、SNSで見かけるようなことは全くなかった。用意したレトルトパウチのお粥やスポーツドリンク、解熱剤も結局使うこと無く押し入れに閉まってしまった。
「あっけなかったなぁ」
そんな感想しか抱けないくらいには、何もなく接種後の時間は過ぎていった。できればそのまま過ぎて欲しかった。本当に……。
2度目の接種から5日後、頭の左側から「にぃーん」とか、「にゅいーん」とかいう音がした。耳鳴りの発症だった。ニイニイゼミの鳴き声をうんと高周波にしたような音だ。都会でたまに聞くネズミ避けのモスキート音という例えでも適当かもしれない。遠くで聞こえる遮断機の音よりもうるさい。下手をすると、風呂場の換気扇の駆動音よりは少し小さいかも……くらいの音量だ。
その日は爆弾低気圧が来ているらしいことを天気予報が言っていたので、最初は気圧のせいに違いないと思った。しばらく様子を見ようと思い、いつも通りに1日を過ごした。
翌朝。目覚めると、耳鳴りはまだはっきりと聞こえていた。昨日と変わらない音程、音量でそこにあった。明らかにおかしいと思った私は、近くの耳鼻科に駆け込んだ。
耳鼻科に入ってすぐ、私は聴力検査室に通された。その検査結果を踏まえ、医師は私に「低音障害型感音難聴」と診断を下した。左耳に聴力低下があったのだ。もっとも聴力低下の度合いがあまりにも小さいので、本来の診断基準では難聴の枠にすら入らない程度の出来事らしい。
彼は「このタイプの難聴は突発性難聴よりも、ずっと予後が良いよ。薬を飲めば治るよ」と言った。私は医学部生でもないので、それを信じるしかない。アデホス、メコバラミン、ストミンA、そして途中からイソソルビド。耳鼻科で処方された薬はこの4種類だった。
一ヶ月後、医師の言うとおり「難聴」は治った。聴力検査の結果は左右の耳が同程度にまで回復していることを示していた。けれども、耳鳴りは鳴り続けていた。
最終的に医師は「君は気にしすぎなんだ。耳鳴りなんて探すから気になるんだ」と言い放つと、そんなに心配ならと脳神経内科への紹介状を書いた。脳の問題からも耳鳴りは生じるらしいので、その観点で診てもらうといいとのことだった。
結局、それ以来その耳鼻科には行っていない。難聴が治ったならと薬も止められたし、もう来なくて良いとまで言われたのだから、言われた通りにしたのだ。
数日後、私は耳鼻科の医師に書いてもらった紹介状を手に、総合病院の脳神経内科へ向かった。いくつかの問診の後、MRIの撮影を行った。
撮影の結果、私の脳は画像上、まったく異常が無いことがわかった。脳神経内科の医師は「まぁ、そのうち良くなりますよ」と慰めの言葉をかけてくれた。が、それ以上何もなかった。以来、その病院には行っていない。
頼る病院がなくなり、途方に暮れていた私だったが、SNS上でLong-COVID外来を行っている医師が、ワクチン接種後に体調を崩した患者の診察も行っているとの情報を目にした。
藁にもすがる思いで、私はLong-COVID外来を行い、かつワクチン接種後に体調不良を起こした患者を診察した実績のある医師を探し始めた。
そのとき問題だったのが、医師の信頼性だった。先に挙げた条件に合致する医師は数人ほどいるが、中にはエビデンスに乏しい治療法を採用していたり、発言が過激だったりで信用できるか怪しい医師もいたからだ。
しばらく考え、最終的に首都圏でLong-COVID外来を行っている、とある医師に診てもらおうと決意した。
数日後、私はその医師がいる病院を訪れた。外来は大人気で、数時間待ちが当たり前のような状況だった。
そんな状況のためか、医師も相当に疲労困憊である様子が見受けられた。かなり大変そうであった……どうか、医者の不養生にならないようにお気をつけを……。
処方は漢方薬がメインで、触診や舌の様子の診断を通して、Long-COVID患者に準じた2種類の漢方薬を処方してくれた。柴胡桂枝乾姜湯と真武湯だった。
同時に、EAT療法というものが効果的であるとのアドバイスがあった。鼻の奥側にある上咽頭を、塩化亜鉛を含ませた綿棒で擦る治療法だそうだ。Long-COVID患者はしばしば強い上咽頭炎を併発しており、その治療に効果的とのことらしい。
またLong-COVID患者もしばしば耳鳴りを訴えるそうだが、EAT治療などを行っているうちに症状が消えることも少なくないらしい。
それから数週間後、先の医師から勧められたEAT治療を受けてみた。細長い綿棒で、鼻と口から上咽頭をぐりぐりと擦るのだ。痛い。めちゃくちゃ痛い。治療後は血痰が2日近く止まらなかった。
以上の経過を経て、現在に至る。
現在、耳鳴り発症から約3ヶ月ほどが経過した。定期的にEAT治療（週一くらい）を受けながら、処方された漢方薬を飲んで過ごしている。
耳鳴りの具合はというと……正直、発症当時から大して変わらないというのが本音である。時間経過で多少慣れたような気がしないではないが、非常にうるさいことこの上ない。
慢性化した耳鳴りは難治だと言われているそうで、治療は基本的に困難であるらしい。しかしながら、どうにかなって欲しいなぁという思いが強い。というかどうにかなってくれないと困る。
一応TRT療法というものもあるが、これは耳鳴りに対する馴化（慣れ）を生じさせるものであり、根治とはほど遠い。いくら慣れが生じたとしても、こんな生き地獄がずっと続くのには耐えられそうにもない。
また、現在受けているEAT治療は、一定の臨床例の報告こそあるが、日本発祥で国外での実施例に乏しい + 一時はかなり怪しい治療扱いされていた（現在は免疫学などの進歩により、一部機序が説明可能になってきたため再評価されつつある……らしい）ため、強力なエビデンスに乏しい。
そういう意味では、エビデンス作りのための治験を受けているようなもの（と勝手に思い込んでいる）でもあるため、どれだけ今の医師を信じていいのか……という考えもわずかに脳裏をよぎる（エビデンスのある治療を受けたくて医師を選んだはずが、結局のところ"まだまし"な選択肢しか選ぶことしかできなかったことへの無力感が近いかもしれない）。
ワクチン接種後に耳鳴りが発症したということもあり、同様の症状を訴える人がいないか個人的に気になり、調査をしてみた。
するとアメリカにて、ABCニュースのアリゾナ局とサンディエゴ局が興味深いニュースを配信していた。
1. ABC15, Unheard Concerns: Thousands blame COVID-19 vaccine for hearing problems (2021/9/17)
https://www.abc15.com/news/local-news/investigations/can-the-covid-19-vaccine-lead-to-hearing-issues
2. ABC15, UA Professor examines possible link between COVID-19 vaccine and tinnitus (2021/9/22)
3. ABC10, In-Depth: Can the COVID-19 vaccines cause ringing in the ears or tinnitus? (2021/9/22)
これらの記事は、アメリカにてワクチン接種後に耳鳴りを訴える患者が少なからずいること（接種者のうち1万人以上）、それについて、アリゾナ大学の教授が調査を行っている事を報道している。
しかし同時に、ワクチン接種が多くの命を救っていることや、耳鳴りとワクチンの関係について評価をすることが難しいことも述べられている（自然に発生する耳鳴り患者も多いので、接種期間における1万人の耳鳴り患者の増加は必ずしも多いとは言い切れないため）。
アメリカにおけるCOVID-19による死者数は同国における第二次世界大戦+朝鮮戦争+ベトナム戦争の累計戦死者を超えているそうで(https://www.yomiuri.co.jp/world/20210223-OYT1T50156/)、そのような状況においてワクチン接種が多くの命を救っている事実は疑いようがない。一方で僅かな人数かもしれないが、（因果関係は別として）ワクチン接種後に耳鳴りの発症を訴える人がいるのも事実のようだ。
近頃、国内でもワクチン接種後の体調不良を訴える人々が出てきている。以下の記事などが例であろう。
4. 河北新報, 「ワクチン後遺症」知って ２３歳女性、長引く体調不良訴える (2021/11/17)
https://kahoku.news/articles/20211116khn000045.html
5. 河北新報, ワクチン「後遺症、私も同じ」 社会的サポート求める声、全国から多数 (2021/11/30)
https://kahoku.news/articles/20211129khn000033.html
6. 中日新聞, 倦怠感、１カ月超の声 長引く副反応つらい (2021/12/2)
https://www.chunichi.co.jp/article/375877
これらの記事では、内容はあくまで患者の声を届けるに留まっている。ワクチン接種と症状の因果関係について深く論じることはしていない。
また、日経メディカルはワクチン接種後に体調不良を起こした患者を診察している医師についての記事を掲載している。
7. 日経メディカル, 谷口恭の「梅田のGPがどうしても伝えたいこと」 「ポストコロナワクチン症候群」は存在するか (2021/9/22)
https://medical.nikkeibp.co.jp/leaf/mem/pub/series/taniguchi/202109/572000.html
さらに、ワクチン接種後の体調不良を起こしている患者が厚生労働省などを相手にオンライン上で調査を行うように嘆願書を提出しようとしている。
8. chage.org, 長期化する新型コロナワクチンの副反応に対する調査と結果の開示、報道と理解を求めます！
アリゾナ大学の教授が行っている研究のように、今後も国内外でワクチン副反応やワクチン後遺症（ワクチン接種後の長期的な体調不良について、適当な表現が考えつかなかったため、このように述べる）についての事実や統計をベースとした検証・研究が進んでいくことを期待したい。
現状、ワクチンと体調不良を明確に関連付けるエビデンスのある資料を見つける事はできなかった。ワクチンが与えるベネフィットを考えれば、リスクは十分小さいと評価することは妥当だと考えられるかもしれない。マクロの観点から見れば接種を推進することに利がある（社会全体や経済を守り、少しでも多くの命と生活を守ることができる）のだと思うが、因果関係については別としても、接種直後に何らかの不調が慢性化しつつある身としては、接種後の体調不良を訴えるだけで「デマ」と言われかねない現状は、なかなか心情的に飲み込むというのは難しいというのが本音だ。
耳鳴りや体調不良は何もしなくとも発生する（健康だった人が突然倒れることもありうる）としても、この状況をすぐに受け入れろ、飲み込めというのはなかなか無茶な注文に思える。
もしもこの耳鳴りがワクチン後遺症のひとつなら……何か治療法が見つかるいいなぁ。一生このままは辛すぎるなぁ。
昨年はトランプ不正選挙騒動、今年は反ワクチンやイベルメクチンなど、陰謀論の勢いはとどまるところを知らない。
自分はTwitterで陰謀論者とレスバするという悪趣味な人間だ。陰謀論者たちと話していてわかったことをまとめたい。
陰謀論者たちは隠された真実を白日の下に晒そうと日々奮闘しているように見える。しかし、彼らの主張は数分使ってデータを調べれば完全に事実無根であることが明らかなことが多い。どう見ても陰謀論者の主張と矛盾する、信頼性の高そうなデータを見せると彼らはどう反応するのか？
彼らは必ずと言っていいほど、違うトピックの陰謀論を持ち出して「ではこれはどうなんだ？」と言ってくる。
例えば、「新型コロナウイルスは存在しない」という主張に対して「ウイルスはとっくに分離されている」という情報を提示すると、「ではワクチンが大量の死者を出しているのはどう説明するのか？」といった具合だ。
たいていの陰謀論者は「陰謀論ストック」を大量に蓄えており、1つ反駁されれば別のデマを持ち出し、弾が尽きるまで撃ち続けようとする（実際は早くにブロックされることも多いが）。
真実に目覚めていると言いつつ、反論できないと判断するとその主張は一瞬で忘れ、別のデマで戦おうとする。彼らは「何が正しいか」には驚くほど無頓着なのである。
陰謀論は社会の敵だと思うが、社会から白い目で見られる陰謀論「者」のことは正直気の毒に感じてしまう。たいていの陰謀論は少数のインフルエンサー的存在が発端であり、まんまと騙されインフルエンサーの養分になっている陰謀論者たちは「被害者」でもある。
そんな彼らは、自らの主張を「デマ」と唾棄する人間に対し攻撃的になっていることが多い。社会ののけ者扱いされ、信仰ともいうべき自分の意見を嘘扱いされれば、そうなるのも無理はないだろう。
そんな彼らに、時々優しくしてみることがある。暴言を吐かれても、「ゆっくり休んでくださいね」と返してみるのだ。
そうすると、彼らはペースが狂う。それまでマシンガンのように陰謀を撒き散らしていたのに、突然黙り込んだり、困惑しつつもそれまで不可能だった人間らしいコミュニケーションが取れたりする。得体の知れないブログサイトのリンクを貼り「それならこれはどうなのだ」と延々とデマをぶつけ続ける「陰謀論エンジン」がバグるのである。
ここからは自分の勝手な推論である。人々が陰謀論にハマるきっかけとして、日常生活がうまくいかないという事情が大きいのではないか（無論、そうではないパターンもあるだろうが）。
家族・友人関係がギクシャクしている、仕事がうまくいかない、就職先が見つからないなど、現代社会で生きていれば不安なことはいろいろあるだろう。そんな心の隙間を埋め、なにか特定のコミュニティへの参加を可能にするツールとして陰謀論は広まっているのではないか。かつて話題になった「父親が定年退職し暇を持て余した結果ネトウヨになってた」みたいな話も似た構造だろう。
人生がうまくいかないときに感じる「自分は多くの人が知らないことを知っている」という優越感はさぞかし中毒的だろう。エビデンスに基づいて反論したところで、精神の安寧を求めて陰謀論を信奉している人には無力だと思うのだ。
陰謀論者の主張のほとんどは事実に反している。しかも、難解な科学上の問題ではなく、説明されれば素人でも誤りが理解できるレベルである。
しかし、大前提を見るべきだ。多くの人々は科学的に正しいとされる知識を信じる。しかし陰謀論者は究極的には科学的な正しさを求めていない。
科学的裏付けがあるかのように話しつつ、実際のところは「科学的に正しいと証明したい」ではなく「自分を認めてほしい」「自分は正しい側にいたい」という動機があったりする。
話をする上での前提が違うので、「あなたの言っていることは事実に反していますよ」という論法で責め立てても、どっぷり陰謀論に浸かった人々には全く効かないのである。むしろ、攻撃性を増すだけだったりする。
どうすればよいか。正直解決策は思いつかない。もちろんエビデンスベースの正しさは重要である。新型コロナのデマは健康の問題に関わる。アメリカ大統領選のデマは民主主義という国の根幹に対する信頼性を貶めてしまう。最近流行ったデマは実害を伴うのである。
しかし、正しい情報を提示しつつも、精神的なケアの重要性はもっと強調されるべきだ。乱暴な予想だが、仕事がうまくいき高収入で、家族や友人関係にも恵まれ、心身ともに充実した人生を送っている人が陰謀論者になることはかなり稀ではないか。
よって、トランスユーラシア語族が成立するか否は別の問題として(成立するとしても言語連合と思っています)、先日琉語族の原郷が遼河流域になるという主張はかなり信ぴょう性が高いと私は判断しています。
そこについては別に意見は対立してないので、私に向けて力説される意味がわからないというか……私は既にanond:20211121201022で「言語学的な原郷が遼河流域という説自体は、個人的にはそれなりに「ありそう」だなと思ってる」と書いてます。ただロベーツの研究はなんらその証明になっていないし、原郷を（仮説やら蓋然性やら「ぼくの意見」やらの話ではなく）言語学的に確定させようと思ったら言語学的な手続きが必要不可欠だよと言っているだけです。
測量点の1つがあやふやならその測量の信頼性は揺らぐという話をしています。まず1つ1つの測量点をきちんと確定させるべきで、現状ロベーツがそれに成功しているとは思えません。
