🤖 マルチエージェント協調パターン 5つのアプローチと使い分け

🎯 はじめに

LLMを活用したAIエージェントが単体で動くフェーズを超えて、複数のエージェントが連携して仕事をする「マルチエージェントシステム」 が本格的な実用段階に入っています。Databricksの調査では、2025年6月〜10月のわずか4ヶ月間でマルチエージェントワークフローの利用が 327%増加 したと報告されており、もはや研究レベルの話ではなく、プロダクション環境での設計判断の問題になっています。

しかし、「マルチエージェントにしよう」と決めたあとに待ち受ける問いは、「どう協調させるか」 です。エージェント間の関係を雑に設計すると、トークンコストだけが膨らんで品質は上がらない、という最悪のパターンに陥ります。

この記事では、Anthropic（Claude）の公式ブログ記事 "Multi-agent coordination patterns: Five approaches and when to use them"（2026年4月公開）を軸に、5つの協調パターン を体系的に解説します。各パターンの仕組み・強み・弱み・実装上の注意点を深掘りし、最後にどのパターンをどの場面で選ぶべきかの判断フレームワークを提供します。

📖 この記事で学べること

#	学べること
1️⃣	マルチエージェント協調パターンとは何か、なぜ重要か
2️⃣	5つのパターン（Generator-Verifier / Orchestrator-Subagent / Agent Teams / Message Bus / Shared State）の仕組みと特性
3️⃣	各パターンの 強み・弱み・落とし穴 と実装上の注意点
4️⃣	パターン選定の 判断フレームワーク — どの場面でどれを選ぶか
5️⃣	パターンを 組み合わせるハイブリッド構成 の考え方
6️⃣	実装を始めるための 実践的な推奨事項

---

🌍 なぜ「協調パターン」を意識する必要があるのか

マルチエージェントシステムを構築するとき、多くのチームは「エージェントを増やせば賢くなる」と考えがちです。しかし実際には、エージェントの数ではなく、エージェント間の協調の設計 こそがシステム全体の品質を決定します。

🔑 コンテキスト境界という視点

Anthropicのブログでは、マルチエージェント協調の本質を 「コンテキスト境界の管理」 として捉えています。各パターンは、作業を分割する方法ではなく、コンテキスト（文脈情報）をどう区切り、どう流通させるか という観点で違いが生まれます。

💡 「シンプルなものから始めよ」の原則

Anthropicが強く推奨しているのは、次の段階的アプローチです。

🔑 「最も単純なパターンから始めて、どこで苦しむかを観察し、そこから進化させる」

これは直感に反するかもしれませんが、極めて実践的な知恵です。なぜなら、協調パターンは 複雑さのコスト を伴うからです。パターンが高度になるほど、デバッグが困難になり、トークンコストが増大し、予期しない振る舞いが増えます。

🏷️ 複雑さのレベル	パターン	トレードオフ
⭐ 最もシンプル	Generator-Verifier	品質向上 vs ループコスト
⭐⭐ 適度	Orchestrator-Subagent	分業効率 vs 情報ボトルネック
⭐⭐ 適度	Agent Teams	並列処理力 vs 調整コスト
⭐⭐⭐ 高度	Message Bus	拡張性 vs デバッグ困難
⭐⭐⭐ 高度	Shared State	自律性 vs 予測困難性

---

🔄 パターン1: Generator-Verifier — 生成と検証のループ

📋 概要

最もシンプルで、最も広くデプロイされている マルチエージェントパターンです。ひとつのエージェント（Generator）が出力を生成し、別のエージェント（Verifier）が明示的な基準に照らして評価する、というシンプルな2者間ループです。

📌 この図のポイント

Verifierが不合格と判定した場合、フィードバックとともにGeneratorにループバックします。重要なのは 最大反復回数の上限 とフォールバック戦略（人間へのエスカレーション、または注意書き付きのベスト版返却）が必須であることです。これがないと、ループが永遠に回り続ける危険性があります。

✅ 向いている場面

• 📧 カスタマー対応メール生成 — 生成されたメールを品質基準で検証
• 💻 コード生成＋テスト検証 — コードを生成し、テストスイートで自動検証
• ✔️ ファクトチェック・コンプライアンス — 出力が規制要件を満たすか検証
• 📝 ルーブリック評価 — 明示的な採点基準に照らして出力を評価

⚠️ 落とし穴

🔑 Verifier に「良いかどうかチェックして」と言うだけでは、Generatorの出力をゴム印で承認するだけになる

この一文は、Generator-Verifier パターンを実装する上で最も重要な警告です。Verifier が機能するためには、何を検証するかの明示的な基準 が不可欠です。

