AI開発のフロー 4フェーズの流れと判断基準・役割分担・契約の進め方を解説

AI開発のフローを調べると、多くの記事が「構想・検証・実装・運用」という4つの段階を挙げています。流れ自体は共通していますが、実際のプロジェクトでつまずくのは段階の名前ではなく、その間にある判断です。

どの状態になったら次へ進んでよいのか、誰がどこまで担うのか、契約はどう分けるのか。ここが決まっていないと、フローを知っていても検証の段階で止まったり、想定外の追加費用が発生したりします。

この記事では、4つのフェーズの流れに加えて、フェーズ間の判断基準、発注側とベンダー側の役割分担、そして契約をどう区切るかまでを整理します。

あわせて、フローどおりに進まない原因と、各フェーズの期間・費用の目安も扱います。まずは要点を4つの質問で確認してください。

確認したいポイント結論詳細
AI開発のフローは?アセスメント・検証・開発・運用の4段階仕様どおりに作る従来型と違い、段階ごとに継続の可否を判断しながら進めます
なぜ段階を分ける?事前に精度を約束できないため実際に試すまで到達できる水準がわからず、区切って投資判断を挟む必要があります
契約はどう結ぶ?フェーズごとに分けるのが基本検証段階は準委任、要件が固まった開発段階は請負という使い分けが一般的です
止まりやすいのはどこ?検証から開発への移行合格基準を決めずに始めると、判断できないまま時間と費用が積み上がります

この記事でわかること

  • 従来のシステム開発のフローとAI開発が異なる理由
  • 4つのフェーズそれぞれの目的・作業・成果物・期間
  • フェーズ間で「進む・戻る・中止」を判断するための基準
  • 発注側とベンダー側の役割分担と、曖昧になりやすい作業
  • フェーズと契約形態の対応、およびフローが止まる5つの原因
━━ 自社のAI開発をどう区切って進めるか整理したい方へ ━━
NextScaleでは、法人向けにAI研修・AI開発・社内定着の支援を提供しています。
進め方と支援内容をまとめた資料を無料でお配りしています。
資料請求はこちら
目次

AI開発のフローが従来と違う理由

AI開発のフローを理解するには、まず何が従来のシステム開発と違うのかを押さえる必要があります。この違いを知らないまま従来型の進め方を当てはめると、途中で必ず食い違いが生じます。

3つの観点から整理します。

ウォーターフォール型のフローとの違い

従来のシステム開発は、要件定義、設計、実装、テスト、リリースという工程を順に進めます。上流で仕様を確定し、そのとおりに作れば完成するという前提に立った流れです。

AI開発では、この前提が成立しません。データから学習して判断する仕組みであるため、実際に試すまでどの程度の精度に届くかがわかりません。要件を確定してから作り始めるという順序が取れないのです。

このため、仮説を立てて検証し、結果をもとに次の判断をするという反復型の流れになります。フローが直線ではなく、段階ごとに分岐を持つ構造になっている点が最大の違いです。

精度を事前に約束できないという前提

開発を始める前に「不良の検出率95%を保証します」と約束することは、原理的に困難です。到達できる水準は、手元にあるデータの量と質によって決まるためです。

この性質は、契約のあり方にも影響します。成果物の完成を約束する形の契約は、AI開発の実態と噛み合わない場面が出てきます。

発注側とベンダー側の双方がこの前提を共有していないと、「思ったものができなかった」という認識のずれが生じます。フローの入口で確認しておくべき事項です。

だから段階を分けて進める

以上の性質から、AI開発では工程を段階に分け、区切りごとに継続の可否を判断する進め方が取られます。経済産業省が示している考え方でも、実現可能性の評価、検証、開発、追加学習という段階に分けて契約を検討することが整理されています。

この進め方であれば、想定と違う結果が出た段階で方針を変えられます。最初にすべての予算を確保するのではなく、段階ごとに投資判断を挟む形です。

AI開発の全体像については、NextScaleのコラムでも取り上げています。

関連記事:AIコンサル会社の比較|5タイプ別の特徴・費用相場・失敗しない選び方を解説

AI開発の全体フロー4フェーズ

ここからは、各フェーズで何をするのかを順に見ていきます。フェーズごとに目的が異なり、達成すべきことも変わります。

まず全体像を整理します。

