【2026年最新】品質保証・QAで使えるChatGPTプロンプト20選｜即コピペテンプレ集

【2026年最新】品質保証・QAで使えるChatGPTプロンプト20選｜即コピペテンプレ集

この記事のポイント ・QAの「考える時間」を奪う定型作業は、プロンプト1本で7割削れる。 ・テストケース生成、バグレポ整形、自動化スクリプト下書きまで20本を即コピペで掲載。 ・現場で使うときの落とし穴（秘匿情報の取り扱い・ハルシネーション対策）も同梱。 ・ChatGPT単体で完結しないタスクは、別ツールに振る判断軸も提示。

QAエンジニアが本当に削りたいのは「テスト実行」じゃなく「テスト設計までの段取り」だ。仕様読解、観点出し、ケース整形、バグレポ清書、自動化スクリプトの初稿。ここをChatGPTに振ると、肌感で1日2〜3時間は浮く。

ただし、雑に投げても雑にしか返ってこない。現場で機能するプロンプトには型がある。本記事は、品質保証・QA業務で日々ヒットしているプロンプトを20本に絞って公開する。全てコピペ可、目的別に並べた。

QAでChatGPTを使うメリットと、現実的な限界

品質保証・QAで使えるChatGPTプロンプト20選 - 解説1

QAでChatGPTが効くのは「仕様→観点→ケース→台本」の上流フェーズだ。逆に、実機での実行や本番接続は別レイヤーになる。

ChatGPTがQA業務に持ち込む価値は、観点抽出の網羅性と、文章整形の速度に集約される。仕様書を流し込めば、人間の頭では漏れがちな境界値や異常系を平気で20件単位で吐く。それをレビューする方が、ゼロから書くより圧倒的に速い。

一方で、最新のフレームワーク仕様や社内のテスト基準を「知らない」のは前提だ。ChatGPTは2026年時点の汎用知識しか持たない。プロジェクト固有のルールは、必ずプロンプトに同梱する必要がある。

メリット限界
観点出しの網羅性が上がる社内ルールは外部知識として渡す必要
バグレポの整形が秒で終わる実機実行・スクショ取得は不可
自動化スクリプトの初稿を量産できるセレクタや実DOMは確認が必要
受け入れ基準のレビューが客観化されるドメイン固有用語は誤解しやすい

要するに「初稿はAI、最終判断は人」の役割分担を崩さなければ、QAの生産性は跳ねる。

プロンプトを書く前に守る5つの前提

品質保証・QAで使えるChatGPTプロンプト20選 - 解説2

プロンプトの良し悪しの前に、入力情報の整理が9割を決める。

ChatGPTはエスパーではない。仕様書の断片、対象機能、品質目標、対象環境、テストレベル（単体/結合/受け入れ）を渡さないと、汎用テンプレを返してくるだけだ。これを「コンテキスト圧」と呼ぶ。

現場で破綻しないための前提:

  1. 機密データを直接貼らない（顧客名、本番DBの値はマスクする）
  2. 仕様書はMarkdownか箇条書きに整形してから投入する
  3. 出力フォーマット（表/JSON/Gherkin）を必ず指定する
  4. テストレベルと対象環境を1行で添える
  5. 「不明な前提は質問してから書け」を毎回つける

この5つを守るだけで、出力品質は体感で倍違う。

プロンプト1: テスト計画書ドラフトを30秒で作る

品質保証・QAで使えるChatGPTプロンプト20選 - 解説3

新規プロジェクトのキックオフ直後、まず必要なのがテスト計画の骨子。これをゼロから書くのは正直しんどい。

あなたは経験10年以上のQAリードです。
以下のプロダクト概要から、テスト計画書のドラフトを作ってください。

# プロダクト概要
[ここに概要を貼る: 機能、対象ユーザー、リリース時期、技術スタック]

# 出力フォーマット
1. テストの目的（3行以内）
2. スコープ（含む/含まない を箇条書き、各5項目）
3. テストレベル別の戦略（単体/結合/E2E/受け入れ）
4. リスクと対応策（5項目、表形式）
5. リリース判定基準（Go/No-Go条件）

不明な前提があれば最大5問まで質問してから書いてください。

「質問してから書け」と入れるだけで、汎用テンプレ吐き出しが激減する。地味だが効く。

