AI開発時代に求められる要件定義書のあり方

Last updated at 2026-05-12Posted at 2026-05-12

はじめに

近年、codexやGitHub Copilot、Claude、Cursor、V0などのAIツールを活用することで、システム開発のスピードは大きく向上しています。

画面のたたき台を作る、APIを実装する、SQLを書く、テストコードを生成する、といった作業は、以前よりもかなり短時間で進められるようになりました。

その一方で、AIを使った開発が進むほど、改めて重要になるものがあります。

それが 要件定義書 です。

AIによって実装が速くなると、

仕様書や要件定義書はなくても、AIに指示すれば作れるのでは？

と思うこともあるかもしれません。

しかし実際には、AI開発時代だからこそ、要件定義書の重要性は下がるどころか、むしろ上がっていると感じます。

ただし、ここでいう要件定義書は、従来のような「分厚くて堅いドキュメント」だけを指しているわけではありません。

AI開発時代における要件定義書は、単なる提出資料ではなく、

依頼者・開発者・AIが同じ前提を共有するための共通コンテキスト

としての役割を持つようになっていると考えています。

この記事では、システム開発において要件定義書がなぜ必要なのか、そしてAIを用いた開発が主流になりつつある今、要件定義書のあり方がどのように変わるのかを整理します。

要件定義書とは何か

要件定義書とは、簡単に言うと、

何を作るのか
なぜ作るのか
どこまで作るのか
何をもって完成とするのか

を関係者間で明確にするための資料です。

システム開発では、依頼者、開発者、デザイナー、運用担当者、管理者など、複数の立場の人が関わります。

そのため、同じ言葉を使っていても、人によってイメージしている内容が違うことがよくあります。

例えば、

注文管理システムを作りたい

という一言でも、考える人によって想定する機能は異なります。

依頼者は、

商品を選んで注文できる
注文内容を確認できる
管理者が注文を見られる

くらいをイメージしているかもしれません。

一方で、開発者は、

ログイン機能は必要か
管理画面は必要か
在庫管理は必要か
注文通知はメールかLINEか
CSV出力は必要か
権限管理は必要か
決済連携は必要か

といったことを考えます。

このように、ひとことで「注文管理システム」と言っても、具体的な中身には大きな差があります。

この認識のズレを埋めるために、要件定義書が必要になります。

要件定義書が必要な理由

1. 認識ズレを防ぐため

要件定義書がないまま開発を進めると、完成後に以下のようなトラブルが起こりやすくなります。

思っていたものと違う
この機能も当然あると思っていた
ここまで作るとは聞いていない
追加費用がかかるとは思っていなかった
どこまでが納品範囲なのかわからない

システム開発におけるトラブルの多くは、技術的な問題というよりも、最初の認識ズレから発生します。

例えば「ログイン機能」と言っても、以下のように決めることはたくさんあります。

項目	決めるべきこと
ログイン方法	メールアドレス、LINE、Google、Appleなど
パスワード再設定	必要か不要か
アカウント登録	誰が登録できるのか
退会機能	必要か不要か
権限	管理者、一般ユーザー、店舗ユーザーなどを分けるか
セキュリティ	ログイン失敗時のロック、二要素認証など

「ログイン機能を作る」という一文だけでは、具体的にどこまで作るべきか判断できません。

要件定義書に具体的な内容を記載しておくことで、依頼者と開発者の認識を揃えることができます。

2. 開発範囲を明確にするため

要件定義書は、開発範囲を明確にするためにも必要です。

システム開発では、開発途中で「あれも欲しい」「これも必要かもしれない」と機能が増えていくことがあります。

もちろん、開発途中でより良いアイデアが出ること自体は悪いことではありません。

しかし、開発範囲が曖昧なまま機能を追加し続けると、予算や納期が崩れてしまいます。

そのため、要件定義の段階で以下を整理しておくことが重要です。

今回作るもの
今回は作らないもの
将来的に追加するもの
必須の機能
あると嬉しい機能
運用でカバーする部分

