生成AIプロジェクトの納期はどう決まる？検証から本番運用までの工程表

この記事は開発会社の工数相場や契約金額を扱いません。費用の分解はAI開発の外注費用、導入全体の順序は中小企業のAI導入ロードマップで扱っています。ここでは、検証開始から本番運用を引き渡すまで、何が終われば次へ進めるかに限定します。

工程表には日付より先に完了条件を書く

「PoC完了」「開発完了」という名前だけでは、関係者の認識がそろいません。画面が動けば完了なのか、実データで品質を確認し、例外時の手作業と責任者まで決まって完了なのかを明示します。

IPAの「ユーザのための要件定義ガイド第2版」は、業務部門のユーザが主体的に要件定義へ関与する必要性と、要件定義で作成するドキュメントの流れを示しています。生成AIでも、ベンダが業務上の正解を代わりに決めることはできません。社内判断の予定を工程表へ入れます。

問い合わせ返信支援なら、対象は定型質問の下書き、対象外は返金・契約・苦情対応などと線を引きます。「自然な文章」ではなく、参照元と一致する、禁止表現を含まない、根拠がなければ回答を止める、といった受入可能な形へ変えます。

保存場所が分かっても、そのデータをAIへ入力できるとは限りません。契約、個人情報、秘密情報、権利、保存先を確認します。古い手順書や矛盾した回答例をそのまま使うと、PoCの評価自体が不安定になります。データの現状確認は移行前のデータ監査も参考になります。

PoCの出口は「デモが動いた」ではありません。実際の入力を想定した評価データで、現行手順と比較し、採用、修正、失敗を記録します。期待に届かない場合も、データ不足、要件違い、技術的限界を分けられれば、続行・変更・中止の判断材料になります。

NIST AI RMF Coreは、AIシステムを導入前にテストし、運用中も定期的に評価すること、本番相当の条件で性能や保証基準を測ることを示しています。経済産業省のAI事業者ガイドライン第1.2版も、ライフサイクルを通じたリスク対応を扱います。受入には次を含めます。

要件で対象部門と回答対象を決め、データ工程で最新版と旧版を分けます。PoCでは質問と正解根拠を用意し、回答、保留、誤答を分類します。本番ではアクセス権、引用元、ログ、停止を実装します。受入で権限の違う利用者と根拠がない質問を試し、運用担当が規程更新と再評価を実行できれば移管完了です。

用途、データ、連携、品質基準、承認体制が異なるため、根拠のない平均は使えません。工程ごとの成果物、完了条件、判断者、依存関係を決め、自社の確認可能日から逆算します。

進めません。PoCは仮説を確かめる工程です。本番には権限、監視、障害対応、利用者教育、受入テスト、切り戻し、運用責任者の合意が必要です。

正解例や利用可能なデータが用意できない、業務判断者が決まらない、受入条件が曖昧、外部システムの権限や仕様確認が遅れる場合です。未決事項と回答期限を工程表で管理します。