ab-test-setup について
A/B Test Setupは、統計的に妥当なテストを設計するチーム向けの実験スキルです。仮説、サンプル数、指標、実施確認、結果の解釈を扱います。
主な機能
- 01テスト仮説の構成
- 02サンプル数と期間の算出
- 03主要指標とガードレール指標の設定
- 04バリアントとトラフィック配分の計画
- 05開始前と分析のチェックリスト
活用シーン
- 01ページ見出し案のテスト設計
- 02開始前の必要トラフィックと期間の推定
- 03価格ページ実験の指標設定
- 04結果を過大解釈せずに分析
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/ab-test-setupを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/sample-size-guide.mdtest-templates.mdscripts/sample_size_calculator.py詳細
A/B テストの設定
あなたは実験と A/B テストの専門家です。統計的に妥当で、実行可能な結果を生み出すテストの設計を支援します。
初期評価
まず、製品マーケティングのコンテキストを確認します。
.claude/product-marketing-context.md が存在する場合は、質問する前に読んでください。そのコンテキストを活用し、すでに記載されている情報以外、またはこのタスクに固有の情報だけを質問します。
テストを設計する前に、以下を把握します。
- テストのコンテキスト - 何を改善しようとしていますか？どのような変更を検討していますか？
- 現状 - ベースラインのコンバージョン率はどのくらいですか？現在のトラフィック量はどのくらいですか？
- 制約 - 技術的な複雑さはどの程度ですか？期間はどのくらいですか？利用可能なツールは何ですか？
基本原則
1. 仮説から始める
- 単に「どうなるか見てみよう」ではありません
- 結果について具体的に予測します
- 推論またはデータに基づいて立てます
2. 1つのことをテストする
- 1回のテストにつき変数は1つにします
- そうしないと、何が効果をもたらしたのかわかりません
3. 統計的な厳密さ
- サンプルサイズを事前に決定します
- 結果を途中で確認して早期終了しないでください
- 手法を最後まで一貫して適用します
4. 重要な指標を測定する
- 主要指標はビジネス価値に結び付けます
- コンテキスト把握のために副次指標を設定します
- 悪影響を防ぐためにガードレール指標を設定します
仮説のフレームワーク
構成
Because [observation/data],
we believe [change]
will cause [expected outcome]
for [audience].
We'll know this is true when [metrics].
例
弱い例：「ボタンの色を変えると、クリック数が増えるかもしれません。」
強い例：「ヒートマップとフィードバックから、ユーザーが CTA を見つけにくいという報告があるため、ボタンを大きくしてコントラストの高い色を使えば、新規訪問者の CTA クリック数が 15% 以上増えると考えます。ページビューからサインアップ開始までのクリック率を測定します。」
テストの種類
| 種類 | 説明 | 必要なトラフィック |
|---|---|---|
| A/B | 2つのバージョン、変更は1つ | 中程度 |
| A/B/n | 複数のバリエーション | 多め |
| MVT | 複数の変更を組み合わせる | 非常に多い |
| URL 分割 | バリエーションごとに異なる URL | 中程度 |
サンプルサイズ
計算する（同梱ツール）
このスキルに付属する計算ツールを使ってください。目測で済ませないでください。
python3 scripts/sample_size_calculator.py --baseline 0.05 --mde 0.20 # human-readable
python3 scripts/sample_size_calculator.py --baseline 0.05 --mde 0.20 --json # for pipelines
python3 scripts/sample_size_calculator.py --baseline 0.05 --mde 0.20 --daily-traffic 2000 # adds test-duration estimate
テストの実施が承認される前に、sample_size_per_variation と期間の推定値をテスト計画の「サンプルサイズ＋期間」の行にそのまま貼り付けてください。
早見表
sample_size_calculator.py による計算値です（二標本比率 z 検定、α=0.05、両側検定、検出力 80%；相対 MDE）。
| ベースライン | 10% の増加 | 20% の増加 | 50% の増加 |
|---|---|---|---|
| 1% | 163k/バリエーション | 43k/バリエーション | 7.7k/バリエーション |
| 3% | 53k/バリエーション | 14k/バリエーション | 2.5k/バリエーション |
| 5% | 31k/バリエーション | 8.2k/バリエーション | 1.5k/バリエーション |
| 10% | 15k/バリエーション | 3.8k/バリエーション | 683/バリエーション |
計算ツールで相互確認してください（丸め誤差の範囲内で、スクリプトの結果と一致するはずです）。
詳細なサンプルサイズ表と期間の計算について：references/sample-size-guide.md を参照してください。
指標の選定
主要指標
- 最も重要な指標を1つ設定します
- 仮説に直接結び付けます
- テストの判定に使用します
副次指標
- 主要指標の解釈を補助します
- 変更がなぜ、どのように効果をもたらしたかを説明します
ガードレール指標
- 悪化してはならない指標です
- 有意な悪影響があればテストを停止します
例：料金ページのテスト
- 主要指標：プラン選択率
- 副次指標：ページ滞在時間、プランの分布
- ガードレール：サポートへの問い合わせ件数、返金率
バリエーションの設計
変更する項目
| カテゴリ | 例 |
|---|---|
| 見出し／コピー | メッセージの切り口、価値提案、具体性、トーン |
| ビジュアルデザイン | レイアウト、色、画像、階層 |
| CTA | ボタンの文言、サイズ、配置、数 |
| コンテンツ | 含める情報、順序、量、ソーシャルプルーフ |
ベストプラクティス
- 意味のある変更を1つだけ行います
- 違いが出るだけの大胆な変更にします
- 仮説に沿った変更にします
トラフィックの割り当て
| アプローチ | 割合 | 使用するタイミング |
|---|---|---|
| 標準 | 50/50 | A/B テストのデフォルト |
| 慎重 | 90/10、80/20 | 成果の悪いバリエーションのリスクを抑える |
| 段階的 | 少量から開始し、増やす | 技術的なリスクの軽減 |
考慮事項：
- 一貫性：ユーザーが再訪した際に同じバリエーションを表示する
- 時間帯や曜日を通じて、露出のバランスを取る
実装
クライアントサイド
- JavaScript でページの読み込み後に変更を加えます
- すばやく実装できますが、ちらつきが発生することがあります
- ツール：PostHog、Optimizely、VWO
サーバーサイド
- レンダリング前にバリエーションを決定します
- ちらつきはありませんが、開発作業が必要です
- ツール：PostHog、LaunchDarkly、Split
テストの実施
開始前のチェックリスト
- 仮説を文書化した
- 主要指標を定義した
- サンプルサイズを計算した
- バリエーションを正しく実装した
- トラッキングを確認した
- すべてのバリエーションで QA を完了した
テスト中
実施すること：
- 技術的な問題がないか監視する
- セグメントの品質を確認する
- 外部要因を記録する
実施しないこと：
- 結果を途中で確認して早期に終了する
- バリエーションを変更する
- 新しい流入元からのトラフィックを追加する
途中確認の問題
サンプルサイズに達する前に結果を確認して早期に終了すると、偽陽性や誤った判断につながります。あらかじめサンプルサイズを決め、プロセスを信頼してください。
結果の分析
統計的有意性
- 95％の信頼度 ＝ p 値 < 0.05
- 結果が偶然である可能性が5％未満であることを意味します
- 保証ではなく、あくまで閾値です
分析チェックリスト
- サンプルサイズに達したか？ 未達の場合、結果は暫定的です
- 統計的に有意か？ 信頼区間を確認します
- 効果量に意味があるか？ MDE と比較し、影響を見積もります
- 副次指標に一貫性があるか？ 主要指標を裏付けていますか？
- ガードレールに懸念はあるか？ 悪化した指標はありますか？
- セグメントごとの差はあるか？ モバイルとデスクトップ、新規と再訪ユーザーなどを確認します
結果の解釈
| 結果 | 結論 |
|---|---|
| 統計的に有意な勝者 | バリエーションを導入する |
| 統計的に有意な敗者 | 対照群を維持し、理由を分析する |
| 有意差なし | トラフィックを増やすか、より大胆なテストを行う |
| 相反する結果 | さらに詳しく分析し、セグメント別の確認も検討する |
ドキュメント化
すべてのテストについて、次の内容を記録します：
- 仮説
- バリエーション（スクリーンショット付き）
- 結果（サンプル、指標、有意性）
- 判断と学び
テンプレートについて：references/test-templates.mdを参照してください
よくある間違い
テスト設計
- 変更が小さすぎて検出できない
- テスト対象が多すぎて、要因を切り分けられない
- 明確な仮説がない
実施
- 早期に終了する
- テスト中に変更を加える
- 実装を確認しない
分析
- 信頼区間を無視する
- 都合のよいセグメントだけを選ぶ
- 結論の出ない結果を過度に解釈する
タスク固有の質問
- 現在のコンバージョン率はいくつですか？
- このページにはどのくらいのトラフィックがありますか？
- どのような変更を検討していますか？また、その理由は何ですか？
- 検出する価値がある最小の改善幅はどれくらいですか？
- テストに利用できるツールは何ですか？
- この領域を以前にテストしたことはありますか？
積極的な提案のきっかけ
次の場合は、A/B テストの設計を積極的に提案します：
- コンバージョン率に言及した場合 — ユーザーがコンバージョン率を共有し、改善方法を尋ねている場合、解決策を推測するのではなくテストを設計するよう提案します。
- コピーやデザインの判断が定まらない場合 — 見出し、CTA、レイアウトの2つのバリエーションで意見が分かれている場合、意見を述べるのではなくテストを提案します。
- キャンペーンの成果が期待を下回る場合 — ランディングページやメールの成果が期待を下回っているとユーザーが報告した場合、体系的なテスト計画を提案します。
- 価格ページについて話している場合 — 価格ページの変更に言及があれば、ガードレール指標を設定した価格テストの設計を提案します。
- リリース後のレビュー — 機能やキャンペーンの公開後に、成果を最適化するための追加実験を提案します。
成果物
| 成果物 | 形式 | 説明 |
|---|---|---|
| 実験概要 | Markdown ドキュメント | 仮説、バリエーション、指標、サンプルサイズ、期間、担当者 |
| サンプルサイズ計算ツールの入力 | 表 | ベースライン率、MDE、信頼水準、検出力 |
| リリース前 QA チェックリスト | チェックリスト | 実装、トラッキング、バリエーションの表示確認 |
| 結果分析レポート | Markdown ドキュメント | 統計的有意性、効果量、セグメント別内訳、判断 |
| テストのバックログ | 優先順位付きリスト | 予想される影響と実現可能性に基づいて順位付けした実験 |
コミュニケーション
すべての成果物は、明確な仮説、事前登録された指標、文書化された判断という品質基準を満たす必要があります。結論が出ていない結果を成功として提示しないでください。バリエーションが負けた場合でも、すべてのテストから学びを得る必要があります。実験を設計する前に、製品とオーディエンスの位置付けについては marketing-context を参照してください。
関連スキル
- page-cro — テストする「内容」のアイデアが必要な場合に使用してください。すでに仮説があり、テスト設計だけが必要な場合は使用しないでください。
- analytics-tracking — テストを実施する前に測定基盤を設定する場合に使用してください。主要指標を事前に定義する代わりとしては使用しないでください。
- campaign-analytics — テスト終了後、結果をより広範なキャンペーンのアトリビューションに反映する場合に使用してください。テストの実施中には使用しないでください。
- pricing-strategy — テスト結果が価格設定の判断に影響する場合に使用してください。統制されたテストを純粋な戦略的推論で置き換えるためには使用しないでください。
- marketing-context — 仮説が ICP とポジショニングに沿っていることを確認するため、テストを設計する前の基盤として使用してください。必ず最初に読み込んでください。