eval-triage-and-improvement

評価トリアージと改善

エージェントの評価結果の解釈と、改善に向けた具体的な次のステップの特定を支援します。ハイブリッドワークフローに従い、まず評価結果を収集してから、Step 7 の根本原因の分類、担当者、推奨される修正を含む構造化されたトリアージレポートを作成します。

このスキルは、標準となる Practical Guidance on Agent Evaluation: 10-step playbook をまとめた skills/eval-guide/playbook.md に基づいています。これは、Step 7 — 失敗を診断するために反復するための詳細ガイドであり、本番環境のフィードバックに向けた Step 9 — 最適化ループの出発点となります。MS Learn のページと Eval Guidance Kit は、Copilot Studio の仕組み、ライフサイクルの実施頻度、チェックリストの資料を補足する情報源として引き続き利用します。

このスキルと eval-result-interpreter の使い分け

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

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

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

ワークフロー

Step 1：評価結果の収集

ユーザーに、以下の情報を共有してもらいます。

1. 実行した評価セットと合格率（例：「Faithfulness：71％、Prompt injection：95％」）
2. 付属の .docx レポートまたは stage-N-data.json に含まれる方法論マニフェストのメタデータ：set_type、category／能力の次元、method、gate（hard／soft）、target、regression_class、人によるレビューのフラグ、ソース／正解データの来歴
3. 具体的な失敗テストケース — テストケース ID、サンプル入力、期待値、実際のエージェントの応答、Copilot Studio で割り当てられている評価方法
4. 実行回数 — 初回のベースライン実行（Step 6）か、修正後の再実行か
5. これまでに試したこと — 評価、エージェント、ナレッジ、ツールに対して、これまでに試した変更

構造化された結果がない場合は、手元の情報を整理できるよう支援します。ファイル名や質問文から推測するより、マニフェストのメタデータを優先してください。一般的な不満（「エージェントの調子が悪い」など）しかない場合は、シナリオライブラリと 10 ステップのプレイブックの Steps 1～6 を使って、まずベースラインを実行するよう案内してください。

Step 2：スコアの解釈

マニフェストの Step 4 の目標値とゲートに基づいて、準備状況を評価します。

READINESS ASSESSMENT

Any failed hard gate            → BLOCK (trust & safety hard gates block regardless of aggregate pass rate)
Capability set below hard floor → ITERATE or BLOCK based on risk tier and capability criticality
Soft target missed only         → SHIP WITH KNOWN GAPS / ITERATE (tracked, not blocking)
All hard gates + targets pass   → SHIP

しきい値の設定 — 固定の数値を適用しないでください。まずマニフェストの目標値を使用し、設定されていない場合は、エージェントレベルのリスク階層から暫定目標値を導き、マニフェストの更新が必要であることを示してください。

要因	しきい値を高くする条件
エラーの重大性	金銭的損失、安全上のリスク、法的責任
対象範囲	外部顧客または多数の社内利用者
自律性／影響範囲	エージェントがアクションを実行したり、下流システムを起動したりできる
規制への該当性	規制対象のワークフロー、監査要件、コンプライアンス上の義務
データの機密性	PII、PHI、機密情報、またはテナント固有の機密データ

ステップ 3：トリアージ前のインフラストラクチャ確認

個々の失敗を診断する前に、評価の実行中にインフラストラクチャが正常だったことを確認します。

• すべてのナレッジソースにアクセスでき、完全にインデックス化されていましたか？
• API バックエンドとコネクターでエラーやタイムアウトは発生しませんでしたか？
• 実行中、認証トークンは有効でしたか？
• 正しいエージェントのバージョンが公開され、評価されましたか？

依存関係に問題があった場合は、インフラストラクチャを修正してから再実行し、その後にトリアージを行うよう推奨します。

ステップ 4：失敗の優先順位付け

失敗が多い場合は、次の順序でトリアージするよう推奨します。

