This post is also available in the following languages. English, Korean

AIエージェントに議論させよ：マルチエージェント連携による開発プロセスの再設計

LINEヤフーの技術カンファレンス「Tech-Verse 2026」の公式記事です。

AIでのコーディングで難しいのは、もはやコードを出すこと自体ではありません。課題はその周辺にあります。意図を正確な仕様に落とし込むこと、前提を問い直すこと、実装を検証すること、そしてレビュワーが信頼できるプルリクエスト（PR）を用意することです。

私たちはそのコーディネーション層を、提案者（Proposer）と挑戦者（Challenger）という専門家の段階的な討論として再設計しました。各フェーズは独自の成果物を持ちます。仕様（spec）、実装（implementation）、そしてレビュー準備が整ったPR（プルリクエスト）パッケージ。提案者は成果物を前進させ、挑戦者はフェーズごとに異なる形でそれを指摘します。仕様フェーズではソクラテス式の質問、実装フェーズでは証拠に基づく異議、デリバリーフェーズでは出荷準備の検証。オーケストレーター（Orchestrator）は、改訂・エスカレーション・前進のいずれを行うかを判断します。

CI（継続的インテグレーション）フローでは、Issue（課題）が議論された仕様になり、ブランチとなり、テストされた実装になり、レビュー準備のPRになります。最終的な判断はエンジニアが担いますが、もはやすべての受け渡しを手作業で調整する必要はありません。

この記事では、このパイプラインがどう機能するか、どこが破綻しやすいか、そして本当の効果が単に生成速度の向上にあるのではない理由を示します。要点は、AIに“仕事の証拠”を出させてから人間が注意を払うようにしている点です。

問題：人間のコーディネーションがボトルネック

「10x Faster」は、個々の手作業をただ速めるだけでは実現しません。必要なのはプロセス自体の再設計です。意図をどう仕様にするか、前提をどう問い直すか、実装をどう検証するか、レビュワーが判断するための十分な証拠をどう渡すか。

ここに耳の痛い現実があります。AIを使ってソフトウェアを作るとき、ボトルネックは必ずしもAIによる生成速度ではなく、その周りにある人間のコーディネーションです。私たちは仕様を書き、AIにドラフトを作らせ、ドラフトを検査し、欠落を明確にし、コードを依頼し、チェックを実行し、失敗を貼り付け、差分をレビューし、PR説明を求め、結果が安全か判断します。AIは各ローカルなタスクを素早く終えますが、次の手続きを調整するのは人間の仕事として残ります。

これはAI支援です。従来のプロセスにAIを差し込んだだけ。個々のステップは速くなりますが、高コストな部分、つまり意図・実装・検証・レビュー・デリバリの間の調整層はそのまま残ります。実用的な道はエンジニアを判断の場から排除することではなく、煩雑な中間の反復的な調整作業から解放することです。

私たちのチームでは、別のアプローチを試しています。開発を、1つのアシスタントにプロンプトを渡す連続ではなく、専門化されたAIロール同士の構造化された協働として扱う方法です。

洞察：AIエージェントに共同で考えさせる

では、もし人間が反復的な受け渡しを逐一調整しなくなったとして、システムはどうやってバグを捕まえ、前提を問い、最終レビュー前にエッジケースを表面化させるのでしょうか？

もう1つ手動チェックポイントを追加するだけでは、ボトルネックに別の名前を付けるだけです。単一のAIチェッカーを追加しても、多くの場合は別の一面だけのレビューに陥ります。

答えはこうです。AIロールを2つの対立するチーム（提案者（Proposer）と挑戦者（Challenger））に整理し、各フェーズで異なる専門的責務を与え、構造化されたプロトコルで討論させることです。これは魔法ではありません—ペアプログラミングが機能する理由と同じです。ただし規模が大きく、2人の代わりに2つのAI専門チームが互いに問いを投げ合います。

役割名そのものは重要ではありません。設計の原則は、仕様、実装、レビュー、検証、デリバリを1つの汎用アシスタントの応答にまとめず、別々の責務として保つことです。工学的責務を分け、各側が証拠に基づいて議論し、オーケストレーターが作業を前進させるかどうかを決めます。

AIネイティブ開発は、これらの専門ロールが共有された成果物を中心に協働するようプロセスを再設計します。人間は中間の面倒なマイクロコーディネーションから解放されますが、所有権や判断責任は残ります。その間にエージェントは自動的に探索、洗練、検証、挑戦、パッケージ化を行います。通常は、開始時に意図を定義し、終了時に成果を承認する、またはシステムが明示的にエスカレーションしたときに介入する、といった戦略的なゲートで人間が関与します。