フェーズ目的主な成果物
①アセスメントAIで解けるかどうかを見極める課題と数値目標、実現可能性の評価
②検証(PoC)小規模なデータで有効性を確かめる試作モデルと評価結果、判断の記録
③開発・実装業務で使えるシステムに仕上げる動作するシステムと運用手順
④運用・追加学習精度を保ちながら改善を続ける監視の記録、再学習後のモデル

フェーズ①:アセスメント

解決したい課題を特定し、AIで対応できるかを見極める段階です。このフェーズの精度が、プロジェクト全体の成否をほぼ決めます。

行う作業は、業務プロセスの分解、対象となる判断の特定、保有データの棚卸し、そして数値目標の設定です。データがどの期間、どの形式で、どれだけあるのかを一覧にするところまで進めます。

ここで確認すべきは、その課題が判断・予測・分類のいずれかに当てはまるか、そして十分なデータを確保できるかという2点です。どちらかが満たされない場合、次に進むべきではありません。

期間は2週間から1か月程度が目安で、この段階を飛ばして検証に入るケースが最も多い失敗の入口になります。

フェーズ②:検証(PoC)

立てた仮説を、実際のデータと試作モデルで確かめる段階です。本格的な開発に進む前に、技術的に実現できるか、業務上の効果が見込めるかを小規模に確認します。

最初に行うのはデータの収集と前処理です。欠損値の補完、外れ値の除去、形式の統一、ラベル付けといった作業がここに含まれ、この工程が全体の工数の大半を占めることも珍しくありません。

次に試作モデルを構築し、精度と処理速度を評価します。このとき重要なのは、開始前に合格ラインを決めておくことです。基準がないまま検証を続けると、結論が出ないまま予算だけが消えていきます。

期間は1か月から3か月程度が一般的です。この段階で得られる最大の価値は、動くものではなく「進むべきか否かの判断材料」だと捉えてください。

フェーズ③:開発・実装

検証で有効性を確認したモデルを、業務で使えるシステムとして構築する段階です。検証で作ったものは簡易な試作であり、そのまま本番に載せられるものではありません。

ここでの作業は、システム設計、モデルの精緻化、既存システムとの連携、権限管理、負荷試験などです。とくに基幹システムとの連携は、AI開発特有の複雑さが出やすい部分になります。

あわせて、AIの出力を業務にどう反映するかを設計します。判断をそのまま自動で実行するのか、人が最終確認してから実行するのかで、システムの構成も現場の運用も変わります。

期間は3か月から1年程度で、規模と連携の範囲によって大きく変動します。

フェーズ④:運用・追加学習

運用フェーズは、プロジェクトの終わりではなく本番の始まりです。AIモデルは稼働後もデータの変化に応じて精度が動くため、継続的な監視と改善が前提になります。

稼働後は、予測精度や処理速度を定期的に計測します。学習時のデータと実際のデータの分布がずれて精度が落ちる現象は、早期に検知できれば再学習で回復できます。

このフェーズで決めておくべきは、誰が、どの頻度で、何を確認するかという運用の設計です。担当者と時間が確保されていないと、半年ほどで確認が止まり、そのまま使われなくなります。

━━ どのフェーズから着手すべきか相談したい方へ ━━
現状の課題とデータの状況をうかがったうえで、進め方と必要な準備を具体的にお伝えします。
無料の相談枠をご用意しています。
相談予約はこちら

関連記事:AI開発のやり方|5ステップの手順と必要なスキル・環境・失敗しない進め方を解説

生成AIを使う場合のフローの違い

ここまでは、データを集めてモデルを学習させる前提のフローでした。一方で近年は、既存の言語モデルを組み込む進め方が増えており、この場合フローの重心が変わります。

違いを整理しておきます。

学習ではなく参照させる設計が中心になる

既存のモデルを使う場合、ゼロから学習させる工程がなくなります。代わりに重くなるのが、モデルに参照させる自社文書を整える工程です。

マニュアル、規程、過去の問い合わせ記録といった文書を、検索しやすい形に整理する作業がここに当たります。文書が古いまま、あるいは内容が矛盾したままでは、正しい回答は返ってきません。

つまり、データ整備の対象が「学習用データ」から「参照用の文書」に変わるだけで、準備に工数がかかるという構造は同じです。