優先度	最初にトリアージする項目	理由
1	ハードゲートの失敗、特に信頼性と安全性の評価セット	影響が最も大きく、集計スコアにかかわらずデプロイを妨げます
2	高リスクな能力の失敗（正確性、忠実性、ツールの使用）	エージェントの価値に直接影響します。ハルシネーションは忠実性または能力の失敗です
3	最もスコアの低い評価セットの失敗	システム全体に関わる可能性が高く、1つのパターンを修正すれば複数の失敗が解消されます
4	ベースラインや再実行でも繰り返し発生する失敗	最も診断しやすく、リグレッションが起きやすい項目です
5	ソフト目標の未達	重要ですが、パターンが悪化しない限りブロック要因にはなりません

失敗が 15 件以上ありますか？ すべてをトリアージする必要はありません。最もスコアの低い評価セットから 3～5 件を確認します。同じ根本原因の分類／サブタイプのパターンが見られる場合は、それを修正して再実行します。

ステップ 5：根本原因の分類

失敗ごとに、診断の質問を順番に確認します。すべての失敗は、ステップ 7 の根本原因の分類のいずれか 1 つに必ず該当させます：eval-setup problem（応答は許容範囲内で、評価を修正する）または agent-quality problem（実際の問題があるため、エージェント／プラットフォームを修正し、パターンを記録する）。

TRIAGE DECISION TREE (for each failing test case)

1. Is the agent's response actually acceptable, even though it failed?
   → YES = Eval-setup problem (grader, expected value, rubric, or method is wrong)

2. Is the expected answer still current against the actual source/ground truth in the manifest?
   → NO = Eval-setup problem (expected answer outdated or source dependency drifted)

3. Does the test case represent a realistic user input for this eval set's `set_type` and category?
   → NO = Eval-setup problem (unrealistic or mis-scoped test case)

4. Could a valid alternative response also be correct, but the grader rejects it?
   → YES = Eval-setup problem (rubric/grader too rigid)

5. Is the eval method appropriate for what you're testing?
   → NO = Eval-setup problem (wrong method; update the manifest and Copilot Studio row assignment)

ALL PASS → The eval is valid. Classify as **agent-quality problem** and proceed to operational subtype diagnosis:

6. Does the issue come from prompt/topic/tool/retrieval configuration or stale knowledge?
   → YES = Agent Configuration / Knowledge Issue (agent-quality problem)

7. Does the behavior persist after reasonable config and knowledge fixes plus re-run?
   → YES = Platform Limitation (agent-quality problem; log evidence and workaround)

ステップ 5b：会話（複数ターン）のトリアージ

会話評価の失敗にも標準の判断ツリーを適用しますが、まず重大なターン、つまりエージェントが最初に誤ったターンを特定する必要があります。誤ったターン以降は、独立した失敗ではなく、連鎖的な失敗です。

重大なターンの特定：

1. 会話をターンごとに確認します
2. エージェントの応答が期待される動作から最初に逸脱したターンを特定します
3. 上記の判断ツリーを使って、そのターンを分類します
4. それ以降のターンに「連鎖的な失敗 — ターン N の修正で解消」と記録します

会話固有の失敗パターンと修正方法：

パターン	見分け方	根本原因の領域	修正方法
コンテキストの喪失 — ターン 1 は問題ないが、ターン 3 以降で忘れる	エージェントが質問を繰り返したり、以前のターンと矛盾したりします	エージェント設定	トピック管理を見直し、トピックの切り替え後も会話のコンテキストが保持されるようにします
状態のループ — エージェントが同じ応答を繰り返す	エージェントのターンが連続して同一またはほぼ同一です	エージェント設定	トピックのルーティングに循環参照がないか確認し、明示的な終了条件を追加します
確認への対応失敗 — エージェントが追加の質問に対応できない	ユーザーが説明を追加したり、訂正したりしたときに、ターン 2 で失敗します	エージェント設定	追加の質問への対応方法を指示に加え、トピックが部分的な入力や訂正の入力を受け付けることを確認します
最後の段階での失敗 — 理解はしているが解決できない	早い段階のターンでは正しく診断できているのに、最終的な解決のターンで失敗します	エージェント設定またはプラットフォーム	アクション／コネクターの設定を確認し、解決までの経路が正しく接続されていることを確認します
評価の厳格さ — 会話は許容範囲内だが、評価者に却下される	会話全体を読むと、結果は妥当です	評価の設定	会話の採点方法には制限があります（AI Generated または Approval Rating のみ）。評価基準または期待値を調整します

