1. 「良くない」を分解する

A/Bテストは、ボタンを差し替えて数字を見比べるだけのシンプルなツールに見える。だから運用していて違和感が出たとき、その違和感を言語化できない人も結構いる。

実際、先日こんな相談を受けた。

「私たちがやっているA/Bテスト、何かが良くないって意見があるんですが、どうしたらいいのかわからなくて」

この「良くない」を分解する準備が自分にもなかったので、調査整理してみました。

2. A/Bテストの見落とされがちな前提

リサーチ結果

何か革新的な新しいやり方がないかと論文やレポートをリサーチしてわかるのは、A/Bテストの失敗は、ツールや計測の設定、そして統計学の基礎的な知識不足が主な原因で起きているという点。足元が疎かなのだ。

  • SRM（サンプル比率不一致）は「AとBの割り当て比率がずれている」という設定・計測上の問題
  • ピーキング（早期停止）は「A/Bテストが “事前にサンプル数を固定する前提” で設計されていることを知らない」という統計の問題
  • 多重比較は「指標を増やせばその分偽陽性が増える」という統計の問題

どれも、ツールの操作や派手な手法の話ではなく、そもそもA/BテストがAとB出すだけだという勘違いから起きている。

業界の論文や失敗事例を大きく３つに分類してみる。

  • 統計的推論とデータ品質
    そもそもツールがうまく使えていない、基礎的な統計の使い方がわかっていない
  • 指標設計と仮説構築
    何を成功とするか、グッドハートの法則などの指標に関する知識不足と副作用を考えた設計不足。もしくはシンプルにA/Bテストの設計の質の低さ
  • 組織運用・文化・システム
    失敗を隠す、上司などの声の大きい人の意見が優先されるなど

A/Bテスト実践ガイド 真のデータドリブンへ至る信用できる実験とは(kadokawa.co.jp) でRon Kohavi氏が丸々一章使って語っているようにA/Aテストを実施しない企業が多い。当たり前のように思えるただのツールチェックだが、これで見つかるミスが多いことが指摘されている。

次にサンプル数の設定と期間の設定をシンプルにやっていないケースだってある。

冒頭の「A/Bテスト、何かが良くない」の “何か” の正体は、そもそもA/Bテストを理解できていない可能性もある。A/Bテストのツールは非常にシンプルだが、それを実行するためにはデータドリブンに意思決定する組織と、そもそもの統計学（決して高いレベルが必要なわけではない）への学習が不足しているケースが多いと複数の研究(最後に参考になるもののリストを提示する)で指摘されている。

A/Bテストの骨組み

A/Bテストは簡易版のランダム化比較試験（Randomized Controlled Trial）。1920年代にフィッシャーが農学（どの肥料が効くか）で確立した手法を、ソフトウェアの世界に持ち込んだものになります。

ビジネスの文脈から色々と時短、コスパのためのテクニックが開発されているが一旦それは横に置く。 A/Bテストのステップは以下のようになります。

  1. 仮説を立てる
    A/Bテストは常に仮説によって推進されます。仮説とは、特定の変更がパフォーマンスにどのように影響するかを予測する、検証可能な仮定です。例えば、「『今すぐ購入』ボタンを青から赤に変更すると、クリック率が10%向上する」といったものが仮説になります。
  2. 試験を設計する
    • 試験グループの設計
      A/Bテストでは、比較対象となる2つの条件が必要です。グループが明確に区別され、重複する可能性がないことを確認することが重要です。
    • サンプルサイズ決定
      テストを実行する前に、信頼できる結果を得るために必要なサンプルサイズ（参加者数）を計算する必要があります。
    • グループのランダム化
      バイアスの可能性を最小限に抑えるために、ユーザーは2つのグループのいずれかにランダムに割り当てられる必要があります。
  3. 試験実装
    テスト対象の2つのバージョンをサンプルグループに展開します。
  4. 結果収集・分析
    要なサンプルサイズを収集するのに十分な期間テストを実行した後、結果を分析して、どちらのバージョンが優れたパフォーマンスを示したかを判断します。

A/Bテストは１つの目標に対して統計学的な試験を行ったに過ぎず、その結果をもって、ビジネス上の勝ちになるかとは切り分けて考えないといけない。そもそも切り分けられないなら、A/Bテスト手法を採用すべきではない。

