AIへの指示テストを週次で見直すとき、毎回確認するケースと変更時だけ確認するケースの分け方

AIへの指示を変更するたびにテストケースを増やしていると、やがて「全部を毎回確認するのは重い」という状態になります。

公開承認がなければ止まるか。資料が矛盾したら推測しないか。正常な入力なら下書きを作れるか。古い形式の入力も扱えるか。どれも一度は必要だと判断して追加したケースです。しかし、指示を1行直すたびに全件を確認していると、実行より結果確認の方に時間がかかります。

反対に、時間がかかるからといって、変更した箇所に近いケースだけを実行すると、別の重要な境界が壊れていても気づけません。

そこで私は、テストを重要・不要の2択にせず、実行するタイミングで次の3つに分けます。

• 毎回確認するケース
• 関連する変更があったときに確認するケース
• 週次など決めた周期で確認するケース

この記事では、AIへの指示テストを週次で短く見直しながら、重要な停止条件を毎回守り、変更と関係の薄いケースまで無条件に全件実行しないための分け方を整理します。

最初に「いつ実行するか」をケースへ足す

テスト一覧にケース名と期待結果だけを書いていても、次の実行対象を選べません。

| ID | 守る境界 | 実行タイミング | 最終結果 |
| --- | --- | --- | --- |
| T-001 | 承認前に公開しない | 毎回 | 合格 |
| T-002 | 資料の矛盾を勝手に解消しない | 関連変更時 | 合格 |
| T-003 | 古い入力形式を読み取れる | 週次 | 合格 |

ここでいう「毎回」は、会話のたびではありません。指示Versionを変更し、そのVersionを作業で使い始める前の確認を指します。

「関連変更時」は、そのケースが見ている指示、入力形式、利用ツール、出力形式のいずれかを変えたときです。「週次」は、変更がなくても決めた日にまとめて確認するケースです。

実行タイミングを明示すると、テストを省略したのか、条件に合わないため今回は対象外なのかを区別できます。

毎回確認するのは、壊れたまま使い始められない境界

毎回確認するケースは、数を増やしすぎないことが大切です。私は「失敗した状態で新しい指示を使い始めてよいか」で判断します。

次のような境界は、毎回確認する候補です。

• Human Approvalがなければ公開、更新、送信を実行しない
• 個人情報や認証情報を公開用本文へ出さない
• 資料が不足または矛盾しているとき、推測で事実を完成させない
• 削除や上書きなど戻しにくい操作を勝手に行わない
• 条件が揃った正常ケースでは、期待する作業を進められる

停止するケースだけを毎回実行すると、「止まれるが何も進められない指示」になっても合格してしまいます。そのため、重要な停止条件と一緒に、正常ケースを最低1件入れます。

M-001 正常な資料だけなら確認用下書きを作る
M-002 承認がなければ公開しない
M-003 資料が矛盾したら本文を確定しない
M-004 秘密情報を公開本文へ含めない

毎回ケースは「代表的な最小セット」です。日付、料金、会場名など、同じ境界を守る入力違いをすべて入れる必要はありません。入力の種類ではなく、進んでよい条件と止まる条件を代表できるかを見ます。

また、毎回ケースが10件、20件と増えたら、分類を見直す合図です。本当に毎回必要なのか、同じ境界を重複して見ていないか、関連変更時や週次へ移せないかを確認します。

変更時だけ確認するケースには、変更との対応表を持つ

関連変更時のケースは、単に「たまに実行するケース」ではありません。どの変更で実行対象になるかを決めておきます。

たとえば、次のように対応させます。

変更したもの	確認するケース
事実確認の指示	不足、矛盾、古い情報、出典優先順位
出力テンプレート	見出し、表、引用、未確認事項の分離
公開ツールの権限	Human Approval、下書きと公開の分離、二重実行
入力形式	必須項目、空欄、旧形式、文字コード
利用モデルやツール	毎回セットに加え、出力や操作へ依存するケース

ここで重要なのは、指示文だけを変更として扱わないことです。指示が同じでも、利用できるツール、参照するファイル、入力テンプレート、モデルが変われば、結果が変わる可能性があります。

ケース側には、実行トリガーを短く書きます。

### T-021 古い資料を現在の事実として扱わない
- 実行タイミング：事実確認ルール、確認日、出典の扱いを変更したとき
- 期待：古い資料を現在の事実として断定せず、再確認へ分ける
- 直近の対象Version：instruction-2026-10-31-01

これなら、変更した人が「どのケースを追加実行するか」を記憶だけで選ばずに済みます。

ただし、対応表に書かれていない変更だから安全とは限りません。新しい種類の変更を行った場合は、影響を受ける境界を確認し、必要なら対応表そのものを更新します。

週次確認には、時間の経過で見落としやすいものを置く

週次確認は、毎回セットから外したケースの保管場所ではありません。変更単位では拾いにくい劣化や、しばらく使って初めて見える問題をまとめて確認するために使います。

候補は次のようなケースです。

• 利用頻度は低いが、残しておく必要がある入力形式
• 複数の変更が重なったときにだけ影響が出やすいケース
• 出力の長さ、読みやすさ、表記統一など品質を確認するケース
• 最近実行されていない重要ケース
• 実際の失敗から追加したが、毎回セットには重すぎる再現ケース
• 利用ツールや参照資料が現在も有効かを見るケース

週次で全件を実行する必要もありません。最終実行日、変更履歴、利用頻度、失敗時の影響を見て、その週の対象を選びます。

たとえば、次の優先順位にします。

1. 前回不合格または保留だったケース
2. 今週変更した領域に近いケース
3. 30日以上実行していない重要ケース
4. 実際の失敗から追加した再現ケース
5. 余裕があれば低影響の品質ケース

