PRDはAIへの指示書。Gherkinで書き切るgaipack AIDD流の要件定義

AI駆動開発（AIDD）では、PRD（プロダクト要求仕様書）は人間が読むためだけの文書ではなく、AIがコードやテストを生成するための入力になります。この記事では、gaipackが実践しているAIDD流のPRDの書き方を、3レイヤー構成、曖昧表現の排除、Gherkin形式の受け入れ基準、E2Eテストへの接続の順に解説します。

PRDはAIへの指示書になる

従来の開発では、PRDは人間のエンジニアが読む文書でした。書き手が多少曖昧に書いても、読み手が打ち合わせで行間を埋めながら設計へ翻訳してくれます。

AI駆動開発ではこの前提が変わります。gaipackのAIDDでは、PRDはAIへの指示（Input）として機能し、そのままコード生成のプロンプトになります。AIは行間を確認しに来ません。曖昧な記述は推測で補完され、頼んでいない機能の生成や、既存仕様と食い違う実装につながります。PRDの曖昧さは、打ち合わせでの質問ではなく、コードの手戻りとして返ってくるようになります。

だからこそ、AIDDの要件定義は「AIが誤解しようのない密度で書き切る」ことを目指します。

PRDに書くこと、書かないこと

gaipackのPRDは、戦略・要件・管理の3レイヤーで構成します。

戦略レイヤー（Why & Who）: 概要、背景・課題、目的・ゴール、ユーザー定義（役割と権限）
要件レイヤー（What & UX）: 機能要件、UI/UX要件
管理レイヤー（Boundaries & Risks）: 制約条件、リスク、用語定義

この構成で特徴的なのは、「書かないこと」を先に決めている点です。

記載する	記載しない
業務要件（業務フロー・ユーザーシナリオ・業務ルール）	エンティティ・データモデル
UX要件（画面構成・画面遷移・ユーザー体験）	DB・テーブル定義
根拠のある制約条件（法令・既存環境・顧客指定）	API設計・内部アーキテクチャ
Gherkin形式の受け入れ基準	実装詳細・利用ライブラリ

DBスキーマやAPI仕様は基本設計フェーズの成果物です。PRDに書いてしまうと、要件の議論と実装手段の議論が混ざり、レビューが発散します。AIに書かせる場合は影響がもっと大きく、根拠のない技術仕様を推測で生成し、それが既成事実として下流工程に流れていきます。

記載するかどうかの境界は「業務上の事実かどうか」で判断します。たとえば「承認時に債権管理システムへ連携する」は業務の事実なので記載します。「連携には内部のイベントバスを使う」は実装手段なので書きません。

曖昧表現を検証可能な記述に置き換える

AIへの指示書として機能させるために、曖昧な表現を測定・検証できる記述へ置き換えます。

NG	OK
高速に検索できること	検索結果を3秒以内に表示すること
使いやすい一覧画面	受付番号・会員番号・氏名・申請種別で複合検索でき、デフォルトで申請日時の降順に並ぶ
適切な権限制御	「会員登録グループ」ロールに属するユーザーのみが承認・差戻・否決を実行できる

数値や条件がまだ決まっていない場合は、それらしい値をでっち上げるのではなくTBDとして残します。gaipackのPRDではTBDをFAQセクションに集約し、確認先と期日をセットで管理します。入力資料にない情報は補わない、が原則です。人間が書くときもAIに書かせるときも、この原則が推測による過剰生成を防ぎます。

受け入れ基準はGherkinで書く

機能要件の受け入れ基準は、Gherkin形式で記述します。GherkinはCucumberなどのBDDツールで使われる構造化記法で、要件定義の各階層がキーワードに対応します。

要件定義の階層	Gherkinキーワード	内容
ユーザーストーリー	Feature	誰が・何を・なぜ
ビジネスルール	Rule	仕様の根拠となる不変の条件・制約
受け入れ基準	Scenario	ルールを検証する具体的な振る舞い
操作と状態の変化	Given / When / Then	前提・操作・期待結果
条件の補足・例外	And / But	条件の追加、やらないことの明示

