フィーチャーフラグ運用：LaunchDarkly/Unleashで安全にリリースする
「デプロイ」と「リリース」を分離できると、コードは本番環境に配置しつつ機能の公開タイミングを 別途コントロールできる。フィーチャーフラグを使えば、 A/Bテストやカナリアリリースをコードのデプロイとは独立して制御できるようになる。
背景・現状の課題
デプロイと同時に機能を全ユーザーへ公開する方式では、問題発生時のロールバックが「再デプロイ」を 伴うため復旧に時間がかかる。また、新機能を一部ユーザーだけに先行公開してフィードバックを得る、 といった段階的な展開もデプロイの仕組みだけでは難しい。
代表的な2つのツール
| ツール | 提供形態 | 特徴 |
|---|---|---|
| LaunchDarkly | SaaS型のフィーチャーフラグ管理サービス | ターゲティング・A/Bテスト機能が豊富、大規模組織での実績が多い |
| Unleash | OSS（セルフホスト可能）のフィーチャーフラグ管理システム | 自社インフラ内で完結させたい場合や、コストを抑えたい場合に選ばれやすい |
実装上の落とし穴と対策
- フラグの整理不足：リリースが完了した機能のフラグを削除せず放置すると、コードベースに条件分岐が蓄積し可読性が下がる。フラグには「役目が終わったら削除する」運用ルールと、棚卸しの定例を設ける。
- フラグ評価のパフォーマンス影響：フラグの数が増えると、リクエストごとの評価コストが無視できなくなることがある。フラグ管理システム側のキャッシュ機構を活用し、評価のたびに外部APIを叩かない設計にする。
- 環境間の設定不整合：ステージングと本番でフラグの状態が食い違ったまま気づかず、本番だけで問題が発生することがある。環境ごとのフラグ設定を定期的に比較・可視化する仕組みを持つ。
A/Bテストとカナリアリリースへの応用
フィーチャーフラグは、単純なON/OFFだけでなく、ユーザー属性に応じたターゲティング（一定割合のユーザーのみ、 特定のプランのユーザーのみ等）にも使える。この仕組みを使えば、新機能を5%のユーザーにだけ公開して メトリクスを観察し、問題なければ段階的に対象を広げる、というカナリアリリース的な運用がデプロイ済みの コードに対して柔軟に行える。
まとめ
フィーチャーフラグは、デプロイとリリースを分離することで、ロールバックの高速化と段階的な機能公開を 実現する。導入効果を持続させるには、役目を終えたフラグを削除する運用ルールを最初から組み込んでおくことが重要である。
公式ドキュメント: LaunchDarkly Docs / Unleash Docs
