次の方法で共有

生成オーケストレーション機能を適用する

ジェネレーティブオーケストレーションは、Copilot Studioにおける会話型エージェント開発の進化形です。 ユーザーの意図を解釈し、複雑なリクエストを分解し、適切なツールと知識を選択し、安全とコンプライアンスを守るための多段階計画を実行する大規模言語モデル(LLM)駆動の計画層を導入します。 手作りの会話トピックだけに頼るのではなく、生成オーケストレーションは再利用可能な構成要素—アクション、トピック、知識ソース、子エージェント、自律トリガー—をインテリジェントなワークフローに組み込みます。

Copilot Studioでは、生成オーケストレーションを有効にすることで、手動スクリプトを減らしながらより良い回答が得られます。 この記事では、生成オーケストレーションの背後にあるアーキテクチャや、効果的な命令の作成方法、オーケストレーションされたエージェントのテスト・チューニング方法について学びます。

なぜ生成オーケストレーションが重要なのでしょうか?

従来のトピック駆動型設計では、複数の手作業されたトピック、厳格な分岐、手動のスロット埋め込みロジックが必要です。 このアプローチは以下のような結果をもたらします:

  • 大きなテーマのインベントリで、論理が重なり合っています。
  • 曖昧または多目的の発話の扱いが難しいこと。
  • ユーザーが質問の表現を変えたときの一貫性のない体験。
  • APIやビジネスルールが変わるとメンテナンスコストが高くなります。

生成的オーケストレーションはこれらの課題を以下のように解決します:

  • 再利用可能な構成要素を書くことでトピックの拡散を減らすこと。
  • 入力定義に基づくスロット充填の自動化。
  • 反応スタイルや計画構造を動的に適応させること。
  • 意味知識検索による関連性の向上。
  • 積極的な次のステップ提案を可能にする。

アーキテクチャとコンポーネント

大まかに言えば、生成オーケストレーターエージェントは複数の重要なコンポーネントが連携して動作します。

  • オーケストレーター(プランナー):エージェントのLLM駆動の脳で、ユーザーメッセージやイベントなどの入力を構造化された計画に変換します。 オーケストレーターは意図を特定し、各ステップで呼び出すツール、トピック、エージェントを選び、ステップ間のシーケンスとデータフローを定義します。 ランタイムが実行する順序付きステップのリスト(「プラン」)を出力し、各ステップがポリシー内であることを保証します。 例えば、機密行動の承認を求めます。

  • ナレッジレイヤー:内部ナレッジベース、ドキュメント、データベースなどの検索源の集合で、エージェントが回答を基に据えてクエリできます。 オーケストレーターはこのレイヤーを使って事実情報や指針を取得します。 結果には引用やメタデータが含まれることが多く、エージェントは透明性を高めるために回答に組み込むことができます。 知識層は読み取り専用で、証拠や文脈を提供します。

  • ツールとコネクタ:エージェントが計画の一部として呼び出せる外部アクション、API、または自動化フロー。 各ツールには定義されたインターフェースがあり、入力パラメータ(期待型付き)、出力変数、そして場合によってはエラー条件が含まれることがあります。 これは基本的に、注文の検索、メールの送信、スクリプトの実行など、オペレーターが操作を行うための「スキル」です。 ツールを徹底的にテストし、同じ入力で決定論的に振る舞うかを確認すべきです。なぜなら、オーケストレーターはそれらを信頼できる関数として扱っているからです。

  • トピックとインラインエージェント:特定の論理をまとめた再利用可能な会話トピックやミニダイアログ。 生成オーケストレーションでは、プランナーはトリガーフレーズだけでなく、ユーザーのニーズに合致する目的に応じてトピックを呼び出しることができます。 インラインエージェントとは、より大きな計画のサブステップとして使われる小さく焦点を絞ったトピックやルーティンを指します。 これらはメインエージェントのコンテキスト内で動作し、個別のタスクを処理するため、メインオーケストレーターが詳細を明示的にスクリプト化する必要がありません。

  • イベントトリガー(自律性):ユーザーメッセージなしでオーケストレーターを起動する仕組み。 これらのメカニズムは、スケジュールトリガーやイベントベースのトリガー(データベースレコード更新のようなもの)で、エージェントが自律的にプランを起動できるようにします。 各トリガーには独自の条件や指示が設定されます。 自律トリガーにより、エージェントは特定の条件が満たされた際に、ユーザーチャット入力だけでなく積極的にワークフローを開始します。

