PRをテストのインプットにすることで変わる、生成AIとの協業型テストプロセス

この記事は ニーリーアドベントカレンダー 16日目です。

こんにちは。株式会社ニーリー QAチームの関井（@ysekii_）です。

昨今、QA界隈のテックブログでも「生成AIによる業務効率化」の話題で持ちきりです。
そんな中、ニーリーでも生成AIの活用について地道に試行錯誤を重ね、ようやくこれなら実務で通用するかもしれないというフローを構築しました。

今回は、私たちが生成AIを活用してテスト設計の効率化をどのように実現しようとしているのか、その取り組みをご紹介します。

小規模開発の「仕様書ない問題」とテストの悩み

本来はドキュメントがあるべきですが、リソースの限られる小さな機能変更やバグ修正などの小規模な開発案件では、ドキュメントが十分に整備されていないことは現場でよくある悩みだと思います。
ドキュメントがない中でテスト設計を進めると、QAと開発者の双方に課題がのしかかります。

• QAエンジニアの苦悩：JiraのコメントやSlackメッセージなどの断片的な情報から仕様を把握する必要があり、不明点は開発者に確認するしかない。
• 開発者の苦悩：QAエンジニアからの質問に回答する時間が増えるため、工数が圧迫される。また、開発者がテスト設計を行う場合は、テスト設計ノウハウがなく作業が思ったように進まない。

こうした課題から、コミュニケーションや工数の問題が日常的に発生しがちです。そこで今回は、「仕様書がないなら、AIに仕様を逆生成させ、ついでにテストも生成させればいいじゃない」というアプローチで、テスト生成フローを構築してみました。

💡 なぜ「PRをインプット」としてテスト設計してもいいのか？

そもそも、「PR（Pull Request = コード）をインプットにしたら、もしコードが間違っていたら、その間違った仕様のテストができてしまうのでは？」という疑問を持つ方もいるでしょう。

今回のフローでは、PRから直接テストを生成するのではなく、後述の3ステップ構成を導入することで、この問題を解決しています。 Step 1で生成された仕様を人間がレビューする工程を挟むことで、AIの誤読や実装ミス（仕様の認識違い）を早期に検知し、誤ったテスト設計になるのを防ぎます。

今回のアプローチ

今回の方法では、Cursor + GitHub MCP (Model Context Protocol) の組み合わせを利用しました。*1

• Cursor: 今回のテスト設計の主役。Composer機能で、複数のファイルや文脈を同時に扱います。
• GitHub MCP: AIがGitHub上のPR情報（差分、コミットログ）を直接読みに行けるようにする仕組み。

テストケースまでの「3ステップ生成」

当初はテストケースまで一気に生成させようとしましたが、仕様からテストケースまでの出力が膨大になりレビューコストが高すぎてやめました。
そこで、人間がテスト設計を行う思考プロセスに基づき、フローを3ステップに分割しました。

1. Step 1: PRから「変更仕様まとめ」を生成
2. Step 2: テスト観点を生成
3. Step 3: テストケースを生成

Step 1: 変更仕様まとめの生成

コード差分から、E2Eテストレベルでの影響範囲の特定やユーザー／システムの振る舞いを推測させるのが目的です。プロンプトでは以下の点を工夫しました。

• ペルソナの明確化（今回はシニアQAエンジニアになってもらいました）
• 「リバースエンジニアリング」の思考プロセスを指定し、PRの概要が薄くても仕様を正しく把握させる
• E2E視点の徹底（内部実装ではなく、ユーザーが操作・確認できることに集中）

これにより、実装者以外（特にQAエンジニア）が見ても「何が変わったのか」が一目で分かる仕様まとめが生成されます。

思考プロセス（Step1プロンプトからの抜粋）：

## 思考プロセス（Reverse Engineering）

いきなり仕様を要約せず、以下のステップで思考を行ってください。

1. **ユーザーストーリーの再構築**:
   * コード変更から「ユーザーは何をしたいのか」「ユーザーにどんな価値を提供するのか」を推測する。
   * 例: ダイアログコンポーネントの追加 → 「ユーザーが画面上で確認ダイアログを通して操作を実行する」

