first-principles-thinking

第一原理思考

複雑な問題をそれ以上分解できない真理に体系的に分解し、そこから積み上げて考えるアプローチです。類推、慣習、「ベストプラクティス」に基づいて考える落とし穴を避けます。

使用する場面

• アーキテクチャ、設計、戦略が本当に最適かどうかを評価するとき
• 現在の状況に合わない可能性のある「ベストプラクティス」に疑問を呈するとき
• 従来の解決策では不十分に感じられる状況を打開するとき
• 長期的な影響をもたらす基盤となる意思決定を行うとき
• レガシーシステムや従来の考え方から引き継いだ前提に異議を唱えるとき
• 「ずっとこのやり方でやってきた」が主な根拠になっているあらゆる場面

使用しない場面

• ささいな意思決定（代わりにオッカムの剃刀を使い、最も単純なものを選びます）
• 時間に追われる緊急事態（まず行動し、分析は後で行います）
• 十分に検証され、実証済みの解決策がある問題（車輪の再発明はしません）
• 専門知識がなく、習得もできない場合（知識のない第一原理思考は、素朴な解決策につながります）

---

中核となる方法論：6つのフェーズ

フェーズ 0：問いの枠組みを定める — 公理を確立する

何かを分析する前に、この領域を制約する、それ以上分解できない真理を定義します。

公理 ＝ 独立して検証可能で、それ以上分解できず、違反すれば確実に失敗を招く事実です。

公理の特定方法：

• 問う：「これはさらに分解できますか？」 — できるなら、まだ公理ではありません。
• 問う：「一般に信じられているだけでなく、証明可能な事実ですか？」 — 不確かなら、それは仮定です。
• 問う：「これに違反すると確実に失敗しますか？」 — そうとは限らないなら、それは好みです。

ゲート：先に進む前に、3つ以上の公理を提示する必要があります。各公理は1文で述べ、「それ以上分解できない理由」の説明を添えます。

### Axioms
1. [Axiom] — [Why this cannot be further decomposed]
2. [Axiom] — [Why this is provably true]
3. [Axiom] — [Why violating this causes failure]

詳細な方法論：references/axiom-based-reasoning.md

フェーズ 1：問題の本質を特定する

実装の詳細を取り除き、問題の核心を見つけます。

1. 問題を明確に述べる — 具体的に何を解決する必要がありますか？
2. 症状と原因を切り分ける — それは本当の問題ですか、それとも表れにすぎませんか？
3. 成功基準を定義する — 完璧な解決策は何を達成しますか？（測定可能な形で。）

重要な問い：

• ここで解決すべき根本的な課題は何ですか？
• このシステムやプロセスが存在しなかった場合、実際には何が必要になりますか？
• どのように実現するかとは無関係に、重要な成果は何ですか？

ゲート：1文の問題定義と、測定可能な成功基準を提示する必要があります。

フェーズ 2：すべての仮定を明らかにし、疑問を呈する

ここは最も大きな効果が得られるフェーズです。多くの「ベストプラクティス」は、事実を装った仮定です。

1. 明示的な仮定を列挙する — 何を所与として扱っていますか？
2. 暗黙の仮定を明らかにする — 疑問を呈さずに従っている慣習は何ですか？
3. それぞれを公理に照らして検証する — これは本当に制約ですか（公理に根拠がありますか）、それとも単に昔からそうしているだけですか？

最低要件：5行以上の仮定を含む表を作成します。

仮定	疑問を呈する理由	使用する公理	判定
「Xが必要だ」	[検証]	A1, A2	維持 / 破棄 / 修正

危険信号（誤った仮定である可能性が高いもの）：

• 「ずっとこのやり方でやってきた」
• 「業界標準では……」
• 「これには誰もがXを使う」
• 「単純すぎてうまくいかない」

深さの基準：各行に、疑問を呈する理由と、判定の根拠となる公理を含める必要があります。理由を示さず「必要ないかもしれない」とするだけでは、掘り下げが不十分です。

ゲート：5つ以上の仮定に疑問を呈し、判定を示す必要があります。各判定では、少なくとも1つの公理を参照してください。

詳細な方法論：references/axiom-based-reasoning.md §「仮定の特定と検証」

