필사 모드: フィーチャーフラグ & 実験プラットフォーム 2026 — LaunchDarkly / Statsig / GrowthBook / Unleash / PostHog / OpenFeature 徹底比較

プロローグ — 「デプロイ = リリース」は 2026 年でもまだ成立しない

エンジニア「今週、新機能のデプロイ終わりました」

PM「じゃあユーザーには出てるんだよね？」

エンジニア「いえ、フラグで止めてあります。来週 5% から開けます」

PM「それじゃデプロイ終わってないじゃん」

エンジニア「…デプロイは終わってます。リリースが終わってないんです」

この会話、2026 年でもよく見る。そしてこの分離 — **デプロイ（コードを本番に置くこと） vs リリース（ユーザーに対して機能を点けること）** — がモダンなデリバリーの核であり、それを可能にする道具が **フィーチャーフラグ（feature flag）** だ。

フィーチャーフラグはもう「if 文の小技」ではない。2026 年のフィーチャーフラグ・プラットフォームは **キルスイッチ + 段階的ロールアウト + A/B 実験 + マルチアームバンディット + holdout 分析 + ターゲティング + セグメンテーション + 監査ログ** を 1 つのプロダクトに束ね、その上に **OpenFeature** という **CNCF 標準 SDK** が乗っている。市場はマネージド SaaS（LaunchDarkly・Statsig）、オープンソース（GrowthBook・Unleash・Flagsmith）、統合プラットフォーム（PostHog）の 3 陣営にきれいに分かれている。

この記事では 2026 年現在のフィーチャーフラグ／実験プラットフォーム地図を描く。16 のプロダクト・標準を 1 行ずつ位置づけ、パターン（キルスイッチ・段階的ロールアウト・A/B・bandit・holdout）を整理し、トス・カカオ・メルカリの実際の運用を見て、最後にチーム別のおすすめまで持っていく。

1 章 · 2026 年のフィーチャーフラグ地図 — マネージド / OSS / 統合プラットフォーム 3 陣営

まず全体像。2026 年の市場は 3 つの陣営にきれいに分かれる。

**1) マネージド SaaS 陣営** — LaunchDarkly, Statsig, ConfigCat, Split, DevCycle, AB Tasty, Eppo, Optimizely Rollouts

- ホスティング前提。エンタープライズ SLA・SSO・SOC 2・HIPAA・BAA・FedRAMP。

- 価格は MAU・フラグ数・環境数で決まる。

**2) オープンソース陣営** — GrowthBook, Unleash, Flagsmith, Bucketeer

- セルフホスティングが一級市民。SaaS はアドオン。

- ライセンス：GrowthBook（MIT）、Unleash（Apache 2.0）、Flagsmith（BSD-3）、Bucketeer（Apache 2.0）。

- 「ベンダーロックインを避けたい」「データを自社インフラに置きたい」「予算固定」が決め手になる。

**3) 統合プラットフォーム陣営** — PostHog

- analytics + セッションリプレイ + フィーチャーフラグ + 実験を 1 つのプロダクトに。

- フラグを別の道具とは見ず、「イベントと同じ平面上のトグル」として扱う。

そしてその上に **OpenFeature（CNCF）** という標準 SDK レイヤーがある。どのベンダーを選んでもコード呼び出し面は統一される。これが 2024〜2026 年の最大の変化だ — 「ベンダーを決めたら一生」ではなく「標準 SDK + 差し替えられるバックエンド」が可能になった。

| 陣営 | 代表 | ライセンス | ホスティング | 一言 |

| --- | --- | --- | --- | --- |

| マネージド SaaS | LaunchDarkly | クローズド | SaaS + セルフオプション | エンタープライズの定番 |

| マネージド SaaS | Statsig | クローズド | SaaS | flags + 実験 + 分析の統合 |

| OSS | GrowthBook | MIT | self/SaaS | 実験に強い OSS |

| OSS | Unleash | Apache 2.0 | self/SaaS | エンタープライズ向け OSS |

| OSS | Flagsmith | BSD-3 | self/SaaS | API 優先の OSS |

| 統合 | PostHog | MIT（コア） | self/SaaS | analytics + flags + replay |

| 標準 | OpenFeature | Apache 2.0（CNCF） | 標準 SDK | ベンダー中立な SDK 層 |

2 章 · OpenFeature（CNCF） — 標準 SDK

**OpenFeature** は 2022 年に開始、2023 年に CNCF Incubating、2024〜2025 年で採用が急速に進んだ **ベンダー中立のフィーチャーフラグ標準** だ。2026 年現在、LaunchDarkly・Split・ConfigCat・Flagsmith・Unleash・DevCycle・GrowthBook など主要なフラグベンダーがほぼ全て OpenFeature provider を公式提供している。

