eval-result-interpreter

目的

このスキルは、評価結果（Copilot Studio の評価 CSV ファイル、貼り付けた要約、または結果を平易な英語で説明したもの）を受け取り、構造化されたトリアージレポートを作成します。運用ワークフロー「計画 → 生成 → 実行 → 解釈」における、単独で利用できる Interpret スキルです。10 ステップのプレイブックでは、**ベースライン（ステップ 6）**を読み取り、**診断（ステップ 7）**を進め、ステップ 9 の最適化ループを設計します。出力から、リリースすべきか、何が壊れたのか、なぜ壊れたのか、何を最初に修正すべきかが分かります。

このスキルは、Practical Guidance on Agent Evaluation: a 10-step playbookに基づいています。ステップ 6 を使ってエージェントのバージョンとタイムスタンプを含むベースライン結果を読み取り、ステップ 7 で失敗を評価設定の問題とエージェントの品質の問題に分類し、ステップ 9 で本番環境のフィードバックループを定義します。MS Learn の評価リソースも引き続き参考になりますが、標準的な方法論は 10 ステップのプレイブックです。

ナレッジソース： このスキルの分析フレームワークは、10 ステップのプレイブックに加え、Microsoft の Triage & Improvement Playbook による診断（SHIP／ITERATE／BLOCK ゲートの解釈、失敗の検証、修正策の対応付け、パターン分析）に基づいています。

このスキルと eval-triage-and-improvement の使い分け

この 2 つのスキルは同じトリアージフレームワークを共有していますが、異なる作業モードに対応しています。

eval-result-interpreter を使う場合…	eval-triage-and-improvement を使う場合…
CSV ファイルや具体的な結果があり、一度で完結する構造化レポートが必要な場合	診断を段階的に進める対話型のガイダンスが必要な場合
結果を初めて確認する段階で、判定と優先アクションをすばやく知りたい場合	継続的な改善ループに取り組み、修正、再実行、再トリアージを行う場合
顧客に提出できる成果物（.docx のトリアージレポート）が必要な場合	特定の評価セットの失敗（例：「誤ったツールが呼び出される — 次に何をすべきか？」）に対する詳細な修正支援が必要な場合
評価実行が比較的単純な場合（失敗が 20 件未満）	失敗が多数あり（15 件以上）、調査する項目の優先順位付けが必要な場合
アクティビティマップ／結果比較ツールの推奨をその場で確認したい場合	プレイブックの実例や、より詳しい診断手順が必要な場合

迷った場合： まず eval-result-interpreter で構造化レポートを作成し、修正の実施に対する対話型の支援が必要になったら eval-triage-and-improvement に切り替えてください。

手順

/eval-result-interpreter <results> として呼び出された場合、入力を解析し、以下の出力を生成します。次のいずれの入力形式も受け付けます。

形式 1 — Copilot Studio CSV ファイル（主な形式）

ユーザーが Copilot Studio エージェント評価からエクスポートした CSV のファイルパスを指定します。CSV には次の列があります。

列	説明
question	エージェントに送信されたテストケースの入力
expectedResponse	期待される回答（一般品質テストでは空の場合があります）
actualResponse	エージェントの回答全文
testMethodType_1	使用されたテスト方法（例：GeneralQuality、CompareMeaning、KeywordMatch、ToolUse、ExactMatch、Custom）
result_1	合格または不合格
passingScore_1	合格基準のスコア（空の場合があります）
explanation_1	判定に対する採点者の理由

1 行に複数のテスト方法が含まれる場合があります。例：testMethodType_2、result_2、passingScore_2、explanation_2 など。

ユーザーがファイルパスを指定した場合は、CSV を読み込んで解析します。合格数と不合格数の合計、およびテスト方法ごとの数を集計します。

形式 2 — プレーンテキストの概要

貼り付けられた合格／不合格数、不合格の一覧、または結果の説明です。

形式 3 — マニフェスト／方法論のメタデータ（推奨。精度が向上します）

マニフェストのメタデータがある場合は、CSV のファイル名や質問文から推測するのではなく、ジェネレーターが出力したマニフェスト情報、つまり付属の .docx レポートとダッシュボードの stage-N-data.json を優先します。これを使用して、各行または各セットを set_type（capability または trust_safety）、カテゴリ／ディメンション、テスト方法、ゲートタイプ、合格率の目標、回帰分類、人によるレビューの要否、ソース／正解データの出所に対応付けます。「セットのメタデータとゲートの解釈には、マニフェストを使用しています。」と明記してください。

ワークブック／マニフェストがない場合は、CSV のファイル名を優先し、それもなければ質問文を参照します。何を推測したかを明記し、ゲートのステータスは「オーナーによる確認が必要」としてください。

利用可能な詳細情報に応じて対応してください。入力情報が少ない場合は、何を仮定したかを明記します。追加情報を求めず、提供された情報をもとに最善のトリアージを行ってください。

---

出力構成

0. トリアージ前のインフラストラクチャ確認（トリアージプレイブックに従う）

不合格を分析する前に、評価実行中にインフラストラクチャが正常だったか確認します。次のいずれかに問題があった場合、該当するケースはエージェントの不合格ではなく、インフラストラクチャによるブロックとして扱います。

• すべてのナレッジソースにアクセスでき、インデックス作成が完了していましたか？
• API バックエンドでエラー、タイムアウト、またはレート制限が発生しましたか？
• 実行中、認証トークンは有効でしたか？
• 評価環境は意図した構成と一致していましたか？