仕組み：3つのフェーズ、1つの仕様主導パイプライン

ワークフローは3つの要素で構成されています。Spec（仕様） → Build（実装） → Delivery（デリバリ）、対立する2つの専門側、そして改訂・エスカレーション・前進を判断するオーケストレーターです。この順序は意図的です。特に重要なのは仕様（Spec）フェーズで、後続のすべてのフェーズが従うべき契約を定義するからです。目的、制約、解釈された要件、明示的な前提、未解決の問い、提案アプローチ、そして完了の定義（Definition of Done）です。

この意味で、これは一種の仕様駆動開発（Spec-Driven Development）です。仕様は問題に応じて短くても長くても構いませんが、ワークフローの支配的な成果物になる必要があります。Build側のエージェントは「まあ合理的に見えることをする」だけではありません。まず合意された仕様からテストと検証設計を導出し、その仕様と検証設計の両方に対して実装を行います。Delivery側は単に差分を要約するのではなく、実装が仕様を満たしているかを証明します。仕様が弱ければパイプライン全体が弱く、仕様が精緻であれば後続フェーズは最適化、挑戦、検証するための具体的な対象を持てます。

各フェーズでは、専門化されたエージェント実行が提案者（Proposer）か挑戦者（Challenger）のいずれかに割り当てられます。ここで「エージェント」とは、Claude Code、Codex、OpenCodeなどのツールで使われるコーディングエージェントの実行を指し、オーケストレーターによって専門的役割が与えられます。「エージェントチーム」は、同一フェーズで対立する側で動作するこれらのロール特化実行の集合です。共有されたハイブマインドを持つ多数の重い自律システムを意味するわけではありません。現在の実装では、各実行は狭いプロンプト、自身のコンテキスト、同じワークスペース成果物へのアクセスを持ちます。チームという比喩は、各実行が1つの工学的視点に基づいて議論することを促し、すべての責務を1つの汎用的な応答に混ぜ込まないようにする点で有用です。

オーケストレーターは提案者（Proposer）と挑戦者（Challenger）の間に位置し、討論が脱線した際の誘導、行き詰まりの打破、継続・改訂・前進のフェーズレベルの評決を行います。役割はフェーズごとに変化します。SpecやBuildでは調停者として収束を導き、Deliveryでは陪審として出荷に十分な証拠があるかを判断します。

各フェーズは異なる専門的焦点と異なる討論戦略を組み合わせています。これは偶然ではなく、各フェーズが根本的に異なる目的を持つためです。

フェーズ	提案者の焦点	挑戦者の焦点	討論戦略
Spec（仕様）	コードベースを調査し、要件を統合する	曖昧さ、隠れた前提、リスクを浮き彫りにする	ソクラテス式質問：質問のみ、断定や解決策は出さない
Build（実装）	仕様からテストと検証を設計し、その後変更を実装・維持する	検証設計、カバレッジ、セキュリティ、性能、受け入れ基準、保守性に異議を唱える	敵対的レビュー：異議にはテスト、コード、または実行の具体的な証拠が必要
Delivery（デリバリ）	PRの要約、証拠、レビュー地図を準備する	出荷準備、証拠の質、可視化の正確さを検証する	陪審討論：双方が自己判断せず、オーケストレーターが決定する

実務では、これらの焦点は requirements-synthesizer、security-analyst、test-coverage-reviewer、technical-writer、および evidence-verifier のような専門ロールに対応します。

俯瞰すると、同じ討論パターンが3つのフェーズすべてで繰り返されます。

重要なのは、各フェーズが雰囲気ではなく証拠に基づいていることです。仕様の文脈はワークスペースやJiraチケット、Confluenceページ、設計ドキュメント、インシデントノートなどの外部プロダクトソースから得られます。エージェントはその文脈を既存のAPI、テスト、依存関係、慣習と組み合わせて利用し、実装開始前により適切な問いを立てます。Buildはテストファーストです。本番コードを変更する前に、提案者は合意された仕様を期待される振る舞い、エッジケース、追加または更新すべきテスト、実行すべきコマンドへと翻訳します。挑戦者はコードの前または並行してその検証設計に異議を唱えることができるため、グリーンチェックが欠けた受け入れカバレッジを隠すことができません。Buildレビューは双方向です。提案者が挑戦を否定することはできますが、それには実行経路、コンパイル／リント出力、または失敗するテストのような証拠が必要です。Deliveryは結果をレビュワー向けの信頼パッケージに変換します。何が変わったか、まずどこを見るべきか、どのチェックが通ったか、どんなリスクが残るか、そして挑戦者が既に何を試したかを示します。

