「AI導入案件の多くはPoCで止まる」。この指摘自体は、もう目新しくもない。コンサルの資料にも、ベンダーのセミナーにも、同じ言葉が並ぶ。
だが、そこで語られる原因——「目的が曖昧」「経営のコミットが弱い」——は、現場にいる立場からすると表層的だと感じる。目的が明確で、経営が乗り気でも、PoCは止まるときは止まる。私は実際に、技術検証としては成功と言える結果が出たのに、その先で止まりかけた案件を経験している。
私は日本企業のクライアント先でFDE（Forward Deployed Engineer）として、AIシステムの企画から実装、現場に定着するまでを仕事にしている。その立場で見てきた「PoCが死ぬ本当の理由」は3つある。そしてそのどれもが、PoCが始まる前の設計の時点でほぼ決まっている。
目次
理由1: PoCの成功条件が「動くこと」に設定されている
多くのPoCは「技術的に実現可能か」を検証する。精度が◯%出るか、応答が◯秒以内か。そして目標をクリアし、報告書に「有効性を確認」と書かれ——そこで止まる。
なぜか。本番導入の成功条件は「動くこと」ではなく「業務が変わること」だからだ。
私が経験した案件でも、検証としては成功だった。それでも本番化がすんなり進まなかった理由のひとつは、「動いた後」の設計がPoCのスコープに入っていなかったことだ。AIの出力を誰が確認するのか、間違っていたら誰がどう直すのか、責任は誰が持つのか。この問いに、PoCの成果物は何も答えてくれない。検証していないのだから当然だ。
「技術的成功」と「業務に組み込める状態」の間には、検証項目の設計時点で埋めておくべき溝がある。ここを飛ばしたPoCは、成功しても前に進めない。
理由2: AIの「たまに間違える」を、業務フローが受け止められない
生成AI特有の問題がこれだ。デモは「うまくいった1回」を見せればいい。だが業務は毎回動かなければならない。LLMは同じ入力でも揺らぐし、まれに自信満々に間違える。
従来のシステム導入は「動くか、動かないか」の世界だった。生成AIでは「だいたい動くが、たまに間違える」という第三の状態を、業務フローの側が受け止める必要がある。人間のレビューをどこに挟むか。間違いをどう検知するか。間違えたときの被害をどう限定するか。
私の経験では、まさにこの誤り処理・確認フローの設計が用意されていなかったことが、PoCの先に進めない要因になった。精度を上げる努力はPoCの中で散々やる。しかし「間違えたときにどうするか」は、誰の宿題にもなっていなかった。
重要なのは、これがモデルの精度の問題ではなく業務設計の問題だということだ。だからベンダーに丸投げできないし、精度99%を待つ必要もない。「間違えても業務が壊れない仕組み」を業務側に作れば、精度90%でも本番に載る。逆にその仕組みがなければ、精度が99%でも「残り1%が怖い」の一言で止まる。
理由3: 定着の担い手が、体制図のどこにもいない
システムが本番に載っても、まだ終わりではない。現場が使わなければ、静かに死ぬ。
導入プロジェクトには体制図がある。だがそこに載っているのは「導入するまで」の登場人物だけだ。導入後、現場で「これどう使うんだっけ」に答える人。使われ方を見て改善を回す人。新しいメンバーに使い方を引き継ぐ人。——定着の担い手は、私が見てきた案件でも、誰にも割り当てられていなかった。
ベンダーは納品で契約が終わる。プロジェクトチームは解散する。現場は日常業務で手一杯。導入の熱量が最も必要なのは「導入した後」なのに、体制はそこで一番薄くなる。この構造がある限り、どんなに良いシステムでも定着は運任せになる。
FDEの動き方: 定着から逆算してPoCを設計する
3つの理由への対応は、突き詰めれば1つの原則になる。定着から逆算することだ。
- PoCの成功条件に「業務がこう変わる」を含める。 精度の検証と並行して、誤り処理・確認フロー・責任の所在を検証項目に入れる。「動いた後」を後回しにしない
- 「間違えても壊れない仕組み」を業務側に設計する。 人間のレビューポイント、間違いの検知、被害の限定。精度改善とフロー設計は両輪で進める
- 定着の担い手をプロジェクト初期に指名する。 現場のキーパーソンをPoCの段階から巻き込み、「導入後に面倒を見る人」を体制図に最初から書き込む
FDEという職種の価値は、この「技術と業務の間」を埋める動きを、外部の人間でありながら現場に入ってやることにある。記事①でも書いたが、日本のAI導入プロジェクトには、導入したシステムが業務に定着するまで見届ける人間がいない。PoCの設計段階からその空白を埋めにいくのが、FDEの仕事だ。
まとめ
PoCが止まるのは、技術が未熟だからでも、経営が弱腰だからでもない。
- 成功条件が「動くこと」で止まっていて、「業務が変わること」まで設計されていない
- AIの「たまに間違える」を受け止める業務フローがない
- 定着の担い手が体制図にいない
——この3つが、PoCが始まる前から結末を決めている。裏を返せば、PoCの設計時点でこの3つを潰せば、「PoC止まり」の大半は構造的に避けられる。
この辺りの実践知は、今後もこのブログで書いていく。
企業のAI導入をFDEとして支援しています。ご相談はサービス紹介ページから。
