マルチエージェントシステムの設計パターン【2026】5社公式ドキュメント横断で整理

単一のAIエージェントは動いた。次は複数のエージェントを協調させたい——そう調べ始めると、主要各社で用語がバラバラで、どの型を選ぶべきか、そもそもマルチにすべきかが分からなくなる。

本記事は5社の公式一次ドキュメントを横断し、「同じ型・違う名前」を対応付けて設計パターンを整理する。なお本記事が扱うのは設計パターン（型）の解説であり、どのフレームワーク製品を選ぶかはAIエージェントフレームワーク比較、組織としての導入プロセスはAIエージェント導入の進め方に譲る。

マルチエージェントシステムの設計パターンは、(1)集中オーケストレーター型＝管理役が下位エージェントへタスクを分配して結果を統合、(2)分散ハンドオフ型＝エージェント同士が制御を直接引き継ぐ、(3)ワークフロー型＝順次・並列・ループの固定フローに沿って実行、(4)協調・評価型＝グループチャットや評価ループで成果物を磨く、の4類型に整理できる。呼び名は各社で違っても型は共通だ。ただし採用の前は「マルチにするか」の判断が先だ。Anthropicはマルチエージェントがチャットの約15倍のトークンを消費すると公表し（社内評価の条件付き）、OpenAIは単一エージェントの能力最大化を先に行うよう公式ガイドで推奨している。

結論：マルチエージェントシステムとは＋5社対応マップ

マルチエージェントシステムとは、複数のAIエージェントが役割を分担し、協調して1つのタスクや業務を遂行するシステム構成である。単一エージェント（基礎はAIエージェントとはを参照）では扱いにくい並列性・専門分化・コンテキスト分離を実現する設計手法だ。

各社が定義するパターンは呼び名こそ違うが型は共通だ。独自統合の対応マップを示す。

型	各社の呼称（公式ドキュメント基準）
集中オーケストレーター型	Anthropic: orchestrator-workers ／ OpenAI: Manager（agents as tools）／ Google ADK: Collaborative（coordinator役）／ LangChain: Subagents ／ Microsoft: Magentic
分散ハンドオフ型	OpenAI: Decentralized（handoffs）／ LangChain: Handoffs ／ Microsoft: Handoff
ワークフロー型	Anthropic: prompt chaining・parallelization ／ Google ADK: Template workflows ／ LangChain: Custom workflow ／ Microsoft: Sequential・Concurrent
協調・評価型	Microsoft: Group Chat ／ Anthropic: Evaluator-optimizer・voting

注意点を1つ。各社の公式呼称は改訂が速い。Microsoftは旧AutoGenをAgent Frameworkに統合し、Google ADKは2.0で分類を再編、LangChainの現行分類はSubagents・Handoffs・Skills・Router・Custom workflowの5つだ。本記事は2026年6月時点の現行版基準で書いている。

設計パターン4類型

集中オーケストレーター型

管理役（オーケストレーター）がタスクを分解し、下位エージェントへ分配して結果を統合する構造だ。Anthropicの「orchestrator-workers」、OpenAIの「Manager（agents as tools）」、Google ADKのcoordinator役（Collaborative）、LangChainの「Subagents」、Microsoftの「Magentic」が同型にあたる。Anthropicは自社のリサーチシステムをこの型で構築し、Opus 4を管理役・Sonnet 4を下位エージェントとした構成が単一エージェントのOpus 4を社内のリサーチ評価で90.2%上回ったと公表する（Anthropic公式・社内評価の値）。タスクの分解が動的で、サブタスクを事前に予測できない調査系の業務に向く。

分散ハンドオフ型

中央の管理役を置かず、エージェント同士が会話の制御を直接引き継ぐ構造だ。OpenAIの「Decentralized（handoffs）」、LangChainの「Handoffs」、Microsoftの「Handoff」が同型にあたる。典型例は窓口エージェントが問い合わせを振り分け、専門エージェントへ会話ごと引き継ぐカスタマーサポートだ。集中型との使い分けは、「1つの統合された成果物が要るか（集中型）」「会話の主導権ごと専門家に渡すのが自然か（ハンドオフ型）」で判断する。

ワークフロー型（順次・並列・ループ）

実行順序を人間がコードで固定する構造だ。Anthropicのprompt chaining（順次）とparallelization（並列・投票）、Google ADKのTemplate workflows（sequence・loop・parallel）、Microsoftの「Sequential」「Concurrent」、CrewAIのProcess（sequential・hierarchical）がここに入る。Anthropicは「workflow（事前定義の経路を辿る）」と「agent（動的に自走する）」を別概念として区別しており、この区別が設計判断の出発点になる（出典：Anthropic公式）。手順が固定できる業務では、予測可能性とデバッグのしやすさでワークフロー型が優る。

協調・評価型（グループチャット・評価ループ）

複数のエージェントが同じ場で発言し合うMicrosoftの「Group Chat」と、生成役と評価役を分けて成果物を磨くAnthropicの「Evaluator-optimizer」がこの類型だ。複数案から多数決で選ぶ「voting」も同じ発想に接続する。品質基準が言語化できる文章・コードのレビューループに向く。

マルチにしない判断——コストと失敗研究

