要件定義書の書き方：AIに伝わる「目的・スコープ・やらないこと」
この記事の結論
- 「いい感じのアプリを作って」だけでは、AIコーディングエージェントは何をどこまで作ればいいのか判断できません。
- この記事では「なぜ先に書くのか」「5項目のテンプレート」「要件定義書・仕様書・スコープ定義の違い」「やらないことの書き方」「失敗チェックリスト」を扱います。
- 最終更新 2026-09-11／読了目安 約8分。
「いい感じのアプリを作って」だけでは、AIコーディングエージェントは何をどこまで作ればいいのか判断できません。実装を任せる前に書いておくべき要件定義書の中身と、初心者がやりがちな失敗パターンを整理します。
最終更新: 2026-09-11・読了目安 約8分
要件定義書はなぜ必要なのか？
簡単に言うと、要件定義書は「AIに渡す注文書」です。飲食店で「おいしいもの」とだけ頼まないのと同じで、何を・誰のために・どこまで作るのかを先に書き出しておくと、作り直しが激減します。
要件定義書とは、「誰のために、何のために、何を作るのか」を言葉にした文書です。AIコーディングエージェントは指示された内容を素直に形にしようとしますが、指示があいまいだと、AIなりの解釈で機能を補い、こちらが想定していなかったものを作ってしまうことがあります。
要件定義書を先に書く目的は、AIに正確な指示を出すことだけではありません。自分自身の頭の中にある「なんとなく作りたいもの」を、具体的な言葉として確認できる形に変換する作業でもあります。書き出す過程で、自分でも気づいていなかった前提や矛盾に気づくことは珍しくありません。本格的なシステム開発における要件定義の考え方は、IPA（情報処理推進機構）「ユーザのための要件定義ガイド 第2版」でも詳しく整理されており、個人開発でも押さえておきたい観点が参考になります。
何を書けばよいのか？（5項目のテンプレート）
個人開発の規模であれば、分厚い文書は不要です。次の5項目を数行ずつ埋めるだけで、AIに渡す最初の指示として十分機能します。
| 項目 | 書くこと | 避けたい書き方 | 良い書き方の例 |
|---|---|---|---|
| 目的 | 何のために作るのか（1〜2文） | 便利なタスク管理アプリを作る | 今日やる分だけを表示して、朝に迷う時間をなくす |
| 想定ユーザー | 誰が、どんな場面で使うのか | 誰でも使える人 | 在宅で働く人が、始業前の5分に見る |
| 解決したい課題 | 今の不便と、解消された状態 | 効率が悪い | 予定が3か所に散っていて、今日の分を探すのに時間がかかる |
| 主な機能 | 箇条書きで3〜5個に絞る | 思いついた機能を10個以上並べる | タスク登録／今日の一覧／完了にする、の3つ |
| やらないこと | 今回の範囲に含めない機能 | （欄ごと書かない） | 会員登録・通知・共有は次のステップ |
この5項目は、詳細な仕様よりも一段抽象度の高い「全体像」を担います。具体的な画面設計や入出力の形は、この後の仕様書側で詳細化します。仕様書の書き方はDESIGN.mdテンプレート実例で扱っています。
「目的」はどこまで具体的に書けばよいのか？
目的の欄でありがちな失敗は、「便利なタスク管理アプリを作る」のように抽象的なまま止めてしまうことです。抽象的な目的は、AIにとっても人にとっても判断基準になりません。「毎日の作業を細切れのタスクに分解し、今日やることだけを表示して迷わせないようにする」のように、状況と結果がセットで見える1〜2文まで絞り込みましょう。
目的が具体的であれば、後の「主な機能」を選ぶときにも「これは目的に沿っているか」という判断基準として使えます。目的に沿わない機能は、たとえ思いついても「やらないこと」側に回す判断がしやすくなります。
なぜ「やらないこと」を書く必要があるのか？
初心者が最も書き漏らしやすいのが「やらないこと」の欄です。「掲示板アプリを作って」とだけ伝えると、AIは会員登録・通知・検索・管理画面まで一度に作ろうとすることがあります。範囲が広がりすぎて、いつまでも完成に辿り着かない——これは個人開発で非常によくある失敗パターンです。
「今回は投稿と一覧表示だけ。会員登録や通知は次のステップ」のように、あえて外す機能を明文化しておくと、AIも人も同じ範囲を見て進められます。スコープを絞る考え方の詳細は個人開発のアイデアの見つけ方やシラバスの仕様駆動開発の週でも扱っています。
要件定義・スコープ定義・仕様書はどう違うのか？
言葉が似ているため混ざりがちですが、決めている内容と決める順番が違います。個人開発では3つを1枚にまとめても構いませんが、「どの問いに答えている行なのか」は意識して書き分けてください。
| 呼び方 | 答える問い | 書く時期 | 中身の例 |
|---|---|---|---|
| 要件定義 | 何のために、何を満たせばよいか | いちばん最初 | 目的・想定ユーザー・解決したい課題 |
| スコープ定義 | 今回どこまでをやるか | 要件定義と同時 | 主な機能／やらないこと |
| 仕様書 | それをどう作るか | 実装に入る直前 | 画面・入力と出力・エラー時の動き |
実装の受け入れ条件まで落とし込むときは受け入れ基準の形で書くと、後からテストにそのまま使えます。
提出前に何をチェックすればよいのか？
要件定義書を書くときに陥りやすい失敗を、チェックリストとしてまとめます。
- 目的が抽象的すぎる：「使いやすい」「便利な」など評価が人によって変わる言葉だけで終わっていないか
- 想定ユーザーが「誰でも」になっている：対象を絞らないと、機能の優先順位も決められない
- やらないことを書いていない：スコープが際限なく広がる原因になる
- 主な機能が10個以上ある：1つの成果物に詰め込みすぎている可能性が高い
- 完成の定義があいまい：「動けば完成」なのか「特定の操作ができれば完成」なのかが曖昧なまま進めていないか
これらは書いた直後には気づきにくいものです。書き終えたら一晩置いてから読み返す、あるいは他の人に読んでもらうだけでも、抜け漏れに気づきやすくなります。要件定義書ができたら、それをもとに機能や画面をより詳細化する仕様駆動開発のステップに進みます。
参照した一次情報
- IPA「ユーザのための要件定義ガイド 第2版」：発注する側が何を決めるべきかの整理。
- 総務省・経済産業省「AI事業者ガイドライン」掲載ページ：AIを使って作る場合に確認したい取り組みの整理。
よくある質問
Q1. 要件定義書と仕様書は何が違いますか？
要件定義書は「誰のために、何のために作るのか」という全体像を言葉にしたものです。仕様書はそれをもとに、具体的な機能や画面、入出力の形を詳細化したものです。書く順番は全体像（要件定義書）→詳細（仕様書）の順が基本です。
Q2. 要件定義書はどのくらいの分量で書けばいいですか？
個人開発の規模であれば分厚い文書は不要です。目的・想定ユーザー・解決したい課題・主な機能・やらないことの5項目を数行ずつ埋めるだけで、AIへの最初の指示として十分機能します。
Q3. 「やらないこと」を書かないとどうなりますか？
AIが会員登録・通知・検索・管理画面など、こちらが想定していなかった機能まで一度に作ろうとすることがあります。スコープが広がりすぎて完成が遠のく、というのが個人開発でよくある失敗パターンです。
Q4. 要件定義とスコープ定義は何が違いますか？
要件定義は「何のために、何を満たせばよいか」を決める作業で、スコープ定義はそのうち「今回どこまでをやるか」という範囲を決める作業です。個人開発では2つを1枚にまとめて書くことが多く、その場合は「主な機能」と「やらないこと」の欄がスコープ定義にあたります。
Q5. 書いた要件定義書はAIにそのまま渡してよいですか？
そのまま渡して構いません。ただし全部を一度に実装させるのではなく、「主な機能」の1つ目だけを指定して作らせ、動作を確認してから次に進むほうが、修正が小さくて済みます。渡す前に、その文書だけを読んで第三者が同じものを想像できるかを読み返してください。