【Copilot Studio】送信前チェックを通らない回答経路、ありませんか？

こんにちは！DXソリューション営業本部の大和矢です。

Copilot Studio で社内向けのAIエージェントを作るとき、「AIが変な回答を返したらどうしよう」と不安になりませんか？
そこで、回答を利用者に届ける前に、承認を挟んだり、個人情報を伏せたり、ログに残したりする仕組みを入れる方も多いと思います。
その仕組みが「すべての回答に効いている」と信じていたのに、実は効いていない回答があったら、怖いですよね。
こうした、回答を送る前の確認の仕組みを、この記事では「送信前チェック」と呼びます。

Copilot Studio には、エージェントの回答が送信される直前に動くトリガーがあります。
送信前チェックを置く場所として、まず思いつきやすいのがここです。
筆者も、「ここに置けば、すべての回答を捕まえられる」と考えていました。
ところが検証してみると、このトリガーを一度も通らずに回答が届く経路が、エージェントに最初から入っていました。

この記事では、その経路の正体、通らない理由、起きる条件を、画面つきで紹介します。考えられる対策にも触れます。
なお、この記事は、トピックやトリガーで作り込む「標準ハーネス」のエージェントを対象にしています（Harnesses in Copilot Studio）。
仕様・挙動は2026年10月時点のものです。

「AI の応答が生成されました」トリガーとは

このトリガーは、日本語UIでは「AI の応答が生成されました」と表示されます。
公式ドキュメントの英語版では「An AI-generated response is about to be sent」（AI によって生成された応答が送信されようとしています）と記載されています（Set topic triggers）。
YAML では OnGeneratedResponse、別のガイダンスのページ（Apply generative orchestration capabilities）では「AI Response Generated」とも呼ばれています。

このトリガーが用意するのは、動くタイミングと、応答の本文を読むための変数だけです。
応答を止める、代わりの本文を出す、といった中身は、トピックの中に作り込むことになります。

公式の表では、このトリガーの発動のタイミングを、次のように説明しています（Set topic triggers）。

Fires when the agent generates a response for a user after calling one or more topics, tools, or knowledge sources. [...]
（エージェントが、1つ以上のトピック、ツール、またはナレッジソースを呼び出した後にユーザーへの応答を生成したときに発動します。[…]）

応答の本文を読む、応答を止める、代わりの本文を出す。
このトリガーでは、そうしたチェックを、トピックの中に作り込みます。
そのため、このトリガーを通らない回答には、作り込んだチェックがかかりません。
では、すべての回答が、このトリガーを通るのでしょうか。次の節で確かめます。

「応答が送信される直前」のトリガーを置いたのに、素通りする回答がある

「AI の応答が生成されました」トリガーが、すべての回答で動くのかを確かめるために、検証用のエージェントを用意しました。

このトリガーが動いたかどうかを画面で見分けるために、名前と時刻を表示するだけの「目印用」のトピックを2つ作りました。

1回目の質問では、「P-early」→「G」→回答の順に表示されました。
応答が送信される直前に、G-hook が動いています。
ここまでは期待どおりです。

同じ会話で2回目の質問を送ると、様子が変わりました。
「P-early」は表示されますが、「G」は表示されないまま、規程に基づく回答が届いたのです。
承認やマスキングのために、このトリガーを使っていたら、この回答は素通りです。

では、なぜ2回目の回答は、「G」を通らなかったのでしょうか。
次の節で、動いたトピックを確かめます。

決め手は「トピック間の追跡」で、実際に動いたトピックを見ること

2回目の回答がどこを通ったかは、テスト画面の「トピック間の追跡」で確認できます。
1回目と2回目で、動くトピックが違いました。

「トピック間の追跡」は、テスト画面の右上の「…」メニューでオンにします（赤枠）。

追跡をオンにして2回目を送ると、画面が「会話の強化」というトピックに切り替わりました（下の画像の左側が、その追跡の画面です）。
トリガーは「意図不明時」で、中身は「生成応答を作成する」ノードです。
待ち時間の表示は、「取得中」でした。

公式のトラブルシューティングも、変更を加える前に、アクティビティマップ（そのターンの実行の流れを示す図）で、選ばれた経路を確認する手順を示しています（Troubleshoot duplicate messages and missed answers）。
今回使った「トピック間の追跡」も、公式では、このアクティビティマップの節で説明されています（Review agent activity）。