プロンプト2: 仕様書からテスト観点を網羅的に抽出

品質保証・QAで使えるChatGPTプロンプト20選 - 解説4

仕様レビューで「観点漏れ」はQAの一番痛い失点だ。これをAIに先回りさせる。

以下の仕様書を読み、テスト観点をマインドマップ風に階層化してください。

# 仕様書
[仕様書本文を貼る]

# 抽出する観点カテゴリ
- 機能観点（正常系・異常系・境界）
- 非機能観点（性能・セキュリティ・可用性・アクセシビリティ）
- データ観点（型・量・形式・タイミング）
- UI/UX観点（表示・操作・遷移）
- 環境観点（OS・ブラウザ・デバイス・回線）

各観点に対し「なぜこの観点が必要か」を1行で添えてください。
合計40-60観点を目標。

40-60と数を指定するのがコツ。曖昧に「網羅的に」と書くと10件で終わる。

なぜ「観点抽出」がQAでの最大のレバレッジになるのか

テスト実行は誰でもできる。設計こそQAの本丸だ。

観点抽出は、属人化しやすい工程の代表格だ。ベテランが頭の中で動かしているパターンを、AIに代弁させると暗黙知が形式知になる。新人QAの育成材料にもなる。

工程人がやる時間AI併用後の時間削減率
テスト観点出し4-6時間1-1.5時間約70%
テストケース作成8-12時間2-3時間約75%
バグレポ清書15-20分/件3-5分/件約80%
テスト報告書ドラフト3-4時間30-45分約80%

数字は編集部が複数のQAエンジニアからヒアリングした目安レンジ（2026年4月時点）。プロジェクトの規模により振れ幅は大きいが、定型作業ほど削減効果が出る傾向は一致している。

プロンプト3: テストケースを表形式で一括生成

観点が出たら、次は具体ケース。表形式で吐かせると、そのままテスト管理ツールに流せる。

以下の観点リストから、テストケースを表形式で生成してください。

# 観点リスト
[観点を貼る]

# 出力カラム
| ID | 大項目 | 中項目 | 前提条件 | 操作手順 | 期待結果 | テストデータ | 優先度(H/M/L) |

# ルール
- 1観点につき最低3ケース（正常/異常/境界）
- 操作手順は番号付きで「Aさんが〜する」形式
- 期待結果は検証可能な具体的事実で書く（「正しく動く」禁止）
- 優先度の判定基準: H=主要機能の正常系、M=異常系・境界、L=表示崩れ・装飾

「正しく動く」禁止が地味に効く。曖昧な期待結果は実行時に必ず揉める。

プロンプト4: 境界値テストを自動で洗い出す

境界値の漏れはバグの温床。これを機械的に潰す。

以下の入力項目について、境界値テストの値を洗い出してください。

# 入力項目仕様
- 項目名: ユーザー名
- 型: 文字列
- 制約: 1〜50文字、半角英数字とアンダースコアのみ
- 必須: はい

# 出力フォーマット（表）
| カテゴリ | 入力値 | 期待結果 | 観点 |
| 境界（下限-1） | "" | エラー: 必須 | 必須チェック |
| 境界（下限） | "a" | 成功 | 最小長 |
...

カテゴリ: 境界（下限-1）、境界（下限）、境界（下限+1）、境界（上限-1）、境界（上限）、境界（上限+1）、無効値（型違反）、無効値（文字種違反）、無効値（NULL/空白）
最低15ケース。

これ1本で同値分割と境界値分析が一気に終わる。重宝する。

プロンプト5: バグレポートを再現可能な形に整形

「動きません」「なんか変です」というSlackの呟きをまともなチケットに変換する。

以下の状況メモを、開発者がそのまま再現できるバグレポート形式に整形してください。

# 状況メモ
[Slackやメモの生テキストを貼る]

# 出力フォーマット
## タイトル
[一行で症状を要約、「〜できない」「〜が表示される」形式]

## 環境
- OS / ブラウザ / バージョン / デバイス
- アカウント種別

## 再現手順
1. ...
2. ...
3. ...

## 期待動作
[何が起きるべきか、検証可能な形で]

## 実際の動作
[何が起きたか、画面の文言や挙動を具体的に]

## 再現性
[毎回/たまに/一度きり、確率を記載]

## 影響範囲
[他機能への波及の有無]

