configuring-experiment-rollout

実験のロールアウト設定

このスキルでは、誰にどのバリアントが表示されるかについて説明します。

推奨される方法：均等に分割し、ロールアウト率を調整する

ほとんどの場合、実験は均等に分割するのが最適です。テストバリアントへの露出を制限したい場合は、代わりにロールアウト率を調整してください。

均等な分割が優れている理由：

• 均等に分割すると統計的検出力が最大になります。各バリアントのサンプルサイズが同じになるためです。
• 均等に分割するとトラフィックのバランスが取れ、有意性により早く到達できます。
• ロールアウト率を段階的に上げることで、実験中にユーザーへの露出を増やす方法はシンプルです（実験の途中で分割を変更すると、ユーザーが別のバリアントに切り替わる可能性があり、ユーザー体験とデータ品質に悪影響を及ぼします）。

ユーザーが明示的に別の方法を希望しない限り、常に均等な分割をデフォルトにしてください。

不均等な分割が必要な場合

デフォルトの「分析から除外」処理と不均等な分割を組み合わせると、バイアスが生じる可能性があります。 実験で複数のバリアントを利用したユーザー（複数のバリアントに露出したユーザー）が確認された場合、そのユーザーは 非対称に除外されます。割り当てられたユーザーのうち、小さい方のバリアントではより大きな割合が失われます。こうしたユーザーの 行動が他のユーザーと異なる場合、小さい方のバリアントの指標に偏りが生じます。

適切な対策は実験の状態によって異なります。

1. 開始前、または開始後でもまだ露出が少ない場合 — 均等に分割し、全体の ロールアウト率を下げます。 バイアスを生じさせずにテストバリアントへの露出を同程度に保ち、統計的 検出力も維持できます。下記の確認質問をご覧ください。
2. 露出が十分に発生している実験の実行中 — 多変量の処理を「最初に確認された バリアント」に切り替えます。 実験の途中で分割を変更すると、ユーザーが別のバリアントに再割り当てされます（アンチパターンです。「実行中の実験でロールアウトを変更する」をご覧ください）。処理を切り替えれば、全員が 元のバリアントを維持し、非対称な除外を避けられます。設定方法については configuring-experiment-analytics をご覧ください。「最初に確認されたバリアント」の処理によって別のバイアスが生じる可能性はありますが、実験途中の再割り当てよりは望ましい方法です。

2つのロールアウト制御

誰にどのバリアントが表示されるかを決める制御は、2つあります。 どちらもリンクされたフィーチャーフラグにあり、フラグ独自の形式を持つ feature_flag オブジェクトを通じて送信します（非推奨の parameters キーではありません）。

1. バリアント分割（feature_flag.filters.multivariate.variants）

実験に参加しているユーザーを、各バリアントにどのように割り当てるかを指定します。

• {key, name, rollout_percentage} の配列です。rollout_percentage の値の合計は100でなければなりません。
• バリアントは最小2つ、最大20個です。
• 特定のバリアントキーは必須ではありません。分析のベースラインには、"control" というキーのバリアントが存在する場合はそれが、存在しない場合は最初のバリアントがデフォルトで使用されます。
• デフォルト：control 50%／test 50%

ユーザーがキーを指定せずに「A/B/Cテスト」と言った場合は、慣例に従ってベースラインのキーを "control" にし、残りのバリアントを追加してください。具体的なキーが指定された場合は、ベースラインを先頭にしてそのまま使用してください。

2. 全体のロールアウト（feature_flag.filters.groups[0].rollout_percentage）

実験に参加する全ユーザーのうちの割合を、単一のロールアウトグループとして指定します：groups: [{ "properties": [], "rollout_percentage": N }]。 デフォルト：100%。

含まれないユーザーは完全に除外されます。どのバリアントも表示されず、分析にも含まれません。

送信先

どちらの制御も feature_flag.filters 内にあります。

{
  "feature_flag": {
    "filters": {
      "multivariate": {
        "variants": [
          { "key": "control", "name": "Control", "rollout_percentage": 50 },
          { "key": "test", "name": "Test", "rollout_percentage": 50 }
        ]
      },
      "groups": [{ "properties": [], "rollout_percentage": 100 }]
    }
  }
}