単一応答のトリアージとの重要な違い： ターンごとに個別のトリアージを行わないでください。重大なターンをトリアージして修正を適用し、再実行してから、それ以降のターンが自動的に解消されるか確認します。重大なターンを修正すると、それ以降の失敗の 40～60％が解消される見込みです。

2 つのルート分類と運用上のサブタイプ

Step 7 のルート分類	運用上のサブタイプ	対応者	意味
評価設定の問題	評価設定の不備	評価作成者	回答は許容範囲内であるか、評価のメタデータ／評価基準／期待される回答／方法に誤りがあります。評価とマニフェストを修正します。
エージェント品質の問題	エージェント設定の問題	エージェント構築者	エージェントが実際に不適切な回答を生成しました。プロンプト、トピック、ツール、検索、グラウンディング、またはナレッジを修正します。
エージェント品質の問題	プラットフォームの制限	プラットフォームチーム＋エージェントの担当者	評価で検出されたのは、プラットフォームの動作が原因で実際に発生した問題です。証拠を記録し、可能であれば回避策を講じ、発生パターンを追跡します。

エージェント品質の問題ごとに、障害パターンログを記録します。ログには、テストケース、set_type／カテゴリ、ルート分類、サブタイプ、推定されるパターン、担当者、修正箇所、検証用評価セット、および回帰テストケースにすべきかどうか（Step 8）を含めます。

Step 6: 修正方法を特定する

Step 7 のルート分類、運用上のサブタイプ、評価セットの失敗パターン別の詳しい修正手順については、プレイブックファイルを参照してください。

• トリアージの全決定ツリー：triage-and-improvement-playbook/triage-decision-tree.md を参照
• 修正方法の対応表：triage-and-improvement-playbook/remediation-mapping.md を参照
• パターン分析：triage-and-improvement-playbook/pattern-analysis.md を参照
• 具体例：triage-and-improvement-playbook/worked-examples.md を参照

修正方法のクイックリファレンス

評価設定の修正：

サブタイプ	修正
古くなった期待される回答	現在のソースコンテンツに一致するよう、期待値を更新します
厳しすぎる採点器	Compare Meaning に切り替えるか、キーワードの範囲を広げます
非現実的なテストケース	実際のユーザーが使う表現で入力を書き直します
誤った評価方法	評価セットの目的と証拠の種類に合うよう、方法を変更します
採点器の誤り／偏り	評価基準を見直し、例を追加し、決定論的な方法を検討します

エージェント品質の修正 — エージェントの設定／ナレッジ／ツール：

失敗パターン	よくある修正
事実の正確性（誤ったソース）	ナレッジソースの設定を確認し、インデックス作成を検証して、語彙の一致を確認します
事実の正確性（誤った抽出）	システムプロンプトに抽出のガイダンスを追加します
ハルシネーション（忠実性の能力不足）	まず検索／チャンク化を改善し、次の指示を追加します：「ナレッジソースの情報だけを使って回答してください。情報がない場合は、その旨を伝えてください。」
誤ったツールが実行される	ツールの説明を書き直して違いを明確にし、否定例を追加します
ツールが実行されない	起動条件を確認し、ツールが有効でアクセス可能か確認します
誤ったトピックが起動する	トリガーフレーズの重複を確認し、優先順位を調整します
共感が不足している	システムプロンプトに、状況に応じた口調の指示を追加します
対応範囲への違反	対応範囲外であることを明示する指示を追加します
PII の漏えい	PII 保護の指示を追加し、認証範囲を確認します

エージェント品質の修正 — プラットフォームの制限への対応：

• 制限事項を証拠とともに記録します
• 可能であれば回避策を実装します
• 既知のプラットフォームの動作を考慮して評価のしきい値を調整します
• 再現手順を添えてプラットフォームチームに報告します