2. **操作フローの特定**:
   * ユーザーが実際に行う操作の流れを時系列で整理する。
   * 画面遷移、ボタンクリック、入力、確認、完了までの一連の流れを明確にする。

3. **目視確認可能な結果の特定**:
   * ユーザーが画面上で確認できる結果（ボタン表示、通知、ステータス変更等）を洗い出す。
   * メール送信、外部システムへの通知など、ユーザーに影響する外部への出力を特定する。

4. **異常系・エッジケースの特定**:
   * 操作フロー中にエラーが発生した場合、ユーザーにどう見えるか（エラーメッセージ、状態保持等）をコードから読み取る。
   * 権限がない場合、不正なデータの場合など、制約違反時の振る舞いをコードから読み取る。

5. **既存機能への影響分析**:
   * 変更により既存の操作フローに影響がないか確認する。

6. **コードから判断できない点の洗い出し**:
   * コードだけでは判断できないUI/UX仕様（例: ダイアログのクローズ動作、エラーメッセージ文言、ローディング表示の有無）があれば、その旨を記載する。
   * ただし、詳細な確認事項リストの作成はステップ2で行います。

👀 Step 1 レビューのポイント

• 意図の整合性: 出力された仕様が、実装者の意図と合致しているかを確認する
• 仕様の網羅性: PRの変更範囲をすべてカバーしているかを確認する
• 仕様のキャッチアップ: QAエンジニアは、この生成結果を読むことで短時間での仕様把握が可能になる

Step 2: テスト観点の生成

整理された仕様を元にテスト観点を洗い出し、全体像を把握しやすくします。

1. マインドマップ形式での構造化: 階層構造で出力させ、網羅性の確認を容易にする
2. 優先度（P0〜P3）の付与: テストスコープの調整を可能にする

思考プロセス（Step2プロンプトからの抜粋）：

## 思考プロセス（E2E Testing）

ステップ1で分析した仕様を基に、以下のステップでテスト観点を設計してください。

1. **操作フローから観点を抽出**:
   * ステップ1で特定した操作フローの各ステップが、テスト観点の中心となる。
   * 各ステップで「何を確認すべきか」を明確にする。

2. **正常系観点の設計**:
   * ハッピーパス（最も典型的な成功フロー）
   * 代替フロー（別の成功パターン）

3. **異常系・エッジケース観点の設計**:
   * バリデーションエラー、権限エラー、ビジネスロジックエラー
   * 境界値、制約違反

4. **画面表示・UI制御観点の設計**:
   * ボタン・フィールドの表示/非表示、有効/無効
   * 権限・ステータスによる表示制御

5. **データ整合性・外部連携観点の設計**:
   * 画面リロード後のデータ表示確認
   * メール送信などの外部出力確認

6. **既存機能への影響観点の設計**:
   * 既存の操作フローへの影響
   * 回帰テスト観点

7. **不明点・確認事項の明確化**:
   * コードやステップ1の仕様分析だけでは判断できない点を洗い出す
   * 各確認事項を対応するテスト観点と紐づける

👀 Step 2 レビューのポイント

• 優先度の妥当性: 過剰品質にならないよう、適切なスコープに調整する
• 観点の不足: ドメイン知識が必要な観点やロジックが抜けていないか確認する

Step 3: テストケースの生成

Step 2で整理した観点の中から、指定した優先度を確実かつ効率的にカバーする具体的なテストケース／テストシナリオを生成します。

1. テストタイプによる出力形式の使い分け:
   • 条件組み合わせテスト: 表形式で作成し、抜け漏れをわかりやすくする
   • E2Eシナリオテスト: 一連の流れを確認する操作フローを作成
2. 観点カバレッジマトリクスの作成: 「どのテストケースが、どの観点をカバーしているか」を示し、網羅性を瞬時に判断できるようにする

思考プロセス（Step3プロンプトからの抜粋）：

## 思考プロセス（Test Case Design）

ステップ2で設計したテスト観点を基に、以下のステップでテストケース・シナリオを設計してください。

1. **P0観点の確認**:
   * ステップ2で設計したP0観点をすべてリストアップする。
   * 各P0観点がどのようなテストケース・シナリオでカバーできるかを検討する。

