---
title: マルチエージェント オーケストレーション
url: https://doc.liz6.com/ja/ai/02-Agent/04-multi-agent-orchestration
locale: ja
area: ai
tags:
- ai
- Agent
date: 2026-06-30
modified: 2026-07-19
description: 単一のエージェントが、コンテキストの膨張、直列処理、多岐にわたって専門性に欠けるという3つの壁にぶつかる。マルチエージェントオーケストレーションは、作業を連携するエージェントに分散する——決定論的オーケストレーション（チェーンリング/ルーティング）からエージェンティックなオーケストレーション（オーケストレーター-ワーカー）へ。中核的な利点は、コンテキストの分離と並列処理である。
---

# マルチエージェント オーケストレーション

> 単一エージェントは、コンテキストの膨張、直列処理、多岐にわたって専門性に欠けるという3つの壁にぶつかる。マルチエージェント オーケストレーションは、作業を連携するエージェントに分散する——決定論的オーケストレーション（チェーンリング/ルーティング）からエージェンティックなオーケストレーション（オーケストレーター-ワーカー）へ。中核的な利点は、コンテキストの分離と並列処理である。

## 概要

単一エージェント（[エージェント ループ](/ai/02-Agent/01-the-agent-loop-and-tool-use.md)）はすべてを自分で行おうとし、3つの壁にぶつかる。**コンテキストの膨張**（1つのウィンドウに全作業を詰め込み、中間部分の情報が希釈される）、**直列処理**（ステップバイステップでしか進めず、遅い）、**多岐にわたって専門性に欠ける**（同じシステム プロンプトで探索、計画、実行、審査を兼務し、どの側面も極限まで最適化されない）。マルチエージェント オーケストレーションは、作業を複数の連携するエージェントに分散し、これらの3つの壁を突破する。

しかし、まず冷水を浴びせよう：**多くのタスクにマルチエージェントは必要ない。** 単一エージェント＋優れたツールセットで解決できる場合は、マルチエージェントを採用すべきではない——マルチエージェントは調整オーバーヘッド、コンテキスト同期のコスト、およびデバッグの複雑さを導入する。まず便益を確認する（判断基準は [エージェント ループ](/ai/02-Agent/01-the-agent-loop-and-tool-use.md) の「ワークフロー vs エージェント」の4つの関門：複雑さ／価値／実現可能性／エラーのコスト に同じ）、そして着手する。このページでは、どのようなオーケストレーション パターンが存在するか、それぞれが何を解決するのか、そして Claude エコシステム内でどのように実装され、どのような失敗を招く可能性があるかを明確にする。

## 決定論的オーケストレーションからエージェンティックなオーケストレーションへ

Anthropic の「Building Effective Agents」では、マルチパターンを簡素なものから複雑なものへと並べている。**重要な区別**：最初のいくつかは**コード制御による決定論的オーケストレーション（ワークフロー）**——ステップと分岐はコードでハードコードされており、各ステップでモデルを呼び出すだけである。最後の1つ（オーケストレーター-ワーカー）こそが、モデル自身が動的に作業を分解する「エージェント」的なマルチパターンである。

| パターン | 形態 | 制御主体 | 用途 |
|------|------|--------|------|
| プロンプト チェーニング | A の出力を B にフィードし、パイプラインを形成 | コード | 固定ステップに分解可能 |
| ルーティング | 最初に分類し、専門処理へ振り分け | コード | 入力種類が多く、それぞれに専門処理が必要 |
| 並列化 | 複数のパスを同時に実行し、集約（シャーディングまたはマルチビュー投票） | コード | 並列化可能なサブタスク / マルチビューが必要 |
| **オーケストレーター-ワーカー** | オーケストレーターがタスクをワーカーに**動的**に割り当て | **モデル** | サブタスクの数や形態が事前に決定できない |
| 評価者-最適化者 | 1つが生成、1つが審査し、循環的に改善 | コード＋モデル | 明確な品質基準があり、反復に値する |

