AI PoC止まりを脱却する開発パートナー選定ガイド｜本番化成功率を3倍にする7基準と失敗5パターン【2026年版】

「PoC は成功した。意思決定者も納得した。でも本番化が進まない」――この光景は珍しくありません。RAND Corporation の 2024 年レポートは AI プロジェクトの 80.3% が失敗 すると報告し、MIT NANDA の 2025 年レポートに至っては 生成 AI パイロットの 95% が財務リターンゼロ だと結論づけました。Gartner も「2025 年末までに 30% の GenAI プロジェクトが PoC 後に放棄 される」と予測しています。

PoC 止まりは技術的問題ではなく、「PoC を引き取って本番化まで運ぶパートナー設計の問題」 です。本記事では、PoC 止まりを生む構造的 5 原因をパートナー選定基準 7 要件にマトリクス変換し、MLOps 実装力 5 段階評価、契約類型 × フェーズ最適マッチング、30 日 PoC → 90 日本番化フレーム、失敗パターン 5 類型（早期検知シグナル付き）、業種別パターン、Go/No-Go 10 項目スコア、本番化保証型契約の中身まで、純テキスト 2 万字超の体系で整理します。

PoC 自体の進め方は AI PoC の進め方完全ガイド、AI 導入全体像は AI 導入の進め方ガイド、開発会社の総合比較は AI 開発会社比較 2026 を合わせてご覧ください。

結論: PoC 止まりは「開発会社の選び方」で 8 割が決まる

PoC 止まり問題の責任は、発注側だけにありません。PoC 完了時点で 「本番化に必要な要件」「責任分界」「運用設計」「契約条項」 を伴走者として組み立てられる開発会社かどうかで、本番化成功率は 3 倍以上の差がつきます。

実際、MIT NANDA の 2025 年レポートは 「専門ベンダーから購入・パートナーシップで進めた取り組みは約 67% が成功、内製ビルドの成功率はその 3 分の 1」 と報告しました。これは「パートナーをどう選ぶか」が本番化の最大変数であることを示す決定的なデータです。

したがって本記事は、開発会社選定を「PoC 止まりの逆問題」として扱います。「PoC が止まる構造的原因」を起点に「それを潰せるパートナーの要件」を導き、契約と運用に落とし込む ――この一筋を 2 万字で整理しました。

一次ソースで見る PoC 止まりの実態

開発会社選定の議論に入る前に、PoC 止まりが「個別現象」ではなく 構造的市場問題 であることを、複数の一次ソースで確認します。

RAND「AI プロジェクト 80.3% 失敗」が示す根本原因

米国 RAND Corporation は 2024 年 8 月、レポート 「The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed: Avoiding the Anti-Patterns of AI」 を公表し、AI プロジェクトの 80.3% が失敗する と報告しました。これは IT プロジェクト一般の失敗率の 2 倍に相当します。

調査は AI 関連経験 5 年以上のデータサイエンティスト・エンジニア 65 名へのインタビューに基づき、根本原因として 5 項目を挙げました。

1. 目的と意図の誤解・誤コミュニケーション: ビジネス側がプロジェクトの目的を不明確に伝える
2. データの不足・低品質: 「AI 用に整備されていないデータ」を AI で解こうとする
3. 技術への執着: ビジネス課題ではなく技術を主役にする
4. インフラ不足: モデル運用基盤が PoC 後に拡張できない
5. 問題の難易度誤認: AI で解ける問題と解けない問題の見極めが甘い

5 項目はすべて 技術力以前の「上流設計」と「インフラ運用設計」の問題 に集約されます。つまり PoC 段階で本番化を見据えた設計をしていない案件が、PoC 後に止まるのです。

MIT NANDA「GenAI 95% pilots fail」の構造

2025 年 8 月、MIT の NANDA イニシアチブが公表したレポート 「The GenAI Divide: State of AI in Business 2025」 はさらに厳しい数字を示しました。150 社のリーダーインタビュー・350 名の従業員調査・300 件の公開 AI 導入事例を分析した結果:

