🎓 レベル：基礎 | 重要度：A（必須）
📎 前提：分散システムとは・なぜ難しいか | 関連：障害モデル（クラッシュ・オミッション・ビザンチン）・配送保証（at-most-once・at-least-once・exactly-once）
要点（BLUF）
- **8つの誤謬（Fallacies of Distributed Computing）**は、Peter Deutsch らがまとめた「分散の初心者が無意識に置く、しかし必ず破れる前提」の一覧。
- どれも「単一マシンでは正しかった暗黙の仮定」が、ネットワークを跨ぐと破れる。バグの多くはここに根がある。
- 対策は共通して「前提を仕様に格上げする」こと：失敗・遅延・順序乱れ・帯域有限を、例外でなく通常運転として設計に織り込む。
問題設定 ── 暗黙の前提が破れる
ローカル関数呼び出しと同じ感覚でリモート呼び出しを書くと、下の前提を無意識に置いてしまいます。RPCの「透過性」（RPCとRMI）が、皮肉にもこの錯覚を助長します。
一覧 ── 8つの誤謬と、効いてくる設計
| # | 誤謬（こう思い込む） | 現実 | だからどう設計するか |
|---|---|---|---|
| 1 | ネットワークは信頼できる | パケットは落ち、分断は起きる | 再送・冪等性・タイムアウト |
| 2 | レイテンシはゼロ | 往復に数ms〜数百ms | 通信回数を減らす・バッチ・非同期 |
| 3 | 帯域は無限 | 有限・輻輳する | ペイロード圧縮・ページング |
| 4 | ネットワークは安全 | 盗聴・改竄・なりすまし | 暗号化・認証（→ サイバーセキュリティ） |
| 5 | トポロジは変わらない | ノード追加削除・経路変更は日常 | サービス発見・一貫性ハッシュ |
| 6 | 管理者は1人 | 多数の運用主体・設定差 | 設定の外部化・冪等な運用 |
| 7 | 転送コストはゼロ | シリアライズ・直列化に CPU と金 | スキーマ・効率的エンコード |
| 8 | ネットワークは均質 | OS・バージョン・MTU がバラバラ | 標準プロトコル・相互運用 |
仕組みの直観 ── なぜ「信頼できる」と思ってしまうか
開発機では全プロセスが同一ホスト、ロスもほぼ0、遅延もμs。テスト環境が嘘をつくのです。本番では別データセンタ・別リージョンとなり、1〜4が一気に牙を剥きます。
flowchart LR
DEV["開発機（全部ローカル・ロス0）"] -->|"そのまま本番へ"| PROD["本番（跨DC・ロスあり・遅延大）"]
PROD -->|"前提1〜3が破れる"| BUG["タイムアウト連鎖・二重実行・輻輳崩壊"]
要するに何か：誤謬は道徳の話ではなく、「どのテストを本番相当にすべきか」のチェックリストです。各項目を「わざと壊して試す」（遅延注入・パケロス注入＝カオスエンジニアリング）と、設計の穴が見えます。
正しさの観点 ── 誤謬と安全性/活性の対応
- 誤謬1（喪失する）を放置すると、再送による二重実行が安全性を壊す → 冪等性（配送保証（at-most-once・at-least-once・exactly-once））。
- 誤謬2（遅延ゼロでない）を放置すると、タイムアウト設計を誤り活性が壊れる（早すぎる諦め＝誤検知、遅すぎる諦め＝無応答）。
- 誤謬5（トポロジ不変）を放置すると、ノード増減のたびに大規模再配置が起き可用性を損なう → 一貫性ハッシュ。
⚠️ よくある誤解・落とし穴
- 「リトライを入れれば誤謬1は解決」→ 冪等でない操作のリトライは状態を壊す。リトライと冪等性はセット。
- 「誤謬は古い（光ファイバで解決）」→ 帯域や遅延は改善しても、分断・順序乱れ・部分故障は物理的に残る。むしろクラウド/マイクロサービスで悪化。
- 「安全（誤謬4）はVPCの中だから不要」→ ゼロトラスト前提。内部通信も認証・暗号化（→ サイバーセキュリティ）。
対応ラボ
なし（概念回）。遅延・喪失の影響は 配送保証（at-most-once・at-least-once・exactly-once） のラボで冪等性として実証します。
関連
- 故障を型で扱うのが 障害モデル（クラッシュ・オミッション・ビザンチン）
- 喪失・重複への王道が 配送保証（at-most-once・at-least-once・exactly-once）
- トポロジ変化への対処が 一貫性ハッシュ