AIへの指示テストが増えたとき、残す・まとめる・削除する基準

AIへの指示を変更するたびにテストケースを追加すると、最初は安心できます。

資料が不足した場合、内容が矛盾した場合、公開承認がない場合、個人情報が混ざった場合。過去に失敗した入力を残しておけば、同じ問題が戻っていないかを確認できます。

しかし、ケースが増え続けると別の問題が起きます。

• 似たケースを何度も確認する
• 何を守るテストなのか分からなくなる
• 古い指示を前提にしたケースが残る
• 実行と確認に時間がかかり、重要なテストが埋もれる
• 失敗しても、本番を止めるべきケースか判断できない

そこで私は、増えたテストを件数だけで管理せず、守っている境界と失敗時の影響から、次の3つに分けます。

• そのまま残す
• 代表ケースへまとめる
• 条件を確認したうえで削除する

この記事では、テストを減らすこと自体を目的にせず、本番で守りたい境界を失わないための整理方法をまとめます。

テストケースの役割を1行で書く

整理を始める前に、それぞれのテストが何を守っているかを書きます。

ケース名：開催日の矛盾
守る境界：資料が食い違うとき、AIが片方を勝手に採用しない
失敗時の影響：誤った開催日を公開する可能性がある
期待する動き：両方の値と出典を示し、本文を完成させず停止する

「日時テスト」「確認テスト」のような名前だけでは、似ているかどうかを判断できません。入力の違いではなく、守る境界を見ます。

たとえば、開催日が異なるケースと、料金が異なるケースは入力内容が違います。しかし、どちらも「複数の資料が矛盾したとき、AIが独自に片方を採用しない」という同じ境界を確認している可能性があります。

反対に、同じ日付を使うテストでも、片方は資料の矛盾、もう片方は古い情報の再利用を防ぐケースかもしれません。見た目が似ていても、守る境界が違えば安易にまとめません。

まず一覧へ揃える

ケースが複数のメモや会話に分かれていると、重複を見つけられません。最低限、次の項目を一覧にします。

項目	内容
ケースID	後から参照できる短い識別子
守る境界	何を防ぐか
入力条件	正常、不足、矛盾、承認など
期待する動き	進む、止まる、確認を返す
失敗時の影響	読者、公開、個人情報、安全など
由来	訂正記録、事故、設計上の予防
最終実行日	いつ確認したか
対象の指示Version	どの指示に対するテストか

由来を残すことが重要です。実際の訂正や公開事故から追加したケースは、単なる思いつきより削除の判断を慎重にします。

また、現在の指示では使わない項目が含まれていても、その場で消しません。古い指示の履歴として必要なのか、現在のテストへ移行できるのかを確認します。

| ID | 境界 | 条件 | 期待 | 影響 | 由来 | 指示Version |
| --- | --- | --- | --- | --- | --- | --- |
| T-01 | 不足を推測しない | 開始時刻なし | 停止 | 誤案内 | Vol.87 | 2026-10-28 |
| T-02 | 矛盾を自動解決しない | 日付が不一致 | 停止 | 誤案内 | 訂正記録 | 2026-10-28 |
| T-03 | 承認前に公開しない | 公開依頼、承認なし | 停止 | 無断公開 | 運用境界 | 2026-10-28 |

そのまま残すケース

次のケースは、原則として個別に残します。

実際の誤りから作ったケース

公開後の訂正、誤送信、誤った更新など、現実に起きた問題を再現するケースです。原因と期待する停止位置が分かる形で残します。

実際の個人情報や機密情報はテスト材料へ残しません。構造を保った架空データへ置き換え、元の記録への参照だけを管理します。

失敗時の影響が大きいケース

• Human Approvalなしの公開や更新
• 個人情報、認証情報、未公開情報の出力
• 削除や外部送信
• 安全や権利に関わる誤情報
• 誤った内容の複数媒体への展開

実行頻度が低くても、失敗したときの影響が大きいため残します。

境界値を確認するケース

同じ停止条件でも、止まる直前と進める直前の両方が必要です。

ケースA：公開承認の記録なし → 公開せず停止
ケースB：対象、公開範囲、承認者、承認日時が揃う → 公開処理へ進める

停止ケースだけを残すと、指示を強くしすぎて正常な作業まで止めていても気づけません。

代表ケースへまとめられるもの

テストをまとめるのは、入力が似ているからではありません。次の条件が揃う場合です。

1. 守る境界が同じ
2. 期待する停止位置が同じ
3. 失敗時の対応が同じ
4. 片方を省いても別の危険を見逃さない

たとえば、次の3ケースがあるとします。

開催日：資料Aと資料Bで不一致
開始時刻：資料Aと資料Bで不一致
料金：資料Aと資料Bで不一致

すべてが「重要項目の矛盾を検出し、本文へ採用せず確認を返す」ことだけを見ているなら、代表ケースとデータ違いへ整理できます。

代表ケース：重要項目の矛盾
データ1：開催日
データ2：開始時刻
データ3：料金
期待：両方の値と出典を示し、本文生成を停止

ただし、料金だけは読者の支払い判断へ影響し、訂正告知の要否まで確認するなら、別ケースとして残します。共通する入口をまとめても、影響や後続処理が違う部分は分けます。

削除を検討できるケース

テストを削除するには、「最近失敗していない」以外の理由が必要です。

次の条件をすべて確認します。

