ab-test-setup

A/B テストの設定 - 実験の設計と分析

カテゴリ： プロダクトチーム タグ： A/B テスト、実験、統計的有意性、サンプルサイズ、フィーチャーフラグ、仮説検定

概要

A/B テストの設定では、統計的に妥当で、実用的な結果を得るための実験設計のフレームワークを提供します。A/B テストの多くが失敗するのは、バリアントが間違っていたからではなく、サンプルサイズや指標が適切でなかったり、誰かが結果を途中で確認して早期に終了したりと、テストの設計が不十分だったためです。このスキルは、そうしたミスを防ぎます。

---

最初に確認すること

実験を設計する前に、次の入力を確認してください。不明または曖昧な項目があれば、推測せずに質問してください。

• 主要指標と最小検出効果 — 成功を測る唯一の指標と、検出する価値のある最小の改善幅です（サンプルサイズ、期間、指標の選定に影響します）
• ベースラインのコンバージョン率 — 主要指標の現在の率です（バリアントごとに必要なサンプルサイズを決定します）
• テスト対象面で利用できるトラフィック — 1 日あたりの対象訪問者数です（テストが実施可能か、より大胆な変更や定性的な手法が必要かを判断します）
• 変更内容とその根拠 — 何を変更するのか、またその根拠となるデータです（仮説とバリアントの設計に影響します）

質問のルール：出力に最も大きな影響を与える 2～3 項目だけを質問してください。ユーザーが「とにかく草案を作って」と言った場合は、そのまま進め、成果物の冒頭に前提を記載してください。

実験のライフサイクル

1. HYPOTHESIZE  →  2. DESIGN  →  3. CALCULATE  →  4. IMPLEMENT
       ↑                                                    │
       │                                                    ▼
7. ITERATE  ←  6. DOCUMENT  ←  5. ANALYZE  ←  [Run to completion]

---

ステップ 1：仮説の立案

仮説のテンプレート

Because [observation or data point],
we believe [specific change]
will cause [measurable outcome]
for [defined audience segment].

We'll know this is true when [primary metric] changes by [minimum detectable effect].
We'll watch [guardrail metrics] to ensure no negative impact.

良い仮説と悪い仮説

品質	仮説	問題点
悪い	「ボタンの色を変えるとクリック数が増えるかもしれません」	データに基づく根拠がなく、対象も測定計画もありません
まずまず	「緑色のボタンは青色よりクリック数が増えます」	「なぜ」がなく、目標値やガードレールもありません
良い	「ヒートマップによると、ユーザーの 40% が CTA に気付いていないため、ボタンを 2 倍の大きさにして背景色とのコントラストを高めることで、新規訪問者の CTA クリック数が 15% 以上増加します。ガードレール：ページの読み込み時間を 2 秒未満に保ちます。」	データに基づいており、変更内容が具体的で、成果を測定でき、対象ユーザーとガードレールが定義されています

仮説の情報源（テストのアイデアを見つける場所）

情報源	確認する内容	例
アナリティクスデータ	離脱ポイント、成果の低いページ	「オンボーディングのステップ 3 で、ユーザーの 80% が離脱しています」
ユーザー調査	混乱、不満、満たされていないニーズ	「ユーザーはホームページを見ても、製品が何をするものか理解できていません」
ヒートマップ／セッション録画	無視される要素、連打クリック	「料金ページでファーストビューより下までスクロールする人はいません」
サポートチケット	繰り返し寄せられる不満、機能に関する混乱	「ユーザーから、チームメンバーの招待方法について何度も質問されます」
競合分析	同じ課題に対する異なるアプローチ	「競合はウィザードを使っていますが、当社はフォームを使っています」
営業時の異議	見込み客がコンバージョンに至らない一般的な理由	「見込み客は登録前に料金を確認したがっています」

---

ステップ 2：テストの設計

テストの種類

種類	バリアント	必要なトラフィック	最適な用途
A/B	2（コントロール＋1 バリアント）	中程度	単一の変更の検証
A/B/n	3 以上のバリアント	多い	複数のアプローチの比較
多変量テスト（MVT）	変更の組み合わせ	非常に多い	複数の要素の最適化
URL 分割テスト	異なるページ	中程度	大規模なリデザイン
バンディット	動的な割り当て	少～中程度	収益の最適化

デフォルトの推奨： 標準的な A/B テストを使用してください。十分なトラフィックがあり、具体的な必要性がある場合に限り、A/B/n または MVT を使用してください。