❌ 悪い検証基準	✅ 良い検証基準
「品質が良いか確認して」	「以下の3項目を確認: 1) 顧客名が正しいか 2) 技術用語が正確か 3) トーンが公式ガイドラインに沿っているか」
「コードに問題がないか確認して」	「テストスイートが全件パスするか実行し、型エラーがないか確認し、セキュリティポリシーに違反しないか検証」
「自然な文章かチェックして」	「Flesch Reading Easeスコアが60以上か測定し、受動態の比率が20%以下か確認」

💡 Generator-Verifierが最も輝くとき

このパターンは、「生成」と「検証」が分離可能なスキルであるとき に最も効果的です。たとえばコード生成の場面では、コードを書く能力とテストで正しさを判定する能力は明らかに異なるスキルです。逆に「創造的なエッセイを書いて検証する」といった主観的な課題では、検証基準そのものが曖昧になるため、このパターンは力を発揮しにくくなります。

🔧 実装のコツ

1. 収束メカニズムを必ず入れる — 最大反復回数（例: 3回）を設定し、上限に達したら人間にエスカレーションするか、注意書き付きのベスト版を返す
2. フィードバックを構造化する — Verifier の不合格理由を構造化データ（JSON等）で返し、Generator が次の反復で具体的に修正できるようにする
3. 検証基準を外部定義する — 基準はVerifier のプロンプトにハードコードせず、設定ファイルやデータベースで管理する。基準の変更がプロンプトの書き換えを伴わないようにする

💻 擬似コード例

Generator-Verifier の基本的なループ構造は以下のようになります。

async def generator_verifier_loop(task: str, criteria: list[str], max_iterations: int = 3):
    """Generator-Verifier パターンの基本ループ"""
    best_output = None

    for i in range(max_iterations):
        # 1. Generator が出力を生成
        if i == 0:
            output = await generator.create(task)
        else:
            output = await generator.revise(task, output, feedback)

        # 2. Verifier が基準に照らして検証
        result = await verifier.evaluate(output, criteria)

        best_output = output

        if result.accepted:
            return {"output": output, "status": "accepted", "iterations": i + 1}

        feedback = result.structured_feedback  # 構造化フィードバック

    # 上限到達 → フォールバック
    return {"output": best_output, "status": "max_iterations_reached", "iterations": max_iterations}

📌 コードのポイント

• ✅ max_iterations で 収束メカニズム を確保
• ✅ structured_feedback で Verifier のフィードバックを構造化
• ✅ 上限到達時は best_output を返し、ステータスで 「上限到達」を明示
• ⚠️ criteria を関数の引数として外部から受け取る（ハードコードしない）

---

🏗️ パターン2: Orchestrator-Subagent — 階層型の指揮と委任

📋 概要

リードエージェント（Orchestrator）が作業を計画し、専門エージェント（Subagent）にタスクを委任し、結果を統合する 階層型パターンです。Anthropicのブログでは「ほとんどのユースケースで最初に試すべきパターン」として推奨されています。

📌 この図のポイント

Orchestrator は一部のタスクを 直接処理 し、残りを Subagent に 委任 します。各 Subagent は独自のコンテキストウィンドウで動作し、蒸留された（distilled）結果 を Orchestrator に返します。この「蒸留」がポイントで、Subagent のフルコンテキストではなく、要約された知見が Orchestrator に戻ります。

🌍 実世界の実装例 — Claude Code

Anthropicの Claude Code がまさにこのパターンを採用しています。

要素	Claude Codeでの実装
🧠 Orchestrator	メインエージェント — コード記述、コマンド実行を直接処理
🔍 Subagent	バックグラウンドエージェント — コードベース検索、独立した調査を並行実行
📤 結果統合	各 Subagent が蒸留した知見をメインエージェントに返却

✅ 向いている場面

• 🔍 自動コードレビュー — セキュリティ、テストカバレッジ、コードスタイル、アーキテクチャ評価を専門 Subagent に分配
• 📝 複合ドキュメント生成 — 章ごとに専門エージェントが執筆し、Orchestrator が統合
• 🔧 タスクが明確に分解可能で、相互依存が少ない 場面全般

🔧 Subagent への委任テンプレート

Orchestrator が Subagent にタスクを渡す際の、構造化された委任指示の例です。

## タスク委任: セキュリティレビュー

### 🎯 目的
以下のPRに含まれるコード変更について、セキュリティ脆弱性を特定する

