AI導入が止まる本当の理由は、モデルではなくデータにある
PoCは動いたのに本番に乗らない。その原因の大半はモデルの性能ではなく、AIに渡すデータの定義・品質・鮮度にあります。止まる三つのパターンと、先に直すべき順番を整理します。
「AIで売上を予測したい」「問い合わせ対応を自動化したい」。相談の入り口はさまざまですが、途中で止まるプロジェクトには共通点があります。モデルが悪いのではありません。モデルに渡しているデータが、AIが使える状態になっていないのです。
PoCは動く。本番で止まる
PoCの段階では、担当者がデータを手で集め、整え、きれいなCSVをモデルに渡します。だから動きます。ところが本番では、そのデータは毎日自動で集まってこなければなりません。売上はSaaSの管理画面に、ユーザーはアプリのログに、広告費はスプレッドシートにあり、それぞれ更新のタイミングも粒度も違う。手で整えていた工程を自動化しようとした瞬間に、「そもそも基盤がない」ことに気づきます。
止まる三つのパターン
1. 指標の定義がない。 「アクティブユーザー」を、営業は月に一度でもログインした人、プロダクトは週に三回以上使った人と数えている。AIにどちらを渡すかで答えは変わります。定義が文書にもコードにもなっていない会社では、AIの回答を誰も検証できません。
2. 品質を誰も見ていない。 欠損、重複、タイムゾーンのずれ、途中で変わったIDの体系。人が見ているダッシュボードなら「なんか変だ」で気づけますが、AIは変なデータからも、もっともらしい文章を作ります。品質テストのない基盤の上のAIは、自信のある間違いを量産します。
3. 更新が止まる。 最初に作った人が異動や退職でいなくなり、パイプラインが止まっていることに三ヶ月後に気づく。AIは古いデータでも答え続けるので、止まったことにすら気づきにくいのです。
先に直す順番
直す順番は決まっています。まず定義です。意思決定に使う指標を10個に絞り、それぞれの計算式をコード(私たちはdbtを使います)として書き、全員が同じ定義を参照する状態をつくります。次に更新です。手作業のExcelをなくし、データソースから自動で集まる経路を一本通します。三つ目が品質で、欠損や重複を検知するテストを更新の経路に組み込みます。ここまで来て、はじめてAIを繋ぎます。
順番を逆にすると、つまり先にAIを繋ぐと、AIの出力を疑う時間で人が疲弊し、「AIは使えない」という結論だけが残ります。
まとめ
AI活用の相談を受けたとき、私たちが最初に見るのはモデルの選定ではなく、いま意思決定に使っている数字がどこにあり、誰が定義し、どう更新されているかです。そこが整えば、AIは驚くほど素直に動きます。基盤が先、AIはその上。この順番を守るだけで、止まるプロジェクトの多くは止まらなくなります。