会員制コンテンツの閲覧機能を例にすると、次のようになります。

GHERKIN

Feature: プレミアム会員限定コンテンツの閲覧
  As a 無料会員
  I want プレミアムプランにアップグレードして限定記事を読みたい
  So that より専門的な知識を得たい
  Rule: プレミアム会員のみが限定記事の全文を閲覧できる
    Scenario: プレミアム会員が記事を閲覧する（正常系）
      Given ログイン済みのユーザーである
      And プレミアムプランを契約している
      When 限定記事のページにアクセスする
      Then 記事の全文が表示される
      And 広告が非表示になる
    Scenario: 無料会員が限定記事にアクセスする（制限系）
      Given ログイン済みのユーザーである
      And プランが「無料」である
      When 限定記事のページにアクセスする
      Then 記事の冒頭200文字だけが表示される
      And プレミアム会員への案内が表示される
      But 記事のメイン画像は隠されない

キーワードごとに、書き方のコツがあります。

Given には画面遷移ではなく、データ・権限・状態の前提を書きます
Then には観測可能な事実だけを書きます。「適切に処理される」というThenは検証できません。画面表示、データの状態、通知の送信など、テストで確認できる形にします
But は「システムがしないこと」を明示するガードレールです。「完了画面は表示される。ただし確認メールは送信されない」のように書くと、「〜のはずだ」という思い込みによる認識ズレを防げます

正常系だけで終わらせない

1つのRuleには、正常系・異常系・エッジケースの3種類のScenarioを書きます。異常系は権限エラーやバリデーションエラー、エッジケースは境界値・同時実行・タイムアウトなどです。正常系だけのPRDは、テストにしたときに網羅性が出ません。

シナリオを書き切るには、執筆エネルギーの配分も決めておきます。gaipackでは「1:9の法則」と呼んでいて、戦略・管理レイヤーは修飾語を省いた簡潔な箇条書きにとどめ、受け入れシナリオ群に9割の労力を注ぎます。前段の作文に力を使うと、肝心のシナリオが「タイトルだけ」の空箱になりがちだからです。

機能要件にはF-1、F-2とIDを振り、シナリオ群と1対1で対応させます。IDの欠番や重複を機械的にチェックできるので、機能の書き漏れを構造的に検出できます。

GherkinがそのままE2Eテストになる

Gherkinで書いた受け入れ基準は、そのままE2Eテストの入力になります。

Playwrightにはplaywright-bdd、Vitestにはvitest-cucumberという.featureファイルを読み込むライブラリがあり、PRDのシナリオをテストコードへ接続できます。運用のポイントはファイル名の対応です。login.e2e.featureにはlogin.e2e.ts、password.unit.featureにはpassword.unit.tsのように、仕様とテストを1対1の対にします。どの仕様をどのテストが守っているかが一目でわかり、AIコーディングエージェントにも文脈が伝わりやすくなります。

仕様がテストとして実行されるようになると、PRDは「生きた仕様書」になります。シナリオでカバーした範囲であれば、実装が仕様から乖離したときにテストの失敗として検出できるため、ドキュメントの陳腐化を仕組みで防げます。

まとめ

gaipack AIDD流のPRDの書き方をまとめます。

原則	内容
PRDはAIへの入力	そのままコード生成のプロンプトになる前提で書く
技術Howを書かない	DB・API・実装詳細は基本設計へ。業務要件とUX要件に集中する
曖昧表現を排除	測定・検証できる記述に置き換え、決まっていなければTBDでFAQへ
受け入れ基準はGherkin	Given / When / Then / And / But で振る舞いを書き切る
1 Ruleに3 Scenario	正常系・異常系・エッジケースで網羅する
仕様をテストに接続	playwright-bdd等で「生きた仕様書」にする

gaipackでは、この書き方をAIDD 要件定義としてサービス提供しています。要件定義の標準化で開発の手戻りを約66%削減した導入事例もあわせてご覧ください。PRDの品質にお悩みでしたら、お気軽にKDDIアイレットへお問い合わせください！