ABテストを回しているとき、いちばん判断に困るのは止めどきです。管理画面の数字は毎日動きます。昨日まで負けていた案が今日は勝っていて、明日にはまた入れ替わる。どこかで線を引かないと終わりませんが、その線の引き方を間違えると、テストをやった意味がなくなります。
「ABテストとは」で上位に並ぶ解説記事を2026年8月に読み比べたところ、言葉の定義はほぼ一致していました。割れるのは止めどきの扱いです。「有意差が出たら終了」とだけ書いて、その基準に達する前に結果を覗きながら判断するとどうなるかに触れていない記事が目立ちます。
何を比べているのか
ABテストは、内容の異なる2つのパターンを訪問者にランダムに出し分けて、どちらの成果指標が良いかを比べる方法です。対象は2つの画面そのものではありません。Aを見た集団とBを見た集団、その指標を突き合わせています。
この区別が後で効いてきます。同じ母集団からランダムに2つに分けた以上、両方にまったく同じものを出しても、集まった数字は一致しません。Optimizely が公式ブログで公開したシミュレーションは、真の差が無い設定、つまり同じものを両側に出すAAテストでも、見るタイミング次第で勝敗がついたように見える瞬間が現れることを示しています。
出た差が仕掛けによるものなのか、分かれ方の偶然なのかを切り分ける手続きが要る。そのために有意水準5%、つまりp値が0.05を下回るかどうかを判定の基準に置く。この置き方は解説記事のあいだで共通しています。
解説が割れるのは「いつ止めるか」
定義が揃っているのに、止めどきの説明は記事ごとに違います。
多いのは、有意差が出たら終了、とだけ書いて済ませるものです。期間の目安として最低2週間を挙げるところまでは共通していますが、その基準に達する前に結果を覗いた場合にどうなるかは書かれていません。
覗くリスクに触れている記事もあります。ただし「毎日p値を確認して0.05を下回った時点で止めると、偽陽性率が最大26%に達する」といった数字を出しながら、その数字の出どころを本文で示していない。読んだ側は、信じるか無視するかしか選べません。
この分岐に公式の答えを出しているのは、ツールを作っている側の文書です。Optimizely のサポート文書は、固定サンプルサイズ方式（頻度論）について「必要なサンプルサイズと期間に達する前に結果を確認しない」ことを明記のルールとして挙げています。一方、ベイズ方式と逐次検定方式については、途中でのモニタリングを許可しています。
有意差が出たら終わり、が成立するかどうかは、使っている方式で変わります。ここを飛ばすと、止めどきの議論は噛み合いません。
回す前に決めること
成功の条件を実装の前に決める
Nue が プロダクト開発支援 で固定している工程は、データ分析、UX診断、改善案、UI、ABテスト案の順です。最後のABテスト案でやっているのは、何をどう比べれば判断できるかの設計と、何をもって成功とするかを実装の前に決めることです。改善案は仮説なので、検証して初めて分かる。その前提に立った工程です。成功の基準を先に決めておく考え方は、生成AIのPoCが本番に行かない理由で書いた合格条件の話と同じです。
検出したい差を決める
ここで決めた値が、テストの期間まで決めます。仮説検定に必要なサンプルサイズは、有意水準、検出力、検出したい差の大きさ（ばらつきに対する比）で決まり、検出したい差が小さいほど、その2乗に反比例して必要な数が増えます。米国国立標準技術研究所（NIST）の統計ハンドブックに載っている関係です。
ハンドブックが示している式は1つの平均に関する検定のもので、ABテストでよく使う2群の比率の比較そのものではありません。ただし、検出したい差が小さいほど必要な数が2乗で効いてくるという関係は同じ形になります。
実務で効くのはこの一点です。検出したい差を半分にすると、必要なサンプルサイズはおよそ4倍になります。小さな違いまで拾いたいと言った瞬間に、テストの規模が跳ね上がる。
期間は逆算で出す
期間を先に置くと、必要な数が集まっているかどうかとは無関係に終わりが来ます。順序は逆にします。検出したい差から必要なサンプルサイズを出し、1日あたりの流入で割って期間に直す。ここで出た期間が現実的でなければ、実装に入る前にそのテストをやめる判断ができます。
途中で覗くと何が起きるか
Optimizely のAAテストのシミュレーションが、数字で答えを出しています。5,000人の訪問者を対象に、真の差が無い設定で回したときの誤判定率です。
| 結果を確認する頻度 | 誤って勝敗を宣言する確率 |
|---|---|
| 訪問者1人ごと | 57% |
| 500人ごと | 26% |
| 1,000人ごと | 20% |
| 逐次検定（Stats Engine）を使う | 3% |
真の差が無いのだから、正しい答えは「どちらも変わらない」です。それでも、訪問者ごとに結果を確認して有意になった時点で止めると、半分以上のケースで勝敗を宣言してしまう。同じ条件でも、Optimizely の逐次検定を使えば誤判定は3%まで下がります。
仕組みは単純です。有意性検定は、サンプルサイズが事前に固定されていることを前提に組み立てられています。指標は日々上下に揺れるので、真の差が無くても、どこかの瞬間には閾値をまたぎます。覗きながらまたいだところで止めれば、その瞬間を選んで拾ったことになる。統計ソフトウェアの開発者がこの問題をWeb業界に向けて指摘したのは2010年です。
対処は2つに分かれます。固定サンプルサイズ方式を使うなら、必要な数と期間に達するまで結果を判断に使わない。途中の状況を見ながら運用したいなら、それを前提に設計された逐次検定方式かベイズ方式のツールを選ぶ。使っているツールの方式を確認しないまま「有意差が出たら止める」だけを運用ルールにすると、その方式が置いている前提から外れます。
自分たちが今どの方式で回しているかは、ツールの設定画面か公式のヘルプで確認できます。見るのは3点です。事前にサンプルサイズを入力する欄があるか。結果画面に「有意」と出るまでの残り期間や残り件数が表示されるか。途中で結果を見てよいと明記されているか。3つ目が書かれていないなら、固定サンプルサイズ方式だと考えて運用した方が安全です。
複数人で回している場合は、結果を見る権限と、止める判断をする権限を分けておくと事故が減ります。数字が動いているのを毎日見ている人ほど、まだ足りていない段階で止めたくなるからです。
差が出なかったときに分かること
有意差なしで終わったテストから何が言えるかは、必要なサンプルサイズを集め切ったかどうかで変わります。
事前に決めた差に対して必要な数を集め終えた上で差が出なかったのなら、少なくともその大きさの差は、この条件では確認できなかった、と言えます。集め切る前に見て差が出ていない場合は、そこから言えることはありません。検出力は、必要なサンプルサイズを決める段階で織り込まれているものだからです。
有意差が出なかったことは、差が無いことの証明にはなりません。設計時に決めた差より小さい違いは、そもそも見つけられるように設計していない。ここを「効果なし」と丸めると、次の判断材料が消えます。
Nue は、改善案が当たらないこともある前提で、負けた施策も記録に残す方針を取っています。当たった施策だけを並べた報告は、次に何をすべきかを教えてくれないからです。
ABテストに乗らない変更
必要なサンプルサイズを先に出すと、テストに乗らない変更が見えてきます。
効果が小さいと見込まれる変更がそれです。検出したい差が小さいほど必要な数は2乗で増えるので、流入の少ない画面では、そこに届くまでに何か月もかかる計算になります。この場合は、テストで決める対象から外す判断が要ります。実装してから気づくと、そのぶんの工数と、判定できないまま放置されたテストが残ります。
裏を返すと、ABテストは回すかどうかから決める工程です。Nue 自身、この領域の見積りでは、案を出すところまでか、実装と結果の判断まで一緒にやるかで範囲を分けています。社内にテストの実務が薄い状態でも、設計だけを外に出して実施は自分たちでやる、という分け方ができます。
ABテストが答えを出すのは、決めた指標がどちらで良くなったか、そこだけです。リリースを重ねながら品質を保つのは別の仕組みの話なので、そちらは プロダクト開発支援 で扱っています。