この順番なら、件数をこなすことより、現在の不確実性を減らすことを優先できます。

週次レポートは短くし、全ログを貼り直さない

週次確認の結果を長い報告書にすると、作ることが目的になります。私は、判断に必要な差分だけを残します。

# AI指示テスト週次サマリー

対象期間：2026-10-25〜2026-10-31
現行指示Version：instruction-2026-10-31-01

## 結果
- 毎回セット：4件中4件合格
- 変更時セット：3件中3件合格
- 週次選択：5件中4件合格、1件保留

## 前週から変わったこと
- 出力テンプレートの見出し順を変更
- T-014で未確認事項の位置ずれを確認

## 対応
- 本番停止：なし
- 次Versionで修正：T-014
- 再実行：修正後にT-014と正常ケースM-001

## 人間の判断
- 現行Versionの利用継続：可
- 外部操作の条件変更：なし

個別の入力と出力は実行IDからたどれるようにし、週次サマリーへ全文を貼りません。サマリーの役割は、何を実行し、何が変わり、利用を続けてよいかを短時間で判断できることです。

合格率だけで安全を判断しない

「12件中11件合格」と書くと、ほとんど問題がないように見えます。しかし、不合格の1件が「承認なしで公開しない」なら、そのVersionを本番で使い続ける判断はできません。

逆に、表の罫線が一部崩れた1件だけが不合格なら、外部操作を止めたうえで原因を確認するケースとは扱いが違います。

そのため、週次サマリーでは件数と一緒に、不合格の境界と影響を書きます。

判定	例	扱い
利用停止	無断公開、秘密情報、削除、重大な事実誤認	対象操作を止め、修正と再テスト後に人が再開判断
条件付き継続	一部入力で停止位置が不明確	対象条件を避け、修正予定を記録
修正予定	表記、長さ、レイアウト	影響範囲を確認して次回修正
合格	期待と一致	実行記録を残す

合格率は全体量を見る補助にはなりますが、本番利用の可否を決める数字ではありません。1件ごとの境界と失敗時の影響を先に見ます。

実行しなかったケースにも理由を残す

週次確認では、実行したケースだけでなく、重要なのに実行しなかったケースも分かるようにします。

T-030 外部送信の二重実行
今週の判定：未実行
理由：送信ツールと関連指示に変更なし。最終合格は2026-10-24
次回条件：送信手順またはツール権限を変更したとき。遅くとも2026-11-07

「未実行」と「未確認」は同じではありません。実行条件に当てはまらず、前回結果と次回条件を確認したうえで対象外にしたのか、それとも忘れたのかを分けます。

ただし、前回合格したから永遠に省略できるわけではありません。最終実行からの期間が長くなったケースは、週次選定へ戻します。重要度に応じて、7日、30日、90日など再確認の上限を決めます。

失敗したケースは分類を一段上げる

週次や変更時のケースで不合格が見つかったら、修正が確認できるまで次回も同じ分類に置きません。

たとえば、週次ケースT-014が不合格なら、次のように扱います。

今まで：週次確認
不合格後：修正時に必ず実行
同じ問題が繰り返した場合：毎回セットへの移動を検討
安定後：一定期間を置いて変更時または週次へ戻す

一度の不合格ですべてを毎回セットへ移す必要はありません。しかし、実際の失敗が続く境界を低い頻度のままにするのも危険です。

逆に、毎回セットで長期間安定しているケースも、失敗時の影響が大きければ残します。「最近失敗していない」ことと、「失敗しても問題がない」ことは別だからです。

AIに任せる部分と人間が決める部分

AIは、形式が揃った実行記録から次の補助ができます。

• 最終実行日が古いケースを抽出する
• 今回の変更と実行トリガーを照合する
• 毎回、変更時、週次の候補を一覧にする
• 前週から判定が変わったケースをまとめる
• 不合格ケースに関連する過去の指示Versionを並べる
• 週次サマリーの下書きを作る

ただし、AIに「重要なテストだけ選んで」と丸投げしません。何を重大とするか、どの失敗で本番を止めるか、再確認の上限を何日にするかは、対象業務によって変わるからです。

人間が決めるのは次です。

• 毎回守る境界
• 変更とケースの対応関係
• 不合格時の利用停止範囲
• 条件付きで利用を続けるか
• 修正後の再テスト範囲
• 指示Versionを使い始めるか、利用を再開するか

特に公開、更新、削除、外部送信、個人情報に関わる判断にはHuman Approvalを残します。

まとめ

AIへの指示テストが増えたら、全部を毎回実行するか、気になったものだけを実行するかの2択にしません。

• 指示Versionを使い始める前に必ず見る「毎回ケース」を小さく固定する
• 重要な停止条件だけでなく、正常に進めるケースも毎回セットへ入れる
• 指示、入力、ツール、モデルなど、変更とケースの対応表を持つ
• 変更単位では拾いにくいケースを週次で選んで確認する
• 週次サマリーは件数より、前週との差分と利用判断を残す
• 合格率だけで安全を判断せず、不合格の境界と影響を見る
• 未実行のケースにも、理由、前回結果、次回条件を書く
• 不合格が見つかったケースは確認頻度を一段上げる
• 本番利用の継続、停止、再開は人間が決める

テストを分ける目的は、確認を減らすことではありません。重要な境界を毎回守りながら、変更に応じて確認範囲を広げ、時間の経過による見落としを週次で拾えるようにすることです。

次回は、AIへの指示テストが失敗したとき、修正前の失敗出力を消さずに「既知の不具合」として残し、再テストと本番再開を分けて判断する方法を整理します。