AIエージェント

マルチエージェントは本当に効くか：同じ計算量の単体との比較

2026/8/2 （更新: 2026/10/11）

🤖 AIを使用して執筆

増やすと効く、確かな事例

まず、マルチエージェントが本当に効く事例を見る。

もっとも分かりやすいのは Mixture-of-Agents（MoA）だ¹。複数のLLMを層状に重ね、各層が前の層の出力を全部受け取って改良する。オープンソースのモデルだけで組んだMoAが、AlpacaEval 2.0で 65.1% を出し、GPT-4 Omniの57.5%を上回った。ただし読み方に注意が二つ要る。第一に、AlpacaEval 2.0が測るのは推論の正解率ではなく、GPT-4系の評価器が回答を見比べて付ける長さ補正済みの選好勝率だ（詳細は脚注¹）。第二に、この65.1%は6モデル×3層の構成で、1問あたり13回のモデル呼び出し（6提案＋6提案＋最終層の集約1回）を要する。GPT-4oの1回の呼び出しとは計算量が桁違いに大きい。

土俵を近づけた数字は著者ら自身が出している。2層の MoA-Lite は、GPT-4oと同等のコストで 59.3%（GPT-4 Omniは57.5%）を出した。原典のコスト分析は、GPT-4o との対比では同額での上回りとして書いている（GPT-4 Turbo との対比では逐語 more than twice as cost-effective と、2倍のコスト効率も掲げる）¹。同じ費用で単体の最強モデルを上回るという、より公平な証拠である。ただし揃えたのは費用であって計算量ではない。MoA-Liteも1問あたり7回の呼び出し（6提案＋集約1回）を重ねており、トークン単価が低いので費用が並ぶ、という話である。

設計次第だ、という点を示すのが MASS（Google/Cambridge）だ²。多エージェント系を①ブロック単位のプロンプト最適化→②トポロジー（つなぎ方）最適化→③全体のプロンプト最適化、と段階的に詰める。著者らは、素朴に数を増やすだけでは伸びず、プロンプトとトポロジーを一緒に最適化して初めて既存手法を大きく上回る、と報告する。Gemini-1.5-proでの8タスク平均（各3回実行）は、MASSが 78.79、多エージェント議論が70.26、ADASが69.72、単発のCoTが65.28だった。「並べれば勝つ」のではなく「設計すれば勝つ」のだ。

このMASSの数字も、コストの側から読んでおく。1クエリあたりの推論コストで大きく負けているわけではない。ただし著者らの言い方は「揃えた」ではなく同水準（a comparable inference cost per query）である。Table 7 では MASS $0.0014／クエリに対し ADAS $0.0016、多エージェント議論 $0.0012 と近いが、Self-Refine は $0.0004 でMASS は 3.5 倍、そして CoT はこの表に載っていない。同じ頁の図（Figure 9、Gemini-1.5-pro の MATH、入出力の合計トークン）から目で読むと、CoT は約600トークン、MASS は最も安い構成でも約1,700トークンで、およそ3倍を使っている。成績のほうは、MATH で MASS が84.67%、ADAS が80.00%だった（この2つは Gemini-1.5-pro の値で、上のコスト表は flash の MATH である。コスト統制の根拠と成績の条件は別である）。ただしMASSには推論とは別に探索・最適化の費用がかかる（24M/11Mトークン＝約5ドル）。ADASなど自動設計手法とは同水準だが、いま並べたCoTや多エージェント議論はそもそも探索をしないので、この費用がゼロだ。勘定に入れる範囲を変えれば順位も変わる。次節で持ち出す物差しは、ここでも同じように効く。

古典的には、複数のLLMに数ラウンド議論させると、事実性と、算術・数学・戦略推論の精度が上がるという報告がある³。ただし実験は2023年当時のChatGPT系モデルで、タスクは計6種。推論を測った3種と事実性を測った3種は別なので、事実性の主張を推論タスクの数字で読まないこと（内訳は脚注³）。単純に多数サンプリングして投票するだけでも、エージェント数に応じて性能が伸びるという報告もある⁴。ただし「難しいタスクほど伸びる」と単調に読んではいけない。著者らは難度を三つの軸に切り分けた実験で、内在的な難度に対する伸び幅は増えてから減ると結論している（Gains increase then decrease by rising the inherent difficulty）。難度が上がりきるとモデルの推論能力を超え、増やしても利得は先細りする。実タスクの側で著者らが測っているのはモデルとタスクの難度差で、同じMATHでも相対利得は弱いLlama2-13Bの200%に対しGPT-3.5-Turboでは34%である。これは出発点に対する比で、MATHの正答率はLlama2-13Bが3%から9%へ、GPT-3.5-Turboが29%から39%へ上がっており、伸びた幅は強いモデルのほうが大きい。増やすことには、確かに効く場面がある。

