A/Bテスト改善基礎

A/Bテストの始め方|ノーコードで検証する手順と注意点

2026年07月15日 ・ Stride

同じページを見ているのに、直したい場所が人によって違う。会議で意見が割れて、結局いちばん声の大きい人の案が通る。

心当たりはありませんか。

A/Bテストは、その決着を訪問者につけてもらう仕組みです。今はコードを書かなくても始められます。

ただし、始め方を間違えると、数字は出ているのに間違った結論にたどり着きます。しかもその間違いは、数字という形をしているぶん、なかなか疑われません。

この記事では、どこを試すかの決め方から、必要なサンプル数の見積もり、結果の読み方、つまずきやすい落とし穴までを順番に説明します。専門用語は出てくるたびに噛み砕きます。

A/Bテストは同時に比べるから意味がある

A/Bテストとは、同じページについて案を2つ用意し、訪問者をランダムに振り分けて、どちらが成果につながったかを比べる方法です。片方が元のページ(A案、対照群と呼びます)、もう片方が変更を加えた案(B案)になります。

大事なのは、AとBを同じ期間に、同じ条件で走らせることです。ここがA/Bテストの核心で、それ以外の比べ方とはっきり違うところでもあります。

振り分けはツールが自動で行いますが、ひとつだけ条件があります。同じ訪問者には、何度来ても同じ案を見せ続けることです。

来るたびに文言が変わったら、訪問者は混乱しますし、どちらの案の効果なのかも分からなくなります。まともなツールなら、訪問者ごとの識別子から機械的に振り分け先を決めるので、この点は自動的に守られます。

似た言葉を整理しておく

A/Bテストの周辺には紛らわしい言葉がいくつかあります。最初に区別しておくと、ツールの説明も読みやすくなります。

多変量テストは、見出しとボタンと画像を同時に何通りも組み合わせて、最適な組み合わせを探す手法です。理屈としては強力ですが、組み合わせの数だけ必要なアクセスが増えるため、中小規模のサイトではまず現実的ではありません

もうひとつがスプリットURLテストで、これは別URLの2ページを丸ごと比べる方式です。デザインを全面刷新する場合には向きますが、ページを2枚維持する手間がかかります。

まず選ぶべきは、既存ページの一部だけを書き換える通常のA/Bテストです。最小の手間で、最大の学びが得られる形から入るのが定石になります。

先月と今月を比べるのでは足りない理由

ページを直したら先月より登録が増えた、だから成功。この判断は危険です。

先月と今月では、季節も、広告の出稿量も、キャンペーンの有無も違うからです。増えたのがページ改善のおかげなのか、たまたま広告を増やしたからなのかを、後から分けることはできません。

同じ期間に訪問者の流れを二分すれば、外側の条件はどちらの群にも等しくかかります。だから差が出たとき、その差を変更のせいだと言い切れるわけです。

これが前後比較には決してできないことです。

何を試すかより先に、どこを試すかを決める

初めてのA/Bテストで、いきなりボタンの色を変えたくなる気持ちはよく分かります。でも、その前にやることがあります。

訪問者がいちばん多く消えている場所を特定することです。トップページの見出しを必死に改善しても、実は決済フォームで7割が離脱していた、ということは珍しくありません。

たとえば、訪問1,000に対してサービス紹介ページが620、料金ページが310、フォーム表示が180、送信完了が42だったとします。この場合、いちばん漏れているのはフォーム表示から送信完了の区間です。

ここが23%しか通っていないなら、テストすべきはトップの見出しではなくフォームそのものです。改善の効きは、直した場所と離脱の大きさの掛け算で決まります

どこで人が消えているかを掴む手順は ファネル分析の基本|離脱ポイントの見つけ方と改善の進め方 に、ページ単位で見直す観点は LP改善チェックリスト|ファーストビューで離脱を防ぐ にまとめました。テストの対象を決める前に、この2つで当たりをつけておくと無駄打ちが減ります。

効果が出やすいのはコンバージョンに近い要素

対象の区間が決まったら、次は変更の中身です。経験的に、成果に近い場所ほど数字は動きやすい傾向があります。

  • 申し込みボタンの文言と、その周辺で不安を打ち消す一文
  • フォームの入力項目の数、とくに必須項目の数
  • ファーストビューの見出し、つまり誰の何を解決するかの一行
  • 価格の見せ方(月額表記にするか、年額割引を前に出すか)

逆に、ページ下部の装飾やフッターのリンク色は、動いたとしても差が小さすぎて検出できません。テストには時間がかかるので、最初の数回は大きく動きそうな場所に使うのが得策です。

なお、フォームの項目数のように、テストするまでもなく削れると分かっている部分もあります。入力段階の詰まりを減らす具体策は フォーム最適化(EFO)|入力離脱を減らす7つの工夫 を参照してください。

テストに向かない変更もある

なんでもテストにかければいいわけではありません。向かない対象を先に外しておくと、限られた回数を無駄にせずに済みます。

まず、月に数件しか起きない申し込みを直接の指標に置くのは避けます。差が出たように見えても、その差はほとんどがばらつきだからです。

