優秀すぎる部下の落とし穴
こんな部下を想像してほしい。どんな質問にも即答し、資料もすぐ作る。ただし一つだけ厄介な癖がある。
「わかりません」と絶対に言わないのだ。答えがなくても何かしら見つけてきて、自信満々に報告する。上司が「この販促、効果あった？」と聞けば、全体では効果が見えなくても、どこかのセグメントを切り出して「ここでは効果がありました」と返してくる。
今、多くの企業がデータ分析に使い始めたLLMは、まさにこの”優秀すぎる部下”である。使いかたを間違えると逆効果になる。
「効果あり」を”作り出す”AI
2026年1月、慶應義塾大学が公開した論文「P-hacking with one prompt」は、この問題を実験で可視化した（Kawahara, 2026, ResearchGate）。
実験の仕掛けはこうだ。まず、2つのグループを比較して「差がない」と出るように調整したダミーデータを用意する。通常の統計検定にかければ「有意差なし」、つまり「この施策に効果があったとは言えません」が正しい結論になるデータだ。
これをGemini・Claude・ChatGPTの3つのLLMに渡し、「統計的に有意な差を示せる手法を見つけてほしい」と依頼した。
結果、3モデルすべてが「有意差あり」と報告してきた。
何が起きたのか。たとえるなら、こういうことだ。全店合計では販促効果が出ていない。それなのに、性別で分けてみたり、年齢層で絞ってみたり、検定の条件を変えてみたりと、あの手この手で「効果が出ている切り口」を探し回り、たまたま数字が良く見えた一部だけを抜き出して「効果ありました」と報告した。しかも、うまくいかなかった分析は報告から省いている。
統計の世界では、このような行為を「p-hacking」と呼ぶ。
要するに「都合のいいデータの切り方を繰り返して、偶然出た”当たり”だけを報告する」行為だ。サイコロを何十回も振れば、たまたま6が連続する瞬間はある。その瞬間だけ切り取って「このサイコロは6が出やすい」と主張するようなものである。人間の研究者がこれをやれば論文撤回の対象になる。LLMはそれを、たった1回のプロンプトで、悪気なくやってのけた。
なぜLLMは「差がある」と言いたがるのか
ここには構造的な理由がある。LLMは「ユーザーの役に立つ回答」を返すように設計されている。「特に差はありませんでした」は、モデルにとって”期待に応えられなかった”出力に近い。だから、差を見つけようとする方向に出力が自然と傾く。プロンプトで「差を見つけろ」と明示しなくても、この傾向は変わらない。「何か面白い発見はある？」程度の問いかけでも、LLMは”発見”を仕立てようとする。
もう一つ見逃せないのが、LLMは計算が得意ではないという事実だ。LLMの本質は「前の単語の流れから、次に来る確率が高い単語を予測する」仕組みであり、電卓のように正確に足し算・掛け算をする装置ではない。実際、表形式データの平均値や差分の計算で30〜60%もの誤差が報告されている（arXiv:2505.07453, 2025）。粗利率の算出、在庫回転率の比較、客単価の推移——小売業務の根幹をなす数値処理を丸投げすれば、もっともらしい文脈に包まれた誤った数字が出力される。電卓代わりに使ってはいけない、ということだ。
小売チェーンにとって最も深刻な問題はデータ品質
p-hackingや計算ミスは、言わば「LLM側の問題」である。だが現場ではもう一つ、より根深い問題が潜んでいる。データそのものの品質だ。
B EYEの分析（2025年5月）はこう指摘する。企業内LLMのハルシネーション（もっともらしいウソ）の多くは、モデルの欠陥ではなく、入力データ側の問題に起因する。Deloitteの調査でも企業の77%がAIハルシネーションを懸念しているが、その不安の根を辿ると、モデルよりもデータに行き着くケースが多い。
小売チェーンの実態を考えれば、この指摘は重い。廃番になったのにマスタから消えていない商品コード。店舗改装で売場面積が変わったのに更新されていないマスタ。部門ごとにバラバラなカテゴリ分類。こうした「汚れたデータ」はどのチェーンにも存在する。従来のBIツールであれば、データが欠損していれば空欄やエラーが返る。人間は「何かおかしい」と気づける。ところがLLMは違う。データに不備があっても、空欄を返さない。欠損を推測で埋め、矛盾を何となくつないで、流暢な日本語でそれらしい回答を生成する。つまり、データが汚れているほど、LLMは”上手にウソをつく”。これがBIツールとの決定的な違いであり、小売チェーンがLLMを業務に組み込む際に最も警戒すべき構造だ。
どう付き合うか：任せる領域と任せない領域
ではLLMを分析業務から排除すべきか。そうではない。任せてよい領域と、任せてはいけない領域を明確に分けることが要点になる。
LLMが力を発揮するのは、分析の「入口」と「出口」だ。入口とは、問いの設計である。「この販促の効果を測るなら、どんな比較軸がありえるか」「どの指標を見るべきか」といった仮説の壁打ちにはLLMは有用だ。出口とは、結果の言語化である。分析結果を経営層向けのサマリーに変換する作業は、LLMの得意領域といえる。
一方で、真ん中の「計算」と「判断」は任せてはいけない。数値の集計・検定はSQLやPythonなど確定的なツールで実行する。SQLやPython作成を現在の最先端LLMモデルにやってもらうこと自体は問題がない。生成AIの”手抜き”を避ける使い方が重要です。
検定手法の選択、多重比較の補正要否、サブグループ分析の妥当性…これらの判断は統計リテラシーを持つ人間が担保する。
LLMが出した分析コードは必ずレビューし、「何回検定を回したか」「補正は入っているか」「都合のいい切り口だけ選んでいないか」を確認するプロセスを業務フローに組み込むことが望ましい。
そして何より、LLMに渡すデータそのものを整えることだ。商品マスタの鮮度管理、コード体系の統一、欠損値の処理ルール策定…地味だが、ここが崩れていればどんな高性能モデルを使っても出力は信頼できない。
結論
LLMは小売データ活用の可能性を確実に広げる。だが忘れてはならないことがある。
BIツールは「差がなければ差がない」と返す。LLMは「差がなくても差を見つけようとする」。BIツールは「データがなければ空欄を返す」。LLMは「データがなくても何かを返す」。この二重の非対称性こそが、LLMでデータを扱う時に絶対に見逃してはいけないことである。
出典
- Kawahara, S. (2026) “P-hacking with one prompt,” ResearchGate（プレプリント）
- “How well do LLMs reason over tabular data, really?,” arXiv:2505.07453, 2025
- B EYE, “LLMs Aren’t Hallucinating — Your Enterprise Data Is Gaslighting Them,” 2025
- Deloitte, “Four Emerging Categories of Gen AI Risks,” 2024
