はじめに：みんながベイズと言うとき、Spotifyはなぜ止まったのか
近年、GrowthBook、LaunchDarkly、PostHog、Amplitude、Optimizely、VWO、Statsig、Eppo といった商用実験プラットフォームがこぞって ベイズモード を追加しています。マーケティングメッセージはどれも似たり寄ったりです。
- 「ベイズはモダンで柔軟」
- 「頻度主義より解釈が簡単」
- 「多重検定や逐次検定といった頻度主義の複雑さが自然に解消される」
ところが Spotify のエンジニアリングチームは逆の結論を出しました。「現時点でベイズを追加する必要はない」 という判断です。
本記事は Spotify が公開した分析をもとに、なぜこの判断に至ったのか、そして自チームにベイズを導入する際に何を先に考えるべきかを整理します。根拠資料は Spotify Engineering ブログ で確認できます。
要点：ベイズA/Bテストは「ひとつの手法」ではなく「設定の集合」です。 これを一括りにした瞬間、議論は崩壊します。
ベイズA/Bテストの実体：設定の集合である
ベイズA/Bテストは 停止規則（stopping rule）+ 事前分布（prior）+ 尤度（likelihood） で定義される設定群です。つまり「ベイズか頻度主義か」ではなく、「どの目標のためにどの設定を選ぶか」 が本当の問いです。
実験プログラムの目標は通常次のようなものです。
- 効果のない機能をリリースする割合を減らしたい
- 効果量を一定の精度で推定したい
- 特定のコスト関数を時間軸で最小化したい
目標が違えば最適な設定も変わります。しかしオンライン上の議論では両者が混ざってしまい、非専門家は「ベイズは万能」という幻想を抱きます。
よくある主張4つを、条件付きで書き直す
1) 「ベイズは peeking 補正が不要」
この主張は二通りに分かれます。
- （目標）peeking 下の false positive rate（FPR）を気にしない
- （設定）Bayes factor stopping を使うので FPR が自動的に統制される
この二つは全く別の主張です。ところが多くは「ベイズの性質」として混同されます。実際、Bayes factor stopping は martingale 性により peeking 下でも FPR を統制します。ただし この設定を提供するプラットフォームはほぼ存在しません。 多くのプラットフォームのデフォルトは flat prior + posterior probability threshold であり、これは頻度主義の peeking と同一の FPR を再現します。
2) 「ベイズは多重指標を自動処理する」
この主張が隠しているのは二点です。
- 統制されるのは FPR ではなく FDR（False Discovery Rate）
- それを得るには 適切に校正された Empirical Bayes prior + Bayes factor stopping が必要
事前分布に point-mass 成分（historical null 比率）を入れることで多重性補正が吸収されます。つまり「補正がない」のではなく、「極めて精巧な補正が事前分布の中に隠れている」 のです。事前分布の校正が不十分なら FPR は統制されません。
3) 「ベイズは winner's curse を直す」
最も問題の少ない主張です。情報を持つ事前分布は推定値を prior mean 方向に shrink させ、winner's curse を緩和します。問題は 多くのチームが flat prior（プラットフォームのデフォルト）を使う ことです。Flat prior は shrinkage がゼロで posterior mean = MLE、つまり頻度主義と同程度に winner's curse に晒されます。
シミュレーションでは、適切に校正された historical prior が最も低い推定誤差を示しました。逆に 誤指定された事前分布は baseline GST より悪化 しました。特に失敗モードは二つ：
- 勝利した実験のみをアーカイブした場合
- 異なるプログラムをプールした場合
どちらも推定精度を悪化させました。
4) 「Decision theory を使うにはベイズが必要」
意思決定理論はコスト関数を指定させ、A/Bテストでは最適方策が Bayes rule になります。単純なコスト関数（FN + FP + サンプリングコスト）に対して最適方策は Bayes factor threshold であり、これは同時に error-rate 保証も与えます。つまり 意思決定理論と error-rate 制御は同じ設定の二つのパラメータ化 になることが多いのです。
例外は示唆的です。Stucchio が説明した expected-loss stopping は、posterior が十分 tight になれば必ず ship します。Flat prior では FPR は約 50% ですが、null-effect の配信が真にコストゼロならこれが最適です。しかしコストが実際の効果量の数 % を超えた時点で最適ではなくなります。
ベイズと頻度主義は思ったよりずっと近い
実務で最もよく使われる設定で見ると、ベイズと頻度主義は論争が示唆するよりもはるかに類似しています。
Flat prior + two-group normal モデルで数値的に同一
| ベイズ | 頻度主義 |
|---|---|
| Posterior mean | Maximum Likelihood Estimate |
| P(B > A | data) | 1 − p-value |
| 95% posterior probability threshold | One-sided rejection region |
Flat prior で posterior probability threshold を使う実験者は、用語が違うだけで頻度主義的推論を行っている ことになります。
より深い接続：mSPRT = Bayes factor stopping
- Mixture SPRT（頻度主義の逐次検定の代表格）は 同一 prior 下の Bayes factor stopping と厳密に一致
- 頻度主義者が MDE で power を最大化するために mixing distribution を選ぶのは、ベイズ的には treatment effect に prior を置くこと と同じです。mixing distribution がすなわち prior です。
- mSPRT は GST（Group Sequential Testing）でよく近似されます。
結局、多くの自然なコスト関数の最適決定規則は Bayes factor threshold → それは mSPRT → mSPRT は GST で近似。両フレームワークは対立ではなく、保証が重なる領域が非常に大きい のです。
解釈は本当に良くなるのか
「効果が 0.2%〜1.1% の間にある確率が 95%」という表現が「95% 信頼区間」を説明するより自然なのは事実です。しかし flat prior 下ではすべての確率的言明が頻度主義量と 1:1 対応 します。点推定・区間も同じ、P(B>A) = 1 − p-value です。
確率的解釈が本当に変わるのは 良い事前分布があるとき だけであり、良い prior は無料ではありません。指定・正当化・保守・説明のコストがかかります。解釈は得られますが、別種の複雑さを支払うことになります。
Empirical Bayes、実際の実装はどれほど難しいか
前の二節が共通して指す点：Bayes factor stopping + 適切に校正された Empirical Bayes prior は頻度主義がきれいに再現できない真の利点を与えます。問題は、その prior を十分な品質で推定するのが難しいことです。
- コーパスが大きい必要がある（時に 200 実験以上）
- 代表性が必要
- 異質なプログラム・指標をプールしてはいけない
例を挙げます。あるプログラムが sign-up rate と recommendation CTR を追跡しているとします。
- Sign-up：多くの実験でほとんど動かない
- CTR：容易に動く
両者を一つのコーパスにプールすると、prior variance は sign-up には広すぎ、CTR には狭すぎます。null-rate 推定も誤ります。結果として どちらの指標も実際には従わない分布に校正された prior が得られます。指標ごとに prior を推定することも可能ですが、新しい指標が生まれるたびに過去実験を backfill する必要があります。
さらに、プログラム内でも時間とともに効果分布は変化します（収穫逓減、世界の変化）。過去実験が将来実験に対して代表性を持つかを判断すること自体が難しい のです。
結論：成熟した単一プログラム + 一貫した指標定義 + 統計専門家が prior を保守する組織は Empirical Bayes で実質的価値を得られます。しかし多くの組織では prior 保守の複雑さが利点を上回ります。
この技術の限界と注意点
- 「ベイズ」というラベルに騙されないこと。 多くのプラットフォームのデフォルトは flat prior + posterior threshold で、頻度主義の peeking と同一の FPR を出します。
- FDR 統制の主張は条件付きです。 適切に校正された empirical prior がなければ成立しません。
- 事前分布は保守対象です。 一度作って終わりではなく、ドリフト・プール誤り・勝利バイアスを継続監視する必要があります。
- 解釈の容易さは complexity trade-off です。 「わかりやすい」は無料ではありません。
次の学習ステップ
- Sequential testing：GST、mSPRT、always-valid inference の関係
- Multiple testing：FDR vs FWER、Benjamini-Hochberg、事前分布ベースの FDR 制御
- Decision theory for A/B testing：コスト関数設計、expected-loss stopping の落とし穴
- Empirical Bayes：James-Stein shrinkage、階層モデリング、prior calibration の診断
では Spotify はなぜベイズを追加しなかったのか
Spotify の実験プログラムの目標を再確認します。
- ビジネス判断を損なう実験数を最小化（製品を害する変更、改善のない変更の ship を防ぐ）
- 実験証拠が信頼できること
- 結果を 誤解しにくいこと（特にチーム・部署間の協業で）
- 計画・設定は簡単だが、誤設定はしにくいこと
Spotify は実験設計と結果の消費において 全社が常時協業 しています。この状況で二つのモードを支援すると、計画・モニタリング・解釈・出力がすべて変わります。第二のフレームワークの利点がそのコストを上回らない というのが彼らの結論です。
例外は認めています。適切に校正された Empirical Bayes prior + Bayes factor stopping は真の利点があります（shrinkage + 自動 FDR 統制）。しかしすべての指標・プログラムに対して十分な品質で prior を保守する必要があり、誤ると信頼が落ちます。混乱を加える sophistication は証拠の強度をむしろ下げます。
実務への示唆（Spotify からのメッセージ）
1. 望む実験プログラムを先に定義すること。 2. 必要な保証（guarantee）を定め、継続的に保守可能かを確認すること。 3. そのうえで「特定のベイズ設定が既存に対して有意に改善するか」を問うこと。
Spotify にとって現時点の答えは「No」です。
フレームワーク論争は本質をぼやけさせる消耗戦になりがちです。本当に重要なのは：
- 推論は一貫しているか？
- サンプルサイズ計算機は実際の決定規則と一致しているか？
- 実験は ship 判断だけでなく 学習 を生んでいるか？
この三点が成立していなければ、ベイズであれ頻度主義であれ意味はありません。