「AIで何かやってほしい」と経営層から言われたものの、何から手をつければいいか分からない。複数のベンダーに声をかけてみたら、ある会社はPoC（概念実証）からと言い、別の会社は最初から本番システムの見積りを出してきて、提案の粒度がバラバラで比較できない。そんな状況に置かれている方は少なくありません。
AI開発が難しいのは、通常の業務システム開発と違って「やってみないと精度が読めない」という性質があるからです。要件を固めて一括で発注する従来のやり方が通用しにくく、どこまでを一度に頼むべきか、どのタイミングで区切るべきかの判断軸が、発注者側にないまま進んでしまいがちです。
さらに発注者を不安にさせるのが、「PoCだけ頼んだ後に、本番でハシゴを外されないか」という懸念です。小さく試したはいいものの、その先につなげる絵が描けず、検証だけで終わってしまう。実際、ガートナーは2025年末までに生成AIプロジェクトの少なくとも30%がPoC後に放棄されると予測しています（ガートナー予測、2024年）。
こうした「どの順番で・どこまで・どのフェーズで発注するか」という発注単位の設計を1枚の地図にまとめたものが、AI開発ロードマップです。本記事では、PoC→MVP→本番リリース→継続改善という4つのフェーズごとに「何を発注し、何を社内に残すか」を整理し、費用・期間の目安と、発注者が主導権を握り続けるための判断軸を、稟議に転記できる早見表とともに解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
AI開発ロードマップとは？段階的に発注するための全体地図
AI開発ロードマップとは、AIプロダクトを完成させるまでの工程を時系列で並べ、各フェーズで「何を・どこまで発注するか」を定めた発注計画の設計図です。一般的なロードマップ解説記事はフェーズの名前と内容を説明するところで止まりますが、発注者にとって本当に必要なのは「発注の単位をどこで区切るか」という判断軸です。本記事はその発注設計の地図として読んでいただくことを意図しています。
なぜAI開発は一括発注に向かないのか
業務システムの開発では、要件定義を固めてから設計・実装・テストへ進む流れが一般的で、最初に全体を見積もって一括発注することができます。ところがAI開発では、この前提が崩れます。
理由は大きく2つあります。1つ目は精度の不確実性です。AIは学習させるデータの質と量によって性能が変わり、実際に作って動かしてみるまで「業務で使えるレベルの精度が出るか」が読めません。2つ目は要件の後出しです。試作したものを見て初めて「本当はこういう動きが欲しかった」と気づくことが多く、最初に要件を固めきれません。
このため、最初から本番システム一式を一括発注すると、精度が出なかった場合に多額の投資が無駄になるリスクを抱えます。そこで、小さく検証して「続行・中止・再設計」を判断しながら段階的に発注を切っていく考え方が必要になります。これがロードマップの出発点です。
ロードマップの4フェーズの全体像
AI開発の工程は、発注の観点から次の4フェーズに整理できます。
- PoC（概念実証）フェーズ: 「そもそも実現できるか」を最小投資で確かめる
- MVPフェーズ: 検証で見込みが立った機能を「使える最小プロダクト」として形にする
- 本番リリースフェーズ: 業務で安定運用できる本番システムとして仕上げる
- 継続改善フェーズ: リリース後の精度劣化やデータ変化に追従し、改善し続ける
競合記事では「企画・構想／PoC／開発・実装／運用／改善・拡張」のように5フェーズで整理することも多いですが、本記事は発注の切れ目に着目し、検証・最小実装・本番・継続改善の4区分に再整理しています。重要なのはフェーズの数ではなく、各区切りで「何を発注し、何を次に引き継ぐか」を意識的に設計することです。次の章から、各フェーズで発注すべき範囲を具体的に見ていきます。
PoCフェーズ｜「実現できるか」を最小投資で確かめる発注
PoC（Proof of Concept、概念実証）は、AI開発ロードマップの最初の関門です。ここで多くの発注者が誤解しがちなのが、PoCのゴールを「成功させること」だと考えてしまう点です。PoCの本当の目的は、成功そのものではなく「このまま本番開発に進むべきか、中止すべきか、設計を見直すべきか」という意思決定の材料を得ることにあります。
PoCで発注する範囲・しない範囲
PoCで発注すべきなのは、検証に必要な最小限の範囲です。具体的には、検証対象を1つの業務・1つのユースケースに絞り込み、限定したデータでAIの精度や実現可能性を確かめる作業に限定します。
逆に、PoC段階で発注すべきでないのが、本番を見据えた作り込みです。きれいな画面のUI、大量の同時アクセスに耐える基盤、他システムとの連携などは、まだ実現できるかどうかも分からない段階で投資する必要はありません。これらは見込みが立ってからのフェーズで発注すれば十分です。検証範囲を欲張って広げるほど、PoCは高額化し期間も延び、本来の「素早く判断する」という目的から外れていきます。
PoC完了時に受け取るべき成果物チェックリスト
ここが、後のフェーズでハシゴを外されないための最も重要なポイントです。PoCを発注する契約の時点で、完了時に以下を成果物として受け取れるよう取り決めておきましょう。
- 検証結果の評価レポート: 設定した成功条件（例: 精度80%以上）に対する実測値と、達成・未達の判定
- 検証に使用したコード・モデル: 次フェーズで再利用・引き継ぎができる形での受領
- 本番化の見積りと工程案: PoCの結果を踏まえた、MVP・本番までの概算費用とスケジュール
特に3つ目の「本番化の見積り」をPoC成果物に含めておくことが、発注者が次フェーズの判断権を握る鍵になります。これがないと、PoC完了後に「では本番はいくらかかるのか」を改めてベンダーに問い合わせることになり、足元を見られかねません。PoC契約時に「本番見積りまで成果物に含める」という一文を入れておくだけで、発注者の主導権は大きく変わります。
費用・期間の目安
AIのPoC開発の費用は、検証範囲によって幅がありますが、おおむね50万〜500万円、中小規模であれば100万〜400万円程度が一つの目安とされています（システム幹事、2026年）。期間は1〜3か月が一般的で、対象を1業務に絞って2か月以内に結果を出すアプローチが推奨されています（renue、2026年）。
これより極端に安い・短い提案を受けた場合は、検証スコープが曖昧でないか、逆に高すぎる場合は本番相当の作り込みが混ざっていないかを確認するとよいでしょう。費用感を持っておくこと自体が、提案の妥当性を評価する物差しになります。
MVPフェーズ｜使える最小プロダクトとして発注する
PoCで「実現できる見込み」が立ったら、次はMVP（Minimum Viable Product、実用最小限の製品）フェーズです。ここで発注者がつまずきやすいのが、PoCとMVPの違いが曖昧なまま、PoCの延長で進めてしまうことです。
PoCとMVPの違い
PoCとMVPは似ているようで、目的がまったく異なります。
- PoC: 検証が目的。製品化を前提とせず、「使えるか」を確かめる実験。動けば捨ててもよい
- MVP: 製品化が目的。実際にユーザーや現場が使う「製品の最初のバージョン」。継続して育てる前提
PoCのコードは「検証のため」に素早く書かれているため、そのまま本番に持ち込むと品質や保守性に問題が出ることがあります。MVPフェーズは、検証で得た知見をもとに「使える製品」として作り直す（あるいは作り足す）段階だと理解しておくと、発注範囲を見誤りません。
MVPで発注する機能の絞り込み方
MVPの肝は「最小限」です。あれもこれもと機能を盛り込むと、MVPの意味がなくなります。発注する機能を絞り込むコツは、その業務の価値の中心となる「コア機能」だけに集中することです。
ここで競合記事でも繰り返し指摘される原則が、「技術選定よりも先に、業務課題・成功条件・運用設計を固める」ことです。どのAIモデルを使うか、どの基盤に載せるかといった技術の話は後回しにして、まず「この機能で現場の何が解決されれば成功なのか」を発注者側で言語化しておきます。これが曖昧なまま技術ありきで進むと、できあがったものが現場で使われない、というMVPの典型的な失敗に陥ります。
MVPフェーズで決めておく運用・体制の初期設計
MVPは作って終わりではなく、現場で使ってフィードバックを集める段階です。そのため、本格的でなくてよいので、運用の初期設計をこのフェーズで発注範囲に含めておくことをおすすめします。
具体的には、誰がMVPを使い、不具合や改善要望をどう吸い上げるか、AIの出力をどうチェックするか、といった最低限の運用ルールです。ここを設計しておくと、次の本番フェーズで「運用の絵がまったく描けていない」という事態を避けられます。MVPフェーズは、本番に向けた運用の助走期間でもあるのです。
本番リリースフェーズ｜「死の谷」を越える発注設計
PoC・MVPまでは順調に進んだのに、本番化の手前で止まってしまう。これがAI開発で最も多く語られる「PoC止まり」「死の谷」の問題です。前述のとおり、ガートナーは2025年末までに生成AIプロジェクトの少なくとも30%がPoC後に放棄されると予測しており、PoCから本番運用に進める企業はおよそ3分の1にとどまるとも言われています（SBクリエイティブ、2024年）。
なぜPoC止まりになるのか
死の谷の正体は、技術の問題というより体制と構造の問題であることがほとんどです。主な要因は次の3つに集約されます。
- 明確なビジネスケース・ROIの欠如: 「精度は出たが、それで業務がどう良くなり、いくらの効果が出るのか」を説明できず、本番化の予算承認が下りない
- 業務プロセスに組み込まれていない: PoCが技術実験のまま終わり、実際の業務フローに統合されていない
- 本番運用を担う人材・体制の不在: 作った後に誰が運用・監視・改善するのかが決まっていない
これらは技術ベンダーだけでは解決できません。特に1つ目と3つ目は発注者側で準備すべき要素であり、PoC・MVPの段階から本番を見据えて手を打っておく必要があります。
本番フェーズで発注する非機能・運用要件
本番フェーズで初めて重みを増すのが、AIの精度そのものではなく、システムとして安定稼働させるための「非機能要件」です。発注範囲に以下を明示的に含めましょう。
- セキュリティ要件: アクセス制御、データの暗号化、機密情報の取り扱い
- 可用性・性能要件: 想定アクセス数に耐える基盤、応答速度の基準
- 監視・監査ログ: AIがどんな入力に対しどう出力したかを追跡できる仕組み
- 本番移行計画: 既存業務・既存システムからの切り替え手順とリスク対応
これらは検証段階では不要だったため、本番フェーズで急に項目が増えます。見積りが本番フェーズで跳ね上がるのはこのためで、決して不当ではありません。むしろ非機能要件が見積りに含まれていないベンダー提案のほうが、後で追加費用が膨らむ危険があります。
本番移行をスムーズにする前フェーズからの引き継ぎ設計
死の谷を越える最大のコツは、本番フェーズで急に頑張ることではなく、前フェーズから本番を見据えて準備しておくことです。
PoC段階で本番見積りを成果物に含めておく、MVP段階で運用の初期設計と成功条件を固めておく、というこれまで述べてきた打ち手が、すべて本番移行の地ならしになります。フェーズを分断された別々の発注として扱うのではなく、前のフェーズの成果物が次のフェーズの入力になるよう連続させる。この引き継ぎ設計こそが、ハシゴを外されないための本質的な対策です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
継続改善フェーズ｜内製と外注のバランスを段階的に切り替える
本番リリースはゴールではありません。AI開発には、通常のシステム開発と決定的に違う点があります。それは「完成」がないことです。
AI開発に「完成」がない理由
AIは、学習したときのデータの傾向をもとに判断します。ところが現実の世界は変化し続けるため、時間が経つと入力されるデータの傾向が学習時とずれていきます。その結果、リリース直後は高精度だったAIが、半年・1年と経つうちに徐々に精度が落ちていく「精度劣化」が起こります。
これに対応するには、新しいデータでの再学習や、出力傾向のモニタリングと調整が継続的に必要です。つまりAIプロダクトは、本番リリース後も手をかけ続けることを前提に予算と体制を組む必要があります。「作って終わり」の感覚で発注計画を立てると、リリース後に想定外の運用コストに直面します。
段階的内製化モデル
継続改善フェーズは、「どこまで外注し続けるか」という発注者の最後の悩みに答える段階です。ここでおすすめしたいのが、外注比率を固定せず、フェーズの進行に合わせて段階的に内製へ寄せていく考え方です。
- 外注主体（初期）: PoC〜本番までは知見のある外部に任せ、自社は要件と判断に集中する
- 並走（移行期）: 本番運用が安定してきたら、自社メンバーがベンダーと並走し、運用ノウハウを社内に移す
- 内製主体（成熟期）: 日常的な改善・監視は社内で回し、難易度の高い改修や新機能だけ外注する
この移行を意識すると、長期的なコストを最適化しながら、自社にAIを扱う力が蓄積されていきます。外注か内製かという二択ではなく、フェーズによって比率を動かすという発想が、継続改善フェーズの肝です。内製化の進め方をより詳しく検討したい場合は、別の機会に判断軸を整理した記事も参考になります。
継続改善を外注し続ける場合の費用構造の注意点
すべてを外注で続ける選択も可能ですが、その場合は費用構造に注意が必要です。継続改善は「月額の運用保守＋随時の改修」という形になることが多く、開発時の一括費用とは別に、毎月のランニングコストが発生し続けます。
発注時には、月額の保守範囲に何が含まれるか（監視まで含むのか、再学習は別料金か等）を契約で明確にしておきましょう。ここが曖昧だと、「精度が落ちたので改善してほしい」と依頼するたびに追加見積りが発生し、想定外の支出につながります。
フェーズ別「発注すべきもの」早見表
ここまで述べてきた4フェーズの発注設計を、1枚の表に集約します。社内稟議の資料にそのまま転記できる粒度でまとめました。
項目 | PoC | MVP | 本番リリース | 継続改善 |
|---|---|---|---|---|
目的 | 実現できるかの検証・続行可否の判断 | 使える最小プロダクトの製品化 | 業務で安定運用できる本番化 | 精度維持・改善の継続 |
発注する範囲 | 1業務に絞った検証・精度測定 | コア機能・運用の初期設計 | 非機能要件・セキュリティ・本番移行 | 再学習・監視・随時改修 |
主な成果物 | 評価レポート・検証コード・本番見積り | 動くMVP・運用ルール初期版 | 本番システム・移行計画・監査ログ | 改善レポート・更新モデル |
費用・期間の目安 | 50万〜500万円／1〜3か月 | 案件規模により変動 | 非機能要件分が加わり増額 | 月額保守＋随時改修 |
社内に残すもの | 成功条件・業務知識 | 業務課題の言語化・現場フィードバック | 運用体制の構築 | 改善の意思決定・段階的内製化 |
次フェーズへの引き継ぎ | 本番見積り・検証コード | 運用初期設計・成功条件 | 運用ノウハウ・体制 | — |
費用・期間はあくまで一般的な目安であり、検証範囲や要件によって大きく変動します。この表は「自社の発注がどのフェーズのどこをカバーしているか」を確認するチェックリストとして活用してください。
AI開発ロードマップを発注計画に落とすときの注意点
最後に、ロードマップを実際の発注計画に落とし込み、発注者として主導権を握り続けるための実務上の注意点を整理します。
段階発注で発注者が握るべき3つの権利
ベンダーの言いなりにならないために、発注者側で次の3つを意識的に握っておきましょう。
- 評価して見直す権利: フェーズごとに区切って発注し、各フェーズの成果を評価したうえで次フェーズの継続・ベンダー変更を判断できる自由を残す。最初に全フェーズを同一ベンダーに固定してしまうと、この自由が失われます
- 成果物を所有する権利: 検証コードやモデル、ドキュメントの所有権・受領を契約で明記する。これがないと、ベンダーを変えたくても引き継げず、実質的に縛られてしまいます
- 次フェーズの見積りを得る権利: 各フェーズの成果物に「次フェーズの概算見積り」を含めるよう取り決める。これが次の判断材料となり、足元を見られにくくなります
この3つは、いずれも契約の段階で一文を加えるだけで確保できます。技術的に難しいことではなく、発注時の意識の問題です。
ロードマップを社内稟議に通すための見せ方
社内の予算承認を得る際は、「AIに○○万円かけたい」と総額で持っていくより、「まずPoCに○○万円で実現性を確かめ、結果次第で本番に進む／撤退する」という段階発注の形で見せるほうが通りやすくなります。
段階発注は、経営層にとって「一度に大きなリスクを取らずに済む」というメリットがあります。各フェーズに判断ポイントがあること、撤退基準が明確であることを示せば、稟議の説得力は大きく高まります。本記事の早見表は、そのまま稟議資料のたたき台として使えるはずです。
まとめ｜AI開発はフェーズで区切って発注する
AI開発は「やってみないと精度が読めない」性質があるため、一括発注ではなく、PoC→MVP→本番リリース→継続改善というフェーズで区切って発注するのが基本です。各フェーズで「何を発注し、何を社内に残すか」を意識的に設計することが、AI開発ロードマップの本質です。
押さえておきたい要点を改めて整理します。
- PoCの目的は成功ではなく「続行・中止・再設計の判断」。成果物に本番見積りを含めておく
- MVPでは技術より先に業務課題・成功条件・運用設計を固める
- 本番化の「死の谷」は、前フェーズからの引き継ぎ設計で越える
- 継続改善では外注比率を固定せず、段階的に内製へ寄せていく
- 発注者は「評価・成果物所有・次フェーズ見積り」の3つの権利を握る
次の一歩は、いきなり大きく始めることではありません。まずは対象業務を1つに絞り、小さくPoCから着手すること。そして本記事の早見表を、社内稟議のたたき台として持ち帰っていただくこと。それが、AI開発の最初の一歩を確実に踏み出すための、最もリスクの小さい進め方です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
