構造化ディベート

クロスモデル対抗型ディベート編成を通じた高品質な製品ドキュメントの作成。

3つの役割：

• 司会者（Host）（あなた、メインセッション Claude）— フレームワークの設計、ラウンドの編成、進行の判定、遡及検証の実行
• 提案者（Proposer）（GPT-5.4、Codex 経由で呼び出し）— 分析と提案の作成
• レビュアー（Reviewer）（Claude サブエージェント）— 対抗型レビュー、弱点と空白の発見

プロセス概要

フェーズ 1：初期化
  → 既存のディベートを確認 → ワークスペースを作成 → .debate-state を初期化

フェーズ 2：意図の明確化（必須）
  → 司会者が構造化提問 → ユーザーが意図を確認 → intent-brief.md に記述
  → フレームワーク設計またはディベート開始の前に必ず完了

フェーズ 3：フレームワーク設計
  → トピックを分析 → 4～7 段階の議論を設計 → ユーザーに提示 → debate-framework.md に記述

コードベース調査（条件付きトリガー）：
  → 司会者がトピックが既存コードベースに関連するかを判断
  → 関連する場合：Explore エージェントがプロジェクトをスキャン → codebase-context.md に記述
  → 目的：製品設計に現実的な基盤を提供、技術方案の作成ではない

フェーズ 4：段階別実行（各段階ごと）
  → 司会者が実行モードを決定：
    A) 探索ラウンド？ → 提案者が問題フレームワークを作成 → レビュアーが批評 → 司会者が重要な質問を充実
    B) モジュール分割？ → 分割 → 各モジュールを単一ラウンド → 複数ラウンドで統合
    C) 標準：2～5 ラウンドの提案者↔レビュアー対抗型ディベート
  → 進行時：共識 + コアコミットメント + 遡及検証を記述
  → すべての成果物は製品の視点であること — 技術実装に関与しない、技術スケジュールに関与しない

フェーズ 5：最終統合 → PRD（製品の視点）+ サマリー + 決定ログ
フェーズ 6：成果物 → 結果を提示 → ユーザーがレビュー/修正可能

自動進行：各フェーズが完了すると、自動的に次のフェーズに進みます。

ワークスペース構造

debates/<debate-slug>/
  .debate-state               # YAML チェックポイント
  intent-brief.md             # ユーザー意図の明確化（フェーズ 2 の成果物）
  debate-framework.md         # フェーズ、目標、重要な質問
  core-commitments.md         # 確認されたコミットメント（遡及アンカーポイント）
  codebase-context.md         # プロジェクトコードベースのサマリー（調査がトリガーされた場合）
  phases/
    01-<phase-slug>/
      round-NN-proposer.md    # 提案者の成果物（00 = 探索ラウンド）
      round-NN-reviewer.md    # レビュアーの成果物
      consensus.md            # フェーズの共識
      backtrack-check.md      # 遡及検証の結果
      prompts/                # Codex プロンプトファイル（監査証跡）
      modules/                # サブモジュールファイル（モジュール分割がトリガーされた場合）
        01-<module>/
          round-01-proposer.md / round-01-reviewer.md / mini-consensus.md
  output/
    prd.md / debate-summary.md / decision-log.md

---

フェーズ 1：初期化

1. /debate 呼び出しからユーザーのトピックを解析
2. debates/ に進行中のディベートがあるかを確認（回復プロトコルは references/session-recovery.md を参照）：
   • 見つかった → .debate-state を読み込み → 回復または新規作成オプションを提供
   • 見つからない → 作成を続行
3. debate-slug を生成（小文字、ハイフン、最大 40 文字）
4. ワークスペースディレクトリを作成
5. .debate-state を初期化：

   version: "1.0"
   debate_name: "<説明的な名前>"
   debate_slug: "<slug>"
   topic: "<ユーザーの元のトピック、逐語的に記録>"
   created_at: "<ISO タイムスタンプ>"
   current_phase: 0
   current_round: 0
   total_phases: 0
   status: "initializing"
   research_done: false
   intent_confirmed: false
   phase_statuses: {}
   last_action: "init"
   last_action_at: "<ISO タイムスタンプ>"
   

---

フェーズ 2：意図の明確化（必須）

目標：フレームワーク設計またはディスカッション開始前に、ユーザーとの深い意図の整合を行い、司会者がユーザーの製品ニーズを完全に理解していることを確認します。

