> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# ポステルの法則

> ポステルの法則（堅牢性の原則）は、実装に厳密な送信と寛容な受信を求めた。RFCの源流と現代の限界。

<Info>
  **カテゴリ**: 法則<br />
  **タイプ**: ネットワーク／システム相互運用の原則<br />
  **起源**: Jon Postel; TCP 仕様（例：**RFC 793**, **1981**）<br />
  **別名**: 堅牢性の原則（Robustness principle）
</Info>

<Note>
  **先に答えると** — **ポステルの法則**（Postel's Law）は堅牢性の原則：**送るものは保守的に、受け取るものは寛容に**（文書によって表現はやや異なる）。初期のインターネットプロトコルが不完全な実装同士でもつながるのを助けた。今日も設計のヒューリスティックだが、寛容さがバグを固定し攻撃面を広げうるため議論もある。
</Note>

## ポステルの法則とは

**ポステルの法則**（Postel's Law）は、プロトコル実装への指針：**送出バイト列は仕様に厳密に従い**、意味が復元できるなら**入力の解釈は寛容に**という組合せです。仕様が成熟途上でピアが異なる時代の相互運用を狙います。[コンウェイの法則](/laws/conways-law)（システムがコミュニケーション構造を映す——別軸）と並べ、[ブルックスの法則](/laws/brookss-law)（人を増やすと調整コストが増える——直交だが出荷制約に効く）とも対照になります。[マーフィーの法則](/laws/murphys-law)とは違い、ポステルは**規範的**です。

### 3つの深さで見る

* **入門**: 古いクライアントは奇妙な空白を送る。サーバは違法フレームは拒否しつつ、無害な揺らぎは正規化しうる。
* **実践**: 出力は正準形で符号化。入力は**許可リスト**で検証し、異常をログし、挙動を明示的にバージョン管理する。
* **上級**: 寛容さを**セキュリティ予算**として扱う。寛容な受け入れが相互運用バグを生態系に固定する、という現代的分析がある。

## 起源

**Jon Postel** が初期 TCP/IP 作業で堅牢性を実装戦略として述べました。広く引用される表現は **RFC 793**（*Transmission Control Protocol*, **1981年9月**）に見え、TCP 実装に堅牢性を求めます。**厳密な生成**と**意味が保たれる範囲の寛容な消費**の組は、その後のプロトコル・パーサ・API の語彙になっています。

## 要点

相互運用を最大化し、その後で寛容さが安全を損なう場所を測る。

<Steps>
  <Step title="相互運用が先">
    異なるベンダーと部分導入では、寛容な受信側がネットを使えるようにした。
  </Step>

  <Step title="出力の正準化">
    「保守的送信」は複雑さをテストされたエンコーダに集約する。
  </Step>

  <Step title="寛容な受け入れには境界が要る">
    スキーマ、ファジング、監視なしでは、寛容なパーサが脆弱性の温床になりうる。
  </Step>

  <Step title="生態系効果が支配する">
    多くのピアが癖に依存すると、修正は協調変更が要る——**バグごとの互換**圧力。
  </Step>
</Steps>

## 応用場面

現代の API とプラットフォーム設計に写像する。

<CardGroup cols={2}>
  <Card title="プロトコルとパーサ" icon="network-wired">
    JSON や protobuf は厳密に送出。受信は曖昧や過大な入力を早めに**拒否**する検証層で。
  </Card>

  <Card title="Web フロント" icon="desktop">
    保存時に入力を正規化。レンダリングでは依然**エスケープ**——寛容な UX は SQL インジェクション赦免ではない。
  </Card>

  <Card title="協業規範" icon="users">
    外向きの約束は精密に。更新の言い回しには、合意した基準の中で善意の揺らぎを許す。
  </Card>

  <Card title="後方互換" icon="clock-rotate-left">
    API を明示的にバージョン管理。黙って永遠に癖を抱えるのではなく、廃止スケジュールを公開する。
  </Card>
</CardGroup>

## 事例

制度的アンカーはテキストである：**RFC 793**（1981）が、ベンダーをまたぐ TCP 実装に堅牢性を課す——**RFC 番号と年**という外部引用可能な標準であり、研究室指標ではない。その後の工学議論（**2000–2020年代**の *ACM Queue* / *Communications of the ACM* など）は、寛容な受け入れが相互運用バグを固定したかを再検討する——論点が「つながるか」から「寛容がデフォルトのとき不変量は守れるか」へ移った指標になる。

## 限界と失敗パターン

**限界1：セキュリティが単純な寛容を壊す**\
攻撃者は、パーサが意図を推測する地点に曖昧な入力を作る。

**限界2：標準は成熟した**\
現代のプロトコルは、黙って修復より明示的失敗を好むことが多い。

**典型の誤用**: テレメトリなしの無限寛容——癖が消せないレガシーになる。

## よくある誤解

<AccordionGroup>
  <Accordion title="誤解：すべて優しく受け入れる">
    **実際**: 寛容なパースでも違法状態は拒否する。善意は安全と仕様の意図で縛られる。
  </Accordion>

  <Accordion title="誤解：ポステルは厳格検証を禁じる">
    **実際**: 保守的送信は規律ある検証と組になることが多い（構文と意味の層）。
  </Accordion>

  <Accordion title="誤解：もう古い">
    **実際**: トレードオフは進化したが、相互運用が要る所には残る。
  </Accordion>
</AccordionGroup>

## 関連概念

<CardGroup cols={3}>
  <Card title="コンウェイの法則" icon="sitemap" href="/laws/conways-law">
    システム形はコミュニケーション形に従う——「互換」の意味は協調で決まる。
  </Card>

  <Card title="ブルックスの法則" icon="users" href="/laws/brookss-law">
    人を増やすとコミュニケーションが増える——レガシー癖の修正にも時間がかかる。
  </Card>

  <Card title="マーフィーの法則" icon="triangle-exclamation" href="/laws/murphys-law">
    起こりうることは起きる——検証をそれに合わせる。
  </Card>
</CardGroup>

## 一言で言うと

<Tip>
  送出は正準形。受信は明示的な限界と指標付きで検証する——無限の推測ではない。
</Tip>