フィーチャーフラグ とは？ SREが知るべき本質と運用
要約
フィーチャーフラグは、コードの経路を実行時に切り替える条件分岐です。再デプロイなしで新機能を止められるため、障害時の被害範囲を数秒で絞れます。フラグは種類ごとに寿命が違い、混ぜると負債になります。自作かプラットフォームかは、評価レイテンシ、料金体系、観測性への統合で比較してください。
03:12 です。チェックアウトのエラー率が 4% を超えました。原因の変更は 6 時間前にリリースされたものです。ただ、同じリリースに無関係な修正が 2 件含まれているため、全体を戻したくありません。この状況で、フィーチャーフラグ とは何でしょうか。
フィーチャーフラグとは、実行時に読み込まれる条件分岐です。コードのどの経路を実行するかを決めます。フラグを OFF にすれば、新しい経路は再ビルドもデプロイもなしに止まります。考え方はこれだけです。残りはすべて運用の話です。
フィーチャーフラグの正体と、そうではないもの
フィーチャーフラグは判断の分岐点です。コードのどこかに if 文があり、その値はバイナリの外から来ます。設定サービス、データベースの行、ベンダーの SDK、再起動なしで変更できる環境変数などです。
const useNewPricing = await flags.isEnabled("new-pricing-engine", {
userId: user.id,
plan: user.plan,
region: request.region,
});
return useNewPricing
? newPricingEngine.quote(cart)
: legacyPricing.quote(cart);このコードから 3 つのことが言えます。古い経路も存在し、動き続けている必要があります。ON と OFF より賢いことをするには、誰がリクエストしているかという文脈がフラグに必要です。そして評価処理はリクエストのホットパス上にあるため、そのレイテンシと失敗時の振る舞いが自分たちの問題になります。
「機能トグル」と「フィーチャーフラグ」は同じ意味で使われます。用語自体は重要ではありません。重要なのは振る舞いです。コードのデプロイと機能のリリースを切り離すのです。コードは本番に暗い状態で出し、誰に見せるかは後から人かシステムが決めます。
フラグは 4 種類ある。混ぜると運用が壊れる
フラグの苦労の多くは、すべてのフラグを同じものとして扱うことから来ます。Martin Fowler のフィーチャートグルの分類は、フラグの寿命と判断の動的さで分けています。実務でも通用する整理です。
リリートグルは一時的なものです。未完成の作業をフラグの裏に隠し、毎日 trunk にマージできるようにします。Fowler の指針では、寿命は 1〜2 週間を超えないのが望ましいとされています。判断は静的で、同じリリースに対するすべてのリクエストは同じ答えを受け取ります。
実験トグルは、異なるユーザーを異なるバリアントに振り分けます。統計的に有意な結果が出るまで、数時間から数週間残ります。それ以上は残しません。判断はリクエストごとです。
運用トグルは運用上の振る舞いを制御します。負荷時に重要度の低い機能を落とす、フォールバックの依存先に切り替える、重いクエリを無効にする、などです。その一部は長く残るキルスイッチになります。これらはリリースを必要とせず、数秒で切り替わる必要があります。
権限トグルは、プランや権利によって機能を制御します。何年も残ることがあり、判断はユーザーごと、リクエストごとです。
間違いは、4 種類すべてに同じライフサイクルを与えることです。権限トグルには永続的な所有者と監査ログが必要です。リリートグルは、作成した日に削除期限を決める必要があります。名前を見てどの種類か分からなければ、どれを安全に削除できるかも分かりません。
SRE がフラグを重視する理由は、被害範囲を絞るつまみ
プラットフォームチームにとって重要なのは A/B テストではありません。フラグによってリリースが「出来事」から「つまみ」に変わることです。
フラグがなければ、デプロイ 1 回で変更は全トラフィックに一斉に露出します。戻す唯一の方法は別のデプロイで、それにはパイプラインの時間と、人間が確信を持つまでの時間がかかります。フラグがあれば、ユーザーの 1% に露出させ、エラー率と p99 を見てから 5%、25%、50% と増やせます。被害範囲は自分が選んだ割合で決まり、戻すのは数秒で伝わる設定変更です。
これは、多くのツール投資よりも平均復旧時間を大きく変えます。事後検証の問いは「ロールバックに 40 分かかったのはなぜか」ではなく、「なぜこれがフラグの裏になかったのか」に変わります。
ただし、つまみには注意点があります。誰かがシグナルを見て、つまみを回さなければなりません。03:12 のその人は疲れています。役に立つフラグ運用は、つまみを SLO に結びつけます。エラー率が予算の一定割合を消費したら、人の介在なしにロールアウトを止めて戻すのです。多くのチームは、アラートツールからフラグ API への webhook を手作業で組んでいます。数百行ほどの作業で、最初に発動した夜に元が取れます。
請求書が届くとき：フラグの負債と Knight Capital の教訓
追加したフラグは、理論上そのコードの経路数を倍にします。実際には、いくつかの組み合わせをテストして、あとは祈ることになります。Fowler は、フラグを維持コストのある在庫として扱うことを勧めています。作成時に削除タスクをバックログに入れ、有効期限を設定し、最も厳格なチームでは、期限切れのフラグがまだコードに残っていればビルドを失敗させます。
この教訓の最も高くついた例が Knight Capital です。2012 年 8 月 1 日、新しいデプロイが、かつて廃止された機能を制御していた古いフラグを再利用しました。1 台のサーバーはデプロイを受け取らず、古いコードのまま動いていました。市場が開いてから最初の 45 分で、同社のルーターは 212 件の顧客注文を執行しようとする間に、400万件を超える注文を市場に送りました。これはSEC が Knight Capital に対して出した命令に記録されているとおりです。Fowler の記事は、約$460 million の損失を、管理されていないフラグへの警告として取り上げています。
この事故の原因はフラグだけではありません。手動デプロイ、キルスイッチの不在、検出の遅さも寄与していました。しかし、廃止されたフラグ名を再利用したという点は、すべてのプラットフォームチームが壁に貼っておくべき詳細です。フラグを再利用してはいけません。古いものを削除して新しいものを作り、削除を第一級の作業ステップにしてください。
自作するか、フラグ基盤を買うか
自作のフラグシステムは、設定ファイルと真偽値 1 つから始まります。1 つのサービスで最初の十数個のリリートグルまでは、それで問題ありません。しかし、ユーザーごとに安定したパーセンテージ展開、セグメント別のターゲティングルール、誰が何を変えたかの監査ログ、そしてフラグ変更が設定ストアに一斉負荷をかけず数秒で全インスタンスに届く仕組みが必要になると、続けられなくなります。
その時点で、測定可能な基準でプラットフォームを比較することになります。SDK の評価レイテンシ（ローカル評価かネットワーク呼び出しか）、更新がストリーミングかポーリングか、ターゲティングルールの粒度、複数環境のサポート、そしてトラフィックに対して料金メーターがどう伸びるか、です。
料金の仕組みは、機能一覧の違い以上に異なります。
LaunchDarkly はこのカテゴリのリファレンス実装です。ターゲティングは成熟しており、ガード付きリリースと深い統合の面を持っています。利用量課金で、サービス接続ごとと、クライアント側の月間アクティブユーザー千人ごとに課金されます。そのため、匿名ユーザーの多いコンシューマーアプリでは、バックエンドだけのチームとは違う形で請求額が動くことがあります。エンタープライズ規模でガバナンスと監査が必要なら、長く磨かれてきたという強みは本物です。
Statsig はフラグを実験機能およびプロダクト分析とまとめて提供し、イベント単位で課金します。フラグを主に実験の場として使うチームには合っています。主な用途が運用トグルとキルスイッチなら、読まないかもしれない分析に料金を払うことになります。また、2025 年 9 月以降にベンダーの所有者が 2 回変わっている点は、ベンダーリスクのレビューに一行書く価値があります。
どれを選ぶにしても、契約の前に障害モードを試してください。ステージングで SDK のネットワークアクセスを遮断し、アプリケーションが何をするか確認します。良い SDK は最後に知られたフラグ値をキャッシュから返し、大きくログを出します。悪い SDK はリクエストの経路をブロックします。
観測性はフラグシステムの半分
テレメトリのないフラグは推測にすぎません。最低限役立つ設定は、リクエストごとのフラグ状態を、そのリクエストのすべてのトレースとログ行に付けることです。そうすれば、エラーの急増が見えたときに、フラグのバリアントでグループ化して、新しい経路が原因かどうかを確認できます。
Datadog などのオールインワン基盤では、SDK がスパンにタグを付ければ、バリアントごとの内訳を簡単に見られます。ただし、フラグキー、バリアント、ユーザーセグメントのような高カーディナリティのタグを足すと、ホスト単位とシグナル単位の課金が急速に増えます。どの次元にタグを付けるかは意図的に選んでください。
Prometheus と OpenTelemetry をすでに運用しているなら、Grafana の方が安く済みます。フラグを意識したダッシュボードは自分で作る必要があり、エンジニアリング時間はかかりますが、出力するラベルを完全に制御できます。プラットフォームグループを持つ 50 から 500 人規模のエンジニア組織では、このトレードオフはしばしば正解です。
本番での最初のフラグのための短い運用手順
フラグを持たないチームに導入するなら、最初のロールアウトは退屈なものにしてください。
成功指標が明確な変更を 1 つ選びます。例えばチェックアウトのエラー率や、1 つのエンドポイントの p99 レイテンシです。
フラグには種類と所有者を含めて名前を付けます。例:
release.checkout.new-tax-calc.owner-payments削除チケットを今書き、有効期限を 2 週間以内に設定します。
1% に展開し、トラフィックの 1 周期を通して保持してから、段階的に増やします。どの閾値で戻すかは事前に決めておきます。
ロールバックは 1 つのコマンドかボタンにし、夜中に必要になる前にステージングで一度リハーサルします。
100% が数日間保たれたら、フラグと古いコードの経路を同じ変更でまとめて削除します。
地味なのは手順 6 です。これを飛ばしたチームは、数百個のフラグを抱え、その半分が何をするのか誰も知らず、リポジトリの中に Knight 型のリスクが残ります。
前回のインシデントがフラグの裏にあったら、どうなっていたか
チームが最後にまとめた本番インシデントを 1 つ思い出してください。3 つの質問をします。その変更は暗い状態で出せたか。デプロイなしで、1 分以内に 1 人が無効化できたか。どのバリアントが失敗しているかを、アラートが教えてくれたか。
3 つすべてが「いいえ」なら、最初のフラグ候補と、今の巻き戻しコストについての最初の正直な見積もりが手に入ります。事後検証は、その結論を述べるでしょう。より良い問いは、ページャーが鳴るまでに、その被害をどれだけ小さくできていたか、です。