要求と要件は違う｜PRDの書き方と、AIに渡すときの作法

「予約できるサイトが欲しい」。これは要求です。要件ではありません。この2つを混同したまま作り始めると、必ず作り直しになります。 この記事では、要求と要件の違い、そしてPRD（要件定義書）の書き方を、AIで自分でも作れる時代に合わせて整理します。

まず結論

要求は「誰が、なぜ、何に困っているか」。要件は「そのために何を作るか」です。

	要求（Requirement）	要件（Specification）
誰が言うもの	顧客・利用者・事業側	作る側が定義する
例	「予約の電話対応で手が止まる」	「Webから日時を選んで予約を確定できる」
変わりやすさ	変わりにくい	変わりやすい
間違えたときの損失	大きい。作り直しになる	小さい。直せばよい

要求を確かめずに要件から始めると、正しく作られた間違ったものができます。

要求を掘る：なぜなぜではなく「いつ・何回」

要求を掘るとき、「なぜ？」を繰り返す方法が知られていますが、慣れないと誘導になりがちです。もっと確実なのは、事実を聞くことです。

1. 1

   いつ起きたか

   「最後にその問題が起きたのはいつですか？」思い出せないなら、頻度が低い証拠です。

2. 2

   何回起きるか

   「週に何回くらいですか？」数えられない問題は、優先度が低いことが多いです。

3. 3

   今どうしているか

   「今はどう対処していますか？」代替手段があるなら、その不便さが価値の上限になります。

4. 4

   いくら払っているか

   「その対処に、時間やお金をどれくらい使っていますか？」ここが価格の根拠になります。

「あったら便利ですか？」は聞かないでください。 ほぼ全員が「便利ですね」と答えます。判断材料になりません。

要求を1文にする

掘った内容を、次の形に落とします。埋まらない項目があるなら、まだ聞き足りていません。

【誰が】予約の電話対応をしている個人サロンのオーナーが
【いつ】施術中に電話が鳴ったとき
【何に困っている】手を止めて対応するため、施術の質が落ちる
【今どうしている】留守番電話にして、後でかけ直している
【その代償】1日30分のかけ直し作業と、取りこぼしが週2件

この形にすると、要件が自動的に決まってきます。 上の例なら、必要なのは「施術中でも予約が入る仕組み」であって、売上分析でも顧客管理でもありません。

PRDに書くこと

PRD（Product Requirements Document）は、作るものを定義する文書です。形式は自由ですが、次の項目が抜けると必ず後で困ります。

項目	書くこと	抜けるとどうなるか
背景	誰の、どんな問題か	途中で「そもそも何のため」が迷子になる
成功の定義	何がどうなれば成功か	完成の判断ができない
対象外	今回やらないこと	際限なく機能が増える
利用者の流れ	使う人が何をするか（画面単位）	実装時に解釈がぶれる
扱うデータ	何を保存するか	後から作り直しになる
制約	期限・予算・法令	実現不能な設計になる

「対象外」を必ず書く

PRDでいちばん効くのが、この項目です。

## 対象外（今回は作らない）

・スマホアプリ版（Webのみ）
・複数店舗の管理（1店舗のみ）
・売上の分析機能
・キャンセル待ちの自動繰り上げ
・クレジットカード決済（現地払いのみ）

書いておかないと、必ず「これも入れられる？」が積み上がります。先に書いてあれば、「今回は対象外です」と一言で返せます。

「扱うデータ」を書く重要性

これは見落とされがちですが、後戻りが最も大きい項目です。

## 扱うデータ

予約
・予約者名（必須）
・電話番号（必須）
・希望日時（必須）
・人数（必須）
・備考（任意）
・キャンセル済みかどうか

保存期間: 施術日から1年
個人情報: 含む（氏名・電話番号）

最後の2行を必ず書いてください。 個人情報を含むかどうかで、必要な安全対策が変わります。ここを書いておけば、作る段階で「本人のデータしか見せない」設定を忘れません。

理由はAIでアプリができた！でも、そのまま公開して大丈夫？に詳しく書きました。

優先順位のつけ方

機能が多すぎるときは、**MoSCoW（モスクワ）**という整理が使えます。

