QAはAIをどう使うべきか？レビューとテストケース作成の実践知

はじめに

UPSIDER CARDチームにQAとして帯同しているteraです。

エンジニアがAI駆動開発で生産性を上げている中で、QAが従来のやり方のままでいると、品質以前に開発のボトルネックになってしまう。この危機感から取り組んできた、QA業務におけるAI活用の実践知を共有します。

※現時点でNotion AIおよびCursorで使用するLLMはClaude Opus 4.5を使用しています。 (Cursorは自動またはClaude Sonnet 4.5も使い分けています。)

品質の良い仕様書が、なぜAI活用の精度を大きく左右するのか

実践知を紹介する前に、前提となる仕様書について触れておきます。

当初はChatGPTを使って仕様書や画面デザインを渡せば、十分なアウトプットが得られるのではないかと期待していました。しかし実際には期待したレビューやテストケースはなかなか生成されず以下のような課題を感じていました。

曖昧さをAIが勝手に補完する
過剰なテストケースが生成される
ドメイン知識が考慮されない

これらの課題は、AIが使えないというよりも、AIに渡している情報の前提が整理されていないことが問題でした。実際に使えると感じ始めたのは、後述するNotion AIやCursorの活用に加えて、仕様書の構成を見直してからです。

以下は、実際に使用している仕様書テンプレートの一例です。

【仕様書テンプレート例】

# Scope
## In Scope:

## Out of Scope:

# Prerequisites

# Details / Notes
## Constraints

# UI Behavior

# Validation Rules

# Technical Notes

# Edge Cases

# Error Handling

一定のフォーマットで整理することで、仕様の意図や制約が一貫して伝わるようにしました。また、ドメイン知識や非機能観点を、テスト観点・仕様レビュー用ガイドとして明示的に用意しました。これらにより、AIによるレビュー・テストケース生成の質が実用レベルになりました。

人にとって分かりやすい仕様書は、AIにとっても分かりやすい。 QAが普段から意識している「第三者が読んでも理解できる資料」を作るという姿勢は、そのままAI活用の精度向上につながっていました。

Notion AIとCursorを使ったレビュー業務

Notionに記載した仕様書に対し、Notion AIとCursorを使ってAIによるレビューを行っています。目的は、実装や品質に直結するリスクを効率よく洗い出すことです。

以下は、実際に使用しているプロンプトの一例です。

【プロンプト例】

あなたはシニアQAエンジニアとして、提供する「レビュー観点」に基づき、仕様書のレビューを行ってください。

## レビューの基本方針（重要）
網羅性よりも「実効性」を重視します。
何でもかんでも指摘するのではなく、以下の3点に絞って厳密にレビューしてください。

1. 【致命的な漏れ】実装時にエンジニアが判断に迷う、またはバグに直結する仕様の欠落
2. 【論理的矛盾】前後の説明や、既存プロダクトとの明らかな矛盾
3. 【データの不整合】境界値、権限、状態遷移など、システムを破壊しうる考慮漏れ

※「あれば便利」といった改善要望や、一般的なUIのベストプラクティスなどの「重箱の隅をつつく指摘」は不要です。

## レビュー対象の仕様書
[ここに「仕様書」のリンクを貼り付けてください]

## レビュー用ドキュメント（参照用）
[ここに「テスト観点・仕様レビューガイド」のリンクを貼り付けてください]

レビューのフェーズによって、Notion AIとCursorを使い分けています。仕様がまだ固まりきっていない段階ではNotion AIを使い、記述の曖昧さや前提条件の不足、仕様として言語化しきれていない意図を洗い出します。最近は仕様全体を踏まえた質問精度が上がり、人にレビューしてもらう前のセルフチェックとして使いやすくなりました。一方、実装が具体化してきた段階ではCursorを使い、実際のコードやAPI定義と突き合わせながら、API処理の考慮漏れや既存実装への影響、性能・パフォーマンスといった仕様書だけでは気づきにくいリスクを確認しています。

仕様書から受入条件（Gherkin）を生成する

そもそも、PBIに受入条件が明示的に書かれていないケースは少なくありません。 Epicや仕様書側で仕様を管理している場合、PBIは実装作業を切り出すための単位として使われることが多く、「何ができれば完了か」は暗黙的に共有されている前提になりがちです。