• 企業の GenAI 投資総額は 300〜400 億ドル
• そのうち 95% のパイロットが財務リターンを生んでいない
• 急速な収益加速を実現した企業は わずか 5%
• 専門ベンダーからの購買・パートナーシップによる導入は 67% が成功、内製ビルドの成功率は 約 22%（3 分の 1）

NANDA は失敗の根本原因を 「learning gap」（学習ギャップ）と命名しました。多くの GenAI システムはフィードバックを蓄えず、文脈に適応せず、時間とともに改善しない――そのため業務に「定着」せず、PoC で止まると分析しています。

実装面の重要な含意は二つです。

• 専門パートナーを選ぶ方が成功率が高い: 完全内製化は構造的に不利
• 「学習しない AI」は本番化しない: フィードバックループ・継続学習・MLOps が必須

Gartner「30% が 2025 年末までに PoC 後放棄」

Gartner は 2024 年 7 月のリリースで、「2025 年末までに、企業の GenAI プロジェクトの 30% は PoC 後に完全放棄される」 と予測しました。続く 2025 年の調査では:

• AI プロジェクトのうち 本番に到達するのは平均 48%
• AI プロトタイプから本番化までの 平均期間は 8 ヶ月
• 失敗の 85% は データ品質起因
• 本番化複雑度を 300〜500% 過小見積もり する組織が多数

「PoC では小さくクリーンなデータで成功するが、本番では大量の実データ・既存システム統合・セキュリティレビューで難易度が跳ね上がる」――Gartner の見立てはここに収斂します。

McKinsey「2/3 がパイロット未達」「39% のみ EBIT 寄与」

McKinsey & Company の 「The State of AI in 2025」 は、2025 年 11 月公表時点で次のように報告しました。

• 78% の組織が AI を利用しているが、EBIT 寄与を報告できる組織は 39%
• 5% 以上の EBIT 寄与 を報告できる「AI ハイパフォーマー」は約 6%
• ほぼ 3 分の 2 の組織は、AI を全社スケールに展開できていない（パイロット止まり）
• エージェンティック AI を業務でスケール展開している組織は 23%

McKinsey はハイパフォーマー群の共通要素として、ワークフロー再設計／組織変革／継続学習の制度化／ベストプラクティスの体系化 を挙げています。これらはすべて「PoC を本番に運ぶプロセス設計」の言い換えです。

国内データ（JUAS / IPA）の温度差

日本国内では JUAS（日本情報システム・ユーザー協会）の 「企業 IT 動向調査 2025」（2025 年 4 月公表）が以下を報告しています。

• 言語系生成 AI 採用（準備中含む）は 41.2%（前年 23.9% から 14.3 ポイント増）
• 画像・動画生成 AI 採用は 21.9%、コード生成 AI は 20.8%
• 効果実感は「期待通り」33.1%、「やや下回る」36.1%、「大きく上回る」4.0%――73.2% が何らかの効果を実感

IPA「DX 動向 2024」は 「PoC が『やりっぱなし』になっている企業が 62%」 と報告し、「PoC は実施するが本番化しない」現象が国内固有でもなく、しかし国内でこそ顕著であることを示しています。

国内・国外を統合すると、PoC 止まり率はおよそ 62〜95% のレンジ に収まります。母集団・期間・AI 種別により幅はありますが、「PoC を始めても 6〜9 割は本番化しない」という認識を経営層と合わせるだけで、本番化を意識した PoC 設計に踏み込めるはずです。

一次ソース 6 本から導かれる 3 つの示唆

一次ソース 6 本を横断比較すると、開発会社選定に直結する 3 つの一貫した示唆が浮かびます。

• 支配的原因は「技術」ではなく「設計と組織」: RAND の根本原因 5 項目、MIT NANDA の learning gap、McKinsey のワークフロー再設計はすべて「上流設計と運用設計」を指す
• 専門パートナー協働は内製化単独より 3 倍成功しやすい: MIT NANDA の 67% 対 22% は、開発会社選びを後回しにできない決定的データ
• 本番化は PoC の何倍も複雑: Gartner の「過小見積もり 300〜500%」は、PoC コストの 3〜5 倍の本番化予算を着手時点で仮押さえするべきという実務的含意を持つ

