AI開発の要件定義とは？精度要件・データ要件・要件定義書の項目を徹底解説

AI開発の要件定義は、通常のシステム開発で決める機能・画面・性能に加えて、AIの精度とデータの扱いまで合意する作業です。特に生成AIのような確率的なAIでは、入力データ・モデル・プロンプト・推論設定などによって出力が変わることがあります。そのため「仕様どおりに動けば合格」という考え方だけでは、開発会社との認識をそろえられません。

いざAI開発を検討すると、「通常のシステム開発と何が違うのか」「精度はどう伝えればよいのか」「相談前にどこまで資料を用意すべきか」といった疑問を感じる方も多いのではないでしょうか。

そこで本記事では、AI開発の要件定義が難しい理由を整理しながら、精度要件・データ要件の決め方、PoCの進め方、よくある失敗、要件定義書のチェックリストまで詳しく解説します。最後までお読みいただくことで、AI開発の相談前に何を決めておけばよいのかが理解できるはずです。

AI開発の要件定義とは

AI開発の要件定義とは、AIモデルの予測・生成結果に一定の不確実性があることを前提に、機能仕様だけでなく精度やデータの要件まで定義する工程です。

一般的な要件定義は、業務上の目的をシステムが満たすべき機能・性能・制約・運用条件に落とし込む作業を指します。IPAの資料では、業務処理の手順やデータ構造、画面・帳票、品質要件、運用・操作要件、SLA、コスト、納期などが成果物の例として整理されています。※1

AI開発では、これらに加えてAI固有の項目を明文化します。主な追加項目は以下のとおりです。

AI特有の要件	定義する内容
入力要件	AIに入力するデータの形式・種類・欠損時の扱い
出力要件	出力形式、回答項目、候補数、根拠の表示有無
精度要件	正解率、再現率、誤検出率、許容できる誤差
評価要件	評価用データ、評価者、評価期間、合格基準
データ要件	データの量・品質・ラベル・更新頻度・所在
人間の関与	AI出力を誰が確認・承認・修正するか
運用要件	監視、ログ、再学習、データ更新、モデル更新
本番化条件	どの水準を満たせば本番へ移行するか
責任分担	発注者・開発会社・サービス提供者の担当範囲

また、混同されやすいのが要求定義・要件定義・RFPの関係。一般的には要求定義は「何を実現したいか」、要件定義は「システムが何を満たすべきか」、RFPは「その実現方法を開発会社に提案してもらうための文書」と整理すると、社内でも説明しやすくなります。

AI開発の要件定義が難しい理由

AI開発の要件定義が難しい理由の一つは、「100%正しく動作する」ことを前提にした仕様定義がそのまま通用しない点にあります。

ルールベースの業務システムでは一般に、入力と処理ルールが決まれば期待する出力を明確に定義できました。一方、機械学習モデルや生成AIの出力は、入力データ、モデル、プロンプト、検索結果、モデル更新などによって変わることがあります。

精度を「100%」とだけ書いてしまうと、実現可能性もコストも判断できません。必要なのは、どの誤りを許容し、どの誤りは絶対に避けるのかという線引きです。

要件定義で押さえるべき要素

本記事では、AI開発の要件定義で押さえる要素を業務課題・利用者・利用シーン・データ要件・精度要件・運用体制の5つに整理します。

要素	決めること
業務課題	どの業務を改善するか、現状の作業時間やコスト、成功を測る業務KPI
利用者・利用シーン	誰がどの業務のどのタイミングで使うか、既存フローのどこに組み込むか
データ要件	どのデータをどこから使うか、量・品質・最新性・権利関係
精度要件	何を正解とするか、評価指標、許容する誤り、本番化に必要な水準
運用体制	データ更新・出力確認・精度低下の検知・継続判断の担当者

この5点は独立しておらず、相互に影響し合う関係です。例えば人による確認を厚くすれば求める精度は下げられますし、データの更新頻度が低ければ運用ルールの設計も変わります。

AI開発の基礎から知りたい方は、下記の記事もあわせてご覧ください。

精度要件の決め方

