eval-faq

目的

AI エージェントの評価という文脈で、評価方法、評価者の種類、データセットの設計、評価基準の作成、非決定性、ツール呼び出しの評価、複数ターンのエージェント評価、評価ツール、能力評価と回帰評価、結果の解釈に関するあらゆる質問に回答します。主な方法論は skills/eval-guide/playbook.md に記載された エージェント評価の実践ガイダンス：10 ステップのプレイブック です。Microsoft のエージェント評価ドキュメント（MS Learn のページ、Eval Scenario Library、Triage & Improvement Playbook、Eval Guidance Kit）は、Copilot Studio の仕組みと参照パターンに関する権威ある補足資料として引き続き使用し、Microsoft が詳しく取り上げていないトピックについては、厳選した業界資料で補います。

手順

/eval-faq <question> として呼び出された場合は、次のプロセスに正確に従ってください。

ステップ 1 — 回答前に信頼できる情報を取得する

このトピックと URL の対応表を使って、取得する情報を決めてください。取得してから回答してください。質問のトピックに一致する URL のみを取得し、毎回すべての URL を取得しないでください。

質問のトピック	取得する URL	抽出するセクション	備考
シナリオの種類、ビジネス課題シナリオと機能シナリオ、記述すべきケース、データセット構造	https://github.com/microsoft/ai-agent-eval-scenario-library	ビジネス課題シナリオ、機能シナリオ、eval-set-template	5 種類のビジネス課題シナリオと 9 種類の機能シナリオ
品質シグナル、ポリシーの正確性、情報源の帰属、パーソナライズ、アクションの実行可能性、プライバシー	https://github.com/microsoft/ai-agent-eval-scenario-library	品質シグナルのセクションと手法のマッピング表	品質シグナルと評価手法の対応付け
レッドチーム、敵対的テスト、攻撃対象領域の縮小、XPIA、エンコード攻撃、ASR 指標	https://github.com/microsoft/ai-agent-eval-scenario-library	レッドチームのセクション：Probe-Measure-Harden フレームワーク	レッドチームの ASR しきい値：有害な内容は <2%、PII は <1%、ジェイルブレイクは <5%
評価手法の選択、キーワード一致と意味の比較と一般的な品質評価の違い	https://github.com/microsoft/ai-agent-eval-scenario-library	resources/evaluation-method-selection-guide.md	選択基準を示した 4 種類の評価手法
評価の生成、プロンプトテンプレートからの評価ケースの作成、テストセットの合成	https://github.com/microsoft/ai-agent-eval-scenario-library	resources/eval-generation-prompt.md	評価ケースを生成するためのテンプレート
エージェントプロファイルのテンプレート、評価対象となるエージェントの範囲の定義	https://github.com/microsoft/ai-agent-eval-scenario-library	resources/agent-profile-template.yaml	評価範囲を定めるためのエージェントプロファイル定義
スコアの解釈、スコアの意味、リスクティアに基づくしきい値、ハードゲート／ソフトゲート、準備状況の判断、SHIP／ITERATE／BLOCK	https://github.com/microsoft/triage-and-improvement-playbook	レイヤー 1：スコアの解釈、準備状況の判断ツリー	ステップ 4／6／7 の準備状況の判断を補足する情報源
失敗のトリアージ、評価失敗のデバッグ、根本原因分析、診断の質問	https://github.com/microsoft/triage-and-improvement-playbook	レイヤー 2：失敗のトリアージ、26 の診断質問	5 つの評価検証質問、評価設定の失敗に関する 7 つのサブタイプ
修正、失敗の解消、指示の予算、失敗パターンごとのアクション	https://github.com/microsoft/triage-and-improvement-playbook	レイヤー 3：修正マッピング	失敗パターンに対応付けられたアクション
パターン分析、シグナル横断パターン、傾向分析、集中度分析	https://github.com/microsoft/triage-and-improvement-playbook	レイヤー 4：パターン分析	7 つのシグナル横断パターン、傾向分析
根本原因の種類、評価設定の問題とエージェント品質の問題、評価設定の問題とエージェント構成の問題とプラットフォームの制限	https://github.com/microsoft/triage-and-improvement-playbook	根本原因の種類のセクション	ステップ 7 の 2 つの根本原因の分類を補足する分類体系
非決定性への対応、実行間のばらつき、不安定な結果	https://github.com/microsoft/triage-and-improvement-playbook	非決定性のセクション	最低 3 回実行、±5% は通常範囲、±10% は調査が必要
4 段階の反復フレームワーク、定義、ベースラインの設定と反復、体系的な拡張、運用化	https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/evaluation-iterative-framework	フレームワーク全体 — 4 つのステージすべて	10 ステップのプレイブックを補足する、MS Learn のライフサイクル／実施頻度に関する情報源
評価チェックリスト、準備状況チェックリスト、リリース前の検証	https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/evaluation-checklist	チェックリスト全体	Eval Guidance Kit のドキュメントに対応
グレーダーの種類、コードベースと LLM 判定と人間によるグレーダー、一般的な評価手法	https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/architecture/common-evaluation-approaches	Echo、Historical Replay、Synthesized Personas、グレーダーの種類	3 種類のアプローチと 3 種類のグレーダー
7 種類のテスト手法、一般的な品質、意味の比較、機能の使用、キーワード一致、テキスト類似度、完全一致、カスタム	https://learn.microsoft.com/en-us/microsoft-copilot-studio/analytics-agent-evaluation-overview	7 種類のテスト手法のセクション	一般的な品質の下位次元：関連性、根拠性、完全性、回答の棄権
テストセットの作成、Copilot Studio での評価データセットの構築	https://learn.microsoft.com/en-us/microsoft-copilot-studio/analytics-agent-evaluation-create	テストセットの作成方法	テストケースの生成、インポート、手動作成
テストセットの編集、ユーザープロファイル、接続、テスト手法の変更	https://learn.microsoft.com/en-us/microsoft-copilot-studio/analytics-agent-evaluation-edit	ユーザープロファイルと接続の管理、テスト手法の編集	異なるユーザーをシミュレートする複数プロファイルでの評価、GCC の制限
評価の実行、結果の表示、テスト結果の解釈	https://learn.microsoft.com/en-us/microsoft-copilot-studio/analytics-agent-evaluation-results	テストの実行と結果の表示	結果の保持期間は 89 日間。結果はすぐにエクスポートしてください
エージェント評価の概要、自動テストを使う理由、テストチャットと評価の違い	https://learn.microsoft.com/en-us/microsoft-copilot-studio/analytics-agent-evaluation-intro	エージェント評価について	GCC の制限：ユーザープロファイルは使用不可、テキスト類似度の手法は使用不可
ルーブリックの改善ワークフロー、AI による採点と人間の判断の整合	https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/kit-rubrics-refinement-workflow	8 段階のワークフロー：実行、レビュー、採点、改善、保存、再実行、反復	整合性マトリックス、標準／詳細の改善ビュー、例のマーキング
ルーブリックのベストプラクティス、ルーブリック改善のヒント	https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/kit-rubrics-best-practices	改善のベストプラクティス	例は量より質を重視し、整合率 100% を目指さない
ルーブリックのリファレンスガイド、採点の定義、ルーブリックの構造	https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/kit-rubrics-reference	ルーブリックのリファレンス	採点尺度の定義、ルーブリックの構成要素
Copilot Studio Kit の概要、Kit の機能	https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/kit-overview	Kit の概要	ルーブリックを含む、Kit のすべての機能を紹介する親ページ
11 のシナリオ検証テーマ、評価フレームワーク	https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/architecture/evaluation-frameworks	11 のシナリオ検証テーマ
評価の目的の定義、評価対象、評価範囲の設定	https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/evaluation-define-purpose	ページ全体
Eval Guidance Kit、チェックリストのドキュメント、フレームワークの PowerPoint	https://aka.ms/EvalGuidanceKit	Checklist、Framework、failure-log-template	GitHub PowerPnPGuidanceHub にリダイレクトされます
pass@k と pass^k の指標、非決定性の統計、0% pass@100 の解釈	https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents	pass@k、pass^k、機能評価のセクション	補足情報：Microsoft の非決定性に関するガイダンスを主な情報源とします
機能評価と回帰評価の違い、評価駆動開発	https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents	機能評価、回帰評価のセクション	10 ステップのプレイブックを補足する業界の背景情報
LLM-as-judge のキャリブレーション、位置バイアス、冗長性バイアス、自己強化バイアス	https://eugeneyan.com/writing/llm-evaluators/	バイアスとキャリブレーションのセクション	補足情報：バイアスの割合は Microsoft の情報源には記載されていません
批評のシャドーイング、判定プロンプトの設計、エラー分析の手法	https://hamel.dev/blog/posts/llm-judge/	判定プロンプトの設計、キャリブレーション	補足情報：LLM 判定手法の詳細
評価プラットフォーム、ツールの比較、Braintrust、LangSmith	https://www.braintrust.dev/articles/top-5-platforms-agent-evals-2025	プラットフォームの比較	補足情報：軽量なツールの参考情報
上記に明確に該当しない質問	主な情報源として https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/evaluation-overview を取得し、関連するナレッジベースのセクションで補足します		既定のフォールバック先は MS Learn です
フェッチのルール：

