※2026.06.29 改訂：意思決定者に向けて内容を見直しました。
AIプロジェクトの失敗は、技術的な問題よりも要件定義の不備から生じることがほとんどです。「何を作るか」「何をもって成功とするか」が曖昧なまま開発を始めると、途中で方向性がずれ、手戻りが発生し、やがてプロジェクトは炎上します。要件定義はプロジェクトマネージャーや担当者の作業に見えますが、炎上を防ぐ要諦は経営者がどこで関与し、何を承認するかにあります。目的・成功基準・投資判断は経営マターであり、ここを担当者任せにしたまま進めると、後戻りできない段階で齟齬が露呈します。本記事では、炎上前に経営者が押さえるべきポイントを軸に、要件定義の進め方を解説します。
AIプロジェクトが炎上する原因
AIプロジェクトが炎上すると、つい「技術が難しかった」「AIの性能が足りなかった」と原因を技術に求めがちです。しかし、実際の原因の多くは、その手前の要件定義にあります。
「何を作るのか」「どんな状態になれば成功なのか」が曖昧なまま開発を始めると、関係者の認識がずれたまま進みます。そして開発が進んでから「思っていたものと違う」と発覚し、大きな手戻りが生じます。炎上は、技術の前に、要件の曖昧さから始まるのです。そして「何を成功とするか」は、本来経営が定めるべき論点です。経営が成功基準を承認しないまま現場が走り出すと、後から経営の期待と成果物がずれ、それが炎上の火種になります。
AI特有の要件を明確にする
AIプロジェクトでは、通常のシステム開発の要件定義に加えて、AI特有の要件を明確にする必要があります。次の4つは必ず定義しましょう。
- ① 精度要件：どの程度の精度（例：正解率90%以上）を求めるか。
- ② データ要件：学習・検証に使うデータの量・質・形式。
- ③ 性能要件：レスポンスタイムや処理能力。
- ④ 運用要件：モデルの再学習頻度、精度劣化時の対応フロー。
これらが曖昧だと、「精度が思ったほど出ない」「運用方法が決まっていない」といった問題が後から噴出します。AIならではの要件を、最初に詰めておくことが重要です。
「精度要件」は現実的に設定する
4つの中でも、トラブルの種になりやすいのが精度要件です。「正解率100%」のような非現実的な目標を掲げると、達成できずにプロジェクトが失敗とみなされてしまいます。AIは確率的に判断するため、100%の精度はありえません。
大切なのは、「どの程度の精度があれば業務で使えるか」という現実的な基準を定めることです。たとえば「人間の作業を完全に置き換える」のか「人間の判断を補助する」のかで、求められる精度は変わります。業務の実態に即した精度要件を、関係者で合意しておくことが炎上防止につながります。AIの限界の理解はAIが苦手なことを知ることが活用への近道もあわせてご覧ください。
3者が同じテーブルで議論する
要件定義の段階で欠かせないのが、ビジネス担当者・IT担当者・データ分析の担当者が同じテーブルで議論することです。この3者の認識がずれたまま進むと、後から「そんな機能を求めていなかった」という齟齬が生まれます。
ビジネス担当者は「何を解決したいか」を、IT担当者は「技術的に何が可能か」を、データ担当者は「どんなデータが使えるか」を持ち寄ります。3者の視点をすり合わせることで、実現可能で、かつビジネス課題を解決する要件が定まります。誰か一人の視点だけで進めると、必ずどこかにずれが生じます。ここで経営者が関与すべきは、議論のすべてに同席することではなく、節目で「目的・成功基準・投資の範囲」を承認することです。具体的には、(1)着手前に目的と成功基準を承認する、(2)精度要件やデータの見通しが固まった段階で投資継続を判断する、(3)PoCの結果を見て本格開発に進むかを決める——この3つの承認ポイントを押さえれば、現場に任せつつ経営が舵を握れます。
要件定義書は「全員が読める」ものに
要件定義書は、技術者だけが読むものではありません。ビジネス担当者も読んで合意できる内容にすることが、炎上防止の鍵です。専門用語ばかりの要件定義書では、ビジネス側が内容を理解できず、「合意したつもり」のまま認識がずれていきます。
「何を作り、どうなれば成功で、どんな制約があるか」を、関係者全員が理解できる言葉で記述しましょう。全員が同じ理解を持って合意することが、後の手戻りを防ぎます。要件定義書は、技術文書であると同時に、関係者の合意を形にする文書なのです。
要件定義チェックリスト
- 解決したい課題と成功の基準を明確にしたか
- 精度要件を現実的な水準で定めたか
- 必要なデータの量・質・形式を定義したか
- 運用（再学習・精度劣化時の対応）まで決めたか
- ビジネス・IT・データの3者で議論したか
- 要件定義書を全員が理解できる言葉で書いたか
よくある質問
Q. 精度要件はどう決めればよいですか？
A. 「業務で使えるか」という観点で決めます。人間を完全に置き換えるなら高い精度が、補助として使うなら現実的な精度で十分です。業務の実態に照らし、関係者で合意できる水準を設定しましょう。
Q. データ要件を満たせるか分からない場合は？
A. 要件定義の段階で、必要なデータが実際にあるかを確認することが重要です。足りない場合は、データ整備やデータ収集を計画に含めます。「データがあるはず」という前提のまま進めると、後で行き詰まります。
Q. 要件定義にどのくらい時間をかけるべきですか？
A. プロジェクトの規模によりますが、ここを急ぐと後の手戻りで結局時間がかかります。関係者が十分に議論し、認識を揃える時間を確保することが、結果的に全体の期間短縮につながります。
Q. 途中で要件を変更してもよいですか？
A. 変更自体は可能ですが、影響範囲を関係者で確認し、合意のうえで行うことが重要です。曖昧なまま変更を重ねると炎上の原因になります。変更の記録を残し、全員が同じ認識を保つようにしましょう。
Q. 3者を集めるのが難しい場合は？
A. 全員が常時集まる必要はありませんが、要件の合意は3者の視点を反映して行うべきです。難しい場合は、橋渡し役（推進担当）が各者の意見を集約し、認識のずれがないか確認する方法もあります。
Q. 小規模なAIプロジェクトでも要件定義は必要ですか？
A. 規模が小さくても、「何を作り、どうなれば成功か」を明確にすることは必要です。簡潔でよいので、目的・成功基準・データ・運用を文書にしておくと、認識のずれを防げます。
Q. 経営者は要件定義のどこまで関与すべきですか？
A. 技術的な詳細に立ち入る必要はありませんが、「目的・成功基準・投資の範囲」は経営が承認すべき事柄です。着手前の目的承認、精度やデータの見通しが立った段階での投資判断、PoC結果を踏まえた本格開発の可否——この節目だけは経営が押さえてください。ここを担当者任せにすると、後で経営の期待と成果がずれ、炎上を招く恐れがあります。最終責任は経営にあるという前提で関与点を設計しましょう。
「PoC」で要件を検証する
要件定義をどれだけ丁寧に行っても、机上だけでは見えない部分が残ります。とくにAIプロジェクトでは、「想定した精度が本当に出るか」「用意したデータで十分か」は、実際に試してみないと分かりません。そこで有効なのが、本格開発の前にPoC（概念実証）を行うことです。
PoCで小さく試すことで、要件の妥当性を早い段階で検証できます。「精度要件が高すぎた」「データが足りなかった」といった問題が、本格開発の前に分かれば、要件を現実的に修正できます。要件定義とPoCをセットで進めることで、炎上の芽を早期に摘めます。いきなり本格開発に入るより、PoCで検証してから進むほうが、結果的に確実で早いのです。PoCの活用はAI投資の承認を出す前に——経営者が確認すべき判断基準もあわせてご覧ください。
要件は「変わるもの」として管理する
要件定義を一度固めたら絶対に変えない、という硬直的な姿勢も、かえって問題を生みます。プロジェクトを進める中で、新たな発見や状況の変化により、要件を見直すべき場面は必ず出てきます。重要なのは、変更を禁じることではなく、変更を適切に管理することです。
要件を変更する際は、その影響範囲を関係者で確認し、合意のうえで行います。そして、変更の内容と理由を記録に残します。曖昧なまま「なし崩し的に」要件が変わっていくと、認識のずれが生じ、炎上の原因になります。要件は「最初に固めて終わり」でも「無秩序に変わる」でもなく、合意と記録を伴って計画的に管理するもの——この姿勢が、変化に対応しながらプロジェクトを安定させます。
まとめ
AIプロジェクトの炎上は、技術ではなく要件定義の不備から生じます。精度・データ・性能・運用というAI特有の要件を現実的に定め、ビジネス・IT・データの3者で議論し、全員が理解できる要件定義書にまとめる——この丁寧な要件定義が、炎上を防ぐ最大の鍵です。そして経営者にとっての要諦は、すべての作業に関与することではなく、目的・成功基準・投資の節目を承認し、舵を握ることです。現場の要件定義を信頼しつつ、要所で経営判断を入れる。プロジェクトの成否と最終責任は経営にあるという前提で関与点を設計することが、炎上を未然に防ぎます。
DSB Consultingでは、AIプロジェクトの要件定義と推進を支援しています。自社のプロジェクトを相談したい方はAI活用支援サービスをご覧ください。