ステップ 7：トリアージの根拠（判断の理由を説明する）

レポートを生成する前に、トリアージの判断結果だけでなく、その判断に至った理由を顧客に説明する根拠を追加します。以下のそれぞれについて、このトリアージの実際の評価データを使ってください。

1. 各失敗がそのルートバケットとサブタイプに分類された理由 — ステップ 7 の各ルートバケットについて、少なくとも 1 つの例を挙げて判断の流れを説明します。例：「テストケース KB-014 は、エージェントの応答が現在のナレッジソースに照らして事実として正しい一方で、期待値が依然として以前の 14 日間のポリシーを参照しているため、評価設定の問題に分類されました。正しいのはエージェントの応答であり、評価が古くなっています。」

2. 修正対象が設定、コンテンツ、評価のいずれであるべきか — その判断の根拠を説明します。「エージェントの検索は正しく機能し、適切なドキュメントを見つけていましたが、そのドキュメント自体に古い情報が含まれているため、プロンプトを変更するのではなく、ナレッジソースを更新することを推奨しました。プロンプトを変更しても、根本的な問題を覆い隠すだけです。」

3. 優先順位の理由 — 影響範囲と依存関係に結び付けて説明します。「ハードゲートの失敗はデプロイを妨げ、下流の動作を変える可能性があるため、最優先で対応します。ブロッキングガードレールの問題を修正してから回帰テストスイートを再実行し、その後に残りをトリアージします。そうしないと、ブロッキングガードレールを修正すれば解消する失敗まで診断してしまう可能性があります。」

4. このトリアージでは分からないこと — 限界を明示します。「このトリアージでは、1 回の評価実行から [N] 件の失敗を分析しました。テストケースを作成していないシナリオの問題は検出できず、1 つのデータポイントだけでは、不安定な失敗（非決定性）と実際の失敗を区別できません。判断が難しい失敗については、修正に取りかかる前に再実行してください。」

この根拠をトリアージレポートに含めてください（以下のレポートテンプレートの「トリアージの根拠」セクションを参照）。

ステップ 8：トリアージレポートの生成

構造化されたトリアージレポートを出力します。

# Triage Report: [Agent Name] — [Date]

## Score Summary
| Eval Set | Set Type / Category | Pass Rate | Target | Gate | Status |
|----------|---------------------|-----------|--------|------|--------|
| ... | capability / faithfulness | ... | ... | hard/soft | PASS/BLOCK/ITERATE |

## Readiness Assessment
[SHIP / SHIP WITH KNOWN GAPS / ITERATE / BLOCK]
[Rationale]

## Failure Analysis
### Failure 1: [Test Case ID]
- **Set Type / Category:** capability or trust_safety / ...
- **Eval-set focus:** ...
- **Sample Input:** ...
- **Expected:** ...
- **Actual:** ...
- **Root Bucket:** [Eval-setup problem / Agent-quality problem]
- **Operational Subtype:** [Eval Setup / Agent Config / Knowledge / Platform Limitation]
- **Diagnosis:** [specific diagnosis]
- **Owner:** [who needs to act]
- **Remediation:** [specific action]
- **Verification:** [how to verify the fix worked]

[Repeat for each triaged failure]

## Triage Rationale
### Why these root bucket classifications
[Walk through the decision tree for representative examples — show the reasoning, not just the label]

### Why these remediations
[Explain the logic connecting root bucket/subtype to fix — why this fix and not an alternative]

### Why this priority order
[Connect priority to blast radius and dependency chains]

### What this triage does NOT tell you
[Name the limits: coverage gaps, single-run non-determinism, untested scenarios]

## Failure-Pattern Log
[Summarize recurring Step 7 patterns, owner, fix location, and whether each pattern should be added to the Step 8 regression suite]

## Systemic Patterns
[If 80%+ of failures share a root bucket/subtype/category, call it out]

## Action Items
| # | Action | Owner | Priority | Verification |
|---|--------|-------|----------|-------------|
| 1 | ... | ... | ... | Re-run [eval set] |