制御層と意思決定境界

本番環境のエージェントでは、すべての決定をAIに任せないでください。 通常、3つの管理層が存在します。

  • 決定論レイヤー:このレイヤーは従来型のルールベースのロジックを使い、ミッションクリティカルまたは不可逆的なアクションに対して依然として強制します。 例えば、支払い処理や記録削除の際には、AI解釈なしにステップバイステップで実行される厳密に作成されたトピックやフローを使うことができます。 この層には、機密データの明示的なチェックや検証も含まれる場合があります。 もし何かが正確に指定された通りに起こらなければならないなら、決定論的に処理してください。 生成オーケストレーターをこれらのフローを上書きしたり変更したりしないように設定できます。 実際には、そのような操作をAIプランナーに公開しないか、常にユーザーの確認が必要なトピックでまとめておくこともあります。

  • ハイブリッド(インターセプト)レイヤー:このレイヤーは主に決定論的な構造に対してAIの柔軟性を提供します。 オーケストレーターが定められた範囲内で活動し、人間またはルールに基づく傍受の可能性を認めます。 例えば、エージェントが自動的にレスポンスを作成したりアクションを実行したりしますが、承認ステップを挿入してマネージャーに確認してもらうこともできます。 あるいは、エージェントが一定の値制限までタスクを処理した後、エスカレーションを求められることもあります。 ハイブリッド層は、AIの自律計画がチェックポイントされるポイントをあらかじめ定義しています。 このアプローチは中リスクのプロセスに用いてください。AIに重労働を任せつつ、監督のために人間を巻き込む。

  • AIオーケストレーター層:この層は完全に生成的です。 LLMプランナーは(ガードレール内で)リスクの低いクエリのために計画を作成・実行する自由があります。 ほとんどのQ&Aやり取り、情報検索、または単純な多段階のリクエストはこのカテゴリーに該当します。 ほとんどのユーザー質問に対して、エージェントは自律的に解決方法を決定し、対応を取ることができます。 この層は生成AIの適応性と力を提供します。 それは規則に縛られています。 例えば、AIは特定の管理ツールを呼び出したり、特定の情報を開示してはいけないと知っているかもしれません。 担当者はルーティン作業のために立ち止まって許可を求める必要はありません。

これらの層が与えられた上で、決定境界を明示的に定義します。 どのような行動やトピックを見てみましょう:

  • 確認なしで実行可能です(AIがそのまま実行できます)
  • 会話の中でユーザーの確認(例:「すべての記録を削除したいですか?」)を求めてください。
  • オフライン承認を義務付ける(例:管理者が承認ワークフローを通じて確認しなければならない)

これらの境界線は、トピックデザインを通じて強制してください。例えば、確認ノードの追加、プラットフォームの承認機能、トリガー内のロジックなどです。 コントロールを重ねることで、エージェントが安全に動作することを保証します。AIは得意なことを処理し、人間や厳格なルールはAIが単独で決めるべきでないことを管理します。

エージェントの指示に関するベスト プラクティス

適切に作成されたエージェント指示はプラン作成の質に影響を与えます。

  • 文脈的関連性

    • 指示はエージェントが利用可能なツールや知識のみを引用するようにしてください。
    • ツール名、変数名、Power FX識別子を正確に使ってください。

  • 会話のガイドライン

    • 回答形式(リスト、表、太字)を指定します。
    • 文体的な指針(「簡潔」「引用を含める」「次のステップを提案する」)を提供してください。
    • 特定の知識源を直接挙げるのは避けましょう。 代わりに彼らを描写してください。

  • 道具や知識を使うべきタイミングの判断

    • ツール名を使うのが好きです。 名前の方が説明よりも重みを持つ。
    • 誤った情報を避けるために知識能力を一般に記述してください。

  • 自律実行命令

    • 多段階ワークフローの期待されるアクションシーケンスを定義します。
    • プロセス指示と具体的なプロンプトを組み合わせましょう。

