※この記事にはアフィリエイトリンクが含まれる場合があります。
単一エージェントでも十分に動くシステムは多いものの、規模が大きくなったり、品質と速度を両立させたい場面では「複数のエージェントを協調させる」設計に踏み込む価値があります。2026年5月時点では、Claude Agent SDKのサブエージェント機能、LangGraph、AutoGenなどが整い、マルチエージェント開発のハードルは大きく下がりました。
一方で、安易に複数エージェント化すると、コンテキストロス、無限ループ、コスト爆発という3大事故が必ず起きます。本記事では、主要5パターンの使い分けと、通信モード、失敗モード対策までを実装目線で整理します。
マルチエージェントとは：単一エージェントと何が違うか
マルチエージェントシステムは、複数のLLMエージェントがそれぞれ異なる役割・コンテキスト・ツールセットを持ち、協調して1つの目標を達成するアーキテクチャです。単一エージェントが「1人で全部やる職人」だとすると、マルチエージェントは「役割の違う複数人で進めるプロジェクトチーム」に近い構造になります。
本質的な違いは、コンテキストの分離にあります。1つのエージェントに全部詰めると、システムプロンプトや過去履歴が膨らみ、注意散漫になります。複数エージェントに分割すれば、それぞれが自分のスコープに集中でき、品質と長時間運用の安定性が上がります。代償として、エージェント間の通信設計やオーケストレーションの複雑さが増えます。
マルチが単一を超える条件
マルチエージェント化が効くのは、次のいずれかが当てはまるときです。それ以外の場合は、まず単一エージェントで素直に書く方が安く速いです。
- タスクが明確に分業可能（例：計画／実装／レビュー）。
- 独立して並列実行できるサブタスクがある（例：複数ファイルの分析）。
- 自己評価バイアスを避けたい（書いた本人が採点しない）。
- 役割ごとに異なるモデル・コスト帯を使い分けたい（例：計画はOpus、量産はHaiku）。
- 1Mコンテキストでも収まらない、長期・大規模ワークフロー。
逆に、ターン数が3〜5回で完結する単機能タスク（メール下書き、CSV要約、コード変換など）は、単一エージェントで十分です。マルチ化のコストを正当化するには、複雑さの絶対量が一定以上必要になります。
5つの主要設計パターン
Supervisor/Worker
最も実用的で、最初に学ぶべきパターンです。1人のSupervisor（指揮者）がタスクを分解し、複数のWorkerに割り振り、結果を集約します。Claude Agent SDKの「サブエージェント呼び出し」もこの形を採用しています。Supervisorに高品質モデル（Opus 4.7やSonnet 4.6）、Workerに軽量モデル（Haiku 4.5）を割り当てると、品質とコストのバランスが取りやすくなります。
Planner/Executor
計画フェーズと実行フェーズを明確に分けるパターンです。Plannerが詳細なステップを設計し、Executorがそれを忠実に実行します。長時間タスクや、計画の妥当性を人手でレビューしたいケースに向いています。Plannerの出力をJSON/Markdownでファイル化しておくと、再利用やデバッグが楽になります。
Debate/Consensus
同じ問題に対して2つ以上のエージェントを独立に走らせ、互いの回答を批評・統合して最終回答を決めるパターンです。コードレビュー、設計判断、リスク評価のように「異なる視点が品質を上げる」場面で効きます。コストはほぼN倍になるので、重要意思決定だけに絞るのがコツです。
Hierarchical
Supervisor/Workerを多段化したパターンです。トップのSupervisorが中間Supervisorを呼び、その下にWorkerが並ぶ、組織図のような構造になります。大規模なドキュメント分析や、多段の品質ゲートが必要な業務プロセスに合いますが、デバッグ難度は急上昇するので、必要になるまで採用を避けるのが無難です。
Swarm
中央指揮者を置かず、フラットな複数エージェントが共有メモリやメッセージバスを通じて自律的に協調するパターンです。研究領域では盛んですが、本番運用では制御が難しく、2026年5月時点では実用例はまだ限定的です。学習用としては面白い領域です。
エージェント間通信の3モード
エージェント同士をどうつなぐかで、システムの性格は大きく変わります。実務では次の3モードのどれかか、その組み合わせになります。
- Shared Scratchpad：全エージェントが読み書きできる共有ノート。Markdownファイル1枚で実装することも多い。シンプルだが、エージェントが増えると衝突しやすい。
- Message Bus：エージェント間で名前付きメッセージをやり取りする方式。LangGraphやAutoGenが採用。並列処理に強い一方、デバッグはやや難。
- Structured Handoff：呼び出し元が引数を構造化して渡し、戻り値で結果を受け取る関数呼び出し型。Claude Agent SDKのサブエージェント呼び出しはこの形に近い。型が明確で扱いやすい。
初学者にはStructured Handoffが圧倒的におすすめです。関数呼び出しと同じ感覚で書け、引数と戻り値の型を意識するだけでだいぶ事故が減ります。
主要フレームワーク
| フレームワーク | 得意なパターン | 通信モード | 備考 |
|---|---|---|---|
| Claude Agent SDK | Supervisor/Worker, Planner/Executor | Structured Handoff | Claudeネイティブ、サブエージェント標準対応 |
| LangGraph | Hierarchical, Debate | Message Bus | 状態遷移グラフが書きやすい |
| AutoGen | Debate/Consensus, Swarm | Message Bus | エージェント同士の自由会話に強い |
| CrewAI | Supervisor/Worker | Shared Scratchpad中心 | 役割ベースで直感的だが細かい制御は弱い |
Supervisor-Workerパターンの擬似コード
もっとも実用的なSupervisor/Workerを、Claude APIだけで書いた最小構造で示します。Supervisorはdelegate_to_workerツールでサブタスクをWorkerに渡し、結果を集約して最終出力を作ります。
from anthropic import Anthropic
client = Anthropic()
def run_worker(task: str) -> str:
resp = client.messages.create(
model="claude-haiku-4-5",
max_tokens=1024,
system="あなたは与えられたサブタスクだけを正確に遂行するWorkerです。",
messages=[{"role": "user", "content": task}],
)
return resp.content[0].text
SUPERVISOR_TOOLS = [{
"name": "delegate_to_worker",
"description": "サブタスクをWorkerに委譲し結果を取得します。",
"input_schema": {
"type": "object",
"properties": {"task": {"type": "string"}},
"required": ["task"],
},
}]
def run_supervisor(goal: str) -> str:
messages = [{"role": "user", "content": goal}]
for _ in range(8): # ハードリミット
resp = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=2048,
system="あなたはSupervisorです。必要に応じてWorkerにサブタスクを委譲し、最終回答を作ります。",
tools=SUPERVISOR_TOOLS,
messages=messages,
)
if resp.stop_reason != "tool_use":
return resp.content[0].text
tool_results = []
for block in resp.content:
if block.type == "tool_use":
out = run_worker(block.input["task"])
tool_results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": out,
})
messages.append({"role": "assistant", "content": resp.content})
messages.append({"role": "user", "content": tool_results})
raise RuntimeError("Supervisor turn limit exceeded")ポイントは、(1) Supervisorに高品質モデル、Workerに軽量モデルを割り当てている点、(2) ループに必ずハードリミットを設けている点、(3) Worker呼び出しがClaude側からは「単なるツール呼び出し」に見える点です。この骨格を覚えれば、Workerを3〜5種類に増やしても、同じ構造で拡張できます。
失敗モードと対策
マルチエージェントの本番運用で必ず遭遇する3つの失敗モードと、その対策を整理します。
- コンテキストロス：あるエージェントが知っている情報を、別のエージェントが知らないことで起こる矛盾。対策は、共有スクラッチパッドへの要点書き込み、Structured Handoffでの必須情報の明示渡し。
- 無限ループ：Supervisor↔Workerの呼び出しがお互いに振り合ってしまう現象。対策は、ターン数のハードリミット、同じツール呼び出しの繰り返し検知、Workerの結果を「最終」扱いにして再委譲を禁じるなど。
- コスト爆発：エージェント数×ターン数×トークン量が掛け算で膨らむ。対策は、Workerの軽量化、Prompt Cachingでの共通プロンプト圧縮、月次コスト上限の設定。
特にコスト面は侮れません。Supervisor1回・Worker3回・各2ターンの構造でも、単一エージェントの7〜10倍のトークンを消費することがあります。Prompt Cachingやモデル使い分けで初期から最適化しておくと、本番投入の判断が楽になります。詳細は「Claude API料金を最適化する方法」も参照してください。
パターン選択フローチャート
「どのパターンを選ぶか」で迷ったら、次の順で考えると整理しやすくなります。
- そもそも単一エージェントで足りないか？ 足りるなら単一で書く。
- 並列実行できるサブタスクがあるなら → Supervisor/Worker。
- 計画段階を人手レビューしたいなら → Planner/Executor。
- 重要意思決定で複数視点が欲しいなら → Debate/Consensus。
- 3段以上の分業が必要なら → Hierarchical。
- 研究目的でなければ Swarm は当面避ける。
まとめ
マルチエージェント設計は強力ですが、「単一で済むなら単一」が大前提です。必要性が固まったら、Supervisor/Workerから始め、Structured Handoffで通信し、ハードリミットとコスト上限を必ず入れる。これだけで実用的なシステムになります。エージェント単体の入門は「AIエージェント入門」、セキュリティ面は「AIエージェントのセキュリティリスクと対策」を合わせて読むと、現場で必要な視点が一通り揃います。
マルチエージェント開発を実践で学ぶ
Claude APIとエージェント設計を体系的に学べる、筆者のUdemy講座一覧です。