PoC 止まりを生む構造的 5 原因

一次ソースを横断すると、PoC 止まりの原因は 業務・データ・運用・組織・アーキテクチャ の 5 領域に分解できます。1 つでも欠けると、PoC は「成功したのに本番化しない」状態に陥ります。

原因 1: ビジネス KPI 未設定（経営対話不足）

最も多い失敗は 「PoC のゴールが技術検証で止まっている」 ことです。「精度 95% を達成した」「処理速度が 2 秒に短縮した」――この種の技術指標は経営層には響きません。

RAND が筆頭に挙げた「目的・意図の誤解」もここに該当します。経営層が承認するのは 「年間業務改善効果 1.2 億円／投資回収 14 ヶ月／コンプライアンスリスク低減」 のような ビジネス言語の成果 です。PoC 着手時点でビジネス KPI を 3 軸（コスト／売上／リスク）で設計していない案件は、PoC 完了時に「で、これでいくら儲かるの？」と聞かれて止まります。

早期検知シグナル: 着手 2 週目に「現場部門の責任者が PoC 結果を説明できない」「ROI 試算スプレッドシートが存在しない」状態なら危険信号です。

原因 2: データ整備未完（データエンジニアリング欠落）

Gartner が「失敗の 85% はデータ品質起因」と断言した領域です。PoC は「整備済みサンプルデータ」で動きますが、本番化には:

• リアルタイム取り込み（Kafka / Pub/Sub / EventBridge 等）
• データ品質モニタリング（dbt tests / Great Expectations 等）
• メタデータカタログ（DataHub / Amundsen / Unity Catalog 等）
• 個人情報マスキング・トークナイゼーション
• ベクトルストア／グラフデータベース（生成 AI 案件）

が必要になります。これらを PoC 段階で「本番化前提のデータエンジニアリング設計」として組み込まない と、本番化フェーズで「データ基盤の作り直し」が発生し、追加で 6 〜 12 ヶ月失います。

原因 3: MLOps 運用設計の欠落

モデルを作って終わりではなく、再学習・監視・ログ・Drift 検知・コスト統制 を運用ループとして設計するのが MLOps です。RAND の「インフラ不足」、MIT NANDA の「learning gap」もここに集約されます。

MLOps が欠落したまま本番化すると次の事故が起きます。

• リリースから 2 ヶ月でデータ分布が変わり、精度が静かに低下（Silent Failure）
• LLM のトークン課金が想定の 3 倍に膨らみ、CFO が緊急停止を要求
• 再学習スクリプトが「あの人しかわからない」属人化状態
• インシデント発生時にログがなく、原因特定に 2 週間かかる

MLOps の実装レベルは後述の 「MLOps 実装力 5 段階評価」 で開発会社を評価します。

原因 4: 業務統合困難（現場巻き込み不足）

PoC は技術検証として「業務の上澄み」だけを切り出して動きますが、本番化には:

• 既存業務フローへの組み込み（現場の手順書改訂）
• 認証・権限統合（AD / IdP / Okta 等）
• 帳票・基幹システム連携（SAP / Salesforce / kintone 等）
• 例外フロー（AI が判定不能な場合の人手フォールバック）
• 教育・トレーニング（現場メンバーへの使い方研修）

が必要です。McKinsey が「ハイパフォーマー群はワークフロー再設計を行う」と指摘したのもここです。「業務オーナー」がプロジェクトに途中から呼ばれている案件は、ほぼ確実に本番化前に立ち往生 します。

原因 5: スケーラビリティ未検証（本番アーキテクチャ未設計）

PoC は「単一サーバ／単一テナント／単一リージョン」で十分動きますが、本番化には:

• 同時アクセス数（QPS）の見積もりとオートスケール
• マルチテナント分離（B2B SaaS 提供時）
• マルチリージョン／DR 設計
• セキュリティ要件（ISO 27001 / SOC 2 / FISC 等）への適合
• 監査ログ・データ持ち出し制御（特に生成 AI）

