A/Bテストの設計とツール選び：GrowthBook / Optimizely / Statsig / PostHog 比較

EP.16 で 「仮説 → 施策 → 計測 → 学習」 のサイクルを扱いました。計測 の決定版が A/Bテスト（A/B Testing）。ユーザーをランダムに2群に分け、因果関係を統計的に確かめる唯一の実用手法です。本記事では ツール選定 と 設計時の落とし穴 を整理します。

なぜ A/Bテストが「唯一の」因果検証手法なのか

Pre/Post 比較や コホート 分析は便利ですが、「同時に起きた他の要因」を排除できません。例: 「プッシュ通知を強化したら DAU（Daily Active Users） が +10%」── 同じ週にテレビ CM を打っていたかも。A/Bテストはランダム割付で施策以外の影響を平均化するため、観測された差はほぼ施策の効果と言える。

1. ツール比較：SaaS（Software as a Service） / OSS（Open Source Software） / 自前

2. 選定の判断基準

• 実験頻度：月10件未満なら自前 / GrowthBook OSS、月50件超なら有償 SaaS（運用効率）
• 実験対象：Web の見た目変更（Visual Editor 必要）→ Optimizely / VWO、機能フラグでバックエンド切替→ GrowthBook / Statsig
• 統計エンジンの好み：Bayesian 派なら GrowthBook / Statsig、Frequentist 派なら Optimizely
• データの所在：自社 DWH 主体なら GrowthBook（DWH 直接接続可）、SaaS 完結なら Optimizely / Statsig
• 価格感：「年数百万円は出せない」なら OSS（GrowthBook / PostHog）

3. A/Bテストの設計：6つの決め事

ツールを選ぶ前に、設計を確定するのが先です。設計が甘いとどのツールでも結果は信用できません。

(1) 仮説（EP.16 の If/Then/Because）

「If CTA を「カートに追加」から「今すぐ買う」に変えると、Then 購入率が +1.5pt 改善する。Because 「買う」の方が次のアクションが明確だから」

(2) Target / Guardrail / Learning メトリクス

(3) サンプルサイズ計算

「何人テストすれば +1.5pt の差を 95% 信頼で検出できるか」を事前に計算します。実装前にやらないと 有意差が出ない無駄な実験になります。

from statsmodels.stats.power import NormalIndPowerfrom statsmodels.stats.proportion import proportion_effectsize
# A 群の購入率: 5% → B 群: 6.5% を検出したいp1, p2 = 0.05, 0.065effect_size = proportion_effectsize(p1, p2)
n = NormalIndPower().solve_power(    effect_size=effect_size,    alpha=0.05,    # 第一種の過誤    power=0.80,    # 第二種の過誤を 20% 以下に    ratio=1.0,     # 50:50 割付)print(f"必要サンプル数: 各群 {int(n):,} 人 (合計 {int(n*2):,} 人)")# 出力例: 必要サンプル数: 各群 3,219 人 (合計 6,438 人)

(4) 実行期間

最低 1 週間は回す（曜日依存を均す）。月初・月末イベント や 季節キャンペーン がある業種は 2 週間以上が安全。サンプル数が早く揃っても ピーキング（早期確認）はしない。

(5) 割付ロジック

user_id のハッシュを 0〜99 の数字に落とし、0〜49 → A 群、50〜99 → B 群 が定番。user_id ベースで割付すれば、同じユーザーが毎回同じ群に入る（PC/スマホ移行も同じ）。セッション単位の割付は危険（同じユーザーが日によって違う体験）。

import hashlib
def assign_variant(user_id: str, experiment_id: str, salt: str = "v1") -> str:    """0〜99 の数字を出して 0〜49 を A、50〜99 を B"""    key = f"{experiment_id}:{user_id}:{salt}".encode()    hashed = hashlib.md5(key).hexdigest()    bucket = int(hashed[:8], 16) % 100    return "A" if bucket < 50 else "B"

(6) ログ設計（EP.10/11 と接続）

全イベントログに `experiment_id`, `variant` を含める。後で GROUP BY variant で集計できるようにしておく。

4. 4 大落とし穴

(1) ピーキング（早期確認）の罠

「3日目にチェックしたら有意差が出てたから打ち切り」── これは false positive 量産機。毎日チェックしながら有意差が出た瞬間に止める と、本来 5% のはずの誤判定率が 30% 超まで膨れ上がる（Sequential testing 問題）。

(2) SRM（Sample Ratio Mismatch）（Sample Ratio Mismatch）

50:50 で割付したのに、実際は 47:53 になっていた というズレ。bot 排除、Cookie 失効、トラッキング欠損などが原因。SRM があるとそのテストは原則 invalid。毎回最初にカイ二乗検定で確認する。

from scipy import stats
a_count, b_count = 4750, 5250  # 観測値expected = (a_count + b_count) / 2chi2, p = stats.chisquare([a_count, b_count], [expected, expected])print(f"chi2 = {chi2:.2f}, p = {p:.4f}")if p < 0.001:    print("⚠️ SRM の疑い - 結果は信用しない")

(3) 多重検定

指標を 20 個比較したら、運だけで 1 つは「有意差あり」 が出ます（5% × 20 = 1）。Bonferroni 補正 や FDR（False Discovery Rate, Benjamini-Hochberg）で補正するか、最初から Target 1 つに絞るのが王道。

(4) Novelty / Primacy 効果

新しい UI は最初は新鮮で使われる（Novelty）が、慣れると効果が消える。逆に 既存ユーザーは変化を嫌う（Primacy）ため、最初は B 案が悪く見える。最低 2 週間以上の長期テストで見極める必要あり。

5. ツール選定の決定木

• 月50件以上の実験 + 予算あり → Optimizely / Statsig（運用効率最大化）
• OSS 派 + 自社 DWH 連携 → GrowthBook（自社 BigQuery / Snowflake と直接連携）
• 全部入りスタートアップ → PostHog（Analytics + A/B + FF + Session Replay）
• Feature Flag 主体で実験はオマケ → LaunchDarkly
• 実験頻度が低い + データチームが強い → 自前実装（Random割付 + 自社 DWH 集計）

次回予告

EP.18 では実際に Python で A/B テストを動かします。シミュレーションデータで仮説検定（t検定 / χ² 検定 / Mann-Whitney）からベイジアン A/B テスト A/Bまで、可視化込みで一気通貫。