Evaluations and Improvements

Test Suite の役割は、良さそうに見える修正が別の場所で静かな regression を起こしていないかを止めることです。

operator にとって最も強い case は、作り物の prompt ではなく、実際に user や stakeholder にとって重要だった会話から生まれます。

Step 1: 実際の失敗から始める

最短ルートは次の通りです。

1. Histories で risky な thread を開く
2. stakeholder feedback または問題の返信を読む
3. Copilot に原因を聞く
4. 問題が instructions、tools、data のどこにあるか判断する

二度と逃したくない失敗だと分かったら、case に保存します。

Step 2: history thread から Add Case を使う

history thread で Add Case を押します。

これが速いのは、元の入力がそのままあり、守りたい失敗がすでに明確だからです。

Step 3: Standard を checklist として書く

case detail では Standard が特に重要です。

曖昧な理想ではなく、確認可能な checklist にしてください。

弱い例:

• Should answer well

強い例:

• Must ask at least one clarifying question before recommending a consultation
• Must not jump straight to booking
• Must mention callback when urgency or uncertainty is high

判断できる standard にする

良い standard は、別の operator が返信を読んでも、何をもって pass かを推測せず判断できるものです。

Step 4: 信頼したい version に対して Test Suite を走らせる

case が揃ったら、今の working version に対して Test Suite を実行します。

見るべきことは二つです。

• 修正した case が通るようになったか
• 以前強かった case が悪化していないか

Step 5: Agent を直して、重要 case が安定するまで回す

case が落ちたら、一つの具体的な変更に結びつけます。

• Instructions のルールを書き直す
• tool の When to Use を締める
• 足りない知識を Knowledge Base や Attachments に移す
• Agent 間の handoff 境界を見直す

その上で同じ case set を再実行します。目的は全ケース満点ではなく、重要な挙動を release 前に安定させることです。

Operator 向けの実用ルール

• 最初は巨大な表ではなく、少数の高価値 case から始める
• trust、routing quality、高コストな handoff mistake に関わる失敗を先に守る
• QA 用に作った文より、実際の user language を優先する
• これをもう二度と外したくない と思ったら、その場で case にする

Publish してよいタイミング

重要 case で必要な挙動が出ていて、すでに信頼している挙動を壊していないなら publish してよい段階です。

評価の本当の仕事は、点数のための点数ではなく、今回の release が前回より安全だと示す証拠を作ることです。

関連ガイド

• Collect Feedback
• Version Management
• Histories