TL;DR
- A/Bテストはツール導入だけでは回らない。実験基盤 / 統計設計 / 意思決定 の3層を連結することで意思決定の質が上がる
- Microsoft ExP は年間 25,000+ 実験、Booking.com は毎日 1,000+ 並列実験を実行する規模。両社の共通点は「実験を組織文化に組み込んでいる」こと
- 統計設計の盲点：MDE（最小検出効果）を事前に決めずに開始する → 結果が読めない実験を量産
- 意思決定プロセス：実験結果 → judgement → ship/kill/iterate を必ず24時間以内に明示
- エンジニア組織で回す肝は「実験プラットフォーム自体を Platform チームが運用する」こと
この記事の目的と成功基準
- 目的: A/Bテストをエンジニア組織で持続的に回す設計を3層モデルで言語化する
- 想定読者: Platform / Growth / Product チームのエンジニア・PM、実験文化を立ち上げる EM
- 成功基準: 「A/Bテスト 組織」「Experimentation Platform」関連クエリでの流入、Platform Engineering 予算2026 への回遊
なぜ「ツール導入だけでは回らない」のか
Optimizely や VWO、自前 Feature Flag を入れただけで A/B テスト文化が回るチームは稀。多くの組織で同じ詰まりが起きる：
- 実験は始まるが結果の解釈で詰まる（統計）
- 統計的に有意でも「で、何をするか」が決まらない（意思決定）
- 結果が組織に共有されず、同じ実験が別チームで再実行される（プロセス）
Microsoft Experimentation Platform や Booking.com の論文系発信で繰り返し強調されているのは「実験基盤 / 統計設計 / 意思決定プロセスの3層を 同時に整える」こと。
3層モデル
1. 実験基盤（Experimentation Platform）
技術レイヤー。Feature Flag、ユーザーバケッティング、メトリクス計測。
最低要件：
- 決定的バケッティング: 同じユーザーは常に同じ variant に振られる
- メトリクスの自動計測: ガード指標（健全性）と primary 指標を分離
- 複数実験の並列実行: 直交設計で干渉を排除
- rollout / rollback の即時性: 異常検知後の rollback が1分以内
詳細は Feature Flag 運用2026（後続記事）で扱う。
2. 統計設計
科学レイヤー。サンプルサイズ・MDE・有意水準。
事前決定する項目：
- MDE（Minimum Detectable Effect）: 検出したい最小効果サイズ（例：CTR 1% 改善）
- サンプルサイズ: MDE と分散から必要トラフィック量を逆算
- 有意水準 α: 通常 0.05、重要な意思決定なら 0.01
- 検出力 1-β: 通常 0.8
これらを 実験開始前に 明示する。後から決めると確証バイアスに支配される。
落とし穴：
- peeking（途中で結果を見て止める）: false positive 率が膨らむ。固定期間を守る
- 多重比較: 10指標見て1つ有意なら α=0.4 になる、Bonferroni 等で補正
- A/A テスト未実施: 基盤の偏りを検出するため、定期的に同一処置の比較を回す
3. 意思決定プロセス
組織レイヤー。実験結果から行動を決めるフロー。
標準フロー：
実験完了
↓
24h 以内: 統計結果のレビュー会
↓ judgement
- ship（有意 + ガード指標問題なし）
- kill（負の効果 or ガード指標悪化）
- iterate（borderline or 仮説修正）
↓
48h 以内: 全社共有（成功・失敗どちらも）
肝：
- kill も成果: 「やめる判断」を組織で称える文化
- iterate を惜しまない: 1回の実験で結論を出そうとしない
- 共有を強制: Slack channel or 月次レビューで結果を出す
Booking.com の発信 では、年間1000+ 実験のうち kill が圧倒的多数（70%+）で、それが健全としている。
Microsoft ExP の規模感
Microsoft ExP の公開情報：
- 年間 25,000+ 実験
- 数千人のエンジニアが利用
- 自社プロダクト全体に展開（Bing / Office / Edge / Azure）
この規模を支えるのは：
- 中央集権的な実験基盤（ExP）
- 統一の統計エンジン
- 実験結果ダッシュボード
- 専任データサイエンスチームのコンサル機能
中小規模で同じ規模は不要だが「Platform チームが実験基盤を運用する」構造は参考になる。
エンジニア組織で回す3つのパターン
パターン A: 集中型（推奨：中〜大規模）
- Platform チームが実験基盤を運用
- 統計コンサル機能を専任 DS が提供
- 全アプリチームは self-service で実験開始
メリット：規模を出しやすい、品質均一 デメリット：Platform 側の人員が必要
パターン B: 分散型（推奨：小規模）
- 各チームが Feature Flag を独自運用
- 統計設計はチーム内で完結
- 結果共有は Slack channel
メリット：立ち上げが速い デメリット：実験品質のばらつき、重複
パターン C: ハイブリッド
- Platform は基盤のみ提供、統計はチーム責任
- 重要実験（売上影響大）のみ専任 DS が介入
中堅組織はここを目指すケースが多い。
1年でゼロから立ち上げるロードマップ
| 月 | 目標 |
|---|---|
| 0-2 | Feature Flag 導入、決定的バケッティング検証 |
| 2-4 | メトリクス計測基盤（primary + guardrail） |
| 4-6 | 統計エンジン（社内 or 既製：Eppo / Statsig） |
| 6-8 | 意思決定フロー（24h レビュー、共有 channel） |
| 8-10 | 月次 5-10 実験の安定運用 |
| 10-12 | 月次 20+ 実験、kill 70% の健全状態 |
12か月で「動くだけ」、本物の文化定着は2-3年スパン。
ガード指標の例
primary 指標だけ見ると視野が狭まる。並行して見るべきガード指標：
| ガード指標 | 検出する問題 |
|---|---|
| サイト全体のエラー率 | A/B 環境のバグ |
| p99 latency | パフォーマンス劣化 |
| 売上 / 注文数 | 副作用としての悪化 |
| サブスク解約率 | UX 劣化 |
| サーバーコスト | リソース消費増 |
primary が良くてもガードに問題があれば ship しない。
アンチパターン
- HiPPO（最高給の人の意見）で決定: 実験結果を覆す、文化が崩れる
- 目的を後付けする: 仮説なしで「とりあえず実験」、結果解釈が恣意的に
- kill を失敗扱いにする: kill 文化が萎縮、確証バイアスに支配される
- 統計を学ばないまま運用: peeking / 多重比較で false positive 量産
- 小数実験を回し続ける: 効果サイズが見えない、組織学習が止まる
A/B 以外の補完手段
A/B が向かないケースもある：
- 小サンプル領域: B2B SaaS（顧客10社）など → 質的調査・interrupted time series
- 長期効果: subscription LTV → switchback / holdout 設計
- ネットワーク効果: 友達招待・SNS → cluster-based randomization
「全部 A/B」は逆効果。手法選定も組織能力。
FAQ
Q. 自前で実験基盤を作るべきか、既製ツール（Eppo / Statsig）を使うべきか？ A. 中小規模なら既製ツール、年間1000+ 実験規模なら内製を検討。境目は「実験単価で換算して内製 ROI が回るか」です。
Q. 統計の専門知識がないチームは A/B を回せない？ A. 既製ツール（Eppo / Statsig）が統計エンジンを内蔵しているため、初期段階は使いこなせます。中級以上の実験（複合介入、CUPED 等）は専門知識が必要です。
Q. 実験文化が定着しない、何から手をつける？ A. 「kill を称える儀式化」が最速です。月次レビューで kill 実験を取り上げ、学びを共有する場を作ります。
まとめ
A/Bテストはツール導入ではなく、実験基盤 / 統計設計 / 意思決定プロセスの3層を連結することで初めて回る。MDE 事前決定、ガード指標の併用、kill 文化、24h レビュー——この4要素が無いと統計的に有意でも組織は動かない。1年で土台、2-3年で文化定着の長期投資。
