thinking-occams-razor

オッカムの剃刀

概要

オッカムの剃刀とは、証拠を同じ程度に説明できる仮説が複数ある場合、仮定が最も少ないものを選ぶという原則です。このスキルでは、この原則をデバッグに適用します。まず最も単純な仮説を検証し、証拠によって必要とされる場合にのみ、複雑な説明へと進みます。

このスキルにはトリガー絞り込みゲートがあります。最も単純な仮説を1ステップで検証できるなら、まず検証してください。列挙と採点の手順全体を実行する必要はありません。複数の仮説が実際に競合し、最も単純な仮説を明らかに検証できない場合に限り、手順全体を実行します。

基本原則：「物事は可能な限り単純にすべきだが、単純化しすぎてはいけない。」 — Einstein

使用する場面

• バグを説明できる仮説が複数あり、最も単純な仮説を1ステップで明らかに検証できない場合
• より単純な仮説を先に検証せず、複雑な仮説を調査しようとしている場合
• 複数のアプローチが有効で、複雑さが異なるアーキテクチャや設計上の判断
• 複数の原因が考えられる根本原因分析

判断の流れ：

Multiple explanations exist?
  → No → Use the available explanation
  → Yes → Can the simplest be tested in one step?
      → Yes → JUST TEST IT (trigger-shrink — skip full procedure)
      → No → Do they explain the evidence equally well?
          → No → Prefer the better explanation
          → Yes → RUN FULL OCCAM'S RAZOR PROCEDURE

使用しない場面

• 証拠がすでに特定の原因を示している場合。 証拠に従ってください。証拠と矛盾する「より単純な」仮説へと格下げしないでください。
• その領域が本質的に複雑な場合（分散合意、並行処理、セキュリティ脅威モデル）。最も単純なモデルは誤りです。単純化しすぎないでください（「単純化しすぎてはいけない」）。
• もっともらしい説明が1つしかない場合。 比較するものがないため、そのまま検証してください。
• 「単純化」が、既知の相互作用を無視したり、根幹を支える安全策を省いたりすることを意味する場合。 システム全体にリスクを生む局所的な単純さは、倹約性ではありません。
• トリガーチェックで解決した場合。 最も単純な仮説を1ステップで検証でき、それが裏付けられたなら完了です。網羅性のために列挙する必要はありません。

トリガーカード

列挙と採点の手順全体を実行する前に、次の質問をしてください。「最も単純な仮説を1ステップで検証できるか？」

1. 最も単純な仮説を特定する — 証拠を説明できる範囲で、仮定が最も少ないものです。
2. 1ステップで検証できますか？ → はい → そのまま検証してください。 裏付けられたら報告して終了します。否定されたら、次に単純な仮説に進みます。
3. 1ステップで検証できない場合 → オッカムの剃刀の手順全体（列挙、仮定の数え上げ、説明力の確認、順番に検証）を実行します。

証拠がすでに特定の原因を示している場合は、証拠に従ってください。証拠と矛盾する「より単純な」仮説へと格下げしないでください。本質的に複雑な領域（分散合意、並行処理）では、最も単純なモデルは誤りです。

手順

トリガーチェック（高速パス）

手順全体を実行する前に、次の質問をしてください。「最も単純な仮説を1ステップで検証できるか？」

• はい → 検証します。裏付けられたら報告して終了します。否定されたら、次に単純な仮説に進みます。
• いいえ → 最も単純な仮説の検証には簡単でない調査が必要です → 以下の手順全体を実行します。

手順全体：トリガーチェックで解決しない場合

ステップ1：競合する仮説を列挙する

観察された挙動について、もっともらしい説明をすべて列挙します。

Bug: Users intermittently can't log in

Hypotheses:
A. Session token expiration edge case
B. Race condition in auth service
C. Database connection pool exhaustion
D. Complex interaction between CDN cache, load balancer, and session service

ステップ2：仮説ごとに仮定の数を数える

仮説	仮定
A. トークンの有効期限切れ	1. トークン検証にエッジケースがある
B. 競合状態	1. 同時リクエストが発生しうる、2. 共有された可変状態が存在する
C. DB プールの枯渇	1. プールのサイズが不足している、2. 接続がリークしている
D. 複雑な相互作用	1. CDN が認証情報をキャッシュしている、2. LB のスティッキーセッションが失敗している、3. セッション同期が遅延している

独立した仮定をそれぞれ数えます。仮定ごとに +1、関与するコンポーネントごとに +1、外部依存関係ごとに +2、タイミングに依存する挙動には +2、まれな条件には +3、「完璧な嵐」のようなシナリオには +5 を加算します。

ステップ3：説明力を確認する

より単純な仮説が実際に証拠を説明していることを確認します。

Evidence: Failures correlate with high traffic periods
Hypothesis A (token edge case): Doesn't explain traffic correlation ✗
Hypothesis C (DB pool exhaustion): Explains traffic correlation ✓ — fewer assumptions than D
→ PREFERRED by Occam's Razor

ステップ 4：仮定が最も少ない順に検証する

仮定が最も少ないものから最も多いものへと、仮説を調査します。単純な仮説が否定されるまでは、複雑な仮説に進まないでください。

ステップ 5：証拠が求める場合にのみ複雑さを上げる

単純な説明が証拠によって否定されたら、より複雑な説明に進みます。直感だけを根拠に、複雑さを上げてはいけません。

出力仕様

オッカムの剃刀による分析を完了すると、次の内容が得られます。

1. トリガーチェックの結果 — 最も単純な仮説を一度の手順で検証できたかどうか
2. 仮説の順位付け — 仮定の数が少ない順に並べ、各仮説の仮定を記載
3. 説明力のチェック — 証拠に合致する仮説
4. 検証の順序と結果 — 検証した仮説、その順序、結果
5. 結論 — 確認された仮説（未解決の場合は、次に検証する仮説）

トリガーを絞り込むケースでは、出力を「最も単純な仮説 X を検証 — 確認／否定」の一行だけにしてもかまいません。

アンチパターン

アンチパターン	症状	修正方法
還元できない領域を単純化しすぎる	分散型コンセンサスやセキュリティモデルに「最も単純」を当てはめる	「これ以上単純にはならない」と捉え、領域の複雑さを尊重する
複雑さへの偏り	複雑なものほど高度だと思い、複雑な仮説から検証する	常に、仮定が最も少ない仮説から検証する
トリガーの過剰な拡大	一度で検証できるものに、すべての仮説を列挙する	最も単純な仮説を一度で検証できるなら、それだけを検証する
説明力を無視する	証拠に合わない、最も単純な仮説を選ぶ	仮定が少なくても、データに合わなければ優先しない
局所的な単純さとシステム全体のリスク	他の箇所に脆弱さを生む単純な局所修正を選ぶ	局所的な単純さより、システム全体の単純さを優先する
儀式的な仮定の数え上げ	仮説の検証よりも、仮定の数え上げに時間をかける	目的は優先順位付けであり、厳密な数え上げではありません。概算で十分です