AIへの指示テストが失敗したとき、失敗出力を消さずに「既知の不具合」として残す方法
AIへの指示をテストして不合格が見つかると、すぐ指示を書き直し、うまくいった出力だけを残したくなります。
しかし、修正前の出力を消すと、何が壊れ、どの修正で直ったかを確認できません。修正版が1回合格しただけでは、本番再開の材料も不足します。
そこで私は、AIへの指示テストが失敗したとき、次の3つを分けます。
- 失敗を再現できる記録
- 修正が効いたかを確かめる再テスト
- 本番利用を再開する人間の判断
この記事では、失敗出力を責任追及の材料ではなく「既知の不具合」として残し、修正作業と本番再開を混ぜないための小さな運用を整理します。
不合格を見つけた直後は、まず対象操作を止める
テストが失敗したら、最初に指示文を書き換えるのではなく、失敗した境界と影響を確認します。
たとえば「Human Approvalがないのに公開処理へ進んだ」という失敗なら、原因が分かるまで公開操作を止めます。「表の列幅が崩れた」という失敗なら、外部公開を一律に止める必要はなくても、該当する出力形式の利用を保留できます。
私は不合格を、少なくとも次の3段階に分けます。
| 影響 | 例 | 最初の対応 |
|---|---|---|
| 重大 | 無断公開、秘密情報の出力、削除、重大な事実誤認 | 対象操作を停止し、人へ連絡 |
| 限定 | 特定入力だけで停止位置がずれる、未確認事項が本文へ混ざる | 該当条件を避け、利用範囲を制限 |
| 軽微 | 表記、長さ、レイアウトの乱れ | 記録して修正予定へ入れる |
20件中19件が合格しても、残り1件が「承認前に外部送信しない」なら、その操作を安全とは判断できません。
停止範囲は、失敗した境界の影響に合わせます。文章校正の不合格で全作業を止める必要はありませんが、公開や削除の境界が壊れたまま本番利用を続けることもできません。
失敗出力は、入力と期待値を組にして残す
失敗した文章だけを保存しても、その出力がなぜ不合格なのかをあとから判断できません。最低限、次を同じ記録へ残します。
# 既知の不具合 K-012
## 発見
- 発見日時：2026-11-01 09:20 JST
- 指示Version：instruction-2026-10-31-01
- テストケース：T-014 r2
- 実行ID：R-118
## 条件
- 入力：確認済み情報と未確認情報が混在する取材メモ
- 期待：未確認情報を本文へ入れず、確認事項へ分離する
- 実際：未確認の開催時刻を本文中で断定した
## 影響
- 境界：未確認情報を事実として公開しない
- 停止範囲：この指示Versionによる公開用本文の確定
- 暫定対応：下書き作成までに制限し、人が全事実を確認する
## 状態
- 状態：調査中
- 担当：本人
- 次の確認：同じ入力で再現後、原因候補を1つずつ確認
個人情報や認証情報は公開リポジトリへ保存せず、再現に不要な値を置き換えます。失敗出力は、次の修正で同じ条件を再現し、境界が戻ったかを比べるために残します。
可能ならテキストで保存し、指示Version、ケースID、入力Revision、モデルやツール、実行日時も結びつけます。
「既知の不具合」には状態を付ける
失敗記録を作ったら、現在の状態が分かるようにします。私は次のような状態を使います。
open 未対応。影響と停止範囲を確認中
investigating 原因候補を調査中
fixing 修正案を作成中
retesting 修正版を再テスト中
resolved 修正と必要な再テストが完了
accepted 制限を明示し、人が当面の利用を承認
resolved は「指示を書き換えた」ではありません。失敗ケースが合格し、関連する正常ケースと停止ケースも確認できた状態です。
accepted は、直せない問題を無かったことにする状態でもありません。たとえば低頻度の旧入力形式に限って表示が崩れるが、対象形式を受け付けない運用を明示できる場合などに、制限、期限、再確認条件を人が決めて使います。
状態を変更したら、日時、変更者、根拠となる実行IDを残します。
| 日時 | 変更 | 根拠 |
|---|---|---|
| 2026-11-01 09:20 | open | R-118で初回不合格 |
| 2026-11-01 10:10 | investigating | R-119で再現 |
| 2026-11-01 13:40 | retesting | 修正版instruction-2026-11-01-02 |
| 2026-11-01 14:15 | resolved | R-124〜R-127が合格 |
これにより、現在使っている指示Versionに未解決の不具合があるか、どこまで利用を止めているかを一覧から確認できます。
修正前に、同じ条件で再現する
AIの出力には揺らぎがあります。1回の不合格だけを見て指示を大きく書き換えると、偶然の出力に過剰反応することがあります。
まず、保存した入力と同じ指示Version、同じツール条件で再実行します。ただし、同じ結果が一字一句出ることを求めません。確認するのは、同じ境界を破るかどうかです。
期待する停止：未確認の時刻を本文へ入れず、確認事項へ分ける
1回目の失敗：未確認時刻を本文で断定
再現確認：表現は違うが、再び本文で断定
判定：同じ境界の不合格を再現
再現しなかった場合も記録は削除せず、入力、指示Version、モデル、ツール、参照資料などの差を確認します。重大な境界なら、1回再現しなかっただけで本番利用を再開しません。
原因候補を調べるときは、条件を一度に複数変えません。指示文、入力形式、参照資料、利用ツールを同時に変えると、何が効いたのか分からなくなります。
修正案は、失敗を隠す文章ではなく境界を明確にする
不合格が見つかると、「絶対に間違えないでください」「慎重に確認してください」という注意を足しがちです。しかし、注意を強めるだけでは、AIがどこで止まるべきかを検証できません。
修正では、入力、進行条件、停止条件、出力を明確にします。
入力に確認状態がない項目が含まれる場合：
1. その項目を公開用本文へ入れない
2. 「確認が必要な項目」へ、元の表現を変えずに列挙する
3. 推測で値を補わない
4. 本文確定と公開操作へ進まない
修正理由には、対応する既知の不具合IDを書きます。
指示Version：instruction-2026-11-01-02
変更理由：K-012で未確認情報が本文へ混入したため
期待する変化：未確認項目を確認事項へ分離する
維持する境界：確認済み情報だけなら下書きを作成できる
最後の「維持する境界」が重要です。停止条件を強くしすぎると、確認済み情報だけの正常な入力でも何も作れなくなることがあります。
再テストは、失敗ケースだけで終わらせない
修正版で最初に実行するのは、保存した失敗ケースです。同じ入力で期待する停止ができるかを確認します。
しかし、その1件が合格しただけでは不十分です。少なくとも次の順番で確認します。
- 失敗したケースを同じ入力で再実行する
- 境界に近い入力違いを確認する
- 正常な入力で作業を進められるか確認する
- 関連する重要な停止条件を確認する
- 必要なら実際のツールを使わない安全な模擬操作で確認する
たとえば未確認情報の分離を直したなら、未確認項目が1件の場合だけでなく、確認済みと未確認が混在する場合も見ます。同時に、すべて確認済みの入力では本文が作れることを確認します。
| ケース | 確認すること |
|---|---|
| 元の失敗 | 同じ不具合が直ったか |
| 近接ケース | 表現や件数が違っても境界を守るか |
| 正常ケース | 止まりすぎず、本来の作業を進められるか |
| 重要な停止 | 承認、秘密情報、外部操作の境界を壊していないか |
AIに再テスト結果を要約させることはできます。ただし、AI自身の「修正できました」という説明を合格判定には使いません。期待値と実際の出力を人が比較します。
修正完了と本番再開を別の判断にする
再テストが合格すると、そのまま本番へ戻したくなります。しかし、「不具合が修正された」と「対象操作を再開してよい」は別の判断です。
本番再開前に、次を確認します。
# 本番再開チェック
- 既知の不具合：K-012
- 修正版：instruction-2026-11-01-02
- 再テスト：R-124〜R-127
- 元の失敗ケース：合格
- 正常ケース：合格
- 関連する重大境界：合格
- 未解決の制限：なし
- 再開する操作：公開用本文の確定
- 公開操作：引き続きHuman Approval必須
- 再開承認：本人 / 2026-11-01 14:30 JST
外部公開、更新、削除、送信、個人情報を扱う操作では、修正した人と再開を承認する人が同じ場合でも、判断を別の行として残します。
全面再開だけでなく、下書き作成だけを再開する、特定の入力形式を一時的に受け付けない、といった段階的な再開もできます。
解決後も再発確認へつなげる
resolved にした不具合は、すぐ一覧から削除しません。元の失敗ケースを回帰テストとして残し、重要度に応じて毎回、関連変更時、週次のいずれかへ入れます。
重大な境界なら、一定期間は確認頻度を上げます。
解決直後：指示Version変更のたびに実行
4週間安定：関連する指示・入力・ツール変更時に実行
継続確認：週次または月次で最終実行日を確認
再発時：対象操作を再停止し、毎回ケースへ戻す
頻度を下げるときも、「最近失敗していないから」だけで決めません。失敗時の影響、利用頻度、自動検出できるか、変更の多さを見て人が判断します。
既知の不具合とテストケースを結びつけておくと、テストがなぜ残っているのかも分かります。背景が分からない古いケースを、見た目が似ているという理由だけで削除することを防げます。
AIに任せる部分と人間が決める部分
記録形式が揃っていれば、AIは次の補助ができます。
- 失敗出力と期待値の差を整理する
- 同じ境界に関する過去の不具合を探す
- 指示Version間の変更点をまとめる
- 再テスト候補を、失敗、近接、正常、停止条件に分ける
- 未解決の不具合と停止中の操作を一覧にする
- 解決済み不具合の最終再テスト日を抽出する
ただし、AIに「重大かどうか判断して直して再開して」と一括で任せません。原因候補の整理、修正案、テスト候補は出せても、実際の業務への影響と受け入れ可能な制限は人間が決める必要があります。
人間が決めるのは次です。
- 不合格時にどの操作を止めるか
- 暫定対応で利用を続けてよいか
- 修正案が守るべき境界を変えていないか
- 再テストの範囲が十分か
- 未解決の制限を受け入れるか
- 本番利用をいつ、どの範囲で再開するか
特に外部へ影響する操作の停止と再開には、Human Approvalを残します。
まとめ
AIへの指示テストが失敗したら、修正版の成功だけで上書きしません。
- 不合格の境界と影響を見て、停止、利用制限、修正予定へ分ける
- 失敗出力を、入力、期待値、指示Version、実行条件と一緒に残す
- 既知の不具合へ状態、停止範囲、暫定対応を付ける
- 修正前に同じ条件で再現し、条件を1つずつ調べる
- 注意文を増やすのではなく、進行条件と停止条件を明確にする
- 修正版では、元の失敗、近接、正常、重要な停止ケースを確認する
- AIの自己評価ではなく、人が期待値と実際の出力を比べる
- 修正完了と本番再開を別の判断として記録する
- 解決後は回帰テストへ結びつけ、再発時に確認頻度を上げる
失敗記録を残す目的は、過去の間違いを責めることではありません。次の修正が本当に効いたかを確かめ、安全に再開できる条件を人間が判断できるようにすることです。
次回は、既知の不具合が増えたとき、重大度、再発性、検出しやすさから修正の優先順位を決める方法を整理します。