ABテストのやり方｜仮説から判定までの手順

この記事の結論

ABテストのやり方は、仮説と判定指標を先に決め、変える要素を1つに絞ることが結果を解釈できるようにする条件です。

広告のクリエイティブやフォームの項目、LPの見出しなど、施策を変えるたびに「なんとなく良さそう」で決めていないでしょうか。担当者の勘や声の大きさで意思決定すると、変更が本当に成果を改善したのかが後から分からなくなります。次の施策を検討するときも、根拠のない変更は再び「なんとなく」の議論に戻ってしまいます。

ABテストは、この「なんとなく」を「どちらが効果的か」という検証可能な問いに変える手法です。既存の案（A案）と、仮説に基づいて変更した案（B案）を同じ条件・同じ期間で比較し、あらかじめ決めた指標の差で判定します。特別なツールがなくても、広告の配信設定や資料ページの差し替えだけで始められる施策も多く、着手のハードルは思われているほど高くありません。

本記事では、仮説の立て方から変数の分離、サンプルサイズと実施期間の決め方、結果の判定までを、手順に沿って解説します。マーケ専任でなくても実施できるよう、統計の専門知識を前提にせず進めます。

ABテストで何を解決するか

ABテストが答えるのは「A案とB案、どちらが成果指標を改善するか」という単純な問いです。感覚での意思決定と違い、実施前に決めた基準で判定するため、結果に対する納得感が生まれ、次の施策にも根拠を持って進められます。

対象は、広告のバナーやコピー、LPの見出しやCTAボタン、フォームの項目数、メールの件名など多岐にわたります。共通するのは「2つ以上の案を用意し、同じ条件で比較する」という考え方です。本記事では、この考え方を実務の手順として落とし込みます。

なお、ABテストは1回実施して終わりではなく、仮説→検証→判定→次の仮説というサイクルとして運用してこそ効果を発揮します。単発の施策としてではなく、継続的な改善の仕組みとして捉えることが、遠回りに見えて最も成果につながります。

同じ「ABテスト」でも、対象によって用意しやすさは大きく異なります。LPやフォームの改修にはエンジニアの工数が必要になりがちですが、資料ダウンロードページのように差し替えだけで済む対象は、着手のハードルが低く始めやすい検証です。まずは自社で「差し替えだけで用意できる対象」から始め、ABテストの進め方に慣れてから、実装が必要な対象に広げていくと無理なく定着します。

事前準備：仮説と指標を決める

何を検証したいのか仮説を立てる

ABテストは「変更すれば良くなるはず」という思いつきで始めると、結果が出ても次に活かせません。まず「〜を変えると〜が改善する」という形で仮説を立てます。例えば「CTAボタンの文言を『資料をダウンロード』から『無料で資料を見る』に変えると、クリック率が上がる」といった具合です。

仮説の質は、事前の観察量に比例します。「なんとなく良くなさそう」ではなく、「フォームの離脱率が高い」「特定の広告のクリック率だけ低い」といった具体的な課題から仮説を立てると、検証後の振り返りもしやすくなります。仮説を立てる際の観察方法や優先順位のつけ方は、仮説検証の方法｜立てる〜検証の手順を解説 で詳しく扱っています。本記事では、仮説がすでにある前提で、検証（ABテスト）の実施手順に絞って解説します。

成果指標（KPI）を1つに絞る

仮説を立てたら、何をもって「改善した」と判断するかを1つの指標に絞ります。クリック率、資料のダウンロード率、フォームの入力完了率などが代表例です。指標を複数追うと、片方は上がり片方は下がるといった結果になったときに判断できなくなります。あらかじめ「この指標で判定する」と決めておくことが、後の判定を迷わないものにします。

指標を選ぶときは、施策の目的に近い指標を選ぶことも大切です。例えばLPのCTAボタンを検証するなら「クリック率」が適切ですが、最終的な受注につながっているかまで確認したい場合は、クリック率だけでなく後続のCVRも合わせて記録しておくと、次の施策判断に役立ちます。ただし判定基準として使う指標は、あくまで1つに絞ります。

指標と合わせて、判定の基準（どのくらいの差が出れば採用するか）もこの段階で言語化しておきます。実施後に基準を決めると、出てきた数字に判断が引っ張られやすくなるためです。「B案のクリック率がA案を明確に上回っていれば採用する」といった簡潔な基準でも、実施前に決めておく意味は大きいです。

ABテストの手順

Step1 比較する変数を1つに分離する

ABテストの基本原則は「比較する要素は1つのみ」にすることです。ボタンの色と文言を同時に変えてしまうと、結果が改善しても、色と文言のどちらが効いたのか分かりません。見出し・画像・CTA文言など、変えたい要素が複数ある場合は、優先度の高いものから1つずつ検証します。

複数の要素を同時に変えて検証する「多変量テスト」という手法もありますが、必要なサンプル数が多くなり、分析も複雑になります。まずは単変数のABテストで検証の型を作り、慣れてから多変量テストを検討するのが現実的です。