中核アイデア：**SDK の API を 1 つに統一し、バックエンド（provider）を差し替え可能にする。** OpenTelemetry がテレメトリでやったことを、OpenFeature がフィーチャーフラグでやる。

典型的な Node/TS コード：

await OpenFeature.setProviderAndWait(

new LaunchDarklyProvider(process.env.LD_SDK_KEY!)

)

const client = OpenFeature.getClient()

const showNewCheckout = await client.getBooleanValue(

'new-checkout',

false, // default fallback

{ targetingKey: userId, plan: user.plan }

)

if (showNewCheckout) {

return <NewCheckout />

}

return <LegacyCheckout />

明日 Unleash に切り替えると決めたら？ `LaunchDarklyProvider` を `UnleashProvider` に置き換えるだけ。評価呼び出し（`getBooleanValue` / `getStringValue` など）は 1 行も触らない。

**OpenFeature が標準化するもの**：

- 評価 API — `getBooleanValue` / `getStringValue` / `getNumberValue` / `getObjectValue`。

- evaluation context — 評価で使うユーザー／リクエスト属性（`targetingKey` ＋任意の attrs）。

- hooks — `before` / `after` / `error` / `finally` のライフサイクルフック。

- providers — ベンダー・バックエンドのアダプタ。

- テレメトリ — OpenTelemetry スパンで評価イベントを自動記録。

**標準化しないもの**：

- フラグ定義のフォーマット — 各ベンダーのコンソールは違っていい。

- ターゲティングルール — ベンダーに任せる。

- 実験・統計 — provider 領域。

OpenFeature を挟まなくていいのは：小さなチーム、単一ベンダー確定、爆速の立ち上げが絶対優先のときくらい。それ以外は、ほぼ全ての新規プロジェクトで **OpenFeature SDK を入口にして、その奥に provider を差し込む** のが 2026 年のデフォルトになった。

3 章 · LaunchDarkly — エンタープライズの定番

**LaunchDarkly** は 2014 年創業、フィーチャーフラグ・マネージド SaaS の事実上の元祖でありエンタープライズの定番だ。2026 年現在 Fortune 500 の多数が利用し、SOC 2・HIPAA・BAA・FedRAMP・SAML SSO・SCIM といったエンタープライズ・チェックリストを誰よりも埋める。

LaunchDarkly の強み：

- **SDK マトリクスが最も広い** — Node/TS/Go/Java/Python/Ruby/.NET/PHP/Rust/Erlang/Elixir/Swift/Kotlin/Flutter/React/Vue/Angular/iOS/Android/Edge Workers。

- **クライアント側の安全性** — サーバーサイド評価、Edge Relay Proxy、PII がコンソールに漏れない「private attributes」。

- **権限・承認ワークフロー** — 誰がどの環境でどのフラグを点けられるか、RBAC、approvals、変更リクエスト。

- **監査ログ・コンプライアンス** — すべての変更に誰／いつ／なぜが残る。

- **実験（Experimentation）** — 自前の統計エンジン（ベイジアン + frequentist）、CUPED、sequential testing。

- **エンタープライズ統合** — Datadog・Slack・Jira・ServiceNow・Terraform provider。

典型的な LaunchDarkly の使い方：

const ldClient = LDClient.init(process.env.LD_SDK_KEY!)

await ldClient.waitForInitialization()

const context = {

kind: 'user',

key: userId,

plan: user.plan,

country: user.country,

}

const variant = await ldClient.variation('checkout-redesign', context, 'control')

switch (variant) {

case 'treatment-a':

return <CheckoutA />

case 'treatment-b':

return <CheckoutB />

default:

return <CheckoutControl />

}

弱点：価格（MAU・フラグ数ベースで急速に高くなる）、SaaS 依存（セルフホスト・オプションはあるが別契約）、小チームには機能セットが過剰。

LaunchDarkly が向くとき：エンタープライズ、規制業界（金融・ヘルスケア）、複数環境・複数 SDK・承認ワークフローが必要、予算に余裕。

4 章 · Statsig — flags + 実験 + 分析

**Statsig** は 2021 年に Meta からスピンアウトしたチームが作ったマネージド SaaS だ。最初から **「フィーチャーフラグと実験と分析を 1 つのプロダクトに束ねる」** というポスチャーで出発した。2026 年現在 OpenAI・Notion・Atlassian・Figma・Whatnot のような急成長スタートアップ／スケールアップが幅広く利用している。

Statsig の差別化点：

- **gate（boolean フラグ） + experiment（A/B） + dynamic config（ランタイム設定） + holdout** が一級コンセプト。

- **自前の統計エンジン** — frequentist（t-test・delta method）デフォルト、sequential testing、CUPED、サンプル比率ミスマッチ（SRM）自動検出。

