Orchestrator-Workers（オーケストレータ・ワーカー）

中央のオーケストレータLLMがタスクを動的に分解し、専門化されたワーカーLLMへ委譲して、結果を統合する。ワーカーごとに文脈と権限を隔離することで、単一エージェントの肥大化を構造的に防ぐ。

別名

呼称	出典
Hierarchical Delegation（階層委譲）	マルチエージェント構成の一般的呼称
Magentic Orchestration	Microsoft「AI Agent Orchestration Patterns」。タスク台帳を構築・更新する発展形
Supervisor	LangGraph 等のマルチエージェントフレームワークでの慣用名
Manager pattern（agents as tools）	OpenAI「A Practical Guide to Building Agents」。中央エージェントがサブエージェントをツールとして呼ぶ集中型

問題

複合タスクには、必要なサブタスクを事前に予測できないものがある。たとえばコーディングタスクでは、変更すべきファイルの数も各ファイルへの変更内容もタスクの入力に依存し、開発者が事前定義した並列分岐（Parallelization）では書けない。

かといって単一エージェントに全ドメインの知識とツールを持たせると、システムプロンプトは肥大し、ツールが多すぎて選択精度が落ち、あるドメインの中間出力が別ドメインの推論を汚染する。単一エージェントの信頼性が、詰め込んだ責務の数に反比例して劣化していく。

コンテキスト

適用する:

サブタスクの数と内容が入力依存で動的に決まるタスク（大規模コード変更、複数ソースにまたがる調査・検索）
複数ドメインの専門性が必要で、プロンプトとツールを分けたほうが各々の精度が上がる場合
エージェントごとに別個のセキュリティ境界・権限（最小権限のツール群）が必要な場合

適用しない（不要な）ケース:

サブタスクを事前定義できる——固定分岐なら Parallelization、固定順序なら Prompt Chaining で足りる
単一エージェント+ツールで信頼できる——Azure が指摘するとおり、調整オーバーヘッドが専門化の利益を上回ることが多い
低レイテンシ要求——分解・委譲・統合の多段呼出は原理的に遅い

解決

オーケストレータLLMが (1) タスクを分析してサブタスク計画を生成し、(2) 各サブタスクを専門ワーカーへ委譲し（独立したサブタスクは並列実行可）、(3) ワーカーの結果を検証・統合する。各ワーカーは独立した文脈・専用プロンプト・最小権限のツール群を持つ。ワーカーへの指示は自己完結にし、ワーカーからは生の全文脈ではなく要約された結果だけをオーケストレータへ返して、文脈の膨張と相互汚染を防ぐ。Azure の発展形（Magentic）では、オーケストレータがタスク台帳を反復的に更新しながら委譲を繰り返し、停滞監視やループガードを組み込む。

python

def run(task):
    plan = llm("タスクを分析し、サブタスクと担当を計画する", task)
    results = []
    for subtask in plan.subtasks:          # 独立したサブタスクは並列実行してよい
        worker_input = {
            "instruction": subtask.self_contained_instruction,  # 自己完結の指示
            "tools": subtask.minimum_privilege_tools,           # 最小権限のツール群
        }
        result = llm("担当範囲を実行し、要約結果を返す", worker_input)
        if not validate_schema(result):    # 結果の形式検証は決定論的コードで行う
            result = retry_or_fail(subtask)
        results.append(result)
    return llm("各ワーカーの要約結果を検証・統合して最終成果物を作る", results)

実装の要点:

ワーカーへの指示は自己完結にする。 オーケストレータの会話履歴を丸ごと渡すと、隔離の利点が消えて文脈汚染が復活する。サブタスクの遂行に必要な情報だけを明示的に詰める
返すのは要約された結果に限る。 ワーカーの全ツールログをオーケストレータに合流させると、文脈が乗算的に膨張する。成果と要点のみを返す契約にする
ワーカー単位で最小権限を徹底する。 ツール・認証情報・データアクセスをワーカーの責務に必要な範囲へ絞る。権限分離こそ単一エージェントに対する本質的な優位である

トレードオフ

✅ 事前予測できないタスクを動的に分割統治でき、専門プロンプト＋専用ツールにより各サブタスクの精度が上がる
✅ 文脈と権限がワーカー単位で隔離され、プロンプト汚染と越権アクセスを指示ではなく構造で防止できる
⚠️ 調整オーバーヘッドが大きい。モデル呼出が乗算的に増え、レイテンシとトークンコストが単一エージェントの数倍になりうる
⚠️ 分散システム的な障害モード（ワーカー障害、結果の矛盾、部分失敗の統合）を持ち込む。タイムアウト・リトライ・矛盾解消の設計が別途必要になる

クラウドパターンとの対応

クラウドパターン	本パターンでの再定義
Scheduler Agent Supervisor	「タスクのスケジュール・実行・監視を分離した役割に分ける」構造を継承しつつ、分解と委譲の判断自体が決定論的なスケジューラからLLMのセマンティックな推論に変わった
Fan-out/Fan-in	「作業の並列分配と結果集約」を、ワーカー並列実行の下部構造としてそのまま継承。何をファンアウトするかを実行時にLLMが決める点だけが異なる

出典・参考

Anthropic — Building Effective Agents（orchestrator-workers ワークフローの定義と Parallelization との違い）
OpenAI — A Practical Guide to Building Agents（manager パターン: 中央エージェントがサブエージェントをツールとして呼ぶ集中型オーケストレーション）
Microsoft — AI Agent Orchestration Patterns（複雑度レベルの選定基準、Magentic Orchestration）
Azure Architecture Center — Scheduler Agent Supervisor pattern（系譜元のクラウドパターン）

Orchestrator-Workers（オーケストレータ・ワーカー） ​

別名 ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

クラウドパターンとの対応 ​

関連パターン ​

出典・参考 ​

Orchestrator-Workers（オーケストレータ・ワーカー）

別名

問題

コンテキスト

解決

トレードオフ

クラウドパターンとの対応

関連パターン

出典・参考