検証フェーズの評価方法が変わる

数値予測であれば精度を指標で測れますが、文章の生成では単純な数値化が難しくなります。評価の設計として、想定される質問を一覧にし、期待する回答と実際の出力を突き合わせる方法が一般的です。

このとき用意する質問の一覧は、現場の担当者に作ってもらうのが確実です。実際に使う人が想定する問いでなければ、評価の意味が薄れます。

あわせて、事実と異なる内容を出力していないかを確認する観点も必要になります。回答の根拠となる文書を提示させる設計にしておくと、この確認が容易になります。

運用フェーズの作業内容が変わる

再学習ではなく、参照させる文書の更新が運用の中心になります。業務ルールが変わったときに文書を更新する仕組みがなければ、古い情報を返し続けることになります。

また、利用しているモデルが提供元によって更新されると、同じ指示でも出力が変わる場合があります。定期的に想定質問で確認する運用を組み込んでおくと、変化に気づけます。

関連記事:AIデータ分析の事例9選|業種別の活用内容と成果・自社に応用する手順を解説

フェーズ間の判断ゲート

フローの本質は、段階の名前ではなくその間にある判断にあります。「進む・戻る・中止する」の3択を各区切りで用意しておくことが、無駄な投資を防ぐ仕組みになります。

判断の設計方法を整理します。

何を基準に次へ進むか

各フェーズには、次に進んでよい状態を示す条件があります。この条件を着手前に文書にしておくことが、判断を可能にする唯一の方法です。

判断のタイミング次に進む条件確認する人
①→②数値目標が定まり、必要なデータが確保できる業務部門と経営層
②→③合格ラインの精度に届き、業務上の効果が見込める業務部門と技術担当
③→④本番環境で安定稼働し、運用体制が決まっている技術担当と運用部門
④の継続精度が維持され、業務指標が改善している業務部門と経営層

とくに②から③への移行は、最も慎重に設計すべき地点です。ここを曖昧にすると、検証を延々と繰り返す状態に陥ります。

戻る・中止の判断も設計に含める

条件を満たさなかった場合の選択肢も、あらかじめ決めておきます。「データを追加して再検証する」「対象業務を変える」「中止する」のいずれを取るかを、事前に整理しておくことが重要です。

中止という選択肢を用意していないプロジェクトは、うまくいかないまま続くことになります。撤退の判断ができる構造にしておくこと自体が、投資を守る仕組みです。

あわせて、判断の期限も決めます。「3か月経った時点で結論を出す」という区切りがあれば、議論が長引くことを防げます。

判断を記録に残す

各ゲートでの判断と、その根拠を記録に残します。なぜ進んだのか、なぜ方針を変えたのかが残っていれば、次のプロジェクトでの判断が速くなります。

とくに、うまくいかなかった検証の記録は価値があります。同じ条件で再挑戦しないための材料になるためです。

発注側とベンダー側の役割分担

フローが止まる原因の多くは、技術ではなく分担の曖昧さにあります。どちらが担うのか決まっていない作業が残っていると、その工程で必ず滞ります。

分担の考え方を整理します。

発注側が担う作業

外部に依頼する場合でも、発注側にしかできない作業があります。課題の定義、データの提供、業務上の判断基準の言語化、そして現場との調整の4つです。

とくにデータの提供は見落とされやすい部分です。ベンダーは整備の方法を助言できますが、データの中身を知っているのは自社だけであり、どの項目が何を意味するのかを説明できるのも自社の担当者だけです。

現場との調整も同様です。分析結果を業務にどう組み込むかは、社内の合意形成が必要な領域であり、外部に代行してもらえるものではありません。

ベンダー側が担う作業

ベンダー側が担うのは、データの前処理、手法の選定、モデルの構築と評価、システムへの実装、そして運用の仕組みづくりです。技術的な実現方法を設計し、形にする部分が中心になります。

加えて、他社での経験にもとづく助言も期待できる部分です。どこでつまずきやすいか、どの程度の精度が現実的かといった感覚は、経験のある相手からしか得られません。

分担が曖昧になりやすい3つの作業

実務でよく問題になるのは次の3つです。契約前に、誰が担うのかを明示的に決めておいてください。

1つ目はラベル付けです。学習データに正解を付与する作業は量が多く、業務知識も必要になります。発注側で行うのか、ベンダーに委託するのか、外部の専門業者を使うのかで費用が変わります。

