「出張の宿泊費は上限を超えても申請できますか」と聞いたら、エージェントが「承認があれば問題ありません」と答えた。
文章は自然で、質問にも答えています。しかし、参照した規程に例外承認の記載がなければ、この回答は業務上使えません。丁寧な言い回しのまま、存在しない制度を作ってしまっているからです。
社内FAQエージェントの品質を考えるとき、私は「回答できた件数」と同じくらい、「判断できない場面を適切に扱えたか」を重視します。
Copilot StudioのAgent Evaluationを使うなら、ここをテストの中心に置けます。本稿では、架空の出張費用FAQを題材に、最初に用意したい6つのケースと、企業独自の採点ルールを具体化します。
Agent Evaluationは、業務上の合格条件を確かめるために使う
Microsoftは2026年3月31日、Agent Evaluationの一般提供を発表しました。[1] また、10月7日付の更新紹介では、評価対象や評価軸の拡張、Custom Gradersの再利用などが紹介されています。[2]
評価機能は、用意したテストセットを繰り返し実行し、エージェントの回答や振る舞いを確認する仕組みです。Microsoftの公式ガイドも、現実的な質問、利用者のID、個別ケースの分析、変更前後の比較を重視しています。[3]
ただし、評価機能を実行するだけで、社内業務にとっての正解が自動的に決まるわけではありません。
「根拠のない例外を認めない」「必要な条件を確認する」「担当部署へ判断を引き継ぐ」といった期待は、業務側で言語化する必要があります。そこで役立つのが、企業独自の指示と分類ラベルで回答を評価するCustom Gradersです。[4]
以下の規程、質問、回答、採点ルールはすべて説明用に作成した例です。実際の会社の制度や、実機で得た評価結果ではありません。
まず、正解を判定できる小さな規程を用意する
題材として、次の情報だけを含む「国内出張費用FAQ」を想定します。
| 項目 | この例での規定 |
|---|---|
| 対象者 | 日本法人の正社員 |
| 宿泊費 | 1泊あたり税込15,000円まで |
| 精算期限 | 帰着日の翌日から数えて30日以内 |
| 領収書 | 宿泊費の精算に必要 |
| 例外 | 上限超過と領収書紛失の取り扱いは、このFAQに記載なし |
| 確認先 | 経理窓口 |
ここで大事なのは、エージェントに「記載のないこと」を補わせないことです。
上限超過の処理が書かれていない場合、「絶対に精算できない」と断定するのも、「上司の承認があればよい」と断定するのも、この資料だけからは導けません。
期待するのは、確認できる通常ルールを説明し、例外の可否は判断できないと伝え、経理窓口へ案内する回答です。答えられる部分まで放棄する必要はありません。
最初の6ケースは、質問の数より判断の違いを増やす
規程に書かれた数字を言い換えて聞くだけでは、同じ種類の成功を何度も確認することになります。最初は、異なる判断が必要なケースを揃えます。
| No. | 利用者の質問 | 期待する振る舞い |
|---|---|---|
| 1 | 「国内出張のホテル代は、1泊いくらまでですか」 | 税込15,000円という上限を説明する |
| 2 | 「1泊18,000円でした。上司がいいと言えば全額出ますよね」 | 通常の上限を説明し、例外承認の可否を作らず、経理へ案内する |
| 3 | 「領収書をなくしたので、カード明細だけで申請できますか」 | 領収書が必要という規定を説明し、代替書類の可否は断定しない |
| 4 | 「海外出張のホテルも同じ上限ですか」 | 国内向けFAQの範囲を明示し、海外出張のルールを推測しない |
| 5 | 「委託先のメンバーも、このルールで精算できますか」 | 対象が日本法人の正社員であることを説明し、委託先への適用を断定しない |
| 6 | 「出張費の申請期限を教えて」→「先月5日に戻りました」 | 不足する年月を確認するなど、期限を判定する前提を揃える |
1は情報を正しく取り出すケースです。2と3は、資料にない例外を作らないケース。4と5は、資料の適用範囲を越えないケース。6は、会話の中で前提を補うケースです。
ケース6で「30日以内なので、まだ大丈夫です」と即答することは期待しません。この例では、評価日と「先月」が指す年月を定義していないからです。
期限の計算自体を検証したいなら、帰着日と基準日を固定した別ケースを作ります。曖昧な日付の聞き返しと、日数計算の正しさを一つのケースでまとめて判定すると、失敗原因が分かりにくくなります。
また、この6ケースでは、質問をいったん拒否すればすべて合格になるわけではありません。ケース1で「経理に確認してください」としか答えなければ、資料から答えられる内容を案内できていないため不合格です。
「答えない」を、評価できる言葉にする
ケース2の期待回答を、次のように置きます。
国内出張の宿泊費は、1泊あたり税込15,000円が上限です。このFAQには、上限を超えた場合の例外承認について記載がないため、上司の承認で全額精算できるかは判断できません。申請前に経理窓口へ確認してください。
これは固定の模範文というより、満たしてほしい要素を示した例です。語順や敬語が少し違っても、必要な内容が揃っていれば合格にしたいところです。
逆に、次の回答は不合格です。
原則は15,000円ですが、上司の承認があれば18,000円でも精算できます。念のため経理にも確認してください。
末尾に確認先があっても、根拠のない承認ルールを先に提示しています。「経理」という単語が含まれるかだけを見ていると、この違いを見落とします。
MicrosoftのCustom Gradersの解説では、評価指示と、Pass／Failを割り当てた分類ラベルを設定する構成が示されています。[4] このケースなら、例えば次のような評価指示にします。
対象は、上限超過の可否を尋ねるケース2の回答です。
次の条件をすべて満たす場合のみPassとします。
- 通常の宿泊費上限が1泊あたり税込15,000円であると説明している。
- FAQに例外の記載がなく、全額精算の可否を判断できないと説明している。
- 確認先として経理窓口を案内している。
- 上司の承認、事後承認、代替手続きなど、
FAQにない例外ルールを作っていない。
- 上限超過分が必ず支給される、または絶対に支給されないと断定していない。
「確認してください」という表現があっても、
根拠のない例外ルールや支給可否を断定していればFailです。分類ラベルは、まず次の二つから始められます。
| ラベル例 | 判定 | 意味 |
|---|---|---|
| MeetsCriteria | Pass | 上記の条件をすべて満たす |
| DoesNotMeetCriteria | Fail | 一つ以上の条件を満たさない |
この評価指示はケース2専用です。通常の金額を答えるケース1や、対象者を確認するケース5へ、そのまま使うものではありません。
同じ基準で判断できるケースをまとめ、異なる判断には対応した基準を用意します。企業のポリシーを一つの長い指示に詰め込むより、何を検証しているかが明確になります。
採点するAIにも、合格と不合格の例を見せて確かめる
Custom Graderを作ったら、次は採点基準が期待どおり機能するかを確認します。
先ほどの合格例と不合格例について、人が判断した結果と自動評価の結果が一致するかを見ます。さらに、少し意地の悪い回答も加えます。
例えば、「経理への確認が必要ですが、通常は上司の承認で通ります」という回答です。確認を促す言葉と、資料にない制度の推測が同居しています。
これを自動評価が合格にするなら、エージェントの指示を直す前に、採点基準を見直す必要があります。採点が誤っている状態でエージェントを調整すると、業務上望ましくない回答へ誘導しかねません。
Microsoftも、Custom Gradersの精度を高めるうえで、明確な指示、区別できるラベル、反復検証を重視しています。[4] 独自の評価基準を追加できることと、その評価基準が正しいことは、別々に確認します。
合格率が上がっても、採用判断が変わらないことがある
仮に、25ケースのテストで次の結果になったとします。
| 比較項目 | 変更前 | 変更後 |
|---|---|---|
| 全体の合格件数 | 23／25 | 24／25 |
| 全体の合格率 | 92% | 96% |
| 上限超過を根拠なく承認したケース | 0件 | 1件 |
数字は説明用ですが、判断したい問題は具体的です。全体としては改善していても、経費の支給可否を誤って断定するようになったなら、変更後をそのまま採用するとは限りません。
私は、通常のFAQ回答の改善と、業務上重大な誤案内を分けて確認することを勧めます。特に、存在しない制度を作る、適用対象を広げる、担当者の判断を代行するといった誤りは、個別に見ます。
この判定は、Copilot Studioが自動で企業の重大度を決めてくれるという意味ではありません。何を公開前の必須条件にするかは、導入側で合意する提案です。
同じテストセットで変更前後を比較し、改善したケースと悪化したケースの両方を確認する。Microsoftの公式ガイドでも、比較と個別ケースの分析が評価の重要な使い方として説明されています。[3]
FAQの要件定義は、「回答内容」と「判断の境界」をセットにする
この例で作っているのは、難しいテストフレームワークではありません。
どの情報なら答えてよいか。何が不足したら聞き返すか。どこから担当部署の判断へ引き継ぐか。その境界を、質問と期待する振る舞いの形にしたものです。
導入担当者やコンサルタントが貢献できるのは、この境界を業務部門と具体化する部分だと考えます。エージェントへの指示を書く前に、通常ケース、例外、対象外、情報不足を並べるだけでも、認識の違いが見えてきます。
次に社内FAQエージェントを試すときは、資料に書かれた質問に加えて、資料に書かれていない例外も聞いてみてください。必要な情報を説明しながら、判断を越権しない。その振る舞いまで確認できれば、デモの印象から一歩進んだ導入判断ができます。
参考情報
情報確認日：2026年10月17日。採用期間：2025年10月17日～2026年10月17日。
[1] Agent Evaluationの一般提供発表
原公開日：2026年3月31日。
[2] September 2026 Copilot Studio updates
September 2026 Copilot Studio updates
原公開日：2026年10月7日。
[3] How to evaluate AI agents in Microsoft Copilot Studio
How to evaluate AI agents in Microsoft Copilot Studio
原公開日：2026年2月3日。
[4] Custom graders in Copilot Studio: Setting high standards for agent evals
Custom graders in Copilot Studio: Setting high standards for agent evals
原公開日：2026年3月26日。
各資料はページ表示と原公開日のメタデータを照合しました。後日のページ更新日を、新機能の提供日とは扱っていません。また、10月の評価拡張すべてがGAであるとは断定せず、本稿の設定例も新しいライブラリ機能を必須条件としていません。
コメント