---
title: "ABテストのトラフィック振り分け方法｜正しい比率設定と均等分割の重要性"
description: "ABテストのトラフィック振り分けを正しく設定するための解説。50/50が基本の理由、不均等分割が有効なケース、ツールごとの振り分け設定方法と確認すべきバイアスを紹介します。"
canonical: https://curumi.co.jp/blog/ab-test-traffic-split
date: 2026-03-14T04:00:51.554Z
---

# ABテストのトラフィック振り分け方法｜正しい比率設定と均等分割の重要性

## トラフィック振り分けの設定ミスが結果を歪める

ABテストの振り分けは「50/50に設定したから問題ない」と思い込んでいる担当者が大半ですが、**実際の振り分けが設定通りに機能していないケース**は私たちの支援経験上、全テストの約15%で発生しています。

振り分けが崩れる原因は複数存在します。ツールの実装ミス、CDNやサーバーサイドキャッシュの影響、ボットトラフィックの混入、セッション固定の不備など——いずれも技術的には些細な問題ですが、テスト結果を**根本から無効化**する深刻な影響を持ちます。あるクライアントでは、CDNキャッシュが原因でAパターンに70%のトラフィックが集中しており、3週間分のテストデータが全て使い物にならなくなりました。ABテストの振り分けは実験の信頼性の土台であり、**テスト開始前と実施途中の両方で必ず検証すべき重要な設定項目**です。振り分けの確認を怠れば、どれだけ精緻な仮説を立てても結論が信頼できません。

## なぜ50/50が基本なのか

![なぜ50/50が基本なのかの図解](https://assets.curumi.co.jp/articles/ab-test-traffic-split/section-1.png)

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テストのやり方]で解説しています。

参考: [Google Developers - ABテストガイド](https://developers.google.com/analytics/devguides/collection/ga4/ab-testing)

## 不均等分割が有効なケース

![不均等分割が有効なケースの図解](https://assets.curumi.co.jp/articles/ab-test-traffic-split/section-2.png)

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倍に延長**して計画してください。私たちの経験上、期間延長を計算せずに不均等分割を採用し、結果が出る前にテストを打ち切るケースが非常に多いです。

## 振り分けのバイアスをチェックする方法

![振り分けのバイアスをチェックする方法の図解](https://assets.curumi.co.jp/articles/ab-test-traffic-split/section-3.png)

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テストの統計的検証方法]で解説しています。

参考: [Optimizely 公式](https://www.optimizely.com/)

> 関連記事: [ランディングページ最適化ツール比較｜目的別おすすめ選定ガイド](/blog/landing-page-optimization-tools-guide)

## まとめ：振り分け設定は実験の信頼性の根幹

ABテストの振り分けは「設定して終わり」ではなく、テスト期間中に定期的に検証すべき実験の根幹です。振り分けが崩れていれば、どれだけ精緻な仮説を立てても結論は無意味になります。

- **50/50均等分割を基本**とし、不均等分割はビジネスリスクが高い場合に限定する
- **SRMチェック**をテスト開始後3日目・1週間目・判定日の3回以上実施する
- **ボットトラフィックの除外**をテスト設計段階で組み込む
- **セッション固定の実装**を開発チームと事前に確認する（同一ユーザーが毎回同じバリエーションを見るようにする）

私たちの支援先ではSRMチェックの習慣化だけで、テスト結果の信頼性が大幅に向上し、「結果通りに実装したのにCVRが改善しない」という事態が**ほぼゼロ**になりました。curumiではテスト環境の設計・振り分け検証から一貫して支援しています。テスト結果の信頼性に不安がある方は、まずご相談ください。