Conclusion
この記事の結論
仮説、主指標、割り付け単位、必要データ量、終了条件を事前に固定します。同時期のランダム比較で計測品質と推定の不確実性を確認し、途中の差や有意になった瞬間だけで採用を決めません。
2026年10月6日訂正:テンプレート・URL例のコードブロック表示と改行を修正しました。本文の項目名・URL値は変更していません。
- 01仮説・主指標・対象者を決める
- 02割り付けと必要データ量・終了条件を設計する
- 03計測品質と不確実性を確認して採否を決める
確認結果で判断期待どおり → 結果を記録して完了期待と異なる → 止まった手順と結果を整理し、担当者へ確認
A/Bテストは、公開前の評価設計から始める
「B案の数字が少し高いので採用する」という判断だけでは、偶然の差や計測ミスを見落とします。A/Bテストでは、対象者を同じ期間にランダムに割り付け、変更が主指標に与える影響を評価します。始める前に、仮説・対象者・指標・必要データ量・終了条件を1枚にまとめておきましょう。
この記事は、サービスページや問い合わせ導線を改善するWeb担当者向けです。GA4等の計測が導入途中なら、まず受付成功の記録と重複防止を検証します。ランダム配信や割り付けの保持も別途必要であり、アクセス解析タグを置くだけではA/Bテストの実施環境にはなりません。
1. 「誰の、どの迷いを減らすか」を仮説にする
仮説は「変更内容 → 利用者の行動 → 事業上の目的」の順で書きます。次は架空のBtoBサービスサイトの例です。
仮説の例: 無料相談の所要時間が分からず申し込みをためらう訪問者に対して、CTAの近くに「30分程度・オンライン」と表示すれば、相談内容を理解したうえでの受付成功率が上がる。
- A案:現在の説明とボタン
- B案:同じ位置に、事実として提供できる所要時間・実施方法の説明を追加
- 固定するもの:料金、フォーム項目、広告の配信条件、他の主要なページ内容
- 対象:事前に定めたサービスページを訪問する、計測・テストの対象となる利用者
複数箇所をまとめて変えるテストもできますが、その場合に分かるのは変更の組み合わせの効果です。どの一文が効いたかまで断定できません。まずは説明したい仮説に対応する変更へ絞ります。Microsoftの実験前設計ガイド
2. 主指標・補助指標・悪化を監視する指標を分ける
採用判断に使う主指標
主指標を事前に一つ決め、分母・分子・観測期間を固定します。例えば「各案へ割り付けられた対象利用者のうち、初回割り付けから7日以内に問い合わせの受付が成功した利用者の割合」です。この7日は説明用の設定例で、実際には検討期間と取得可能なデータに合わせます。
- 分母:事前条件に合い、AまたはBへ割り付けられた利用者数
- 分子:定めた期間内に受付成功が確認できた利用者数。1人が複数回送っても主指標では1人と数える
- 成功条件:サーバー等で受付が確認できること。CTAクリックや送信ボタンの押下だけでは成功としない
- 除外条件:社内テスト等を開始前に定義し、両群に同じルールを適用する
閲覧回数やセッション数を、無作為に割り付けた利用者数の代わりに使うと、同じ人を何度も数える可能性があります。集計単位を割り付け単位に合わせることが基本です。
原因を理解するための補助指標
CTAクリック率、フォーム到達率、入力開始率などを見ます。主指標が改善しなかったときに、どこで行動が変わったかを考える材料です。結果を見てから都合のよい補助指標へ主指標を入れ替えないようにします。
悪化を監視する指標
フォームエラー、表示速度、誤解に基づく相談や対象外の相談が増えていないかを確認します。例えば「受付成功率は上がったが、対象外の問い合わせが増えた」という結果もあり得ます。営業側の分類基準と、確認可能な範囲を先に決めておきます。個人情報や相談内容をアクセス解析へ送る必要はありません。Microsoftの実験中の指標設計ガイド
3. 同じ期間・同じ母集団からランダムに割り付ける
先月をA、今月をBとする比較は、季節性や広告配信の変化も含みます。A/Bテストでは、同時期の対象者をランダムにA・Bへ割り付け、例えば50:50で比較します。同じ人が訪れるたびに案を変えず、定めた単位で割り付けを保持します。
BtoBでは、同じ会社の複数人が情報を共有する場合があります。個人単位の独立性が成り立たないと考えられる場合は、会社単位の割り付けや分析を検討します。その場合、必要なのは単純なアクセス数ではなく、会社数や会社内の相関を踏まえた設計です。Cookieの削除や端末の変更でも同じ人を識別できない場合があるため、使う仕組みの限界を記録します。
割り付けの保持に使うCookie等と、GA4への送信は分けて確認します。GA4の同意設定だけで、実験ツールの識別子の保存まで制御されるとは限りません。必要な同意管理、拒否・撤回時の識別子と計測の扱いを開始前に決め、観測できない範囲を記録します。観測対象となった利用者の結果を、すべての訪問者へ無条件に一般化しないようにします。Googleの同意管理に関するガイド
本番開始前に、両案の表示・リンク・フォーム・受付成功の記録を確認します。AとBを同じ内容にするA/Aテストは、配信や計測の偏りを調べる方法の一つです。Microsoftのランダム化単位に関する解説
4. 必要人数と終了条件を、結果を見る前に決める
「100件集まったら十分」「1週間で終了」といった共通の基準はありません。主指標の現状値、検出したい最小差、ばらつき、検定方法、許容する誤判定の水準によって必要なデータ量が変わります。
必要データ量を見積もるための入力例
- 現状の受付成功率:4%と仮定
- 意思決定上検出したい差:絶対差で1ポイント。4%から5%への変化は、相対差では25%
- 割り付け比率:A・Bを50:50
- 有意水準:両側5%、検出力:80%を検討する例
- 分析方法:利用する実験ツールで定めた比率の比較方法
- 観測単位:利用者。会社単位なら別の見積もりが必要
これらは計画の説明用の値で、推奨人数や成功を保証する設定ではありません。計算ツールや分析担当者と必要人数を見積もり、日々の対象利用者数で実行可能か確認します。現状値が分からない場合は、計測を整えて基準となるデータを集めるところから始めます。Microsoftの検出力・指標感度の解説
終了条件の書き方
開始前に「必要人数」「最低限含める営業日・休日等の周期」「募集終了の最長日」「最後の利用者の成果を待つ期間」を決めます。必要人数に届かないまま最長日を迎えた場合は、原則として判断保留とし、好ましい差が出るまで延長しません。
通常の固定期間の検定で、毎日結果をのぞいて有意になった瞬間に止めると、誤判定が増える原因になります。早期判定を行いたい場合は、そのための逐次検定等を開始前に設計し、ツールのルールに従います。一方、送信不能や大きな表示不具合など安全上の停止は別です。停止理由を記録し、その中断を「B案の成功」と扱わないようにします。
5. 終了後は「計測の健全性 → 効果 → 採用」の順で判断する
- 配分と欠損を確認する。 予定した配分から不自然に外れていないか、片方だけイベントが抜けていないかを確認します。標本比率の不整合(SRM)が疑われる場合は原因調査を優先します。配分が完全に同数でないことだけを異常とはしません。
- 決めた主指標を集計する。 A・Bの対象人数、受付成功人数、率、絶対差・相対差、信頼区間等を、事前に定めた分析方法で報告します。
- 事業上の意味と副作用を確認する。 統計的な差があっても、運用コストや相談の質を含めて採用に値するか判断します。
- 採用・不採用・判断保留を残す。 差が確認できない結果は、効果がゼロの証明ではありません。想定した差を検出できる設計だったか、推定の幅も見ます。
SRMがある結果は、人数をそろえるために後から都合のよいデータを削って修正しないでください。MicrosoftのSRM解説
数字の読み方の例
架空の結果として、Aが2,000人中80人、Bが2,000人中100人の受付成功だった場合、率は4%と5%、絶対差は1ポイント、相対差は25%です。しかし、この集計だけで「Bは必ず25%改善する」とは言えません。割り付け・計測の品質、事前の終了条件、推定の不確実性を確認する必要があります。実際のXEROTTAの実績ではありません。
テスト後に特定の端末や流入元だけで良い差を見つけた場合も、探索的な発見として記録します。多数の切り口から選んだ結果を、そのまま確定した結論として発表しないようにします。Microsoftの実験後評価ガイド
そのまま使える評価計画テンプレート
テスト名・責任者:
対象ページ・対象利用者・除外条件:
課題と仮説:
A案/B案の違い・固定する条件:
割り付け単位・配分・保持方法:
主指標(分子/分母/観測期間):
補助指標・悪化を監視する指標:
現状値・検出したい最小差:
分析方法・有意水準・検出力・必要人数:
開始日・最低観測周期・募集終了の最長日:
成果を待つ期間・早期停止の条件:
配分異常・欠損・不具合の確認方法:
採用/不採用/判断保留の基準:
結果・不確実性・残った課題・次の判断:開始前チェックリスト
- 主指標と分母・分子を説明できる
- A・Bの表示、受付成功、重複防止を確認した
- 無作為割り付けと同じ案の継続表示を確認した
- 必要データ量と終了条件を事前に記録した
- 不具合停止と、結果を見て勝敗を決める停止を区別した
- 個人情報の取得範囲と取り扱いを確認した
アクセスが少ないときの進め方
必要なデータが現実的な期間で集まらない場合は、細かな文言のA/Bテストを増やすより、フォームの動作確認、利用者へのヒアリング、説明不足やスマートフォン表示の見直しを先に進めます。変更前後の数値は参考になりますが、同時期のランダム比較と同じ強さで因果関係を主張しないようにします。
テストを始める前に、計測と改善の優先順位を整理する
XEROTTAのアクセス解析・CV改善では、成果指標、計測項目、導線・フォームの改善候補を整理します。A/Bテストを行えるデータ量があるか、先に直すべき操作上の問題があるかを確認したい方は、Webマーケティング診断をご覧ください。テスト方法・実施範囲は、サイトの状況に応じて確認します。
公式資料・確認日
- Microsoft:実験前の設計
- Microsoft:実験中の指標・早期判定
- Microsoft:会社等の単位で割り付ける際の課題
- Microsoft:検出力と指標感度
- Microsoft:標本比率の不整合(SRM)
- Microsoft:実験後の評価
資料・リンクの確認日:2026年10月4日。本文の設定・数値は説明用の仮定であり、実測結果ではありません。
関連サービス
関連する支援例・参考費用
支援内容
サービスの強みと問い合わせ導線を整理する
参考想定:相談課題と支援サービスの関係を3ページに再構成し、事例/問い合わせへの共通CTA1種を実装
支援内容と進め方を見る →参考価格(税別・役務のみ)
初期役務費 450,000円
月次役務は別途 50,000円/月(税別)
機器・ライセンス・クラウド利用料等は別途。実績価格・確定見積ではありません。
支援内容
検索意図に合わせてサービス情報を整える
参考想定:検索テーマ3件に沿って5ページの見出し・説明・内部リンクを改修しSearch Consoleの観測表を作成
支援内容と進め方を見る →参考価格(税別・役務のみ)
初期役務費 400,000円
月次役務は別途 50,000円/月(税別)
機器・ライセンス・クラウド利用料等は別途。実績価格・確定見積ではありません。