コスト：マルチはチャットの約15倍のトークンを消費する

Anthropicは公式に「エージェントはチャットの約4倍、マルチエージェントシステムはチャットの約15倍のトークンを典型的に消費する」と公表している（出典：Anthropic公式・原文は typically about）。マルチエージェントの性能向上は、トークン消費すなわちAPI費用と引き換えという構造だ。並列化で得られる価値が、この倍率に見合うかを最初に問う必要がある。

原則：単一エージェントの最大化が先

OpenAIは公式ガイドで、まず単一エージェントの能力を最大化し、足りない場合にのみ複数エージェントへ分割することを推奨する。Anthropicも「可能な限り最もシンプルな解決策から始める」「フレームワークの抽象化レイヤーはデバッグを困難にする」と公式に述べる。分割を検討するシグナルとして公式ガイドが挙げるのは、プロンプトの条件分岐が複雑化しすぎたとき、ツールが多すぎて選択を誤るようになったときだ。この兆候がないうちのマルチ化は早すぎる。

失敗研究：MASTの3カテゴリ14失敗モード

「マルチにすれば賢くなる」わけではないことは、定量研究でも示されている。UC Berkeley系の研究「Why Do Multi-Agent LLM Systems Fail?」（arXiv:2503.13657 v3）は、7フレームワーク・1,600超の実行トレースを分析し、失敗をMASTという分類体系——システム設計の不備・エージェント間の不整合・タスク検証の不足の3カテゴリ・14の失敗モード——に整理した。協調にはエージェント間の認識ずれや検証漏れという、単一構成にはない固有の失敗様式が増える。判断にはこの失敗コストも織り込む。

採用判断フローと実装の要点

採用判断フローチャート

一次情報を1本のフローに統合する。第一の問い: 単一エージェント＋ツール追加で足りないか（足りるならマルチにしない）。第二の問い: 手順が固定できるか（できるならワークフロー型）。第三の問い: 分解が動的で統合成果物が要るなら集中オーケストレーター型、会話の主導権を専門エージェントへ渡すのが自然なら分散ハンドオフ型。各分岐の判断材料は、約15倍のトークンコスト・単一最大化の原則・MASTの失敗様式だ。型が決まったあとの組織としての導入手順はAIエージェント導入の進め方で整理している。

実装の要点：役割定義と構造化ハンドオフ

どの型でも共通する実装の要点が3つある。(1)各エージェントの役割と管轄を文書で固定する、(2)エージェント間の受け渡しを口頭的なプロンプトではなく、依頼書・成果物といった構造化された形式で行う、(3)管轄外のタスクは引き受けず担当エージェントへ誘導させる。当社でも戦略・制作・公開オペレーションなどを分担するAIエージェント群を実運用しており、連携精度を保つ要はこの「役割の文書化と依頼書形式の受け渡し」だと実感している。なお、エージェントと外部ツールの接続を共通化する標準仕様としてはMCPがあり、MCPとはで入門解説している。

Q1. マルチエージェントシステムとは何ですか？

複数のAIエージェントが役割を分担し、協調して1つのタスクを遂行するシステム構成です。単一エージェントでは扱いにくい並列性・専門分化・コンテキスト分離を実現する設計手法です。

Q2. エージェントの協調パターンには何がありますか？

集中オーケストレーター型・分散ハンドオフ型・ワークフロー型（順次・並列・ループ）・協調/評価型の4類型に整理できます。各社で呼び名は違いますが、型は共通しています。

Q3. オーケストレーター型とは何ですか？

管理役のエージェントがタスクを分解して下位エージェントに分配し、結果を統合する型です。Anthropicのorchestrator-workers、OpenAIのManager、Google ADKのcoordinator役、LangChainのSubagents、MicrosoftのMagenticが同じ型にあたります。

Q4. マルチエージェントとシングルエージェントはどちらを選ぶべきですか？

まず単一エージェントの能力を最大化するのが先、というのが主要ベンダー公式の共通見解です。マルチエージェントはチャットの約15倍のトークンを消費するとAnthropicが公表しており（社内評価・条件付き）、タスクの分解が動的で並列の価値が大きい場合に限って採用します。

Q5. マルチエージェントシステムはなぜ失敗しますか？

失敗研究MASTは、システム設計の不備・エージェント間の不整合・タスク検証の不足の3カテゴリ・14の失敗モードに分類しています（arXiv:2503.13657 v3）。協調そのものに固有の失敗様式があります。

まとめ

マルチエージェントの設計パターンは、集中オーケストレーター型・分散ハンドオフ型・ワークフロー型・協調/評価型の4類型に整理でき、5社の公式呼称は違っても型は共通している。そして設計の第一歩はパターン選びではなく「マルチにするか」の判断だ。約15倍のトークンコスト、単一エージェント最大化の原則、MASTが示す固有の失敗様式——この3つを織り込み、分解が動的なタスクに絞って採用するのが一次情報に忠実な設計だ。各社のドキュメントは改訂が速いため、実装時は必ず現行版を確認してほしい。

---

どのフレームワークで実装するかはAIエージェントフレームワーク比較、組織としての導入手順はAIエージェント導入の進め方、エージェントとツールの接続標準はMCPとはも参考にしてください。