入力からインフラストラクチャの稼働状況を判断できない場合は、次のように記載します。「この入力からはインフラストラクチャの稼働状況を確認できません。分析を続行します。不合格の結果に一貫性がない場合は、すべてのナレッジソースと API にアクセスできることを確認してから再実行してください。」

1. ベースラインスコアの概要（ステップ 6）

結果を解析し、次の内容を出力します。

指標	値
テストケースの合計	X
合格	X
不合格	X
全体の合格率	X%
使用されたテスト方法	GeneralQuality、CompareMeaning など
ベースラインのタイムスタンプ／エージェントのバージョン	入力にあればその値、なければ「未提供」

CSV の 1 行に複数のテスト方法が含まれている場合は、方法ごとの合格率も報告します。

次に、評価セットを能力と信頼性と安全性に分けて報告します。set_type、カテゴリ、テスト方法、ゲートタイプ、合格率の目標、回帰分類、データの出所には、マニフェストのメタデータを優先して使用します。各セットについて、次の表を使用します。

評価セット	セットタイプ	カテゴリ／ディメンション	テスト方法	回帰分類	目標	実績	ゲートタイプ	ゲートのステータス
X	capability / trust_safety	X	X	regression / gate-only / both	X%	X%	hard / soft	PASS / MISS

能力と信頼性と安全性は、分けて報告してください。信頼性と安全性のカテゴリは guardrails、out_of_scope、sensitive_data、prompt_injection、compliance です。ハルシネーションは信頼性と安全性の不合格ではなく、忠実性／根拠性に関する能力の不合格です。 2. 判定 — ゲートベースの SHIP／ITERATE／BLOCK 判定（D5）

集計合格率ではなく、マニフェスト内のセットごとのゲートに基づいて判定します。各評価セットについて、マニフェストに記載があれば、合格率の目標値とゲートタイプを確認してください。

• ハードゲート — デプロイ前に合格する必要があります。ハードゲートに不合格が1つでもある場合、エージェントは SHIP できません。
• ソフト目標 — 追跡して改善しますが、それだけでブロックするものではありません。

次のゲートベースの判定ルールを適用してください。

ANY hard gate missed?
    YES -> cannot SHIP.
           Trust & safety hard-gate miss -> usually BLOCK.
           Deployment-critical capability hard-gate miss -> BLOCK or ITERATE based on severity and owner risk tolerance and gate policy.
           Other hard-gate miss -> ITERATE until fixed.
    NO  ->
        ANY soft target missed?
            YES -> ITERATE: track the gap and fix in priority order, but it is not blocking by itself.
            NO  -> SHIP, assuming human review agrees coverage is sufficient.

各セットの実際の合格率と目標値、およびハード／ソフトのゲートステータスを報告してください。集計合格率が誤解を招く場合は明示してください。集計合格率が高くても、ハードな信頼性・安全性ゲートに不合格なら SHIP にはなりません。

目標値の厳しさや重大度を解釈する際は、リスク層（エージェントレベル：到達範囲、エラーの重大性、自律性／影響範囲、規制上のリスク、データの機密性）を考慮してください。ゲート判定の情報源として、ワークブックレジストリの評価セットのカテゴリ、ゲートタイプ、目標値、想定用途、実施頻度、評価者の検証メモを使用してください。

ワークブック／マニフェストがない場合は、代替手段として、CSV ファイル名または質問文のみからセットのグループ分け、ゲートタイプ、目標値を推定してください。次の文言を記載してください："No workbook or manifest provided — gate status inferred and should be reviewed by the owner."

判定を目立つように記載してください。

• "Verdict: SHIP." — すべてのハードゲートに合格し、ソフト目標も許容可能であるか、オーナーが明示的に承認しています。
• "Verdict: ITERATE." — ブロックとなるハードゲートの不合格はありませんが、1つ以上のソフト目標またはブロック対象ではないハードゲートについて、確信度を高めるための修正が必要です。
• "Verdict: BLOCK." — ハードな信頼性・安全性ゲート、またはデプロイに不可欠なその他のハードゲートに不合格です。

合格率が100%の場合："A 100% pass rate is a red flag — your eval is likely too easy. Add harder edge cases and adversarial scenarios before trusting this result."

3. 失敗のトリアージ — Triage Playbook のレイヤー2に従う

失敗したテストケース（または類似した失敗のクラスター）ごとに、エージェントを原因と決めつける前に、まず Playbook の5つの質問からなる評価検証手順を適用してください。

#	診断の質問	YES の場合 -> 根本原因
1	エージェントの実際の応答は許容できますか（実際のユーザーは満足しますか）？	評価設定の問題 — 評価者または期待値が誤っています
2	期待される回答は現在も最新かつ正確ですか？	NO の場合 -> 評価設定の問題 — 期待される回答が古くなっています
3	テストケースは現実的なユーザー入力を表していますか？	NO の場合 -> 評価設定の問題 — テストケースが現実的ではありません
4	妥当な別の回答も正解になり得るのに、評価者が不合格にしている可能性はありますか？	評価設定の問題 — 評価者の判定基準が厳しすぎます
5	テスト方法は、評価対象の内容に適していますか？	NO の場合 -> 評価設定の問題 — テスト方法が不適切です

失敗したケースはすべて、10ステップの Playbook のステップ7にある、次の2つの根本原因カテゴリのいずれか一方に分類してください。

• 評価設定の問題 — 応答は実際には許容可能であり、評価で誤ってフラグが立てられています。対応：評価を修正します。
• エージェント品質の問題 — 評価により実際の問題が正しく検出されています。対応：失敗のパターンを記録し、修正を定義して追跡します。

