【プロンプト例あり】テスト仕様書のAIレビュー｜観点と事前実行

テスト仕様書を書き上げて、そのままテスターに渡していないでしょうか。

テスト期間に入ると、問い合わせが続きます。「この期待結果はどこで確認すればいいですか」「このURLを開いてもエラーになります」。そのたびにテスターの手が止まり、PMは仕様書を開き直すことになります。

本記事では、テスト仕様書のAIレビューと、テスター実施前のAIによる事前実行を組み合わせる方法を紹介します。テスト仕様書のAIレビューとは、完成したテスト仕様書をAIに読ませ、矛盾やテスターに伝わらない記述を、テスターに渡す前に洗い出す工程です。

テストケース約600件の受託案件で実際に行った内容をもとにしています。この案件では、テスターとのやり取りが減り、AIが報告したバグはすべて実際のバグでした。一方で、人が実施して初めて見つかったバグもありました。その線引きも含めて解説します。

すぐにプロンプトを使いたい方は、こちらから該当箇所へ移動できます。

目的	プロンプト
仕様書の矛盾・システム仕様書との不整合を見つけたい	プロンプト1：矛盾と不整合のレビュー
テスターに伝わらない記述（DB用語・URL）を直したい	プロンプト2：テスターに伝わらない記述のレビュー
テスト環境で確認できないケースを分けたい	プロンプト3：テスト環境で確認できないケースの洗い出し
テスターより先にAIにケースを流させたい	事前実行用のプロンプト

なお、テスト仕様書やテストケースをAIで作る方法は、生成AIでテストケース作成を効率化する方法で解説しています。本記事は「作った後」の工程に絞ります。

テスト仕様書のAIレビューと事前実行で何が変わるか

最初に全体像を示します。今回の案件で行ったのは、テスターに渡す前の3つの工程です。

工程	AIにやらせたこと	減らしたいもの
① 仕様書レビュー	仕様書内の矛盾、システム仕様書との不整合、テスターに伝わらない記述を指摘させた	テスト中の問い合わせ
② ケースの分類	テスト環境の都合でテスターが確認できないケースを洗い出させた	「確認できません」というやり取り
③ 事前実行	Playwright MCP でテストケースをブラウザ操作させた	テスター実施後に発覚するバグと、その再実施

テスター工程のコストには、テストそのもの以外に「止まる時間」が含まれます。記述が分からずに止まる、環境が足りずに止まる、バグで先に進めずに止まる。

AIレビューと事前実行は、この「止まる原因」をテスターに渡す前に潰す工程です。テストの網羅性をAIで上げる話とは目的が違う点に注意してください。

テスト仕様書のAIレビューで見る5つの観点

AIに「レビューして」とだけ頼むと、誤字や表記ゆれの指摘で終わりがちです。観点を明示して渡すことが重要です。

今回の案件で見た観点を、5つに整理しました。

#	観点	典型的な問題
1	仕様書内の矛盾	同じ機能で、ケースごとに期待結果が食い違う
2	システム仕様書との不整合	仕様変更前の文言・上限値が残っている
3	テスターに伝わらない記述	テーブル名・カラム名・内部ステータス値で書かれている
4	URLの意図	確認する画面のURLではなく、処理のURLが書かれている
5	テスト環境で確認できないケース	外部連携や特定の権限が、テスト環境にない

観点1・2：仕様書内の矛盾とシステム仕様書との不整合

ケース数が数百件になると、人の目では離れた章どうしの食い違いに気づきにくくなります。たとえば、ある章では入力上限50文字、別の章では100文字になっている状態です。

AIには、テスト仕様書とシステム仕様書の両方を渡します。片方だけでは、どちらが正しいかの判断材料がないためです。

• 仕様書内で、同じ項目の期待結果が食い違っていないか
• システム仕様書の記述と、期待結果が一致しているか
• （あわせて見ておきたい点）システム仕様書にある機能・条件で、ケースが存在しないものはないか

観点3：テスターに伝わらない記述

テスターが開発メンバーを兼ねていて、DBも見られる体制なら、この観点の優先度は下げてかまいません。問題になるのは、テスターが画面を操作して結果を見るだけの体制です。

開発者が書いたテスト仕様書には、次のような記述が紛れ込みます。

