2026.11.01 アーキテクチャ

LaunchDarklyとは？料金の数え方とNode.js実装、Unleash等OSSとの選び分け【2026年11月時点】

LaunchDarklyは、フィーチャーフラグの作成、配信、段階公開、実験を1か所で管理する米国のSaaSです。コードのデプロイと機能の公開を切り離し、管理画面の操作だけで特定の利用者に機能を出したり、障害時に止めたりできます。フラグという考え方そのものはフィーチャートグルの4種類と自前実装の例を解説した記事にまとめているので、ここでは製品としてのLaunchDarklyに絞ります。

扱うのは、SDKがフラグを評価する仕組み、Node.jsでの組み込みコード、OpenFeature経由の呼び出し、Pod単位で増える料金の計算、Unleash・Flagsmith・GrowthBook・flagdとの比較、そして採用する条件と見送る場面です。料金と版番号は2026年11月1日時点の公式ページとGitHubで確認した値を使います。

まとめ：LaunchDarklyを採用する条件とOSSのフラグ管理で足りる条件

採用判断の結論は次のとおりです。複数チームが同じフラグ基盤を使い、変更の承認や監査ログ、段階公開の自動化まで必要な組織なら、LaunchDarklyを契約して運用を任せる価値があります。逆に、フラグが十数本でサービスが1つ、承認フローも不要なら、無料のDeveloperプランかOSSで足ります。

任せられる範囲：フラグの配信、ターゲティング、割合での段階公開、変更履歴、A/Bテストの集計
自社で書く範囲：SDKの初期化、コンテキストの設計、既定値、使い終えたフラグの削除
料金の単位：サーバー側SDKはPodやプロセスごとの接続数、ブラウザやアプリは月間利用者数で課金
見送る条件：フラグ管理を社内ネットワークで閉じたい、Pod数が多く接続課金が読めない

料金は台数で増えます。単価だけを見て安いと判断し、本番のPod数と検証環境を掛け忘れるのが最もよくある見積もり漏れです。

LaunchDarklyの仕組みとサーバー側SDKがフラグを評価する流れ

LaunchDarklyでは、管理画面で作ったフラグの定義（どの利用者にどの値を返すかのルール）が、アプリに組み込んだSDKへ配信されます。アプリはSDKに「このフラグの値は何か」を問い合わせ、返ってきた値で処理を分岐させます。

クライアント側SDKとサーバー側SDKで異なる評価場所と3種類のキー

公式のSDK種別の解説によると、サーバー側SDKはSDKキーに紐づくルールセット全体を受け取り、手元でフラグを評価します。クライアント側SDKはセキュリティ上の理由からルールセットを持たず、評価済みの値だけを受け取ります。

種別	使うキー	秘匿	評価場所	課金単位
サーバー側	SDK key	必要	アプリ内	サービス接続
JavaScript等	Client-side ID	不要	LaunchDarkly側	月間利用者数
モバイル	Mobile key	不要	LaunchDarkly側	月間利用者数

SDKキーをフロントエンドのコードに書くと、全フラグのルールが外から読めてしまいます。ブラウザに出すのはClient-side IDだけ、と最初に決めておくのが漏えい事故を防ぐ方法です。SDKの一覧には、このほかAI向けとエッジ向け（Cloudflare・Fastly・Vercel・Akamai）のSDKも載っています。

ストリーミング接続でフラグ変更がアプリへ届く配信経路と遅延の目標値

サーバー側SDKは既定でLaunchDarklyとストリーミング接続を張り続け、フラグを変更するとその接続で更新を受け取ります。評価自体は手元のキャッシュで済むため、1回の判定のたびに外部へ通信が発生するわけではありません。

料金ページでは、設定の配信遅延の目標をFoundationで200ミリ秒未満のSLO、Enterpriseで150ミリ秒未満のSLAとしています。障害時に機能を止めるキルスイッチとして使うなら、この数字が切り替えにかかる時間の目安です。

100,000バケットのハッシュで固定される段階公開の振り分け方

割合ロールアウトの公式解説によると、コンテキストのキーと種別からハッシュを作り、利用者を1〜100,000のバケットへ振り分けます。割合は小数点以下3桁（例：0.125%）まで指定できます。

割合を50%から70%へ上げても、すでに新機能を見ている利用者はそのまま残り、バケット50,001〜70,000が追加される仕組みです。ただしフラグ同士の振り分けは独立しているため、2つのフラグで同じ10%の利用者を狙うならセグメントを使います。インフラ側で割合を切る方式との違いはカナリアリリースの仕組みと実装の解説で比べています。

