AIにテストケースを洗い出させる｜観点の与え方

「テストは書いた。でも、これで足りているのか自信がない」。 動かしてみて正常に通ったときほど、ふと不安になりますよね。本当に怖いのは、自分が思いつきもしなかった場面で落ちることです。思いつけていれば、テストにできているはずなので。

そういうとき、AIはテストケースの洗い出し相手になります。 ただ、「テストケースを出して」とだけ頼むと、正常系がきれいに並んで終わりがちです。一見ちゃんとしているので安心してしまう。でも、欲しかったのはそこではなく、自分が見落としている異常系や境界値のほうだったりします。

この記事は、AIに「ありそうなテスト」を並べさせるのではなく、自分の視野の外にある観点を引き出すための頼み方の話です。テストの正解をもらうのではなく、抜け漏れに気づくための使い方を、一緒に見ていきましょう。

結論：テストケースの洗い出しでは、①対象の仕様と前提を渡す → ②正常系・異常系・境界値・状態の観点を指定して出させる → ③出てきた案に「他には？」ともう一段深掘りする → ④優先順位を自分でつける、の順で頼みます。AIに完成形をもらうのではなく、自分が思いつかなかった場面を炙り出す相手として使うのがコツ。どれを実際に書くかは、自分で決めます。

テストに「これで全部」という終わりはめったにありません。 だからこそ、漏れをゼロにしようとするより、漏れに気づける確率を上げるほうが現実的です。

「テストケースを出して」がうまくいかない理由

AIは、聞かれたことに「ありそうな答え」を返すのが得意です。 だから「テストケースを出して」と漠然と頼むと、世間でよく書かれる正常系のパターンを中心に、それらしく並べます。それが間違っているわけではありません。ただ、そこには次のような落とし穴があります。

• 正常系に偏るので、肝心の異常系や境界値が薄くなる
• 仕様を渡していないと、一般論のテストになり、その機能固有の事情が抜ける
• 観点を指定していないので、AIも何を網羅すべきか分からないまま並べる
• それらしく見えるので、足りない所に気づく前に満足してしまう

テストでいちばん怖いのは、間違ったテストを書くことより、必要なテストの存在に気づかないことです。書いていないテストは、レビューにも引っかかりません。「無い」ものは、見えないからです。

洗い出しの目的は、テストの一覧を完成させることではありません。 自分が思いつかなかった場面を、表に出すことです。そのために、頼み方を少し変えます。

洗い出しの全体像：4つのステップ

先に流れを出します。この順番で頼むと、AIが「正常系を並べる人」から「抜け漏れを一緒に探す人」に変わります。

ポイントは、②の観点指定です。 ここを省くと、何度頼んでも似たような正常系が返ってきます。逆に、観点さえ渡せば、AIは網羅の手がかりを得て、自分では出てこなかった場面を挙げてくれます。1つずつ見ていきましょう。

ステップ1：仕様と前提を先に渡す

最初にするのは、依頼ではなく対象の共有です。 その関数や機能が「何を受け取って、何をして、何を返すのか」を、AIは知りません。それを渡さないまま頼むと、教科書的だけどその機能には合わないテストになります。

渡すと良いこと：

• 何をする処理か（入力・出力・やりたいこと）
• 入力の種類と範囲（型、必須か任意か、想定される値の幅）
• 満たすべきルール（業務ルール、制約、禁止する状態）
• 失敗してほしい条件（どんな入力はエラーにすべきか）

ただ、関数1個ごとに4項目すべて書こうとすると面倒になり、結局「丸投げ」に戻りがちです。最低ラインは①の入出力を1行渡すこと。「年齢を受け取って料金区分を返す」だけでも、AIは何の処理かを掴めます。ルールや失敗条件は、その機能で効いてくる時だけ足せば十分です。

たとえば「年齢を受け取って料金区分を返す関数。0以上の整数を想定。マイナスや小数は不正値として扱いたい」と渡すだけで、AIは境界（0歳、区分の切り替わる年齢）や不正値（マイナス、小数、文字列）を意識した案を出しやすくなります。 仕様は、テストを狭めるものではなく、その機能固有の落とし穴に近づくための手がかりです。

ステップ2：観点を指定してケースを出させる

仕様を渡したら、「テストケースを出して」ではなく「次の観点ごとに出して」と頼みます。 観点を渡すかどうかで、洗い出せる幅がいちばん変わります。