• 守っていた境界が別のケースで確認されている
• 入力と期待値が完全に重複している
• 過去の訂正や重大な事故に由来していない
• 現在の指示Versionでは到達しない条件である
• 自動検査や入力制約へ移行済みである
• 削除前後で残るテストを実行し、境界が保たれる
• 人間が削除理由を確認した

たとえば、タグ数の上限をAIへ数えさせるテストがあり、その後、公開前スクリプトがタグ数を必ず検査するようになった場合、AI指示のテストからは外せるかもしれません。

ただし、自動検査へ移したことを記録し、検査自体のテストは残します。確認場所が変わっただけで、守る境界を消したわけではありません。

次の理由だけでは削除しません。

• 実行に時間がかかる
• 最近失敗していない
• ケース名が古い
• AIが賢くなったように見える
• 担当者が内容を覚えていない

内容を覚えていないケースは、不要なのではなく、説明が不足している可能性があります。

削除ではなく、保留にする選択肢

現在は使わないが、すぐ削除する根拠もないケースは保留へ移します。

状態：保留
理由：現在の指示では対象機能を使用しない
最終確認：2026年10月29日
再確認条件：対象機能を再開するとき
元の指示Version：2026-09-01版

保留ケースは通常の毎回実行から外せますが、一覧と由来は残します。機能や運用を再開するとき、必要なテストをゼロから思い出さずに済みます。

ただし、保留を無期限の物置にしません。再確認条件または見直し日を付けます。条件がなく、誰も説明できないケースが増えたら、改めて削除候補として確認します。

実行頻度を分ける

すべてのケースを毎回実行する必要はありません。重要度と変更範囲で頻度を分けます。

種類	実行するタイミング
基本ケース	指示を変更するたび
重大境界	公開・更新・削除・送信に関する変更時
記事別ケース	対象の記事種別を使うとき
全体回帰	月次、または大きな指示変更時
保留ケース	再開条件を満たしたとき

基本ケースには、正常、不足、矛盾、承認の代表例を置きます。これなら、毎回の確認時間を抑えながら、進む条件と止まる条件を見られます。

大量のケースを一律に減らすのではなく、必要な場面で必要なケースを呼び出す設計にします。

整理後に必ず回帰確認する

まとめたり削除したりしたあと、残したケースを実行します。

整理前：18ケース
代表ケースへ統合：6ケース
記事別へ移動：4ケース
保留：3ケース
通常実行：5ケース

件数が減ったことだけで完了にしません。

• 正常入力で下書きを作れるか
• 不足情報を推測せず止まるか
• 矛盾を片方へ寄せず返すか
• Human Approval前に外部操作しないか
• 重大な過去事例を再現できるか

整理前に守っていた境界が、整理後も確認できることを見ます。

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

AIは、ケース整理の補助に向いています。

• ケース名と期待値を一覧化する
• 同じ境界を扱う候補をまとめる
• 入力だけが違うケースを探す
• 古い指示Versionを参照するケースを抽出する
• 整理前後の境界一覧を比較する

ただし、AIが「似ている」と判断しただけで統合や削除を実行しません。

人間は次を決めます。

• 失敗時の影響を同じとみなせるか
• 実際の訂正や事故に由来するケースを残すか
• 自動検査への移行が完了しているか
• テスト範囲を減らしてよいか
• 保留や削除を承認するか

特に、公開、個人情報、削除、外部送信、安全、権利に関するケースはHuman Approvalなしに削除しません。

テスト整理記録のテンプレート

# AI指示テスト整理記録

## 対象
- 対象の指示Version：
- 整理前のケース数：
- 整理日：

## 境界一覧
| 境界 | 代表ケース | 失敗時の影響 | 由来 | 状態 |
| --- | --- | --- | --- | --- |

## 判断
- そのまま残す：
- 代表ケースへまとめる：
- 記事別へ移す：
- 保留にする：
- 削除候補：

## 削除確認
- 別ケースで境界を確認できる：
- 自動検査または入力制約への移行：
- 過去事例への影響：
- 整理後の回帰結果：

## Human Approval
- 承認者：
- 承認日時：
- 承認した変更：

## 次回
- 次回見直し日：
- 保留ケースの再開条件：

空欄が残る場合、AIに削除理由や承認者を補完させません。統合案や削除候補は作れても、実際の範囲変更は人間が確認してから行います。

まとめ

AIへの指示テストが増えたら、単純に古い順や似た名前で削除しません。

• 各ケースが守る境界と失敗時の影響を1行で書く
• ケースID、期待値、由来、指示Versionを同じ形式へ揃える
• 実際の誤り、重大な影響、境界値を扱うケースは個別に残す
• 守る境界、停止位置、対応が同じ場合だけ代表ケースへまとめる
• 自動検査へ移した場合は、確認場所が変わった記録を残す
• 削除の根拠が足りなければ、再開条件付きで保留する
• 毎回、記事別、月次など、ケースの実行頻度を分ける
• 整理後は件数ではなく、守る境界が残っているかを確認する
• 統合、保留、削除にはHuman Approvalを置く

AIは重複候補や整理案を出せます。しかし、同じリスクとみなせるか、過去の失敗を忘れてよいか、どの確認範囲を維持するかは人間が決めます。

テストを増やし続けることも、減らすことも目的ではありません。必要な境界を、実行できる数のケースで確認し続けることが目的です。

次回は、AIへの指示Versionとテスト結果を一緒に記録し、どの変更から失敗が戻ったかを追えるようにする方法を整理します。