見切り発車のAI PoCが引き起こす悲劇：技術的には成功でも「中止」になる……一体何が起こってる？

この記事のポイント

3つギャップが“負の連鎖”を引き起こす

　ある企業で、生成AIツールを全社員に展開した。ライセンスを一括購入し、IT部門は導入完了を「成功」とした。ところが半年後、利用ログを確認すると、全社員のおよそ3分の1は直近1ヵ月でログインした形跡すらなかったのだ。パソコンをあまり開かない社員がいることを鑑みても多すぎる。利用していないユーザーに「どうして使わないのですか」と聞くと、返ってきた答えはこうだった。

　「使わなくても業務が回ります」「何に使えばいいのかよくわからなくて」

　これはツールの問題ではない。展開前に整理されていなかったのは「誰が、どの業務に、どのように使うか」という問いだった。そしてまったく同じ構造が、生成AIや従来のAIのPoCでも繰り返されている。

　なぜ同じ場所で詰まるのか。複数のプロジェクトを横断して見えてきた構造を、筆者は同僚と3つのギャップに整理してみた。

　この3つはそれぞれ独立して起こるのではない。課題が不明確なまま進み始めると（ビジネス価値のギャップ）、何を検証すべきかが曖昧になり、必要なデータ要件も定まらない（利用可能性のギャップ）。データ要件が不明なままでは、必要な人材・体制の判断も難しくなる（AI人材・技術力のギャップ）。つまり、これらのギャップは連鎖するのだ。

第1の落とし穴：「誰の、何を、どれだけ」の定義

「まずPoC」が走り出す前に止まれなかった現場

　生成AIブームの中で「AIで何かやりたい」という期待が経営層から降りてくることがあるだろう。IT部門がベンダーに相談すると「まずPoCを」という流れになる。このとき、多くのケースで整理されていないのが、次の3つだ。

　この3つの問いに答えられないまま始まるPoCは、技術的に動いても「本番化すべきか」の判断材料にはならない。

　製造業界のある案件では、図面・仕様書・議事録を横断検索できるRAGシステムのPoCが始まった。精度は十分に出ていたが、最後まで「現場の誰が、1日何分使うのか」「その時間削減が業務上どんな価値を持つのか」が定義されなかった。PoCのレポートには「精度〇%達成」と書かれたように技術的には成功と言えるが、経営層はGo/No-Goを判断できず、プロジェクトはそのまま止まってしまった。

ベンダー側にも構造的な問題がある

　ここで正直に書く必要がある。この問題はクライアント側だけに起因しない。セールスやプリセールスと技術検証の間に距離がある場合、課題設定自体がAIで解ける問いになっていないまま案件が動き出すことがある。PoCが「失敗」するのではなく、そもそも成功しようがないPoCの始まりとなる。これはベンダー側も自覚すべき構造的な問題だ。

　それでもPoCが失敗した原因が「AIの限界」ではなく「問いの設定ミス」であることは、プロジェクトが終わるまで誰にも気づかれないことがある。だからこそ、問いを正しく立てることがすべての出発点になる。

KPI設計は「技術」と「業務」の2軸で

　技術KPIと業務KPIは別物であり、両方をPoC開始前に設計する必要がある。

　たとえば「精度92%達成」は技術的には成功に見える。しかし「その業務で92%の精度があれば工数がどれだけ削減されるか」が定義されていなければ、経営層はGo/No-Goを判断できない。技術KPIと業務KPIの2層で設計し、PoC開始前に業務部門と合意しておく事項となる。