2つ目は既存システムとの連携部分です。AIの本体はベンダー、連携部分は既存の保守業者という分け方になる場合、その間の調整を誰が担うのかが問題になります。

3つ目は運用フェーズの監視と再学習です。開発だけを依頼し運用は社内で担う場合、引き継ぎの範囲を契約に含めておく必要があります。

━━ 役割分担と進め方を具体的に設計したい方へ ━━
フェーズごとの進め方、必要な体制、社内での定着までをまとめた資料をご用意しています。
検討の初期段階でもご活用いただけます。
資料請求はこちら

フェーズと契約形態の対応

AI開発では、契約の結び方もフローに合わせて設計します。すべてを1本の契約でまとめると、精度を約束できないという性質と噛み合わなくなります。

考え方を整理します。

請負と準委任の違い

請負契約は「仕事の完成」に対して報酬を支払う形で、受託側に完成させる責任が生じます。仕様が明確に定まっている開発には適していますが、成果物の定義が固まりきらない段階では、認識のずれが生じやすい形態です。

準委任契約は、業務を遂行することに対して報酬を支払う形で、完成の責任は生じません。探索的に進める性質を持つAI開発とは相性がよく、検証段階で選ばれることが多い形態です。

なお準委任には、作業量に応じて支払う形と、成果物の提出に応じて支払う形があります。評価レポートの提出を条件にするなど、報酬の紐付け方は設計できます。

フェーズごとに契約を分ける

実務でよく取られるのが、フェーズごとに契約を区切る方法です。検証段階は準委任、要件が固まった開発段階は請負、運用段階は保守契約という組み合わせが基本形になります。

この方法であれば、各フェーズの終了時点で継続の可否を判断できます。想定と違う結果が出た場合に、次の契約を結ばないという選択が可能になる点が利点です。

経済産業省も、AIの利用と開発に関する契約について、確認すべき論点を整理した資料を公表しています。契約の検討にあたっては、こうした公的な資料を参照すると論点の抜けを防げます。

データと成果物の扱いを決める

契約で必ず整理しておくべきなのが、提供したデータの利用範囲と、成果物の権利の帰属です。とくに学習に使ったデータを、ベンダーが他社向けに転用できるかどうかは、事前に明確にしておくべき論点になります。

成果物についても、学習済みモデル、学習に使ったデータ、生成されたパラメータのそれぞれについて扱いを決めます。曖昧なまま進めると、パートナーを変更する際に持ち出せないという事態が起こります。

あわせて、精度についてどこまで保証を求めるかも整理します。一律の完成基準を設けにくいため、評価用データを使った条件付きの取り決めにするといった方法が取られます。

フローどおりに進まない5つの原因

流れを理解していても、実際には想定どおりに進まないことがあります。原因はほぼ5つに集約され、いずれも事前に対処できるものです。

順に確認します。

アセスメントを飛ばして検証に入る

最も多いのがこのパターンです。課題の定義とデータの棚卸しを済ませないまま検証を始めると、途中でデータ不足が判明して計画全体が崩れます。

対策は、着手前に数値目標とデータの一覧を作ることです。この2つが揃っていない状態で次のフェーズに進まないというルールを、社内で決めておいてください。

検証の合格基準が決まっていない

検証は実施したものの本番導入に至らないケースの多くは、開始時点で合格ラインを決めていなかったことが原因です。基準がないと、精度がどこまで上がっても「もう少し改善できるのでは」という議論が続きます。

逆に、届かなかった場合も撤退の判断ができず、時間と予算だけが積み上がります。達成すべき数値、判断の期限、届かなかった場合の方針の3点を文書にしておくことで、この状態は回避できます。

データの提供が遅れる

ベンダー側の作業は、データが届かなければ始まりません。発注側でデータ提供の準備が整っておらず、着手できないまま期間が過ぎるという事態は実際によく起こります。

対策は、契約時に提供するデータの範囲、形式、時期を明記しておくことです。あわせて、社内で誰がデータを抽出するのかも決めておきます。

紙の記録しかない、部門をまたぐ承認が必要といった事情がある場合は、その工数もフローに織り込んでおく必要があります。

運用フェーズの体制が決まっていない

