オーケストレーション

オーケストレーターは、複数のサブエージェントを調整して、複雑な複数ステップのワークフローを管理します。

サブエージェントの追加によってエージェントをオーケストレーターとして構成すると、エージェントはタスクを計画し、サブエージェントに作業を委任し、その出力を統合する調整レイヤーになります。オーケストレーターはツールを直接実行しません。代わりに、戦略、タスクのルーティング、結果の組み合わせに焦点を当てます。

アーキテクチャ

オーケストレーターは、複数のエージェントを調整する監視レイヤーとして機能します。ツールを直接呼び出すことはありません。

代わりに、次の操作を実行してワークフローを管理します。

エンドユーザーの目標を解釈します。
どのエージェントが必要かを特定する。
これらのエージェントにタスクを委任する。
収集し、その結果を統合します。

利点

モジュラーアーキテクチャ:エージェントは特殊であり、独立して保守できます。
スケーラブルな実行: タスクを並行して実行できます。
堅牢性: 障害は再試行/フォールバックメカニズムで分離されます。
明確な責任分担: オーケストレーターが計画を管理し、エージェントが実行を管理します。
拡張性: 新しいエージェントやツールを簡単に追加できます。

オーケストレータープロンプトの例

javascript

1Workflow Example: Quarterly Sales Report

3 1. Understand end user intent.

4 - Identify that the request involves data extraction, analysis, visualization, and summary generation.

5 2. Break down into subtasks:

6 - Data Extraction → retrieve and prepare sales data

7 - Analysis → compute key metrics (totals, growth rates, etc.)

8 - Visualization → generate charts and graphs

9 - Summary Generation → write a textual executive summary

10 3. Delegate each subtask:

11 - Assign to the most suitable AI agent based on its capabilities

12 - Provide each agent with clear, structured instructions and required inputs

13 4. Monitor and validate responses:

14 - Check if each agent output meets the required format and quality

15 - Retry or reassign if an agent fails or produces incomplete output

16 5. Integrate results:

17 - Combine data, charts, and summary text into a unified final report

18 6. Deliver the final output to the end user in a clear and formatted structure

20 Behavioral Guidelines:

21 - Always focus on planning and coordination, not execution

22 - Use consistent task naming and clear communication between agents

23 - Ensure all outputs are validated before integration

24 - Manage partial failures gracefully: retry or reroute when needed

25 - Maintain transparency in the workflow (log which agent performed which subtask)

27 Example End User Request:

28 "Generate a Q2 sales performance report with visualizations and an executive summary."

30 Expected Orchestrator Behavior:

31 - Break down → Delegate → Monitor → Integrate → Deliver

オーケストレーションを使用するタイミングについては、エージェントの計画を参照してください。

サブエージェントがツールとして使用できるコンポーネントを構築するには、コンポーネント設計を参照してください。

サブエージェントのバージョン管理

オーケストレーターエージェントがサブエージェントを参照する場合、各サブエージェントには独自の独立したバージョンライフサイクルがあります。オーケストレーターを公開すると、各サブエージェントの正確なバージョンを固定する不変のスナップショットが作成されます。

仕組み [#how-it-works-subagent-versioning]

ドラフトオーケストレーターは、サブエージェントの任意のバージョン(ドラフトまたはリリース済み)を参照できます。
オーケストレーターのリリースバージョンを作成すると、次のようになります。
- まだドラフト状態のサブエージェントは、新しいリリースバージョンに自動的に公開され、オーケストレーターのリリースに固定されます。
- すでにリリースされているサブエージェントは、そのまま固定されます。不要なバージョンのバンプは発生しません。
サブエージェントがまだドラフトである場合は、続行する前に、そのサブエージェントをリストする確認ダイアログが表示されます。
リリースされたオーケストレーターは、サブエージェントに対する今後の変更の影響を受けません。ピン留めされたバージョンはフリーズされたままです。

ランタイムバージョンの解決 [#runtime-version-resolution-subagent-versioning]

オーケストレーターが実行時にサブエージェントを呼び出すと、現在アクティブなサブエージェントのバージョンではなく、マニフェストの固定されたバージョンが使用されます。

サブエージェントのアクティブバージョンは、そのサブエージェントへの直接トラフィックを処理するバージョンを制御します(たとえば、ユーザーがサブエージェントスタンドアロンと対話する場合)。親エージェントが依存関係を解決する方法には影響しません。

例: オーケストレーター (V1) は、払い戻しハンドラー V2 をピン留めします。払い戻しハンドラー V3 がアクティブな場合でも、オーケストレーターは引き続き V2 を使用します。V3 を使用するには、オーケストレーターのドラフトを V3 を参照するように更新し、新しいリリースバージョンを作成します。

ロールバック [#rollback-subagent-versioning]

オーケストレーターのリリースされた各バージョンは、固定されたサブエージェントバージョンの不変のスナップショットであるため、オーケストレーターを以前のバージョンにロールバックして、以前のサブエージェント構成を即座に復元できます。詳細は、バージョン履歴をご参照ください。