見せ方の工夫とは別に、価格そのものを訪問者ごとに出し分けるテストも慎重に扱ってください。同じ商品に違う価格を提示することになり、後から知られたときの不信は、得られる知見に見合いません。

特定商取引法にもとづく表記や利用規約のような、正確さが最優先される文言も対象外です。読みやすくする必要はありますが、それはテストではなくそのまま直せばいい部分になります。

進め方は4ステップ

やることは多くありません。仮説を書き、案を作り、判定基準を決め、走らせる。

この順番を守るだけで、テストの精度は大きく変わります。

1. 仮説を一文で書く

仮説とは、何をどう変えると、なぜ、どの数字が動くのかを言葉にしたものです。ここが曖昧だと、結果が出ても解釈できません。

弱い仮説と、検証できる仮説の違いを見てみましょう。

弱い仮説 検証できる仮説
書き方 ボタンを目立たせる 無料で試せることが伝わっていないので、ボタン文言を変えれば登録が増える
変更点 曖昧 文言1箇所のみ
判定 目立ったかどうか測れない 登録完了に到達したセッション数

右の書き方なら、負けたときにも学びが残ります。無料という訴求は刺さらなかった、という次の仮説につながるからです。

2. 変更は一箇所だけにする

見出しもボタンも画像も一度に変えたくなりますが、それをやると勝っても何が効いたのか分かりません。次に活かせない勝ちは、運と大差ないのです。

実際の変更は、たとえばこのくらい小さくて構いません。

<!-- A案(元のまま) -->
<a class="cta" href="/signup">お申し込みはこちら</a>

<!-- B案(文言だけ変更) -->
<a class="cta" href="/signup">無料で試す(登録1分)</a>

変えるのは一箇所、比べるのは一指標。この原則を、最初の数本は必ず守ってください。

3. 判定基準を先に決めて、書き残す

テストを始める前に、何をもって勝ちとするかを決めます。始めてから決めると、都合の良い数字を後から選んでしまうからです。

紙でもメモアプリでも構いません。こんな形で残しておきます。

テスト名 : LPのCTA文言
仮説     : 無料と分かればハードルが下がり、登録が増える
対象     : /lp/ のみ(他ページは対象外)
指標     : 登録完了に到達したセッション数
必要数   : 片群 14,000セッション(CVR 3.0% → 3.6% を検出する場合)
期間     : 最低2週間、曜日が一巡するまで
禁止事項 : 期間中は広告予算と価格を変えない

最後の一行を軽視しないでください。テスト中に広告を増やすと訪問者の顔ぶれが変わり、両群ともぶれます。

4. 公開前に実機で確認し、走らせたら触らない

ノーコードのツールなら、サイトを開いたままビジュアルに文言を書き換えてB案を作れます。Strideもこの方式で、HTMLを触らずにテストを作成できます。

ただし公開前に、自分のスマホとPCの両方でB案を一度は表示してください。確認するのは、崩れていないか、表示が遅れてちらつかないか、リンク先が正しいかの3点です。

対象ページの指定も忘れずに確認します。サイト全体に適用してしまうと、関係のないページの訪問者まで母数に入り、差が薄まってしまうからです。

あとは十分な数がたまるまで待つだけです。途中で文言を微調整したくなっても我慢してください。

必要なサンプル数は、始める前に見積もる

A/Bテストでいちばん多い失敗は、数が足りないうちに勝敗を決めてしまうことです。ここだけは感覚に頼らず、事前に計算してください。

なぜ数が必要なのか、コインで考えると腑に落ちます。同じ確率で表が出るコインを10回ずつ投げても、6対4や7対3になるのは普通です。

同じことがコンバージョンにも起きます。100セッションで3件と5件なら、率は3%と5%で1.7倍の差に見えますが、これはただのばらつきの範囲です。

必要な数は、元のコンバージョン率と、検出したい改善幅で決まります。改善幅が小さいほど、必要な数は急激に増えます。

元のCVRが3.0%、1日あたり500セッションのサイトを例に見てみましょう。

検出したい改善 片群に必要なセッション かかる日数の目安
+10%(3.0% → 3.3%) 約54,000 約216日
+20%(3.0% → 3.6%) 約14,000 約56日
+50%(3.0% → 4.5%) 約2,600 約11日

驚いたかもしれません。ボタンの色を変えて数パーセント改善する程度のテストは、実は多くのサイトでは検出不可能なのです。

だからこそ、小さいサイトほど大胆に変える必要があります。見出しを丸ごと書き換える、フォームの項目を半分にする。

そのくらいの変更なら、現実的な期間で決着がつきます。

案を3つ4つと並べたくなることもありますが、必要な数は案の数だけ増えていきます。最初のうちは、AとBの2案に絞るほうが現実的です。

アクセスが少ないサイトの現実的な進め方

月に数百セッションのサイトで、最終コンバージョンのA/Bテストを回すのは無理があります。表のとおり、決着まで何ヶ月もかかるからです。