## 補足
[ログ・スクショの有無、関連チケット]

不明な前提があれば質問してから書いてください。

これは肌感で1件3分→30秒になる。バグレポ品質の底上げ効果も大きい。

プロンプト6: 不具合の根本原因分析（5Whys）

なぜなぜ分析を、思いつきじゃなくフレームで詰める。

以下の不具合について、5Whys分析を行ってください。

# 不具合
[症状と発生条件を貼る]

# 出力
## 直接原因（Why 1〜5）
1. なぜ発生したか: ...
2. なぜそれが起きたか: ...
3. ...
4. ...
5. ...

## 真の原因（根本原因）
[5回目の答えを基に、組織・プロセス・技術のどこに問題があるか]

## 再発防止策
- 短期（即日対応）
- 中期（1-2週間）
- 長期（プロセス改善）

## 同種バグが潜む可能性のある箇所
[類似ロジックを持つ機能や、影響範囲の推定]

組織・プロセス・技術の3軸に分けるのが肝。「個人のミス」で終わらせない。

プロンプト7: APIテストケースを仕様書から自動生成

REST APIの仕様（OpenAPIでもMarkdownでも）から、ケースを生成する。

以下のAPI仕様から、テストケースを生成してください。

# API仕様
[OpenAPI YAMLまたは仕様書本文を貼る]

# 出力フォーマット（curl + 期待レスポンス）
## ケース1: [概要]
<strong>リクエスト:</strong>

curl -X POST 'https://api.example.com/v1/users'
-H 'Content-Type: application/json'
-d '{...}'

<strong>期待レスポンス:</strong>
- ステータス: 201
- レスポンスボディ: {...}
- 検証ポイント: ...

# カバー範囲
- 正常系（最小/最大パラメータ）
- 異常系（必須欠落、型違反、値域外、認証なし、権限不足）
- 境界値（数値範囲、文字列長、配列要素数）
- セキュリティ（SQLインジェクション試行、XSS、過大ペイロード）

合計20ケース以上。

セキュリティ系を最初から組み込むのがミソ。あとから追加するのは事故りやすい。

プロンプト8: PlaywrightのE2Eスクリプト下書き

自動化スクリプトの初稿は、ChatGPTに任せて人がレビューする方が速い。

以下のテストケースを、Playwright (TypeScript) のスクリプトに変換してください。

# テストケース
タイトル: [タイトル]
前提条件: [前提]
操作手順:
1. ...
2. ...
期待結果: ...

# 出力ルール
- セレクタは `data-testid` を最優先、なければ `role + name`
- 待機は明示的（`waitForLoadState`, `waitForResponse`）、`waitForTimeout` 禁止
- アサーションは `expect().toHaveText()` など意味のあるものを使う
- 共通処理は `beforeEach` に抽出
- 1ファイル内にコメントで「セレクタ要確認」を残す

# 出力構造
import { test, expect } from '@playwright/test';
test.describe('[機能名]', () => {
  test.beforeEach(...);
  test('[ケース名]', async ({ page }) => {
    ...
  });
});

「セレクタ要確認コメント」を残させるのが現場のリアル。実DOMを見ないと最終形にはならない。

プロンプト9: テストデータを大量生成（マスク済み）

テストには「もっともらしいが架空」のデータが要る。

以下のスキーマに沿って、テスト用のダミーデータを30件生成してください。

# スキーマ
- name: 日本人の氏名（漢字、ふりがな）
- email: 形式は有効だが実在しないドメイン（@example.com系）
- phone: 080/090/070 で始まる11桁
- address: 都道府県＋市区町村レベルまで（番地は無し）
- birth_date: 1960-2005の範囲
- role: admin/editor/viewer のいずれか

# 出力形式
JSON配列、フォーマット済み、各レコードに id (UUID v4 を装った形式) を含める

# 注意
実在の人物・企業名は使わない。著名人の氏名も避ける。

「実在の人物・企業名は使わない」は明示しないと、芸能人の名前が混じることがある。

プロンプト10: 受け入れ基準（AC）のレビュー

PdMが書いたACをQA目線で検査する。

あなたはシニアQAです。以下の受け入れ基準（AC）をレビューし、テスタビリティの観点で問題点を指摘してください。

# 受け入れ基準
[ACを貼る]

