【2026年版】AI開発のプロセス4段階｜PoCで止めないための進め方と契約

AI開発のプロセスを調べている方の多くは、実は工程の名前を知りたいわけではありません。「どこで何を判断すればいいのか」「なぜ検証で止まってしまうのか」を知りたい、というのが本音ではないでしょうか。

AI開発が通常のシステム開発と決定的に違うのは、契約を結ぶ時点で完成形を定義できないという点です。性能が学習に使うデータに依存するため、やってみないと分からない部分が必ず残ります。この特性を前提にしていない進め方をすると、検証段階で判断がつかず、そのまま立ち消えになります。

この記事では、経済産業省が提唱する探索的段階型の4段階を軸に、各段階で何を決めるのか、生成AIの登場でプロセスがどう変わったのか、PoCで止まる4つの理由、段階ごとの契約の考え方、そして発注側が担うべき役割までを整理します。

確認したいポイント	結論	詳細
普通のシステム開発と何が違う？	完成形を契約時に決められない	性能が学習データに依存し、リリース後の改善が前提になります。契約の組み方も変わります。
プロセスは何段階に分かれる？	アセスメント・PoC・開発・追加学習	経済産業省の契約ガイドラインが提唱する探索的段階型の4段階が、実務上の基準になります。
なぜPoCで止まってしまう？	業務指標に接続していないから	精度そのものが目的化し、本番の運用体制も決めないまま検証すると、判断できずに終わります。
期間はどれくらいかかる？	構想から実装まで半年から1年	構想1〜2か月、PoC1〜3か月、実装2〜4か月が目安。既存システム連携が重いと長引きます。

この記事でわかること

• AI開発が通常のシステム開発と異なる3つの構造的な違い
• 経済産業省が提唱する探索的段階型の4段階と、各段階で決めるべきこと
• 生成AIの登場でAI開発プロセスがどう変わったか、変わらなかったか
• PoCで止まる4つの理由と、着手前に潰しておく具体的な方法
• 段階ごとの契約の考え方と、発注側が各フェーズで担うべき役割

AI開発の進め方、無料で相談できます 何から着手すべきか、どこまで自社で担うか。構想の段階から一緒に整理します。初回のご相談は無料です。

AI開発が従来のシステム開発と異なる3つの点

工程の説明に入る前に、なぜAI開発だけ特別なプロセスが語られるのかを整理します。この3点を押さえていないと、通常のシステム開発と同じ進め方をして失敗します。

実際、多くの企業が従来型の進め方で着手し、要件が固まらないまま予算だけを消化するという経過をたどっています。構造的な違いから確認してください。

違い1｜完成形を契約時に定義できない

通常のシステム開発では、計画の時点で完成形を想定し、それを100%実現することを目指します。要件定義書に書かれたとおりに作れば、原則として完成です。

AI開発では、この前提が成立しません。モデルの内容や性能が、契約を締結する時点では不明瞭な場合が多いためです。「精度95%を保証する」という契約が原理的に結びにくいという構造があります。

経済産業省の「AI・データの利用に関する契約ガイドライン」も、この特性を出発点にしています。やってみないと分からない領域があることを前提に、段階を分けて進める方式が提唱されているのはこのためです。

違い2｜性能が学習データに依存する

同じアルゴリズムを使っても、投入するデータが違えば結果は変わります。性能を決めるのはコードではなくデータという点が、通常の開発と根本的に異なります。

この違いは、プロジェクトの工数配分にそのまま表れます。実務では、モデルの構築よりデータの整備に時間がかかるのが通例です。品目コードが部署ごとに違う、過去データに欠損がある、単位が揃っていないといった問題は、ほぼすべての現場で見つかります。

発注側にとって重要なのは、この整備作業の多くが自社側の仕事になるという点です。外部に委託しても、どのデータが正しいかを判断できるのは社内の人間だけです。

違い3｜リリースが終わりではない

