war-room

概要

War Room は、複数の AI 専門家を招集して、多様な視点から問題を分析し、敵対的レビューを通じて前提に異議を唱え、最高司令官の指揮のもとで最適なアプローチを統合します。

哲学

「秘訣は、秘訣などないということです。知性の力は、単一の完璧な原則ではなく、私たちの幅広い多様性から生まれます。」

• Marvin Minsky, Society of Mind

可逆性に基づくルーティング

審議の前に、適切なリソース配分を決定するため、**可逆性スコア（RS）**を評価します。

RS = (Reversal Cost + Time Lock-In + Blast Radius + Information Loss + Reputation Impact) / 25

RS 範囲	タイプ	モード	リソース
0.04 - 0.40	Type 2	エクスプレス	専門家 1 名、2 分未満
0.41 - 0.60	Type 1B	軽量	専門家 3 名、5〜10 分
0.61 - 0.80	Type 1A	全体会議	専門家 7 名、15〜30 分
0.81 - 1.00	Type 1A+	デルファイ	専門家 7 名、30〜60 分

簡易ヒューリスティック：

• A/B テストが可能ですか？ → Type 2
• データ移行が必要ですか？ → Type 1
• 公開の確約が必要ですか？ → Type 1A+

詳細なスコアリングガイドは modules/reversibility-assessment.md を参照してください。

使用する場面

• 大きなトレードオフを伴うアーキテクチャ上の決定
• 多様な視点を必要とする、複数の利害関係者が関わる問題
• 重大な結果を伴う重要な選択（RS > 0.60）
• 明確な前例のない新しい問題
• ブレインストーミングで、複数の有力な競合アプローチが生まれた場合

使用しない場面

• 答えが明らかな単純な質問
• 定型的な実装タスク
• 解決策が明確な、十分に文書化されたパターン
• 即時の対応が必要な、時間的制約の厳しい決定
• Type 2 の決定（RS ≤ 0.40）：エクスプレスモードを使うか、War Room を完全に省略してください

専門家パネル

デフォルト（軽量モード）

役割	モデル	目的
最高司令官	Claude Opus	最終的な統合、エスカレーションの判断
首席戦略官	Claude Sonnet	アプローチの立案、トレードオフの分析
レッドチーム	Gemini Flash	敵対的な検証、障害モードの特定

全体会議（エスカレーション時）

役割	モデル	目的
最高司令官	Claude Opus	最終的な統合
首席戦略官	Claude Sonnet	アプローチの立案
情報将校	Gemini 3 Pro	大規模なコンテキストの分析（1M 以上）
現場戦術家	GLM-5.3	実装の実現可能性
偵察担当	Qwen Turbo	データの迅速な収集
レッドチーム司令官	Gemini Flash	敵対的な検証
兵站担当	Qwen Max	リソースの見積もり

審議プロトコル

デフォルトの 2 ラウンド

Round 1: Generation
  - Phase 1: Intelligence Gathering (Scout, Intel Officer)
  - Phase 2: Situation Assessment (Chief Strategist)
  - Phase 3: COA Development (Multiple experts, parallel)
  - Commander Escalation Check

Round 2: Pressure Testing
  - Phase 4: Red Team Review (all COAs)
  - Phase 5: Voting + Narrowing (top 2-3)
  - Phase 6: Premortem Analysis (selected COA)
  - Phase 7: Supreme Commander Synthesis
  - Phase 8: Discussion Publishing

デルファイ拡張（重大な判断が必要な場合）

重大な判断が必要な場合は、反復的なデルファイ方式による合意形成に拡張します。

• 専門家の合意に達するまで複数回ラウンドを実施
• 合意形成のしきい値：0.85

統合

Brainstorm との連携

War Room は Phase 3（アプローチの立案）の後、Skill(attune:project-brainstorming) から自動的に呼び出されます。

brainstorm スキルは、以下のすべてのコンテキストを War Room に渡します。

• 問題の説明と制約
• 長所と短所を含む、立案されたアプローチ
• 比較マトリクス
• 可逆性の評価（自動計算）

バイパス条件（以下をすべて満たす場合のみ）：

• RS ≤ 0.40（Type 2 の決定 — 明らかに可逆的）
• 有意なトレードオフがない、明白な単一のアプローチ
• 複雑性が低く、十分に文書化されたパターンがある
• RS 評価を確認した後、ユーザーが明示的に辞退する

# Automatic invocation from brainstorm (do not skip)
/attune:war-room --from-brainstorm

# Direct invocation (standalone)
/attune:war-room "Should we use microservices or monolith for this system?"

Memory Palace との連携

セッションは Strategeion（War Palace）に保存されます。

