Copilot Studioエージェント構築：グラウンディング、ペルソナ、デバッグ、公開で初心者のミスを防ぐ方法

Copilot Studioで初めてエージェントを公開したのに、「ポリシーには、おそらくそれがボット構築の自然な姿だと書いてある気がします」といった頼りない回答をしてしまった。そんな経験は、決して珍しくありません。テスト画面では完璧に動いていたボットが、本番では急に自信のない答えを返し始めるのです。

原因の多くは、グラウンディング(根拠付け)、ペルソナ、デバッグ、公開という4つの工程での初歩的なミスにあります。この記事では、テストペインで悪い回答を再現する方法、実際の文書を引用させる方法、そしてパイロット運用を経て公開する流れを順に解説します。

Copilot Studioのテストペインで完璧でも、本番で崩れる理由

スタジオは、入力データが整理された「道場」のような環境です。質問は短くきれいで、用意したトレーニング例と一致しやすくなっています。ところが本番では、ユーザーは人間らしく入力します。同じ意味でも、次のように言い方はさまざまです。

• 「ホテル滞在時の請求額はいくらまで?」
• 「ホテル経費制限」のような、助詞を省いた書き方や誤字混じりの入力
• 「出張費について教えて」という漠然とした聞き方

「経費制限はいくらですか」しかテストしていないと、ボットはこれらを常に結びつけられるとは限りません。

3パターンの質問でギャップを確認する

確認は簡単です。テストペインを開き、次の3つを順に投げてみてください。

1. きれいな質問文
2. カジュアルな書き換え
3. 誤字のあるパターン

回答の変化を観察すると、きれいな質問にしか正しく答えられないボットは意外に多いものです。たとえばスタジオで「経費の制限は」と入力すると「宿泊費は1日200ドルです」と答えるのに、「ホテルの代金はいくらまで戻るんだっけ」と聞くと人事への確認を促したり、曖昧な推測を返したりします。意図は同じなのに結果は全く違います。

トリガーフレーズを広げる

技術的な背景は、インテント(意図)の網羅性にあります。ボットはトリガーフレーズとトピック定義を頼りに、いつ回答すべきかを判断します。例がすべて似た表現だと、類義語ひとつで混乱することもあります。

対策は地味ですが効果的です。ポリシー文書の正式な言葉だけでなく、カジュアルで略語を含む少し崩れた表現もトリガーフレーズに加えましょう。何十個も必要はなく、明白なバリエーションを押さえれば十分です。追加したら再テストします。

チャンネルごとの違い

テストペインはあくまでシミュレーションです。Teams、SharePoint、デモ用ウェブサイトなどに公開すると、入力テキストの処理や応答の表示がプラットフォームごとに変わる可能性があります。Teamsでは改行のされ方が異なることがあり、ウェブページでは書式が削除されることもあります。重要なフレーズを別の行に移すといった些細な変更でも、モデルの評価が変わり得ます。Microsoftが各チャンネルでの繰り返しテストの必要性を強調しているのは、このためです。

スタジオはスパーリングの練習相手と考えましょう。学習には役立ちますが、準備万端の証明にはなりません。

グラウンディング:ボットを「水晶玉」から「ルールブック」へ

初心者が最初に犯しやすいミスは、Copilot Studioをルールブックではなく水晶玉のように扱うことです。十分な知識なしにエージェントを立ち上げるのは、準備ゼロの新人を役員会議に送り込むようなものです。話し方は自信ありげでも、誰かが確認した瞬間に内容の半分は崩れます。

グラウンディングされていないボットは、事実ではなくパターンを抽出しているにすぎません。最悪なのはハルシネーション(幻覚)で、わからないと断る代わりに、ありそうな数字をでっち上げます。それを信じたスタッフがホテルを予約すれば、経費のトラブルや苦情対応につながります。

ポリシー文書の有無で回答が変わる例

