LaunchDarkly：とは何か、フィーチャーフラグとその仕組み

LaunchDarklyとは？

LaunchDarklyは2014年にCatamorphic Corp.によって設立されたフィーチャーフラグ管理プラットフォームです。このサービスの主な目的は、開発チームが新しいコードをデプロイすることなく、アプリケーションの機能をリアルタイムで有効化、無効化、設定できるようにすることです。

新しい機能のリリースにアプリストアでのバージョン公開が必要な従来のアプローチとは異なり、LaunchDarklyではリモートで動作を変更できます。モバイル開発ではこれが特に重要です。App StoreやGoogle Playのレビューには数時間から1日かかりますが、フラグは数秒で切り替えられます。

LaunchDarklyプラットフォームの仕組み

LaunchDarklyのアーキテクチャは、フラグサーバー、クライアントSDK、ダッシュボードの3つのコンポーネントで構成されています。サーバーはフラグ設定、ターゲティングルール、ユーザーセグメントを保存します。SDKはリアルタイムで更新を受信するためにサーバーとの永続的なSSE接続を維持します。

ダッシュボードでフラグが変更されると、サーバーは接続されているすべてのSDKに更新を送信します。遅延は200〜500ミリ秒です。接続が失われた場合、SDKはチャネルが復元されるまで最後にキャッシュされた状態を使用します。これにより、アプリケーションは切断時点で利用可能な最新の設定で動作し続けることが保証されます。

LaunchDarklyダッシュボードは、フラグを作成および管理するためのビジュアルインターフェースを提供します。ダッシュボードには各フラグの現在の状態、誰がいつ設定を変更したかの監査履歴、および使用状況メトリクスが表示されます。環境ごとに個別のルールを設定できます。ステージングでは100％有効、本番では5％有効といった設定が可能です。

LaunchDarklyの主要概念

Feature flagはルールとターゲットを持つ名前付きスイッチです。フラグにはブール型、多変量型、JSON型があります。ルールは有効化条件を定義します。例えば、“ドイツのAndroid 12ユーザーの10％に対して有効化”などです。セグメントはOSバージョン、地域、デバイスモデル、カスタム属性でユーザーをグループ化します。

各フラグには開発、ステージング、本番の環境があります。これにより、実際のユーザーに有効化する前に、隔離された環境で新機能をテストできます。環境ルールは独立して設定されます。フラグはステージングで有効、本番で無効にすることができます。

SDKとモバイルアプリとの統合

LaunchDarklyはAndroid、iOS、React Native、Flutter用のネイティブSDKを提供しています。各SDKは最小限の設定（SDKキーとユーザー識別子）のみが必要です。ライブラリは接続、キャッシング、エラー処理を自動的に管理します。

Android SDKの初期化

接続するには、Application.onCreateでLDClientインスタンスを作成します。クライアントはモバイルキーとユーザーコンテキストを含む設定を受け入れます。初期化後、アプリケーションはboolVariationメソッドを使用してコード内の任意の場所でフラグバリエーションを呼び出します。

class MyApplication : Application() {
    private lateinit var ldClient: LDClient

    override fun onCreate() {
        super.onCreate()
        val config = LDConfig.Builder("mobile-key-abc123")
            .build()
        val user = LDUser.Builder("user-unique-id")
            .build()
        ldClient = LDClient.init(this, config, user)
    }
}

フラグ変更の読み取りと購読

初期化後、フラグの確認は1つのメソッドで行われます。BoolVariationはフラグルールに従って値を返します。デフォルト値は、SDKが設定を取得できなかった場合に使用されます。boolVariationDetailメソッドは、フラグがその値を取った理由を追加で返します。

val ldClient = LDClient.get()
val showNewFeature = ldClient.boolVariation(
    "new-checkout-flow",
    false
)
if (showNewFeature) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}

LaunchDarklyによるA/Bテストと段階的ロールアウト

LaunchDarklyでのA/Bテストは多変量フラグを通じて実装されます。各バリアントにはトラフィックの割合が割り当てられます。例えば、50％のユーザーが古い画面（バリアントA）、50％が新しい画面（バリアントB）を表示します。プラットフォームはユーザーを固定し、常に同じグループに属することを保証します。

段階的ロールアウトは、機能にアクセスできるユーザーの割合を徐々に増やします。典型的なスケジュール：1％（初日）、5％（2日目）、25％（3日目）、100％（1週間後）。エラーが検出された場合、フラグは全員に対して即座に無効化されます。LaunchDarklyはAmplitude、Mixpanel、Google Analyticsと統合して各バリエーションのメトリクスを追跡します。