詳細は 「生成オーケストレーションのための高品質命令の設定」をご覧ください。

トピックの入力と出力の設計

トピック作成時には、生成オーケストレーションモードで入力と出力パラメータに特に注意を払ってください。

  • 明確な入力パラメータを定義し、説明をつけます: トピックやアクションが特定の情報(例えばパスワードリセットトピックの「ユーザー名」)を必要とする場合は、トピック入力を作成し、説明的な名前と例を付けます。 オーケストレーターはこれらの名前と説明を用いて、値が欠けているかどうかを自動的にユーザーに尋ねます。 受け入れ値のリストやPower FXの検証式を入力に使うことで、ボットが有効なデータを収集するのを確実にできます(例えば、国コードを2文字に制限するなど)。

  • 自動プロンプトの活用: 生成モードでは、エージェントが自動的に質問を生成し、あなたが手動で質問ノードを追加して欠落情報を促す必要がなくなります。 このアプローチは従来のボットからの大きな変化です。 重要なのは、入力名が人間に優しいもの(例えば「開始日」「メールアドレス」)であるべきであり、AIが自然に質問を形成できるようにすることです。 AIの自動生成質問が理想的でない場合は、入力の説明や名前を洗練させることを検討してください。 この機能は会話を大幅に効率化しますが、よく指定された入力に依存しています。

  • 適切なトピックごとに出力を指定します: トピックは出力変数を生成し、オーケストレーターは最終的な回答をコンパイルするために使います。 例えば、「ストアファインダー」トピックは NearestStoreLocationを出力するかもしれません。 ユーザーに直接メッセージを送るのではなく、情報を出力することで、オーケストレーターがその情報を他のステップと優雅に組み合わせることができます。 トピックの内容が大きな回答で使われている場合は、それを出力変数としてキャプチャし、最終的なメッセージングはオーケストレーターに任せます。 詳細については、「 生成型 AI を使用してエージェントの動作を調整する」を参照してください。

  • プロンプトでの「二重扱い」は避けてください: 出力を設定する場合は、それらの出力もオープンエンドコンテキストとしてLLMに入力しないでください。 例えば、アクションが要約テキストを返した場合、その要約を構造化出力として渡し、「 アクションの結果が{summary}と言う 」のような命令を書く代わりに、オーケストレーターに含めてもらうべきです。このアプローチにより、モデルがコンテンツの過剰生成や重複を防ぐことができます。 出力は可能な限り最終的なデータポイントであるべきです。

行動、トピック、知識の連鎖

