ABテストとは、2つの案を同じ期間に同じ条件で出し分けて、どちらがコンバージョンを多く生むかを統計的に判定する検証手法です。手順そのものは「案を2つ作る、半分ずつ見せる、数字を比べる」だけで、専用ツールを入れれば数時間で始められます。ところが実務の失敗はほぼすべて、始めてからではなく始める前に決めるべき数字を決めていないことから生まれます。何%の改善を検出したいのか、各案へ何セッション必要なのか、いつ終えるのか。この3つを先に置かないABテストは、結論が出ないまま声の大きい人の意見で決着してしまうでしょう。この記事では定義の整理から入り、必要サンプル数をコピーして動かせるPythonコードとベースCVRごとの実数で示し、判定を壊す条件と、見送るべき場面までを順に扱います。
まとめ｜ABテストを始める前に決める3つの数字とやめる判断
先に結論を置きます。ABテストの成否は、開始前に決める3つの数字でほぼ決まります。
- ベースとなる現状のCVR（改善前の実測値。直近4週間程度の平均を使う）
- 検出したい改善幅（相対何%の差なら意思決定が変わるか。甘く見積もると必要数が跳ね上がる）
- 各案に必要なセッション数と、そこから逆算した期間（週の倍数で切る）
この3つを式に入れると、多くの中小規模サイトでは「必要数が現実の流入を超える」という答えが出ます。現状CVR2.0%のページで相対20%の改善（2.0%から2.4%）を検出するには各群およそ21,100セッションが必要で、週2,000セッションのページなら約5か月かかります。選択肢は3つに絞られるでしょう。もっと大きな差が出る案へ振り替えるか、CVより手前の指標（クリック率やフォーム到達率）を判定対象に切り替えるか、ABテストを見送って別の手を打つかです。この数字は後の章に置いた15行ほどのPythonコードで再現できるため、社内の議論では計算根拠ごと共有するのが早いはずです。
判定を壊す条件も先に挙げます。有意になった時点で打ち切る「途中の覗き見」、同じ導線で複数テストを並走させること、割り当ての崩れと計測の穴。いずれも集計上は綺麗な数字が出るのに、結論が偶然に寄ります。ツールが出す「勝者」の表示は、これらの前提が守られている場合にだけ意味を持つ数字です。
そしてABテストを見送る条件です。月間のコンバージョンが各案10件を割る規模、検証したい差が相対10%程度の小さな差、流入の質が週ごとに変わる期間、この3つのいずれかに当てはまるなら判定に届きません。代わりに、前後比較で方向を掴む、5人程度のユーザーテストで詰まりを見つける、案の差を大きくする、という手順へ切り替えましょう。
ABテストの定義と、多変量テスト・多腕バンディットとの守備範囲の違い
ABテストが答えを出せる問いと、枠組みの外にある問いの切り分け方
ABテストの本質は「同時性」と「無作為性」の2点にあります。同じ期間に訪問者をランダムな2群へ振り分け、片方に現行案（A：コントロール）、もう片方に変更案（B：バリエーション）を見せる。前後比較と違い、広告出稿の増減や季節要因といった外部要因が両群へ等しくかかるため、差分を変更案の効果として読めるわけです。逆に言えば、同時に2案を出せない対象は守備範囲外になります。値上げの是非のように全社へ一意でしか適用できない変更や、効果が現れるまで数か月かかる施策は測れません。
答えを出せる問いは、短期のコンバージョンに紐づき、ページ上で同時に2通り見せられる変更に限られます。ファーストビューの訴求文、CTAボタンの文言と位置、フォームの項目数、料金表の見せ方。これらは判定対象として素直でしょう。一方で「どちらのデザインが好まれるか」という好意度の問いには向きません。好意度はコンバージョンと相関しないことがあり、測っている指標がずれてしまいます。判定対象の指標を先に1つ決め、それ以外は参考値として扱ってください。指標の定義そのものに迷いがある場合は、CVR（コンバージョン率）とはで分母と分子の置き方を確認してから設計に入ってください。
多変量テスト（MVT）と使い分ける境界線はサイトの流入規模にある
ABテストが「ページ全体の2案比較」なのに対し、多変量テスト（MVT）は複数の要素をそれぞれ2通り以上用意し、組み合わせを同時に評価する手法です。見出し2通り×画像2通り×ボタン色2通りなら8パターンになり、要素ごとの寄与まで見えるのが利点です。反面、パターン数に比例して必要サンプル数が増えていきました。Google検索セントラルのABテストの影響を最小限に抑える方法でも、多変量テストは「一度に複数種類の変更を試し、各変更の影響と変更同士の相乗効果を見るもの」と定義されており、要素間の相互作用を見たい場合の手法だと位置づけられています。
実務上の線引きはこうなります。月間数万セッション規模までは、要素を1つずつ変えるABテストを直列に回すほうが速い。多変量テストが成立するのは、1ページで月間数十万セッションを持ち、かつ要素間の相互作用（画像を変えたら見出しの効き方が変わる）を疑う理由がある場合だけです。要素を1つに絞れないという理由で多変量へ逃げると、どのパターンも判定に届かないまま期間だけが過ぎてしまいました。
多腕バンディットとの違いと、配信比率を動かす手法を選ぶ場面の条件
多腕バンディットは、テスト期間中に成績の良い案へ配信比率を寄せていくアルゴリズムです。ABテストが「期間中は50:50を固定し、終わってから勝者に全振りする」のに対し、バンディットは検証しながら機会損失を減らします。短期キャンペーンのバナーやニュースの見出し選定のように、検証期間そのものが売上の本番であり、かつ結論を厳密に残す必要がない場面では有利でしょう。
ただし配信比率が動くため、各案の効果量を後から正確に推定しづらく、「なぜ勝ったのか」を説明する材料が残りません。組織の意思決定材料として効果量を報告する必要があるなら、固定比率のABテストのほうが扱いやすいはずです。アルゴリズムの中身と実装まで踏み込みたい場合は、多腕バンディット問題とは？仕組み・アルゴリズムとA/Bテストの違いをPythonで解説で探索と利用のバランスの取り方を確認できます。
有意水準・検出力・p値を先に決めてABテストの判定基準を固定する
p値が小さいことは効果が大きいことを意味しないという前提の確認
ABテストの判定でよく使われる「有意差」は、観測された差が、たまたま生じたと考えるには不自然なほど大きいかを表す指標です。有意水準5%（p<0.05）で有意という判定は、「本当は差がないのに差があると誤って言う確率を5%以内へ抑えた」という意味になります。ここで混同されやすいのが、p値の小ささと効果の大きさでしょう。サンプル数が多ければ、CVR2.00%と2.05%という意思決定に影響しない差でもp値は小さくなってしまいます。
実務で見るべきは、有意かどうかの二値ではなく効果量とその区間です。「B案のCVRはA案より相対12%高く、95%信頼区間は相対3%から22%」と報告できれば、下限の3%でも投資判断が成立するのかという議論へ持ち込めます。「勝者：B」とだけ表示する画面を報告に使うと、この幅が落ちてしまいました。区間の下限で意思決定が変わらないなら、その差は実装コストに見合いません。
検出力80%が意味する「効果のある案を5回に1回捨てる」という実態
有意水準と並ぶもう1つの入力値が検出力（統計的検出力）です。慣習的に80%が使われ、これは本当に想定した大きさの差がある場合に、それを有意と検出できる確率が80%という意味になります。裏を返せば、効果がある案を「差なし」と誤って捨てる確率が20%残るわけです。5回に1回は正しい案が却下される計算で、決して小さい数字ではないでしょう。
検出力を90%へ上げれば見逃しは減りますが、必要サンプル数は約1.34倍に増えます。作り込みに数週間かけた大掛かりな改修なら、見逃しの代償が大きいため検出力90%で設計する価値があるでしょう。文言の差し替え程度なら、80%で回して次の案に移るほうが総合的な学習速度は上がるはずです。なお必要数が足りないからといって片側検定へ切り替えるのは、B案がA案を下回る可能性を検証対象から外す宣言に等しく、筋が悪い選択です。
必要サンプル数をPythonで計算する関数を書いて実行結果を確かめる
依存ライブラリなしで動く必要サンプル数の計算コードと実行結果
ツールの計算機に数字を入れるだけでは、入力値を1つ動かしたときに必要数がどう跳ねるかが体感できません。標準ライブラリだけで動く関数を手元に持っておくと、企画会議の場で「その改善幅なら何セッション要る」と即答できます。次のコードは追加インストールなしで動き、下の表と同じ数値を出力します。
# 必要サンプル数の計算（2群の比率比較・両側・標準ライブラリのみ）
from math import sqrt, erf
def norm_ppf(p):
# 標準正規分布の分位点を二分法で求める（scipy不要）
lo, hi = -10.0, 10.0
for _ in range(200):
mid = (lo + hi) / 2
if 0.5 * (1 + erf(mid / sqrt(2))) < p:
lo = mid
else:
hi = mid
return (lo + hi) / 2
def sample_size(p1, lift, alpha=0.05, power=0.80):
# p1: 現状CVR, lift: 検出したい相対改善幅 戻り値は1群あたりの必要数
p2 = p1 * (1 + lift)
z_a, z_b = norm_ppf(1 - alpha / 2), norm_ppf(power)
var = p1 * (1 - p1) + p2 * (1 - p2)
return (z_a + z_b) ** 2 * var / (p2 - p1) ** 2
for p1 in (0.01, 0.02, 0.05, 0.10):
row = [round(sample_size(p1, lift)) for lift in (0.10, 0.20, 0.50)]
print(p1, row)
手元のPython 3.14系（2026年9月時点）で実行した出力は次のとおりです。左からベースCVR、続いて相対10%・20%・50%を検出するための1群あたりのセッション数になります。
0.01 [163092, 42690, 7747]
0.02 [80679, 21106, 3822]
0.05 [31231, 8155, 1468]
0.1 [14748, 3838, 683]
この関数の要点は、必要数を決めているのが分母に置いた差の2乗だという1点に尽きます。lift を半分にすると分母が4分の1になり、必要数はおよそ4倍へ膨らみます。逆に、狙う差を倍にすれば必要数は4分の1近くまで落ちました。統計の知識ではなく、この非線形性を先に知っているかどうかが設計の質を分けます。
statsmodelsで同じ計算をするときの関数と引数の対応関係
既にPythonの分析環境がある現場なら、statsmodelsのNormalIndPowerで同じ計算ができます。効果量にはproportion_effectsizeが返すコーエンのhを渡し、solve_powerでnobs1を未知数にすると1群あたりの必要数が返ります。上の自作関数は正規近似で分散を素直に置いたもの、statsmodels側は逆正弦変換を挟んだ効果量を使うため、数%のずれが出る点は把握しておいてください。桁が変わるほどの差ではないので、どちらで見積もっても意思決定は同じ結論になります。
検定側の関数もリファレンスで確認しておく価値があります。proportions_ztestのシグネチャはproportions_ztest(count, nobs, value=None, alternative='two-sided', prop_var=False)で、既定では標本比率にもとづく分散でz統計量を作ります。帰無仮説のもとでのプール分散を使いたい場合はprop_varへ比率を明示的に渡す仕様です。ツール間でp値が小数第3位あたりで食い違う原因の多くはここにあり、実装を読まずに数字だけ比べると理由の分からない差として残ってしまいます。
計算結果を表へ落とし込み、週あたりの流入から週数を出す具体的手順
関数が動いたら、対象ページの直近4週間の実測CVRと週あたりセッション数を入れて、必要数を週数へ割り戻します。手順は3つです。第1に、対象ページのみの実測CVRを取り出す。第2に、意思決定が変わる最小の改善幅を関係者で1つに決める。第3に、必要数の2倍（両群の合計）を週あたり流入で割り、7日の倍数へ切り上げる。この3ステップを企画書に貼れば、期間の議論が感覚論から外れます。
必要サンプル数と検証期間の見積り方｜ベースCVR別の実数で判断する
必要サンプル数を決める4つの入力値と、動かせるのは2つだけの事実
2群の比率を比較するときの必要サンプル数は、両側・有意水準5%・検出力80%の場合、次の式で各群あたりの数を出せます。
n =（1.96 + 0.84）2 ×｛p1(1 – p1) + p2(1 – p2)｝÷（p2 – p1）2
p1が現状のCVR、p2が目標のCVRです。入力値は4つ（現状CVR・目標CVR・有意水準・検出力）で、実務で動かせるのは前の2つだけと考えてください。現状CVRは実測値なので操作の余地がなく、結局「どれだけ大きな差を狙うか」がサンプル数を決めていることになります。分母が差の2乗であるため、狙う差を半分にすると必要数は約4倍へ膨らみました。ここが感覚と最もずれる部分でしょう。
なお現状CVRは、全ページ平均ではなくテスト対象ページの実測値を使ってください。参照元（広告・自然検索・メール）ごとにCVRが数倍違うことは普通にあり、平均を入れると見積りが実態から外れます。参照元別の数字の切り出し方はアクセス解析のやり方で確認できます。
ベースCVR別に見る各群あたりの必要セッション数の実数と読み方
前章のコードに実数を入れた結果が下の表です。数字は各群あたりに必要なセッション数で、合計流入はこの2倍になります。手計算で1.96と0.84を使うと1%ほど小さい値になりますが、判断は変わりません。
| 現状CVR | 相対+10%を検出 | 相対+20%を検出 | 相対+50%を検出 |
|---|---|---|---|
| 1.0% | 約163,100 | 約42,700 | 約7,700 |
| 2.0% | 約80,700 | 約21,100 | 約3,800 |
| 5.0% | 約31,200 | 約8,200 | 約1,500 |
| 10.0% | 約14,700 | 約3,800 | 約680 |
表から読み取れる含意は2つあります。1つはベースCVRが低いページほど検証が難しいという非対称性です。CVR1.0%のLPで相対10%改善を検出するには各群16万セッションが必要で、大半のBtoBサイトでは年単位の話になってしまいます。もう1つは狙う差を大きくすると必要数が急激に減ることでしょう。CVR2.0%でも相対50%（2.0%から3.0%）を狙うなら各群3,800セッションで足り、週2,000セッションのページでも1か月弱で判定に届きます。
この非対称性は、テストの設計方針を変えます。流入が限られるサイトでは、ボタンの色や文言の微修正を並べるより、構成を作り替えるレベルの大きな案を1つ用意して勝負するほうが判定へ到達しました。小さな差を積み上げる戦略は、月間数十万セッションを持つサイトの特権です。
検証期間は週の倍数で切り、期間中に避けるイベントを先に確認する
必要セッション数を週あたりの流入で割れば必要な週数が出ます。このとき端数の日数は切り上げ、必ず7日の倍数で期間を確定させてください。曜日によってCVRは大きく変わり、BtoBなら平日へ寄る傾向があります。6日や10日で切ると、特定曜日に偏った標本になってしまいました。最低2週間を推奨する慣習が広く共有されているのも、曜日周期を2周させて偏りを平均化する意図によるものでしょう。
加えて、大型連休や決算期、自社のキャンペーン開始、大型の広告出稿といったイベントを先に確認します。これらは流入の質を丸ごと入れ替えるため、両群へ等しくかかるとはいえ分散が膨らみ、必要サンプル数が実質的に増えてしまいました。予定が読めるものは期間から外してください。
必要数の見積りが現実の流入を超えたときに採れる3つの逃げ道と代償
計算結果が現実の流入を超えたとき、期間を延ばして押し切るのは最後の手段です。半年のテストでは、その間にサイトも市場も変わり、測っている前提が崩れてしまいます。現実的な逃げ道は3つでしょう。
1つ目は判定指標を手前へ移すことです。最終コンバージョンではなく、CTAクリック率やフォーム到達率を主指標に置きます。手前の指標は発生率が高いため必要サンプル数が一桁減りました。ただし手前の指標が改善しても最終CVが増えない場合があるため、最終CVは参考値として必ず併記し、下振れしていないかを見張ってください。
2つ目は対象範囲をまとめることです。同じテンプレートを使う複数ページへ同じ変更を当て、合算で判定します。1ページ単位では届かない流入が合算で足りました。ページごとの効果差は見えなくなりますが、テンプレート改修の是非を決めるには十分でしょう。
3つ目は案の差を大きくすることです。前述の表が示すとおり、狙う差を相対20%から50%へ上げれば必要数は5分の1近くまで落ちます。文言の言い換えではなく、訴求の切り口ごと変える、フォーム項目を半分に削る、料金の見せ方を根本から変える。判定に届く設計とは、統計の工夫ではなく案の大胆さで作るものだと考えてください。
テスト終了後にz検定を実行し、効果量と信頼区間まで出して判断する
2群のCV数から比率のz検定を計算するコードと実務での出力の読み方
期間が終わったら、ツールの「勝者」表示ではなく手元で数字を作り直します。入力は各群のセッション数とコンバージョン数の4つだけです。次のコードはz統計量、両側p値、CVR差の95%信頼区間をまとめて返します。
# ABテストの判定（プール分散のz検定＋差の95%信頼区間）
from math import sqrt, erf
def ab_test(n_a, cv_a, n_b, cv_b):
p_a, p_b = cv_a / n_a, cv_b / n_b
p = (cv_a + cv_b) / (n_a + n_b)
z = (p_b - p_a) / sqrt(p * (1 - p) * (1 / n_a + 1 / n_b))
pval = 1 - erf(abs(z) / sqrt(2)) # 両側p値
se = sqrt(p_a * (1 - p_a) / n_a + p_b * (1 - p_b) / n_b)
return (round(z, 3), round(pval, 4),
round(p_b - p_a - 1.96 * se, 5),
round(p_b - p_a + 1.96 * se, 5))
print(ab_test(21100, 422, 21100, 506)) # B案が勝った例
print(ab_test(21100, 422, 21100, 470)) # 惜しいが届かなかった例
(2.788, 0.0053, 0.00118, 0.00678)
(1.624, 0.1043, -0.00047, 0.00502)
1行目はA案が21,100セッションで422件（CVR2.00%）、B案が21,100セッションで506件（CVR2.40%）の結果です。相対では約20%の改善で、p値0.0053なら有意水準5%を下回る結果です。注目すべきは3つ目と4つ目の数字で、CVR差の95%信頼区間が+0.118ポイントから+0.678ポイント、相対に直すと+5.9%から+33.9%という幅になっています。報告書に書くべきはこの区間で、下限の+5.9%でも改修コストが回収できるかを先に確認すれば、意思決定は数字で閉じます。
有意にならなかった数字の例と、そこから次に何をするかの判断軸
2行目はB案が470件（CVR2.23%、相対+11.4%）だった場合です。差の向きはプラスなのにp値は0.1043で、有意水準5%には届きません。信頼区間も−0.047ポイントから+0.502ポイントと0をまたいでおり、相対では−2.4%から+25.1%の幅になります。「B案が悪い」と読むのは誤りで、正しい読みは「この標本数では+11%程度の差を分離できなかった」です。相対10%の検出には各群80,700セッションが必要という前章の表と、そのまま整合します。
ここでの分岐は2つに絞られます。追加の流入を投じて必要数まで積む価値があるなら期間を延ばさず同じ設計で新規のテストとして回し直す、価値がないなら案の差を大きくして別のテストに賭ける。既に走ったテストの期間だけを継ぎ足す延長は、後述する途中の覗き見と同じ構造の問題を招くため避けてください。
効果量の信頼区間を投資判断の材料へ翻訳するときの読み替え手順
信頼区間をそのまま渡しても、事業側の判断材料にはなりません。翻訳の手順を決めておきます。第1に、区間の下限値を年間の流入数へ掛けて、追加で得られるコンバージョン数の下限を出す。第2に、1件あたりの粗利や受注率を掛けて金額へ直す。第3に、改修の実装工数と運用コストを引く。下限のシナリオでも黒字なら採用、下限では赤字だが中央値では黒字なら追加検証、中央値でも赤字なら見送りという3分岐で決められます。
この計算をしておくと、「有意差は出たが実装を見送る」という結論が説明可能になります。統計的な有意性と事業上の有意性は別物で、両方を並べて初めて判断が閉じるからです。
ABテストの判定を壊す3つの条件と、失敗が起きる仕組みの見分け方
途中で結果を覗いて有意になり次第打ち切ると誤検出が膨らむ仕組み
最も頻度が高い失敗が、テスト中に毎日ダッシュボードを見て、有意になった瞬間へ打ち切る運用です。固定サンプルサイズを前提とした検定は「決めた数に達した時点で1回だけ判定する」設計であり、途中で何度も判定して都合の良いタイミングで止めると、本当は差がないのに有意と出る確率が名目の5%を大きく超えてしまいます。毎日覗いて止める運用では、誤検出率が20%を超える水準まで膨らみました。
対策は単純で、開始時に決めた必要サンプル数と期間へ達するまで判定しないことです。途中の数字を見る必要があるなら、判定ではなく「実装事故が起きていないか」の確認目的に限定します。見ていいのは動作、決めていいのは期間到達後、という切り分けでしょう。なお逐次検定やベイズ推定を採るツールは前提が異なり、途中判定を許容する場合があります。使っているツールがどちらの枠組みかは開始前に確認してください。
同じ導線で複数のテストを並走させたときに効果が打ち消し合う理由
組織の中で複数チームがそれぞれテストを走らせると、同じユーザーが2つのテストの両方へ入ります。ランダム割り当てが独立なら理屈上は影響が平均化されますが、実務では2つの問題が出ました。1つは同じ導線上にある変更同士の相互作用です。LPのCTAを変えるテストとフォームを変えるテストが同時に走ると、効果が打ち消し合い、どちらも「差なし」に見えてしまいます。もう1つは分散の増加で、同じ必要サンプル数では判定へ届きません。
運用ルールとしては、同一の導線（LPからフォーム送信までのように1つのコンバージョン経路）では同時に1つのテストだけを走らせるのが安全です。導線が別（採用ページと製品ページ）なら並走に問題はありません。対象URLと期間を書いた登録台帳を1つ持ち、重複を機械的に弾くのが現実的でしょう。
割り当ての崩れと計測の穴でAB両群の条件が非対称になる3つの型
ランダム割り当てが崩れる典型は3つあります。第1に、セッション単位で割り当てるツール設定では、同じ人が訪問ごとにA案とB案を見ることになり、体験が混ざってしまいます。第2に、PCとスマートフォンで別の割り当てになるため、端末をまたぐ検討行動は分断されました。第3に、キャッシュやCDNの設定で片方の案が特定の環境に表示されない事故です。
計測側では、ボットと社内アクセスの除外が要点になります。監視ツールやクローラーのアクセスは案の内容に反応しないため、両群へ等量入れば差を薄め、偏って入れば偽の差を作りました。IPやユーザーエージェントによる除外設定は、テスト開始前に確認してください。加えて、片方の案だけ表示が遅いという非対称も要注意です。JavaScriptで同一URLのDOMを書き換える方式では、書き換え前に元の表示が一瞬見える「ちらつき」が起きます。B案側だけが遅延を負っているため、測っているのが訴求の差ではなく表示速度の差になっている可能性があります。
Optimize終了後にABテスト環境を組み直すときの選定と実装
Google Optimize終了後に取り得るツール構成と選定の3観点
無料で使えたGoogle OptimizeとOptimize 360は、公式告知の[Sunset September 2023] Google Optimizeのとおり2023年9月30日をもって提供を終え、その時点で動いていた実験とパーソナライズも終了しました。同じ告知の中でGoogleは、AB Tasty・Optimizely・VWO（アルファベット順）との連携を進めていること、APIを公開して任意のABテストツールをGoogleアナリティクスへ接続できるようにしたことを説明しています。つまり出し分けは外部ツール、集計と分析はGA4という二層構成が既定路線になりました。
付随して押さえておきたいのがFirebase A/B Testingの扱いです。同じ告知によれば、2023年10月23日以前に開始された実験は推定計算にOptimizeの基盤を使い続け、同日以降に開始された実験は頻度論の推定へ切り替わってOptimizeに依存しない構成になっています。アプリ側の実験を引き継いだ場合、開始日によって内部の推定方法が違う点は結果の比較時に効いてきます。
選定の観点は次の3つです。第1に出し分けの実装方式で、クライアントサイドのJavaScript、サーバーサイド、CDNのエッジのいずれかを選びます。第2に判定の枠組みで、固定サンプルサイズの検定か、逐次検定かベイズ推定かによって「途中で見てよいか」が変わります。第3に計測基盤との連携で、GA4の探索レポートやBigQueryエクスポートへ実験IDを渡せるかどうかが、後からセグメント別に掘る余地を決めました。
ちらつきを抑えるアンチフリッカー実装と、計測に出る副作用の見方
クライアントサイドで出し分ける方式では、元のHTMLが描画された後にJavaScriptが書き換えるため、一瞬だけA案が見えます。対策として同期スクリプトでページを一時的に隠すアンチフリッカーの仕組みが使われますが、これはA群にもB群にも表示遅延を課すという副作用を持ちます。隠している時間の上限（タイムアウト）を数百ミリ秒から数秒で設定し、超えたら元の表示へ戻す実装が一般的です。
副作用の読み方はこうなります。第1に、両群ともLCPが伸びるため、テスト期間中のCVRが平常時より低く出る場合があります。テスト内のA対Bの比較は成立しますが、テスト期間の絶対値を前後の月と比べるのは筋が悪いでしょう。第2に、タイムアウトで元表示へ戻った訪問者はB群に割り当てられながらA案を見ており、効果が薄まる方向へ働きます。タイムアウト発生率を計測に載せ、数%を超えるなら実装方式そのものを見直すのが安全です。サーバーサイドやエッジでの出し分けはこの問題を構造的に回避できる代わりに、配信基盤へ手を入れる工数が必要になります。
ABテストを見送る条件と、代わりに手を付けるべき打ち手の選び方
ABテストを見送ると判断する3つの条件と、逆に採用してよい条件
ここは言い切ります。次のいずれかに当てはまるなら、ABテストは判定に届かないため見送ってください。第1に、テスト対象ページの月間コンバージョンが各群10件を下回る規模のとき。期間を延ばしても年単位になってしまいます。BtoBの問い合わせのように月間CVが数件から十数件のページは、そもそも比率の差を検出する材料が足りません。
第2に、検証したい差が相対10%程度の小さな差でしかないとき。必要数が跳ね上がる一方、仮に検出できても実装コストを回収できるかが微妙です。CVR2.0%が2.2%になる価値と、検証に5か月かける機会損失を並べて、後者が勝つなら着手しない判断が正しくなります。第3に、流入の質が週ごとに変わる期間へ当たるとき。キャンペーン中や季節商材の繁忙期の入り口では母集団が動くため分散が大きく、同じサンプル数でも判定が不安定になってしまいました。
逆に、次の条件が揃うならABテストは費用対効果の高い投資になります。対象ページの月間セッションが1万を超え、CVRが2%以上あり、検証したい変更が構成レベルの大きな案で、テスト期間中に大きなイベントが入らない。この条件下ではCVR2.0%で相対50%改善なら各群3,800セッション、2週間強で判定へ届きます。広告費を継続的に投じているLPであれば、勝ち案がそのまま獲得単価に効くため、検証工数は短期で回収できるはずです。担当者の交代が多い体制では、検証記録そのものが資産になる点も採用理由でしょう。
ABテストを見送るときに代わりに打つ3つの手と、その使い分け方
見送りは「何もしない」ではありません。現実的な代替は3つです。1つ目は前後比較で、外部要因の影響を承知の上で、期間をずらして同じ長さで比べます。厳密な因果は言えませんが、大きな改修の方向性が誤っていないかの確認には使えました。参照元構成と広告費が同じ期間を選ぶのが最低条件でしょう。
2つ目は5人程度のユーザーテストです。実際の見込み客に近い属性の人へ操作してもらうと、どこで手が止まるかは数人でも明確に見えます。「そもそもサービス内容が伝わっていない」ような致命的な詰まりは、ABテストで数か月かけるより早く見つかりました。3つ目は、改善対象そのものの選び直しです。離脱地点の特定から改善仮説を1点へ絞る作業を先に済ませておけば、大胆な案が作りやすくなります。LP1枚を対象にした改善の手順と着手順の考え方は、LPOとは？LP改善で最初に触る要素と検証の順序・効かない場面の見極めで整理しました。本記事の検証設計と組み合わせれば、「どこを直すか」と「効いたかどうか」の両方が揃います。
そもそもテストに載せる前段として、LPの構成要素と制作の相場感を掴んでおくと案の大胆さを設計しやすくなります。構成・費用・外注の判断基準はランディングページ（LP）とは？LP制作の流れ・構成・費用と外注の判断基準を解説にまとめてあり、どこまでを内製で回し、どこから外へ出すかの線引きに使えます。
自社の流入規模でABテストが成立するのか、成立しない場合にどの代替手段を採るべきかの切り分けは、実データを見ないと判断できません。相談したい場合は、Webコンサルティング・アクセス解析で、現状の数字をもとに検証計画の立て方からお手伝いしています。
よくある質問｜ABテストの期間とツール選定とSEOへの影響について
ABテストは何日回せばよいのでしょうか？
日数から決めるのではなく、必要サンプル数を週あたりの流入で割って週数を出し、7日の倍数へ切り上げてください。慣習として最低2週間が挙げられるのは、曜日周期を2周させて偏りを均す意図によるものです。上限の目安は4週間から6週間で、それを超えるなら設計を見直す合図でしょう。Google検索セントラルも、必要以上に長く実験を走らせているサイトは検索エンジンを欺く試みと解釈され、対処の対象になり得ると明示しています。
期間が終わっても有意差が出なかったときはどうしますか？
期間を延長せず、「想定した大きさの差は無かった」という結論で閉じるのが原則です。延長は途中の覗き見と同じ構造の問題を招いてしまいます。前章のコードで信頼区間を出しておけば、「上限まで見ても改修コストに届かない」のか「上限側は魅力的だが標本が足りない」のかを区別できます。前者なら打ち切り、後者なら案の差を大きくして再挑戦という分岐でしょう。
流入が少ないサイトでもABテストはできますか？
比率の検定という枠組みでは難しいと考えてください。月間CVが各群10件を割る規模では、必要サンプル数が数万セッションになってしまいます。判定指標を手前の指標へ移す、同じテンプレートを使う複数ページを合算する、という工夫で届く場合はあるでしょう。それでも足りないなら、ユーザーテストと前後比較の組み合わせへ切り替えるほうが進みます。
ABテストのツールは何を選べばよいですか？
無料で使えたGoogle Optimizeは2023年9月30日にサポートを終えており、GA4単体には出し分けを実行する機能がありません。現在は外部の実験ツールで出し分けを行い、結果の分析をGA4側で受ける構成が一般的です。Googleは公式告知でAB Tasty・Optimizely・VWOとの連携に触れ、APIを公開して他のツールも接続できるようにしたと説明しています。選定時の観点は、ちらつき対策の実装方式、判定の枠組み（固定サンプルサイズの検定か、逐次検定・ベイズ推定か）、計測基盤との連携可否の3つでしょう。
同じ内容の2ページを出し分けるとSEOで不利になりませんか？
出し分け自体はGoogle検索セントラルのガイドで許容されています。守るべき運用は3点で、テスト用URLにはrel="canonical"で元ページを指す（Googleはこの状況ではnoindexよりcanonicalを推奨しています）、振り分けは一時的なリダイレクト（302）で行う、終了後は速やかに元の構成へ戻すことです。検索エンジンにだけ別の内容を返す実装はクローキングに該当してしまいます。なおGooglebotは一般にCookieを解さないため、Cookieで出し分けを制御している場合はCookieを受け取らない環境向けの版だけがクロールされる点も押さえておいてください。
