この記事でわかること：Copilot Studio でエージェントを本番導入するとき、設計フェーズで判断が難しかった5点の整理。どこで詰まりやすいか・判断軸・実際に取ったアプローチを書く
本業で Copilot Studio を使って社内 AI エージェントの設計・展開を担当している。プレビュー段階からいくつかのエージェントを本番に乗せてきた経験から、設計フェーズで「ここは注意が必要だった」と思ったポイントを 5 つ整理してみる。
設定の手順書ではなく、「どちらを選ぶか」という判断に迷った場面の話だ。
対象読者：Copilot Studio を社内展開しようとしている、または設計を検討中のエンジニア・IT担当者。基本的な操作はできる前提で書く。
1. トピック設計：汎用型か、専用型か
Copilot Studio のエージェントは、複数のトピックを持てる。最初に直面する判断が「1 つのエージェントでなんでも答えさせるか、用途ごとにエージェントを分けるか」だ。
| 観点 | 汎用型（1 エージェント多トピック） | 専用型（用途別に分割） |
|---|---|---|
| ユーザー体験 | 窓口が1つで迷いにくい | どのボットに聞けばよいか分かりにくい |
| 意図分類の精度 | トピック数増加で下がりやすい | 範囲が絞られているため高くなりやすい |
| メンテナンス | 1 か所に集まるが肥大化しやすい | 各エージェントの責務が明確 |
| 管理責任 | 担当者を決めにくい | 部署ごとに管理者を割り当てやすい |
大企業環境では、部署ごとの管理責任が分かれていることが多いため、専用型で部署ごとに管理者を割り当てる構成が現実的なことが多かった。汎用型は「全部任せるが品質の責任を持つ人が決まらない」という問題が起きやすい。
ただし、ユーザー側の視点から「窓口をできるだけ1つにしてほしい」という要望は強い。妥協点として、複数のエージェントをグループ化して1つのチャンネルに並べるという構成も検討する価値がある。
2. 生成型回答（Generative Answers）の範囲設定
Copilot Studio には、あらかじめ定義したトピック以外の質問に対して、SharePoint や Web サイトの情報を参照して生成で答える「Generative Answers」機能がある。
これを広く使うと確かに柔軟性は上がるが、「社内ドキュメントに書いてある内容なら何でも答える」という設計は予想外の回答につながりやすい。たとえば、人事規程に書いてある解釈が揺れる部分（有給休暇の取り扱い等）について、意図と異なる回答をするケースが実際にあった。
本番導入時に取った判断は「まず特定のナレッジソース（FAQドキュメント）だけを参照先に限定し、範囲を徐々に広げる」というアプローチだ。
最初から全社ドキュメントを参照先に入れると、想定外の回答が出たときの原因特定が難しくなる。「どのドキュメントのどの記述からその回答が生成されたか」の追跡コストが上がる。
参照先を限定する際の具体的な方法：SharePoint のドキュメントライブラリ単位で指定するか、タグ・メタデータで絞り込む。全社イントラネットを全部入れることはできるだけ避ける。
3. フォールバック処理：「わからない」をどう扱うか
エージェントが質問の意図を捉えられなかったとき（フォールバック）の処理設計は、ユーザー体験に直結する。
よくある失敗は「わかりません」で終わらせることだ。特に社内向けのサポートボットでは「わからないなら問い合わせ先を教えてほしい」という期待がある。フォールバック時に「担当部署への連絡先を案内する」「チケットを起票するフローに繋ぐ」という設計を入れることで、「使えないボット」というレッテルを防げる。
フォールバックの設計として有効だったパターン：
- 1 回目のフォールバック：「意図をもう少し具体的に教えてください」と再質問を促す
- 2 回目のフォールバック：「お役に立てなくて申し訳ありません。◯◯部（連絡先）にお問い合わせください」と終了
- フォールバックログを収集：週次でフォールバックの多い質問を確認し、新しいトピックを追加するサイクルを回す
特に 3 の「フォールバックをトピック改善のフィードバックとして使う」が長期的な品質改善に効いた。Copilot Studio の分析タブでフォールバック率を確認できるので、定期的に見る習慣をつけるとよい。
4. 認証設定：社内ユーザー限定か、匿名アクセスも許可するか
Teams に埋め込む社内用エージェントなら Azure AD（Entra ID）認証が自然な選択だ。しかし、外部向けポータル（Power Pages 等）に埋め込む場合は「匿名でも使えるようにしてほしい」という要望が来ることがある。
認証なしで使えるエージェントは、パーソナライズ（ユーザーごとの情報の使い分け）ができない。たとえば「あなたの申請の状況は？」という質問に答えるには、誰から聞かれているかの情報が必要になる。
この点で整理した設計の考え方：
- 匿名エージェント：一般的な FAQ 回答・案内専用。動的なユーザー情報は使わない
- 認証エージェント（Entra ID）：パーソナライズされた情報提供、申請処理などの業務フロー
「1 つのエージェントで両方やりたい」という要望があるが、認証状態によって動作を分岐させると複雑度が上がり、テストが難しくなる。最初は用途で分割することを勧めた。
5. Power Automate との連携：どこでフローを呼ぶか
Copilot Studio は Power Automate のフローを呼び出してバックエンド処理を行える。しかし、「どのトピックからフローを呼ぶか」の設計が甘いと、同じフローが複数の経路から重複して呼ばれる問題が起きやすい。
具体的な経験として、「申請の受け付け」と「申請の確認」に別々のトピックを作っていたが、どちらも最終的に同じ通知フローを呼んでいた。ユーザーが確認操作を行うたびに通知が飛んでしまい、受け取る側から「通知が多すぎる」というフィードバックが来た。
フローを呼ぶ前に「今回の処理は新規か、確認か」を明示的に状態で管理する設計が必要だった。
Copilot Studio の変数は会話セッションの間だけ保持される。セッションをまたぐ状態管理は、フローの中（Dataverse や SharePoint リスト）に持たせるのが適切だ。「会話の中で1回だけ通知を送る」という制御は、エージェント側の変数では実現できない場面がある。
フローとエージェントの責務の分け方として有効だったのは：
- Copilot Studio の担当：ユーザーとの会話、意図の解釈、情報収集
- Power Automate の担当：外部システムとの接続、データ処理、通知・記録
この分業を意識して設計すると、フローの再利用もしやすくなる。
まとめ
| ポイント | 判断軸 |
|---|---|
| 汎用型 vs 専用型 | 管理責任を誰が持つかで決まる |
| 生成型回答の範囲 | まず絞って、徐々に広げる |
| フォールバック | 2 回連続フォールバックは人手に渡す。ログを改善に使う |
| 認証設計 | 匿名なら FAQ 専用と割り切る |
| Power Automate 連携 | 状態管理はフロー側で持つ。フローの重複呼び出しに注意 |
Copilot Studio の設計はトピックを増やすほど複雑になる。最初はシンプルな構成で動かして、ユーザーフィードバックを見ながら拡張していく方が、「作ったけど使われない」を防ぎやすいと感じている。
本業での Power Platform・AI 基盤の運用についてはnoteでも書いています：https://note.com/light_tern636/n/nd807b5f274ee
皆さんの現場では、Copilot Studio のトピック設計はどのアプローチで進めていますか？
補足：リリース前のテストで押さえた 3 点
本番に乗せる前のテストで特に有効だったポイントを補足として書いておく。
①「失敗させるテスト」を意識的に行う
Copilot Studio のテスト用チャットパネルは「うまくいく入力」を試しがちだ。意図的に「話題が外れた質問」「不完全な入力」「悪意のあるプロンプト（プロンプトインジェクション）」を入れてフォールバックが適切に動くかを確認する。
②トリガーフレーズのバリエーションを増やす
各トピックのトリガーフレーズは、書いた人が思う言い方以外にも、実際のユーザーが使う口語表現・略語・打ち間違いに近い表現を追加する。Copilot Studio は機械学習ベースの意図分類を行っているが、フレーズのバリエーションが少ないと意図の一致率が低くなりやすい。
③本番の前に限定ユーザーで試験運用する
IT 部門だけでテストしてから全社展開すると、現場特有の入力パターンに対応できていない問題が起きやすい。10〜20 人の限定グループで 2 週間程度動かし、フォールバックログを見てから全体展開するサイクルが有効だった。
この記事の内容で詰まったことや、自分の環境に応用したいケースはありますか？Copilot・AIエージェント構築の相談を受け付けています（ご連絡の際は「Qiitaを見た」とお書きください）：https://coconala.com/services/4209036