特に受託開発では、要件定義書が開発範囲の基準になります。

要件定義書に書かれているものは今回の開発範囲、書かれていないものは追加要件として扱う、というように整理できます。

これにより、依頼者側も開発者側も、無用なトラブルを避けやすくなります。

3. 見積もりとスケジュールの根拠になるため

要件が曖昧なままでは、正確な見積もりはできません。

例えば、

簡単な予約システムを作りたい

と言われても、実際には以下のような内容によって工数は大きく変わります。

会員登録は必要か
管理画面は必要か
予約の承認フローは必要か
キャンセル処理は必要か
決済機能は必要か
メール通知は必要か
LINE通知は必要か
複数店舗に対応するか
スタッフごとの予約枠を管理するか
CSV出力は必要か

これらが決まっていない状態で見積もりを出すと、後から大きくズレる可能性があります。

要件定義書があることで、開発者はそれをもとに工数を分解できます。

例えば、

機能	想定作業
ログイン機能	認証、登録、パスワード再設定
予約登録	予約フォーム、バリデーション、DB保存
管理画面	一覧、詳細、検索、ステータス変更
通知機能	メール送信、テンプレート作成
CSV出力	検索条件反映、ファイル生成

このように、要件定義書は見積もりやスケジュールの根拠になります。

4. 完成後の検収基準になるため

要件定義書は、開発中だけでなく、完成後にも重要です。

なぜなら、納品時に、

何ができていれば完成なのか

を判断する基準になるからです。

例えば要件定義書に、

管理者は注文一覧をCSVで出力できる

と書かれていれば、納品時にその機能が実装されているか確認できます。

逆に、要件定義書に書かれていなければ、

CSV出力も必要だった
いや、それは聞いていない

というトラブルにつながります。

要件定義書は、単なる開発前の資料ではなく、納品・検収・請求の場面でも重要な役割を持ちます。

AI開発時代に要件定義書がさらに重要になる理由

ここからが本題です。

AIを使った開発では、コードを書くスピードが大幅に上がります。

例えば、AIに指示すれば以下のような作業を短時間で進められます。

画面のUIを作る
APIを作る
DB設計のたたき台を作る
バリデーション処理を書く
テストコードを書く
エラー原因を調査する
リファクタリングする
ドキュメントを作る

そのため、以前よりも少人数・短期間で開発を進めやすくなっています。

しかし、ここで重要なのは、

AIは実装を速くするが、何を作るべきかを自動で正しく決めてくれるわけではない

ということです。

AIに対して、

注文管理アプリを作って

と指示すれば、それっぽい画面やコードは作れます。

しかし、以下のような前提が決まっていなければ、実務で使えるシステムにはなりません。

誰が使うのか
どの業務を楽にしたいのか
どの画面が必要なのか
注文後に誰へ通知するのか
管理者は何を確認したいのか
スマホ前提なのか、PC前提なのか
既存業務のどこを置き換えるのか
どのデータを保存するのか
個人情報をどう扱うのか
将来的にどこまで拡張するのか

これらが曖昧なままだと、AIは「それっぽいもの」を高速で作ります。

しかし、それが「業務で使えるもの」とは限りません。

AIは「実装」は得意だが、「業務判断」は人間側に残る

AIは非常に便利ですが、システム開発におけるすべてを任せられるわけではありません。

特に以下のような判断は、人間側が行う必要があります。

判断内容	人間が決める理由
どの業務をシステム化するか	事業判断だから
どの機能を優先するか	予算・納期・売上に関わるから
どこまで自動化するか	現場運用とのバランスが必要だから
何を作らないか	開発範囲とコストに直結するから
誰が承認するか	業務責任に関わるから
個人情報をどう扱うか	法務・セキュリティに関わるから
どの状態を完成とするか	検収条件に関わるから

AIは、与えられた条件の中で実装することは得意です。