Capture this evidence before you change anything. [...] Use an activity map to identify the topics, tools, agents, and knowledge sources that the orchestration layer selected for that turn.
（何かを変更する前に、この証拠を取ってください。[…] アクティビティマップを使って、そのターンでオーケストレーション層が選んだトピック、ツール、エージェント、ナレッジソースを特定します。）

回答の中身を疑う前に、まず「どの経路で届いたか」を見る。
原因の切り分けでは、これが近道になります。

正体は、既定で存在するシステムトピック「会話の強化」

2回目の回答を作っていたのは、エージェントに最初から入っているシステムトピック「会話の強化」でした。
システムトピックは削除できませんが、不要ならオフにできます（Use system topics）。

公式の一覧（Use system topics）では「Conversational boosting」という名前で、次のように説明されています。

Creates generative answers from external data sources. [...] Triggers when the agent can't find a match for the user query.
（外部のデータソースから生成型の回答を作成します。[…] ユーザーのクエリに一致するものをエージェントが見つけられないときに発動します。）

このトピックを開くと、次のようになっています。
トリガーは「意図不明時」で、「生成応答を作成する」ノードのあとに、回答（Answer）が空白でないかを調べる条件が続きます。

コードエディターで開くと、次の定義でした。

kind: AdaptiveDialog
beginDialog:
  kind: OnUnknownIntent
  id: main
  priority: -1
  actions:
    - kind: SearchAndSummarizeContent
      id: search-content
      variable: Topic.Answer
      userInput: =System.Activity.Text

    - kind: ConditionGroup
      id: has-answer-conditions
      conditions:
        - id: has-answer
          condition: =!IsBlank(Topic.Answer)
          actions:
            - kind: EndDialog
              id: end-topic
              clearTopicQueue: true

OnUnknownIntent は、画面の「意図不明時」に当たります。
質問に合うトピックが見つからないときにこのトピックが動き、ナレッジを検索して回答を作ります（SearchAndSummarizeContent）。
回答が空でなければ、そのままトピックを終了します（EndDialog）。
回答の生成から終了までが、このトピックの中で完結しています。
「AI の応答が生成されました」トリガーに関わる処理は、この定義のどこにも出てきません。
2回目の回答で「G」が表示されなかったことと、つながる点です。

似たシステムトピックに、「フォールバック」があります。
公式の一覧では、次のように説明されています（Use system topics）。

Informs users their query couldn't be matched to a topic and asks them to try again. [...] Triggers when the agent can't match the user's question or message to a topic.
（ユーザーに、質問に合うトピックが見つからなかったことを伝え、もう一度試すよう案内します。[…] ユーザーの質問やメッセージに合うトピックをエージェントが見つけられないときに発動します。）

会話の強化もフォールバックも、質問に合うトピックが見つからないときに動きます。
では、どちらが先に動くのか。公式の生成応答ノードの説明は、次のように書いています（Use generative answers in a topic）。

When your agent can't find a matching intent (defined in a topic) for the user's query, it uses generative answers to try to answer the question. [...] If the user's intent isn't matched to topics or generative answers, the Fallback system topic is used.
（エージェントが、ユーザーのクエリに一致するインテント（トピックで定義したもの）を見つけられないときは、生成回答で質問に答えようとします。[…] ユーザーの意図が、トピックにも生成回答にも一致しないときに、フォールバックのシステムトピックが使われます。）

会話の強化は、先ほどの一覧のとおり、外部のデータソースから生成型の回答を作るシステムトピックです。
つまり、先に動くのは会話の強化で、そこで答えが作れなかったときに、フォールバックに進みます。
優先度の面でも、会話の強化が先だと書かれています（Topic enrichment analysis）。

なぜ「AI の応答が生成されました」トリガーを通らないのか

「会話の強化」の回答が、このトリガーを通らない理由を、画面の設定と公式の情報から調べました。
手がかりは2つあります。
1つは、回答を送る設定がノード側にあること、もう1つは、公式の優先順位の一覧にこの経路が載っていないことです。

ノードの「メッセージの送信」がオンになっている

「生成応答を作成する」ノードの詳細を開くと、「メッセージの送信」にチェックが入っていました。
画面でノードの詳細を開かない限り、気づきにくい設定です。

公式の手順（生成応答ノード）には、このチェックを外すと何が変わるかの説明があります（Use generative answers in a topic）。

Clearing this option prevents your agent from immediately returning the generated answer, which allows you to customize the answer.
（このオプションを外すと、エージェントは生成した回答をすぐには返さなくなり、回答をカスタマイズできるようになります。）

逆に言うと、チェックが入っているノードは、作った回答をすぐに返します。
この動きが、トリガーを経由せずに回答が届く理由だと考えられます。