これらを後付けすると、本番リリース直前に「セキュリティレビューが 3 ヶ月遅延」「想定 QPS の半分しか捌けない」など致命傷を負います。Gartner が「本番化複雑度を 300〜500% 過小見積もり」と警告した部分です。

5 原因 → パートナー 7 要件マトリクス

5 つの原因を 「それを潰せるパートナーの要件」 に変換すると、開発会社選定の評価軸が明確になります。本記事の核となる独自マトリクスです。

要件 1: 経営層との対話力（KPI 翻訳能力）

開発会社の営業担当・PM が 「現場課題をビジネス KPI に翻訳する語彙」 を持っているかは、提案書の冒頭 1 ページで見抜けます。次の 3 点を必ず確認してください。

• 「ROI 試算」が単年ではなく 3 年スパン で提示されているか
• コスト削減・売上増加・リスク低減 の 3 軸が揃っているか
• 「やらないリスク」（機会損失・規制リスク） がシナリオ化されているか

KPI 翻訳能力の高い開発会社は、提案書の 1 枚目が技術構成図ではなく 「経営層が稟議で読めるエグゼクティブサマリー」 になっています。

要件 2: データエンジニアリング体制

データ整備未完を防げるパートナーは、以下を PoC 着手前 に提示できます。

• データソース棚卸し表（テーブル数・件数・更新頻度・所有部門）
• データ品質スコアリング（欠損率・重複率・型不整合率）
• メタデータ管理ツールの選定理由（DataHub / Amundsen / Unity Catalog 等）
• マスキング・トークナイゼーション方針（個人情報・機密情報）
• ベクトルストア／グラフ DB の選定理由（生成 AI / RAG 案件）

「データはお客様側で整備してください」という会社は、PoC は動かせても本番化を伴走できない リスクが高いと判断してください。

要件 3: MLOps 運用設計力

本ガイドの最も重要な評価軸です。次節 「MLOps 実装力 5 段階評価」 で詳述します（Google Cloud「MLOps: Continuous delivery and automation pipelines in machine learning」および Microsoft「MLOps Maturity Model」を参考に、開発会社評価向けに koromo が再編した独自フレームです）。

要件 4: 現場ヒアリング力

PoC 着手前のヒアリング工数が 「2〜3 時間／1 回」 で済むと言ってくる開発会社は危険信号です。本番化を見据えるなら以下を最低工数として確保するべきです。

• 業務オーナー: 8〜12 時間（業務フロー全棚卸し）
• 現場オペレーター: 4〜6 名 × 各 2 時間（実作業観察含む）
• 情シス・IT 部門: 4 時間（既存システム連携要件）
• 法務・コンプライアンス: 2 時間（データ持ち出し・規制適合）

合計 30〜40 時間 がヒアリング工数の目安です。これを「PoC が始まる前の事前調査として無償で実施する」開発会社は、本番化への意欲が高いと判断できます。

要件 5: 本番アーキテクチャ設計力

PoC コードはそのまま本番には載りません。PoC 段階から「本番アーキテクチャ図」を併走して描ける 開発会社を選んでください。チェックすべきは以下です。

• コンテナ化前提（Docker / Kubernetes / ECS / Cloud Run）
• IaC（Infrastructure as Code）整備（Terraform / Pulumi / AWS CDK）
• CI/CD パイプライン（GitHub Actions / GitLab CI / CodePipeline）
• 観測性スタック（Prometheus / Grafana / Datadog / New Relic）
• セキュリティスキャン（Snyk / Trivy / Wiz / Prowler）

これらは PoC では使わなくても、本番化フェーズで導入される前提でパートナーが設計できているかが鍵です。

要件 6: 契約柔軟性

後述の 「契約類型 × フェーズ最適マッチング」 で詳述します。重要なのは PoC フェーズで「請負契約」だけを提案する開発会社は危険 という点です。要件が固まりきっていないフェーズで請負を結ぶと、変更のたびに変更契約書が発生し、本番化の速度が落ちます。

要件 7: 内製化伴走力

最終的に 発注側が AI システムを運用できる状態 に持っていく能力です。これを「伴走」と曖昧に表現する会社は多いですが、具体性が伴っているかを次の 5 点で確認してください。