オーケストレーターは1ターンで複数の機能を使えるため、組合可能性を考慮して設計してください:

  • すべてのものに直感的な名前と説明を与える:プランナーは、ツールやトピックの名前や説明がユーザーの要望にどれだけ合致しているかに基づいて使うかどうかを大きく決めます。 ユーザーの意図に合ったアクティブなフレーズを使いましょう。 例えば、「TranslateText」という説明のツールは、翻訳について尋ねる際に選ばれやすいのに対し、一般的な名称の「Flow1」よりも優先されます。名前が何よりも大切だ。 謎めいた名前は避けましょう。 もしエージェントが間違ったトピックを選んだ場合は、その名前や説明を見直しましょう。

  • 豊かな「ツールキット」を提供しつつ、厳選してください:シナリオに必要なすべての有用なアクション(API、フローなど)をつなげ、重要なフローのトピックを作成しましょう。 このアプローチにより、AIはクエリを解決する選択肢が増えます。 ただし、担当者にとって無関係またはリスクのあるツールやトピックは削除または無効にして、プランナーを混乱させないようにしましょう。 高品質な選択肢の少ないセットは、重複する網羅的な選択肢よりも優れています。 重複した説明はエージェントが複数のことを同時に試みることになり、望ましくない場合があります。

  • プランナーを合理的な範囲で信頼する:コンポーネントが明確に定義されたら、オーケストレーターに組み合わせさせましょう。 例えば、ユーザーが知識記事やライブデータAPIで対応可能な質問をした場合、プランナーは両方を使い、背景情報として知識を取得し、現在の情報をAPIに呼び出すことを選択できます。 このアプローチはより良い回答を生み出すことができます。 この自律性を受け入れつつ、早い段階で良い選択がなされるかどうかを見守ってください。

  • 複数の意図に対応する:ユーザーのクエリが本質的に2つの別々の要求(例えば「新しいアカウントを開設して詳細を送ってください」)の場合、生成プランナーは関連するシーケンスを順に呼び出して両方を満たそうとします。 マルチインテントのために分岐を手動でスクリプトする必要はない。 開発者としてのあなたの仕事は、各サブタスク(アカウント開設、詳細送信)が何らかのツールやトピックでカバーされ、必要に応じて出力と入力がつながるようにすることです。

  • 知識をトピックやツールを補完する:オーケストレーターは単なるバックアップとしてではなく、能動的に知識検索を呼び出すことができます。 豊富な知識ベースを設定していれば、アクションが別の部分をカバーしていても、エージェントは知識記事のスニペットでクエリの一部に答えることがあります。 この動作は設計によるものです。 ツールでは簡単に得られない情報で知識ベースを最新に保ちましょう。

  • 知識の使用範囲に注意してください:現在、エージェントに特定の知識記事を要求に応じて使用させることはできません。 AIはクエリに基づいて関連する記事を選択します。 また、制限にも注意してください。 例えば、「複数のトピックがマッチしている」のようなシステムトピックは、プランナーが曖昧さ回避の処理方法が異なるため、生成モードでは使われません。 生成オーケストレーションに関する他の既知の制限についても詳しく学びましょう。

オケストレーションされたエージェントのテストと調整

生成オーケストレーションは、明示的な設計からAIの「脳」へと論理を移します。反復テストは、意図通りに動作していることを保証します。 ここでは、オーケストレーションされたエージェントのテストと改善のためのベストプラクティスをご紹介します。

  • アクティビティマップの活用:Copilot Studioはテスト中にアクティビティ マップ を提供し、オーケストレーターが決定したステップを表示します。 複雑な質問をエージェントにした後、計画を確認しましょう:どのトピックやアクションが出されたのか? どの順番ですか? 適切なフォローアップの質問はありましたか? もし担当者が間違ったトピックを選んだり、ツールを見落としたりした場合は、部品の説明を洗練させたり、指示を調整したりする必要があるかもしれません。

  • トランスクリプトのレビュー:エージェントが公開されたら、会話のトランスクリプトやログを定期的に確認しましょう。 回答に幻覚や不正確さがないか注意してください。 ユーザーが「それは正しくない」とフィードバックをした場合は、なぜエージェントがそう思ったのかを遡って確認してください。 問題には、知識ベースに欠けている事実を追加したり、指示を絞ったり、場合によってはギャップを埋めるために新しいトピックを追加したりします。 詳細は 「エージェント会話のトランスクリプトを抽出・分析(参照アーキテクチャ)」をご覧ください。

  • 小さな変更で反復する:微妙な変更を加えることで生成エージェントを改善することがよくあります。 例えば、エージェントの出力が冗長すぎたり望ましいフォーマットでない場合は、スタイルやフォーマットに関する指示を調整して再度テストします。 毎回不要なツールを呼び出しているなら、そのツールの説明が広すぎて、適切な時だけ呼び出しるように調整できるかもしれません。 一度に一つずつ変更を行い、エージェントの意思決定に与える影響に気づきましょう。

  • 例句を慎重に提供する:トピックの説明にいくつかの例のユーザークエリを加えることで、LLMがそのトピックを使うタイミングを理解するのに役立つかもしれません。 例えば:「目的:ユーザーのパスワードをリセットする。 例えば、ユーザーが『パスワードを忘れました』や『Contosoアカウントのアクセスをリセットしました』と言うことがあります。」これらの例はモデルに追加のヒントを与えます。 やりすぎず、説明は簡潔かつ焦点を絞りましょう。 モデル自体にはすでに多くの文脈があります。ただし、メタデータは明確であることを確実にしてください。

  • パフォーマンス指標のモニタリング:利用率が増加するにつれて、成功率(エージェントがユーザーのリクエストを実際に解決したか)、フォールバック率(「申し訳ありませんがお手伝いできません」と表示された頻度)、ユーザー満足度(可能なら)などの重要な指標に注目してください。 テスト中でも、各トピックやツールの使用頻度を単純に数えるだけで、必要な調整のヒントを得ることができます。 例えば、些細な雑談の話題が頻繁に話題になりノイズを加えている場合は、無効化するか説明を絞り込む。 エージェントのパフォーマンスをテストする方法についてのガイダンスを見直しましょう。

