カテゴリ: 法則
タイプ: ネットワーク／システム相互運用の原則
起源: Jon Postel; TCP 仕様（例：RFC 793, 1981）
別名: 堅牢性の原則（Robustness principle）
タイプ: ネットワーク／システム相互運用の原則
起源: Jon Postel; TCP 仕様（例：RFC 793, 1981）
別名: 堅牢性の原則（Robustness principle）
先に答えると — ポステルの法則（Postel’s Law）は堅牢性の原則：送るものは保守的に、受け取るものは寛容に（文書によって表現はやや異なる）。初期のインターネットプロトコルが不完全な実装同士でもつながるのを助けた。今日も設計のヒューリスティックだが、寛容さがバグを固定し攻撃面を広げうるため議論もある。
ポステルの法則とは
ポステルの法則（Postel’s Law）は、プロトコル実装への指針：送出バイト列は仕様に厳密に従い、意味が復元できるなら入力の解釈は寛容にという組合せです。仕様が成熟途上でピアが異なる時代の相互運用を狙います。コンウェイの法則（システムがコミュニケーション構造を映す——別軸）と並べ、ブルックスの法則（人を増やすと調整コストが増える——直交だが出荷制約に効く）とも対照になります。マーフィーの法則とは違い、ポステルは規範的です。3つの深さで見る
- 入門: 古いクライアントは奇妙な空白を送る。サーバは違法フレームは拒否しつつ、無害な揺らぎは正規化しうる。
- 実践: 出力は正準形で符号化。入力は許可リストで検証し、異常をログし、挙動を明示的にバージョン管理する。
- 上級: 寛容さをセキュリティ予算として扱う。寛容な受け入れが相互運用バグを生態系に固定する、という現代的分析がある。
起源
Jon Postel が初期 TCP/IP 作業で堅牢性を実装戦略として述べました。広く引用される表現は RFC 793（Transmission Control Protocol, 1981年9月）に見え、TCP 実装に堅牢性を求めます。厳密な生成と意味が保たれる範囲の寛容な消費の組は、その後のプロトコル・パーサ・API の語彙になっています。要点
相互運用を最大化し、その後で寛容さが安全を損なう場所を測る。応用場面
現代の API とプラットフォーム設計に写像する。プロトコルとパーサ
JSON や protobuf は厳密に送出。受信は曖昧や過大な入力を早めに拒否する検証層で。
Web フロント
保存時に入力を正規化。レンダリングでは依然エスケープ——寛容な UX は SQL インジェクション赦免ではない。
協業規範
外向きの約束は精密に。更新の言い回しには、合意した基準の中で善意の揺らぎを許す。
後方互換
API を明示的にバージョン管理。黙って永遠に癖を抱えるのではなく、廃止スケジュールを公開する。
事例
制度的アンカーはテキストである：RFC 793（1981）が、ベンダーをまたぐ TCP 実装に堅牢性を課す——RFC 番号と年という外部引用可能な標準であり、研究室指標ではない。その後の工学議論（2000–2020年代の ACM Queue / Communications of the ACM など）は、寛容な受け入れが相互運用バグを固定したかを再検討する——論点が「つながるか」から「寛容がデフォルトのとき不変量は守れるか」へ移った指標になる。限界と失敗パターン
限界1：セキュリティが単純な寛容を壊す攻撃者は、パーサが意図を推測する地点に曖昧な入力を作る。 限界2：標準は成熟した
現代のプロトコルは、黙って修復より明示的失敗を好むことが多い。 典型の誤用: テレメトリなしの無限寛容——癖が消せないレガシーになる。
よくある誤解
誤解：すべて優しく受け入れる
誤解：すべて優しく受け入れる
実際: 寛容なパースでも違法状態は拒否する。善意は安全と仕様の意図で縛られる。
誤解：ポステルは厳格検証を禁じる
誤解：ポステルは厳格検証を禁じる
実際: 保守的送信は規律ある検証と組になることが多い（構文と意味の層）。
誤解：もう古い
誤解：もう古い
実際: トレードオフは進化したが、相互運用が要る所には残る。
関連概念
コンウェイの法則
システム形はコミュニケーション形に従う——「互換」の意味は協調で決まる。
ブルックスの法則
人を増やすとコミュニケーションが増える——レガシー癖の修正にも時間がかかる。
マーフィーの法則
起こりうることは起きる——検証をそれに合わせる。