### 📤 出力形式
JSON形式で以下のスキーマに従う:
- findings: [{severity: "HIGH"|"MEDIUM"|"LOW", file: string, line: number, description: string, recommendation: string}]
- summary: string (1-2文の要約)
- overall_risk: "PASS" | "NEEDS_REVIEW" | "BLOCK"

### 🔧 使えるツール
- ファイル読み取り（対象PRの差分のみ）
- OWASP Top 10 チェックリスト参照

### 🚧 境界
- コードスタイルや設計パターンは評価しない（別のSubagentが担当）
- 修正コードは書かない（発見と推奨のみ）
- 想定外の重大な発見（データ漏洩の痕跡など）があれば `unexpected_finding` フラグを立てる

💡 なぜ構造化された委任が重要か

「コードレビューして」と雑に委任すると、Subagent はスコープを広げすぎたり、逆に浅すぎるレビューを返したりします。4要素（目的・出力形式・ツール・境界）を明示 することで、Subagent の出力品質が安定し、Orchestrator での統合もスムーズになります。

⚠️ 弱点と対策

😰 弱点	💡 対策
情報ボトルネック — Orchestrator がすべての情報のハブになるため、Subagent が発見した横断的関心事が伝わりにくい	Subagent に「想定外の発見があれば明示的にフラグを立てる」よう指示する
詳細の喪失 — 複数回のハンドオフを経るうちに情報が落ちる	結果を構造化フォーマット（JSON / テーブル）で返させる
逐次実行のスループット制限 — 明示的に並列化しない限り、Subagent は順番に実行される	独立したタスクは並列実行を指示する
トークンコスト — マルチエージェントのオーバーヘッドが速度向上なしにコスト増を招く可能性	Subagent の数を最小限に抑え、本当に専門性が必要なタスクだけ委任する

💡 Orchestrator に「委任の仕方」を教える

Anthropicのマルチエージェントリサーチシステムの実装解説記事によると、リードエージェントにサブエージェントを委任する際には、以下の4要素を明示的に伝える必要があります。

• 🎯 目的 — 何を達成してほしいか
• 📤 出力形式 — どういう形式で結果を返すか
• 🔧 使えるツール・ソース — どのリソースにアクセスしてよいか
• 🚧 タスクの境界 — 何をやるべきで、何をやるべきでないか

---

👥 パターン3: Agent Teams — 持続的なワーカーによる並列処理

📋 概要

Orchestrator-Subagent との最大の違いは、ワーカーエージェントが 持続的（persistent） であることです。1回きりの呼び出しではなく、長期間にわたって自律的に動作し、複数のタスクにまたがってコンテキストを蓄積 していきます。

📌 この図のポイント

Coordinator が共有タスクキューにタスクを投入し、各 Worker が自律的にタスクをクレームして処理します。Worker は持続的に動作するため、反復を重ねるごとにドメイン専門性が蓄積 されていくのが特徴です。

🌍 典型的なユースケース — フレームワーク移行

コードベースのフレームワーク移行 が最も典型的なユースケースです。

• 👷 Worker A → Service X を担当（独自の依存関係、テストスイート、デプロイ設定を把握）
• 👷 Worker B → Service Y を担当
• 👷 Worker C → Service Z を担当

📊 持続ワーカーの価値 — 回を重ねるごとに性能が向上

Agent Teams パターンの独自の強みは、コンテキストの蓄積による性能向上 です。これは1回限りの Subagent では得られない利点です。

📌 この図のポイント

Worker が同じサービスを繰り返し扱うことで、そのサービス固有のパターン（特殊な命名規則、頻出するエッジケース、チーム独自のコーディング慣習など）を学習していきます。この蓄積効果は、Orchestrator-Subagent パターンの1回限りの呼び出しでは得られない、Agent Teams 固有のメリットです。

各ワーカーは自分のサービスに対して 本物の理解 を築き上げていきます。最初のタスクでは汎用的な対応しかできませんが、同じサービスを繰り返し扱うことで、そのサービス固有のパターンや注意点を学習し、パフォーマンスが向上します。

✅ Orchestrator-Subagent とどう使い分ける?

判定基準	Orchestrator-Subagent	Agent Teams
サブタスクの性質	短く、境界が明確で、1回の呼び出しで完結	複数ステップにわたる持続的な作業が必要
コンテキストの蓄積	不要（毎回リセット）	必要（担当領域の理解が深まるほど性能向上）
実行時間	短時間（分単位）	長時間（時間〜日単位もあり得る）
代表的な場面	コードレビュー、文書要約、情報検索	フレームワーク移行、長期テスト、大規模リファクタリング