悪い例（コード・DB前提）	良い例（画面で確認できる）
orders.status が 1 になる	一覧の「状態」欄が「受注済」に変わる
deleted_at に日時が入る	一覧から表示されなくなる
ordersテーブルに3件レコードがある	受注が3件以上登録されている
role = admin のユーザー	管理者でログインしている
バリデーションエラーになる	「顧客名は必須です」と赤字で表示され、登録されない

「テーブル名.カラム名が◯◯になっていること」と書かれていても、DBを見られないテスターには確認する手段がありません。テスト体制とテスターの状態に合わせて、記述を調整する必要があります。

こうした記述は、次のような仕様書で起きやすい印象があります。

• AIで作ったテストケースを、見直す時間が取れないまま使った仕様書
• 類似システムのテスト仕様書を流用した仕様書
• 以前のシステムで使っていた仕様書を改修して使った仕様書

テストケースの書き方の基本は、テストケースの書き方｜他人が迷わず実行できる項目と例も参考にしてください。

観点4：URLの意図

見落とされやすいのがURLです。ルーティング定義をそのまま転記すると、テスターが開けないURLが仕様書に入ります。

操作	処理のURL（テスターは開けない）	画面のURL（テスターが開く）
登録	POST /orders	/orders/create（入力フォーム）
更新	PUT /orders/{id}	/orders/{id}/edit（編集画面）
削除	DELETE /orders/{id}	/orders/{id}（削除ボタンがある詳細画面）

AIには、書かれたURLが「確認してもらいたい画面のURL」なのか「処理のURL」なのかを判定させます。そのうえで、それが意図したものかを確認させます。

権限のテストで「URLを直接入力して弾かれること」を確かめる場合だけは、例外的に処理側のURLを書くことがあります。その場合は、手順に「アクセスを試すURL」と明記させます。

観点5：テスト環境で確認できないケースの分類

テストケースとしては必要でも、テスト環境の都合でテスターが確認できないものがあります。

• テスト環境に外部サービスとの連携が設定されていない
• メール送信がテスト環境では止められている
• 特定の権限を持つアカウントがテスト環境に用意されていない
• 日時や件数の条件を作るのに、DBの直接操作が必要

これらを他のケースと混ぜて渡すと、テスターは実施を試み、行き詰まってから問い合わせることになります。

事前にAIに洗い出させて「テスターが実施するケース」と「別の担当が確認するケース」に分けておくと、このやり取りを減らせます。今回の案件でも、この分類で問い合わせの工数を減らせました。ケースを削るのではなく、担当を分けるのがポイントです。

そのまま使えるテスト仕様書のAIレビュー用プロンプト

ここからは、実際の作業で使える指示文です。Claude Code などファイルを直接読めるAIツールを前提にしていますが、チャット型のAIに貼り付けても使えます。

仕様書が数百件ある場合は、章や機能単位に分けて渡してください。一度に全件を渡すと、後半の見落としが増えます。

プロンプト1：矛盾と不整合のレビュー

あなたはテスト仕様書のレビュアーです。
添付のテスト仕様書と、システム仕様書を照合してください。

次の3点を確認し、該当するケースIDと根拠を表で出してください。
1. テスト仕様書内で、同じ項目の期待結果が食い違っているケース
2. システム仕様書の記述と、期待結果が一致しないケース
3. システム仕様書にある機能・条件のうち、テストケースが存在しないもの

どちらが正しいか判断できない場合は「判断保留」とし、
両方の記述箇所を引用してください。勝手にどちらかを正としないでください。

最後の2行が重要です。AIはどちらかを正として修正案を出しがちですが、仕様書と実装のどちらが正しいかは人が判断すべきことです。

プロンプト2：テスターに伝わらない記述のレビュー

このテスト仕様書は、コードもDBも見られないテスターが実施します。
テスターは画面を操作し、画面に表示される結果だけで合否を判断します。

次に当てはまる記述を、ケースIDつきで表にしてください。
1. テーブル名・カラム名・内部のステータス値・メソッド名が書かれている
2. URLが、テスターが開く画面のURLではなく処理のURLになっている
3. 「正しく表示される」「エラーになる」など、合否が1つに定まらない
4. 前提条件の書き方が足りず、必要なデータやログインユーザーが読み取れない

それぞれ、画面上の表示で確認できる書き方に修正案を出してください。
画面上で確認できる言い換えが存在しない場合は、修正案を出さずに
「画面で確認不可」と書いてください。

