生成AIをQA業務にどう使うか？テスト現場で使える4つのプロンプト例
- AIソリューション
- ソフトウェアテスト・品質保証
Introduction
テスト計画や設計の場面で生成AIを使ってみたものの、「どこに当てはめればよいのかわからない」と感じたことはないでしょうか。プロンプトを工夫すれば何かできそうですが、テスト工程のどこで使うべきかが曖昧なまま、結局使いこなせないケースは多いです。
この「使いどころが分からない」という状態は、QA業務でAI活用が進まない原因になります。テストは複数の工程に分かれているため、まずどの工程で何を任せるかを切り分けないと効果が出ません。この記事では、テスト工程ごとにAIをどのように使い分けるかを整理し、プロンプトとアウトプットをセットで提供します。
この記事でわかること
- テスト工程ごとの生成AIの使いどころが分かる
- 各工程でそのまま使えるプロンプトが手に入る
- QA業務に適用する具体的なイメージが持てる
使用するAIモデルは、ChatGPT・Claude・M365 Copilotなど主要な生成AIであれば本記事のプロンプトをそのまま使用できます。生成AIを使用する際は、事前にオプトアウト設定や社内のAI利用ポリシーをご確認ください。
目次
生成AI活用の前に押さえておきたい基本
生成AIの出力は「そのまま使うもの」ではなく、「検討の起点」として扱います。最終的な判断は人が担い、AIは情報の整理や抜け漏れの補完といった領域で活用する、という役割分担を置きます。対話型AIを使っていると、対話を重ねるうちに最初のゴールが曖昧になることがあります。出力を改善しているのか、方向がずれているのか判断できなくなります。そのため、最初に「何を出したいのか」を明確にしてから使い始めます。
なお、仕様書や不具合メモをAIに渡す前に、個人情報・認証情報のマスキング要否と、社内ポリシーで許容される入力範囲を必ず確認してください。
では、テスト工程ごとに使いどころを見ていきましょう。
テスト計画：生成AIで品質リスクを可視化する
背景
テスト計画の段階でリスクを洗い出す作業は、担当するQAエンジニアの経験や感覚に依存しやすく、属人化しがちです。「何を見落としているかわからない」という不安を抱えたまま計画を進めると、後工程で想定外のリスクが顕在化します。
インプット情報
プロジェクト・プロダクト概要（変更点・仕様・スケジュール・過去障害など）
形式：テキスト・Excel・Word・PDF・Confluenceなどのドキュメント
ECサイトリニューアル（改修）
・ECサイトの決済画面をUI全面改修（ユーザー側、店舗側）
・決済にコンビニ払いと後払い追加（新機能）※過去にクレカ決済で本番障害あり
・コンビニ払いは支払い期限あり、後払いは与信審査あり
・外部ベンダー1社に開発委託（品質基準・受入条件は未合意）
・リリースはざっくり2ヶ月後、テスト期間3週間
プロンプト例
あなたは経験豊富なQAエンジニアです。
プロジェクト・プロダクトに関するインプット情報をもとに、テスト計画で考慮すべき品質リスクを洗い出してください。
【思考プロセス】
洗い出し前に以下を順番に行ってください。
1.変更点（新機能・改修・体制変更）を列挙する
2.過去障害・既知の懸念事項を列挙する
3.1と2をもとにリスクを特定し、重複・類似は統合してから出力する
【影響度定義】
・3：品質・テストが停止する深刻な影響あり
・2：品質・テストに一部停止・遅延影響あり
・1：品質・テストへの影響は少ない
【発生確率定義】
・高：顕在化する確率が高い
・中：顕在化する確率が中程度
・低：顕在化する確率は低い
【制約】
・リスクの重複・類似は統合すること
・影響度3×発生確率高のリスクを必ず上位に並べること
【出力形式】
| No | リスク区分 | 分類 | 想定されるリスク | 影響度 | 発生確率 | 判断根拠・補足 | テスト戦略において考慮すべき点（提案） |
—
【インプット情報】
（ここにインプットを貼り付ける）
アウトプット例（上位3件）
| No | リスク区分 | 分類 | 想定されるリスク | 影響度 | 発生確率 | 判断根拠・補足 | 考慮すべき点 |
|---|---|---|---|---|---|---|---|
| 1 | プロダクトリスク | 決済 | コンビニ払い期限切れ時の在庫・注文状態の戻し処理漏れ | 3 | 高 | 支払期限、後払いは与信審査あり | 決済手段別に正常系・異常系テストは必須 |
| 2 | プロダクトリスク | UI/UX | UI全面改修後、旧店舗タブレット端末の決済確定ボタンが見切れる・タップ不可になるリスク | 3 | 高 | 決済画面が全面改修対象 | 主要端末・ブラウザでの表示確認 |
| 3 | プロジェクトリスク | 検証 | 外部連携のサンドボックス環境と本番環境の差異による検証漏れ | 2 | 中 | 外部決済・与信などの連携が想定される | モック・スタブだけでなく、可能な範囲で実連携する |
活用のポイント
属人化しやすいリスク洗い出しをAIに起点として担わせることで、経験の浅いメンバーでもベテランの視点に近い観点を引き出せます。変更点・過去障害・体制上の懸念を箇条書きで渡すだけで、言語化できていなかったリスクを可視化できます。
テスト設計：生成AIでテスト観点を抽出する
背景
テスト設計の中でも、観点の初期洗い出しは負荷のかかる工程です。仕様書を読み込みながら「どこまで確認すれば十分か」を判断するのは簡単ではなく、観点の抜け漏れがそのまま品質リスクにつながるため、慎重にならざるを得ません。経験の浅いメンバーに限らず、多くのテスト設計者にとって判断の難しい工程です。
インプット情報
テスト目的、仕様、対象、範囲、テストタイプ、過去不具合やリスク
形式：テキスト・Excel・Word・PDF・Confluenceなどのテストベース
ふるさと納税ECサイトの会員ランク実装の機能テスト
・テスト対象：会員ランク判定・送料計算・ポイント還元率計算（新機能）
・ランクによって送料とポイント還元率が変わる
・過去にクレカ決済で本番障害あり
・主なリスク：ランク×送料×ポイントの条件分岐が複雑
プロンプト例
あなたは経験豊富なQAエンジニアです。
プロジェクト・プロダクトのテストに関するインプット情報をもとに、テスト観点を洗い出してください。
【思考プロセス】
洗い出し前に以下を順番に行ってください。
1.テスト対象・範囲・タイプを確認する
2.インプット情報からテスト観点を要約で列挙し、重複は統合する
3.対象外・申し送りを整理する
【優先度定義】
・高：システム全体に影響する観点
・中：主要機能に関わる観点
・低：テスト対象への影響が限定的な観点
【制約】
・重複・類似は統合すること
・優先度「高」の観点を上位に並べること
・申し送りはテスト設計に必要な情報に限定すること
【出力形式】
メインテーブル：
| No | 標準／PJ固有 | 分類1 | 分類2 | 分類3 | 優先度 | テスト観点 | 観点の選定理由（AI根拠） |
テスト設計者への申し送り：
| No | 確認観点 | 確認内容 | 確認先 | 優先度 | 理由 |
—
【インプット情報】
（ここにインプットを貼り付ける）
アウトプット例（上位3件）
| No | 標準／PJ固有 | 分類1 | 分類2 | 分類3 | 優先度 | テスト観点 | 観点の選定理由（AI根拠） |
|---|---|---|---|---|---|---|---|
| 1 | PJ固有 | 会員ランク | 判定ロジック | 境界値 | 高 | ランク別の判定条件（購入金額・回数） | ランク誤判定は送料・ポイント全体に連鎖影響するため |
| 2 | PJ固有 | 条件分岐 | 組み合わせ | 網羅性 | 高 | ランク×送料×ポイントの全パターン組合せ | 主リスクとして明記された複雑分岐のため、最重要 |
| 3 | PJ固有 | 計算 | 送料 | ロジック | 高 | ランク別の送料計算 | 金額誤りはユーザ影響・売上影響が大きい |
“
テスト設計者への申し送り
| No | 確認観点 | 確認内容 | 確認先 | 優先度 | 理由 |
|---|---|---|---|---|---|
| 1 | ランク判定仕様 | 判定条件（購入金額・期間・回数）の詳細定義 | PO/仕様書 | 高 | 境界値設計に必須のため、ランク別の仕様を明確にすること |
| 2 | 送料ルール | ランク別送料、無料条件、地域差有無 | 業務担当 | 高 | 分岐網羅設計に影響するため、送料の仕様を確認すること |
| 3 | ポイント仕様 | 還元率・端数処理・付与タイミング | 業務担当 | 高 | 計算ロジックの正確性に影響するため、ポイント仕様を明確にすること |
活用のポイント
生成AIに仕様や変更点、過去の障害情報などを渡すことで、テスト観点の候補を効率良く整理できます。これにより、観点の叩き台を素早く得られるため、自身の考えと照らし合わせながら抜け漏れを確認しやすくなります。
また、「テスト設計者への申し送り」をあわせて出力することで、自分では意識できていなかった観点や見落としにも気づきやすくなり、仕様確認の抜けを防ぐ役割として活用できます。
テスト実行：生成AIでバグ報告を標準化する
背景
不具合チケットはフォーマットとしてはある程度そろっているものの、実際の記載内容はテスト実行者が検証しながら書いていくため、どうしても人によってばらつきが出てしまいます。
その結果、伝えたい情報がうまく伝わらず、開発者が内容を読み解くのに時間がかかったり、やり取りが増えたり、追加で検証が必要になることもあります。
インプット情報
不具合の概要、発生手順、環境
形式：テキスト
ECサイト
カート画面から商品詳細に戻り、再度カートに戻ると商品が重複して表示される。
3回中3回必ず発生。
テストアカウント：A3
環境：STG
端末：Android16.1だけで発生。他は発生しない（最新Chrome）
プロンプト例
あなたは経験豊富なQAエンジニアです。
以下のバグ報告・概要のインプットをもとに、下記の2つを出力してください。
【1. 障害報告チケット】
メモの情報を元に各項目を埋めてください。
情報が不足している箇所は「要確認：（何が必要か）」と記載してください。
【概要】
【操作手順】
【再現性の有無】（あり／なし／未確認）
【環境依存性】（あり／なし／未確認）
【発生環境】（OS・ブラウザ・デバイス・バージョン）
【優先度】（高／中／低）
【重要度】（Critical／High／Normal／Low）
【2. テスターへの確認事項】
以下の3つの観点で、確認が必要な事項を質問形式で優先度順にそれぞれ最大3つまで列挙してください。
・影響範囲：他の画面・機能・アカウント種別でも発生するか
・環境：他の端末・ブラウザ・OSでも発生するか
・発生条件：特定の操作手順や条件でのみ発生するか
—
【インプット情報】
（ここにインプットを貼り付ける）
アウトプット例
【障害報告チケット】
【概要】カート画面から商品詳細に戻り再度カートに遷移すると商品が重複表示される
【操作手順】
1.カート画面を開く
2.商品詳細画面に戻る
3.再度カート画面に遷移する
4.商品が重複して表示される
【再現性の有無】あり（3回中3回）
【環境依存性】あり（Android 16.1のみ発生）
【発生環境】STG / Android 16.1 / Chrome最新版 / テストアカウント：A3
【優先度】高 【重要度】High
【テスターへの確認事項】
・影響範囲：重複表示された状態でそのまま購入した場合、注文・決済に影響が出るか
・環境：Android他バージョンや同スペックの別端末でも発生するか
・発生条件：商品詳細への遷移回数や特定の商品でのみ発生するか
活用のポイント
AIに不具合の概要や再現手順を渡すことで、チケットの構造や必要な項目が自動的に整理されます。そのため、テスト実行者のスキルに依存せず、チケットの品質を一定に保ちやすくなります。また、「テスターへの確認事項」をあわせて出力することで、事前に何を確認しておくべきかが明確になり、不具合報告の質をさらに高めることができます。
テスト報告：生成AIで品質評価・課題を言語化する
背景
テスト完了後の報告書作成では、結果の振り返りや品質の評価、課題の整理、結論の言語化といった工程に時間がかかりがちです。「数字はそろっているのに言葉にできない」「何をどう整理すればよいかわからない」といった詰まりが起きやすく、テスト管理者の経験やスキルによって、まとめ方にばらつきが出やすい部分でもあります。
インプット情報
テスト消化状況・不具合解決状況・重要度別分析のサマリ、振り返りの概要。
形式：Excel・Confluence・Notionなどの管理ファイルやテキスト
テスト結果の所感・メモ
【テスト消化状況】
| テスト名 | ケース数 | OK | NG | 対象外 | 不具合数 | 不具合率 |
|—|—|—|—|—|—|—|
| 結合テストA | 1,276 | 1,246 | 20 | 10 | 15 | 1.2% |
| システムテストB | 366 | 355 | 5 | 6 | 5 | 1.4% |
| 合計 | 1,642 | 1,601 | 25 | 16 | 20 | 1.2% |
【不具合解決状況】
未解決：0件、欠陥17件、仕様2件、指摘ミス1件
【重要度別分析】
Blocker:0 / Critical:0 / Major:3 / Normal:8 / Minor:1 / Trivial:0
【振り返りメモ】
・Majorは決済まわりで3件、修正確認済み
・テスト期間1週間延伸
・後半に不具合集中
プロンプト例
あなたは経験豊富なQAエンジニアです。
テスト結果・所感のインプット情報をもとに、テスト報告書の下書きを作成してください。
【思考プロセス】
以下の順で考えてから出力してください。
1.テスト消化状況・不具合状況の数値を確認する
2.重要度別分析・メモから品質上の特徴を読み取る
3.数値と特徴をもとに総合評価・改善事項・結論を生成する
4.数値が不足している箇所・管理者が確認すべき箇所を整理する
【制約】
・総合評価・改善事項・結論はAIの推測であることを前提とする
・改善事項は総合評価を元に箇条書きで記載すること
・申し送りはテスト管理者自身が確認・判断すべき事項に限定すること
【出力形式】
■総合評価（文章）
■改善事項（箇条書き）
■結論（文章）
■テスト管理者への申し送り
| No | 確認観点 | 内容 | 優先度 |
—
【インプット情報】
（ここにインプットを貼り付ける）
アウトプット例
■総合評価
全1,642件中1,601件がOKとなり、不具合率は1.2%と低水準であった。Blocker・Criticalは発生しておらず、Major不具合3件（決済機能）も修正確認済みのため、全体として品質は概ね良好と推測される。一方で、テスト期間の1週間延伸および後半での不具合集中は改善余地として残る。
■改善事項
・決済周りなど業務クリティカル領域に対するテスト設計の強化
・テスト後半に不具合が集中しないよう、早期テスト・シフトレフトの推進
・テスト進捗・品質指標の中間レビュー頻度の向上
■結論
未解決の不具合はなく、重大な不具合も発生していないことから、リリース判断における品質上の大きな懸念は少ないと考えられる。ただし、スケジュール延伸や不具合検出時期の偏りについては、次回案件での改善が望まれる。
■テスト管理者への申し送り（抜粋）
| No | 確認観点 | 内容 | 優先度 |
|---|---|---|---|
| 1 | 決済領域の品質 | Major不具合3件の原因分析と再発防止策の妥当性確認 | 高 |
| 2 | 不具合検出タイミング | 後半集中の原因特定 | 高 |
| 3 | テスト計画精度 | 1週間延伸の要因整理 | 中 |
活用のポイント
数値を渡すだけで、総合評価・改善事項・結論の下書きが生成されるため、「数字はそろっているが言語化できない」という状態の解消につながります。また、テスト管理者への申し送りを併せて出力することで、見落としやすい観点も自然に補完できます。
まとめ：最終判断の責任を持つのはAIではなく人間である
AIは「どこにでも使うもの」ではなく、工程ごとに役割を分けることで使いどころが明確になります。4つの工程を通して共通しているのは、AIが「作業を代替する」のではなく、各工程で必要な情報やアウトプットを整理し、判断を進めやすい状態を作る役割を持つという点です。
・テスト計画：品質リスクを整理し、優先度判断に集中できる
・テスト設計：観点を整理し、採否と抜け漏れの確認に集中できる
・テスト実行：不具合情報を整理し、判断に必要な情報を揃えられる
・テスト報告：数値や所感を整理し、品質評価や改善事項を言語化する
一方で、AIは「作業」は代替できますが、「判断」は代替できません。そして、品質の評価や意思決定は、人や組織の責任が伴います。プロンプト例をそのまま使っても、「成果物は作れたが、このまま進めてよいのか判断できない」という状態で止まってしまうことは少なくありません。
つまり、AIは各工程でアウトプットを出すことはできても、「進めてよいか」を決めることはできません。出力された内容を評価し、品質として成立させるかは、人間が専門性にもとづき、「責任」を持って判断する必要があります。
テストをAIに任せるという選択肢 ―「ネムラナイ」サービス
こうしたテスト設計や実行など人手の負荷が高い工程を、AIサービスに任せる選択肢もあります。
SHIFTの「ネムラナイ」は、AIテストエージェントが24時間365日自律的に稼働し、テスト設計とテスト実行を支援します。
これにより、品質保証までのリードタイムを大幅に短縮し、品質改善や新機能の検討など、より付加価値の高い業務へリソースを振り分けられます。
▶「ネムラナイ」 のサービス詳細・お問い合わせはこちら
https://contents.shiftinc.jp/nemuranai/
この記事を書いた人
ご支援業種
- 製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント
など多数
