ベイズ型A/Bテストとは？｜「勝つ確率」と「期待損失」で判断する考え方と、p値との違い

A/Bテストの結果画面で「勝つ確率 97%」と表示されたとき、あなたはすぐにBを採用しますか。それとも、p値が0.05を下回っているかを探しにいきますか。

最近のA/Bテストツールでは、p値の代わりに勝つ確率や期待損失を表示するものが増えています。これらはベイズ統計と呼ばれる考え方にもとづく指標で、意思決定の言葉に近いぶん直感的に読めます。

一方で、ベイズ型なら途中で何度結果を見てもよい、少ない人数でも結論が出る、といった誤解も広がっています。この記事では、ベイズ型A/Bテストの仕組みを初学者向けに整理し、従来の方法(頻度論)との違い、読み方、そして運用でつまずきやすい落とし穴までを順に解説します。

ベイズ型A/Bテストとは何か

ベイズ型A/Bテストとは、観測したデータをもとに「BがAより良い確率」そのものを直接計算する検証方法です。結果は「Bが勝つ確率は97%」「Bを選んで外れたときの平均的な損は0.01ポイント」のように、判断にそのまま使える形で返ってきます。

事前分布・データ・事後分布の三段構え

ベイズ統計の基本は、テスト前の見込みをデータで更新していくことです。テスト前に持っている見込みを事前分布、データで更新した後の見込みを事後分布と呼びます。

たとえばコンバージョン率(CVR)について、テスト前は「0%から100%のどこでもありうる」という、ほぼ何も知らない状態から始めることができます。そこに「4,000人中120人が購入した」というデータを加えると、CVRは3%前後に集中した分布へと絞り込まれます。

この分布は、一つの数字ではなく「CVRがこのあたりにありそうだ」という幅を持った確信の度合いを表しています。AとBそれぞれについてこの分布を作り、二つを比べるのがベイズ型A/Bテストの骨格です。

ベータ分布が使われる理由

CVRのように「した/しなかった」の二択で表せる指標では、ベータ分布という確率分布がよく使われます。ベータ分布は0から1の範囲の値の確からしさを表す分布で、成功数と失敗数を足し込むだけで更新できるという便利な性質があります。

具体的には、事前分布をベータ(1, 1)という一様な分布にしておけば、事後分布はベータ(1+成功数, 1+失敗数)になります。複雑な計算を覚える必要はなく、購入した人数と、しなかった人数を数えるだけで事後分布が決まるわけです。

頻度論(p値)との違い

ベイズ型を理解するには、多くの人が学校や業務で触れてきた頻度論の検定と並べるのが近道です。両者は同じデータを見ていても、答えている問いがそもそも違います。

答えている問いが違う

頻度論の検定が返すp値は、「AとBに本当は差がないと仮定したとき、今回くらい極端なデータが偶然出る確率」です。回りくどい定義なので、「Bが勝つ確率は95%」と読み替えられてしまうことがよくありますが、それは誤りです。

ベイズ型は、まさにその読み替えたくなる問いに直接答えます。つまり「今のデータを見たうえで、BがAより良い確率はどれくらいか」です。

次の表は、両者の違いを実務で気になる観点ごとにまとめたものです。

どちらが正しいという話ではない

ここで強調しておきたいのは、どちらかが正しく、どちらかが間違っているわけではないという点です。十分なデータがあり、事前分布をほぼ無情報にしておけば、両者はたいてい似た結論にたどり着きます。

違いが出るのは、データが少ないとき、途中で結果を見るとき、そして結果を誰にどう伝えるかの場面です。どちらの方法を使うかより、選んだ方法のルールを事前に決めて守れるかのほうが、結論の信頼性にはずっと効いてきます。

勝つ確率と期待損失の読み方

ベイズ型の結果画面で中心になるのは、勝つ確率と期待損失の二つです。片方だけを見て判断すると誤りやすいので、セットで読む習慣をつけましょう。

勝つ確率(Chance to Win)

勝つ確率は、AとBの事後分布から値を何万回も取り出し、BがAを上回った割合として計算されます。ツールによって「Probability to be best」「Chance to win」など呼び名は違いますが、意味はほぼ同じです。

