複数AIを協調させると賢くなる、はコストが4〜15倍という代償の上に成り立つという話

複数のAIモデルやエージェントに役割を分担させ、互いのやり取りを通じて単体より良い結果を得ようとする方式を、マルチエージェントと呼ぶ。この方式には、学術研究と業界フレームワークの双方に確立した手法があり、Anthropic自身もClaude Codeの中で実装として使っている。

本稿では、討論を基盤にした学術研究の系譜、役割分担を軸にした業界フレームワークの設計、Anthropicが自社のResearch機能とClaude Codeで実際に使っている構成を順に見て、最後に協調の実装パターンとコスト構造を整理する。

エージェント同士を討論させる学術研究

基盤になっているのはマルチエージェント討論(Du et al.、arXiv:2305.14325、ICML 2024)である。 3体程度のエージェントがまず個別に回答と推論過程を生成する。次に各エージェントが他のエージェント全員の回答を読んで批判し、それを踏まえて自分の答えを更新する。これを2ラウンド程度繰り返し、討論は基本的に収束によって1つの答えに至る。算術問題では単体67.0%が討論後81.8%に、GSM8Kでは77.0%が85.0%に上がったと報告されている(論文Table 1、標準偏差付き)。

この基盤研究に対して、MAD(Liang et al.、arXiv:2305.19118、EMNLP 2024)は非対称な役割設計をとる。討論者同士をtit-for-tat(やられたらやり返す)形式で対立させ、別の判定役エージェントが議論を管理して最終解を出す。出発点にあるのは、一度自分の解に確信を持ったLLMは、その後の内省だけでは考えを変えられなくなるという指摘である(論文では「Degeneration-of-Thought」と呼ぶ)。

討論そのものではないが、同じ系譜に属する隣接手法もある。 Self-Consistency(Wang et al.、arXiv:2203.11171、ICLR 2023)は単一モデルから複数の推論経路をサンプリングし、多数決で答えを決める。討論はしない。 Self-Refine(Madaan et al.、arXiv:2303.17651、NeurIPS 2023)は1つのモデルが生成、批評、修正の3役を兼ね、自己フィードバックで反復修正する。 Reflexion(Shinn et al.、arXiv:2303.11366、NeurIPS 2023)は実行後のフィードバックに言葉で自己反省し、その反省文をメモリに蓄積して次の試行で参照する。いずれもエージェントは1体である。

討論の効果には懐疑的な検証もある。 Wang et al.(arXiv:2402.18272、ACL 2024)は、例示を含む強いプロンプトを与えた単一エージェントが、既存の最良の討論手法とほぼ同等の性能を出すと報告した。討論が優位なのは、プロンプトに例示がない場合に限られるという分析である。

役割分担で協調させる業界フレームワーク

AutoGen(Microsoft)は「会話」を基盤に据えた汎用フレームワークである。固定の役職テンプレートを持たず、汎用のConversableAgentに自由に役割を定義して組む。発話順はGroupChatのマネージャーが選ぶ方式が主流だが、2026年初頭にメンテナンスモードに入り、公式README上で後継のMicrosoft Agent Frameworkへの移行が推奨されている。

CrewAIは役職ベースの設計をとる。各エージェントをrole、goal、backstoryの3属性で定義し、自律的な委譲を行うCrewか、実行パスを明示制御するFlowとして動かす。導入の速さが利点で、GitHub star 54.9k超(2026年7月時点)のコミュニティを持つ一方、条件分岐やループなど細かい制御は効きにくい。

MetaGPT(arXiv:2308.00352、ICLR 2024 Oral採択)はソフトウェア企業の組織を模倣する。 Product Manager、Architect、Engineer、QA Engineerなどの役職に、人間の業務手順(SOP)をプロンプト列としてエンコードする。通信は共有メッセージプールへのpublish-subscribeで行い、各エージェントは自分の役割に関係するメッセージだけを購読する。全員が全員と直接会話する構成で起きる情報過多を、この購読フィルタで避ける設計である。

ChatDevは仮想ソフトウェア企業をウォーターフォールで回す。設計からテストまでの各工程をChatChainという逐次構造で処理し、2エージェントの多ターン対話(programmerとreviewerなど)に分解して、相互レビューで検証済みの成果物だけを次工程に渡す。 2026年1月、ChatDev 2.0ではDAGベースの汎用マルチエージェント基盤へ路線転換しており、開発特化ツールとしての性格は薄れた。

LangGraph(LangChain)はグラフ構造でエージェントをつなぐ。 Supervisor(中央管理)、Swarm(エージェント間の直接ハンドオフ)、Network(多対多)、Hierarchical(入れ子のsupervisor)の4パターンを提供し、チェックポイントによる状態復旧が本番運用向けに成熟している。主要フレームワークの中では学習曲線が最も急という評価が複数の第三者比較記事で共通しているが、これはLangChain公式の自己評価ではなく、業界レビュー記事の傾向である。

Anthropic自身がすでに使っている実例

Anthropicは商用のResearch機能として、オーケストレーター1体とサブエージェント複数からなる構成を公開している(エンジニアリングブログ「How we built our multi-agent research system」)。 LeadResearcherがユーザーのクエリを分析して調査戦略を立て、クエリの複雑度に応じて3〜5体程度(単純な事実確認は1体、複雑な調査では10体を超えることもある)のサブエージェントを並列生成する。各サブエージェントが独立にウェブ検索と評価を行い、リードが結果を統合して追加調査の要否を判断し、最後にCitationAgentが各主張に出典を付与する。 Opus 4をリード、Sonnet 4をサブエージェントとする構成は、単体のOpus 4を内部評価で90.2%上回った。

