ab-test-setup について
測定可能な結果を得るランダム化テストを設計する、プロダクトチーム向けの実験計画スキルです。仮説、前提条件、サンプル数、トラッキング、実施準備を確認し、結果解釈の限界も記録します。
主な機能
- 01仮説と判断基準の確定
- 02妥当性に関する前提の確認
- 03適切なテスト形式の選択
- 04指標とガードレールの定義
- 05サンプル数と期間の推定
- 06開始前のトラッキング検証
活用シーン
- 01十分なトラフィックがある製品変更の検証
- 02A/B テストと停止ルールの計画
- 03実験開始前の準備状況の確認
- 04結果と解釈上の制約の記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ sickn33/ agentic-awesome-skills --skill ab-test-setupインストール後、Claude Code で/ab-test-setupを入力して読み込まれたか確認します。
詳細
A/B テストの設定
1️⃣ 目的と範囲
特定のプロダクト上の問いに答えられる実験を定義し、ユーザーに公開する前にその前提を検証します。この手順自体が妥当性を保証するものではありません。
- 停止ルールを文書化する
- 明示した前提のもとで必要なサンプル数を推定する
- 仮説と判断基準をレビュー可能にする
2️⃣ 前提条件
以下が必要です。
- 明確なユーザーの課題
- 分析ソースへのアクセス
- おおよそのトラフィック量の推定
仮説の品質チェックリスト
妥当な仮説には以下が含まれます。
- 観察または根拠
- 単一の具体的な変更
- 方向性のある期待
- 定義された対象ユーザー
- 測定可能な成功基準
3️⃣ 仮説の確定 (ハードゲート)
バリアントや指標を設計する前に、必ず以下を行ってください。
- 最終的な仮説を提示する
- 以下を明示する
- 対象ユーザー
- 主要指標
- 期待される効果の方向性
- 最小検出可能効果 (MDE)
タスクですでに合意された仮説を使用してください。ローンチに不可欠な選択が欠けている場合は、独立した分析を続けながら、具体的な選択肢を確認のために提示してください。すでに承認された決定について、繰り返し承認を求めてはいけません。
4️⃣ 前提と妥当性の確認 (必須)
以下の項目についての前提を明示的に列挙してください。
- トラフィックの安定性
- ユーザーの独立性
- 指標の信頼性
- ランダム化の品質
- 外部要因 (季節性、キャンペーン、リリース)
前提が弱い、または満たされない場合:
- ユーザーに警告する
- テストの延期または再設計を推奨する
5️⃣ テストタイプの選択
最もシンプルな妥当なテストを選んでください。
- A/B テスト – 単一の変更、2 つのバリアント
- A/B/n テスト – 複数のバリアント、より多くのトラフィックが必要
- 多変量テスト (MVT) – 交互作用効果、非常に多くのトラフィック
- スプリット URL テスト – 大規模な構造変更
明確な理由がない限り、デフォルトは A/B です。
6️⃣ 指標の定義
主要指標 (必須)
- 成功を評価するために使用する単一の指標
- 仮説に直接結びついている
- ローンチ前に事前定義され、確定されている
副次指標
- コンテキストを提供する
- 結果が なぜ 発生したかを説明する
- 主要指標を上書きしてはいけない
ガードレール指標
- 悪化してはいけない指標
- 有害な成功を防ぐために使用する
- 有意に悪化した場合、テスト停止をトリガーする
7️⃣ サンプルサイズと期間
事前に定義してください。
- ベースライン率
- MDE
- 有意水準 alpha (多くの場合 0.05、95% 信頼度に対応)
- 統計的検出力 (通常 80%)
推定してください。
- バリアントごとに必要なサンプルサイズ
- 想定されるテスト期間
現実的なサンプルサイズの推定なしに進めないでください。
トラッキングの検証 (ゲート 8 の前に必須)
以下の実行準備ゲートに入る前に、このチェックリストを実行して「トラッキングが検証済み」を具体的な意味にしてください。
- イベントの発火: 主要指標と副次指標が依存する各イベント (サインアップ、カートへの追加、カスタムイベント) をステージングまたはデバッグページで発火させ、そのパイプラインで文書化されたレイテンシ内に到達することを確認し、観測された遅延を記録します。
- バリアントの帰属: バリアント割り当て ID が、エントリイベントだけでなく、発火したすべてのイベントに付与されていることを確認します。分析ツールの生イベントビューを使用して、バリアントごとに 5 件以上のイベントのサンプルを比較してください。
- 重複排除: ユーザーがページをリロードしてもイベントが二重カウントされないことを確認します。安定したイベント/トランザクション ID を使用し、クライアント/サーバー間の重複排除を文書化してください。バリアントラベルだけでは一意のイベントキーになりません。
- サンプルのランダム化: 設定された割り当てに対するサンプル比率の不一致を、事前に指定した統計的チェックと十分な記録を用いて確認します。100 件の記録に対する固定の ±5% の範囲は、有効な普遍的なランダム化テストではありません。割り当ての安定性、ユニットの独立性、欠落した露出記録を検査してください。
- ガードレール指標のパイプライン: §6️⃣ で定義された各ガードレール指標には、テストのローンチ時点で機能するダッシュボードまたはアラートが必要です。
上記のいずれかが失敗した場合は、停止してゲート 8 の前に解決してください。
8️⃣ 実行準備ゲート (ハードストップ)
以下のすべてが真である場合にのみ、実装に進むことができます:
- 仮説が確定している
- 主要指標が凍結されている
- サンプルサイズが計算されている
- テスト期間が定義されている
- ガードレールが設定されている
- トラッキングが検証されている
いずれかの項目が欠けている場合は、停止して解決してください。
テストの実行
テスト中
すべきこと:
- 技術的な健全性を監視する
- 外部要因を記録する
すべきでないこと:
- 「良さそうな」結果を理由に早期停止する
- テスト中にバリアントを変更する
- 新しいトラフィックソースを追加する
- 成功基準を再定義する
結果の分析
分析の規律
結果を解釈する際:
- テスト対象集団を超えて一般化しないこと
- テストした変更を超えて因果関係を主張しないこと
- ガードレールの失敗を上書きしないこと
- 統計的有意性とビジネス判断を分離すること
解釈の結果
| 結果 | アクション |
|---|---|
| 有意な正の結果 | ロールアウトを検討する |
| 有意な負の結果 | バリアントを却下し、学びを記録する |
| 結論が出ない | 不確実性を報告する; 事前に指定した継続ルールを使用するか、新しいテストを設計する |
| ガードレールの失敗 | 主要指標が勝っていても、出荷しない |
ドキュメント化と学習
テスト記録 (必須)
以下を記録します:
- 仮説
- バリアント
- 指標
- サンプルサイズと達成値
- 結果
- 意思決定
- 学び
- フォローアップのアイデア
記録は共有された検索可能な場所に保存し、同じ失敗を繰り返さないようにします。
拒否条件 (安全性)
以下の場合は続行を拒否します:
- ベースライン率が不明で、推定できない
- MDE を検出するにはトラフィックが不十分である
- 主要指標が定義されていない
- 適切な設計なしに複数の変数が変更されている
- 仮説を明確に述べることができない
理由を説明し、次のステップを推奨します。
主要原則 (譲れない)
- テストごとに1つの仮説
- 主要指標は1つ
- ローンチ前にコミットする
- 覗き見しない
- 勝つことよりも学習
- 統計的厳密性を最優先
使用する場面
製品変更に、ランダム化比較に十分な対象トラフィックと測定可能な結果がある場合に使用します。低ボリュームのローンチや定性的な探索には、因果的なリフトを主張する代わりに、ユーザビリティリサーチや記述的測定を検討してください。
サンプルサイズ計算の例
例示的な二値指標について、10% から 11% への変更 (1パーセントポイント、10% の相対リフト)、50/50 割り当て、両側アルファ 0.05、検出力 0.80 のバリアントごとのサンプルを推定します。この Python 3 の大標本近似は、Cohen の比率効果量を使用します:
from math import asin, ceil, sqrt
from statistics import NormalDist
baseline, variant = 0.10, 0.11 # illustrative assumptions, not measured data
alpha, power = 0.05, 0.80
h = abs(2 * asin(sqrt(variant)) - 2 * asin(sqrt(baseline)))
z = NormalDist()
per_variant = ceil(2 * (z.inv_cdf(1 - alpha / 2) + z.inv_cdf(power)) ** 2 / h ** 2)
print(per_variant)
期待される出力: これらの仮定では、バリアントごとに 14745 件の観測値です。
この計算は、独立した単位、1つの二値アウトカム、固定ホライズン、多重性の調整なしを前提としています。クラスター化された観測や反復観測、逐次的意思決定、連続的な売上指標には適していません。サンプル推定をカレンダー期間に変換する前に、対象トラフィック、離脱、アウトカムの遅延、サンプリング単位を考慮してください。想定される比率が等しい場合、効果量はゼロであり、その差を検出するための有限のサンプルは存在しません。
実例
Observation: users abandon a long signup form.
Change: remove one optional field; unit: account; allocation: 50/50 and stable.
Primary metric: completed signup / eligible assigned accounts within 24 hours.
Guardrails: validation failures and support requests.
Before launch: estimate sample needs from baseline and MDE, verify exposure and
completion IDs, define analysis window and stopping rule.
Expected report: counts, absolute/relative effect, interval, data-quality checks,
guardrail results and a decision with its limits; never just “p < 0.05, ship”.
制限事項
- クラスター化されたユーザー、スピルオーバー、反復観測は、独立サンプルの計算を無効にする可能性があります。
- 逐次モニタリングには計画された逐次手法が必要です; 固定ホライズンの有意性は、繰り返しの覗き見を許可しません。
- トラッキングのギャップやサンプル比率の不一致は、主要指標が良好であっても推論を無効にする可能性があります。
- このスキルは、フラグの有効化、バリアントの公開、規制遵守の確立を自動的に行いません。