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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

仕様レビューで「観点漏れ」は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ファイル内にコメントで「セレクタ要確認」を残す

# 出力構造
```typescript
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 の完全ガイド](/mag/felo-complete-guide-2026) や [Meta AI ガイド](/mag/meta-ai-guide-2026) も参考になる。

---

## プロンプト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 の使い方](/mag/felo-complete-guide-2026) が参考になるし、画像系テストでは [Sora AI ガイド](/mag/sora-ai-guide-2026) や [ComfyUI vs Stable Diffusion](/mag/comfyui-vs-stable-diffusion) の比較が示唆を与えてくれる。スクリーンショット解析の自動化を考えるなら [AI OCR ツール比較](/mag/ai-ocr-tools-guide-2026) も合わせて読みたい。

複数AIサービスの選定で迷うなら [Meta AI 完全ガイド](/mag/meta-ai-guide-2026) で全体像を掴むのも手だ。

---

## 実際に使っている企業・チーム

QA領域でのChatGPT活用は、国内外で着実に広がっている。

<strong>LegalOn Technologies（日本）</strong>: AI契約レビューを開発するリーガルテック企業。AI機能の品質保証にあたり、生成AIを使った観点抽出やテスト設計の補助を業務に組み込んでいると、自社発信のテックブログで触れている（出典: LegalOn Technologies Tech Blog、2026年4月時点で確認可能な範囲）。

<strong>Microsoft（米）</strong>: GitHub Copilot を含むAI開発で、品質保証プロセスにLLMを組み込む実験を継続的に公開している。具体的にはバグレポートの分類自動化や、テストケース生成の補助といった領域で適用が進んでいる（出典: Microsoft Research の公開資料）。

<strong>ChatGPT 提供元の OpenAI</strong>: ChatGPT 自体の品質保証においても、内部評価プロセスでLLMを補助的に活用していることをドキュメント化している（出典: OpenAI 公式の Responsible AI 関連ドキュメント、2026年4月時点）。

注: 各社の社内詳細プロセスは公開情報に基づく一般的記述。具体の運用は社内資料で確認するのが確実だ。

---

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

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

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

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

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

---

## AI PICKS 編集部の判定

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

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

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

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

---

## 編集部の利用レポート

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

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

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

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

---

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

- [ChatGPT vs Claude の比較](/compare/chatgpt-vs-claude)
- [ChatGPT vs Gemini の比較](/compare/chatgpt-vs-gemini)
- [ChatGPT vs Copilot の比較](/compare/chatgpt-vs-copilot)
- [Claude vs Gemini の比較](/compare/claude-vs-gemini)
- [ChatGPT の代替ツール一覧](/tool/chatgpt/alternative)
- [Claude の代替ツール一覧](/tool/claude/alternative)

---

## よくある質問（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を使いこなす側に回るのが現実解だ。

---

## 参考にした一次情報

- OpenAI 公式: ChatGPT プラン仕様と Enterprise 学習除外ポリシー (2026年4月時点)
- 起業ログ: ChatGPT 2026年最新の始め方と使い方解説
- 中村祐太のFindUアカデミー: ChatGPT 有料プラン徹底比較 2026年版（YouTube、2026年2月公開）
- PCMag UK: ChatGPT Review 2026（GPT-5 / GPT-5 Thinking 機能評価）
- MezMarketing: ChatGPT Review 2026: Pros, Cons, and Is It Worth It?
- AI Toolbox (formerly ChatGPT Toolbox): Chrome Web Store 公開情報
- 創業手帳: ChatGPT 無料版vs有料版の徹底比較 (2026年最新)
- LegalOn Technologies Tech Blog: AI機能の品質保証プロセスに関する発信

---

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

<!-- IMAGE_GEN_PROMPTS
1. ヒーロー画像 prompt: photoreal editorial style, a focused QA engineer reviewing test cases on a large monitor with a ChatGPT interface beside structured test data tables, modern open office, 16:9, soft warm lighting, professional editorial photography
2. セクション図解1 prompt: minimalist infographic illustration, hierarchical mindmap of QA test perspectives with branches for functional, non-functional, data, UI/UX and environment, light background, vector style, amber accent color
3. セクション図解2 prompt: comparison chart visualization, three AI tools (ChatGPT, Claude, Gemini) compared across QA task fit dimensions like test case generation, long spec reading, workspace integration, clean modern style, isometric look
4. セクション図解3 prompt: workflow diagram, the QA workflow from spec review to test case generation to bug report formatting to automation script drafting, isometric perspective, brand amber color, with ChatGPT integration points highlighted
5. セクション図解4 prompt: persona scene illustration, a mid-career QA engineer at desk using ChatGPT to draft test cases on left monitor while reviewing automation code on right monitor, photoreal but stylized editorial illustration, warm office lighting
-->