ただし、この性能差の大半はトークン投入量の増加で説明できるとAnthropicは分析している。 BrowseComp評価では性能分散の80%をトークン使用量が占め、残りをツール呼び出し数とモデル選択が占める。コストも相応で、エージェントは通常チャットの約4倍、マルチエージェント構成は約15倍のトークンを消費する。

Anthropic自身が、マルチエージェント化に不向きな領域を明言している。全エージェントで同じ文脈の共有が必須のタスクと、エージェント間の依存が多い領域であり、後者の代表例として「ほとんどのコーディングタスク」が挙げられている。

このオーケストレーターワーカー構成は、いま使っているClaude Codeの中にもそのまま実装されている。サブエージェント(Agentツール)は独立したコンテキストウィンドウで動作し、結果の要約だけがメイン会話に戻る。 Agent Teams(実験的機能)は、独立したClaude Codeインスタンス同士が共有タスクリストとメッセージ機能で自己調整する点がサブエージェントと違う。サブエージェントがリードへの一方向報告であるのに対し、チームメイト同士は直接やり取りする。 Dynamic workflowsは、Claudeが書いたJavaScriptスクリプトをランタイムが解釈してサブエージェント群をオーケストレーションする仕組みで、ループや分岐、中間結果はスクリプト側の変数に保持され、Claudeのコンテキストには最終結果だけが入る。 3機構を分けているのは、計画を誰が保持するかという軸である。サブエージェントとAgent TeamsではClaude自身がターンごとに次の手を判断するが、Dynamic workflowsではスクリプトが判断する。

話し合いを実装する六つのパターン

学術研究と業界フレームワークに共通する実装パターンは、次の六つに整理できる。

オーケストレーターワーカー方式は、中央のリードがタスクを分解してワーカーに配り、結果を統合する。ワーカーは互いを知らない。独立に並列探索できるリサーチに向き、実務でよく使われる構成とされる。統合ステップが難所で、1体の誤出力を下流が正として扱う「幻覚カスケード」のリスクがある。

ブラックボード方式は、エージェントが直接通信せず、共有データ構造への読み書きだけで協調する。次に動くエージェントは制御部が盤面の状態から決める。 1970年代の音声認識システムHearsay-IIが起源で、部分解を段階的に積み上げる問題に向く。

討論方式は、各エージェントが個別回答を出し、互いの回答を批判しながら複数ラウンド繰り返す。多様な視点の統合に向くが、同質のモデルと似たプロンプトで構成すると回答の独立性が薄れ、討論が形骸化しやすい。

投票によるコンセンサス形成は、多数決、判定役モデルへの一任、信頼度で重み付けした投票などで最終解を決める。分類のような離散的な出力に向く。ただし、意見の割れた設問では討議を重ねても誤った合意に収束することがあり、慎重な設計が要る。

批評ループは、生成、評価、修正のサイクルを、合格基準の達成か回数上限まで繰り返す。テスト実行のような明確な合格基準があるタスクに向くが、エージェントが自分の出力を自分で評価すると自己肯定に流れやすい(コヒーレンストラップ)。外部テストや別エージェントによる採点で接地しない自己批評は機能しにくい。

fan-out/fan-in方式は、並列に作業を分配し、各エージェントが独立に完了した後で結果を統合する。サブタスク間の独立性が高い問題に向く。

コストと向き不向き

マルチエージェント化の効果の主因は、独立した試行の数を増やすこと、つまりトークン投入量の増加にある。コストは必ず増え、通常チャットの4倍から15倍のトークンを消費する。向くのは、高価値で並列化でき、単一コンテキストに収まらない情報量を扱うタスクである。討論や投票の理論的な支えである回答の独立性も、同系統のモデルを並べた構成では成り立ちにくい。

まとめ

マルチエージェント討論(Du et al.)は個別回答の相互批判を2ラウンド程度繰り返し、収束によって1つの答えに至る設計で、算術問題やGSM8Kで単体より高い正答率を報告している。
MADは討論者を対立させ判定役が管理する非対称設計であり、Self-Consistency、Self-Refine、Reflexionは討論を伴わない単一エージェントの手法で、系譜は同じでも仕組みは異なる。
強いプロンプトを与えた単一エージェントが既存の最良の討論手法に匹敵するという懐疑的な検証もあり、討論の優位はプロンプトに例示がない場合に限られるという分析がある。
AutoGen、CrewAI、MetaGPT、ChatDev、LangGraphはそれぞれ異なる協調モデル(会話ベース、役職ベース、SOPと購読フィルタ、ウォーターフォール、グラフ構造)を採用しており、AutoGenは後継フレームワークへの移行が進み、ChatDevも汎用基盤へ路線転換した。
AnthropicのResearch機能はオーケストレーター1体とサブエージェント複数の構成で、性能向上の大半はトークン投入量の増加で説明でき、コストは通常チャットの4倍から15倍にのぼる。
Anthropicは、全エージェントでの文脈共有が必須のタスクや依存の多い領域(代表例が「ほとんどのコーディングタスク」)をマルチエージェント化に不向きと明言している。
Claude Codeにはサブエージェント、Agent Teams、Dynamic workflowsの3機構があり、計画をClaudeが持つかスクリプトが持つかで区別される。
協調の実装パターンはオーケストレーターワーカー、ブラックボード、討論、投票によるコンセンサス形成、批評ループ、fan-out/fan-inの六つに整理でき、それぞれ向くタスクの形が異なる。

Claude Codeに「AI同士が直接やり取りする」機能が追加されたという話題（投稿より）