精度要件は「高いほど良い」と考えるのではなく、業務で許容できる誤り率を先に決めるところから始めます。

同じ正解率でも、誤ったときの業務影響が大きい業務と、人がすぐ修正できる業務では求める水準が変わります。まずはリスクの大きさを確認し、そこから逆算して基準を置く流れが現実的です。

精度要件に含めたい項目は以下のとおりです。

項目	決める内容
対象タスク	分類、予測、抽出、要約、検索、生成など
正解の定義	人の判断、既存データ、専門家評価のいずれを正解とするか
評価データ	どの期間・部署・ケースのデータで評価するか
評価指標	Accuracy、Precision、Recall、F1、MAEなど
許容誤差	誤分類率、誤抽出率、誤回答率の上限
重大エラー	起こしてはいけない誤りの定義
評価者・評価環境	誰が、どの環境で評価するか
再評価条件	データ更新時、モデル更新時、精度低下時の扱い

また、AIの種類によって見るべき精度も変わります。画像分類や物体検出なら見逃しと誤検出のどちらを減らすか、OCRなら金額や日付といった重要項目の誤り率、生成AIやRAGなら根拠資料との整合性や回答不能時の挙動が論点になるでしょう。

「精度」をビジネス指標に落とし込む

技術指標だけでは、導入効果を判断できません。許容誤差率と、誤った場合の業務影響度をセットで定義することが重要です。

例えば正解率が80%でも、全件を人が確認する業務であれば確認時間が短縮され、全体の生産性は向上する可能性があります。逆に正解率95%でも、誤りによる損害が大きければ完全自動化には不十分。

区分	指標の候補
分類タスクの技術指標	Accuracy、Precision、Recall、F1
数値予測の技術指標	MAE、RMSE、MAPE
検索・RAGの評価観点	検索適合率、根拠との一致度、回答の正確性（標準化された指標名ではなく評価観点の例）
共通の技術指標	応答時間、エラー率、稼働率、1件あたりの利用コスト
業務KPI	作業時間の削減、1件あたりの処理時間、差し戻し件数、人による修正回数、担当者の利用率

受入基準を書くときは、「高精度」「実用的」といった曖昧な言葉を避けます。対象・指標・基準値・条件の4要素で書くと、開発会社との認識がそろいます。

AIの出力を確定情報として扱うか、候補として扱うか

求める精度の基準は、人が最終確認するフロー（Human-in-the-Loop）を挟むかどうかで大きく変わります。

Human-in-the-Loopとは、AIの処理に人間の確認・判断・承認を組み込む考え方。医療や人事評価、与信、法務判断、顧客への正式回答のように高いリスクを伴う業務では、AI出力をそのまま確定情報にせず人間の確認を設ける設計を検討すべきといえるでしょう。

出力の扱い	概要	向いているケース
自動確定	AIの出力をそのまま後続処理へ渡す	誤りの影響が小さく、例外処理が容易な業務
候補提示	AIが候補を出し、人が選択・修正する	分類、検索、推薦、下書き作成
自動処理＋例外確認	通常は自動、信頼度が低い場合のみ人が確認	OCR、定型データ処理
AI回答を控える	AIが答えず担当者へ引き渡す	高リスク・根拠不足・機密情報を含む場合

なお、欧州委員会が示すEU AI Actの枠組みでも、高リスクAIについて適切な人間による監督やログ、データ品質、精度などが要求事項として整理されています。※2

ただし、EU AI ActはEU域外の事業者にも適用され得る制度です。EU市場へAIシステムを提供する場合やEU域内で利用される場合など、一定の条件では日本企業も適用対象となるため、自社への適用範囲を確認しておく必要があります。

データ要件の整理

本記事では、データ要件の確認事項を所在・量・品質・権利・準備スケジュールの5つに整理します。「データはあります」という回答だけでは、開発に使えるかどうかを判断できません。