メトリクスと実験

プラットフォームは、バリアント間の差異の統計的有意性を自動的に計算する組み込みの実験システムを提供します。利用可能なメトリクス：コンバージョン、リテンション、セッション数、エラー、カスタムイベント。結果は信頼区間の可視化とともにダッシュボードに表示されます。実験は本番トラフィックと専用ユーザーセグメントの両方で実行できます。

分析プラットフォームとの統合はLaunchDarklyのもう1つの利点です。フラグデータは自動的にAmplitude、Mixpanel、Google Analytics、またはData Export APIを介したカスタムデータパイプラインに送信されます。これにより、各機能がアプリケーションの主要メトリクスに与える影響についてのレポートを作成できます。LaunchDarklyはフラグ状態の変更について外部システムに通知するためのWebhookもサポートしています。

AndroidでのLaunchDarkly SDK統合例

完全なサイクルを見てみましょう。依存関係の追加、初期化、クラッシュテレメトリ用のフラグ確認です。この機能は実際のユーザーではなくテスターのみに対してアクティブである必要があります。Android用LaunchDarkly SDKはMaven Centralから入手できます。バージョン5.xはKotlin CoroutinesとJetpack Composeをサポートし、フラグ更新のリアクティブな受信を可能にします。

iOSアプリケーションの場合、LaunchDarklyはSwift Package ManagerとCocoaPodsをサポートしています。Swift SDKは非同期初期化にasync/awaitを、変更の購読にCombineフレームワークを使用します。両方のSDK（AndroidとiOS）は、オフライン操作のためのバックグラウンド同期とローカルストレージへのキャッシュをサポートしています。

build.gradleの依存関係

// app/build.gradle
dependencies {
    implementation "com.launchdarkly:launchdarkly-android-sdk:5.2.0"
}

CrashReporterでのフラグ確認

CrashReporterクラスでcrash-reporting-enabledフラグを確認します。現在のユーザーに対してフラグが有効な場合、クラッシュレポートの送信を開始します。サーバーで状態が変更されるとSDKは自動的に新しい状態を受け取りますが、初期化には1回の確認で十分です。

class CrashReporter {
    fun init() {
        val client = LDClient.get()
        if (client.boolVariation("crash-reporting-enabled", false)) {
            Crashlytics.start()
        }
    }
}

一般的なシナリオとアンチパターン

成功シナリオ：プロバイダ障害時の即時無効化による支払いフローの管理、メトリクス監視を伴うUI変更の段階的ロールアウト、セグメントごとのコンテンツパーソナライゼーション。LaunchDarklyの公式ブログによると、チームはエラー復旧時間を数時間から数分に短縮しています。

アンチパターン：恒久的な条件付きロジックへのフラグの使用（フラグは一時的）、フラグ属性への秘密情報の保存、重複するルールの作成。推奨事項：ロールアウト完了後はコードからフラグを削除してください。これにより技術的負債とコードベースの複雑化を防げます。もう1つの一般的な間違いは、機能が安定した後もコードから削除されない長期存続スイッチとしてフラグを使用することです。

適切なフラグ管理戦略には、新しいフラグごとに削除計画を含める必要があります。LaunchDarklyは未使用フラグを検出するための組み込みツールを提供しています。SDKが30日以上フラグの値を確認していない場合、そのフラグは未使用と見なされます。これらのフラグはダッシュボードでマークされ、コードから安全に削除できます。

LaunchDarklyを避けるべき場合

1つのチームで小規模なプロジェクトの場合、LaunchDarklyは過剰である可能性があります。コード内の単純な条件分岐やFirebase Remote Configで十分です。プラットフォームを選択するのは、複雑なセグメンテーション、変更監査、A/B実験、またはマルチチームでのフラグ管理が必要な場合です。スタートアップやMVPプロジェクト向けに、LaunchDarklyはフラグ数とMAUに制限のある無料のStarterプランを提供しています。

既存のツールとの互換性は重要な選択基準です。プラットフォームはJira、Slack、PagerDuty、DatadogなどのサービスとWebhookやAPIを介して統合します。これらのツールを既に使用しているチームは、フラグ状態変更の監視やアラートのための追加インフラストラクチャなしでシームレスな統合を実現できます。LaunchDarklyはコードとしてのフラグ管理（Flags as Code）のためのTerraformプロバイダもサポートしています。これにより、フラグ設定をGitに保存し、適用前にコードレビューを実施できます。