フェーズ 3：絶対的な真実を確立する

疑問を投げかけられた前提が崩れた後、この特定の問題において、これ以上分解できない本質的な真実を特定します。

絶対的な真実のテスト：

• さらに分解できますか？ → できる場合は、分解します。
• 単に広く信じられているだけでなく、証明できますか？ → 確信が持てない場合、それはまだ仮定です。
• これに違反すると、確実に失敗しますか？ → そうでない場合、それは好みの問題です。

ゲート：3つ以上の絶対的な真実を導き出す必要があります。それぞれ具体的で、反証可能なものでなければなりません。

❌ "Users need fast response times" (too vague)
✅ "P99 latency must be < 200ms per SLA contract §3.2" (specific, verifiable)

❌ "The team is small" (relative)
✅ "Team is 3 engineers, no new hires possible before Q3" (concrete constraint)

フェーズ 4：上向きに推論する

絶対的な真実だけをもとに解決策を構築します。各層には、その存在を正当化する理由が必要です。

Ground Truth → Minimal Solution → Justified Additions → Final Design
     ↑              ↑                    ↑
  (proven)     (sufficient)        (each defended)

1. 最小限から始める — すべての絶対的な真実を満たす、最もシンプルなものは何ですか？
2. 必要なものだけを追加する — 追加するものはすべて、絶対的な真実または公理を根拠とする必要があります。
3. 各層を問い直す — この層は、その複雑さに見合う価値がありますか？

ゲート：各段階を絶対的な真実までたどれる推論の連鎖を導き出す必要があります。

### Reasoning Chain
GT#1 (latency < 200ms) + GT#3 (3-person team) → Eliminate distributed architecture
GT#2 (read-heavy 95%) + GT#1 → Add read cache with 30s TTL
→ Conclusion: Monolith + in-memory cache

フェーズ 5：検証とストレステスト

行動に移る前に、推論が妥当であることを確認します。

3つの検証質問（完了ゲート）：

#	質問	失敗が意味すること
1	すべての結論を絶対的な真実までたどれますか？（追跡可能性）	フェーズ 4 で正当化されていない仮定を持ち込んでいます
2	すべての絶対的な真実が、少なくとも1つの結論でカバーされていますか？（完全性）	解決策が制約を無視しており、その点で失敗します
3	フェーズを飛ばしたり、浅く済ませたりしていませんか？（誠実性）	戻って、最後までやり遂げてください

相補的なモデルでストレステストを行う：

モデル	問いかける質問	効果を発揮する場面
プレモーテム	「12か月後、この取り組みが失敗しました。なぜですか？」	解決策に期待を寄せているとき
二次的影響	「これがうまくいったら、次に何が起きますか？ その後は？」	解決策がシステム全体に影響を及ぼすとき
逆転思考	「失敗を確実にするものは何ですか？ そのいずれかを実行していませんか？」	見落としを見つける必要があるとき
OODA の実行	「今すぐ実行できる最小のテストは何ですか？」	分析麻痺に陥ったとき

モデルの全ツールキット：references/thinking-models-toolkit.md

ゲート：3つの検証質問すべてに「はい」と回答する必要があります。少なくとも1つのストレステストモデルを適用してください。

---

推論規律プロトコル

問題：AI はステップを飛ばしたり、分析の途中で気がそれたり、各ステップを浅く済ませたりしがちです。

フェーズゲート（必須成果物）

フェーズ	作成するもの	最低限の深さ
0：枠組み	根拠を添えた公理を3つ以上	各公理：1文と、これ以上分解できない理由
1：本質	問題の記述と成功基準	具体的で測定可能
2：仮定	5行以上の仮定表	各行：検証、関連する公理、判定
3：絶対的な真実	絶対的な真実を3つ以上	それぞれ具体的で、反証可能で、自明な真理ではない
4：上向きの推論	GT の参照を含む推論の連鎖	すべての段階を GT までたどれる
5：検証	3つの検証への回答と1つのストレステスト	すべての回答が「はい」

成果物がなければ、次のフェーズには進みません。 ゲートを満たしていない場合は、そこで止めて完了させてください。

進捗トラッカー（脱線防止）

