マルチエージェントとは？——複数のAIを協調させる設計パターンと、いつ使うべきか

2026年、AIエージェントを語るときの主役は「1体のスーパーエージェント」から「役割の違うエージェントのチーム」へと移った。Anthropic の Research 機能、Claude Code のサブエージェント、Devin のエンジニアチーム、Cursor の並列ワーカー——いずれも複数のAIを協調させるアーキテクチャを採用している。

本記事では、マルチエージェントとは何かを定義から始めて、主要アーキテクチャパターン、本番フレームワーク比較、実例、コスト構造、そして「いつ使うべきで、いつ使うべきでないか」までを最新動向ベースで整理する。「とりあえずマルチにすれば賢くなる」という幻想を解いて、設計判断の基準を持って帰ってほしい。

1. マルチエージェントとは何か

マルチエージェントシステム（Multi-Agent System, MAS）とは、複数のAIエージェントが協調して1つのタスクを解くアーキテクチャのこと。それぞれのエージェントは独自のプロンプト・ツール・コンテキストを持ち、メッセージや結果のやり取りを通じて全体目標を達成する。

基本となる「1体のエージェント」は、AIエージェントの記事で解説した通り、「知覚→推論→行動→観察」のループを単独で回す存在だ。マルチエージェントはここに役割分担と並列性を加えたものと考えるのがいちばん近い。

シングルエージェントとの違い

2. なぜ複数のAIを協調させるのか

「1体で全部できるなら、それでいい」が出発点だ。マルチエージェントが必要になる理由は、シングルが構造的に苦手な3つの壁にある。

マルチエージェントは 「コンテキスト分離 × 並列化 × 役割特化」 の3点セットでこれらを越える。実際 Anthropic の Research 機能では、リード・リサーチャーが計画を立て、複数のサブエージェントが 並列に 異なる側面を調査し、結果を集約することで シングルエージェント比で約90%の品質向上を達成したと報告している。

3. 主要アーキテクチャパターン5つ

マルチエージェントの構造には、いくつかの「型」がある。フレームワークごとに名前は違うが、本質的にはこの5パターンに収束する。

3-1. オーケストレータ・ワーカー型（最も普及）

1体の「司令塔（オーケストレータ／リードエージェント）」がタスクを分解し、複数の「ワーカー（サブエージェント）」に並列に割り振る。各ワーカーは独立したコンテキストで動き、結果を司令塔に返す。司令塔が集約して最終出力。

採用例: Anthropic Research、Claude Code subagents、OpenAI Agents SDK の典型構成。

3-2. ハンドオフ型（OpenAI Swarm系統）

エージェント同士が 明示的に「次はあなたに任せる」と制御を渡す 形。会話履歴とコンテキストが手から手へ移っていく。チケットの担当者リレーに似た構造で、サポートデスクのエスカレーションフローなどに向く。

採用例: OpenAI Agents SDK（旧 Swarm の継承）。

3-3. 階層型（チームのチーム）

司令塔の下にさらに「中間マネージャー」エージェントを置き、その下にワーカー群を置く木構造。大規模システムで使われ、Cognition の Devin がこのパターンを採用していると報告されている。深さが増すほどコストとレイテンシも増えるため、層は2〜3段が現実的な上限。

3-4. ピアツーピア型（討論・合意）

司令塔がなく、複数のエージェントが 対等な立場で議論 し、合意に達するまで反復する。Multi-Agent Debate として研究されており、回答の事実性・推論の堅牢性を上げる効果が報告されている。実装はやや高度で、実用では限定的。

3-5. パイプライン型（ワークフロー）

「調査 → 構造化 → 検証 → 出力」のように 固定された順序 で各エージェントを通す。LangGraph がグラフ構造で得意とする領域。動的判断は減るが、再現性とデバッグ性が高い。本番運用で最も安定する型でもある。

4. 主要フレームワーク比較

2026年時点、マルチエージェント開発の主役は4つのフレームワークに収束している（中小フレームワークの淘汰が進んだ）。

本番運用で見ると、Claude Agent SDK・OpenAI Agents SDK・LangGraph・Strands が四強。CrewAI と AutoGen は学習・PoCには向くが、エンタープライズの本番採用例は前者4つに集中している。

5. 本番運用されている実例

