AIでテスト設計を自動化：チームの事例紹介

こんにちは、hacomonoでエンジニアをしているタクローです。
私たちのチームでは、ここ数ヶ月にわたりAIを活用したテスト分析とテストケース作成の自動化に取り組んできました。
運用を開始してからおよそ2ヶ月が経過し、実際にチームの生産性や品質にポジティブな成果が見えてきたため、今回はその取り組み内容と学びを記事としてまとめました。

背景：テスト設計フローとその課題

私たちのチームでは、QAリソースが十分でない状況を背景に、
テスト工程を効率的に進める方法を検討していました。
その中で次のような方針が挙がっていました。

エンジニアにもテスト観点を養ってもらい、開発段階から品質意識を高める
テストの初期設計をエンジニアが担い、QAはより専門的なレビューや探索的テストに集中できる体制をつくる

しかし、実際にエンジニアがテスト設計やテストケースの作成を担おうとした段階で、いくつかの課題が見えてきました。

● 課題①：エンジニアの作業負担が大きくなる懸念

開発とテスト設計の両方をこなすことになれば、エンジニアの負担が増え、アウトプットの質やスケジュールに影響が出る可能性があると考えました。

● 課題②：実装者による「思い込み」が入りやすい

実装者本人がテスト観点を考えると、無意識に「正しく動くはず」という前提で進めてしまい、重要な観点の抜け漏れにつながるリスクがあると想定しました。

解決策：AIにテスト設計とテストケース作成を任せる

前述のような懸念を踏まえ、私たちのチームではAIによるテスト分析とテストケース作成の自動化を導入しました。
目的は、エンジニアの作業負荷を軽減しつつ、テスト観点の抜け漏れを防ぎ、品質保証体制の安定化を図ることです。

対話型プロンプトベースの成果物の出力

導入にあたっては、事前にMarkdown形式で定義したプロンプトをAIに読み込ませることで、成果物を自動生成できるようにしました。

💡補足：PBIとは？

本記事で登場する PBI（Product Backlog Item） とは、アジャイル開発における「開発チームが実装すべき具体的な作業項目」を指します。
プロダクトバックログに積まれる単位であり、ユーザーストーリー、機能追加、改善要望、バグ修正などを含みます。
一般的に、PBIには次のような情報が含まれます。

タイトル：開発対象となる機能や改善の概要
受け入れ条件（Acceptance Criteria）：完了と見なすための具体的な条件
Out of Scope（対象外事項）：今回の開発・テスト対象から除外する範囲

私たちのチームでは、このPBIを単位としてテスト設計の自動化を行っています。

実際に利用しているプロンプト

# PBIベースのテスト成果物生成プロンプト
あなたはアジャイル開発におけるQAエキスパートです。
ユーザーから以下の3つの情報を対話形式で順に取得し、その内容を元に「テスト分析テンプレート.md」と「テストケーステンプレート.md」に従って成果物を生成してください。

## 🔽 取得する情報
1. PBIのタイトル
2. PBIの受け入れ条件（箇条書き形式）
3. PBIのやらないこと（Out of Scope）

## ⚠ 制約と要件
- 3つの情報を順番に確認し、すべてそろった時点で成果物を出力してください。
- 成果物は、すでに存在する以下のテンプレートに準拠して作成してください：
  - `テスト分析テンプレート.md`
  - `テストケーステンプレート.md`
- 出力形式は **Markdown** としてください。
- テスト分析では、以下の観点を含めてください：
  - 受け入れ条件から導かれる通常のテスト観点
  - **アドホックテスト（探索的テスト）の観点**：仕様に書かれていない不具合の可能性や、想定外の使われ方に着目した自由な観点を1～2個記述すること
- テストケース作成時には、**受け入れ条件**に基づくケースに加えて、アドホック観点から派生する代表的なケースも1～2件追加してください。
- **既存のプロダクトコードや仕様**も参考にして、機能の整合性や副作用などを想定して分析・設計を行ってください。
- 「やらないこと（Out of Scope）」がある場合は、テスト範囲に含めないよう配慮してください。

## ✅ 出力の構成
1. "pbiのタイトル"テスト分析.md
2. "pbiのタイトル"テストケース.md
上記の二つのファイルを出力する

それでは、ユーザーへの質問から開始してください。

利用者による属人性を排除するために、リファインメントが完了し、共通認識が取れているPBIの情報をもとに、対話形式で実行されるようにしています。
Cursor や Claude Code のような、コードベース全体を把握して支援できるAIコードエディタ上でプロンプトの実行を指示することで、対話が開始されます。

対話の流れ

その後、AIが対話形式で以下の3点をユーザーに順番に尋ねます。

PBIのタイトル
PBIの受け入れ条件（箇条書き形式）
PBIのやらないこと（Out of Scope）

出力される成果物

3点すべてが揃うと、AIは以下の2つのMarkdownファイルを自動で生成します。

「PBIのタイトル」テスト分析.md
「PBIのタイトル」テストケース.md

精度の高い成果物を実現する仕組み

単に入力された情報を処理するだけではなく、実際のプロダクトコードや既存の仕様情報も参照した上でテスト観点を導き出すようにしています。
これにより、以下のような精度の高いアウトプットが実現できています。

コードの実装内容に即したテスト観点
たとえば、受け入れ条件に記載されていないが、コード上で分岐しているロジックやエッジケースをAIが検知し、それに応じたテストケースを補完してくれます。
仕様と実装の不整合にも気づける
受け入れ条件とコードにギャップがある場合、AIがその違和感を捉え、アドホック観点として補足することで、設計ミスや仕様漏れの早期発見にも貢献します。