AI開発のプロジェクトで、要件定義書を開くと「問い合わせにAIが自動で回答する」とだけ書いてあることがある。普通のシステムなら、ここから画面や項目を詰めていけば済む。AIではそうはいかない。どの問い合わせに、どの程度の正しさで答えれば合格なのか。間違えたら誰が気づき、どう戻すのか。そこが決まっていないと、作ったものが使えるかどうかを誰も判定できない。
ここでは、AI開発の要件定義が普通のシステム開発と何が違うのかを整理し、PoCの前に決めること、AI要件定義書に書く項目を表にした。対象は主に、生成AI（大規模言語モデル）を業務システムに組み込む開発だ。
AIの要件定義が普通のシステム開発と違うところ
違いは大きく3つある。
1つめは、出力が毎回同じとは限らないことだ。普通のシステムは、同じ入力に同じ出力を返す。だから要件は「この条件ならこう動く」と書ける。生成AIは、同じ質問にも言い回しの違う答えを返し、ときどき間違える。要件は「ある割合で合格ラインを超える」という形でしか書けない。
2つめは、作ってみるまで実現できるか分からないことだ。産業技術総合研究所の「生成AI品質マネジメントガイドライン第1版」（2025年5月公開）は、要求を整理する段階で、期待する機能が実現可能かを確認する必要があると書いている。その確認には、主にプロンプトの試行錯誤による試作（プロトタイピング）を使い、これを要求獲得・形式化の一部とみなせるとしている。試作で実現できると確かめた要求を、あとは普通のV字型の開発で作る、という流れだ。
同じガイドラインは、ソフトウェア工学の考え方として、「要求」はステークホルダーの期待を表し、「要求仕様」は実現可能な要求の仕様表現だと区別している。AIの要件定義が難しいのは、この「期待」と「実現できる仕様」の差が、試してみるまで見えないからだ。
3つめは、データと権限が要件の一部になることだ。同じガイドラインは、大規模言語モデルの課題として、最新のデータを扱えないこと（データ最新性）と、社内情報など利用側のデータを持たないこと（組織内データ）を挙げている。社内文書に答えるAIなら、どの文書を読ませ、誰にどの文書まで見せるかを決めないと、機能そのものが決まらない。
| 観点 | 普通のシステム開発 | AI開発 |
|---|---|---|
| 要件の書き方 | 条件と動作を決める | 評価データと合格ラインで決める |
| 実現できるか | 設計の段階でほぼ分かる | 試作で確かめるまで分からない |
| データ | 入力と保存の項目 | 何を読ませ、誰に何を見せるかが機能を決める |
| 間違い | 不具合として直す | 一定の割合で起きる前提で、気づき方と戻し方を決める |
| 変化 | 改修の依頼で変わる | モデルの更新やデータの変化で、何もしなくても変わる |
この表は私の整理だ。最後の行は見落とされやすい。モデルの提供者が版を更新すれば、同じプロンプトでも答えは変わる。要件定義の段階で、変化に気づく仕組みまで決めておく必要がある。
PoCの前に決める7つのこと
私の見方では、PoCを始める前に、少なくとも次の7つを決めておくべきだ。全部を細かく決める必要はないが、空欄のまま始めると、PoCが終わったときに判定ができない。
1. 動かしたい業務の数字
「AIを使うこと」は目的にならない。問い合わせの一次回答の時間を短くしたいのか、担当者1人あたりの処理件数を増やしたいのか。動かしたい数字を1つ決め、今の値を測っておく。数字から逆算する考え方はKPI設計から始めるAI導入にまとめた。
2. AIに任せることと、人が判断すること
AIが下書きを作り人が確かめて出すのか、AIがそのまま顧客に返すのか。この線で、求める正しさも、作るべき確認の仕組みもまるで変わる。最初は人が確かめる形で始め、評価の結果を見て任せる範囲を広げるほうが安全だ、と私は考える。
3. 入力するデータと、見せてよい範囲
どのデータを入力に使うか。そのデータを、誰にどこまで見せてよいか。社内文書を検索して答えるなら、文書ごとの閲覧権限を検索の段階で守る必要がある。ここはRAG構築の進め方で詳しく書いた。
4. 出力の合格ラインと、評価データ
いちばん大事なのがこれだ。実際の業務から問いと正しい答えの組を集め、評価データにする。そのうえで「この評価データで何割が合格なら本番に出す」と決める。合格の判定のしかた（人が採点するのか、自動で照合するのか）もここで決める。
5. 間違えたときの影響と、戻し方
AIは一定の割合で間違える。間違いが顧客に届いたときの影響の大きさで、確認の仕組みの重さが決まる。誰が間違いに気づき、どう訂正し、どう記録するかを決めておく。間違いを減らす設計はハルシネーション対策に書いた。
6. 応答時間と費用の上限
生成AIの費用は、使う量とモデルの大きさで変わる。1件あたりいくらまでなら業務として成り立つか、利用者が何秒まで待てるかを決める。これがないと、精度を上げるためにより大きなモデルを使い、費用が合わなくなる。
7. 運用の持ち主と、見直しの周期
本番に出したあと、誰が評価を回し、誰がプロンプトやデータを直すのか。何か月ごとに合格ラインを見直すのか。持ち主が決まっていないAIは、出した日から少しずつ使われなくなる。
AI要件定義書に書く項目
7つを文書にすると、AI要件定義書は次のような項目になる。普通の要件定義書にある画面・帳票・外部連携の項目は、この後ろに続ければよい。
| 項目 | 書くこと | 決める人 |
|---|---|---|
| 目的とKPI | 動かしたい数字、今の値、目標の値、測り方 | 業務の責任者 |
| 対象業務と範囲 | 対象にする業務と、対象にしない業務 | 業務の責任者 |
| AIと人の役割 | AIに任せること、人が確かめること、人が判断すること | 業務の責任者とエンジニア |
| 入力データと権限 | 使うデータ、更新の頻度、利用者ごとに見せてよい範囲 | 業務の責任者と情報システム部門 |
| 合格ラインと評価データ | 評価データの作り方と件数、合格の判定方法、本番に出す基準 | 業務の責任者とエンジニア |
| 間違えたときの扱い | 影響の大きさ、気づく仕組み、訂正と記録の手順 | 業務の責任者 |
| 非機能の上限 | 応答時間、1件あたりの費用、利用の上限、使ってよいモデルの条件 | エンジニア |
| 運用 | 運用の担当、評価を回す周期、見直しの条件 | 業務の責任者とエンジニア |
表は私の整理だ。項目は多く見えるが、PoCの前に全部を埋める必要はない。私の見方では、PoCの前に最初に埋めるのは「目的とKPI」「AIと人の役割」「合格ラインと評価データ」の3つで、残りはPoCの結果を見て書き足していけばよい。
品質の観点を漏れなく見たいときは、国際標準も参考になる。先のガイドラインは、AIシステムの技術的な特徴を考慮した品質モデルとして、ISO/IEC 25059:2023を紹介している。要件定義書の非機能の項目を考えるときの物差しとして使える。
要件定義からPoC、本番までの進め方
要件定義とPoCの関係を誤解すると、プロジェクトは止まる。Gartnerは2024年7月に、生成AIプロジェクトの少なくとも30%が2025年末までに概念実証の後で中止されると予測し、理由の1つにビジネス価値の不明確さを挙げた。私の見方では、価値が不明確になる原因の多くは、PoCの前に合格ラインを決めていないことにある。
進め方は次の順になる。
| 段階 | すること | 終わりの判定 |
|---|---|---|
| 要求の整理 | 7つのことを決め、評価データを集める | 合格ラインと評価データがそろった |
| 試作（PoC） | 小さく作り、評価データで測る | 合格ラインを超えたか、超えないなら何が足りないかが分かった |
| 要件定義書 | 試作で実現できると分かった要求を、仕様として書く | 業務の責任者とエンジニアが合意した |
| 開発 | 権限、記録、確認の仕組みを含めて作る | 評価データで合格ラインを超え、運用の手順がそろった |
| 運用 | 評価を回し、変化に気づいたら直す | 見直しの周期ごとに判定する |
試作の段階で合格ラインに届かないことは、失敗ではない。何が足りないか（データか、AIに任せる範囲か、合格ラインそのものか）が分かれば、要件を直して次に進める。PoCから先に進めない理由の整理はAIのPoC止まりを抜け出すに書いた。運用に入ってから評価を回し続ける仕組みはLLMOpsとはで説明している。
要件定義は、発注する側だけで書くものでも、作る側に丸投げするものでもない。業務の数字を持つ人と、データと権限と費用から実現できる範囲を示せる人が、同じ机で書くものだ。そうした役割を担う職種がFDE（Forward Deployed Engineer）で、業務の現場に入って要件から本番の運用までを受け持つ。私たちの支援の中身はサービス詳細に書いた。