生成システムは、あなたの設定や修正から暗黙のうちに学習します。 指示やメタデータの改善がAIの次の判断をより良くします。 時間が経つにつれて、あなたのオーケストレーションされたエージェントはより正確で効率的にクエリ処理を行っていきました。

生成オーケストレーションにおけるカスタムトリガー

生成オーケストレーション専用のトピックトリガーが利用可能です。 これらのトリガーを使うことで、エージェントのライフサイクルにフックし、オーケストレーションプロセスの重要なポイントでカスタムロジックを注入できます。 主なトリガーは3つあります:

トリガー トリガーが起きたとき 目的
知識の要求について エージェントがナレッジベースクエリを実行する直前に このトリガーは、オーケストレーターが知識源を検索しようとした瞬間をインターセプトできるようにします。 エージェントが使用しようとする SearchPhrase やキーワードへの読み取り専用アクセスと、カスタム検索結果を提供するシステム変数を提供します。 例えば、クエリをキャッチしてプロプライエタリインデックスにルーティングしたり、結果にさらにデータを注入したりすることができます。
これは高度(「シークレット」)トリガーで、UIではデフォルトでは表示されておらず、現在はYAML編集(トピック名を正確に OnKnowledgeRequestedにすることで)で有効化する必要があります。 特定の結果をフィルタリングしたり、外部データを知識応答に統合したりするなど、知識検索のステップを補強・カスタマイズする必要がある場合に使ってください。
AI応答生成 AIが下書きの回答を作成した後、しかしユーザーに送信される前に エージェントは最終的なレスポンステキスト(すべてのツールとトピックの出力に基づく)を作成し、それを配信直前にこのトリガーを発動します。 このステップでは、回答やその引用をプログラム的に修正する機会が得られます。 例えば、テキストのフォーマットを修正するために後処理を施したり、生のURLをフレンドリーな追跡リンクに置き換えたりすることができます。 返答を上書きすることも可能です。 トリガーは独自のカスタムメッセージを生成でき、 ContinueResponse フラグを使って元のAI応答を送るべきかどうかを判断できます。
このトリガーは、アンケートの提示を付け加えたり、AIが含めたものを削除したいものを黒塗りにしたりするなど、AIの回答の直前での調整や強化に使うことができます。 このトリガーの多用は、メイン命令に含まれていた可能性のあるロジックを示している可能性があります。 必要に応じて細かい制御に使ってください。
計画完了 計画全体が実行され、応答が送信された後 計画が完了し、すべてのステップが完了し、ユーザーが答えを見ると、このトリガーが発動します。 通常は、会話の終わりのプロセスを始めるために使います。 一般的な使い方としては、会話を特定の最終トピックやアンケートに誘導することです。 例えば、ユーザーに感謝したり次のステップを示すチャット終了トピックがあるかもしれません。 On Plan Completeを使うことで、そのトピックを自動的に呼び出すことができます。
ただし注意が必要です。特にユーザーが追加質問をする可能性がある場合は、すべての質問で会話を終わらせたくはないでしょう。 特定のコンテキスト変数が設定された場合や、プランが特定のリクエストタイプを解決した場合にのみ終了するロジックを追加してください。 基本的には、適切な清掃作業や適切な場合の優雅なクロージングにはOn Plan Completeを活用してください。

より多くの生成オーケストレーション機能

Copilot Studioのオーケストレーションモデルについて、エージェントの計画、行動、協働の進捗を拡張する高度な機能で理解を深めましょう:

  • Last updated on