通常のシステムは、リリース後は保守フェーズに入ります。AI開発では、リリース時点が完成形になるとは限りません。運用しながらデータを追加し、チューニングを重ねて精度を高めていきます。

つまり、運用フェーズにも継続的な体制が必要です。誰が実績を確認し、どの頻度でモデルを更新するのか。ここを決めずにリリースすると、時間の経過とともに精度が劣化し、やがて使われなくなります。

予算の組み方も変わります。開発費だけを確保して運用費を見ていない計画は、初年度で行き詰まります。運用と改善の費用を最初から織り込んでください。

▶ 関連記事：受託開発サービスの詳細はこちら

AI開発プロセスの4段階

ここからが本題です。経済産業省の契約ガイドラインは、AI開発をアセスメント・PoC・開発・追加学習の4段階に分け、段階ごとに進めるかどうかを判断する「探索的段階型」の方式を提唱しています。

一般的な解説記事では「構想・PoC・実装・運用」と呼ばれることが多く、名前は違いますが中身はほぼ同じです。以下では、各段階で何を決め、何を判断するのかを整理します。

第1段階｜アセスメント（構想・要件定義）

最初に行うのは、そもそもAIで解決できる課題なのかの見極めです。課題を洗い出し、AIで解くべきものと、業務フローの変更やルールベースの自動化で足りるものを切り分けます。

この段階で必ず決めるのが5点です。対象業務、目的（工数削減か品質向上か売上拡大か）、評価指標、利用できるデータの有無と品質、そして運用条件です。誰が使い、誰が改善し、どのシステムと連携するかまで、この時点で言語化してください。

評価指標を決める際は、必ず業務指標とセットにします。「正答率90%」だけでは判断できません。「正答率90%を達成すれば、月あたり何時間の工数が減る」という接続がないと、次の段階へ進む根拠になりません。

第2段階｜PoC（実現可能性の検証）

限定的なデータで初期モデルを作り、実現可能性を検証する段階です。目的は完璧なモデルを作ることではなく、本開発に進むかどうかの判断材料を得ることにあります。ここを取り違えると、PoCが延々と続きます。

確認すべきは4点です。データの品質（欠損、重複、形式の揺れ、更新頻度）、モデルの適合性、評価方法の妥当性、そして運用の想定です。特に評価方法は、機械的な指標だけでなく、人が実際に見て使えるかを判定する工程を設計してください。

PoCの終了条件も、開始前に決めておきます。「この指標がこの水準に達したら本開発へ進む、達しなければ中止する」という基準です。基準がないPoCは、成功も失敗も判定できません。

第3段階｜開発・実装

本番運用に耐えるシステムとして作り込む段階です。データの取得から前処理、推論、結果の出力までを継続的に動くパイプラインとして構築します。

ここで見落とされやすいのが、業務プロセスへの組み込みです。精度の高いモデルができても、担当者が従来どおりの判断を続けていれば業務は変わりません。どの画面で結果を見て、どの手順で次のアクションに繋げるかまで設計に含めてください。

既存システムとの連携要件やセキュリティ要件が重い場合、この段階が最も長くなります。連携先の仕様確認は、PoC段階から並行して進めておくと手戻りを防げます。

第4段階｜運用と追加学習

本番環境で稼働させ、継続的にモニタリングして改善する段階です。契約ガイドラインではこれを「追加学習段階」と呼び、納品後に追加のデータで学習を行う工程として明確に位置づけています。

運用開始時に決めておくのは3点です。モニタリングの指標と頻度、モデルを更新する担当者、そして精度が閾値を下回ったときの対応手順。担当者名まで含めて文書にしておくと、人事異動があっても引き継がれます。

また、予測や判定と異なる判断を人が行った場合、その理由を記録する仕組みを入れてください。この記録が、次の改善で最も価値のある情報になります。

各段階の期間の目安

要件によりますが、構想から実装まで半年から1年程度かかるケースがほとんどです。内訳の目安は、構想フェーズで1〜2か月、PoCで1〜3か月、実装で2〜4か月というところです。

