先に要点
「ボタンの色は青と緑のどちらがよいか」「見出しは短い方がよいか」「フォーム項目を減らすと問い合わせは増えるか」。
こうした迷いを、会議の好みだけで決めず、実際のユーザー行動で比べる方法がA/Bテストです。
ただし、A/Bテストは魔法の多数決ではありません。
何でも2パターン出せば正解が分かるわけではなく、目的、仮説、指標、十分なデータ量がそろって初めて判断材料になります。
この記事では、A/BテストをWebサイト、LP、フォーム、アプリ画面の改善で使う前提で、基本の考え方と失敗しやすい点を整理します。
A/Bテストとは
A/Bテストとは、A案とB案のように複数の案を用意し、ユーザーを分けて表示し、事前に決めた指標で結果を比べる方法です。
英語では A/B testing や split testing と呼ばれます。
たとえば、同じLPに来たユーザーの一部には既存の見出しを見せ、別の一部には新しい見出しを見せます。
そのうえで、登録率、問い合わせ率、購入率、クリック率などを比べ、どちらの案が目的に近い結果を出したかを確認します。
大切なのは、A案とB案を同じ条件で比べることです。
片方だけ広告キャンペーン中に出したり、片方だけ休日に出したりすると、案の違いではなく、時期や流入元の違いを見ている可能性が高くなります。
何を比べるのか
A/Bテストで比べる対象は、画面の見た目だけではありません。
| 比べる対象 | 例 |
|---|---|
| 見出し | 価値を先に出すか、課題を先に出すか |
| CTA | ボタン文言、配置、強調の仕方 |
| フォーム | 入力項目の数、エラー表示、確認画面の有無 |
| 価格表示 | 月額表示、年額表示、無料トライアルの見せ方 |
| 導線 | 記事から問い合わせへ送るか、資料請求へ送るか |
| メール | 件名、本文冒頭、リンク文言 |
実務では、いきなり画面全体を変えるより、仮説に関係する部分を絞って比べる方が結果を読みやすくなります。
たとえば「登録前の不安が強い」という仮説なら、ボタン色よりも、料金、導入事例、FAQ、入力前の説明を比べる方が意味があります。
先に決めること
A/Bテストを始める前に、少なくとも次を決めます。
- 何を改善したいのか
- なぜB案の方が良くなると思うのか
- どの指標で判断するのか
- 誰を対象にするのか
- どれくらいの期間、またはデータ量まで続けるのか
- どの条件なら採用し、どの条件なら戻すのか
この準備がないと、結果を見たあとで都合のよい数字だけを選びやすくなります。
クリック率は上がったが登録率は下がった、問い合わせは増えたが質が下がった、ということは普通に起きます。
A/Bテストは、事前に「何を成功と呼ぶか」を決めておくほど、あとから迷いにくくなります。
見る指標
A/Bテストでよく見る指標には、次のようなものがあります。
| 指標 | 見ること |
|---|---|
| クリック率 | ボタンやリンクが押された割合 |
| CVR | 登録、問い合わせ、購入など目的行動に至った割合 |
| 完了率 | フォームや申込フローを最後まで進んだ割合 |
| 売上・客単価 | 購入金額や1件あたりの価値 |
| 継続・解約 | その後も使われたか、短期で離脱していないか |
特に注意したいのは、手前の指標だけで勝ち負けを決めないことです。
ボタンのクリック率が上がっても、問い合わせ完了率が下がるなら、ユーザーを期待と違う場所へ誘導しているだけかもしれません。
CVRは、Conversion Rateの略で、目的の行動に至った割合を表します。
詳しい意味は CVR の用語ページでも整理しています。
向いている場面
A/Bテストは、次のような場面で使いやすいです。
- すでに一定のアクセスや利用がある
- 問い合わせ、登録、購入などの目的が明確
- どこを変えると良くなりそうか仮説がある
- 2つの案を同じ条件で出し分けられる
- 結果を計測できる環境がある
たとえば、広告から来るLPの見出し、資料請求フォームの入力項目、SaaSの無料登録導線、ECサイトの商品ページ、メールの件名などは候補になりやすいです。
一方で、アクセスが少なく、月に数件しかコンバージョンがないページでは、A/Bテストの結果がぶれやすくなります。
その場合は、先にユーザーインタビュー、ログ確認、ヒートマップ、フォームのエラー分析などで大きな詰まりを見つける方が早いことがあります。
向いていない場面
A/Bテストは、次のような場面では使いにくいです。
| 場面 | 理由 |
|---|---|
| そもそも誰の課題か分からない | 比べる前に顧客理解が足りない |
| アクセスやCV数が少ない | 偶然の差を結果と誤解しやすい |
| 画面全体を大きく変える | どの変更が効いたのか分かりにくい |
| 短期間で止める | 一時的な変動を勝ち負けと見やすい |
| 目的指標がない | 何をもって改善と呼ぶか決められない |
新しいサービスの価値そのものを確かめたい場合、A/Bテストよりも、課題発見、顧客ヒアリング、MVP、手作業での検証が先になることが多いです。
その整理は、新しいサービスを生み出すコツとは？課題発見・MVP・検証の進め方 で扱っています。
つまり、A/Bテストは「何を作るべきか」をゼロから決める道具というより、すでにある案をより良くするための比較方法です。
実務の進め方
実務では、次の順で進めると整理しやすくなります。
- 現状の課題を確認する
- 改善仮説を1つに絞る
- 主要指標と補助指標を決める
- A案とB案を作る
- 対象ユーザーをランダムに分ける
- 予定した期間またはデータ量まで実施する
- 結果を見て、採用、再テスト、保留を決める
- 結果と学びを記録する
最後の記録は地味ですが大事です。
「どの案が勝ったか」だけでなく、「どんな仮説だったか」「どの流入で効いたか」「副作用はなかったか」を残すと、次の改善が速くなります。
よくある失敗
A/Bテストでよくある失敗は、数字が出たこと自体に安心してしまうことです。
- 予定より早く止めて、たまたま良い瞬間を切り取る
- 同時に多くの場所を変えて、理由が分からなくなる
- クリック率だけを見て、最終成果を見ない
- 広告、季節性、キャンペーンの影響を無視する
- 既存ユーザーと新規ユーザーを混ぜて判断する
- 結果が小さいのに「勝ち」と言い切る
- 悪化した理由を見ずに、すぐ別案へ移る
特に「ボタン色を変えたら売上が上がるか」のような細かすぎる比較は、仮説が弱いまま実施されがちです。
色を比べる前に、ユーザーが不安に思っている情報は足りているか、次に押すべきボタンが分かるか、フォームで離脱していないかを見た方がよい場合もあります。
ユーザーテストやMVPとの違い
A/Bテストは、実際のユーザー行動を量で比べる方法です。
一方、ユーザーテストは、少人数の操作を観察して「なぜ迷うのか」「どこで誤解するのか」を見る方法です。
MVPは、完成版を作る前に、価値や課題の仮説を小さく検証する考え方です。
A/Bテストは、MVPや既存サービスで得た学びをもとに、画面、文言、導線を改善するときに使うことが多いです。
| 方法 | 主な目的 |
|---|---|
| A/Bテスト | 2つの案の結果差を見る |
| ユーザーテスト | 迷い、誤解、詰まりの理由を見る |
| MVP | そもそも価値があるかを小さく確かめる |
| アクセス解析 | どこで流入し、どこで離脱しているかを見る |
どれか1つで全部を解決するのではなく、状況に合わせて組み合わせます。
まとめ
A/Bテストは、Webサイトやアプリで2つ以上の案を出し分け、事前に決めた指標で結果を比べる改善手法です。
LPの見出し、CTA、フォーム、価格表示、メール件名など、ユーザー行動に影響しそうな要素を比較できます。
ただし、A/Bテストで大事なのは、ツールを入れることではありません。
何を改善したいのか、なぜ良くなると思うのか、どの指標で判断するのかを先に決めることです。
クリック率だけに引っ張られず、CVRや売上、問い合わせの質、継続利用まで見ながら判断すると、ただの見た目変更ではなく、実務で意味のある改善につながります。
参考リンク
- Optimizely: What is A/B testing?
- Optimizely Developer Docs: Overview of A/B tests in Optimizely Feature Experimentation
- GOV.UK Developer Documentation: How A/B testing works