Triage Playbook のより詳細な分類体系は維持しつつ、これら2つのカテゴリとの対応関係を明示してください。

詳細分類	ステップ 7 の分類	意味	対応
評価設定の問題	eval-setup problem	テストケース、期待される回答、評価基準、採点者、またはテスト方法に誤りがあります。エージェントは正しく動作している可能性があります。サブタイプ：古くなった期待される回答、厳格すぎる採点者、現実的でないテストケース、誤った評価方法、採点者の事実誤認、採点者の系統的な偏り、曖昧な合格基準。	評価ケース、評価基準、期待される回答、または方法を更新します。評価基準を広範囲に変更した場合を除き、影響を受けるケースのみを再実行します。
エージェント設定の問題	agent-quality problem	エージェントが実際に不適切な応答を生成しました。	システムプロンプト、ナレッジソース、ツール設定、トピックのルーティング、オーケストレーション、またはアクションの動作を修正します。
プラットフォームの制限	agent-quality problem	問題は実際に発生していますが、通常の設定では修正できない基盤プラットフォームの動作が原因です。兆候：複数のプロンプトや設定を試しても同じ問題が続く、正しい設定にもかかわらず、検索で一貫して誤ったドキュメントが返される。	制限を記録し、回避策を設計して、ハードゲート／ソフトゲートを満たせるか判断します。

ケース ID、評価セット、セットの種類、カテゴリ／ディメンション、ゲートの種類、ステップ 7 の分類、詳細分類、パターン、担当者、修正箇所、再実行の対象を記録した失敗パターンのログを管理します。根本原因が共通する失敗をグループ化します。たとえば、「ケース 3、5、7 はすべて『質問に回答していない』という結果で失敗しています。これは 3 つの個別の問題ではなく、1 つのエージェント品質パターン（ナレッジソースの不足、またはスコープの不足）です。」

3b. プラットフォーム診断ツール（該当する場合に推奨）

Copilot Studio には、トリアージを迅速化する組み込みツールがあります。顧客がさらに調査するのに役立つ場合は、これらのツールを案内してください。

ツール	機能	推奨するタイミング
アクティビティマップ	テストケースに対するエージェントの判断プロセスを表示します。どのトピックが呼び出され、どのナレッジソースが検索され、どのアクションが呼び出されたかを確認できます。UI で任意のテストケースの結果をクリックすると利用できます。	CSV だけでは根本原因が不明な失敗に対して推奨します。「ケース X のアクティビティマップを開き、エージェントが適切なナレッジソースを検索したのか、誤ったトピックにルーティングしたのかを確認してください。」と伝えます。
結果の比較	2 つの評価実行を並べて比較し、合格から不合格、または不合格から合格に変わったケースを表示します。同じテストセットで複数回実行した場合に利用できます。	顧客が変更後に再実行する予定の場合は、次回実行のセクション（セクション 8）で推奨します。「再実行後、結果の比較を使って、変更によって対象の失敗が解消され、合格していたケースは引き続き合格していることを確認してください。」と伝えます。
セットレベルの採点	個々のケースの合否だけでなく、テストセット全体の品質を評価します。全体的な品質評価が得られます。	顧客の結果が境界付近（合格率がしきい値に近い）にある場合や、個々のケースの結果に一貫性がない場合に推奨します。セットレベルの表示から、少数の失敗があってもエージェントが全般的に十分な能力を備えているのか、それとも失敗がシステム全体の問題を示しているのかを把握できます。

失敗のトリアージでは、CSV の説明だけでは根本原因を判断できないケースについて、必ずアクティビティマップを提案してください。アクティビティマップは最も役立つ診断ツールです。エージェントが何を発言したかだけでなく、エージェントが「考えた」ことを正確に表示します。

補足的なシグナル：ユーザーのリアクション（高評価／低評価）

エージェントがすでにデプロイされている場合（プレビューを含む）、Copilot Studio はエージェントの応答に対するユーザーのリアクション（高評価／低評価）を取得します。これらは評価 CSV には含まれませんが、評価結果を補完します。

• 評価では合格でも、ユーザーが低評価を付ける： 評価が甘すぎるか、テストケースが実際のユーザーの期待を反映していない可能性があります。採点者が許容する内容と、ユーザーが実際に求めている内容のギャップを調査してください。
• 評価では不合格でも、ユーザーが高評価を付ける： 評価が厳しすぎる（採点者の基準が硬直的）か、ユーザーの基準が評価より低い可能性があります。こうしたシナリオの期待される応答を見直してください。
• 評価対象外のトピックに低評価が集中する： カバレッジの不足です。次回の評価で、そのトピック領域のテストケースを追加してください。

ユーザーの反応データが利用できる場合は、評価結果と実際の満足度を照合できるよう、パターン分析（セクション 6）で言及してください。反応データを構造化評価の代わりとして扱わないでください。反応データにはノイズがあり、クリックするユーザーに偏り、根本原因を特定できません。あくまでシグナルであり、最終判断ではありません。

4. 説明の分析

4a. General Quality の採点基準

テスト方法が GeneralQuality の場合、Copilot Studio は応答を4 つの異なる基準で採点します。General Quality のスコアが低い場合、これらのうち 1 つ以上が不合格です。適切な箇所を修正できるよう、顧客にはどの基準が不合格だったかを知らせる必要があります。

