Claude Code スラッシュコマンドで6体のAIエージェントが討論し、止揚的結論を導く
前日（0318）のCLI三者討論フレームワークを発展させ、Claude Codeのスラッシュコマンド＋サブエージェント機能で実際に動作するマルチAI討論システムを設計した。
20260319/ ディレクトリをカレントディレクトリとしてClaude Codeを起動し、スキルを実行する。
cd 20260319
claude
# Claude Code内で:
/debate ソフトウェア開発においてテストは本当に必要か実行後、debate_YYYYMMDD_HHMMSS/ ディレクトリが生成される。
20260319/
├── .claude/
│ ├── skills/
│ │ └── debate/
│ │ └── SKILL.md # オーケストレーター（スキル定義）
│ └── agents/
│ ├── debater/
│ │ └── AGENT.md # 討論者エージェント（Claude用）
│ ├── summarizer/
│ │ └── AGENT.md # 要約者エージェント
│ └── judge/
│ └── AGENT.md # 審判エージェント
└── prompts/
└── debater.md # Gemini/Codex CLI用プロンプトテンプレートdebate_20260319_143000/
├── 1_claims/
│ ├── pro_claude.md # Claude賛成派の主張
│ ├── pro_gemini.md # Gemini賛成派の主張
│ ├── pro_codex.md # Codex賛成派の主張
│ ├── con_claude.md # Claude反対派の主張
│ ├── con_gemini.md # Gemini反対派の主張
│ └── con_codex.md # Codex反対派の主張
├── 2_summaries/
│ ├── pro_summary.md # 賛成派要約（共通主張＋独自洞察）
│ └── con_summary.md # 反対派要約（共通主張＋独自洞察）
└── 3_report/
└── final_report.md # 最終レポート（評価＋止揚的結論）オーケストレーターが主張ファイルを読むと、要約の前にバイアスが入る。ファイルパスの受け渡しのみ行い、内容の解釈はサマライザーと審判に委ねる。
賛成・反対それぞれに専任のサマライザーを置くことで、立場の混同を防ぐ。サマライザーは「3者共通の主張（Core Claims）」と「1者だけの独自視点（Unique Insights）」を分離して出力する。
審判AIは単純な勝ち負けではなく、弁証法的な統合を目指す。賛成・反対双方の正当な点を取り入れた、より高次の結論を導出する。
| 役割 | 種別 | 定義ファイル | モデル | 概要 |
|---|---|---|---|---|
| オーケストレーター | Skill | .claude/skills/debate/SKILL.md | opus | 全体の制御フロー。Phase 0〜4を順次実行 |
| 討論者（Claude） | Agent | .claude/agents/debater/AGENT.md | opus | テーマと立場を受け取り、主張をファイル出力 |
| 討論者（Gemini/Codex） | CLI | prompts/debater.md | — | CLIに渡すプロンプトテンプレート |
| 要約者 | Agent | .claude/agents/summarizer/AGENT.md | opus | 同一立場の3ファイルを統合要約 |
| 審判 | Agent | .claude/agents/judge/AGENT.md | opus | 両要約を評価し止揚的結論を導出 |
スキル（SKILL.md）とエージェント（AGENT.md）はYAMLフロントマター付きMarkdown。
# SKILL.md のフロントマター例
---
name: debate
description: マルチAI討論システム
user-invocable: true
allowed-tools: Read, Write, Bash, Glob, Grep, Agent
model: opus
argument-hint: "[討論テーマ]"
---
# AGENT.md のフロントマター例
---
name: debater
description: 討論の参加者
tools: Read, Write
model: opus
maxTurns: 5
---0318の調査結果に基づく。プロンプトは一時ファイル経由で渡す（シェルエスケープ問題の回避）。
| AI | 呼び出し方 | 備考 |
|---|---|---|
| Claude | Agentツール（サブエージェント） | Read/Writeツールにアクセス可能 |
| Gemini | gemini -p "$(cat prompt.txt)" | TTY非検出で自動ヘッドレス |
| Codex | codex exec "$(cat prompt.txt)" 2>/dev/null | stderr抑制で結果のみ取得 |
gemini) がPATH上にあることcodex) がPATH上にあることテーマ: 「ソフトウェア開発においてテストは本当に必要か」
実行日時: 2026-03-19 05:33 / ワークスペース: debate_20260319_053330/
要旨: テストは品質保証と変更容易性の両面で不可欠。省略は短期的コスト削減に見えて長期的に技術的負債を蓄積する。
根拠:
先制回答: 小規模でもコアロジックにはテストを書く習慣が将来の拡張に備えた合理的判断。テストなしの手動確認・障害対応コストを定量比較すれば投資は正当化される。
要旨: テストは単なる確認作業ではなく、品質・開発効率・ビジネス持続可能性を支える不可欠な基盤。
根拠:
要旨: テストは品質確保・保守性向上・コスト削減・仕様共有・属人化防止のために必要な開発活動。
根拠:
要旨: テストは品質向上の一手段に過ぎず、すべての開発文脈において必須とはいえない。
根拠:
先制回答: 品質保証はテスト以外の手段の組み合わせで達成可能。テスト整備は安定フェーズ以降でも合理的。
要旨: 「テストは必ずしも常に必要・最適解であるとは限らない」
根拠:
要旨: テストはあらゆるソフトウェア開発で必須とするのは現実的ではない。
根拠:
共通主張（Core Claims）:
独自の洞察（Unique Insights）:
強度評価: 複数の独立した軸から一貫して同一結論を支持。ただし反論耐性の厚みにばらつきあり。
共通主張（Core Claims）:
独自の洞察（Unique Insights）:
強度評価: 「無条件の必須論への反証」という抑制的立場は堅固だが、ミッションクリティカル領域への言及が薄く適用範囲の限界が不明確。
| 評価軸 | 賛成派 | 反対派 |
|---|---|---|
| 論理的整合性 | A — 複数の独立した軸から一貫して同一結論を支持 | B — 抑制的立場は健全だが適用範囲の限界が不明確 |
| 根拠の具体性 | A — IBM調査、アリアン5事故、ECサイト・金融系の具体例 | B — Netflix・Amazon等の事例はあるが因果関係の立証が不十分 |
| 反論への対応力 | B — Claudeのみ先制回答あり、他2名は反論への対応を欠く | B — ミッションクリティカル領域への反論が薄い |
| 独自性 | B — CI/CD統合やTDD設計改善等の新規性あり | A — 通説を反転させる切り口に独自性 |
| 総合 | A（8.0/10） | B（6.5/10） |
この討論の本質的な対立は「テストが必要か否か」ではなく、「品質保証のコストをどの時点・どの手段に配分するのが最適か」という資源配分問題である。
賛成派が正しく指摘するように、欠陥コストは発見が遅れるほど指数関数的に増大し、テストはその早期発見の最も体系化された手段である。一方、反対派が正しく指摘するように、テストコード自体が保守対象であり、不確実性の高い段階で過剰なテストを整備することは投資効率を損なう。両者は矛盾しているのではなく、ソフトウェアのライフサイクル上の異なるフェーズにおける最適戦略を述べているに過ぎない。
統合的視座は「品質保証戦略のポートフォリオ管理」という概念である。テストは品質保証の重要な構成要素だが唯一の手段ではなく、型システム・静的解析・コードレビュー・監視・ロールバック機構・フォーマル検証といった手段とともに、プロジェクト特性に応じて最適な組み合わせを選択すべきである。
問うべきは「テストは必要か」ではなく、「このプロジェクト・このフェーズにおいて、品質保証への投資をどの手段にどれだけ配分するのが合理的か」である。