公式の優先順位の一覧に載っていない

この経路と「AI の応答が生成されました」トリガーの関係が、公式に説明されているかを確認しました。
公式には、複数のトリガーが動くときの順序の説明があります（トピックのトリガーを設定する）。

要点は3つです。
トリガーの種類ごとに順序が決まっていること、同じ種類なら作成順（古いものから）になること、Priority で順序を明示できること。
この一覧には、「AI の応答が生成されました」トリガーも「意図不明時」トリガーも載っていません。
筆者が確認した範囲では、この2つの順序や関係を説明した記述は見つかりませんでした。

補足として、順序を明示する Priority（画面では「重要度」）の数値の向きは、Copilot Studio の画面のツールチップに、次のように書かれています。
「値が低いほど、優先度が高くなります」

筆者の環境でも、同じ種類のトリガーは作成順に動き、重要度に小さい値を付けたものが先に動きました。
試したのは、同じトリガー（メッセージを受信した時）を持つ2つのトピックで、P-early を先に、P-late をあとに作りました。
重要度を設定しないと、作成順に P-early → P-late の順で動きました。
P-early に10、P-late に1を設定すると、順序が入れ替わり、P-late → P-early の順で動きました。

起きる条件のひとつは「根拠のない応答を許可する」をオフにしたとき

この経路に落ちるかどうかは、「根拠のない応答を許可する」という設定で変わりました。
この設定は、生成オーケストレーションがオンであることが前提です。
検証では、この設定をオフにしていました。

画面での説明は、「エージェントが一般的な知識のみを使用して応答できるかどうかを管理します。［オフ］を選択すると、ナレッジソースやツールを使用しない応答（アクティブな会話の文脈のみを参照する応答を含みます）がブロックされます」です。

公式では、英語名「Allow ungrounded responses」の説明が次のとおりです（Knowledge sources summary）。

When you turn off this setting, the agent blocks any response generated in a turn where it didn't use a knowledge source or tool. This condition means the response is blocked if the agent answers a question from conversation history or general knowledge without calling a knowledge source or tool. In that case, the fallback topic triggers.
（この設定をオフにすると、ナレッジソースもツールも使わなかったターンで生成された応答は、エージェントがブロックします。つまり、ナレッジソースやツールを呼ばずに、会話履歴や一般知識から質問に答えた場合、その応答はブロックされます。その場合、フォールバックトピックが発動します。）

公式の例（Knowledge sources summary）では、ナレッジから1回目の回答をしたあとに、「それはセール品にも当てはまりますか？」と続けて聞くと、履歴だけで答えようとした応答がブロックされます。
筆者の環境では、この設定を切り替えて、次の違いを確認しました。

設定がオンのときは、2回目の質問でも、「P-early」→「G」→回答の順に表示されました。
「AI の応答が生成されました」トリガーを通っています。

設定がオフのときは、2回目の質問で、「P-early」のあとに「G」が表示されないまま、回答が届きました。
「AI の応答が生成されました」トリガーを通らず、「会話の強化」が回答を作っています。

ここまでの確認から、落ちるのは、ナレッジやツールを使わずに答えるターンだと考えられます。
会話が続いたときの続きの質問で起きやすいと考えられます。筆者の体感でも、この設定をオフにすると、2回目以降の質問で、会話の強化に回ることがよくあります。1回目の質問で会話の強化に回ったことは、筆者は経験していません。ただし、1回目の質問を、条件を変えて試したわけではありません。
また、会話の強化は、質問に合うものが見つからないときに動く仕組みなので、設定以外の条件でも落ちる可能性があります。
筆者が確認できたのは、この設定の切り替えだけです。

回答を根拠のあるものに限りたくて設定をオフにするほど、この経路に落ちる条件が整う点には、注意が必要です。
対策は、次の節で考えます。

公式の立場と、考えられる対策

ここまでで、「AI の応答が生成されました」トリガーだけでは、すべての回答をチェックできないことが分かりました。
では、どう設計すればよいのでしょうか。
まず、公式がどのような設計を勧めているかを確認し、そのうえで、筆者が考える対策案を紹介します。

公式の考え方：利用者への応答は、オーケストレーション層に任せる

公式のガイダンスは、トピックの作り方を、次のように勧めています（Design topics as mini-agents that avoid duplicate messages）。

In the standard harness, keep deterministic logic inside the topic and leave user communication to the orchestration layer.
（標準ハーネスでは、決まった処理はトピックの中に置き、利用者とのやり取りはオーケストレーション層に任せてください。）

