実験プラットフォームは「Feature Flag の延長」ではない
- 年時点で、多くのチームが「Feature Flag ツール＝実験プラットフォーム」と認識しているが、これは正確には誤りだ。Feature Flag は単にリリース制御のスイッチであり、A/Bテストのためには独立した統計エンジン・メトリクスレジストリ・Exposure ログ・Guardrail の4点セットが必要になる。2026年の主要プレイヤーである Statsig、LaunchDarkly、GrowthBook、Unleash は、この4点セットをどこまで提供するかで性格がまったく異なる。
Statsig は統計エンジンが最も成熟しており、Meta 出身チームの設計思想を濃く受け継ぐ。LaunchDarkly は Feature Flag のデファクトだが、実験機能は Experimentation アドオンとして別課金だ。GrowthBook は OSS で統計ロジックを完全にオープンにしており、自社のデータウェアハウスに乗せる構成が可能。Unleash は Feature Flag 単独の OSS で、実験は外部統合前提という割り切った設計を取る。
Statsig: エンド・ツー・エンドの統計エンジン
Statsig の強みは、CUPED（Controlled-experiment Using Pre-Experiment Data）、Sequential Testing、Bayesian / Frequentist の切り替え、Guardrail Metrics が最初から統合されていることだ。2026年版では特に「Autotune」機能が注目で、バンディットベースでトラフィック配分を動的に調整する。最適なバリアントへの収束速度が固定配分の2〜3倍速いと公表されている。
Exposure ログは `@statsig/react` 経由で自動記録され、イベントとの結合は Statsig 内部の統計エンジンが処理する。Metrics レジストリは DAG 構造で、派生メトリクス（例: 「購入完了後30日以内の2回目購入率」）を宣言的に定義可能だ。プライシングは無料枠が月100万イベントまでと寛容で、スタートアップフェーズから使える。Enterprise プランは年額3,000〜8,000万円のレンジ。
日本チームが陥りがちな落とし穴は、Exposure のタイミングだ。Statsig は「値を参照した瞬間」を Exposure として記録するため、事前に全バリアントを評価するコードは意図しない Exposure を大量生成する。必ず `checkGate` / `getExperiment` を使用直前で呼び出す実装規約が必要になる。
LaunchDarkly: Feature Flag 基盤としての堅牢性
LaunchDarkly は Feature Flag 運用の堅牢さで他を圧倒する。Targeting Rule のバージョニング、Approval Workflow、Code References、Guarded Rollouts（メトリクス劣化時の自動ロールバック）といった本番運用機能が網羅されており、1,000人規模のエンジニア組織でも破綻しない。
- 年版では `AI Configs` という新機能が追加され、Anthropic / OpenAI / Google の LLM 呼び出しをモデル・温度・プロンプト単位でFlag管理できるようになった。モデル切り替えを Feature Flag と同じ運用フローに乗せられる点は、LLMプロダクトの運用効率を大きく高める。
実験機能は Experimentation アドオンとして年額追加1,500万円前後から。統計エンジンは Frequentist ベースで、Sequential Testing は対応するが、CUPED は未対応。そのため分析の奥行きが必要な場合は、Exposure ログを BigQuery / Snowflake に吐き出し、自前で統計処理する構成になる。LaunchDarkly + dbt + Hex の組み合わせは2026年の定番だ。
GrowthBook: OSS とデータウェアハウス統合
GrowthBook は完全 OSS（MIT）で、統計エンジンが Python / Go 実装で公開されている。最大の差別化ポイントは「データウェアハウスに直接クエリする」設計思想だ。BigQuery、Snowflake、Redshift、ClickHouse、Databricks など20種以上に対応し、分析対象のイベントテーブルを GrowthBook 側にコピーしない。これにより、データ主権を失わず、PII の越境を避けられる。
統計エンジンは Bayesian（デフォルト）と Frequentist の両対応、CUPED、Sequential Testing、CUPAC（CUPED の多変量拡張）も実装済み。2026年版では Causal Inference（Double Machine Learning）機能が追加され、観察データからの因果効果推定も可能になった。観察データは厳密な A/B より弱いが、倫理的に実験できない領域（例: 価格変更）での一次スクリーニングに有効だ。
GrowthBook Cloud は月200ドル（約30,000円）から、セルフホストは完全無償。ただしセルフホストは Redis + MongoDB の運用が必要で、小規模チームでは GrowthBook Cloud の方が実質安価になる。
Unleash: 純粋な Feature Flag と外部統合
Unleash は Feature Flag 単独の OSS で、実験は「データパイプラインで外出しする」という割り切り方だ。ClickHouse や Apache Druid に Exposure を吐き出し、統計処理は別ツール（Kubit、自前ノートブック、Metabase 等）で実施する前提になる。
この設計の強みは、実験プラットフォームをデータ基盤の一部として構成できる点だ。Unleash から BigQuery に Exposure を送り、既存の KPI メトリクス（セグメント / LTV / 解約率）と結合して分析することで、実験専用メトリクスと経営メトリクスの二重管理を避けられる。大企業のデータ基盤との親和性はこの4社中もっとも高い。
Bayesian vs Frequentist: 2026年の現実解
長年の論争だが、2026年時点での実務的な推奨は「ほぼ全てのプロダクト実験は Bayesian、Regulated 業界（金融・医療）のみ Frequentist」というシンプルな結論に落ち着いている。Bayesian は「バリアントAが勝つ確率」という直感的な解釈、Stop condition の柔軟さ、事前分布による知見の取り込みという点で実務に向く。
ただし Bayesian を使う際の最大の落とし穴は事前分布（Prior）の設定だ。Uninformative Prior を選ぶなら良いが、過去データから Informative Prior を組むと、意図せず過去の失敗パターンをバイアスとして持ち込む危険がある。GrowthBook / Statsig ともにデフォルトは Uninformative Prior なので、迷ったら変更しないのが安全だ。
Frequentist を選ぶ場合でも、従来の `p<0.05` 固定値は Peeking Problem（中間確認によるα膨張）を生むため、Sequential Testing（Alpha-spending または Always-valid p-values）を必ず併用する。Statsig / GrowthBook ともに Sequential Testing 対応済み。
CUPED による分散削減
CUPED（Controlled-experiment Using Pre-Experiment Data）は、実験期間前のユーザー行動を共変量として使い、メトリクスの分散を削減する技法だ。同じ効果サイズを検出するのに必要なサンプル数を30〜50%削減できる。特に Revenue や Retention のようにノイズの大きいメトリクスでは劇的な効果がある。
実装は単純で、実験前30日間のユーザー行動（例: 購入金額、セッション数）を共変量 `X` とし、メトリクス `Y` を `Y - θ(X - E[X])` で調整する。`θ` は `cov(Y, X) / var(X)` で推定する。Statsig / GrowthBook はこれを自動化しているが、LaunchDarkly では自前実装が必要だ。
注意点として、CUPED はバリアント間で事前期間の行動が独立である必要がある。新規ユーザーが多い実験では事前データが存在せず、CUPED の恩恵が薄くなる。そのため、新規ユーザー実験では CUPED を無効化するのが正しい運用だ。
Guardrail Metrics と Stop 判定
Guardrail Metrics は実験の成功メトリクスとは別に「壊してはいけないメトリクス」（ページ読み込み時間、エラー率、離脱率等）を監視し、劣化した瞬間に実験を自動停止する仕組みだ。Statsig は `Guardrails` タブで設定可能、GrowthBook も同等機能を提供する。
Stop 判定は「Guardrail が有意に悪化したら即停止」と「主要メトリクスが十分な確率で勝っていれば早期終了」の2軸で設計する。Bayesian の場合、主要メトリクスの勝率95%以上で早期勝利、Guardrail の悪化確率90%以上で早期停止、というのが2026年の定番閾値だ。
Server-side vs Client-side の判断軸
実験を Server-side と Client-side のどちらで評価するかは、実装の都度で判断する問題ではなく、組織としてポリシーを決めるべき領域だ。2026年の推奨は「Server-side デフォルト、Client-side は UI のみに限定」だ。
Client-side の問題は3つある。1つ目は Flicker（バリアント切り替え時の画面のちらつき）で、UX を劇的に損ねる。2つ目は広告ブロッカーによる SDK ロード失敗で、Exposure の欠損率が5〜15%発生する。3つ目は機密ロジック（価格、レコメンド）をクライアントに晒すセキュリティリスクだ。
Server-side で評価する際の注意点は、Edge ランタイム（Cloudflare Workers、Vercel Edge）で Statsig / LaunchDarkly の SDK を使う場合、コールドスタートで100〜300ms のオーバーヘッドが発生することだ。Edge Config（LaunchDarkly）や Statsig の Local Evaluation モードを使い、評価ロジックをメモリ内で完結させる構成が必須になる。
実験プラットフォーム選定チェックリスト
- 統計エンジン（CUPED / Sequential Testing / Bayesian）の標準装備を必ず確認する
- Exposure ログをデータウェアハウスへ複製し、外部での再分析を可能にしておく
- Guardrail Metrics を最初から設定し、自動停止の閾値を明示する
- Server-side 評価をデフォルトとし、Client-side は UI のみに限定する
- Feature Flag と Experiment を同じツールに統合するか、分離するかを組織で決めておく
- OSS / セルフホストを選ぶ場合、運用工数を年間400〜600時間で見積もる
実験プラットフォームは2026年、「意思決定の速度と正しさ」を決める最重要基盤の一つだ。統計エンジンの差異、運用の細かな規約、そして Server-side / Client-side の設計思想まで含めて、戦略的に選ぶ時代になった。