AIでテストケースを作る、最初の一歩
はじめに
こんにちは！グロービスで学習管理システム「GLOPLA」のQAエンジニアをしている『おまつ』です。
AIを活用したテストケース作成に興味はあるけれど、どこから始めればいいかわからない。そんな方に向けて、私が実践している方法を共有したいと思います。
最初にAIでテストケースを作り始めたとき、何ができて何ができないのかわからないことが多かったです。最終的にどんなテストケースが欲しいのかも曖昧でした。
そこから自分で試して中でいいなと思った方法を本記事で紹介します。
なぜ「明示的な仕様から」なのか
本記事では、明示的な仕様（要件定義ドキュメント）からテストケースを作成する方法に焦点を当てます。
なぜかというと、暗黙知などを含めてテストケースを作ろうとすると、やることが大量に出てくるからです。過去の不具合パターン、経験に基づくリスク観点、曖昧な要件の解釈...暗黙知の範囲は広く、どこまでやればいいのかわからなくなりがちです。AIの生成もブラックボックスなため、ますます混乱してしまいます。
なので、まずは最初の一歩として明示的な仕様からテストケースを作るところから始めるのが良いかなと思っています。要件定義ドキュメントに書いてあることをテストケースにするのは、比較的やりやすいです。ここから少しずつAIに慣れていくのが良いのではないでしょうか。
検証環境: 本記事はCursorでの検証結果に基づいています（2025年12月時点）。AIモデルによって精度が異なる可能性があります。
私が実践してみて大切だなと感じたのは以下の3つです：
- 要件への採番: 要件（受け入れ条件）に採番し、レビューしやすくする
- ステップバイステップでレビューする: AIは推測して変えてしまうことがあるので、人間のレビューは必ず行う
- 継続的な改善: ルールとフィードバックで自分の欲しいケースを作れるようにする
1. 採番をする：レビューしやすいように採番する
まずは何も情報がない場合のテストケース生成
まず、要件に書かれた受け入れ条件をそのままAIに渡してテストケースを作ってもらいます。
AIへの指示：
【受け入れ条件】
・通知設定画面から「通知ON・通知OFF」の設定ができる
・通知ONになっている機能を通知OFFにすることができる
・通知ONにする時に確認ダイアログが出る
この受け入れ条件を満たすテストケースを作成して
AIの出力（抜粋）：
### TC-001: 通知設定画面で通知ON設定を選択できる
**目的**: 通知設定画面から「通知ON・通知OFF」の設定ができることを確認する
**テスト手順**:
1. 通知設定画面を開く
2. 通知ON・通知OFF設定のUI要素が表示されていることを確認
3. 通知ON・通知OFF設定のUI要素を操作できることを確認
**期待結果**:
- 通知ON・通知OFF設定のUI要素が表示されている
- UI要素を操作できる
### TC-002: 機能を通知OFFに設定できる
**目的**: 通知設定画面で通知OFF設定を選択できることを確認する
...
### TC-003: 機能を通知ONに設定する際に確認ダイアログが表示される
...
### TC-004: 確認ダイアログで「確認」を選択して機能を通知ONにできる
...
### TC-005: 確認ダイアログで「キャンセル」を選択した場合、通知ON設定が適用されない
...
### TC-006: 通知ONになっている機能を通知OFFに変更できる
...
テストケースを作ってくれました。しかし、これだとぱっと見でどのテストケースがどの受け入れ条件を満たすために作ったかわかりません。
採番するとどう変わるか
次に受け入れ条件にID（ここではACCと採番）を振って、AIに渡します。
AIへの指示：
【要件】
ACC-001: 通知設定画面から「通知ON・通知OFF」の設定ができる
ACC-002: 通知ONになっている機能を通知OFFにすることができる
ACC-003: 通知ONにする時に確認ダイアログが出る
この受け入れ条件をカバーするテストケースを作成して
AIの出力（抜粋）：
## ACC-001: 通知設定画面から「通知ON・通知OFF」の設定ができる
| テストケースID | テストケース名 | 優先度 |
|---|---|---|
| TC-001-01 | 通知設定画面に「通知ON・通知OFF」の設定項目が表示される | 高 |
| TC-001-02 | 「通知ON」に設定できる | 高 |
| TC-001-03 | 「通知OFF」に設定できる | 高 |
**TC-001-01: 通知設定画面に「通知ON・通知OFF」の設定項目が表示される**
- **前提条件**: ユーザーがログインしている
- **実行手順**:
1. 通知設定画面にアクセスする
2. 画面を確認する
- **期待結果**: 「通知ON」と「通知OFF」の選択肢が表示される
---
## ACC-002: 通知ONになっている機能を通知OFFにすることができる
| テストケースID | テストケース名 | 優先度 |
|---|---|---|
| TC-002-01 | 通知ONになっている機能の編集画面で通知OFFに変更できる | 高 |
| TC-002-02 | 通知ONになっている機能を通知OFFに変更すると、状態が更新される | 高 |
| TC-002-03 | 通知ONになっている機能を通知OFFに変更する際、確認なしで変更できる | 高 |
---
## ACC-003: 通知ONにする時に確認ダイアログが出る
| テストケースID | テストケース名 | 優先度 |
|---|---|---|
| TC-003-01 | 通知OFFの機能を通知ONに変更する際、確認ダイアログが表示される | 高 |
| TC-003-02 | 確認ダイアログで「通知ONにする」をクリックすると、機能が通知ONになる | 高 |
| TC-003-03 | 確認ダイアログで「キャンセル」をクリックすると、通知ONにならない | 高 |
このように、受け入れ条件ごとにテストケースが整理されるので、どのテストケースがどの受け入れ条件をカバーしているか一目でわかります。
採番のメリット
- AIが作ったテストケースがどの受け入れ条件をカバーしているかを確認しやすい
- テストケース作成前に受け入れ条件に漏れがないかを確認できる
- レビュー時に「ACC-001の期待結果を確認してください」と明確に伝えられる
2. ステップバイステップでレビューする：AIは推測して変えてしまう
実際にテストケースを見てみる
先ほど作成したテストケースを見てみましょう。
**TC-002-03: 通知ONになっている機能を通知OFFに変更する際、確認なしで変更できる**
- **前提条件**:
- ユーザーがログインしている
- 通知ONになっている機能が存在する
- **実行手順**:
1. 通知ONになっている機能の編集画面を開く
2. 「通知OFF」を選択する
3. 「保存」ボタンをクリックする
- **期待結果**:
- 確認ダイアログが表示されない
- 直接保存される
実は、この通知設定のON・OFFは保存ではなく、プルダウン選択で切り替わる仕様です。手順3の「保存ボタンをクリックする」はAIが推測して記載されています。
このような推測を入れるとかえって私が混乱してしまうので、AIに指摘します。
AIに指摘する
通知設定のON・OFFは保存ではなく、プルダウン選択で切り替わる仕様です
推測でテストケースを作成しないようにしてください
修正後のテストケース
AIが修正したテストケース（抜粋）：
**TC-002-01: 通知ONになっている機能の編集画面で通知OFFに変更できる**
- **前提条件**:
- ユーザーがログインしている
- 通知ONになっている機能が存在する
- **実行手順**:
1. 通知ONになっている機能の編集画面を開く
2. プルダウンから「通知OFF」を選択する
- **期待結果**:
機能が通知OFFに変更される
「保存ボタンをクリックする」という推測が削除され、「プルダウンから選択する」という正しい手順に修正されました。
なぜレビューが必要か
このように、AIは推測して変えてしまうことがあります。ルールで指定しても、抜けてしまうことがあります。
また推測以外にも以下のようなことがあります：
- 作業の抜けがある：受け入れ条件をACC-001〜050などにした際に一部が抜けてしまった
- 要件の解釈が異なる：同じ要件でもAIが異なる解釈をしてしまうことがある
こういうことがあるので、人間のレビューは必ず行うようにしています。
レビューをしないと、テスト実行の段階で問題を発見することになり、修正範囲が広くなってしまいます。早い段階でレビューしておくと、手戻りが少なくなります。
やっていること：ステップごとにレビューする
私は以下のステップでレビューしています：
- 採番のレビュー: 要件（受け入れ条件）に正しく採番できているか
- テストケースのレビュー: 作成されたテストケースが要件をカバーしているか、漏れがないか
各ステップでレビューを入れることで、問題があれば早めに修正できます。
実際にはテスト分析やテスト設計などのテストプロセスが入るので、その都度レビューするのが良いかなと思います。AIに任せきりにせず、各工程で人間が確認するという考え方です。
3. 継続的な改善：ルールとフィードバックで自分の欲しいケースを作れるようにする
なぜ継続的な改善が必要か
テストケースは現場やプロダクトによって異なることが多いです。AIが最初から自分の欲しいケースを作ってくれるとは限りません。
そこで、ルールを整備して、AIにフィードバックを繰り返すことで、自分の欲しいケースを作ってもらえるようにしています。
やっていること：ルールファイルを整備する
先ほどのレビューで「推測でテストケースを作成しないように」と指摘しました。この指摘をルールファイルに追加します。
AIへの指示：
テストケース作成全般のルールとして、受け入れ条件に記載されていない内容を
推測してテストケースに含めることを禁止するルールを .cursor/rules に追加してください
追加されたルール：
# テストケース作成ルール
## 基本原則
### 推測の禁止
- **受け入れ条件に記載されていない内容を推測してテストケースに含めることを禁止する**
- テストケースは受け入れ条件に明示的に記載されている内容のみをカバーすること
- 実装の詳細や一般的な動作を推測して期待結果に含めないこと
### テストケース作成時の注意事項
1. 受け入れ条件を正確に読み取り、記載されている内容のみをテストケース化する
2. 受け入れ条件に記載されていない動作や状態については、テストケースに含めない
3. 一般的なUIの動作（例：モーダルの背景クリック、ESCキーでの閉じる動作など）も、受け入れ条件に記載されていない限り含めない
ルールを適用して再度テストケースを作成
このルールを適用して、再度テストケースを作成してみます。
AIへの指示：
ACC-001: 通知設定画面から「通知ON・通知OFF」の設定ができる
ACC-002: 通知ONになっている機能を通知OFFにすることができる
ACC-003: 通知ONにする時に確認ダイアログが出る
この受け入れ条件をカバーするテストケースを @rules に沿って作成して
AIの出力：
## ACC-001: 通知設定画面から「通知ON・通知OFF」の設定ができる
### テストケース TC-001
**前提条件**: 通知設定画面が表示されている
**テスト手順**:
1. 通知設定画面を開く
2. 「通知ON・通知OFF」の設定を行う
**期待結果**:
「通知ON・通知OFF」の設定ができる
---
## ACC-002: 通知ONになっている機能を通知OFFにすることができる
### テストケース TC-002
**前提条件**: 通知ONになっている機能が存在する
**テスト手順**:
1. 通知ONになっている機能を開く
2. 通知OFFに設定する
**期待結果**:
通知ONになっている機能を通知OFFにすることができる
---
## ACC-003: 通知ONにする時に確認ダイアログが出る
### テストケース TC-003
**前提条件**: 機能を通知ONにする操作が可能な状態である
**テスト手順**:
1. 通知設定画面を開く
2. 通知ONにする操作を実行する
**期待結果**:
確認ダイアログが出る
だいぶスッキリしましたが、抽象度が高くなりました。これは推測がなくなった結果、情報量が減ったとも言えます。
これはトレードオフですが、推測で間違った情報を入れられるよりは、抽象的でも正確な情報の方がいいと考えを切り替えました。足りない情報は、プロダクト情報として追加していけばいいのです。
ルールやプロダクト情報を追加するとどうなるか
このように、最初は抽象的なテストケースになりますが、ルールやプロダクト情報を追加していくことで、自分の期待値に沿ったテストケースができていくと思います。
私の場合、以下のような情報をルールファイルに追加しています：
- 画面仕様ID（SCR）の採番と内容
- プロダクト固有のUI要素（プルダウン、モーダル、ボタン名など）
- 環境別のテストパターン（Windows Chrome、macOS Safari、モバイルブラウザ）
- 過去のテストケースの参照
- テストケースのカラムを指定する
これらを追加した結果のイメージです：
（実際の要件ではないのであくまでイメージになります）
### TC-001-002: 通知OFF機能を通知ONにする
**テスト目的**: 通知OFF機能を通知ON状態に変更できることを確認する
**機能エリア**: 通知設定機能
**テスト種別**: 機能テスト
**操作者**: 管理者
**優先度**: 最高
**実施環境OS**: Windows 11
**実施環境ブラウザ**: Chrome
**受け入れ条件ID**: ACC-003 / SCR-008, SCR-009
**事前条件**:
- 通知OFF機能が存在する
**操作手順**:
1. 通知設定一覧画面で通知OFF機能をクリック
2. 通知設定詳細画面が表示される
3. ヘッダー右側の「通知OFF」ドロップダウンをクリック（SCR-008）
4. 「通知ON」を選択
5. 確認ダイアログが表示される（SCR-009）
6. 確認ダイアログで「通知ONにする」ボタンをクリック
**期待結果**:
- 確認ダイアログが表示され、機能が通知ON状態になる
**備考**:
- （テスト実行時に気づいた点やメモを記載）
**AIフィードバック**:
- （AIが生成したテストケースへの改善点を記載し、次回のルール改善に活かす）
先ほどの抽象的なテストケースと比較すると：
| 項目 | 推測禁止ルールのみ | ルール・プロダクト情報追加後 |
|---|---|---|
| 操作手順 | 「通知ONにする操作を実行する」 | 「ヘッダー右側の『通知OFF』ドロップダウンをクリック」 |
| 期待結果 | 「確認ダイアログが出る」 | 「確認ダイアログが表示され、機能が通知ON状態になる」 |
| 画面仕様 | なし | SCR-008, SCR-009 などで紐付け |
| 環境情報 | なし | Windows 11 / Chrome |
このように、ルールやプロダクト情報を追加することで、より具体的なテストケースに近づけていけると感じています。
私はプロンプトを毎回手書きするのではなく、**ルールファイル（.mdcファイル）**を整備してAIに指示を出しています。Cursorでは、ルールファイルを設定しておくと、AIが自動的にそのルールを参照して動作してくれます。
継続的な改善のサイクル
私は以下のようなサイクルで改善を続けています：
- テストケース作成: ルールに基づいてAIにテストケースを作成してもらう
- レビュー: 作成されたテストケースをレビューする
- フィードバック: 問題があれば「ここはこうしてほしい」とAIにフィードバックを返す
- ルール・知識の蓄積: フィードバックの内容をルールやプロダクト知識として蓄積する
- 次回に活かす: 蓄積したルール・知識で次回のテストケース作成を改善
実際に試すことでAIへの理解が深まり、だんだんと欲しいテストケースに近づいてきた感覚があります。
まとめ
明示的な仕様からテストケースを作成する際に意識している3つのことを共有しました：
1. 要件への採番
- 要件（受け入れ条件）にIDを振っておく（ACC-001など）
- どのテストケースがどの要件をカバーしているかわかりやすくなる
- レビュー時に指摘箇所を明確に伝えられる
2. ステップバイステップでレビューする
- AIも推測して変えてしまうことがあるので、人間のレビューは必ず行う
- 早い段階でレビューしておくと、手戻りが少なくなる
3. 継続的な改善
- ルールファイルを整備する
- AIにフィードバックを返し、ルールやプロダクト知識として蓄積する
効率化のポイント
- 最初は時間がかかる: ルールファイルの整備など、最初は準備に時間がかかります
- 徐々に効率化できる: AIへの理解が深まり、ルールや情報が集まってくると効率化できます
- レビューの時間は必要: AIが作成したテストケースのレビューは必ず必要なので、その時間は見込んでおく必要があります
おわりに
本記事では、明示的な仕様からテストケースを作成する方法を共有しました。
私が感じているのは、AIを使う習慣をつけて、継続的に改善していくことが大切だということです。
AIは飛躍的に進化しており、これからますます欠かせないものになってくると思います。最初から完璧なテストケースが出てくるわけではありませんが、継続的にAIに触れてフィードバックを繰り返すことで、だんだん自分の欲しいケースを作ってもらえるようになってきました。
私自身、AIへの理解深めながら、まだまだ試行錯誤している中ですが本記事が少しでも参考になる部分があれば幸いです。
今後の展望: 本記事ではスコープ外としましたが、暗黙知的なテスト分析・設計（過去の不具合パターンの活用、ペルソナ別のテスト観点など）についても試行錯誤中です。いつか成果が出たら共有できればと思います。