multi-agent-patterns

マルチエージェントアーキテクチャのパターン

マルチエージェントアーキテクチャでは、それぞれが独自のコンテキストウィンドウを持つ複数の言語モデルインスタンスに作業を分散します。適切に設計すれば、この分散により単一エージェントの限界を超える機能を実現できます。設計が不適切だと、調整のオーバーヘッドによって利点が損なわれます。重要なのは、サブエージェントは主にコンテキストを分離するために存在するのであり、役割分担を擬人化するためではないという点です。

使いどき

次の場合にこのスキルを有効にしてください。

• 単一エージェントのコンテキスト上限によって、タスクの複雑さに対応できない場合
• タスクを自然に並列のサブタスクへ分割できる場合
• サブタスクごとに異なるツールセットやシステムプロンプトが必要な場合
• 複数のドメインを同時に扱う必要があるシステムを構築する場合
• 単一コンテキストの上限を超えて、エージェントの能力を拡張する場合
• 複数の専門コンポーネントを備えた本番エージェントシステムを設計する場合

他のスキルが担当する関連作業では、このスキルを有効にしないでください。

• トポロジーが決まる前に、タスクとモデルの適合性、パイプラインの構成、プロジェクトレベルのコストを判断する：project-development。
• ホスト型サンドボックス、ウォームプール、リモートセッション、バックグラウンドランタイムのインフラストラクチャを設計する：hosted-agents。
• 管理されたランタイムで、KV キャッシュの圧縮を通じてオーケストレーターの状態を共有する：latent-briefing。
• 各エージェントが公開するツールを設計する：tool-design。

基本概念

単一エージェントのコンテキストウィンドウに、タスクに関連するすべての情報を収められない場合は、マルチエージェントのパターンを使用してください。最大の利点はコンテキストの分離です。各エージェントは、他のサブタスクから蓄積されたノイズのないクリーンなコンテキストで動作し、情報が要約を繰り返すうちに劣化する「伝言ゲーム」の問題を防ぎます。

組織上のたとえではなく、調整の必要性に基づいて、主な3つのパターンから選んでください。

• スーパーバイザー／オーケストレーター — タスクを明確に分解でき、人間による監督が重要な場合に、中央集権的な制御に使用します。単一のコーディネーターが専門エージェントに作業を委任し、結果を統合します。
• ピアツーピア／スウォーム — 厳密な計画がかえって妨げになる場合に、柔軟な探索に使用します。明示的なハンドオフの仕組みを通じて、どのエージェントからでも別のエージェントへ制御を引き継げます。
• 階層型 — 抽象化の階層（戦略、計画、実行）を持つ大規模プロジェクトに使用します。各階層は、それぞれ独自のコンテキスト構造を用いて、異なる詳細レベルで動作します。

すべてのマルチエージェントシステムは、明示的な調整プロトコル、追従を抑える合意形成の仕組み、そしてエラーの連鎖的な伝播を防ぐ障害処理を軸に設計してください。

詳細トピック

マルチエージェントアーキテクチャを採用する理由

コンテキストのボトルネック 単一のエージェントのコンテキストが、蓄積された履歴、取得したドキュメント、ツールの出力でいっぱいになり、パフォーマンスが低下する場合は、マルチエージェントアーキテクチャを検討してください。パフォーマンス低下の兆候は3つあります。ミドル・ロスト効果（コンテキストの中間にある内容への注意が弱まる）、注意の希薄化（競合する項目が多すぎる）、コンテキスト汚染（無関係な内容が有用な内容を押しのける）です。

作業を複数のコンテキストウィンドウに分割し、各エージェントがサブタスクに集中したクリーンなコンテキストで動作できるようにします。単一のコンテキストにすべての負荷を負わせず、調整レイヤーで結果を集約します。

トークンコストの実情 トークンコストが大幅に増えることを見込んでください。実運用データによると、マルチエージェントシステムは単一エージェントのチャットよりはるかに多くのトークンを消費する可能性があります（claim-multi-agent-token-multiplier）。