• 「Do NOT fetch.」の記載がない行は、必ずフェッチを試みてください。失敗した場合（404、タイムアウト、関連性のないコンテンツ）は、以下のナレッジベースを参照し、「フェッチ時にソースを利用できなかったため、ナレッジベースに基づいて回答しています」と明記してください。
• Microsoft のソースを優先します。 トピックが Microsoft と外部の両方のソースで扱われている場合は、Microsoft の内容を主な回答に使い、外部の内容は補足情報としてのみ使用してください。
• Microsoft の引用形式：「Per Microsoft's Eval Scenario Library:」、「Per the Triage Playbook:」、「Per MS Learn agent evaluation guidance:」
• 外部ソースの引用形式：「Additional industry context from [source]:」—必ず Microsoft の内容の後に記載してください。
• フェッチが失敗しても、回答を止めないでください。情報が不十分でも回答しないよりは適切です。
• 質問に関連するセクションだけを抽出してください。ページ全体を要約しないでください。

ステップ 2 — フェッチした内容とナレッジベースを使って回答する

フェッチした内容を、以下のナレッジベースと統合してください。10 ステップのプレイブックが方法論の中核です。Microsoft からフェッチした内容で詳細と Copilot Studio 固有の情報を補足し、その後、外部ソースで不足分を補ってください。

回答スタイルのルール — 例外なし：

• 回答は最大 3～5 文にしてください。冗長な説明、前置き、「良い質問ですね」は不要です。
• 明確で直接的な推奨を示してください。具体的な推奨をすぐに示さずに「場合によります」と言ってはいけません。
• 具体的な数値を示してください（「まず 20～50 件から始める」、「一致率が 60％未満のケースにフラグを立てる」、「各ケースにつき 3 回試行する」など）。
• エージェントのアーキテクチャ、リスクレベル、またはライフサイクルの段階によって回答が大きく変わる場合に限り、的を絞った確認質問を最大 1 つ行ってください。それ以外は、妥当な前提を置いて回答してください。
• 回答の末尾に、使用したソースを引用してください。

---

ナレッジベース

フェッチした内容で質問に答えられない場合や、フェッチした内容に追加情報を補う場合は、以下のセクションを主な参考資料として使用してください。

標準の方法論：10 ステップのプレイブック

中核となる方法論は skills/eval-guide/playbook.md の**「エージェント評価の実践ガイダンス：10 ステップのプレイブック」**です。以下の MS Learn ページは補足資料として使用し、中核とはしないでください。

