本番で失敗した案件を環境の状態ごと回帰テストに加える
質問文だけでなく、初期データ・規程のバージョン・ツール応答・期待する業務結果を記録する。隔離した環境を毎回初期化し、回答の文面だけで修正できたと判断しない。
用語
- 回帰テスト
- 既知の挙動や失敗に対し、変更後も必要な品質が維持されるか確かめるテスト。
- 初期状態
- 試行を始める前の業務データ、権限、規程、ファイルなどの条件。
- モック
- 外部システムの応答や挙動を評価用に模擬する仕組み。
図と例
失敗案件と期待結果を合意 → 初期状態とツール応答を再現 → 隔離環境を試行ごとに初期化 → 回答と業務結果で採点
仮定の例：住所変更が禁止された出荷済み注文に、AIが「変更しました」と回答した。質問だけでなく、出荷済みの初期状態と更新拒否のツール応答を再現する。修正後は「変更不可を案内した」と「注文の住所が変わっていない」の両方を確かめ、各試行を同じ初期状態から始める。
実際のサービス・製品では
Anthropic
Anthropicは実行履歴と環境の最終結果を区別し、試行をクリーンな環境で分離して評価する方法を説明する。採点器の不備や不必要に固定した経路で、妥当な結果を誤判定しない確認も勧めている。
資料を読む
解説
顧客の担当者と、失敗時の事実・期待結果・判定根拠を合意する。必要な条件を再現できない事例は未再現として残し、モデルを替えただけで原因が解消したとは扱わない。
回帰テストは変更によって既知の失敗が再発していないか確かめるテスト。本番の失敗には利用者の入力以外に、古い注文状態、ツールのタイムアウト、承認の欠落などが関わる。必要な情報を許可された形で抽出し、初期状態と観測した失敗を再現するテストデータへ変換する。評価環境は本番の発注・送信へ接続せず、試行ごとに状態と識別子の範囲を初期化する。モックは外部サービスの重要な拒否や処理状態を再現する必要があり、常に成功する応答では連携品質を証明できない。採点は外部状態や禁止操作の不在も見て、正しい複数の経路を許す。修正に使った事例と独立した確認事例を分ける。
トレードオフ
- 制御したツール応答と初期データで評価する
- 得るもの：失敗条件をそろえて変更前後を比較できる
- 払うもの：模擬した契約と実連携の差を別に検証する必要がある
- 隔離した実サービスの検証環境も使う
- 得るもの：認証や応答の実際の制約を確認できる
- 払うもの：環境の変動、データ初期化、実行費用を管理する必要がある
さらに学ぶ
チェック
出荷済み注文の住所を変更してはいけない案件を評価する。回答が「変更できません」となっただけでなく、何を確認すべき？
- ツール呼び出しの順番が過去の失敗と完全一致したこと
- 文章が以前より長くなったこと
- 毎回同じ初期状態から始め、注文の住所が実際に変わっていないこと
解答と解説
毎回同じ初期状態から始め、注文の住所が実際に変わっていないこと
文章が正しくても、裏で禁止された更新をしていれば業務上は失敗。状態をそろえて結果を検証する。固定の呼び出し順や長い説明は、更新されていないことの証明にならない。