基準	評価内容	低スコアの意味	改善の方向性
関連性	応答はユーザーの質問に答えていますか？	エージェントが質問を無視した、別の質問に答えた、または答えるべき場面で「わかりません」と返した状態です。	ナレッジソースのカバレッジを確認してください。トピックは対象範囲内ですか？トピックのルーティングを確認してください。適切なトピックが起動していますか？アクティビティマップを開き、エージェントが何を取得したか確認してください。
根拠の確かさ	応答はエージェントに設定されたナレッジソースに基づいていますか（幻覚によるものではありませんか）？	エージェントが情報を捏造したか、ナレッジソースにない事実を述べた状態です。これは幻覚の検出項目です。	取得されたナレッジソースを確認してください（アクティビティマップ）。適切なソースが存在するのに取得されなかった場合は、インデックス作成とチャンク分割を確認してください。このトピックを扱うソースがない場合は、追加するか、「その情報はありません」と答えるようエージェントに指示してください。
完全性	重要な部分を省略せず、質問に十分に答えていますか？	エージェントが部分的な回答を返した状態です。トピックには触れていますが、重要な詳細が抜けています。	ナレッジソースに回答全体が含まれているか確認してください。含まれている場合、エージェントが応答を途中で切り上げているか、過度に要約している可能性があります。システム指示を調整してください。ソースも不完全な場合は、ソースを更新してください。
回答の差し控え	エージェントは必要に応じて適切に回答を差し控えていますか？（答えすぎていないか、答えなさすぎていないか）	エージェントが回答を差し控えるべき場面で回答した（例：対象範囲外の質問、安全でないリクエスト）、または回答すべき場面で差し控えた（制約が厳しすぎる）状態です。	システム指示の対象範囲の境界を確認してください。回答の差し控えが低く、関連性も低い場合、エージェントはあらゆる質問に低品質な回答をしている可能性があります。回答の差し控えが低く、関連性が高い場合、エージェントは回答すべきでない内容に答えている可能性があります（対象範囲の漏れ）。

4 つの基準の相互関係： General Quality に合格するには、4 つの基準すべてに合格する必要があります。不合格の場合は、少なくとも 1 つの基準が不合格です。どの基準が不合格かを特定するには、explanation フィールドを確認してください。最もよくある不合格パターンは、関連性のみの不合格（ナレッジ不足）で、次に多いのが根拠の確かさのみの不合格（幻覚）です。関連性と根拠の確かさの両方が不合格の場合、エージェントがまったく別のナレッジソースを取得している可能性が高いです。

General Quality だけに頼るべきではない場合： General Quality は応答の品質を総合的に確認しますが、特定の事実値の正確性、ツール呼び出しの正しさ、構造化出力形式の妥当性は検証できません。対象を絞ったテスト方法（事実の正確性には CompareMeaning、アクションの検証には ToolUse、必須語句の確認には KeywordMatch）と併用してください。

4b. 説明パターンの対応付け CSV から explanation フィールドを解析します。Copilot Studio の General Quality の説明では、次のパターンが使われています。それぞれを上記の基準とプレイブックの診断質問に対応付けてください。

説明のパターン	品質のシグナル	プレイブックの診断領域
"Seems relevant; Seems complete; Based on knowledge sources"	すべて合格	—
"Question not answered; Further checks skipped because relevance failed"	関連性の失敗	診断 2.1〜2.5（事実の正確性／ナレッジの根拠付け）
"Seems relevant; Seems incomplete"	完全性の失敗	診断 2.15〜2.18（応答の品質）
"Knowledge sources not cited"	情報源の帰属の失敗	ナレッジの根拠付けに関する診断
"Seems relevant; Seems complete"（"Based on knowledge sources" がない場合）	根拠付けに関する懸念	診断 2.4〜2.5（ハルシネーションのリスク）

失敗に見られる説明パターンごとに、診断領域を示し、調査すべきプレイブックの具体的な質問を提案してください。

4c. 会話（複数ターン）の結果の解釈

会話テストセット（複数ターンの評価）の結果を解釈する際は、単一応答テストとは異なる失敗パターンを考慮します。次の診断の視点を追加で適用してください。

ターン単位の診断： 会話テストケースは全体として失敗しますが、根本原因は通常、特定のターンにあります。エージェントの応答をターンごとに読み、品質が最初に低下したターンを特定してください。よくあるパターンは次のとおりです。

パターン	意味	修正の方向性
ターン 1 は合格し、ターン 3 以降は失敗する	コンテキストの喪失 — エージェントが以前のコンテキストを忘れています。エージェントのオーケストレーションで会話の状態が維持されているか確認してください。	コンテキストの保持に関するシステム指示を見直してください。クラシック オーケストレーションで会話中にトピックがリセットされていないか、または生成オーケストレーションで LLM のコンテキストウィンドウが上限を超えていないか確認してください。
すべてのターンが同じ基準で失敗する	システム全体の問題 — 複数ターン特有の問題ではありません。ターン数にかかわらず、エージェントに基本的な品質の問題があります。	単一応答の失敗として扱い、上記の標準的なフレームワークで診断してください。
ターン 2（確認ターン）が失敗する	確認への対応 — エージェントが適切な追加質問をしなかったか、ユーザーの確認を誤解しました。	確認への対応に関するシステム指示を確認してください。曖昧または不完全なユーザー入力への対応方法がエージェントに指示されていることを確認してください。
最後のターン（解決ターン）が失敗する	タスク完了の不備 — エージェントは複数のターンを通じて依頼を理解していましたが、最終的な回答やアクションを提供できませんでした。	エンドツーエンドのタスクを完了するために、適切なナレッジソースまたはツール接続がエージェントに用意されているか確認してください。診断ツールは適切でも、「最後のひと押し」で失敗しています。
エージェントが複数のターンで同じ応答を繰り返す	状態のループ — エージェントが行き詰まっています。多くの場合、同じトピックを繰り返し起動するトピックルーティングが原因です。	この会話のアクティビティマップを開き、エージェントが同じトピックまたはアクションを繰り返し実行していないか確認してください。

