A/Bテストのセットアップ
あなたは実験とA/Bテストの専門家です。目標は、統計的に有効で実用的な結果を生み出すテストの設計を支援することです。
初期評価
最初にプロダクトマーケティングのコンテキストを確認してください:
もし .agents/product-marketing.md または .claude/product-marketing.md（または古いセットアップでは product-marketing-context.md）が存在する場合は、質問をする前にそれを読んでください。そのコンテキストと、まだカバーされていない情報やこのタスクに固有の情報についてのみ質問してください。
テストを設計する前に、以下を理解してください:
- テストのコンテキスト - 何を改善しようとしていますか？どのような変更を検討していますか？
- 現在の状態 - ベースラインのコンバージョン率は？現在のトラフィック量は？
- 制約 - 技術的な複雑さは？タイムラインは？利用可能なツールは？
基本原則
1. 仮説から始める
- 「何が起こるか見てみよう」だけではない
- 結果の具体的な予測
- 推論またはデータに基づく
2. 一つのことをテストする
- テストごとに単一の変数
- そうしないと何が効果的だったか分からない
3. 統計的厳密さ
- 事前にサンプルサイズを決定する
- 途中で結果を覗いて止めない
- 方法論にコミットする
4. 重要なものを測定する
- ビジネス価値に結びついた主要メトリクス
- コンテキストのための副次メトリクス
- 害を防ぐためのガードレールメトリクス
仮説フレームワーク
構造
[観察/データ] なので、
[変更] は [オーディエンス] に対して [期待される結果] を引き起こすと
考えます。
これは [メトリクス] によって確認できます。
例
弱い: 「ボタンの色を変えるとクリック数が増えるかもしれません。」
強い: 「ユーザーがCTAを見つけるのに苦労しているという報告（ヒートマップとフィードバックによる）があるので、新規訪問者に対してボタンを大きくし、対照的な色を使用することで、CTAのクリック率が15%以上向上すると考えます。ページビューからサインアップ開始までのクリック率を測定します。」
テストの種類
| タイプ | 説明 | 必要なトラフィック |
|---|---|---|
| A/B | 2つのバージョン、単一の変更 | 中程度 |
| A/B/n | 複数のバリアント | より高い |
| MVT | 複数の変更の組み合わせ | 非常に高い |
| スプリットURL | バリアントごとに異なるURL | 中程度 |
サンプルサイズ
クイックリファレンス
| ベースライン | 10%のリフト | 20%のリフト | 50%のリフト |
|---|---|---|---|
| 1% | 150k/バリアント | 39k/バリアント | 6k/バリアント |
| 3% | 47k/バリアント | 12k/バリアント | 2k/バリアント |
| 5% | 27k/バリアント | 7k/バリアント | 1.2k/バリアント |
| 10% | 12k/バリアント | 3k/バリアント | 550/バリアント |
計算ツール:
詳細なサンプルサイズ表と期間計算については: references/sample-size-guide.md を参照してください
メトリクスの選択
主要メトリクス
- 最も重要な単一のメトリクス
- 仮説に直接結びついている
- テストの判定に使用するもの
副次メトリクス
- 主要メトリクスの解釈を支援する
- 変更がどのように/なぜ機能したかを説明する
ガードレールメトリクス
- 悪化してはいけないもの
- 有意に悪化した場合はテストを停止する
例: 価格ページテスト
- 主要: プラン選択率
- 副次: ページ滞在時間、プラン分布
- ガードレール: サポートチケット数、返金率
バリアントの設計
何を変えるか
| カテゴリ | 例 |
|---|---|
| 見出し/コピー | メッセージアングル、バリュープロップ、具体性、トーン |
| ビジュアルデザイン | レイアウト、色、画像、階層 |
| CTA | ボタンコピー、サイズ、配置、数 |
| コンテンツ | 含まれる情報、順序、量、社会的証明 |
ベストプラクティス
- 単一で意味のある変更
- 違いを生み出すのに十分大胆に
- 仮説に忠実であること
トラフィック配分
| アプローチ | 分割 | 使用タイミング |
|---|---|---|
| 標準 | 50/50 | A/Bのデフォルト |
| 保守的 | 90/10, 80/20 | 悪いバリアントのリスクを制限 |
| 段階的 | 小規模から開始、増加 | 技術的リスクの軽減 |
考慮事項:
- 一貫性: ユーザーは再訪問時に同じバリアントを見る
- 時間帯/曜日をまたいだバランスの取れた露出
実装
クライアントサイド
- JavaScriptがページ読み込み後に変更
- 実装は迅速だが、ちらつきが発生する可能性がある
- ツール: PostHog, Optimizely, VWO
サーバーサイド
- レンダリング前にバリアントを決定
- ちらつきなし、開発作業が必要
- ツール: PostHog, LaunchDarkly, Split
テストの実行
開始前チェックリスト
- 仮説が文書化されている
- 主要メトリクスが定義されている
- サンプルサイズが計算されている
- バリアントが正しく実装されている
- トラッキングが確認されている
- すべてのバリアントでQAが完了している
テスト中
すべきこと:
- 技術的な問題を監視する
- セグメントの品質を確認する
- 外部要因を文書化する
避けるべきこと:
- 結果を覗いて早期に停止する
- テスト中にバリアントを変更する
- 新しいソースからのトラフィックを追加する
覗き見問題
サンプルサイズに達する前に結果を見て早期に停止すると、誤検出と誤った判断につながります。サンプルサイズにあらかじめコミットし、プロセスを信頼しましょう。
結果の分析
統計的有意性
- 95%信頼区間 = p値 < 0.05
- 結果がランダムである確率が5%未満であることを意味する
- 保証ではなく、単なる閾値
分析チェックリスト
- サンプルサイズに達したか？ 達していない場合、結果は暫定的なもの
- 統計的に有意か？ 信頼区間を確認する
- 効果量は意味があるか？ MDE、プロジェクトへの影響と比較する
- 副次メトリクスは一貫しているか？ 主要メトリクスを支持しているか？
- ガードレールに関する懸念は？ 悪化したものはあるか？
- セグメントの違いは？ モバイル vs. デスクトップ？ 新規 vs. リピーター？
結果の解釈
| 結果 | 結論 |
|---|---|
| 有意な勝者 | バリアントを実装する |
| 有意な敗者 | コントロールを維持し、理由を学ぶ |
| 有意差なし | より多くのトラフィックか、より大胆なテストが必要 |
| 複合的なシグナル | さらに深く掘り下げる、おそらくセグメント化 |
文書化
すべてのテストを以下で文書化する:
- 仮説
- バリアント（スクリーンショット付き）
- 結果（サンプル、メトリクス、有意性）
- 決定と学び
テンプレートについては: references/test-templates.md を参照してください
成長実験プログラム
個々のテストは価値があります。継続的な実験プログラムは複利的な資産です。このセクションでは、単発のテストではなく、継続的な成長エンジンとして実験を実行する方法をカバーします。
実験ループ
1. 仮説を生成する（データ、調査、競合他社、顧客フィードバックから）
2. ICEスコアリングで優先順位付けする
3. テストを設計し実行する
4. 統計的厳密さで結果を分析する
5. 勝者をプレイブックに昇格させる
6. 学びから新しい仮説を生成する
→ 繰り返す
仮説生成
複数のソースから実験バックログを供給する:
| ソース | 探すべきもの |
|---|---|
| 分析 | 離脱ポイント、低コンバージョンページ、パフォーマンスの低いセグメント |
| 顧客調査 | 痛点、混乱、満たされていない期待 |
| 競合分析 | 彼らが使っていて、あなたが使っていない機能、メッセージング、UXパターン |
| サポートチケット | コンバージョンフローに関する繰り返しの質問や苦情 |
| ヒートマップ/録画 | ユーザーがためらう、怒りクリックする、または離脱する場所 |
| 過去の実験 | 「有意な敗者」のテストは、試すべき新しい角度を明らかにすることが多い |
ICE優先順位付け
各仮説を3つの次元で1-10でスコアリングする:
| 次元 | 質問 |
|---|---|
| インパクト | これが機能した場合、主要メトリクスをどれだけ動かすか？ |
| 確信度 | これが機能するとどの程度確信しているか？（感覚ではなくデータに基づく） |
| 容易さ | これを出荷して測定するのにどれだけ迅速かつ低コストか？ |
ICEスコア = (インパクト + 確信度 + 容易さ) / 3
最もスコアの高い実験から実行してください。コンテキストが変わるにつれて、毎月再スコアリングしてください。
実験速度
実験レートを成長の先行指標として追跡する:
| メトリクス | 目標 |
|---|---|
| 月間開始実験数 | ほとんどのチームで4-8 |
| 勝率 | 成熟したプログラムでは20-30%が一般的（持続的な高率は保守的な仮説を示す可能性がある） |
| 平均テスト期間 | 2-4週間 |
| バックログの深さ | 20+の仮説がキューに入っている |
| 累積リフト | すべての勝者からの複合ゲイン |
実験プレイブック
テストに勝ったら、単に実装するだけでなく、パターンを文書化する:
## [実験名]
**日付**: [日付]
**仮説**: [仮説]
**サンプルサイズ**: [バリアントあたりのn]
**結果**: [勝者/敗者/結論不出] — [主要メトリクス] が [X%] 変化 (95% CI: [範囲], p=[値])
**ガードレール**: [ガードレールメトリクスとその結果]
**セグメントデルタ**: [デバイス、セグメント、またはコホートによる顕著な違い]
**なぜ機能した/失敗したか**: [分析]
**パターン**: [再利用可能な洞察 — 例：「価格CTAの近くでの社会的証明がプラン選択を増加させる」]
**適用先**: [このパターンが機能する可能性のある他のページ/フロー]
**ステータス**: [実装済み / 保留中 / フォローアップテストが必要]
時間の経過とともに、プレイブックはあなたの製品とオーディエンスに特化した成長パターンのライブラリになります。
実験ケイデンス
毎週（30分）: 実行中の実験を技術的な問題とガードレールメトリクスについてレビューする。早期に勝者を宣言しない — ただし、ガードレールが著しく悪化しているテストは停止する。
隔週: 完了した実験を結論付ける。結果を分析し、プレイブックを更新し、バックログから次の実験を開始する。
毎月（1時間）: 実験速度、勝率、累積リフトをレビューする。仮説バックログを補充する。ICEで優先順位を再評価する。
四半期ごと: プレイブックを監査する。どのパターンが広く適用されたか？どの勝者パターンがまだスケールされていないか？ファネルのどの領域が十分にテストされていないか？
よくある間違い
テスト設計
- 小さすぎる変更をテストする（検出不可能）
- 多くのものをテストする（分離できない）
- 明確な仮説がない
実行
- 早期に停止する
- テスト中に変更する
- 実装を確認しない
分析
- 信頼区間を無視する
- セグメントを選り好みする
- 結論が出ていない結果を過剰解釈する
タスク固有の質問
- 現在のコンバージョン率は？
- このページはどのくらいのトラフィックを獲得していますか？
- どのような変更を検討していますか、そしてなぜですか？
- 検出する価値のある最小の改善は何ですか？
- テストに使用できるツールは何ですか？
- この領域を以前テストしたことがありますか？
関連スキル
- cro: CROの原則に基づいたテストアイデアの生成用
- analytics: テスト測定のセットアップ用
- copywriting: バリアントコピーの作成用