- **イベントを自前で収集** — 自社の analytics／イベントパイプラインがあって、「フラグ評価 + 露出 + メトリクス」が 1 つのシステムにまとまる。

- **無料枠が太い** — 月 100 万イベントまで無料、スタートアップが始めやすい。

- **Pulse** — 本番で興味深いメトリクス変動を自動検出して通知。

典型的な Statsig の使い方：

await Statsig.initialize(process.env.STATSIG_SERVER_KEY!)

const user = { userID: userId, email: user.email, country: user.country }

if (await Statsig.checkGate(user, 'new_checkout_enabled')) {

// gradual rollout

}

const experiment = await Statsig.getExperiment(user, 'checkout_redesign_v2')

const layout = experiment.get('layout', 'vertical')

const buttonColor = experiment.get('button_color', 'blue')

await Statsig.logEvent(user, 'checkout_completed', orderTotal, { variant: layout })

**Holdout** が Statsig で最もよく挙げられる機能だ。「長期的に一定のユーザーグループには実験変更を一切適用しない」状態にして、四半期ごとにそのグループと他のメトリクス差分を見て、累積効果（あるいは退行）を測る。単一の実験は統計的に有意でも、積み重ねの効果は holdout でしか見えない。

Statsig が向くとき：急成長中のプロダクトチーム、実験を毎週何本も走らせ、「フラグ + メトリクス + 分析」が 1 つの道具にまとまるとうれしい場合。Meta の社内ツールに最も近い結。

5 章 · GrowthBook（OSS） — Series Seed

**GrowthBook** は 2020 年にオープンソースとして開始した実験プラットフォームだ。MIT ライセンス + Y Combinator + Series Seed。**「OSS 陣営の実験プラットフォーム」** という位置で最も早く地歩を固めた。

GrowthBook のポスチャー：

- **データウェアハウス・ベースの実験** — メトリクスを自前で収集せず、BigQuery・Snowflake・Redshift・ClickHouse・Postgres・MySQL・Databricks など、自社ウェアハウスから直接 SQL で取ってくる。

- **ベイジアン + frequentist 統計エンジン** — 両方サポート、ベイジアンがデフォルト。

- **セルフホスト優先** — `docker compose up` 一発で立ち上がる。SaaS はアドオン。

- **フラグも実験も両方** — 単純なトグルから本格的な実験分析まで。

- **可視化** — uplift・信頼区間・time-series・次元別ブレイクダウンが綺麗に出る。

典型的な GrowthBook の使い方（JS）：

const gb = new GrowthBook({

apiHost: 'https://gb.example.com',

clientKey: process.env.GB_CLIENT_KEY!,

attributes: { id: userId, country: user.country },

})

await gb.loadFeatures()

const showNewCheckout = gb.isOn('new-checkout')

const experiment = gb.evalFeature('checkout-redesign')

const variant = experiment.value // 'control' | 'treatment-a' | 'treatment-b'

gb.trackingCallback = (experiment, result) => {

analytics.track('experiment_viewed', {

experimentId: experiment.key,

variationId: result.variationId,

})

}

**データウェアハウス・ベース** というポスチャーが鍵だ。Statsig は自前のイベントパイプラインを持つが、GrowthBook は「メトリクス収集はしない、君たちのウェアハウスにすでにあるイベントの上で分析する」という立場。だから **データ・ガバナンスがクリーン** で、**すでに dbt / Airflow で作ったメトリクスをそのまま使える**。

GrowthBook が向くとき：すでに自社のウェアハウス＋分析パイプラインがあって、そこに実験レイヤーを乗せたいとき。OSS + セルフホスト派。データチームと実験チームの協業が中心。

6 章 · Unleash — ノルウェー発 OSS

**Unleash** はノルウェー発のオープンソース・フィーチャーフラグ・プラットフォームだ。2014 年から、Apache 2.0 ライセンス。2026 年現在 OSS 陣営では GrowthBook と並んで最もよく挙げられるが、ポスチャーは違う — **Unleash は「エンタープライズ向け OSS」** という位置。

Unleash のポスチャー：

- **セルフホスト一級市民** — Docker / Helm / Terraform すべて公式。

- **エンタープライズ機能を OSS にも多く開放** — 環境分離、プロジェクト単位の権限、監査ログ、change requests（リクエスト・承認ワークフロー）まで OSS で。

- **strategies** — 単純な boolean を超えて、gradual rollout、userId ベース、custom 戦略をコンソールで構成。

- **edge proxy** — Unleash Edge という別コンポーネントで、クライアント評価をデータセンター／エッジ近傍に。

- **多国採用** — ノルウェー政府、フィンランド政府、BMW、Audi、Lufthansa など EU エンタープライズの事例が多い。