ビジネス的な勝ち（何を持って勝ちとするかは議論の余地あり）と、統計的優位性には特に関係性はない。統計的試験をせずとも、感で選んだ結果の方がビジネス的な勝ちを拾えることはある。

このあたりを忘れて運用すると、後述するピーキングや多重比較といった罠に落ちやすい。統計の前提が、思っているより繊細にできているからだ。

そもそも勝つテストは少ない、という前提

もう一つ、リサーチの中で印象に残った内容を補足しておく。Microsoft Bingの実験成功率は約15%、Google Ads・Netflix・Booking.comでも、新しいアイデアが統計的に有意な改善をもたらすのは10%前後にとどまる、と報告されている。残りはフラット（差がない）かネガティブだ。

この前提を踏まえると、「何回も連続で勝っているテスト」をは眉唾になる。業界には「驚くほど良い数字が出たときほど計測や設定を疑え」という経験則（Twymanの法則）がある。

3. よくある5つの落とし穴

#1 計測・トラッキング設定の不備

A/Bテストの統計は「ランダムに割り当てた群が、施策以外は均質」という前提の上に成立している。この前提は、実装ミスで簡単に壊れる。

代表的な症状が SRM（Sample Ratio Mismatch：サンプル比率の不一致） で、50対50で配分したつもりなのに、ログ上の比率が52対48にずれているような状態を指す。誤差の範囲に見えても、サンプルサイズが大きいとこの程度のズレでも統計的に異常な確率になる。原因はターゲットオーディエンス定義のミス、フロントエンドサイドの計測プログラムの実行遅延でイベントが取りこぼされる、リダイレクトベースの実験での離脱、ボット検知が片方の群を誤判定して除外、実験途中での配分比率の変更などなど。

割り当てが歪んだ瞬間、その後の統計的設計は意味を消失する。「BがAより2%良かった」と見えていても、その2%は施策の効果なのか、消えてしまったユーザー群のせいなのかを区別できない。

DoorDashの事例では、ある実験で「年間1000万ドルの増収」と結論しかけたが、SRM検証で購買意欲の低いユーザーがバグで実験群から脱落していたことが判明し、結果は無効化されている。

参考: Addressing the Challenges of Sample Ratio Mismatch in A/B Testing(careersatdoordash.com)

Microsoftの事例では、MSN画像カルーセルで新カルーセルへのエンゲージメントが高すぎたためにボット検知が「熱心なファンユーザー」をボットと誤判定して除外し、エンゲージメント低下という逆の結論が出てしまった。脱落したユーザーがランダムにではなく特定の特徴を持って脱落していると、典型的な生存者バイアスが発生する。

参考：Diagnosing Sample Ratio Mismatch in A/B Testing(microsoft.com)

生存者バイアス

といえば、コレ

Martin Grandjean (vector), McGeddon (picture), US Air Force (hit plot concept) - 投稿者自身による著作物, CC 表示-継承 4.0, リンクによる

改善案

  • SRMアラート機能を使用し、警告がきたら即停止
    A/Bテストフレームワークについてる機能を使う。原因究明前に「とりあえず結果を見てみる」のは厳禁。歪んだデータを眺めてみても幻想が見えるだけ。
  • SRMアラートを実装する
    A/BテストでSRMアラート機能がついていないもの使用する場合は、カイ二乗統計量を使い自力で計算する仕組みを作る。
  • A/Aテストの運用
    同じ体験をA群にもA’群にも見せる「A/Aテスト」を走らせて、有意差が出ないことを確認する。

#2 ピーキング

ダッシュボードを毎日見て、p値が0.05を下回った瞬間に「もういいよね」と試験を止める Peeking は、A/Bテストで最も頻繁に起きる間違い。古典的なA/Bテストはt検定に基づいており、「事前に決めたサンプル数に達するまでp値を見てはいけない」という強い前提がある。サンプル数を固定する代わりにp値の信頼性を担保する設計なので、ハックは厳禁。

スタンフォード大学のシミュレーションは深刻さを数字で示している。本来5%（α=0.05）であるべき偽陽性率が、毎回p値を確認し続けると 最大60%にまで膨張する。ピーキングしながら有意差を待つ運用は、「コインを何度も投げて、たまたま表が3回続いた瞬間に “このコインは表が出やすい” とする」 のと同じことをしていることになります。やっかいなのは、ピーキングしている本人にp値ハッキングをしている自覚がないことだ。

