SRM（サンプル比率の不一致）とは？｜A/Bテストの結果を疑うべき最初のサイン

A/Bテストの結果画面を開いたら、新しいデザインのBが大きく勝っていた。うれしい半面、どこか出来すぎだと感じたことはないでしょうか。

その違和感は、結果の数字よりも先に見るべき場所があるというサインかもしれません。50対50で振り分けたはずなのに、実際の人数が片方に偏っている状態です。

この偏りはSRM（Sample Ratio Mismatch、サンプル比率の不一致）と呼ばれます。本記事では、SRMとは何か、なぜ起きるのか、どう検出してどう対処するのかを、初めての人にもわかるように順を追って整理します。

SRM（サンプル比率の不一致）とは何か

まずは言葉の意味から確認しましょう。SRMとは、A/Bテストで設定した振り分け比率と、実際に観測された人数の比率が、偶然では説明できないほどずれている状態を指します。

A/Bテストは、訪問者をランダムに2つの群に分け、片方には元のページ（A）、もう片方には変更したページ（B）を見せて、成果を比べる手法です。

少しのずれは自然に起きる

ランダムに振り分ける以上、人数がぴったり半分ずつになることはまずありません。コインを100回投げて表がちょうど50回になる方が珍しいのと同じです。

問題になるのは、その揺らぎの範囲を明らかに超えるずれです。統計的に見てありえないほどの偏りがあるとき、振り分けか計測のどこかが壊れていると考えます。

なぜ結果より先に見るべきなのか

A/Bテストの比較が成り立つのは、2つの群が変更点以外は同じ性質の集団だという前提があるからです。ランダムな振り分けは、その前提を保証するための仕組みにすぎません。

人数が不自然に偏っているなら、どこかで特定の種類の人だけが片方の群から抜け落ちている可能性があります。その場合、BがAに勝ったのは変更の効果ではなく、集団の中身が違ったせいかもしれないのです。

なぜSRMは結果を信用できなくするのか

ここで、SRMが結果を歪める仕組みを具体的に見てみましょう。数式よりも、どんな人が消えるのかを想像する方がわかりやすいはずです。

消えた人が成果を左右する

たとえばBのページだけ読み込みが重く、回線の遅い人ほど計測タグが動く前に離脱してしまったとします。すると、Bの群からは買う気が薄くすぐ去りがちな人が記録されずに消えていきます。

残ったBの群は、もともと熱心な人の割合が高い集団です。当然コンバージョン率（訪問者のうち成果に至った割合）は高く見えますが、それはページの出来とは無関係です。

大規模な実験基盤でも珍しくない

SRMは、慣れたチームなら起きないという類の問題ではありません。マイクロソフトの研究チームによるSRMの診断に関する解説記事では、同社のA/Bテストの約6%、LinkedInで詳しく分析したテストの約10%でSRMが見つかったと紹介されています。

専任の実験基盤チームを持つ企業ですら、一定の割合で起きているという事実は重いものです。小さなチームが手作りの仕組みで回すテストなら、なおさら確認を習慣にしておく価値があります。

有意差の検定では気づけない

厄介なのは、SRMが起きていても結果画面は普通に勝ち負けを表示してしまう点です。勝率や有意差の計算は、群の中身が同じだという前提の上で動いているからです。

前提が崩れていても、計算そのものはエラーを出しません。数字がきれいに出ていることは、その数字が正しいことの証明にならないのです。

SRMを生む典型的な原因

では、SRMはどこから生まれるのでしょうか。先ほどのマイクロソフトの解説では、原因が入り込む段階を、振り分け・実行・ログ処理・分析の4つに分けて整理しています。

振り分けと実行の段階

最初に疑うべきは、訪問者を群に割り当てる仕組みそのものです。ユーザーIDの扱いを誤って同じ人が何度も別の群に入り直したり、以前のテストの割り当てを引きずったりすると、比率は簡単に崩れます。