⚠️ 落とし穴

🔑 独立性が最重要条件

Agent Teams パターンが成立するためには、各ワーカーのタスクが 互いに独立 でなければなりません。あるワーカーの作業が別のワーカーの作業に影響を与える場合、検出されない衝突 が発生します。

😰 課題	💡 対策
ワーカー間の干渉	タスク分割時に依存関係を明示的にマッピングし、依存があるタスクは同じワーカーに集約
完了時間のばらつき	タイムアウトを設定し、遅いワーカーのステータスを定期的に確認
共有リソースの競合	ファイルロック、データベースの行ロック、ブランチ戦略などで明示的にパーティショニング

---

📡 パターン4: Message Bus — イベント駆動の疎結合

📋 概要

エージェント同士が直接通信するのではなく、メッセージバス（イベントバス）を介してトピックを発行・購読（pub/sub） する、イベント駆動型の協調パターンです。ルーターが受信者を決定し、エージェント間に直接の接続がなくても連携が成立します。

📌 この図のポイント

Message Bus がすべてのメッセージの 中継点 になっています。新しいエージェント（たとえば「マルウェア解析Agent」）を追加したい場合、既存のエージェントの配線を変更する必要がありません。バスにトピックを追加するだけで拡張できます。これが 疎結合 の強みです。

🌍 最適なユースケース — セキュリティオペレーション

Anthropicのブログでは、セキュリティオペレーション自動化（SecOps） が最適なユースケースとして紹介されています。

1. 🚨 複数のソースからアラートが到着
2. 🏷️ Triage Agent が深刻度・種別を分類
3. 📡 ルーターがネットワーク系アラートをNetwork Agent へ、認証系を Identity Agent へ振り分け
4. 🔍 調査エージェントがエンリッチメントリクエストを発行
5. 🛡️ Response Coordination Agent が対応アクションを決定

脅威の種類が変化しても、新しいエージェントを独立してデプロイ できるのがこのパターンの真価です。

✅ Orchestrator-Subagent とどう使い分ける?

判定基準	Orchestrator-Subagent	Message Bus
ワークフローの予測可能性	既知で固定的なシーケンス	発見に基づいて変化するイベント駆動
エージェント追加	Orchestrator を修正する必要がある	バスにトピックを追加するだけ
デバッグ容易性	✅ シーケンスを追いやすい	❌ カスケードするイベントの追跡が困難
向いているスケール	小〜中規模（エージェント5個程度まで）	中〜大規模（エージェントが増え続ける環境）

⚠️ 落とし穴

🔑 サイレントファイラーに注意

ルーターがメッセージを誤分類したり、イベントをドロップした場合、静かに失敗 します。エラーが発生しないため、問題に気づくのが遅れます。

😰 課題	💡 対策
カスケードイベントのトレーシング	各メッセージにcorrelation IDを付与し、分散トレーシングを導入
ルーターの誤分類	フォールバック先（未分類キュー）を用意し、定期的に人間がレビュー
LLMベースルーターの追加故障モード	ルーティングのログを全件保存し、分類精度を定期的に計測
デバッグの困難さ	イベントフローの可視化ダッシュボードを構築

---

🧠 パターン5: Shared State — 中央コーディネーターなしの協調

📋 概要

最も 自律性が高い パターンです。中央のコーディネーターを排除し、エージェントが 永続的なストア（データベース、ファイルシステム、ドキュメント）を通じて直接協調 します。各エージェントは自律的に動作し、ストアに書き込んだ情報が他のエージェントの行動に影響を与えます。

📌 この図のポイント

双方向矢印 がポイントです。すべてのエージェントがストアを読み書きできるため、あるエージェントの発見が即座に他のエージェントの調査に影響します。コーディネーターを介さないため、情報のボトルネックが存在しません。

🌍 最適なユースケース — リサーチシンセシス

複数エージェントがそれぞれ異なる角度から調査し、発見を共有しながら全体像を組み立てる ユースケースが最適です。

🤖 エージェント	担当
📚 学術文献 Agent	学術論文の調査
🏢 産業レポート Agent	業界レポートの分析
📋 特許調査 Agent	特許文献の検索
📰 ニュースモニタ Agent	最新ニュースの監視

各エージェントの発見が共有ストアに書き込まれ、他のエージェントが即座にそれを参照して自分の調査を調整します。学術文献 Agent が「新しい手法Xが注目されている」と書き込めば、特許調査 Agent が「手法Xの特許出願状況」を追加調査するかもしれません。

✅ Agent Teams とどう使い分ける?