代表的なツールのドキュメントでは、95%を勝ちの目安として既定にしている例が見られます。ただしこれはあくまで既定値であり、間違えたときの痛みが大きい変更ほど高く、気軽に戻せる変更ほど低く設定するのが本来の使い方です。

期待損失(Expected Loss)

期待損失は、「Bを採用したのに実はAのほうが良かった場合、平均してどれだけ損をするか」を表す数字です。外れる確率だけでなく、外れたときの損の大きさまで掛け合わせて評価する点が特徴です。

勝つ確率が80%でも、外れたときの差がごくわずかなら採用して問題ないことがあります。逆に勝つ確率が95%でも、外れたときにCVRが大きく下がる可能性が残っているなら、もう少しデータを待つべきかもしれません。

信用区間で差の幅を見る

三つ目に見ておきたいのが、信用区間です。これは「BとAの差が、95%の確率でこの範囲に収まる」という幅を示すもので、頻度論の信頼区間とよく似た見た目をしています。

勝つ確率が高くても、信用区間が「ほぼゼロから大きなプラス」まで広がっているなら、改善の大きさはまだよく分かっていません。売上予測やロードマップの説明に使うなら、勝ったかどうかよりどれくらい勝ったかの幅を伝えるほうが、後で期待外れを生みにくくなります。

計算してみる

ここでは、二つのテストを想定した仮の数値で、Pythonの標準ライブラリだけを使って計算してみます。数値は説明用の仮定です。

import random

def compare(conv_a, n_a, conv_b, n_b, draws=200_000):
    win, loss_b = 0, 0.0
    for _ in range(draws):
        a = random.betavariate(1 + conv_a, 1 + n_a - conv_a)
        b = random.betavariate(1 + conv_b, 1 + n_b - conv_b)
        win += b > a
        loss_b += max(a - b, 0)  # Bを選んで外れたときの損
    return win / draws, loss_b / draws

print(compare(120, 4000, 150, 4000))  # 約 (0.97, 0.00005)
print(compare(12, 400, 15, 400))      # 約 (0.72, 0.0023)

一つ目は各群4,000人でAが3.0%、Bが3.75%というケースで、勝つ確率は約97%、期待損失は約0.005ポイントでした。二つ目はCVRの比率はまったく同じで、人数だけ10分の1にしたケースですが、勝つ確率は約72%に下がり、期待損失は約0.23ポイントまで膨らみます。

同じ見た目の差でも、データ量によって確信の度合いはまるで違うことがわかります。結果画面のCVRの差だけを見て判断する危うさが、数字で確認できるはずです。

ベイズ型にまつわる三つの誤解

ベイズ型の分かりやすさは大きな利点ですが、そのぶん過大な期待もつきまといます。現場でよく耳にする誤解を三つ取り上げます。

誤解1: 何度覗いても問題ない

もっとも広く信じられているのが、ベイズ型なら途中で何度結果を見ても大丈夫という主張です。確かにベイズの事後分布は、いつ計算しても「その時点の確信の度合い」として解釈できます。

しかし、勝つ確率が95%を超えた瞬間に止めるという運用をすると、偶然の揺れで一時的に95%を超えたタイミングを拾ってしまいます。結果として、本当は差がないのに勝ちと判定する頻度は、事前に期間を決めた場合より高くなることがシミュレーションでも繰り返し示されています。

この覗き見の問題は、A/Bテストのピーキング問題で頻度論の側から詳しく扱っています。ベイズ型でも、止める条件と最短期間を事前に決めておくという処方箋は変わりません。

誤解2: 少ない人数でも結論が出る

ベイズ型は、データが少なくても何らかの勝つ確率を表示してくれます。表示されること自体は事実ですが、それは結論が出たことを意味しません。

前の節の計算例で見たように、人数が少なければ勝つ確率は中途半端な値にとどまり、期待損失も大きいままです。必要な人数の見積もりは、A/Bテストのサンプルサイズ設計と同じく、検出したい差の大きさから逆算するのが基本です。

誤解3: 事前分布で好きな結論にできる

