LaunchDarklyの概要

Sean：LaunchDarklyとは、フィーチャーフラグマネジメントプラットフォームです。フィーチャーフラグになじみのない方もご心配なく。基本からご説明します。

フィーチャーフラグはコード内の判断ポイントで、外部入力によって制御されます。if文だと考えてください。フィーチャーマネジメントは、フィーチャーフラグを中心に構築されたツールと手法です。フィーチャーフラグは弊社が発明したものではなく、長年用いられている仕組みです。

この分野で革新を続ける我々は、最初から2つの重要な差別化要因にフォーカスしてきました。1つ目は、ブール値（真偽）を超えることです。当製品は文字列および数値の多値（マルチバリアント）フラグに対応しており、より多くの選択肢ときめ細かなアプリ動作の制御が可能です。

また、実行時の変更にも即座に適応できます。UIにおける変更をリアルタイムで反映することも可能です。世界中に反映するのにかかる時間は1秒未満で、通常は200ミリ秒程度です。



弊社のフラグデリバリーネットワークは当製品の原動力となっており、製品の信頼性と規模を支えています。1日あたり数十兆件のフラグ評価を処理しており、稼働率のSLA（サービスレベル合意）は99.99％です。LaunchDarklyの強みは、このネットワークと幅広いSDK（ソフトウェア開発キット）です。主要な言語やフレームワークに対応した、32種類を超えるSDKを提供しています。



LaunchDarklyのフィーチャーフラグには、主に2つの構成要素があります。1つ目はターゲティングの規則で、対象ユーザーを特定し、提供すべきバリアントを決めます。２つ目はコンテキストです。皆さんのアプリからユーザーやデバイス、ビルド番号に関する情報が送信されます。それらを基に評価し、正しいフラグを返します。

コンテキストはシンプルなJSON形式で表現されます。単一のコンテキストの場合はユーザーまたは組織に関する情報です。マルチコンテキストの場合は、ユーザーとデバイスなどの情報が組み合わさり、SDKの初期化を簡潔に記述できます。

コンテキストの各kind（種類）には識別子があり、追跡とターゲティングに使われます。例えば当製品のパーセンテージロールアウトや実験機能では、コンテキストに含まれる属性をターゲティングに使えます。ビルド番号や地理、プランの階層などを使ってターゲティングの規則をカスタムできます。そして、その識別子を基にユーザーを追跡します。



弊社のSDK評価には3つの異なるアプローチがあります。1つ目はサーバーサイドSDKです。SDK自体の内部でローカルに評価を実行し、フラグルールを取得して更新用のストリーミング接続を維持します。これによりポーリングを最小限に抑え、遅延を減らします。



2つ目は導入環境についてです。複数のローカルSDKが必要となる場合には、リレープロキシがあります。インターネット接続がない環境にも使えます。リレープロキシはオンプレミス環境からLaunchDarklyへの中継役として機能します。なお、クライアントサイドSDKでの利用は特別な場合を除いて推奨されていません。



3つ目はクライアントサイドSDKです。クラウド上にあるLaunchDarklyのサーバーで評価を行い、ネットワーク状況に応じてストリーミング接続とポーリング接続を切り替えます。モバイルSDKでは、ネイティブなフラグキャッシュ機能でオフライン環境に対応します。



まとめると、LaunchDarklyは回復性に優れたデリバリーアーキテクチャを搭載しています。複数の可用性ゾーン、グローバルCDN、オプションのリレープロキシ、自己復旧機能を備えたSDK、メモリ上のフラグ値キャッシュ、開発者定義のフォールバック値を備えています。

このあと、パートナー企業のアンチパターンがLaunchDarklyの導入による成功例をご紹介します。その後、同じくパートナーのエクセルソフトが製品のライブデモをお見せします。

アンチパターン社の導入事例

穴田：アンチパターンは「日本のソフトウェアエンジニアを憧れの職業へ」という理念を掲げるスタートアップ企業です。2025年7月で7期目を迎え、スタートアップとしては比較的多くのサービスを展開しています。

弊社では独自の「ソフトウェア企業の成長サイクル」を定義しています。プロダクトが資金を生み出し、その資金で組織に投資することで良い組織を構築し、その組織が優れたプロダクトを生み出していくという循環です。このサイクルを回すことで、ソフトウェア企業の成長を実現していくという考え方です。



組織づくりの領域では、POSSEという大学生向けプログラミング学習コミュニティも運営しています。これは4年制のプログラミングコミュニティで、1年目にHTML/CSS、JavaScriptの基礎から始まり、最終的にはプロダクトマネジメントやインフラまで幅広く学習し、社会で活躍できる人材を輩出することを目指しています。

今回主にご紹介するのは、プロダクト開発分野のSaaSus Platformというサービスです。これは「SaaSを作るためのSaaS」として位置づけられています。

SaaS開発を氷山に例えると、水面上の部分がアプリケーションプレーン（顧客に直接価値を提供するコア機能）で、水面下の部分がコントロールプレーン（SaaSで共通的に必要な機能群）になります。コントロールプレーンには、認証・認可機能、テナント管理、ユーザー管理など、どのSaaSでも競争力を保つために必要不可欠な機能が含まれます。