• ナレッジ移転のドキュメント体系（運用手順書・トラブル対応集・ADR）
• コードレビュー体制（双方向で発注側エンジニアもレビュー参加）
• OJT ローテーション（開発会社のエンジニアが現場常駐 → 段階的に撤退）
• 卒業条件の契約条項化（「3 つのインシデント対応を発注側だけで完了したら卒業」等）
• 卒業後の SLA（Slack 内 1 営業日応答／クォーター毎レビュー等）

「ずっと一緒にやらせてください」と内製化を回避する会社は短期売上重視と判断できます。

MLOps 実装力 5 段階評価

開発会社の本番化実装力を最も鮮明に映すのが MLOps 成熟度 です。下表で自社評価を出してもらい、Lv3 以下なら本番化伴走力に疑問符を付けてください。

各レベルの確認質問テンプレート

• Lv2 確認: 「最新案件で GitHub Actions（あるいは GitLab CI）の YAML を見せてください。デプロイ手順は何ステップですか」
• Lv3 確認: 「再学習をトリガーする条件は時間ベース／精度ベース／データ量ベースのどれですか。再学習結果の評価は誰が承認しますか」
• Lv4 確認: 「入力 Drift と出力 Drift を別々に検知していますか。Drift 検出時のアラート先と再学習開始判断はどう設計していますか」
• Lv5 確認: 「A/B テストと Shadow デプロイの実装事例を見せてください。ロールバック判断の閾値設計はどう自動化していますか」

国内の AI 開発会社の多くは Lv1〜Lv2 に集中しています。Lv3 以上を契約条項に盛り込める会社は限られるため、本番化を本気で目指すなら 「初回リリース時点で Lv3、リリース 6 ヶ月以内に Lv4 到達」 を要件定義書に明記することを推奨します。

契約類型 × プロジェクトフェーズ最適マッチング

開発会社選定で最も見落とされがちなのが 「契約形態が PoC 止まりを生む」 構図です。請負契約は「要件確定後」が前提のため、PoC 段階で結ぶと変更管理が地獄になります。逆に準委任契約だけで本番運用に入ると、成果物責任が曖昧になり「動かない AI」を抱えるリスクが上がります。

5 つの契約類型

1. 請負契約（一括）: 仕様確定・成果物コミット・瑕疵担保あり。要件不確実性が低い案件向け
2. 準委任契約（伴走）: 工数コミット・成果物保証なし。要件不確実性が高い PoC 段階向け
3. ハイブリッド: PoC 部分は準委任、本番化フェーズは請負に切替
4. 成果報酬型: 業務 KPI 達成連動でフィー支払い。リスクシェアが強い
5. 本番化保証型（koromo 独自）: PoC 完了時点で本番リリース時期・主要要件・KPI 達成水準を契約条項化。未達時のフィー減額・期間延長条件を明文化

フェーズ別の推奨契約マッピング表

本番化保証型契約の中身（koromo 独自）

「伴走」「成功責任」と謳う開発会社は多いですが、契約書の条項に落ちている ケースは稀です。koromo の本番化保証型契約は、以下を明文化します。

• 本番リリース日のコミット（PoC 完了から N ヶ月以内）
• 主要 KPI 達成水準のコミット（精度／処理時間／業務改善効果額）
• 未達時のフィー減額条件（達成率に応じた減額率テーブル）
• 追加工数の上限（コミット未達時の無償延長期間）
• スコープ変更プロトコル（変更契約書フローと判断基準。発注側起因のスコープ変更時はフィー減額条件から除外する旨も明文化）

この設計により、開発会社側にも本番化への金銭的インセンティブが働き、PoC 止まりの構造的リスクが下がります。なお、具体的な減額率は下請法・独占禁止法に抵触しない範囲で個別協議となります。詳細はお問い合わせください。

PoC 止まり失敗パターン 5 類型と早期検知シグナル

開発会社選定の議論を補完するために、PoC 自体を失敗させる 発注側の典型的アンチパターン を 5 つに整理します。重要なのは「3 週目までに気づける早期検知シグナル」を併記している点です。

