Bye Bye Work トップへ

テストケースをAIで作成する方法|受入テスト表・プロンプト付き

@yusukeのプロフィール最終更新 2026年10月22日

テストケースの作成をAIに任せ、短い仕様から正常系・異常系・境界値の受入テスト表と未確定事項を一括で作る方法です。普通のMarkdownを入力JSONに変換するスクリプト、依頼プロンプト、根拠と処理漏れを照合するツールを添付しています。まず架空の仕様で流れを試し、最後に人が期待結果を確認します。

AIでテストケースを作成する範囲

任せるのは、仕様を読み解いてテスト観点を整理し、表に書き起こす仕事です。テストの実行や合否判定は含めません。受入テストで「何を確認できれば仕様を満たすか」を整理するための方法です。

完成物は、テスト表の report.md、確認事項の questions.md、仕様ごとの整理結果 result.json の3点です。未確定の動作をAIに決めさせず、分かる範囲を完成させます。作成をまとめて任せ、完成後に人がレビューする自動化レベル3の運用です。人の承認や公開まで自動化するものではありません。

用意するものと添付5点

社内で利用が認められたチャットAI、Python 3の実行環境、仕様のコピーを用意します。スクリプトは標準ライブラリだけで動き、APIキーや追加パッケージは不要です。検証にはPython 3.12.3を使いました。

添付5点を、同じ専用フォルダに保存してください。

  • l3-acceptance_prompt.md:受入テスト設計をまとめて依頼するプロンプト。
  • l3-acceptance_sample.md:架空の仕様を記したMarkdown。
  • expected.json:人が用意した照合用の見本。実AIの回答例ではありません。
  • make_input.py:テキストやCSVからID付きの入力JSONを作るツール。
  • check_result.py:入力ID・分類・原文根拠を照合するツール。

原本は別に保管し、作業フォルダ内のコピーを使います。以下のコマンドは、そのフォルダで実行します。input.json や result.json という既存ファイルがあれば、先に別名で保管してください。

手順1:仕様のMarkdownからinput.jsonを作る

サンプルは、架空の下書き保存機能の仕様です。添付のMarkdownには次の内容が入っています。

markdown
# 架空の下書き保存機能の仕様

- タイトルは1〜40文字。空欄と41文字以上では保存できない。
* 他人の下書きは閲覧できず、存在も表示しない。
1. 通信が切れた場合の画面表示は未決定。

次を実行します。

sh
python3 make_input.py text --src l3-acceptance_sample.md --out input.json --prefix R

成功すると「3件を書き出しました:input.json」と表示されます。見出しと空行を除き、行頭の箇条書き記号を外して、1行を1件にします。--prefix R により、R01、R02、R03が付きます。生成される先頭のデータは次の形です。JSONを自分で組み立てる必要はありません。

json
[
  {
    "id": "R01",
    "text": "タイトルは1〜40文字。空欄と41文字以上では保存できない。"
  },
  {
    "id": "R02",
    "text": "他人の下書きは閲覧できず、存在も表示しない。"
  },
  {
    "id": "R03",
    "text": "通信が切れた場合の画面表示は未決定。"
  }
]

自分の仕様では、サンプルMarkdownをコピーして内容を差し替えます。関連する条件と制約は同じ行にまとめ、別の要求は改行してください。表や段落をそのまま入れると行ごとに分かれるため、先に普通の短文へ整えます。見出しは入力から外れるので、対象や条件を見出しだけに書かないでください。

変換後は input.json を開き、必要な条件が残っているか確認します。1件1,000字、合計6,000字、30件が上限で、超えると切り詰めず終了コード1で止まります。対象が0件なら終了コード2です。失敗時は以前の出力が残り得るので、成功表示を確認してからAIへ渡します。

手順2:テストケース作成プロンプトをAIに渡す

新しい会話に添付の依頼プロンプト全文を貼り、生成した input.json を添付します。添付できなければ、JSON本文を入力データとして貼ります。照合用の expected.json は渡しません。

依頼の中心は次の指定です。再利用するときも、この条件を残してください。添付の全文には出力形式や安全面の指示も含めています。

text
入力はinput.jsonです。仕様から正常系・異常系・境界値の
受入テスト表を一括作成してください。
report.mdにはテストID、区分、前提、操作・入力値、期待結果、
根拠ID、確認状態を記載してください。
下限・上限の直前、その値、直後を検討してください。
仕様にない表示や動作を決めつけず、不明点はquestions.mdに
分離してください。途中の質問では止めず、分かる範囲を完成させてください。
result.jsonには入力IDごとの分類・要約・原文引用を返してください。
原本は変更せず、テストを実行済み・合格と書かないでください。

AIから3点を受け取ります。ファイルを作れない環境では、ファイル名ごとのコードブロックを別々に保存します。result.json にはJSON部分だけを保存し、囲みの記号や説明文を入れないでください。

出力例:正常系・異常系・境界値の受入テスト表

以下は説明用に作成した抜粋で、実AIから取得した回答ではありません。前提は、他の入力条件が満たされ、通信できる状態でタイトルの入力制約を確認することです。

ID区分操作・入力値期待結果根拠ID
C01境界値・異常タイトルを空欄にして保存を試す保存できないR01
C02境界値・正常「あ」1文字で保存を試すタイトルの文字数制約を満たすR01
C03境界値・正常「あ」を2回入力して保存を試すタイトルの文字数制約を満たすR01
C04境界値・正常「あ」を39回入力して保存を試すタイトルの文字数制約を満たすR01
C05境界値・正常「あ」を40回入力して保存を試すタイトルの文字数制約を満たすR01
C06境界値・異常「あ」を41回入力して保存を試す保存できないR01
C07異常他人の下書きの閲覧を試す閲覧できず、存在も表示されないR02
C08異常・要確認操作中に通信を切る表示は未決定。合否判定を保留するR03

