Redditの r/PromptEngineering に、こんな投稿がありました。
投稿者はデータ系のコンサルタントです。
そして、自分のクライアント企業で数カ月前に目撃した出来事を書いています。
ざっくり要約してみましょう。
CEOがMetabaseの契約を切りました。
代わりにチームにClaudeを渡し、「ダッシュボードなんて無駄だ。AIに聞け」と命じたそうです。
数週間後、そのCEOから電話がかかってきました。
「どうやら何か壊したかもしれない」と。
以下は、その投稿とコメント欄から見えてきた教訓をまとめたものです。
何が壊れたのか
まず営業VPが数字を引っ張ってきました。
しかし、経理部門の数字とどうしても合いません。
掘ってみると、そもそも「アクティブ顧客」の定義が部署ごとに違っていたそうです。
さらにClaudeは、2022年以降クリーニングされていない古いテーブルを参照していました。
その結果、ありもしないリテンション数値を自信たっぷりに返してきたのです。
データチームはどうなったでしょうか。
新しい基盤の構築どころではありません。
「なぜAIの答えが間違っているのか」を社内に説明する業務で、一日が終わるようになりました。
投稿者の指摘が鋭いです。
Claudeは設計通りに動いていました。
Metabaseも悪くありません。
本当にMetabaseが果たしていた役割は、ダッシュボードを描画することではなかったのです。
「指標の定義について社内が会話せざるを得ない場」を、強制的に作り出すこと。
ところが経営者には、この裏の仕事が見えていませんでした。
コメント欄に集まった洞察
この投稿には、同業者や技術者から示唆に富む反応が寄せられました。
いくつかご紹介します。
あるユーザーは、システム移行の基本を思い出せと書いています。
動いているものを捨てる前に、新旧を並行稼働させる。
そして出力を比較し、差分の原因を特定する。
データの汚れなのか、不足なのか、定義違いなのか。
両者が比較可能な結果を出すようになって、やっと旧システムを退役させる。
教科書的な話ですね。
しかし、この手順をスキップする経営判断が後を絶ちません。
別のコメントでは、Wikipediaの「セカンドシステム症候群」の項目が紹介されていました。
これは、新しいシステムが古いシステムの制約を一気に取り払おうとする現象を指します。
そして、かえって過剰設計や破綻を招いてしまうのです。
名前がついていること自体、この失敗パターンが繰り返されてきた証拠と言えるでしょう。
Senior_Hamster_58 というユーザーのコメントが本質を突いていました。
大意はこうです。
ダッシュボードは利便性のレイヤーに見えていた。
しかし実は、経営者の思いつきに対する最後の防波堤として機能していた。
Claudeは得意技を発揮しただけ、つまり自信を持って文章を補完しただけなのです。
足りなかったのはガバナンスであって、Metabaseではありません。
Mean-Elk-8379 というユーザーの提案はもっと具体的です。
自分も先四半期に二度同じパターンを見たと言っています。
そのうえで、解決策はAIを捨てることではないと主張しました。
AIに、BIツールが担っていたのと同じセマンティックレイヤーを与えればいい。
具体的には、次のようなものです。
- 型付きのメトリクスレジストリ
- ディメンションテーブル
- 評価セット
こうした土台を用意しておけば、「リテンションは73%です」と出力された瞬間に追跡できます。
どのクエリが走ったのか、その定義が前四半期と一致しているのかを確認できるのです。
結果として、AIを活かしつつガバナンスも保てます。
同じ話が他でも起きている
投稿の最後で、著者はこう書いています。
別のコンサルタントからほぼ同じ報告を、先週聞いたと。
違う会社、同じ入れ替え、同じ結末でした。
コメント欄にも生々しい例がありました。
BigPP41 というユーザーの報告がそれです。
自社がSalesforceの契約を解約したとのこと。
理由は、「まだ存在しない自社製のvibe codedソリューション」への移行のためだそうです。
次はLookerの契約が切られる見込みだと言います。
「Claudeに頼めば自前でダッシュボードを書ける」と、経営陣は本気で信じているらしいのです。
ちなみにこのユーザーは、現在転職活動中と書いていました。
この騒動から何が引き出せるか
話の本筋は、AIの限界というより組織運営の問題です。
少なくとも三つの論点があります。
既存ツールの「裏の役割」が見えていない
既存ツールが実際に何を担っているのか。
経営者がこれを理解していない、という構造的な弱点があります。
Metabaseはダッシュボード描画ツールに見えますね。
しかし現場では、指標定義の合意形成装置として働いていました。
表面の機能だけを見て代替可能かを判断する。
すると、隠れていた役割ごと吹き飛ばしてしまうのです。
AIは混乱を解決せず、増幅する
AIは既存の混乱を解決してくれません。
むしろ増幅します。
ImmediateDisaster604 というユーザーが短く書いていました。
指標と定義が揃っていない会社にAIをBIの代わりに据える。
すると混沌を整理するどころか、拡大することになります。
データが汚れていれば、出力も汚れます。
しかもAIは自信満々に答えるので、読み手は汚れに気づきにくいのです。
Firthsuburbia というユーザーも、似た問題を報告していました。
Claudeは「データの紐付けに失敗したこと」を自己申告してくれません。
だから全員が、完全なデータセットを見ていると思い込んでしまうのです。
経営者の姿勢がそのまま結果に出る
現場の声を聞かないCEOは、ツールを変えてもまた同じ場所に戻ってきます。
kosta123 というユーザーの指摘が的を射ていました。
この話の核心はAIでもプロンプトエンジニアリングでもありません。
チームを信頼しない経営者が繰り返す、古典的な失敗なのです。
AIをBI用途に使うこと自体は筋が悪くない
念のため書き添えておきます。
データ分析にAIを組み込むアイデア自体は、間違っていません。
問題はやり方です。
Mean-Elk-8379 の提案が示す方向は現実的ですね。
まずガバナンスのレイヤー、つまり指標の定義、ディメンション、評価基準を整備する。
その上にAIを載せる。こうすればAIの出力は検証可能になります。
そして間違いがあっても追跡できるのです。
投稿者の話に戻りましょう。
Claudeを使ったこと自体が失敗だったわけではありません。
Claudeを使う前にやるべきことを飛ばしたのが失敗でした。
ダッシュボードを捨てる前にやることがあります。
ダッシュボードが果たしていた裏の仕事を、誰が引き継ぐのかを決める。
この順番を守らない限り、どんなAIを入れても結末は変わりません。
まとめ
Redditの投稿とコメント欄に目を通すと、ある事実が見えてきます。
AIをBIツールの代わりに据えるという判断は、単体のツール選定の問題ではありません。
もっと根の深い問題です。
組織が指標について合意を持っているか。
データが信用に足るか。
経営者が現場と対話できているか。
AIが出すアウトプットの正しさは、こうした土台の上にしか成立しないのです。
裏を返せば、土台さえ整えればAIは強力な相棒になります。
だからこそ、順番を間違えた会社の失敗事例は貴重ですね。
このRedditの投稿は、AI導入を検討している経営者と現場の双方にとって、読む価値のある警告と言えるでしょう。