1. 評価の取り組みを計画する — 評価の目的、5 つのリスク要因に基づくエージェントレベルのリスク区分、担当者の明確化。
2. 能力評価セットを構築する — 能力の各側面（正確性／正しさ、忠実性／根拠への準拠、関連性、スタイル／トーン、推論／ツール使用）ごとに 1 つのセットを作成します。ハルシネーションは、忠実性に関する能力の失敗です。
3. 信頼性と安全性の評価セットを構築する — 拒否、ポリシー、機微データ、プロンプトインジェクション、コンプライアンスのセットを個別に作成します。
4. 合格率の目標とゲートを定義する — 各セットに明示的な目標を設け、必須ゲートまたは努力目標を設定します。
5. 人による評価の入力を指定する — 評価基準、正解データ、模範回答、ソースと正解データの依存関係を用意します。
6. ベースラインを実行する — セットごと、ケースごとの結果を、タイムスタンプとエージェントのバージョンとともに記録します。
7. 反復して失敗を診断する — すべての失敗を、評価設定の問題かエージェント品質の問題のいずれかに分類し、失敗パターンのログを維持します。
8. 回帰テストスイート — 評価セットを回帰テスト用とゲート専用に分け、実行頻度とアラートを設定します。
9. 最適化ループ — 本番環境のシグナル → クラスター化 → 修正箇所の特定 → リリース → 回帰テストスイートで再評価。
10. 再利用可能なアセットを特定して保存する — 再利用できるセット、評価基準、パターンを、共有ライブラリの「必須」、「推奨」、または「任意」ティアに追加します。

補足となる MS Learn のライフサイクル資料： MS Learn の反復型フレームワークは、ライフサイクルや実行頻度に関する質問で引き続き役立ち、プレイブックにも対応しています。ただし、このツールキットで標準となる方法論ではありません。

リスクティア、ゲート、ワークブック、マニフェスト

• リスクティアはエージェントレベルで設定し、到達範囲、エラーの重大性、自律性／影響範囲、規制上のリスク、データの機密性という5つの要素を用います。リスクティアによって、目標、ゲートの厳格さ、必要なトラスト＆セーフティの網羅範囲、人によるレビューの要件が決まります。
• ハードゲートはデプロイ前に必ず通過する必要があり、ソフト目標は追跡対象ですが、ブロック要因にはなりません。
• 推測よりもワークブック／マニフェストを優先してください。タイプ、カテゴリ、メソッド、ゲート、目標、想定用途、実施頻度、人によるレビューの入力、ソース依存関係、グレーダー検証のメモ、再利用可能なアセットのフラグは、Copilot Studio のインポート CSV ではなく、Eval Suite Template のワークブックとマニフェストに記載します。

Step 9 の最適化ループと Step 10 の再利用可能なアセット

Step 9 では、本番環境のシグナルを改善につなげます。低評価（最も強いシグナル）、エスカレーション、手動オーバーライド、サポートチケット、定性的なフィードバックを収集 -> クラスタリング -> 修正箇所を決定（エージェントの設定／検索／ツール、評価ルーブリック／期待される回答、新しい評価ケースのいずれか） -> リリース -> Step 8 の回帰スイートで再評価します。本番環境での失敗に対応する評価ケースがない場合、それはカバレッジの不足を示すものであり、プロンプトに問題がある証拠ではありません。

Step 10 では、再利用可能なアセットを共有評価ライブラリに追加します。ティアは3つあります。必須（組織全体のデプロイゲート）、推奨（同じクラスのほとんどのエージェントに適用）、任意（関連する場合に利用）です。適した候補には、トラスト＆セーフティのセット、トーン／引用／拒否のルーブリック、失敗パターンのテンプレート、本番環境から得られたエッジケースなどがあります。

シナリオの種類

Microsoft の Eval Scenario Library では、シナリオは2つのカテゴリに分かれています。

5つのビジネス課題シナリオ（エージェントが実際のユーザー課題を解決するかをテストします）：

• 情報検索 — エージェントがナレッジソースから適切な情報を見つけて提供します。
• トラブルシューティング — エージェントが手順を案内しながらユーザーの問題を診断し、解決します。
• リクエストの送信 — エージェントがユーザーに代わってトランザクションリクエストを完了します。
• プロセスの案内 — エージェントが複数のステップからなるワークフローをユーザーに案内します。
• トリアージとルーティング — エージェントがリクエストを正しく分類し、適切な担当者に振り分けます。

9つの機能シナリオ（特定の能力を個別にテストします）：

• ナレッジのグラウンディング、ツール呼び出し、トリガーのルーティング、コンプライアンス、トラスト＆セーフティ／レッドチーミング、トーン、適切な失敗処理、回帰。

アンチパターン： データセットの80％以上をハッピーパスのケースに偏らせることです。Scenario Library によると、有意義なカバレッジを確保するには、ビジネス課題シナリオと機能シナリオのバランスを取る必要があります。目安として、ハッピーパスを約50％、エッジケースを30％、敵対的ケースを20％にしてください。

ソースライブラリの品質次元

Microsoft の Eval Scenario Library には、評価セットの設計に活用できる再利用可能な品質次元が5つあります。ただし、このツールキットでは、これらを主な計画成果物として扱わず、ワークブックのレジストリ行として記録します。

1. ポリシーの正確性 — エージェントはビジネスルールとポリシーに正しく従っていますか？
2. ソースの帰属 — エージェントは取得したドキュメントに基づいて主張し、出典を引用していますか？
3. パーソナライズ — エージェントはユーザーの状況や好みに応じて回答を調整していますか？
4. アクションの促進 — エージェントはユーザーが次のステップに進めるよう支援していますか？
5. プライバシー保護 — エージェントは機密情報の開示を避けていますか？

各品質次元は、キーワード一致、意味の比較、機能の利用、総合品質などのメソッドに対応付けることができます。ただし、選択するメソッドとガバナンスは、ワークブックレジストリ内の評価セットで管理します。

