生成AIのPoCとは？本番に乗らない理由と対策

「デモはうまくいったのに、半年経つと誰も開いていない」。生成AIのPoCについて、同様の話を何度も聞きます。

PoCと本番開発は、確かめている対象が違う

PoC（Proof of Concept／概念実証）は、本格的に作りはじめる前に「その考え方が成り立つか」を小さく試す工程です。生成AIでは精度が事前に読めないため、たいてい最初に置かれます。

違いは期間でも規模でもありません。PoCが見るのは、技術的に実現できるかどうかです。用意したデータで、狙った出力が得られるか。本番が引き受けるのは、毎日の業務のなかで使われ続けるかどうか。例外的なデータが届いたときにどうなるか、担当者が結果を信じられるか、間違いに気づけるか。

PoCの合格が本番の合格にならないのは、そのためです。

「試すのでデータをください」と頼むと、整ったものが集まります。悪気はありません。うまく処理できなさそうなものを、わざわざ選んで出す人がいないだけです。

一方、現場を流れているのは、書式が崩れたもの、項目が抜けているもの、長い付き合いの相手にしか通じない省略で書かれたものです。検証で出た数字は、選ばれたデータの上でしか成立していません。本番との差は、モデルではなくサンプルのほうにあります。

処理できなかったときに「できませんでした」と返ってくるなら、担当者はその1件だけを見れば済みます。

自信のない出力もそのまま返す作りになっていると、担当者はどれを信じてよいか分からず、結局は全件を見比べることになります。確かめる手間が、元の作業を上回る。その時点で使われなくなります。

「この作業をAIで自動化できませんか」。よくある相談ですが、これは課題ではありません。相談してきた人が、すでに出した答えです。

答えから始めると、その答えの精度しか測れません。課題から考えるなら、入力の経路そのものを変える、例外だけを人が扱う、といった手も並びます。どれが良いかは、その業務がなぜ今の形になっているのかを知らないと言えません。前提を知らないまま出した打ち手は、提案書の中でしか動きません。

PoCの成功率は、モデルを選ぶ前の段取りでかなり変わります。発注する側が決められるのは、おおよそ次の四つです。

現場で作業してみる。相談してくる人と、困っている本人はたいてい別です。その作業を一度自分でやってみると、例外がどこから来るのか、どの手順がいちばんつらいのかが分かります
実データをみる。実際に現場を流れているデータを、こちらで選ばずに受け取ります。「先週届いた分を全部」と期間で区切れば、例外が何割を占めるのかがそのまま分かります
確認にかかる時間を測る。精度だけでなく、担当者が結果を目で確かめる時間も併せて記録します
撤退要件と商用化基準を先に決める。どの結果が出たら撤退するのか、逆にどこまで届けば本番に進めるのか。この2つが着手前に書いてあるPoCは、乗らなかった場合でも次の判断に効きます

本番に乗らなかったPoCを振り返ると、原因はAIの精度ではなく、何を確かめるかを決めないまま始めたことにあります。決めずに走ると、確かめやすいものだけを測って合格にしてしまう。

AIを使うかどうかは、そのあとで決まります。使わない、という結論も含めて。

技術のことを、話せる相手はいますか。

つくる前の段階から、リリース後の運用まで。技術的なご相談だけでも、「泥臭く」お手伝いします。