AIエージェントのオーケストレーション

オーケストレーション（Orchestration）とは、複数のエージェントやツールを協調させて、単一のエージェントでは困難な複雑なタスクを達成するための設計・制御の仕組みです。どのエージェントに何を任せるか、どの順序で実行するか、人間の確認をどこに挟むかを管理します。

対象読者: AIエージェントの基本概念を理解しており、複数エージェントの協調や本番運用を学びたい方

学習時間の目安: 読了 25分

前提知識: AIエージェントとは

オーケストレーションとは

オーケストレーションとは、複数のエージェント・ツール・処理ステップを協調させて、複雑なタスクを達成する設計手法です。

1つのエージェントがすべての処理を担当するシングルエージェント構成から、専門化した複数エージェントが連携するマルチエージェント構成まで、タスクの複雑さや要件に応じて選択します。

オーケストレーションを適切に設計することで以下のメリットが得られます。

複雑なタスクを並列実行し、完了時間を短縮できる
専門化したエージェントを組み合わせることで、各処理の品質が向上する
人間の確認ステップを適切に組み込み、信頼性の高いシステムを構築できる

オーケストレーションパターン3種

パターン1: シングルエージェント

1つのLLMがすべてのツールを直接呼び出して処理するシンプルな構成です。

graph TD
    User["ユーザー"] --> Agent["エージェント\n（LLMコア）"]

    subgraph Tools["ツール群"]
        T1["Web検索"]
        T2["コード実行"]
        T3["ファイル操作"]
        T4["外部API"]
    end

    Agent --> T1
    Agent --> T2
    Agent --> T3
    Agent --> T4

    T1 --> Agent
    T2 --> Agent
    T3 --> Agent
    T4 --> Agent

    Agent --> Result["結果"]

特徴と向いている用途

項目	内容
メリット	シンプルで実装が容易、コンテキストが1つなので一貫性を保ちやすい
デメリット	複雑なタスクではコンテキストが長くなりすぎる、並列実行が難しい
向いている用途	比較的シンプルなタスク、ツール数が少ない場合、プロトタイプ開発

パターン2: マルチエージェント

オーケストレーター（親エージェント）が全体の計画を立て、専門化したサブエージェント（子エージェント）に個別のタスクを委任する構成です。

graph TD
    User["ユーザー"] --> Orchestrator["オーケストレーター\n（親エージェント）\n計画・タスク分解・統合"]

    Orchestrator --> SubA["リサーチエージェント\nWeb検索・情報収集"]
    Orchestrator --> SubB["ライティングエージェント\n文章生成・編集"]
    Orchestrator --> SubC["レビューエージェント\n品質チェック・校正"]

    SubA --> |"収集した情報"| Orchestrator
    SubB --> |"生成した文章"| Orchestrator
    SubC --> |"レビュー結果"| Orchestrator

    Orchestrator --> Result["最終成果物"]

具体例: 調査レポート生成

オーケストレーター: 「EV市場レポートを作成する」ゴールをタスクに分解
リサーチエージェント: 市場データ・競合情報を並列で収集
ライティングエージェント: 収集情報をもとにレポート本文を生成
レビューエージェント: 事実確認・文章品質をチェック
オーケストレーター: 各エージェントの出力を統合して最終成果物を生成

特徴と向いている用途

項目	内容
メリット	専門化による品質向上、並列実行による高速化、コンテキスト分散
デメリット	エージェント間の情報受け渡し設計が必要、オーバーヘッドが増加
向いている用途	複雑なタスク、各フェーズで異なる専門性が必要な場合

パターン3: 階層型マルチエージェント

複数層のエージェント階層を持つ最も複雑な構成です。大規模なソフトウェア開発プロジェクトや組織のような複合タスクに対応します。

graph TD
    User["ユーザー"] --> Top["トップレベル\nオーケストレーター"]

    Top --> Mid1["ミドル\nオーケストレーターA\n（フロントエンド担当）"]
    Top --> Mid2["ミドル\nオーケストレーターB\n（バックエンド担当）"]

    Mid1 --> Sub1["コーディング\nエージェント"]
    Mid1 --> Sub2["テスト\nエージェント"]

    Mid2 --> Sub3["API設計\nエージェント"]
    Mid2 --> Sub4["DB設計\nエージェント"]

    Sub1 --> Mid1
    Sub2 --> Mid1
    Sub3 --> Mid2
    Sub4 --> Mid2

    Mid1 --> Top
    Mid2 --> Top

    Top --> Result["完成したシステム"]

特徴と向いている用途

項目	内容
メリット	大規模・複雑なタスクを体系的に分解できる、スケールしやすい
デメリット	設計・実装の複雑度が高い、デバッグが難しい
向いている用途	大規模ソフトウェア開発、複数の独立したサブシステムが必要なタスク

パターン比較

観点	シングルエージェント	マルチエージェント	階層型
実装複雑度	低	中	高
並列処理	限定的	可能	可能・効率的
コンテキスト管理	1つのコンテキスト	エージェントごと	階層ごと
専門化	なし	あり	多層的
向いているタスク規模	小〜中	中〜大	大〜超大

並列実行 vs 順次実行

タスク間の依存関係によって、並列実行と順次実行を使い分けます。

graph LR
    subgraph Parallel["並列実行（依存関係なし）"]
        P_Start["タスク開始"] --> PA["サブタスクA"]
        P_Start --> PB["サブタスクB"]
        P_Start --> PC["サブタスクC"]
        PA --> P_End["統合・完了"]
        PB --> P_End
        PC --> P_End
    end

    subgraph Sequential["順次実行（依存関係あり）"]
        S1["ステップ1\nデータ収集"] --> S2["ステップ2\nデータ分析"]
        S2 --> S3["ステップ3\nレポート生成"]
        S3 --> S4["ステップ4\n最終確認"]
    end

