【2026年最新】マルチエージェントの協調×論文4選｜「エージェントを増やしたのに精度が上がらない」を解く

【2026年最新】マルチエージェントの協調×論文4選｜「エージェントを増やしたのに精度が上がらない」を解く AIエージェント
2026.09.26

計画役・実行役・レビュー役のように、複数のAIエージェントに役割を分担させる「マルチエージェント」構成が人気を集めています。人間のチームのように分業させれば、より難しい仕事もこなせるはずだという期待があります。

ところが現場では、「エージェントを増やしたのに成果がほとんど変わらない」「どこで失敗したのか追いかけられない」「APIの呼び出し回数だけが増えて費用がかさむ」といった声がよく聞かれます。

この記事では、各社の公式ドキュメントやエンジニアリングブログをもとにマルチエージェントの基本と使いどころを整理し、「なぜ失敗するのか、本当に単体より良いのか」を扱った論文4本を紹介します。結論を先に言うと、まず強い単体エージェントを作り、増やすときは同じコストで比べ、協力の手順と失敗の記録を設計に組み込むのが基本です！

マルチエージェントとは何か：複数のエージェントで仕事を分ける構成

エージェントと「複数のエージェント」

Anthropic は、エージェントを「LLMがツールを使いながら、自分で手順を決めて繰り返し動くもの」と説明し、マルチエージェントを「そうしたエージェントが複数で協力して動くシステム」と定義しています。同社はあわせて、あらかじめコードで決めた経路でLLMを呼ぶ「ワークフロー」と、LLM自身が進め方を決める「エージェント」を区別しています（Anthropic「How we built our multi-agent research system」、Anthropic「Building effective agents」）。

よくある3つの構成

各社の資料に出てくる構成は、おおむね次の3つに整理できます。

構成仕組み各社の資料での呼び名
役割分担型決まった順に作業を受け渡す、または得意な相手に仕事を引き継ぐ逐次（sequential）、引き継ぎ（handoff）、分散型
オーケストレーター型中心のエージェントが仕事を分けて配り、結果をまとめるorchestrator-workers、マネージャー型
議論型複数のエージェントが同じ会話に参加し、提案と検証を繰り返すグループチャット、作成者と確認者のループ

OpenAI のガイドは、中心の「マネージャー」が専門エージェントをツールとして呼ぶ型と、対等なエージェント同士が仕事を引き継ぐ分散型の2つを挙げています（OpenAI「A practical guide to building agents」）。Anthropic の調査機能は、主役のエージェントが計画を立て、3〜5体の下位エージェントを並行して走らせるオーケストレーター型です。Microsoft の設計ガイドは、議論型（グループチャット）には別名として「マルチエージェント・ディベート」もあると説明し、会話の制御を保つために参加するエージェントを3体以下に抑えることを勧めています（Microsoft「AI agent orchestration patterns」）。

単一エージェントとの使い分けとコスト

各社とも「まず単体」を勧めている

OpenAI のガイドの基本方針は、まず単体のエージェントの能力を最大限に引き出すことです。分けるのは、条件分岐の多い複雑な指示を扱いきれないときや、似たツールが多すぎて選び間違えるときとしています。Microsoft も、ツールを持つ単体のエージェントを「企業での用途では多くの場合、妥当な既定の選択」とし、複数にするのは単体では確実に処理できない理由があるときだと書いています。Anthropic も、必要になるまで複雑にしないよう勧めています。単体のエージェントの作り込みはエージェント・ハーネスの記事で扱っています。

増やすほどトークンが増える

Anthropic の社内データでは、エージェントは通常のチャットのおよそ4倍、マルチエージェントはおよそ15倍のトークンを使います。同社の社内評価では、マルチエージェント構成が単体の Claude Opus 4 を90.2%上回った一方、Web閲覧の評価（BrowseComp）で成績のばらつきの80%はトークンの使用量だけで説明できたとも述べています。つまり、性能の上積みの多くは「多くの計算を使えたこと」から来ている可能性があります。同社は、並行して進められ、価値が費用に見合う調査のような仕事に向き、多くのコーディング作業のように依存関係の多い仕事には今のところ向かないとしています（Anthropic「How we built our multi-agent research system」）。Microsoft も、エージェントごとに作業の難しさに合ったモデルを割り当てることを勧めています。モデルの使い分けによる費用の下げ方は推論コストの記事で詳しく扱っています。

研究で見る「なぜ失敗し、どこで失敗したか」

📄 論文: 失敗は「設計」「すれ違い」「検証不足」の3系統に分かれる