典型的な Unleash の使い方：

const unleash = initialize({

url: 'https://unleash.example.com/api/',

appName: 'web-checkout',

customHeaders: { Authorization: process.env.UNLEASH_API_TOKEN! },

})

unleash.on('ready', () => {

const enabled = unleash.isEnabled('new-checkout', {

userId: userId,

properties: { plan: user.plan, country: user.country },

})

const variant = unleash.getVariant('checkout-experiment', { userId })

// variant.name: 'control' | 'a' | 'b' | 'disabled'

})

**SaaS と OSS の境界が意図的にぼかされている** のが Unleash の特異点だ。Unleash Enterprise は SaaS でも提供されるが、OSS に開放された機能の幅が広いので「セルフホスト + OSS」だけでもかなり遠くまで行ける。EU GDPR・データ主権が気になる政府・金融・製造ドメインで特によく採用される。

Unleash が向くとき：エンタープライズ向け機能が OSS で必要なとき、EU／規制業界、セルフホスト必須。GrowthBook が「実験に強い OSS」なら、Unleash は「フラグ運用に強い OSS」。

7 章 · ConfigCat / Flagsmith / Split — その他

**ConfigCat** — ハンガリーのチームが作るシンプルなマネージド SaaS。**「フィーチャーフラグはただのトグル」** というポスチャーで、実験機能をあえて入れずに価格を安く抑える。無料枠が太く（月 1000 万評価）、ターゲティング・gradual rollout・環境分離といった基本機能は揃っている。SDK も 20+ 言語サポート。「実験は別の道具でやる、フラグだけあればいい」というチームに刺さる。

**Flagsmith** — イギリスのチームの OSS（BSD-3）＋ SaaS。Unleash・GrowthBook と結が似ているが **API／headless 優先** が差別化点。REST + GraphQL + SDK + Terraform provider が一級。セルフホストも `docker compose` 一発。PostHog・Segment・Datadog・Slack のような道具との統合がきれい。

**Split** — 2015 年創業、**実験 + フラグ** を束ねた初期のマネージド SaaS。2024 年に Harness が買収し、**Harness Feature Management & Experimentation** に統合された。2026 年現在、Split を単独で評価するよりも、Harness プラットフォームの 1 モジュールとして見るのが自然。CI/CD・デプロイ検証と 1 つの道具にまとまる点が最大の強み。

**AB Tasty** — フランスのマネージド SaaS、マーケティング／プロダクトチーム向け。**2024 年 Insight Partners が過半数取得**、**2024 年 9 月にデジタルエージェンシー DEPT に買収**。2026 年現在のポスチャーはマーケティング実験寄りで、エンジニア一級ユーザーは LaunchDarkly・Statsig 系のほうが馴染む。

**Optimizely Rollouts** — Optimizely（旧 Web Experimentation のリーダー）が **無料のフィーチャーフラグ製品** として出したもの。実験は有料製品側で、単純なフラグは Rollouts で。2026 年現在、マーケティング向け実験 + エンジニア向けフラグを一緒に使いたい大規模組織でよく見かける。

8 章 · PostHog — オールインワン（analytics + flags + replay）

**PostHog** は 2020 年開始の OSS（MIT コア）プロダクト分析プラットフォームだ。analytics + funnel + retention + セッションリプレイ + フィーチャーフラグ + 実験 + アンケート + データウェアハウス + LLM オブザーバビリティまで **1 つのプロダクトに全部突っ込む** ポスチャー。2026 年現在、YC のトップカンパニーの 1 角を占め、マネージド SaaS + セルフホストどちらも一級。

フィーチャーフラグ視点での PostHog：

- **analytics と同じ平面上のトグル** — フラグを点けるとその瞬間「分析イベントと紐付けて」コホート・funnel・retention・replay が見える。

- **flag → 実験 → メトリクス → 意思決定** の流れが 1 つの道具で。

- **セッションリプレイと結合** — 新機能を点けたユーザーの実際のクリックパターンをそのまま見られる。

- **LLM オブザーバビリティ（LLM 分析）** — 2025〜2026 年に追加、プロンプトごとの latency／コスト／結果も同じ平面で。

- **無料枠が非常に太い** — 月 100 万イベント、100 万フラグ呼び出しまで。

典型的な PostHog の使い方：

const client = new PostHog(process.env.POSTHOG_KEY!, { host: 'https://app.posthog.com' })

const enabled = await client.isFeatureEnabled('new-checkout', userId, {

groups: { organization: orgId },

personProperties: { plan: user.plan, country: user.country },

})

const variant = await client.getFeatureFlag('checkout-redesign', userId)

// variant: 'control' | 'treatment-a' | 'treatment-b'

