テストケースをAIで作るプロンプトテンプレート 仕様書から確認観点を抜け漏れなく出す書き方
仕様書やチケットを読んでテストケースを作るとき、AIには「テストして」ではなく、入力情報、確認観点、出力形式、除外条件をまとめて渡すのが近道です。
この記事では、ChatGPT、Claude、Gemini などの汎用LLMで使える、テストケース自動生成用のプロンプトテンプレートを紹介します。対象は、開発者、QA担当者、プロダクト担当者、業務システムの受け入れ確認を行う人です。
まず要点です。
- 仕様文だけでなく、対象画面、ユーザー権限、正常系、異常系、未確認の前提を渡す
- 出力は「表」または「JSON」に固定すると、レビューや管理表への転記がしやすい
- AIの出力は候補であり、最終的な合否基準、セキュリティ、個人情報、業務影響は人が確認する
- 期待結果を曖昧にさせないため、各テストケースに「前提条件」「操作」「期待結果」「優先度」を入れる
ここがポイント: AIに任せるのは「観点の洗い出し」と「初稿化」です。合否判定の責任まで渡さないことが、実務で使いやすい境目です。
何に使うプロンプトか
このテンプレートは、仕様書、ユーザーストーリー、画面説明、API仕様、バグ修正内容などから、テストケースのたたき台を作るために使います。
たとえば、次のような場面で役立ちます。
- 新機能の受け入れテスト項目を作りたい
- 修正チケットから回帰テストの候補を出したい
- 仕様レビュー前に抜けている条件を見つけたい
- 手作業の確認項目を表にそろえたい
- QA担当者に渡す前の初稿を整えたい
テストケース作成でAIを使う意味は、単に作業時間を短くすることではありません。人が仕様を読んだときに見落としやすい「権限違い」「空欄」「境界値」「エラー表示」「再実行」「既存データへの影響」を、最初から確認対象に含めやすくする点にあります。
コピペ用プロンプトテンプレート
以下をそのままコピーし、{} の中だけ自分の案件に合わせて差し替えてください。最初は表形式で出すのがおすすめです。
あなたはソフトウェアテストのレビュー担当者です。
以下の仕様情報をもとに、実務で確認しやすいテストケース案を作成してください。
# 対象
- 対象機能: {機能名}
- 対象画面またはAPI: {画面名/API名}
- 利用者: {一般ユーザー/管理者/社内担当者など}
- テスト目的: {新機能確認/改修確認/回帰テスト/受け入れ確認}
# 仕様情報
{仕様書、チケット、ユーザーストーリー、画面説明、API仕様などを貼り付ける}
# 前提条件
- 実行環境: {開発環境/検証環境/本番相当環境}
- 対象データ: {使用するテストデータの条件}
- 対象外: {今回テストしない範囲}
- 注意事項: {個人情報、課金、通知送信、外部連携などの注意点}
# 作ってほしいテストケース
以下の観点を含めてください。
- 正常系
- 入力漏れ、形式不正、上限下限などの異常系
- 権限やログイン状態の違い
- 既存データへの影響
- エラーメッセージや画面表示
- 再実行、戻る、キャンセルなどの操作
- 仕様が曖昧で確認が必要な点
# 出力形式
Markdownの表で出力してください。
列は以下にしてください。
- ID
- テスト観点
- 前提条件
- 操作手順
- 入力データ
- 期待結果
- 優先度 高/中/低
- 種別 正常系/異常系/境界値/権限/回帰/確認事項
- 補足または確認事項
# 制約
- 仕様に書かれていない挙動は断定せず、確認事項として分けてください。
- 同じ内容の言い換えだけで件数を増やさないでください。
- 危険な本番操作、実在する個人情報、実課金、実通知を前提にしないでください。
- 最後に、追加で確認すべき仕様質問を5つ以内で出してください。
このプロンプトの狙いは、AIに「テストケースを作る」だけでなく、「どの前提で、どの範囲を、どの形式で出すか」まで指定することです。OpenAIのプロンプトエンジニアリング資料でも、指示や文脈、出力形式を明確にする考え方が示されています。AnthropicやGoogleの公式ガイドでも、明確な指示、例、形式指定は安定した出力につながる基本として扱われています。
入力時に変える部分
テンプレートを使うときは、すべてを長く埋める必要はありません。最低限、次の5つが入っていれば、AIはテストケースの方向を合わせやすくなります。
必ず入れたい項目
{機能名}: 例「請求書PDFの再発行」「会員情報の住所変更」{画面名/API名}: 例「管理画面の請求一覧」「PATCH /users/{id}」{利用者}: 例「一般ユーザー」「経理担当者」「管理者」{テスト目的}: 例「新機能確認」「改修後の回帰テスト」{仕様情報}: チケット本文、受け入れ条件、画面項目、APIの入出力など
特に重要なのは、利用者とテスト目的です。同じ住所変更機能でも、一般ユーザーが自分の住所を変えるのか、管理者が代理で変更するのかで、権限、ログ、通知、確認画面の観点が変わります。
固定した方がよい条件
毎回変えずに固定してよいのは、出力列と制約です。
- ID
- テスト観点
- 前提条件
- 操作手順
- 入力データ
- 期待結果
- 優先度
- 種別
- 補足または確認事項
この列を固定しておくと、複数機能のテストケースを後から比較しやすくなります。チームで使う場合は、優先度の基準だけ先に決めておくと、レビュー時の手戻りが減ります。
NG例と改善例
テストケース生成で失敗しやすいのは、AIへの依頼が短すぎる場合です。短い依頼でも何かは出ますが、実務で確認できる粒度にならないことがよくあります。
NG例
この仕様のテストケースを作って。
仕様:
ユーザーはメールアドレスを変更できる。
変更後、確認メールを送る。
この指示だと、AIは一般的な項目を並べるだけになりがちです。ログイン状態、メール形式、既存メールアドレスとの重複、確認メールの送信条件、変更前のアドレスに通知するかどうかなど、重要な確認点が抜ける可能性があります。
改善例
あなたはWebサービスのQA担当者です。
以下の仕様から、メールアドレス変更機能のテストケース案を作成してください。
# 仕様
- ログイン中のユーザーはマイページからメールアドレスを変更できる
- 新しいメールアドレスに確認メールを送信する
- 確認メール内のURLを押すまで、ログイン用メールアドレスは変更されない
- すでに登録済みのメールアドレスは使用できない
- メールアドレス形式が不正な場合はエラーを表示する
# 出力形式
Markdownの表で、ID、観点、前提条件、操作手順、入力データ、期待結果、優先度、確認事項を出してください。
# 必ず含める観点
正常系、形式不正、登録済みメール、未ログイン、確認URL期限切れ、再送、変更確定前のログイン可否
# 制約
仕様にない挙動は確認事項として分け、断定しないでください。
改善後は、AIが見るべき範囲が具体的になります。ここで効いているのは、専門的な言い回しではなく、確認したい状態を先に並べていることです。
出力形式を安定させるコツ
AIの出力をそのままテスト管理表やチケットに貼るなら、形式指定を強めに書きます。自由な文章で出させるより、表やJSONのように枠を決めた方が後処理しやすくなります。
表で出す場合
表は、人がレビューする初稿に向いています。仕様レビューやQA観点の相談では、まず表で出すと読みやすくなります。
追加指定は次のように書けます。
出力はMarkdownの表にしてください。
1行につき1テストケースにしてください。
操作手順は3ステップ以内に分けてください。
期待結果には、画面表示、データ更新、通知、ログのうち関係するものを含めてください。
JSONで出す場合
JSONは、別ツールに取り込む、スクリプトで整形する、管理表に変換する場合に向いています。
出力はJSON配列にしてください。
各要素には次のキーを含めてください。
case_id, title, precondition, steps, test_data, expected_result, priority, type, open_questions
説明文や前置きは出さず、JSONだけを出してください。
JSONを使う場合は、AIの出力が必ずしも機械的に正しいJSONになるとは限りません。取り込み前に構文チェックを行い、必要なら「JSONとして解釈できる形に修正してください」と再依頼します。
確認事項を分ける
テストケースと確認事項を混ぜると、レビュー時に迷います。仕様が足りない部分は、テストケースの中に無理に埋めず、別枠に出させます。
最後に、仕様が不足していてテストケース化できない点を「確認事項」として最大5件出してください。
各確認事項には、確認先の候補を「PO」「開発者」「QA」「法務」「運用」のいずれかで付けてください。
この指定を入れると、AIが勝手に仕様を補うのを抑えやすくなります。テストケース生成では、きれいな表を作ることより、曖昧な前提を見える場所に出すことの方が重要です。
失敗しやすい点
AIが作るテストケースは便利ですが、そのまま完成版として扱うと危険です。特に次の点は、人が必ず確認してください。
- 仕様にない期待結果をAIが補っていないか
- 本番データ、個人情報、実課金、実通知を前提にしていないか
- セキュリティや権限の確認が抜けていないか
- 画面表示だけでなく、DB更新、メール送信、ログ、外部連携まで必要に応じて見ているか
- 同じ観点の言い換えで件数だけ増えていないか
- 優先度が業務影響と合っているか
見落とされがちなのは、「正常に保存できるか」よりも「保存してはいけない条件で止まるか」です。たとえば、退会済みユーザー、権限のない管理者、期限切れURL、重複データ、外部連携失敗などは、仕様書の本文に小さく書かれているか、そもそも書かれていないことがあります。
AIには、こうした観点を候補として出させます。ただし、採用するかどうかは、サービスの仕様、リスク、テスト環境の制約を知っている人が判断します。
活用例
同じテンプレートでも、入力する情報と出力形式を変えると、使い道が広がります。
開発チケットから回帰テストを出す
以下の修正チケットから、今回の修正で影響しそうな回帰テスト候補を作成してください。
新規テストではなく、既存機能が壊れていないかを確認する観点を中心にしてください。
# 修正内容
{修正チケット本文}
# 出力
影響を受ける可能性がある機能、確認観点、具体的な操作、期待結果、優先度を表で出してください。
バグ修正後の確認では、修正箇所そのものだけでなく、周辺機能の確認が必要になります。AIに「回帰テスト候補」と明示すると、新機能テストとは違う観点で出しやすくなります。
受け入れ条件から確認表を作る
以下の受け入れ条件を、非エンジニアでも確認できる受け入れテスト表に変換してください。
専門用語を避け、画面上で何を操作し、何を見ればよいかが分かる表にしてください。
# 受け入れ条件
{受け入れ条件を貼る}
# 出力列
確認項目、事前準備、操作、期待される表示、OK/NG記入欄、備考
プロダクト担当者や業務部門が確認する場合は、技術的に正しい表よりも、画面上で実行できる表が必要です。「非エンジニアでも確認できる」と書くと、操作と表示に寄せた出力になりやすくなります。
API仕様から境界値テストを出す
以下のAPI仕様から、入力値の境界値テストを作成してください。
必須項目、型、文字数、数値範囲、配列件数、日付形式、認証状態を確認対象にしてください。
# API仕様
{API仕様を貼る}
# 出力
Markdownの表で、パラメータ名、テスト値、観点、期待されるステータスコード、期待されるレスポンス、補足を出してください。
APIでは、画面操作よりも入力値とレスポンスが重要です。画面向けのテンプレートをそのまま使うより、パラメータ名、ステータスコード、レスポンスを列に入れる方が確認しやすくなります。
モデルを問わず使うときの前提
この記事のテンプレートは、2026年7月時点で一般的に使われているChatGPT、Claude、Geminiなどの汎用LLMを想定しています。特定モデルの専用機能には依存していません。
公式ドキュメントを見ると、各社とも表現は違いますが、実務プロンプトで重要な点はかなり近いです。
- 何をしてほしいかを具体的に書く
- 必要な文脈を渡す
- 出力形式を指定する
- 例や制約を入れる
- 不明点を勝手に埋めさせず、確認事項として出させる
テストケース生成では、この基本がそのまま効きます。モデル選びより先に、仕様情報を整理し、出力列を固定し、確認事項を分けることが大切です。
使う前のチェックリスト
最後に、プロンプトを送る前に確認する項目をまとめます。
- 機能名、対象画面、利用者、テスト目的を書いたか
- 仕様情報を貼り付けたか
- 対象外の範囲を書いたか
- 個人情報、課金、通知、外部連携の注意点を書いたか
- 出力形式を表またはJSONに固定したか
- 期待結果に画面表示、データ更新、通知、ログのどれを見るかを指定したか
- 仕様にない挙動は確認事項に分けるよう指示したか
- AIの出力を人がレビューする前提にしているか
テストケース自動生成の実用性は、AIの文章力よりも、入力する仕様の粒度で決まります。次に試すなら、完成した仕様書ではなく、いま手元にある1件のチケットを貼り、回帰テスト候補を10件だけ出すところから始めると、レビューしやすい形で効果を確認できます。