F1: 精度 100% 追求型

「もう少し精度を上げたら本番化する」と PoC が無限に延長されるパターン。多くの SERP 上位記事も挙げる典型類型です。

• 早期検知シグナル: 着手 3 週目で「目標精度」がまだ確定していない／精度向上 1 ポイントごとに必要工数の試算がない
• 対策: 着手時点で 「業務代替に必要な精度の下限」 を業務オーナーと合意。下限を超えた時点で Go 判断する規律を契約に明記

F2: 予算切れ型

PoC で予算を使い切り、本番化のための追加予算稟議が通らないパターン。

• 早期検知シグナル: 着手 2 週目時点で 「本番化フェーズの稟議資料雛形」 が用意されていない
• 対策: PoC 着手と同時に 本番化フェーズの予算枠を仮押さえ。経営会議に「PoC 完了報告」「本番化稟議」をワンセットで提出する段取りを組む

F3: 内製化計画なし型

本番化はしたものの、開発会社が常駐し続けなければ運用できない状態に陥るパターン。

• 早期検知シグナル: 提案書に「ナレッジ移転計画」「卒業条件」「OJT ローテーション」のいずれも記載がない
• 対策: 要件 7（内製化伴走力）で詳述した 卒業条件を契約条項に組み込む。具体的な指標（インシデント自社対応 N 件等）で測定可能化

F4: 研究指標偏重型

PoC の評価が「BLEU」「F1 スコア」「mAP」など技術指標のみで、業務 KPI に翻訳されていないパターン。

• 早期検知シグナル: PoC 計画書の評価セクションに 「業務 KPI への換算式」 が書かれていない
• 対策: 着手時点で 「研究指標 → 業務 KPI 換算表」 を作成。例: 「Recall 90% → 月間漏れ件数 12 件 → 損失額 240 万円」

F5: 経営巻き込み不足型

業務部門と情シスだけで PoC を走らせ、本番化稟議の段になって経営層から「で、これでいくら儲かるの？」「セキュリティリスクは？」と差し戻されるパターン。RAND が筆頭に挙げた根本原因に直結します。

• 早期検知シグナル: PoC スポンサーが本部長以下／PoC 結果のレビュー会議に役員が招待されていない
• 対策: 着手時点で 経営層スポンサー（最低でも役員クラス） を正式アサイン。月次で経営層レビューを定例化

「30 日 PoC → 90 日本番化」フレーム（koromo 方法論）

ここまでの 5 原因・7 要件・MLOps 5 段階評価・契約類型・失敗 5 類型を統合した実行フレームが、koromo の 「30 日 PoC → 90 日本番化」プログラム です。Week 1 から Week 13 までの 4 ヶ月で 「PoC 着手 → 本番リリース → スケール開始」 までを通します。

Week 1-4: PoC フェーズ（30 日）

Week 5-12: 本番化フェーズ（90 日）

Week 13-: スケールフェーズ

このフレームを採用するメリットは 「本番化の見えない複雑度」を 13 週間の可視化されたタイムボックスに収める ことです。Gartner の指摘した「過小見積もり 300〜500%」を、現実のスケジュールに変換します。

業種別 PoC → 本番化パターン

業種ごとに「典型 PoC テーマ」「本番化阻害要因」「推奨パートナー要件」を整理します。要件マトリクスの優先順位は業種により変わります。

製造業

• 典型 PoC テーマ: 外観検査自動化（画像認識）／予知保全（IoT 時系列）／需要予測
• 本番化阻害要因: 工場ネットワークの閉域性／既存 PLC・MES 連携／検査ライン停止リスク
• 重視すべきパートナー要件: 要件 5（本番アーキテクチャ設計力＝オンプレ・エッジ対応）、要件 4（現場ヒアリング力＝検査員との対話）
• 関連記事: 製造業 AI 活用事例、製造業デジタルツイン

小売・EC

