編注
原文：「How the best AI-ready product teams get a head start on building right」。翻訳にあたり若干加筆修正を行っています。
悪いのはAIではなくデータだった──27度のマイアミに冬ジャケットが届いた理由
まずは、Google CloudでAIデータコンサルティングの責任者を務めるエイダ・ラウ氏が、MXPサンフランシスコ（Mixpanelが世界各都市で開催する、プロダクトやデータの責任者向けサミット）のセッションで語ったエピソードを紹介します。
想像してみてください。気温は27度。アメリカのマイアミに本拠地を置くグローバル小売企業の倉庫は、入荷したばかりの冬用ジャケットで埋め尽くされています。店舗マネージャーたちは、届いたばかりの商品を呆然と見つめるばかり……。
これは、彼らが使用しているAIエージェントが、カレンダーの日付が11月であること、店舗が営業中であることを確認した上で、設計どおりに「出荷をトリガー」した結果でした。エージェントは、データが指示したとおりに実行しただけです。
AIに不具合はなかった。その基盤となるデータに問題があった
この一件は、AIプロダクトを開発するチームの大半が依然として目を背けている問題を、最も鮮明に浮き彫りにしました。AIを正しく機能させることは、エンジニアリングだけの課題ではなく、データの側にもまたがる課題なのです。そして、このギャップこそが、本来は巧みに設計されていたはずのAI機能の多くが正しく機能しなくなる原因となっています。
「ゴミを入れれば、ゴミが出てくる」──AIがこの法則を悪化させる理由
「ゴミを入れれば、ゴミが出てくる」。古くからあるこの原則は、今も変わらず通用します。質の悪いデータが入れば、質の悪い出力しか得られません。ただしAIの登場によって、ここに新たなやっかいさが加わりました。AIは、質の悪いデータに対しても、まったく揺るぎない自信を持って処理を実行してしまうのです。
マイアミで冬ジャケットの一件が起きたのは、データモデルが必要な要素を表面的にはそろえていたからです。プロダクトのエンティティ（データモデル上で商品を表す単位）、店舗の所在地、発売月。しかし、そこには天候との関連性が欠けていました。気温の属性や季節性のロジックといった、「11月のマイアミは11月のシカゴとは違う」とAIエージェントに伝えられる要素が、何もなかったのです。だからこそAIエージェントは、利用可能なデータを確認しても矛盾するシグナルを見つけられず、そのまま行動を起こしました。
ラウ氏の指摘は、「AIが愚かだった」ということではありません。AIはその役割を完璧に果たしています。問題は構造の側にあり、そして構造の問題は、自ら姿を現してはくれません。それは、締切を守るというプレッシャーの下で急いで構築されたデータモデルの中に、静かに潜んでいます。そのモデルを作成した人は、目の前のダッシュボードの課題を解決することだけに注目していました。6か月後に自律型AIエージェントがそのデータをどう使うかは、一切考慮されていなかったのです。
これこそが、AIプロダクトアナリティクスが向き合わなければならない課題です。
AI機能は、動かなくなるまでは正常に動作しているように見えます。そしてユーザーがそれに気づいた時には、すでに手遅れなのです。
データモデリングが依然として機能しない理由とは
「データモデルの構築と維持管理における現在のプロセスは遅く、直線的であり、AI機能のリリースペースに常に後れを取っている」とラウ氏は指摘しています。
データチームの多くが身に覚えのあるシナリオを挙げてみましょう。
- 経営陣は、すでにリリース済みのプロダクトについて新たな指標を必要としている。
- データチームは大慌てで適切なテーブルを探し出して矛盾を解消し、腰を据えて取り組む時間があるかどうかを判断しようとする。だが大抵は、急いで済ませることになる。
- 新しいテーブルが作成され、新しいパイプラインが構築され、問題は解決したことにされる。
- 構造的な負債は積み重なり、次のチームがそれをすべて引き継ぐことになる。
これを何度も繰り返すうちに、技術的には動くけれども、誰も完全には信頼できないデータモデルが出来上がってしまいます。
AIの文脈でこれが特に危険なのは、エージェントがデータの品質を判断できないからです。そのテーブルが締切に追われて作られたもので、必ずしも「真実の源」とは限らない。エージェントは、そんな事情を知りません。ただクエリを実行するだけです。
かつてデータガバナンスでは、主に事後の後始末に重点が置かれていました。エージェント型AIの時代において、それでは間に合いません。