SaaSus Platformはこのコントロールプレーンの機能群を提供することで、SaaS事業者が顧客への直接的な価値提供に集中できる環境を整え、開発生産性の向上を実現します。

導入形態としては、コントロールプレーンの機能群をAPIとして提供し、さらにそのAPIをラップしたSDKをライブラリとして提供しています。お客様はSaaS環境にこのSDKをインストールすることで、必要なAPI機能を簡単に呼び出すことができます。

また、SaaS開発コンソールと運用コンソールも提供しており、ウェブ画面からSaaSの設定値確認やユーザー登録などの操作が可能です。デフォルトでログイン画面も提供されるため、SaaSの初期立ち上げを迅速に行うことができます。

SaaSus Platform開発において、LaunchDarklyを2つの用途で活用しています。1つ目がデプロイとリリースの分離、2つ目がリリースターゲットの制限です。

デプロイとリリースを分ける

SaaSus PlatformのAPI機能群開発において、2つの課題を抱えていました。

第一の課題は「機能完成まではソースコードをマージできない」という制約です。マージをするとすぐにデプロイされてしまうため、すべての機能が完成するまでマージを控える必要がありました。第二の課題は「決められたリリースタイミングまでソースコードをマージできない」という時間的制約です。



これらの課題により、機能A、B、C、Dすべてが完成するまでAPI機能の開発が完了せず、長期間の開発期間中にバグやコンフリクトが混入し、最終的なリリース時に問題が発覚するケースが多発していました。

従来の解決策として環境変数による制御やコードのコメントアウトなどが考えられますが、これらの手法では実際のリリース時にコードの修正とデプロイが必要となり、工数とリアルタイム性の両面で問題がありました。さらに、バグが発生した場合のロールバックでも同様の作業が必要となり、復旧時間の長期化という深刻な問題を抱えていました。

LaunchDarklyを導入することで、新機能をフィーチャーフラグで囲み、機能をオフ状態でコードをマージ・デプロイすることが可能になりました。これにより、デプロイ済みでありながら機能はリリースされていない状態を実現し、機能完成やリリース日を待たずにプルリクエストを細かく迅速にマージできるようになりました。

管理画面からのフィーチャーフラグオン/オフ操作により、リリースのリアルタイム性を担保し、問題発生時にはワンクリックでのロールバックも実現しています。

リリースターゲットを制限する

ベータ版機能を特定の顧客のみに提供したい場合や、申請のあった顧客にのみ機能を提供したい場合があります。

LaunchDarklyではフィーチャーフラグ確認時にコンテキストを渡すことができます。SaaSの契約単位であるテナントのIDをコンテキストに含めることで、そのテナントがベータ版機能を使用可能かどうかを判定し、true/falseの結果を返すシステムを構築しました。

具体的には、LaunchDarkly側に有効化リストを保持し、テナントAとBは使用可能、テナントCは使用不可といった制御を行います。問い合わせに対して適切な権限判定を返すことで、ベータ版機能の特定顧客への限定リリースを実現しています。



さらに注目すべき点として、IaCであるAWS CDKでもLaunchDarklyを活用しています。ベータ版機能提供時に専用データベースやサーバーが必要な場合、利用申請されたタイミングでリソースを立ち上げることでコスト最適化を図ることができます。

AWS CDKはTypeScriptやGoなど、アプリケーション開発で使用される言語で記述できるため、API側とCDK（インフラ）側の両方で同一言語を使用し、どちらからもLaunchDarklyのフィーチャーフラグを参照することが可能です。LaunchDarklyが様々な言語のSDKを提供しているため、アプリケーションと同様にインフラ側でもフィーチャーフラグを利用できる点は、非常に画期的だと考えています。



SaaSus Platform開発において、LaunchDarkly導入により既存実装を大幅に変更することなく、次の2点を実現できました。第一にデプロイとリリースの分離、第二にリリースターゲットの制限です。

弊社では常に「自社開発部分の最小化」を提唱しており、顧客への直接的価値提供部分にフォーカスすることで開発生産性向上を実現しています。フィーチャーフラグの活用にはLaunchDarklyを、SaaS開発にはSaaSus Platformをご活用いただければと思います。

エクセルソフト社によるライブデモ

田淵：エクセルソフトは開発者向けのソフトウェア、ライブラリの販売・サポートを専門とする代理店です。主要事業として、ソフトウェア、ドキュメントのローカライズ、海外製品の輸入・販売を行っています。近年は特に、クラウド・DevOps系、AI・機械学習系、CI/CD系の開発者特化製品を数多く取り扱っています。



本日のLaunchDarklyデモでは、参加者の皆様のスマートフォンを使用してフィーチャーフラグの動作をリアルタイムで確認していただけます。提示したQRコードを読み取り、専用ウェブサイトにアクセスしてください。



デモ環境として、銀行アプリケーションを想定したサマリーアカウント画面を用意しました。画面右上のユーザーアイコンから「Switch User」機能を使用することで、複数のユーザーアカウント間で簡単に切り替えが可能です。



