🤖

AIを増やすほど性能が下がる — マルチエージェントの落とし穴

に公開
AI
llm
multiagent
teamdevelopment
idea

「AIエージェントは増やせば増やすほど賢くなる」——そう思っていませんか？

私もそう信じていました。でも最新の研究が、その直感を真っ向から否定しています。

はじめに

2025年12月、Google Research・MIT等の研究チームが発表した論文 "Towards a Science of Scaling Agent Systems"（arXiv: 2512.08296）が、マルチエージェントAIシステムの「不都合な真実」を明らかにしました。

180通りの構成を体系的に評価した結果、逐次的な推論タスクではマルチエージェント構成が単一エージェントより39〜70%も性能を落とすことが示されたのです。

これはマルチエージェント開発に携わるエンジニアにとって、かなり衝撃的なデータです。

論文の概要

この研究では、5つのアーキテクチャを3つのLLMファミリー（OpenAI・Google・Anthropic）で横断的に評価しています。

評価したアーキテクチャ

  • Single Agent（SAS）: 1つのエージェントがすべてを逐次処理
  • Independent: 複数エージェントが独立に並列処理し、最後に集約
  • Centralized: オーケストレーターがワーカーに指示を出す
  • Decentralized: エージェント同士がP2Pで直接やりとり
  • Hybrid: 上記の組み合わせ

3つの重要な発見

論文が示した主要な知見は以下の3つです。

① ツール協調トレードオフ
固定の計算予算下では、ツールを多用するタスクほどマルチエージェントのオーバーヘッドが重くのしかかります。エージェント間の調整コストがツール呼び出しと競合するためです。

② 能力飽和
単一エージェントの精度が約45%を超えると、エージェントを追加しても効果がなくなり、むしろ悪化する傾向があります（β = -0.404, p < 0.001）。これは強力なモデルほど「チーム」が邪魔になるという、直感に反する結果です。

③ エラー増幅
Independent構成（各エージェントが独立に動く）ではエラーが17.2倍に増幅されます。一方、Centralized構成なら4.4倍に抑えられます。つまり、アーキテクチャの選択でエラー伝播が4倍近く変わるのです。

数字で見るインパクト

特に印象的なのが、タスクの性質によるパフォーマンス差です。

タスク種別 MASの効果
並列化可能（金融分析など） Centralized構成で +80.8% 向上
動的Webナビゲーション Decentralized構成で +9.2% 向上
逐次的推論 全MAS構成で -39〜-70% 悪化

並列化できるタスクでは劇的に効く。でも逐次的な推論タスクでは全滅。

これ、マルチエージェントをワンパターンで適用しているプロジェクトには致命的なデータではないでしょうか。

実体験：複数LLMで議論させてみた結果

実は私自身、この論文が指摘する現象を身をもって体験しています。

以前、Gemini・Claude・Codex・Kimi・Mistralなど複数のLLMを使って、マルチエージェント的な構成でさまざまな事象について議論させていた時期がありました。ビジネス戦略の検討、技術選定の比較、投資判断の材料集め——「複数のAIに意見を出させて、多角的な視点を得よう」という狙いです。

最初は確かに面白かった。各モデルの個性が出て、Claudeは慎重に構造化した回答を返し、Geminiは幅広い視点を提示し、Mistralはヨーロッパ的な視点を混ぜてくる。しかし、議論をまとめようとした瞬間に問題が起きました。

  • 各モデルの意見が微妙に矛盾して、統合するのに余計な時間がかかる
  • 「どのモデルの意見を信じるか」という判断が結局人間に戻ってくる
  • 最終的に、一番優秀なモデル1つに深く聞いた方が速くて質が高いという結論に至った

これ、まさに論文の「能力飽和」と「妥協案への収束」そのものです。優秀なモデル単体の精度が十分に高い場合、複数を混ぜると専門性が希釈されて中途半端な結論に陥る。

この経験を経て、今は用途によってモデルを使い分ける（コード生成はClaude、リサーチはGemini、など）スタイルに落ち着いています。全員で議論させるのではなく、タスクに最適な専門家を1人選ぶ。これも論文の教訓と一致する結論でした。

チーム開発PMとしての既視感

そしてもう一つ、PM経験を通じて「人間のチーム」でもまったく同じ現象を見てきました。

  • 少人数の精鋭チームの方がスピードも品質も高い
  • 人数を増やすと合意形成のコストが指数的に増える
  • 「妥協案」に収束して、誰もが微妙に不満な結果になる