filters には、aggregation_group_type_index（個々のユーザーではなくグループタイプを対象に実験を実行する場合）と、payloads（バリアントキーをキーとするJSONエンコード済み文字列）も含められます。 実行中の実験では、フラグ設定を変更する場合は必ず update_feature_flag_params: true も送信してください。そうしないと、API がフラグに変更を適用する前に更新を拒否します（「実行中の実験でロールアウトを変更する」をご覧ください）。

これらの設定の連動

この2つの設定は相互に作用します。

全体のロールアウト	バリアントの分割	テストを閲覧する割合	分析対象の割合
100%	50/50	50%	100%
100%	75/25 コントロール/テスト	25%	100%
50%	50/50	25%	50%
25%	50/50	12.5%	25%

曖昧さを解消するための質問

重要：ユーザーが不均等なバリアント分割（例：「60/40」、「70/20/10」）を依頼した場合、または分割とロールアウトのどちらを指すか判断できない具体的な割合（例：「25%にロールアウト」）に言及した場合は、先に必ず確認してください。次の2つのケースが該当します。

ケース 1：単一の割合（「25%」、「40%にロールアウト」）

割合が曖昧です。バリアント分割またはロールアウトの変更を意味する可能性があります。次のように尋ねてください。

テストバリアントを閲覧するユーザーを25%にする方法は2つあります。

1. ロールアウトを縮小し、均等に分割する（推奨）：全体のロールアウトを縮小し、バリアントを均等に分割します。一部のユーザーのみが実験に参加し、その参加者には各バリアントが同じ割合で割り当てられます。 均等な分割は統計的検出力を最大化し、バイアスを避けられます。
2. 不均等に分割する：ロールアウトを100%に保ち、テストバリアントの割合を25%にします。 すべてのユーザーが実験に参加しますが、不均等な分割により少数側のバリアントの検出力が低下し、バイアスのリスクが生じます。

どちらの方法を希望しますか？

ユーザーが指定した割合に合わせて数値を調整してください。

ケース 2：不均等な比率（「60/40」、「70/30」、「80/20」など）

この比率は明示的なバリアント分割の指定に見えますが、ほとんどの場合、ロールアウトを縮小して均等に分割するほうが適切です。トレードオフを説明し、代替案を推奨してください。

不均等なバリアント分割も可能ですが、ロールアウトを縮小して均等に分割することを推奨します。

1. 均等な分割＋ロールアウトの縮小（推奨）：テストバリアントを閲覧するユーザーの割合が同じになるよう全体のロールアウトを縮小し、実験内ではバリアントを均等に分割します。 均等な分割は統計的検出力を最大化し、多変量の非対称な除外によるバイアスを避けられます。
2. 不均等な分割。 ユーザーから見た結果は同じですが、少数側のバリアントの検出力が低下し、バイアスのリスクが生じます。

均等に分割する方法を希望しますか？それとも、不均等な分割にする具体的な理由がありますか？

比率に合わせて数値を調整してください。バリアントが3つ以上ある実験では、「均等」とは各バリアントが同じ割合になることを意味します（例：3つのバリアントなら34/33/33）。トレードオフの説明を受けた後、ユーザーが不均等な分割を希望すると確認した場合は、そのまま進めてください。ただし、次のセクションは必ず確認してください。

ユーザーが不均等な分割を選んだ後

ユーザーが不均等な分割（上記いずれかのケースで選択肢2）を選んだ場合、実験を作成または更新する前に、多変量の処理に関する影響を必ず伝えてください。ユーザーはリスクの高いロールアウト方法を選択しているため、リスクを軽減する方法を十分に理解したうえで選べるようにする必要があります。

次のように尋ねてください。

もう一点あります。不均等に分割すると、デフォルトの「分析から除外」設定では、複数のバリアントに接触したユーザーが非対称に除外されます。少数側のバリアントでは割り当てのうち除外される割合が高くなり、そうしたユーザーの行動がほかのユーザーと異なる場合、指標に偏りが生じる可能性があります。