実行の段階では、Bだけがリダイレクト（別のURLへの転送）を挟む構成が典型的な落とし穴です。転送の途中で離脱した人や、転送先で計測が動かなかった人は、Bの群からだけ静かに消えていきます。

ログ処理と分析の段階

計測データを集計する段階でも、比率は崩れます。代表的なのがボット判定です。

前述の解説には、MSNで行われたカルーセル（横にスライドする表示枠）のテストで、Bをよく操作した利用者の動きがボット判定アルゴリズムに誤ってボットと見なされ、除外されていたという事例が紹介されています。人間らしくない速さで操作する人ほど消えるのですから、結果は大きく歪みます。

ボットやクローラーの扱いはAIクローラーの急増とボットトラフィック｜PVの数字は「人間」を語れているかでも取り上げましたが、除外ルールが群ごとに違う効き方をすると、それ自体がSRMの原因になります。分析の段階では、群によって偏る条件で絞り込むことも原因になります。

人の運用ミスとブラウザの事情

技術的な不具合だけでなく、運用のミスもSRMを生みます。テストの途中で配分比率を変えたり、片方の群だけ先に配信を広げたりすると、期間ごとに比率が違う集団が混ざります。

ブラウザ側の事情も見逃せません。トラッキング防止機能や広告ブロッカーが片方の群でだけ計測スクリプトの動きに影響すると、その群の記録が欠けます。

この仕組みについて、詳しくはトラッキング防止機能とは？｜Safari・Firefox・広告ブロッカーがアナリティクスを削る仕組みを参照してください。

原因と見るべき箇所を、段階ごとに表にまとめました。

SRMの検出方法｜カイ二乗検定の考え方

原因を探す前に、まずは偏りが本物かどうかを判定する必要があります。ここで使われるのがカイ二乗適合度検定です。

期待値とのずれを一つの数字にまとめる

カイ二乗適合度検定とは、観測した人数が、期待していた人数からどれだけずれているかを測る検定です。各群について、観測値と期待値の差を二乗し、期待値で割った値を合計します。

この合計が大きいほど、ずれは偶然では説明しにくくなります。合計値からp値（偶然でこれほどのずれが起きる確率）を求め、それが十分小さければSRMと判定します。

計算例｜同じずれ方でも結論が変わる

具体的な数字で確かめてみましょう。以下はいずれも50対50で振り分けたと仮定した説明用の例で、実在のテストの数値ではありません。

2行目と3行目は、どちらもA群が51.2%、B群が48.8%という同じ比率です。それでも人数が10倍になると、同じ1.2ポイントのずれが偶然ではありえない水準になります。

人数が多いほど偶然の揺らぎは小さくなるので、わずかな偏りでも検出できるようになるわけです。比率の見た目だけで大丈夫そうだと判断するのが危ない理由はここにあります。

閾値はかなり厳しく置く

SRMの判定には、通常の有意差の検定よりずっと厳しい閾値を使うのが一般的です。先ほどのマイクロソフトの解説では、同社の実験基盤がp値0.0005未満という保守的な基準を使っていると紹介されています。

厳しくする理由は、テストのたびに毎回チェックするからです。緩い閾値だと誤報が増え、本物の警告まで無視されるようになってしまいます。

上の例で言えば、2行目のp値0.016は通常の基準の0.05なら引っかかりますが、厳しい基準では警告になりません。一方で3行目は、どの基準で見ても明確なSRMです。

手元で確かめる計算式

専用のツールがなくても、2群なら簡単な計算で確かめられます。以下は標準ライブラリだけで書いたPythonの例です。

import math

def srm_p_value(a, b, ratio_a=0.5):
    total = a + b
    exp_a, exp_b = total * ratio_a, total * (1 - ratio_a)
    chi2 = (a - exp_a) ** 2 / exp_a + (b - exp_b) ** 2 / exp_b
    # 自由度1のカイ二乗分布の上側確率
    return math.erfc(math.sqrt(chi2 / 2))

print(srm_p_value(50800, 49200))  # 約4.2e-07 → SRMの疑いが強い

