マルチエージェントは、どんな仕事で成果を出したか

マルチエージェントで改善したのは、何だったのか

一つの難しい仕事を複数のAIに渡しても、答えがよくなるとは限らない。互いの誤りを採用したり、同じ調査を繰り返したり、連絡に計算予算を使い切ったりするからだ。それでも、コードの正答率、調査の評価、回答の品質、アイデアの新規性を改善し、実験で検証する科学的仮説を生んだ研究がある。どの仕事で、何を分けたときに成果が出たのか。

本稿で扱うマルチエージェントは、複数のLLMの呼び出しが、別々の情報や履歴を持って提案・作業を行い、その結果を他の担当や統合処理へ渡す構成を指す。同じモデルを使う場合も、異なるモデルを組み合わせる場合も含める。単純な多数決や、あらかじめ定めた手順での分業も比較対象に置く。研究ごとに「エージェント」の意味が違うため、自律的な道具の利用と、回答候補の生成は区別する。

成功例から筆者が導く判断は、独立に探せる情報、依存関係を保って分離・統合できる工程、生成者から切り離せる検証、多様な候補を選び直せる工程がある仕事では、複数に分ける価値を検証できるというものだ。「複雑だから分ける」だけでは、誰が何を補うのかが決まらない。

コードとテストを分けたAgentCoder

表の中で、担当を分けることの効果を具体的に追いやすいのがAgentCoderである。コードを書くLLMと、テストを考えるLLMを分け、テスト担当には生成したコード全体を見せずに問題からテストを作らせる。実行担当はPythonスクリプトで、コードを実際に動かし、失敗を生成担当へ返す。「3エージェント」という呼称でも、3つのLLMが会話する実装ではない。

同論文のTable 7では、コードとテストを同じ会話で作る単一構成に対し、担当を分けた構成のpass@1がHumanEvalで71.3%から79.9%、MBPPで79.4%から89.9%へ上がった。差はそれぞれ8.6、10.5ポイントである。ここでpass@1は、仕組みの内部で修正を繰り返した後に出す一つのコード候補の評価であり、LLMを一度だけ呼んだ正答率ではない。

この設計には、コードの思い込みをテストへ持ち込ませにくくする狙いがある。実装が空の入力を忘れたとき、同じ履歴で続けてテストを作ると、その抜けを前提にした検査になり得る。担当を分ければ、問題文から別に境界条件を探せる。そこへ実行結果を返すことで、もっともらしい批評を、修正に使える具体的な失敗へ変える。

筆者がこの結果から採用したいのは、生成と検証の情報を分け、実行によるフィードバックを用意する設計だ。結果には指示、文脈の分離、反復も寄与するため、人数だけの効果とは断定できない。また、関数単位の課題の改善を、そのまま大規模なリポジトリの改修成功率へ移せない。テスト担当自身が誤った期待値を作る可能性も残る。

依存する開発工程でも成果が出たCAID

AgentCoderの関数単位の成果を、長い開発作業へそのまま広げることはできない。複数段階がつながる仕事では、まず一つのエージェントが同じ履歴を保って進める構成を比較の起点にしたい。OneFlowの研究も、7つのベンチマークで、同じモデルの複数担当による処理を単一エージェントが順番に実行して同等の性能へ到達できると報告している。工程や役割が多いだけでは、複数に分ける理由は足りない。

その起点から改善を示した例が、CAIDである。管理役が開発の依存関係を追い、実行できる部分を別々の作業場へ割り当てる。担当者は変更を検証して提出し、管理役が統合する。前段が終わっていない作業は待たせるため、全体に順序がある仕事でも、独立に進められる部分だけを取り出せる。

Claude Sonnet 4.5を使ったPaperBench Code-Devでは、単一構成のスコア57.2に対し、作業場を共有する複数構成は55.5、git worktreeで分離するCAIDは63.3だった。これは論文の完全な実験再現率ではなく、実装コードを評価する方式のスコアである。共有状態への干渉を抑え、統合を明示した構成で改善した点が、人数だけを増やす設計との違いになる。

ただし、全体の計算予算を揃えた比較ではない。単一側と管理役・実装担当側では反復上限が異なり、この条件ではCAIDの費用も所要時間も増えた。品質の改善と高速化は分けて読む必要がある。