7 種類のテスト方法（Copilot Studio）

MS Learn のエージェント評価ガイダンスによると、7 種類のテスト方法でさまざまな評価ニーズに対応できます。

1. 全般的な品質 — 関連性、根拠の確かさ、完全性、回答の保留というサブディメンションにわたる LLM 判定評価です。自由形式の品質評価に使用します。合格率の目標は 80～90％です。
2. 意味の比較 — エージェントの回答と期待される回答の意味的類似性を評価します。意味は重要でも、正確な表現は問わない場合に使用します。
3. 機能の使用（UI では「ツールの使用」と表示） — エージェントが正しいツールを正しいパラメーターで呼び出したことを検証します。ツール呼び出しを伴うエージェント型ワークフローに使用します。
4. キーワード一致 — 特定のキーワードが含まれているか、含まれていないかを確認します。コンプライアンス、ポリシーの遵守、必須または禁止する内容の確認に使用します。
5. テキスト類似度 — 語句または埋め込みに基づく類似度をスコア化します。回答の表現が重要な場合に使用します。
6. 完全一致 — 文字列が厳密に一致するかを評価します。分類、ルーティングラベル、構造化出力に使用します。
7. カスタム — 評価手順とラベル付きの結果を指定して、独自の評価基準を定義します。構成要素：（1）評価手順 — 確認内容を説明する平易な言葉による評価基準（例：「回答は当社の人事エスカレーションポリシーに従っていますか？」）、（2）ラベル — 判定者が割り当てる名前付きの結果（例：「準拠」／「非準拠」。それぞれに合格または不合格を対応付けます）。単一回答と会話の両方のテストセットに対応します。キーワード一致や意味の比較では捉えられない判断が合否に必要な場合、たとえばコンプライアンス確認、トーンやブランドボイス、安全性ポリシー、分類の正確性などにカスタムを使用します。CSV インポートに関する注意： カスタムテストケースは CSV からインポートできません。Copilot Studio の評価 UI で直接作成してください。

評価アプローチ

MS Learn（common-evaluation-approaches）によると、テストのやり取りを生成するアプローチは 3 種類あります。

• エコー — ユーザー入力をそのまま再生し、出力を期待される結果と比較します。最も簡単で、リグレッションテストに適しています。
• 履歴の再生 — 実際の本番環境の会話ログを評価入力として使用します。本番環境に即したカバレッジを得るのに最適です。
• 合成ペルソナ — 多様なテストのやり取りを作成するため、さまざまなユーザーペルソナをシミュレーションして生成します。本番環境のログが限られている場合に、カバレッジを広げるのに最適です。

スコアの解釈とトリアージ（Triage Playbook）

Triage Playbook に従い、スコアの解釈には 4 層のフレームワークを適用します。

Layer 1 — スコアの解釈： リスクレベル、ワークブックで定義されたゲート、評価者の検証に関する注意事項、および準備状況の判断ツリーを適用します。

• SHIP — すべてのハードゲートに合格し、ソフト目標も許容範囲内で、担当者が残存リスクを受け入れています。
• ITERATE — 一部の評価セットがソフト目標に達していないか、後退を示しています。対象を絞った修正が必要です。
• BLOCK — ハードゲートに不合格です。特に信頼性と安全性に関するゲートに不合格の場合は、総合合格率にかかわらずリリースしないでください。

Layer 2 — 失敗のトリアージ： スコアが低い場合は、エージェントを責める前に、まず 5 つの質問からなる評価の検証（評価自体は正しいか？）を実施します。次に、6 つの領域にまたがる 26 の診断質問を適用して、根本原因を特定します。7 つの評価設定の失敗サブタイプで、よくある評価者やデータセットのバグをカバーします。

Layer 3 — 修正の対応付け： 失敗した各評価セットを、具体的な修正箇所に対応付けます。指示の予算の問題に注意してください。ある失敗パターンを修正するために指示を追加すると、別のパターンの性能が低下することがあります。

Layer 4 — パターン分析： 失敗の集中（特定のシナリオタイプに失敗が偏っていないか）、シグナル間の相関（文書化された 7 つのシグナル間パターン）、および経時的な傾向を確認します。

Step 7 の主要な分類： すべての失敗は、次のいずれか 1 つに分類されます。（1）評価設定の問題 — 応答は許容できるものであり、評価、正解データ、ルーブリック、または手法に誤りがある、または（2）エージェント品質の問題 — 評価によって実際の問題が検出された。Triage Playbook の「評価設定」「エージェント構成」「プラットフォームの制約」というカテゴリは、これら 2 つの分類に対応付けられた、運用上有用なサブタイプです。必ず最初に評価設定の問題を除外してください。初期の「失敗」の多くは、エージェントのバグではなく、評価者やデータセットのバグです。

非決定性

Triage Playbook によると、エージェントの動作は非決定的です。各ケースについて最低 3 回の試行を実施してください。実行間のスコアのばらつきが +/-5% であれば正常です。ばらつきが +/-10% 以上の場合は、評価が不安定なのか、エージェントに実際の不安定性があるのかを調査する必要があります。

Anthropic による業界の補足情報： pass@k（「k 回の実行で少なくとも 1 回成功」）と pass^k（「k 回の実行すべてで成功」）は、規模が大きくなると大きく乖離します。k=10 で試行ごとの成功率が 70% の場合、pass@k は約 97%、pass^k は約 3% です。どちらの指標を報告するかによって、同じエージェントが非常に優秀にも、壊滅的にも見えます。顧客向けエージェントでは、pass^k で評価するのが適切です。pass@100 が 0% になる場合、ほとんどはエージェントの問題ではなくタスク仕様の問題です。モデルを責める前に、タスク定義を修正してください。

レッドチームテスト

Microsoft の Eval Scenario Library によると、レッドチームテストでは Probe-Measure-Harden フレームワークを使用します。

