ABテストとは何か。何を比べていて、いつ止めるのか

ABテストの止めどきは、使う統計方式で変わる

ABテストは、訪問者をランダムに分け、異なる案の成果を比べる方法です。管理画面の数字が動いても、方式の停止条件を外れて、勝っている瞬間だけを選んで止めることはできません。最初に自分たちのツールの統計方式を確認し、その方式の停止条件を記録します。

ツールの実験設定と公式ヘルプで、固定サンプルサイズ方式、逐次検定方式、ベイズ方式のどれを使うかを確認します。画面の「有意」という表示や残り件数だけでは方式を判断できません。方式が分からない間は、途中の数字だけで採否を決めず、管理者や製品のサポートに確認します。

• 固定サンプルサイズ方式事前に決めた数と時点で判定。途中のp値では採否を決めない
• 逐次検定方式途中の結果を判断に使える。製品が定める停止条件を確認する
• ベイズ方式案が優れている確率などを読む。採用・中止の条件を製品の説明に沿って決める

方式の名前が同じでも製品の設定や表示は違います。使っているツールの条件を、別方式の計算サイトのp値へ置き換えないことが必要です。

何を比べているのか

ABテストは、内容の異なる2つのパターンを訪問者にランダムに出し分けて、どちらの成果指標が良いかを比べる方法です。対象は2つの画面そのものではありません。Aを見た集団とBを見た集団、その指標を突き合わせています。

この区別が後で効いてきます。同じ母集団からランダムに2つに分けた以上、両方にまったく同じものを出しても、集まった数字には偶然の差が出ることがあります。Optimizely が公式ブログで公開したシミュレーションは、真の差が無い設定、つまり同じものを両側に出すAAテストでも、見るタイミング次第で勝敗がついたように見える瞬間が現れることを示しています。

出た差が仕掛けによるものなのか、分かれ方の偶然なのかを切り分ける手続きが要ります。固定サンプルサイズ方式では、有意水準5%を設定し、事前に決めた時点でp値が0.05を下回るかを見る方法があります。ただし、これはどの統計方式にも共通する停止条件ではありません。

回す前に決めること

成功の条件を実装の前に決める

何を変えると、誰のどの行動が変わると考えるかを先に書きます。たとえば申込完了率を主要指標にするなら、申込数だけでなく分母になる対象者も揃えます。途中で良かった指標へ主要指標を変更すると、最初の仮説を確かめたテストではなくなります。

開始前の記録	決めておくこと
仮説と対象	変更する箇所、対象者、ランダムに分ける単位、割付割合
成果	主要指標と分母、改善として採用する条件
方式と停止	統計方式、製品の判断条件、採用・継続・判定保留を決める担当
業務上の確認	計測不具合や障害で中断する条件、影響を監視する指標、成果が記録されるまでの時間

計測不具合や障害で中断した場合は、その理由を記録し、途中の好調な数字を採用の根拠にしません。中断と、優れた案が決まったという判定は別です。成功の条件を先に決める考え方は、生成AIのPoCの合格条件にも共通します。

検出したい差から必要人数を計算する

現在の申込率が2%で、2.4%への改善を検出したいとします。差は0.4ポイント、相対では20%増です。これは人数を設計するための最小差で、採用に必要な改善幅は費用や成果の価値から別に決めます。

計算例の設定	値・前提
方式・対象	固定サンプル方式。独立した利用者をランダムにAとBへ1対1で割り付け、1人の申込有無を比べる。主要指標1つ、比較はAとBの1回
ベースラインと検出したい差	2%と2.4%を想定。差は0.004
有意水準・検出力	両側5%・80%
計算法	二群比率の正規近似、連続性補正なし
必要人数	各案21,109人、全体42,218人

Rの比率用計算関数 power.prop.test(p1=.02, p2=.024, sig.level=.05, power=.80, alternative="two.sided", strict=FALSE) と同じ正規近似の式で各案21,108.38人となり、整数へ切り上げています。自分たちの申込率と検出したい差に置き換えて計算します。検出力80%は、真の率がこの想定どおりなら差ゼロを棄却できる確率の近似値で、今回のテストが成功する保証ではありません。

ベースラインは対象者・計測定義・期間を揃えた過去データから設定します。平均金額など別の指標、複数案や複数指標の判定には、それに対応する設計が必要です。逐次検定やベイズ方式には、この人数を停止条件として流用せず、製品の条件を確認します。

各案への流入で日数を見積もる

上の人数を使い、実験対象に入る新しい利用者が全体で1日200人という架空の流入を置きます。半分ずつなら各案へ1日100人。21,109人を100人で割ると211.09日なので、人数が集まるまで212日が目安です。全体42,218人を1日200人で割っても同じになります。

全訪問回数ではなく、同じ人の再訪を重複させない実験対象者を数えます。流入が一定という仮定なので、割付や流入が変わる場合は各案への人数で見積もり直します。212日の間に利用条件が変わりそうなら、開始前に対象や仮説、検証方法を見直します。

判定日は、必要人数に加えて平日・休日の周期と成果が記録されるまでの待ち時間から決めます。実施期間の上限も記録し、予定人数へ届かず終了した場合は判定保留とします。人数や終了条件を、途中の好調な数字に合わせて変えません。

