「とりあえず PoC をやってみましょう」——この一言から始まったプロジェクトが、半年後に静かに棚上げされていく光景を、私たちは何度も見てきました。技術検証は成功した、デモも動いた、経営層の反応も悪くなかった。それなのに本番運用には届かない。担当者は次の PoC テーマを探し始め、現場は「またあの話か」と冷めていく。
PoC 止まりは、もはや一企業の問題ではなく、生成 AI や DX の文脈で日本中の組織が踏んでいる地雷のようなものです。正直に言うと、私のところでも何度かやらかしました。だからこそ、同じ業界・同じ規模・同じツールを使っていても、PoC を越える会社と越えられない会社がはっきり分かれる、というのが今の率直な実感です。差は技術力でも予算でもありません。最初の一歩の選び方にあります。
先に答えを書きます
結論を 3 行で言うと、こうなります。
PoC 止まりを越えるかどうかは、最初の一歩を「技術検証」ではなく「業務と意思決定の検証」として設計しているかどうか、ほぼそこで決まります。技術が動くかではなく、誰がいつ何を判断するかを先に決めている。この 1 点が分かれ目です。
うーん、これだけ書くと身も蓋もない話に聞こえるんですが、現場の観察を重ねるほどこの結論に戻ってきてしまいます。生成 AI のように技術進化が速い領域では、「技術が動くか」はわりとすぐ検証できます。むしろ、動いた後で誰がそれを使い続け、誰がコストを払い、誰が運用を止める判断をするかが決まっていないせいで、本番化の議論が始まらない。
PoC の成否は、デモが動いた瞬間ではなく、初回ミーティングのホワイトボードでほぼ決まっている。
これが、ここ数年で私が一番納得してしまった経験則です。以降のセクションでは、なぜ止まるのか、越える会社が何を決めているのか、逆に何をやってはいけないのかを順に書いていきます。
なぜ PoC は止まるのか——よくある 3 つの構造
PoC が本番に届かない理由は、技術選定の失敗ではなく、もっと構造的なところにあります。現場で繰り返し観察してきたのは、次の 3 つです。
構造的な詰まり | 起きている現象 | 越えた組織のやり方 |
|---|---|---|
検証対象が技術に偏る | 「精度が出るか」だけが論点になり、業務に乗るかが抜ける | 業務フロー図を先に書いてから技術検証に入る |
撤退基準と本番判断基準が別物 | PoC は「動いたら成功」、本番化は「ROI が出るか」で別の評価軸になる | 同じ言葉・同じ KPI で両方を書く |
現場運用者が PoC 後半まで登場しない | できあがった頃に呼ばれて「これじゃ使えない」となる | 初回打ち合わせから運用者が参加している |
1 つ目の「検証対象が技術に偏る」は、特に生成 AI の文脈で繰り返し起きています。精度 80% を超えたから成功、と報告書には書かれるんですが、現場から見れば「残り 20% を人がチェックするなら今までと変わらない」になる。技術指標と業務適合は別物なんですよね。
2 つ目の「撤退基準と本番判断基準が別物」は、もっと地味だけど致命的です。PoC では「精度が出れば OK」と言っていたのに、本番化の稟議では突然「ROI は」「運用コストは」「セキュリティ要件は」と別の言葉で評価される。これだと PoC が成功しても本番化のスタートラインに立てません。越えた組織は、最初から本番化時の判断基準を PoC の成功基準として書いてしまいます。
3 つ目は単純に、PoC を組む段階で運用者が忙しすぎて呼ばれない、という現場あるあるです。でも、できあがってから見せると、運用者は自分が決めていないものを引き受けようとはしません。これは責任の話なので、後から巻き取るのは難しい。
越える会社が最初の一歩で決めていること
では、PoC を越える組織は最初に何を決めているのか。観察した範囲では、初回ミーティングのホワイトボードに次の 4 項目が必ず書かれています。
- 本番化したときの運用者は誰か（個人名または役割名で）
- そのコストを誰の予算で払うか（情シス予算か、事業部予算か）
- 撤退基準は何か（どの数字を下回ったらやめるか）
- 成功時の意思決定者は誰か（本番化を決裁する人）
書いてみるとどれも当たり前なんですが、これが PoC キックオフの場でちゃんと言語化されている案件は、私の体感だと半分もありません。たいていは「いやそれは追々」「まずは技術検証から」となって、後回しになる。後回しにされた瞬間に、その PoC は止まる側に分類されます。
注意点として、これは大規模な要件定義の話ではないんです。A4 一枚に収まる程度の合意で十分です。「営業事務の◯◯さんが運用する」「営業部予算で年 200 万円までなら本番化を検討する」「精度 70% を下回ったら撤退」「本番化判断は営業部長」——このくらいの粒度。
逆に言うと、A4 一枚すら書けない PoC は、関係者の頭の中に「この後どうなるか」の像がまだ存在していない、ということです。像のない PoC は、技術がどれだけうまく動いてもゴールに辿り着けません。
ちなみにこの A4 一枚は、PoC が失敗したときにも効きます。撤退基準が言語化されていれば、「失敗」ではなく「撤退判断」として処理できる。PoC を止める判断は、想像以上に組織にとって難しい意思決定なんですよね。最初に基準を書いておくと、止めるときの心理的コストが下がります。関連して、生成 AI の業務実装で最初に必ず躓く 3 つの設計判断 でも近い論点を書いています。
逆に、やってはいけない最初の一歩
ここからは率直に、失敗パターンを書きます。白状すると、私自身が過去にやらかしたパターンも混ざっています。
- 「生成 AI で何かやってみたい」から始める PoC
- ベンダーに丸投げで PoC を組む
- 経営層の興味だけで、現場合意なくスタートする
- 成功指標を「動くこと」に置く
この 4 つの共通点は、判断の主語が曖昧なまま動き出していることです。「何かやってみたい」のは誰か、「ベンダーに任せた結果を引き受ける」のは誰か、「経営層の興味」が冷めた後に推進するのは誰か。主語が決まっていないと、PoC は走り出してしまえば誰も止められません。
主語のない PoC は、誰も止められない。
これは PoC の最大の落とし穴だと思っています。「動いている以上、止める理由がない」という空気だけで、ずるずる延長される。半年後に予算が切れて自然消滅、というのが定番のオチです。
特に怖いのが「経営層の興味だけで始まる PoC」で、これは私のところでも何度か立ち会いました。経営層は他社事例や講演で刺激を受けて「うちもやろう」となるんですが、現場合意がないまま降りてくる指示は、現場から見ると「優先度の押し付け」になります。現場は表向き協力しつつ、本気で運用する気はない。そして PoC が終わった頃には経営層の興味も別のテーマに移っていて、誰も本番化を推進しない。
避け方はシンプルで、最初の一歩を技術担当者と経営層だけで決めないこと。運用する現場の人を必ず初回から入れる。そのうえで、前のセクションで書いた A4 一枚を全員で書く。これだけで、止まる側の PoC はかなり減ります。
DX 全体の話として、「DX 戦略」という言葉が、もう半分使えなくなった理由 も併せて読んでもらえると、なぜ「主語のなさ」が今これだけ問題になっているのかが見えやすいと思います。
ある中堅製造業で起きた、2 度の見積もり PoC
匿名で具体的な事例を 1 つ書きます。
ある中堅製造業で、見積もり業務の自動化をテーマに 2 度の PoC を実施した案件です。1 回目は情シス主導で生成 AI を使った試作を行い、技術的には精度 80% を超えたものの、現場は「最後に人がチェックするなら手作業と変わらない」と受け取り、運用には乗りませんでした。情シスからすれば「精度が出たのに採用されない」、現場からすれば「自分たちが決めていないものは引き受けられない」。両者の言い分はどちらも正しくて、構造的に噛み合っていなかった、というのが今振り返っての評価です。
2 回目は組み立てを変えました。最初の打ち合わせから営業事務 2 名を入れ、「どのケースは AI に任せ、どのケースは人が判断するか」を業務フロー図に書き起こしてから技術検証に入りました。具体的には、過去 1 年分の見積もり依頼を分類し、定型パターン 4 割・準定型 3 割・個別判断 3 割に整理。AI に任せるのは定型パターンの 4 割に絞り、残りは人が判断する設計にしました。
結果、対象を全見積もりの 4 割に絞ったうえで本番運用に移行し、6 ヶ月で対象範囲の処理時間が約 30% 削減されました。技術的な精度は 1 回目の方が高かったにもかかわらず、本番に届いたのは 2 回目です。
差は、最初の一歩で「誰がどのケースを判断するか」を決めたかどうか、それだけでした。技術選定はほぼ同じ、予算もほぼ同じ、ベンダー（私たち）も同じ。違いは、初回ミーティングのホワイトボードに何を書いたか、だけです。なお、似た構造の話を 「AI を入れるべき場所」を判別する 5 つの問い でも別角度から書いています。
PoC テーマを持ち寄って、最初の一歩を一緒に書く
ここまで読んでいただいて、「うちの PoC、止まっているやつあるな」と思い当たった方もいるかもしれません。あるいは、これから組もうとしている PoC の設計で迷っている方もいると思います。
私たちは、こうした「PoC の最初の一歩をどう設計するか」をテーマにした論点持ち寄り型の相談を受けています。営業目的の打ち合わせではなく、現状の PoC テーマや過去に止まった案件を持ち寄っていただいて、A4 一枚の合意項目を一緒に書いてみる、という時間です。技術選定の前段、業務と意思決定の所在をどう設計するかの議論が中心になります。
正解は私も知らないですが、止まる PoC と越える PoC の構造的な違いだけは、現場で繰り返し観察してきました。同じ地雷を踏まないために、設計の最初の段階で少しだけ視点を増やしてもらえれば、と思っています。
関連記事：