1. Probe（探査） — プロンプトインジェクション、XPIA（クロスプロンプトインジェクション攻撃）、エンコーディング攻撃、ロールプレイを利用した悪用など、敵対的な攻撃を実行します。
2. Measure（測定） — カテゴリごとに攻撃成功率（ASR）指標を追跡します。
3. Harden（強化） — 脆弱性を修正し、ガードレールを追加して、再度探査します。

レッドチームのしきい値： 有害コンテンツでは ASR <2%、PII の漏えいでは <1%、ジェイルブレイクでは <5% を目指します。レッドチームテストを CI/CD に組み込んでください。単発のテストでは、プロンプトの変更やモデルのアップグレードによる後退を見逃します。

複数ターンにわたる敵対的パターン： デプロイ済みの対話型エージェントには、単一ターンのテストでは不十分です。次の 3 つの攻撃パターンには複数ターンの評価が必要です。（1）コンテキスト操作 — ターンを重ねるごとに要求を徐々に変化させる、（2）権限昇格 — 会話の中で偽の管理者権限の主張を持ち込む、（3）ロールプレイのエスカレーション — 早い段階で架空の設定を確立し、その後エスカレートさせる。どの評価スイートにも、複数ターンにわたる敵対的シナリオを少なくとも 2～3 件含めてください。

採点者の種類

MS Learn（common-evaluation-approaches）によると、採点者は次の3つのカテゴリに分けられます。

• コードベース／決定論的な採点者（正規表現、文字列照合、JSON スキーマ検証、長さチェック）：高速で低コスト、判定も明確です。まずこれらを実行してください。決定論的なチェックで答えが得られる場合は、LLM ジャッジに頼らないでください。
• LLM ジャッジの採点者（LLM が出力を書面の基準に照らして採点）：トーン、完全性、事実に基づいているか、関連性など、判断を要する品質チェックに使用します。採点者のコードを書く前に、基準を平易な言葉で記述してください。
• 人間の採点者：最も時間がかかりますが、品質も最高です。自動採点者の判定が専門家の人間と少なくとも80％一致すること（Cohenのκ > 0.6）を検証する較正にのみ使用してください。

採点の階層（低コストから高コストの順）： まずコードベースのチェックを実行し、合格したケースに対してLLMジャッジを実行してから、較正用のサンプルを人間がレビューします。Scenario Libraryによると、4つの評価方法（キーワード一致、意味の比較、機能の利用、全般的な品質）は、これらの採点者カテゴリに対応します。

較正のしきい値： LLMジャッジと人間の専門家の一致率が80％未満（κ < 0.6）の場合、基準が曖昧です。スコアを信頼する前に、基準を書き直してください。

データセットの設計

Eval Scenario Libraryに従い、データセットの構成には eval-set-template.md を使用してください。エージェントのプロファイルからケースを生成するには、eval-generation-prompt.md テンプレートを使用してください。

• 対象を絞ったタスクでは、まず20～50件のケースから始めます。Scenario Libraryに従い、機能のシナリオに広げる前に、関連するビジネス上の課題のシナリオをすべて網羅してください。
• ケースを作成する前に、エージェントプロファイルテンプレート（agent-profile-template.yaml）を使用してスコープを定義してください。
• 本番環境のインシデントはすべて、24時間以内にデータセットのケースにしてください。
• データセットは継続的に更新する成果物です。定期実行される固定データセットは回帰テストセットとなり、マイルストーン時のみ使用する信頼性と安全性のセットはゲート専用セットとなります。
• 合格率が100％に達したら、データセットは飽和しています。回帰テストスイートに昇格させ、より難しいケースを作成してください。

CSVと採点の規約： Copilot Studioのインポート用CSVは、列が正確に2つ（Question、Expected response）である必要があります。インポート後にCopilot StudioのUIでテスト方法を割り当ててください。set_type、category、method、gate、target、regression class、human-review flag、source/ground-truth provenanceは、マニフェスト（.docxレポートとstage-N-data.json）に保持してください。スイート全体で採点方法を統一してください。ほとんどのエージェントでは、二値の合否をデフォルトにするのが適切です。

基準の記述

• 2人がそれぞれ独立して読んでも、合格か不合格かで一致する程度に基準を具体的にしてください。Triage Playbookのレイヤー2によると、曖昧な基準は評価設定の失敗の主なサブタイプです。
• 悪い例：「回答が役に立つ」。良い例：「回答が300文字未満で、返金ポリシーの名称を挙げている」。
• コードを書く前に基準を記述してください。テスト可能な基準を記述できない場合、エージェントが何をすべきかを理解できていません。
• スコアごとに1つの側面を評価します。 正確性、トーン、簡潔さを1つのスコアにまとめないでください。複数の側面をまとめた複合スコアでは、リグレッションが見えなくなります。
• リッカート尺度（1～5）は避けてください。 合否の二値評価を使用します。二値評価によって基準が明確になります。複数段階の評価が必要な場合は、最大3段階（不合格／部分合格／合格）にしてください。
• 採点者のプロンプトにはバージョンを付けてください。 採点者を変更すると、スコアを比較できなくなります。データセットのバージョンと併せて、採点者のバージョンも記録してください。

評価主導の開発

10ステップのプレイブックに沿って、評価はエージェントの構築前にステップ1 — 評価の取り組みを計画するから始めます。

• エージェントが目標を達成する前に、目標とする動作を定義する能力評価セットと信頼性・安全性評価セットを作成します（ステップ2～3）。
• スコアを解釈する前に、目標値とハードゲート／ソフトゲートを定義します（ステップ4）。
• ベースラインを実行します（ステップ6）。新しい能力評価セットでスコアが低くなるのは想定どおりであり、有益です。
• ハードゲートを通過し、リリース基準を満たすまでステップ7で反復します。その後もステップ8の回帰モニタリングを継続します。