これは必須ステップであり、スキップできません。 フレームワーク設計に早期に進入すると、方向のずれ、やり直し、および議論リソースの無駄につながります。明確化の観点、提問テンプレート、および成果物フォーマットについては、references/intent-clarification.md を参照してください。

実行方法

1. 初回質問：ユーザーの初期説明に基づいて、最も重要な 3～5 の質問を選択して提出します。すべての質問を一度に出さないでください。
2. フォローアップと深掘り：ユーザーの回答に基づいて、曖昧な部分または重要な点についてフォローアップします。
3. 情報の統約と確認：司会者が十分な情報があると判断したら、理解の要約をユーザーに提示し、明確に確認を求めます。
4. ユーザーの確認後：明確化の内容を intent-brief.md に記述し、.debate-state を更新（intent_confirmed: true）してフェーズ 3 に進みます。

---

フェーズ 3：フレームワーク設計

目標：ユーザーのトピックのためのカスタマイズされたディスカッションフレームワークを設計します。

固定テンプレートを使用しません。 フレームワークを設計する際に、基本パターンと設計原則を得るために references/framework-design.md を読んでください。

重要：フレームワークは製品の視点から設計する必要があります。各フェーズは製品レベルの問題（ユーザー価値、シナリオ、エクスペリエンス、優先順位、スコープ）に焦点を当てるべきであり、技術実装の詳細に関与しません。「どのフレームワークを使うのか」「インターフェースをどのように設計するのか」「データベースをどのようにモデル化するのか」「技術スケジュールはどのくらいか」などの技術的な質問はこのフェーズの範囲ではありません。

1. intent-brief.md を読んでフレームワーク設計の主要な入力とします
2. トピックを分析：タイプ、依存チェーン、潜在的な分歧の領域
3. 4～7 フェーズを設計、各フェーズに以下を含めます：名前、目標、重要な質問（3～5 個）、完了基準、依存性
4. すべての重要な質問が製品レベルであることを検証：技術実装方案に関与しない、技術スケジュールに関与しない
5. debate-framework.md に記述
6. ユーザーに確認を提示
7. ユーザーの確認後：.debate-state を更新し、コードベース調査判定に進みます

---

コードベース調査（条件付きトリガー）

目標：ディベートをプロジェクトの実際のコードベースに植え込み、PRD が既存の製品機能と互換性があるようにします。

重要：コードベース調査は製品設計の現実的な基盤を支援するもので、技術計画ではありません。その目的は以下を理解することです：

• 既存の製品機能とユーザーエクスペリエンス（ユーザーは現在何ができるのか）
• 製品の制約と境界線（既存の製品構造に基づいて、何が実行可能/不可能か）
• 製品モジュール間の関係（機能がどのように相互に関連しているか）
• データとコンテンツモデルの製品的意味（どのような情報が存在し、どのように組織されているか）

コードベース調査は技術実装方案、アーキテクチャ設計、または開発スケジュールを作成しません。これらのコンテンツは製品 PRD の最終版後の独立した技術方案フェーズに属しています。

このフェーズに進むときに、完全なプロトコル、Explore エージェントプロンプト、および成果物フォーマットを取得するために references/codebase-research.md を読んでください。

トリガー条件（いずれかに該当）：トピックが既存機能の進化に関連している；重要な質問が技術的な制約に関連している；ユーザーが具体的なモジュールまたはコンポーネントを言及した。

スキップ条件（いずれかに該当）：純粋な戦略/ビジネストピック；新規製品；意味のあるコードリポジトリがない。

トリガーされたとき：

1. Explore エージェントがコードベースをスキャン（1～2 エージェント、並列実行）
2. 司会者が成果物を統合 codebase-context.md（1000～2000 字）
3. コンテキストを提案者/レビュアープロンプトに注入（references/context-management.md を参照）
4. .debate-state を更新：research_done: true

---

フェーズ 4：段階別実行

これはコアディベートループです。 各フェーズについて：

重要な制約 — 製品の視点のみ：ディスカッション全体の成果物は製品方案である必要があり、技術方案ではありません。ディスカッション内でコードベースの現状を製品決定の根拠として参照することは可能です（例：「既存製品は既に XX 機能をサポートしている」）が、技術実装の詳細を深掘りすべきではありません（例：「React を使うべきか Vue を使うべきか」「データベーステーブルをどのように設計するか」「インターフェースをどのように定義するか」）。技術実装方案と技術スケジュールは製品 PRD 完成後の独立した技術方案フェーズで実施すべきです。