3群以上のテストでは自由度が変わるため、統計ライブラリの関数を使うのが安全です。なお、実験の実務家として知られるルーカス・フェルメール氏が公開していたSRMチェック用のブラウザ拡張は、主要な実験ツールの多くがSRMチェックを標準で備えるようになったことなどを理由に、現在は開発を終えています。

SRMが出たときの対処の進め方

検定でSRMが出たら、どう動けばよいのでしょうか。最初に決めておきたいのは、SRMが出たテストの勝敗は、原因がわかるまで判断に使わないという原則です。

結果を捨てる勇気を持つ

数週間かけたテストの結果を保留にするのは、正直つらいものです。Bが勝っているならなおさら、多少の偏りは目をつぶりたくなります。

それでも、偏りの原因がBの変更そのものに関係しているなら、勝ちは見せかけの可能性が高いのです。誤った勝者を本番に出すコストは、テストをやり直すコストよりずっと大きいと考えましょう。

原因を絞り込む順番

原因探しは、あてもなく調べると時間ばかりかかります。次の順に切り分けると、効率よく絞り込めます。

• 偏りがテスト開始直後からあるのか、途中から急に出たのかを日別に確かめる
• デバイスやブラウザ、流入元ごとに比率を分け、特定の層だけで崩れていないかを見る
• Bだけにある処理（転送、追加の読み込み、新しいスクリプト）を洗い出す
• ボット判定や重複除去などの除外処理が、群ごとに同じ割合で効いているかを比べる

途中から偏り始めたなら、その日に行った設定変更やリリースが有力な手がかりになります。特定のブラウザだけで崩れているなら、計測スクリプトの互換性や読み込み順を疑います。

直したらテストはやり直す

原因が見つかって修正したら、基本的にはテストを最初からやり直します。偏った期間のデータを部分的に削って使い回したくなりますが、どこまでが汚れているかを正確に切り分けるのは難しいからです。

必要な人数や期間の見積もりはA/Bテストのサンプルサイズ設計｜検定力とMDEをどう決めるかで解説しました。やり直しの計画もそれに沿って立て直します。

SRMを予防する運用の型

最後に、SRMをそもそも起こしにくくする運用を考えます。検出は事後の安全網で、本当に効くのは仕組みで防ぐことです。

テスト前に決めておくこと

テストを始める前に、配分比率と、比率を変えない期間をチームで合意しておきます。途中で配分を変えたくなったら、それは新しいテストとして始め直すルールにしておくと安全です。

あわせて、SRMチェックを結果確認の最初の手順に組み込みます。勝敗を見る前に比率を確かめる順番にしておけば、うれしい数字に引っ張られて見落とすことがなくなります。

毎日の結果確認との付き合い方

結果を毎日のぞいて有利なときに止めてしまう問題はA/Bテストのピーキング問題（覗き見問題）とは？｜早期終了が結果を歪める理由と防ぎ方で扱いました。勝敗は判定日まで待つべきですが、SRMは事情が違います。

比率の偏りは、早く見つけるほど失う期間が短くて済む種類の問題です。勝敗の判断は我慢しつつ、比率の健全性は早い段階から確かめておくのが理にかなっています。

ツールに任せる部分と人が見る部分

最近の実験ツールの多くは、SRMの自動チェックを備えています。MonaLensのA/Bテストでも、各群の人数をカイ二乗検定で確かめ、p値が0.001を下回ると比率の不一致を警告する仕組みにしています。

ただし、ツールが教えてくれるのは偏りがあるという事実までです。なぜ偏ったのかを突き止め、その結果を捨てるか判断するのは人の仕事として残ります。

まとめ｜勝敗より先に、比率を見る

SRMは、A/Bテストの結果が信用できるかどうかを教えてくれる、最も手軽で強力な健康診断です。計算は単純で、必要なのは各群の人数と設定した比率だけです。

それでも見落とされがちなのは、私たちがどうしても勝敗の数字に先に目を奪われるからでしょう。次に結果画面を開くときは、まず人数の比率を確かめるところから始めてみてください。