Node.jsのサーバーSDKでフラグを評価するまでのインストール手順

ここではNode.jsのサーバー側SDK（公式リファレンス）を例にします。npmのレジストリで確認した最新版は2026年10月27日公開の9.16系です。

npm install・waitForInitialization：初期化とフラグ判定

SDKキーは環境変数で渡し、クライアントはプロセスに1つだけ作ります。公式リファレンスも、リクエストごとに新しいクライアントを作らないよう注意しています。

npm install @launchdarkly/node-server-sdk

// flags.js
import { init } from '@launchdarkly/node-server-sdk';

// クライアントはプロセスに1つだけ作る（リクエストごとに作らない）
const ldClient = init(process.env.LD_SDK_KEY);

export async function startFlags() {
  try {
    await ldClient.waitForInitialization({ timeout: 10 });
  } catch (err) {
    // 初期化に失敗しても、variation は既定値を返して処理は止まらない
    console.error('LaunchDarkly init failed', err);
  }
}

export async function isNewCheckoutEnabled(userId, orgId) {
  const context = {
    kind: 'multi',
    user: { key: userId },
    organization: { key: orgId },
  };
  return ldClient.variation('new-checkout', context, false);
}

process.on('SIGTERM', async () => {
  await ldClient.flush();
  ldClient.close();
  process.exit(0);
});

variationの第3引数が既定値です。LaunchDarklyに届かないとき、フラグが存在しないとき、どちらもこの値が返ります。既定値は「新機能を出さない側」にしておくのが安全です。

userとorganizationのコンテキスト設計とキー選びの失敗パターン

コンテキストは「誰に対して評価するか」を表す入れ物で、kindで種別を、keyで個体を示します。上のコードのようにkindをmultiにすると、利用者と所属企業の両方の属性でルールを書けます。BtoBのSaaSで「契約企業A社の全員にだけ出す」という公開をするなら、organizationの種別を最初から作っておくと後で困りません。

失敗しやすいのは、keyにメールアドレスやセッションIDを入れる設計です。メールアドレスは変更されるとバケットが変わり、同じ人に出たり消えたりします。セッションIDではログインのたびに振り分けが変わります。keyにはデータベースの不変な利用者IDを使い、氏名などの個人情報は属性に入れないか、必要な項目だけに絞ってください。

プロセス終了時のflushとシングルトン化を怠ったときに起きる不具合

公式リファレンスによると、このSDKは終了時に未送信の分析イベントを自動では送りません。上のコードでSIGTERMを受けてflushを呼んでいるのはそのためで、省くとデプロイのたびに評価回数や実験の集計が欠けます。

クライアントを複数作る不具合はもっと高くつきます。後述のとおり課金はSDKのインスタンス数で数えるため、ハンドラの中でinitを呼ぶ実装はそのまま請求額が増える原因です。PythonやRubyのようにプロセスをforkするサーバーでは、ワーカーごとに初期化が要る点も公式のサービス接続の説明に書かれています。

OpenFeature経由でLaunchDarklyを呼び、ベンダー依存を薄くする実装

OpenFeatureは、フラグ評価のAPIを製品から切り離すためのCNCFの仕様です。アプリはOpenFeatureのAPIだけを呼び、裏の製品はProviderとして差し替えます。

LaunchDarklyProvider登録とgetBooleanValue評価

LaunchDarklyのOpenFeature Providerを使うと、次のように書けます。npmで確認したProviderの最新版は2.1系で、package.jsonの動作条件はNode.js 20以上です。

npm install @openfeature/server-sdk @launchdarkly/node-server-sdk @launchdarkly/openfeature-node-server

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

await OpenFeature.setProviderAndWait(new LaunchDarklyProvider(process.env.LD_SDK_KEY));
const client = OpenFeature.getClient();

// targetingKey が LaunchDarkly の key になる。kind を省くと user として扱われる
const enabled = await client.getBooleanValue('new-checkout', false, {
  targetingKey: 'user-123',
});

将来UnleashやflagdへProviderを替えても、getBooleanValueを呼ぶ側のコードは変わりません。解約時の書き換え範囲を小さくしたいなら、最初からこの形で組むのが堅実です。代わりに、実験の計測など製品固有の機能は直接SDKを呼ぶ必要が残ります。

Relay Proxyで外向き接続を束ねる構成と課金が減らない注意点

Relay Proxyは自社インフラで動くGo製の中継役で、各サーバーはRelay Proxyにだけ接続し、LaunchDarklyとの接続はRelay Proxyが保ちます。GitHubのリポジトリでは2026年10月30日にv9.0.0が出ています。