Contosoの例では、「Expenses Policy.docx」に宿泊費の上限が1泊200ドルと明記されています。この文書を添付せずに「ホテルの規定は?」と尋ねると、ボットは「1泊100ドル」と自信満々に答えてしまうかもしれません。完全なデタラメです。文書を実際に添付して初めて、モデルは適当な回答をやめ、「社内規定によると宿泊費は1日200ドルまでです」と引用付きで答えます。でっち上げか引用かを分けるのが、グラウンディングの工程です。

ナレッジの追加手順

1. Copilot Studioで対象のエージェントを開き、概要画面から「ナレッジ」をクリックします。
2. 「ナレッジの追加」を選び、ファイルをアップロードします。信頼できるソースを指定してください。
3. インデックス作成の完了を待ちます。10分以上かかることもあるため、最初のテストで反映されなくても慌てないでください。
4. 完了後にもう一度質問し、アップロードした文書からの引用元と正しい200ドルという回答が表示されるか確認します。

公開ウェブサイトやSharePointへの接続も可能ですが、管理しやすいのはファイルです。

会話ブースティングは万能ではない

会話ブースティングが欠落を魔法のように補ってくれる、というのは誤解です。ブースティングは規定を理解するわけではなく、一般的な言葉を並べるだけです。ナレッジベースに一致するものがない場合、モデルに組み込まれた一般知識に頼り、曖昧または不正確な回答を返す可能性があります。コンプライアンス、財務、人事のように正確さが求められる分野では、追加したソースのみを検索するよう設定してください。

根拠のないボットが勝手に限度額を作り、5人の従業員が誤った金額で申請してしまえば、財務部門への説明が必要になります。その修正コストは、最初に文書をアップロードする手間よりはるかに大きくなります。

ペルソナ設定:名前・説明・指示・トーンで信頼を得る

正確でも、個性がなければユーザーは離れてしまいます。Copilot Studioは標準では個性を与えてくれないため、自分で書き込む必要があります。名前、説明、指示のフィールドを空のままにすると、チュートリアルモードから抜け出せないNPCのような、ありきたりな返答になります。

人事や財務の場面で一般的な口調のままだと、ユーザーは「信頼できるツールではなく、プロトタイプを試している」と受け取ります。経費規定の専門家を作るつもりでも、名前や説明を変えなければ、背景情報のない汎用的なCopilotに見えてしまいます。最初の接触で逃したユーザーは、なかなか戻ってきません。

キャラクターシートのつもりで設定する

設定全体はキャラクターシートに例えられます。名前は職業クラス、説明は背景、長い指示ボックスは能力値、トーンは属性です。能力値を割り振らずにキャンペーンへ挑まないのと同じで、ボットも設定してから公開します。

• 名前:上限は30文字です。「経費規定エキスパート」「トラベルガイド」「福利厚生ヘルパー」のように、短く目的が伝わるものにします。
• 説明:約1000文字まで入力できます。「公式の出張規定に基づいた最新の回答を従業員に提供します。関連する条文を引用し、推測による回答は避けます」といった数文で十分です。
• 指示:最大8000文字です。「親切に」と書くだけでなく、「ポリシーの該当箇所があれば必ず引用する」「推測では答えない」「役員向けには簡潔な一文で要約し、その後に引用元を示す」など、運用ルールを具体的に書きます。
• トーン:「フォーマルかつプロフェッショナルに」「技術的背景のないスタッフにもわかりやすく、カジュアルに」のように明示します。必要なら指示欄に例を直接加えます。

指示欄には、行動ルール、含めるべき内容、避けるべき内容、フォーマット方法を盛り込みましょう。これらは作成時に設定でき、概要ページからあとで編集することもできます。

5分でできる2つの改善

ひとつは「会話開始」トピックの編集です。デフォルトの汎用的な挨拶を、「出張規定の理解をサポートします。可能な限り公式ドキュメントを引用します」といった役割に応じた紹介文に置き換えます。会話をリフレッシュしてテストすれば、印象が一変します。