プロトコルの実際の形

ペイロードの細部はフェーズによって変わりますが、プロトコルの形は一貫しています。各専門家の実行はフェーズコンテキストを受け取り、必要に応じてワークスペースの証拠を調査し、オーケストレーターが解析・比較して次ラウンドに渡せる厳格なJSONを返します。エージェントは単一のライブコンテキストウィンドウを共有しません。永続的に共有される状態はワークスペース、生成された成果物、そしてオーケストレーターによって蓄積されたトランスクリプトです。

仕様フェーズは、このパターンが最も明瞭に現れます。なぜならそれが後続のすべての契約を作るからです。ラウンドは単なる「仕様をレビューする」だけではなく、小さな状態機械です。各ターンには定義された役割、制約された応答フォーマット、そして仕様を改訂するか、追加レビューを要求するか、残存する不確実性が安全に仮定できない場合はブロックするかを決める決定があります。

出力は長いエッセイではなく構造化されたJSONです。各ターンは同じエンベロープを保持するため、そのターンで使われないフィールドは空のままになります。例えば、挑戦者（Challenger）の質問ターンは次のように見えます。

{
  "turn": "questions",
  "status": "needs-revision",
  "summary": "ビルド前にスコープ境界が1つ必要です。",
  "specialistInputs": [
    {
      "name": "ambiguity-reviewer",
      "stance": "caution",
      "opinion": "指定されたエンドポイントは明確ですが、隣接する検索系のエンドポイントがスコープ内か外か明示されていません。"
    }
  ],
  "decisionRationale": "指定スコープを保持することで、意図しない範囲拡大を防ぎ、提案者が仕様に限定的な前提を記述できるようにします。",
  "payload": {
    "ready": false,
    "interpretation": {
      "requirements": [],
      "constraints": [],
      "definitionOfDone": [],
      "assumptions": [],
      "openQuestions": []
    },
    "questions": [
      {
        "id": "Q1",
        "severity": "major",
        "section": "constraints",
        "question": "実装は既存の `/api/search` ルートに限定し、他の検索系エンドポイントは明示的に名前が挙がらない限り変更しないようにすべきですか？",
        "whyItMatters": "この境界がないと、ビルドフェーズで関連しないエンドポイントが変更される可能性があります。仕様に文書化された場合、指定スコープを保持するのが安全なデフォルトです。",
        "requiresUserInput": false,
        "assumptionRisk": "low",
        "confidence": 0.85
      }
    ],
    "answers": []
  }
}

重要なのは、プロトコルが不確実性とブロッカーを区別することです。曖昧さが低リスクで可逆的かつ既存のワークスペース証拠で限定できるなら、提案者はその前提を仕様に書き込み進行できます。欠けている答えが安全性に関わる、破壊的、外部制約がある、または実質的に不可逆である場合は、システムは推測せずにエスカレーションします。

BuildとDeliveryも同じ構造化討論の考え方を用いますが、ペイロードは異なります。Buildはテストファーストの検証設計、実行の証拠、そしてレビュー課題を持ち、それらは根拠と証拠付きで accepted、rejected、または compromised にマッピングされます。Deliveryは結果をPR文、テスト証拠、レビュワー向けガイダンスにパッケージします。共通点は、エージェントが単に散文を生成するのではなく、次フェーズが検証できる構造化された証拠を残すことです。

スキルが専門ロールを強化する

専門ロールはロールプロンプトだけでは十分に機能しません。例えば「セキュリティアナリスト」という視点は有用ですが、再利用可能なスキルと組み合わせることでより強力になります。変更されたエンドポイントの脅威モデル化、認証境界のチェック、入力バリデーションのレビュー、あるいは具体的なエクスプロイトシナリオの生成などです。要するに、ロールはエージェントが何を重視すべきかを定め、スキルはそれをどう実行するかを定めます。

これにより専門知識はモジュール化されます。テストエンジニアは境界テスト生成のスキルを持ち込み、デリバリー担当のライターは意思決定の証拠を保つPR記述スキルを持ち、可視化の専門家は差分を図に変えるレビュー地図スキルを持ち込めます。チームがより良いレビュー手法を学べば、それは巨大なプロンプトの内側に埋もれるのではなく、再利用可能なメソッドになります。