公式ドキュメントは「削減されるのは外向きのネットワーク接続で、課金対象のサービス接続ではない」と明記しています。ファイアウォールの穴を1か所にしたい、LaunchDarkly側の障害時もフラグを配り続けたい、という目的なら入れる意味があります。費用を下げる目的なら入れても効きません。

LaunchDarklyの料金体系とサービス接続・利用者数の数え方

料金は「プラン」と「使った量」の掛け算で決まります。シート（管理画面の利用者数）による課金はありません。

Developer・Foundation・Enterpriseの3プランの上限と単価

項目	Developer	Foundation	Enterprise
月額の基本	0ドル	従量のみ	個別見積もり
サービス接続	5まで	5込み・超過1件10ドル	契約による
ブラウザ等の利用者	1,000人まで	1,000人あたり8.33ドル	契約による
プロジェクト/環境	1/3	無制限	無制限
承認フロー	なし	なし	あり

数値は2026年11月1日時点の公式料金ページによります。Foundationの利用者単価は本文で年払い表示の8.33ドル、比較表で10ドルと2か所の記載が食い違っているので、見積もりでは高い方で置いてください。Foundationには14日間の試用があり、カスタムロール、承認、スケジュール公開はEnterpriseの機能です。

本番3Pod・検証1Podの3サービス構成で月額を試算する計算例

サービス接続の公式説明では、1接続は「1つのサーバー側SDKのインスタンスが1つの環境に1か月（43,800分）つながった量」です。Pod、コンテナ、仮想マシン、レプリカはそれぞれ別に数え、検証環境も課金対象に入ります。

API・管理画面・バッチの3サービスがあり、本番は各3Pod、検証と開発は各1Podで常時起動している
本番は3サービス×3Pod＝9接続、検証と開発は3サービス×1Pod×2環境＝6接続で、合計15接続
Foundationは毎月5接続が含まれるので、超過10接続×10ドル＝月100ドル
ブラウザで評価する利用者が月5,000人なら、5×8.33ドル≒月42ドル（比較表の10ドルなら50ドル）を足す

月150ドル前後なら安く見えます。ただしKubernetesの水平スケールでPodが倍になれば接続料も倍になり、Pythonのgunicornでワーカーを4つ立てればPod1つで4接続です。サーバーレスは1回の起動を1/43,800接続として按分し、ポーリング方式ならリクエスト732回で1接続と数えます。見積もりは平均Pod数ではなく、ピーク時のPod数とワーカー数で置くのが安全です。

Unleash・Flagsmith・GrowthBook・flagdの比較とOSS選定

自社でフラグ管理サーバーを動かすなら、OSSの選択肢があります。どれもGitHubで2026年10月中に更新されている、活発なプロジェクトです。

OSS4製品を選ぶ際のライセンス条件と有償版に回される機能の違い

製品	GitHub上のライセンス	最新リリース	性格
Unleash	AGPL-3.0	v8.3.1	フラグ管理の専業
Flagsmith	BSD-3-Clause	v2.288.2	フラグとリモート設定
GrowthBook	製品ごとに要確認	v5.1.0	実験と分析が中心
flagd	Apache-2.0	core v0.19.2	OpenFeature純正の評価器

表は2026年11月1日にUnleash、Flagsmith、GrowthBook、flagdの各リポジトリで確認した内容です。UnleashのREADMEは、権限管理（RBAC）やSSO、追加の環境数を有償のPro・Enterpriseの機能として案内しています。GrowthBookはGitHubのライセンス自動判定が付いていないため、採用前にLICENSEファイルで対象ディレクトリごとの条件を読んでください。

管理画面が要らず、フラグ定義をGitのJSONファイルで管理したいならflagdが軽量です。承認や画面での操作を求めるならUnleashかFlagsmithが候補になります。

Docker Composeで立てたUnleashを自社で保守するときの負担

Unleashは、READMEの手順どおりなら次の3行で手元に立ち上がり、ブラウザで4242番ポートを開けば管理画面が出ます。

git clone https://github.com/Unleash/unleash.git
cd unleash
docker compose up -d
# http://localhost:4242 を開く

立ち上げは数分ですが、本番で使うと話が変わります。PostgreSQLのバックアップ、Unleash本体の更新（最新のv8.3.1は2026年10月29日公開）、冗長化、管理画面への認証、障害時の連絡体制がすべて自社の仕事になります。フラグ管理サーバーが止まってもSDKは最後に受け取った定義で動き続けますが、障害中はキルスイッチが効きません。この保守を誰が持つかを決めずに入れると、半年後に更新が止まったサーバーが残ります。

LaunchDarklyを採用する条件とOSSで足りる場面の判断

