上級

A/B検証の設計:小さな変更を比較できる形にする

仮説、比較対象、主要指標、期間、終了条件を決め、結果を過大評価しない改善テストを設計します。

この記事でわかること

  • 同時比較と変更前後の比較を区別する
  • 開始前に見る指標と終了条件を決める
  • 差が不明な結果もそのまま記録する

何が分かれば次の判断ができるかを定義する

A/B検証は、二つの案を用意して数字の大きい方をすぐ採用する作業ではありません。「比較表の後の案内が曖昧なので、確認する内容を具体化すると読者が迷いにくくなる」という仮説を先に書きます。対象ページ、対象読者、変更する要素、見る指標を固定し、何を比較したいのかが説明できる状態で始めます。

例えばA案は「詳細を見る」、B案は「公式サイトで対応プランを確認する」です。これは検証用の仮例で、B案が必ず優れるという意味ではありません。移動先で実際に確認できる内容だけを書き、どちらの案でも広告との関係や商品条件を同じように伝えます。誤解を増やす案を比較のために公開しないようにします。

同時に分ける比較と、時期を変える比較を区別する

同時に対象者を二案へ分ける設計では、原則としてランダムに割り当て、同じ利用者が短時間で両案を行き来しないように扱います。Aをスマートフォン、Bをパソコンへ分けると端末差が混ざり、案の差を判断しにくくなります。一方、今月と来月で案を入れ替える方法は、季節や流入元の変化も含む前後比較です。差を変更の効果だけと説明しないでください。

実施メモの例は「一記事の案内文のみ変更/主要指標は対象閲覧者のうち案内を使った割合/流入元と端末も確認」です。表示機会のない読者を分母へ入れるかなど、指標の定義も先に決めます。見出し、色、位置、リンク先を同時に変える場合は、まとまり全体の比較であり個別要素の効果は分からないと記録します。

途中の数字で都合よく検証を止めない

開始前に観察期間、必要なデータ量の見積り、問題が起きた時の中止条件を決めます。必要量は元の率や検出したい差、割り当て方法などで変わり、「何件あれば必ず十分」という固定値はありません。計測が壊れた、申込みが進めないなどの不具合は、結果の良し悪しと無関係に止めて修正します。

計算用の仮例でA案は200人中10人、B案は200人中14人が案内を利用したなら、率は5%と7%です。この差だけで効果が証明されたとは言えません。差が偶然の範囲かを考慮する必要があり、十分に判断できなければ「不明」とします。途中で指標を何度も変え、良く見える数字だけを結果にしないでください。

検索と通常利用を保ち、検証後に片付ける

Googleの公式資料は、検索エンジンだけに異なる内容を見せることを避け、複数URLでの検証では正規URLなどを適切に扱うよう案内しています。URLを切り替える仕組みを導入する場合は、検索の設定への影響も確認します。検証のために記事が読めなくなったり、別の案内へ意図せず飛んだりしないか、公開前に操作してください。

終了時は採用案、差があった範囲、判断できなかったこと、実施期間を記録します。不要な検証用URLやスクリプトを残さず、採用した状態でリンクと計測を再確認します。アクセスが少なく比較が難しいサイトでは、まず読者の質問や実際の操作から明らかな説明不足を直し、検証する価値がある仮説へ絞っていきましょう。

  • 仮説・対象・変更要素・主要指標を定義した
  • 同時比較と前後比較を区別した
  • 観察期間と中止条件を開始前に決めた
  • 小さな件数差だけで勝敗を断定していない
  • 検証後の設定と不要な要素を整理した

参考にした公式情報

確認日:2026-09-11。提供条件や仕様は変更される場合があります。

広告・アフィリエイトリンクを含む場合があります。編集・掲載方針

KEEP LEARNING

次に読む

学習ガイドへ