プロンプト3：テスト環境で確認できないケースの洗い出し

テスト環境の条件は次のとおりです。
- 外部サービス連携：未設定
- メール送信：送信されない（ログのみ）
- 用意されているアカウント：一般ユーザー、管理者
- テスターの権限：画面操作のみ。DB・サーバーへのアクセスなし

この条件で、テスターが実施できないケースを洗い出し、
「テスター実施」「別担当で確認」の2つに分類してください。
「別担当で確認」に分類したケースは、理由と、誰がどう確認すべきかの案を添えてください。

テスト環境の条件はプロジェクトごとに違います。最初の箇条書きを自分の環境に合わせて書き換えるのが、このプロンプトの使い方です。

AIの指摘を人が判断する箇所

AIの出力をそのまま反映してはいけない箇所があります。

• 「判断保留」の指摘：仕様書と実装、どちらに合わせるかは発注側やPMが決める
• 「画面で確認不可」の指摘：ケースを消すのか、別担当に回すのか、自動テストで担保するのかを決める
• 修正案の文言：ボタン名やエラーメッセージが、実際の画面の文言と一致しているかを確認する

特に3つ目は注意が必要です。AIは「それらしいエラーメッセージ」を書くので、実装の文言と照合しないと新たな不一致を生みます。

テスト仕様書のAIレビュー後に行うAI事前実行の手順

レビューで仕様書を整えたら、次はテスターに渡す前にAIにケースを流させます。

使うのは Playwright MCP です。AIがブラウザを操作するためのMCPサーバーで、画面を開く・クリックする・入力する・結果を読み取るといった操作をAIが実行できます。MCPの仕組み自体は Model Context Protocol の公式サイトで解説されています。導入やツールの選び方は、テストに使えるAIツール｜Playwright MCPと選び方で詳しく扱っています。

事前実行の前提条件

事前実行には、次の準備が必要です。

• 対象システムをローカル環境で起動できる
• ケースの前提条件を満たすテストデータを投入できる
• テスト用のログインアカウントがある

受託案件では、このローカル環境が用意できないこともあります。その場合でも、前章のプロンプト1〜3によるレビューだけで効果は出ます。事前実行は、レビューの次の一手として考えてください。

事前実行の進め方

今回の案件では、社内で用意した Claude Code のスキル（作業手順を定義したファイル）で、次の流れを決めて実行しました。

1. ローカル環境で実行する（テスト環境はテスターの作業場所なので触らない）
2. テストケースを1件ずつ、書かれた手順どおりにAIに操作させる
3. 実行結果を期待結果と突き合わせ、5つの判定に分類させる
4. 問題があったケースだけスクリーンショットを残させる
5. 結果を一覧にまとめさせ、人が確認する

テストケースが数百件あると、AIの実行にも時間がかかります。夜、寝ている間に実行させておけば、作業時間を使わずに一巡できます。

運用するうえでは、次の点にも注意してください。

• ケースは章や機能単位に分けて流す（一度に全件流すと途中で止まりやすい）
• 登録→更新→削除のようにデータが前後のケースに依存する場合は、実行順を崩さない
• 実行前にテストデータを初期状態に戻す
• 失敗したケースは、もう一度流して再現するかを確かめる

テスト環境で確認できないとして別担当に回したケースも、ローカル環境で動くなら事前実行の対象に含めてかまいません。

判定は5つに分ける

AIに「OK/NG」の2択で判定させると、NGの中身がバラバラになります。原因によって直す対象が違うため、次の5つに分けさせます。

判定	条件	直す対象
OK	手順どおり実行でき、期待結果と一致した	なし
実装バグ	手順どおり実行できたが、期待結果と実際の動作が違う	実装
仕様矛盾	動作はするが、仕様書の記述と実装が食い違う	仕様書か実装（人が判断）
ケース不備	手順・URL・期待結果・前提条件の書き方に不足や誤りがあり、実行・判定できない	テストケース
実行不可	前提条件は書かれているが、そのデータや権限が環境に用意されていない	環境・テストデータ

「書き方の問題」はケース不備、「環境の問題」は実行不可と分けると、直す担当がはっきりします。

事前実行用のプロンプト

Playwright MCP を使い、テスト仕様書のケースを上から順に実行してください。
実行先はローカル環境（http://localhost:8000）です。仕様書に書かれた
テスト環境のURLは使わないでください。

