AIエージェントの回答品質は、業務で使う質問に対して、何を答えるべきか、何を出してはいけないか、いつ確認・保留すべきかを決めて評価します。質問、利用者、参照資料と期待結果を一組で残し、変更前後に同じ条件で試すと、改善した点と未解決の失敗を確かめられます。
この記事は、回答を受け入れてよいか判断するDX・業務責任者に向け、評価ケースの作り方を提案します。表と仮想例はアクセルAIの設計案です。Copilot Studioの公式機能は実施方法の一例として紹介し、業務上の合格条件と分けて扱います。
質問を集める前に、評価する業務を決める
まず、誰がどの仕事で回答を使い、何が分かれば次の作業へ進めるかを決めます。規程の案内なら、対象者や適用時期を取り違えず、必要な条件と参照先を示せることが判断材料になります。業務担当者が正しい扱いを説明できない質問は、期待結果を合意するところから始めます。
Microsoftの評価設計ガイドも、業務目的と評価をつなぎ、更新前に回帰試験を行う考え方を示しています。自社の業務でどの結果を確認するかを先に定めます。公式：エージェント評価の設計と運用
質問の候補は、利用許可を確認した問い合わせ履歴や、担当者が普段受ける質問から集めます。個人情報・機密の扱いを確認して評価用に整え、条件の省略や曖昧さも試せるようにします。実際の質問がまだない段階の想定ケースは、仮置きと明記して後から見直します。
期待結果を、必須要素・禁止事項・確認・保留に分ける
期待結果には、模範的な文章に加えて、判定する条件を書きます。含めるべき情報、出してはいけない内容、追加で尋ねる条件、答えを保留する条件を分ければ、表現が異なる回答も同じ観点で確認できます。
正本となる資料とその版、適用条件を業務担当者が確かめます。回答の確認者によって判断が割れるときは、その理由を残し、期待結果を合意してから合否を決めます。次の表は仮想の設計例で、実際の顧客の質問や実績ではありません。
表は横にスクロールして確認できます。
| ケース | 質問・前提の例 | 期待する結果 | 確認する記録 |
|---|---|---|---|
| 通常の質問 | 対象者と申請条件が分かる質問 | 必要な条件・手順・出典を含める | 実回答、参照した正本・版 |
| 情報不足 | 対象者や適用時期が分からない | 足りない条件を尋ね、結論を断定しない | 確認質問と続く応答 |
| 権限外 | 資料の閲覧を許可していない利用者で質問 | 対象内容を回答・引用しない | 実行アカウント、権限、応答 |
| 資料の不一致 | 現行版と旧版の記述が食い違う | 合意済みの適用条件で判断し、不明なら保留する | 参照資料・版、判定理由 |
| 根拠がない | 登録した資料に回答根拠がない | 推測で埋めず、決めた窓口へ案内する | 実回答、案内先、確認者 |
記録には、ケースID、質問と前提、利用者の役割、資料の版、期待結果、実結果、確認者、再評価結果を残します。出してはいけない内容が含まれた場合など、他のケースの高得点で相殺しない失敗条件も業務側が決めます。
AIエージェントの評価ケース雛形をダウンロードする。必須要素・禁止事項・確認や保留の条件を記入するための雛形です。自社の業務に合わせて項目と期待結果を調整してください。
自動採点と、業務担当者の確認を組み合わせる
Copilot Studioの公式評価機能では、質問や会話をテストセットにし、繰り返し実行できます。現在サインインしている利用者で評価するため、利用者の役割と接続条件も記録します。公式：エージェント評価の概要
この製品例はstandard harness向けです。手動認証を設定したエージェントなど対象外の条件があるため、採用方式・認証・接続に合う評価方法を確認してください。別製品にも同じ機能があるとは扱わず、記録する条件と評価手段を分けて設計します。
自動採点の結果を手掛かりに、業務担当者は重要な条件の抜け、根拠の取り違え、保留すべき場面を確認します。誰が何を確認するか、判断できない結果を誰へ戻すかを決めます。一律の合格率や必要件数を置かず、誤りの影響と利用範囲に応じて受け入れ条件を合意します。
失敗の理由を分類し、同じケースで変更前後を比べる
不合格の理由は、必要な情報を探せない、見つけた情報を取り違える、確認質問が足りない、保留・案内ができない、権限の条件を満たさない、といった形で記録します。回答文だけを直す前に、正本、接続、指示、期待結果のどこを見直すかを判断します。
Microsoftの結果確認機能では、同じテストセットの実行結果を比較し、実回答や使用リソースを確認できます。応答時間は計測値として表示されますが、その値だけで合否が決まるわけではありません。公式：評価の実行と結果確認
資料、指示、接続やモデルを変えたら、変更内容と実行日を残して再評価します。変えた箇所に関係する質問に加え、それまで使えていた重要な質問も確認します。期待結果自体を変える場合は理由と承認者を残し、以前と同じ採点条件として比較しないようにします。
評価ケースを、改善と受け入れ判断に引き継ぐ
打ち合わせには、質問セット、根拠資料、実回答、失敗理由、未解決事項を持ち寄ります。業務側が期待結果と受け入れ条件を決め、開発・支援側が再現と修正を行い、変更後の結果を一緒に確認する役割分担を提案します。
データと権限が原因の失敗は、社内データの接続前確認へつなげて調べます。評価結果を含めた公開可否は、Copilot Studioの本番移行で整理しています。
Copilot Studio活用支援と、社内で改善を続けるAI推進者育成・内製化支援をご確認ください。支援の進め方と支援者の背景も掲載しています。