AIエージェントでもこれが再現されるのは、ある意味で当然かもしれません。マルチエージェントシステムはいわば「AIのチーム開発」です。人間のチームと同じく、ただ人数を増やすだけでは機能しないのです。

ソフトウェア開発の世界には「ブルックスの法則」——遅れているプロジェクトに人を追加するとさらに遅れる——がありますが、マルチエージェントAIにも同じ法則が成り立つと言えるでしょう。

実務への示唆：どう設計すべきか

この論文から得られる実務的な教訓をまとめます。

1. まず単一エージェントで限界を見極める

いきなりマルチエージェント構成にせず、単一エージェントでどこまでいけるか検証しましょう。精度45%を超えているなら、エージェントを増やすよりプロンプトやツールの改善に投資する方が効果的です。

2. タスクの並列性を分析する

  • 並列化できるタスク → Centralized構成が有効
  • 動的に変化するタスク → Decentralized構成が有効
  • 逐次推論が必要なタスク → 単一エージェントの方が良い

3. エラー伝播を意識したアーキテクチャ選択

Independent構成は一見シンプルですが、エラー増幅が最も大きくなります。品質が重要な場面では、オーケストレーターを置くCentralized構成の方が安全です。

4. 人間がワークフローを設計する

UC Berkeleyの実態調査（2025年12月）でも、成功している本番デプロイの80%は人間が設計した構造化ワークフローを使っていることが報告されています。AIに自律的に計画させるのではなく、人間がフローを設計し、AIがその中で力を発揮する——この分業が現時点では最も効果的です。

業界の動き：各社のマルチエージェント戦略

この論文の知見は、業界のトッププレイヤーたちの動きとも深く関連しています。

Anthropicのオーケストレーター設計

Anthropicは自社のマルチエージェント設計でオーケストレーター・ワーカーパターンを明確に採用しています。

Research機能の技術解説によると、リードエージェント（オーケストレーター）が調査計画を立て、専門化されたサブエージェントに並列で情報収集を委託する構成です。さらにClaude Code Agent Teamsでは、チームリードが作業を調整し、各メンバーが独立したコンテキストウィンドウで並列作業できる仕組みが導入されました。

公式ドキュメントでも「Agent teams add coordination overhead（チームは調整コストを増やす）」と明記されており、リサーチや並列探索など、並列性が活きるタスクに限定して使うことが推奨されています。論文の知見と完全に一致する設計思想です。

Sam Altmanの「マルチエージェント宣言」

OpenAIのSam Altmanも最近、「未来は極めてマルチエージェント的になる（The future is going to be extremely multi-agent）」 とXで発言し、OpenClawの創業者をOpenAIに招聘してパーソナルエージェント開発を加速させています。

業界として「マルチエージェント」が次のフロンティアであることは共通認識ですが、重要なのは**「ただ増やす」のではなく「いかに設計するか」**というこの論文の教訓です。

関連技術：MoEとの類似性

余談ですが、LLMの内部アーキテクチャにも似た発想があります。Mixture of Experts（MoE） は、モデル内の全パラメータを使うのではなく、入力に応じて専門化されたサブネットワーク（Expert）を選択的に活性化する手法です。GPT-4やMistralのMixtralなどで採用されています。

MoEの設計思想は「全員で議論する」のではなく「適切な専門家を選んで任せる」こと。これはまさに、この論文が示すマルチエージェントの教訓と同じ構造です。タスクに合った専門家を、必要な分だけ使う——モデルの内部もエージェントの外部も、スケーリングの原則は共通しているのかもしれません。

MoEやマルチエージェント構成の詳しい技術比較については、別の記事で掘り下げたいと思います。

おわりに

「マルチエージェント」という言葉の響きには、なんとなく「高性能」「先進的」というイメージがあります。しかし実際は、適切に設計されていないマルチエージェントシステムは、優秀な単一エージェントに劣るというのが研究の示す事実です。

これは人間のチーム開発の教訓とも完全に一致します。大事なのは人数ではなく、役割設計・ワークフロー・タスクとの適合性です。

AnthropicもOpenAIも、マルチエージェントを次のフロンティアと位置づけています。しかしその設計において「どこを並列化し、どこを逐次処理にするか」を人間が判断することが成功の鍵である——この論文はその判断基準を定量的に示してくれました。

皆さんはマルチエージェント設計で、どんな工夫をしていますか？「単一エージェントの方が良かった」という経験がある方も、ぜひコメントで教えてください。

参考文献

GitHubで編集を提案

Discussion