ルール：
- ケースに書かれた手順だけで操作してください。書かれていない操作を
  補って成功させてはいけません。補わないと進めない場合は「ケース不備」とし、
  何を補えば進めたかを記録してください
- 期待結果は画面上で確認できる範囲で判定してください。DBは見ないでください
- 判定は OK / 実装バグ / 仕様矛盾 / ケース不備 / 実行不可 のいずれかにしてください
- 実装バグか仕様矛盾か迷った場合は「仕様矛盾」とし、根拠を書いてください
- OK以外のケースはスクリーンショットを撮ってください
- 10件ごとに進捗を記録してください

最後に、全ケースの判定一覧と、OK以外のケースの詳細（期待／実際）を表で出してください。

「手順を補って成功させてはいけない」という指示が要です。AIは気を利かせて足りない操作を補い、ケースを通してしまうことがあります。AIが補わないと進めなかったケースは、テスターも同じ場所で止まります。

DBを見させないのも同じ理由です。テスターと同じ条件で確認しないと、テスターが判定できないケースを検出できません。

迷ったときに「仕様矛盾」へ倒すのは、どちらが正しいかをAIに決めさせないためです。仕様矛盾に分類されたものは人が必ず確認するので、実装バグが埋もれることはありません。

テストケース約600件の案件で起きたこと

ここからは、実際にこの工程を入れた受託案件での結果です。件数を記録していなかったため、数値ではなく起きたことを書きます。1案件での観察であり、誤検知率や見逃し率を測ったものではない点にご注意ください。

仕様書レビューで見つかったもの

• テスターには確認できない、テーブル名やカラム名で書かれた記述
• 意図が曖昧なURL（画面のURLか処理のURLか判別できないもの）
• テストケースとしては必要だが、テスト環境の都合でテスターが確認できないケース

最後のケースは、削除せずに分類して別扱いにしました。テスターに渡すケースを分けておいたことで、実施中のやり取りが減りました。

AIの事前実行で見つかったもの

この案件では、AIが報告してきたバグは、確認したところすべて実際のバグでした。

一方で、内容によってはAIでは確認できない項目もありました。また、テスターが実施して初めて見つかったバグもありました。AIの事前実行は、テスターの実施を置き換えるものではありません。

バグが報告されたケースは、修正後にテスターに実施してもらう段取りにしました。テスターが同じケースを、バグの前後で2回流さずに済みます。

この結果から言えること

• AIの事前実行は「バグを全部見つける」工程ではなく、テスターの時間を守る工程
• テスターが見つけたバグは、AIが見逃したもの。人の実施を省くことはできない
• 仕様書レビューの指摘は、テスターに渡す前に反映するほど、止まる時間を減らせる

工数はどれくらい減るか（仮の条件での試算）

今回の案件では工数を計測していません。そのため、ここでは仮の条件を置いた試算を示します。実測値ではないので、自分の案件の数字に置き換えて使ってください。

前提はテストケース600件です。以下の比率・時間・解消率は、すべて仮定です。

項目	仮の条件	AIを挟まない場合	AIを挟んだ場合
テスターに伝わらない記述	30件（5%）に含まれる。問い合わせ1往復20分。AIレビューで8割を事前に解消	30件×20分＝10時間	残り6件×20分＋レビュー結果の確認2時間＝4時間
環境で確認できないケース	30件が混ざる。確認・相談1件20分。分類で8割を事前に解消	30件×20分＝10時間	残り6件×20分＋分類結果の確認1時間＝3時間
テスター実施で見つかるバグ	AIで先に見つかるバグが10件。テスター側の起票・切り分け・再実施に1件1時間	10件×1時間＝10時間	AI報告の確認と起票に1件15分＝2.5時間
準備（初回のみ）	環境の用意、プロンプトの調整に8時間	0時間	8時間
合計		30時間	初回17.5時間／2回目以降9.5時間

この仮定では、初回で約12時間、2回目以降は約20時間の差になります。

試算には、次のものを含めていません。

• バグの修正工数（どちらの場合も同じだけかかるため）
• AIツールの利用料
• AIが見落とした問題への対応

試算で効いているのは、1件あたりの往復時間です。テスターが社外の人や別拠点のメンバーである場合、質問と回答の往復が20分より長くなることもあります。往復が長い体制ほど、事前に潰す効果は大きくなります。