しかし、ビジネス上どの機能が必要なのか、どの業務を変えるべきなのか、どこまで作れば費用対効果が合うのか、といった判断は人間が行う必要があります。

つまりAI開発時代のシステム開発では、

コードを書く前の意思決定の質が、成果物の質を大きく左右する

と言えます。

要件定義書がないAI開発で起きやすい問題

AIを使えば、曖昧な指示でも一見きれいな画面やコードができます。

しかし、要件定義が不十分なまま開発を進めると、以下のような問題が起きやすくなります。

画面はできたが、実際の業務フローに合わない
DB設計が後から破綻する
権限設計が抜けていて作り直しになる
通知や履歴管理が後から必要になる
管理画面の検索条件が不足する
CSV出力が必要だったことに後から気づく
「誰が何をできるか」が曖昧になる
セキュリティや個人情報の扱いが後回しになる
AIが作ったコードの前提が実運用と合っていない

特にAI開発では、最初のたたき台がすぐに出てきます。

そのため、見た目だけを見ると、

もうほとんど完成している

ように感じることがあります。

しかし実際には、

見た目はできているけど、業務では使えない

という状態になることも少なくありません。

AIによって実装スピードが上がるからこそ、最初に方向性を間違えると、間違ったものも高速に作られてしまいます。

従来の要件定義書とAI開発時代の要件定義書の違い

従来の要件定義書は、主に以下のような目的で作られることが多かったと思います。

発注者と開発者の認識を合わせる
見積もりの根拠にする
契約範囲を明確にする
開発者が実装内容を理解する
納品時の検収基準にする

もちろん、これらの役割は今後も重要です。

ただし、AI開発時代では、要件定義書にもう一つ大きな役割が加わります。

それが、

AIに正しく開発させるための前提情報になる

という役割です。

AIは、前提が明確であればあるほど、精度の高い出力を返しやすくなります。

逆に、前提が曖昧なままだと、AIは一般的なパターンやそれっぽい推測で補完してしまいます。

そのため、AI開発時代の要件定義書は、単に人間が読むための資料ではなく、

AIに読み込ませるための開発コンテキスト

としても活用できます。

AI開発時代の要件定義書は「共通コンテキスト」になる

AIを使った開発において、要件定義書は人間同士の認識合わせだけでなく、AIへの指示書としても活用できます。

要件定義書があると、AIに対して以下のような依頼がしやすくなります。

画面一覧を作成する
画面遷移図を作成する
DB設計のたたき台を作成する
API一覧を作成する
テーブル定義を作成する
実装タスクに分解する
テスト項目書を作成する
不足している仕様を洗い出す
セキュリティ上の懸念点を洗い出す
将来的な拡張性を考慮した設計を提案する

例えば、要件定義書をAIに読み込ませて、

この要件定義をもとに、必要な画面一覧を作成してください

と依頼できます。

また、

この要件定義に不足している観点を洗い出してください

と依頼することもできます。

さらに、

この要件定義をもとに、Laravel + Reactで実装する場合のDB設計を提案してください

というように、より具体的な実装準備にも活用できます。

このように、AI開発時代の要件定義書は、

依頼者・開発者・AIが同じ前提を共有するための共通コンテキスト

として機能します。

要件定義書は「作るため」だけでなく「作らないため」にも必要

要件定義書というと、必要な機能をまとめる資料というイメージがあるかもしれません。

しかし、実際には「作らないもの」を決めるためにも重要です。

システム開発では、すべての機能を最初から作ろうとすると、開発コストも期間も膨らみます。

そのため、初期リリースでは以下のように優先順位を決めることが重要です。

決済機能は初期リリースでは入れない
チャット機能は後回しにする
多店舗対応は次フェーズにする
CSV出力は管理者のみ対応する
スマホ対応を優先し、PC最適化は後回しにする
通知はまずメールのみ、LINE通知は次フェーズにする

AIで実装が速くなったとしても、機能を増やせば以下の作業も増えます。

テスト
デバッグ
保守
運用
セキュリティ確認
マニュアル作成
ユーザーサポート

