SpotifyがベイズA/Bテストを導入しなかった理由 — 実務者のための統計的検証まとめ

はじめに：ベイズは本当に「万能」なのか

近年、A/Bテストにおけるベイズ推論への関心が高まる中、GrowthBook、LaunchDarkly、PostHog、Statsig、Optimizelyなど、多くの商用実験プラットフォームがベイズモードを追加しています。共通する主張はこうです。「ベイズA/Bテストは現代的で柔軟、頻度論より解釈が容易である」。さらに「多重検定や逐次検定といった頻度論の複雑さが、ベイズ的思考では自然に解消される」とも言われます。

しかし、この主張には慎重な検討が必要です。本記事の結論を先に述べると、ベイズA/Bテストは単一の手法ではなく「設定の集合」であり、誤った設定では頻度論のピーキング（覗き見）問題と同等の結果を生みます。

本記事は、Spotify Engineeringチームが公開した技術検証に基づいています。詳細はSpotify Engineeringブログをご参照ください。

A/Bテストを設計する実務者の方にとって、「ベイズか頻度論か」というフレーム自体を再考するきっかけになれば幸いです。

核心概念：ベイズA/Bテストは「一つ」ではない

1. ベイズ推論は設定の組み合わせである

ベイズA/Bテストを導入する企業が陥りやすい誤解は、これを単一のツールと見なすことです。実際には、停止規則（stopping rule）、事前分布（prior）、尤度（likelihood） の3要素で定義される設定群です。

# ベイズA/Bテストの3つの構成要素（擬似コード）
config = {
    "stopping_rule": "bayes_factor_threshold",  # または posterior_probability_threshold
    "prior": "empirical_bayes_calibrated",      # または flat_prior
    "likelihood": "normal_two_group"            # 多くは正規近似
}

問題は、オンライン上の議論がこれら3要素を混同している点です。「ベイズは多重指標を自動処理する」という主張は、特定の設定（較正済み経験ベイズ事前分布＋ベイズファクター停止）でのみ成立します。デフォルトのフラット事前分布では全く成立しません。

2. ピーキング問題：ベイズも自由ではない

「ベイズはピーキング補正が不要」という主張をよく耳にします。これは2通りに解釈できます。

• 解釈A：「偽陽性率（FPR）を気にしない」（目標についての言明）
• 解釈B：「ベイズファクター停止を使うのでFPRは自動制御される」（設定についての言明）

この2つは全く異なる話ですが、議論では「ベイズの一般的性質」として括られてしまいます。特に、多くの商用プラットフォームのデフォルトであるフラット事前分布＋事後確率閾値の組み合わせは、頻度論のピーキングと同一の偽陽性率を再現します。統計的には頻度論のピーキングと変わりません。

3. 意外な事実：フラット事前分布ではベイズ＝頻度論

数学的に興味深いのは、フラット事前分布＋正規近似の条件下で、ベイズと頻度論の手続きが数値的に一致する点です。

• 事後平均 = 最尤推定量（MLE）
• BがAに勝つ事後確率 = 1 - p値
• 95%事後確率閾値 = 片側棄却域

# フラット事前分布における数値的同等性（概念例）
# 頻度論: p_value = 0.03
# ベイズ（フラット事前分布）: P(B > A | data) = 1 - 0.03 = 0.97

p_value = 0.03
posterior_prob = 1 - p_value
print(f"事後確率: {posterior_prob:.2f}")  # 0.97
# → 同じデータ、同じ結論、異なる語彙

つまり、ベイズを使っても「より高度な統計」を使っているわけではないということです。解釈のしやすさは得られますが、その代償として事前分布の維持・管理という複雑さを抱え込みます。

実務上の注意点：経験ベイズの落とし穴

1. 経験ベイズ事前分布の維持は想像以上に困難

ベイズの真の利点は較正済み経験ベイズ事前分布（well-calibrated empirical Bayes prior） にあります。これを使えば勝者の呪い（winner's curse）バイアスを低減し、偽発見率（FDR）を自動制御できます。しかし、この事前分布を「適切に」推定するのが極めて難しいのです。

特に**「勝利した実験だけをアーカイブに蓄積する」** ミスは致命的です。Spotifyのシミュレーションによれば、このような偏った事前分布は、基準線である群逐次検定（GST）よりも精度・検出力ともに悪化します。事前分布がない状態より悪くなるのです。