理由は、トラブルシューティングのページに書かれています（Troubleshoot duplicate messages and missed answers）。

Most duplicate messages and missed answers occur when a component communicates with the user on its own, and the orchestration layer's context no longer matches the response the user received.
（重複メッセージや回答の取りこぼしの大半は、コンポーネントが自分でユーザーとやり取りし、オーケストレーション層の文脈が、ユーザーが受け取った応答と合わなくなるときに起こります。）

トピックなどの部品が、利用者に直接メッセージを送ると、オーケストレーション層は、何が送られたかを把握できません。
その結果、同じ内容が二重に届いたり、答えたのに未回答として扱われたりしやすい、というのが公式の見方です。
一方で、承認を挟みたいなど、応答を無条件には流せない要件もあります。
公式の推奨と、そうした要件は、ぶつかると筆者は考えています。

考えられる対策案

次の2つは、筆者が、実際のエージェント開発で試したことのある案です。
ただし、この記事の検証用エージェントでは、動作を確認していません。

1つ目の案では、リダイレクト先のトピックで答える場合の終わらせ方が要になります。
公式は、入力を横取りしてリダイレクトする場合について、次のように書いています（Troubleshoot duplicate messages and missed answers）。
リダイレクトして答える点は同じなので、1つ目の案にも当てはまると考えられます。

If the interception redirects and owns the request, end all topics after the redirect so the same request isn't handled twice.
（横取りがリダイレクトして依頼を引き受けるなら、同じ依頼が二重に処理されないよう、リダイレクトの後ですべてのトピックを終了してください。）

使い分けは、回答を根拠のあるものに限る要件があるかどうかです。
あるなら1つ目です。ないなら、または機能性を優先して一般知識での回答を許容できるなら、2つ目が手軽です。

よくある質問

Q. 「AI の応答が生成されました」トリガーを置けば、すべての生成応答を捕まえられますか？

筆者の検証では、すべては通りませんでした。
「根拠のない応答を許可する」をオフにして2回目の質問を送ると、既定のシステムトピック「会話の強化」が回答を作り、このトリガーを経由せずに回答が届きました。
設定をオンにすると、2回目の質問もこのトリガーを通りました。

Q. 「会話の強化」とは何ですか？

エージェントに最初から入っているシステムトピックで、公式の英語名は Conversational boosting です（Use system topics）。
質問に合うトピックが見つからないとき（意図不明時）に動き、ナレッジを検索して回答を作り、そのまま送信します。
システムトピックは削除できませんが、不要ならオフにできます。

Q. 「根拠のない応答を許可する」をオフにすると、なぜ別の経路になるのですか？

公式は、ナレッジやツールを使わず会話履歴だけで答えた応答はブロックされ、フォールバックが動くと説明しています（Knowledge sources summary）。
そして、会話の強化はフォールバックより先に動くと書いています（Topic enrichment analysis）。

Q. 回答が「AI の応答が生成されました」トリガーを通らない場合の対策はありますか？

筆者が考える案は2つです。
会話の強化のノードで「メッセージの送信」をオフにして自前のトピックへ合流させる案と、「根拠のない応答を許可する」をオンに戻す案です。

まとめ：「全部通る」と決めつけず、回答の経路を数える

学びは2つです。

1. 「AI の応答が生成されました」トリガーを使っても、回答が別のルートで届くことがあります。
   • 既定のシステムトピック「会話の強化」のように、このトリガーを通らずに回答を送るものがあります。
   • 作成したトピックだけでなく、システムトピックも含めて、回答の経路を数えます。
   • 「トピック間の追跡」で、実際に動いたトピックを確認できます。
2. 経路は、設定で変わります。
   • 「根拠のない応答を許可する」を切り替えると、2回目の回答が通る経路が変わりました。

統制を設計するときは、ユーザーにメッセージを送るノードを持つシステムトピックがないか、一覧を開いて探してみてください。
手元のエージェントで「トピック間の追跡」をオンにして、2回目の質問を送ってみるのもおすすめです。

QUICK E-Solutionsでは、Copilot Studio / Power Platform 環境のセキュリティ・ガバナンス設計から、エージェント開発のPoC・本番構築、運用・継続改善まで一貫して支援しています。
以下のリンクからご提供しているサービスの詳細をご確認いただけます。

※このブログで参照されている、Copilot Studio、Power Platform、SharePoint、Teamsは、米国Microsoft Corporationの米国およびその他の国における商標または登録商標です。