次の2つの方法があります。

1. 多変量の処理を「最初に確認されたバリアントを使用」に切り替える（不均等な分割では推奨） — すべてのユーザーを分析対象に維持し、非対称な除外を避けられます。別のバイアスが生じる可能性など、注意点もありますが、不均等な分割ではデフォルト設定より適しています。
2. デフォルトの「除外」設定を維持し、バイアスのリスクを受け入れます。

どちらにしますか？

多変量の処理の設定方法については、configuring-experiment-analyticsを参照してください。選択した設定は、作成または更新と同じ操作の一部として適用してください。ユーザーに明示的かつ十分な情報に基づく判断をしてもらわずに、不均等な分割をデフォルト設定のままにしないでください。

ログインをまたぐバケット分けと永続化

デフォルトでは、ユーザーのバリアントはそのユーザーの distinct ID に従います。同じユーザーが識別される前後（通常はログイン時）にフラグを確認すると、distinct ID が変わり、それに伴ってバリアントも変わることがあります。 フラグまたは実験を作成する前に選択してください。稼働中のフラグでは、バケット分けや永続化の設定を変更しないでください。

ページ上の匿名訪問者の割合だけでは判断できません。この割合が示すのはページ上の構成であり、同じユーザーがそこで識別の前後をまたぐかどうかではありません。これは別の問いです。割合が半々でも、互いに重ならない2つの集団かもしれません。また、ほぼ全員が識別済みのページでも、全員が最初のページビューで匿名として処理される場合があります。 そのため、3つの選択肢をそれぞれに必要な条件とともに提示し、ユーザーに選んでもらってください。

• ユーザー ID によるバケット分け（デフォルト）：ensure_experience_continuity を含めず、チームの永続化デフォルトを適用します。ただし、以下の2つの場合を除きます。
• デバイス ID によるバケット分け（以下の手順を参照）：すべてのフラグ呼び出しでデバイス ID が必要です。デバイス ID のない呼び出しにはバリアントが割り当てられません。サーバー SDK ではブラウザーのデバイス ID を転送する必要があり、転送されていればローカル評価も機能します。Web SDK は posthog-js 1.307.1 以降、フラグリクエストにデバイス ID を送信します。古いバージョンではイベントにはデバイス ID が付与されますが、フラグリクエストには付与されないため、バージョンを確認してください。フラグサービスは、デバイス ID を送信するあらゆる SDK からデバイス ID を受け取ります。そのため、プラットフォームではなくデバイス ID の割合を確認してください。この割合はフラグリクエストではなくイベントを数えるため、割合がほぼ 0 でも、この選択肢を無効とはせず、未確認のままにしてください。
• 永続化（ensure_experience_continuity: true）：SDK がフラグをローカル評価する環境では機能しません。ローカル評価ではオーバーライドストアを参照しないためです。また、匿名ユーザーの person プロファイル、ブートストラップを使用しないこと、サーバーのフラグ呼び出しでの $anon_distinct_id も必要です。詳細：https://posthog.com/docs/feature-flags/creating-feature-flags#persisting-feature-flags-across-authentication-steps

ensure_experience_continuity を省略すると、experiment-create はチームの永続化デフォルトを適用します。デバイス ID によるバケット分けには、このような手順は必要ありません。create-feature-flag は、設定しない限り永続化をオフにし、experiment-create は、すでに存在するフラグに対する feature_flag オブジェクトを拒否します。デバイス ID によるバケット分けと永続化は併用できず、API はこの組み合わせを拒否します。

次の2つの場合は、省略せずにフィールドを設定する必要があります。

• experiment-create ですでに作成したフラグを、デバイス ID によるバケット分けに変更する場合。このフラグにはチームの永続化デフォルトが設定されているため、同じ呼び出しで ensure_experience_continuity: false を渡してください。渡さないと、前述の拒否によって変更できません。
• チームの永続化デフォルトがオンで、SDK がフラグをローカル評価する場合。この場合、フラグはそこで機能しない永続化設定を継承します。そのことをユーザーに伝え、ユーザーから依頼された場合にのみ、このフィールドを false に設定してください。チームがそのデフォルトを選択しているためです。