並列実行が適しているケース

複数のWebページを同時にスクレイピングする
異なるデータソースから独立して情報を収集する
複数のコードファイルを同時にレビューする

順次実行が必要なケース

前のステップの結果が次のステップの入力になる
データ収集 → 分析 → レポート生成のように依存関係がある
承認が得られた場合のみ次の処理を実行する

Human-in-the-loop（人間の介入）

Human-in-the-loop（HITL）とは、エージェントの処理フローの特定ポイントで人間の確認や承認を求める設計パターンです。

なぜ重要か

エージェントが完全自律で動作すると、以下のリスクが生じます。

不可逆な操作のミス: ファイルの削除、メールの送信、データベースの更新は取り消せない
高リスクな判断の誤り: 重要な意思決定をエージェントだけに任せると責任の所在が不明確になる
コンテキストの欠如: エージェントはユーザーの真の意図や組織の方針を完全には理解できない

実装パターン

sequenceDiagram
    participant U as ユーザー
    participant O as オーケストレーター
    participant A as エージェント
    participant T as ツール

    U->>O: タスク依頼
    O->>A: サブタスク委任
    A->>A: 計画立案
    A->>U: 承認リクエスト（高リスク操作前）
    Note over A,U: 「以下のファイルを削除しますか？」
    U->>A: 承認
    A->>T: ツール実行
    T->>A: 実行結果
    A->>O: サブタスク完了
    O->>U: 最終結果

承認が推奨される操作の例

リスクレベル	操作例	対応
高	ファイル削除・メール送信・支払い処理	必ず人間の承認を求める
中	重要ファイルの変更・外部サービスへのPOST	変更内容を表示して確認
低	ファイル読み取り・Web検索	自動実行してよい

コンテキスト管理の課題

長いタスクや複数エージェントの協調では、コンテキスト管理が重要な課題になります。

主な課題

コンテキスト長の制限

LLMにはコンテキストウィンドウ（一度に処理できるテキスト量）の上限があります。長いタスクでは蓄積された情報がウィンドウを超えてしまいます。

サブエージェントへの情報受け渡し

親エージェントから子エージェントへ渡す情報が多すぎると非効率、少なすぎると処理の質が下がります。

対処法

課題	対処法
コンテキスト長の超過	重要情報の要約、古いコンテキストのアーカイブ
情報受け渡しの最適化	構造化された中間成果物（JSON等）の活用
状態の永続化	外部メモリ（ベクトルDB、ファイル）への保存

Claude Code SDKでのサブエージェント例

Anthropic の Claude Code SDK では、以下のようにサブエージェントを並列実行できます（概念的な例）。

# Python（概念的なコードスニペット）
# Claude Code SDK を使ったマルチエージェントの例

import anthropic

client = anthropic.Anthropic()

# オーケストレーターが複数のサブタスクを並列に起動する
async def run_parallel_agents(tasks: list[str]):
    """複数のサブエージェントを並列実行する"""

    # 各タスクを独立したサブエージェントに委任
    results = await asyncio.gather(*[
        run_subagent(task) for task in tasks
    ])

    return results

async def run_subagent(task: str) -> str:
    """単一のサブエージェントを実行する"""
    response = await client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=4096,
        system="あなたは専門的なリサーチエージェントです。",
        messages=[{"role": "user", "content": task}]
    )
    return response.content[0].text

# 使用例
tasks = [
    "EV市場の最新動向を調査してください",
    "主要プレイヤーの市場シェアを調査してください",
    "日本市場の特徴を調査してください",
]
# 3つのサブエージェントが並列で実行される
results = await run_parallel_agents(tasks)

実際の Claude Code SDK では claude -p "タスク" コマンドでサブエージェントを起動する形態も利用できます。詳細はフレームワーク比較を参照してください。

まとめ

オーケストレーションとは複数エージェントを協調させてタスクを達成する設計手法
3つのパターン：シングルエージェント（シンプル）、マルチエージェント（専門化）、階層型（大規模）
独立したタスクは並列実行、依存関係があるタスクは順次実行で効率化する
Human-in-the-loopは不可逆な操作や高リスクな判断に必須の安全設計
コンテキスト管理（長さの制御・情報受け渡しの設計）が実用システムの鍵になる

よくある質問

Q: マルチエージェントにするとコストは増えますか？

A: はい、エージェントの数だけLLM呼び出しが増えるため、コストは増加します。ただし、並列実行による時間短縮や、専門化による品質向上で費用対効果が向上するケースも多くあります。タスクの複雑さとコストのトレードオフを考慮して設計してください。

Q: Human-in-the-loopを入れると自律性が失われませんか？

A: 承認ポイントは必要最小限にすることが重要です。リスクの低い操作は自律実行し、不可逆な操作・高リスクな判断のみ確認を求める設計にすることで、安全性と自律性のバランスを保てます。

Q: コンテキストウィンドウの上限はどのくらいですか？

A: 2026年時点で、Claude 3.7 Sonnet は200Kトークン、GPT-4o は128Kトークンのコンテキストウィンドウを持ちます。日本語テキストの場合、1トークンはおよそ1〜2文字に相当します。長期タスクでは要約・外部メモリ活用が実用上必要になります。

Q: サブエージェントに渡す情報はどう決めればいいですか？

A: サブエージェントがタスクを完了するために最低限必要な情報のみを渡す設計が基本です。ゴール・制約条件・前のステップの重要な結果をコンパクトに構造化（JSON形式など）して渡すと、効率と精度のバランスが取れます。

参考資料

次のステップ: AIエージェントフレームワーク（2026年版）

このページへのリンク（英語）: AI Agent Orchestration