Anthropic Research（Claude.ai 内）

Claude.ai のリサーチ機能は典型的なオーケストレータ・ワーカー型。リード・リサーチャーがユーザーの質問を分解し、複数のサブエージェントが並列に異なる側面（企業情報・時系列・技術詳細など）を調査、結果を集約してレポートを返す。Anthropic の公式エンジニアリングブログで詳細が公開されており、シングルエージェント版より約90%の精度向上を報告している。

Claude Code subagents

Claude Code では、長時間タスクを 役割の違うサブエージェント に委ねられる。例: メイン Claude が計画を立て、調査担当サブエージェント が複数ファイルを並列に読み、実装担当サブエージェント がパッチを書く。各サブエージェントは 独自の context window を持つので、メインのコンテキストを圧迫しない。

Devin（Cognition）

Cognition の自律エンジニアリング Devin は、階層型のマルチエージェント構成と報告されている。プロジェクトマネージャー的な親エージェントの下に、専門領域別のチームが並列に動く。複雑な PR やマイグレーション作業をエンドツーエンドで完遂するために、この深さが要る。

Cursor の並列ワーカー

Cursor は最近の更新で、複数ファイルにまたがる変更を 並列のサブエージェント に分担させる機能を強化した。1体のエージェントがファイルを順に処理する代わりに、領域ごとに別エージェントが並走する。

6. コストとトレードオフ——15倍トークンの現実

「マルチにすれば賢い」を信じる前に、コスト構造を理解しておく必要がある。Anthropic 自身の報告では、マルチエージェントシステムは標準のチャット利用比で約15倍のトークンを消費する。

つまりマルチエージェントは「コストに見合うアウトプットの価値があるタスク」にのみ正当化される。Anthropic の表現を借りれば、「コストに比してアウトプットの価値が高い、複雑な調査タスク」が想定ユースケースだ。

7. いつ使う・いつ使わない

マルチを選ぶべきケース

• 並列調査: 「10サイトを同時に調べてレポート化」「複数の API を並行で叩いて統合」など、並列性が直接的な価値を生む
• 長時間自律タスク: 1セッションのコンテキスト窓を超える作業量。役割を分けないとコンテキスト汚染で精度が落ちる
• 専門性の異質性: 「コードを書く」と「コードをレビューする」を同じエージェントが両方やると批評性が下がる。役割分離が品質に直結
• ビジネス価値が高い1回完遂タスク: 監査レポート、戦略分析、複雑な技術調査など、コストに見合うアウトプット

マルチを選ぶべきでないケース

• 明確で順次的なタスク: 「このコードを直して」「この文書を要約して」など、シングルで普通に終わる作業
• レイテンシ重視のサービス: チャットボット・カスタマーサポートの一次応答など、即応性が要件
• コスト重視のバッチ処理: 大量にこなす定型タスク。マルチ化すると単価×倍率で破綻する
• デバッグ・運用リソースが少ない組織: マルチは複雑性が指数的に上がる。チームが持ち堪えられないなら、シングルから始めるべき

業界の合言葉は 「Start with one agent, add more only when you have a clear reason」——「1体から始めて、明確な理由があるときだけ増やせ」。これが2026年の本番運用エンジニアの共通見解だ。

8. 設計のベストプラクティス

「使うべき」と判断したあと、設計で躓きやすいポイントを Anthropic の公開資料を中心に整理する。

① サブエージェントには「目的・出力形式・ツール・境界」を明確に渡す

サブエージェントの失敗の多くは「指示が曖昧で、別タスクまで拡張する」「出力フォーマットが揃わず集約できない」という形で起きる。Anthropic の指針: 各サブエージェントには (1) 明確な目的、(2) 期待する出力形式、(3) 使ってよいツールと情報源、(4) タスクの境界 を明示せよ。

② 「努力レベル」を明示する

サブエージェントは「どれくらい掘り下げるべきか」を自力で判断するのが苦手。「1ホップ調査」「徹底検証」「既知情報のみで推測」 など、エフォート水準をプロンプトに埋め込む。Claude Opus 4.7 の xhigh や task budgets（ベータ） はまさにこの問題への公式対応。

③ オーケストレータには「集約と矛盾解決」を任せる