• 典型 PoC テーマ: ダイナミックプライシング／需要予測／レコメンド／カスタマーサポート LLM
• 本番化阻害要因: 季節変動／POS・EC プラットフォーム連携／個人情報マスキング／A/B テスト設計
• 重視すべきパートナー要件: 要件 3（MLOps 運用設計＝高頻度再学習）、要件 1（KPI 翻訳＝粗利インパクト換算）

金融

• 典型 PoC テーマ: 与信スコアリング／不正検知／RAG による問い合わせ自動応答／コンプラ文書要約
• 本番化阻害要因: FISC 安全対策基準／監督官庁レビュー／説明可能性（XAI）／ハルシネーション責任分界
• 重視すべきパートナー要件: 要件 5（セキュリティアーキテクチャ）、要件 6（契約柔軟性＝コンプラ責任分界）

医療

• 典型 PoC テーマ: 画像診断補助／電子カルテ要約／AI 問診／予約・受付最適化
• 本番化阻害要因: 医療機器プログラム承認（薬機法）／個人情報保護法／医師の最終判断責任
• 重視すべきパートナー要件: 要件 5（規制適合アーキテクチャ）、要件 4（医療現場ヒアリング力）
• 関連記事: ヘルスケア AI 画像診断、AI 問診システム

物流

• 典型 PoC テーマ: ラストワンマイル最適化／需要予測／倉庫内ピッキング AI／配車計画
• 本番化阻害要因: 多拠点ネットワーク／ドライバー労務規制（2024 年問題）／既存 TMS／WMS 連携
• 重視すべきパートナー要件: 要件 5（スケーラビリティ＝多拠点同時最適化）、要件 4（現場巻き込み＝ドライバー受容性）
• 関連記事: ラストワンマイル AI

本番化前 Go/No-Go チェックリスト（10 項目スコアシート）

PoC 完了時点で「本番化に進むかどうか」を客観評価する 10 項目スコアシートを提供します。各項目 0〜3 点で採点し、合計 24 点以上で Go、20〜23 点で条件付き Go、19 点以下で No-Go を推奨します。

このスコアシートは、開発会社にも採点に参加させることで、「本番化に必要な準備が何で、誰が責任を持つか」が PoC 完了時点で明確化 されます。

開発会社選定の RFP テンプレート（20 質問）

要件マトリクスを RFP（提案依頼書）に落とし込んだテンプレートです。提案依頼時にコピーしてご活用ください。

経営対話・KPI 翻訳（要件 1）

1. 直近 3 案件で、ROI 試算を 3 軸（コスト／売上／リスク）で提示した実例を見せてください
2. 「やらないリスク」を経営層に説明する際の語彙・フレームを教えてください
3. 経営会議向けエグゼクティブサマリーの過去事例（情報マスク版）を提示できますか

データエンジニアリング（要件 2）

4. データ品質モニタリングは何を採用していますか（dbt tests / Great Expectations 等）
5. メタデータカタログは何を採用していますか（DataHub / Amundsen 等）
6. マスキング・トークナイゼーション方針を教えてください
7. ベクトルストアとして何を採用していますか（生成 AI 案件の場合）

MLOps（要件 3）

8. 自社の MLOps 成熟度を Lv1〜Lv5 で自己評価し、各レベルの達成証跡（GitHub Actions YAML 等）を提示してください
9. 再学習のトリガー条件は時間／精度／データ量のどれを基本としますか
10. Drift 検知の実装事例を見せてください

現場ヒアリング（要件 4）

11. PoC 着手前のヒアリング工数の標準値を教えてください（業務オーナー／オペレーター／情シス／法務それぞれ）
12. 現場ヒアリングをリードするのは PM／コンサル／業務 SME のどれですか

本番アーキテクチャ（要件 5）

13. PoC 段階で本番アーキテクチャ図を併走して描く運用ですか
14. IaC は何を採用していますか（Terraform / Pulumi / AWS CDK 等）
15. 観測性スタックは何を採用していますか（Prometheus / Datadog / New Relic 等）

契約柔軟性（要件 6）

16. PoC は準委任、本番化は請負、運用は成果報酬――組み合わせ可能ですか
17. 本番化保証型契約（リリース日・KPI コミット・未達時減額）は対応可能ですか
18. 変更管理プロトコル（変更契約書フロー）はどう設計していますか