# レビュー観点
- 検証可能性（数値・閾値・条件が明確か）
- 網羅性（正常系・異常系・境界の漏れ）
- 一貫性（用語・状態名の揺れ）
- スコープ（何を含み何を含まないか）
- 依存関係（他機能・他ACとの関係）

# 出力
| 観点 | 該当ACの引用 | 問題点 | 改善提案 |

最後に「このAC全体の判定: 通過 / 要修正 / 要差し戻し」を理由付きで。

PdMとQAの議論の叩き台になる。表で出るのが大きい。

ChatGPT、Claude、Geminiの使い分けは？

QAタスクごとに得意が違う。1ツールに固執しない方が良い。

ChatGPTは表組みとコード生成のバランスが良く、テストケース表やPlaywrightスクリプトの初稿で重宝する。文章整形（バグレポ清書）も自然な日本語が出る。一方で、長文の仕様書を一度に処理させると後半が雑になる傾向は残る。

Claudeは長文仕様の理解力に強みがある。100ページ規模の仕様書からの観点抽出は、こちらが向く局面もある。GeminiはGoogle Workspace連携が活きるシーンで便利。スプレッドシートのテストケースを直接いじりたい場合は選択肢に入る。

詳しい比較観点は Feloの完全ガイド や Meta AIガイド も参考になる。

プロンプト11: 探索的テストのチャーター作成

時間制限付きの探索的テストを設計する。

以下の機能について、探索的テストのチャーターを作ってください。

# 対象機能
[機能名と概要]

# 出力フォーマット
## チャーター名
[1行で目的]

## ミッション
[何を発見するためか、3行以内]

## 探索エリア
- エリア1: [どこを]
- エリア2: ...
- エリア3: ...

## ヒューリスティック（使う発想ツール）
- SFDIPOT（Structure/Function/Data/Interface/Platform/Operation/Time）の中から該当するもの
- 異常な使い方の仮説3つ

## タイムボックス
[60分 / 90分 / 120分]

## 終了時の記録項目
- 発見した問題（重要度別）
- カバーした領域
- カバーできなかった領域と理由
- 次回への申し送り

「次回への申し送り」を必ず書かせるのがコツ。探索的テストは継続性が命。

プロンプト12: リグレッションテスト範囲の判定

差分PRが来たとき、どこを回帰テストするかを決める。

以下のコード変更内容から、リグレッションテストの対象範囲を判定してください。

# 変更内容
[PRの差分サマリ、または変更したファイル一覧と概要を貼る]

# 出力
## 直接影響範囲
[変更したコード自体の動作確認項目]

## 間接影響範囲（依存関係）
| 機能 | 依存の根拠 | テスト優先度 |

## 横断的観点
- 認証/認可への影響
- データベーストランザクションへの影響
- 外部API連携への影響
- パフォーマンスへの影響

## 推奨するリグレッション範囲
- マスト（必ず実行）
- 推奨（時間があれば）
- 不要（影響なしと判断、理由を記載）

## 自動テストでカバー済みか
[既存の自動テストで足りる範囲と、手動が必要な範囲の切り分け]

「不要」の理由を書かせるのが重要。漏れの責任分界点になる。

プロンプト13: パフォーマンステストのシナリオ設計

負荷試験のシナリオを構造化する。

以下のシステムについて、パフォーマンステストのシナリオを設計してください。

# システム概要
[アクセス想定、主要機能、技術スタック]

# 出力
## 想定ワークロード
| シナリオ | ユーザー比率 | 主要操作 | 想定TPS |

## 負荷パターン
- 平常負荷（baseline）: ...
- ピーク負荷（peak）: ...
- ストレス負荷（stress）: ...
- 持続負荷（soak）: ...

## 計測指標とSLO
| 指標 | 目標値 | 計測方法 |
| レスポンスタイム(p95) | <500ms | ... |
| エラー率 | <0.1% | ... |
| スループット | >100TPS | ... |
| リソース使用率 | CPU<70% | ... |

## ボトルネック仮説と検証方法
[DBコネクション、外部API、キャッシュなどの仮説]

## 中止条件
[テストを止めるべき閾値]

「中止条件」を最初に決めるのが本番事故を防ぐ鍵。

プロンプト14: セキュリティテスト観点の洗い出し

OWASP系の観点をプロジェクトに当てはめる。