**まず決定論的オーケストレーションを使用する。** タスクがチェーンリング/ルーティングでハードコードできる場合は、オーケストレーター-ワーカーを採用すべきではない——決定論的アプローチの方が制御可能で、キャッシュ可能、デバッグしやすい。事前に「いくつのサブタスクに分解するか、それぞれが何か」をハードコードできない場合にのみ、モデルをコーディネーターとして必要とする。

## オーケストレーター-ワーカー：エージェンティックなマルチパターンの中核

```mermaid
flowchart TD
    O["オーケストレーター<br/>目標を理解 → 動的分解 → スケジューリング → 集約"]
    O -->|サブタスク A + 必要なコンテキスト| W1["ワーカー A<br/>独立ウィンドウ"]
    O -->|サブタスク B + 必要なコンテキスト| W2["ワーカー B<br/>独立ウィンドウ"]
    O -->|サブタスク C + 必要なコンテキスト| W3["ワーカー C<br/>独立ウィンドウ"]
    W1 -->|結果の要約| O
    W2 -->|結果の要約| O
    W3 -->|結果の要約| O
    O --> R["総合出力"]
```

これが有用である理由を、3つのメカニズム的観点から説明する。

- **コンテキストの分離**：各ワーカーは**独自のウィンドウ**を使用してサブタスクを処理し、**結果の要約**のみをオーケストレーターに返す。メインのコンテキストは20個のファイルの生内容で埋め尽くされない——これは [コンテキストエンジニアリング](/ai/01-models-and-context/01-context-engineering.md) の「ウィンドウを溢れさせない、中間部分を希釈させない」と直接対応する。これが、「単一エージェントがすべてを読む」ことに対するマルチパターンの最大の利点である。
- **並列ファンアウト**：独立したサブタスクが同時に実行され、ウォールクロック時間が「直列和」から「最遅のもの」に低下する。
- **コスト削減（かつキャッシュを破壊しない）**：サブタスクは**より安価なモデル**で実行できる。ただし、[プロンプト キャッシュ](/ai/01-models-and-context/01-context-engineering.md) という制約がある：**同じループ内で途中でモデルを切り替えると、セグメント全体のキャッシュが無効になる**（キャッシュはモデルごとにバケツ分けされる）。正しい方法は、**別のサブエージェントを立ち上げて安価なモデルを使用**し、メインループでは単一モデルを維持すること——これによりメインループのキャッシュは維持され、サブタスクのコストは削減される。Claude Code の `Explore` サブエージェントは、読み取り専用ファンアウト検索に Haiku などのより安価なモデルを使用するが、これがまさにこのパターンである。

## Claude エコシステム内での実装

- **Claude Code**：`Explore` / サブエージェント——広範な検索や独立したサブタスクをサブエージェントに委任（一般的により安価なモデルを使用）、結果の要約をメインエージェントに返す。メインエージェントのコンテキストとキャッシュは汚染されない。
- **OMC (oh-my-claudecode)**：Claude Code 上で**明示的なチーム オーケストレーション**を行い、探索/計画/実行/審査を専門のエージェントに分散し、以下の原則を堅持する——**記述と審査は別のレーンで行う**：実行エージェントは自身を審査せず、別のレビュアー/検証者が独立したコンテキストで評価を行う。
- **Managed Agents multiagent**（マネージド）：**エージェント**上で `multiagent: {type: "coordinator", agents: [...]}` を宣言し、委任可能な名簿を作成する。ランタイムでは、委任された各サブエージェントが独自の **スレッド** で実行される——コンテキスト分離されたイベント ストリームで、**独立したモデル/システム プロンプト/ツール/スキル** を持つ。メカニズムの詳細：
  - 共有コンテナとファイルシステムを共有するが、**会話履歴は共有しない**；
  - 名簿は1〜20個のエージェントで構成され、同一エージェントの複数のコピーを生成でき、最大 **25 個の並行スレッド** をサポート；
  - **1層の委任のみをサポート**（サブエージェントの名簿はカスケードしない）；
  - スレッド間通信は `agent.thread_message_sent/received` を介して行われ、ツール確認などは**メインスレッドに戻されて処理**される。