ステップ 1：実行モードの決定

探索ラウンド？ トリガー条件：早期フェーズの情報不足；重要な質問が詳細な定義を必要とする；前のフェーズが不十分なコンテキストをもつ。スキップ条件：後期フェーズ、前のフェーズからの豊富なコミットメントまたは評価型の目標。

モジュール分割？ トリガー条件：フェーズが詳細な仕様書に関連している；3 個以上の独立したサブモジュールを識別；重要な質問がモジュール単位でグループ化されている。スキップ条件：単一で一貫性のあるトピック。

両方は共存可能です：探索ラウンド → モジュール分割 → 統合ラウンド。

ステップ 2：ラウンドの実行

探索ラウンド（第 0 ラウンド） — トリガーされたときに、探索ラウンドプロンプトテンプレートを得るために references/proposer-protocol.md を読んでください：

1. 提案者が問題フレームワークを作成（提案ではない） → round-00-proposer.md
2. レビュアーがフレームワークの完全性を批評 → round-00-reviewer.md
3. 司会者が両者を統合 → debate-framework.md の重要な質問を更新
4. 第 1 ラウンドに進みます。5 ラウンドの上限にカウントされません。

モジュール分割 — トリガーされたときに、提案者テンプレートを得るために references/proposer-decomposition.md を読み、レビュアーテンプレートを得るために references/reviewer-decomposition.md を読んでください：

1. 分割ラウンド：提案者がサブモジュールをリストアップ → レビュアーが検証 → 司会者が確認
2. モジュール単位ラウンド（各モジュール 1 ラウンド）：提案者が提案 → レビュアーが批評 → 司会者が小さな共識を記述
3. 統合ラウンド（2～5 ラウンド、標準進行）：提案者がすべてのモジュールを統合 → レビュアーがモジュール間一貫性を批評

標準ラウンド（第 1～5 ラウンド） — プロンプトワードを準備するときに、提案者テンプレートを得るために references/proposer-protocol.md を読み、レビュアーテンプレートを得るために references/reviewer-protocol.md を読んでください：

1. 司会者が提案者プロンプトを準備（フェーズの目標 + 重要な質問 + 前ラウンドのサマリー + レビュアーの異議 + コアコミットメント）。完全なディベート履歴を含まない — references/context-management.md を参照してください。
2. Bash から Codex CLI を実行して提案者を呼び出します：

   codex exec -o "<output-path>" --full-auto --ephemeral - < "<prompt-file-path>"
   

   ここで <prompt-file-path> は記述したプロンプトファイルパス、<output-path> は出力結果ファイルパス（例 round-NN-proposer.md）です。 - は stdin からプロンプトを読み取ることを意味し、--full-auto は自動実行を有効にし、--ephemeral はセッションを永続化しません。
3. 成果物を検証：長さ ≥ 200 字、必要なセクションが存在、重要な質問が網羅されている。チェック失敗の場合、明確なギャップの説明で再プロンプト（最大 2 回の再試行）。
4. Agent ツールを通じてレビュアーを呼び出し（model: opus）
5. 司会者が収束性を判定 — references/phase-progression.md から 5 選 3 の進行基準を参照

ステップ 3：フェーズの完了

進行基準が満たされた場合（または第 5 ラウンドで強制進行）：

1. consensus.md に記述（達成された共識的立場、解決された分歧、トレードオフ、開いている項目）
2. コアコミットメントを抽出 → core-commitments.md に追加、C{phase}.{index} として番号付け
3. 遡及検証 — このチェックを実行するときに references/backtracking-algorithm.md を読んでください：
   • 3 つの観点：アラインメント、スコープ、優先順位
   • ハード違反（矛盾） → 進行を阻止、補充ラウンド
   • ソフト違反 → 共識で必ず記録
4. .debate-state を更新し、自動的に次のフェーズに進みます

---

フェーズ 5：最終統合

すべてのフェーズが完了した後：