ここまでの仕組みと料金を踏まえ、受託開発の現場で判断する線を示します。迷う場合は、次の採用条件に2つ以上当てはまるかで決めてください。

採用する条件：3チーム以上での共同利用・承認フロー・監査記録が要る組織

3チーム以上が同じフラグ基盤を使い、誰がいつどのフラグを変えたかを追う必要がある
本番のフラグ変更に承認を挟む社内規程がある（Enterpriseの承認・ワークフロー機能が該当）
キルスイッチを確実に効かせたいが、フラグ管理サーバーの保守要員を置けない
A/Bテストの統計処理まで含めて1つの製品で済ませたい

この条件なら、Foundationの従量課金か、承認が要るならEnterpriseの見積もりを取る価値があります。国内では2024年9月にエクセルソフトが販売代理店契約を結び、日本語サポートを始めたとBCNが報じています。円建ての請求や日本語での問い合わせが必要な会社は、この経路も確かめておくとよいでしょう。

見送る場面：フラグ20本以下の単一サービスと閉域網が条件の案件

サービスが1つでフラグが20本以下なら、LaunchDarklyは過剰です。無料のDeveloperプラン（5接続・利用者1,000人・3環境）に収まるか、収まらないならflagdかUnleashで足ります。社内規程でフラグ定義や利用者の属性を外部SaaSへ送れない案件、閉域網で動かす業務システムも見送りです。Relay Proxyを置いても、定義の取得元はLaunchDarklyのクラウドだからです。

Pod数が日々大きく変わるKubernetes構成も注意が要ります。接続課金が読めないまま契約すると、スケールのたびに請求が増えます。先に1か月分のピークPod数を測ってから見積もってください。

どちらを選んでも、フラグを使い終えたら消す運用は自社で続ける作業です。作成時に期限と削除の担当者を決め、四半期ごとに棚卸しする流れはフィーチャートグルを残さない運用ルールで整理しています。SaaSの契約から段階公開の手順書づくり、使い終えたフラグの削除まで含めて運用を外部と分担したい場合は、一創の保守運用・内製化支援で体制づくりから相談を受けています。

よくある質問

LaunchDarklyの導入を検討する方から寄せられやすい質問を、2026年11月1日時点の公式情報をもとにまとめました。

LaunchDarklyは無料で使えますか？

使えます。Developerプランは月額0ドルでクレジットカードも不要です。上限はサービス接続5件、ブラウザやアプリで評価する利用者が月1,000人、プロジェクト1つと環境3つです。フラグの本数とメンバー数には上限がありません。本番1Podと検証・開発各1Podの小さな構成なら、サービス1つでこの枠に収まります。上限を超えるとFoundationの従量課金へ移ることになります。

SDKキーをフロントエンドのコードに書いてもよいですか？

書いてはいけません。公式ドキュメントは、サーバー側SDKのSDKキーは秘密にし、クライアントやモバイルのアプリで使ってはならないと明記しています。SDKキーで取得できるのは全フラグのルールセットなので、漏れると公開前の機能や対象企業の条件まで読まれます。ブラウザではClient-side ID、モバイルではMobile keyを使ってください。どちらも秘匿不要のキーとして設計されています。

LaunchDarklyとFirebase Remote Configはどう使い分けますか？

モバイルアプリの表示や設定値を切り替えるだけなら、Firebase Remote Configで足ります。条件配信と段階ロールアウトの実装はFirebase Remote Configの解説記事を参照してください。サーバー側の処理分岐、複数サービスでの同じフラグの共有、承認フローや監査記録が要るなら、LaunchDarklyの方が向いています。Firebaseを使っているモバイル中心の開発なら、まずRemote Configで足りるかを確かめるのが近道です。

LaunchDarklyのA/Bテスト機能は別料金ですか？

公式料金ページでは、Developerプランにも実験の対象者として月10万人分（100K experiment MAU）が追加料金なしで含まれています。フラグの割合配信と同じ仕組みで利用者を振り分け、指標の差を統計的に集計する機能です。ただし、指標の自動監視と自動ロールバックを担うGuardianはEnterprise向けの有償アドオンで、別に見積もりが要ります。

Relay Proxyを入れると料金は下がりますか？

下がりません。公式ドキュメントに、Relay Proxyが減らすのは外向きのネットワーク接続であって課金対象のサービス接続ではない、と書かれています。課金はRelay Proxyにつながっているサーバー側SDKの数で計算されます。Relay Proxyを入れる理由は、ファイアウォールの穴を1か所にまとめる、LaunchDarkly側の障害時もフラグを配り続ける、といった通信と可用性の都合です。