TL;DR
- Feature Flag は導入は簡単、運用と廃棄が難しい。zombie flag（消し忘れ）が技術債として積もる
- 選定軸：規模 / 機能要件 / コスト / セルフホスト要件。LaunchDarkly は機能完備でコスト高、Unleash は OSS 柔軟、自前は初期工数大
- フラグ種別を release / experiment / ops / permission の4分類 で管理し、ライフサイクルを分ける
- 廃棄ルール：「30日経過 + 100% rollout」は自動アラート → PR 自動生成 → レビュー後 merge
- A/Bテスト基盤と Feature Flag を統合運用するなら Statsig / Eppo が選択肢
この記事の目的と成功基準
- 目的: Feature Flag を持続的に運用するための選定・分類・廃棄ルールを実装粒度で整理する
- 想定読者: Platform / Backend エンジニア、リリース戦略を設計する EM
- 成功基準: 「Feature Flag 運用」「LaunchDarkly Unleash 比較」関連クエリでの流入、A/Bテストをエンジニア組織で回す への回遊
なぜ「運用が難しい」のか
Feature Flag の導入自体は1日でできる。SDK を入れて if (flag.isEnabled('new-checkout')) と書けば動く。
問題は半年後に起きる：
- リリース完了したフラグが残ったまま（zombie flag）
- 同じ機能に対するフラグが複数存在（重複）
- 誰がそのフラグを管理しているか不明（owner 不在）
- フラグ評価の latency がリクエスト全体を遅延
- 設定変更が監査ログに残らない
これらが積もると「Feature Flag を入れたせいで運用が重い」状態になる。
選定軸：3ツール比較
| 軸 | LaunchDarkly | Unleash | 自前 |
|---|---|---|---|
| 価格 | $$$ | $（OSS）or $$（SaaS） | 初期工数大 |
| 機能完備度 | ◎（ターゲティング・実験・監査） | ◯（OSS）/ ◎（Enterprise） | チーム次第 |
| SaaS / Self-host | SaaS のみ | 両対応 | self-host |
| 統計エンジン | 内蔵 | 別途 Eppo/Statsig 等 | 別途 |
| エンタープライズ機能 | RBAC / SSO / 監査 | Enterprise 版で同等 | 内製要 |
| 適性規模 | 中〜大 | 小〜中 | 大（特殊要件） |
LaunchDarkly が向くケース
- 100+ エンジニア、毎日 50+ flag 評価
- A/Bテスト + Feature Flag の統合運用
- SOC2 / GDPR コンプライアンス強要環境
- 内製運用したくない
Unleash が向くケース
- 50-200 エンジニア
- データ越境制限あり（self-host 要）
- OSS 文化、ベンダーロックイン回避
- コスト最適化優先
自前が向くケース
- 単機能の Feature Flag（実験不要）
- 既存設定管理（Config Server / etcd）と統合したい
- 1リクエストあたりレイテンシ要件が厳しい（< 1ms）
4分類モデル：ライフサイクルを分ける
すべての Feature Flag を同じルールで管理すると破綻する。4分類 で扱う：
| 種別 | 用途 | 推奨寿命 | 例 |
|---|---|---|---|
| release | 段階リリース・kill switch | 2-30日 | new-checkout-v2 |
| experiment | A/Bテスト | 14-28日（実験期間） | checkout-button-color |
| ops | 運用切替（緊急停止・負荷制御） | 永続 | enable-rate-limit |
| permission | ユーザー権限・プラン制御 | 永続 | premium-feature-x |
ライフサイクル別の運用：
- release / experiment：期限を frontmatter に必ず書く、期限超過は自動アラート
- ops / permission：permanent タグを付与、削除対象から除外
A/Bテスト記事 で扱った実験のフラグは experiment 種別、それ以外を混同しないこと。
zombie flag 自動検出
LaunchDarkly / Unleash 両方に「30日以上 100% rollout のフラグを検出」機能がある。これを活用：
# 週次 cron で実行
- name: detect zombie flags
run: |
ld-cli list-flags --filter "rollout=100,days>30,type=release" \
| gh issue create --title "zombie flag 整理候補" --body-file -
検出 → PR 自動生成 → コードレビュー → merge という流れ。手動運用は持続しない。
廃棄プロセス：5ステップ
zombie flag の安全な廃棄：
- Pre-check: 全環境で 100% rollout を確認、monitoring に異常がないか
- コード削除 PR:
flag.isEnabled()呼び出しを削除、両分岐どちらを残すか明示 - flag 設定アーカイブ: LaunchDarkly / Unleash 側で archive（即削除しない）
- 48h 経過: rollback 余地を残す
- 永久削除: 問題なければ flag を完全削除
「すぐ消す」と緊急時に再開できない。archive 経由必須。
レイテンシ最適化
Feature Flag 評価が遅いと全リクエストに乗る。最適化：
- client-side cache: SDK が local cache、TTL 5分〜1時間
- streaming: server push で設定変更を即時反映、polling より低 latency
- edge evaluation: Cloudflare Workers 等の edge で評価、API server を介さない
- bulk evaluation: 1リクエスト内で複数フラグを評価する場合は一括取得
評価 latency は p99 で 5ms 以内に保つ。これを超えると本番リクエストに影響。
監査ログの整備
「いつ・誰が・どのフラグを・どう変えたか」を全部残す。SOC2 / ISO27001 要件にもなる：
- フラグ変更 → 自動的に audit log
- 重要フラグ（決済・認証）は2人承認制
- 監査ログは別 storage に転送（改ざん防止）
LaunchDarkly / Unleash Enterprise には標準装備。自前なら別途実装要。
A/Bテスト基盤との統合
A/Bテスト記事 と組み合わせる場合：
| パターン | ツール組合せ |
|---|---|
| 統合型 | LaunchDarkly / Statsig / Eppo（Feature Flag + 統計エンジン内蔵） |
| 分離型 | Unleash（Flag）+ Eppo / Statsig（実験統計） |
| 自前統合 | 自前 Flag + 自前統計 |
中小規模は統合型推奨。大規模で要件が独自化したら分離型 or 自前。
アンチパターン
- すべてのフラグを永続化: 技術債が積もる、release タイプは必ず期限管理
- kill switch 不在: 緊急停止できない、ops タイプを最低1つ整備
- flag 評価を try-catch なしで使う: ツール側障害でアプリ全停止、デフォルト値を必ず指定
- 環境変数で代用: 環境変数は再デプロイ要、Feature Flag の意味がない
- flag の本番値を git に commit: 設定変更が PR 経由になり遅い、専用 UI 経由が原則
Growth Lab の運用例
参考：本サイト Platform チーム：
- ツール：Unleash self-host（10 FTE 規模、コスト最適化優先）
- 平均アクティブフラグ数：35（うち release 8 / experiment 4 / ops 12 / permission 11）
- zombie 検出：週次 GitHub Action、月平均 3-5 件廃棄 PR
- evaluation latency：p99 2.5ms（edge evaluation 採用）
FAQ
Q. 既存の Feature Flag が乱立しています、整理から始めるには？ A. まず4分類タグを全フラグに付与、release / experiment で30日以上稼働中を抽出します。そこから10件ずつ廃棄 PR を出していくのが現実的です。
Q. 自前で実装する場合の最低要件は？ A. 設定変更の即時反映（streaming or polling 30秒以内）・client-side cache・監査ログ・kill switch、この4つは最低必要です。
Q. Feature Flag と Config はどう使い分けますか？ A. Feature Flag = ユーザー単位・段階的・A/B 可能、Config = システム全体・即時・全ユーザー一律、と切り分けます。混同すると運用が破綻します。
まとめ
Feature Flag は導入後の運用と廃棄が本質。4分類モデルでライフサイクルを分け、zombie 自動検出と archive 経由廃棄を CI 化する。LaunchDarkly / Unleash / 自前の選定は規模と独自要件で決まる。A/Bテスト基盤との統合運用は中小規模なら統合型ツールが ROI 高い。フラグ債務管理は1年で土台、3年で文化定着の長期投資。
