AI Agent Orchestration

AIエージェントのオーケストレーションは、複数のAIエージェント、モデル、ツールからなるシステムを調整するレイヤーです。タスクの各部分をどのコンポーネントが処理するか、それぞれにどのコンテキストを渡すか、どの順序で実行するか、互いにどのように作業を引き継ぐか、そして結果をどう統合して検証するかを決定します。オーケストレーターは、固定された制御フローを持つ通常のコード、実行時に計画と委任を行うLLM、またはその両方の組み合わせで実装できます。オーケストレーションにより、検索エージェント、コーディングエージェント、コンピュータービジョンモデルなどの専門コンポーネントを組み合わせ、単一の大規模言語モデル（LLM）呼び出しでは完了できないタスクを実行するシステムを構築できます。

オーケストレーションレイヤーの役割#

• ルーティング: 各サブタスクを、最適なエージェントまたはモデルに割り当てます。多くの場合、簡単なステップには小型で高速なモデル、難しいステップには最先端モデルを使います。
• コンテキスト管理: 各エージェントには必要な指示、ファイル、過去の結果だけを渡します。別々のコンテキストウィンドウで動作するサブエージェントは、詳細な探索を行い、リードエージェントのコンテキストを埋め尽くす代わりに短い要約を返せます。
• 構造化されたハンドオフ: JSONの固定スキーマなど、検証済みのデータとしてエージェント間で結果を渡し、次のステップがその形式を前提に処理できるようにします。
• エラー処理: 失敗したステップを再試行し、タイムアウトと予算を適用し、重大な操作の前に人による承認を求めます。
• 可観測性: すべての呼び出し、ツールの結果、判断のトレースを記録し、障害の特定と再現を可能にします。

一般的なオーケストレーションパターン#

ほとんどのシステムは、いくつかのよく使われるオーケストレーションパターンを組み合わせています。

• 逐次パイプライン: 下書き、レビュー、翻訳のように、各エージェントが決まった順序で前のエージェントの出力を処理します。
• 並列ファンアウト: 複数のエージェントが同じ入力を並列に処理し、集約器が結果を統合するか、投票で決定します。
• オーケストレーターとワーカー: リードエージェントが実行時にタスクをサブタスクに分割し、ワーカーエージェントに委任して、返された結果を統合します。この階層型パターンは、手順を事前に列挙できないオープンエンドなタスクに適しています。
• ハンドオフ: エージェントが会話全体を、より適切な専門エージェントに引き継ぎます。たとえば、トリアージエージェントが請求に関する質問を請求担当エージェントに渡します。
• グループチャットとディベート: エージェントが共有スレッドで順番に発言し、モデレーターのもとで互いの意見を批評し、発展させます。
• 評価器・オプティマイザー: 1つのエージェントが結果を作成し、別のエージェントが基準に照らして評価します。結果が合格するまでこの処理を繰り返します。

LangGraph、OpenAI Agents SDK、GoogleのAgent Development Kit、そしてAutoGenとSemantic Kernelの後継であるMicrosoft Agent Frameworkなどのフレームワークは、共有状態を持つエージェントとツールのグラフとして、これらのパターンを実装します。2つのオープンプロトコルが各要素を接続します。モデルコンテキストプロトコル (MCP)はエージェントをツールやデータに接続し、Agent2Agent (A2A)プロトコルは、異なるベンダーが構築したエージェント同士がタスクを委任できるようにします。

オーケストレーションと関連用語の比較#