もうひとつはエージェントアイコンの変更です。192x192ピクセル以下、30KB未満のPNG形式に対応しています。ブランドロゴなどを一つ入れるだけで、デモ感が薄れます。

これらは単なる仕上げではなく、最低限の防具です。味気ない名前と曖昧な挨拶で迎えるボットは、防具なしで戦場に出るようなものです。役割を明記した導入文はユーザーが適切な質問をする助けになり、口調のルールは冗長な回答を防ぎ、明確な指示はAIが余計な情報をそぎ落とす助けになります。

デバッグの基本ループ:再現・修正・再実行

本当のテストは、実際のやり取りで成功と失敗を目にしてから始まります。一度の失敗で諦めず、立ち止まって原因を調べましょう。間違いを見つけ、特定し、修正し、再度テストする。このループを回すことで、失敗が問い合わせではなく学びに変わります。

5ステップのデバッグ手順

1. 再現する:失敗したユーザーのクエリを、一字一句同じ形でテストウィンドウに入力します。
2. リセットする:リフレッシュアイコンか新しいチャットで会話をリセットし、白紙の状態で実行します。
3. トピックを確認する:どのトピックが作動したかを見ます。自分で作ったものではなくシステムの会話ブースト機能によるものなら、ボットが独自の知識ではなくモデルの知識に頼ったというヒントです。
4. インデックスを確認する:ブーストが働いていた場合は、関連するファイルやサイトがアップロードされ、インデックスされているかを確認します。インデックスがなければ根拠付けも行われず、作成には数分かかることがあります。
5. 修正して再実行する:指示やトピックを編集して保存し、同じクエリをもう一度実行します。

この「再現・修正・再実行」の繰り返しを習慣にしましょう。省略すると、次回は運任せで結果が良くなるのを願うだけになってしまいます。

曖昧な回答にはトピックの追加を

回答が曖昧なのは、トーンではなく構造の欠如が原因の場合もあります。その場合は、トピックページからCopilotを使い、説明文から新しいトピックを追加できます。「経費の上限について聞かれたら直接答える」といった内容を書いて追加を押すと、その説明からトピックのノードツリーが下書きされます。ボットが同じ基本的な質問でつまずき続けるときに有効です。

トーンのA/Bテストとグラウンディング確認

10分でできる実験として、指示フィールドでトーンのA/Bテストを行えます。パターンAは形式的な規定の言葉づかい、パターンBはルールを引用しつつ親しみやすい人事担当者のような説明にします。それぞれ保存して「出張費の上限は?」と質問し、回答を比べれば、推測ではなく証拠に基づいてトーンを決められます。

グラウンディングの確認も忘れずに行います。「ホテルの経費はいくらまで?」に対して「人事に確認してください」と返ってきたなら、それは完全な失敗ではなくフィードバックです。経費規定のドキュメントがまだインデックスされていないか、トリガーフレーズに「ホテル」が含まれていない可能性があります。ナレッジタブでファイルの反映を確認し、トリガーフレーズに「ホテル経費」を追加して再実行しましょう。「規定により宿泊費は1泊200ドルまでです」と返れば解決です。

もうひとつの工夫が会話のきっかけ(スターター)です。空の入力欄の前でユーザーは戸惑いがちなので、概要ページで推奨プロンプトを3〜5個事前入力しておきます。「ホテルの上限は?」「出張経費の申請方法は?」「食事代は精算される?」といった内容です。ユーザーはクリックするだけで済み、ボットの役割も伝わります。

公開とチャンネル別テスト:パイロット運用から始める

公開はクリック一つで終わる作業ではありません。誰がエージェントにアクセスでき、どう接続し、応答が現場でどう表示されるかを決めるプロセスです。Teams、SharePoint、デモ用ウェブサイトにはそれぞれ癖があり、スタジオで完璧だった返信が、見た目が変わったり表示に失敗したりすることがあります。たとえばTeamsで同じ質問をすると、ボット側は何も変えていないのに「理解できません」と返ってくる場合があります。公開先はそれぞれ別のアリーナなので、個別にテストしなければなりません。

