検証可能な受入基準を書く

著者: AILesson6 分でセットアップテスト済み:ChatGPTレビュー日: 2026-08-28

クイック回答

要件を、観察可能な合格条件、境界事例、除外事項、証拠に変える. 入力するもの: 要件とユーザー成果, 業務と品質のルール, 範囲と不明点. 期待される結果: トレーサビリティ、例、未解決の決定事項を含むテスト可能な受入基準一式.

1

コンテキストを追加

テキストはこのブラウザ内に留まります。AILesson Prompts は、そのテキストをモデルやサーバーに送信しません。

2

あなたのプロンプト

未入力のフィールドはプレースホルダーとして表示されたままなので、プロンプトをコピーして編集できます。

要件に対する検証可能な受入基準を書いてください。

承認済みの要件、ユーザー、目的、出典:
[requirement]

業務、データ、権限、状態、しきい値、アクセシビリティ、性能、エラーのルール:
[rules]

範囲、除外事項、プラットフォーム、依存関係、未解決の用語、承認者:
[boundaries]

提供されたルールだけを使ってください。複数の動作を含む要件を、独立した基準に分けます。各基準について、ID、元の要件、前提条件、行動またはイベント、観察可能な期待結果、テストデータまたは境界事例、証拠、優先度を示してください。関連があり、指定されている場合に限り、正常系、空・無効・重複入力、権限の境界、中断または部分的完了、時間とロケールの動作、復旧、アクセシビリティ、非機能しきい値を扱います。曖昧な要件は「決定が必要」と記し、しきい値や実装を創作しないでください。「速い」「直感的」「適切」「リアルタイム」など、テストできない表現と矛盾を検出します。最後に、範囲外の確認事項とトレーサビリティマトリクスを示してください。
Playgroundで試す
デフォルトで非公開プロンプトの組み立てはブラウザ内で行われます。組織が許可しない限り、機密情報を AI サービスに入力しないでください。

入力から結果へ

具体例

具体的なコンテキストを加えると、このレシピが実用的な結果になる様子をご覧ください。

実際の入力

要件とユーザー成果
「REQ-12:認証済みの従業員は、未完了の作業を失わないよう、経費申請を提出せずに下書きとして保存し、後で戻ることができる。」
業務と品質のルール
申請にはClaimID、従業員ID、通貨、明細、領収書添付、状態、作成・更新タイムスタンプがある。下書きでは領収書とコストセンターを省略できる。作成した従業員だけが閲覧・編集できる。提出時に必須フィールドを検証するが、このストーリーの範囲外。自動保存は「速く」と要求されているが、間隔は承認されていない。対応するWebロケールはen-GBとzh-CN。添付には既存のアップロードルールを使う。
範囲と不明点
Webのみ。オフライン編集と管理者アクセスは範囲外。認証サービスとアップロードサービスに依存。プロダクトオーナーが基準を承認する。セッション期限切れ時の動作と下書き保持期間は未解決。

出力例

AC-01 | REQ-12 | 認証済みの従業員が申請を開始 | 「下書きを保存」を選択 | 一意のClaimIDが、作成者、Draft状態、通貨、既存の明細データ、更新タイムスタンプとともに保存される。提出は行われない | 証拠:永続化された記録と画面上の確認 | 必須。 AC-02 | REQ-12 | 下書きに領収書とコストセンターがない | 下書きを保存 | Draft状態では両方が任意のため、保存に成功する | 境界事例:明細1件、添付・コストセンターなし | 必須。 AC-03 | 所有権ルール | 従業員Bが画面または直接URLから従業員Aの下書きを要求 | アクセスが拒否され、申請の詳細は公開されない | 証拠:認可テスト・ログ | 必須。 AC-04 | 後で戻る | 作成者が後でen-GBまたはzh-CNでサインイン | 保存された値を含む下書きがロケールに適した形式で表示される。基になる金額とタイムスタンプは変わらない | 必須。 AC-05 | アップロード依存 | 既存のアップロードルールにより添付の保存に失敗 | 下書きの動作と復旧可能なメッセージは確認が必要。添付が保存されたと主張しない | 決定が必要。

決定が必要:「速く」に代わる自動保存間隔。セッション期限切れ時の未保存編集の扱い。保持期間と削除通知。範囲外:提出時の検証、管理者アクセス、オフライン編集。トレーサビリティ:REQ-12→AC-01/02/04、所有権→AC-03、アップロード依存→AC-05。

これがうまくいく理由

  1. 1

    観察可能な結果と境界事例により、実装開始前に合意内容をテストできます。

  2. 2

    「決定が必要」という表示により、製品上の曖昧さがテストケース内に隠れるのを防げます。

結果を確認

  • 各基準は独立し、観察可能で、提供された要件までたどれますか?

  • 境界条件は一般的な定型文ではなく、実際に関連するものですか?

  • 不足するしきい値と未定義の用語を、決定事項として残していますか?

安心して使うために

よくある質問

このレシピをいつ使うか、何を用意するか、どの場面で人による確認が依然として重要かについての実践的な回答です。

「検証可能な受入基準を書く」を使用する前に、何を準備すればよいですか?

「検証可能な受入基準を書く」を使用するには、要件とユーザー成果、業務と品質のルール、範囲と不明点を準備してください。プレースホルダーは確認可能な情報だけで置き換えます。詳細が不明な場合は、モデルに推測させず、不明であることを明示してください。

「検証可能な受入基準を書く」の結果は、どのような場合にまだ使用できませんか?

提供された証拠から、記載された成果である「トレーサビリティ、例、未解決の決定事項を含むテスト可能な受入基準一式」をまだ作成できていない場合や、未解決の前提、承認の不足、創作した詳細に依存している場合、その結果は使用できません。チェック項目を公開可否の判断基準として使い、裏付けのない出力を磨くのではなく、元の入力を修正するか、権限を持つ担当者を指名してレビューを依頼してください。

「検証可能な受入基準を書く」では、どのAIツールのテスト記録がありますか?

2026-08-28時点で、「検証可能な受入基準を書く」の公開テスト記録にはChatGPTが掲載されています。これは実行記録があることを示すだけで、今後の製品バージョンとの互換性や同一の結果を保証するものではありません。別のツールやバージョンでは、すべての制約を明示したまま、使用前に結果のチェック項目をもう一度確認してください。

さらに探す方法

このレシピが役立つ場面

作業を前に進める