アーキテクチャ	トークン倍率	ユースケース
単一エージェントのチャット	基準値	単純なクエリ
ツールを使う単一エージェント	基準値より高い	ツールを使うタスク
マルチエージェントシステム	基準値より大幅に高い	複雑な調査／調整

ブラウジングエージェントの評価研究では、トークン使用量、ツール呼び出し、モデルの選択がパフォーマンスのばらつきを大きく左右することが示されています（claim-evaluation-browsecomp-variance）。これは、エージェントを増やせば効果があると決めつけず、マルチエージェント構成を単一エージェントのベースラインと比較して測定することを裏付けています。

アーキテクチャ設計と同様に、モデルの選択も優先してください。より優れたモデルへのアップグレードは、多くの場合、トークン予算を2倍にするより大きなパフォーマンス向上をもたらします。BrowseCompのデータによると、モデル品質の向上は、単純なトークン数の増加を上回ることが少なくありません。モデルの選択とマルチエージェントアーキテクチャは、相互補完的な戦略として扱ってください。

並列化の論拠 並列化できるサブタスクは、単一のエージェントで順番に処理するのではなく、新しいコンテキストを持つ専用エージェントに割り当てます。複数の独立した情報源を検索する、異なるドキュメントを分析する、あるいは競合するアプローチを比較する必要がある調査タスクでは、並列実行が有効です。実際の所要時間は、すべてのサブタスクの所要時間の合計ではなく、最も長いサブタスクの所要時間に近づきます。

専門化の論拠 各エージェントには、特定のサブタスクに必要なシステムプロンプト、ツール、コンテキストだけを設定します。汎用エージェントは、考えられるすべての構成をコンテキストに保持する必要があり、そのぶん注意が分散します。専門化されたエージェントは必要なものだけを保持し、各分野に最適化された簡潔なコンテキストで動作します。コーディネーターから専門エージェントにタスクを振り分けることで、組み合わせの爆発を避けながら専門化を実現できます。

アーキテクチャパターン

パターン 1：スーパーバイザー／オーケストレーター グローバルな状態と軌跡を維持し、ユーザーの目標をサブタスクに分解して、適切なワーカーに割り当てる中央エージェントを配置します。

User Query -> Supervisor -> [Specialist, Specialist, Specialist] -> Aggregation -> Final Output

次の場合にこのパターンを選択します：タスクを明確に分解できる場合、複数の領域にまたがる調整が必要な場合、または人間による監督が重要な場合。

次のようなトレードオフがあります：ワークフローを厳密に制御でき、人間が途中で介入しやすい一方で、スーパーバイザーのコンテキストがボトルネックになり、スーパーバイザーの障害がすべてのワーカーに波及します。また、スーパーバイザーがサブエージェントの応答を誤って言い換える「伝言ゲーム」の問題が発生します。

伝言ゲームの問題と解決策 伝言ゲームの問題により、スーパーバイザーアーキテクチャは最適化されたバージョンより当初約 50％性能が低くなると想定してください（LangGraph のベンチマーク）。スーパーバイザーがサブエージェントの応答を言い換えるたびに、忠実性が失われます。

サブエージェントが応答をユーザーに直接渡せるようにする forward_message ツールを実装して解決します。

def forward_message(message: str, to_user: bool = True):
    """
    Forward sub-agent response directly to user without supervisor synthesis.

    Use when:
    - Sub-agent response is final and complete
    - Supervisor synthesis would lose important details
    - Response format must be preserved exactly
    """
    if to_user:
        return {"type": "direct_response", "content": message}
    return {"type": "supervisor_input", "content": message}

サブエージェントがユーザーに直接応答できる場合は、スウォームアーキテクチャをスーパーバイザーより優先してください。これにより、伝達時の誤りを完全に排除できます。

パターン 2：ピアツーピア／スウォーム 中央制御をなくし、事前に定義されたプロトコルに基づいてエージェント同士が直接通信できるようにします。明示的な引き継ぎメカニズムを通じて、任意のエージェントから別のエージェントに制御を移します。

def transfer_to_agent_b():
    return agent_b  # Handoff via function return

agent_a = Agent(
    name="Agent A",
    functions=[transfer_to_agent_b]
)