公開前チェックリスト

1. ナレッジファイルが完全にインデックスされていることを確認する。アップロード直後はライブ回答に対応できていない可能性があります。
2. 認証を設定する。広くデモを行うなら「認証なし」を選び、リンクを持つ誰でも試せるようにします。
3. 公開ボタンを押し、緑の確認バナーまたはチャンネルページのステータス更新を確認する。
4. デモ用ウェブサイトのチャンネル設定で、ウェルカムメッセージと会話のきっかけを更新する。
5. テナント全体にはまだ配信せず、クローズドパイロットを実施する。

パイロットグループの活用

明確な指示を与えた小規模グループで進める方が、全体リリースより賢明です。メンバーには自分たちがテスターであると伝え、カジュアルな言葉づかいや誤字を含めて質問し、適切な場面でファイルをアップロードしてもらいましょう。彼らのミスが弱点を浮き彫りにし、全社展開の前に修正すべき具体的なレポートが得られます。

スタジオでテストしたシナリオ(正式なクエリ、カジュアルな表現、誤字、根拠となる引用)は、すべてのターゲットチャンネルで再実行します。Teamsの表示、SharePointでの挙動、Webデモでソースの引用が正しく付くかを確認してください。

公開後はテレメトリを監視する

公開すると利用データの収集が始まります。Power Platform管理センターと組み込みの分析機能により、導入数やエラー数、どの会話がトピックをトリガーできなかったかまで把握できます。ログを見て、ボットが正しく使われているか、ヘルプデスクのチケットを増やしていないかを確認しましょう。公開ボタンは物語の結末ではなく、フィールドキャンペーンの始まりです。

初心者が陥りやすいミスと対策

• スタジオでの成功を過信する:きれいな質問だけの確認では、言い換えや誤字、チャンネル固有の表示に対応できているかわかりません。
• ナレッジなしで公開する:根拠のないボットは、もっともらしい数字を作り出します。
• ブースティングに頼る:ナレッジソースという土台がなければ、一般的で空虚な言葉が並ぶだけです。
• インデックス完了前にテストする:反映されないのを不具合と誤解しがちですが、10分以上かかることもあります。
• 名前・説明・指示を空のままにする:権威も文脈もない、当たり障りのない挨拶のボットになります。
• 失敗をテスト外で曖昧に流す:失敗した質問をそのまま再現せずに直すと、次回も運任せになります。
• 全社へ一気にロールアウトする:重要な回答が欠落し、「動かない」というチケットであふれるリスクがあります。

実践のためのポイントとまとめ

• きれいな質問、カジュアルな言い換え、誤字入りの3パターンでテストし、トリガーフレーズを広げる。
• Expenses Policy.docxのような信頼できる文書をナレッジに追加し、インデックス完了後に引用付きで答えるか確認する。
• 正確さが重要な分野では、追加したソースのみを検索するよう設定する。
• 名前(30文字以内)、説明(約1000文字まで)、指示(最大8000文字)、トーンを具体的に書く。
• 会話開始トピックとアイコン(192x192ピクセル以下、30KB未満のPNG)を、役割に合わせて更新する。
• 失敗は「再現・リセット・原因確認・修正・再実行」のループで潰す。
• 会話のきっかけを3〜5個用意し、ユーザーが迷わず始められるようにする。
• 公開前にインデックスと認証を確認し、クローズドパイロットで検証する。
• すべてのチャンネルで主要クエリを再実行し、公開後もログを監視する。

まとめ

Copilot Studioで信頼されるエージェントを作る鍵は、3つに集約されます。実際のドキュメントで根拠を与えること、指示フィールドでペルソナを具体的に設計すること、そしてテストペインでの成功に安心せず、限定的なパイロットを経て公開し、公開後も監視することです。この手順を踏めば、ボットは問い合わせチケットを増やす存在ではなく、ユーザーの信頼を獲得する存在になります。