筆者はこの成果を、全体の依存を一人が管理し、部分的な変更を分離して検証・統合できる仕事に限定して採用候補とする。すべての工程を直列に引き継ぐ必要がある処理まで、同じ理由で分担できるとは言えない。どの変更が統合済みかを明確にできることが、この成功例の条件になる。

別々に調べられる仕事では、並列化が成果につながる

CAIDでは、依存関係を保った上で独立に進められる実装を選んだ。調査や分析では、成果物の材料そのものを別々に集める余地がある。収益、費用、市場条件をそれぞれ調べ、最後に一つの分析へまとめる仕事なら、各担当が最初から同じ履歴を共有し続ける必要は小さい。

Kimらの2026年の比較研究は、6つのベンチマーク、5種類の構成、3系列のLLMにまたがる260構成を評価した。Finance Agentでは、集中調整型の平均成功率が単一構成の34.9%から63.1%へ上がった。28.2ポイント、相対値では80.8%の改善である。各モデル・構成の評価は50問で、道具とシステム全体の計算予算上限を揃えた比較だ。

一方、同じ研究のPlanCraftでは、複数構成はいずれも単一構成より低下した。著者らは、独立に分析できる金融課題と、前の操作で変わった条件を追い続ける逐次的な計画課題の違いを論じる。この比較からは、難易度だけで分担を決めるより、途中結果を独立に作れるかを先に調べる方が妥当だと考える。

製品実装の例として、AnthropicのResearchに関する技術報告も参考になる。Claude Opus 4が調整し、Sonnet 4が並列に調査する構成は、単一のOpus 4より社内調査評価で90.2%上回ったと報告する。具体例は、S&P 500の情報技術企業について取締役を漏れなく調べる課題だ。会社ごとに調査を進められるため、同じ問いを皆に解かせる必要がない。

これは査読論文の共通ベンチマーク比較とは異なり、同予算で90.2%よくなるという結果でもない。同報告の「約15倍のトークン」は通常のチャットとの比較であり、単一エージェントとの比較ではない。筆者なら、対象企業や資料群を分担でき、集まった記録を照合できる高価値の調査で試す。短い一件の事実確認まで同じ構成にする根拠にはしない。

画面操作と逐次処理で効果が出た分担

長い画面操作では、コードの変更を分離する代わりに、計画と操作の専門能力を分ける方法がある。Agent S2は、上位の計画、個々の操作、画面上の対象位置の特定を分担する。操作後の観測に応じて計画を更新し、対象の位置特定には専門の機能を使う。OSWorldの50操作上限の評価では、Claude 3.7 Sonnetを使うClaude Computer Useの成功率26.0%に対し、Agent S2は34.5%だった。

この構成は、位置特定にUI-TARS、文字読取り、アプリの構造を扱う機能も使う。異なる専門能力を組み合わせた成果として読める一方、同じLLMを複数にした効果だけを分離した比較ではない。採用候補になるのは、計画全体より、画面の読取りや正確な操作が失敗の原因になっている場合だと考える。

モデルを変えず、履歴の渡し方を変えた研究もある。情報の圧縮と損失から複数構成を分析した研究は、家事の手順を実行するシミュレーションALFWorldで、対象を探す担当と後続の操作担当を短い引継ぎでつないだ。実行例を事前に与えない設定では、Qwen2.5-7Bの通常の単一構成の成功率36.6%に対し、複数構成は54.5%だった。同じ段階分けを一つの履歴で進める対照も設け、134課題で最大の総操作ステップ数を50に揃えている。

この結果は、後段に不要な探索履歴を外し、対象や場所など必要な情報を残す設計を支持する。ただし、4ビットに量子化した強いQwen3.5-27Bでは、同じ設定の通常の単一構成90.3%に対し複数構成89.5%で、単一を上回らなかった。費用や総トークンを揃えた比較でもない。担当を分ける前に、単一側で履歴を整理するだけで同じ効果が得られないかも確かめたい。