アンチパターン： 機能を構築した後に評価を作成することです。そうすると、意図していたものではなく、構築したものに合わせて評価が調整されてしまいます。

トランスクリプトの読み取りとエラー分析

ステップ7およびトリアージプレイブック（レイヤー2）に沿って、手動で検証していないスコアを決して信用しないでください。最初に確認すべきなのは、失敗が評価設定の問題かどうかです。テストセットは正しいですか？ 評価者は適切なものを測定していますか？ 期待される回答は本当に正しいですか？ エージェントには適切なコンテキストが与えられていますか？ 評価環境は本番環境と一致していますか？

失敗分析のための軸索コーディングのプロセス：

1. 評価を実行し、すべての失敗を収集します。
2. それぞれの失敗を読み、根本原因を一文でラベル付けします。
3. ラベルを3～5つのカテゴリに分類します（まずステップ7の分類項目を使い、次にトリアージプレイブックの診断領域を運用上のサブタイプとして使います）。
4. カテゴリごとの頻度を数え、降順に並べます。
5. 最も頻度の高いカテゴリから修正します。再実行して、繰り返します。

ステップ7に沿って、必ず「評価設定の問題」をカテゴリに含めてください。新しい評価における失敗の多くは、エージェントの品質の問題ではなく、評価者、ルーブリック、古くなった正解データ、マニフェストのバグが原因です。

Hamel Husain による業界の追加情報： 軸索コーディングの手法と「AI エンジニアリングで最も ROI の高い活動」という考え方は、Hamel Husain のエラー分析の取り組みに由来します。彼の重要な洞察は、ほとんどの実務者が分類を省略して「プロンプトを修正する」ことに飛びつき、構造的なパターンを見落としているというものです。

ツール呼び出しの評価

Eval Scenario Library の Tool Invocations 機能シナリオと、MS Learn の Capability Use テスト手法に沿って、次の点を確認します。

• 各ツール呼び出しで確認する3つの質問： （1）適切なツールでしたか？ （2）引数は正しく、すべて揃っていましたか？ （3）その呼び出しは必要でしたか？
• ツール呼び出しのシーケンスを厳密に採点しないでください。経路ではなく、結果を評価します。エージェントが異なるツールのシーケンスで正解にたどり着いた場合も、合格とするべきです。
• 不要なツール呼び出しは、本番環境でコストとレイテンシの問題になります。評価で検出してください。

マルチターン評価と軌跡評価

MS Learn の評価アプローチに沿って、マルチターンのワークフローでは、ターン単位ではなく会話単位の評価が必要です。

• 軌跡のスコアリング： 一連のステップを全体として評価します。エージェントは妥当な最短経路をたどりましたか？ 途中のエラーから回復できましたか？
• 環境状態の検証： 正解の根拠は外部環境の状態であり、エージェントの主張ではありません。予約エージェントは、データベースに予約が存在すれば合格です。
• 複合的なエラー： ステップ2での誤りが、最終出力に現れないことがあります。各ステップで詳細なログを取りながら評価を実行してください。
• ステートフルな対話の評価： ターン単位の合格率が90％でも、会話単位の失敗率が40％であることを見逃す場合があります。

エージェント型ワークフローの評価

MS Learn の評価フレームワーク（11のシナリオ検証テーマ）に沿って、次の点を確認します。

• 各コンポーネントをまず個別にテストしてから、エンドツーエンドで評価します。パイプラインでは、コンポーネントレベルの失敗が積み重なります。
• オーケストレーションレベルの失敗は、最も見落とされやすい失敗モードです。各コンポーネントのスコアが個別には95％のパイプラインでも、エンドツーエンドでは40～60％の確率で失敗することがあります。
• 評価にはシミュレーション環境を使用します。本番システムに対して評価を実行しないでください。
• パイプラインの各ステップでバリデーターを使い、中間出力を監視します。

シンプルなQ&Aとマルチステップエージェント：評価で何が変わるか

エージェントの複雑さによって、評価のアプローチは大きく異なります。

評価軸	シンプルなQ&Aエージェント	マルチステップ／エージェント型ワークフロー
主な指標	応答の正確さ（意味の比較、総合品質）	タスクの完了度 — エンドツーエンドで作業を完了できたか
採点単位	1ターン：1つの入力と1つの出力	会話または軌跡：一連のステップ全体
評価セットで重視する点	根拠に基づく回答とポリシーの正確さ	アクションの実行可能性、ツール呼び出し、Q&Aの正確さ
テスト方法の組み合わせ	意味の比較と総合品質を重視	ツール呼び出しには機能の活用、中間チェックポイントにはキーワード一致を追加
注視すべき失敗モード	誤答、ハルシネーション、拒否	エラーの連鎖、誤ったツールの選択、不要なステップ、部分的な完了
エッジケース	曖昧なクエリ、対象範囲外の質問	ワークフロー途中の失敗、ツールのタイムアウト、会話途中でのユーザーによる訂正
評価の複雑さ	低 — 決定論的な入力／出力のペアが有効	高 — 中間ステップと最終結果の両方を評価する必要がある

実践的なガイダンス：

• エージェント型ワークフローでも、まずはQ&A形式の評価から始めます。 エージェントがたどる経路を評価する前に、最終回答の正しさを確認します。正しいツールを使っていても、回答が間違っていれば誤りです。
• 応答品質が安定してから、ツール呼び出しの評価（機能の活用）を追加します。 シナリオライブラリによると、ツール呼び出しのテストでは、正しいツール、正しい引数、呼び出しの必要性という3点を確認します。
• 経路ではなく結果を採点します。 有効なツール呼び出しの手順が2通りあっても、同じ正しい結果が得られることがあります。評価シナリオライブラリにあるとおり、ツール呼び出しの手順を厳格に採点しないでください。
• オーケストレーションのギャップに注意します。 MS Learnの評価フレームワークによると、個々のコンポーネントがそれぞれ95％のスコアでも、エンドツーエンドでは40〜60％の確率で失敗することがあります。ターン単位だけでなく、必ず会話単位の評価を実行します。
• テストケースを多めに用意します。 Q&Aエージェントでは、有意な傾向を把握するために20〜30件のケースが必要になる場合があります。3つ以上のツールを使うマルチステップワークフローでは、ツールの組み合わせや失敗からの回復経路を網羅するために50〜100件が必要です。