デバイス ID によるバケット分けの手順

experiment-create ではバケット分けを設定できないため、まずフラグを作成してからリンクします。

1. 実験のキー、bucketing_identifier: "device_id"、およびリリース前にバリアントが割り当てられないよう active: false を指定して、create-feature-flag を呼び出します（新しいフラグはデフォルトで有効です）。

   {
     "key": "kebab-case-key",
     "name": "Experiment name",
     "active": false,
     "bucketing_identifier": "device_id",
     "filters": {
       "groups": [{ "properties": [], "rollout_percentage": 100 }],
       "multivariate": {
         "variants": [
           { "key": "control", "rollout_percentage": 50 },
           { "key": "test", "rollout_percentage": 50 }
         ]
       }
     }
   }
   

   filters.groups は必須です。グループのないフラグは拒否されます。

2. その feature_flag_key を指定し、feature_flag オブジェクトを含めずに experiment-create を呼び出します。実験はフラグをそのままリンクし、実験を開始するとフラグが有効になります。

experiment-setup-context は、これらのルールに必要な情報（ページ上の未識別訪問者の割合と、SDK ごとのデバイス ID およびローカル評価の割合）を報告します。creating-experiments（references/setup-decisions.md）がそれらに基づいて判断します。

実験の特定

ロールアウトを変更するには、実験 ID が必要です。ユーザーが名前や説明で実験を指定した場合（例：「サインアップのテストのロールアウトを変更して」）、続行する前に finding-experiments スキルを読み込み、具体的な ID を特定してください。

実行中の実験におけるロールアウトの変更

実行中の実験のロールアウトやバリアントの割り当て比率を変更すると、ユーザー体験と統計的妥当性の両方に影響します。 変更を行う前に、必ずユーザーに警告し、明示的な確認を得てください。

変更を黙って適用してはいけません。ユーザーから直接依頼された場合も同様です。 次の両方の観点を含めて警告してください。

1. どのユーザーにどのバリアントが表示されるか？ — ユーザーが別のバリアントに切り替わったり、機能を利用できなくなったりしますか？
2. 誰が分析対象に含まれるか？ — データ品質にどのような影響がありますか？

例外：割り当て比率を変えずにロールアウトを拡大する場合は、通常、安全です。ユーザーが別のバリアントに切り替わることはなく、より多くのユーザーが問題なく追加されます。

目的が割合の変更ではなく「新しいユーザーの参加を止める」ことである場合：ロールアウトを縮小する方法は適切ではありません。すでに参加しているユーザーも実験から外れてしまいます。 experiment-freeze-exposure を使用すると、参加中のユーザーはバリアントを維持し、メトリクスの記録も続けたまま、新規参加を停止できます。前提条件と制限については managing-experiment-lifecycle を参照してください。

実験の途中で、割り当て比率の不均衡によるバイアスを修正する場合：「除外」から「最初に確認したバリアント」に多変量の処理方法を切り替えることが、すでに開始した実験に推奨される緩和策です。ユーザーが別のバリアントに切り替わることはなく、収集済みのデータはすべて分析に残ります。実験の途中で割り当て比率を均等に変更するのはアンチパターンです（通常、実験のリセットまたは終了が必要です）。実験がまだ多くのユーザーに公開されていない場合に限り、こちらが優先されます。処理方法の変更については configuring-experiment-analytics を参照してください。

詳しい警告内容、ユーザーへの説明、代替案を推奨すべき状況については references/changing-distribution-after-launch.md を参照してください。

関連スキル

• configuring-experiment-analytics — 分析に関する内容：公開基準、メトリクス、多変量の処理方法
• diagnosing-experiment-health — 実験途中の割り当て比率の変更により、結果にすでに偏りが生じている場合
• managing-experiment-lifecycle — 割り当て比率の変更にリセットまたは終了して再開する必要がある場合の手順