途中の結果で止めると何が起きるか

Optimizely のAAテストのシミュレーションが、数字で答えを出しています。5,000人の訪問者を対象に、真の差が無い設定で回したときの誤判定率です。

方式と途中判定の頻度	誤って勝敗を宣言する確率
固定サンプルサイズ方式で訪問者1人ごと	57%
固定サンプルサイズ方式で500人ごと	26%
固定サンプルサイズ方式で1,000人ごと	20%
逐次検定（Stats Engine）で訪問者1人ごと	3%

これは真の差をゼロに設定したシミュレーションです。固定サンプルサイズ方式の途中で有意になった瞬間を採用すれば、誤って勝敗を宣言するケースが増えます。表の3%はこの設定でのStats Engineの結果で、すべての逐次検定や実験に共通する誤判定率ではありません。

固定サンプルサイズ方式の検定では、評価する時点を事前に決めます。指標は日々上下に揺れるので、真の差が無くても、途中で閾値をまたぐ場合があります。途中で見つけたその瞬間に止めれば、都合のよい時点を選んで拾ったことになる。画面を開いて計測不具合を見ることと、その時点のp値で勝敗を決めることを区別します。

実験を始める前に、使う方式と停止条件を揃えます。固定サンプルサイズ方式で途中の数字を採否に使ったり、ベイズ方式の確率をp値と同じものとして読んだりすると、選んだ方式の前提から外れます。「有意差が出たら止める」だけでは、判断の条件が抜け落ちます。

結果を見る担当と、停止・採用を判断する担当を記録します。複数人で運用するなら、途中で指標や停止条件を変更する場合も、誰が何を理由に変更したかを残します。

結果から採用・見送り・判定保留を決める

固定サンプル方式では、まず予定人数と観測期間、計測・割付の不具合を確認し、事前に決めた時点で判定します。「有意差なし」は差ゼロの証明ではありません。差の推定値と信頼区間を、業務上必要な改善幅と照らし合わせます。

費用を回収する改善幅を先に置く

ここからは架空の判断例です。導入・運用費を月10万円に換算し、導入後の対象者を月1万人、追加の申込1件が生む利益を5,000円と置きます。費用回収には月20件の増加、申込率では0.2ポイントの改善が必要です。先ほどの検出対象0.4ポイントとは用途が違い、この人数計算は0.2ポイントを上回ることを80%の検出力で確かめる設計ではありません。

• 採用差の95%信頼区間の下限が0.2ポイントを上回り、悪化監視の条件も満たす
• 見送り区間の上限が0.2ポイントを下回り、費用を回収する改善を支持できない
• 判定保留区間が0.2ポイントをまたぎ、必要な改善を満たすか決め切れない

これは不確実性を含めて費用回収を判断する事前ルールの一例です。採用時には決済エラー率などの悪化監視指標も、別途決めた許容上限と照合します。主指標が良くても、許容範囲を超える悪化がある、または悪化を判断できない場合は採用しません。

同じ人数でも、区間によって判断が変わる

各案21,109人を観測し、Aで422件の申込があったとします。Bの申込数を変えた3通りの架空結果です。差はBからAを引いたポイント、95%信頼区間は二群比率の正規近似で、連続性補正なし。悪化監視の条件は別途確認できたと仮定します。

B申込数	差と95%区間 （ポイント）	事前ルールでの判断
550件	+0.61 +0.32〜+0.89	採用。下限でも費用回収に必要な0.2ポイントを上回る
380件	−0.20 −0.46〜+0.06	見送り。有意差はないが、上限でも必要な改善に届かない。効果ゼロとは断定しない
486件	+0.30 +0.03〜+0.58	判定保留。ゼロとの差は有意でも、0.2ポイントを満たすか決め切れない

保留のまま今回の実験を終えることも結果です。有意になるまで同じ実験を延長せず、新しい検証が必要なら仮説・人数・終了条件を改めて設計します。逐次検定やベイズ方式の結果は、製品で定めた条件に戻って読みます。

記録には、方式と設定、集まった人数、対象期間、差の推定と不確実性、監視指標、採否の理由を残します。統計的な差と業務上の採用判断を分けると、次の仮説へ進む根拠になります。

ABテストに乗らない変更

固定サンプルサイズ方式で必要な人数が現実的な期間に集まらないなら、実装前に検証方法を見直せます。小さな差を検出したい、対象画面の流入が少ない、成果が出るまで長い、といった条件を確認します。逐次検定やベイズ方式でも、判定に必要な情報が十分に集まるかを確認します。

その変更をABテストで採否判断する必要があるかも分けます。不具合の修正なら、仕様と回帰テストで正しさを確認する方法があります。使いづらさの原因を探すなら、利用者の操作を観察して仮説を絞れます。ABテストの代わりに別の方法を選んだ場合も、同じ水準で効果を証明できたとは扱いません。

社内で実験を回す際も、外に依頼する際も、改善案を出す範囲、実装、計測、結果の判断を分けて担当を決めます。プロダクト開発支援への相談では、試す案と一緒に、対象者・指標・統計方式・停止条件を揃えると、検証までの仕事の範囲が明確になります。