AIプロジェクトの要件定義ガイド【発注者向け】テンプレート・チェックリスト付き

AI開発を会社から任されたものの、「要件定義書を用意してください」と言われた途端に手が止まってしまった経験はないでしょうか。

Webシステムの発注経験はあっても、AIプロジェクトの要件定義となると話は別です。「精度はどう書けばいいのか」「学習データって何を用意するのか」「倫理的な配慮って具体的に何をすればいいのか」——通常のシステム開発では問われなかった項目が次々と出てきて、途方に暮れてしまうのは当然です。

実は、AI開発の要件定義は通常のシステム開発とは本質的に異なります。同じフォーマットで進めると、開発会社との認識のズレが生じたり、PoC（概念実証）で「想定していた精度が出なかった」という事態に陥ったりするリスクがあります。

本記事では、AI開発の発注経験がない方でも理解できるよう、AI特有の要件定義ポイントを5つに絞って解説します。記事後半にはそのまま使えるテンプレートと発注者向けチェックリストも用意しましたので、ぜひご活用ください。

秋霜堂株式会社は、システム開発の構想段階から発注者に伴走する経験を積んできました。その経験から「要件定義の段階で詰めておくべきだった」という失敗パターンを多く目の当たりにしてきました。本記事の内容を参考に、AI開発を成功に導く要件定義を進めていただければと思います。

AI開発の要件定義が通常のシステム開発と異なる理由

通常のシステム開発との本質的な違い

通常のシステム開発では、「このボタンを押したらこの画面に遷移する」「この条件を満たしたらこの処理を実行する」というように、入力と出力の関係を明確に定義できます。要件を満たしているかどうかは、テストで確認できます。

しかし、AIシステムはこれとは根本的に異なります。AIは「確率的に動作する」——つまり、同じ入力を与えても必ずしも同じ出力が返ってくるわけではありません。また、「100%の精度を保証する」こと自体が原理的に困難です。

この違いを理解しておかないと、要件定義の段階で「精度は99%以上で」「エラーは絶対に起きないように」と書いてしまい、開発会社から「それは実現できません」と言われる事態が起きます。

AIと通常のシステム開発の違いを整理すると、以下のようになります。

比較軸	通常のシステム開発	AI（機械学習）開発
動作の確実性	条件を満たせば100%同じ出力	確率的動作（同一入力でも出力が変わりうる）
精度の保証	テストで合否判定が可能	「精度X%以上」という目標値として設定
品質の基準	バグがないこと	ビジネス目標に対して精度・再現率が十分であること
データへの依存度	データは任意（設計次第）	学習データが成果を大きく左右する
リリース後の変化	機能追加がなければ動作は変わらない	継続学習で動作が変化する可能性がある

SCROLL→

AI開発が失敗しやすい3つの理由

AI開発プロジェクトが要件定義の段階で躓きやすい理由は主に3つあります。

理由1: 「精度」の定義があいまいなまま開発が始まる

「精度は高ければ高いほどいい」という認識で発注し、開発会社も具体的な数値目標を設定しないまま開発を進めてしまうケースです。PoC終了後に「思ったより精度が出なかった」という結果になり、そもそも「何%なら合格なのか」という基準を決めていなかったため、プロジェクトの継続・中止の判断ができなくなります。

理由2: 学習データの準備が後手に回る

AIの品質はデータで決まります。要件定義の段階でデータ取得の方針を決めていなかったため、開発開始後に「社内にデータがない」「外部データを購入する必要があるが予算がない」という事態が発生します。

理由3: PoC前提の開発フローを知らない

通常のシステム開発は「要件定義→設計→実装→テスト→リリース」という直線的なフローで進みます。しかし、AI開発では「PoC（概念実証）→精度検証→本格開発」という段階的なフローが一般的です。この違いを知らずに通常のシステム開発と同じスケジュールや予算感で発注してしまうと、後になって計画の大幅な見直しが必要になります。

AI要件定義で押さえるべき5つのポイント

ポイント1: 精度要件は「許容誤差率」とビジネス指標で定義する

最もよくある失敗が、精度要件を「99%以上」「限りなく100%に近いこと」のように書いてしまうことです。AIの精度は用途によって評価指標が異なりますし、100%に近づけようとすると開発コストが指数関数的に増大します。

発注者に求められるのは、「この用途で、どの程度の誤りまでなら業務が成立するか」を定義することです。

NGな書き方の例

「画像認識の精度は99%以上であること」

OKな書き方の例

「商品の傷検知において、見逃し率（実際に傷があるのに見逃す確率）が1%以下、誤検知率（傷がないのに傷と判定する確率）が5%以下であること。この条件を満たした場合、現在の人手による検品工数が30%削減できると想定する」

ポイントは「ビジネス目標とセットで定義する」ことです。精度の数値だけでなく、その精度が達成されたときにどのような業務改善が実現するかを記載することで、開発会社も何を最優先で最適化すべきかが明確になります。

精度指標の主な種類（参考）