判定基準	Agent Teams	Shared State
タスク間の相互作用	独立したパーティション、最後に結合	発見がリアルタイムで他エージェントに影響
コーディネーター	あり（Coordinator が集約）	なし（ストアを通じた間接的協調）
単一障害点	Coordinator が落ちると全体停止	エージェント1つが止まっても他は継続
振る舞いの予測可能性	比較的高い	低い（創発的な振る舞い）

💻 Shared State の初期化と終了の擬似コード

async def shared_state_research(topic: str, agents: list[Agent], config: dict):
    """Shared State パターンのリサーチ実行"""
    store = SharedStore()

    # 初期シード: ストアに問いを投入
    store.write("research_question", topic)
    store.write("status", "active")

    start_time = time.time()
    cycle_count = 0
    no_new_findings_count = 0

    # 全エージェントを並列起動
    tasks = [agent.run(store) for agent in agents]

    while store.read("status") == "active":
        await asyncio.sleep(config["check_interval_seconds"])
        cycle_count += 1

        # 終了条件1: 時間予算
        if time.time() - start_time > config["time_budget_seconds"]:
            store.write("status", "completed")
            store.write("termination_reason", "time_budget_exceeded")
            break

        # 終了条件2: 収束閾値
        new_findings = store.count_new_findings_since_last_check()
        if new_findings == 0:
            no_new_findings_count += 1
        else:
            no_new_findings_count = 0

        if no_new_findings_count >= config["convergence_threshold"]:
            store.write("status", "completed")
            store.write("termination_reason", "converged")
            break

    # 全エージェントを停止
    for task in tasks:
        task.cancel()

    return store.read_all()

📌 コードのポイント

• ✅ 初期シード — ストアに research_question を書き込んで全エージェントに共有
• ✅ 2つの終了条件 を明示的に組み込み（時間予算 + 収束閾値）。3つ目の「判定エージェント」による終了は、ストアに status: completed を書き込むことで各エージェント内部から実現可能
• ✅ termination_reason を記録して、なぜ終了したかを追跡可能に
• ⚠️ 全エージェントを cancel() で明示的に停止

⚠️ 落とし穴 — 終了条件は「ファーストクラス」で設計する

🔑 「終了条件を後回しにしたシステムは、無限にサイクルし続ける傾向がある」

Shared State パターンの最大の危険は、反応ループ です。Agent A が書き込む → Agent B が反応 → Agent A がフォローアップ → Agent B がさらに反応、というサイクルが トークンを燃やし続けながら 延々と回ります。

終了条件は以下のいずれかを 必ず 設計に組み込む必要があります。

🛑 終了条件	説明
⏰ 時間予算	「30分で調査を終了する」
📉 収束閾値	「Nサイクル連続で新しい発見がなければ終了」
👤 判定エージェント	「ストアの内容が十分かどうかを判断する専用エージェント」

📌 この図のポイント

3つの終了条件が OR の関係で評価されます。どれか1つが成立すれば終了する、という安全策です。これにより、反応ループによるトークン浪費を防げます。

---

🧭 パターン選定フレームワーク — どの場面でどれを選ぶか

5つのパターンを理解したところで、実際の場面でどれを選ぶべきか を判断するフレームワークを整理します。

📊 ユースケース別クイックリファレンス

🏷️ 状況	🎯 推奨パターン
品質が最重要、評価基準が明示的	🔄 Generator-Verifier
タスクが明確に分解可能、境界の明確なサブタスク	🏗️ Orchestrator-Subagent
並列ワークロード、独立した長時間サブタスク	👥 Agent Teams
イベント駆動パイプライン、エージェント追加が頻繁	📡 Message Bus
協調的リサーチ、発見のリアルタイム共有	🧠 Shared State
単一障害点の排除が必要	🧠 Shared State

🔀 パターン対比の判断フロー

迷ったときのために、よくある比較を整理します。

---

🚫 よくあるアンチパターン — やってはいけない設計判断

パターンを選ぶのと同じくらい重要なのが、避けるべき落とし穴 を知ることです。実務で繰り返し観察される失敗パターンを整理します。

❌ アンチパターン1: 「とりあえずマルチエージェント」

項目	内容
😰 症状	シングルエージェントで十分なタスクに、無理やりマルチエージェントを適用する
💥 結果	トークンコストが2〜5倍に増加するが、品質はほぼ変わらない
💡 教訓	マルチエージェントは「専門化・並列化・スケール経済」がオーバーヘッドを正当化するときだけ有効

⚠️ 判断基準

