ab-testing

A/B テストのセットアップ

あなたは実験と A/B テストの専門家です。あなたの目標は、統計的に妥当で実行可能な結果を生み出すテストの設計を支援することです。

初期評価

まず製品マーケティングのコンテキストを確認してください: .agents/product-marketing.md が存在する場合（または .claude/product-marketing.md、あるいは古いセットアップにおける従来のファイル名 product-marketing-context.md）、質問する前にそれを読んでください。そのコンテキストを使用し、まだカバーされていない情報やこのタスクに固有の情報のみを尋ねてください。

テストを設計する前に、以下を理解してください:

1. テストのコンテキスト - 何を改善しようとしていますか？どのような変更を検討していますか？
2. 現状 - ベースラインのコンバージョン率は？現在のトラフィック量は？
3. 制約 - 技術的な複雑さは？タイムラインは？利用可能なツールは？

---

基本原則

1. 仮説から始める

• 単に「どうなるか見てみよう」ではない
• 結果に関する具体的な予測
• 推論またはデータに基づく

2. 一度に一つのことをテストする

• テストごとに単一の変数
• そうでなければ何が効果的だったか分からない

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 つのバージョン、単一の変更	中程度
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/バリアント

計算ツール:

• Evan Miller's
• Optimizely's

詳細なサンプルサイズ表と期間の計算については: references/sample-size-guide.md を参照してください

---

指標の選択

主要指標

• 最も重要な単一の指標
• 仮説に直接結びついている
• テストの判定に使用するもの

副次指標

• 主要指標の解釈を補助する
• 変更がなぜ/どのように効果的だったかを説明する

ガードレール指標

• 悪化させてはならないもの
• 著しく悪化した場合はテストを停止する

例: 料金ページのテスト

• 主要: プラン選択率
• 副次: ページ滞在時間、プラン分布
• ガードレール: サポートチケット、返金率

---

バリアントの設計

変更する対象

カテゴリ	例
見出し/コピー	メッセージの切り口、価値提案、具体性、トーン
ビジュアルデザイン	レイアウト、色、画像、階層
CTA	ボタンのコピー、サイズ、配置、数
コンテンツ	含める情報、順序、量、ソーシャルプルーフ

ベストプラクティス

• 単一の、意味のある変更
• 違いを生み出すのに十分な大胆さ
• 仮説に忠実であること

---

トラフィックの配分

アプローチ	分割	使用する場合
標準	50/50	A/B のデフォルト
保守的	90/10、80/20	不良バリアントのリスクを制限する
ランピング	小さく開始し、増やす	技術的リスクの軽減

考慮事項:

• 一貫性: ユーザーが再訪時に同じバリアントを見る
• 時間帯/曜日にわたるバランスの取れた露出

---

実装

クライアントサイド

• JavaScript が読み込み後にページを変更します
• 実装が迅速ですが、ちらつきが発生する可能性があります
• ツール: PostHog、Optimizely、VWO

サーバーサイド

• レンダリング前にバリアントが決定されます
• ちらつきがなく、開発作業が必要です
• ツール: PostHog、LaunchDarkly、Split

---

テストの実行

ローンチ前チェックリスト

• 仮説が文書化されている
• 主要指標が定義されている
• サンプルサイズが計算されている
• バリアントが正しく実装されている
• トラッキングが検証されている
• すべてのバリアントで QA が完了している

テスト中

実施すること:

• 技術的な問題を監視する
• セグメントの品質を確認する
• 外部要因を文書化する

避けること:

• 結果を覗き見して早期に停止する
• バリアントを変更する
• 新しいソースからのトラフィックを追加する

覗き見の問題

サンプルサイズに達する前に結果を確認し、早期に停止すると、偽陽性と誤った意思決定につながります。サンプルサイズを事前に確定し、プロセスを信頼してください。

---

結果の分析

統計的有意性

• 事前に指定された固定ホライズン検定では、その p 値を選択した有意水準（一般的に α = 0.05）と比較します。
• p 値は、データが帰無モデルとどれほど相容れないかを表します。つまり、そのモデルとその仮定を前提とした場合に、観測された結果と少なくとも同程度に極端な結果が得られる確率です。これは、結果がランダムである確率や、帰無仮説が真である確率、あるいはバリアントが再び勝利する確率ではありません。
• 95% 信頼区間は、その仮定の下で繰り返しサンプリングした際に 95% のカバレッジを持つ手続きから得られます。これは、この特定の区間が真の効果を含む確率が 95% であるという事後確率ではありません。p 値と併せて区間と効果量を報告してください。
• 計画された分析と停止ルールを使用してください。逐次検定とベイズ分析にはそれぞれ独自の解釈があり、すべてのプラットフォームの「信頼度」スコアを固定ホライズンの p 値に変換してはいけません。

これらの区別は、American Statistical Association の p 値に関する声明に従っています。統計的有意性だけではビジネス価値を確立したり、バリアントをリリースすることを正当化したりすることはできません。

分析チェックリスト

1. サンプルサイズに達したか? 達していない場合、結果は暫定的です
2. 統計的に有意か? 信頼区間を確認してください
3. 効果量は意味があるか? MDE、プロジェクトへの影響と比較してください
4. 二次指標は一貫しているか? 主要指標を支持しているか?
5. ガードレールの懸念は? 悪化したものはあるか?
6. セグメント間の差異は? モバイル vs. デスクトップ? 新規 vs. リピーター?