指標名	意味	向いている用途
正解率（Accuracy）	全体に対して正しく分類した割合	データに偏りがない分類タスク
適合率（Precision）	AIが「正」と予測したうちの正解割合	誤検知コストが高い場合（例: スパムフィルター）
再現率（Recall）	実際の「正」のうちAIが検知できた割合	見逃しコストが高い場合（例: 医療診断）
F1スコア	適合率と再現率の調和平均	両方バランスよく評価したい場合

SCROLL→

どの指標を使うかは開発会社と相談のうえ決定してください。要件定義書には「どの指標で何%以上を達成すること」と明記します。

ポイント2: 学習データの品質・量・取得方法を合意する

「データはAIの燃料」と言われるほど、学習データの品質と量は成果を左右します。しかし、要件定義の段階でデータについて詳細を詰めておかないと、開発フェーズに入ってから「実は使えるデータがない」という致命的な問題が発覚します。

要件定義書に記載すべきデータ関連の項目は以下の通りです。

データの種類と量

• 学習に使用するデータの種類（画像・テキスト・数値データなど）
• 必要なデータ件数の見込み（開発会社と相談して決定）
• データのラベル（正解データ）付けは誰が、どのような基準で行うか

データの入手方法

• 社内に既存データがあるか（量・品質・形式）
• 社外からデータを調達する場合、購入元・コスト・利用規約
• データ収集を新たに開始する場合のスケジュールと担当者

データの品質基準

• 欠損値・ノイズ・重複データの許容範囲
• データの鮮度（いつ収集したデータまで使用可能か）
• 個人情報が含まれる場合の匿名化・仮名化の方針

社内にデータがない場合は、PoC前にデータ収集フェーズを設けることも検討してください。「データを集めながら開発する」という方針は現実的ではなく、PoCの精度に直接影響します。

ポイント3: PoC→本番の段階的開発フローを前提にする

AI開発のプロジェクト計画は、通常のシステム開発のような「要件定義→実装→テスト→リリース」という一直線のフローでは進みません。経済産業省の「AI・データの利用に関する契約ガイドライン」でも、AI開発は①アセスメント、②PoC、③開発、④追加学習の段階的なフローを推奨しています。

PoCとは何か

PoC（Proof of Concept：概念実証）とは、AI開発を本格的に始める前に「本当にAIが機能するか」を小規模で検証するフェーズです。実際のデータを使って精度目標に到達できるかを検証し、プロジェクトの実現可能性を判断します。

PoCに入る前に、以下の事項を要件定義書に明記することが重要です。

• PoCの成功/失敗を判定する基準（精度が何%以上なら本格開発に進む、など）
• PoCの期間と予算上限
• PoCが失敗した場合の撤退条件と対応方針

「PoCは成功して当然」と考えてしまいがちですが、実際のデータを試した結果「想定した精度が出ない」という場合はあります。事前に撤退条件を決めておくことで、投資の拡大を防ぐことができます。

本番移行フェーズの要件

PoCが成功した後の本格開発フェーズでは、PoC版の「動くか確認する」から「ビジネスで実際に使える」レベルへの作り直しが必要になります。要件定義書には本番システムの要件として以下を記載します。

• 処理速度・スループットの要件（何件を何秒以内に処理するか）
• 同時アクセス数・可用性要件
• エラー時のフォールバック処理（AIが判断できない場合の業務フロー）
• 段階的な本番移行計画（1部門から試験運用し全社展開へ）

ポイント4: 倫理的配慮（バイアス・公平性・プライバシー）を明文化する

AI開発において倫理的配慮は、単なる建前ではなく実務上のリスク管理です。2024年4月に公開された日本政府の「AI事業者ガイドライン（第1.0版）」でも、公平性・透明性・説明責任がAI開発の基本原則として明記されています（経済産業省）。

要件定義書に記載すべき倫理関連の項目は以下の3つです。

バイアスへの対応

AIは学習データに含まれる偏りをそのまま学習します。たとえば、採用選考AIを過去の採用データで学習させると、過去の採用パターン（特定の学校・性別が多い、など）を引き継いでしまう可能性があります。

要件定義書では「AIの判断に特定属性（性別・年齢・国籍など）が影響を与えないように設計すること」と明記し、バイアス検証のテスト項目を含めることを検討してください。

プライバシー保護

AIの学習に個人情報を使用する場合、個人情報保護法への対応が必要です。要件定義書には以下を記載します。

• 学習データに含まれる個人情報の種類と匿名化方針
• 本番運用で処理する個人情報の保存・削除方針
• 第三者へのデータ提供の有無とその条件

判断の説明可能性

AIがどのような根拠で判断したかを説明できるか（説明可能AI・XAI）は、利用者や規制当局への説明責任に関わります。特に金融・医療・採用など高リスク領域では、「なぜそのような判断をしたか」を説明できることを要件として明記することを推奨します。

ポイント5: 運用後の継続学習・モデル更新の要件を定義する

通常のシステム開発はリリースで完成しますが、AIシステムは「リリースしてから育てる」という継続的な運用が前提です。この点を要件定義の段階で合意しておかないと、本番運用が始まった後に「精度が落ちてきた」「世の中の変化に対応できていない」という問題が発生しても、誰が何をする責任があるのかが曖昧になります。