確認区分	確認項目	確認内容
所在	保存場所・取得方法	ファイルサーバー、クラウド、SaaS、基幹システム、個人PCのどこにあるか。API・CSV・手動アップロードのいずれで渡せるか
量	データ量・更新頻度	ファイル数、レコード数、対象期間、リアルタイム／日次／月次の更新頻度
品質	欠損・重複・ラベル・代表性	表記ゆれや誤記の有無、正解ラベルの有無、本番データをどの程度代表しているか
権利	所有権・利用許諾・機密性	個人情報や営業秘密の有無、第三者提供の可否、学習利用の可否
準備スケジュール	準備担当・準備期限	誰がいつまでに用意するか、PoC開始時と本番開始時で何が変わるか

さらに、採用するAIの方式によっても必要なデータは変わります。RAGなら文書の所在・分割単位・メタデータ・アクセス権、画像認識なら撮影条件やラベル、予測モデルなら時系列データと説明変数が中心になるでしょう。

データの所在・品質・取得方法を合意する

まず必要なのは、どのデータが、どこに、どの状態で存在するかの棚卸しです。

最低限、以下を確認しておくと、開発会社との初回打ち合わせがスムーズに進みます。

• データがどこにあり、誰がアクセスできるか
• どの形式で保存され、何件・何年分あるか
• 欠損や重複、古い情報の混在がないか
• 正解データやラベルが用意されているか
• 本番で発生するデータと同じ性質か
• 開発会社へ提供できる状態か

これらをデータ台帳の形でまとめておくと、後工程での認識ずれを防げます。台帳にはデータ名、保存場所、形式、量、更新頻度、品質課題、権限、担当者を並べておくと実用的。

データの権利・セキュリティの取り扱いを明記する

個人情報や機密情報が含まれる場合は、取り扱いルールと役割分担を要件定義書に書き切る必要があります。

個人情報保護委員会は、生成AIサービスへの個人情報の入力について注意喚起を行っています。サービス提供者が入力情報を学習に利用するか、利用目的や安全管理措置がどうなっているかは、導入前に確認しておきたいポイントです。※3

また経済産業省は、AIの利用・開発に関する契約チェックリストを公表しています。提供するデータの利用範囲、AI生成物の利用条件、データの予期せぬ利用や第三者提供などを契約時に確認する重要性が示されました。※4

確認領域	要件定義書に記載する項目
個人情報	利用目的、委託先への提供可否、匿名化の要否、安全管理措置
機密情報	外部APIへの送信範囲、ログ保存の可否、開発終了後の削除方法、再委託の可否
知的財産権	学習・検索対象の文書を利用できる権利、AI生成物の利用範囲、成果物の権利帰属
体制	セキュリティ責任者、個人情報保護責任者、漏えい時の報告手順

役割分担も同じタイミングで決めておきたいところ。

弊社に寄せられる相談でも、AIが参照・学習するデータの準備や提供を発注者側が担い、開発会社は実装に専念するという役割分担を要件定義の段階で明記しているケースは、プロジェクトがスムーズに進む傾向が見られます。

AIと著作権の関係について、詳しく知りたい方は下記の記事をご覧ください。

利用者・利用シーンと運用体制の定義

誰が、どんな場面で使うかを決めると、画面設計や権限設計、運用ルールが自然に定まります。

AI単体の機能ではなく、前後の業務を含めた流れで考えることがポイント。データを入力し、AIが処理し、結果と根拠を表示し、人が確認・修正し、業務システムへ登録して、履歴を改善に活用する、という一連の設計です。

利用者・権限設計

利用者の役割によって、見せる情報と操作できる範囲は変わります。

利用者	主な操作
一般利用者	AIへの入力、結果の閲覧
業務担当者	AI出力の確認・修正・確定
管理者	利用状況の確認、ログ管理、ユーザー管理
データ管理者	参照データの追加・更新・削除
評価担当者	正解データの作成、精度評価
監査担当者	ログ・履歴・権限の確認

例えば問い合わせ対応のAIであれば、一般社員は自部門のFAQしか参照できず、CS責任者は全社の履歴とログを閲覧できる、といった設計になります。プロンプトや設定の変更、ログの削除を誰に許可するかも決めておきましょう。

ただし、RAGやAIエージェントでは注意が必要です。AIが参照するデータの権限と、利用者本人の権限が一致していないと、権限のない情報がAIの回答に含まれる可能性があります。