サブエージェントの結果は 互いに矛盾する ことがある（同じ事実を違う角度で報告するなど）。オーケストレータの仕事の半分は「矛盾を解消し、整合的な単一の答えにまとめる」こと。集約ロジックを軽視すると、マルチ化のメリットが消える。

④ 観測性を最初に作る

マルチエージェントは 何が起きているか追えない と即破綻する。各サブエージェントの入出力・所要時間・トークン消費・呼び出されたツールを 最初からログ化。LangGraph や Strands は観測性に強い設計で、本番採用される理由のひとつだ。

⑤ シングルから始めて、ボトルネックを見てから分割

最初からマルチを設計するな。まずシングルで動かし、明確に「ここが壁」と分かってからその箇所だけサブエージェント化する。リファクタリングと同じ発想で十分。

まとめ

• マルチエージェントは「複数のAIが役割分担＋並列で動く」アーキテクチャ。コンテキスト汚染・並列性欠如・役割混線というシングルの3つの壁を越える
• 主要パターンはオーケストレータ・ワーカー、ハンドオフ、階層、ピアツーピア、パイプラインの5つ。最も普及しているのはオーケストレータ・ワーカー型
• 主要フレームワークは Claude Agent SDK、OpenAI Agents SDK、LangGraph、Strands の四強に収束
• コストは2〜15倍。レイテンシも +30〜50%。安易な多用は経済的に間違い
• 判断基準: 並列性・専門性・長時間タスクのどれかが必須ならマルチ。それ以外はシングルで十分
• 設計の鉄則: シングルから始めて、ボトルネックが見えた箇所だけ分割する

FAQ

Q1. マルチエージェントは「賢いシングルエージェント」より必ず優れているのか？

違う。Anthropic の Research は約90%精度向上を示したが、それは「複雑な並列調査」という得意領域での話。明確で順次的なタスクではシングルのほうが速くて安く、結果も同等以上になる。タスクの性質次第。

Q2. 自分でマルチエージェントを作るには、どのフレームワークから始めるべき？

用途による。Claude を使うなら Claude Agent SDK（公式・サブエージェント＋Hooks）、OpenAI 中心なら Agents SDK、複雑な分岐ロジックを表現したいなら LangGraph、AWS 上で本番運用するなら Strands。学習目的なら CrewAI が概念把握に向く。

Q3. シングルエージェントから段階的にマルチに移行できるか？

できる。多くの本番システムはこのパターン。まずシングルで MVP を作り、コンテキスト窓の限界・レイテンシ・専門性の必要性が見えてきた箇所だけサブエージェント化していく。最初から全部マルチに設計するのは推奨されない。

Q4. マルチエージェント間の通信プロトコルに標準はあるか？

2026年時点で MCP（Model Context Protocol） が事実上の標準になりつつある。Anthropic 発で、現在は OpenAI・Microsoft・AWS なども採用。エージェント間およびエージェント／ツール間の共通インターフェースとして広く使われる。ACP（Agent Communication Protocol） という標準化提案もあるが、まだ実装は少ない。

Q5. マルチエージェントの失敗パターンで一番多いのは？

(1) 観測性の欠如（何が起きているか追えない）、(2) サブエージェントの指示が曖昧で結果が集約できない、(3) コストの暴発。とくに (3) は、ループに入ったサブエージェントが API を叩き続けてクラウド費用が一晩で1桁増えるという事故が頻発している。タスクバジェット（コスト・時間の上限）を必ず設定すること。

Q6. マルチエージェントは AGI（汎用AI）に近づく道なのか？

研究者の意見は分かれる。「役割分担と協調は知能の本質」とする立場と、「単一モデルのスケーリングが本質で、マルチはエンジニアリング上の便法に過ぎない」とする立場の両方が有力。実用上は 「現時点で実現可能なAIタスクの幅を広げる手段」 として位置付けるのが穏当。

Q7. シングル vs マルチ以外に「中間」の選択肢はあるか？

ある。「シングルエージェント＋ツールとしてのサブエージェント」 という形。Claude Agent SDK の Task ツールがまさにこれで、メインは1体のままだが、必要に応じて使い捨てのサブエージェントを呼び出す。フルマルチほどの複雑性はなく、シングルの限界を一部突破できる中庸な選択肢として人気。