だが、計算量を揃えると話が変わる

ここに落とし穴がある。多くの比較は、多エージェントが余分に使った推論計算を勘定に入れていない。つまり「多エージェントが勝った」は、「たくさん考えさせたから勝った」と区別がついていないことが多い。この混同を、情報理論の裏づけと評価手続きまで詰めて測り直したのが、スタンフォード大の研究（査読前のプレプリント）だ⁵。「計算量を揃えると単体が勝つ」こと自体は、先行研究が既に示唆していた。著者らもそう書いている（逐語 Recent budget-aware studies suggest that, when computation is normalized, many such strategies underperform strong single-agent baselines）。彼らが自分の寄与に置いたのは、理論と方法論の側である。思考トークンの予算を100・500・1k・2k・5k・10kの6水準に固定し、単体エージェントと、5種の多エージェント構成（逐次・サブタスク並列・役割並列・討論・アンサンブル）を同じ予算で比べている。

物差しは FRAMES と MuSiQue（4ホップ）である。前者は検索拡張生成(RAG)の統合評価セットで、事実性・検索・推論を切り離さず、複数の情報源を統合しないと答えが出ない問いで測る⁶。後者は、互いに依存する単ホップの問いを組み合わせて作った2〜4ホップのQAデータセットで、近道で解けないことを設計目標に据えている⁷。どちらも「筋道を継がないと答えが出ない」ことを狙って作られており、多エージェントという構造が多段推論に効くのかを見るには適した土俵だ。ただし担保の強さは同じではない。近道耐性を数値で測って設計目標に据えているのは MuSiQue のほうで、FRAMES が担保するのは「複数記事を使って書かれた問いであること」までだ（要する記事数は2〜15、最頻は2記事で約36%）。現に、検索を一切させないベースラインでも最強のモデルは0.408を当てている。そして MuSiQue については、前段のスタンフォード大の研究の著者ら自身が、原問題に記憶・過学習の疑いがあると付録で報告している⁵。問いを規則で軽く言い換えると成績が下がり、意味を保ったまま深く言い換えると上がった（Gemini-2.5-Flash の単体・1kトークンで 0.331→0.358）。著者らはこの食い違いを根拠に挙げている（逐語 strongly suggests that the original questions may suffer from memorization or overfitting from pretraining）。著者らは要旨でも、ベンチマーク側の癖が多エージェントの見かけの利得を膨らませうると書いている。そして記憶の疑いは土俵の両側にある。FRAMES の著者ら自身も、事前学習データの汚染を Limitations の筆頭に挙げ、成績が artificially inflated になりうると書いている。土俵は適しているが、無傷ではない。逆に言えば、ここで測っているのは文書に対する質問応答であって、ツールを使う長期タスクの成否ではない。

結果の大勢は揃っていた。多段推論タスクで単体エージェントが、要求した同じ予算のもとで、多エージェント系に匹敵または上回った（Qwen3・DeepSeek-R1系・Gemini 2.5の3系統）。著者らは例外を最小の100トークン水準のみと要約する。ただし付録の表を著者ら自身の基準（最高値と95%信頼区間が重なるか）で読み直すと、Gemini-2.5-Pro の MuSiQue では100以外の全水準で、標準の単体が最良の構成に届いていない。そのうえで、差は予算が増えるほど縮む。Table 1 の平均で、単体 対 最良の多エージェント構成は 2000トークンで 0.421 対 0.403、5000で 0.427 対 0.420、10000では 0.426 対 0.423 と 0.003 差まで詰まる。著者らも討論型（Debate）を最も一貫して強い多エージェント構成と名指しし、on Gemini-2.5-Pro MuSiQue it is often the strongest overall MAS architecture と書いている（当該セルでは 0.470 対 単体 0.419）。