以下のWebアプリケーションについて、セキュリティテストの観点を洗い出してください。

# アプリ概要
[機能、認証方式、扱うデータの種類]

# 出力フォーマット
| OWASP TOP10 カテゴリ | 該当する自社の機能 | テスト観点 | 検証方法 |

# カバー範囲
- 認証・認可（パスワードポリシー、セッション管理、権限分離）
- インジェクション（SQL、コマンド、XSS、CSRF）
- データ保護（暗号化、PII取扱、ログマスキング）
- 設定ミス（HTTPヘッダ、CORS、エラーメッセージ）
- 依存関係（ライブラリの既知脆弱性）
- ログ・監視（不審アクセスの検知）

各観点に「自動化可能/手動必須」のフラグを付ける。

「自動化可能/手動必須」のフラグが、CI組み込みの判断材料になる。

プロンプト15: ユーザビリティチェックリスト

ヒューリスティック評価を体系化する。

以下の画面について、ユーザビリティチェックを行ってください。

# 画面情報
[画面の目的と主要要素を貼る、可能ならスクショの説明を添える]

# 評価基準（ニールセンの10原則）
1. システム状態の可視性
2. システムと実世界の一致
3. ユーザーの自由と制御
4. 一貫性と標準
5. エラー予防
6. 想起ではなく認識
7. 柔軟性と効率性
8. 美的でミニマルなデザイン
9. エラーからの回復
10. ヘルプとドキュメント

# 出力
| 原則 | 該当箇所 | 問題点 | 重大度(H/M/L) | 改善提案 |

最後に総合所感を3行以内で。

10原則を機械的に当てる方が、属人的な評価より再現性が高い。

プロンプト16: テスト報告書のドラフト生成

イテレーション末のテスト報告書をAIに下書きさせる。

以下のテスト実施結果から、テスト報告書のドラフトを作ってください。

# 実施結果（生データ）
[ケース数、Pass/Fail/Block数、検出バグ一覧、未消化ケースの理由などを貼る]

# 出力構造
## エグゼクティブサマリ（3行以内、リリース可否の見解付き）

## 実施実績
| 項目 | 計画 | 実績 | 差分 | 備考 |

## 検出した不具合
| 重大度 | 件数 | 修正済 | 残存 | 残存リスク評価 |

## 残存リスク
[本番リリースに踏み切る場合のリスクを3つ以内で]

## 学び・改善提案
[次イテレーションへの申し送り]

## リリース推奨判定
[Go / No-Go / 条件付きGo、理由付き]

「条件付きGo」の選択肢を残すのが現場感。100%か0%しかない世界ではない。

プロンプト17: 仕様レビューチェックリスト

開発開始前の仕様レビューを構造化する。

以下の仕様書を、QA観点でレビューしてください。

# 仕様書
[仕様書を貼る]

# レビュー観点
## 完全性
- 正常系の全フローが書かれているか
- 異常系の振る舞いが定義されているか
- データの型・範囲・必須有無が明確か

## 一貫性
- 同じ概念に同じ用語を使っているか
- 状態遷移に矛盾がないか
- 他機能との関係が明示されているか

## テスタビリティ
- 動作の検証方法が想定できるか
- 観測可能な指標があるか
- 再現可能な手順で書かれているか

# 出力
| 観点 | 該当箇所 | 問題レベル(致命/重要/軽微) | コメント |

最後に「この仕様で開発開始可能か」の判定とその理由を記載。

「致命」を1件でも出したら、仕様書を直してから開発に入る。これだけで手戻りが減る。

プロンプト18: テスト戦略のレビュー（セルフチェック）

自分が書いたテスト戦略を、AIに突っ込ませる。

あなたは外部のQAコンサルタントです。以下のテスト戦略を批判的にレビューしてください。

# テスト戦略
[戦略文書を貼る]

# 観点
- リスクベースで優先順位がついているか
- 各テストレベルのカバー範囲に重複・漏れがないか
- 自動化と手動の役割分担が合理的か
- 環境・データ・スケジュールの制約を考慮しているか
- 関係者（PdM、開発、運用）の合意が取りやすい構造か

# 出力
## 強み（3点）
## 弱み・リスク（3点）
## 致命的な欠陥（あれば）
## 改善提案（具体的に3つ）
## 総合評価（A/B/C/D + 理由）

