「マルチエージェントにしたら、なんか良くなりそう」——そう思ってエージェントを増やした結果、むしろ遅くなったりコストが膨れたりした経験はありませんか？
Anthropic が 2026年4月に公開したブログ記事「Multi-agent coordination patterns」は、この問題にストレートに答えています。メッセージは明快で、「カッコよさそうなパターンではなく、問題に合ったパターンを選べ」ということ。
この記事では、Anthropic が提示した 5つの連携パターン を日本語で噛み砕き、それぞれの「得意な場面」「苦手な場面」「どこから進化するべきか」を整理します。最後に、あなたのプロジェクトでどのパターンから始めるべきかの判断軸も紹介します。
5つのパターンの全体像
まず全体を俯瞰しましょう。Anthropic が示した5つのパターンは、シンプルなものから順に以下の通りです。
| パターン | 一言で言うと | 向いている場面 |
|---|---|---|
| Generator-Verifier | 作る係 + チェックする係 | 品質が最優先で、評価基準が明確 |
| Orchestrator-Subagent | リーダー + 部下 | タスク分解が明確で、サブタスクが短い |
| Agent Teams | チームメンバーが並列で長時間作業 | 独立した大規模タスクを並列処理 |
| Message Bus | イベント駆動のパイプライン | ワークフローが動的で、エージェントが増え続ける |
| Shared State | 共有データベースを介した協調 | エージェント同士の発見を即座に共有したい |
Anthropic の推奨は 「まず Orchestrator-Subagent から始めて、壁にぶつかったら他のパターンに進化させろ」 です。
では、各パターンを掘り下げていきましょう。
パターン1: Generator-Verifier（生成 + 検証）
最もシンプルで、最も広くデプロイされているパターンです。
仕組み
- Generator（生成エージェント）がタスクを受け取り、出力を生成
- Verifier（検証エージェント）が出力を評価基準に照らしてチェック
- 合格なら完了。不合格ならフィードバック付きで Generator に差し戻し
- 合格するか、最大反復回数に達するまでループ
こんなときに使う
- コード生成: 一方が書いて、もう一方がテストを書いて実行する
- カスタマーサポート: メール文面を生成 → ナレッジベースとの整合性・トーン・網羅性を検証
- コンプライアンス: 契約書ドラフトを生成 → 法的要件を満たしているかチェック
共通点は「間違った出力のコストが、もう1回生成するコストより高い」場面です。
たとえば、あなたが Claude Code でAPIのエンドポイントを生成させるとき、別のエージェントに「このコードに対してテストを書いて実行してもらう」という使い方は、まさに Generator-Verifier です。テストが通らなければフィードバックが返り、コードが修正される。人間が目視で確認するよりはるかに速く、確実です。
落とし穴
検証基準が曖昧だと機能しない。 「出力が良いかチェックして」だけでは、Verifier は Generator の出力をそのまま通してしまいます。「料金プランが正しいか」「すべての質問に回答しているか」など、具体的な基準を定義することが必須です。
ループが収束しないリスク。 Generator が Verifier のフィードバックに対応できないと、延々とループし続けます。最大反復回数 + フォールバック（人間にエスカレーション、最善の結果にキャビアット付きで返す）が必要です。
パターン2: Orchestrator-Subagent（指揮者 + 部下）
Claude Code が実際に使っているパターンです。
仕組み
- Orchestrator（リーダーエージェント）がタスクを受け取り、分解方法を判断
- 一部のサブタスクは自分で処理、残りは Subagent に委任
- Subagent は結果を返して終了
- Orchestrator が結果を統合して最終出力を生成
Claude Code では、メインエージェントがコードを書いたりファイルを編集しながら、大規模なコードベース検索や独立した調査を バックグラウンドのサブエージェント に並列で投げています。各サブエージェントは独自のコンテキストウィンドウで動き、要約した結果だけを返す。こうすることで Orchestrator のコンテキストが本来のタスクに集中できます。
こんなときに使う
- コードレビュー自動化: PR が来たら、セキュリティ・テストカバレッジ・スタイル・アーキテクチャの各チェックを別々のサブエージェントに委任 → 統合レビュー
- リサーチ: メイン質問に対して、複数の情報源を並列で調査 → 統合レポート
タスク分解が明確で、サブタスク間の依存関係が少ない ときに最適です。
落とし穴
情報のボトルネック。 サブエージェント A が発見した情報がサブエージェント B に関係する場合、Orchestrator を経由しないと伝わりません。何度もハンドオフを繰り返すうちに、重要な詳細が要約で失われがちです。
逐次実行のコスト。 明示的に並列化しないと、サブエージェントが順番に実行されるため、マルチエージェントのトークンコストだけかかって速度メリットがないという最悪の結果になります。
つまり、Orchestrator-Subagent を選ぶなら「サブエージェントを並列で走らせる」設計を最初から意識することが重要です。Claude Code の Agent ツールでも、1つのメッセージ内で複数のエージェントを同時に起動できます。この並列起動をしないと、サブエージェントの恩恵は半減します。
パターン3: Agent Teams（エージェントチーム）
Orchestrator-Subagent との違いは ワーカーの寿命 です。
仕組み
- Coordinator が複数のワーカーエージェントを独立プロセスとして生成
- ワーカーは共有キューからタスクを取得し、長時間にわたって自律的に作業
- 複数のタスクを跨いでコンテキストを蓄積する（1回で終了しない）
Subagent は「1つのタスクを完了したら消える」のに対し、チームメイトは 生き続けて、ドメインの専門性を蓄積 します。