その場合は、判定に使う指標を手前にずらします。申し込み完了ではなく、料金ページの閲覧やフォームの入力開始を指標にすれば、発生件数が数倍から十数倍になり、現実的な期間で差が見えます。

この考え方は マイクロコンバージョンの設計|小さな一歩を計測する で詳しく扱っています。

もうひとつ有効なのが、量ではなく質で原因を探る方法です。実際の操作を再現するセッションリプレイで、どこで手が止まっているかを数人分見るだけでも、仮説の精度は上がります。

Strideのリプレイは記録の時点で全テキストを伏せ字にし、入力値も画像も保存しない完全マスク方式です。個人情報を集めずに、動きだけを確認できます。

テストが回せない規模なら、まず観察する。仮説の質が上がってから少ない回数で当てにいくほうが、結果的に速いのです。

結果の読み方と、途中で覗くことの危険

数がたまったら判定です。ここにも落とし穴があります。

毎日覗いて、良い日にやめてはいけない

テスト中の数字は日々揺れます。B案が勝っている日もあれば、負けている日もある。

問題は、勝っている日を見つけた瞬間に終了してしまうことです。これはピーキングと呼ばれ、まったく差のない2案でも、何度も覗いて都合の良い時点で止めれば、かなりの確率で勝ったように見えてしまいます。

対策は単純で、事前に決めた期間とサンプル数に達するまで結論を出さないことです。途中経過を眺めるのは構いません。

ただし、それで止めない。

ツール側で歯止めがかかる場合もあります。Strideは開始時点のCVRをもとに必要サンプル数を計算して固定し、その数に届くまでは勝者を確定しません。

確信度と、割り当ての偏りを確認する

判定では、B案が勝っている確率がどのくらいかを見ます。たとえば勝率92%と表示されたら、100回同じテストをしたら92回はB案が上、8回は実は差がないか逆、というくらいの意味です。

目安は95%程度ですが、社内の意思決定に使うだけなら90%でも実務上は十分なことが多いです。求める確信度を上げるほど、必要なサンプル数も増えるというトレードオフがあることは覚えておいてください。

もうひとつ確認したいのが、AとBに振り分けられた人数の比率です。50対50で振っているはずなのに52対48のように偏っていたら、タグの設置や計測に問題がある可能性があります。

これはSRM(サンプル比率の不一致)と呼ばれ、放置すると結果そのものが信用できません。Strideでは、ベイズ推定による勝率の表示に加えて、この偏りのチェックも自動で行われます。

合計では見えない差がある

全体の勝率だけを見ていると、逆向きの結果が打ち消し合っていることに気づけません。よくあるのが、スマホでは勝っているのにPCでは負けているケースです。

Strideの結果画面はデバイスや国、ページで絞り込めるので、判定の前に一度は分けて眺めてください。片側だけで明確に効いているなら、その条件に限って適用するという選択もあります。

ただし、分け方を増やすほど各グループの母数は小さくなります。後から何通りもの切り口で探し回れば、偶然の勝ちはいくらでも見つかるので、分けて見る軸は事前に1つか2つ決めておくのが安全です。

差が出なかったときこそ収穫がある

多くのテストは引き分けで終わります。がっかりする必要はありません。

引き分けは、その要素は訪問者の意思決定に関係していなかったという発見だからです。ボタンの文言で動かないなら、迷いの原因は価格や信頼性など別の場所にある。

次はそちらを疑えばいい、という情報が手に入ったことになります。

よくあるつまずきと、その回避

現場で繰り返し見かける失敗をまとめます。どれも事前に知っていれば避けられるものばかりです。

  1. 期間が半端で曜日が揃っていない(平日と週末で行動が違うので、1週間の倍数で回す)
  2. B案の表示が一瞬遅れて、元の文言がちらついて見える
  3. スマホとPCで結果が逆になっているのに、合計だけを見て判断している
  4. テスト対象外のページにも変更が及んでいて、比較が成立していない
  5. 勝った案を本番に反映し忘れ、テストだけ止めてしまう

2番目のちらつきは軽視されがちですが、体験を損ねるだけでなく、変更前の文言を見てしまった人が混ざるので結果もぼやけます。

3番目は前の章で触れたとおりです。合計が引き分けに見えるときほど分けて確認する価値があり、放置すると効いている条件ごと捨ててしまいます。

5番目は笑い話のようですが、本当に起きます。テスト終了時に、勝った案を恒久的に反映する作業までを一連の手順に含めておきましょう。

まとめ

A/Bテストは、コードなしで小さく始められます。難しいのは技術ではなく、判断の作法のほうです。

離脱の大きい場所を選び、変更は一箇所に絞り、必要なサンプル数を先に見積もり、決めた期間まで待つ。この4つを守るだけで、結果の信頼性はまったく変わります。

そして引き分けを恐れないこと。一本のテストで大勝ちを狙うより、学びを積み上げるほうが最終的に強いのです。

まずは、いちばん人が消えている場所をひとつ見つけるところから始めてみてください。

Strideで、あなたのサイトの導線を可視化しませんか?

Cookieレスで、離脱ポイントとコンバージョンが数分でわかります。

無料で始める