「外部コンサル視点」と明示すると、忖度なしの指摘が返ってくる。これがChatGPTの強み。

プロンプト19: テスト自動化の費用対効果（ROI）試算

「これ自動化する価値ある？」を数字で答える。

以下のテストケース群について、自動化の費用対効果を試算してください。

# 入力情報
- テストケース数: [N件]
- 1ケースの手動実行時間: [X分]
- 1ケースの自動化開発時間（推定）: [Y時間]
- 自動化スクリプトの想定メンテナンス時間: [月Z時間]
- 想定実行頻度: [週/イテレーション/リリース]
- プロジェクトの想定期間: [Mヶ月]

# 出力
## 損益分岐点（何回実行すれば元が取れるか）
## Mヶ月後の累積削減時間
## 推奨判定（自動化推奨 / 部分自動化 / 手動継続）
## 自動化対象から除外を推奨するケース（変更頻度が高い、UIが不安定など）
## 自動化の優先順位上位5ケース

「除外を推奨するケース」を必ず出させる。全部自動化が正解ではない。

プロンプト20: QAプロセス改善の提案

レトロスペクティブ用の改善提案。

以下のプロジェクトの現状から、QAプロセス改善案を提案してください。

# 現状
- チーム構成: ...
- 現在のテスト実施フロー: ...
- 現在の課題（KPT のProblem）: ...
- 直近のリリースで起きた問題: ...

# 出力
## 短期改善（1-2週間で着手可能）
| 課題 | 改善案 | 期待効果 | 実施難易度 |

## 中期改善（1-3ヶ月）
[同上のフォーマット]

## 長期改善（3ヶ月以上）
[同上のフォーマット]

## やらない方が良いこと（アンチパターン）
[流行りに飛びつきがちな施策で、このチームには合わないもの]

## 推奨する次の一手（一つだけ）
[実施難易度と効果のバランスで最良の一手]

「やらない方が良いこと」を出させるのが秀逸。アンチパターンの言語化はAIが得意。

QA以外のドメインでも使えるテンプレ集

QAで磨いたプロンプト技法は、他職種でも応用が効く。

たとえば文章生成系では Feloの使い方 が参考になるし、画像系テストでは Sora AIガイド や ComfyUI vs Stable Diffusion の比較が示唆を与えてくれる。スクリーンショット解析の自動化を考えるなら AI OCRツール比較 も合わせて読みたい。

複数AIサービスの選定で迷うなら Meta AI完全ガイド で全体像を掴むのも手だ。

ハルシネーション対策とセキュリティの落とし穴

QAでAIを使うとき、現場で必ず引っかかる地雷を先に書いておく。

ハルシネーション（事実誤認の出力）: ChatGPTは「もっともらしい嘘」を平気で吐く。特に、社内ライブラリのAPI名、フレームワーク固有の関数、最新バージョンの仕様。これらは100%確認が要る。プロンプトに「不明な前提は質問してから書け」を入れるのは、この防衛策だ。

秘匿情報の漏洩: ChatGPTの無料・Plusプランは、入力データが学習に使われる可能性がある（オプトアウト設定をしない限り）。Business / Enterpriseプランはデフォルトで学習対象外と公式に明記されている。本番データ・顧客情報・契約書を貼るのは、Enterprise契約か社内LLMでないと事故る。

著作権・ライセンス: 生成されたテストスクリプトや文書の権利関係は、OpenAIの利用規約上「出力物の所有権はユーザー」となっている。ただし、他社の特許やライセンス違反を生成する可能性はゼロではない。コードの自動化スクリプトは特に、外部OSSとの組み合わせで注意が必要。

AI PICKS編集部の判定

QA業務へのChatGPT導入は「やる/やらない」の二者択一ではもう議論にならない。論点は「どの工程に、どう組み込むか」だ。

編集部の見立てとしては、まずバグレポート整形・テストケース表生成・受け入れ基準レビューの3つから入るのが破格に費用対効果が高い。1日30分で導入可能、1週間で効果が肌感で分かる。逆に、自動化スクリプトの全自動生成や、本番DBへの直接接続による検証は、現時点では正直イマイチで、トラブルの方が大きい。

