PoCを本番に繋げる4つの設計前提

PoCは成功した。しかし本番にはならなかった

概念実証（PoC）は成功した。デモも良かった。関係者は「これはいける」と言った。しかし、そこから本番実装に進む決裁が下りない。あるいは決裁は下りたが、本番環境で動かすと精度が出ない、コストが合わない、現場が使わない。

私たちが2020年の創業以来、100社を超える企業の支援を通じて見てきた限り、PoCから本番に進めないプロジェクトには共通する構造がある。 そしてその構造は、PoCの技術的な出来とは関係がない。

PoCと本番の間にある4つの断絶

断絶1: 成功基準が「動くこと」で設定されている

従業員350名規模のB2B SaaS企業で、社内ナレッジ検索のAI導入PoCが行われた。LLMを使ったRAGシステムのプロトタイプを2週間で構築し、デモで社内文書の検索精度を見せた。経営層は「面白い」と評価した。

しかし、「面白い」から先に進まなかった。「これを本番に入れたら、どの業務が、どれだけ改善するのか」は誰も答えられなかった。PoCの成功基準が「技術的に動くか」である限り、「動いた、で？」の壁を超えられない。

断絶2: PoCのデータと本番のデータが別物

同じ企業で、PoCでは手動で選定した「きれいなデータ」を使っていた。整形済みのFAQドキュメント50件。検索精度は90%を超えた。

本番データは5,000件のSlackログ、社内Wiki、顧客対応マニュアル。フォーマットはバラバラ、重複あり、古い情報も混在。検索精度は60%に落ちた。PoCが「きれいなデータ」で行われている場合、その精度は本番を予測しない。

断絶3: PoCの担当者と本番の利用者が異なる

従業員280名規模の製造業で、AIによる需要予測のPoCが実施された。データサイエンティストが構築したモデルは精度85%。経営会議で「これは使える」と評価された。

しかし、本番で予測値を使って発注量を調整するのは現場の購買担当者だった。購買担当者にとって、AIの予測値は「ブラックボックスが出した数字」であり、自分の経験に基づく判断を覆す根拠としては信頼できなかった。

断絶4: 本番化のコストが見積もられていない

PoCは2週間で100万円。経営層は「安いし試してみよう」と判断した。しかし、本番化に必要な作業——データパイプラインの整備、セキュリティ対応、運用監視の構築、エラーハンドリング、ユーザー教育——を見積もると、追加で2,000万円が必要だった。PoCの100万円と本番化の2,000万円の間に20倍のギャップがある。

PoC地獄の構造

これがPoC地獄の構造だ。

PoCの前に設計すべき4つの前提

4つの断絶は、いずれもPoCが始まる前に設計されるべき前提が欠落していることに起因する。

前提1: PoCの成功基準は「本番化のGo/No-Go判断に必要な情報が揃うこと」で設定する。 「動くかどうか」ではなく、「本番に進む意思決定に何が必要か」を先に定義する。これがないと、PoCは「面白かったね」で終わる。

前提2: 本番に近いデータで検証する。 きれいなサンプルで得た精度は、本番の予測にならない。本番データの汚さを最初から織り込んだ設計が必要だ。

前提3: 本番の利用者を巻き込む。 PoCを作る人と使う人が異なるとき、技術的精度と業務的信頼の間に断絶が生まれる。「この予測値が出たら、あなたは判断を変えるか」を先に聞く。

前提4: 本番化コストの概算をPoC承認時に提示する。 PoC100万円の承認時に「本番化は追加で1,500〜2,500万円の見込み」を併記する。全体像なしの承認は、後の「こんなにかかるのか」ショックを生む。

これらの前提をどのような順序で、誰と、どのフォーマットで設計するか——その実装方法論はSemantic SI完全ガイドで体系化している。

この規律が効かないケース

率直に書いておく。

探索段階のPoCには、この前提設計は合わない。 「そもそも何に使えるか分からないから試す」という初期探索のPoCに、最初から本番化コストの概算を求めるのは過剰だ。上記は「ある程度ユースケースが絞れた段階」のPoCに適用するものだ。

組織の意思決定構造が曖昧な場合、PoCの成功基準を誰と合意するかが決まらない。 前提1の前提は「意思決定者がPoCの設計に関与できること」だ。この条件が満たされない場合、別の問題を先に解く必要がある。

PoC地獄の正体

PoCが本番にならないのは、PoCの精度が足りないからではない。PoCの「前提」が設計されていないからだ。

あなたの組織で、PoCの成功基準が「技術的に動くか」で設定されている。本番データではなく整形済みデータで検証している。PoCを作る人と使う人が別れている。本番化コストが見積もられていない——いずれかに該当するなら、次のPoCを始める前に前提の設計から始めることを勧める。

この問題はPoC固有ではない。DXプロジェクト全体に共通する、もっと大きな構造問題の一部だ。その全体像は「中堅企業のDXが失敗する3つの構造的問題」で整理している。