対象業務が限定されていれば短縮できます。逆に、既存システムとの連携やセキュリティ要件が重い場合は長引きやすくなります。最初の案件では対象を絞り、短期間で1周させることを優先してください。

出典：経済産業省「AI・データの利用に関する契約ガイドライン」（平成30年6月）

▶ 関連記事：外注ゼロでAIを回す会社がやっている、内製化5段階のステップ

自社の案件がどの段階にあるのか、整理しませんか 課題の切り分けから評価指標の設計、段階ごとの判断基準づくりまで、現場に入って一緒に組み立てます。初回のご相談は無料です。

生成AIの登場でプロセスはどう変わったか

ここまでの4段階は、機械学習モデルを自社向けに構築する前提で組み立てられたものです。生成AIが普及した2026年時点では、前提が一部変わっています。

何が変わり、何が変わらなかったのかを整理します。この区別を誤ると、不要な工程に時間をかけることになります。

モデルを作るのか、既製モデルを組み合わせるのか

従来は、自社のデータで学習済みモデルを一から構築するのが前提でした。現在は、既に高い性能を持つ汎用モデルを使い、自社のデータと業務知識を組み合わせる構成が主流になっています。

この変化により、モデル構築に必要だった大量の学習データと長い学習期間は、多くのケースで不要になりました。着手のハードルは明確に下がっています。

ただし、すべてのケースで当てはまるわけではありません。画像による外観検査、需要予測、異常検知といった領域では、依然として自社データでモデルを構築する従来型のプロセスが必要です。どちらの型かを最初に見極めてください。

学習データの整備から、業務知識の整備へ

既製モデルを使う構成では、性能を左右するのは学習データではなく、モデルに参照させる社内の情報です。規程、マニュアル、過去の問い合わせ履歴、設計書といった文書が対象になります。

つまり、データ整備の中身が変わりました。数値データのクレンジングではなく、文書が検索可能な形で1か所に集まっているかが問われます。フォルダやチャットに散在したままの状態では、AIに読ませる材料が揃いません。

この整備作業は外部に委託しにくい領域です。どの文書が最新で、どれが廃止されたものかを判断できるのは社内の人間だけだからです。

評価方法が難しくなった

数値を予測するモデルであれば、誤差率で機械的に評価できます。ところが文章を生成するシステムでは、「正解が1つに定まらない」ため、評価そのものが設計課題になります。

実務的な対処は、業務ごとに合格条件を言語化することです。「必要な項目がすべて含まれているか」「事実と異なる記述がないか」といったチェック項目を作り、人が採点する形から始めます。

評価が設計できていないPoCは、必ず判断に迷って止まります。生成AIを使う案件では、モデルの選定より評価の設計に時間をかけてください。

▶ 関連記事：中小企業が月120時間を削った、生成AI活用30の現場

PoCで止まる4つの理由

AI開発で最も多い失敗が、PoCから本開発へ進めないまま終わることです。原因はモデルの性能ではなく、判断の設計にあります。

ここでは現場で繰り返し見てきた4つの理由と、その回避方法を整理します。着手前にこの4点を潰しておけば、判断できずに終わることはなくなります。

理由1｜目的が「AIを使うこと」になっている

最も根本的な失敗です。「AIで何かできないか」から始まった案件は、解決すべき課題が定義されていないため、何をもって成功とするかを決められません。

回避策は、課題から始めることです。いま何にどれだけ時間がかかっているのか、どこで損失が出ているのか。この数字を先に押さえ、そのうえでAIが有効な手段かを検討します。

検討の結果、AIを使わないという結論もあり得ます。業務フローの見直しやルールベースの自動化で足りるなら、そのほうが安く早く確実です。

▶ 関連記事：人を増やせない地方の中小企業が、AIで現場を回し始めるまでの3週間

理由2｜評価指標を業務指標に接続していない