このピーキングをしてしまうことを前提としている手法も考えられている。

参考：Stanford Webinar: Common Pitfalls of A/B Testing and How to Avoid Them(youtube.com)

改善案

  • サンプルサイズを事前に固定する
    MDE（最小検出可能効果）と検出力（典型的には80%）から必要サンプルサイズを計算し、その数に達するまで判定を保留する。古典的故に強力。
  • 逐次テスト（Sequential Testing）に切り替える
    Optimizelyの “Always Valid p-values” や mSPRT（混合逐次確率比検定）。「途中で見たい」というニーズに統計的に正しく応える。
  • 早期停止の条件を「勝ったから」ではなく「危険だから」だけに限定する
    ガードレール指標（決済エラー率、レイテンシなど）が悪化した場合の早期停止は許容するが、「主要指標で勝ったから止める」は禁止。
  • ベイズ統計を使うなら事前分布に注意
    ベイズ手法は覗き見耐性があると言われるが、Uninformed Priors（無情報事前分布）を使った安易なベイズツールは「2%改善と200%改善が同じ確率で起こる」と仮定しているので、健全な再起疑心を持たないと。ピーキングと同じく危険である。ドメイン知識を反映した事前分布の設計が必須。 (参考：The Bet Test: Spotting Problems in Bayesian A/B Test Analysis)

A/Bテストのサンプル数算出ツール

理論名前link
t検定Evan’s Awesome A/B Toolsevanmiller.org
逐次テストA/B test sample size calculatoroptimizely.com
ベイズ推定A/B Test Sample Size & Duration Calculatorvwo.com

#3 シンプソンのパラドックスと多重比較問題

シンプソンのパラドックス 母集団全体で観察された傾向が、データを特定のサブグループ（年齢、性別、ブラウザ、デバイスなど）に分割した際に消失、あるいは完全に逆転する統計的現象。

原因は、実験期間中にトラフィック配分比率の変更、時間帯によるバケッティング（例：平日はA群、週末はB群に多く割り当てる）。週末のユーザー群全体のコンバージョン率が平日よりも著しく低かった場合、週末に多く割り当てられたバリアントは全体集計において不利な結果を強いられることになる。その結果、正しい結果が受け取れなくなる。

多重比較問題 複数の仮説を同時に検定する場合の問題。複数のバリアント、複数のセグメント、複数の指標を個別に検定していくと、統計的検定は「20回に1回は偶然有意差が出る」（α=0.05）ように設計されているため、検定回数を増やすほど偽陽性が増加する。

具体的には、8つの独立した仮説を個別に α=0.05 で試験すると、少なくとも1つの偽陽性が出る確率は以下の式で計算できる。

P=1−(1−0.05)8=1−0.958≈0.336=33.6% P = 1 - (1 - 0.05)^8 = 1 - 0.95^8 \approx 0.336 = 33.6\%

つまり、8つ検定すれば、実は差がないのに約33.6%の確率で「有意な差がある」と誤った結果になる。

改善案

  • ボンフェローニ補正を適用する
    複数の主要仮説を同時に検定する場合、有意水準を厳しくする。
    8つ検定するなら有意水準を αcorrected=αn\alpha_{\text{corrected}} = \frac{\alpha}{n} から計算して、
    0.058=0.00625\frac{0.05}{8} = 0.00625 になる。
  • セグメント別の多角的事後検証
    結果をデバイス、新規/再訪、トラフィックソース、時間帯など主要セグメントに分割して検証する。全体で勝ちでも、すべてのセグメントで一貫性があるか確認する。

#4 ユーザーの傾向対策不足

A/Bテストの結果は、その期間中のユーザー反応のスナップショットにすぎない。

  • 新奇性効果（Novelty Effect）
    新機能を珍しがって過剰に使うが時間とともに飽きて使用が減衰する現象
  • プライマシー効果（Primacy Effect）
    既存ユーザーが新UIに戸惑い、習熟するまでエンゲージメントが落ちる現象

これらが厄介なのは、テスト期間中に観測した効果サイズが、長期定常状態の効果サイズと一致しない可能性が高いことだ。1週間のテストで「B群がCTR+30%」と見えても、3ヶ月後にはほとんど差がなくなっているかもしれない。