## Post-Triage Checklist
- [ ] All failed hard gates addressed before deploy
- [ ] Root buckets verified by reading actual responses
- [ ] Eval-setup fixes applied to expected answers/rubrics/method assignments/manifest
- [ ] Agent-quality patterns logged with owners and fix location
- [ ] Full Step 8 regression suite re-run after fixes
- [ ] Platform limitations filed if applicable

## Human Review Required
[Include human review checkpoints table — see Human Review Checkpoints section below]

トリアージ後の検証

修正を適用した後：

• 修正後もスコアが横ばいですか？ → ルートバケットまたはサブタイプが間違っています。再度トリアージしてください。
• 一方のスコアが上がり、もう一方が下がりましたか？ → 指示が競合しています。修正によってある動作は改善しましたが、別の動作は悪化しています。
• 失敗の 80% 以上が同じルートバケットまたはサブタイプですか？ → システム的な問題です。個々のテストケースではなく、そのカテゴリを修正してください。

非決定性への対応

LLM ベースのエージェントと評価器は、出力にばらつきが生じます。

• ベースラインの確立： ステップ 6 のベースラインとして扱うスコアを決める前に、3 回以上実行してください。平均値を使用し、エージェントのバージョンとタイムスタンプを記録します。
• 通常の変動： 実行間で +/-5% の変動は想定内です。10% を超える場合は調査してください。
• 不安定なテストケース（合格することもあれば、不合格になることもある）：エージェントがどちらも妥当な応答を生成していても、評価が厳格すぎる可能性があります。期待値の範囲を広げるべきか調査してください。
• 小規模な評価セット（テストケースが 30 件未満）： テストケースが 1 件反転するだけで、スコアが 3% 以上変化します。過度に解釈しないでください。

ステップ 9 最適化ループ：本番環境のシグナル

エージェントをデプロイしている場合（プレビュー段階でも）、本番環境からのフィードバックをステップ 9 のループとして扱います。シグナルを収集 → 分類 → 修正箇所を決定 → リリース → ステップ 8 の回帰テストスイートに照らして再評価します。シグナルは次の順に優先してください。低評価（最も強い否定的フィードバック）、エスカレーション、手動での上書き、サポートチケット、その後に定性的なコメントです。

• 評価が合格しているトピックで低評価が多い場合： カバレッジのギャップです。本番環境で繰り返し発生するリスクを示す場合は、評価ケースを追加または修正し、回帰テスト用にタグ付けします。
• 設定変更後に低評価が集中した場合： 回帰の可能性があります。ステップ 8 の回帰テストスイートを再実行し、スイートで見逃していた場合はケースを追加します。
• エスカレーション／手動での上書き： 反証が得られるまでは、エージェント品質の問題として扱います。能力または信頼性と安全性のカテゴリごとに分類し、修正箇所（エージェントの設定／検索／ツール、評価基準／期待される回答、新たな評価カバレッジ）を選びます。
• 評価が不合格のトピックで高評価が続く場合： 評価の設定に問題がある可能性があります。ゲートを緩める前に、実際の回答を確認します。

本番環境のシグナルだけで結論を出してはいけません。シグナルは仮説、新たな評価ケース、失敗パターンのログ記録の起点となり、修正内容は回帰テストスイートで検証します。

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

トリアージレポートに基づいて対応する前に、次のチェックポイントを確認してください。トリアージの判断はエージェントの変更に直結するため、診断を誤ると反復サイクルを丸ごと無駄にします。

