検証済みシナリオ
検証済みシナリオは専門家の判断を残し、Agent の変更後にもチームが同じ判断を再確認できるようにします。
Agent には instructions、情報源、ツールがあります。シナリオは、それらが認識できる仕事の状況でどのような結果を出すかを示します。両方が必要です。Instructions だけでは動作が推測のままになり、定義した仕事がない case set は散らばったチェックリストになります。
実際の仕事から始める
次に行う判断を代表するシナリオを選びます。次の四つに分けます。
- Core scenarios：Agent が今対応する仕事
- Boundary scenarios：確認、注意、専門家レビューが必要な仕事
- Out-of-scope scenarios：Agent が拒否、handoff、または別の場所へ案内する仕事
- Action scenarios：ツール、form、payment、booking、API call、別の Agent が必要な仕事
理想的な質問だけに限定しないでください。安全な first scope では、情報不足や人が担当すべき依頼への動作も確認します。
Case set を判断に合わせる
すべての Agent に共通する最初の固定件数はありません。次の判断に十分な証拠を提供する最小の set を作ります。
| 段階 | 判断 | 証拠の重点 |
|---|---|---|
| 最初の動作 | この仕事を十分理解し、続ける価値があるか | 実際の状況一つと隣接する境界 |
| 制御された pilot | 小さな利用者範囲が承認済み scope を使えるか | 頻度と影響の大きい must-pass 動作、ツール、handoff |
| 広い rollout | 信頼済みの動作を壊さず、次の version が仕事を広げられるか | 新しい scope と regression、boundary、tool、handoff case |
| 正式な受け入れ | 何が提供されたかについて関係者が合意できるか | 固定した Agent version、case set、Standards、must-pass case、既知の制限、結果記録 |
頻度と影響で case を選びます。まれでも、誤りが安全、金銭、サービス、信頼に大きく影響する場合は must-pass にします。
各シナリオを case にする
Test Suite の有用な case には次が含まれます。
- 現実的な
Input - 十分な会話または仕事の context
- 回答が行うこと、避けることを示す
Standard - Agent が仕事を完了すべきでない場合の handoff 条件
Ideal Response は任意です。例が review を大きく改善する場合に使い、一つのサンプル回答で品質条件を置き換えないでください。
強い Standard は観察可能です。別の reviewer が結果を見て、作者の意図を推測せず pass または fail を判断できるようにします。
退行してはいけない動作を指定する
失敗した場合に公開を止めるべき case を must-pass とします。典型的な理由は次のとおりです。
- Agent の仕事の中心となる動作である。
- 誤りが影響の大きい行動や主張につながる。
- Agent が続けず handoff する必要がある。
- 承認済み pilot または受け入れ境界の一部である。
すべての case が公開を止める必要はありません。診断用の coverage とリリース条件を分け、探索中のことと必ず正しく保つことを両方見えるようにします。
Agent を変更する前に診断する
Case が失敗した場合、どの契約が誤っているか、不完全かを判断します。
Standardが誤った結果を要求する場合はStandardを直す。- 判断ルールが不明確な場合は
Instructionsを直す。 - 必要な情報源がない、古い、取得しにくい場合は Knowledge Base を直す。
- アクションまたは呼び出し境界が誤っている場合はツールを直す。
- 承認済み scope 外の場合は安全な fallback を保つ。
その case が実際の一般ルールを表す場合を除き、一つの case だけを合格させる狭い instruction を追加しないでください。
Version ごとに scope を広げる
Agent により多くの仕事を扱わせる場合は、次の順番で進めます。
- 新しい状況と Standards を追加する。
- 次のリリースで must-pass となる case を確認する。
- Failure が必要性を示した instructions、情報源、ツールだけを更新する。
- 影響する case を実行する。
- 信頼済みの動作に影響する可能性がある場合は、広い regression case を実行する。
- リリース条件を満たしてから新しい version を公開する。
この流れにより、修正は prompt patch の連続ではなく、積み重なる専門資産になります。
責任を明確に保つ
- 専門家または責任者が品質条件と境界を承認する。
- 運用担当者が実際の pattern から case を作成し、維持する。
- 実装担当者が情報源とツールを接続する。
- Release reviewer が must-pass 条件を満たしたか判断する。
一人が複数の役割を担当しても、各判断の責任は見える状態にします。