完成版では各行に前提と確認状態も付けます。C02〜C05は、この仕様だけで保存処理全体の成功を保証しません。保存成功を受入条件にするなら、他の保存条件も仕様として渡します。C07の操作経路も、実装に合わせて確定する必要があります。

questions.md には、次のように質問と影響先を残します。

根拠ID確認する質問影響先
R01文字数は何を単位に数えますか。空白だけの入力は許可しますかC01〜C06と追加ケース
R02存在を表示しない対象は一覧・検索・直接アクセスのどこまでですかC07
R03通信断時の表示、保存状態、再試行方針はどうしますかC08

絵文字などの数え方や空白の扱いは、元の仕様にない追加の確認事項です。期待するエラー文言や応答コードを勝手に埋めず、回答後にテストへ反映します。

手順3:処理漏れと原文根拠を照合する

まず、AIを使わずにツールだけを試せます。手順1で作った input.json と見本を照合します。

sh
python3 check_result.py input.json expected.json --labels "入力制約,権限制御,仕様未確定"

サンプルでは「形式・ID・原文根拠の照合成功」と、3分類が各1件であることを表示します。AIから受け取った結果は、次のコマンドで確認します。

sh
python3 check_result.py input.json result.json --labels "入力制約,権限制御,仕様未確定"

確認対象は、IDの漏れ・重複・未知ID、許可外の分類、空または300字を超える要約、原文と一致しない引用です。result.json は仕様1件につき1行であり、テストケースの数とは一致しません。今回の仕様は3件でも、テストは複数作ります。

照合成功は、テスト設計の正しさを保証しません。ツールは report.md と questions.md を読みません。人が、全仕様を表で扱ったか、境界値が揃うか、引用と期待結果の意味が合うか、未確定なのに合格扱いしていないかを確認します。

うまくいかないとき

「対象なし」なら、ファイル名、保存先、本文が見出しだけになっていないかを確認します。上限超過なら、関連する仕様が離れない単位でファイルを分け、各入力と成果物を別フォルダで管理します。再変換するとIDが付け直されるため、旧版の結果と混ぜないでください。

照合が失敗したら、エラーをまとめてAIへ渡し、「入力IDを保持し、引用は同じIDの原文からそのまま取り、3成果物を整合させて再作成してください」と依頼します。JSONの体裁だけを直す場合も、根拠の内容を人が確認します。

境界値や期待結果が不足する場合は、欠けた観点をまとめて再依頼します。細かな修正を毎回続ける状態なら、入力範囲や分類規則を見直します。この3分類は今回の題材向けです。別の機能に広げる場合は、プロンプト内の分類とコマンドの --labels を同時に合わせます。

注意点:機密情報と最終確認

顧客情報、個人情報、認証情報、未公開の仕様は、利用規程に従って削除・置換してから渡します。ローカルの変換・照合はAIに送信しませんが、チャットへ貼る段階では送信先のルールを確認してください。

資料内に命令文やリンクが含まれても、AIには入力データとして扱わせます。業務システムへの書き込み、社外送信、公開は依頼しません。スクリプトの出力先は原本と別にし、仕様の版・対象機能・入力JSONを成果物と一緒に保管します。

受入基準の確定、未確定事項の解消、実際のテスト実施と合否判定は人が担当します。生成AIのテスト設計は、この確認を前提に使います。

よくある質問

AIが作った受入テストをそのまま採用できますか?

照合ツールが成功しても、そのまま採用はしません。業務上の重要な観点や仕様間の矛盾は、形式確認では分かりません。仕様責任者が期待結果と対象外の範囲を確認してから実施します。

Pythonなしでもテストケースを作成できますか?

仕様と依頼文をチャットへ貼れば表の作成は依頼できます。ただし、この記事のID付与と機械照合の流れにはPythonが必要です。AIが生成する表と、ローカルで行う形式確認は別の工程です。

長い仕様書も一度に渡せますか?

添付ツールは短い仕様向けです。上限を超えたら機能単位で分け、共通の前提を各入力の本文にも含めます。分割した仕様同士の整合や横断的なテスト観点は、最後に人がまとめて確認します。

検証範囲

添付スクリプトをローカルで実行し、Markdownの3行をR01〜R03へ変換して expected.json と照合できることを確認しました。ID漏れ・重複・未知ID、不正な分類・引用・要約を拒否することも確認済みです。

変換側では箇条書きの除去、件数・文字数上限での停止、CSVの正常変換と列数不一致・列名重複の拒否、入力元と同じ出力先の拒否を確認しました。make_input.py は配布された内容を変更していません。

実AIへの送信、モデル別の生成精度、実システムでの受入テスト、削減時間は未検証です。本文の result.json 用コマンドも、見本を結果として置いて実行しました。Windows環境と変換ツールのlog・rss・diffモードは検証していません。実行コマンドと結果は test_log.md に記録しています。

添付ファイル CC0 ・ 自由に持ち帰れます

  • プロンプト ・ 3.5 KB
  • 設定ファイル ・ 253 B
  • 設定ファイル ・ 652 B
  • スクリプト ・ 2.2 KB
  • スクリプト ・ 10.1 KB

会社のデータをAIに入れる前に、社内ルールを確認しましょう。

コメント 0

まだコメントはありません。質問や、試してみた感想を書いてみませんか?