運用ルール・本番化の条件

リリース後に効果を維持するうえでは、誰がAIの出力を監視し、精度が落ちたときにどう対応するかを事前に決めておくことが重要です。

運用体制で決めておきたいのは、AI出力の品質確認者、データ更新担当者、プロンプトや設定の管理者、精度低下の検知方法、誤回答や苦情への対応者、利用停止の判断者です。あわせて定期評価の頻度とログの保存期間も定めます。

観点	本番化条件の例
技術面	精度、応答時間、稼働率、エラー率、外部API障害時の代替処理
業務面	作業時間の削減、修正時間、利用率、現場担当者の受容性
リスク面	個人情報・機密情報の管理、人間確認の設計、ログと監査、事故時の停止手順
経営面	本番運用費、追加開発費、人員配置、継続判断の基準

生成AI導入の進め方について、詳しく知りたい方は下記の記事もあわせてご覧ください。

PoCから本番運用までの進め方

不確実性が高い案件では、いきなり本開発の要件を確定させるのではなく、PoCなどの小規模な検証を挟んで段階的に進める方法がよく用いられます。

WEELではAI開発を、構想フェーズ・PoCフェーズ・実装フェーズ・運用フェーズの4段階で整理しています。本記事ではこの4段階をベースに、本番移行を独立させた5段階で各フェーズの決めごとと成果物を見ていきます。

フェーズ	決めること	主な成果物
構想	業務課題、対象業務、期待効果、対象利用者	構想書、課題整理表
PoC	検証仮説、評価データ、評価指標、期間、成功条件	PoC計画書、評価結果
実装	システム構成、UI、連携、権限、セキュリティ	要件定義書、設計書
本番移行	運用、監視、教育、障害対応、契約	移行計画、運用設計書
運用	精度監視、データ更新、改善、再評価	運用報告、改善計画

PoCから本番へ進む判断では、以下の条件がそろっているかを確認します。

1. 設定した評価指標を満たしている
2. 重大な誤りが許容範囲内に収まっている
3. 対象データを継続的に提供できる見通しがある
4. 現場の確認・承認フローが定まっている
5. セキュリティ・法務確認が完了している
6. 運用責任者と本番費用が決まっている

なお、IPAのDX調査では、PoCを繰り返すなど一定の投資は行われるものの、実際のビジネス変革にはつながっていない企業が多いと報告されました。AIに限らずDX全般の傾向を示した調査ですが、PoCの成功だけで終わらせず、業務・組織・運用まで含めて本番化を設計する重要性を裏づけています。※5

PoCの進め方について、詳しく知りたい方は下記の記事をご覧ください。

AI開発の要件定義でよくある失敗

要件定義でつまずくポイントは、ある程度パターン化できます。特に抜け落ちやすいのが、精度要件とデータ要件の2つです。

弊社への問い合わせでも、作りたい機能ははっきりしている一方で、精度要件やデータ要件の記載が曖昧なまま相談に来るケースや、要件定義そのものの支援を求めて相談に来るケースが多く見られます。

この2点は特に抜け落ちやすい失敗ポイントといえるでしょう。ここからは、要件定義でつまずきやすい代表的なパターンを見ていきます。

AI導入そのものが目的になっている

業務課題やKPIが曖昧なまま「AIを入れること」が目的化すると、評価軸が定まりません。

先に業務課題を定義し、AIを使わない代替案と比較したうえで、効果を測るKPIを設定します。対象業務を絞ってPoCで検証する進め方が現実的です。

「精度を高く」としか書いていない

何を正解とするかが決まっていないと、評価方法も本番化条件も判断できません。開発会社の見積もりもぶれてしまいます。

指標・許容誤差・重大な誤り・人間の確認範囲・評価用データの5点を書き添えるだけで、精度要件は一気に具体化します。

書き方	記載例	何が問題か／何が良いか
避けたい書き方	画像認識の精度は99%以上であること	何を正解とするか、見逃しと誤検知のどちらを重視するかが不明で、合否を判定できない
望ましい書き方	見逃し率1%以下、誤検知率5%以下。達成時に検品工数30%削減を想定	誤りの種類ごとに基準を分け、業務効果とセットで示しているため、評価も投資判断もできる