次の場合にこのパターンを選択します：タスクに柔軟な探索が必要な場合、厳格な計画がかえって妨げになる場合、または要件が動的に生じ、事前の分解が難しい場合。

次のようなトレードオフがあります：単一障害点がなく、幅優先で効率的に拡張できる一方で、エージェント数が増えると調整が複雑になり、中央の状態管理役がいないと発散のリスクが高まります。また、堅牢な収束制約が不可欠になります。

状態を引き継ぐ明示的な引き継ぎプロトコルを定義します。エージェントが受け取り側のエージェントに、必要なコンテキストを伝えるようにします。

パターン 3：階層型 エージェントを抽象化の階層に沿って編成します。戦略（目標の定義）、計画（タスクの分解）、実行（個別のタスク）に分けます。

Strategy Layer (Goal Definition) -> Planning Layer (Task Decomposition) -> Execution Layer (Atomic Tasks)

次の場合にこのパターンを選択します：プロジェクトに明確な階層構造がある場合、ワークフローに管理階層が含まれる場合、またはタスクに高レベルの計画と詳細な実行の両方が必要な場合。

次のようなトレードオフがあります：関心事を明確に分離でき、階層ごとに異なるコンテキスト構造を扱えます。一方で、階層間の調整コストがかかり、戦略と実行の不整合が生じる可能性があり、エラーの伝播経路も複雑になります。

設計原則としてのコンテキスト分離

マルチエージェントアーキテクチャの主な目的として、コンテキストの分離を捉えます。各サブエージェントは、他のサブタスクで蓄積されたコンテキストを引き継がず、自身のサブタスクに集中できるクリーンなコンテキストウィンドウで動作する必要があります。

分離の仕組み 各サブタスクに適した分離の仕組みを選択します。

• コンテキスト全体の委譲 — プランナーのコンテキスト全体をサブエージェントと共有します。サブエージェントがタスクを完全に理解する必要がある複雑なタスクで使用します。サブエージェントは独自のツールと指示を持ちますが、判断のためにコンテキスト全体を受け取ります。注：この方法では、コンテキスト分離の目的が部分的に損なわれます。
• 指示の受け渡し — 関数呼び出しを通じて指示を作成し、サブエージェントには必要な情報だけを渡します。単純で明確に定義されたサブタスクに使用します。分離を維持できますが、サブエージェントの柔軟性は制限されます。
• ファイルシステムメモリ — エージェントが永続ストレージを読み書きします。共有状態を必要とする複雑なタスクに使用します。ファイルシステムを調整メカニズムとして用いることで、共有状態の受け渡しによるコンテキストの肥大化を回避できます。遅延や整合性に関する課題が生じますが、メッセージパッシングよりも拡張性に優れています。

タスクの複雑さ、調整の必要性、許容できる遅延に基づいて選択します。デフォルトでは指示の受け渡しを使い、共有状態が必要になったらファイルシステムメモリに切り替えます。サブタスクで本当に必要な場合を除き、コンテキスト全体の委譲は避けてください。

合意形成と調整

投票の問題 単純な多数決は避けてください。弱いモデルの幻覚を、強いモデルの推論と同等に扱ってしまいます。介入しなければ、合意を優先する本質的な傾向により、マルチエージェントの議論は誤った前提への合意に陥ります。

重み付き投票 エージェントの投票に、確信度や専門性に応じた重みを付けます。確信度が高いエージェントや、該当分野の専門知識を持つエージェントの意見は、最終判断でより大きな重みを持たせます。

ディベートプロトコル 複数ラウンドにわたり、エージェントが互いの出力を批評するように構成します。複雑な推論では、敵対的な批評のほうが、協調による合意形成より高い精度をもたらすことがよくあります。正しさよりも同調を優先してエージェント同士が賛同する、迎合による収束に注意してください。

トリガーベースの介入 エージェント間のやり取りを監視し、行動上の兆候を確認します。議論が進展しない場合は、停滞トリガーを作動させます。エージェントが独自の推論を示さず、互いの回答を模倣する場合は、迎合トリガーを検知します。

フレームワークに関する考慮事項

