先に要点
- マルチエージェント は、1つの AIエージェント ですべてを処理するのではなく、役割の違う複数のエージェントを連携させる構成です。狙いは 役割分担・文脈の分離・並列化 の3つです。
- ただし無料ではありません。Anthropic 自身の計測では、マルチエージェント構成は単一チャットの 約15倍のトークン を消費し、しかも性能差の約80%がそのトークン量だけで説明できると報告されています。「賢くなる」前に「高くなる」のが先に来ます。
- 実料金で見ると、調査→執筆→レビューの3役に分けるだけで 単体エージェントの約3〜4倍 の課金になるのは珍しくありません。本文に具体的な試算表を載せます。
- 役割分担はしばしば裏目に出ます。責務の境界、共有情報、権限、停止条件を設計しないと、単体より 遅く・高く・原因が追いにくい 構成になります。本記事は失敗を「現象→原因→確認→回避」で具体化し、何を分けて何を分けないかの意思決定表まで踏み込みます。
最近の AI エージェント文脈では、マルチエージェント という言葉をかなり見かけるようになりました。1つのAIが全部やるのではなく、複数のAIが役割分担して進める発想です。
ただ、この言葉はかなり広く使われています。単に並列実行しているだけのこともあれば、オーケストレーターが部下エージェントを使う構成、handoff で別のエージェントへ会話を渡す構成まで含まれます。
この記事の主眼は「定義の言い換え」ではありません。分けると何が起きるのか、コストが具体的にどれくらい膨らむのか、役割分担がどこで裏目に出るのか を、実料金の数字と失敗パターンで掘り下げます。なお本文中の Anthropic / OpenAI の挙動・料金は 2026年6月時点の公開情報を確認して書いています。
マルチエージェントとは何か
マルチエージェントとは、1つの AI エージェントに全部任せるのではなく、役割の違う複数のエージェントを連携させる構成です。
たとえば、次のように分けます。
- 調査担当
- 要約担当
- 実装担当
- テスト担当
- レビュー担当
Anthropic の Multiagent sessions ドキュメントでは、coordinator(調整役)が複数のサブエージェントへ仕事を振る構成として説明され、コードレビュー、テスト生成、リサーチのような well-scoped(役割の狭い)タスクへ分ける例が出ています。OpenAI Agents SDK の orchestration ガイドでも、specialized agents が1つのタスクに集中する形を勧めています。
つまり本質は「AIを増やすこと」ではなく、仕事を分担すること です。そしてこの分担には、後述するとおり明確な値札が付きます。
まず値札を見る：なぜ「約3〜4倍」になるのか
加筆の主目的なので、ここを最初に厚く書きます。マルチエージェントを検討するとき、多くの記事は「コストが増える」とだけ書いて終わります。実務では「どれくらい増えるか」が判断のすべてです。
公式が出している実測値
Anthropic は自社のリサーチ機能(Lead Researcher が複数のサブエージェントを束ねるマルチエージェント構成)についてエンジニアリング記事を公開しており、要点は次の3つです。
性能差の約80%
エージェント間の性能ばらつきの約80%は「使ったトークン量」だけで説明できた。ツール呼び出し回数は約10%、モデル選択は約5%。つまり成績の大半は「どれだけ広く探索したか=どれだけ課金したか」に紐づきます。
向き不向きがはっきり
並列に分割できる調査タスクでは単体を90%超上回った一方、コーディングのように工程が密に依存するタスクは並列化しにくく、マルチエージェント化の効果が出にくいとされています。
ここで重要なのは、「15倍」はあくまでヘビーな調査エージェントの話だという点です。多くの業務はそこまで行きませんが、分けた瞬間にトークンが累積で増える 構造はどんな構成でも共通です。次でその構造を実料金に落とします。
トークンが累積する仕組み
単体エージェントなら、入力(指示+資料)を1回読んで出力します。マルチエージェントでは、オーケストレーターが各サブへ文脈を渡し、サブの出力を受け取り、それをまとめて次へ渡す——この受け渡しのたびに同じ情報が トークン として再計上されます。
具体的に、Claude の現行料金(2026年6月時点、いずれも100万トークンあたり)で並べます。
| モデル | 入力 $/1M | 出力 $/1M | 位置づけ |
|---|---|---|---|
| Claude Opus 4.8 | $5.00 | $25.00 | 最上位・調整役向き |
| Claude Sonnet 4.6 | $3.00 | $15.00 | バランス・実作業向き |
| Claude Haiku 4.5 | $1.00 | $5.00 | 最速・単純作業向き |
ここで「調査→執筆→レビュー」を1本の記事生成タスクで回す例を考えます。資料(共有コンテキスト)が約20,000トークン、各役の追加指示・出力がそれぞれ数千トークン規模だと仮定します。数字は分かりやすさのための概算で、実測ではないことを断っておきます。
| 構成 | 入力トークン(累積) | 出力トークン(累積) | 概算コスト(Sonnet 4.6 換算) |
|---|---|---|---|
| 単体エージェント(1回で完結) | 約25,000 | 約4,000 | 約 $0.14 |
| 3役(調査・執筆・レビュー) | 約75,000(資料を3回渡す) | 約12,000 | 約 $0.41(単体の約3倍) |
| 3役+オーケストレーター+1往復の差し戻し | 約110,000 | 約16,000 | 約 $0.57(単体の約4倍) |
ポイントは2つです。1つ目は、役を増やすほど「同じ資料」を何度も入力として課金される こと。2つ目は、レビューで差し戻しが1往復入るだけで、文脈がもう一周して一気に跳ねること。FAQ で触れていた「単体の3〜5倍」という肌感覚は、こうした累積から自然に出てきます。
なお、この累積を抑える代表的な手段が プロンプトキャッシュ です。共有資料のように毎回同じ前置きを各サブへ渡すなら、キャッシュ読み出しは入力単価のおよそ1/10で済むため、上表の入力側を実質的に大きく圧縮できます。逆に言うと、キャッシュ設計をしないマルチエージェントは「同じ資料をフル単価で何度も買い直している」状態になりがちです。
なぜ1体でなく複数に分けるのか
コストを払ってでも分ける価値が出るのは、次の3つが効くときです。
1. 役割を狭めると迷いが減る
1体の万能エージェントに「調べて・書いて・テストして・レビューして」を全部やらせると、文脈が膨らみ、判断が散りやすくなります。一方、調査だけ・修正だけ・レビューだけ、と分けると役割が明確になり、各エージェントの指示も短く保てます。
2. 文脈を分離しやすい
Anthropic の multi-agent docs では、各エージェントは サブエージェント ごとに独立した文脈(isolated context)を持てると説明されています。調査用の長い資料と、実装用の細かいコード差分を同じ文脈に全部詰め込まなくて済むのは大きな利点です。
3. 並列で進めやすい
OpenAI Agents SDK の multi-agent guide でも、独立した作業の並列実行は有用だと説明されています。たとえば「A: 既存コードを読む / B: テストケースを洗い出す / C: 関連仕様を調べる」を別々に進めれば、時間を縮められます。
ただし前述のとおり、並列化が効くのは 工程が互いに独立しているタスク に限られます。後工程が前工程の結果に強く依存するコーディングのような作業では、分割の効果は薄く、コストだけ増えやすい点に注意してください。
代表的な構成
1. オーケストレーター型
中心に coordinator(manager)がいて、必要に応じて専門エージェントへ仕事を振る形です。Anthropic の docs でも coordinator が callable agents を呼ぶ構成として、OpenAI Agents SDK では manager pattern を agents as tools(サブを「ツール」として呼ぶ)として紹介しています。全体方針を1か所で持て、ユーザーとの窓口がぶれにくく、役割分担を制御しやすいのが強みです。
2. Handoff型
OpenAI Agents SDK の handoffs は、今のエージェントが会話や仕事の主導権を別の専門エージェントへ渡す形です。受付→請求→技術サポートのように、話題に応じて担当が切り替わるイメージで、顧客対応のように「担当を切り替える方が自然」な場面で使いやすいです。
3. コード主導の分岐型
OpenAI の orchestration guide では、LLM に任せきりにせず orchestrating via code(コードで分岐)も示されています。まず分類だけさせ、その結果に応じて次のエージェントをコード側で決める形で、速度・コスト・予測可能性を重視したいときに向きます。
役割分担が裏目に出る失敗パターン
ここが本記事のもう一つの主眼です。「分ければ良くなる」は幻想で、分け方を誤ると単体より悪化します。実務で繰り返し見る4パターンを、現象→原因→確認→回避の形で整理します。
失敗1：責務が重なり、二重作業と取りこぼしが同時に起きる
- 現象：調査役と実装役の両方が同じ仕様書を読み込み、しかも「設計判断」はどちらも自分の仕事ではないと判断して誰もやらない。出力は冗長なのに肝心の決定が抜ける。
- 原因：役割名(調査・実装)だけ決めて、境界(誰が何を決めるか) を決めていない。名前は役割を示すが責務は示しません。
- 確認：各エージェントへの指示文(システムプロンプト)を並べ、「同じ入力を読む役が2つ以上」「最終決定者が明記されていない」のどちらかに当てはまるかを見る。実行ログで同一資料の読み込みが複数スレッドに出ていれば確定。
- 回避：役割を「動詞+成果物」で書く(例:「実装役は、調査役が確定した設計に従いコードのみを書く。設計判断はしない」)。決定権を1か所に固定する。
失敗2：全員に同じ巨大コンテキストを持たせ、単体より重くなる
- 現象：分けたのに速くも安くもならない。むしろ単体より遅く、料金は数倍。
- 原因：分離のはずが、全サブへ同じ資料一式を毎回フルで渡している。マルチエージェントの利点である文脈の分離が消え、前述の「同じ資料を何度も買い直す」状態。
- 確認：API のレスポンスにある使用量(usage)で、各サブの入力トークンを合計し単体時と比較する。
cache_read_input_tokensがほぼ0なら、共有資料がキャッシュされず毎回フル単価で再計上されている。 - 回避：各役に「その役が本当に要る部分」だけを渡す。共有が避けられない前置きは プロンプトキャッシュ に載せ、読み出し単価(入力の約1/10)で再利用する。
失敗3：調整役が弱く、振り分けが崩れる
- 現象：オーケストレーターが曖昧な指示を曖昧なまま各サブへ流し、重複・漏れ・責任の押し付けが起きる。
- 原因：coordinator の質が全体品質を決めるのに、調整役のプロンプトと権限設計が手薄。「よしなに振り分けて」では振り分けられません。
- 確認：調整役の指示に、(a)分割の基準、(b)各サブへ渡す入力の選び方、(c)結果の統合方法、が明文化されているか。1つでも欠けていれば崩れる予兆。
- 回避：分割が自明でないなら、無理に LLM に任せず「コード主導の分岐型」へ切り替える。調整役は Opus 4.8 など上位モデルにし、サブは安いモデルに落としてコストと品質を両立させる。
失敗4：停止条件と観測がなく、青天井かつ原因不明になる
- 現象：レビュー差し戻しが延々続いて課金が止まらない。失敗してもどのエージェントで何が起きたか追えない。
- 原因：最大反復回数・予算上限・実行ログという3点が未設計。複数体になると、どこで失敗したかが単体より見えにくくなる。
- 確認：構成に「最大ステップ数」「予算上限」「各エージェントの入出力ログ」が揃っているかをチェック。1つでも無ければ事故の温床。
- 回避：最大反復回数(例:差し戻しは2回まで)と予算上限を必ず置く。各スレッドの入出力とトークン使用量を記録する。観測と安定運用の設計は ハーネスエンジニアリングとは？AIエージェントを安定運用する設計を整理 と密接につながります。
単体・マルチをどう選ぶか（意思決定表）
関連記事との差別化として、ここでは「全体像をどう判断するか」を1枚の表にします。タスクの性質から、まず単体で十分か、マルチならどの型か、を引けるようにしたものです。
| タスクの性質 | 推奨 | 理由 | コスト感 |
|---|---|---|---|
| 小さい要約・単純な変換・短いFAQ・1ステップで終わる作業 | 単体エージェント | 分けても制御ロジックとデバッグだけ増える。文脈受け渡しの無駄が利益を上回る。 | 最安(基準) |
| 工程が独立で並列に割れる調査・情報収集 | マルチ(オーケストレーター型) | 並列化が効く数少ない領域。Anthropic も調査タスクで単体を大きく上回ると報告。 | 単体の数倍〜十数倍 |
| 後工程が前工程に強く依存する実装・リファクタ | 原則 単体(必要時のみレビュー役を追加) | 密に依存する工程は並列化しにくく、分割の効果が薄い。実装は1体に集約し、独立した観点のレビューだけ分ける。 | 単体〜単体の約2倍 |
| 話題で担当が切り替わる顧客対応・サポート窓口 | マルチ(Handoff型) | 受付→専門担当のように主導権を渡す方が自然。並列ではなく直列の引き継ぎ。 | 単体の約2〜3倍 |
| 分類結果で次工程が決まる・速度と予測可能性が最優先 | マルチ(コード主導の分岐型) | 分岐をLLMに委ねず確定的にできる。調整役の暴走リスクを排除しつつ最小コスト。 | 単体の約1.5〜2倍 |
| 編集役と検証役で権限を分けたい(片方は read-only) | マルチ(権限分離) | レビュー役を読み取り専用にすると、誤編集の被害範囲を構造的に縮められる。安全面の意味が大きい。 | 単体の約2〜3倍 |
判断の順番は「①そもそも分ける必要があるか → ②並列に割れるか(割れないなら単体寄り) → ③直列の引き継ぎか分岐かで型を選ぶ → ④権限・停止条件・観測を必ず設計する」です。この順で考えると、過剰なマルチエージェント化をかなり防げます。
実務で見るポイント
マルチエージェントを入れる前に、次の問いを先に整理した方が安全です。
- 本当に役割分担が必要か(単体で完成度を上げる方が早くないか)
- どこを共有し、どこを分離するか(共有はキャッシュに載せられるか)
- 誰が最終判断を持つか(決定権は1か所に固定されているか)
- どのエージェントにどの権限を与えるか(検証役は read-only にできるか)
- 失敗時にどこで止めるか(最大反復・予算上限・ログがあるか)
この設計がないと、単体エージェントより説明しづらい失敗が増えます。マルチエージェントは「AIを増やす技術」ではなく「AIの仕事を分担する設計」だと捉えると、判断を誤りにくくなります。
マルチエージェントAIに関するよくある質問
Q. マルチエージェントは単体エージェントより常に優れていますか？
A. いいえ。コストと複雑さが増えるトレードオフがあります。Anthropic の計測では調査タスクで単体を90%超上回った一方、コストは通常チャットの約15倍に達しました。並列に割れないタスクや小さい作業では、単体の方が速く安く、デバッグも容易です。
Q. なぜ「単体の3〜5倍」もかかるのですか？
A. オーケストレーターが各サブへ文脈を渡すたびに、同じ資料が入力トークンとして再計上されるためです。本文の試算では、3役+1往復の差し戻しで単体の約4倍になりました。差し戻しが増えるほど文脈が周回し、さらに跳ねます。
Q. コストを抑える一番効く手は何ですか？
A. 3つあります。(1)調整役だけ Opus 4.8 にしてサブは Sonnet 4.6 や Haiku 4.5 に落とす、(2)各サブへ渡す共有資料を プロンプトキャッシュ に載せ入力の約1/10で再利用する、(3)最大反復回数を決めて差し戻しの無限ループを止める。特に(2)は入力側の累積を大きく削ります。
Q. 役割分担が一番崩れやすいのはどこですか？
A. 責務の境界です。役割名だけ決めて「誰が何を決めるか」を書かないと、二重作業と取りこぼしが同時に起きます。役割は「動詞+成果物」で書き、最終決定者を1か所に固定してください(本文の失敗1)。
Q. 暴走や青天井課金を防ぐには？
A. 最大ステップ数の上限、予算上限、重要操作の人間承認、実行ログの完全記録、各エージェントの最小権限、で多重に防御します。複数体になると失敗箇所が見えにくくなるため、各スレッドの入出力とトークン使用量の記録は必須です。
Q. 実装とレビューはどう分けるのが安全ですか？
A. 実装役のみ編集可、レビュー役は read-only にします。検証役から書き込み権限を外すと、誤った修正がそのまま反映される事故を構造的に防げます。レビューを別観点(別文脈)で回せる点も品質に効きます。なお複数モデルで相互採点させる構成は LLM-as-a-judge の考え方とも重なります。
Q. 開発に使えるフレームワークは？
A. Anthropic の Managed Agents(coordinator 構成)や OpenAI Agents SDK のほか、LangGraph、AutoGen、CrewAI などが定番です。セルフホスト+安全性重視か、マネージド+開発速度重視か、で選びます。どれを使っても「分けると課金が累積する」構造は同じなので、先にコスト試算をしてから着手してください。
まとめ
マルチエージェントとは、複数のAIエージェントに役割分担させて仕事を進める構成 です。価値が出やすいのは、工程が独立で並列に割れる調査、文脈を分離したいとき、権限を分けたいときです。
一方で、
- 分けた瞬間にトークンが累積し、単体の約3〜5倍は普通に起きる(公式の重い構成では約15倍)
- 並列に割れない実装系では効果が薄く、コストだけ増えやすい
- 責務の境界・共有情報・権限・停止条件・観測がないと、単体より遅く・高く・原因不明になる
という現実があります。本記事の試算表・失敗パターン・意思決定表を、着手前のチェックリストとして使ってください。
参考リンク
- Anthropic Engineering: How we built our multi-agent research system
- Anthropic Docs: Multiagent sessions
- Anthropic Docs: Session tracing / Observability
- Anthropic Docs: Pricing
- OpenAI Agents SDK: Orchestrating multiple agents
- OpenAI Agents SDK: Agents