ab-test-setup

A/B テストの設定

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

初期評価

テストを設計する前に、次の点を把握してください。

1. テストの背景

   • 何を改善しようとしていますか？
   • どの変更を検討していますか？
   • なぜこのテストを行いたいと思ったのですか？

2. 現状

   • ベースラインのコンバージョン率はどのくらいですか？
   • 現在のトラフィック量はどのくらいですか？
   • 過去のテストデータはありますか？

3. 制約

   • 技術的な実装の複雑さはどの程度ですか？
   • スケジュールの要件はありますか？
   • 利用可能なツールは何ですか？

---

中核となる原則

1. 仮説から始める

• 「とりあえずどうなるか見てみよう」ではいけません
• 結果を具体的に予測します
• 推論またはデータに基づきます

2. 1 つのことだけをテストする

• テストごとに変数は 1 つだけにします
• そうしないと、何が効果をもたらしたのか分からなくなります
• 多変量テスト（MVT）は後の段階に取っておきます

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）
• バージョン間の変更は 1 点のみ
• 最も一般的で、分析が最も容易

A/B/n テスト

• 複数のバリアント（A 対 B 対 C…）
• より多くのトラフィックが必要
• 複数の選択肢を比較する場合に適しています

多変量テスト（MVT）

• 複数の変更を組み合わせてテストします
• 変更同士の相互作用を検証できます
• 大幅に多くのトラフィックが必要
• 分析が複雑

スプリット URL テスト

• バリアントごとに異なる URL を使用します
• ページの大幅な変更に適しています
• 実装が容易な場合があります

---

サンプルサイズの計算

必要な入力値

1. ベースラインのコンバージョン率: 現在の率
2. 最小検出効果（MDE）: 検出する価値のある最小の変化量
3. 統計的有意水準: 通常は 95%
4. 統計的検出力: 通常は 80%

クイックリファレンス

ベースライン率	10% のリフト	20% のリフト	50% のリフト
1%	バリアントあたり 15 万	バリアントあたり 3.9 万	バリアントあたり 6,000
3%	バリアントあたり 4.7 万	バリアントあたり 1.2 万	バリアントあたり 2,000
5%	バリアントあたり 2.7 万	バリアントあたり 7,000	バリアントあたり 1,200
10%	バリアントあたり 1.2 万	バリアントあたり 3,000	バリアントあたり 550

計算式の参考資料

• Evan Miller のカリキュレーター: https://www.evanmiller.org/ab-testing/sample-size.html
• Optimizely のカリキュレーター: https://www.optimizely.com/sample-size-calculator/

テスト期間

Duration = Sample size needed per variant × Number of variants
           ───────────────────────────────────────────────────
           Daily traffic to test page × Conversion rate

最短: 1〜2 回の業務サイクル（通常は 1〜2 週間） 最長: 長期間の実施は避けてください（新奇性効果や外部要因の影響があるため）

---

指標の選定

主要指標

• 最も重要な単一の指標です
• 仮説に直接結び付いている必要があります
• テストの結論を判断するために使用する指標です

補助指標

• 主要指標の解釈を補完します
• 変更がなぜ、どのように効果をもたらしたのかを説明します
• ユーザー行動の理解を助けます

ガードレール指標

• 悪化してはならない指標です
• 売上、継続率、満足度などが該当します
• 有意に大きくマイナスになった場合はテストを停止します

テストタイプ別のメトリクス例

ホームページのCTAテスト:

• プライマリ: CTAのクリック率
• セカンダリ: クリックまでの時間、スクロール深度
• ガードレール: 直帰率、後続のコンバージョン

料金ページのテスト:

• プライマリ: プラン選択率
• セカンダリ: ページの滞在時間、プランの分布
• ガードレール: サポートチケット数、返金率

サインアップフローのテスト:

• プライマリ: サインアップ完了率
• セカンダリ: フィールド単位の入力完了率、完了までの時間
• ガードレール: ユーザーのアクティベーション率（サインアップ後の品質）

---

バリアントの設計

コントロール（A）

• 現在のエクスペリエンスをそのまま使用
• テスト中は変更しない

バリアント（B+）

ベストプラクティス:

• 意味のある変更を1つだけ加える
• 効果が出るほど大胆にする
• 仮説に忠実であること

変更すべき要素:

見出し・コピー:

• メッセージの切り口
• 価値提案
• 具体性のレベル
• トーン・文体

ビジュアルデザイン:

• レイアウト構造
• 色とコントラスト
• 画像の選定
• ビジュアルの階層構造

CTA:

• ボタンの文言
• サイズ・目立ちやすさ
• 配置
• CTAの数

コンテンツ:

• 含める情報
• 情報の順序
• コンテンツの量
• 社会的証明の種類

バリアントの文書化

Control (A):
- Screenshot
- Description of current state

Variant (B):
- Screenshot or mockup
- Specific changes made
- Hypothesis for why this will win

---

トラフィックの割り当て

標準的な分割

• A/Bテストは50/50
• 複数バリアントの場合は均等に分割

保守的なロールアウト

• 最初は90/10または80/20
• 不良バリアントのリスクを抑える
• 有意差に到達するまでに時間がかかる

段階的な増加（ランピング）

• 小さく始めて時間をかけて増やす
• 技術的リスクの軽減に有効
• ほとんどのツールがサポートしている

考慮事項

• 一貫性: ユーザーが再訪時も同じバリアントを見られるようにする
• セグメントのサイズ: 各セグメントが十分な規模であることを確認する
• 時間帯・曜日: 露出のバランスを取る

---

実装アプローチ