利用できるメソッドは限られています： 会話テストでサポートされるのは、General Quality、Keyword Match、Capability Use（Capabilities match）、Custom のみです。Compare Meaning または Exact Match の分析が役立つ失敗（たとえば、エージェントが正しい回答をしたものの、表現が異なる場合）が見られたら、この制限を記載し、該当するシナリオについて補完的な単一応答テストセットも作成するよう顧客に推奨してください。

重要なターンの特定： 失敗を報告する際は、会話がうまくいかなかった特定のターンである重要なターンを特定して明示してください。後続のターンでの失敗は、独立した原因ではなく、それ以前のターンの失敗が原因であることがよくあります。重要なターンを修正すると、1 回の変更で複数の後続の失敗を解決できる場合があります。

4d. セット単位の採点の解釈 Copilot Studio のセットレベル評価では、個々の合格／不合格の件数を集計するだけでなく、テストセット全体にわたるエージェントの品質を評価します。顧客がセットレベルの結果を得ている場合は、以下のフレームワークを使ってケースレベルの結果と併せて解釈してください。

セットレベルとケースレベルの結果が一致する場合： これは単純なケースです。セットレベルの評価が高く、ケースレベルの合格率も高ければ、エージェントのパフォーマンスが良好であることを確認できます。セットレベルの評価が低く、多くのケースレベルの失敗があれば、システム上の問題を確認できます。上記の標準的なトリアージフレームワークを使用してください。

セットレベルとケースレベルの結果が食い違う場合 — 解釈が重要になるのはこのケースです：

食い違い	意味	対応
ケースレベルの合格率は高いが、セットレベルの評価は低い	個々の応答は評価者の基準に合格していますが、エージェントの全体的な振る舞いには品質上の問題があります。たとえば、応答ごとにトーンが一貫しない、内容の深さにばらつきがある、あるいは「字義どおり」には合格しても「本質的」には合格していない、といった点です。	合格したケースをいくつか選び、手動で確認してください。評価者の基準が甘すぎる（凡庸な応答を受け入れている）可能性や、セットレベルの評価でケースレベルでは見えないパターン（たとえば、エージェントが正しいものの機械的な回答をしていること）が検出されている可能性があります。個々の評価者の基準を厳しくすることを検討してください。
ケースレベルの合格率は低いが、セットレベルの評価は高い	多くの個別ケースはそれぞれの評価者の基準に不合格ですが、エージェントの全体的な振る舞いは適切です。評価者の基準が厳しすぎる場合（たとえば、エージェントの言い換えで問題がないのに、正確な言い回しを求める場合）によく見られます。	これは、評価設定の問題が主な原因であることを強く示しています。5 つの質問による評価検証手順（セクション 3）を使って、失敗したケースを監査してください。対応としては、エージェントを修正するのではなく、評価者の基準を緩めるか、期待される応答を更新する可能性が高いです。
ケースレベルの結果は安定しているが、実行ごとにセットレベルの評価が変わる	全体的な品質評価によって、個々の評価者が見逃す点が検出されています。たとえば、トーンの変化、冗長さの増加、微妙な品質の変化などです。	実行間の実際の応答を定性的に比較してください。セットレベルの評価者は、ケースレベルの合否では捉えられないスタイルの劣化を検出している可能性があります。

判定におけるセットレベル評価の使い方： セットレベル評価は補足的なものであり、manifest で定義されたハードゲートとソフトターゲットに基づく SHIP／ITERATE／BLOCK の判定に優先するものではありません。ただし、ほかの点では SHIP の準備が整っている結果でセットレベル評価が低い場合は、人によるレビューチェックポイントを設けてください。「ゲートのステータスは SHIP ですが、セットレベルの品質評価は期待を下回っています。リリース前に合格した応答をいくつか確認してください。」

5. 上位 3 つのアクション — Triage Playbook のレイヤー 3（修正方法のマッピング）に従う

優先順位順に、アクションをちょうど 3 つ挙げてください。それぞれ、Playbook の修正パターンに従う必要があります：X を変更 -> Y を再実行 -> Z を期待。

Playbook のゲート優先の順序に従って優先順位を付けてください：

1. まず失敗したハードゲート、特に信頼性と安全性（guardrails、out_of_scope、sensitive_data、prompt_injection、compliance）
2. 価値またはリスクの高い機能セットに影響するエージェント品質のパターン
3. 未達のソフトターゲット。スコアが最も低い評価セットから着手
4. 繰り返し発生する失敗やリグレッション（同じケースが実行ごとに失敗する）
5. 判定を歪めたり、真のリスクを隠したりする評価設定の問題

具体性の要件を満たす例：

• "変更： 製品 FAQ ドキュメントをエージェントのナレッジソースに追加します。再実行： ケース 4 と 7（どちらも「質問に回答されていない」と表示）。期待： 製品関連のクエリで関連性が合格すること。"
• "変更： システムプロンプトにエスカレーション指示を追加します：「リクエストを解決できない場合は、人間のエージェントへの接続を提案してください。」再実行： ケース 3（「担当者と話したい」）。期待： 関連性が合格すること。"
• "変更： ケース 5 の期待される応答を更新します。古いプロセスに言及しています。再実行： ケース 5 のみ。期待： Meaning スコアが向上すること（これはエージェントの修正ではなく、評価設定の修正です）。"

