トラフィック振り分けの設定ミスが結果を歪める
ABテストの振り分けは「50/50に設定したから問題ない」と思い込んでいる担当者が大半ですが、実際の振り分けが設定通りに機能していないケースは私たちの支援経験上、全テストの約15%で発生しています。
振り分けが崩れる原因は複数存在します。ツールの実装ミス、CDNやサーバーサイドキャッシュの影響、ボットトラフィックの混入、セッション固定の不備など——いずれも技術的には些細な問題ですが、テスト結果を根本から無効化する深刻な影響を持ちます。あるクライアントでは、CDNキャッシュが原因でAパターンに70%のトラフィックが集中しており、3週間分のテストデータが全て使い物にならなくなりました。ABテストの振り分けは実験の信頼性の土台であり、テスト開始前と実施途中の両方で必ず検証すべき重要な設定項目です。振り分けの確認を怠れば、どれだけ精緻な仮説を立てても結論が信頼できません。
なぜ50/50が基本なのか
ABテストの振り分けで50/50の均等分割が基本である理由は、統計的に最も効率が良いからです。同じサンプルサイズの条件下で、均等分割は最も早く有意差を検出できる分割比率です。
分割比率と検出効率の関係
| 分割比率 | 必要期間（50/50比） | 適用場面 |
|---|---|---|
| 50/50 | 1.0倍（基準） | 標準的なABテスト |
| 70/30 | 約1.4倍 | 新パターンのリスクが若干ある場合 |
| 80/20 | 約2.0倍 | 段階的ロールアウト |
| 90/10 | 約5.0倍 | 高リスクな変更の初期検証 |
| 95/5 | 約19倍 | 大規模サイトの段階展開のみ |
私たちの運用では、特別な理由がない限り50/50を選択します。「新しいデザインに自信がないから80/20にしたい」という要望をよく受けますが、それは検出に2倍の時間がかかることを意味します。自信がないなら、テスト期間を短くするのではなく、リスクの低い要素から検証する方が合理的です。
例外的に不均等分割を推奨するケース： 決済フローの大幅変更や会員登録プロセスの刷新など、バグがあると売上に直接影響する変更の場合は、80/20で初期検証してから50/50に移行する段階的アプローチを採用しています。
不均等分割が有効なケース
ABテストの振り分けで不均等分割（例：80/20）が有効なのは、新バリエーションのビジネスリスクが高い場合に限られます。私たちの実務では、以下の3パターンでのみ不均等分割を採用しています。
不均等分割を採用する3つのケース
1. 決済・課金フローの変更 決済フローのUIを大幅に変更する場合、バグや離脱増加のリスクがあるため20%のトラフィックで初期検証します。あるECサイトでは、チェックアウトフローの2ステップ化を80/20で2週間検証し、致命的な問題がないことを確認してから50/50に移行しました。
2. 段階的ロールアウト サーバーサイドの変更を伴うテストで、パフォーマンスへの影響を段階的に確認したい場合。90/10→70/30→50/50と段階的にトラフィックを増やします。
3. 大規模サイトのリスク管理 月間100万PV超のサイトでは、新パターンに50%を流すだけでも数万ユーザーに影響するため、初期は5〜20%で検証することがあります。
重要な注意点： 不均等分割を採用する場合、検出力が落ちることを前提にテスト期間を1.5〜5倍に延長して計画してください。私たちの経験上、期間延長を計算せずに不均等分割を採用し、結果が出る前にテストを打ち切るケースが非常に多いです。
振り分けのバイアスをチェックする方法
ABテストの振り分けが正しく機能しているかを検証するにはSRMチェック（Sample Ratio Mismatch）が不可欠です。SRMとは、設定した振り分け比率と実際のトラフィック比率の統計的な乖離を検出する手法で、カイ二乗検定を使って判定します。
私たちは全テストでSRMチェックを実施しており、実際にSRMが検出された割合は全テストの約12%です。この12%のテストは、SRMに気づかなければ誤った結論を導いていた可能性が高いものです。
SRMが発生する主な原因と対策
| 原因 | 発生頻度 | 対策 |
|---|---|---|
| CDN/サーバーキャッシュ | 高い | テストページのキャッシュを無効化 |
| ボットトラフィック | 中程度 | User-Agentフィルタ・reCAPTCHA導入 |
| リダイレクトの遅延 | 中程度 | サーバーサイドで振り分け実装 |
| ツールのスニペット配置ミス | 低い | ドキュメント通りの実装を検証 |
ツール別のSRM対応状況
- Optimizely — 自動でSRMを検出し、アラート表示
- VWO — SRM検出機能あり（ダッシュボードで確認可能）
- Google Optimize後継（自前実装） — 手動でカイ二乗検定を実行する必要あり
SRMが検出された場合、そのテスト結果は信頼できません。 原因を特定し修正した上で、テストをゼロからやり直すことを推奨します。「もったいないから」とSRMのあるデータで判定を下すのは、コインの重心が偏ったコイン投げで意思決定するのと同じです。
まとめ：振り分け設定は実験の信頼性の根幹
ABテストの振り分けは「設定して終わり」ではなく、テスト期間中に定期的に検証すべき実験の根幹です。振り分けが崩れていれば、どれだけ精緻な仮説を立てても結論は無意味になります。
- 50/50均等分割を基本とし、不均等分割はビジネスリスクが高い場合に限定する
- SRMチェックをテスト開始後3日目・1週間目・判定日の3回以上実施する
- ボットトラフィックの除外をテスト設計段階で組み込む
- セッション固定の実装を開発チームと事前に確認する（同一ユーザーが毎回同じバリエーションを見るようにする）
私たちの支援先ではSRMチェックの習慣化だけで、テスト結果の信頼性が大幅に向上し、「結果通りに実装したのにCVRが改善しない」という事態がほぼゼロになりました。curumiではテスト環境の設計・振り分け検証から一貫して支援しています。テスト結果の信頼性に不安がある方は、まずご相談ください。