フレームワークごとに、これらのパターンの実装方針は異なります。LangGraph は、ノードとエッジを明示的に定義するグラフベースのステートマシンを使用します。AutoGen は、GroupChat を使った会話型／イベント駆動型のパターンを使用します。CrewAI は、階層型のクルー構造による役割ベースのプロセスフローを使用します。

実践的なガイダンス

失敗モードと緩和策

失敗：スーパーバイザーのボトルネック スーパーバイザーはすべてのワーカーからコンテキストを集約するため、飽和や性能低下が起こりやすくなります。

ワーカーの出力スキーマを制約し、要約した情報だけを返すようにして緩和します。チェックポイントを使用してスーパーバイザーの状態を永続化し、完全な履歴をコンテキストに保持せずに済むようにします。

失敗：調整のオーバーヘッド エージェント間の通信はトークンを消費し、レイテンシを増加させます。複雑な調整によって、並列化の利点が相殺されることがあります。

明確な引き継ぎプロトコルを設けて通信を最小限に抑え、緩和します。可能な場合は結果をまとめて処理します。非同期の通信パターンを使用します。長いコンテキストを持つ単一のエージェントと比べて、マルチエージェントの調整によって実際に時間を節約できているか測定します。

失敗：発散 中央で調整されずに異なる目標を追求するエージェントは、意図された目標から逸れていきます。

各エージェントの目標範囲を明確に定義して緩和します。共通の目標に向けて進捗しているかを確認する、収束チェックを実装します。無制限の探索を防ぐため、エージェントの実行に有効期限を設定します。

失敗：エラーの伝播 あるエージェントの出力に含まれるエラーが、その出力を利用する後続のエージェントに伝播し、結果が次第に誤ったものになっていきます。

エージェントの出力を利用側に渡す前に検証し、緩和します。サーキットブレーカーを備えた再試行ロジックを実装します。可能な場合は冪等な操作を使用します。重要な出力がパイプラインに入る前に相互確認する、検証エージェントの追加も検討してください。

例

例 1：調査チームのアーキテクチャ

Supervisor
├── Researcher (web search, document retrieval)
├── Analyzer (data analysis, statistics)
├── Fact-checker (verification, validation)
└── Writer (report generation, formatting)

例 2：引き継ぎプロトコル

def handle_customer_request(request):
    if request.type == "billing":
        return transfer_to(billing_agent)
    elif request.type == "technical":
        return transfer_to(technical_agent)
    elif request.type == "sales":
        return transfer_to(sales_agent)
    else:
        return handle_general(request)

ガイドライン

1. マルチエージェントシステムの主な利点である、コンテキストの分離を重視して設計します
2. 組織上の比喩ではなく、調整の要件に基づいてアーキテクチャパターンを選択します
3. 状態の引き継ぎを伴う、明示的な引き継ぎプロトコルを実装します
4. 合意形成には、重み付き投票またはディベートプロトコルを使用します
5. スーパーバイザーのボトルネックを監視し、チェックポイントを実装します
6. エージェント間で渡す前に出力を検証します
7. 無限ループを防ぐため、有効期限を設定します
8. 障害シナリオを明示的にテストします

注意点