アクセス数が限られる中小企業のマーケティングでは、多変量テストは必要なサンプル数を確保しづらいため、まずは単変数のABテストから始めることをおすすめします。

Step2 A案・B案を作成する

既存の案をA案（コントロール）とし、仮説に基づいて変更を加えたものをB案とします。A案は「今まで通り」の基準として保ち、B案との差分が仮説で立てた1変数のみになるように作成します。変更幅が小さすぎると差が出にくく、大きすぎると何が効いたのか特定しづらくなるため、仮説の根拠に沿った変更にとどめます。

A案・B案を作る段階で、判定後にどちらを本採用にするかの運用も決めておくとスムーズです。例えば「B案が勝てば全面差し替え、差がなければA案を継続」といった運用ルールを事前に決めておけば、判定後にすぐ次の動きに移れます。

また、A案とB案を並行して走らせられる状態を用意することも忘れずに確認します。片方しか出せない環境（例えば1つのページしか公開できない仕組み）では、同時比較ができず、時期をずらした比較（時系列比較）になってしまいます。時系列比較は季節要因や競合の動きなど、施策以外の要因が混ざりやすいため、可能な限り同時並行で比較できる形を用意します。

Step3 サンプルサイズと実施期間を決める

見る人の数が少ないうちに結果を判断すると、たまたまの偏りを「効果があった」と誤認しやすくなります。コインを5回投げて3回表が出ても「表が出やすいコイン」とは言えないのと同じで、少ない試行では偶然の振れ幅が結果を左右します。目安として、少なくとも数百件規模の接触（表示・クリックなど）が両案に集まるまでは判定を保留し、可能であれば1〜2週間など曜日による変動を含む期間で実施します。特定の曜日や時間帯だけで区切ると、平日と休日の行動差がノイズになるため避けます。

必要なサンプル数は、対象のアクセス数や現状の指標の値によって変わるため、一律の数字を示すことはできません。目安に迷う場合は、まず短めの期間（例えば1週間）で試験的に走らせ、両案の合計接触数が数百件を超えたところで一度中間確認をし、明確な差がまだ見えなければ期間を延長する、という進め方が現実的です。

期間を決める際は、月初・月末や決算期など、業界特有の繁忙期を避けることも意識します。特定の時期だけ行動パターンが変わる業種の場合、通常期と異なる結果が出て、通年の判断材料としては使いにくくなるためです。

またテスト期間中は、広告予算や掲載面など他の条件を変えないことも重要です。同じ期間に別の施策を重ねると、結果がABテストによるものか他の要因によるものか切り分けられなくなります。テスト対象以外の変更（サイトの他の箇所の修正、価格改定など）が発生する予定があれば、事前にスケジュールを確認し、ABテストの期間と重ならないよう調整します。

なお本記事では、厳密な統計的有意差の計算式までは扱いません。サンプルサイズが小さいまま判定すると誤った結論を導きやすいという定性的な注意にとどめ、精緻な検定が必要な場面（意思決定の影響が大きい施策など）は、統計や分析ツールに詳しい担当者と連携することをおすすめします。

Step4 テストを実施し、判定する

準備が整ったら、A案・B案を同じ期間・同じ条件で並行して走らせます。A案とB案を交互に出し分ける、あるいは訪問者を案ごとに振り分けるなど、実施方法は対象によって変わりますが、共通するのは「同じ期間に両案を走らせる」ことです。前後の期間で比較する（先にA案、翌週にB案）と、時期による他の要因が混ざるため避けます。

実施中は条件を変えず、あらかじめ決めた基準（指標の差・期間・サンプルサイズ）を満たした時点で判定します。「差が出なかった」という結果も、その仮説が支持されなかったという有効な検証結果です。有意な差の有無を厳密な統計計算で判断したい場合は、社内のデータ担当や分析ツールと連携するとよいでしょう。判定後は、勝った案を新しい基準（A案）として採用し、次の仮説の検証に進みます。

例えば「CTAボタンの文言を変えるとクリック率が上がる」という仮説であれば、A案・B案それぞれに一定数のアクセスを集め、2週間走らせた時点でクリック率を比較します。B案のクリック率が明確に高く、かつ十分なアクセス数が集まっていれば、B案を新しい基準として採用します。差がほとんど見えない、あるいはアクセス数が少なく判断がつかない場合は、期間を延長するか、その仮説自体を見直します。

つまずきやすいポイント

手順を知っていても、実際に運用すると次のようなつまずきがよく起こります。あらかじめ知っておくことで、着手後に判断を誤るリスクを減らせます。