Why Do Multi-Agent LLM Systems Fail?（Mert Cemri ほか、2025年3月投稿・10月改訂、arXiv:2503.13657）は、査読前の論文（プレプリント）です。

対象は、公開されている7つのマルチエージェントの枠組み（MetaGPT、ChatDev など）を、プログラミング・数学・汎用タスクで動かした実行記録です。まず専門家が150件超の記録を読んで失敗の型を洗い出し、3人の注釈者で定義を詰めて一致度（κ=0.88）を確かめました。そのうえでLLMを使った自動分類で、1,642件の記録に失敗の型を付けています。

結果、失敗は14の型に分かれ、「システム設計の問題（指示や役割に従わない、同じ手順の繰り返しなど）」「エージェント間のすれ違い（確認せずに思い込みで進む、情報を渡さないなど）」「タスクの検証（早すぎる終了、検証の不足や誤り）」の3系統にまとまりました。検証役を持つ枠組みは失敗が少ない傾向がありましたが、検証役がいてもコンパイルが通るかだけを見るような表面的な確認にとどまる例も多く見られました。付録では役割の指示や構成を見直す改善も試していますが、ChatDev での改善は大きなものではなかったと著者ら自身が述べています。

運営者にとっての意味は、失敗を「モデルが弱いから」で片付けず、設計・受け渡し・検証のどこで起きたかを分けて見られるということです。

📄 論文: どのエージェントのどのステップが悪かったかは、自動ではまだ特定しにくい

Which Agent Causes Task Failures and When? On Automated Failure Attribution of LLM Multi-Agent Systems（Shaokun Zhang ほか、2025年4月投稿・6月改訂、arXiv:2505.00212）は、査読前の論文（プレプリント）です。

対象は、Web検索などを伴う質問集（GAIA、AssistantBench）を解かせた127のマルチエージェントシステムの失敗記録です。自動生成した構成（GPT-4o で動作）と、人が作り込んだ構成（Magentic-One）の両方を含みます。人が「原因のエージェント」と「決定的な誤りのステップ」を注釈したデータセット（Who&When）を作り、主に GPT-4o に記録を読ませて当てさせました。

記録を一度に全部読ませる方法は、原因のエージェントを当てるのが最も得意で、正答率は平均53.5%でした。一方、誤りのステップを当てるのは1ステップずつ判定させる方法が最も得意でしたが、それでも平均14.2%にとどまりました。どちらも GPT-4o での、正解の有無と構成の種類をまたいだ4条件の平均です。ランダムより平均で悪かったのは、一度に全部読ませる方法でステップを当てる場合で、エージェントを当てる場合はどの方法もランダムを上回っています。人が作り込んだ構成の記録で OpenAI o1 や DeepSeek R1 に替えて試しても、GPT-4o を一貫して上回ることはありませんでした。

運営者にとっての意味は、失敗の原因探しをまだAIに任せきれないということです。人が後から追えるよう、記録の残し方を最初から決めておく必要があります。

研究で見る「協力するか、本当に単体より良いか」

📄 論文: 賢いモデルほど協力的とは限らない

More Capable, Less Cooperative? When LLMs Fail At Zero-Cost Collaboration（Advait Yadav ほか、2026年4月投稿・6月改訂、arXiv:2604.07821）は、ICML 2026 採録（abs のコメント欄の記載）です。

対象は、実際の業務ではなく著者らが作った模擬環境です。10体のエージェント（すべて同じモデル）が20ラウンドにわたり、他のエージェントが持つ情報を集めてタスクを完了させます。情報を渡しても渡した側は何も失わず、全員に「システム全体の収益を最大化し、協力せよ」と同じ指示を与えています。8つのLLMで各5回ずつ試しました。

最適な動きをした場合と比べると、OpenAI o3 は17%しか達成できず、より小型の o3-mini は50%に達しました。一般的な性能の高さと、この環境での成果には相関が見られませんでした。一部のモデルは、渡しても損をしないのに、求められた情報を渡しませんでした。対策の効き方はモデルで分かれ、「必要な情報を求め、求められたら渡し、そろったらすぐ提出する」という手順を明示すると、手際の悪さで失敗していたモデルの一部は成果がおよそ2倍になりました。協力しないことで失敗していたモデルには、情報を渡すたびの小さな報酬が効きました。

運営者にとっての意味は、「賢いモデルなら自然に協力する」とは考えず、誰が何をいつ渡すかを手順として書いておく必要があるということです。

📄 論文: 最適化の予算を揃えると、チームは単体を有意に上回れなかった

