仮説を証明しにいかない — 娘が読み上げたニュース

夜、娘がニュースを声に出して読んでくれた。スターバックスがAIの在庫管理をやめた、という話だった。

聞いた時点で、僕には自分なりの仮説があった。毎回同じ答えが要る作業にAIを使って、周りの仕組みを作らずに失敗し、在庫の担当者をAIのエンジニアに入れ替えたんじゃないか、と。

僕はその頃、AIを仕事に入れる話を一般向けのレポートにまとめていた。そこに引用できるかもしれない、と思った。

ニュースをレポートに引用するなら、重い方の調べ方で回す

僕のリサーチの手順には、手早く当たりをつける軽い方と、一次資料まで確かめる重い方がある。引用する話は重い方で調べる決まりなので、今回も重い方にした。

調べるのは、コーディングしてくれているClaude Code（以降Code）。重い方には最後に、レッドチーム（あえて反論役をさせて、弱いところを探す検証）のステップがある。書いたAIが自分で見直しても、自分の結論をかばう偏りが抜けないので、Codeとは別に立ち上げたまっさらなClaudeにやらせる。

このステップを使ったのは、それまで同じ日の1回だけ。その時も僕は別の仮説を持っていた。AIに丸ごと任せた調べ物は、中身の4割が間違っている、というもの。

勝ち負けでなく情報が欲しいと伝えて、仮説を5つの主張に割った

その1回目で、Codeは僕が4割を証明したがっていると受け取った。でも僕は、4割を大きく見せたいわけでも、守りたいわけでもなかった。

だから今回は、スターバックスの仮説を調べる前に、Codeに言っておいた。僕は誰かと正しさを競っているわけじゃない、情報が知りたいだけ、と。手順にも、仮説を持って調べる時は、仮説に合う証拠より、仮説を崩す証拠を探しにいくと決めてある。

それから、Codeがニュースと僕の仮説を、1つずつ確かめられる主張に書き出した。C1とC2は娘が読んだニュースの中身で、C3〜C5は僕の頭の中の仮説。

番号	主張	出どころ
C1	スターバックスは在庫管理にAIを使っていた	ニュース
C2	それをやめた	ニュース
C3	失敗の理由: AIは決定論的な作業（毎回同じ答えが要る作業）に向いていない	僕の仮説
C4	AIの周りに、検証や手入れの仕組みが作られていなかった	僕の仮説
C5	在庫管理のスタッフを解雇して、AIエンジニアに入れ替えた	僕の仮説

たとえばC3とC4は、どちらも失敗の理由なので一言にまとめがちだけど、C3はAIという道具の話で、C4はスターバックスが社内でどう運用していたかの話。C3は報道からツールの出来を確かめられるけど、C4は社内の事情が分からないと確かめようがない。

主張ごとに割っておけば、どこがどのくらい支持されるかを1つずつ見られる。

割った5つは、確かめられた度合いがそれぞれ違った

Codeが、元になったロイター通信の記事と後追いの記事を集めて読み比べた。

C1（AIを使っていた）は確認できた。NomadGoという会社の、センサーとカメラで在庫を数えるツールが、北米の店舗に入っていた。

C2（やめた）は一部だけ確認できた。スターバックスは確かにそのツールをやめて、手で数えるやり方に戻していた。でも、MicrosoftのAIを使った従業員向けのアシスタントは続いていて、ほかのAIはむしろ広げている。**「AI在庫管理をやめた」は事実で、「AIをやめた」は誤読。**ニュースの一文を丸ごと判定していたら、「やめた」が本当というだけで、「AIをやめた」まで正しいことになっていた。

C3（決定論的な作業に向いていない）は、一部だけ裏付けがあった。ロイターは、ツールが品物をよく数え間違えたり取り違えたりしたと報じていて、米経済誌のFortuneは、時間が経つと数える正確さが落ちたと書いていた。ただFortuneの方は手入れが足りなかっただけかもしれないので、「AIはこういう作業に向かない」とまでは言えない。

C4（周りに仕組みがなかった）は検証できない。社内の事情は、外からは分からない。

C5（人を入れ替えた）は、ツールのために人を入れ替えた、というつながりが見つからなかった。ツールはバリスタが在庫を数えるのを手伝うもので、外した後は同じ人が手で数えるやり方に戻っただけ。別にあった解雇は、ツールより前の本社の人員削減。AIエンジニアを雇った証拠も無い。ただ、その後に店の人へ影響が出たかどうかまでは確かめられなかった。

C5は僕の仮説の一部だった。証拠もなく人を切るという話は、もともと好きじゃないんだよね。ただ、仮説は当てるためじゃなく確かめるために立てたものなので、支持されなくても困ることは何もなかった。

「わからない」と書いた主張を、同じまとめが結論に使っていた

Codeは調べた結果を1つのまとめに書き、レッドチームのステップで別のClaudeに渡した。指摘は6件返ってきて、Codeは全部直した。

その中に、こういう矛盾があった。C4の所では「検証できない」と正直に書いてある。ところがその後、この話を一般向けレポートにどう使うかを書いた所では、「スターバックスには信頼できる検証の仕組みがなかった」と言い切っていた。

C4は確かめられないと書いたのに、同じまとめの中で、そのC4を事実として使っていた。通して読むと「言いたいことは分かる」で読み流してしまう矛盾だけど、レッドチームは見逃さなかった。

残りの5件は、1つの例だけで「AIは一般にこう」と広げていた所や、C5を「否定」と言い切りすぎていた所など。最初のまとめはC5を「否定」と書いていて、さっきのC5の最後の一文（その後の影響は確かめられなかった）は、この指摘で足したもの。

1回目のリサーチでは、レッドチームの問いがきっかけで、調べ物の元にした論文に無い数字がまとめに入っていたと分かった。今回は、まとめの中の2か所を読み比べれば見つかる矛盾で、種類は違う。それでも、どちらもレッドチームが無ければ見落としていた。

当たり外れでまとめる癖には、書いたCode自身は気づけなかった

Codeが結果を報告してきた時、その言い方が、僕の仮説が当たったか外れたかに寄っていた。まとめの結論も、僕の仮説が支持されるかどうかの形で書かれていた。

僕はすぐCodeに言った。誰が正しいか間違っているかの話じゃない、情報の話だ、と。今回の冒頭で断っておいたのに、1回目のリサーチに続いて、同じことをもう一度言うことになった。

最初に断って、主張ごとに割っても、まとめる時にまた証明しにいく側へ寄っていく。確かめられないC4を結論に使っていた所は別のClaudeが見つけ、当たり外れへの寄りには僕が気づいた。どちらも、書いたCodeが自分で見直して気づいたものではなかった。

結局、このニュースはレポートには入れなかった。調べた中身は、情報として手元に置いてある。