分析全体を通じて、チェックリストを更新し続けます。各フェーズの完了後に出力します：

## 🧭 FP Progress
- [x] Phase 0: Frame — ✅ 3 axioms
- [x] Phase 1: Essence — ✅ "..."
- [→] Phase 2: Assumptions — 3/6 checked
- [ ] Phase 3: Ground Truths
- [ ] Phase 4: Reason Upward
- [ ] Phase 5: Validate

会話が脱線した場合（ユーザーが余談を求めたり、議論が脇道に広がったりした場合）、その話題に対応した後、直ちに次を出力します：

📍 FP 分析に戻ります：フェーズ N には M 件の項目が残っています。続けます。

深さの基準（浅い分析を防ぐ）

フェーズ	浅い（不合格）	深い（合格）
仮定	「これが不要かもしれません」	検証の理由、公理の参照、判定を含む表の行
絶対的な真実	「ユーザーは速さを求めている」	「SLA §3.2 に基づき、P99 < 200ms」
推論	「したがって X を使うべきです」	「GT#2 + GT#3 → Y を排除 → X が最小限の解決策」

---

Trellis との統合

Trellis 管理下のプロジェクトで使用する場合、分析の成果物はタスクシステムと統合されます。

ファイルの配置

.trellis/tasks/{MM-DD-slug}/
├── task.json              # Existing
├── prd.md                 # Existing — FP feeds into this
├── fp-analysis.md         # ← FP analysis output (Phases 0-5)
├── fp-progress.md         # ← Phase progress tracker (anti-drift)
├── implement.jsonl        # Existing — fp-analysis.md auto-added
├── check.jsonl            # Existing — fp-analysis.md auto-added
└── ...

ブレインストーミングとの統合

/trellis:brainstorm の実行中に、タスクが「Complex」に分類された場合：

1. トリガー：ユーザーが「第一原理から分析して」と言うか、AI が未検証の前提が3つ以上あると判断した場合
2. 実行：フェーズ0～3を実行し、出力をタスクディレクトリ内の fp-analysis.md に保存します
3. PRD への反映：
   • グラウンドトゥルース → PRD の要件と制約
   • 前提条件の表 → design.md のトレードオフ
   • 推論チェーン → design.md
4. 続行：フェーズ4～5を実装の意思決定に役立てます

コンテキストへの注入

FP 分析の完了後、コンテキストファイルに追加します：

python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" implement "fp-analysis.md" "Ground truths and reasoning chain"
python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" check "fp-analysis.md" "Verify implementation traces to ground truths"

完了の記録

フェーズ5の後、task.json を更新します：

{
  "fp_analysis": {
    "completed": true,
    "axioms_count": 3,
    "assumptions_challenged": 6,
    "ground_truths_count": 5,
    "validation_passed": true
  }
}

---

出力形式

第一原理思考を適用する場合は、最終出力を次の形式で構成します：

## First Principles Analysis: [Topic]

### Axioms
1. [Axiom 1] — [Why irreducible]
2. [Axiom 2] — [Why irreducible]
3. [Axiom 3] — [Why irreducible]

### Problem Essence
**Core problem:** [One sentence]
**Success criteria:** [Measurable outcomes]

### Assumptions Challenged
| Assumption | Challenge | Axiom(s) | Verdict |
|------------|-----------|----------|---------|
| ... | ... | A1, A2 | Keep/Discard/Modify |

### Ground Truths
1. [Specific, falsifiable fact]
2. [Specific, falsifiable fact]
3. [Specific, falsifiable fact]

### Reasoning Chain
GT#1 + GT#3 → [Inference] → [Step] → [Conclusion]

### Conclusion
**Recommended approach:** [Description]
**Key insight:** [What FP analysis revealed that convention missed]
**Trade-offs acknowledged:** [What we accept and why]

### Validation
- [x] Every conclusion traces to a ground truth
- [x] Every ground truth is covered
- [x] No phases skipped
- [x] Stress-tested with: [model name]

---

よくある落とし穴

複雑さの落とし穴

症状：解決策が、問題に見合わないほど複雑です。 FP チェック：コンポーネントを1つ取り除いても、中心的な問題を解決できますか？ できるなら、そのコンポーネントは不可欠ではありません。これを繰り返します。