client.capture({

distinctId: userId,

event: 'checkout_completed',

properties: { variant, orderTotal },

})

PostHog の決定的な魅力は **「1 つのプロダクトで全部できる」** こと。小さなチームは Mixpanel + LaunchDarkly + Optimizely + Hotjar + Datadog LLM を別々に買う代わりに、PostHog 1 つで始められる。弱点：分析／replay／flags のそれぞれの領域で、単一専門ツール（Amplitude・Mixpanel・LaunchDarkly・FullStory）ほどには深くないかもしれない —「広く適度に深い」結。

PostHog が向くとき：スタートアップ・スケールアップ、分析／replay／flags が最初から 1 プロダクトにあると嬉しい、OSS／セルフホスト・オプションも必要。**2026 年新規 SaaS スタートアップの最も一般的なデフォルト** の 1 つ。

9 章 · DevCycle / Hypertune（TS） / Eppo / Bucketeer

「特定のポスチャーで差別化した」後発組。

**DevCycle** — 2023 年に Taplytics からリブランド。**エッジ評価が一級** — Cloudflare Workers・AWS Lambda@Edge・CloudFront Functions でフラグ評価がミリ秒で終わる。SDK は自動同期でフラグ定義を取り込み、評価自体は 100% ローカル（ネットワーク往復なし）。モバイル・エッジ・サーバーレス環境で最もよく挙げられるマネージド SaaS。

**Hypertune** — **TypeScript の型安全** が一級の差別化点。フラグ定義がそのまま TS 型として生成され、`flags.checkout.layout` のような dot-access で書くと IDE の自動補完と型チェックが即作動する。Vercel 出身のチームが作っていて、Next.js + TS フルスタックのチームに特に強く刺さる。単純な boolean トグルを超えて **構造化された config（オブジェクト・ネストされた enum）を型安全に扱う** ポスチャー。

// Hypertune は codegen で次のような型を生成する

const hypertune = createHypertune(/* ... */)

const layout = hypertune.checkout({ user }).layout()

// 'vertical' | 'horizontal'（enum 型）

const buttonColor = hypertune.checkout({ user }).buttonColor()

// 'blue' | 'green' | 'red'

**Eppo** — **実験 first** のマネージド SaaS。GrowthBook と結が似て「データウェアハウス上の実験」だが SaaS。CUPED・sequential・SRM・heterogeneous treatment effect のような高度な統計が一級。Airbnb・Stitch Fix 出身のチームが作っていて、「データサイエンティストが実験を深く分析する」結。

**Bucketeer** — CyberAgent（日本）が社内ツールとして作り、2022 年に Apache 2.0 で公開。セルフホスト OSS。**「日本版 LaunchDarkly」** のような位置で、日本のエンタープライズ／ゲーム業界で採用事例がある。OpenFeature provider を公式サポート。

10 章 · Vercel Edge Flags / Cloudflare Workers

**Vercel** は自前ホスティングではなく **adapter モデル** を選んだ。`@vercel/flags` という薄いライブラリ + Edge Config（グローバルに read-optimized な KV）で、どのフラグベンダー（LaunchDarkly・Statsig・Hypertune・Optimizely など）でも Vercel adapter を通して **Edge Function でミリ秒級の評価** が可能になる。2025 年に安定化、2026 年に Next.js フルスタックチームのデフォルトパターンになりつつある。

// app/page.tsx

const showNewCheckout = flag({

key: 'new-checkout',

decide: async () => {

const ld = await getLaunchDarklyClient()

return ld.variation('new-checkout', context, false)

},

})

export default async function Page() {

const enabled = await showNewCheckout()

return enabled ? <NewCheckout /> : <LegacyCheckout />

}

**Cloudflare Workers** — Cloudflare 自体にはマネージドのフラグ製品はない（2026 年 5 月時点）。代わりに **Workers KV + D1 + Durable Objects** を組み合わせて自前で作るパターンが一般的で、Statsig・LaunchDarkly・DevCycle・Flagsmith の Workers アダプタを通した評価が標準。**Hyperdrive + Workers Analytics Engine** が実験分析の下地になる結も見え始めている。

中核アイデア：**エッジでの評価はミリ秒級でなければならない。** ユーザーリクエスト → エッジ → フラグ評価 → レスポンス分岐までが 1 リージョン内で終わる必要がある。そのために SDK は「フラグ定義を事前に同期 → 評価は 100% ローカル」で動くのがデフォルト。評価そのものに外部 API 呼び出しが入ってはいけない。

11 章 · パターン — キルスイッチ / 段階的ロールアウト / A/B / マルチアームバンディット / Holdout

道具を選んだら次は **パターン** だ。2026 年現在、実務で最もよく使われる 5 つ。