#	チェックポイント	重要な理由
1	ステップ 7 の根本原因の分類を自分で確認する — 評価の設定に問題があると分類された失敗について、エージェントの実際の回答を読みます。本当に許容できる回答でしょうか。それとも、トリアージがエージェントに有利な判断をしているでしょうか。	エージェント品質の問題を評価の設定の問題と誤分類すると、実際の問題が無視されます。2 つの分類を区別するには判断が必要であり、スコアだけによる自動化では不十分です。
2	全体的なパターンの診断を確認してから、全体的な修正を適用する — 失敗の 80% 以上が同じ根本原因の分類／サブタイプに該当するとレポートに記載されている場合は、実際の回答を読んで確認します。症状が似ていても、原因が異なる場合があります。	全体的な診断を誤ると、多くの失敗を解決するつもりで 1 つの修正を適用しても、一部しか解決しないか、まったく解決しない結果になります。
3	修正の実現可能性と優先順位を検証する — チームで実際に推奨された変更を実施できますか。優先順位は、スケジュールや制約に照らして適切ですか。	トリアージでは影響度に基づいて優先順位を付けますが、作業量や依存関係はチームが把握しています。ナレッジソースの修正には 2 週間かかる一方、プロンプトの調整なら今すぐ先に進められるかもしれません。
4	提案された修正によって、合格済みのシナリオが失敗しないか確認する — 変更を加える前に、現在合格しているテストケースのうち、影響を受ける可能性があるものを検討します。特にプロンプトの変更には波及効果があります。	3 件の失敗を修正する一方で、新たに 5 件の失敗を生み出すのは、差し引きで損失です。エージェントの設定を変更した後は、必ずテストスイート全体を再実行する計画を立ててください。
5	エスカレーションする前に、プラットフォームの制限に関する分類を検証する — プラットフォームの制限と分類された失敗については、プラットフォームチームに報告する前に、複数のプロンプトや設定のパターンを試してもその動作が続くことを確認します。	設定の問題をプラットフォームのバグとしてエスカレーションすると、プラットフォームチームの時間を浪費し、実際の修正が遅れます。
6	マニフェストの目標とゲートが、実際のリスク層に合っているか確認する — SHIP/ITERATE/BLOCK の判断で、必須ゲート、ソフト目標、5 つのリスク要因が適切に反映されていますか。	実際にどの程度のリスクを許容できるかを把握しているのはチームだけです。社内向けのヘルパーならソフト目標の未達を許容できるかもしれませんが、信頼性と安全性に関する必須ゲートに不合格ならデプロイはできません。

この表をトリアージレポートの出力に含めてください。次の文を追加します。このトリアージレポートは診断を迅速化しますが、人による判断に代わるものではありません。修正に着手する前にチェックポイント 1 と 2 を確認してください。評価の設定に関する問題とエージェント品質の問題を区別するには、実際の回答を読む必要があります。

データ保持に関する警告

Copilot Studio は、89 日後にテスト実行結果を削除します。つまり、初回の評価で得たベースライン結果は、次の四半期レビューまでに失われる可能性があります。トリアージサイクルのたびに、次の手順を実施してください。

1. 結果の CSV をすぐにエクスポートします（テストセット → 結果をエクスポート）
2. トリアージレポートと一緒に保存します（SharePoint、リポジトリ、またはチームでバージョン管理された成果物を保管している場所）
3. エージェントのバージョンと日付をタグ付けし、将来比較できるようにします

トリアージで修正して再実行するサイクルが必要だと判断した場合は、変更を適用する前に修正前の結果をエクスポートしてください。修正前と修正後の比較が必要ですが、Copilot Studio は「修正前」の結果を永久には保持しません。

相互参照

このスキルでは、方法論の中核として skills/eval-guide/playbook.md を使用します。また、補足的なシナリオパターンと品質の評価軸を定義する AI Agent Evaluation Scenario Library（github.com/microsoft/ai-agent-eval-scenario-library）と、ステップ 7 の診断フレームワークを提供する Triage & Improvement Playbook（github.com/microsoft/triage-and-improvement-playbook）と連携して動作します。

関連する評価スキル

トリアージ後に必要なこと	使用するスキル
トリアージ中に特定した新しいシナリオを使って評価計画を作成または拡張する	/eval-suite-planner
拡張または改訂したシナリオの新しいテストケースを生成する	/eval-generator
新しい CSV から対話型のトリアージなしで、簡潔で構造化されたレポートを取得する	/eval-result-interpreter
トリアージ中に生じた方法論に関する質問に回答する	/eval-faq
評価パイプライン全体を最初から最後まで顧客に案内する	/eval-guide