> ## Documentation Index > Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt > Use this file to discover all available pages before exploring further. # Kameleoon でクライアントサイドおよびサーバーサイド実験をまたぐ相互排他グループを作成する > Web 実験と機能実験の両方にまたがる相互排他グループを設定し、クライアントサイドとサーバーサイドのテスト間で訪問者の重複を防ぎます。 相互排他的な実験の管理は、複数の実験が並行して走る場合によくある要件です。しかし、これらの実験の一部がクライアントサイドで（**Kameleoon Web Experimentation** 経由で）トリガーされ、他のものがサーバーサイドで（**Kameleoon Feature Experimentation** 経由で）トリガーされる場合はどうでしょうか？ これはより高度なユースケースですが、適切なセットアップにより Kameleoon でサポートされています。この記事では、両方のテクノロジーにまたがる相互排他的なセットアップを構成する方法を順を追って説明します。 ## シナリオ **3 つの相互排他的な実験** を実行したいとします。 * **2 つの実験** は Kameleoon Web Experimentation（JavaScript ベース）を使用して **クライアントサイド** でトリガーされます。 * **1 つの実験** は Kameleoon Feature Experimentation（例: バックエンド SDK 経由）を使用して **サーバーサイド** でトリガーされます。 ここでの課題は、これらの実験が異なるテクノロジーで、かつユーザージャーニーの異なる段階でアクティブ化されるにもかかわらず、訪問者が **これらのうち 1 つだけに公開される** ようにすることです。 ### このユースケースの処理 クライアントサイドとサーバーサイドの両方の実験で相互排他性を確保するには、以下の手順に従います。 #### 1. 機能実験から開始する 機能実験は **サーバーサイド** でトリガーされ、早期のターゲティング（ページロード前）が必要なため、最初にこれにトラフィックを割り当てるのが最適です。 * **Feature Experiment** を作成します。 * この実験に **総トラフィックの 33%** を割り当てます（またはテスト計画に合わせて他のパーセンテージでも構いません）。 残りの **67%** のトラフィックは、2 つの Web 実験で利用できるようになります。 #### 2. Web 実験用の相互排他グループを作成する 次に、2 つの Web 実験用に **相互排他グループ（Mutually Exclusive Group）** を作成します。 👉 このドキュメントに従ってください: [Mutually Exclusive Groups で重複するキャンペーンを防止する](./prevent-overlapping-campaigns-with-mutually-exclusive-groups)。重複を防ぐことで、訪問者は 2 つの Web 実験のうち **どちらか 1 つ** しか見ることができず、両方を見ることはありません。 #### 3. 機能実験参加者を除外するターゲティング条件を追加する 機能実験にバケットされたユーザーがどちらの Web 実験にも入らないようにするため、両方の Web 実験に次のターゲティング条件を適用します。 * **ターゲティング条件:** `Campaigns → Feature Flag` **→ "feature\_experiment\_name" の任意のバリエーションに公開された訪問者を除外する。** このステップにより、両方のテクノロジーにまたがる相互排他性が保証されます。 #### 4. 技術的な考慮事項 デフォルトでは、**Kameleoon Web Experimentation** は各ページロード時に **リモート同期コール** を実行し、ユーザーが Feature Experiment に公開されたかどうかをチェックします。このコールにより、Kameleoon はユーザーを Web 実験に含めるか除外するかを判断できます。 3 つの実験が **同じページ** で走っている場合、このセットアップは **扱いが難しい** ことがあります。なぜなら、Web エンジンはユーザーを Web 実験に含めるかどうかを決定する前に **サーバーサイドの公開ステータスを待たなければならない** ためで、これは **フリッカリング** や遅延コンテンツを引き起こす可能性があります。 Feature Experiment と Web Experiments がカスタマージャーニーの異なるタイミング（例: 異なるページ）でトリガーされる場合、すでに Web Experiments の 1 つに公開された訪問者を除外するための除外ターゲティング条件を Feature Experiment にも追加する必要があります。 ##### 推奨される解決策 フリッカリングを排除し、リアルタイムの意思決定を確保するために、リモートコールを待たずに **フロントエンドで直接** ユーザーの Feature Experiment ステータスを公開します。 * SDK メソッドを使用します: `getEngineTrackingCode()`。 * 出力をページの HTML、できれば `` セクションに挿入します。 これにより、Kameleoon はユーザーが Feature Experiment にすでに公開されたかどうかをすぐに認識でき、より高速でシームレスなターゲティングが可能になります。 ## まとめ クライアントサイドとサーバーサイドの実験にまたがる相互排他テストは **複雑ですが、Kameleoon が適切に実装すれば完全にサポートされます**。 要点を簡単にまとめると: * **機能実験から始め**、そのトラフィックシェアを最初に割り当てる。 * **相互排他グループを使用** して Web 実験間の重複を管理する。 * キャンペーン条件を使用して、Web 実験のターゲティングから **機能実験参加者を除外する**。 * 実験が同じページで重複する場合は、**トラッキングコードメソッドを使用して** 遅延とフリッカーを排除する。 このアプローチにより、データの整合性を維持しながら、クリーンで信頼できるテスト体験を確保できます。