Category: 法則
Type: ソフトウェア互換性とAPI進化の法則
Origin: Hyrum Wright（観察）；Titus Winters が命名；Software Engineering at Google（2020）で普及
Also known as: 暗黙インターフェースの法則；バグ対バグ互換（bug-for-bug compatibility）
Type: ソフトウェア互換性とAPI進化の法則
Origin: Hyrum Wright（観察）；Titus Winters が命名；Software Engineering at Google（2020）で普及
Also known as: 暗黙インターフェースの法則；バグ対バグ互換（bug-for-bug compatibility）
先に答えると — ハイラムの法則（Hyrum’s Law）は、APIの利用者が十分いれば、人々は文書の約束だけでなく、あらゆる観測可能な振る舞いに依存する、という観察です。文書は線を引きますが、実際の利用はもっと太い線を引きます。実務では「見えること」自体を契約リスクとして扱い、暗黙依存に備えて変更を計画します。
ハイラムの法則とは
ハイラムの法則は、利用者が十分いれば、システムのあらゆる観測可能な振る舞いが誰かの依存になる——公式契約に書かれているかどうかにかかわらず——という観察です。APIの利用者が十分いれば、契約で何を約束しても関係ない。システムのあらゆる観測可能な振る舞いは、誰かに依存される。メニューを契約、厨房の癖を実装だと考えてください。客は、書かれていない皿の大きさ、待ち時間、付け合わせを期待し始めます。ソフトウェアでは、並び順、エラー文、タイミング、さらにはバグまでもが荷重壁になり得ます。規模が大きくなると、「非公開」の実装は非公開でなくなります。消費者集団が表面全体を固定してしまうのです。
ハイラムの法則を3つの深さで理解する
- Beginner: ユーザーが見えるものは、文書の有無にかかわらず誰かが土台にする。
- Practitioner: ライブラリやAPIを変える前に、呼び出し側が文書外で何に頼っているかを問う。
- Advanced: 利用のエントロピーを設計に織り込む——偶発的な観測面を減らし、テストで破壊を検知し、暗黙インターフェースを変えるときは移行コストを見積もる。
起源
Hyrum Wright は、Googleで大規模なライブラリ・インフラ変更に取り組む中でこの観察を言語化しました。コアC++ライブラリへの「見えない」微調整でも、偶発的振る舞いに寄っていた遠いシステムが壊れました。彼は極端形を暗黙インターフェースの法則と呼びました——消費者が十分いれば、実質的に非公開実装はなく、メンテナはしばしばバグ対バグ互換を強いられます。 同僚の Titus Winters がこれを Hyrum’s Law と名付け、Google内で広めました。2020年のO’Reilly刊 Software Engineering at Google（Winters、Wright、Manshreck）は、長寿命コードの中核制約として扱います。変更の議論は効率の議論がエントロピーを意識するのと同様にハイラムの法則を意識すべきで——緩和はできるが根絶はできない、と述べます。 Wrightの公開サイト（hyrumslaw.com）は定番の文言を固定し、Joel Spolskyのリークする抽象の法則（Law of Leaky Abstractions）と結び付けます。消費者は、抽象から漏れるものを必ず気づき、依存します。要点
ハイラムの法則は道徳律というより、大規模ユーザー基盤が観測された振る舞いを凍結する、という予測です。観測可能が文書化を上回る
契約は許されることを言い、利用は頼っていることを言います。エラー文字列、応答フィールド順、キャッシュ遅延、既定フォーマットは、呼び出し側がコードに埋め込めば、真のインターフェースの一部になります。
互換はしばしばバグ対バグを意味する
バグ修正は、それを回避して動いていた呼び出し側を壊し得ます。チームはバグを残すか、二重経路を出すか、協調移行のコストを払うかを選びます——寛容と厳格のあいだのポステルの法則と隣接するトレードオフです。
応用場面
「誰もそんなものに頼らないはず」が願望にすぎないほど広く共有されているとき、ハイラムの法則を使います。ライブラリとAPIの所有
意図した保証を文書化し、変更の自由を残したい偶発的振る舞いは隠すかランダム化します（例：ハッシュ反復順）。
製品とプラットフォームの変更
スクリーンショット、CSV列順、webhookペイロードの癖を、パートナーとパワーユーザーの事実上のAPIとして扱います——エンジニアだけのものではありません。
チームのプロセスと方針
書かれていない「いつもこうする」習慣は、コンウェイの法則が構造を形づくるように荷重を持ちます——儀式を変えると、静かに何かが壊れます。
個人のツールと学習
表計算の偶然の並びやアプリの奇妙なエクスポートをスクリプトで囲むときは、その依存にラベルを付けます。ベンダーが「直した」ときに壊れる前提でいます。
事例
Pythonの辞書の順序は、ハイラムの法則が実装詳細を言語約束に変える様子を示します。CPython 3.6（2016）では、コンパクトなdict再設計が挿入順を保ちましたが、これは実装詳細でした——有用で見えるが、全Python実装への言語保証ではありません。それでも呼び出し側は実務でその順序を前提にし始めました。 2017年12月15日、python-devの議論の後、Guido van Rossumは裁定しました。「Make it so. ‘Dict keeps insertion order’ is the ruling.」Python 3.7（2018年6月27日リリース）は、挿入順の保持を言語仕様の公式部分とし、適合実装はそれに従わねばなりません。プロジェクトは、広く観測された振る舞いを追認する道を選び、意図的に順序をかき混ぜてすでに適応した生態系を壊す道は取りませんでした。教訓は鋭いです。十分な利用者が振る舞いを見られるようになったら、「約束していなかった」は弱い弁明です。契約に取り込むか、強制移行のコストを払うかです。境界も同様に鋭いです。追認は一つの戦略であり——偶発的振る舞いが有害だったり、より良い設計を封じたりするときは、常に正しいわけではありません。限界と失敗パターン
ハイラムの法則は、広く共有され長寿命のインターフェースで最も強く働きます。利用者二人の個人スクリプトは自由に変えられます。数百万クライアントのプラットフォームAPIはそうではありません。 何も改善しない言い訳としては失敗します。法則は破壊リスクを予測するのであって、変更を禁じません。調査・伝達・移行の価格を求めます——永久凍結を求めません。 よくある誤用は、ユーザーの「誤用」を責めつつ、高度に見えながら未文書化の癖を出し続けることです。明確さのない可視性は依存を招きます。もう一つの誤用は、すべての不具合を聖域にすることです。セキュリティや正しさの負債を生むバグは、バージョン付き破壊と移行経路で直すべき場合があります。よくある誤解
予測・非難・設計戦略を分けてから使います。ハイラムの法則は文書が無意味だという意味だ
ハイラムの法則は文書が無意味だという意味だ
いいえ。明確な契約は、偶発的結合を減らし、誠実な利用者を導きます。法則は、文書だけでは「まだ見えているもの」への依存を止められない、と述べます。
パブリッククラウドAPIにだけ当てはまる
パブリッククラウドAPIにだけ当てはまる
いいえ。内部ライブラリ、CLI、設定形式、家族で共有する表計算でも、十分な人がその上に作れば同じパターンに従います。
唯一の対応は何も変えないことだ
唯一の対応は何も変えないことだ
いいえ。対応には、観測面の隠蔽、バージョニング、二重運用、クライアントのカオス試験、そして人気の振る舞いを明示保証に昇格させること——Pythonがdict順で行ったように——が含まれます。
関連概念
これらのページは、相互運用・システム成長・意図しない結合のなかにハイラムの法則を置く助けになります。ポステルの法則
寛容は相互運用を助け——後に暗黙契約となる癖を固めることにもなり得ます。
コンウェイの法則
組織構造がシステムを形づくるように、非公式な習慣も人々が何に依存するかを形づくります。
ガルの法則
動く複雑系は単純なものから育ち——ユーザーは偶発的な表面にも掴まります。
グッドハートの法則
指標が目標になると歪むように、癖が依存になると凍結します。
意図せざる結果
見える副作用は、利用者にとっての真の結果集合の一部になります。
ワースの法則
ソフトウェア複雑さはハードウェア利得を食い——複雑さは観測面も増やします。