LaunchDarkly管理画面の左側には、フラグ、AIコンフィグ、ガーデットロールアウトなどの設定項目が配置されています。フラグ機能では、ウェブサイトのページ内にif文形式でフラグ名を設定し、表示対象機能をtrue、非表示機能をfalseとして定義します。実際の評価はLaunchDarkly側で実行され、その結果に基づいて機能の表示・非表示が制御されます。

現在の設定では、ベータユーザーのみにウェルスマネジメントコンポーネントが表示されるよう構成されています。クイックログイン機能でアリーシャさんというベータユーザーを選択していただくと、特別な機能が表示されます。通常ユーザーには表示されない「Start Now」という要素が画面下部のグラフ付近に表示されているのが確認できます。



次に、段階的な機能展開を行うプログレッシブロールアウト機能をご紹介します。この機能では、全ユーザーを対象としながらも、時間軸に沿って段階的に機能を展開することができます。

本日のデモでは、最初の1分間で25%のユーザーに機能を展開し、その1分後に50%、最終的に3分後に100%のユーザーが機能を利用できる設定を行いました。フロントエンドがReactで構築されているため、リアルタイムでの状態更新が可能で、ページのリロードなしに自動的に機能が表示される仕組みになっています。

デプロイ時の安全性を確保するため、閾値設定による自動ロールバック機能「ガーデットロールアウト」も提供されています。この機能では、エラー率、APIレイテンシー、データベースレイテンシーなど、複数の監視指標を設定できます。

例えば新しいデータベースを導入した場合、これらの指標が事前に設定した閾値を超えると、自動的に以前の状態にロールバックされます。展開期間についても柔軟に設定でき、1週間での段階的展開では1日ごと、または10時間ごとといった細かな制御が可能です。

このように、LaunchDarklyは安全なリリース実行のための包括的な機能群を提供しています。

AIの設定では、GeminiとClaudeを50%ずつ振り分けられます。同一のプロンプトを使用しながら、異なるモデルでの結果を並行してテストできます。ユーザーからのフィードバック（「良かった」「悪かった」）を収集することで、コスト効率とユーザー満足度の両面から最適なモデルを選択することが可能になります。

Q&Aセッション

デモンストレーション終了後、会場から複数の技術的な質問が寄せられました。

設定情報管理とシークレット情報の扱いについて

Q：このフィーチャーフラグの管理の仕組みにおいて、フィーチャーフラグとして使う以外の、よりスタティックな設定情報を使うためのロールアウトに利用すること、特にシークレット情報の扱いについて、ベストプラクティスを教えてください。

Sean：とても良い質問です。非常によくあるユースケースですね。フィーチャーフラグに機密情報を保存することは推奨しません。しかし、動的に設定を変更できることが、弊社プラットフォームの大きな利点です。リージョンごとに設定が異なる場合の対応例として、ユーザーのリージョン判定後にフィーチャーフラグでアプリケーションの接続先リージョンエンドポイントやデータベーススキーマを指定することが可能です。

その他の活用例として、ワーカーアプリケーションの並行処理数制御、顧客クラス別のAPIレート制限設定があります。企業間取引では、特定顧客に対して1分あたりのAPIリクエスト数を優遇的に設定するフラグ構成も実現できます。

フラグ管理とソースコード連携について

Q：フィーチャーフラグそのものの管理について、誰がどのフィーチャーフラグを作っているか全体把握する人間がいない状況や、ロールアウト後の自動削除、エラー監視サービスとの連携は可能でしょうか？

田淵：基本的に完全自動化は困難ですが、クリーンアップ機能が提供されています。フラグ作成者はメインテナーとして記録され、管理可能です。コードリファレンス機能により、GitHubやGitLabとの連携でフラグの使用箇所を追跡できます。未使用フラグについてはアーカイブ機能があり、トランクベース開発においてフィーチャーフラグ版と完全版を並行開発し、完全版への移行後にフラグを削除する運用が可能です。

Sean：Sentryとの連携には対応しています。コードリファレンス機能では専用ユーティリティをCI/CDパイプラインで実行し、コードリポジトリからの参照取得が可能です。ロールベースアクセス制御により、フラグのアーカイブや削除には承認プロセスを設定できます。全アクションの監査証跡も保持され、コンプライアンス要件に対応しています。

API接続とエクスポート機能について

Q：LaunchDarklyの設定に対してAPIアクセスや、コードとして管理するといったやり方は可能でしょうか？

Sean：LaunchDarklyへのAPI接続には完全に対応しています。例として、TerraformプロバイダがAPIを活用している事例があります。公開APIはロールベースアクセス制御に対応しており、ロール連携トークンにより機能制限が可能です。環境構築全体やAPIによるフラグ状態変更も実現でき、高い拡張性を提供しています。

設定データはAPI経由でのエクスポートに対応し、データエクスポート機能によりコンプライアンス強化も可能です。フラグ評価データの詳細分析が必要な場合、どのフラグ値がどのユーザーにいつ送信されたかを追跡し、データウェアハウスへの送信による長期保存・分析も実装できます。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です