何をテストするか（影響度別）

カテゴリ	影響度：高	影響度：中	影響度：低
コピー	見出し／価値提案、CTA テキスト	本文、ソーシャルプルーフ	マイクロコピー、ラベル
デザイン	ページレイアウト、ファーストビューのコンテンツ	視覚的な階層、画像	色、フォントサイズ
UX	ステップ数、フォーム項目	ボタンの配置、ナビゲーション	アニメーション、トランジション
価格設定	価格、プラン名	機能のパッケージ化、アンカリング	請求頻度の表示
ソーシャルプルーフ	お客様の声の有無、ロゴ	お客様の声の形式、配置	お客様の声の数

指標の選定

すべてのテストで、次の3種類の指標が必要です。

主要指標（1つのみ）

• 成功を判定する単一の指標です
• 仮説に直接結び付いている必要があります
• テスト期間内に測定できる必要があります
• 例：登録率、クリック率、購入率

副次指標（2～3つ）

• 主要指標が変化した理由を説明します
• 意思決定のための背景情報を提供します
• 例：ページ滞在時間、スクロール深度、機能の利用率

ガードレール指標（1～3つ）

• 悪化してはならない指標です
• 大幅に悪化した場合はテストを中止します
• 例：エラー率、サポートチケット数、ページ読み込み時間、返金率

---

ステップ 3：サンプルサイズの算出

クイックリファレンス表

各バリアントに必要な最小訪問者数（信頼度95％、検出力80％）：

ベースライン率	向上率5％	向上率10％	向上率15％	向上率20％	向上率50％
1%	620,000	156,000	70,000	39,000	6,400
2%	305,000	77,000	34,000	19,500	3,200
3%	200,000	51,000	23,000	12,800	2,100
5%	116,000	29,500	13,200	7,500	1,250
10%	54,000	13,800	6,200	3,500	600
20%	24,000	6,200	2,800	1,600	280
50%	6,100	1,600	720	410	75

期間の算出

Duration (days) = (Sample size per variant * Number of variants) / Daily traffic to test page

最短期間： 曜日による影響を捉えるため、7日間 推奨される最長期間： 6週間（これを超えると、外部要因によって結果が左右されます）

トラフィックが足りない場合

状況	解決策
10万人の訪問者が必要だが、週に5,000人しか来ない	最小検出可能効果を大きくする（より大胆な変更をテストする）
トラフィックが非常に少ない（週1,000人未満）	代わりに定性的なテスト（ユーザーテスト、アンケート）を実施する
トラフィックが中程度（週5,000～20,000人）	4～6週間実施し、大きな変更だけをテストする
トラフィックが多い（週50,000人以上）	小さな変更もテストでき、複数のテストを実施できます

---

ステップ 4：実装

クライアントサイドでの実装

JavaScript で初回レンダリング後にページを変更します。

メリット： すばやく実装でき、デプロイは不要です デメリット： ちらつき（元のコンテンツが一瞬表示されること）が発生する場合があり、広告ブロッカーに阻止されます ツール： PostHog、Optimizely、VWO、Google Optimize

ちらつき防止パターン：

// Add to <head> before any rendering
<style>.ab-test-hide { opacity: 0 !important; }</style>
<script>document.documentElement.classList.add('ab-test-hide');</script>

// In your test script (runs after variant assignment):
document.documentElement.classList.remove('ab-test-hide');

サーバーサイドでの実装

ページのレンダリング前にバリアントを決定します。ちらつきがなく、クライアントサイドへの依存もありません。

メリット： ちらつきがなく、広告ブロッカーに阻止されず、ログイン済みユーザー向けの機能にも対応します デメリット： エンジニアリング作業が必要で、デプロイも必要です ツール： PostHog、LaunchDarkly、Split、Unleash、カスタム機能フラグ

基本的な機能フラグパターン：

# Server-side variant assignment
def get_variant(user_id: str, experiment: str) -> str:
    # Deterministic hash ensures same user always sees same variant
    hash_input = f"{user_id}:{experiment}"
    hash_value = hashlib.md5(hash_input.encode()).hexdigest()
    bucket = int(hash_value[:8], 16) % 100

    if bucket < 50:
        return "control"
    else:
        return "variant"

トラフィックの割り当て

戦略	割合	使用するタイミング
標準	50/50	デフォルト。統計的検出力を最大化できます。
保守的	90/10 または 80/20	リスクの高い変更、収益に影響するテスト
段階的	95/5 から開始し、50/50 まで引き上げる	新しいインフラストラクチャ、技術的リスク