要件定義書に記載すべき運用関連の項目は以下の通りです。

モデルのモニタリング

• 精度の監視指標と監視頻度（月次・週次など）
• 精度が閾値を下回った場合のアラート基準と対応フロー

再学習・モデル更新の方針

• 再学習のトリガー条件（精度低下・データ変化・一定期間経過など）
• 再学習に使うデータの収集フロー（本番データのフィードバック方法）
• モデルバージョン管理と更新時の承認プロセス

運用体制

• AIシステムのモニタリング担当者（社内担当者 or 開発会社に委託）
• 問題発生時のエスカレーションフロー
• 年次での精度レビューと改善計画の策定サイクル

継続的な改善コストも初期費用と合わせて計画に含めてください。「初期開発費用だけ払えばあとは自動で動く」という認識は、AI開発では通用しません。

AI要件定義書のテンプレートと記載例

テンプレートの全体構成

以下の6章構成を基本とした要件定義書テンプレートを紹介します。プロジェクトの性質に応じて項目を追加・削除してください。

各章の記載例

第1章：ビジネス要件（記載例）

第2章：精度要件（記載例）

第3章：データ要件（記載例）

第4章：開発フェーズ計画（記載例）

第5章：倫理要件（記載例）

第6章：運用要件（記載例）

開発会社に伝えるべき情報チェックリスト

最低限伝えるべき10項目のチェックリスト

開発会社への初回相談・RFP送付前に、以下の10項目を用意しておくと、精度の高い提案書と見積もりを受け取りやすくなります。

#	項目	確認内容
1	解決したい業務課題	何を効率化・自動化したいか。現状の課題を具体的に記述できるか
2	成功の定義	プロジェクトが成功したとみなす基準（精度・工数削減率・コスト削減額など）
3	AI化する業務のインプット・アウトプット	何を入力にして、何を出力として欲しいか
4	既存データの保有状況	種類・件数・形式・収集期間。データがない場合の収集計画
5	本番環境の要件	処理速度・同時アクセス数・利用デバイス（スマートフォン・PC・工場端末など）
6	予算規模と希望スケジュール	PoC・本格開発のそれぞれの予算上限と希望時期
7	社内の推進体制	プロジェクトオーナー・担当者・開発会社との窓口
8	倫理・コンプライアンス要件	個人情報の取り扱い・業界規制・自社のデータポリシー
9	既存システムとの連携要件	連携が必要なシステム・API・データベースの一覧
10	運用保守の希望	開発会社に継続して保守委託するか、社内で内製化するか

SCROLL→

精度の高い提案を受けるための追加質問

上記10項目を揃えた上で、開発会社への相談時に以下の質問を投げかけると、提案の質が上がります。

精度に関する質問

• 「今回のデータ量と課題内容で、PoC段階でどの程度の精度が期待できますか？」
• 「精度改善に最も重要なのは何でしょうか（データ量・データ品質・モデルアーキテクチャなど）？」

開発フローに関する質問

• 「PoC成功の判断基準を一緒に決めていただけますか？」
• 「PoC期間中、進捗と精度はどのように報告してもらえますか？」

コストに関する質問

• 「初期開発費用のほかに、継続的な保守・再学習費用はどの程度かかりますか？」
• 「データのラベル付けや収集のサポートはしていただけますか？追加費用はかかりますか？」

リスクに関する質問

• 「このプロジェクトで最も失敗リスクが高い要因は何だと思いますか？」
• 「PoCが失敗した場合、どのような対応をしていただけますか？」

まとめ — AI要件定義セルフチェックリスト（発注者向け）

最後に、本記事の内容を自己確認できるチェックリストをまとめます。開発会社への提案依頼前にご活用ください。

精度要件

• 「精度は高ければ高いほどいい」ではなく、ビジネス目標とセットで精度目標を定義している
• 用途に応じた精度指標（適合率・再現率など）を選定している
• PoC合格基準・本番合格基準を数値で定義している

データ要件

• 学習データの種類・量・保有状況を把握している
• データがない場合、収集フェーズの計画と予算を確保している
• ラベル付けの基準と担当者を決定している
• 個人情報が含まれる場合、匿名化方針を決定している

開発フェーズ計画

• PoCフェーズを前提とした計画になっている
• PoCの成功基準・撤退条件を明記している
• Phase 1（PoC）とPhase 2（本格開発）の予算を分けて確保している

倫理要件

• 学習データのバイアスリスクを検討している
• 個人情報の取り扱い方針を決定している
• 判断の説明可能性（どのような根拠で判断したかを説明できるか）を要件として検討している

運用要件

• 精度のモニタリング頻度と担当者を決定している
• 再学習・モデル更新のトリガー条件を定義している
• 継続運用のコストを予算計画に含めている

AI要件定義で最も重要なのは「通常のシステム開発とは違う」という前提を持ち、AI特有の項目を意識的に詰めておくことです。特に精度要件・データ要件・PoC前提のフェーズ設計の3点は、後から修正するコストが大きくなるため、発注前の段階でしっかりと議論することをおすすめします。