「このタスクで2つ目のエージェントを足すことで、具体的にどの品質指標が改善するか?」と自問してください。答えが曖昧なら、シングルエージェントのまま改善したほうがコスト効率が良い可能性が高いです。

❌ アンチパターン2: 「検証基準のないVerifier」

項目	内容
😰 症状	Verifier に「出力が良いか確認して」とだけ指示する
💥 結果	Verifier が Generator の出力をほぼ毎回承認する（ゴム印問題）
💡 教訓	検証基準はチェックリスト形式で具体的に定義する。「3項目中2項目以上OKなら合格」のように定量化する

❌ アンチパターン3: 「終了条件なしのShared State」

項目	内容
😰 症状	エージェントがストアに書き込むたびに他のエージェントが反応し、無限ループが発生
💥 結果	数時間で数百万トークンを消費し、有用な成果がほとんど生まれない
💡 教訓	時間予算・収束閾値・判定エージェントの3つの終了条件を 必ず 組み込む

❌ アンチパターン4: 「なんでもOrchestrator経由」

項目	内容
😰 症状	すべての情報フローを Orchestrator に集中させ、Subagent 間の直接通信を一切認めない
💥 結果	Orchestrator がボトルネックになり、横断的関心事が伝わらず、重要な発見が落ちる
💡 教訓	Subagent が「想定外の発見」を報告する仕組みを用意する。また、協調が必要なサブタスクには Shared State サブシステムの併用を検討する

❌ アンチパターン5: 「動詞で分割するエージェント設計」

項目	内容
😰 症状	「分析Agent」「書くAgent」「確認Agent」のように、作業の動詞でエージェントを分ける
💥 結果	エージェント間で大量のコンテキスト転送が必要になり、ハンドオフで情報が劣化する
💡 教訓	「動詞」ではなく「コンテキスト要件」で分割する。同じドメイン知識が必要なタスクは同じエージェントに集約する

📌 この図のポイント

左の「動詞で分割」するアプローチでは、各ステップでコンテキストの転送が必要になり、情報が劣化します。右の「コンテキストで分割」では、各エージェントが自分のドメイン内で分析・執筆・確認をすべて完結させるため、ハンドオフが不要で情報の鮮度が保たれます。

---

🔀 パターン間の移行シナリオ — 進化の道筋

「シンプルから始めて進化させる」という原則を掲げましたが、具体的にどう進化させるのでしょうか。よくある移行シナリオを3つ紹介します。

📈 シナリオ1: Orchestrator-Subagent → Agent Teams

フェーズ	状況
🟢 初期	コードレビューを Orchestrator + 3つのSubagent（セキュリティ / テスト / スタイル）で運用。各Subagent は1回呼び出しで完結
🟡 苦しみ始め	マイクロサービスが増え、各サービスの文脈を理解していないと正確なレビューができなくなる。毎回ゼロからコンテキストを渡すコストが急増
🔵 移行判断	Subagent が「毎回リセット」される問題が原因と特定 → 各サービス専任の持続ワーカーが必要
🟣 移行後	Service A 担当Worker / Service B 担当Worker ... に切り替え。各ワーカーが担当サービスのパターンを蓄積し、レビュー精度が向上

💡 移行のサイン

「同じSubagentに毎回同じコンテキストを渡している」「Subagentがドメイン知識を持っていればもっと良い結果が出るのに」と感じたら、Agent Teams への移行を検討するタイミングです。

📈 シナリオ2: Orchestrator-Subagent → Message Bus

フェーズ	状況
🟢 初期	インシデント対応を Orchestrator + Subagent で運用。アラート受信 → 分類 → 調査 → 対応の固定フロー
🟡 苦しみ始め	新種の脅威が出るたびに Orchestrator の分岐ロジックを書き換える必要がある。エージェントの追加がOrchestratorの修正を強制する
🔵 移行判断	「エージェントを追加するたびにOrchestratorを触る」コストが問題と特定 → 疎結合が必要
🟣 移行後	Message Bus に切り替え。新しい脅威タイプ用のエージェントを、既存エージェントに影響なく追加できるように

📈 シナリオ3: Agent Teams → Shared State（部分移行）

フェーズ	状況
🟢 初期	リサーチタスクを Agent Teams で並列実行。各ワーカーが独立して調査し、最後に Coordinator が結合
🟡 苦しみ始め	ワーカーAの発見がワーカーBの調査に本来影響すべきなのに、最後の結合まで共有されない。重複調査や矛盾する結論が発生
🔵 移行判断	「リアルタイムの発見共有」が必要と特定 → Shared State への部分移行
🟣 移行後	リサーチ部分だけ Shared State に切り替え。全体のフレーム管理はCoordinatorが維持

