結論：マルチエージェントの協調方式は「スーパーバイザ型」「パイプライン型」「スウォーム型」の3つに大別でき、タスクの予測可能性とデバッグのしやすさを軸に選ぶのが基本です。
- 要点1：手順が事前に決まっている定型処理はパイプライン型、サブタスクの内容が入力次第で変わる複雑なタスクはスーパーバイザ型が出発点として適しています（Anthropic公式ブログ「Building Effective Agents」の分類に基づく）。
- 要点2：学術研究MAST（UC Berkeley Sky Computing Lab, 2025）は、MetaGPT・ChatDev・AG2・Magentic-Oneなど7つの実運用マルチエージェントフレームワークの失敗を分析し、仕様問題(41.77%)・エージェント間の不整合(36.94%)・タスク検証の不備(21.30%)の3カテゴリに分類しています。
- 要点3：どのパターンでも「最大ステップ数のハード上限」「トレースログの永続化」「人間へのエスカレーション経路」の3つを実装しないと、本番で暴走・沈黙タスクが発生しやすくなります。
対象読者：複数のAIエージェントを協調させるシステムを設計・実装する開発者、PM。
今日やること：今動かしているマルチエージェント構成が3パターンのどれに当てはまるかを確認し、終了条件のハード上限が入っているかをチェックする。
「サブエージェントを増やしたのに、かえって遅くなった上に何が起きているか分からなくなった」——AIエージェントの導入支援をしていると、こういう相談を受ける機会が増えている。
原因の多くは、エージェントの数を増やす前に「どう協調させるか」の設計を決めていないことにある。1つのLLMに全部やらせる方式で頭打ちになったチームが、いきなり複数のサブエージェントを並べてみたものの、誰が何の判断をして、どこで処理を止めるべきかが曖昧なまま本番に出してしまうケースが典型だ。
マルチエージェントの協調方式には、大きく分けて「スーパーバイザ型」「パイプライン型」「スウォーム型」という3つの基本アーキテクチャがある。この記事では、それぞれの仕組みと向き不向きを、Anthropic・Google・OpenAI・AWSなど各社の公式ドキュメント、そして学術研究が明らかにした失敗パターンをもとに整理する。
まず押さえたい「3つのアーキテクチャ」の全体像
マルチエージェント設計の議論は流派によって呼び方が揺れるが、実務上は次の3タイプに整理すると見通しがよい。Anthropicが公式に紹介している「Orchestrator-Workers」パターンはスーパーバイザ型の代表例であり、同社は他にもPrompt Chaining（パイプライン型の原型）、Routing、Parallelization、Evaluator-Optimizerという5つのワークフローパターンを提示している。本記事ではこのうち複数エージェントの協調に直結する3パターンに絞って比較する。
| 観点 | スーパーバイザ型 | パイプライン型 | スウォーム型 |
|---|---|---|---|
| 制御構造 | 中央集権（1つのLLMが判断・委譲） | 固定順の直列実行 | 分散・エージェント間ハンドオフ |
| タスクの予測可能性 | 低〜中（動的に分解される） | 高（処理順序が決まっている） | 低（次の担当が動的に決まる） |
| デバッグのしやすさ | 中（supervisorのログを追えばよい） | 高（各ステージが独立して検証できる） | 低（分散トレースの整備が必須） |
| レイテンシ傾向 | 中〜高（判断のたびにLLM呼び出しが発生） | 予測しやすい（ステージ数が固定） | 可変（ホップ数に依存） |
| 向いているタスク例 | サブタスクの内容が事前に読めない複雑タスク（コード修正、リサーチ） | fetch→clean→analyze→summarizeのような定型多段処理 | 専門特化エージェント同士が対等な立場で協業する場面 |
| 代表的な実装例 | LangGraph Supervisor、CrewAI Hierarchical Process | Google ADKのSequentialAgent、CrewAI Sequential Process | OpenAI Agents SDKのHandoffs、AWS Strands AgentsのSwarm |
パターン1：スーパーバイザ型（中央集権オーケストレーション）
スーパーバイザ型は、中央の1エージェント（supervisor／orchestrator）がタスクを解釈し、専門化されたworkerエージェントに動的にサブタスクを割り振る方式だ。LangGraphの公式リファレンスでは、supervisorノードは自分ではタスクを実行せず、LLMの判断に基づいてどのworkerを呼ぶか・いつ終了するかだけを決める設計が推奨されている。CrewAIでも同様の考え方が「Hierarchical Process」として実装されており、manager_llmまたはmanager_agentを指定するとタスクの割り振り・レビューを中央のマネージャーが担う。
Anthropicが紹介するOrchestrator-Workersワークフローも同じ発想で、「事前にサブタスクの数や内容を予測できない」複雑なタスクに向くとされている。コーディングタスクを例に挙げると、修正が必要なファイル数や変更内容はタスクごとに変わるため、固定の手順書（パイプライン）では対応しきれない。こうしたケースでは、中央のLLMがその場で計画を立て直せるスーパーバイザ型が有効に働く。
# 動作環境: Python 3.11+
# 概念実装（特定SDKに依存しないフレームワーク非依存の最小実装）。
# 本番環境で使用する前に、必ずテスト環境で動作確認してください。
from dataclasses import dataclass
from typing import Callable
@dataclass
class Worker:
name: str
run: Callable[[str], str]
def supervisor_loop(task: str, workers: list[Worker], llm_route, max_steps: int = 5) -> str:
"""中央のsupervisorがタスクを解釈し、適切なworkerに委譲するループ。
max_stepsは暴走防止のためのハード上限（省略しないこと）。"""
history = []
for _ in range(max_steps):
decision = llm_route(task, history, [w.name for w in workers])
if decision["action"] == "finish":
return decision["result"]
worker = next(w for w in workers if w.name == decision["worker"])
result = worker.run(decision["subtask"])
history.append({"worker": worker.name, "subtask": decision["subtask"], "result": result})
raise RuntimeError("max_stepsに到達: supervisorが終了判断を出せていない")
ポイント: max_stepsのようなハード上限を入れないと、supervisorが「もう一度別のworkerに聞いてみよう」を繰り返して停止しない事故が起きる。この点は後述の失敗パターンでも詳しく扱う。
パターン2：パイプライン型（逐次処理）
パイプライン型は、あらかじめ決まった順序でエージェント（またはステージ）を直列に並べ、前段の出力をそのまま次段の入力として渡す方式だ。Google ADKの公式ドキュメントでは、この構造はSequentialAgentとして提供されており、fetch→clean→analyze→summarizeのような多段処理の変換チェーンに最適だと説明されている。CrewAIの「Sequential Process」もタスクリストの順番どおりに実行する、最もシンプルで既定のプロセスタイプだ。
パイプライン型の強みは処理順序が固定されているため、各ステージを独立してテストでき、デバッグもしやすい点にある。一方で、入力次第でステージの数や順序自体を変えたいタスクには向かない。「サブタスクが事前に読めるか」がスーパーバイザ型との分岐点になる。
# 動作環境: Python 3.11+
# 概念実装。各ステージの出力を次ステージの入力にそのまま渡す固定順パイプライン。
# 本番環境で使用する前に、必ずテスト環境で動作確認してください。
from typing import Callable
def run_pipeline(input_data: str, stages: list[Callable[[str], str]]) -> str:
data = input_data
for i, stage in enumerate(stages):
try:
data = stage(data)
except Exception as e:
# パイプライン型は1ステージの失敗が即座に全体停止につながるため、
# どのステージで落ちたかを必ずログに残す
raise RuntimeError(f"stage {i} ({stage.__name__}) で失敗: {e}") from e
return data
# 例: fetch_data -> clean_data -> analyze_data -> summarize の4ステージ
# result = run_pipeline(raw_query, [fetch_data, clean_data, analyze_data, summarize])
ポイント: パイプライン型は「見た目のシンプルさ」に反して、1ステージの検証漏れが全体の品質を落としやすい。ステージ間のデータ受け渡しにバリデーションを挟む重要性は、失敗パターンの章で改めて触れる。
パターン3：スウォーム型（分散協調）
スウォーム型は、中央の制御役を置かず、各エージェントが「このタスクは自分が処理するか、それとも別の誰かに渡すか」を自律的に判断する方式だ。OpenAIが2024年に公開した教育目的のフレームワーク「Swarm」は、まさにこの発想を体現しており、各エージェントが軽量なハンドオフ（引き渡し）だけを判断すればよく、タスク全体の分解計画を把握する必要がないという設計思想だった。Swarmはその後開発が終了し、現在は本番運用向けのOpenAI Agents SDKに置き換わっているが、SDK内の「Handoffs」機能として同じ考え方が引き継がれている。
AWSのStrands Agentsも公式ドキュメントで同様の「Swarm」パターンを提供しており、エージェント同士が共有コンテキストとワーキングメモリを介して自律的に協調する設計を紹介している。分散型は単一障害点（supervisorのボトルネック）を避けられる反面、システム全体の挙動が予測しづらく、デバッグや可観測性のコストが上がる点がトレードオフになる。
# 動作環境: Python 3.11+
# 概念実装。中央制御を置かず、各エージェントが「次に誰に渡すか」だけを自律判断する。
# 本番環境で使用する前に、必ずテスト環境で動作確認してください。
from dataclasses import dataclass
from typing import Callable, Optional
@dataclass
class SwarmAgent:
name: str
handle: Callable[[str, dict], tuple[Optional[str], Optional[str]]]
# handle(task, shared_state) -> (result_or_None, next_agent_name_or_None)
def run_swarm(task: str, agents: dict[str, SwarmAgent], start: str, max_handoffs: int = 8):
shared_state: dict = {}
current = start
for _ in range(max_handoffs): # 暴走防止: ここも必ず上限を設ける
agent = agents[current]
result, next_agent = agent.handle(task, shared_state)
if next_agent is None:
return result
current = next_agent
raise RuntimeError("max_handoffsに到達: エージェント間のハンドオフが収束していない")
ポイント: 「誰も引き受けられないタスクが宙に浮く」のはスウォーム型に特有のリスクだ。どのエージェントも処理できない場合の明示的なデフォルトルート（人間へのエスカレーション等）を用意しておく必要がある。
どのパターンを選ぶべきか — 判断基準
3パターンは排他的ではなく、実際の本番システムでは組み合わせて使われることが多い。判断の出発点としては、次の2つの質問が役に立つ。
- タスクの手順は事前に決まっているか？ 決まっているならパイプライン型、入力によって必要なサブタスクが変わるならスーパーバイザ型かスウォーム型を検討する。
- 中央の判断役を置くべきか、置きたくないか？ 1箇所でポリシー・権限・監査ログを一元管理したいならスーパーバイザ型、専門特化したエージェント同士を疎結合に保ちたいならスウォーム型が候補になる。
OpenAIも設計原則として「まず1つのエージェントから始め、専門化がケイパビリティの分離・ポリシーの分離・プロンプトの明確化・トレースの可読性のいずれかを明確に改善する場合だけ分割する」ことを推奨している。エージェントを増やすほどプロンプト数・トレース数・承認ポイントが増え、複雑さのコストが積み上がる点は3パターン共通の注意点だ。フレームワーク別の具体的な機能比較はAIエージェントツール比較完全ガイドも参考にしてほしい。
【要注意】マルチエージェントが壊れる典型パターン（学術研究から）
UC BerkeleyのSky Computing Labなどの研究グループが2025年に公開した論文「Why Do Multi-Agent LLM Systems Fail?」（通称MAST）は、MetaGPT・ChatDev・HyperAgent・AppWorld・AG2・Magentic-One・OpenManusという7つの実運用マルチエージェントフレームワークについて、200件以上のタスク・トレースを専門家6名が分析し、失敗を14種類・3カテゴリに分類した研究だ。カテゴリ別の出現率（論文Figure 2、2026年7月時点で確認）は次のとおり。
| カテゴリ | 内容 | 出現率 |
|---|---|---|
| 仕様問題（Specification Issues） | タスク仕様・役割仕様からの逸脱、終了条件の未認識など | 41.77% |
| エージェント間の不整合（Inter-Agent Misalignment） | エージェント同士の発言と行動の不一致、意思疎通の失敗など | 36.94% |
| タスク検証の不備（Task Verification） | 上流の出力を下流が十分に検証せず進めてしまう | 21.30% |
この分類を踏まえて、パターン別によくある失敗を整理する。
失敗1：終了条件をLLMの自己申告だけに任せる（スーパーバイザ型）
❌ 「タスクが終わったらfinishと言って」とプロンプトで指示するだけで済ませる
⭕ 最大ステップ数のハード上限に加えて、「同じworkerへの委譲が3回連続したら強制終了」のような機械的な停止条件を併用する
なぜ重要か：MASTが指摘する「ステップの反復」（FM-1.3、単独の失敗モードとして約17%と高頻度で観測）は、supervisorが同じ処理を繰り返して収束しないケースを指す。自己申告に頼った終了判定は本番で最も壊れやすい箇所だ。
失敗2：前段の出力を無検証で次段に渡す（パイプライン型）
❌ ステージ1の出力をそのままステージ2の入力にする
⭕ 各ステージの出力に軽量なバリデーション（スキーマチェック・空文字チェック・想定外フォーマットの検知）を挟む
なぜ重要か：MASTの「タスク検証の不備」カテゴリ（21.30%）は、上流の出力を下流が確信度高く鵜呑みにしてしまう失敗を指す。パイプライン型は構造上、1ステージの検証漏れがそのまま最終出力の品質低下に直結する。
失敗3：誰も引き受けないタスクが宙に浮く（スウォーム型）
❌ 「わからなければ誰かに投げる」というルールだけで設計する
⭕ どのエージェントも処理できない場合に「人間にエスカレーションする」という明示的なデフォルトルートを必ず用意する
なぜ重要か：分散設計は単一障害点がない代わりに、責任の所在が曖昧になりやすい。MASTの「エージェント間の不整合」カテゴリ（36.94%）には、こうした連携不全に起因する失敗が含まれている。
失敗4：あいまいな指示のまま処理を進めてしまう（3パターン共通）
❌ 不足情報があっても、エージェントが推測で処理を続行する
⭕ 「不足している情報があれば、最初に質問してから作業を開始する」というルールを全エージェント共通のシステムプロンプトに入れる
なぜ重要か：MASTでは「明確化要求の失敗」（FM-2.2）も代表的な失敗モードの1つとして報告されている。曖昧な指示のまま処理が進むと、パターンを問わず後工程での手戻りコストが大きくなる。
実装時のチェックリスト — 本番投入前に確認すべきこと
- 終了条件・最大ステップ数／最大ハンドオフ数をハード上限で設定しているか
- 各エージェント・各ステージの入出力をトレースとして永続化しているか（デバッグ可能性の担保）
- supervisorやhandoffの判断プロンプトに「不明な場合は人間にエスカレーション」を明示しているか
- コスト予算（トークン数・呼び出し回数）に上限を設け、超過時にアラートが飛ぶか
- エージェント間・ステージ間のデータ形式をスキーマで固定し、想定外フォーマットを弾いているか
- 本番投入前にカナリア／シャドーモードで実トラフィックの一部だけを流して検証したか
# 動作環境: Python 3.11+
# 暴走防止の最小ガードレール例（3パターンいずれにも共通して使い回せる）
# 本番環境で使用する前に、必ずテスト環境で動作確認してください。
import logging, time
logger = logging.getLogger("agent.orchestration")
def with_guardrails(fn, *, max_seconds=60, max_calls=20):
calls = {"n": 0}
def wrapped(*args, **kwargs):
calls["n"] += 1
if calls["n"] > max_calls:
logger.error("guardrail: max_calls超過のため強制停止")
raise RuntimeError("max_calls exceeded")
start = time.monotonic()
result = fn(*args, **kwargs)
elapsed = time.monotonic() - start
if elapsed > max_seconds:
logger.warning(f"guardrail: 1呼び出しが{elapsed:.1f}s（想定超過）")
return result
return wrapped
リトライ・フォールバック・タイムアウトといった個々のエージェントの信頼性設計をさらに詳しく実装したい場合は、本番で落ちないAIエージェントの作り方｜信頼性設計で具体的なPython実装を解説している。
よくある質問
Q1. マルチエージェントは単一エージェントより必ず優れているのですか？
いいえ。OpenAIも「まず1つのエージェントから始め、専門化が明確に効果を持つ場合だけ分割する」ことを推奨している。エージェントを増やすほどプロンプト数・トレース数・承認ポイントが増え、複雑さのコストが積み上がる。
Q2. スーパーバイザ型とパイプライン型、どちらから試すべきですか？
タスクの手順が事前に決まっている定型処理（fetch→clean→analyze→summarizeのような多段処理）ならパイプライン型、サブタスクの内容や数が入力次第で変わる複雑なタスクならスーパーバイザ型が出発点として適している。
Q3. スウォーム型はどんな場面で使うべきですか？
専門特化したエージェント同士が対等な立場で協業し、中央のボトルネックを避けたい場合に向く。ただし分散システムはデバッグ・可観測性のコストが上がるため、小規模なチームがいきなり採用するのはおすすめしにくい。
Q4. LangGraph・CrewAI・Google ADK・OpenAI Agents SDKはどれを選べばいいですか？
個別ツールの選定は本記事の範囲外だが、パターンとの対応関係としてはLangGraph SupervisorとCrewAIのHierarchical Processがスーパーバイザ型、Google ADKのSequentialAgentとCrewAIのSequential Processがパイプライン型、OpenAI Agents SDKのHandoffsとAWS Strands AgentsのSwarmがスウォーム型に近い実装になる。
Q5. マルチエージェントの失敗はどう検知すればいいですか？
MAST研究が指摘する「ステップの反復」のような失敗は、最大ステップ数の上限設定とトレースログの監視で早期に検知できる。障害対応・オンコール運用の実装をさらに詳しく知りたい場合はAIエージェント障害対応・オンコール運用ガイドを参照してほしい。
参考・出典
- Building Effective Agents — Anthropic公式ブログ（参照日: 2026-07-18）
- Workflow Agents — Google Agent Development Kit公式ドキュメント（参照日: 2026-07-18）
- Developer’s guide to multi-agent patterns in ADK — Google Developers Blog（参照日: 2026-07-18）
- LangGraph Multi-Agent Supervisor — LangChain公式リファレンス（参照日: 2026-07-18）
- Orchestrating multiple agents — OpenAI Agents SDK公式ドキュメント（参照日: 2026-07-18）
- Handoffs — OpenAI Agents SDK公式ドキュメント（参照日: 2026-07-18）
- openai/swarm — OpenAI公式GitHub（教育目的フレームワーク、アーカイブ済み。参照日: 2026-07-18）
- Processes — CrewAI公式ドキュメント（参照日: 2026-07-18）
- Swarm Multi-Agent Pattern — AWS Strands Agents公式ドキュメント（参照日: 2026-07-18）
- Why Do Multi-Agent LLM Systems Fail? — UC Berkeley Sky Computing Lab（MAST論文、参照日: 2026-07-18）
まとめ：今日から始める3つのアクション
- 今日やること：今動かしている（または設計中の）マルチエージェント構成が、スーパーバイザ型・パイプライン型・スウォーム型のどれに当てはまるかを言語化する。
- 今週中：終了条件のハード上限とトレースログの永続化が実装されているかをチェックリストで確認し、抜けていれば追加する。
- 今月中：カナリア／シャドーモードで一部トラフィックだけに新しいオーケストレーション構成を流し、失敗パターン（ステップの反復・検証不備・エスカレーション漏れ）が出ていないかを観測する。
あわせて読みたい:
【2026年最新】Claude Agent SDK サブエージェント実装ガイド — 階層的なサブエージェント生成をコード付きで解説
AIエージェント ガバナンス・権限設計2026 — supervisor型で権限ポリシーを一元管理する際の実装フレーム
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（旧Twitter）で活用法を発信（@SuguruKun_ai、フォロワー10万人超）。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』累計3万部突破。
この記事を読んでマルチエージェント設計の全体像が見えてきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