区分	意味	判断基準
Must	これがないと成立しない	なければリリースしない
Should	あるべきだが、なくても出せる	次のリリースでもよい
Could	あれば嬉しい	余裕があれば
Won't	今回はやらない	対象外に書く

MustはPRD全体の2〜3割に収めてください。 半分以上がMustになっている場合、要求の絞り込みができていません。

もう1つ有効なのが、**「これがなくても、確かめたいことは確かめられるか？」**という問いです。答えが「確かめられる」なら、それはMustではありません。

PRDをAIに書かせるときの指示

ここからが、これまでと違う部分です。PRDの下書きはAIに作らせて、判断だけ自分でやるほうが速くなりました。

新規事業のPRDを書きたいです。下書きを作ってください。

わかっていること:
【誰が】（対象者）
【いつ】（問題が起きる場面）
【何に困っている】（具体的に）
【今どうしている】（代替手段）
【その代償】（時間やお金）

次の項目で書いてください。
・背景
・成功の定義（数値で測れる形にしてください）
・対象外（今回作らないこと）
・利用者の流れ（画面単位で）
・扱うデータ（項目名・必須かどうか・個人情報を含むか・保存期間）
・制約

わからない部分は、推測で埋めずに「要確認」と書いてください。

最後の一文が重要です。 これがないと、それらしい内容で埋められてしまい、確認すべき箇所が見えなくなります。

PRDから、そのまま試作品を作る

PRDができたら、それを渡して試作品を作らせられます。ここが、これまでと決定的に違う点です。

このPRDをもとに、検証用の試作品を作ってください。
本番で使うものではなく、10人に触ってもらうためのものです。

（PRDを貼り付け）

条件:
・「利用者の流れ」の中心となる1本だけを実装してください
・対象外に書いたものは作らないでください
・データの保存は Supabase、公開は Vercel で、無料の範囲でお願いします
・扱うデータに個人情報が含まれるので、
  Supabase の RLS で、本人のデータしか見えないようにしてください

PRDが具体的なほど、出てくるものの精度が上がります。 逆に言えば、曖昧なPRDは、AIを使っても曖昧なものにしかなりません。

PRDの質は、AI時代にむしろ上がった

これまでPRDは、エンジニアに渡すための文書でした。曖昧でも、対話で埋められました。

今は、PRDがそのまま入力になります。 曖昧なまま渡すと、曖昧なものが出てきます。しかも速く出てくるので、間違いに気づくのが遅れます。

自分とAIでできることが多い

• 自分や友達だけで使うツール
• 学校や会社の中だけで使うツール
• アイデアを試すための試作品
• 利用者が少ない小さなサービス

専門家の知識が重要になる

• 他人の個人情報を預かる
• お金のやりとりをする
• 利用者が一気に増えたとき
• 動かなくなったときの復旧

PRDを書く力の重要性は、下がるどころか上がっています。

よくある質問

Q. PRDはどれくらいの分量が適切ですか？ A. A4で2〜3枚が目安です。それ以上になるなら、対象範囲が広すぎます。

Q. 要求が固まらないうちに作り始めてもいいですか？ A. 試作品なら構いません。 むしろ作って見せたほうが、要求が明確になることがあります。ただし本番は、要求が固まってからです。

Q. 成功の定義は、どう書けばいいですか？ A. 数えられる形にしてください。 「使いやすくなる」ではなく「かけ直し作業が1日30分から5分になる」のように書きます。

Q. エンジニアにPRDだけ渡すのと、試作品も渡すのはどちらがよいですか？ A. 両方渡すのがいちばん伝わります。 進め方はプロトタイプまで作って、あとはエンジニアに渡すにまとめました。

Q. 対象外を書くと、機会損失になりませんか？ A. なりません。**対象外は「永久にやらない」ではなく「今回はやらない」**です。次のリリースで入れれば済みます。

まとめ

• 要求は「誰が、なぜ、何に困っているか」。要件は「何を作るか」
• 要求は意見ではなく**事実（いつ・何回・今どうしている・代償）**で掘る
• PRDで抜けると困るのは、対象外と扱うデータ
• 優先順位はMoSCoW。Mustは全体の2〜3割に収める
• PRDの下書きはAIに書かせ、**「わからない部分は要確認と書いて」**を必ず入れる
• 曖昧なPRDからは、曖昧なものしか出てこない。 PRDの重要性はむしろ上がった