クライアントサイドのテスト

ツール: PostHog、Optimizely、VWO、自作

仕組み:

• ページの読み込み後にJavaScriptでページを変更する
• 実装が簡単
• ちらつき（フリッカー）が発生することがある

適したケース:

• マーケティングページ
• コピーやビジュアルの変更
• 迅速な反復改善

サーバーサイドのテスト

ツール: PostHog、LaunchDarkly、Split、自作

仕組み:

• ページが描画される前にバリアントを決定する
• ちらつきが発生しない
• 開発作業が必要

適したケース:

• プロダクト機能
• 複雑な変更
• パフォーマンスが重要なページ

フィーチャーフラグ

• オン/オフの二値（真のA/Bテストではない）
• ロールアウトに適している
• パーセンテージの分割によってA/Bテストに変換できる

---

テストの実施

公開前チェックリスト

• 仮説を文書化している
• プライマリメトリクスを定義している
• サンプルサイズを算出している
• テスト期間を見積もっている
• バリアントが正しく実装されている
• トラッキングを確認している
• すべてのバリアントでQAが完了している
• ステークホルダーに周知している

テスト実施中

やるべきこと:

• 技術的な問題を監視する
• セグメントの品質を確認する
• 外部要因があれば記録する

やってはいけないこと:

• 結果を途中で覗き見て早期に停止する
• バリアントを変更する
• 新しいソースからトラフィックを追加する
• 答えが「わかっている」からといって早期に終了する

覗き見の問題（ピーキング問題）

サンプルサイズに達する前に結果を確認し、有意差が見えた時点で停止すると、次のような問題が生じます:

• 偽陽性
• 効果量の過大評価
• 誤った意思決定

対策:

• サンプルサイズを事前に決めて、それを守る
• どうしても途中確認が必要な場合は逐次検定を使う
• プロセスを信頼する

---

結果の分析

統計的有意性

• 95%の信頼水準 = p値 < 0.05
• 結果がランダムである確率が5%未満であることを意味する
• 保証ではなく、あくまで判断の目安となる閾値である

実務的有意性

統計的有意 ≠ 実務的有意

• 効果量はビジネス上意味があるか?
• 実装コストに見合うか?
• 長期的に持続するか?

確認すべき項目

1. サンプルサイズに到達しましたか？

   • 到達していない場合、結果は暫定的なものです

2. 統計的に有意ですか？

   • 信頼区間を確認する
   • p 値を確認する

3. 効果量は意味のあるものですか？

   • MDE と比較する
   • ビジネスへの影響を試算する

4. 副次的な指標は一貫していますか？

   • 主要指標を裏付けていますか？
   • 予期しない影響はありますか？

5. ガードレール指標に懸念はありますか？

   • 悪化した指標はありますか？
   • 長期的なリスクはありますか？

6. セグメントごとに差はありますか？

   • モバイルとデスクトップの違いは？
   • 新規とリピーターの違いは？
   • 流入元による違いは？

結果の解釈

結果	結論
有意な勝者	バリアントを実装する
有意な敗者	コントロールを維持し、原因を調べる
有意な差なし	より多くのトラフィックか、より大胆なテストが必要
相反するシグナル	さらに掘り下げる。セグメント分析を検討する

---

文書化と学習

テストのドキュメント

Test Name: [Name]
Test ID: [ID in testing tool]
Dates: [Start] - [End]
Owner: [Name]

Hypothesis:
[Full hypothesis statement]

Variants:
- Control: [Description + screenshot]
- Variant: [Description + screenshot]

Results:
- Sample size: [achieved vs. target]
- Primary metric: [control] vs. [variant] ([% change], [confidence])
- Secondary metrics: [summary]
- Segment insights: [notable differences]

Decision: [Winner/Loser/Inconclusive]
Action: [What we're doing]

Learnings:
[What we learned, what to test next]

学習用リポジトリの構築

• すべてのテストを一元的に管理する
• ページ、要素、結果で検索可能にする
• 失敗したテストの再実行を防ぐ
• 組織としてのナレッジを蓄積する

---

出力形式

テスト計画書

# A/B Test: [Name]

## Hypothesis
[Full hypothesis using framework]

## Test Design
- Type: A/B / A/B/n / MVT
- Duration: X weeks
- Sample size: X per variant
- Traffic allocation: 50/50

## Variants
[Control and variant descriptions with visuals]

## Metrics
- Primary: [metric and definition]
- Secondary: [list]
- Guardrails: [list]

## Implementation
- Method: Client-side / Server-side
- Tool: [Tool name]
- Dev requirements: [If any]

## Analysis Plan
- Success criteria: [What constitutes a win]
- Segment analysis: [Planned segments]

結果の要約

テストが完了したとき

推奨事項

結果に基づく次のステップ

---

よくある間違い

テスト設計

• 変更が小さすぎる（差を検出できない）
• 多くの要素を同時にテストする（原因を切り分けられない）
• 明確な仮説がない
• 対象ユーザーが不適切

実行

• 早期に停止する
• テスト途中で変更を加える
• 実装を確認しない
• トラフィックの割り当てが不均等

分析

• 信頼区間を無視する
• 都合のよいセグメントだけを取り上げる
• 結論の出ていない結果を過度に解釈する
• 実務上の有意性を考慮しない

---

確認しておきたい質問

より詳しい状況が必要な場合は、次の点を教えてください。

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

---

関連スキル

• page-cro: CRO の原則に基づくテストアイデアを生成する場合
• analytics-tracking: テストの計測を設定する場合
• copywriting: バリアントのコピーを作成する場合