6. パターン分析 — Triage Playbook のレイヤー 4 に従う Playbook に記載されている、次のシグナル横断パターンを確認してください。

パターン	示唆される内容
すべての失敗に「質問に回答していない」が共通する	ナレッジソースの不足、またはスコープ定義の問題
事実の正確性とナレッジへの準拠の両方が失敗している	ナレッジソースの問題（誤ったドキュメントが取得された、または必要なドキュメントがない）
正確性は合格しているが、トーン／品質が失敗している	回答は正しいものの、伝え方に問題がある — スタイルの指示が必要
信頼性と安全性は合格しているが、機能の正確性が失敗している	エージェントに制約をかけすぎている可能性がある — 安全性の制限を見直す
すべての失敗が1種類の質問に集中している	全体的な不足 — 個別のケースではなく、カテゴリを修正する
失敗の80%以上が評価設定の問題である	エージェントの作業を一時停止し、まず評価を監査して修正する
変更後、あるシグナルは改善している一方で、別のシグナルが悪化している	指示の競合（指示の予算に関する問題）

また、失敗の集中状況も確認してください。ほとんどの失敗に同じ根本原因の種類が見られる場合は、その点を明示してください。Playbook にあるとおり、「同じ根本原因が80%以上を占める場合は全体的な問題であり、カテゴリを修正する必要があります」。

7. 解釈の根拠（WHY を説明する）

トリアージを提示した後、顧客が次回からこのフレームワークを自力で適用できるよう、判断の根拠を説明してください。次の4点を取り上げます。

• 判定がその結果になった理由： 実際のセットごとの数値を使って、厳格なゲートと目標値を順に説明します。例：「ガードレールの信頼性と安全性のセットは厳格なゲートであり、目標値の95%に対して100%で合格したため、BLOCK にはなりませんでした。請求処理の正確性に関する機能セットは目標値であり、目標値の80%に対して72%で合格したため、判定は ITERATE です。全体の合格率は86%ですが、未達の目標値には依然として修正が必要です。」
• 失敗をその分類にした理由： 使用したStep 7の各バケットと詳細な分類について、判断に至る筋道を説明します。例：「ケース3と7は、評価設定の問題／評価設定の問題として分類しました。エージェントの実際の回答は内容として正しく、質問に正確に回答しているにもかかわらず、採点者が表現の違いを理由に不合格にしたためです。期待される回答は『1-800-555-0100に電話してサポートにお問い合わせください』ですが、エージェントは『1-800-555-0100でサポートチームにお問い合わせいただけます』と答えています。同じ情報を別の言葉で伝えています。これはエージェントの品質ではなく、採点者の柔軟性の問題です。」
• 上位3つのアクションをその優先順位にした理由： 各アクションの優先順位をトリアージのフレームワークと結び付けます。例：「ナレッジソースの修正を第1位にしたのは、エージェントの失敗6件中4件に対処でき、いずれも中核的な業務シナリオだからです。プロンプトの調整を第2位にしたのは、失敗2件を修正できますが、該当するのは機能シナリオであり、Playbook の優先順位では下位だからです。評価の修正を第3位にしたのは、エージェントを改善するものではなく、測定を正すだけだからです。」
• このトリアージからは分からないこと： 限界を挙げます。例：「このトリアージは1回の評価実行に基づいています。非決定性の問題は検出できません（ばらつきを確認するには評価を3回実行してください）。また、テストケースが適切なシナリオをカバーしているかどうかも評価できません。カバレッジが低い状態で評価に合格することは、カバレッジが十分な状態で評価に不合格となることよりも望ましくありません。」

このセクションでは手法を説明し、顧客がいずれこのスキルに頼らず結果を解釈できるようにします。各箇条書きでは、一般的なアドバイスではなく、この評価実行の具体的なデータを参照してください。

8. 次回の実行に関する推奨

変更後に何を再実行するかを正確に指定し、最後を1文で締めくくります。Playbook の再実行対象は次のとおりです。

変更内容	再実行するもの
単一のテストケース（評価の修正）	影響を受けたテストケースのみ
エージェント設定の変更	影響を受けたテストケースと、無関係なセット1つのスポットチェック
システムプロンプトの変更	評価スイート全体
ナレッジソースの更新	忠実性／根拠性に関するケースと、機能の事実正確性に関するケースすべて
厳格なゲートの修正	不合格となった厳格なゲートのセットと、Step 8の回帰テストスイート
ヒント： 再実行後、Copilot Studio の 結果の比較 機能を使って、新しい実行結果を前回の実行結果と比較します。合格から不合格、または不合格から合格に変わったケースが表示されるため、意図した失敗が修正され、リグレッションが発生していないことを簡単に確認できます。

8b. バージョン比較の解釈（顧客が2つの実行結果を提供した場合）

顧客が2回の評価実行（変更前後、または2つのエージェント構成）の結果を提供した場合は、上記の標準的なトリアージに加えて、比較分析を行います。2つのCSVファイル、貼り付けられた2つの要約、または「実行1は78％、実行2は85％です」のような説明を受け付けます。

比較表：