討論はどう収束するか

よくある懸念：エージェントが際限なく議論し続けるのをどう止めるのか？

各ラウンドは厳格な構造に従います。提案者が提示 → 挑戦者が評価 → オーケストレーターが決定。オーケストレーターは継続させる、方向を修正する（話題外を誘導する）、解決する（部分的合意を受け入れる）、または終了させることができます。重要なのは、解決済みの問題が後続ラウンドから除外される点です—各ラウンドで討論の対象が段階的に狭まっていきます。5つの問題がある議論なら、ラウンド1で3つが解決され、ラウンド2は残り2つに集中します。

重要なのは、すべてのタスクが大きな発見を生むことではなく、各フェーズが不確実性を狭め構造化された証拠を残すことで、信頼性が偶然のレビューではなく再現可能なコントロールから生じる点です。

信頼性を支える要素

このパイプラインが無駄なラウンドを重ねたり、生産性のないループに陥ったりしないようにするための3つのエンジニアリング上の決定があります。

メカニズム	解決する問題	主要な考え方
複雑性ルーティング	すべてのタスクが完全な討論を必要とするわけではない	複雑さを分類し、リスクに応じて討論の強度を調整する
振動検出	A→B→A の修正ループはトークンを浪費する	繰り返される失敗シグネチャを検出し、再設計へエスカレーションする
構造化されたプライア	生のトランスクリプトは将来の実行に役立つ教訓を伝えない	結果をスキーマ対応の助言シグナルに圧縮する

複雑性ルーティング。 すべてのタスクが同じ討論強度を必要とするわけではありません。仕様の洗練レビューは、利用可能な実装コンテキスト（ソースファイルや実際に解決された外部参照など）を収集した後にタスクの複雑度を推定できます。討論が有効な場合でも、些細なタスクは軽量な専門家レビューにとどめ、重要と分類されたタスク（セキュリティに敏感な変更を含む）は追加ラウンドを設けます。コストはリスクに比例します。

ここで「light pass」は最小限の専門家レビューを意味し、「one full round」は複数ラウンドに拡張しない完全な提案者／挑戦者のやり取りを指します。

振動検出。 AIコーディングツールを一定期間使うと、このループを経験するでしょう。あるテストを直すと別のテストが壊れ、さらにそれを直すと元の失敗が再発する。個々の修正は進捗に見えますが、外からはループだと分かっても、エージェントは現在のエラーに集中しているため気づけないことが多いのです。

これは単一エージェントワークフローで最も苛立たしい失敗モードの1つです。エージェントは一生懸命働きトークンを消費しているのに、どこにも進まないことがあります。

当システムは自己修正の試行にわたる失敗シグネチャを追跡します。現在の失敗が2ステップ前と一致し、1ステップ前と異なる場合、つまり典型的なA→B→Aの振動であれば、自己修正ループを止め、その最新の結果をさらに同じ修正サイクルに費やすのではなく挑戦者（Challenger）レビューに回します。

ステップ 1: エラー A
ステップ 2: A を修正 → エラー B
ステップ 3: B を修正 → エラー A  ← ステップ 1 と同じ。ループ検出。
                         → 繰り返しを中断し、再設計のためにエスカレーション

検出を実行可能にするのは多エージェント構造です。単一のエージェントは「このエラーを以前に見た」と検出できても、その後どうすべきか？より頑張るだけでしょうか。討論構造はそれを別の視点を持つチームにエスカレーションできる場所を提供します。

構造化されたプライア（Structured priors）。 各実行後、システムは全トランスクリプトを生のメモリとして保存しません。代わりに、再利用可能な教訓を小さなスキーマ対応のプライアに圧縮します。どのパターンが現れたか、どの程度深刻か、それを裏付ける証拠カテゴリ、出現頻度、信頼度、最新のタスク、推奨される緩和策などです。

プロダクト的には、これは裁定者としてのメモリではなく警告ラベルとしてのメモリです。プライアは次のようにプロンプトに戻されることがあります。

- repeated-failure-check validation:rate-limit-concurrency:major
  (出現 3 回, 信頼度 0.65);
  mitigation: 変更された挙動パスのテストを追加または更新し、関連するチェックを再実行する;
  root causes: test-gaps, trust-boundary