1. スーパーバイザーのボトルネックによるスケーリング — ワーカー数が増えると、スーパーバイザーのコンテキストへの負荷は非線形に増加します。ワーカーが5人以上になると、スーパーバイザーは実際のタスクに取り組むワーカー以上に、サマリーの処理にトークンを費やします。スーパーバイザーごとのワーカー数に上限（3～5人）を設け、1人に過度な負荷をかけるのではなく、スーパーバイザーを2階層にしてください。
2. トークンコストの過小評価 — 複数エージェントの実行コストは、ベースラインの約15倍です。チームは、調整のオーバーヘッド、リトライ、合意形成のラウンドを考慮せず、エージェントごとのコストだけを見積もるため、予算を一貫して少なく見積もります。15倍を見込んで予算を立て、それより少なく済めば幸運だと考えてください。
3. 迎合的な合意形成 — 議論パターンにおけるエージェントは、正しい答えではなく、同意しやすい答えに収束する傾向があります。LLM には本質的に同意を優先するバイアスがあります。明示的に敵対的な役割を割り当て、意見の相違を述べるまで収束を認めないことで対処してください。
4. エージェントの増やしすぎ — エージェントを3～5人以上に増やしても、効果は次第に薄れ、調整のオーバーヘッドが増加します。エージェントを1人追加するごとに、通信経路は二次的に増加します。実用最小限の人数から始め、コンテキストを分離する明確なメリットがある場合にのみ追加してください。
5. メッセージパッシングでの伝言ゲーム — エージェント間で情報が受け渡されるたびに、繰り返し要約されることで情報が劣化します。各エージェントが言い換えるたびに、細かなニュアンスが失われます。複数のエージェントが正確に参照する必要がある状態には、メッセージパッシングではなく、ファイルシステムによる連携を使ってください。
6. エラー伝播の連鎖 — あるエージェントのハルシネーションが、別のエージェントにとっての「事実」になります。後続のエージェントには、上流のハルシネーションと本当の情報を見分ける手段がありません。エージェント間に検証チェックポイントを設け、検証せずに上流の出力を信頼しないでください。
7. 過度な細分化 — タスクを細分化しすぎると、タスクそのものよりも調整のオーバーヘッドが大きくなります。10人のエージェントによる10ステップのパイプラインでは、実際の作業よりも引き継ぎに多くのトークンが使われます。サブタスクがそれぞれ独立したコンテキストで本当に効果を発揮する場合にのみ、細分化してください。
8. 共有状態の欠如 — 共有ファイルシステムや状態ストアなしでエージェントを動作させると、作業が重複し、出力に一貫性がなくなり、すでに完了した作業を把握できなくなります。複数エージェントのワークフローを構築する前に、永続的な共有ストレージを用意してください。

統合

このスキルは、エージェントのトポロジーと調整プロトコルを担当します。関連するスキルは、プロジェクト構成、ホスト型ランタイム、潜在状態の転送を担当します。

• project-development：トポロジーの詳細を検討する前に、プロジェクトレベルで単一エージェントか複数エージェントかを選択します。
• hosted-agents：リモートサンドボックス、セッション、ウォームプール、マルチプレイヤーのインフラストラクチャを担当します。
• memory-systems：エージェント間の永続的な共有状態を担当します。
• tool-design：ツールの専門化と、スポーン／ステータスツールの契約を担当します。
• context-optimization：トークン効率化の手法の1つとして、分割を担当します。
• latent-briefing：モデルが一致する場合に、オーケストレーターとワーカー間で KV キャッシュの軌跡を引き継ぎます。
• evaluation：調整コストを考慮したうえで、複数エージェントが成果を改善するかどうかを測定します。

参考資料

内部資料：

• フレームワークの参考資料 - 参照するタイミング：LangGraph、AutoGen、CrewAI で特定のマルチエージェントパターンを実装する際に、フレームワーク固有のコード例が必要な場合

このコレクションの関連スキル：

• context-fundamentals - 参照するタイミング：エージェントの分割を設計する前に、コンテキストウィンドウの仕組みを理解する必要がある場合
• memory-systems - 参照するタイミング：エージェントがコンテキスト境界をまたいで状態を共有したり、実行間で情報を保持したりする必要がある場合
• context-optimization - 参照するタイミング：個々のエージェントのコンテキストが大きすぎるため、分割または圧縮の方法が必要な場合

外部リソース：

• LangGraph ドキュメント - 参照するタイミング：明示的な状態機械を使ったグラフベースのマルチエージェントワークフローを構築する場合
• AutoGen フレームワーク - 参照するタイミング：会話型の GroupChat パターンやイベント駆動型のエージェント連携を実装する場合
• CrewAI ドキュメント - 参照するタイミング：役割ベースの階層的なエージェントプロセスを設計する場合
• マルチエージェント連携に関する研究 - 参照するタイミング：マルチエージェントシステムの理論と評価に関する学術的な基盤が必要な場合

---

スキルのメタデータ

作成日: 2025-12-20 最終更新日: 2026-05-15 作成者: Agent Skills for Context Engineering Contributors バージョン: 2.1.0