1) キルスイッチ（運用安全網）

**最もシンプルで最も重要なパターン**。新機能を点けて監視しながら、問題が見えたら **即座に消す**。これは実験ではない — インシデント対応だ。

- 運用ルール：すべての新機能は最初の 1〜4 週はキルスイッチの後ろにいる。

- ガード：SRE / on-call が PM・エンジニアの承認なしで消せる権限分離。

- 監視：フラグ ON のユーザーのエラー率・latency・コンバージョンが自動アラームと結びついていること。

2) 段階的ロールアウト（progressive delivery）

**% ベースでゆっくりトラフィックを増やす**。1% → 5% → 10% → 25% → 50% → 100%。各段階の間に **カナリア期間** を置いてメトリクスが正常か確認。

- userId・sessionId・deviceId ベースの決定論的ハッシュ — 同じユーザーは常に同じグループ。

- 「全体の 5%」ではなく「新規登録ユーザーの 5% から」のような segmentation が一般的。

- ターゲティングルール：country・plan・platform・app version で絞る。

3) A/B テスト（仮説検証）

**2 つ（あるいはそれ以上）のバリアントがメトリクスに与える因果効果** を測る。単純な rollout と本質的に違うのは — A/B は **統計的な結論** を出そうとする試み。

- 事前設計：hypothesis・primary metric・secondary metrics・MDE（minimum detectable effect）・サンプルサイズ・期間。

- 実行中の hygiene：SRM（sample ratio mismatch）自動検出、peeking 抑制（sequential testing が助ける）。

- 意思決定：lift + 信頼区間 + ビジネスインパクトの 3 点セットで。

4) マルチアームバンディット（適応的探索）

A/B とは違う結。固定比率で最後まで行く代わりに、**勝っている arm に徐々にトラフィックを寄せていく**。Thompson sampling が最も一般的なアルゴリズム。

- いいとき：短期的な意思決定（見出し・サムネ・プッシュ通知）、明確な単一メトリクス、速いフィードバック。

- 悪いとき：長期効果を見たい変更（価格・オンボーディング）、heterogeneous treatment effect を見たいとき。

- 道具：Statsig・Eppo・LaunchDarkly・GrowthBook いずれも bandit モードをサポート。

5) Holdout（累積効果の測定）

**一部のユーザーグループにはすべての実験変更を一切適用しない**。四半期ごとにそのグループと残りのメトリクス差を見て、「前四半期に打った変更の累積効果」を見る。

- なぜ必要か：個別の実験は皆 +0.5% lift だったのに、四半期末で見たら retention が落ちている？ 個別実験検証では見えないシステム効果を捕まえる。

- 運用：1〜5% のユーザーを四半期開始時にランダムに選んで全ての実験から除外。

- 道具：Statsig・LaunchDarkly・Eppo が holdout を一級機能としてサポート。

12 章 · 韓国 / 日本 — トス、カカオ、メルカリ

海外 SaaS だけ見ると絵の半分だ。韓国・日本の大手の実際の運用パターン。

韓国 — トス

**トス（Viva Republica）** は社内フィーチャーフラグ・システムを自社構築していることで知られる。トス SLASH カンファレンスの発表・技術ブログによれば：

- トラフィック分岐の意思決定（gradual rollout・A/B）のために自社のトラフィック・ルーティング・システムを運用。

- 決済・送金のような **金融ドメイン特有の安全性** 要件 — 誤った分岐は即インシデントなので、権限・承認・監査が非常に厳格。

- データ基盤（自社の社内分析システム）と結合して、フラグ評価 + 露出 + メトリクスが 1 つの流れに。

トスのポスチャーは **「規制業界の自社構築 + データチームとの深い統合」** に要約できる。外部 SaaS を導入するというよりは、自社で作り込んだ結。

韓国 — カカオ

**カカオ** は複数の事業部があるので一律ではないが、カカオ if/kakao カンファレンスやカカオ技術ブログから次の流れが確認できる：

- **社内フィーチャーフラグ・ゲートウェイ・パターン** — マイクロサービスの前段でフラグ評価を統一。

- カカオトーク・カカオペイ・カカオモビリティのような大規模サービスの **A/B 基盤** が社内で発表されたことがある。

- 一部の事業部は **PostHog／LaunchDarkly のような外部 SaaS と自社構築を併用** する結。

大規模組織らしく事業部ごとに道具選択が異なり、社内共通ゲートウェイがその上に敷かれる構造。

日本 — メルカリ

**メルカリ** は自社エンジニアリングブログでフィーチャーフラグ運用を比較的詳しく公開している事例がある：

- **一時期 LaunchDarkly を使用** していたとされ、一部ドメインでは自社構築に移った流れも。