1. すべての consensus.md + core-commitments.md + debate-framework.md + intent-brief.md を読む
2. output/prd.md を作成 — references/prd-template.md の構造に従ってコンテンツを整理
   • 製品の視点：PRD が説明するのは「何をするのか」と「なぜやるのか」であり、「どのようにやるのか」ではありません。技術アーキテクチャ設計、インターフェース定義、データベース方案、技術スケジュールなどのコンテンツは含めません。
   • 技術的な制約が関連する場合：製品制約の形式でのみ表示（例「既存 XX 機能との互換性が必要」）、技術の詳細は展開しません。
3. output/debate-summary.md を作成：フェーズ単位の要約、統計データ、ハイライト
4. output/decision-log.md を作成：時系列の決定と理由
5. .debate-state を更新：status: "completed"

---

フェーズ 6：成果物

ディベート完了："{debate_name}"
合計 {total_phases} フェーズ、{total_rounds} ラウンド、{commitment_count} 件のコミットメント

成果物ファイル：
- debates/<slug>/output/prd.md
- debates/<slug>/output/debate-summary.md
- debates/<slug>/output/decision-log.md

A) 完全な PRD を表示  B) 特定のフェーズを詳しく  C) 特定のセクションを修正

---

ユーザーの介入

ユーザーは任意のラウンド間に割り込むことができます：

ユーザーの発言	司会者の操作
「X を考慮してください」/ 「Y を忘れないでください」	制約条件として次のラウンドのプロンプトに追加
「方向が違う」/ 「Z に焦点を当てる」	フェーズ戦略を調整、重要な質問を修正
「このフェーズをスキップする」	スキップとマーク、進行
「一時停止」	状態を保存、待機
「フェーズ N に戻る」	そのフェーズにリセット
「X についての新しいフェーズを追加する」	フレームワークに新しいフェーズを挿入

処理後、変更内容を明確に確認してから続行します。

---

エラー処理

Codex 障害：1 回再試行 → タイムアウトの場合：プロンプト長を削減 → 継続して失敗する場合：Claude サブエージェントに一時的な提案者としてフォールバック（記録で注記）。

成果物の品質が低い：明確なギャップの説明で再プロンプト、最大 2 回の再試行。再試行後も不十分な場合、進行を続け、マークします。

制御不能なディベート：総ラウンド数 > total_phases × 4 → ユーザーに通知、圧縮または終了オプションを提供。

---

禁忌

不要	理由
意図の明確化をスキップまたは不十分に実施	意図の不整合はディベートラウンドの無駄と PRD 方向の誤りにつながる
すべてのトピックに固定フェーズテンプレートを使用	フレームワークはカスタマイズされなければならない
ディベートに技術実装や技術スケジュールを含める	製品 PRD は「何をするのか」と「なぜやるのか」に焦点を当て、技術方案は独立した後続フェーズ
完全なディベート履歴をサブエージェントに渡す	コンテキストオーバーフロー — 制限された要約を使用
レビュアーに提案者のプロンプトを見せる	追従傾向が生じる
レビュアーが同意してもも 1 ラウンド後に進行	堅牢性を確保するには最少 2 ラウンド
遡及検証をスキップ	コアメカニズム — 決してスキップしない
各ラウンド後にユーザーにサマリーを提供	フェーズ転換のみ
ディベートに司会者自身の見方を注入	司会者は編成を担当、ディベートに参加しない

コア原則

1. 意図優先 — 十分な意図の明確化なしに、フレームワーク設計を開始しないでください。「なぜ」を理解してから「何をするのか」を議論してください
2. 製品の視点 — ディベート全体の成果物は製品ドキュメントです。技術実装の詳細、技術スケジュール、アーキテクチャ設計は含めません。これらは独立した下流フェーズに属します
3. ファイルが状態 — すべての状態はファイルにあり、対話メモリにはありません。すべての操作が .debate-state を更新します
4. エージェントコンテキスト有界 — 各エージェントが必要なコンテンツのみを見ます。references/context-management.md を参照してください
5. 自然な対抗 — レビュアーの責務は攻撃であり、検証ではありません
6. 遡及は譲れない — フェーズ進行のたびに前のコミットメントを確認
7. 誠実な収束 — ドキュメント化された分歧を伴う部分的な共識は合法です
8. クロスモデルの優位性 — GPT-5.4 が提案、Claude がレビュー。異なる盲点
9. ユーザーが最終権限 — ユーザーのあらゆる介入はディベート動態より優先
10. コードベース植根 — トピックが既存プロジェクトに関連する場合、PRD は現実の製品機能と互換性がある必要があります（技術方案を規定するのではなく）