Copilot Studioで専門エージェントを束ねるオーケストレーター設計

Microsoft Foundry Blogは、Copilot Studioで一つのオーケストレーターが複数の専門エージェントを呼び分ける構成を解説しました。天気と旅行計画を組み合わせる例で、作成からActivity Mapによる確認までを示します。

要点

• 中央のLife Assistantが意図分類、振り分け、最終回答の統合を担います。
• Weather AgentとTravel Assistant Agentをエージェントアクションで呼び、専門知識の所有者を分けます。
• Activity Mapで、どのエージェントがどの順序で呼ばれたかを検証できます。

今回のブログ記事で語られていること

記事が出発点にするのは、単一エージェントへ質問応答、リアルタイムデータ、部門固有ルール、複数段階の処理を詰め込むと、保守と統制が難しくなる問題です。解決策として、一つの中央エージェントが利用者の意図を判断し、必要な専門エージェントへ仕事を渡し、戻った結果を一つの回答へまとめる構成を採ります。専門エージェントは財務、人事、ITサービス管理などの部門が個別に所有でき、複数のCopilotから再利用できます。中央層を一つに保つことで、判断の入口と観測点を集約しながら、専門ロジックのライフサイクルを分離します。

実装例ではLife Assistant Agentがオーケストレーター、Weather AgentとTravel Assistant Agentが専門役です。Weather AgentにはKnowledge画面から公開天気サイトを追加し、Travel Assistantには旅行計画や交通情報を提供するサイトを設定します。その後、Life AssistantのAgents画面で二つを追加し、どんな依頼をどちらへ委任するかを指示します。「週末に北京へ行くので天気に基づく旅行計画を作ってほしい」という質問では、天気情報と旅行提案の両方が必要だと判断し、各専門役の結果を統合します。独自のオーケストレーションコードを書かず、Copilot Studioのネイティブなエージェントとアクションで構成する点が記事の実務的な狙いです。

検証では最終回答だけでなくActivity Mapを見ます。オーケストレーターが先に振り分け、天気結果が中間処理へ入り、旅行提案へ反映されたかを確認します。これにより、誤答時に専門知識、振り分け条件、統合指示のどこを直すべきかを分けられます。ただし、公開Webサイトを知識源にした簡易例は、企業データの認可、更新頻度、障害時の代替、複数エージェント間のデータ最小化までは扱いません。本番では各専門役の所有者、入力・出力契約、タイムアウト、費用上限、個人情報を渡せる範囲、統合回答の引用を定義する必要があります。

今回のブログ記事が関係する人

Copilot Studioの作成者、部門別エージェントを管理する製品責任者、複雑な業務Copilotを統制するアーキテクト、呼び出し経路を監視する運用担当に関係します。

結局、今回のブログ記事をどう読むべきか

複数エージェントを増やすこと自体より、専門性の所有と中央判断を分け、Activity Mapで経路を確認できる構成が要点です。まず二つの専門役と明確な受け入れ条件で試し、振り分け誤りと統合品質を測ってから領域を増やすべきです。