Googleの研究（Focus on the Long-Term: It’s better for Users and Business(research.google)やMicrosoftの研究（Novelty and Primacy: A Long-Term Estimator for Online Experiments(arxiv.org)は、こうした ユーザーの学習効果を切り分ける手法を提案している。

改善案

  • Post-Period (PP) 法
    A/Bテストを行った後、A,B両方を同じ設定（通常は実験対象でないもの）に戻して比較。この「事後期間」に残った行動の差が、ユーザーの学習効果を示します。
  • Cookie-Cookie-Day (CCD) 法
    毎日ランダムに抽出される「CCDグループ（その日だけ実験に参加するユーザー）」と比較することで、長期間処置を受け続けているユーザーの学習プロセスをリアルタイムで追跡する。
    CCDグループとは、ずっと通常の機能を使ってるControlグループ、実験機能をずっと使っているLong-term Treatmentグループ、そしてその日だけ実験機能を使うCCDグループと分けたグループ分けです。
  • Observational Approach
    CCD法はコストが高いと感じる場合の提案です。実験機能グループの中にいるユーザーを、さらに機能に対して触れた回数によって細かくグループ分けしていきます。「たくさん触れた人」と「少ししか触れていない人」で違った結果が出ることを期待しています。

#5 組織文化と意思決定プロセス

ここまでの落とし穴4つは、統計や計測などのテストの仕組み側の話でした。別の視点として、統計が正しく動いていても、組織の意思決定プロセスが壊れていれば結果は活かされない という点です。研究されている３つの要素を提示します。

  1. HiPPO（Highest Paid Person’s Opinion）
    HiPPOつまり給料の最も高い人、日本の文化的には職位が高い人の意見でリリースが決まり、テスト結果はお飾りになる。
  2. 失敗の隠蔽
    自分のアイデアがうまくいかなかったテストの結果を隠蔽する、あるいはp値ハッキングで無理矢理よい結果だったことにする。
  3. 確証バイアス
    経営陣が特定の施策を強く推している場合、データから都合のいい解釈だけが拾われ、反証データは軽視される。

これらを放置していると、認知心理学のACT-R(認知制御論)モデルが示すように、人間も組織も「失敗した仮説の記憶を保持しない」性質があるため、同じ仮説を別チームが再発明し、同じ失敗を繰り返すことになる。 参考：

改善案

  • 失敗の共有を制度化する
    成功例だけでなく、フラットや負けたテストも社内で定期的に共有する場（隔週レビュー、社内Wiki）を設ける。失敗したテストの担当者を称賛できる文化を作る。
  • HiPPOへの対抗として “事前合意” を文書化する
    テスト開始前に主要指標、ガードレール指標、Ship Decision Rule（リリース可否の判定基準）を書面で合意し、結果が出た後に基準を後出しで動かさない仕組みにする。
  • 失敗からの学習を評価指標に組み込む
    「打率」だけで担当者を評価すると、確実に勝てる小さなテストばかり選ぶ保守的な行動が誘発される。挑戦的な仮説を立てたか、失敗から何を学んだかも評価項目にする。

まとめ

冒頭の問いに即答できなかったのは、知識不足を自分で露呈していたということ。

リサーチを通じて見えてきたのは、A/Bテストの失敗の大半が、統計の基礎、計測の前提、組織の意思決定といった足場固め不足で起きているということ。SRMもピーキングも多重比較も、目新しいテクニックで解決する話ではなく、ランダム化比較試験の基本に立ち戻れば防げるものが多い。

だからA/Bテストを見直したいと思ったら、最初にするのは、基本の知識のおさらいから。サンプルサイズの計算、有意水準の意味、A/Aテストの実施。地味に見えるが効果が高い。

途中でp値を見たいし、短期で結論を出したいし、勝てそうな指標だけ拾いたいというのも気持ちはわかるが、ピーキングや多重比較がなぜ問題なのかを理解しないままハックに走ると、ハックがハックを呼んで状況が悪化する可能性が高い。

A/Bテストのツール自体はシンプルだ。ボタンを押せばA群とB群が出てきて、p値が表示される。ただしそれは、統計の前提と指標設計をきちんと理解した人にとっての「シンプル」であって、何も知らない人がそのまま回せる魔法の箱ではない。「簡単に使えるツール」と「ちゃんとした知識の上で簡単に使えるツール」は、別物として区別しておきたい。

基礎は大事。