At Equal Inference Cost, Multi-Agent Structure Does Not Beat a Single Frozen Agent（David Dylan ほか、2026年6月、arXiv:2609.04217）は、査読前の論文（プレプリント）です。

対象は、家庭内の作業をこなすテキストの仮想環境（ALFWorld、評価用134タスク）と、模擬的なネット通販の環境（WebShop、80セッション）です。すべての役割で同じ Qwen2.5-7B を固定して使い、プロンプトだけを最適化しました。多くの比較ではチームの方が1ステップあたり多くのモデル呼び出しを使えるため、この論文はプロンプトを最適化する段階で使えるLLMの呼び出し総数を揃えて、計画役・実行役・批評役のチームと単体のエージェントを比べています。最適化後の評価での呼び出し回数は揃えていません。評価は条件ごとに1回です。

ALFWorld では、チームの平均が最も高かったものの、単体との差は統計的に有意ではありませんでした（0.769対0.754、p=0.80）。しかも評価での1タスクあたりの呼び出し回数は、チームが単体の1.8倍でした。最適化の段階でチームに2〜3倍の呼び出しを許しても、チームは単体と並ぶだけでした。WebShop ではプロンプト最適化の効果自体が見られず、チームはむしろ悪化する傾向でした（有意差はなし）。計画役と批評役のプロンプトは最適化しても空のままで、成績の上積みにつながっていませんでした。著者ら自身、7Bモデル1種類・1つの構成での結果で、大きなモデルや役割ごとに違うモデルを使う場合に当てはまるとは主張しないと述べています。また、表の一部の行は検定の値が空欄で、一部の実験はエラーで完了しなかったと著者ら自身が書いています。

運営者にとっての意味は、「チームにしたら良くなった」という結果を見たら、まず同じ呼び出し回数の単体と比べたかを確かめるべきだということです。

現場でやること

まず「強い単体エージェント」を基準線にする

いきなり複数にせず、ツールと指示を整えた単体のエージェントで、どこまでできるかを測ります。この成績と費用が、後でチームを評価するときの基準線になります。

増やすときは、同じ呼び出し回数・トークン数で比べる

以下は論文の条件ではなく、運用上の提案です。チームを試すときは、成績と一緒に本番でのLLMの呼び出し回数とトークン数を記録します。4本目の論文のように、作る段階の予算を揃えても、本番ではチームの方が多く呼び出すことがあるためです。単体にも同じ回数を使わせて（たとえば複数回答えさせて選ぶなど）比べ、差が構成の効果なのか、計算を多く使った効果なのかを切り分けます。

受け渡しの手順を明文化する

エージェントごとに、目的・出力の形式・使うツール・担当の範囲を書きます。Anthropic も、下位のエージェントへの指示があいまいだと、同じ検索を重複して行ったり抜けが出たりしたと述べています。あわせて次を決めておきます。

  • 誰が、どの情報を、いつ渡すか
  • どの条件で作業を終えてよいか
  • 検証役は何を基準に合否を出すか

実行記録を残し、失敗の型で読む

各エージェントの入出力とツールの呼び出しを、後から順に追える形で残します。失敗したら、設計・受け渡し・検証のどの系統かで分類します。自動での原因特定はまだ精度が低いので、AIの判定は手がかりとして使い、最後は人が確かめます。

マルチエージェント導入の鍵は次の3点です

  1. まず強い単体エージェントを基準線にする
    各社とも単体から始めることを勧めています。複数にするのは、単体では確実に処理できない理由が見えてからです。
  2. 同じコストで比べてから増やす
    チームの上積みは、多くの計算を使えたことから来ている場合があります。呼び出し回数とトークン数を揃えて単体と比べます。
  3. 協力の手順と失敗の記録を設計に組み込む
    賢いモデルでも自然には協力しません。受け渡しの手順を明示し、人が後から追える実行記録を残します。

まとめ：マルチエージェントは「増やせば強い」から「必要なときだけ、設計して使う」へ！

マルチエージェントは、並行して進められる調査のような仕事では大きな力を発揮します。一方で、トークンの消費は大きく増え、失敗の原因は追いにくくなり、同じコストで比べると単体を上回らない例も報告されています。

まずは今のエージェントの成績・呼び出し回数・トークン数を記録し、「単体ではどこまでできるか」を測ってみてください。そのうえで増やすかどうかを決めれば、費用だけが膨らむ構成を避けられます！

参考文献

2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、失敗原因の自動特定の正答率とランダムとの比較、チームと単体の比較で揃えた条件の記述の誤りを修正しました

タイトルとURLをコピーしました