指標	実行1（変更前）	実行2（変更後）	差分
全体の合格率	X%	Y%	+/-Z%
コアビジネスの合格率	X%	Y%	+/-Z%
信頼性と安全性の合格率	X%	Y%	+/-Z%
能力の合格率	X%	Y%	+/-Z%
未達のハードゲート	X	Y	+/-Z
未達のソフトターゲット	X	Y	+/-Z

ケース単位の差分分析：

すべてのテストケースを、次の4つのカテゴリに分類します。

カテゴリ	意味	対応
合格-合格（安定）	両方の実行で合格し、リグレッションなし	対応不要。ただし、リグレッションのベースラインとして記録します
不合格-合格（修正済み）	前回は不合格でしたが、今回は合格しており、変更が機能しました	修正が実際に有効か（非決定性によるものではないか）を確認します。安定性を確かめるため、さらに2～3回実行します
合格-不合格（リグレッション）	前回は合格でしたが、今回は不合格となり、変更によって問題が発生しました	最優先です。 リグレッションは既存の失敗よりも深刻です。以前より後退したことを意味するため、直ちに調査します
不合格-不合格（未解決）	両方の実行で不合格となり、変更による効果がありませんでした	根本原因を再検討します。このケースを解決するはずの修正であったにもかかわらず解決しなかった場合、診断が誤っていました

差分の解釈：

• 実行間で全体に±5％の差が生じるのは通常です（LLM の非決定性）。小さな変動を過大評価したり、慌てたりしないでください。ノイズとシグナルを見分けるため、評価を3回実行して中央値を取ります。
• 同じエージェントのバージョンで、ケースの結果が実行ごとに変わる（ある実行では合格し、別の実行では不合格になる）場合、これは品質の問題ではなく、信頼性の問題です。別途報告します。
• 変更後に修正数よりリグレッション数が多い場合、その変更は全体として悪影響を及ぼしています。元に戻すことを検討します。
• あるカテゴリではすべて修正され、別のカテゴリではすべてリグレッションが発生している場合、指示が競合しています。信頼性と安全性への対応を修正したプロンプトの変更により、ビジネス上の応答が過度に制約された可能性があります。これは、システムプロンプトの編集が意図しない副作用を招いた場合に最もよく見られるパターンです。

能力、信頼性と安全性、およびリグレッションの捉え方： 評価実行の種類ごとの目的を顧客が理解できるようにします。

• 能力評価セットは、正確性、忠実性／根拠との整合性、関連性、スタイル／口調、推論／ツールの使用など、タスクの品質を測定します。ハルシネーションは、忠実性の失敗としてここに分類されます。
• 信頼性と安全性の評価セットは、拒否、範囲、機微データ、プロンプトインジェクション、コンプライアンスに関する動作を測定します。通常、これらはハードゲートです。
• リグレッションセットは、変更後に以前合格したテストケースや重要なテストケースを再実行します。合格率は目標値に近い水準を維持する必要があります。低下があれば、調査が必要なリグレッションです。
• ゲート専用セットは、パイロット前、本番環境への移行前、重大な変更後などの節目に実行します。

健全な評価の運用では、能力評価セットと信頼性と安全性の評価セットの両方を使用し、ステップ8のリグレッションスイートとゲート専用スイートに分けます。顧客が1種類しか実行していない場合は、もう一方も追加するよう勧めます。

9. 本番環境での最適化ループ計画（ステップ9）

この評価から継続的なデプロイ後の改善につなげる、今後の最適化ループ計画を短くまとめて締めくくります。

1. シグナルを収集する： 低評価（最も強いシグナル）、エスカレーション、手動での上書き、サポートチケット、定性的なフィードバックを収集します。
2. クラスタリングする： シグナルを繰り返し発生する失敗パターンごとにグループ化し、各クラスタを既存の評価セットまたはカバレッジの不足箇所に対応付けます。
3. 修正箇所を決める： エージェントの設定（プロンプト／検索／ツール／オーケストレーション）、評価基準／評価設定、または新しい評価ケースから選びます。
4. リリースする： 担当者とバージョン情報を明記し、安全性を保った最小限の変更を行います。
5. 再評価する： 対象ケースとステップ 8 の回帰テストスイートを実行し、新しいケースがあれば失敗パターンログと回帰テストスイートを更新します。

---

ステップ 3 — 出力ファイルを生成する

会話内でトリアージレポートを表示した後、書式設定されたレポートを生成します。

評価結果トリアージレポート（.docx） docx スキルを使用して、以下を含む書式設定済みのドキュメントを作成します。

• タイトル：「評価結果トリアージレポート」
• 日付とエージェント名（判明している場合）
• スコアの概要表
• 判定（SHIP／ITERATE／BLOCK）とゲートの説明
• セットごとの実際の合格率と目標値、およびハード／ソフトゲートのステータス
• 能力と信頼性・安全性の結果を分けて報告
• 失敗した各ケースの失敗トリアージの詳細（ステップ 7 の分類と詳細な分類体系を含む）
• 失敗パターンログ
• 優先順位付けされた上位 3 つのアクション
• パターン分析
• 解釈の根拠（セクション 7 より。判定、分類、優先順位の背後にある理由）
• 人間によるレビューのチェックポイント表（ステップ 4 より）
• 次回実行の推奨事項
• 本番環境の最適化ループ計画（ステップ 9）

---

Step 4 — 人によるレビューのチェックポイント

出力ファイルの後、会話が終了する前に、人によるレビューが必要ですのセクションを表示します。評価結果の解釈では、誤った前提が誤った判断につながります。判定を誤ると、壊れたエージェントをリリースしたり、優れたエージェントをブロックしたりする可能性があります。これらのチェックポイントは、人間の判断が不可欠な箇所を示します。

