本番の訂正をテストケースへ変える「失敗回収票」

顧客対応AIの回答を担当者が訂正したのに、数週間後、似た条件で同じ誤りが再発する。AIプロダクト責任者や基盤担当者に必要なのは、修正依頼を増やすことではなく、訂正を回帰テストへ変える仕組みです。本稿では、そのための「失敗回収票」と週次フローを紹介します。

訂正は、そのままではテストにならない

生成AIは同じ入力でも出力が変わるため、従来型テストだけでは振る舞いを捉えきれません。評価は、目的、データ、判定方法を組み合わせた構造化テストとして設計する必要があります[1]。本番ログや利用者の指摘は有力な材料ですが、個人情報を含む会話や担当者の感覚をそのまま登録しても、再現も判定もできません。

まず、訂正を「誰が悪かったか」ではなく「次回は何を機械的に検出するか」に変換します。障害後に原因と再発防止策を記録するポストモーテムも、再発を減らす行動項目まで持って初めて機能します[2]。AIの小さな誤りにも、同じ考え方を軽量に適用します。

コピーして使える「失敗回収票」

受付担当は、次の票を1件につき1枚作ります。元の会話はアクセス制御された保管先に置き、評価セットには再現に必要な最小情報だけを残します。

case_id: FC-0001
detected_by: user_feedback | operator_review | monitor
task: AIが何をする場面か
input_snapshot: 匿名化した最小の再現入力
actual_output: 問題がある出力
expected_behavior: 満たすべき振る舞い
failure_type: retrieval | reasoning | tool | policy | format
severity: S1 | S2 | S3
reproducible: yes | no
grader: exact_match | rule | human_rubric
owner: 担当者名
evidence: 管理された原本への参照
status: intake

すべてを回帰テストにしてはいけません。表現の好みだけなら記事・UIの改善候補へ、仕様が未決ならプロダクト判断へ、外部ツールの誤更新なら権限や契約テストへ送ります。安定した期待値を置けて、再発時の損失がある案件だけを評価ケースにします。

5段階で回す週次フロー

1. 受付と最小化：個人名、契約番号、自由記述を削り、誤りが残る最小入力を作ります。
2. 再現：現行版で問題を再現します。再現しなければ、条件不足として票を戻します。
3. 期待値と判定器の決定：完全一致、ルール判定、人手ルーブリックのいずれかを選びます。自由文の良し悪しを雰囲気で判定しません。
4. 失敗するテストを先に登録：修正前に落ちることを確認してから、プロンプト、検索、ツール、仕様のうち原因に最も近い箇所だけを直します。
5. 周辺ケースを含めて検証：対象ケースと既存の回帰セットを実行し、合格、担当者、根拠リンクがそろった時点で完了にします。

自動採点しやすい形へ構造化し、人の判断で判定基準を校正する方法が推奨されています[1]。また、Google SREの公開例でも、障害後の行動項目として回帰テストの追加が明記されています[3]。つまり、修正と再発検知は別の成果物として管理します。

具体例：割引条件の誤要約を回収する

たとえば、営業支援AIが「更新割引は年契約のみ対象」という社内規定を、「更新顧客は割引対象」と要約した場面を考えます。担当者が文章だけを直すと、月契約の別顧客で同じ誤りが起こり得ます。

受付担当は、固有名を除いた年契約と月契約の2ケースを作ります。期待値は「年契約=true、月契約=false」、判定器は構造化出力の真偽値一致です。現行版で月契約が誤ってtrueになることを確認し、参照範囲または指示文を修正します。その後、2ケースと既存の割引関連ケースを実行し、すべて合格したら票を閉じます。

この方法は、正解が毎回変わる創作業務や、合否基準を共有できないという場合には向きません。ただし、重大な安全・権限事故は、完全な自動採点が難しくても人手評価ケースとして残します。

明日から使える実装チェックリスト

• 訂正の受付先が一つに決まっている
• 原本と匿名化した評価入力を分離している
• 現行版で失敗を再現できる
• 期待する振る舞いを一文で書ける
• 判定器と合格条件が決まっている
• 修正前にテストが落ち、修正後に通る
• 周辺ケースを壊していない
• 担当者と根拠リンクを残している

まずは明日、直近の訂正を1件だけ選び、この票へ移してください。週次会議では件数ではなく、「再現できたか」「判定できるか」「回帰セットに入ったか」の三点で完了を判断します。

参考資料

1. OpenAI, Evaluation best practices
2. Google SRE, Postmortem Culture: Learning from Failure
3. Google SRE, Example Postmortem

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-10-07。