曖昧な要件をテスト可能にする受け入れ条件プロンプト｜Given・When・Then対応
「検索できるようにする」「エラーを分かりやすくする」といった要件を、開発者とテスターが同じ基準で判定できる受け入れ条件へ変換するためのプロンプトです。
プロダクトオーナー、ディレクター、QA担当者など、要件を具体化したい一方で、条件の抜けや曖昧な表現に悩んでいる人を想定しています。
重要なのは、AIに条件を書かせるだけでなく、正常系・異常系・境界値・未確定事項を分けて出力させることです。 これにより、もっともらしい文章で要件の穴が隠れるのを防げます。
この記事で分かることは次のとおりです。
- 受け入れ条件を作るコピペ用プロンプト
- 入力時に具体化すべき項目
- Given・When・Then形式へ変換する方法
- NG例をテスト可能な条件へ直す方法
- AIの出力をレビューするときのチェックポイント
このプロンプトで作るもの
このプロンプトの目的は、機能要件を「実装できたかどうか判定できる条件」へ変えることです。
たとえば、次の要件を考えてみます。
商品を価格で絞り込めるようにする。
この一文だけでは、最低価格と最高価格の両方が必要なのか、未入力を許すのか、最低価格が最高価格を上回った場合にどうするのかが分かりません。
AIには、元の要件から少なくとも以下を整理させます。
- 利用者と利用場面
- 操作前の状態
- 利用者が行う操作
- 画面や外部システムから確認できる結果
- 入力エラーや権限不足などの例外
- 最小値、最大値、文字数、件数などの境界
- 要件だけでは決められない質問
CucumberのGherkinリファレンスでは、Givenは初期状態、Whenはイベントや操作、Thenは期待される結果を表します。特にThenは、内部データベースの状態ではなく、利用者や外部システムから観測できる結果にするのが基本です。
ここがポイント: AIの役割は合意済みの仕様を発明することではありません。要件を判定可能な形に整理し、不明点を質問として表面化させることです。
コピペ用プロンプトテンプレート
以下は、特定のAIサービスに依存しない汎用テンプレートです。2026年7月26日時点の一般的な対話型LLMで使うことを想定しています。
あなたは、Webサービス開発に参加するプロダクトオーナー兼QA担当者です。
以下の機能要件を、開発者・テスター・業務担当者が同じ基準で判定できる受け入れ条件に変換してください。
## 対象機能
{機能名}
## 機能の目的
{利用者が達成したいこと}
## 対象ユーザー
{利用者の種類・権限}
## 元の要件
{現在分かっている要件を貼り付ける}
## 前提条件・業務ルール
{ログイン状態、対象データ、期限、上限、権限など}
## 対象範囲
{今回実装する範囲}
## 対象外
{今回実装しない範囲}
## 出力ルール
1. 最初に、要件から確定できる内容を3〜7項目で要約する。
2. 受け入れ条件を「AC-01」のような連番で整理する。
3. 各条件には次の項目を含める。
- 条件名
- 種別: 正常系 / 異常系 / 境界値 / 権限 / 状態遷移
- Given: 操作前の状態
- When: ユーザーまたは外部システムの操作
- Then: 外部から確認できる結果
4. 1つの条件では、原則として1つの振る舞いだけを扱う。
5. 「適切に」「正しく」「必要に応じて」「分かりやすく」など、判定基準が不明な表現を使わない。
6. 数値、表示内容、権限、期限などが入力情報にない場合は推測しない。
7. 推測が必要な点は受け入れ条件に混ぜず、「未確定事項」として質問形式で列挙する。
8. 正常系だけでなく、入力なし、不正値、境界値、権限不足、対象データ0件を検討する。
9. 画面のクリック手順ではなく、利用者から見た振る舞いを記述する。
10. 元の要件と矛盾する条件は作らない。
## 最終確認
出力後、各受け入れ条件を次の観点で自己点検する。
- 実行前の状態が明確か
- 操作が1つに絞られているか
- 合否を客観的に判定できるか
- 要件にない仕様を追加していないか
- 重複する条件がないか
自己点検で問題を見つけた場合は、修正後の内容だけを提示してください。
そのまま使えますが、空欄が多いほど未確定事項も増えます。AIに推測させて空欄を埋めるより、「未定」と明記して質問を出させるほうが安全です。
入力時に変える部分
出力の品質を左右するのは、プロンプトの長さより入力情報の具体性です。
必ず変える項目
{機能名}：チケット一覧でも識別できる短い名称{利用者が達成したいこと}：実装方法ではなく利用者の目的{対象ユーザー}：一般利用者、管理者、未ログイン利用者など{現在分かっている要件}：依頼文、仕様メモ、関連ルール{今回実装する範囲}：今回のリリースに含める動作{今回実装しない範囲}：将来対応や別チケットに分ける動作
分かる範囲で追加したい項目
次の情報があれば、境界値や異常系を具体化しやすくなります。
- 入力可能な文字数や数値範囲
- 日時の基準とタイムゾーン
- 利用者ごとの閲覧・編集権限
- 0件時、通信失敗時、重複時の扱い
- 表示する文言やエラーコード
- 既存機能との優先順位
「エラーを表示する」だけでは合否を判断できません。「価格には0以上の整数を入力してください、と入力欄の近くに表示する」のように、確認できる結果まで入力すると条件が安定します。
固定しておきたい指示
次の3点は、案件が変わっても残しておくのがおすすめです。
- 不明な仕様を推測せず、質問として分離する
- Thenを外部から観測できる結果にする
- 正常系だけでなく異常系と境界値も確認する
CucumberのBDD解説でも、良い例は抽象的ではなく、日時や金額など問題領域に関係する値を具体的にすると説明されています。一方、技術的な実装詳細はシナリオへ持ち込まないことが推奨されています。
入力例と出力イメージ
商品検索の価格絞り込みを例に、テンプレートへ入力してみます。
## 対象機能
商品検索の価格絞り込み
## 機能の目的
購入希望額に合わない商品を検索結果から除外する
## 対象ユーザー
ログイン状態を問わない一般利用者
## 元の要件
検索画面で最低価格と最高価格を指定できる。
条件に合う販売中の商品だけを表示する。
## 前提条件・業務ルール
価格は税込の整数で管理する。
売り切れ商品は検索結果に表示しない。
## 対象範囲
最低価格、最高価格、両方を指定した絞り込み
## 対象外
通貨の切り替え、送料を含む総額での検索
想定される受け入れ条件の一部は次のようになります。
AC-01：最低価格だけで絞り込む
- 種別：正常系
- Given：税込価格が2,000円、3,000円、4,000円の販売中商品が存在する
- When：利用者が最低価格に3,000円を指定して検索する
- Then：3,000円と4,000円の商品が表示され、2,000円の商品は表示されない
AC-02：上限と下限を含めて絞り込む
- 種別：境界値
- Given：税込価格が2,999円、3,000円、5,000円、5,001円の販売中商品が存在する
- When：利用者が最低価格に3,000円、最高価格に5,000円を指定して検索する
- Then：3,000円と5,000円の商品が表示され、2,999円と5,001円の商品は表示されない
AC-03：売り切れ商品を除外する
- 種別：状態
- Given：税込価格4,000円の販売中商品と売り切れ商品が存在する
- When：利用者が最低価格3,000円、最高価格5,000円で検索する
- Then：販売中商品だけが表示され、売り切れ商品は表示されない
未確定事項には、たとえば次の質問が残ります。
- 最低価格または最高価格に負数を入力した場合、検索を止めるか、0円として扱うか
- 最低価格が最高価格を上回る場合、どのエラー文言を表示するか
- 小数や桁区切り記号を入力できるか
- 条件に合う商品が0件の場合、何を表示するか
この質問にプロダクト責任者が答えれば、その回答を追加入力して異常系の条件を再生成できます。
NG例を改善する
受け入れ条件でよく起きる失敗は、要望を言い換えただけで終わることです。
NG例
- 正しい価格の商品が表示されること
- 不正な入力では適切なエラーが表示されること
- 検索が問題なく動作すること
「正しい」「適切」「問題なく」の意味が定義されていません。開発者が実装を終えたと判断しても、テスターや依頼者が別の結果を期待する可能性があります。
改善用プロンプト
既存の受け入れ条件だけを直したい場合は、短い改善用テンプレートが便利です。
以下の受け入れ条件をレビューしてください。
{既存の受け入れ条件}
次の順で出力してください。
1. 判定できない表現と、その理由
2. 要件から不足している正常系・異常系・境界値
3. Given・When・Then形式に直した受け入れ条件
4. 仕様決定が必要な質問
制約:
- 入力にない数値、文言、権限、業務ルールを作らない
- 1つの条件には1つの振る舞いを書く
- Thenには利用者または外部システムから確認できる結果を書く
- UI部品の操作手順ではなく、機能の振る舞いを中心にする
Cucumberの「Writing better Gherkin」は、「何を実現するか」を記述し、「どう操作するか」という実装手順を避ける宣言的な書き方を勧めています。ボタン名や画面遷移へ条件を結びつけすぎると、UI変更のたびに受け入れ条件まで直すことになるためです。
出力を安定させる3つのコツ
AIの初回出力を完成版として採用せず、レビュー可能な材料として扱います。
1. 事実・仮定・質問を混ぜない
AIは空白を自然な文章で補うことがあります。そこで、出力欄を明確に分けます。
- 確定事項：入力から直接読み取れる内容
- 受け入れ条件：確定事項だけで作れる判定基準
- 未確定事項：人が決める必要のある質問
仮定を許す場合も、「提案」と明示させ、受け入れ条件には自動で組み込ませないようにします。
2. 具体例で境界を確認する
「3,000円以上」のような条件では、2,999円、3,000円、3,001円を並べると境界が明確になります。
同じ考え方は、次の要件にも使えます。
- 文字数：上限の1文字前、上限ちょうど、上限の1文字後
- 日付：期限の前、期限ちょうど、期限の後
- 件数：0件、1件、最大件数、最大件数超過
- 権限：許可あり、許可なし、権限変更後
具体例は条件を増やすためではなく、チーム内で同じルールを想像できているか確かめるために使います。CucumberのExample Mappingでも、ルール、具体例、未回答の質問を分けて整理し、開発前に範囲を明確にする方法が示されています。
3. 条件を増やしすぎない
AIに「網羅的に」とだけ指示すると、似た条件が大量に生成されることがあります。
次のように制限すると、レビューしやすくなります。
優先度が高い受け入れ条件を最大10件に絞ってください。
同じ業務ルールを検証する条件は統合してください。
統合すると合否判定が曖昧になる場合だけ分割してください。
追加候補は「補足テスト観点」として本文と分けてください。
CucumberのGherkinリファレンスも、1つの例に含めるステップが多すぎると、仕様や文書としての表現力が下がると説明しています。条件数ではなく、各ルールの意図が読み取れるかを優先します。
受け入れ条件とDefinition of Doneを混同しない
受け入れ条件は個別機能の期待動作、Definition of Doneは成果物全体に共通する品質基準です。
たとえば、価格絞り込みの受け入れ条件には「3,000円以上の商品が表示される」と書けます。一方、コードレビュー、必要なテスト、セキュリティ確認、文書更新など、複数の機能に共通する完了基準はDefinition of Done側で管理します。
Scrum Guideは、Definition of Doneを、プロダクトに必要な品質基準を満たしたIncrementの状態を示す正式な記述と定義しています。
AIへ両方を同時に作らせると、機能固有の動作とチーム共通の完了手続きが混ざりやすくなります。入力欄を分けるか、今回のプロンプトでは受け入れ条件だけを対象にしてください。
活用パターン
基本テンプレートは、開発前後の複数の場面で使えます。
チケット作成前の要件整理
会議メモや依頼文を入力し、条件より先に未確定事項を抽出します。質問への回答が集まってから受け入れ条件を再生成すると、推測の混入を減らせます。
QA観点の洗い出し
合意済みの受け入れ条件を入力し、正常系、異常系、境界値、権限、状態遷移のどこが不足しているかを分類させます。ただし、詳細なテストケースや操作手順は別の成果物として分けます。
API機能への応用
Thenを画面表示ではなく、利用者側から観測できるHTTPステータス、レスポンス項目、エラーコードに置き換えます。レスポンス例を与える場合は、既存のAPI契約と矛盾しないようにしてください。
バグ修正の再発防止
発生条件、実際の結果、期待する結果を入力し、修正後に満たす条件を作ります。元の正常動作が壊れていないことを確認する条件も、必要に応じて追加します。
使用前のチェックリスト
最後に、生成された条件を人が確認します。
- [ ] 対象ユーザーと権限が明記されている
- [ ] Givenに必要な初期状態がある
- [ ] Whenが1つの操作またはイベントに絞られている
- [ ] Thenを画面、通知、レスポンスなどから確認できる
- [ ] 「正しく」「適切に」などの曖昧語が残っていない
- [ ] 正常系だけでなく異常系と境界値が検討されている
- [ ] 入力にない仕様をAIが追加していない
- [ ] 未確定事項に回答者または決定期限を設定できる
- [ ] 個別機能の条件とDefinition of Doneが混ざっていない
- [ ] 条件を開発者、QA担当者、業務担当者が同じ意味で読める
AIが整ったGiven・When・Thenを返しても、それだけで仕様が確定したことにはなりません。次に行うべきことは、未確定事項へ回答し、具体例を関係者で確認してからチケットへ反映することです。 判断できない項目が残ったままなら、条件を増やすより先に、その仕様を誰が決めるのかを明確にしてください。