最低限、渡したい観点はこの4つです。

• 正常系：想定どおりの入力で、期待どおりに動くか
• 異常系：不正な入力・想定外の状況で、ちゃんと失敗するか
• 境界値：区切りのちょうど上・ちょうど下・その境目で正しく分かれるか
• 状態・順序：前の操作の状態に依存する場合、その組み合わせや順番で崩れないか

聞き方の例：

この関数のテストケースを、次の観点ごとに分けて挙げてください。
- 正常系（代表的なパターン）
- 異常系（不正な入力・想定外の状況）
- 境界値（区切りの上・下・ちょうど）
- 状態や順序に依存する場合の組み合わせ

各ケースは「入力 → 期待する結果」の形で。まだ良し悪しの判断はしなくて大丈夫です。

観点を分けて頼むと、AIは「異常系の枠を埋めなきゃ」と動き、正常系だけでは出てこなかった場面を挙げてくれます。 特に境界値は人が見落としやすい所です。「ちょうど上限のとき」「1つ超えたとき」「空のとき」「0件のとき」——この辺りを言葉にして渡すと、洗い出しの密度が上がります。

ステップ3：「他には？」でもう一段深掘りする

ケースが並んだら、最初の一覧で止めないことが大事です。 AIは一度の回答で全部を出しきるとは限りません。だから、「他には？」ともう一段だけ掘る。これだけで、視野の外にあったケースが出てくることがあります。

聞き方の例：

いま挙がっていない観点で、見落としがちなケースはありますか。
特に、入力が「空」「0件」「同時に複数」「途中で失敗」「異常に大きい/長い」
といった状況を想定して、追加で挙げてください。

人は、一度「だいたい出たな」と思うと、そこで探すのをやめてしまいます。 だから、自分では止めてしまう場所を、AIにもう一歩進ませる。これは「AIに見落としを洗わせる」使い方の、テスト版です。

ただ、深掘りには止め時もあります。延々と「他には？」を続けると、似たケースの言い換えばかりになっていきます。1〜2回聞いて新しいケースが目に見えて減ったら、そこで打ち切ってよい。無限に掘る作業ではありません。

ここで出てきたケースを、全部書く必要はありません。 「これは今回は起きない」「ここまでは見なくていい」と、自分で判断して取捨選択する。このとき、言語・フレームワーク・バリデーション層で機械的に弾けるもの（型が違えばそもそも渡らない入力など）は、観点として残さず最初から外してかまいません。残すのは、自分のコードで判断が要るケースです。大事なのは、書かないと決めたことと、思いつかなかったことを、区別できる状態にすることです。

ステップ4：最後は自分で優先順位をつける

そして、いちばん大事なステップです。 ケースが出そろっても、全部を今すぐ書くのは現実的ではありません。だから、どれから書くかは自分で決めます。

優先順位の付け方の目安：

• 壊れたときの影響が大きい所から（お金・データ・安全に関わる処理）
• 間違えやすい所から（境界値、複雑な条件分岐）
• よく通る道から（多くの利用者が使う主要な経路）

AIは、その機能がシステム全体でどれだけ重要か、過去にどこで事故ったか、いまどれだけ時間が取れるかを知りません。だから「まずどれを書くか」は、それらを知っているあなたにしか決められません。 AIの役割は、選択肢を広げ、抜けを炙り出すことまで。そこから先の「で、今日はどこまで書くか」は、人の仕事です。

これは品質の話でもあります。テストは、数を増やすこと自体が目的ではありません。意味のあるテストに、限られた時間を配る。その判断が、現場の品質を支えます。AIで洗い出したカバレッジの広さと、実際に効くテストの質は、別物だからです。

ありがちな落とし穴と、その回避

洗い出しでつまずきやすい所を、先に潰しておきます。

• 仕様を渡さず頼む：その機能固有の境界や不正値が抜ける。まず入力・出力・ルールの共有から。
• 観点を指定しない：正常系ばかり並ぶ。正常系・異常系・境界値・状態の4観点を最低限渡す。
• 最初の一覧で満足する：「他には？」を一度挟むだけで、見落としが出てくる。
• 出たケースを全部そのまま書く：時間が足りなくなる。影響と頻度で優先順位をつける。
• AIの出力を「正解」として扱う：AIは仕様を誤解していることがある。ただ、洗い出したケースが数十個になると全件を仕様照合するのは時間的に無理です。影響の大きい上位のケースだけ期待結果を精査し、優先度の低いものは実際に書く段で確認する——この段階分けが現実的です。
• テストの中身まで鵜呑みにする：AIが生成したテストコードは、通すこと自体が目的になって、肝心の検証が甘いことがあります。確認の型は生成コードをそのまま使わない｜最低限の動作確認の型に整理しました。