つまり、AIがあるからといって、無制限に機能を増やしてよいわけではありません。

むしろ、AIで作れる範囲が広がったからこそ、

今回は何を作らないのか

を明確にすることが重要になります。

AI開発時代の要件定義書は重厚な資料である必要はない

ここで注意したいのは、要件定義書は必ずしも分厚くて堅い資料である必要はないということです。

特に小規模〜中規模の開発であれば、まずは実用的な内容を整理できていれば十分です。

例えば、以下のような項目をまとめるだけでも効果があります。

項目	内容
目的	何のために作るのか
背景	なぜ今必要なのか
対象ユーザー	誰が使うのか
解決したい課題	どの業務・不便を解消するのか
現在の業務フロー	現状どのように運用しているのか
導入後の業務フロー	システム導入後にどう変わるのか
機能一覧	必要な機能、不要な機能
画面一覧	どんな画面が必要か
権限	管理者、一般ユーザー、店舗など
データ項目	保存する情報
外部連携	LINE、決済、メール、外部APIなど
非機能要件	セキュリティ、速度、バックアップなど
検収条件	何ができれば完了か

重要なのは、見た目がきれいな資料を作ることではありません。

関係者が判断できる状態にすることです。

完璧な要件定義書を最初から作ろうとすると、逆に進まなくなることもあります。

最初はラフでもよいので、開発しながら更新していく形でも十分価値があります。

要件定義書に最低限入れておきたい項目

個人的には、AIを活用した開発であっても、最低限以下の項目は整理しておいた方がよいと考えています。

1. システムの目的

まずは、何のためにシステムを作るのかを明確にします。

例：

電話や紙で行っている注文管理をWeb化し、注文内容の確認・共有・履歴管理を効率化する。

目的が曖昧だと、機能の優先順位も決めにくくなります。

2. 対象ユーザー

誰が使うシステムなのかを整理します。

例：

一般ユーザー
店舗スタッフ
管理者
代理店
外部取引先

ユーザーごとに、できること・見える情報・必要な画面が変わります。

3. 業務フロー

現状の業務フローと、システム導入後の業務フローを整理します。

例：

現在：
電話で注文を受ける
↓
紙にメモする
↓
担当者が内容を確認する
↓
商品を準備する

導入後：
ユーザーがWebから注文する
↓
店舗側に通知が届く
↓
管理画面で注文内容を確認する
↓
ステータスを更新する

業務フローが整理されていると、必要な画面や機能が見えやすくなります。

4. 機能一覧

必要な機能を一覧化します。

例：

区分	機能	優先度
ユーザー	会員登録	高
ユーザー	ログイン	高
ユーザー	注文作成	高
管理者	注文一覧	高
管理者	注文詳細	高
管理者	CSV出力	中
管理者	売上集計	低

優先度をつけることで、初期リリースに必要な範囲を決めやすくなります。

5. 画面一覧

どのような画面が必要なのかを整理します。

例：

画面名	利用者	内容
ログイン画面	全ユーザー	メールアドレスとパスワードでログイン
注文作成画面	一般ユーザー	商品を選択して注文
注文履歴画面	一般ユーザー	自分の注文履歴を確認
注文一覧画面	管理者	全注文を確認
注文詳細画面	管理者	注文内容の詳細を確認
ユーザー管理画面	管理者	ユーザー情報を管理

画面一覧があると、UI設計や実装タスクに落とし込みやすくなります。

6. 権限

誰がどの操作をできるのかを整理します。

例：

操作	一般ユーザー	管理者
自分の注文作成	○	○
自分の注文履歴閲覧	○	○
全ユーザーの注文閲覧	×	○
注文ステータス変更	×	○
ユーザー削除	×	○

権限設計は後回しにすると手戻りが大きくなりやすい部分です。

AIに実装を依頼する場合でも、権限の前提は明確にしておく必要があります。

7. データ項目

システムで保存するデータを整理します。

例：