~/.claude/memory-palace/strategeion/
  - war-table/      # Active sessions
  - campaign-archive/  # Historical decisions
  - doctrine/       # Learned patterns
  - armory/         # Expert configurations

Conjure を使用する場合

専門家は conjure による委任を通じて呼び出されます。

• Gemini モデルには conjure:gemini-delegation
• Qwen モデルには conjure:qwen-delegation
• GLM-5.3 には直接 CLI を使用します（get_glm_command() 経由の ccgd または claude-glm）

委任がデフォルトで有効になっていても、ここでは何も変わりません。War Room はその構造上、委任を行うからです。パネルとは外部モデルで構成されるものであり、そうでなければパネルではありません。

変わるのはフォールバックです。conjure:delegation-core は、どのプロバイダーからも応答がない場合や、オペレーターが委任を拒否した場合に、例外を発生させる代わりに fallback_reason を返すようになりました。この結果を受けて、Claude がすべての席の役割を担うのは適切ではありません。

外部モデルに到達できなかったパネルは、パネルではありません。 委任が無効になっている場合、または委任先の候補をすべて試した場合は、次のようにします。

1. 審議を始める前に、その旨と理由、試したプロバイダーを明示します。
2. 空席を Claude で埋め、その結果をマルチモデルパネルの出力として提示してはいけません。1 つのモデルが 7 つの役割を演じると、合意に見えても実際はそうではない結論になります。
3. 次の選択肢を提示します。単一モデルによるレビューだと明記して実施するか、プロバイダーが利用可能になるまで中止するかです。

このリポジトリで、無言のローカルフォールバックが単に処理を遅らせるのではなく、結果を誤って伝えるのはここだけです。

使用方法

基本的な呼び出し

/attune:war-room "What architecture should we use for the new payment system?"

コンテキストを指定する場合

/attune:war-room "Best approach for API versioning" --files src/api/**/*.py

可逆性の評価のみ

本格的な審議を行わずに、簡易評価を実施します。

/attune:war-room "Database migration to MongoDB" --assess-only

出力：

Reversibility Assessment
========================
Decision: Database migration to MongoDB

Dimensions:
  Reversal Cost:      5/5 (months of rework)
  Time Lock-In:       4/5 (migration path hardens)
  Blast Radius:       5/5 (all services affected)
  Information Loss:   4/5 (query patterns, ACID)
  Reputation Impact:  2/5 (internal unless downtime)

Reversibility Score: 0.80
Decision Type: Type 1A (One-Way Door)
Recommended Mode: Full Council

Proceed with full deliberation? [Y/n]

Express モード（Type 2）を強制する

明らかに可逆な選択について、迅速な意思決定に進みます。

/attune:war-room "Which logging library to use" --express

Full Council を強制する

重大な決定について、RS による評価を上書きします。

/attune:war-room "Migration strategy" --full-council

Delphi モード

最も重大で、不可逆な決定に使用します。

/attune:war-room "Long-term platform decision" --delphi

セッションを再開する

/attune:war-room --resume war-room-20260120-153022

出力

決定文書

War Room は Supreme Commander Decision 文書を作成します。

## SUPREME COMMANDER DECISION: {session_id}

### Reversibility Assessment
| Dimension | Score | Rationale |
|-----------|-------|-----------|
| Reversal Cost | X/5 | ... |
| Time Lock-In | X/5 | ... |
| Blast Radius | X/5 | ... |
| Information Loss | X/5 | ... |
| Reputation Impact | X/5 | ... |

**RS: 0.XX | Type: [1A+/1A/1B/2] | Mode: [delphi/full_council/lightweight/express]**

### Decision
**Selected Approach**: [Name]

### Rationale
[Why this approach was selected]

### Implementation Orders
1. [ ] Immediate actions
2. [ ] Short-term actions

### Watch Points
[From Premortem - what to monitor]