📌 この図のポイント

矢印のラベルが 移行のトリガー を示しています。「なぜ今のパターンが苦しいか」が明確になれば、次のパターンは自然に決まります。重要なのは、痛みのポイントが明確になってから移行する ことです。「なんとなく高度なパターンのほうが良さそう」で移行するのはアンチパターンです。

---

💰 コスト比較の考え方 — トークン消費の構造を理解する

マルチエージェントシステムの実運用で避けて通れないのが トークンコスト です。パターンによってトークンの消費構造が大きく異なるため、コスト意識を持って設計することが重要です。

📊 パターン別トークン消費の傾向

パターン	💰 コスト傾向	📝 コスト増の主因
🔄 Generator-Verifier	基本 × 反復回数	ループの回数に比例。平均2〜3回で収束するなら許容範囲
🏗️ Orchestrator-Subagent	基本 + (Subagent数 × 各コスト)	Subagent数が増えると線形に増加。各Subagentのコンテキストウィンドウは独立
👥 Agent Teams	Subagentと同等だが持続的	ワーカーが長時間動作するため、コンテキストウィンドウが成長し続ける
📡 Message Bus	イベント数 × 関与Agent数	カスケードイベントが多いと爆発的に増加する可能性
🧠 Shared State	⚠️ 最も予測困難	反応ループによりトークン消費が指数的に増加するリスク

🧮 概算の考え方

シングルエージェントで1タスクあたり約 10K トークン を消費するケースを基準として考えます。

シングルエージェント:              ~10K tokens
Generator-Verifier (3回ループ):    ~30K tokens (×3)
Orchestrator + 3 Subagents:        ~50K tokens (Orch: 15K + Sub: 12K×3)
Agent Teams (3 Workers, 持続):     ~80K tokens (各Workerのコンテキスト累積)
Shared State (4 Agents, 収束まで): ~100K〜500K tokens (反応ループ次第)

⚠️ 上記は概算イメージであり、実際のトークン消費はタスクの複雑性、モデル、コンテキストウィンドウの管理方法によって大きく変動します。

🎯 コスト最適化の原則

1. 📏 最小限のエージェント数で始める — 「このSubagentは本当に必要か?」を常に問う
2. 📊 トークン使用量を計測する — エージェントごと、リクエストごとに計測し、異常値を検知
3. ⏰ 時間予算を設ける — 特にShared Stateでは、トークン予算を超えたら強制終了
4. 🗜️ コンテキストを圧縮する — Subagentに渡す情報は必要最小限に絞り、結果の返却も蒸留させる
5. 💡 コスト対品質のトレードオフを定量化する — 「Subagentを追加することで品質がX%向上し、コストがY%増加する」を計測可能にする

---

🔗 パターンの組み合わせ — ハイブリッド構成

Anthropicのブログが強調しているのは、「プロダクションシステムはパターンを組み合わせることが多い」 という事実です。5つのパターンは排他的な選択肢ではなく、ビルディングブロック として組み合わせて使えます。

🧩 典型的なハイブリッド例

ハイブリッド構成	説明
🏗️ + 🧠 Orchestrator + Shared State	全体のワークフローは Orchestrator が管理し、協調が特に必要なサブタスクでは Shared State を使う
📡 + 👥 Message Bus + Agent Teams	イベントルーティングは Message Bus が担い、各イベントタイプの処理は Agent Teams が持続的に対応
🏗️ + 🔄 Orchestrator + Generator-Verifier	Orchestrator がタスクを分配し、品質が重要なタスクでは Generator-Verifier ループを内部で回す

📌 この図のポイント

Orchestrator が全体を管理しつつ、リサーチが必要な部分だけ Shared State サブシステムに委任 しています。これにより、Orchestrator の制御性と Shared State の協調的な知識構築の両方を享受できます。

💡 ハイブリッド構成を考えるタイミング

単一パターンで始めて、特定のサブタスクで「このパターンだと苦しい」と感じたとき、そのサブタスクだけ を別パターンに切り替えるのが現実的なアプローチです。最初からハイブリッドを設計すると複雑さが爆発しますが、「ここだけ別のやり方にしたい」というポイントを明確にしてから組み合わせるのは健全な進化です。

---

🚀 実装を始めるための実践的推奨事項

最後に、これらのパターンを実際に実装に移す際のガイドラインをまとめます。

📌 1. まずは Orchestrator-Subagent から始める

🔑 「ほとんどのユースケースでは、Orchestrator-Subagent から始めることを推奨します。最も広い範囲の問題を、最も少ない協調オーバーヘッドで処理できるパターンです。」 — Anthropic