内製化伴走（要件 7）

19. ナレッジ移転の卒業条件をどう契約に落とし込みますか
20. OJT ローテーション・コードレビュー双方向参加・卒業後 SLA の標準パッケージを提示してください

これらに 明確な回答と過去事例を提示できる開発会社 を選定の最終候補とし、後述の評価表で比較してください。

候補開発会社の評価表（テンプレート）

3〜5 社の候補を以下の表で評価します。各社の RFP 回答を 0〜3 点でスコアリングし、合計点と内訳の偏りを見て選定します。

配点は MLOps（要件 3）と本番アーキテクチャ（要件 5）を重く 設計しています。PoC 止まりの根本原因が運用設計・スケーラビリティだからです。

選定の最終決め手は「合計点」ではなく 「要件 3・5・7 のいずれかが 0 点の会社を脱落させる」 ことです。本番化伴走の必須項目が欠ければ、他の点数で補えません。

koromo の「本番化保証型」契約と「30 日 PoC → 90 日本番化」プログラム

ここまで整理した 5 原因 → 7 要件 → MLOps 5 段階 → 契約類型 → 30/90 日フレーム → 業種別パターン → Go/No-Go スコアシート → RFP テンプレートをすべて統合した実行プログラムを、koromo は 「30 日 PoC → 90 日本番化」プログラム として提供しています。

プログラムの特徴

• 着手 1 週目から本番アーキテクチャを併走設計: PoC コードと本番コードの「作り直し」を最小化
• MLOps は初回リリース時点で Lv3 以上を要件定義: Drift 検知・自動再学習をリリース時に運用開始
• 契約は本番化保証型を標準提案: PoC 完了時点で本番リリース日・KPI 水準・未達時減額条件を明文化
• 内製化卒業条件を契約に組み込み: 「インシデント対応自社完了 N 件」など具体的指標で測定
• 業種別実績: 製造業の外観検査、金融の不正検知、医療の問診補助、物流の配車最適化など、業種特性に応じた本番化設計を提供

想定する読者像

• PoC を 2 回以上実施したが、いずれも本番化していない AI 推進部長
• 社内 PoC を抱えており、本番化フェーズを伴走できるパートナーを探している CTO・VPoE
• 既存 SIer から AI 案件を引き取ってもらえず、専門パートナーを探している情シス部門長

PoC 止まりからの脱却を本気で考えるなら、本記事で提示した RFP テンプレートを使って koromo を含む 3 社以上を比較してください。本記事はあくまで選定の 「公平な評価軸」 を提供するためのものであり、自社プロダクトの選定を強制するものではありません。

よくある質問

まとめ: PoC 止まりは「設計と契約」で解決できる

PoC 止まりは技術ではなく 設計と契約の問題 です。本ガイドから持ち帰っていただきたいのは次の 3 点です。

1. 逆問題として開発会社を選ぶ: 「PoC が止まる構造的 5 原因」を起点に、それを潰せる「パートナー 7 要件」を評価軸に置く
2. MLOps Lv3 以上と本番アーキテクチャ設計力を必須要件にする: 要件 3・5・7 のいずれかが欠落する会社は本番化伴走力に届かない
3. 契約条項に「本番化責任」を落とす: 「伴走」「成功責任」という口頭の言葉ではなく、リリース日・KPI・未達時減額条件として明文化する

PoC を 2 回以上実施したが本番化していない――そのときこそ、開発パートナー選定を見直すタイミングです。本ガイドの RFP テンプレートと 10 項目スコアシートで、3 社以上を比較してください。

• 関連: AI PoC の進め方完全ガイド — PoC 自体の進め方を 5 ステップで体系化
• 関連: AI 導入の進め方ガイド — AI 導入全体像とフェーズ設計
• 関連: AI 開発会社比較 2026 — 開発会社の総合比較
• 関連: AI ROI 計算ガイド — 投資判断のための ROI 試算
• 関連: LLMOps 実践ガイド — 生成 AI 案件の MLOps 詳細
• 関連: システム開発失敗事例 — 失敗パターンと回避策