結論から言うと、生成AIの要件定義でまず決めるべきは、細かい画面や処理の仕様ではなく、「成果の判定基準（どうなれば合格か）・使えるデータの在り処と品質・人がどこで確認するか・失敗時にどう振る舞うか」の4つです。 生成AIは出力が毎回まったく同じにはならないため、従来のシステム開発のように「仕様を固めてから作る」進め方が噛み合いません。正しさを「仕様との一致」ではなく「代表的なケースで期待水準を満たすか」で定義し、実際の出力を見ながら要件を磨く——この順番の違いが、PoC止まりと成果達成を分けます。
この記事では、生成AIの要件定義が従来のシステム開発と何が違うのか、具体的に何を決めればよいのか、そしてやりがちな失敗までを、AI導入を成果まで伴走する FDE（Forward Deployed Engineer／フォワードデプロイドエンジニア）の観点で解説します。
生成AIの要件定義は何が違うのか？
最大の違いは、生成AIの出力が「決定的（毎回同じ）」ではないため、「この入力ならこの出力」と一意に仕様化できない点です。 従来のシステム開発は、仕様書どおりに作れば期待どおり動くことを前提に、画面・項目・処理を細かく固めてから開発に入ります。生成AIでは、同じ入力でも表現が揺れ、想定外の入力にも何かしら答えを返します。仕様との「一致」で正しさを測れないのです。
だからこそ、要件定義で固めるべき対象が変わります。従来が「どう作るか（実装の仕様）」を固めたのに対し、生成AIでは「どうなれば成功か（成果の判定基準）」と「どこまで任せ、どこから人が見るか（責任の境界）」を先に固めます。
| 観点 | 従来のシステム開発 | 生成AIの開発 |
|---|---|---|
| 出力の性質 | 決定的（同じ入力→同じ出力） | 非決定的（表現が揺れる） |
| 正しさの定義 | 仕様との一致 | 代表ケースで期待水準を満たす割合 |
| 先に固めるもの | 画面・処理の詳細仕様 | 成果の判定基準・データ・人の関与 |
| 進め方 | 仕様確定→実装→テスト | 小さく作る→出力を見る→要件を磨く |
| 失敗の主因 | 仕様の抜け漏れ | 判定基準とデータの曖昧さ |
なぜ「仕様を固めてから作る」がAIで失敗するのか？
仕様を先にすべて固めようとすると、非決定的な出力を言葉だけで規定しようとして破綻し、机上で時間だけが過ぎるからです。 「丁寧な文体で」「適切に要約して」といった仕様は、人によって解釈が割れ、AIの出力が合格か不合格かを判定できません。判定できない基準は、実装しても「なんとなく良さそう／悪そう」の水掛け論になり、これがPoC止まりの典型的な入り口になります。
生成AIでは、言葉で規定する代わりに具体例で規定します。「この問い合わせには、この要素を含み、この禁止事項を避けた返信なら合格」という代表ケースを集め、それを合格ラインつきの判定基準にします。この判定基準がそのまま、後の評価（Evals）の土台になります。要件定義と評価設計は、AIでは地続きなのです。
生成AIの要件定義で決めるべき4つのこと
生成AIの要件定義では、次の4つを最初に握ります。細かいプロンプトや画面デザインは、この4つが決まってからで構いません。
生成AIの要件定義で先に固める4点。実装の詳細ではなく「成功の定義と責任の境界」を決める
1. 成果の判定基準——「どうなれば合格か」を具体例で決める
最初に決めるのは、AIの出力が合格かどうかを判定できる基準です。抽象的な形容詞（丁寧・適切・分かりやすい）ではなく、代表的な入力と、それに対する合格・不合格の例をセットで用意します。「この20件の入力に対して、合格ラインを満たす出力が9割以上」といった、測れる形にするのが要点です。
2. データの在り処と品質——「実現できるか」はデータで決まる
生成AIの実現可否は、モデルの賢さより必要なデータが使える状態にあるかで決まる場面が多くあります。社内文書・過去対応履歴・マスタデータが、どこにあり、参照できる形式か、内容が最新かを要件段階で確認します。ここが欠けていると、いくら良いモデルでもRAG（検索連携）が機能しません。「データが無い・古い・散らばっている」は、実装より前に見つけるべき最大のリスクです。
3. 人の関与ライン——「どこまで任せるか」を先に引く
AIにどこまで任せ、どこから人が確認・承認するかの線を、要件段階で引きます。下書きまでをAIが作り人が承認して送るのか、低リスクな範囲は自動で完結させるのか。この境界は、扱う業務のリスク（誤りが起きたときの影響）で決めます。境界の設計はワークフローへの組み込み（Human-in-the-Loop）と一体で考えます。
4. 失敗時の挙動——「間違えたとき」をガードレールで決める
生成AIは必ず一定の割合で間違えます。だから要件定義では、AIが確信を持てないときや、想定外の入力が来たときにどう振る舞うかを決めておきます。「自信が低いときは人にエスカレーションする」「範囲外の依頼は答えず定型文で断る」など、失敗を前提にした挙動をガードレールとして定義します。ここを決めないと、業務に載せた瞬間に事故が顕在化します。
具体例：問い合わせ返信ドラフト生成の要件定義
たとえば「カスタマーサポートの一次返信ドラフトをAIに作らせる」プロジェクトを、4点で要件定義してみます（数値は説明用の仮の値です）。
- 成果の判定基準：直近の問い合わせ50件を代表ケースにし、「必要な回答要素を含む／社内規程に反しない／文体が既存の返信に沿う」の3条件を満たすドラフトを合格とする。合格率8割以上を初期の目標ラインに置く。
- データの在り処と品質：過去の問い合わせと返信の履歴、FAQ、社内規程が、参照可能な形で存在するかを確認する。古いFAQが混ざっていれば、参照対象から外すか更新する。
- 人の関与ライン：AIはドラフトまで。オペレーターが確認・修正して送信する（当面は全件、慣れてきたら低リスク類型のみ自動化を検討）。
- 失敗時の挙動：規程で判断が割れる照会や、個人情報を含む依頼は、ドラフトを作らず「要人手」とフラグを立てて人に回す。
この4点が握れていれば、実装（プロンプトやRAGの構成）は反復で磨けます。逆に、ここが曖昧なまま画面やプロンプトから作り始めると、「動くけれど使えない」ものが出来上がります。
生成AIの要件定義でやりがちな失敗
- 仕様を言葉で固めきろうとする：「丁寧に」「適切に」で合意した気になり、合格判定ができない。→ 代表ケースと合格ラインで規定する。
- データ確認を後回しにする：作り始めてから「参照できるデータが無い」と判明する。→ 要件段階でデータの在り処と品質を確認する。
- 100%自動化を前提に置く：例外まで全部AIにやらせようとして破綻する。→ 8割をAI、2割の例外は人、と割り切って境界を引く。
- 失敗時を決めない：うまくいくケースだけ想定し、間違えたときの挙動が無い。→ エスカレーションと拒否の挙動を先に決める。
- 要件を一度で凍結する：実際の出力を見る前に確定させ、現実とズレる。→ 成果の判定基準（ゴール）は固定し、実装は反復で磨く。
FDEは要件定義をどう伴走するか
DeploAI の FDE（Forward Deployed Engineer） は、顧客の業務現場に入り込み、成果から逆算して要件を定義するところから伴走します。会議室で仕様書を積み上げるのではなく、実際の業務データと現場の判断を見ながら、「何を・どこまでAIに任せ、どうなれば成功か」を一緒に決めていきます。
- 成果の判定基準を、現場の代表ケースから一緒に作る（机上の理想像で終わらせない）。
- データの在り処と品質を早期に点検し、実現可能性を要件段階で見極める。
- 人の関与ラインと失敗時の挙動を、業務のリスクに合わせて設計する。
- 要件確定を待たず、小さく作って出力を見て、要件と実装を反復的に磨く。
要件定義の前段にあたる業務の見極めはAI導入に業務棚卸しは必要？、投資判断は生成AI導入の社内稟議はどう通す？、内製化の道筋はAI内製化の現実的なロードマップもあわせてご覧ください。
まとめ
- 生成AIの要件定義は、出力が非決定的なため、従来の「仕様を固めてから作る」が噛み合わない。
- 先に固めるのは実装の詳細ではなく、成果の判定基準・データの在り処と品質・人の関与ライン・失敗時の挙動の4つ。
- 正しさは「仕様との一致」ではなく「代表ケースで期待水準を満たす割合」で定義し、ゴールは固定し実装は反復で磨く。
自社の生成AIプロジェクトを「作りたい」で止めず「業務で効く」まで届かせたい場合は、お問い合わせからお気軽にご相談ください。FDE が要件定義から実装・定着まで伴走します。