### Reversal Plan (for Type 1 decisions)
[If this decision proves wrong, here's the exit strategy]

### Dissenting Views
[For the record]

セッションの成果物

Strategeion に保存されます。

• インテリジェンスレポート
• 状況評価
• すべての COA（開示後の完全な帰属情報を含む）
• レッドチームによる課題提起
• プレモーテム分析
• 最終決定

トレードオフを記録する（意思決定ジャーナル）

Supreme Commander Decision は、その構成上、トレードオフの記録です。選択したアプローチ、それと比較検討した COA、そして異論のある見解が含まれます。推論を Strategeion だけでなくコードとともに残すため、内容を docs/tradeoffs.md に反映します（下書き後に確認します）。

• leyline がインストールされている場合は、Skill(leyline:decision-journal) を呼び出し、トレードオフのエントリーを追加します。次のように直接対応付けます。Selected Approach は decision に、RS と根拠は Y ステートメントに、却下された COA は options に、Dissenting Views は consequences_negative に対応させます。phase には、元のフェーズ（例：plan）を設定します。エントリーのリンクに RS を記録します。確認後に追加します。
• フォールバック（leyline がない場合）：ファイル内の ENTRY TEMPLATE を使って docs/tradeoffs.md に追記し、次の TR-NNN ID を割り当てます。

docs/adr/ に番号付き ADR を作成するほどアーキテクチャ上重要な決定である場合は、ADR を作成し、内容を重複させずに、トレードオフのエントリーからその番号を参照します。

匿名化

審議中は Merkle-DAG を使用して専門家の貢献を匿名化します。

• レビュー中の回答には「Response A, B, C...」というラベルを付けます
• 帰属情報は決定後にのみ開示されます
• ハッシュ検証によって整合性を保証します

詳細は modules/merkle-dag.md を参照してください。

エスカレーション

自動（可逆性に基づく）

可逆性スコアに基づいて、審議モードが自動的に選択されます。

RS スコア	自動モード
≤ 0.40	Express（War Room 全体を省略）
0.41 - 0.60	軽量パネル
0.61 - 0.80	Full Council
> 0.80	Full Council および Delphi

手動オーバーライド

最高司令官は、以下の場合に自動分類をオーバーライドできます。

• 高い複雑性が検出された場合（複数のアーキテクチャ上のトレードオフ）
• 初期評価を行った専門家の間に大きな意見の相違がある場合
• 専門的な分析を必要とする新規の問題領域である場合
• 前例となる決定である場合（今後の決定がそのパターンに従う）
• 技術的な範囲を超える政治的・組織的な機微がある場合

エスカレーションには、RS 評価を含む書面での正当化が必要です。

エスカレーションの解除

同様に重要なのは、過剰に審議されている決定を特定することです。

• RS ≤ 0.40 の場合は、Express モードまたは即時実行を推奨します
• 「誤った不可逆性」に異議を唱えます（証拠なしに「後から変更できない」とする主張）
• チームの健全性指標として、エスカレーション解除率を追跡します

設定

ユーザー設定

{
  "war_room": {
    "default_mode": "lightweight",
    "auto_escalate": true,
    "delphi_threshold": 0.85,
    "max_delphi_rounds": 5
  }
}

フックによる自動起動

以下の場合、フックを介して War Room を自動的に提案できます。

• キーワードが検出された場合（「戦略的決定」、「トレードオフ」など）
• 複雑性スコアがしきい値（0.7）を超えた場合
• ユーザーが設定でオプトインしている場合

エージェントチーム実行モード

概要

--agent-teams が指定された場合（または Full Council／Delphi モードで自動選択された場合）、War Room は逐次的な conjure 委任の代わりに Claude Code Agent Teams を使用します。各専門家は双方向のメッセージングが可能な常駐チームメイトとして動作し、一括のリクエスト／レスポンスの繰り返しではなく、リアルタイムで審議できます。

必要条件：Claude Code 2.1.32 以降、CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1、tmux のインストール。

エージェントチームが役立つ場合

モード	エージェントチームなし	エージェントチームあり	メリット
Express	Sonnet の直接呼び出し	該当なし（過剰）	なし：スキップ
Lightweight	逐次的な委任 3 回	該当なし（オーバーヘッドがメリットを上回る）	なし：スキップ
Full Council	逐次／並列の委任 7 回	ライブ受信トレイメッセージングを備えたチームメイト 7 人	専門家が互いの COA にリアルタイムで反応できます
Delphi	複数回の委任ラウンド	収束するまで反復する常駐チーム	ラウンドごとの再呼び出しコストがなく、ラウンド間で状態が維持されます

目安：エージェントチームは Full Council モードと Delphi モードでのみ使用してください。Lightweight モードと Express モードでは、連携のオーバーヘッドを正当化するほど専門家間のやり取りが発生しません。

チーム設定

# War Room agent team structure
Team: war-room-{session-id}
  Lead: supreme-commander (Opus) — orchestrates phases, final synthesis
  Teammates:
    chief-strategist (Sonnet) — approach generation
    intel-officer (Sonnet) — deep context analysis
    field-tactician (Sonnet) — implementation feasibility
    scout (Haiku) — rapid reconnaissance
    red-team (Sonnet) — adversarial challenge
    logistics (Haiku) — resource estimation

注：エージェントチームモードでは、すべてのチームメイトが Claude Code インスタンス（Opus／Sonnet／Haiku）として動作します。エージェントチームには Claude CLI が必要なため、外部 LLM の専門家（Gemini、Qwen、GLM）は使用されません。トレードオフとしてモデルの多様性は失われますが、専門家間のリアルタイムメッセージングが可能になります。

エージェントチームでの審議の流れ

1. リードがチームを作成 → tmux ペインでチームメイトを起動します
2. フェーズ 1（インテル）：リードが受信トレイを介して、偵察担当者とインテル担当者にインテルタスクを割り当てます
3. フェーズ 3（COA）：リードが状況評価をブロードキャストします。チームメイトはそれぞれ独立して COA を作成し、メッセージングを通じて作成中に確認事項を質問できます
4. フェーズ 4（レッドチーム）：レッドチームのチームメイトがすべての COA を受け取り、異議を投稿します。他のチームメイトはリアルタイムで異議に応答できます
5. フェーズ 5（投票）：リードが投票用紙をブロードキャストし、チームメイトは受信トレイメッセージを通じて順位を付けます
6. フェーズ 6（プレモーテム）：すべてのチームメイトが選ばれた COA を受け取り、互いの失敗シナリオを発展させることができます
7. フェーズ 7（統合）：リードがすべての成果物を集め、決定をまとめます
8. フェーズ 8（ディスカッションの公開）：最高司令官決定ドキュメントの最終版が完成したら、 modules/discussion-publishing.md を実行して、 決定を GitHub Discussions に公開する必要があります。 デフォルトでは公開します。ユーザーは「n」で拒否できます。 手順の詳細については、以下の「ディスカッションの公開（必須）」 セクションを参照してください。

conjure 委任へのフォールバック

エージェントチームが失敗した場合（tmux を利用できない、チーム作成エラーなど）、War Room は標準の conjure 委任に自動的にフォールバックします。審議プロトコルは同一で、異なるのは実行バックエンドのみです。

コストに関する考慮事項

エージェントチームは、conjure の委任よりも大幅に多くのトークンを消費します（各チームメイトが独自のコンテキストウィンドウを維持するためです）。調整による価値がコストに見合う場合にのみ使用してください。通常は、複数回の修正を重ねることでチームメイトを継続的に参加させる価値が生まれる Delphi モードが該当します。

ディスカッションの公開（必須）

Phase 7 の統合が完了した後（実行モードを問わず）、必ずディスカッション公開ワークフローを実行してください。ユーザーが明示的に辞退しない限り、これは必須です。

以下の手順を順番に実行してください：

1. GraphQL ワークフローの全手順について、modules/discussion-publishing.md を読みます
2. ユーザーに「この決定を GitHub Discussions に公開します。［Y/n］」と尋ねます
3. ユーザーが「n」と答えた場合は、関連スキルに進みます。それ以外の場合は、手順 4～6 を実行します
4. モジュールに記載された gh api graphql コマンドを実行し、「Decisions」カテゴリにディスカッションを作成します
5. 各フェーズの要約を、ディスカッションへのスレッド形式のコメントとして投稿します
6. ローカルの strategeion ファイルをディスカッションの URL で更新します

GitHub Discussions を利用できない場合（GitHub 以外のプラットフォーム、Discussions が無効、gh が認証されていない場合）は、ユーザーに警告してスキップしてください。公開に失敗しても、ウォールームのワークフローは中断されません。

終了条件

• 可逆性スコアと意思決定の種類が算出され、記録されている。
• 選択したアプローチ、その根拠、異論を含む最高司令官の決定文書が作成されている。
• 決定が docs/tradeoffs.md に反映されている（アーキテクチャ上の決定の場合は、番号付き ADR も docs/adr/ に作成されている）。
• 事前検死の監視ポイントと、タイプ 1 の決定の場合は撤回計画が記録されている。

関連スキル

• Skill(attune:project-brainstorming) - ウォールーム前のアイデア創出
• Skill(imbue:scope-guard) - スコープ管理
• Skill(imbue:rigorous-reasoning) - 推論方法論
• Skill(conjure:delegation-core) - 専門家の招集
• Skill(conjure:agent-teams) - エージェントチームの調整（Full Council／Delphi）

関連コマンド

• /attune:war-room - このスキルを起動します
• /attune:brainstorm - ウォールーム前のアイデア創出

参考資料

戦略の基盤

• Sun Tzu - Art of War（情報収集）
• Clausewitz - On War（摩擦と不確実性）
• Robert Greene - 33 Strategies of War（指揮系統の統一）
• MDMP - 米陸軍（体系的な意思決定プロセス）
• Gary Klein - Premortem（失敗モード分析）
• Karpathy - LLM Council（匿名のピアレビュー）

可逆性のフレームワーク

• Jeff Bezos - タイプ 1 とタイプ 2 の意思決定（Amazon の株主向け書簡）
• Farnam Street - 可逆的な決定と不可逆的な決定（STOP-LOP-KNOW フレームワーク）
• Tapan Desai - 一方通行と双方向のドアによる意思決定（実践的な適用）