デジタル実験を高頻度で回すプロダクトチームやグロースチームでは、同一ページやチェックアウト導線、主要なコンバージョン経路において複数の A/B テストが並行して稼働することが珍しくありません。しかし、同一ユーザーが複数の重複テストに同時に割り振られると、**交互作用（Interaction Effects）が生じ、成果の向上や低下がどちらの施策に起因するのか判別できなくなります。さらに、意図しないトラフィックの偏りによってサンプル比率の不均衡（Sample Ratio Mismatch: SRM）**が引き起こされるリスクもあります。
Optimizely では、この問題を解決するために**排他グループ（Exclusion Groups / Mutually Exclusive Groups）**を構成します。排他グループは複数の実験を包括するトラフィックコンテナとして機能し、共通の決定的ハッシュシードを用いてユーザーを分割します。排他グループ内で「実験A」に割り当てられたユーザーが、同時に「実験B」に割り振られることはありません。
排他グループを適用すべきケースと避けるべきケース
相互排他は統計データの整合性を担保する一方で、トラフィックの希釈化という明確なトレードオフを伴います。限られたトラフィックを複数のテストで分割すると、各実験のサンプルサイズが減少し、統計的有意差に到達するまでの所要期間が大幅に長期化します。
実験チームはシナリオに応じて適切な方針を選択する必要があります。
| 実験シナリオ | 推奨アプローチ | 判断の根拠 |
|---|---|---|
| 直接的な UI / UX の競合（例: 同一ページ内のファーストビューバナーやモーダルの重複改修） | 排他グループの必須設定 | デザイン崩れやメッセージの矛盾によるユーザー体験の悪化を防ぐ。 |
| 同一の重要コンバージョン導線（例: カート画面改修と購入フローの送料計算テストが同時進行） | 排他グループの必須設定 | 上流の変更が下流テストの指標を歪める交互作用バイアスを排除する。 |
| 同一コアアルゴリズムの改修（例: 検索順位モデルとレコメンドエンジンの並行テスト） | 排他グループの必須設定 | アルゴリズム重複によるレスポンス競合やレイテンシ指標の歪みを防止する。 |
| 物理的に独立したページ領域（例: ヘッダーナビゲーション改修とフッターの利用規約表示改修） | 同時並行で実施（排他なし） | 行動の交互作用リスクが極めて低く、十分なトラフィック量と実験速度を維持できる。 |
| 組み合わせによる相乗効果の検証（例: キャッチコピーとCTAボタン色の相互作用を検証したい） | 多変量テスト（MVT）を採用 | 全因子 MVT により、交互作用を抑制するのではなく統計的に定量評価する。 |
Optimizely における相互排他の内部メカニズム
標準の Optimizely では、各実験が独立してユーザーをバケッティング（振り分け）します。実験ごとにユーザー識別子（User ID または Bucketing ID）と実験ID（Experiment ID）を組み合わせ、決定的ハッシュ関数（MurmurHash3）を通じて 0 〜 9,999 の 10,000 個のバケットにマッピングします。
独立した実験同士ではハッシュ値の算出基盤が異なるため、同一ユーザーが複数の同時稼働テストの対象バケットに同時に合致することが起こり得ます。
実験を**排他グループ（Exclusion Group）**に登録すると、振り分けロジックが次のように変化します:
- 共通バケッティング基準: ハッシュ関数はユーザー識別子をまず排他グループIDと組み合わせて評価します。
- 決定的なトラフィック分割: 10,000 個のバケットが、グループ内で設定されたトラフィック配分割合に応じて各実験に排他的に割り振られます。
- 厳格な分離: ユーザーが「実験A」のバケット範囲に入った場合、そのユーザーは実験Aのみの対象となり、グループ内の実験Bや実験Cの判定からは即座に除外されます。
判定の優先順位（Evaluation Order）
Optimizely Feature Experimentation および Web Experimentation では、以下の厳格な順序でショートサーキット評価が行われます:
- ルール状態チェック: フラグルールまたは実験が有効か確認。
- 強制バリエーション（Forced Variations）: 最優先（QA や動作確認用）。
- ユーザーホワイトリスト（User Allowlisting）: 指定ユーザーIDの固定割り当て。
- ユーザープロファイルサービス（User Profile Service: UPS）: 過去セッションの永続化データの参照。
- オーディエンスターゲティング（Audience Targeting）: 属性条件の一致判定。
- 排他グループ判定（Exclusion Group Evaluation）: グループ内の他実験にすでに割り当てられていないか確認し、重複時は除外。
- トラフィック配分とバリエーション決定（Traffic Allocation）: 実験内の設定比率に応じて具体的バリエーション（Control または Variation）を決定。
設定手順: Optimizely Web Experimentation（クライアントサイド / Edge）
Web サイトのフロントエンド改修を実施するチーム向けの手順です。
1. 排他グループの作成
- Optimizely Web Experimentation の管理画面で Experiments を選択します。
- Exclusion Groups タブを開きます。（※ Optimizely Personalization を利用中の場合は Optimizations > Exclusion Groups に進みます）。
- Create New Exclusion Group をクリックします。
- 識別しやすいグループ名（Name）（例:
Checkout_Funnel_Q2_Exclusion）と任意の**説明（Description）**を入力します。
2. 対象実験の追加とトラフィック比率の配分
- 排他グループに含めるドラフト状態の実験を選択します。
- グループ全体のトラフィックに対する各実験の配分割合を設定します:
- 2 つのテストを均等に分ける場合は 50% ずつ設定します。
- ホールドアウト（非割り当て枠）を確保することも可能です（例: 実験1に 40%、実験2に 40%、ホールドアウトに 20%）。
- Create Exclusion Group をクリックして保存します。
3. ターゲティング条件の確認
同一の排他グループに属する実験同士は、対象 URL 条件やトリガー発火条件が合致しているか確認してください。
設定手順: Optimizely Feature Experimentation（サーバーサイド / SDK）
バックエンド、モバイルアプリ、フルスタック環境で実験を実装するエンジニアリングチーム向けの手順です。
1. Flags 管理画面での排他グループ作成
- Flags メニューから Exclusion Groups タブを開きます。
- Create New Exclusion Group をクリックします。
- グループ名と説明を入力します。
- 対象の環境（Environment）（
ProductionやStagingなど）を選択します。排他グループは環境ごとに独立して管理されます。 - Create Exclusion Group をクリックして作成を完了します。
2. フラグの実験ルールを排他グループに紐付け
- Flags の一覧に戻り、対象の実験ルールを含む機能フラグ（Feature Flag）を開きます。
- 対象環境を選択し、該当の Experiment Rule を開きます。
- Configure Rule セクション内のプルダウンメニュー "Add this experiment to the following exclusion group" を確認します。
- 作成した排他グループを選択します。
- その実験ルールが排他グループ内で占有するトラフィック割合を指定します。
- Save Experiment をクリックします。
- 並行して排他制御を行いたい他の実験ルールについても同様に設定します。
3. REST API による自動構成
CI/CD パイプライン等で設定を自動化する場合、Optimizely REST API を直接利用できます:
- グループ作成:
POST /v2/groupsに{"name": "Cart_Redesign_Group", "environment_key": "production"}を送信。 - ルールの紐付け:
PATCH /v2/groups/{group_id}を使用し、対象ルールのrule_idを渡して更新。 - グループ一覧の取得:
GET /v2/groupsで既存の排他設計を監査。
4. アプリケーションコードへの影響はゼロ
排他制御ロジックはデータファイル（Ruleset）に組み込まれ、SDK 内のメモリ上で自動計算されます。アプリケーション側で client.decide(user_key, flag_key) を呼び出す際、排他制御のための追加コードは一切不要です。
実験ガバナンスにおける4つの重要原則
データの歪みや統計的破綻を防ぐために、実験チームは以下の 4 原則を厳守する必要があります。
1. グループ内の実験は原則として同時に開始する
実験1を本日開始し、来週になって同じ排他グループに実験2を追加することは避けてください。既に一部のユーザーがグループのバケットに振り分けられている状態で実験を追加すると、内部バケットの境界が変動し、既存ユーザーの遷移やランダム配分の偏りが発生します。
2. 稼働中の排他グループに対して実験の追加・削除を行わない
グループ内のいずれかの実験が本番稼働している間は:
- 新しい実験を追加しない
- 実行中の実験をグループから削除しない 稼働中の変更はトラフィック比率を狂わせ、サンプル比率の不均衡（SRM）警告を引き起こし、統計的検証を無効化します。特定の実験を早期終了させたい場合は、グループを解体するのではなく、該当ルールの配信を一時停止してください。
3. オーディエンスターゲティングの整合性を保つ
実験Aがデスクトップユーザー全体を対象とし、実験Bがモバイルユーザーのみを対象とする場合、これらを同一の排他グループに入れるとトラフィックが無駄になります。グループ単位でバケッティングが行われるため、実験Bに割り当てられたデスクトップユーザーは何も表示されず、実験Aの必要サンプル数が不足します。
4. User Profile Service（UPS）による優先順位の逆転に注意する
セッション間でのバリエーション固定を目的に User Profile Service（UPS）を導入している場合、UPS の参照は排他グループの評価よりも前に実行されます。排他グループ設定前に単独テストでバリエーションを受け取っていたユーザーがいる場合、UPS に保存された過去の割り当てが優先され、排他制御をすり抜ける可能性があります。厳格な排他が必要な場合は、OptimizelyDecideOption.IGNORE_USER_PROFILE_SERVICE の利用を検討してください。