PoCと本番の差を考慮していない

PoCで少量データしか使っていない、本番の利用者や権限を再現していない、APIコストや同時利用数を確認していないといったケースは要注意。

加えて、通常のシステム開発と同じ「要件定義→設計→実装→テスト→リリース」の流れで計画してしまい、AI開発で挟まる検証工程を織り込めていないケースもあります。PoCは成功して当然のものではないため、撤退条件も事前に決めておきましょう。

PoC段階から可能な限り本番に近い条件で評価し、運用担当者もこの時点で決めておくと、本番移行の判断が早くなります。

AI導入でつまずきやすい課題について、詳しく知りたい方は下記の記事をご覧ください。

要件定義書に盛り込むべき項目チェックリスト

最後に、開発会社に相談する前に埋めておきたい項目を、本記事なりのチェックリストとしてまとめます。

区分	チェック項目
1. 業務課題	背景、解決したい課題、対象業務、期待効果、対象外とする範囲
2. 利用者・業務フロー	利用者と利用部署、利用シーン、現行フローとTo-Beフロー、人による確認工程
3. 機能・AI要件	AIの入力と出力、画面、承認・修正・履歴、AIの方式、回答拒否条件、根拠表示
4. データ要件	データ一覧、保存場所、形式、量、更新頻度、品質、正解データ、準備担当、削除方法
5. 精度・評価要件	正解の定義、評価指標、評価データ、評価者、合格基準、許容誤差、重大エラー、本番化条件
6. 非機能要件	可用性、応答時間、同時利用数、拡張性、ログ、障害対応、外部API障害時の動作、AI利用コスト
7. セキュリティ・法務	個人情報、営業秘密、著作権、入力禁止情報、学習利用の可否、再委託、インシデント対応
8. 運用要件	運用責任者、データ更新担当、精度監視担当、誤回答の報告ルール、定期評価、保守契約
9. スケジュール・費用	要件定義期間、データ準備期間、PoC期間、開発期間、初期費用、運用費、保守費

非機能要件については、IPAの「非機能要求グレード」も参考になります。発注者と開発者の認識の行き違いを防ぐため、非機能要求を一覧化して段階的に確認するツールです。※6

このチェックリストを埋めておくと、対象業務・データ・連携範囲・評価方法が明確になり、開発会社との見積もり条件をそろえやすくなります。

AI開発の見積もりの考え方について、詳しく知りたい方は下記の記事をご覧ください。

AI開発の要件定義のよくある質問

ここではAI開発の要件定義のよくある質問について回答していきます。AI開発を検討している場合には、ぜひ参考にしてみてください。

AI開発の要件定義を固めてスムーズなAI導入を実現しよう

AI開発の要件定義は、通常のシステム開発で決める機能・画面・性能に、精度要件とデータ要件を上乗せする作業です。AIモデルの予測・生成結果には一定の不確実性があるため、どの誤りを許容し、誰が確認し、どのデータを誰が用意するのかまで書き切る必要があります。

単にAIの性能を保証するための文書ではなく、AIを業務のどこに組み込み、どこから人が判断するのかを決めるための文書といえるでしょう。精度を技術指標と業務KPIの両面で定義し、PoCの成功条件と本番化条件を分けて考えることが、判断のぶれを防ぎます。

今後はAIを前提とした業務設計がさらに進み、要件定義の段階で運用や改善体制まで織り込むことが当たり前になっていくのではないでしょうか。発注者と開発会社の役割を早い段階で合意しておくことは、本番移行時の認識ずれを減らすうえで有効です。

ぜひ皆さんも本記事を参考にAI開発の要件定義を進めてみてください！

最後に

AI開発の要件定義を固めることで、精度やデータの前提がそろい、見積もりと開発の手戻りを大きく減らせます。一方で、精度要件の置き方やデータの準備範囲は設計次第で効果が大きく変わるため、業務課題と利用データの整理から専門家に相談することも重要な選択肢です。