重要なルール：

• ユーザーには訪問のたびに同じバリアントを表示する必要があります（ユーザー ID または Cookie による固定割り当て）
• 割り当ては、時間帯と曜日を通じて均等にする必要があります
• テストの途中で割り当てを変更してはいけません

---

ステップ 5：テストの実施

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

• 仮説が、主要指標と最小検出可能効果とともに文書化されている
• サンプルサイズを算出し、予想期間を見積もっている
• 両方のバリアントを実装し、すべてのデバイスタイプで QA を実施している
• トラッキングを確認している（両方のバリアントでイベントが正しく発火する）
• 同じページ／機能でほかのテストが実施されていない
• テスト期間と「結果を先読みしない」ルールを関係者に伝えている
• 外部要因のカレンダーを確認している（大規模なローンチ、祝日、プレスリリースがない）

テスト中

実施すること：

• 技術的なエラーを監視する（バリアントが表示されない、トラッキングが機能しないなど）
• 毎日、トラフィックの分割が均等であることを確認する
• 結果に影響する可能性のある外部イベントを記録する

実施しないこと：

• サンプルサイズに達する前に結果を見る（「先読み問題」）
• どちらかのバリアントに変更を加える
• テストの途中で新しい流入元からのトラフィックを追加する
• 一方のバリアントが「勝っているように見える」からといってテストを早期終了する

先読み問題（重要）

計画したサンプルサイズに達する前に結果を見て、一方のバリアントのほうが良さそうだという理由でテストを終了すると、**偽陽性率が25～40％**になります（本来意図した5％に対して）。

理由：サンプルサイズが小さいと、統計的有意性は大きく変動します。計画したサンプルサイズの20％時点では、あるバリアントの p 値が 0.05 未満でも、サンプルサイズ全体では 0.30 を超えることがあります。

解決策：

1. サンプルサイズを事前に確定し、そこに達するまで結果を確認しない
2. 監視が必要な場合は、逐次検定法（群逐次デザイン、常に有効な p 値）を使用する
3. 予想完了日にカレンダーのリマインダーを設定し、その日に結果を確認する

---

ステップ 6：分析

分析チェックリスト

1. 計画したサンプルサイズに達しましたか？ 達していない場合、結果はまだ暫定的です。
2. 統計的に有意ですか？ p < 0.05 は、差が実在する確信度が95％であることを意味します。
3. 信頼区間はどのくらいですか？ 真の効果としてあり得る範囲がわかります。
4. 効果量に意味はありますか？ 「有意」な0.1％の向上でも、実装する価値がない場合があります。
5. 副次指標にも一貫性がありますか？ 主要な結果を裏付けていますか？
6. ガードレール指標に違反していませんか？ 何か悪化しましたか？
7. セグメント分析： モバイルとデスクトップで結果に違いはありますか？ 新規ユーザーとリピーターではどうですか？

結果の解釈

結果	主要指標	信頼度	対応
明確な勝者	バリアント +15%、p < 0.01	高	バリアントを実装する
小幅な勝者	バリアント +5%、p < 0.05	中	容易に実装できる場合は実装し、そうでなければテストを延長する
差なし	差が2％未満、p > 0.20	高（効果なし）	コントロールを維持し、より大胆な案をテストする
敗者	バリアント -10%、p < 0.05	高	コントロールを維持し、理由を調査する
結論が出ない	差が5％、p = 0.08	低	トラフィックを増やすか、より大胆なテストが必要
相反する結果	主要指標は上昇、ガードレール指標は低下	要調査	セグメントを詳しく調べ、結果を盲目的にリリースしない

よくある分析ミス

ミス	結果	防止策
初めて有意になった時点で終了する	偽陽性率が25～40％	サンプルサイズを事前に確定する
都合のよいセグメントだけを選ぶ	再現しない「勝者」を見つけてしまう	関心のあるセグメントを事前登録する
信頼区間を無視する	効果量を過大評価する	p 値とともに必ず信頼区間を報告する
多重比較	第I種の過誤が増加する	A/B/n テストにはボンフェローニ補正を適用する
生存者バイアス	フローを完了したユーザーだけを分析する	割り当て時点からのすべてのユーザーを含める
シンプソンのパラドックス	集計値によってセグメントごとの逆転が隠れる	主要なセグメントを必ず確認する

---

ステップ 7：文書化