ただし Gemini については、thinkingBudget は上限ではなく目安であり、観測トークンでの apples-to-apples な計算比較は intractable だと著者ら自身が書き、消費側の突き合わせは成り立たないと断っている。API の申告値は、高い予算帯ほど可視テキスト換算から離れていく（著者らは API-Reported counts are highly inflated at higher thinking budget と書き、10kトークンを要求した例で4.7倍を挙げる。付録の表には6倍を超えるセルもある）。外に出た思考テキストの長さも揃っていない。同じ要求予算のもとで、逐次型の多エージェントは単体より長い思考テキストを出しており（1k要求時に 693 対 390。語数に 10/7 を掛けた推定トークン）、単体を上回った先の 0.470 のセルでは、討論型が単体の約4.4倍だった（5000トークン要求時に 1,741 対 394）。ただしこれは可視テキストの長さの比であって、実際に使った計算量の比とはみなせない。著者らの intractable は API の申告値だけでなく、この可視テキスト換算（content-based）にも掛かっている。

著者らは単体の優位を情報理論のデータ処理不等式で説明する。固定のトークン予算でコンテキストを完全に使えるなら、単体の方が情報効率がよい。多段推論タスクで報告されてきた多エージェントの優位の多くは、構造の恩恵より、勘定に入れていない追加計算とコンテキスト効果で説明がつく、と著者らは示唆している。

ただし著者らは「単体があらゆる領域で常に優位、というわけではない」とも明記する。モデルが生成した推論の途中経過を、無作為に伏せ字にしたり無関係な語に置き換えたりして人工的に壊す実験がある（逐語 Apply corruption operator T only to the generated think text）。そこでは劣化を強めた α=0.7 の条件で逐次型（Sequential）の多エージェントが単体を逆転した（Qwen3-30B-A3B、MuSiQue 4ホップ、1000トークン固定）。ただし逆転したのは情報を壊す摂動（マスク・置換）だけで、単に消す削除では最重度でも単体が優位に戻り、無関係な文を足すだけの摂動では単体が終始優位だった。著者らの結論はこうだ。多エージェントが最も助けになるのは、単にコンテキストが長いときではなく、一本の推論の筋道では関連する情報と誤導する情報を見分けにくくなったときである。要旨はこの条件を、単体がコンテキストを実際に使いこなせなくなったときと言い表し、それと並べて、多エージェントがより多くの計算を使うときにも競り合えるようになると書いている。

ツールを使うタスクについては、外部の環境と何手もやり取りするエージェント型のタスク6種で、ツール・プロンプト・計算量を揃えて単体と4種の多エージェント構成を比べた Google と MIT の研究（査読前のプレプリント）がある⁸。単体に対する性能の変化は、分解できる金融推論の +80.8% から逐次の計画の −70.0% まで開いた。6種のタスクと4構成を平均した変化は −0.3%（95%信頼区間 −58.7%〜+77.2%）で、著者らは多エージェントに普遍的な利得は無く、成否を分けるのは構造とタスクの噛み合わせだとする。著者らの回帰では、単体の正答率がすでに45%を超えるタスクで、エージェントを足した見返りが負になった。

失敗の正体は、モデルでなく「設計」

では、マルチエージェントが失敗するとき、何が壊れているのか。UC Berkeleyの研究「Why Do Multi-Agent LLM Systems Fail?」⁹が、7つの主要フレームワークの実行トレースを注釈し、失敗を体系化した（MAST：14の失敗モードを3カテゴリに整理）。注釈の規模は、人手が5フレームワークの150トレース超（うち3名で反復ラベリングした15トレースで注釈者間一致 kappa=0.88）、これをLLM注釈器（o1、人手との一致 kappa=0.77／正解率94%）で1,642件（MAST-Data）に広げている。

肝心なのは内訳だ。この1,642件で、失敗の最多はシステム設計の問題（タスクや役割の仕様からの逸脱、会話履歴の喪失、終了条件の無自覚など）で44.2%、次いでエージェント間の不整合（すれ違い・情報共有の失敗）が32.3%、いわゆる「検証の失敗」は23.5%だった。著者らはこの分布を、役割の切り方・つなぎ方・情報の受け渡しの側、すなわち個々のエージェントの能力の限界というより組織設計と調整の問題として読む。ただし著者ら自身の介入実験では、同じモデルのまま系の作りとプロンプトを変えて改善は最大15.6%にとどまり、著者らは「完了率は依然として低い」と書く。設計は効き所だが、そこを直せば済む規模の話ではない。

