テストケースをAIで生成する｜観点漏れを防ぐプロンプトとレビュー手順

テストケースの作成をAIに任せると、初稿を作るスピードは大幅に上がる。だが要件定義書をそのまま貼り付けて「テストケースを作って」と投げただけでは、観点が偏ったまま本番リリースまで漏れが残る。この記事では、AIにテストケースを生成させる際の具体的なプロンプト設計、観点マトリクスを使った漏れ防止の方法、生成後にPMが行うべきレビュー手順を解説する。読み終える頃には、AIを「叩き台生成機」として使いこなし、QAレビュー工数を圧縮しながら品質を落とさない実務フローが手に入る。

なぜAI生成のテストケースは観点が漏れるのか

AIは要件定義書や画面仕様書のテキストから、統計的にもっともらしいパターンを出力する仕組みだ。文書に明記されている入力項目や画面遷移は拾えるが、文書に書かれていない「暗黙の業務ルール」「過去の障害履歴に基づく注意点」「現場の運用慣習」までは拾えない。

たとえば会員登録フォームの仕様書に「メールアドレスを入力する」としか書かれていなければ、AIは正常系の入力チェックとフォーマットエラーくらいしか思いつかない。実際には「既に退会済みのメールアドレスで再登録した場合」「大文字小文字だけが異なる重複」といった、過去のトラブルから学んだ観点が抜け落ちる。

これはAIの精度の問題ではなく、インプット情報の問題だ。PMがテストケース生成をAIに任せる前提で動くなら、「AIは要件文書に忠実だが、文書外の暗黙知は補えない」という制約を理解した上で、観点を明示的に補う設計が必要になる。プロンプト設計の基本はWBSをAIで自動生成する手順｜プロンプト例と人間が直すべき箇所で扱った考え方と同じで、AIの出力を鵜呑みにせず「人間が構造を与え、AIが埋める」分業にすると精度が上がる。

AIにテストケースを作らせる基本の型

テストケース生成プロンプトは、次の4要素を明示するだけで出力品質が大きく変わる。

対象機能の仕様：入力項目、出力結果、制約条件（文字数上限、必須／任意、データ型）
想定ユーザー：一般ユーザー、管理者、未ログインユーザーなど権限の違い
出力フォーマット：表形式で「No／観点カテゴリ／前提条件／操作手順／期待結果」の列を指定
観点カテゴリの明示：正常系・異常系・境界値・例外処理・非機能の5分類を最低限指定する

この4要素を毎回同じテンプレートで渡すことで、案件ごとに出力のばらつきが減る。週次報告や議事録をAIに任せる基本フローについてはChatGPT・Claudeに週次報告を丸投げしたら、PM業務の2時間が消えた話でも触れているが、テストケース生成も同様に「毎回ゼロから頼む」のではなく、定型プロンプトを社内で共有資産化するのが工数削減の近道だ。

観点漏れを防ぐ観点マトリクスの使い方

観点カテゴリを「正常系・異常系」だけに任せると、AIはどうしても正常系に偏る。そこで、生成前に観点マトリクスを提示し、各カテゴリ最低件数を指定する方法が有効だ。

観点カテゴリ	確認内容の例	AIが単独で拾いやすいか
正常系	想定通りの入力・操作フロー	拾いやすい
異常系	不正入力、必須項目未入力	ある程度拾える
境界値	文字数上限／下限、数値の最大最小	指定しないと抜けやすい
例外処理	通信断、タイムアウト、二重送信	指定しないとほぼ抜ける
データパターン	全角／半角、絵文字、null、特殊記号	指定しないとほぼ抜ける
権限・ロール	管理者／一般／未ログインでの挙動差	仕様書に権限記載が無いと抜ける
非機能	同時アクセス、性能劣化、セキュリティ	ほぼ抜ける、別途指定必須

プロンプトの末尾に「上記カテゴリごとに最低3件ずつ出力せよ」と一文入れるだけで、正常系偏重が解消されるケースが多い。特に例外処理・データパターン・非機能の3カテゴリは、指定しない限りAIが自発的に埋めることはほぼないと考えてよい。

具体的なプロンプト例