その結果、PBI単体では完了条件が曖昧になり、「このPBIで本当に満たすべき要件は何か」が見えにくくなってしまいます。

そこで、チーム全員で「完了の定義」の認識を合わせ、「このPBIでやるべきこと・大事なこと」を明確にするために、仕様書からPBI単位の受入条件をAIで切り出す手法を取り入れました。

具体的には、Cursorを使用してGherkin形式の受入条件を生成しています。

Notionに記載している仕様書はEpic単位で整理されているため、そのままではPBIに対する受入条件としては粒度が合いません。そこで、PBIの内容に合わせ、プロンプトにより対象となる範囲を指定して抽出を行っています。

【プロンプト例】

あなたはシニアQAエンジニアです。
Product Backlog Itemを振る舞い駆動開発するために、Gherkinで受入条件を書きたいと考えています。

## インプット：対象の仕様書
[ここに「仕様書」のリンクを貼り付けてください]

## インプット：対象のProcuct Backlog Item
[ここに「Product Backlog Item」のリンクを貼り付けてください]

## レビュー用ドキュメント（参照用）
[ここに「汎用テスト観点・仕様レビューガイド」のリンクを貼り付けてください]

仕様書を元に、Product Backlog Itemの受入条件（Gherkin）を考えてください。
・実装範囲・内容は、Product Backlog ItemのSub-issueを元に判断してください
・[条件・制約を記載してください]
・整合性のあるテスト用データを作成してください
・Gherkin形式で記述してください
　・テーブルで表現する場合は、Markdownのテーブル形式を使用してください
・テスト用データのうち1つは最大文字数で記述してください
　・最大文字数の定義は、レビュー用ドキュメントを参照してください

テスト用データを生成する際には、前述した汎用テスト観点・仕様レビューガイドを参照させたり、必要に応じてコードからデータ生成を行わせることで、実装と乖離しない受入条件になるよう工夫しています。

仕様書からテストケースを生成する

テストケースのAI生成は、工数を削減することと、観点漏れを防ぐことを目的に行っています。

【プロンプト例】

あなたはシニアQAエンジニアです。
提供する「レビュー観点」と「仕様書」に基づき、実装・テストに必要なテストケースを作成してください。

## 作成方針
「数」を増やすのではなく、シニアの視点で「リスクが高い箇所」を重点的に抽出してください。

1. 【正常系】主要な各機能を1パスずつ（最小限）。
2. 【異常系・境界値】仕様で定義された制限値の前後、エラーが期待される操作。
3. 【条件分岐】権限（ロール）による挙動の違いや、外部連携の成功/失敗パターン。
4. 【判断基準】「仕様の不備で実装が止まるリスク」や「データ破壊のリスク」を優先。

## 出力形式・ルール
・[テスト範囲]
・[特定のカラムに出力して欲しい内容]

## テスト観点サマリー
・ページ下部に、作成したテストケースの全体像を要約して記載してください。
　・（例：どの機能の影響範囲を重点的にカバーしたか、どのようなデータ不整合リスクを考慮したか等）

## インプット：対象の仕様書
[ここに「仕様書」のリンクを貼り付けてください]

## レビュー用ドキュメント（参照用）
[ここに「汎用テスト観点・仕様レビューガイド」のリンクを貼り付けてください]

Notion AIやCursorを使用することで、前提条件や手順については、人が書いたものと遜色ないレベルで生成されると感じています。まずNotion AIで全体を生成し、観点が足りないと感じた場合は、Cursorでも生成して必要なケースをマージしています。 Cursorは1つのテストケースに期待値を詰め込みやすいといったクセはありますが、境界値や異常系などは得意です。

おわりに

AIを活用することで、レビューやテストケース作成の工数は確実に減りました。特に、AIが仕様書と既存コードを突き合わせてレビュー指摘を出力できるようになり、エラー仕様など実装に直結するヌケモレの早期検知が定着しました。加えて、元ドキュメントの精度向上により、生成するテストケースもほぼ手修正不要なレベルに達しています。

今後は、ドメイン知識・非機能要件・セキュリティ・運用上のエッジケースといった領域でも、AIによる補助・生成を広げていきたいと考えています。

この記事に興味を持った方は、ぜひカジュアル面談でお話しましょう。