LabHub

ブログ

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

2026-05-16 · 33 分で読めます · #feature-flags#experimentation#ab-testing#launchdarkly#statsig#growthbook#unleash#configcat#flagsmith#posthog#split-io#devcycle#hypertune#openfeature#cncf#deep-dive#japanese

한국어English日本語

プロローグ — 「デプロイ = リリース」は 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

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

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

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

陣営代表ライセンスホスティング一言
マネージド SaaSLaunchDarklyクローズドSaaS + セルフオプションエンタープライズの定番
マネージド SaaSStatsigクローズドSaaSflags + 実験 + 分析の統合
OSSGrowthBookMITself/SaaS実験に強い OSS
OSSUnleashApache 2.0self/SaaSエンタープライズ向け OSS
OSSFlagsmithBSD-3self/SaaSAPI 優先の OSS
統合PostHogMIT（コア）self/SaaSanalytics + flags + replay
標準OpenFeatureApache 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 コード：

import { OpenFeature } from '@openfeature/server-sdk'
import { LaunchDarklyProvider } from '@openfeature/launchdarkly-server-provider'

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 が標準化するもの：

標準化しないもの：

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

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

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

LaunchDarkly の強み：

典型的な LaunchDarkly の使い方：

import * as LDClient from 'launchdarkly-node-server-sdk'

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 の差別化点：

典型的な Statsig の使い方：

import { Statsig } from 'statsig-node'

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 のポスチャー：

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

import { GrowthBook } from '@growthbook/growthbook'

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 のポスチャー：

典型的な Unleash の使い方：

import { initialize } from 'unleash-client'

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：

典型的な PostHog の使い方：

import { PostHog } from 'posthog-node'

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 で次のような型を生成する
import { createHypertune } from './generated/hypertune'

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
import { flag } from '@vercel/flags/next'

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) キルスイッチ（運用安全網）

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

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

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

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

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

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

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

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

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

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

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

韓国 — トス

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

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

韓国 — カカオ

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

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

日本 — メルカリ

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

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

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

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

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

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

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

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

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

意思決定の 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 年現在の市場：

よくある罠 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

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-feature-flags-experimentation-2026-launchdarkly-statsig-growthbook-unleash-posthog-openfeature-deep-dive.ja

コメント

まだコメントはありません。

ログインするとコメントできます