要件定義とは
この記事の結論
- 要件定義とは、作る前の段階で「このシステムが満たすべき条件」を洗い出し、関係者の合意として確定させる工程のことです。
- 決める中身は大きく、業務要件（何の役に立つか）・機能要件（何ができるか）・非機能要件（どの程度の品質で動くか）の3層に分かれます。
- AIに実装を任せる開発でも、要件を決める役目は使う側に残ります。AIは候補を出す相手で、確定させる相手ではありません（2026-09-26 時点の整理）。
ようけんていぎ／Requirements Definition
作る前に、システムが満たすべき条件を洗い出して合意として確定させる工程のことです。
最終更新: 2026-09-26
要件定義とは（意味と読み方）
要件定義（ようけんていぎ）とは、システムを作り始める前に、そのシステムが満たすべき条件を洗い出し、関係者の合意として確定させる工程です。英語では Requirements Definition と呼ばれます。
ポイントは「工程」だという点です。文書を1枚書けば終わる作業ではありません。聞き取る、書き出す、矛盾を見つける、優先順位を付ける、合意する、という一連の流れを指します。
日本の公的な整理では、IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」（2019年12月発行）が代表的です。このガイドは、要件を定義する責任はシステムを使って業務に役立てる側、つまりユーザにあると位置づけています。
要件定義で決める3つの層
要件定義の中身は、抽象度の違う3つの層に分けて考えると整理しやすくなります。上の層が決まらないと、下の層は選びようがありません。
| 層 | 答える問い | 読書記録アプリでの例 |
|---|---|---|
| 業務要件 | 何の役に立てたいのか | 読み終えた本を後から振り返れるようにする |
| 機能要件 | システムが何をできるか | 書名と読了日を登録でき、新しい順に一覧できる |
| 非機能要件 | どの程度の品質で動くか | スマホの画面幅でも崩れない、一覧が待たずに開く |
言葉の使い分けも押さえておきます。「要求」は利用者が望んでいること、「要件」はそのうち実現すると合意した条件、と区別するのが一般的です。望みをすべて要件にするわけではなく、取捨選択が入ります。
非機能要件は見落とされやすい層です。IPAの非機能要求グレードは、発注側と開発側の認識の行き違いを防ぐ目的で、非機能要求の項目を6つの大項目に分類して一覧にし、それぞれの要求レベルを段階で示しています。
AI開発での要件定義の具体例
AIコーディングエージェントを使う場合、要件定義は「エージェントに読ませる前提条件をそろえる作業」として効いてきます。流れの一例です。
- 要求を出し切る：思いつく望みを箇条書きにし、AIに「抜けている観点はあるか」と聞いて候補を増やします。
- 要件に絞る：候補のうち今回採るものだけを
requirements.mdに残します。採らなかったものは理由と一緒に別の欄へ移します。 - 非機能要件を1行ずつ足す：
375px幅で横スクロールが出ないのように、確かめられる形で書きます。 - 読ませてから計画させる：実装を頼む前に「requirements.md を読んで、作業手順だけ出して」と指示し、解釈のずれを先に見つけます。
最後の手順が大事です。エージェントが出した手順に要件にない機能が混ざっていたら、それは書いた要件のどこかがあいまいだという合図です。
要件定義についてのよくある誤解
- 誤解：要件定義は書類を作ること → 実際：書類は合意の記録で、中心にあるのは「何を満たせば目的に届くか」を決める判断です。
- 誤解：どう作るかも要件定義で決める → 実際：使う技術や画面の組み方は、次のシステム設計の役目です。要件定義は「何を」、設計は「どうやって」を受け持ちます。
- 誤解：AIに頼めば要件も決まる → 実際：AIは要求の候補や抜けの指摘は出せますが、どれを採るかの判断材料（使う人の事情や優先順位）は持っていません。
- 誤解：一度決めた要件は変えてはいけない → 実際：作りながら分かることは多く、変更は起こります。変えるときは、変えた理由と日付を残すことが大切です。
要件定義を進めるときのコツ
IPAの要件定義ガイドは、開発の遅れの過半は要件定義の失敗にあると言われる、と述べています。個人の開発でも、つまずく場所は似ています。
- 「未決」を隠さない：決めきれない項目は空欄にせず、「未決：通知の要否」のように書いておきます。見えていれば後で拾えます。
- 要件ごとに確かめ方を添える：確かめ方が書けない要件は、まだあいまいです。完成判定の条件は受け入れ基準として別に書き起こします。
- 最初の版を小さくする：要件を全部入れた版を最初に作る必要はありません。最初に出す範囲はMVPの考え方で切り出します。
共通フレーム2013（IPA）は、要件定義プロセスに国際規格 ISO/IEC/IEEE 29148 の考え方を取り入れています。概要は共通フレーム2013の紹介ページ（IPA）で確認できます。
関連用語
関連記事
出典・参考資料
- ユーザのための要件定義ガイド 第2版（IPA）：要件定義の責任の所在と、要件定義で直面する問題の整理。
- 非機能要求グレード 紹介ページ（IPA）：非機能要求を分類し、要求レベルを段階で示したツール群。
- 共通フレーム2013（IPA）：開発から廃棄までの作業項目の共通の枠組み。要件定義プロセスに ISO/IEC/IEEE 29148 のエッセンスを導入。
よくある質問
Q1. 要件定義とは何ですか？
システムを作る前に、満たすべき条件を洗い出して関係者の合意として確定させる工程です。書類を作ることそのものではなく、何を満たせば目的に届くかを決める判断が中心にあります。
Q2. 要求と要件はどう違いますか？
要求は利用者が望んでいることで、要件はそのうち実現すると合意した条件です。望みのすべてが要件になるわけではなく、目的や手間に照らして採るものを選びます。
Q3. 機能要件と非機能要件の違いは何ですか？
機能要件はシステムが何をできるか、非機能要件はそれがどの程度の品質で動くかを表します。表示の速さや画面幅への対応、データの守り方などは非機能要件にあたり、書き漏らしやすい部分です。
Q4. AIコーディングエージェントに要件定義を任せてもよいですか？
要求の候補を出させたり、抜けている観点を指摘させたりする使い方は有効です。ただし、どの要求を採るかは使う人の事情で決まるため、最終的に確定させるのは人の側です。