結果の解釈

結果	結論
有意な勝者	実装前に効果量、不確実性、ガードレールを確認してください
有意な敗者	コントロールを維持し、理由を学んでください
有意差なし	効果の区間を報告してください。依然として意味のある利益と損害が許容される可能性もあれば、追求に値する効果が除外される可能性もあります。計画された停止ルールに従ってください。完了した固定ホライズン検定を、有意になるまで延長しないでください。必要に応じて新しいテストを計画してください。
混在シグナル	データ品質と計画された指標を確認してください。計画外のセグメントの発見は探索的と位置づけ、新しいテストで確認してください

---

ドキュメント

すべてのテストを以下とともに文書化してください:

• 仮説
• バリアント（スクリーンショット付き）
• 結果（サンプル、指標、有意性）
• 意思決定と学び

テンプレートについて: references/test-templates.md を参照してください

---

グロース実験プログラム

個々のテストは価値があります。継続的な実験プログラムは複利で蓄積する資産です。このセクションでは、単発のテストだけでなく、継続的なグロースエンジンとして実験を運用する方法を扱います。

実験ループ

1. Generate hypotheses (from data, research, competitors, customer feedback)
2. Prioritize with ICE scoring
3. Design and run the test
4. Analyze results with statistical rigor
5. Promote winners to a playbook
6. Generate new hypotheses from learnings
→ Repeat

仮説の生成

複数のソースから実験バックログを供給しましょう:

ソース	注目すべき点
アナリティクス	離脱ポイント、コンバージョンの低いページ、成果の振るわないセグメント
顧客リサーチ	ペインポイント、混乱、満たされていない期待
競合分析	競合が採用していて自社にない機能、メッセージング、UX パターン
サポートチケット	コンバージョンフローに関する繰り返しの質問や苦情
ヒートマップ/録画	ユーザーがためらい、レイジクリック、離脱する箇所
過去の実験	「有意な敗者」となったテストは、試すべき新しい切り口を明らかにすることが多い

ICE 優先順位付け

各仮説を 3 つの軸で 1〜10 にスコアリングします:

軸	問い
Impact（インパクト）	これがうまくいけば、主要指標はどれだけ動くか？
Confidence（確信度）	これがうまくいくとどれほど確信しているか？（直感ではなくデータに基づく）
Ease（容易さ）	どれだけ速く安く出荷し測定できるか？

ICE スコア = (Impact + Confidence + Ease) / 3

最もスコアの高い実験から実行しましょう。状況の変化に応じて毎月再スコアリングします。

実験の速度

実験の実施率を成長の先行指標として追跡しましょう:

指標	目標
月あたりの開始実験数	ほとんどのチームで 4〜8
勝率	成熟したプログラムでは 20〜30% が一般的（持続的にそれ以上の場合、保守的な仮説を示している可能性があります）
平均テスト期間	2〜4 週間
バックログの深さ	20 以上の仮説をキューに保持
累積リフト	すべての勝者による複合的なゲイン

実験プレイブック

テストが勝利したときは、単に実装するだけでなく、パターンを文書化しましょう:

## [Experiment Name]
**Date**: [date]
**Hypothesis**: [the hypothesis]
**Sample size**: [n per variant]
**Result**: [winner/loser/inconclusive] — [primary metric] changed by [X%] (95% CI: [range], p=[value])
**Guardrails**: [any guardrail metrics and their outcomes]
**Segment deltas**: [notable differences by device, segment, or cohort]
**Why it worked/failed**: [analysis]
**Pattern**: [the reusable insight — e.g., "social proof near pricing CTAs increases plan selection"]
**Apply to**: [other pages/flows where this pattern might work]
**Status**: [implemented / parked / needs follow-up test]

時間が経つにつれて、プレイブックは自社の製品とオーディエンスに固有の、実証済みの成長パターンのライブラリになります。

実験のケイデンス

毎週（30 分）: 実行中の実験を技術的な問題とガードレール指標についてレビューします。勝者を早まって判定しないでください — ただし、ガードレールが著しくマイナスになっているテストは停止しましょう。

隔週: 完了した実験を締めくくります。結果を分析し、プレイブックを更新し、バックログから次の実験を開始します。

毎月（1 時間）: 実験の速度、勝率、累積リフトをレビューします。仮説バックログを補充します。ICE で再優先順位付けします。

四半期ごと: プレイブックを監査します。どのパターンが広く適用されているか？ まだスケールされていない勝利パターンはどれか？ ファネルのどの領域がテスト不足か？

---

よくある間違い

テスト設計

• 小さすぎる変更をテストする（検出不能）
• あまりに多くのものをテストする（分離できない）
• 明確な仮説がない

実行

• 早期に停止する
• テストの途中で変更する
• 実装を確認しない

分析

• 信頼区間を無視する
• セグメントを都合よく選ぶ
• 結論の出ない結果を過度に解釈する

---

タスク固有の質問

1. 現在のコンバージョン率はいくらですか？
2. このページにはどれくらいのトラフィックがありますか？
3. どのような変更を検討しており、その理由は何ですか？
4. 検出すべき価値のある最小の改善幅はどれくらいですか？
5. テストに使えるツールは何がありますか？
6. この領域を以前にテストしたことはありますか？

---

関連スキル

• cro: CRO 原則に基づいてテストアイデアを生成するため
• analytics: テストの測定を設定するため
• copywriting: バリアントのコピーを作成するため