履歴や専門能力を分けても、次の操作が前の結果に依存する順序は残る。M1-Parallelは、その順序を保ったまま、タスク全体を解く複数のチームを同時に動かす。GAIAの検証課題で3チームの最初の回答を採用する方式は、1チームのMagentic-Oneに対して1.6〜1.8倍高速で、完了率を維持したと報告する。ただし推論費用は1.7〜1.8倍になった。比較対象も既に複数エージェントであり、単一構成への優位を示す結果ではない。

回答と実行記録を待って統合する別方式では、解ける課題が増えた一方、概ね待ち時間も増えた。早期終了と統合は異なる目的の設定であり、「高速かつ高精度」を一つの結果としてまとめられない。最初に返った回答が正しいと判定する仕組みでもない。

筆者なら、調査のように複数の到達経路があり、待ち時間を減らすための追加費用を許容できる仕事で、この方式を比較する。注文確定や記録更新を伴う業務で処理全体を複製すれば、同じ操作を重ねる可能性がある。並行実行を検討する際は、書込みを伴う部分をどの一つの結果から実行するかも決める必要がある。

異なる回答を統合したMixture-of-Agents

M1-Parallelが解法全体の実行記録を統合したのに対し、回答候補だけを補い合わせる方法もある。Mixture-of-Agents（MoA）は、複数モデルが回答を作り、次の層がその回答群を参照して書き直す。ここでのエージェントは主に回答を提案・統合するLLMであり、各担当が自律的にブラウザーを操作する仕組みとは異なる。

6つの提案を3層で扱う構成は、AlpacaEval 2.0の長さ補正後の勝率で65.1%を報告した。比較に置いた2024年5月版のGPT-4oは57.5%で、差は7.6ポイントだった。この数字は、評価用の参照回答に対してどちらが好まれるかを測る指標であり、「65.1%の質問に正解した」という意味ではない。モデル群と呼び出し回数も異なるため、この比較だけで協調の効率は決まらない。

多様性を見るための別の比較もある。Table 3では、統合役をQwen1.5-110B-Chatに固定した2層・6提案の構成で、同じモデルから6候補を出す場合の56.7%に対し、異なるモデルの候補を使う場合は61.3%だった。これは先ほどの3層の数値とは別条件である。提案数を揃えた比較で差が出たことは、異なる候補を用意する設計の根拠になる。ただし、モデルの規模や計算費用まで同じにした比較ではない。

筆者はこの成果を、候補に含まれる説明や着眼点を統合役が使い直せる仕事に結び付ける。複数の下書きから説明の不足を補う用途は候補になるが、同じ誤った事実を全員が信じていれば、統合しても裏付けは増えない。原典との照合は別に必要である。

アイデアの探索では、新規性に改善が見られる

回答を一つの正解へ寄せる仕事と、候補の幅を広げる仕事では、成果の測り方も変わる。Huらの2026年のプレプリントは、社会課題、事業上の問題、仮想状況を含む6課題で、人間のチームと複数LLMのチームが作った案を比較した。新規性と有用性を5人の評定者が評価し、その積を創造性の指標とした。

単一モデルとの比較では、GPT-4.1の平均が0.253から、同モデルの最良の複数構成で0.298へ上がった。o3の2つの推論設定でも最良構成の改善を報告している。ただし、複数構成を試した中の最良値との比較であり、任意のチーム構成が同じ利得を生むという結果ではない。評定前には、表現の差を抑えるため案の文章をLLMで整えている。

人間のチームとの比較で見られた優位は、主に新規性の高さから来ており、有用性は同程度だった。これは、案を考える段階で探索範囲を広げる成果と読める。一方、案を実装して顧客に受け入れられた割合や、事業成果を測った研究ではない。企画へ応用するなら、候補の多様性と採用後の有用性を別々に測る必要がある。

この用途では、すぐに全員を同じ意見へ揃えると、欲しかった候補の違いを失いかねない。筆者なら、案を独立に出す工程と、制約に照らして選ぶ工程を分けて試す。その順序が効くかは、モデルと議論の方法を含めた比較で確かめたい。

Co-Scientistは、候補を実験で確かめるところまで進んだ

アイデアの評定より一歩進み、現実の対象で提案を検証した例がCo-Scientistである。2025年の初稿「Towards an AI co-scientist」は、2026年6月の改訂で「Accelerating scientific discovery with Co-Scientist」となった。Geminiを基盤に、研究者の目的と先行研究に沿って、仮説を生成・批評・改良する複数の担当を動かす。