落とし穴のほとんどは、「AIに完成形をもらおう」とした瞬間に生まれます。 「AIと一緒に抜けを探す」に意識を変えるだけで、多くは避けられます。

明日からやること（小さく始める3つ）

いきなり全部やろうとせず、まずこの3つから。

1. 次にテストを書くとき、対象の仕様を1行書いてから頼む：まずは入力・出力だけで十分。この1行があるだけでケースの質が変わります。
2. 「テストケースを出して」ではなく「観点ごとに出して」と頼む：正常系・異常系・境界値・状態。偏りが減ります。
3. 最初の一覧に「他には？」を一度だけ足す：見落としていた場面が出てきます。

この3つだけでも、「これで足りているのか」という夜の不安が、少し軽くなります。

コピーして使う「テスト洗い出しテンプレ」

新しい機能のテストを考えるとき、上から順に頼んでください。一度に全部でなく、迷っている所から使えば十分です。

# テストケースの洗い出し

## ① 仕様・前提（最低限、最初の1行だけでも渡す）
- 何をする処理か（入力 → 何をする → 出力）：  ← ここだけでも効果あり
- 入力の種類と範囲（型・必須/任意・想定値の幅）：  ← 以下は必要な時だけ
- 満たすべきルール / 禁止したい状態：
- 失敗させたい条件（どんな入力はエラーにすべきか）：

## ② 観点ごとに出させる
「この処理のテストケースを、次の観点ごとに分けて。
 各ケースは『入力 → 期待する結果』の形で。
 - 正常系（代表的なパターン）
 - 異常系（不正な入力・想定外の状況）
 - 境界値（区切りの上・下・ちょうど・空・0件）
 - 状態や順序に依存する組み合わせ」

## ③ 深掘り
「いま挙がっていない観点で、見落としがちなケースは？
 特に『空』『0件』『同時に複数』『途中で失敗』『異常に大きい/長い』を想定して。」

## ④ 自分で優先順位
- まず書くケース（影響が大きい / 間違えやすい / よく通る）：
- 今回は書かないと決めたケース（理由つき）：

洗い出し前後のチェックリスト

頼む前と、書く前に、さっと確認します。全部に○が要るわけではなく、関係する所だけで十分です。

頼む前

• 対象の仕様（入力・出力・ルール）を言葉にしたか
• 失敗させたい条件をはっきりさせたか

ケースを検討するとき

• 正常系・異常系・境界値・状態の4観点を渡したか
• 「他には？」で一度、深掘りしたか（新規が減ったら打ち切ってよい）
• 「期待する結果」を仕様に照らして確認したか（全件は無理なので影響の大きいケース優先で。低優先は書く段で）

書く前

• 影響と頻度で優先順位をつけたか
• 「今回は書かない」と決めたケースを、思いつかなかったケースと区別できているか
• テストの中身（検証が甘くないか）まで目を通したか（こちらも影響の大きいケースを優先でよい）

最後に

テストの抜け漏れを、ひとりで全部背負うのは、しんどいものです。 「これで足りているか」に終わりはないし、レビューしてくれる人がいつもいるとは限りません。その状況は、簡単には変わらないかもしれません。

でも、完成形を写すためでなく、抜けを一緒に探す相手としてAIを使えば、ひとりで見ていた範囲に、もうひとつの視点が加わります。

4つ全部でなくても、今日ひとつ「他にはどんな場面がある？」と聞けたなら、それはもう、見落としを減らす一歩です。 洗い出したケースをコードに落としたら、書いたものを最後にもう一度見る型としてAI生成コードのレビュー・検証チェックリストも合わせてどうぞ。考える前に渡す前提はAIにコードを書かせる前に渡す前提と制約に。洗い出す・書く・見る。この3つがそろうと、AIとのテストはずいぶん落ち着きます。

関連用語

• 正常系・異常系
• 単体テスト
• プロンプト
• LLM