評価カバレッジのスイスチーズモデル

どの評価方法も、すべての失敗を検出できるわけではありません。評価シナリオライブラリの4つの評価方法と、トリアージプレイブックの多層的なアプローチに基づくと、次のようになります。

• コードベースの採点器は構造上の失敗を検出できますが、意味上の失敗は見逃します。
• LLM評価者は意味上の失敗を検出できますが、体系的なバイアスがあります。
• 人によるレビューは微妙な判断の失敗を検出できますが、全件を網羅するには時間がかかりすぎます。
• 本番環境のモニタリングは、実環境での分布に起因する失敗を検出します。
• 4つすべてを重ねて適用します。 まず決定論的なチェック（最も低コスト）を実行し、次にLLM評価者、続いて人によるキャリブレーションを行い、最後に本番環境のモニタリングを実施します。

LLMを評価者として使う場合のキャリブレーション

MS Learnの総合品質テスト方法によると、LLM評価者は関連性、根拠性、完全性、回答の保留という下位の評価軸にわたって評価します。これらの定義済みの評価軸に照らして評価者をキャリブレーションします。

Eugene Yanによる業界の補足情報（バイアスデータ）：

• 位置バイアス： GPT-3.5は50％の確率で最初の選択肢を優先し、Claude-v1は70％の確率で優先しました。評価では両方の順序を試して、このバイアスを軽減します。
• 自己強化バイアス： GPT-4は自身の出力を10％高く評価し、Claude-v1は自身の出力を25％高く評価します。モデル自身の出力を、そのモデルで評価しないでください。
• 冗長性バイアス： 両モデルとも、90％を超える確率で長い応答を好みました。評価者へのプロンプトには、長さに依存しないよう明示的に指示を含めます。

Hamel Husainによる業界の補足情報（批評のシャドーイング）： LLM評価者を一から構築する場合は、7段階の批評シャドーイング手法を使います：（1）専門家を1名特定する、（2）多様なデータセットを作成する、（3）記述式の批評を添えて合格／不合格の二択評価を収集する、（4）明らかな誤りを修正する、（5）専門家の例を使い、評価者向けプロンプトを反復的に作成する、（6）評価が食い違うケースをエラー分析する、（7）特定の失敗モード向けに特化した評価者を構築する。本番で使用する前に、分野の専門家との一致率90％超を目指します。

ナレッジグラウンディング（RAG エージェント向け）

Eval Scenario Library のナレッジグラウンディングに関するガイダンスに基づくと、次のとおりです。

• ナレッジグラウンディングスコアは、各事実に関する主張が検索されたコンテキストによって裏付けられているかを測定します。
• グラウンディングスコアが 75％の場合、主張のおよそ 4 件に 1 件はドキュメントから出典をたどれない可能性があります。重大な影響を伴う事実確認タスクでは、しきい値を 90％以上に設定してください。
• グラウンディングスコアが低い場合、ほぼ常に問題は生成ステップではなく検索ステップにあります。プロンプトを調整する前に、チャンク分割と検索を修正してください。

本番環境での継続的な改善

10 ステップのプレイブックのステップ 9 に基づくと、評価はリリース前の関門ではなく、継続的な最適化ループです。

• 評価を CI/CD に統合します。システムプロンプト、ツール定義、またはエージェントの動作を変更するすべての PR で、完全なテストスイートを実行します。
• 本番環境のシグナルは、低評価（最も重要なシグナル）、エスカレーション、手動による上書き、サポートチケット、定性的なフィードバックから収集され、パターンごとにクラスタリングされます。
• 最適化ループ： 本番環境のシグナル -> クラスタ -> 修正箇所の決定（エージェント設定／検索／ツール、評価基準／期待される回答、または新たな評価範囲） -> リリース -> ステップ 8 の回帰テストスイートで再評価します。
• 評価だけでなく、モニタリングも併せてリリースします。評価で確認できるのは、テストケースでエージェントが機能したことです。モニタリングでは、実際のユーザー入力でも機能していることを確認できます。

エージェントが評価に合格しても本番環境で失敗する場合： トリアージプレイブックによると、これはほぼ常にデータ分布の不一致です。最近の本番環境での失敗を 20 件抽出してください。現在の評価データセットで評価した場合に失敗するケースがあるか確認します。該当するケースがなければ、改善すべきなのはプロンプトではなく、本番環境のケースを追加したデータセットです。

結果の解釈

トリアージプレイブックの準備状況の判定フローに基づくと、次のとおりです。

• SHIP：すべての必須ゲートに合格し、ソフトターゲットの未達が承認・記録されている状態です。
• ITERATE：能力セットが目標を達成していない、または本番環境のパターンに修正が必要な状態です。ステップ 7 の失敗トリアージを使って原因を診断します。
• BLOCK：集計合格率にかかわらず、必須ゲートに 1 つでも不合格がある状態です。特に信頼と安全に関するゲートは重視してください。

トリアージプレイブックのレイヤー 4（パターン分析）に基づき、特定のシナリオタイプへの失敗の集中、シグナル間の相関、時間経過に伴う傾向を調べます。評価者の判定が直感と異なる場合は調査してください。評価者が間違っている（基準を修正する）か、直感が間違っている（メンタルモデルを更新する）かのどちらかです。

能力セット、信頼と安全のセット、回帰セット、ゲート専用セット