2. **テストケース vs シナリオの選択**:
   * 条件組み合わせテスト（因子・水準）が必要な観点 → テストケース表形式
   * 操作フロー確認が必要な観点 → シナリオ形式

3. **テストケース表の設計**:
   * 因子（テスト対象の変動要素）を特定する
   * 水準（各因子が取り得る値・状態）を特定する
   * 組み合わせパターンを網羅する
   * 各テストケースの期待結果を明確にする

4. **シナリオの設計**:
   * P0観点をすべてカバーできる最小限のシナリオセットを作成する
   * 1つのシナリオで複数のP0観点を効率的に検証できるよう設計する
   * 実際のブラウザ上で再現可能な操作手順とする

5. **カバレッジマトリクスの作成**:
   * すべてのP0観点が少なくとも1つのテストケースまたはシナリオでカバーされることを確認する
   * 未カバーのP0観点がないことを確認する
   * カバレッジマトリクスで可視化する

6. **最終確認**:
   * P0観点の完全網羅を確認
   * テストケース・シナリオの実行可能性を確認

👀 Step 3 レビューのポイント

• 網羅性: カバレッジマトリクスで、指定した優先度の観点がすべてカバーされているかを確認する
• 実行可能性: 生成されたシナリオの手順に無理がないかチェックする

【Step 3 の出力イメージ】

条件組み合わせテストケース

ID	テスト観点	権限	ステータス	承認機能	期待結果	優先度	観点No
TC-01	承認ボタン制御	管理者	申請中	ON	ボタンが表示される 承認ダイアログが開く	P0	#1
TC-02	承認ボタン制御	一般	申請中	ON	ボタンが非表示	P0	#2
...	...	...	...	...	...	...	...

観点カバレッジマトリクス

観点ID	観点概要	TC-01	TC-02	シナリオ1	網羅状況
#1	基本フロー	-	-	✓	OK
#2	ボタン制御	✓	✓	-	OK
...	...	...	...	...	...

モデルによる出力の違い

今回の検証では、いくつかのモデルで生成結果を比較しました。

• Claude Sonnet 4.5: 詳細で網羅性が高いが、レビューでの取捨選択が必要。
• GPT-5.1: バランス型。テスト手順の記述が丁寧な印象。
• Gemini 3 Pro: シンプル。P0観点だけでは十分ではなく、実用的なテストとするにはP1やP2の観点も含める必要がある。

この傾向は、あくまで今回用いたプロンプトと検証案件での一例です。プロンプト設計やプロダクト特性によって最適なモデルは変わり得るため、実際の運用では複数モデルで生成し、その開発案件に合うものを選ぶ運用が現実的だと感じました。

期待される導入効果

本運用前の事前検証で得られた主な効果は以下の通りです。

1. 「ゼロから書く」工数の大幅な削減

従来半日〜1日かかっていた作業が、AIによる生成（約10分）＋人間によるレビュー・修正（1〜2時間程度）に短縮できる見込みです。「ゼロから生み出す」という最も重い工程をAIに任せられるため、大幅な効率化が期待できます。

2. メンタルコストの低下と品質の向上

白紙からの作業という「書く苦しみ」からの解放に加え、AIの「網羅性」と人間の「ドメイン知識」が相互補完することで、人が独力でテスト設計するよりも質の高いテスト観点が得られると期待しています。

今後の課題

今回の手法は「完成したPR（コード）」を起点としているため、仕様認識の誤りによる手戻りリスクが残ります。本来であれば、コードが書かれる前段階で品質を作り込むべきです。

そのため、今後はPRよりもさらに上流、例えば要件定義や設計のフェーズからAIを活用する方法も引き続き検討していきたいと考えています。

おわりに

正直なところ、最初は私も「PRをインプットとしてテスト設計するのはどうなんだろう」と懐疑的でした。しかし、実際にこのフローで検証してみると、予想以上に実用的な結果が得られ、良い意味で裏切られました。

同じような課題を持たれている方は、ぜひ「3ステップのテスト生成フロー」を試してみてください！
比較的気軽に始められる方法なので、まずはPR1つだけでも試してフィット感を確かめてみるのがおすすめです。