結果にかかわらず、すべてのテストを文書化する必要があります。

テスト文書テンプレート

EXPERIMENT: [Name]
DATE: [Start] to [End]
OWNER: [Name]

HYPOTHESIS:
Because [observation], we believed [change] would cause [outcome] for [audience].

VARIANTS:
- Control: [description]
- Variant: [description + screenshot]

METRICS:
- Primary: [metric] (baseline: [X]%, MDE: [Y]%)
- Secondary: [metrics]
- Guardrails: [metrics]

RESULTS:
- Sample size: [actual] / [planned]
- Duration: [X] days
- Primary metric: Control [X]% vs Variant [Y]% (p = [Z], CI: [range])
- Secondary metrics: [results]
- Guardrails: [all clear / violation noted]

DECISION: [Ship variant / Keep control / Iterate]

LEARNINGS:
- [What we learned about our users]
- [What we'd do differently next time]

---

実験の優先順位付けフレームワーク

ICE スコアリング

要素	スコア（1-10）	質問
インパクト	指標にどれほど影響しますか？	主要 KPI を大きく変える = 10
確信度	うまくいくとどれほど確信していますか？	仮説を裏付ける強力なデータがある = 10
容易さ	実装と測定はどれほど簡単ですか？	1 日でリリースできる = 10

ICE スコア =（インパクト + 確信度 + 容易さ）/ 3

すべてのテスト案を ICE スコア順に並べます。最も高いものから実施します。

テストバックログのテンプレート

#	仮説	主要指標	ICE	推定期間	ステータス
1	CTA を大きくすると登録が増える	登録率	8.3	2 週間	準備完了
2	料金ページにソーシャルプルーフを掲載するとコンバージョンが増える	プラン選択率	7.0	3 週間	デザインが必要
3	オンボーディングを短縮するとアクティベーションが増える	機能のアクティベーション	6.7	4 週間	バックログ内

---

プロアクティブなトリガー

• 2 つのデザイン案で意見が分かれている場合：意見を述べるのではなく、A/B テストを提案します
• コンバージョン率の低迷について言及された場合：解決策を推測するのではなく、テストの設計を提案します
• 料金ページの変更が話題になった場合：必ずガードレール指標を設定して料金変更をテストします
• 機能のリリース後：最適化のためのフォローアップ実験を提案します
• 「とりあえず試してみましょう」と言われた場合：実装前に、構造化された仮説を立てるよう促します

---

関連スキル

スキル	使用する場面
analytics-tracking	実験指標に利用するイベントトラッキングを設定するとき
campaign-analytics	実験結果をより広範なアトリビューションに反映するとき
launch-strategy	製品ローンチの一連の流れの中でテストするとき
prompt-engineer-toolkit	本番環境で AI プロンプトを A/B テストするとき

---

ツールリファレンス

sample_size_calculator.py

2 比率 z 検定の正規近似を使用して、各バリアントに必要なサンプルサイズを計算します。複数バリアントのテストに対するボンフェローニ補正と期間の推定も含みます。

フラグ	型	デフォルト	説明
--baseline, -b	float	(required)	ベースラインコンバージョン率（例：5% の場合は 0.05）
--mde, -m	float	(required)	相対的な増加率としての最小検出可能効果（例：10% の場合は 0.10）
--alpha, -a	float	0.05	有意水準
--power, -p	float	0.80	検出力
--variants, -v	int	2	コントロールを含むバリアント数
--daily-traffic, -d	int	0	期間推定に使用する、1 日あたりの対象トラフィック
--one-tailed	flag	False	両側検定ではなく片側検定を使用します
--json	flag	False	JSON 形式で出力します

python scripts/sample_size_calculator.py --baseline 0.05 --mde 0.10
python scripts/sample_size_calculator.py --baseline 0.12 --mde 0.15 --power 0.9 --daily-traffic 5000
python scripts/sample_size_calculator.py --baseline 0.05 --mde 0.10 --variants 3 --json

experiment_analyzer.py

信頼区間とセグメント別の内訳を含む、2 比率 z 検定を使用して A/B テストの結果を分析します。

フラグ	型	デフォルト	説明
input	positional	(required)	結果を含む CSV ファイル、またはサンプルを作成する場合は "sample"
--alpha, -a	float	0.05	有意水準
--json	flag	False	JSON 形式で出力します

CSV 形式： variant,visitors,conversions,segment

python scripts/experiment_analyzer.py sample
python scripts/experiment_analyzer.py results.csv
python scripts/experiment_analyzer.py results.csv --alpha 0.01 --json

experiment_planner.py

仮説テキストから、指標の選定、サンプルサイズ、タイムライン、リスク、ドキュメントのテンプレートを含む、構造化された実験計画を生成します。

フラグ	型	デフォルト	説明
--hypothesis, -H	string	(required)	実験の仮説テキスト
--baseline, -b	float	0.05	ベースラインコンバージョン率
--mde, -m	float	0.10	相対的な増加率としての最小検出可能効果
--daily-traffic, -d	int	0	1 日あたりの対象トラフィック
--variants, -v	int	2	コントロールを含むバリアント数
--json	flag	False	JSON 形式で出力します

python scripts/experiment_planner.py --hypothesis "Larger CTA will increase signups by 15%"
python scripts/experiment_planner.py -H "Simplified checkout boosts conversions" -b 0.08 -m 0.15 -d 3000
python scripts/experiment_planner.py -H "New pricing page" --json

---

トラブルシューティング

問題	原因	解決策
サンプルサイズが現実的でないほど大きい	MDE が小さすぎる、またはベースラインが低すぎる	MDE を大きくする（より大胆な変更をテストする）か、トラフィックの多いページを対象にします
テスト期間が 6 週間を超える	1 日あたりのトラフィックが不十分	定性的な手法を検討する、より大きな変更をテストする、または複数のページのトラフィックをまとめます
p 値が 0.05 前後で推移する	有意性の境界付近にある	早期に終了せず、計画したサンプルサイズに達するまで実施するか、期間を 20% 延長します
結果は有意だが、リフトがごくわずか（<1%）	検定の検出力が過剰	統計的有意性だけでなく、実務的有意性も確認します
セグメントごとの結果が全体の結果と矛盾する	シンプソンのパラドックス	セグメントの構成を調査し、全体とセグメントの両方の結果を報告します
モバイルとデスクトップでバリエーションの成果が異なる	デバイス固有の UX の問題	デバイスごとのバリエーションを設計し、セグメントごとのサンプルサイズを増やします
計算ツールが負の CI を出力する	サンプルが非常に少ない、または率が極端	十分なサンプルサイズを確保し、データの整合性を確認します

---

成功基準

基準	目標	測定方法
テストが計画したサンプルサイズに達する	テストの 100%	終了時に実際のサンプル数と計画したサンプル数を比較します
偽陽性率	<5%	実装後のリフトをテスト時の予測と比較して追跡します
テスト実施速度	チームあたり月 2 件以上のテスト	スプリントごとに記録された実験の数を数えます
ドキュメントの完全性	テストの 100% を文書化	四半期ごとに実験記録を監査します
平均テスト期間	<4 週間	開始から終了までの暦日数を測定します
意思決定の質	リリースしたバリエーションの 80% 超が 90 日後も効果を維持	リリース後に指標を追跡します

---

対象範囲と制限事項

対象範囲：

• 仮説の策定と検証
• サンプルサイズと検定力の計算
• 頻度論に基づく 2 標本比率の z 検定
• A/B、A/B/n、および URL 分割テストの計画
• セグメントレベルの分析
• テスト前後のドキュメント作成

対象範囲外：

• ベイズ A/B テスト手法（専用のベイズツールを使用してください）
• 多腕バンディットアルゴリズム（リアルタイムの割り当てインフラが必要です）
• 多変量テスト（MVT）分析（組み合わせの爆発的増加に対応するには、専用ツールが必要です）
• サーバーサイドのフィーチャーフラグ実装（エンジニアリングスキルを参照してください）
• トランザクションレベルのデータが必要な収益ベースの指標
• シーケンシャルテスト／常に有効な p 値（Optimizely Stats Engine などを使用してください）

---

統合ポイント

ツール／プラットフォーム	統合方法	ユースケース
PostHog / Amplitude	experiment_analyzer から JSON をエクスポート	結果をプロダクト分析に取り込みます
Jira / Linear	experiment_planner の JSON 出力	メタデータ付きの実験チケットを作成します
Google Sheets	experiment_analyzer から CSV をエクスポート	技術者以外の関係者と結果を共有します
LaunchDarkly / Unleash	experiment_planner のチェックリスト	フィーチャーフラグのロールアウト前に検証します
Slack / Notion	人が読める形式の出力をコピー	非同期で実験状況を更新します
CI/CD パイプライン	すべてのスクリプトで --json フラグを使用	実験の健全性を自動的に確認します