生成オーケストレーションでは、1 つのエージェントが他のエージェントを呼び出すマルチエージェント システムもサポートされます。 問題を複数の特殊なエージェントに分割すると、アプリケーションのモジュール性、拡張性、管理性が向上します。
インラインエージェント
インラインエージェントは、子エージェントとも呼ばれ、同じエージェント内で小規模で再利用可能なワークフローです。 それらは多くの場合、メインエージェントがサブルーチンとして使う単なるトピックです。 例えば、メインエージェントは「テキスト翻訳」トピックを大きな計画の一歩として呼び出すことができます。 インラインエージェントはメインエージェントとコンテキストを共有するため、データのやり取りは簡単です。
ベスト プラクティス: インライン エージェントを 1 つの責任に集中させ、適切にテストします。
接続されているエージェント
コネクテッドエージェントは、それぞれ独自のオーケストレーション、ツール、知識を持つ別個のエージェントです。 メインエージェントは、リクエストの一部を子供エージェントに委任します。 たとえば、IT エージェントは Sales エージェントを呼び出して価格に関する情報を取得します。 接続されたエージェントにより、モジュール性とドメインの分離が可能になり、プランの制限を回避できます。 それぞれ異なる権限や知識を持っている場合があるため、ガバナンスや監査管理を適用してください。
しかし、接続エージェントを使用するには慎重なガバナンスが必要です:
オーケストレーション:親オーケストレーターは、接続されたエージェントにいつ引き継ぐかの明確な基準を持つべきです。 オーケストレーターは通常、ユーザーの意図が接続先エージェントの担当領域と一致すると、そのエージェントに処理を引き継ぎます。 このプロセスを助けるために、接続されたエージェントの目的を親の設定で明確に説明してください。 接続されたエージェント全体を、親の観点から説明を含むエージェントの "ツール" として扱います。
データハンドオフ:データハンドオフを管理しなければなりません。 親から接続されているエージェントに渡すべきコンテキストを決定します。 Copilot Studio では、あるエージェントが別のエージェントを呼び出す際、既定で会話履歴が引き継がれるため、呼び出されたエージェントはそれまでの会話の文脈を理解できます。 ただし、特定のパラメータも通過する必要があるかもしれません。 例えば、メインエージェントが以前にユーザーの名前を知っている場合、再度尋ねないように接続されたエージェントにその名前を送信することがあります。
セキュリティ:接続されたエージェントは親エージェントがアクセスできないものにアクセスできる場合があります。 接続されたエージェントに電話することで、誤って制限を回避しないようにしましょう。 例えば、親エージェントが記録を削除できないのに接続エージェントが削除できる場合、適切な承認なしに削除が行われる状況で親エージェントは接続エージェントに連絡すべきではありません。 接続されたエージェントの通話は、他の強力なアクションと同じように扱いましょう。 機密性の高い動作をしている場合は、必要なチェックやユーザーの同意を受けてください。
監査と監視:接続されたエージェントがいつ呼び出しられ、何をしたかを記録します。 別のエージェントなので、別の成績証明書が必要です。 デバッグでは親セッションと接続されたセッションを相関させることが重要です。 通常、テレメトリ内の識別子は両者を結びつけます。
エージェントを分離するタイミング
すべてのサブタスクごとに別々のエージェントを作成しないでください。 サブタスクの場合は別々のエージェントを使用しましょう:
- 独自のツールや知識(専門分野が異なる)を持つほど複雑です。
- メインエージェントとは異なるガバナンスルールやアクセス制御が必要です
- 多くの異なるメイン エージェントで再利用できます (サービス エージェントのようなものです)。
これらの条件がいずれも適用されない場合、単純なインライン エージェントは、完全に接続されたエージェントよりも単純である一方で、ジョブを適切に処理する可能性があります。 個別のエージェントによって、システムにオーバーヘッドが発生します。 コンテキストの切り替えと、複数のエージェントの保守の複雑さにより、実行時間が若干長くなります。 だから賢明に使いましょう。 実用的な方法については、1 つのエージェントから始めます。 そのうえで、モジュール化の必要性、または単一のエージェントが越えるべきでない境界が明確にあると判断できる場合にのみ、複数のエージェントに分割してください。
マルチエージェント オーケストレーションのベスト プラクティス
マルチエージェント セットアップで親エージェントとサブエージェントの手順を作成する場合は、次のベスト プラクティスが適用されます。
1. 単一応答の原則
1 ターンに 1 人のエージェントがユーザーと対話するようにします。 マルチエージェントのセットアップでは、最終的な応答を提供する必要があるのは親エージェントだけです。 サブエージェントは研究者であり、レスポンダーではありません。
- 実行: 親命令に追加します。"ユーザーと通信するのは自分だけです。 すべての子エージェントから得られた知見を、1 つの応答にまとめます。
- しない: あいまいなままにしておきます。 明示的なガイダンスがない場合、サブエージェントはユーザーに直接応答し、重複または部分的なメッセージが発生します。
2. サブエージェント命令でロールを宣言する必要がある
サブエージェントには、自分がサブエージェントであることを常に伝えてください。 サブエージェントは、本質的にオーケストレーションの一部であるとは認識しません。 明示的なガイダンスがなければ、スタンドアロン エージェントとして動作し、ユーザーに直接メッセージを送信します。
- Do: すべてのサブエージェントの指示に「あなたはサブエージェントです。」を追加します。 ユーザーに直接返信しないでください。 あなたの役割は、情報を検索し、その調査結果を親エージェントに返すことです。 親エージェントは、ユーザーとの通信をすべて処理します。
- しない: サブエージェントが単独でオーケストレーション パターンを把握しているとします。
3. 手順で明確で直接的な言語を使用する
ディレクティブ言語を常に使用します。 柔らかい言い回しや丁寧な言い回しは避けてください。 プラットフォームは、強力な言語を使用してシステム レベルの命令を挿入します (MUST、DO NOT、NEVER)。 ソフト言語で記述された命令 ("お試しください"、"you should"、"it would be good to") は、競合すると優先順位が失われます。
- 実行: "ユーザーに直接返信しないでください。 結果のみを返してください。
- Do: "ユーザーの質問ごとに最後に 1 つの回答が必要です。"
- "ユーザーにメッセージを送信しないようにしてください。代わりに、結果を返してください"。
- してはいけません: 「理想的には、1つにまとめた回答が必要です。」
4. サブエージェントごとに 1 つのナレッジ ソースを使用する (重複なし)
重複しない個別のナレッジ ソースを各サブエージェントに割り当てます。 2 つのサブエージェントが同じナレッジ ベースを検索すると、1 つのサブエージェントが最初に回答を検索します。 2 番目のサブエージェントは、重複する結果を返すか、検索全体をスキップして値を追加しません。
- 実行: CA-1 はナレッジ ソース A (人事ポリシーなど) を検索します。 CA-2 はナレッジ ソース B (IT ドキュメントなど) を検索します。
- Don't: 両方のサブエージェントに、同じドキュメント、Dataverse テーブル、またはSharePoint サイトへのアクセス権を付与します。
- 注: ナレッジ ソースが 1 つしかない場合は、2 つのサブエージェントに分割するのではなく、ナレッジを持つ 1 つのエージェントを使用します。 マルチエージェントは、ソースがまったく異なる場合にのみ値を追加します。
5. サブエージェントに対して正確で明確な説明を使用する
親に表示される各サブエージェントについて、明確で個別の説明を記述します。 親エージェントは、サブエージェントの説明を使用してルーティングを決定します。 説明があいまい、同一、または不正確な場合、親は適切なルーティングの決定を行うことはできません。
- 実行: CA-1: "人事ポリシー ドキュメントで従業員関連の質問を検索します。"CA-2: "IT ナレッジ ベースでテクニカル サポートの質問を検索します。"
- しない: 異なるドメインにサービスを提供する場合は、両方のエージェントに同じ説明を付けます。
- しない: "このエージェントは質問に役立ちます" などの一般的な説明を使用します。
6. 親命令でオーケストレーション パターンを定義する必要がある
親エージェントに調整方法を指示します。 "子エージェントを使用する" と言うだけではありません。親には、エージェントの呼び出し、結果の待機、結合、応答というパターンに関する明示的な命令が必要です。
- 実行: "ユーザーが質問したとき: 1. 両方の子エージェントを呼び出して情報を収集します。 2. 両方の子エージェントが調査結果を返すのを待ちます。 3。 結果を 1 つの統一された応答に結合します。 4. ユーザーに正確に 1 つの応答を配信します。 子エージェントは、ユーザーに直接返信することはできません。"
- してはいけません: 「ユーザーが質問したら、子エージェントを呼び出し、両方の情報源から応答を取得して、単一の統合された回答を返す。」（あいまいすぎます。この指示では、サブエージェントに応答しないよう指示していません。）
7. タスク委任に "直接応答しない" ディレクティブを含める
明確なサブエージェント命令を使用しても、委任されたタスクに強化を追加すると、セーフティ ネットが提供されます。
- Do: 親エージェントへの指示に追加する: "子エージェントに委任する際は、必ず次の内容をタスクに含めること: '調査結果のみを返す。 ユーザーに返信しないでください。'"
- しない: サブエージェント独自の命令のみに依存します。 タスク コンテキストは、パターンを補強するシグナルをサブエージェントに与えます。
8. ドメイン不一致クエリを使用してテストする
サブエージェントのドメインと一致しない質問を常にテストします。 このテストでは、サブエージェントが正しく "情報が見つかりません" を返すか、正しくない可能性がある情報を返すか、ハングアップするか、または混乱するメッセージを送信するかを明らかにします。
- Do: すべてのサブエージェント ドメインの外部にあるクエリを使用してテストします (たとえば、エージェントが HR と IT を処理する際に天気について質問します)。
- 実施: 親側が「両方のエージェントで何も見つからなかった」状況を適切に処理できることを確認します。
- しない: 1 つのサブエージェントのドメインに完全に一致する最も単純なケース クエリでのみテストします。
9. フォローアップを期待する場合は、伝えるよりも質問することを優先する
ユーザーが応答することを期待するときは、質問/質問スタイルの対話を使用します。 inform/send-style は、最終的な一方向メッセージにのみ使用します。 エージェントが一方向メッセージ (inform) を使用してユーザーに何かを求めた場合、ユーザーの応答は、まったく新しいクエリとして親プランナーに戻ります。 この場合は、サブエージェントと同じ会話を続行することをお勧めします。
- Do: 次のような手順を記述します。"説明が必要な場合は、ユーザーに質問をして、応答を待ちます。"
- しない: "オプションについてユーザーに通知し、選択できるようにする" のような手順を記述します。"Inform" は一方向メッセージを通知し、"ask" は双方向の交換を通知します。
クイック リファレンス チェックリスト
| # | 確認 |
|---|---|
| 1 | 親の指示には、「ユーザーに応答するのは自分だけ」と明記されている |
| 2 | すべてのサブエージェント命令に "ユーザーに直接返信しない" と表示される |
| 3 | 指示では、強い指示表現を使用します (MUST、NEVER、ONLY) |
| 4 | 各サブエージェントには、重複しない一意のナレッジ ソースがあります |
| 5 | サブエージェントの説明は正確で、明確で、具体的です |
| 6 | 親命令は、完全なオーケストレーション パターンを定義します (呼び出→待機→応答→結合) |
| 7 | 親プロセスが、委譲されたタスクのコンテキストで「直接応答不可」を返す |
| 8 | ドメイン不一致クエリでテスト済み |
| 9 | サブエージェント命令で区別が正しいことを確認または通知する |