「正答率85%を達成した」という結果が出ても、それが良いのか悪いのかは判断できません。比較対象と、業務への影響が示されていないためです。

必要なのは2つの接続です。1つは現状との比較で、いま人が行っている作業の精度をベースラインに置きます。もう1つは業務指標への換算で、「この精度なら月何時間の工数が減る」という形にします。

この2つが揃えば、投資判断は自然に下せます。逆に揃っていなければ、どんなに高い精度が出ても意思決定はできません。

▶ 関連記事：そのAI、何ヶ月で元が取れますか。投資回収を3分で見える化する計算式

理由3｜本番運用の体制を決めずに検証している

PoCが成功しても、「誰が運用するのか」が決まっていなければ本開発には進めません。モデルの更新、精度の監視、問い合わせ対応。これらを担う人が社内にいないと、稟議は通りません。

回避策は、PoCの段階で運用体制を並行して設計することです。専任を置けないなら、外部に委託する前提で費用を見積もる。この検討を後回しにすると、成功したPoCが宙に浮きます。

理由4｜データ整備の工数を見積もっていない

PoCでは、きれいに整えた一部のデータを使います。ところが本番では、全社のデータを継続的に整備し続ける必要があります。この工数を見ていないと、本開発の見積もりで想定外の金額が出てきます。

対処は、PoCの段階でデータの状態を全量調査しておくことです。欠損率、表記の揺れ、更新の頻度、部署ごとの差異。ここで見つかった問題が、そのまま本開発の作業量になります。

情報処理推進機構（IPA）が2026年7月に公開したDX動向2026でも、AI導入は広がる一方、業務効率化の段階から新たな価値創出へ発展させることが課題として示されています。入れることと、業務に定着させることは別の問題です。

PoCで止まらない設計を、一緒に組み立てます 評価指標の設計、判断基準の設定、運用体制の検討まで支援します。導入以外のご相談もお問い合わせフォームから承ります。

段階ごとの契約の考え方

外部に開発を委託する場合、契約の組み方が成否を左右します。AI開発の特性を無視した契約は、双方にとって不利益になります。

ここでは経済産業省の契約ガイドラインが示す考え方をもとに、実務での要点を整理します。

探索的段階型という進め方

契約ガイドラインが提唱するのは、開発プロセスを4段階に分け、段階ごとに「AIで目的を実現できるか」「次の段階に進むか」を判断しながら探索的に進める方式です。段階ごとにモデル契約も示されています。

この方式が推奨される理由は、AI技術を使うソフトウェア開発の特徴にあります。モデルの内容や性能が契約締結時に不明瞭であり、その性能が学習用データセットに依存する。この不確実性を、契約を分けることで管理するという発想です。

一括で全工程を請け負う契約は、双方にリスクが偏ります。ベンダー側は達成できるか分からない性能を約束することになり、発注側は成果が出ない場合に打ち切れなくなります。

段階ごとに契約を分ける実務上の利点

発注側にとっての最大の利点は、各段階の終わりに撤退できることです。アセスメントで実現性が低いと分かれば、そこで止められます。損失は最小限で済みます。

ベンダー側にとっても、不確実な段階では準委任、成果が定義できる段階では請負という形で、無理のない責任範囲を設定できます。結果として、双方が納得できる条件になりやすくなります。

契約を分ける際に必ず決めておくのが、各段階の終了条件と成果物です。「PoCの成果物は評価レポートと初期モデル」といった形で明示しておかないと、完了の判定で揉めます。

発注側が事前に決めておくこと

権利関係は、着手前に整理してください。学習に使うデータは誰のものか、生成されたモデルの権利は誰に帰属するのか、そのモデルを他社案件に流用してよいのか。この3点は、後から揉めやすい代表格です。

契約ガイドラインでも、データを提供した側とノウハウを提供した側の主張が対立する事例が取り上げられています。独占的な権利を求めるのか、利用条件を細かく設定して調整するのか。方針を先に決めておくと、交渉が短く済みます。