逆に、テスターが開発メンバー自身でDBも見られる体制なら、観点3の効果は小さくなります。AIレビューの効果は、仕様書の質だけでなく「誰がテストするか」で大きく変わります。

AIに任せきりにしてはいけない理由

AIの事前実行で全ケースがOKになっても、テスターの実施は省けません。理由は次のとおりです。

AIが苦手なこと	理由
見た目・使い勝手の違和感	期待結果に書かれていない違和感には気づきにくい
テスト環境固有の問題	ローカル環境で実行するため、環境差は検出できない
ケースに書かれていない操作	手順どおりに動かすので、想定外の操作を試さない
仕様の正しさの判断	どちらが正しいかは業務を知る人にしか決められない

今回の案件でも、人が実施して初めて見つかったバグがありました。AIの事前実行は工数を減らす手段であり、最終的に確かめるのは人の実施です。

また、クライアントのシステム仕様書やソースコードをAIに読ませる場合は、契約上の扱いを事前に確認してください。入力データが学習に使われない設定やプランを選ぶことも必要です。Claude Code の仕様は Claude Code の公式ドキュメントで確認できます。

レビュー全般が形骸化しやすい点については、レビューの形骸化を防ぐ｜バグが漏れる現場の立て直しも参考になります。

導入するときのチェックリスト

最初から全部を導入する必要はありません。まずは手元の仕様書の1章分を、プロンプト2に渡してみてください。 事前実行の環境がなくても、仕様書があれば試せます。

そのうえで、次の順に広げていくと、効果を確かめながら進められます。

• テスターの権限（DB・サーバーにアクセスできるか）を確認した
• テスト環境で使えないもの（外部連携・メール・権限）を書き出した
• プロンプト2で「テスターに伝わらない記述」をレビューさせた
• プロンプト3で「別担当で確認するケース」を分類した
• AIの修正案の文言を、実際の画面と照合した
• ローカル環境で対象システムを起動し、テストデータを投入できるか確認した
• 事前実行の結果を5つの判定で確認し、実装バグを開発側に戻した
• バグが出たケースは、修正後にテスターへ渡す段取りにした
• AIへのデータ入力が契約上問題ないことを確認した

よくある質問

ChatGPTなどのチャット型AIだけでもできますか？

仕様書レビュー（プロンプト1〜3）は、仕様書を貼り付ければチャット型のAIでも行えます。事前実行には、AIがブラウザを操作できる環境（Playwright MCP に対応したツール）が必要です。

クライアントの仕様書をAIに渡してよいか判断できません

契約や社内規程で、外部サービスへの入力が認められているかを先に確認してください。判断がつかないうちは、固有名詞をダミーに置き換えた一部の抜粋で試す方法があります。

事前実行で全件OKなら、テスターの実施は不要ですか？

不要にはなりません。AIは手順どおりにしか操作せず、見た目の違和感やテスト環境固有の問題は検出できません。今回の案件でも、人の実施でしか見つからないバグがありました。

まとめ

本記事のポイントを振り返ります。

• テスター工程のコストには、記述が分からない・環境が足りない・バグで進めない「止まる時間」が含まれる
• 仕様書のAIレビューでは、矛盾・不整合に加えて「テスターに伝わるか」「テスト環境で確認できるか」を見る
• Playwright MCP による事前実行は、手順を補わせず、5つの判定に分けさせる
• 約600件の案件では、AIが報告したバグはすべて実際のバグだった。一方で人の実施でしか見つからないバグもあった
• 効果は「誰がテストするか」で変わる。テスターとの往復が長い体制ほど大きい

AIは仕様書を読み、ケースを流すことは得意です。しかし、何を確認すべきかを決め、AIが見られない部分を確かめるのは人の仕事です。

自社だけでテスター体制を回しきれない場合は、外部の力を借りるのも一つの方法です。テスト仕様書の品質やテスター体制の見直しを検討されている方は、テスト体制についてお気軽にご相談ください。

次に読むならこの記事

• 受託開発のAI時代における品質保証｜実務ガイド
• AI生成テストコードのレビュー観点7つ｜AIコードレビューはどこまで使えるか
• Playwright MCPでE2Eテストを自動化する方法｜導入手順と使いどころ

テストの手戻りを減らしたい方へ

テスト仕様書のExcelテンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。

テスト仕様書テンプレートを無料DL テスト代行について相談する