A/Bテスト再考

Mon, 04 May 2026 17:15:00 +0900

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テストのステップは以下のようになります。

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

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検証で購買意欲の低いユーザーがバグで実験群から脱落していたことが判明し、結果は無効化されている。

Research on callas1900.net