会員登録フォームを例にした実際のプロンプトは、次のような形になる。

以下の仕様に基づき、テストケースを表形式（No／観点カテゴリ／前提条件／操作手順／期待結果）で作成せよ。【仕様】メールアドレス（必須、255文字以内、形式チェックあり）、パスワード（必須、8〜20文字、英数記号混在）、利用規約同意チェック（必須）【対象ユーザー】未登録の一般ユーザー、既に登録済みのユーザー【観点カテゴリ】正常系・異常系・境界値・例外処理・データパターンの5カテゴリについて、各カテゴリ最低3件ずつ出力すること【制約】1つの期待結果には1つの検証内容のみを含めること（複合条件は分割する）

最後の「期待結果は1件1検証」という制約は、テスト管理ツールへ登録した際にケースが実行しづらくなるのを防ぐための実務上のコツだ。AIは放っておくと1つのケースに複数の確認事項を詰め込みがちで、後工程で分割し直す手間が発生する。

生成後のレビュー手順

AIが出力したテストケースは、そのままテスト管理ツールに登録せず、次の3段階でレビューする。

①網羅性チェック：観点マトリクスと生成結果を突合し、抜けているカテゴリがないか確認する。特に非機能・例外処理は要チェックだ。

②期待値の正確性チェック：AIが「期待結果」として書いた内容は、要件文書と必ず突き合わせる。AIは仕様が曖昧な箇所を推測で埋めるため、誤った仕様を正しいものとして出力することがある。これをレビューせず登録すると、誤った期待値のままテストが「合格」してしまうリスクが生まれる。品質面のリスクが後工程まで見えにくい構造についてはAIでプロジェクトリスクを自動検知：Asana AI Teammatesの使い方でも扱った通り、AIが自信ありげに出す誤情報こそPMが最も警戒すべき領域だ。

③粒度・重複の整理：AIは似たケースを微妙に表現を変えて重複生成することが多い。テスト管理ツールに登録する前に、重複統合と粒度の統一（1ケース1操作の原則）を行う。

よくある失敗パターン

現場でAIテストケース生成を導入する際に、よく起きる失敗は次の5つに集約される。

要件を丸投げする：仕様書をそのまま貼り付けるだけでは表面的な正常系しか出ない
期待値を鵜呑みにする：AIの推測による誤仕様がそのままテストの合格基準になる
観点カテゴリを指定しない：正常系に偏り、非機能・例外系がごっそり抜ける
ノーレビューで登録する：初稿の生成スピードに満足して、精度検証を省略する
粒度がバラバラなまま運用する：後工程でテスト管理ツールへの入力や実行順の管理が崩れる

これらはいずれも「AIの性能不足」ではなく「人間側の運用設計不足」が原因だ。生成と検証をセットで運用フローに組み込むことが、AI活用の前提になる。

チームへの導入ロードマップ

いきなり全プロジェクトに展開せず、まず1機能・1画面規模の小さいスコープで試すのが現実的だ。定型プロンプトと観点マトリクスをテンプレート化し、実案件で生成とレビューのサイクルを回し、頻出した抜け漏れパターンをプロンプトにフィードバックする、という3ステップで精度が安定していく。

QAレビュー工数がどの程度削減できるかは案件の複雑さに依存するため一概には言えないが、少なくとも「ゼロから手書きでケースを起こす時間」は明確に減らせる。浮いた時間を期待値レビューと観点網羅性チェックに再投資することで、生成スピードと品質の両立が現実的な運用になる。

あわせて読みたい

テスト工程での抜け漏れは、放置するとプロジェクト全体のトラブルに直結する。品質起因の炎上対応や再発防止の考え方を体系的に押さえておきたい場合は、こちらが参考になる。

プロジェクトのトラブル解決大全：テスト漏れが引き金になった炎上案件のリカバリー手順を体系的に学べる。品質起因のトラブルが実際に起きた後の動き方を知っておくと、レビュー体制の設計にも説得力が増す。

PMBOK ガイド第7版：品質マネジメントの知識体系を一冊で押さえたいPMにおすすめ。AIにテストケースを作らせる際の「何を観点として担保すべきか」という判断軸を補強できる。