プロンプトとコンテキスト
あるプロダクト組織では、毎日数百件のA/Bテストが実行されています。プラットフォームはユーザーを割り当て、エクスポージャーを記録し、メトリクスを計算し、品質を監視します。過去の実験では、不均等な割り当て、サンプル比率の不一致（Sample Ratio Mismatch: SRM）、繰り返しの早期確認（peeking）に起因する無効な結論といった問題が発生していました。実験の設定から意思決定のレビューまで、データの遅延、統計手法、アラート、権限管理を含めてシステムを設計してください。
面接官が見ているポイント
- 実験単位、ランダム化レベル、相互排他プレーン、メトリクス定義を明確にできるか。
- 割り当て（assignment）、トリガー（trigger）、エクスポージャー（exposure）、成果（outcome）の各イベントを分離して扱えているか。
- ランダム化チェック、SRM検知、データ品質アラートを設計できるか。
- 固定期間テスト（fixed-horizon test）を自由に早期確認できないことを理解しており、逐次手法や常時有効（anytime-valid）な手法を提案できるか。
- アラート、監査、再実行、リリースゲートが単一のワークフローとして統合されているか。
最初に確認すべき明確化のための質問
- ランダム化はユーザー、デバイス、セッション、リクエストのどの単位ですか？実験は直交（orthogonal）して実行できますか？
- 1日に実行される実験数とユーザー数はどのくらいで、メトリクスのレイテンシや保持期間ウィンドウはどのようになっていますか？
- 主要メトリクス、ガードレール、最小検出可能効果（MDE）はどのように宣言されますか？
- SRMやエクスポージャーデータの欠損が発生した場合、トラフィックを一時停止すべきですか、テストを無効化すべきですか、それとも再実行すべきですか？
- 割り当ての確認、停止ルールの変更、リリースの承認を行える権限は誰にありますか？
30秒の回答
「私はプラットフォームを設定とランダム化、イベント収集、分析、意思決定ゲートの4つに分割します。割り当てには安定したハッシュを使用してユーザーをバケットにマッピングし、相互排他な実験と直交する実験を分離します。イベントパスでは、割り当て済み、トリガー済み、エクスポージャー済み、成果の各状態を記録します。品質サービスがバケット分布とSRMを継続的にチェックし、分析ではモニタリングと停止のために逐次手法または常時有効な手法を採用します。すべての意思決定にはデータ、コード、監査のバージョンが付与され、品質アラートが発生した場合は単なるチャット通知にとどまらずリリースの進行をブロックします。」
ステップごとの詳細な回答
1. 実験とランダム化の境界を定義する
設定には、実験ID、バージョン、単位、トラフィック分割、相互排他プレーン、対象メトリクス、ガードレール、最小検出可能効果、停止ルールが含まれます。ハッシュには安定したユニットキーと実験シードを使用し、1人のユーザーがリクエストごとにバリアントを切り替わらないようにします。相互排他なテストはプレーンを共有し、直交テストは別々のプレーンを使用して衝突ポリシーを記録します。
2. 割り当てイベントと成果イベントを分離する
コンバージョンのみを記録しても、ユーザーが実際にバリアントを閲覧したことを証明できません。イベントには、割り当て、トリガー、エクスポージャー、成果を含め、実験バージョン、バリアント、時刻、匿名のユニットハッシュ、ソースを記録する必要があります。イベントスキーマをバージョニングし、再計算ウィンドウ内への遅延イベントの混入を許容し、冪等性キーで重複を排除します。
{
"experiment": "checkout-copy-v3",
"experimentVersion": 7,
"unitHash": "u_8f2c",
"variant": "treatment",
"event": "exposure",
"eventTime": "2026-08-01T12:00:03Z",
"schemaVersion": 2,
"idempotencyKey": "u_8f2c:checkout-copy-v3:7:exposure"
}イミュータブルなイベントとバージョン識別子によって割り当てと分析が結びつけられるため、設定を変更しても過去のデータが誤って再解釈されることはありません。
3. ランダム化とSRMを監視する
ランダム化チェックでは、バケット分布を期待値と比較します。SRMチェックでは、観測されたトリガー済みサンプルを設定された比率と比較します。適格性（eligibility）、クライアントのバージョン、計測実装が割り当て後にのみバイアスをもたらす可能性があるため、割り当て済みレベルとトリガー済みレベルの両方を検査します。アラートは診断用スライスを保持しつつ、一時的なデータ遅延、実際の割り当ての欠陥、トラフィックの変化を区別できるようにします。
4. 継続的な観測と停止を処理する
毎日確認して有意になった時点で停止する固定期間テストは、第一種の過誤（Type I error）を増大させます。グループ逐次法、SPRT、または常時有効な信頼区間（anytime-valid confidence sequences）を使用し、境界、alpha、beta、MDE、観測時刻を実験バージョンに記録します。リードを確認したプロダクトオーナーであっても統計的ゲートを迂回することはできません。ガードレールの失敗や安全境界の突破が発生した場合は、まずトラフィックを停止する必要があります。
5. ストリーミングパスとバッチパスを設計する
ストリーミングパスはKafkaライクなイベントを消費し、割り当て品質やデータ遅延のアラートを数分以内に更新します。バッチパスは重複排除、遅延データの修復、スライスの計算を行い、最終レポートを生成します。両者はスキーマ、実験バージョン、メトリクス定義を共有します。ストリーミングの結果は暫定的なものであり、バッチのウォーターマークによってのみリリース証跡となります。
6. 意思決定を監査およびリリースゲートに接続する
実験の状態には、draft、running、paused、invalid、concluded、archivedが含まれます。シード、メトリクス、または停止ルールを変更すると新しいバージョンが作成され、古い結果は凍結されます。意思決定サービスは、データウォーターマーク、手法、サンプルサイズ、SRM状態、ガードレール状態、監査リンクを出力します。リリースは、品質チェックに合格したconcluded状態のバージョンのみを受け入れます。
高品質な回答例
「私ならまずランダム化単位と実験バージョンを固定し、割り当て、トリガー、エクスポージャー、成果の各イベントを分離します。ランダム化には安定したハッシュと相互排他または直交プレーンを使用します。イベントパイプラインでは、重複、遅延データ、リプレイに対応するためにスキーマバージョンと冪等性キーを使用します。品質サービスは、割り当て済みおよびトリガー済みのレベルでバケット分布とSRMをチェックし、根本原因分析のためのスライスを公開します。固定期間テストが恣意的な早期確認によって損なわれないよう、分析には逐次手法または常時有効な手法を用い、境界と観測時刻を記録します。ストリーミングデータはアラートを駆動し、バッチウォーターマークがレポートを生成します。意思決定には設定、コード、データ、監査のバージョンが付与され、SRM、エクスポージャーの欠損、ガードレールの失敗が発生した場合はリリースをブロックします。」
よくある間違い
- 最終メトリクスのみを保存する → 割り当てやエクスポージャーの欠損が見えなくなる → 割り当て、トリガー、エクスポージャー、成果を保持する。
- ユーザーごとではなくリクエストごとにランダム化する → 1人のユーザーが複数のバリアントを目にする → 安定したユニットキーとシードを使用する。
- 毎日p値をチェックして早期停止する → 固定期間の前提が崩れる → 逐次手法または常時有効な手法を使用する。
- SRMを成果の有意性結果と呼ぶ → 異常な比率はテスト自体を無効化する可能性がある → 意思決定を一時停止し、割り当てと適格性を診断する。
- ストリーミングデータから直接リリースを駆動する → 遅延イベントや重複イベントが結論を書き換える恐れがある → バッチウォーターマークとリリースゲートを必須とする。
フォローアップ質問と回答
なぜ割り当て済みサンプルとトリガー済みサンプルの両方をチェックするのですか？
割り当て自体が均等であっても、ページに到達した対象ユーザーのみがテストをトリガーします。適格性ロジック、クライアントバージョン、インターセプター、エクスポージャーイベントの欠損などがトリガー比率を歪める可能性があります。両方のレベルを検証することで、ランダム化自体の欠陥とエクスポージャー経路の欠陥を区別できます。
相互排他テストと直交テストをどのようにサポートしますか？
相互排他テストはトラフィックプレーンとシードを共有するため、ユーザーはそのプレーン内で1つのテストにのみ参加します。直交テストは別々のプレーンを使用し組み合わせが可能ですが、プラットフォームは衝突マトリクスを記録し、リスクのある組み合わせを無効化します。
常時有効（anytime-valid）な手法は何を解決しますか？
時間に対して一様なエラー制御を提供しながら、継続的なモニタリングとデータ依存の停止を可能にします。プラットフォームは依然として目標効果、検出力、ガードレール、ビジネス損失を宣言する必要があり、恣意的なメトリクスや停止理由が統計的保証にすり替わることはありません。
SRMの失敗は自動再実行をトリガーすべきですか？
まず意思決定を凍結し、生データを保持します。時間、クライアント、国、適格性、プレーンごとにスライスして原因を特定します。割り当てや計測実装が修正され、プロダクトオーナーが新しい分析ウィンドウを受け入れた後にのみ再実行します。自動再実行によって無効な実験を隠蔽してはなりません。