## ベストプラクティス

- **多くのタスクにマルチエージェントは必要ない。** 単一エージェント＋優れたツールセットで解決できる場合はマルチエージェントを採用すべきではない。まず複雑さ／価値／実現可能性／エラーのコストの4つの関門を通過する。
- **まず決定論的オーケストレーション、その後動的調整。** チェーンリング/ルーティングでハードコードできる場合はオーケストレーター-ワーカーを採用すべきではない——より制御可能で、キャッシュ可能、デバッグしやすい。
- **コンテキスト分離によって便益を得る。** 各ワーカーは独自のウィンドウを使用し、**結果の要約**のみを返す。メインのコンテキストは生内容で埋め尽くされない。
- **コスト削減にはサブエージェントを別途立ち上げ、メインループ内でモデルを切り替えない。** モデルの切り替えはセグメント全体のキャッシュを無効にする。Claude Code の `Explore` は、読み取り専用ファンアウトに安価なモデルを使用するが、これがまさにこのパターンである。
- **オーケストレーターは、必要なコンテキストを委任メッセージに明示的に記載する。** スレッド間で履歴やツールは共有されないため、ワーカーは「経緯を知らない」。必要なコンテキストはメッセージに書き込むか、共有ファイルに落とし、ワーカーに読ませる。
- **記述と審査は別のレーンで行う。** 実行エージェントは自身を審査せず、別のレビュアー/検証者が独立したコンテキストで評価を行う（[評価と観測可能性](/ai/02-Agent/05-evaluation-and-observability.md) を参照）。

## トレードオフと失敗パターン（修正方法付き）

- **過剰な委任**：`grep`/`read` だけで解決できるケースでもサブエージェントを起動する → 明確なガイダンスを与える：*「並列または独立したワークフローの場合のみ委任する。単一ファイルの読み取りや順序操作は直接実行する。」*
- **調整オーバーヘッド > 便益**：階層が深すぎ、往復が多すぎるため、単一エージェントよりも遅く、高価になる → 委任の深さを制御する（Managed Agents では1層のみ許可）。決定論的オーケストレーションで対応できる場合は動的調整を採用しない。
- **コンテキスト非共有の罠**：スレッド間で履歴やツールが共有されず、ワーカーが「経緯を知らない」 → オーケストレーターは必要なコンテキストを**委任メッセージに明示的に記載**するか、共有ファイルに落とし、ワーカーに読ませる必要がある。
- **モデル切り替えによるキャッシュ破壊**：コスト削減のためにメインループ内でモデルを切り替えると、キャッシュがすべて無効になり、逆に高価になる → サブエージェントで安価なモデルを隔離し、メインループでは切り替えない。
- **自己審査による背书**：実行エージェントが自身の作業を自己評価する → 審査は別のレーンで行う（OMC の実践、[評価と観測可能性](/ai/02-Agent/05-evaluation-and-observability.md) を参照）。

## 参考文献

- **Anthropic 公式ドキュメント**：「Building Effective Agents」、Managed Agents Multi-Agent (platform.claude.com)

*Keywords: マルチエージェント, オーケストレーション, プロンプト チェーニング, ルーティング, 並列化, オーケストレーター-ワーカー, 評価者-最適化者, サブエージェント, Explore, コンテキスト分離, ファンアウト, プロンプト キャッシュ不変条件, モデル切り替えによる無効化, Managed Agents multiagent, コーディネーター, スレッド, スレッド間メッセージ, 1層の委任, OMC チーム, 記述 vs 審査レーン*