マルチエージェント（Multi-Agent System）とは、複数の AI エージェントが役割を分け、並列に動いて1つの仕事を仕上げる仕組みのこと。司令塔のエージェントが仕事を分け、担当のエージェント（サブエージェント）がそれぞれ別の文脈で調べたり書いたりして、結果を司令塔がまとめる。
ただし「エージェントを増やせば賢くなる」わけではない。Google Research などが6種類の課題で比べた実験では、単体のエージェントと比べて分けられる仕事では最大で約81%良くなり、順番どおりに進める仕事では最大70%悪くなった。この記事では、定義と5つの型に加えて、この実験と Anthropic・Cognition などの公開資料から「どんな仕事なら効き、どんな仕事なら逆効果か」を判断できるところまで整理する。
マルチエージェント＝役割を分けて並列で動かすチーム
— 1体のAIに全部やらせる代わりに、専門の小チームが分担する
それぞれが 独自のコンテキストウィンドウ を持ち、並列で動く。
司令塔は結果を確かめて集約する——実験では、この「確かめる司令塔」の有無が誤りの広がりを大きく左右した。
目次
1. マルチエージェントとは何か
マルチエージェントシステム（Multi-Agent System, MAS）とは、複数のAIエージェントが協調して1つのタスクを解く仕組みのこと。それぞれのエージェントは独自の指示（プロンプト）・使える道具（ツール）・文脈（コンテキスト）を持ち、結果のやり取りを通じて全体の目標を達成する。
土台になる「1体のエージェント」は、AIエージェントとはで解説した通り、「考える→道具を使う→結果を見る」のループを単独で回す存在だ。マルチエージェントはここに役割分担と並列性を加えたものと考えるのがいちばん近い。
シングルエージェントとの違い
| 観点 | シングルエージェント | マルチエージェント |
|---|---|---|
| 構造 | 1体のAIがループを回す | 複数のAIが連携して動く |
| コンテキスト | 1つのウィンドウに全部詰め込む | 役割ごとに分ける（無関係な情報が混ざらない） |
| 並列性 | 原則として順番に処理 | 担当どうしで同時に進められる |
| 誤りの広がり | 自分の誤りが積み重なる | 確かめる役が無いと、担当の誤りがそのまま最終結果に入る |
| コスト | 低い（チャットの約4倍） | 高い（チャットの約15倍） |
| 得意な仕事 | 順番どおりに進む仕事・前の結果に次が依存する仕事 | 独立した部分に分けられる調査・比較・検証 |
トークンの倍率は Anthropic が自社の調査機能について公表した値（How we built our multi-agent research system・2025年6月13日）。詳しくは6章。
2. なぜ複数のAIを協調させるのか
「1体で全部できるなら、それでいい」が出発点だ。マルチエージェントが必要になるのは、1体では構造的に越えにくい3つの壁にぶつかったときだ。
1体では越えにくい3つの壁
効果の例として、Anthropic は Claude の調査機能（Research）について、司令塔に Claude Opus 4、担当に Claude Sonnet 4 を使った構成が、Opus 4 の1体だけの構成より社内の調査用の評価で90.2%良かったと公表している（同上）。同じ記事は、性能のばらつきの80%は使ったトークンの量だけで説明できた（BrowseComp という調査の評価で）とも書いている。つまりマルチエージェントの強みの大半は、「別々の文脈を並べて、1体では入りきらない量を読める」ことにある。
3. 5つの型
マルチエージェントの構造には、いくつかの「型」がある。名前は製品ごとに違うが、おおむね次の5つにまとまる。4章の実験で使われた分け方（独立・集中・分散・混合）との対応も添える。
3-1. オーケストレータ・ワーカー型（いちばん使われている）
1体の司令塔（オーケストレータ）が仕事を分け、複数のワーカー（サブエージェント）に割り振る。各ワーカーは別の文脈で動き、結果を司令塔に返す。実験の分け方では「集中型（Centralized）」にあたる。Anthropic の調査機能、Claude Code のサブエージェント、OpenAI Agents SDK の「エージェントを道具として呼ぶ」形（Agent.as_tool()）がこの型だ。
3-2. ハンドオフ型（担当のリレー）
エージェント同士が「次はあなたに任せる」と会話の主導権を渡す形。OpenAI Agents SDK の説明では、ハンドオフを受けた専門のエージェントがそのターンの残りを受け持つ。問い合わせの受付から請求担当・技術担当へ回すような窓口の仕事に向く。この SDK の前身にあたる実験的な Swarm は、リポジトリで「Agents SDK に置き換えられた」と案内されており、新しく作るなら Agents SDK を使う。
3-3. 階層型（チームのチーム）
司令塔の下にさらに中間の司令塔を置き、その下に担当を置く木の形。Claude Code では、サブエージェントが自分のサブエージェントを呼べる深さが既定で3段まで（公式ドキュメント）、Cursor も2026年2月の2.5で担当が担当を呼べるようにした。段を重ねるほどトークンと待ち時間が増えるので、深さは上限を決めておく。
3-4. ピアツーピア型（討論・合意）
司令塔を置かず、複数のエージェントが対等に意見を出し合い、合意するまで繰り返す。実験の分け方では「分散型（Decentralized）」。Multi-Agent Debate の研究で、答えの事実性や推論が良くなると報告されている。ウェブの調べもののように、いくつもの見方を突き合わせる仕事で力を出しやすい（4章）。
3-5. パイプライン型（決まった順番）
「調査 → 構造化 → 検証 → 出力」のように決まった順で各エージェントを通す。どのエージェントを次に動かすかを AI でなくプログラムが決めるので、結果が安定し、どこで失敗したかも追いやすい。OpenAI Agents SDK は、前の出力を次の入力に渡す「チェーン」や、作る役と評価する役を回す「評価ループ」をコードで組む形として紹介している。
5つの型の早見表
4. 実験で分かった「効く仕事・効かない仕事」
「どの型が強いか」は仕事の性質で逆転する。それを数字で示したのが、Google Research と Google DeepMind などの研究者による論文 Towards a Science of Scaling Agent Systems（最新版は2026年4月）だ。GPT・Gemini・Claude の3系統のモデルで、単体と4つのマルチ構成の計5つの型を、6種類の課題・260通りの組み合わせで比べている（Google Research のブログでの紹介は2026年1月。ブログにある180通りは初版の時点の数）。
出典：論文の4.2節。コードの修正と手順の計画は、試したマルチ構成がすべて単体より悪く、いちばん悪化が小さかったものを載せた（コードの修正は −2.1%〜−14.9%、手順の計画は −39.1%〜−70.0%）。
読み取れることは3つある。
- 分けられる仕事でだけ大きく効く：金融の分析は、売上・費用・市場などを別々に調べて最後にまとめられるので、集中型が単体を約81%上回った。
- 順番に依存する仕事では逆効果：前の一手が次の一手を決める計画の課題では、どの構成も単体より悪かった。仕事を分けると、担当の間で前提がずれるうえ、やり取りに手数を取られる。
- コードの修正も伸びなかった：Anthropic も「多くのコーディングの仕事は、調査に比べて本当に並列にできる部分が少ない」と書いており（同社の記事）、結果と食い違わない。
確かめる司令塔がいると、誤りの広がりが小さい
同じ論文は、担当の誤りが最終結果にどれだけ広がるかを型ごとに測っている（単体を1とした倍率）。
独立型（相談も確認もなし）
17.2倍
担当の結果を並べるだけで、誤りがそのまま残る
分散型（対等に討論）
7.8倍
話し合いで一部は直るが、確かめる役がいない
混合型
5.1倍
司令塔＋担当どうしの相談
集中型（司令塔が確かめる）
4.4倍
司令塔が担当の結果を確かめてからまとめる
出典：論文の表5（Error Amp）。同じ表では、1回の課題に要したやり取りの回数が単体の平均7.2回に対し、集中型は27.7回、混合型は44.3回だった。
「単体で45%以上解けるなら、増やすと逆効果になりやすい」——論文は、単体のエージェントの正答率がすでに約45%を超えている課題では、エージェントを足すと成績が下がる傾向を報告している。まず1体で測り、その数字を見てから増やすかを決める、という順番が実験からも支持される。
5. 実際の製品での使われ方
Anthropic の調査機能：問いの難しさで担当の数を変える
Claude の Research は典型的なオーケストレータ・ワーカー型で、司令塔が問いを分け、担当が並列に調べ、司令塔がまとめる。公開された設計で役に立つのは、問いの難しさに応じて担当の数を指示文に書いている点だ（同社の記事）。
| 問いの種類 | 担当の数 | 道具の呼び出し |
|---|---|---|
| 単純な事実の確認 | 1体（司令塔だけ） | 3〜10回 |
| 直接の比較 | 2〜4体 | 各10〜15回 |
| 複雑な調査 | 10体を超えることもある | 担当ごとに受け持ちをはっきり分ける |
この目安が無かった初期には、単純な問いに50体の担当を立てるといった失敗があったと同社は書いている。自分で作るときも、この表をそのまま指示文の「規模の決め方」に入れるのが手早い。また、検索などの道具を並列に呼ぶよう変えたことで、複雑な問いの調査時間が最大90%短くなったという。
Claude Code・Codex のサブエージェント
Claude Code では、調べもの・レビューなどをサブエージェントに任せられる。各サブエージェントは自分の文脈で動き、親には要約だけを返すので、親の文脈が埋まらない。同時に動かせる数は既定で20、入れ子は既定で3段まで。担当どうしが相談しながら進める「エージェントチーム」との違いはサブエージェントとエージェントチームの違い、Codex と並べた並列の頼み方はCodex と Claude Code の並列サブエージェントで詳しく扱っている。
Devin（Cognition）：「作るな」から「束ねる」へ
Cognition は2025年6月に「Don't Build Multi-Agents」という記事を出し、並列の担当が互いの判断を知らないまま作業すると食い違った結果になると指摘した。原則は「文脈を共有する（個々のメッセージでなく作業の経過ごと）」と「行動には暗黙の判断が含まれ、判断が食い違うと結果が悪くなる」の2つ。
その同社が2026年3月には、Devin が大きな仕事を分けて、それぞれ専用の仮想マシンで動く複数の Devin に並列で任せる機能を出した。親の Devin は進み具合を見て、食い違いを解消し、結果をまとめる。並列を捨てたのではなく、「担当の食い違いを親が引き受ける」形に落ち着いたと読める。4章の「確かめる司令塔がいると誤りが広がりにくい」とも合う。
Cursor：担当を待たずに進める
Cursor は2.5（2026年2月17日）で、サブエージェントを非同期に動かし、親が待たずに作業を続けられるようにした。担当がさらに担当を呼ぶこともできる。Anthropic も、司令塔が担当の終わりを待つ同期の実行は「詰まりを生む」と書いており、待たせない作りは各社の共通の課題になっている。
6. コスト——トークンはチャットの約15倍
Anthropic は、エージェントはチャットの約4倍、マルチエージェントは約15倍のトークンを使うと書いている（同社の記事）。自分の用途に当てはめると、次のような見積もりになる。
見積もりの例（倍率は Anthropic の調査機能の値。仕事によって変わる）
チャットで1回 1万トークン かかる問い → エージェント1体なら約 4万、マルチエージェントなら約 15万トークン。
1日100件こなすなら、チャット100万・エージェント400万・マルチ1,500万トークン。単価は使うモデルの公式の料金表で掛ける。
増えるのはトークンだけではない
上限は「止まる上限」と「目安」を分けて設定する
担当が担当を呼び、ループに入ると、費用は一気に膨らむ。Claude で作る場合、仕組みの違う2種類の上限がある。
| 上限 | どこで設定 | 止まるか |
|---|---|---|
| 費用の上限 | Claude Agent SDK の max_budget_usd（TypeScript は maxBudgetUsd） | 止まる（新しい担当を立てず、問い合わせを終える） |
| 入れ子の深さ | 環境変数 CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH（既定3、1なら入れ子なし） | 止まる（最下段の担当は自分で作業する） |
| 同時に動く数 | 環境変数 CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS（既定20） | 止まる（上限を超える担当は立てない） |
| タスクバジェット | Claude API の task_budget（ベータ・最小2万トークン） | 止まらない（モデルが残りを見てペースを配分する目安） |
出典：Agent SDK のサブエージェント・Task budgets（2026年11月12日に確認）。上の3つの止まる上限は TypeScript SDK v0.3.219・Python SDK v0.2.127 以降の動きで、それより前の版では無いものや既定値が違うものがある。タスクバジェットは公式に「強制ではなく目安」とあり、確実に止めたいときは費用の上限や max_tokens と組み合わせる。
7. 使うか決める判定表
ここまでの資料をまとめると、判断は次の5つの問いでほぼ決まる。上から順に答え、1つでも「単体」の側に当たったら、まず1体で作る。
| 問い | マルチに向く | 単体に向く | 根拠 |
|---|---|---|---|
| 仕事を独立した部分に分けられるか | 分けられる（会社ごと・資料ごと・観点ごと） | 前の結果で次が決まる | 金融の分析 +80.8%、手順の計画 −39.1%〜−70.0% |
| 単体でどれくらい解けるか | 単体では正答率が低い | 単体ですでに45%程度以上解ける | Google Research などの論文 |
| 担当が同じ文脈を共有する必要があるか | 担当ごとの情報で足りる | 全員が同じ文脈を見ないと食い違う（多くのコーディング） | Anthropic・Cognition |
| 1つの文脈に入りきるか | 資料が多く、1体では文脈があふれる | 1体の文脈に収まる | トークン量が性能のばらつきの80%を説明 |
| 15倍のトークンに見合う価値があるか | 1件の価値が高い（調査・監査・比較の報告） | 大量の定型処理・即答が要る窓口 | Anthropic の約15倍 |
Anthropic もエージェントの作り方の指針で、できるだけ単純な解決策から始め、必要なときだけ複雑さを足すよう勧めている。作り始める手順と最小のコード例はマルチエージェントの作り方、1体目のエージェントの作り方はAIエージェントの作り方にまとめた。
8. 設計の要点と、よくある失敗の型
① 担当には「目的・出力の形・使える道具・範囲」を渡す
Anthropic は、担当への指示が曖昧だと、担当が仕事を取り違えたり、ほかの担当と同じ検索を重ねたり、必要な情報を調べ漏らしたりすると書いている。各担当には(1) 目的、(2) 返してほしい形、(3) 使ってよい道具と情報源、(4) 仕事の範囲を明示する。Claude Agent SDK のサブエージェントは親の会話を受け取らず、渡されるのは呼び出し時の指示文だけなので（公式ドキュメント）、ファイルのパスや決めたことも指示文に書き込む。
② 掘り下げる深さを指示する
担当は「どこまで調べるか」を自分で決めるのが苦手だ。5章の表のように規模の目安を書き、あわせて推論の深さを設定する。Claude の effort は担当ごとにも指定でき、Agent SDK の担当の定義でも low から max まで選べる。単純な担当は軽く、検証の担当は深く、と分けると費用が抑えられる。
③ 司令塔に「確かめる」仕事を持たせる
4章のとおり、司令塔が担当の結果を確かめてからまとめる集中型は、確かめない独立型より誤りの広がりがはるかに小さかった（4.4倍と17.2倍）。司令塔の指示には、担当の結果どうしの矛盾を探し、根拠を確かめてから採る手順を入れる。
④ 失敗の型を知っておく
UC Berkeley などの研究者は、7つのマルチエージェントの仕組みの1,600件を超える実行記録から、失敗を3つの分類・14の型に整理した（Why Do Multi-Agent LLM Systems Fail?）。設計を見直すときの点検表として使える。
| 分類 | 起きること | 手当て |
|---|---|---|
| 設計の問題 | 役割や手順の指示に従わない・同じ作業を繰り返す・終える条件が分からない | 役割・範囲・終わりの条件を指示文に書く |
| 担当どうしのずれ | 前提が食い違う・必要な情報を伝えない・ほかの担当の意見を無視する | 経過ごと共有する・司令塔が食い違いを解く |
| 確認の不足 | 途中で終える・確かめない・確かめ方が浅い | 確かめる役（司令塔か検証の担当）を置く |
⑤ 動きを記録する仕組みを最初に作る
マルチエージェントは、何が起きているか追えないと直せない。各担当の入出力・所要時間・トークン・呼んだ道具を最初から記録する。Anthropic は評価について、実際の使われ方に近い約20件の問いから始め、採点基準を渡した AI に採点させたと書いている。大きな評価の仕組みを待たずに、少数の問いで変化を見るのが現実的だ。
9. 型ごとの書き方（主な SDK）
同じ型でも、SDK ごとに呼び方が違う。どれを選ぶかの比較（試作の速さ・本番での成熟度・トークン量）はAIエージェントのフレームワーク比較に任せ、ここでは3章の型がどの部品にあたるかだけを示す。
| SDK | オーケストレータ・ワーカー型 | ハンドオフ・パイプライン型 |
|---|---|---|
| Claude Agent SDK | agents で担当を定義し、Agent ツールで呼ぶ（旧名 Task） | 専用の部品は無く、パイプラインは自分のコードで順に呼ぶ |
| OpenAI Agents SDK | Agent.as_tool() で担当を道具として呼ぶ | ハンドオフで主導権を渡す・チェーンや並列はコードで組む |
| LangGraph | 司令塔のノードから担当のノードへ分岐させる | ノードと辺で順番・分岐・繰り返しをグラフに書く |
| Strands Agents（AWS） | Agents as Tools で担当を道具として呼ぶ | Swarm で担当どうしが受け渡す・Graph や Workflow で順番を組む |
| Microsoft Agent Framework | 複数エージェントの協調の型を部品として持つ | ワークフローとして順番を組む |
Microsoft の AutoGen はリポジトリがアーカイブされ、Microsoft による不具合や安全性の修正も提供されなくなった（2026年11月12日に確認）。新しく作るなら後継の Microsoft Agent Framework を使うよう案内されている。各 SDK の最小のコード例はマルチエージェントの作り方を参照。
まとめ
- マルチエージェントは、複数のAIが役割を分け、並列に動いて1つの仕事を仕上げる仕組み。文脈があふれる・同時に進められない・作る役と確かめる役が同じ、という1体の壁を越える。
- 型はオーケストレータ・ワーカー、ハンドオフ、階層、ピアツーピア、パイプラインの5つ。いちばん使われているのはオーケストレータ・ワーカー型。
- 効くかは仕事しだい。分けられる金融の分析では単体より +80.8%、順番に依存する計画では −39.1%〜−70.0%、コードの修正も伸びなかった。
- 確かめる司令塔を置くと、誤りの広がりが独立型の17.2倍から4.4倍に抑えられた。
- トークンはチャットの約15倍（エージェント1体は約4倍）。費用の上限・深さ・同時に動く数は「止まる上限」で設定する。
- 判断の順番：まず1体で作って測る。分けられる仕事で、1体では足りないと分かった所だけ担当に分ける。
FAQ
Q1. マルチエージェントは「賢いシングルエージェント」より必ず優れているのか？
違う。Anthropic の調査機能では1体より90.2%良かったが、それは独立した部分に分けられる調査での話。Google Research などの実験では、順番に依存する計画の課題でどのマルチ構成も単体より悪かった。仕事を分けられるかで決まる。
Q2. コーディングにマルチエージェントは効くか？
1つの修正を複数の担当で書き分ける使い方は、効きにくい。実験ではコードの修正（SWE-bench Verified）で、どのマルチ構成も単体を下回った（−2.1%〜−14.9%）。一方、調べもの・レビュー・テストの実行のように独立した作業を担当に任せ、親の文脈を空けておく使い方は、Claude Code のサブエージェントの代表的な用途だ。
Q3. シングルエージェントから段階的にマルチに移行できるか？
できる。まず1体で作って正答率・トークン・時間を測り、文脈があふれる所や並列にできる所が見えたら、その部分だけ担当に分ける。最初から全部をマルチで設計すると、どこが効いているのか測れなくなる。
Q4. マルチエージェント間の通信プロトコルに標準はあるか？
エージェントとツール・データをつなぐ部分では MCP（Model Context Protocol） が事実上の標準になっている。Anthropic 発で、2025年12月に Linux Foundation のAgentic AI Foundationへ寄贈され、OpenAI・Microsoft・AWS なども採用している。エージェント同士の通信には Google 発の A2A（Agent2Agent） があり、こちらも Linux Foundation に移管された。IBM 発の ACP（Agent Communication Protocol） は2025年8月に A2A へ合流している。
Q5. タスクバジェットを設定すれば、費用の暴走は防げるか？
それだけでは防げない。Claude API のタスクバジェットはモデルにペース配分させる目安で、公式に「強制ではない」とある。確実に止めたいなら、Agent SDK の費用の上限（max_budget_usd）や入れ子の深さ・同時に動く数の上限を設定する（6章の表）。
Q6. 「サブエージェント」と「マルチエージェント」は別物か？
サブエージェントは、マルチエージェントの中のオーケストレータ・ワーカー型で使われる「担当」のこと。Claude Agent SDK では、メインは1体のまま、必要なときだけ Agent ツールで担当を呼ぶ。担当どうしが直接相談しながら進める形（Claude Code のエージェントチームなど）は、ピアツーピア型や混合型に近い。