- マイクロサービス環境でフラグ評価が **マイクロサービス間の一貫性** を壊さないようにするパターン — 1 リクエスト内で同じフラグを複数サービスが評価しても同じ結果になるように。

- **データ・ガバナンス + アプリ内実験 + マイクロサービス** が交わる結で、自社構築が次第に自然になった事例。

また **Bucketeer（CyberAgent）** が日本のカンファレンスでよく取り上げられるのも日本市場の特徴 — 日本発の OSS が日本のエンタープライズで OpenFeature provider として採用される流れ。

**共通パターン**：韓国・日本の大手は **外部 SaaS だけは使わない**。自社構築または OSS セルフホストを mix し、データ・ガバナンス・承認ワークフロー・ドメイン特性（金融・EC・通信）に合わせてカスタマイズする。**OpenFeature 標準はこういう mix 環境で最も光る** — 外部 SaaS・自社構築・OSS の間を同じ SDK でつなげる。

13 章 · 誰が何を選ぶべきか — 小チーム / 成長期 / エンタープライズ / セルフホスト

道具比較は終わった。あなたのチームに合う答え。

小チーム（5〜20 人） — 単一プロダクト、爆速スタート

- **1 番のおすすめ：PostHog** — analytics + flags + replay を 1 つに。無料枠が太く、小さなチームは道具を 5 つも運用する余力がない。

- **OpenFeature は挟んでおきたい** — 小チームほど将来ベンダーを差し替える可能性が高い。

- **ロックイン心配なしなら Statsig** — 無料枠が太く、実験を毎週やるなら結が合う。

- **単純なトグルだけなら ConfigCat** — 価格が非常に安く、実験なしでフラグだけ。

成長期（20〜200 人） — 実験文化

- **実験を毎週たくさんやるなら：Statsig** — flags + 実験 + 分析が 1 つの道具にまとまる結。

- **ウェアハウス優先なら：GrowthBook または Eppo** — メトリクスがすでに BigQuery / Snowflake にあるとき。

- **Next.js + TS フルスタックなら：Hypertune + Vercel Edge Flags** — 型安全とエッジ評価が核心。

- **依然 OpenFeature を積極利用** — 道具が変わる可能性が高いステージ。

エンタープライズ（200 人以上、規制業界） — 権限・承認・監査

- **1 番のおすすめ：LaunchDarkly** — エンタープライズ・チェックリスト（SOC 2・HIPAA・BAA・FedRAMP・SSO・SCIM）を最も埋める。

- **EU / GDPR 優先なら：Unleash Enterprise** — EU ベース、セルフホスト・オプションが豊富。

- **CI/CD に紐付けたいなら：Harness Feature Management（旧 Split）** — deploy + flag + verification が 1 つのプラットフォーム。

- **OpenFeature は必須** — 複数ベンダーが社内で共存するのが自然。

セルフホスト（法的／技術的要件） — データ主権

- **OSS first がデフォルト — GrowthBook・Unleash・Flagsmith・Bucketeer の中から結に合うものを**：

- GrowthBook — 実験に強い、データウェアハウスと統合。

- Unleash — フラグ運用・承認ワークフローに強い。

- Flagsmith — API／headless 優先、他ツールとの統合が容易。

- Bucketeer — 日本発 OSS、OpenFeature provider 公式。

- **PostHog セルフホスト** — 分析／replay も一緒にセルフホストしたいとき。

意思決定の 4 軸

| 軸 | A 側 | B 側 |

| --- | --- | --- |

| ホスティング | SaaS（LaunchDarkly・Statsig・ConfigCat） | セルフホスト（Unleash・GrowthBook・Flagsmith・PostHog） |

| 範囲 | flags only（LaunchDarkly・ConfigCat） | プラットフォーム（Statsig・PostHog・GrowthBook） |

| データモデル | 自前のイベントパイプ（Statsig・PostHog） | ウェアハウス first（GrowthBook・Eppo） |

| 親和性 | マーケ／PM（AB Tasty・Optimizely） | エンジニア／データ（LaunchDarkly・Statsig・GrowthBook） |

真ん中に OpenFeature を置けば、上の軸はすべて「差し替え可能な意思決定」になる。**2026 年のデフォルトは「ベンダー + OpenFeature」** だ。

エピローグ — フラグは運用安全網、実験は学習システム

この記事の 1 行要約：

> **フィーチャーフラグはデプロイとリリースを分離する運用安全網であり、実験は仮説をデータで検証する学習システムだ。両者は普通 1 つの道具にまとまるが、優先順位は違う — フラグはすべてのチームに必要で、実験は実験文化があるときに必要だ。**

2026 年現在の市場：

- **LaunchDarkly** — エンタープライズの定番。

