A/B テストの落とし穴 7 選 ─ 有意でも実装してはいけないとき
Web / プロダクト改善で標準的な A/B テスト。でも『p < 0.05 で有意 → 即実装』では失敗します。実務で踏みやすい 7 つの落とし穴と対策を解説。
A/B テストはオンラインビジネスの 意思決定の主軸。でも『p < 0.05 だから採用』は半分正解、半分間違い。実務で陥りやすい 7 つの罠を整理します。
1. Peeking(覗き見)
テスト中に 何度も中間結果を確認 し、有意になった時点で停止する。これは 第 1 種の誤り(α)を膨らませる 古典的バイアス。連続的に検定していると、本来 5% のはずが 30% 以上の確率で『偶然有意』が出る。
- 対策: テスト前にサンプルサイズと期間を決め、終了まで結果を見ない
- Sequential testing(O'Brien-Fleming・GST): 中間解析を許容する手法
- ベイズ A/B: 事後確率は何度見ても問題ない
2. p ハッキング
有意になるまで条件を変える(セグメント・指標・期間)。複数の仮説を試し、たまたま有意だったものだけ報告。多重比較補正 で対処。
3. サンプルサイズ不足
『有意差なし』は『効果なし』ではなく『検出できなかった』。MDE(Minimum Detectable Effect) を事前に決めて、必要サンプルサイズを計算する。本サイトの [サンプルサイズ計算機](/tools) で簡単に出せます。
4. ノベルティ効果(Novelty Effect)
新機能を出すと 最初は新鮮さで使われ て効果が大きく見える。長期で見ると元に戻ることも。最低 1 〜 2 週間は走らせて 安定後の効果で判断。
5. シンプソンのパラドクス
全体では B が勝つが、セグメント別に見ると全セグメントで A が勝つ ── という不思議な現象。サンプル分布の偏り が原因。ランダム化が破れた 兆候なので即停止して原因調査。
6. SUTVA 違反(干渉)
ユーザー間で影響が伝播 する場合、A/B 群が独立でなくなる。SNS の友達紹介・市場全体の価格・口コミ ── これらは クラスター単位(都市・コホート)でランダム化する。
7. 複数指標の罠
20 個の指標を見れば、たまたま 1 つは p < 0.05 になる(α=5% の罠)。主要指標(OKR / 北極星指標)を 1 つだけ事前に決め 、副次指標は探索的扱いに留める。
1. 事前に: 仮説 + 主要指標 + MDE + サンプルサイズ + 期間を決める 2. テスト中: 結果を見ない(覗き見しない) 3. テスト後: 主要指標を確認 → 有意かつ実用的なサイズなら採用 4. ロールアウト: 段階的に展開しモニタリング(逆効果なら巻き戻し)
関連ツール・記事
- [A/B テスト計算機](/tools) ─ 2 比率検定の p 値・信頼区間
- [サンプルサイズ計算機](/tools)
- [p 値の誤解 5 選](/blog/p-value-misunderstandings)
- [因果推論ミニ教科書](/causal-inference) ─ 観測データで因果を推定する
関連記事
- 2026-04-30実装Slack Bot を LLM で作る ─ FastAPI + OpenAI で社内ツール化Slack の Slash Command と Events API を使い、社内チャンネル内で動く LLM Bot を構築。FastAPI バックエンド + OpenAI で 1 日で完成。
- 2026-04-30実装FastAPI 入門 ─ ML モデルを 5 分で API にするPython の高速 Web フレームワーク FastAPI を使って、ML モデルを REST API として公開する最短ルート。型ヒント・自動ドキュメント・非同期対応の 3 拍子。
- 2026-04-30実装Docker 入門 ─ ML 環境の再現性を担保する「自分の PC では動く問題」を解決する Docker。ML プロジェクトの Dockerfile・GPU 対応・docker-compose・Multi-Stage Build までを実用視点で。