2. 指標を安易にプールしてはいけない理由

登録率（sign-up rate）とレコメンドクリック率（CTR）を1つのコーパスにプールするとどうなるでしょうか。登録率はほとんどの実験で動かず、クリック率は動きやすい。両者を統合すると、事前分布の分散が登録率には広すぎ、クリック率には狭すぎます。どちらの指標にも合わない事前分布が出来上がるのです。

# 誤ったプーリングの例（擬似コード）
# ❌ 悪い例: 異なる効果分布を持つ指標を一つに統合
pooled_prior = fit_prior([signup_rate_data, ctr_data])

# ✅ 良い例: 指標別に分離推定（ただしバックフィルコスト発生）
signup_prior = fit_prior(signup_rate_data)
ctr_prior = fit_prior(ctr_data)

3. 決定理論と誤り率制御は意外に近い

「決定理論的アプローチを取りたいからベイズが必要」という主張もよく聞きます。興味深いのは、一般的なコスト関数（偽陽性・偽陰性・サンプリングコストの和）では、最適停止規則がベイズファクター閾値として導出される点です。そしてその閾値は同時に誤り率保証も提供します。つまり、決定理論と誤り率制御は同じ規則の2つのパラメータ化なのです。

例外もあります。Stucchioが提案した期待損失停止（expected-loss stopping）は、事後分布が十分に狭まれば停止しますが、効果がなくても最終的に新バリアントを出荷します。フラット事前分布では偽陽性率が約50%に達します。ただし、無効果バリアントの配備が真にコスト0なら、これが最適です。 コストが実際の効果サイズの数%を超えた瞬間、この規則は最適ではなくなります。

結局、問いに戻るのは**「我々の実験プログラムの目標は何か」** です。

結論：Spotifyの選択と私たちの適用

Spotifyがベイズを追加しなかった理由

Spotifyの実験プログラムの目標は明確でした。

1. ビジネス意思決定を害する実験の最小化
2. 実験証拠への信頼確保
3. チーム・部署間の解釈ミス防止
4. 計画と設定は容易に、誤設定は困難に

ここでの核心は**「2つのモードを同時サポートするコスト」** でした。計画、モニタリング、解釈、出力形式がすべて異なってきます。一方で実質的な利得は限定的でした。結果として「第2のフレームワークの利得がコストを上回らない」という結論に至ったのです。

日本の開発エコシステムにおける適用文脈

日本の開発現場では、この議論は特に重要です。多くのスタートアップや受託開発プロジェクトでA/Bテストツールを導入する際、「ベイズが最新だから」 という理由だけで選択するケースが見られます。しかし実験ボリュームが絶対的に不足する初期段階では、経験ベイズ事前分布を維持するコーパス自体が存在しません。この場合フラット事前分布のデフォルトを使うことになりますが、それは頻度論と数値的に同一でありながら、解釈だけを異なる形で包装したに過ぎません。

実務アドバイス： ツール選定の前に「我々のプログラムの目標は偽陽性率制御か、FDR制御か、あるいは意思決定コスト最小化か」を先に文書化してください。その上で、その目標を達成する設定を逆算する順序が正しいのです。

この技術の限界

• ベイズが「より正確な」推論を保証するわけではありません。フラット事前分布では頻度論と同一です。
• 経験ベイズ事前分布の利得はコーパス品質に100%依存します。誤ったプーリングはむしろ性能を悪化させます。
• 「解釈が容易」という利点は実在しますが、その代償として事前分布の維持・説明コストが発生します。

次のステップ学習方向

1. 群逐次検定（GST） と mSPRT の関係を先に理解してください。ベイズファクター停止と数学的に接続します。
2. 偽発見率（FDR）vs 偽陽性率（FPR） の違いを明確にしてください。多重指標問題の核心です。
3. 実験プログラムの目標 → 設定 → 保証 の順で考えるフレームワークを練習してください。

ベイズと頻度論は対立ではなく、重なる領域の多い2つの言語です。重要なのはどちらの陣営に立つかではなく、我々のプログラムがどのような保証を必要としているかを知ることです。

あわせて読みたい記事

• AI時代、データジェネラリストの価値はさらに高まった
• Google ADK Go 2.0 正式リリース：グラフベースワークフローへの進化