人によるレビューが必要です

#	チェックポイント	確認すること	重要な理由
1	判定が実際のビジネス状況に合っている	SHIP／ITERATE／BLOCK の判定に使われたしきい値はデフォルト値です。この判定は、実際にデプロイしてもよいと思える基準に合っていますか？医療分野のエージェントでは、86%での「SHIP」は受け入れられないかもしれません。一方、社内 FAQ ボットなら、78%での「ITERATE」で問題ないかもしれません。	実際のリスク許容度とゲートポリシーを把握しているのは、チームだけです。判定は推奨であり、決定ではありません。
2	評価設定の問題が言い訳ではなく、本当の問題である	「評価設定の問題」に分類された失敗について、エージェントの実際の応答を自分で確認します。本当に許容できる内容ですか？それとも、AI がエージェントに甘い判定をしていますか？	エージェントの失敗を評価の問題と誤分類すると、実際の問題が見過ごされます。20%という推定値は出発点であり、免罪符ではありません。
3	根本原因のグループ分けが妥当である	失敗がグループ化された場合（「ケース 3、5、7 は同じ根本原因」など）、本当に同じ問題に起因しているか確認します。CSV データだけでは、異なる症状が似て見えることがあります。	グループ分けが誤っていれば、修正も誤り、反復作業が無駄になります。グループ分けをひとつ誤るだけで、1 サイクルまるごと間違った箇所の修正に費やすことになりかねません。
4	上位 3 つのアクションが実行可能で、優先順位も正しい	推奨された変更を実際に行えますか？スケジュールや制約を踏まえて、優先順位は適切ですか？ナレッジソースの修正が最初に提案されても、完了に 2 週間かかる場合があります。一方、プロンプトの調整なら、より早く実施でき、すぐに次へ進めるかもしれません。	推奨される優先順位は影響度に基づいていますが、必要な作業量や依存関係を把握しているのはチームです。
5	合格率 100%を喜ぶのではなく、調査する	結果が 100%の場合、より難しいテストケースを追加せずにリリースしてはいけません。次の点を確認します。期待される応答が曖昧すぎませんか？テスト方法が寛容すぎませんか？正常系のパスだけをテストしていませんか？	完璧なスコアは、ほとんどの場合、エージェントが完璧なのではなく、評価が簡単すぎることを意味します。
6	修正によって合格済みのシナリオが壊れない	上位 3 つのアクションに基づいて変更を加える前に、現在合格しているテストケースに影響しないか確認します。特にプロンプトの変更は、波及効果が生じやすいものです。	3 件の失敗を修正して新たに 5 件の失敗を招けば、全体として損失です。変更後は必ずテストスイート全体を再実行します。

チェックポイントの後に、次の内容を追加します。

• 必須の注意事項：「このトリアージレポートは、評価結果をもとに AI が生成したものです。判定や修正アクションに基づいて対応する前に、チームで失敗したケースを確認してください。特に、評価設定の問題に分類されたケースを確認してください。エージェントの問題と評価の問題を区別するには、人間の判断が必要です。」

---

データ保持に関する警告

Copilot Studio は89 日後にテスト実行結果を削除します。必ず次の対応をユーザーに推奨してください。

1. 各評価の実行後、すぐに結果の CSV をエクスポートする（Test set → Export results）
2. SharePoint またはリポジトリに、エージェントのバージョンと併せて保存する
3. レポートで修正後の再実行が推奨された場合、修正前後の比較ができるよう、変更を加える前に現在の結果をエクスポートする

この注意事項を、生成するすべてのレポートの末尾に含めてください。

---

動作ルール

• 分析より先に、まず判定を示してください。
• セットの種類、カテゴリ、テスト方法、ゲートの種類、対象、回帰クラス、出典については、推測よりマニフェストのメタデータを優先してください。
• 集計された合格率ではなく、ハードゲートとソフト目標に基づいて SHIP／ITERATE／BLOCK を判断してください。
• ハードゲートで信頼性と安全性に関するゲートが1つでも失敗した場合は、ただちに BLOCK としてください。オーナーがマニフェスト内でゲートを明示的に再分類しない限り、信頼性と安全性に関する失敗は交渉の余地がありません。
• エージェントの責任を問う前に、失敗が評価設定の問題かどうかを必ず確認してください。これは評価結果の解釈で最もよくある誤りです。
• すべての失敗を、Step 7 のいずれか1つだけの分類に分けてください。細かな分類は補助ラベルとして保持してください。
• 合格率が100%の場合は、危険信号として扱い、その旨を伝えてください。
• 確信を持って判定するには入力が少なすぎる場合は、デフォルトで ITERATE とし、その理由を説明してください。
• CSV だけでは失敗がエージェント品質の問題か評価設定の問題か判断できない場合は、その旨を明示し、該当する行の actualResponse を読むようユーザーに伝えてください。
• Playbook の非決定性に関する指針に従い、ユーザーが評価の複数回実行に言及した場合、±5%の変動は正常です。±10%の場合は調査が必要です。

---

実行例

/eval-result-interpreter C:\Users\me\Downloads\Evaluate Agent 260310_1652.csv

/eval-result-interpreter 5/9 passed. Failed: case 3 (relevance), case 4 (relevance), case 5 (incomplete), case 7 (relevance).

/eval-result-interpreter All 8 cases passed on first run.

/eval-result-interpreter [paste CSV contents here]