thinking-scientific-method

科学的手法（仮説の鑑別）

ある症状に複数の原因が考えられる場合は、反証可能な仮説を列挙し、それらを最も効果的に識別できる仮説に、最も低コストの観察を行います。観察のたびに、なお当てはまる仮説だけを残し、裏付けのない前提が最も少ないものを作業仮説として優先します。

使用する場面

• バグ、インシデント、または異常に、もっともらしい原因が複数ある場合。
• コード、ログ、差分、トレース、テスト、設定、またはデータを今すぐ確認できる場合。
• 修正する前に、問題のあるファイル、関数、分岐、設定、または不変条件を特定する必要がある場合。
• 複数の説明が同じ表面的な事実に当てはまり、それらを識別するチェックが必要な場合。

使用しない場面

• スタックトレース、失敗したテスト、または最近の差分から原因が明らかな場合 — 直接修正します。
• もっともらしい仮説が1つしかない場合 — それを検証します。形式的に対立仮説を作り出してはいけません。
• まだ観察できない場合 — まずアクセス手段を確保します。根拠のない原因箇所の推測はしません。
• 数週間に及ぶ実験、プロダクトのA/Bテスト、またはポリシーの試験 — このスキルはエージェントが今すぐ実施できるチェックを対象とします。
• 問題の箇所はすでに特定されており、システム全体の根本原因や予防策を深掘りする必要がある場合 — five-whys-plus を使用します。
• 特定の対象や時間に限られる不具合で、IS/IS-NOT 比較のほうが適している場合 — Kepner-Tregoe を使用します。
• 表現物（ドキュメント／ダッシュボード）が実態と食い違っている可能性がある場合 — 仮説検討を再開する前に、まず map-territory で実態を確認します。

手順

1. 症状を正確に記述します。 失敗する動作、範囲、発生時期、環境、制約を記録します。観察事実と解釈を分けます。
2. 競合する仮説を2～5個列挙します。 具体的なファイル、関数、設定、入力条件、または不変条件を挙げます。「バックエンドの問題」のような曖昧な分類は避けます。意図的に確認した結果、真剣に検討すべき代替案が残らない場合は、この鑑別を終了し、証拠のある唯一の原因を直接検証または修正します。手順を続けるために対立仮説を捏造してはいけません。
3. 調査する前に、反証条件と低コストの観察方法を明確にします。 各仮説について、どの結果がその仮説を退けるのか、今すぐ実行できる読み取り／grep／diff／ログ／テストのチェックは何かを決めます。デプロイ、カナリアリリース、長時間の待機よりも、すぐに利用できる観察を優先します。
4. 識別力 × 低コストで観察を順位付けします。 有力な仮説を最もよく区別できる、最も低コストのチェックを実行します。安価な相互チェックで代替案を排除できるなら、最有力の仮説を最初から深掘りしてはいけません。
5. 観察のたびに更新します。 反証された仮説を取り除きます。すべての証拠に引き続き当てはまる仮説の中では、独立した裏付けのない前提（追加のコンポーネント、まれなタイミング、外部依存関係など）が最も少ないものを優先します。簡潔さは、適合する仮説の順位付けに使うものであり、証拠にすでに反している、より単純な仮説を救うものではありません。より単純な仮説が排除された場合にのみ、複雑な説明へ進みます。
6. 問題の箇所を特定して終了します。 1つの仮説に直接的な裏付けとなる証拠があり、重要な代替案が排除されたら、変更するファイル／関数／設定と、それを特定した証拠を示します。箇所を直接特定できた時点で分析を終了します。

出力

Symptom: <specific failing behavior, scope, timing>
Hypotheses:
  H1: <specific cause> | Why plausible | Observation | Falsified if
  H2: ...
  H3: ...
Test order: <cheapest discriminating checks>
Results: <what each observation showed>
Survivors: <remaining Hs; least-assumptive working pick among fit>
Localized fault: <file/function/config + supporting evidence>
Ruled out: <Hs dropped and why>

検証

• 真剣に検討すべき仮説が2つ未満のまま進めた場合、事前に反証条件を定めていなかった場合、より低コストで識別できるチェックを省略した場合、または証拠に反する「より単純な」説明を残した場合は、鑑別の結論を反証します。
• 問題の箇所を直接特定し、重要な代替案を排除した時点で終了します。推測を続けてはいけません。
• 過剰適用を防ぐための注意：原因が競合していないのに、観察→疑問という流れを説明してはいけません。前提の少なさを証明として扱ってはいけません。単一の明白な原因がすでに証拠で裏付けられている場合は、このスキルを実行してはいけません。