• 早期に結果を確定させてしまう：数日で片方の数値が良く見えても、サンプルが少ないうちは偶然の偏りである可能性が高いです。特にB案が良い数値を出した直後は「もう十分」と感じやすいですが、決めた基準に達するまで判定を待ちます。
• 複数箇所を同時に変える：見出しとボタンを同時に変更すると、どちらが効いたか分からなくなります。1回のテストで1変数に絞り、複数の仮説がある場合は順番にテストします。
• サンプルサイズ不足のまま判断する：アクセス数が少ないページでは、統計的な差を得るまでに時間がかかります。母数が小さい施策は、期間を長めに取るか、より上流のアクセスが多い施策から検証します。
• 指標を後から変える：「クリック率で判定するはずが、途中でダウンロード数を見始めた」といった変更は、都合の良い結果を選び取ることにつながります。開始前に決めた指標で判定します。
• テスト対象を作り込みすぎる：完璧なB案を目指して着手が遅れるより、仮説の核となる1変数だけを変えた案を早く出す方が、検証のサイクルを多く回せます。
• テスト終了後の振り返りをしない：勝敗を記録するだけで満足し、なぜその案が支持されたかを言語化しないと、次の仮説に活かせません。判定後は「なぜその結果になったと考えられるか」を1〜2行でも書き残しておきます。

いずれの失敗も、事前に「何を・どれくらいの期間・どんな基準で」検証するかを言語化しておけば防げます。実施前にこの3点をメモしておく習慣をつけましょう。

訴求メッセージをABテストする：資料2種を使う方法

ABテストというとLPやサイトの実装が必要と思われがちですが、訴求メッセージの検証はページの実装なしでも行えます。広告の遷移先を、訴求の異なる資料ページ2種に分けてダウンロード率を比較する方法です。

例えば「機能の網羅性」を訴求したホワイトペーパーと、「導入の手軽さ」を訴求した同じ内容のホワイトペーパーを2種類用意し、広告のクリエイティブごとに遷移先を分けます。それぞれのページのダウンロード率を比較すれば、どちらの訴求メッセージが読者に響くかが分かります。手順としては、次のように進めます。

1. 同じ資料の内容から、訴求角度が異なる2種類の紹介文・タイトルを用意する（例：「機能の網羅性」訴求と「導入の手軽さ」訴求）
2. 資料ごとに独立した共有ページを発行する
3. 広告のクリエイティブや配信セグメントを分け、それぞれの遷移先を専用ページに設定する
4. 一定期間・同条件で並行配信し、ページごとのPVとダウンロード率を比較する
5. ダウンロード率が高かった訴求を本採用にし、負けた案のページを非公開にする

この方法は、LPやサイトの実装を伴わないため、エンジニアの工数を待たずにマーケ担当だけで着手できるのが利点です。DocLead では、PDFをアップロードするだけでリード獲得フォーム付きの共有ページを即発行できるため、訴求メッセージ違いの資料ページを短時間で2種類用意できます。テスト終了後は公開・非公開をワンクリックで切り替えられるので、負けた案のページをすぐに止められます。また、フォーム経由のダウンロード記録（誰が受け取ったか）とページのPV計測（集計値）を組み合わせれば、各ページの閲覧数とダウンロード率を比較でき、判定の材料になります。

この方法が有効なのは、資料のダウンロードページが「広告の受け皿」として機能しているケースです。広告のクリエイティブ（画像・コピー）は変えず、遷移先の訴求メッセージだけを変えることで、Step1で説明した「比較する変数を1つに分離する」原則を保ったまま検証できます。逆に、広告クリエイティブと資料の訴求を同時に変えてしまうと、どちらが効いたか分からなくなる点は通常のABテストと同じです。

判定の基準も、通常のABテストと同様にあらかじめ決めておきます。例えば「PVが200件を超えた時点でダウンロード率を比較し、明確に高い方を本採用にする」といったルールです。ダウンロード率の差が小さい場合は、判定を急がず期間を延長するか、訴求の違いをより明確にしたB案を作り直して再検証します。

資料の切り口で訴求を検証したい場合は、フォーム自体の設計も合わせて見直すと精度が上がります。フォームの離脱率を改善する手順｜資料DL編 や リード獲得フォームの最適化とは｜考え方と改善サイクル もあわせて参考にしてください。

次のテストにつなげる効率化のヒント

1回のABテストで終わらせず、結果を記録に残して次の仮説につなげることが、ABテストを継続的な改善サイクルにする鍵です。「どんな仮説を立て、何を変え、結果はどうだったか」を簡単なメモでもよいので残しておくと、似た施策を検討する際に同じ検証を繰り返さずに済みます。

記録する項目は最小限で構いません。①仮説、②変更した変数、③実施期間とサンプル数、④判定結果、⑤採用した案、の5項目をスプレッドシート等に1行で残すだけでも、後から振り返る際の手がかりになります。チームで共有すれば、他のメンバーが同じ仮説を重複して検証してしまうことも防げます。

こうした記録は、ABテストの件数が増えるほど価値を増します。「この訴求はすでに検証済みで効果がなかった」「このパターンは複数の対象で効果が出ている」といった蓄積が、次の仮説を立てる際の判断材料になり、検証のスピードそのものを上げていきます。

小さな変更から始めて検証のサイクルを回すほど、次に何を検証すべきかの精度も上がっていきます。特に資料ダウンロードページのように差し替えだけで検証できる対象は、LPの実装を待つ施策よりも先に着手しやすく、検証の型を組織に根付かせる第一歩として適しています。まずは影響範囲の大きい1箇所から、仮説→実施→判定のサイクルを始めてみましょう。