- **Statsig** — 実験 + フラグ + 分析の統合、急成長中のチーム。

- **GrowthBook / Unleash / Flagsmith / Bucketeer** — OSS 陣営、セルフホストとデータ主権。

- **PostHog** — analytics + flags + replay のオールインワン。

- **ConfigCat / Split（Harness） / DevCycle / Hypertune / Eppo / Optimizely Rollouts / AB Tasty** — それぞれの結。

- **OpenFeature** — 上記すべてを束ねる CNCF 標準。

よくある罠 10 個：

1. フラグを作って消さない — 半年後に 1000 個のゾンビフラグ。

2. キルスイッチなしで新機能リリース — 事故時の対応がコード・ロールバックだけ。

3. 権限分離なしで誰でも本番フラグを点ける — ミスがインシデントに。

4. SRM 無視 — 50:50 のつもりの実験が実は 60:40。

5. peeking — sequential testing なしで毎日結果を見て意思決定。

6. 単一実験の結果で永久決定 — holdout で累積効果の確認なし。

7. フラグ評価に外部 API 呼び出し — latency が爆発。

8. PII がフラグ評価 context にそのまま入る — コンソールに露出。

9. 1 ベンダーに強くロックイン — 差し替え時にコードを全部直す（OpenFeature を使わない）。

10. 実験の仮説／メトリクス事前定義なしで開始 — 結果を見て仮説を作る（HARKing）。

次回予告

次回候補：**OpenFeature 深掘り — provider を自前で作る**、**実験統計の深掘り — CUPED・sequential・SRM**、**キルスイッチ + canary + SRE on-call を束ねる**。

> 「デプロイはコードを動かすこと、リリースはユーザーに対して点けること。その間の距離を縮めつつ安全に保つのがフィーチャーフラグの仕事だ」

— フィーチャーフラグ & 実験プラットフォーム 2026、終わり。

参考 / References

- [OpenFeature — CNCF](https://openfeature.dev/)

- [OpenFeature GitHub — open-feature/spec](https://github.com/open-feature/spec)

- [OpenFeature CNCF Incubating announcement](https://www.cncf.io/projects/openfeature/)

- [LaunchDarkly](https://launchdarkly.com/)

- [LaunchDarkly Documentation](https://docs.launchdarkly.com/)

- [Statsig](https://statsig.com/)

- [Statsig Documentation](https://docs.statsig.com/)

- [Statsig — Holdouts](https://docs.statsig.com/experiments-plus/holdouts/)

- [GrowthBook](https://www.growthbook.io/)

- [GrowthBook GitHub — growthbook/growthbook](https://github.com/growthbook/growthbook)

- [Unleash](https://www.getunleash.io/)

- [Unleash GitHub — Unleash/unleash](https://github.com/Unleash/unleash)

- [ConfigCat](https://configcat.com/)

- [Flagsmith](https://flagsmith.com/)

- [Flagsmith GitHub — Flagsmith/flagsmith](https://github.com/Flagsmith/flagsmith)

- [PostHog — Feature Flags](https://posthog.com/feature-flags)

- [PostHog GitHub — PostHog/posthog](https://github.com/PostHog/posthog)

- [Split — Now Harness Feature Management](https://www.harness.io/products/feature-flags)

- [DevCycle](https://devcycle.com/)

- [Hypertune](https://www.hypertune.com/)

- [Eppo](https://www.geteppo.com/)

- [Bucketeer GitHub — bucketeer-io/bucketeer](https://github.com/bucketeer-io/bucketeer)

- [Bucketeer — CyberAgent OSS](https://bucketeer.io/)

- [Vercel Flags SDK](https://vercel.com/docs/feature-flags)

- [Vercel Edge Config](https://vercel.com/docs/storage/edge-config)

- [Cloudflare Workers — KV](https://developers.cloudflare.com/kv/)

- [AB Tasty](https://www.abtasty.com/)

- [Optimizely Rollouts](https://www.optimizely.com/products/intelligence/rollouts/)

- [Toss SLASH Conference](https://toss.tech/slash)

- [Kakao Tech Blog](https://tech.kakao.com/)

- [Mercari Engineering Blog](https://engineering.mercari.com/en/)

- [Microsoft — Progressive Experimentation](https://learn.microsoft.com/en-us/azure/architecture/example-scenario/data/feature-flags)

- [Martin Fowler — Feature Toggles](https://martinfowler.com/articles/feature-toggles.html)

- [Statsig — CUPED](https://docs.statsig.com/stats-engine/methodologies/cuped)

- [Eppo — Sequential Testing](https://www.geteppo.com/sequential-testing)

- [Thompson Sampling — Multi-armed bandit](https://en.wikipedia.org/wiki/Thompson_sampling)