• エージェント型ワークフロー: ワークフローは、LLMの呼び出しとツールをあらかじめ定めた順序で実行するものです。オーケストレーションは、多数のエージェントとワークフローをより広く調整するもので、コードによって、または実行時に計画を立てるLLMによって駆動できます。
• エージェントの混合 (MoA): 複数のモデルが同じプロンプトに回答し、集約モデルが改善した回答を1つ作成する、特定の並列パターンです。一般的なオーケストレーションでは、通常、異なるサブタスクを異なるエージェントに割り当てます。
• 複合AIシステム: モデル、リトリーバー、ツールを組み合わせたシステムの総称です。オーケストレーションは、そのようなシステム内部の制御ロジックです。
• Kubernetesとコンテナオーケストレーション: マシン間でコンテナをスケジュールし、スケールします。エージェントオーケストレーションは推論とツールの各ステップを調整し、エージェントプラットフォームは多くの場合、基盤となるコンテナオーケストレーター上で実行されます。

ビジョンモデルのオーケストレーション#

ビジョンシステムも、モデルをワーカーとして同じパターンを適用します。高速な物体検出器がすべての画像を処理し、低速な専門モデルに回す画像を判定します。Ultralytics Platform Agentsでは、こうしたワークフローを視覚的に構築できます。YOLO26ブロックを、検出数や信頼度の範囲を確認するGateブロックにつなぎ、さらに視覚言語モデル、データセット、Slack、Webhookの各ブロックへ接続します。これにより、「YOLO → VLM Monitor」ワークフローでは、YOLOが人物を検出したときだけVLMにシーンの説明を求めます。Pythonで同じルーティングを行う場合、検出器が人物を検出したときだけ画像を姿勢推定ワーカーに送ります。

from ultralytics import YOLO

# Worker models: a general detector and a pose specialist
detector = YOLO("yolo26n.pt")
pose_worker = YOLO("yolo26n-pose.pt")
image = "https://ultralytics.com/images/bus.jpg"

# Orchestrator step 1: run the detector and read its findings
detections = detector(image)[0]
people = int((detections.boxes.cls == 0).sum())

# Orchestrator step 2: route to the pose worker only when people are present
if people:
    poses = pose_worker(image)[0]
    print(f"{people} people detected, {len(poses.keypoints)} poses estimated")
else:
    print("No people detected, pose worker skipped")

検出器の結果によって2つ目のモデルを実行するかどうかが決まります。この仕組みにより、ゲート付きパイプラインは必要のない画像に高コストなモデルを適用せずに済みます。

実際のアプリケーション#

• 製造: センサーがアラートを発すると、オーケストレーターはカメラのフレームを欠陥検査エージェントに送り、LLMエージェントに保守ログを検索させます。その後、両方の調査結果を修理チケットにまとめます。
• ドキュメント処理: スキャンしたページを物体検出とOCRのワーカーに渡して表やフィールドを抽出し、推論モデルが抽出値をポリシーと照合します。信頼度の低いページは人間のレビュアーに回します。
• エージェント型コーディング: コーディングエージェントはサブエージェントを起動してコードベースの検索、テストの実行、差分のレビューを行わせ、メインの変更に使う自身のコンテキストを確保します。
• カスタマーサービス: トリアージエージェントがリクエストを特定し、適切なツールと権限を持つ請求、技術サポート、返品の各エージェントに引き継ぎます。

コストと障害モード#

オーケストレーションによって能力が高まる一方、トークン消費量と複雑さも増します。Anthropicのマルチエージェント研究システムでは、Claude Sonnet 4のサブエージェントを指揮するClaude Opus 4のリードエージェントが、社内の研究評価で単独のClaude Opus 4エージェントを90.2%上回りました。一方、マルチエージェント実行のトークン数はチャットの約15倍だったため、このパターンが効果を発揮するのは主に、並列に分割できる広範なタスクです。調整によって新たな失敗の可能性も生じます。エージェントが指示を誤読したり、互いに情報を隠したり、タスクの確認前に停止したりすることがあります。マルチエージェントLLMシステムが失敗する理由を調べた研究では、7つのフレームワークから収集した注釈付きトレース1,600件以上を、システム設計上の問題、エージェント間の不整合、タスク検証の3つに分類される14の失敗モードに整理しました。