重要な制約：プライアは助言的なシグナルです。専門家にどこをまず見るべきかを示しますが、現在の証拠がその主張を立証する必要があります。過去のパターンは追加の精査を促しますが、新しい実行を自動的に失敗扱いにすることはできません。これにより、メモリが無検証のバイアスに変わることなく過去のパターンから学べます。

いつ使うべきか

「正しい」が証拠で定義できる場合にこのパイプラインを使用してください。明確な意図、受け入れ基準、そしてコード・テスト・ログ・差分による検証があること。

この手法は非同期でCI駆動の作業に最も適しています。Issue（課題）がSpecの議論を引き起こし、Build、検証、そしてレビュー準備が整ったPRにつながります。人間は判断のゲートに留まり、意図を明確にし、リスクの境界を定め、結果を承認するかスコープを再設定します。

一般的な現在のフローは次の通りです。

適用に向くケース：

Issue→PR の CI 駆動自動化。
テスト可能な受け入れ基準を持つ小〜中規模の実装タスク。
再現可能な失敗、ログ、またはコードパスを伴うバグ修正。
セキュリティ、性能、テスト、保守性に関する挑戦が価値を生むリスク感度の高い変更。

「正しい」の定義がまだ交渉中である場合はこの手法を避けてください。探索的なプロダクト判断、不明瞭な要件、あるいは具体的な証拠で検証できない作業については、人間を内側のループに残してください。

このパイプラインは自身のソースコードの変更を提案することもできますが、それはあくまで提案にとどまります。ブランチとPRが必要、自己マージ禁止、CIバイパスなし、新しい権限なし、承認なしの破壊的操作は禁止です。

トレードオフと制限

次元	現実	緩和策
コスト	単一エージェントの1回分より多くのトークンを消費する	ルーティングにより些細なタスクは軽量ラウンドに留める。レイジーローディングで全ソースや差分、参照、トランスクリプトを毎回プロンプトに貼り付けることを避ける
レイテンシ	タスクごとに数分	非同期パイプラインに適合し、リアルタイムコーディングには向かない
大きな仕様	1回でスムーズに解決するのは依然難しい	仕様の分割を進める。大きな問題を中〜小に分解し、人間の確認が必要な決定を隔離する
盲点	両チームが同じ見落としをする可能性がある	モデル／プロバイダを多様化すると、異なるシステムが異なる盲点を持つため共有の失敗モードを減らせる
所有権	討論はエンジニアリングの説明責任を置き換えない	人間が意図を定義し、境界を承認し、本番の成果に責任を持ち続ける

追加コストはそれだけの価値があるでしょうか？多くの本番向け変更では、1つの見落としが追加の討論ラウンドより高くつくことがあります。バージョンアップのような場合は討論が無駄になることもあります。ルーティングとレイジーローディングによりコストはリスクと証拠の必要性に比例します。多エージェント討論は判断の万能な代替ではなく、人間に承認を求める前により一貫した判断を適用する手段です。

現在の状況

我々はこのシステムをCIを含め日常的に使用しています。これは「ハローワールド」デモではなく、小〜中規模の変更、特に明確な受け入れ基準を持つ作業で用いるワークフローです。実運用において、単一パスのアシスタントワークフローよりも仕様が厳密になり、問題を早期に表面化させることに役立っています。

完璧ではありません。討論が誤った収束をすることもあり、大きな仕様は依然として難しく、探索的タスクはビルド前に調査が必要なことが多く、コストのオーバーヘッドは現実です。Human-in-the-loopは意図的に維持されます。目的はシステムが常に正しいと装うことではなく、手動の調整を減らし、実際に判断が必要な瞬間に人間を介在させることです。

次のロードマップは、仕様の分割と低リスク変更に対する信頼度ベースの承認に焦点を当てています。速やかな討論収束と明確な検証が可能な場合に自動化の恩恵を受けられるようにすることが目標です。結論は「すべてを自動マージする」ことではありません。価値は受け渡しを減らし、レビューのループを解消し、人間が最終判断に時間を使う前に一貫した技術的挑戦の層を追加することにあります。

より有益な問いは「AIはコードを書けるか？」だけではありません。「AIに自分の作業を証明させ、挑戦を受けさせ、人間が迅速に判断できるだけの証拠を残させるプロセスとは何か？」ということです。我々はその対立する専門的視点を再現可能にし、日常的にコードを出荷するプロセスに統合するためにこのパイプラインを構築しました。