データ	項目
ユーザー	氏名、メールアドレス、電話番号、パスワード
注文	注文ID、ユーザーID、注文日時、合計金額、ステータス
商品	商品名、価格、在庫数、表示状態
通知履歴	送信先、送信日時、送信内容、結果

保存するデータが曖昧だと、DB設計やAPI設計が不安定になります。

8. 外部連携

外部サービスとの連携がある場合は、早めに整理しておく必要があります。

例：

LINEログイン
LINE通知
メール送信
決済サービス
Google Maps API
S3などのストレージ
外部業務システム
CSVインポート・エクスポート

外部連携は、仕様確認や審査、API制限、料金体系などが関係するため、後から追加するとスケジュールに影響しやすいです。

9. 非機能要件

非機能要件とは、画面や機能そのものではなく、システムの品質に関する要件です。

例：

表示速度
セキュリティ
バックアップ
ログ管理
障害時の復旧
同時アクセス数
スマホ対応
ブラウザ対応
個人情報の取り扱い

非機能要件は後回しにされがちですが、実運用では非常に重要です。

10. 検収条件

最後に、何ができれば完成なのかを明確にします。

例：

以下の条件を満たした場合、初期リリース範囲の開発完了とする。

- ユーザーが会員登録・ログインできる
- ユーザーが商品を選択して注文できる
- 管理者が注文一覧を確認できる
- 管理者が注文ステータスを変更できる
- 注文完了時にメール通知が送信される
- スマートフォンで主要画面が正常に表示される

検収条件が明確であれば、納品時の認識ズレを防ぎやすくなります。

AI開発時代の要件定義書は更新され続けるもの

従来の要件定義書は、最初に作成して、その後はあまり更新されないケースも多かったと思います。

しかし、AI開発時代の要件定義書は、一度作って終わりではなく、開発の進行に合わせて更新されるべきものだと考えています。

AIを使うと、実装のたたき台が早く出てくるため、

実際に触ってみて気づくこと
画面を見て初めてわかること
業務フローとのズレ
足りないデータ項目
不要だとわかる機能
後回しにできる機能

が早い段階で見えてきます。

そのため、最初から完璧な要件定義書を作るというよりも、

まずは開発の土台になる要件を整理し、開発しながら精度を上げていく

という考え方が合っていると思います。

ただし、何も決めずに作り始めるのではなく、最低限の目的・対象ユーザー・業務フロー・機能範囲・検収条件は整理しておくべきです。

まとめ

AIの登場によって、システム開発のスピードは大きく向上しました。

しかし、AIが速く実装できるようになったからといって、要件定義が不要になるわけではありません。

むしろ、AI開発時代だからこそ要件定義書は重要になります。

理由は、AIに曖昧な指示を出すと、曖昧なまま「それっぽいもの」が高速で作られてしまうからです。

要件定義書は、単なる提出書類ではありません。

本質的には、

何を作るか
何を作らないか
誰のために作るか
何をもって完成とするか

を明確にするためのものです。

そしてAI開発時代においては、

依頼者・開発者・AIが同じ前提を共有するための共通コンテキスト

としての役割も持ちます。

従来の要件定義書は、主に人間同士の認識合わせや契約・検収のための資料でした。

一方で、AI開発時代の要件定義書は、それに加えて、AIに正しく開発させるための前提情報としても機能します。

つまり、要件定義書は不要になるのではなく、役割が変わってきているのだと思います。

AIによって実装のスピードが上がる今こそ、開発前の要件整理がより重要になります。

要件定義書は、昔ながらの堅いドキュメントではなく、AIを正しく活用するための設計図として考えるべきだと思います。

最後に

AIを使えば、コードを書くこと自体はどんどん効率化できます。

しかし、

何を作るべきか
なぜ作るのか
どこまで作るのか
どの状態を完成とするのか

を決めるのは、今後も人間の重要な役割です。

AI開発時代のシステム開発では、要件定義書の価値はなくなるのではなく、むしろ高まっていくと考えています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up