中堅QAエンジニアにとって最大の脅威は「AIが自分の仕事を奪うこと」ではなく、「AIを使いこなす同年代のQAに、生産性で2倍差をつけられること」だと考えている。コピペで動くテンプレが手元にある以上、使わない選択肢は微妙。一方で、AIの出力を鵜呑みにして実行する初心者QAは、ハルシネーションの罠で痛い目を見る局面が今後増えるはずだ。

つまり、AI併用QAの本質は「より速く、より深く考える」ためのレバーであって、思考を肩代わりさせる道具ではない。この線引きを守れるチームと守れないチームで、6ヶ月後の品質指標は圧倒的に差がつく。

編集部の利用レポート

20本のプロンプトを実際にQA現場で運用しているチームから聞いた率直な感想を、編集部視点でまとめる（複数チームのヒアリングを抽象化、2026年5月実施）。

「バグレポ整形は手放せない」が満場一致の感想だった。1件あたり15分かかっていた清書作業が3分弱に縮む。週20件のバグレポを扱うチームなら、それだけで月15時間以上が浮く。

一方で「自動化スクリプトの初稿生成は、思ったほどそのままは使えない」という声も多い。セレクタが架空のものだったり、待機処理が雑だったり。それでも「ゼロから書くよりは速い」ので、結果的には採用されている。

意外だったのは「テスト戦略のセルフレビュー」が役立つという声。自分の戦略を他者目線で批判するのは難しいが、AIに「外部コンサル」の役を演じさせると、忖度なしの指摘が返ってくる。これは正直、想定外の収穫だった。

関連する比較・代替を見る

よくある質問（FAQ）

Q. ChatGPTで生成したテストケースをそのまま本番運用に乗せて良い？

A. レビューなしで乗せるのは推奨しない。観点漏れ、ドメイン固有用語の誤解、ハルシネーションのリスクがある。QAエンジニアが目を通してから採用するのが原則だ。「初稿はAI、最終判断は人」を崩さないこと。

Q. 機密情報や顧客データを含む仕様書を投入しても大丈夫？

A. ChatGPT無料・Plusプランでは推奨しない。Business / Enterpriseプランはデフォルトで学習対象外とOpenAI公式が明記している（2026年4月時点）。本番データを扱う場合は、Enterprise契約または社内LLMの利用が前提になる。

Q. ChatGPT、Claude、Geminiのどれが品質保証に一番向いている？

A. 用途による。テストケース表やコード初稿はChatGPTが安定。長文仕様の理解はClaudeに分がある。Workspace連携を活かしたいならGemini。1ツールに絞らず、タスクで使い分けるのが2026年現在のベストプラクティスだ。

Q. プロンプトをチームで共有するベストな方法は？

A. NotionやConfluenceにプロンプト集を集約し、Pull Request的なレビューで品質管理するのが現実的。プロンプトはコードと同じく「資産」扱いで、誰が改善したか追跡できる状態にすると、属人化が防げる。

Q. AI生成のテストケースで漏れた重要観点を後から発見した。どう改善する？

A. プロンプト側に「過去の漏れケース」を例として追加するのが効く。「以下のような観点を必ず含めること: [漏れた観点リスト]」を追加すると、次回以降の生成精度が上がる。プロンプトはバージョン管理せよ。

Q. テスト自動化スクリプトの生成精度はどのくらい？

A. 体感で「7-8割は構造として正しいが、セレクタや待機処理は要修正」というのが現実。ゼロから書くより速いが、無修正で動かそうとすると失敗する。レビュー前提で使うのが正解だ。

Q. プロンプトを使ってもうまく結果が出ない。コツは？

A. 入力情報の整理が9割。仕様書を箇条書きに整形してから渡す、出力フォーマットを明示する、不明前提は質問させる、この3点で改善する。プロンプトの問題より、コンテキスト不足が原因のことが多い。

Q. QAエンジニアの仕事はAIに奪われる？

A. 短期的にはむしろ「AI併用QAエンジニア」の需要が増える。テスト実行の単純作業は自動化が進むが、戦略設計・リスク判断・品質ゲートの番人としての役割は、当面人間が担う。AIを使いこなす側に回るのが現実解だ。

各ツールの公式サイト（一次情報）

料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。

注: 本記事内のAIモデル名・料金は2026年4月〜6月時点の公開情報に基づく。最新情報は各社公式を参照のこと。「使ってみた」表現は編集部によるヒアリング・公開情報の整理であり、特定個人の一次体験ではない。