このシステムは、仮説を比較するトーナメント形式の評価と改良を繰り返す。改訂版は、急性骨髄性白血病に対する薬剤転用候補と相乗効果を狙う組み合わせの特定を支援し、それらを試験管内の実験で検証したと報告している。LLM同士が仮説を高く評価したことに加え、研究者が外部の実験で確かめる対象を作った点に成果がある。

ただし、実験室での成果は、同じ予算の単一エージェントでは得られなかったという証明と同じではない。計算量の追加、仮説を選ぶ仕組み、研究者の指導、実験の設計も結果に関わる。試験管内で確認した効果を、臨床上の有効性とも区別する必要がある。

筆者がここから引き出す採用候補は、評価に時間と費用がかかるため、実験前に候補を広く作り、批判して絞る価値が大きい仕事である。成果を数える単位は、議論の回数ではなく、外部で検証できる候補と、その検証結果になる。

討論を追加する価値は、多数決と比べて確かめる

候補を比べることが有効でも、互いに長く討論させればさらによくなるとは限らない。Duらの初期研究は、複数モデルが答えと理由を出し、相互に修正する方法で、数学的推論や事実性の改善を報告した。これに対し、Debate or Voteは7つの言語課題で要素を分け、討論に帰属されてきた利得の多くを多数決だけで説明できると報告する。

両者は、複数の候補を使う成果と、会話を続ける追加効果を別に測る必要を示している。Self-Consistencyは、同じモデルから複数の推論を生成し、答えを集約する比較方法になる。Voting or Consensus?も、最終決定の方法によって成績が変わり、投票前の議論を長くすると性能が下がる場合を報告している。

したがって、討論を採用するなら、他の担当の発言が何を増やすかを定めたい。未確認の主張に反例を出す、異なる資料を持ち寄る、実行したテストの失敗を示す、といった情報なら、候補を更新する根拠になる。同じ推測を言い換えて共有するだけでは、正しさを判定する材料が増えない。

引き継ぎと検証も成果を左右する。MASTの失敗分析は、7つのフレームワークの1,600件超の実行記録を整理し、設計、担当間の不整合、検証に関わる14の失敗類型を示した。独立した仕事を作れても、出典や前提を渡し損ねれば、統合役は結果を正しく使えない。

どの仕事からマルチエージェントを試すか

成功例を実務へ移すときは、一人で解きにくかった理由と、増やす担当の役割を対応させる。次の表は、研究の比較から筆者が導く導入候補であり、各業務での効果を実測した一覧ではない。

前の操作結果で次の一手が変わる作業では、まず同じ工程を単一エージェントが実行する構成を基準にする。その上で、CAIDのように依存関係を管理して変更を分離できるか、Agent S2のように専門能力を補う必要があるかを確かめる。工程ごとに別の担当へ渡すだけでは、必要な履歴を失い、引継ぎの負担だけが増える場合がある。

比較は、同じ課題群に対して、単一エージェント、単一モデルの反復・複数候補の投票、役割を分けた構成を用意するところから始められる。モデル、道具、システム全体のトークンや費用の上限、試行回数を揃え、予算を揃えた比較と、時間短縮を狙った比較を分ける。これは本稿の提案であり、各論文が共通して採用した評価手順ではない。

AI Agents That Matterが指摘するように、正確さと費用を一緒に評価する必要がある。完了した成功例だけでなく、失敗と再試行を含む一件当たりの費用、待ち時間の中央値と遅いケース、人の修正時間を記録する。正答率が少し上がっても、確認の仕事が増えれば採用理由は弱くなる。

AgentCoderなら、生成者が見落とした条件を別の担当がテストにできるか。CAIDなら、依存する開発の一部を分離し、検証して統合できるか。並列調査なら、異なる資料を分担し、出典を失わずに統合できるか。Co-Scientist型なら、候補を外部の実験へ渡せるか。マルチエージェントへ進む判断は、この具体的な不足を補う担当を置き、その追加による成果を、同じ仕事をする単一構成と比べて確認できるときに成立する。