あわせて、入力データの取り扱いと、生成物の確認責任も明文化しておいてください。総務省・経済産業省の「AI事業者ガイドライン」も、利用者としての責任を果たす観点から参考になります。

▶ 関連記事：Claude Code企業導入｜セキュリティ・運用・ROI設計

各段階で発注側が担うこと

AI開発は、外部に委託しても発注側の作業がなくなりません。むしろ、通常のシステム開発より発注側の関与が求められます。

ここでは段階ごとに、社内で担うべき役割を整理します。ここを人任せにすると、期待した成果は出ません。

アセスメント段階｜課題とデータの提示

この段階の主役は発注側です。どの業務に、どれだけの時間とコストがかかっているのか。外部の会社はこの情報を持っていません。現状値を測って提示するのは、社内の仕事です。

あわせて、保有しているデータの一覧と、それぞれの更新頻度・保存形式・保存期間を整理します。この棚卸しができていれば、後続の見積もり精度が上がります。

社内の推進担当も、この段階で決めてください。兼任で構いませんが、窓口が定まっていないプロジェクトはほぼ確実に遅延します。

PoC段階｜評価への参加と現場の巻き込み

PoCの評価は、外部の会社だけでは完結しません。出力が実務で使える水準かどうかを判定できるのは、その業務を毎日やっている現場の担当者だけです。

評価の場に現場を巻き込んでください。この関与が、後の定着率を大きく左右します。管理部門だけで進めたプロジェクトは、本番稼働後に「使いにくい」と言われて止まります。

また、この段階で本開発の予算感を経営層に共有しておきます。PoCが成功してから初めて金額を出すと、稟議に時間がかかり勢いが失われます。

開発・運用段階｜業務フローの変更を決める

システムができても、業務のやり方を変えるのは発注側の仕事です。誰の作業がなくなり、誰の作業が増えるのか。この調整は外部には委ねられません。

運用段階では、モデルの更新を担う体制を決めます。社内で担うのか、保守契約に含めるのか。内製化を目指すなら、開発段階から社内メンバーを並走させておく必要があります。

最終的に目指すのは、「導入した」ではなく「その業務は毎日AIを使って回っている」という状態です。ここまで到達して初めて、投資は回収の局面に入ります。

▶ 関連記事：Claude Codeチーム導入｜社内展開90日ロードマップ

構想から定着まで、現場に入って伴走します 課題の整理、評価設計、PoCの判断基準、業務フローの組み替え、そして運用体制まで。PoCで止めない開発をご一緒に。初回相談は無料です。

まとめ

AI開発のプロセスについて、従来の開発との違い、4段階の中身、生成AI時代の変化、PoCで止まる理由、契約の考え方、発注側の役割まで整理しました。最も重要なのは、着手前に評価指標と判断基準を決めることです。

経済産業省の契約ガイドラインが提唱する探索的段階型は、不確実性を段階に分けて管理するための枠組みです。アセスメント、PoC、開発、追加学習。それぞれの終わりで「次に進むか」を判断できる状態にしておけば、無限にPoCを繰り返すことはなくなります。

生成AIの登場で、着手のハードルは明確に下がりました。一方で、評価の設計はむしろ難しくなっています。モデルの選定より、何をもって合格とするかの言語化に時間をかけてください。

株式会社LiftBaseは、AI導入をPoCで止めないことを掲げ、現場に常駐して業務フローの設計から実装、定着までを伴走しています。構想の段階から一緒に組み立てるご相談も承っています。

出典：経済産業省「AI・データの利用に関する契約ガイドライン」／情報処理推進機構（IPA）「DX動向2026」

▶ 関連記事：AI導入支援・コンサルティングのサービス詳細はこちら

AI開発を、実装と定着まで一気通貫で支援します 構想・要件定義からPoC、実装、運用まで。現場に深く入り込み、業務フローそのものを設計し直すところからご一緒します。初回相談は無料です。