要件定義書の書き方とテンプレート
在庫管理システムの例文つき。打ち合わせメモからAIで下書きしたときの未決事項・数字・設計の書き足しの実測・プロンプト
要件定義書は、システムで何を実現するかを、依頼する側と作る側で合意するための文書です。このページでは、要件定義書を「何を実現したいか」を決める文書、仕様書を「どう作るか」を書く文書として使い分けています。会社によって呼び方は異なるため、提出先の書式がある場合はそれに合わせてください。構成とテンプレートに加えて、AIに書かせたときに未決事項を決めてしまわないか、メモに無い数字や設計を足さないかを確かめた結果を紹介します。
要件定義書に書くこと
| 項目 | 書くこと |
|---|---|
| 目的と現状の課題 | 何を何に替えたいか、いま何に困っているか（数字があればそのまま） |
| 利用者と権限 | 使う人と人数、権限の種類。決まっていない権限は「未決定」と書く |
| 機能 | 必須の機能と、範囲に入れるかが決まっていない機能を分ける |
| 既存データの移行 | 移行する件数と、移行前の課題 |
| 性能・利用環境 | 同時に使う人数など、決まっている数字だけ。目標が決まっていなければ「未決定」 |
| 期限と予算 | 稼働させたい時期、予算の上限か見込みか、承認が済んでいるか |
| 範囲外 | 今回やらないこと |
| 確認が必要な事項 | 未決定・未承認の項目を、現状とともに一覧にする |
発注前に要件を整理して取引先に出す提案依頼書から、要件を抜き出す実測は提案依頼書（RFP）の要件抽出に載せています。
要件定義書のテンプレート
件名：○○システムの要件定義書（下書き） 1. 目的と現状の課題 ・ 2. 利用者と権限 ・人数が確定していなければ「未確定」 3. 機能 ・必須の機能： ・範囲に入れるかが決まっていない機能：「未決定」 4. 既存データの移行 ・対象の件数と、移行前の課題 5. 性能・利用環境 ・目標が決まっていない項目は「未決定」（数字を仮置きしない） 6. 期限と予算 ・予算は上限か見込みかを明記。承認が済んでいなければ「未承認」 7. 今回やらないこと（範囲外） ・ 8. 確認が必要な事項（未決定の一覧） ・事項と現状（未決定・未承認など）
AIで下書きしたときの実測
在庫管理システムの打ち合わせメモ（架空）を、答えを知らない状態のClaudeに、「ただ頼む」「下のプロンプトを使う」の2通りで1回ずつ解かせ、正解表と照らし合わせました（2026年10月13日、当社の作業環境から実行）。ツールを使わせないエージェントを、opus（Opus 5.5）・haiku（Haiku 4.5）の指定で起動しています。メモには、決定扱いにされやすい次の点を仕込みました。営業部長の権限、通知メールを範囲に入れるか、スマートフォン対応の要否、応答時間の目標は決まっていないこと、予算は上限を想定しているだけで社長の承認がまだ無いこと、品目コードが統一されていないこと、会計システムとの連携は今回やらないことです。
【打ち合わせメモ（2026年10月8日／営業部・情報システム部）】 ・目的：営業所3か所の在庫管理を、営業所ごとのExcelから、ブラウザで見られる在庫管理システムに替える ・困りごと：在庫の数が営業所ごとのExcelで合わない。月末の棚卸しに2日かかっている ・利用者：営業所の事務担当約15名。権限は「閲覧のみ」と「編集できる」の2種類。営業部長を編集できる側にするかは決まっていない ・機能：入庫・出庫の登録、在庫数の一覧表示、月末の棚卸し用のCSV出力。在庫が発注点を下回ったときの通知メールは「あれば望ましい」が、今回の範囲に入れるかは決まっていない ・既存データ：Excelの在庫データ約2,400品目を移行する。品目コードの付け方が統一されていない ・性能：同時に使うのは最大10人。応答時間の目標は決めていない ・期限と予算：2027年3月末までに稼働させたい。予算は上限300万円を想定しているが、社長の承認はまだ取っていない ・今回やらないこと：会計システムとの連携 ・決まっていないこと：スマートフォン対応の要否、通知メールの扱い、営業部長の権限
採点は正解表の8項目（目的と現状・利用者・機能・通知メール・移行・性能・期限と予算・範囲外と未決）です。これとは別に、メモに無い数字・日付・設計・決定を書き足した数と種類を数えました。
| 条件 | 8項目の得点 | 未決事項の扱い | メモに無い数字・日付・設計の書き足し |
|---|---|---|---|
| Opus 5.5・プロンプトあり | 8 | 正確（「未決定」「未承認」と書き、末尾の表に6件を一覧にした） | なし |
| Opus 5.5・ただ頼んだだけ | 8 | 正確（「未決」「未定」と書き、8章の表に6件を一覧にした） | 数字・日付・設計はなし。メモに無い予定1か所（「次回の打ち合わせで決める」）、影響の推定（未決事項の表の「決まらないと影響すること」欄）、文書の外の助言1つ |
| Haiku 4.5・プロンプトあり | 8 | 正確（「未決定」「未取得」と書き、「確認が必要な事項」に6件を一覧にした） | 数字・設計はなし。文書の外の助言1つ（「次は、確認事項のうち権限と通知メールの扱いを営業部と決めると、機能要件を確定できます。」） |
| Haiku 4.5・ただ頼んだだけ | 8 | 正確（「未決」「未設定」「未取得」と書いた。ただし一覧にしたのは7章の3件で、応答時間と社長の承認は別の章） | 5種類。日付「2026年10月13日」（作成日として付いたもの）、入力項目、権限による制御の行（必須）、「編集できる（入庫・出庫の登録を含む）」という権限の中身、進め方（決め方・見積もり依頼・社長への承認依頼など） |
- 未決事項を決定扱いにした条件は、4条件ともなかった。営業部長の権限・通知メール・スマートフォン対応・応答時間・社長の承認は、どの条件でも「未決」「未定」「未設定」「未承認」「未取得」などと書かれました。Opusの2条件とHaikuのプロンプトあり条件は、品目コードの扱いを含む6件を表や末尾の一覧にまとめ、Haikuのただ頼んだ条件の未決事項の一覧は3件（スマートフォン対応・通知メール・営業部長の権限）でした。応答時間の秒数など、メモに無い数字はどの条件にも出ませんでした。
- メモに無い日付・設計を足したのは、Haikuのただ頼んだ条件だけだった。版の行の「2026年10月13日」はメモに無い日付です。機能の表では、入庫の登録に「品目、数量、日付、営業所を入力して在庫を増やす」と入力項目を書き、「権限による制御」を必須の機能として1行足しています。権限の「編集できる」にも「入庫・出庫の登録を含む」と中身を足しました。メモには、権限が2種類あることだけが書かれていました。
- Opusのただ頼んだ条件は、数字や設計は足さなかったが、予定と影響の推定を足した。「次回の打ち合わせで決める」と書いたのは、メモに無い打ち合わせの予定で、決まったことのように読めます。未決事項の表に作った「決まらないと影響すること」の欄は、メモに無い影響の推定です。
- この検証は、プロンプトの効果を8項目では測れていない。メモが短く、項目名がはっきりしているため、4条件とも8項目は満点でした。差が出たのは書き足しの有無だけで、1回ずつの結果です。
AIの出力の悪い例と直した例（原文のまま）
メモに無い日付・設計・要件を足した出力と、メモにあることだけを書いた出力を、同じ場面で並べます。
| 場面 | メモに無いことを足した例（Haiku 4.5・ただ頼んだだけ） | メモにあることだけを書いた例（Opus 5.5・プロンプトあり） |
|---|---|---|
| 版・日付 | 「版：v0.1（2026年10月13日）」（作成日として付いた日付で、メモにはない） | 版の行はなく、「根拠：2026年10月8日の打ち合わせメモ（営業部・情報システム部）」 |
| 入庫の機能 | 「品目、数量、日付、営業所を入力して在庫を増やす」 | 「入庫の登録」 |
| 権限 | 機能の表に「権限による制御」の行を足し、「閲覧のみの利用者は登録・編集できないようにする」（優先度は「必須」） | 「権限は次の2種類です。」「閲覧のみ」「編集できる」 |
足した例は、承認する側が決まった仕様として読みやすい形になっています。権限による制御は権限が2種類あることから考えられる要件ですが、メモに書かれた要件ではなく、足すかどうかは決める人の判断です。右の列は、メモにある事実だけを書いています。
要件定義書のプロンプト（コピーして使えます）
上の検証で「プロンプトあり」に使ったものと同じです。
次の打ち合わせメモから、要件定義書の下書きを書いてください。守るルールは次の4つです。 1. メモにある数字・日付・人数・品目数・条件は、そのとおりに書く。 2. メモに無い数字（応答時間・稼働率・バックアップ頻度など）、設計（認証方式・使う技術・画面の仕様）、日程、人名・会社名は書かない。 3. メモで「決まっていない」とされていることは、決まったことのように書かず「未決定」と書き、末尾に確認が必要な事項として一覧にする。 4. 「今回やらないこと」は、範囲外として書く。 ［ここにメモを貼り付け］
使うときのコツ
- 版の日付や入力項目が増えていないか確かめる。メモにある日付は打ち合わせの日だけ、というように、書類の中の日付をメモと照らします。
- 「未決定」の一覧が消えていないか確かめる。下書きを整えるうちに、未決事項が決定した機能の表に混ざっていないかを見ます。
- 文書の外の助言と、文書の中の進め方を分けて読む。「次回の打ち合わせで決める」のような文が文書の中に入ると、決まった予定として読まれます。
よくある質問
要件定義書には何を書けばよいですか？
目的と現状の課題、利用者と権限、機能（必須と範囲未定を分ける）、既存データの移行、性能・利用環境、期限と予算、今回やらないこと、確認が必要な事項を書きます。決まっていない項目は数字を仮置きせず「未決定」と書き、末尾に一覧にすると、後から決定事項と取り違えられません。
要件定義書と仕様書は何が違いますか？
このページでは、要件定義書を「何を実現したいか」を決める文書、仕様書を「どう作るか」を書く文書として使い分けています。会社によって呼び方は異なるため、提出先の書式がある場合はそれに合わせてください。
AIに要件定義書を書かせると、決まっていないことを決めてしまいますか？
当社の検証（各条件1回）では、Claude Opus・Haikuとも、営業部長の権限、通知メールの扱い、スマートフォン対応、応答時間、社長の承認を決定扱いにしませんでした。一方、ただ頼んだHaikuは、メモに無い日付、入力項目、権限による制御の要件を足しました。
AIが要件定義書に書いた日付や項目は、そのまま使ってよいですか？
そのままでは使わず、メモと照らして確かめてください。当社の検証では、Haikuのただ頼んだ条件が、版の日付や入庫の入力項目をメモに無いまま書きました。承認する側は決まった仕様として読むため、メモに無い日付や設計を足さないよう指示するのが安全です。
要件定義書の下書きをAIに頼むとき、何を指示するとよいですか？
メモにある数字・日付・人数・条件はそのまま書くこと、メモに無い数字・設計・日程・人名は書かないこと、決まっていないことは「未決定」と書いて末尾に一覧にすること、今回やらないことは範囲外として書くこと、の4つを指示します。このページのプロンプトに入れてあります。
合同会社フューチャープロンプト（AIプロダクト開発・業務自動化／東京・渋谷）がまとめました。AIの検証は2026年10月13日に行いました。会社の詳細はトップページをご覧ください。
検証の進め方は実測の進め方をご覧ください。
要件定義書の下書きをAIで行う仕組みづくりのご相談
合同会社フューチャープロンプトは、打ち合わせメモから要件定義書を下書きし、未決事項と数字・設計の書き足しを確かめる手順まで含めた仕組みづくりをご一緒します。
お問い合わせ →