• 能力評価セットは、正確性／正しさ、忠実性／根拠性、関連性、スタイル／トーン、推論／ツール使用のうち、1 つの能力軸を測定します。低い合格率から始まります。新しい能力セットでの合格率 30％は、失敗ではなく有用なシグナルです。
• 信頼と安全の評価セットは、拒否／ポリシー／機密データ／プロンプトインジェクション／コンプライアンスに関する独立したセットで、通常は必須ゲートとして扱われます。
• 回帰セットは、ドリフトを検出するため定期的に実行します。ほぼすべての能力セットに、信頼と安全のセットから絞り込んだ一部を加えます。
• ゲート専用セットは、マイルストーンごとに実行します。広範な信頼と安全のチェックの多くがこれに該当します。能力セットが飽和したら、代表的なケースを回帰テストに移し、より難しい能力ケースを作成してください。

評価ツール（補足）

ツールに関する質問では、本番環境の Copilot エージェント向けに Microsoft の Copilot Studio 評価機能を第一に推奨します。サードパーティのプラットフォームが必要なチームには、次の選択肢があります。

• Braintrust： 本番環境のエージェントに適した、汎用性の高い既定の選択肢です。無料プランでは月 100 万スパンを処理できます。
• LangSmith： すでに LangChain を使用している場合に最適です。ネイティブトレーシングに対応しています。
• Langfuse： セルフホスト型で、データ主権を重視する環境に最適です。MIT ライセンスです。
• 重要な注意点： 評価基準の作成とスコアリングを人間による調整なしで自動化するツールには注意してください。ツールは人間によるレビューをワークフローに組み込める必要があります。

---

スキルの振り分け — 関連スキルを提案するタイミング

質問に回答した後、ユーザーが関連する eval スキルを実行すると役立つかどうかを確認してください。該当する場合は、回答の最後に1行の推奨文を追加してください。

質問の内容...	提案するスキル	追加する一文
eval プランの作成、または評価対象の範囲設定	/eval-suite-planner	"Eval Suite Template の入力済みワークブックを作成するには、/eval-suite-planner を実行してください。"
テストケースの生成、CSV データセットの作成、eval セットの構築	/eval-generator	"すぐにインポートできるテストケースの CSV を生成するには、/eval-generator を実行してください。"
スコアの解釈、結果の確認、合格率の把握	/eval-result-interpreter	"特定の eval 結果を解釈するには、その結果を /eval-result-interpreter に貼り付けてください。"
失敗のデバッグ、低スコアのトリアージ、根本原因分析、改善策	/eval-triage-and-improvement	"診断フレームワーク全体を使って特定の失敗をトリアージするには、/eval-triage-and-improvement を実行してください。"
eval とは何か、eval が重要な理由、関係者への eval の説明	/eval-guide	"関係者と共有できる eval の一貫した解説については、/eval-guide を実行してください。"

ルール：

• 1つの回答につき、提案するスキルは1つだけにしてください。最も関連性の高いものを選んでください。
• ユーザーの質問が、関連スキルで実行できるアクションに明確に該当する場合にのみ提案してください。eval-faq だけで十分に対応できる、純粋に方法論に関する質問では振り分けを提案しないでください。
• /eval-faq は提案しないでください（これは現在のスキルであり、ユーザーはすでに利用しています）。

---

呼び出し例

/eval-faq What eval scenarios should I use for a RAG agent?
/eval-faq How do I interpret a 75% knowledge grounding score?
/eval-faq What is the difference between business-problem and capability scenarios?
/eval-faq When should I use a model-graded grader instead of a deterministic one?
/eval-faq What makes a good adversarial test case?
/eval-faq How many cases do I need in a dataset to get meaningful signal?
/eval-faq My eval passes 100% on first run — is that good?
/eval-faq How do I write a good criterion for a model-graded grader?
/eval-faq What should I do when a grader disagrees with my gut feeling about an output?
/eval-faq How do I handle non-determinism in my eval results?
/eval-faq My agent makes tool calls — how do I eval those?
/eval-faq I suspect my grader is wrong — how do I debug it?
/eval-faq What should I eval in production after I ship?
/eval-faq Should I use pass@k or pass^k for my agent?
/eval-faq How do I calibrate my LLM-as-judge grader?
/eval-faq When do I stop adding eval cases and just ship?
/eval-faq My agent finds a different tool sequence than I expected — is that a failure?
/eval-faq How do I know if my grader is actually measuring what I think it is?
/eval-faq What is the difference between a capability eval and a regression suite?
/eval-faq How do I eval a multi-turn conversational agent?
/eval-faq What eval platform or tool should I use?
/eval-faq My agent passes evals but fails in production — why?
/eval-faq How do I score intermediate steps in a multi-step agent?
/eval-faq How is evaluating a multi-step workflow different from a simple Q&A agent?
/eval-faq What does 0% pass@100 mean — is my agent broken?
/eval-faq How do I avoid LLM judge bias in my grader?
/eval-faq Which eval sets should I include?
/eval-faq What is the Probe-Measure-Harden red-teaming framework?
/eval-faq What are the 7 test methods in Copilot Studio?
/eval-faq How do I use the Triage Playbook to debug failing scores?
/eval-faq How does the MS Learn iterative framework relate to the 10-step playbook?
/eval-faq What are the 3 root cause types for eval failures?
/eval-faq How do I decide between SHIP, ITERATE, and BLOCK?
/eval-faq What red-team ASR thresholds should I target?
/eval-faq How do I generate eval cases from a prompt template?
/eval-faq What is the critique shadowing methodology for building LLM judges?
/eval-faq Should I use a 1-5 scale or pass/fail for my LLM judge?
/eval-faq How do I continuously red-team my agent in CI/CD?
/eval-faq How do I systematically analyze eval failures to find patterns?
/eval-faq How do I know if my eval is too easy?
/eval-faq How do I write an LLM grader prompt that actually works?
/eval-faq Should I score factuality and tone in the same eval criterion?
/eval-faq When should I use the Custom test method instead of General Quality?
/eval-faq How do I set up a Custom test method for compliance checking?