事前分布を使うと聞くと、都合のよい見込みを入れて結果をねじ曲げられるのでは、と不安になる人もいるでしょう。理屈のうえではその通りで、極端に強い事前分布を置けば、少々のデータでは結論が動かなくなります。

だからこそ実務では、ほぼ無情報な事前分布を使うか、過去のテスト結果から控えめに作った事前分布を使うのが一般的です。事前分布をテスト開始前に決めて記録しておくことが、恣意性を疑われないためのいちばんの防御になります。

運用ルールの設計

ベイズ型を安全に使うには、統計の知識以上に、チームで共有する運用ルールが重要です。ここでは、テスト開始前に決めておきたい項目と、結果が出た後の判断の流れを整理します。

開始前に決めておく四つのこと

次の四つは、テストを始める前に文書に残しておくことをおすすめします。

• 主指標と、採用を判断する勝つ確率の閾値
• 許容できる期待損失の上限(これ以下なら差は気にしないという水準)
• 最短の実施期間と、打ち切る最長期間
• 悪化してはいけない副指標と、その許容範囲

最後の副指標は、主指標が勝っても製品のどこかを壊していないかを確かめるためのものです。考え方の詳細はガードレール指標で解説しています。

結果が出た後の判断フロー

テスト期間が終わったら、勝つ確率と期待損失を組み合わせて判断します。次の表は、その組み合わせごとの典型的な判断の目安です。

三行目は見落とされがちですが、実務ではとても大切です。差がないとわかったこと自体が成果であり、それ以上テストを続けるより、次の仮説に人数を回したほうが得なことは少なくありません。

結果を疑う前提のチェック

勝つ確率がどれほど高くても、データの集め方が壊れていれば意味がありません。AとBへの振り分け比率が設計どおりかを確かめるSRM(サンプル比率の不一致)のチェックは、ベイズ型でも頻度論でも最初に行うべき確認です。

また、勝つ確率は一つの指標についての答えにすぎません。指標を何十個も並べて、そのうち一つが95%を超えたことを喜ぶのは、偶然の当たりを探しているのと同じだと心得ておきましょう。

どんなチームにベイズ型が向くか

最後に、ベイズ型がどのような場面で力を発揮し、どんな場面では慎重になるべきかを考えます。

向いている場面

ベイズ型がもっとも役立つのは、統計の専門家ではない人が意思決定に関わる場面です。プロダクトマネージャーやマーケター、経営者に「勝つ確率は97%、外れても損は小さい」と伝えるほうが、p値の定義を説明するよりはるかに議論が前に進みます。

また、一つのテストに大量の人数を割けない小さなプロダクトでも、期待損失を使えば「この程度の損なら採用して前に進もう」という合理的な割り切りがしやすくなります。インディーハッカーや少人数のチームにとっては、完璧な証明より、外れたときの損を管理しながら速く学ぶほうが現実的なことが多いはずです。

慎重になるべき場面

一方で、医療や金融など厳密な誤り率の保証が求められる領域や、学術的な報告を前提にするテストでは、頻度論の枠組みが求められることがあります。また、ベイズ型の結果をそのまま使い続けると、トラフィック配分を自動で寄せていくマルチアームドバンディットのほうが目的に合う場合もあります。

ちなみにMonaLensのA/Bテスト機能も、勝つ確率をシミュレーションで計算するベイズ型の集計に、SRMの検知を組み合わせた結果表示を採用しています。どのツールを使う場合でも、表示される数字の背後にある前提を知っておくことが、誤った採用を防ぐ近道です。

まとめ

ベイズ型A/Bテストは、「Bが良い確率」と「外れたときの損」を直接示してくれる、意思決定の言葉に近い検証方法です。事後分布はベータ分布で簡単に更新でき、計算自体もシミュレーションで手軽に行えます。

ただし、何度覗いても大丈夫、少人数でも結論が出る、といった期待は誤りです。

閾値・期待損失の上限・期間・副指標を事前に決めるという地味なルールこそが、ベイズ型の分かりやすさを本物の信頼性に変えてくれます。次のテストでは、結果画面を開く前に、まずこの四つを書き出すところから始めてみてください。