開発が完了してから運用方法を考え始めると、精度が落ち始めたときに対応できません。監視の方法、再学習の頻度、担当者、費用を、開発の初期段階で決めておく必要があります。

運用費用は月額5万〜50万円程度が目安ですが、再学習の頻度とデータ量で変わります。予算計画にはこの継続費用を必ず含めてください。

━━ フローの設計でつまずかないための壁打ち相手が必要な方へ ━━
これまでの支援経験をもとに、貴社の状況に合わせた進め方と、避けるべき落とし穴を具体的にお伝えします。
相談予約はこちら

現場が関与しないまま進む

技術部門と外部ベンダーだけでフローを回すと、実装まで進んだ段階で現場との齟齬が表面化します。精度は出ているのに使われないという結果は、この構造から生まれます。

対策は、アセスメントの段階から実際に使う担当者をプロジェクトに入れることです。設計に関わっていれば、業務との食い違いは早い段階で見つかります。

加えて、検証フェーズの評価に現場の視点を含めることも有効です。数値上は基準を満たしていても、現場が納得できない結果であれば運用には乗りません。

各フェーズの期間と費用の目安

計画を立てる際は、各段階にどれだけの時間と費用がかかるかの目安が必要です。とくに費用は、フェーズごとに区切って予算を確保する前提で考えます。

一覧で整理します。

フェーズ別の目安

規模やデータの状況によって変動しますが、おおよその水準は次のとおりです。

フェーズ期間の目安費用の目安
①アセスメント2週間〜1か月40万〜200万円
②検証(PoC)1〜3か月200万〜500万円
③開発・実装3〜12か月数百万〜数千万円
④運用・追加学習継続月額5万〜50万円

合計すると、検証までで3〜4か月、本格的な実装まで含めると半年から1年程度が一般的な範囲になります。この幅を最も大きく左右するのは、データの整備状況です。

期間が延びやすい要因

延びる原因として多いのは、データの収集と整備です。構造化されて蓄積されていれば準備は短く済みますが、紙や個人のパソコンに散在している場合は、集める作業だけで数か月かかることがあります。

次に多いのが、社内の意思決定の待ち時間です。技術的な作業が1週間で終わっても、承認に1か月かかれば全体の期間はその分延びます。判断を誰がどの会議で行うのかを、フローの設計時に決めておいてください。

まとめ

AI開発のフローは、アセスメント、検証、開発・実装、運用・追加学習という4つのフェーズで進みます。仕様を確定してから作る従来のシステム開発と異なり、精度を事前に約束できないため、段階ごとに継続の可否を判断する構造になっています。

重要なのは、段階の名前より、その間にある判断です。各フェーズで次に進む条件を文書にし、戻る・中止するという選択肢も設計に含めておくことで、無駄な投資を防げます。

あわせて、発注側とベンダー側の分担と、フェーズごとの契約の区切り方も先に決めておいてください。まずは自社の課題を1つ選び、アセスメントの段階から着手することをおすすめします。

社外AI役員サービスご紹介資料

社外AI役員サービスご紹介資料

この資料でこんなことがわかります!

  • 社外AI役員とは
  • 支援内容
  • 導入の進め方
  • 導入実績・効果

3ステップで簡単入力

━━ AI開発の進め方を、自社の状況に合わせて設計しませんか ━━
NextScaleは、法人向けにAI研修・AI開発・社内定着支援を提供しています。課題の整理段階からのご相談も歓迎しています。
相談予約はこちら

出典:経済産業省「AIの利用・開発に関する契約チェックリスト」 https://www.meti.go.jp/press/2024/02/20250218003/20250218003.html

この記事の監修者

石丸真平

石丸真平

NEXTSCALE コンサルタント / AI活用・業務効率化支援

NEXTSCALEのコンサルタントとして、生成AI活用、業務効率化、DX推進に関する支援を担当する想定のプロフィールエリアです。業務整理からツール選定、導入設計、社内定着までを一気通貫で支援する人物紹介として使用します。

ワイヤー段階では、監修者名、肩書き、プロフィール本文、関連リンク、著者導線がどのように入るかを確認できる構成にしています。実装時には実際のプロフィール文や外部リンク、SNSアカウント情報などに差し替える想定です。
この記事をシェアする
  • URLをコピーしました!
他の成功事例を見る
目次