類推の落とし穴

症状：「Company X がこの方法を採用しているので、私たちもそうすべきです。」 FP チェック：Company X はどのような問題を解決していたのでしょうか？ 関連するすべての観点で、私たちの問題と同じでしょうか？ 制約にはどのような違いがありますか？

レガシーの落とし穴

症状：もはや役に立たない判断との互換性を維持しています。 FP チェック：当初の理由は何だったのでしょうか？ その条件は今も存在しますか？ 変更の真のコストと、維持し続けるコストはそれぞれいくらでしょうか？

さらに多くのパターンと事例については、references/case-studies.md を参照してください。

---

補完ツールのクイックリファレンス

ツール	主な問い	最適な組み合わせ
反転思考	「何が失敗を確実にするでしょうか？」	フェーズ2（隠れた前提を見つける）
二次的影響	「その次は？ さらにその次は？」	フェーズ5（結論をストレステストする）
5つのなぜ	「なぜ？ なぜ？ なぜ？ なぜ？ なぜ？」	フェーズ1（真の問題を見つける）
プレモーテム	「失敗しました。なぜでしょうか？」	フェーズ5（ストレステスト）
OODA ループ	「最小のテストは何でしょうか？」	フェーズ5（行動に移す）
引き算思考	「何を取り除くべきでしょうか？」	フェーズ4（解決策を簡素化する）
ベイズ更新	「どのような新しい証拠があれば、考えが変わるでしょうか？」	フェーズ3（グラウンドトゥルースを検証する）
可逆性フィルター	「一方通行のドアですか、それとも双方向のドアですか？」	フェーズ4（意思決定の深さを調整する）

例を含むツールキット全体については、references/thinking-models-toolkit.md を参照してください。

---

バイアスへの注意

第一原理分析において最も危険な5つのバイアス：

バイアス	FP を歪める仕組み	簡単なバイアス低減策
確証バイアス	自分が好む解決策を裏付けるグラウンドトゥルースを「見つけて」しまいます	まず反証となる証拠を探します
アンカリング	「新鮮な」視点で考えているつもりでも、従来のアプローチが思考のアンカーになります	評価する前に3つの代替案を作成します
サンクコスト	過去の判断をグラウンドトゥルースのように感じてしまいます	「今日ゼロから始めるとしたら、これを選ぶでしょうか？」
現状維持バイアス	「現在の仕組み」が、選択肢であるにもかかわらず制約のように感じられます	真の制約と現在の選択を切り分けます
過信	前提を検証せずにグラウンドトゥルースとして扱ってしまいます	各前提に確信度（％）を割り当てます

バイアス低減策を含む12種類のバイアス一覧については、references/bias-and-debiasing.md を参照してください。

---

問題の分解

複雑な問題に FP を適用する前に、まず問題を分解する必要がある場合があります。簡単な選び方：

問題の種類	最適なフレームワーク
診断（X はなぜ起きているのか？）	イシューツリーまたはフィッシュボーン
財務（収益／コスト）	収益性ツリー
戦略（何をすべきか？）	仮説ツリー
業務（何が壊れているのか？）	プロセスフロー＋5つのなぜ
複雑適応系	システムマップ

15種類すべてのフレームワークについては、references/decomposition-frameworks.md を参照してください。

---

参考ファイル

ファイル	内容	読むタイミング
references/axiom-based-reasoning.md	公理の確立、前提への疑問、結論の導出に関する詳細な方法論	単なる分析ではなく、厳密な導出が必要なとき
references/thinking-models-toolkit.md	4象限フレームワーク＋12の思考モデル＋モデル選択ガイド＋「なぜ」を5回問う方法の詳細	相互に補完する思考ツールが必要なとき
references/case-studies.md	ソフトウェアエンジニアリングの事例5件＋SpaceX/Teslaの事例2件＋テンプレート	FPの具体的な実践例を見たいとき
references/bias-and-debiasing.md	FPの思考を損なう12の認知バイアス＋バイアス低減の戦略	分析に見落としがないか検証するとき
references/decomposition-frameworks.md	問題分解の手法15種類（MECE、イシューツリーなど）	問題が大きすぎて、直接分析できないとき