迷ったら Orchestrator-Subagent から始めましょう。このパターンが苦しむポイントを観察してから、特定のニーズに応じて他のパターンに進化させるのが、最も安全なアプローチです。

📌 2. コンテキスト要件で分割する

作業の種類（「分析タスク」「生成タスク」）で分割するのではなく、コンテキスト要件 で分割します。同じコンテキストが必要なタスクは同じエージェントに、異なるコンテキストが必要なタスクは別のエージェントに割り当てます。

❌ 避けるべき分割	✅ 推奨する分割
「分析する」エージェントと「書く」エージェント	「セキュリティのコンテキストが必要な」エージェントと「パフォーマンスのコンテキストが必要な」エージェント
作業の「動詞」で分ける	必要な「知識と文脈」で分ける

📌 3. 終了条件と収束メカニズムを必ず設計する

どのパターンでも、エージェントが永遠にループする可能性 があります。以下を必ず組み込みましょう。

• ⏰ 最大反復回数 / 時間予算
• 📤 フォールバック戦略（人間エスカレーション or ベスト版返却）
• 📊 コスト監視（トークン使用量の上限）

📌 4. 観測可能性（Observability）に投資する

マルチエージェントシステムで最も困るのは 「何が起きたかわからない」 状態です。以下を最初から組み込むことを推奨します。

🔍 観測ポイント	説明
📝 各エージェントの入出力ログ	何を受け取り、何を返したか
🔗 correlation ID	1つのリクエストに関連するすべてのエージェント活動を追跡
💰 トークン使用量の計測	エージェントごと、リクエストごと
⏱️ レイテンシ計測	各エージェントの処理時間
🔄 反復回数の記録	ループパターンで何回反復したか

📌 5. コスト対効果を常に問う

マルチエージェントは 必ずシングルエージェントよりコストが高い です。一般に、マルチエージェントが価値を発揮するのは 専門化、並列化、またはスケール経済がコーディネーションオーバーヘッドを正当化する場合 に限られます。マルチエージェントにすること自体が目的にならないよう注意しましょう。

---

🎯 まとめ

📌 5つのパターン一覧

パターン	🔑 一言で	⭐ 使いどころ
🔄 Generator-Verifier	生成→検証ループ	品質重視、評価基準が明示的
🏗️ Orchestrator-Subagent	計画→委任→統合	タスクの明確な分解、まず最初に試す
👥 Agent Teams	持続ワーカー並列	長時間の独立した並列タスク
📡 Message Bus	イベント駆動 pub/sub	エージェントが増え続ける環境
🧠 Shared State	共有ストア協調	リアルタイムの発見共有、単一障害点の排除

🌱 発展的なトピック

トピック	内容
🔧 フレームワーク実装	LangGraph / CrewAI / OpenAI Agents SDK / Google ADK での各パターン実装
🏢 エンタープライズ規模	数十〜数百エージェントの管理とガバナンス
🤝 Agent-to-Agent Protocol	エージェント間の標準通信プロトコル（A2A）
🔌 MCP (Model Context Protocol)	エージェントが外部ツールにアクセスする標準化
💰 コスト最適化	シングルエージェント vs マルチエージェントの経済性判断

💭 最後に一言

マルチエージェント協調パターンは、「より多くのエージェント = より良い結果」ではない という直感に反する現実と向き合うためのフレームワークです。5つのパターンは、それぞれ異なるトレードオフを持ち、異なる問題の構造に最適化されています。重要なのは最も高度なパターンを選ぶことではなく、あなたの問題の構造に合ったパターンを選ぶこと です。そして、その判断を正しくするための最も確実な方法は、シンプルなものから始めて、現実のフィードバックに基づいて進化させること です。

---

📚 参考

• 🔗 Multi-agent coordination patterns: Five approaches and when to use them (Claude Blog) — Anthropicによる5つの協調パターンの公式解説
• 🔗 How we built our multi-agent research system (Anthropic Engineering) — Anthropicのマルチエージェントリサーチシステム実装解説
• 🔗 AI Agent Orchestration Patterns (Microsoft Azure) — Microsoftによるエージェントオーケストレーションパターン解説
• 🔗 The Orchestration of Multi-Agent Systems (arXiv) — MASアーキテクチャの学術調査
• 🔗 Developer's guide to multi-agent patterns in ADK (Google) — Google ADKでのマルチエージェントパターンガイド
• 🔗 Agent orchestration - OpenAI Agents SDK — OpenAIのhandoff抽象化