生成AIのPoCが本番に乗らない理由

デモは、驚くほどうまく動きました。半年後、その仕組みを開く人は、社内に一人もいませんでした。壊れたからではありません。使う理由が、どこにもなかったからです。

原因は精度ではありません。確かめていたものが、そもそも違ったのです。

生成AIのPoCで確かめるべきなのは「作れるかどうか」ではなく、「毎日使われるかどうか」です。

100枚のうち80枚を読み取れて、本番化が決まりました

地方で食品を扱う卸売の会社を、思い浮かべてください。

注文はメールとFAXで届きます。担当者がそれを読んで、社内のシステムに手で打ち込む。忙しい時期には、一日中これをやっている。

「注文票の入力を、AIで自動化できませんか」。業務部の部長が、そう切り出しました。一日中入力しているのは、部長ではありません。

PoCは順調でした。過去の注文票を100枚持ってきて、書いてある品名と数量を読み取り、入力欄に流し込む仕組みを2週間ほどで作ります。

100枚のうち80枚は、品名も数量も正しく入りました。デモを見た人たちは「8割なら十分だ」と判断し、その場で本番化が決まりました。

ここまで、間違ったことは何ひとつ起きていません。

朝、FAXが一晩ぶんの注文票を吐き出します。担当者はそれを一枚ずつ手に取ります。

一枚目。「いつものやつを、いつもの数で」。二枚目。「先週と同じ。ただし木曜着で」。

品名も数量も、そこには書かれていません。長い付き合いの取引先ほど、こういう書き方をしてきます。届く注文票の、およそ半分がこれです。残りの半分は、書式の整った紙で届きます。

PoCで作ったAIは、この紙にも数字を返しました。「先週と同じ」を読んで、それらしい品番と数量を入力欄に並べます。

参考にはなります。けれど、その数字が合っているかどうかは、元の紙を見ないと分かりません。

だから担当者は、結局すべての紙を一枚ずつ見比べます。

確かめる手間のほうが、最初から打ち込む手間より大きくなりました。

PoCのとき、私たちは担当者にこう頼みました。「読み取りを試すので、過去の注文票を100枚ください」。

担当者は、読みやすい注文票を選んで渡してくれました。悪気はありません。「読み取りを試す」と言われて、読めない紙を出す人はいないからです。

だから100枚のなかに、「いつものやつで」と走り書きされた紙は一枚もありませんでした。 80枚読めた、というのはこの100枚での話です。

AIは走り書きの紙を一枚も読まないまま、本番に出ていきました。

PoCで使った整った注文票の小さな山と、現場に実際に届く走り書きだらけの大きな山を並べたイラスト

左がPoCに持ち込まれた注文票で、右が現場に届くものです。数えていたのは、左の山だけでした。

このPoCが考えていなかったことが、もうひとつあります。間違え方です。

読み取れなかったときに「読み取れませんでした」と言ってくれれば、担当者はその一枚だけを見れば済みました。けれど、自信ありげに数字を返してくる相手では、どれを信じてよいのか分かりません。

だから全部見る。そして、使わなくなる。

「注文票の入力を、AIで自動化できませんか」。これは課題ではありません。 部長がすでに考えた、解決策です。

解決策から始めると、その解決策の精度しか測れません。だから私たちは読み取りの枚数を測り、 80枚で合格にしました。

課題から考えるなら、手は他にもあります。

どれも、確かめるまでは言えません。取引先には取引先の事情があります。 FAXでなければ回らない会社もある。フォームを渡しても、使ってもらえないかもしれない。

前提条件を知らないまま出した打ち手は、提案書の中でしか動きません。

私たちが最初にすべきだったのは、モデルを選ぶことでも、100枚を集めることでもありませんでした。担当者の隣に一日座ることです。

座って初めて、分かることがあります。走り書きは特定の3社からしか来ないのかもしれない。その3社には、FAXでなければ困る事情があるのかもしれない。そして担当者は、入力より電話の問い合わせのほうを、つらいと思っているかもしれない。

困っていることは、聞かなければ分かりません。 そして最初に相談してくる人は、たいてい困っている本人ではありません。

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

AIが本番に乗るかどうかは、モデルではなく、問いの立て方で決まります。

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

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