ただし、失敗の分布はシステムごとにもモデルごとにも大きく異なる。著者らは同じMetaGPTフレームワーク上でも、設計起因の失敗（上の「システム設計の問題」）がGPT-4oではClaude 3.7 Sonnetより39%少なかったと報告する。ただしこれはプログラミングタスク上の比較で、かつ著者らはGPT-4o が総合成績でも上回ると併記している。モデルを替えれば失敗の量も内訳も動く。著者らはシステムごとの失敗プロファイルを並べたうえで、「万能の解はない（no one-size-fits-all）」と観察している（結論部ではなく、失敗分析の節での所見である）。

議論（ディベート）にも固有の罠がある。ある研究¹⁰は、3体のうち2体を強いほうのモデルにしてもラウンドを重ねるほど精度が下がりうることを示した（GPT-4o-mini と 7〜8B のオープンモデルを混ぜた構成、各タスク100問×5シード）。モデルは仲間の推論に触れると、誤りを指摘するより同調してしまい、正解から不正解へ翻る。増やした対話が、むしろ誤りを伝播させる。

現場の声も同じ方向を指す。Devinを作るCognitionは、2025年6月の「マルチエージェントを作るな」と題した実践記で¹¹、並列サブエージェントはコンテキストが分断されるため脆いと論じた。あるサブエージェントがゲーム背景を作り、別のサブエージェントが噛み合わない素材を作る。互いの暗黙の判断を共有しないからだ。彼らが挙げる原則は二つ。①個々のメッセージだけでなく、エージェントの軌跡（trace）ごとコンテキストを共有せよ。②行動には暗黙の判断が伴い、判断が食い違えば結果も壊れる。原典は、単線の（線形の）エージェントを原則そのものではなく、この二つを最も単純に満たす設計例として示している。

この実践記には続きがある。同じ著者は10か月後（2026年4月）に、書き込みは単線に保ち、増やしたエージェントには行動でなく知能を足させるという条件つきで効く型を見つけたと報告した¹²。コンテキストを共有しない別のレビュー役にコードを見せる、管理役が仕事を分割して子エージェントに投げ結果を統合する、といった形である。ただし後者を、原典は「Looking Ahead」の節に置いている。Devinでは既に稼働しているが（This is live in Devin today）、著者ら自身は we're still improving on all of them と書く。単一エージェント並みの一貫性をどう出すかを at the center of some of our upcoming work in 2026 に置いており、レビュー役ループほど固まってはいない、という程度に読むのがよい。一方で並列に書き込むエージェント群については「当初の観察は今も成り立つ」としている。著者は禁止を撤回したのではなく、効く条件を絞り込んだ。この型は、書き込みを一本に保つことで原則②（判断の食い違い）を回避している。

なお、原則①の「コンテキストを共有せよ」はエージェント間で何を渡すかの話だ。一つのエージェントの中で履歴をどこまで刈り込むか、という話とは層が違う（もっとも原典は、原則①を制約しているのはコンテキスト長そのものだとし、その解として単体エージェント内の履歴圧縮を地続きに置いている）。

多エージェントを製品に入れた側の記録もある。Anthropic は自社の調査機能について、主エージェント（Claude Opus 4）が調べものを複数のサブエージェント（Claude Sonnet 4）に割り振る構成が、単体の Claude Opus 4 を社内の評価で90.2%上回ったと報告した¹³。同じ記事は、多エージェント系が効くのは主に、問題を解くのに十分なトークンを使えるからだと書く。ウェブ閲覧の評価（BrowseComp）では、性能の分散の80%がトークン使用量だけで説明できた。Anthropic はこの結果を、別々のコンテキストウィンドウに仕事を分けて考える容量を足す設計の裏づけとも読み、多エージェント系は通常の対話の約15倍のトークンを使うと認めている。一方で、全エージェントが同じコンテキストを共有する必要のある領域や、エージェント間の依存が多い領域は今のところ向かないとし、例としてコーディングは調査より本当に並列化できる部分が少ないと挙げる。LLM のエージェントは、実時間で互いに仕事を調整し割り振ることもまだ得意ではない、とも書いている。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。