フィーチャーフラグとは｜4分類と段階リリース・運用の注意点
最終更新日：2026/10/10
フィーチャーフラグとは、コードを再デプロイせずに機能のオン・オフを切り替える仕組みです。デプロイと機能公開を切り離せるため、段階リリースや障害時の緊急停止ができます。一方で消し忘れたフラグはそのまま負債になります。4つの分類と、公開から撤去までの運用手順を、参画先で実際に触るエンジニア向けに整理しました。
先に結論
フィーチャーフラグは「デプロイ＝公開」をほどく仕組み。コードを出荷しても、フラグがオフなら利用者には見えません
分類はリリース／実験／Ops／権限の4つ。寿命と切り替えの動的さが違うため、同じ運用ルールで扱うと必ず事故ります
段階リリースは社内→1%→5%→25%→50%→100%のように刻む。日次のトラフィックが一定量あるWebサービスでは、各段で30分程度は指標を観察してから次へ進める運用がよく採られます
最大の失敗はフラグ負債。作成時に撤去期限とチケットをセットで作る運用が、消し忘れの抑制につながります
ツールはSaaS・OSS・クラウド標準機能の3択。OpenFeatureという共通APIを挟んでおくと、後からの乗り換え余地を残せます
この記事でわかること
フィーチャーフラグの仕組みと、環境変数やブランチ運用との違い
4分類（リリース／実験／Ops／権限）の使い分けと、それぞれの想定寿命
段階リリースの刻み方、観察すべき指標、切り戻しの判断基準
カナリアリリース・ブルーグリーンデプロイとの関係の整理
フラグ負債を防ぐ命名・デフォルト値・撤去期限の設計
参画先でフラグ運用に合流するとき、初週に確認しておきたいこと
想定読者は、Webアプリやバックエンドの開発・運用に携わるエンジニアです。実務経験の年数は問いませんが、CI/CDパイプラインに触れたことがあると読みやすい内容になっています。
目次
フィーチャーフラグとは｜デプロイと機能公開を切り離す仕組み
フィーチャーフラグの4分類｜寿命と動的さで使い分ける
段階リリースの進め方｜0%から100%までの刻み方
カナリアリリース・ブルーグリーンとの違い
実装と運用の設計｜命名・デフォルト値・撤去期限
ツールの選び方｜SaaS・OSS・クラウド標準機能
よくある失敗と対策｜フラグ負債・テスト爆発・権限事故
フリーランスエンジニアが参画先で確認しておくこと
まとめ
よくある質問
フィーチャーフラグとは｜デプロイと機能公開を切り離す仕組み
結論から言うと、フィーチャーフラグは「コードをデプロイすること」と「機能を利用者に見せること」を別々の操作に分ける仕組みです。条件分岐をコードに埋め込み、その分岐の判定値を外部から動的に変える。基本原理はそれだけですが、実務ではターゲティングの設計、変更履歴の記録、評価に失敗したときの挙動まで含めて考える必要があります。
従来、新機能を世に出す唯一の方法はデプロイでした。だから「リリース日＝デプロイ日」になり、デプロイは緊張する行事になります。不具合が出れば切り戻し、つまり再デプロイです。フィーチャーフラグはここを分離します。機能はとっくに本番に置いてあり、公開の判断は管理画面のスイッチひとつ。切り戻しも再デプロイ不要で、秒単位です。
マーティン・ファウラー氏のサイトで公開されているPete Hodgson氏の解説記事「Feature Toggles (aka Feature Flags)」が、この分野で最も参照される整理です。本記事の分類もこの枠組みを下敷きにしています。
フラグの評価はどこで起きるのか
フラグの実体は、次の2つの組み合わせです。
コード内の評価ポイント：「このフラグがオンなら新処理、オフなら旧処理」という分岐
外部の設定・ルール：オン／オフの値と、誰に対してオンにするかの条件
重要なのは2つめです。単なる真偽値ではなく、「ユーザーIDのハッシュ下位5%」「特定テナントのみ」「社内ドメインのアカウントのみ」といったターゲティングルールを持てる点が、設定ファイルとの決定的な差になります。
評価の場所はサーバーサイドとクライアントサイドの両方がありえます。クライアントで評価する場合、フラグの存在そのものがユーザーに見えてしまう点には注意が必要です。未公開の機能名がJavaScriptのバンドルに含まれていた、という漏洩は実際に起きています。公開前の機密性が高い機能は、サーバーサイドで評価してレスポンスに含めないのが安全側の設計です。
環境変数・設定ファイルとの違い
「環境変数で十分では」という疑問は当然です。違いは3点に集約できます。
観点 | 環境変数・設定ファイル | フィーチャーフラグ |
|---|---|---|
変更の反映 | 再起動・再デプロイが必要なことが多い | 無停止で即時反映 |
対象の絞り込み | 環境単位（全ユーザー一律） | ユーザー・テナント・割合単位 |
変更の記録 | Git履歴やサーバー設定に散る | 専用ツールなら誰がいつ変えたかを一元管理しやすい |
変更の記録については注意が必要です。監査ログはフラグという仕組みに備わっている性質ではなく、ツール側の機能です。自前実装や機能を絞ったOSS構成では、別途ログ設計を用意しなければ履歴は残りません。
逆に言えば、全環境で一律に切り替えられればよく、変更頻度も低い設定は環境変数のままで構いません。フラグ管理基盤を入れる価値が出るのは、段階的に対象を広げたい場合や、本番で即座に止めたい場合です。
ブランチでの機能開発（フィーチャーブランチ）との違い
両者は「未完成の機能をどこに置いておくか」の答えが違います。フィーチャーブランチはマージするまでブランチに隔離する。フィーチャーフラグは未完成のままmainにマージし、フラグで隠す。
後者を選ぶとブランチが長命化せず、コンフリクトの解消コストが下がります。トランクベース開発がフィーチャーフラグとセットで語られるのはこのためです。ただし「動かない中途半端なコードが本番に存在する」状態を許すことでもあります。フラグがオフでも、その分岐が原因で落ちないことはテストで担保しなければなりません。
ミニFAQ：小規模チームでもフィーチャーフラグは必要ですか？
3〜5名程度でデプロイが週1回以下なら、専用ツールの導入まではオーバースペックになりがちです。まずは真偽値1つの自前フラグで「緊急停止スイッチ」だけ作るところから始めても、十分に効果が出ます。
フィーチャーフラグの4分類｜寿命と動的さで使い分ける
結論として、フラグは4種類に分けて扱います。判断軸は「どれくらい生きるか（寿命）」と「どれくらい頻繁に切り替わるか（動的さ）」の2つです。この2軸が違うものを同じルールで管理しようとすると、撤去されるべきフラグが永住します。
分類 | 目的 | 想定寿命 | 切り替えの主体 | 撤去の責任 |
|---|---|---|---|---|
リリーストグル | 未完成の機能を隠したまま出荷する | 数日〜数週間 | 開発チーム | 必須。公開完了と同時に削除 |
実験トグル | 複数パターンを出し分けて効果を測る | 実験期間（数週間） | プロダクト・分析担当 | 必須。勝ち筋に寄せて削除 |
Opsトグル | 高負荷時や障害時に機能を止める | 数か月〜恒久 | 運用・SRE | 任意。残すなら棚卸し対象に |
権限トグル | 特定ユーザー層にだけ見せる | 恒久 | プロダクト・事業側 | 不要。機能の一部として扱う |
リリーストグル｜最も短命で、最も消し忘れられる
未完成の機能をmainにマージして出荷するためのフラグです。4分類の中で最も寿命が短い。公開が完了した瞬間に役目は終わります。
にもかかわらず、現場で最も残りやすいのがこれです。理由は単純で、公開が終わるとチームの関心が次の機能に移るから。だからこそ、リリーストグルだけは作成と同時に撤去チケットを切る運用が要ります。詳しくは後述の「撤去期限」で扱います。
実験トグル｜A/Bテストの土台にあたる層
ユーザーを分割して複数パターンを出し分け、結果を比較するためのフラグです。A/Bテストの「出し分け」部分を担当しているのがこのトグルだと考えると整理しやすくなります。
実験そのものの設計、つまりサンプルサイズの見積もりやSRM（割付比率のズレ）の検知、途中で結果を覗く「ピーキング」の扱いといった統計面は、フラグの話とは別の専門領域です。この領域に踏み込む案件の実情は「A/Bテスト基盤の開発案件｜必要スキル・単価と実験設計の実務」で扱っているため、本記事ではフラグ側の仕組みに絞ります。
Opsトグル｜キルスイッチとして常備する
運用側が本番の挙動を制御するためのフラグです。代表例がキルスイッチで、「重い推薦機能を一時停止する」「外部APIが不調なのでキャッシュ応答に切り替える」といった用途に使います。
障害対応の初動で「再デプロイせずに止められる手段が1つある」ことの価値は大きいです。一次対応の流れ自体は「障害対応の手順とポストモーテムの書き方｜一次対応から再発防止まで」で整理していますが、復旧手段の選択肢にキルスイッチを含められるかどうかで、初動の所要時間は変わります。
Opsトグルは恒久的に残ることがある数少ないフラグです。ただし「残してよい」と「放置してよい」は別です。半年に1回は、そのスイッチが今も正しく動くかを確認しておきたいところ。
権限トグル｜料金プランや社内向け機能の出し分け
「有料プラン契約者のみ」「管理者ロールのみ」といった、ビジネスルールに基づく出し分けです。これは恒久的に存在して構いません。というより、もはやフラグというよりアプリケーションの仕様そのものです。
実務上の注意は、権限トグルを他の3種と同じ基盤で管理するかどうかの判断です。フラグ管理ツールに寄せると一元管理できますが、認可ロジックが2箇所（アプリのロール管理とフラグ基盤）に分散します。認可はアプリ側に持ち、フラグ基盤には置かないという切り分けを採るチームもあります。
安全側の設計としては、後者を勧めます。認可判定そのものをフラグの設定値だけに依存させると、管理画面での設定ミスがそのまま権限事故に直結します。フラグで出し分けるのは画面や導線の表示までにとどめ、最終的な認可判定はアプリケーション側のロール管理で担保する。この二重化があれば、フラグ設定を誤っても権限そのものは守られます。
ミニFAQ：分類が曖昧なフラグはどう扱えばいいですか？
迷ったら寿命の短い側に寄せて登録します。リリーストグルとして撤去期限つきで作り、恒久化が必要と判明した時点でOpsトグルや権限トグルへ分類変更する。逆方向（恒久として作って後で消す）は、まず消えません。
段階リリースの進め方｜0%から100%までの刻み方
段階リリースは「対象を広げる刻み」と「各段での観察時間」をあらかじめ決めてから始めます。その場の判断で広げると、必ず急ぎすぎます。
ロールアウトの刻み方
以下は、日次アクセスが数万規模以上あるBtoC寄りのWebサービスを念頭に置いた刻みの一例です。業種・規模によって適切な刻みは変わります。
社内ユーザーのみ（ドッグフーディング）：1〜3日
1%：30分〜数時間
5%：半日〜1日
25%：1日
50%：1日
100%：完了。フラグ撤去チケットを着手可能に
数字自体は絶対ではありません。日次のトラフィックが少ないサービスで1%にしても、エラーが1件も出ないまま30分が過ぎるだけです。重要なのは割合ではなく、異常を検知できるだけのサンプルが各段で集まるか。トラフィックが小さいサービスでは、1%を飛ばして5%から始める判断も合理的です。
各段で何を見るか
見る指標は、機能固有の指標と、サービス全体の健全性指標の2層で用意します。
機能固有：当該機能のエラー率、レイテンシ、完了率
全体：5xx率、p95レイテンシ、主要CVの推移、関連するキューの滞留
ここで効いてくるのがフラグの値をテレメトリに乗せているかです。フラグのオン／オフでメトリクスを分けて見られないと、「全体のエラー率はわずかに上がったが、新機能が原因かは分からない」という最悪の状態になります。OpenTelemetryとは｜可観測性標準の仕組み・導入の流れ・案件動向で扱っている属性付与の考え方をそのまま適用し、スパンやログにフラグ名と評価結果を属性として載せる設計にしておくと、後の調査が段違いに楽になります。監視基盤側で分けて見る方法は「Datadogとは｜統合監視SaaSの特徴・Sentryとの違い・案件単価を徹底解説」も参考になります。
切り戻しの判断基準を先に決める
ロールアウト前に「どうなったら戻すか」を文章で決めておきます。後から決めると、必ず「もう少し様子を見よう」に傾きます。
決めておく内容は、たとえば次のような形です。
当該機能のエラー率がベースラインの2倍を10分継続したらオフ
サービス全体のp95レイテンシが20%以上悪化したらオフ
判断者は当番のオンコール担当。合議を待たずに止めてよい
最後の1行が実は一番大事です。止める権限が曖昧だと、止めるべき場面で誰も止めません。
ミニFAQ：フラグをオフに戻せば必ず元に戻りますか？
戻らないケースがあります。新機能がデータベースに新しい形式でデータを書き込んでいた場合、フラグをオフにしても書き込まれたデータは残ります。旧コードがその形式を読めなければ、オフにした後で壊れます。データの書き込みを伴う変更では、旧コードが新形式を読める状態にしてから出す、といった順序の設計が別途必要です。
カナリアリリース・ブルーグリーンとの違い
この3つは競合する選択肢ではなく、効く層が違う手法です。並べて比較されがちですが、実務では組み合わせて使います。
手法 | 何を切り替えるか | 粒度 | 切り戻しの速さ | 特定ユーザーへの出し分け |
|---|---|---|---|---|
フィーチャーフラグ | アプリ内の機能単位 | 機能・ユーザー属性 | 即時（秒） | 可能 |
カナリアリリース | 新バージョンへ流すトラフィック | サーバー・Pod単位 | 速い（分） | 原則不可（割合のみ） |
ブルーグリーンデプロイ | 環境まるごと | 環境単位 | 速い（分） | 不可 |
ローリングアップデート | インスタンスを順次入れ替え | インスタンス単位 | 遅い（再展開） | 不可 |
カナリアリリースの考え方はマーティン・ファウラー氏の解説にまとまっています。インフラ層でトラフィックを分割する手法で、Istioとは｜サービスメッシュの仕組み・Kubernetes運用での役割を解説で触れているサービスメッシュや、ArgoCDとは｜GitOpsの仕組み・Kubernetes運用と案件動向のようなデプロイツールが担当します。
違いを一言で言えば、カナリアは「どのバージョンのコードを動かすか」、フィーチャーフラグは「動いているコードの中でどの経路を通すか」です。だから、新バージョンをカナリアで25%に流しつつ、その中の新機能をフラグで社内ユーザーだけに見せる、という重ね方ができます。
マイクロサービスとは｜モノリスとの違い・採用判断・案件動向を解説で扱っているようなサービス分割済みの構成では、インフラ層の切り替えだけでは粒度が粗すぎる場面が出ます。サービス単位では止めたくないが、その中の一機能だけ止めたい。そこを埋めるのがフラグです。
実装と運用の設計｜命名・デフォルト値・撤去期限
ここが運用の成否を分けます。ツール選定より先に決めるべき3点を挙げます。
命名規則を最初に決める
フラグ名は後から変えにくいため、最初に型を決めます。実務で機能しやすいのは、種別・対象・内容・作成時期が読み取れる形式です。
例：release_checkout_new_payment_202610（リリーストグル／決済画面／新決済フロー／2026年10月作成）
ポイントは先頭の種別と末尾の年月です。先頭に種別を置くと一覧がソートで分類ごとに並び、末尾に年月を置くと古いリリーストグルが一目で分かります。「2024年のreleaseフラグが残っている」という状態が一覧を見た瞬間に発見できる、これだけで棚卸しのコストが下がります。
デフォルト値はフェイルセーフに倒す
フラグ管理基盤への接続が切れたとき、アプリケーションはどう振る舞うべきか。答えは「安全な側（多くの場合は旧挙動）に倒れる」です。
SDKが評価値を取得できない場合に返すデフォルト値を、評価ポイントごとに明示します。ここを省略して例外を投げる実装にすると、フラグ基盤の障害がそのままサービス全体の障害になります。フラグ基盤は単一障害点になりうるという前提で設計してください。多くのSDKはローカルキャッシュを持ちますが、キャッシュが空の起動直後が最も危険な瞬間です。
撤去期限（TTL）とチケットをセットで作る
フラグ負債を防ぐ最も実効性がある手は、これひとつです。
リリーストグルを作るPRと同じタイミングで、撤去チケットを起票する
期限の目安として作成から30日を置くチームが見られます。2週間スプリントなら2回分にあたり、これで終わらない公開は計画側に問題があるサインです
月1回、フラグ一覧を棚卸しする定例を15分でいいので設ける
期限超過のフラグ数を、チームのダッシュボードに出す
「後で消す」は消えません。消す作業が誰かのタスクリストに乗っていることが唯一の担保です。撤去のPRはレビューも軽いので、コードレビューの作法｜指摘の書き方・受け方と信頼される進め方で触れているような、小さく出して早く通す進め方と相性が良い作業でもあります。
ツールの選び方｜SaaS・OSS・クラウド標準機能
結論から言えば、まず自前実装で足りるかを検討し、足りなくなってからツールを入れるのが順当です。真偽値を数個管理したいだけなら、設定テーブル1つで十分なケースがあります。
選択肢 | 代表例 | 向いている状況 | 注意点 |
|---|---|---|---|
SaaS | LaunchDarkly、Split、Statsig | ターゲティングや実験機能まで必要 | 単価が高くなりやすい。外部依存が増える |
OSS（セルフホスト） | Unleash、Flagsmith、GO Feature Flag | 自社管理したい／コストを抑えたい | 運用工数が自前。可用性の担保も自前 |
クラウド標準機能 | AWS AppConfig、Firebase Remote Config | すでに該当クラウドに寄せている | 他クラウドへの移植性は低い |
自前実装 | 設定テーブル＋管理画面 | フラグ数が一桁、ターゲティング不要 | 増えた時点で破綻しやすい |
OSSではUnleashの公式ドキュメントが導入手順と運用の考え方の両方を扱っていて読みやすい部類です。クラウド標準機能ではAWS AppConfigのフィーチャーフラグや、モバイルで採用例の多いFirebase Remote Configが候補になります。
OpenFeatureで乗り換えの余地を残す
ツール選定で悩むなら、共通APIを挟んでおくという選択肢があります。OpenFeatureは、フラグ評価のAPIをベンダー非依存で標準化する仕様とSDK群です。アプリケーション側はOpenFeatureのAPIを呼び、裏側のプロバイダ（LaunchDarkly、Unleash等）を差し替えられる構造にします。
OpenFeature公式サイトによれば仕様とSDKが言語別に公開されており、CNCFのプロジェクトページでは本記事執筆時点でIncubatingステージに置かれています（2023年11月に同ステージへ移行）。最新の状況は公式ページで確認してください。
評価用のコードが全コードベースに散るのがフラグの性質である以上、後からの差し替えコストは極端に高くなります。最初から薄い抽象層を挟む価値は、このコストで正当化できます。自前実装から始める場合でも、OpenFeatureのインターフェースに寄せておくと移行が楽になります。
自前実装で足りるケースを見極める
次の条件をすべて満たすなら、ツール導入は先送りして構いません。
管理するフラグが常時10個以下で済む見込み
割合指定やユーザー属性でのターゲティングが不要
切り替えの頻度が月数回で、反映まで数分かかっても許容できる
監査ログ（誰がいつ変えたか）の要求が厳しくない
ひとつでも外れるなら、既存ツールを検討した方が結局は安く済みます。特にターゲティングと監査ログは、自前で作ると想像の3倍は手間がかかる部分です。
よくある失敗と対策｜フラグ負債・テスト爆発・権限事故
失敗1：フラグが消えず技術的負債になる
最も頻度が高い失敗です。数年前のリリーストグルが残り、もはや誰もオフにしたときの挙動を知らない。消そうにも影響範囲が読めず、触れないまま分岐だけが増えていきます。
対策は前述の撤去期限とチケット化ですが、すでに溜まっている場合の進め方も書いておきます。
フラグ一覧を出し、たとえば90日以上オン100%で固定されているものを抽出する（しきい値はリリース頻度に合わせて決めます）
そのうち、コード上の分岐が1箇所のものから着手する
分岐を削除し、オフ側のコードパスも合わせて削除する
1PRあたり1〜2フラグまでにとどめる
既存コードの整理を案件として扱う際の合意形成は「技術的負債とは｜リファクタリング案件の合意形成と単価への影響」が参考になります。フラグ撤去は影響範囲が明確で成果が数えやすいため、負債返済の実績づくりとしては着手しやすい部類です。
失敗2：フラグの組み合わせでテストが破綻する
独立したフラグが3つあれば組み合わせは8通り、5つで32通り、10個で1024通りです。全網羅は現実的ではありません。
対策は組み合わせを減らすことと、検証対象を絞ることの2方向です。
同時に検証中のリリーストグルを同一機能領域で2つまでに制限する
CI上のテストは「全フラグがオフ（現行動作）」と「検証対象のフラグのみオン」の2パターンに絞る
実際のユーザー導線はPlaywrightとは｜E2Eテスト自動化の基本・Cypressとの違い・案件単価をフリーランス視点で解説で扱うようなE2Eで、本番相当のフラグ設定を読み込んで検証する
CIで全組み合わせを回そうとすると実行時間が爆発します。GitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説のようなパイプライン上では、マトリクスを増やす前にパターンを絞る判断が先に要ります。
失敗3：本番フラグの変更権限が広すぎる
フラグの切り替えは、実質的に本番の挙動変更です。にもかかわらず、デプロイには承認フローがあるのにフラグ変更は誰でも押せる、という状態がしばしば発生します。
本番環境のフラグ変更はロールで制限する（開発環境は自由、本番は限定メンバー）
変更時に理由の入力を必須にする
変更をSlack等へ自動通知し、記録を残す
100%公開への最終変更だけは2名承認とする運用も有効です
「障害調査で直前のデプロイを確認したが何も出ていない。実はフラグが切り替わっていた」というのは、起きると原因特定が長引く典型です。フラグ変更履歴をデプロイ履歴と同じ時系列で見られるようにしておきたいところ。
フリーランスエンジニアが参画先で確認しておくこと
フィーチャーフラグは、参画してすぐ既存の運用に合流する類の仕組みです。ルールが明文化されていない現場も珍しくありません。
参画初週に確認する5項目
フラグの総数と、リリーストグルの最古の作成日：負債の量が一目で分かります
撤去のルールが明文化されているか：なければ、自分が作るフラグだけでも期限を切る
本番フラグの変更権限は誰が持つか：自分に権限があるのか、依頼するのか
切り戻しの判断権限：オンコール時に自分の判断で止めてよいのか
フラグの値がログ・メトリクスに出ているか：出ていなければ調査が難航する前提で動く
特に3と4は、契約上の責任範囲とも関わります。本番を止める権限がないまま障害対応だけ求められる構造になっていないか、参画前の面談段階で確認しておくと安心です。面談で何をどこまで聞くかは「エンド面談と営業面談の違い｜段階ごとの目的・準備・所要日数」が参考になります。
短期参画でフラグを残さない進め方
契約期間が3〜6か月の参画では、自分が作ったリリーストグルを自分で消して出るのが原則です。残したまま離任すると、残されたチームは「消していいか分からないフラグ」を抱えることになります。
契約終了の1か月前に、自分が作成したフラグを棚卸しする
公開完了済みのものは撤去PRを出す
期間内に消しきれないものは、撤去手順をドキュメント化して引き継ぐ
この一手間は、継続契約の判断材料として見られている部分でもあります。
案件でフィーチャーフラグの経験はどう効くか
正直に書くと、「フィーチャーフラグ経験者募集」という形で単独のスキルとして求人が立つことは、公開案件を見る限りではほぼありません。評価されるのは、その周辺にあるリリース設計・可観測性・障害対応をまとめて語れることです。
そのため、フラグ運用の経験はSRE・プラットフォームエンジニア・DevOps寄りのポジションで効いてきます。該当する職種の実情は次の記事で整理しています。
スキルシートに書くときは、「フィーチャーフラグを導入」ではなく「段階リリースの設計と、フラグ撤去の運用ルール策定を担当。フラグ総数を◯件から◯件に削減」のように、担当範囲と数値をセットで書くと伝わりやすくなります。単価を体系的に上げる考え方は「フリーランスエンジニアの単価相場と単価の上げ方」で整理しています。現在の自分がどの程度の単価を狙えるか確認したい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。
導入前チェックリスト
これから導入する立場なら、次を埋めてから着手すると後の揉め事が減ります。
確認項目 | 決めること |
|---|---|
命名規則 | 種別・対象・年月を含む形式を1つに固定 |
分類 | 4分類のどれに当たるかを登録時に必須入力 |
撤去期限 | リリーストグルの既定値を決める（30日を置くチームが多い） |
デフォルト値 | 基盤接続不可時に旧挙動へ倒す方針を明文化 |
権限 | 本番変更が可能なロールを限定 |
可観測性 | フラグ名と評価結果をログ・メトリクスに付与 |
棚卸し | 月次15分の定例と、期限超過フラグの可視化 |
切り戻し基準 | 指標・閾値・判断者を事前に文書化 |
リリースの頻度や変更失敗率といった指標でチームの状態を測りたい場合は、DORAが公開している指標の定義が出発点になります。フィーチャーフラグは変更失敗率とサービス復旧時間に効く施策として位置づけると、導入の説明がしやすくなります。
まとめ
フィーチャーフラグとは、デプロイと機能公開を切り離し、段階的な公開と即時の緊急停止を可能にする仕組みです。効果を出す鍵は導入ではなく、撤去まで含めた運用ルールを先に決めることにあります。
フラグはリリース／実験／Ops／権限の4分類。寿命が違うため、同じルールで管理しない
段階リリースは社内→1%→5%→25%→50%→100%のように刻み、各段での観察時間を事前に決める（トラフィックが十分なサービスでは30分程度が一つの目安）
切り戻しの閾値と判断者を事前に文書化する。合議待ちにしない
リリーストグルは作成時に撤去期限（目安30日）と撤去チケットをセットで作る
フラグ名と評価結果をログ・メトリクスに載せる。載っていないと原因の切り分けができない
基盤接続不可時は旧挙動に倒す。フラグ基盤を単一障害点にしない
ツールはSaaS・OSS・クラウド標準機能の3択。OpenFeatureを挟むと乗り換え余地が残る
次の一歩としては、いま参画している現場のフラグ一覧を出して、最も古いリリーストグルの作成日を調べるところから始めるのが手軽です。その1件が3年前のものだったなら、本記事の「よくある失敗1」の手順がそのまま使えます。
参照した一次情報は次のとおりです。
よくある質問
フィーチャーフラグとフィーチャートグルは違うものですか？
同じものを指します。「フラグ」「トグル」「スイッチ」はいずれも同義で使われており、文献によって呼び方が揺れているだけです。日本語では「フィーチャーフラグ」が使われる場面が多い印象ですが、どちらで話しても通じます。
フラグが増えすぎると性能に影響しますか？
評価処理そのものはローカルキャッシュ上の判定なので、通常は無視できる水準です。影響が出るのは別の2点です。ひとつは初回起動時に設定を取得する待ち時間、もうひとつは分岐が増えることによる可読性とテストコストの悪化です。後者の方が現実的な問題になります。
フラグの設定はGitで管理すべきですか？
目的次第です。設定をコードリポジトリに置けば変更履歴がPRとして残り、レビューも通せます。一方で無停止での即時変更という利点が失われます。実務では、Opsトグルや権限トグルは管理画面から即時変更、リリーストグルの有効化ルールはGit管理、という使い分けも成立します。
データベースのスキーマ変更にもフィーチャーフラグは使えますか？
機能の見せ方は制御できますが、スキーマそのものの切り戻しはフラグでは戻せません。カラム追加のように後方互換のある変更は読み書きの経路をフラグで切り替えられます。カラム削除やリネームのような破壊的変更は、「追加→両方書く→読み替え→旧削除」という多段階の手順（Expand and Contractと呼ばれます）を踏む必要があり、フラグはその各段を安全に進めるための補助として使います。
モバイルアプリでもフィーチャーフラグは有効ですか？
むしろ有効性が高い領域です。アプリは審査とユーザーの更新を挟むため、不具合が出ても即座にコードを差し替えられません。Firebase Remote Configのような仕組みで審査を通さずに機能を止められることの価値は、Webより大きくなります。ただし端末側での評価になるため、未公開機能の情報がアプリ内に含まれる点には注意が必要です。
フラグの値をテストでどう扱えばよいですか？
ユニットテストでは、フラグ評価の部分をモックしてオン・オフ両方のケースを明示的に書くのが基本です。本番のフラグ基盤に接続してテストを回すと、外部の設定変更でテストが落ちるという厄介な状態になります。接続するのは、本番相当の設定を確認するE2Eの一部に限定するのが無難です。
フラグを導入すると開発速度は上がりますか？
短期的には下がり、中期的には上がる、というのが現実的な見立てです。導入直後は分岐の実装とテストの手間が増えます。効いてくるのは、ブランチの長命化によるコンフリクト解消や、リリース調整の待ち時間が減ってからです。導入の効果を見るなら、最低でも2〜3か月は回してから判断したいところ。
既存のフラグが大量に残っている現場に参画しました。どこから手をつけますか？
まず消さずに数えることから始めます。一覧を出し、「オン100%で90日以上」「オフ100%で90日以上」の2群に分けると、安全に消せる候補が見えてきます。オフのまま放置されているフラグは、機能そのものが不要になっている可能性が高く、分岐ごと削除できることが多いです。いきなり全部を整理しようとせず、週1〜2件のペースで進める方が通ります。
フィーチャーフラグとA/Bテストはどう使い分けますか？
A/Bテストは「どちらが良いかを統計的に判断する」ことが目的で、フィーチャーフラグはその出し分けを実現する手段にあたります。つまり対立する概念ではありません。ただし実験として扱うなら、割付の偏り検知や有意差の判定といった仕組みが別途必要です。実験基盤として作り込む場合の論点は「A/Bテスト基盤の開発案件｜必要スキル・単価と実験設計の実務」を参照してください。
フラグ管理ツールが落ちたらサービスも落ちますか？
設計次第です。SDKのローカルキャッシュと、評価不能時のデフォルト値を適切に設定していれば、サービスは旧挙動で動き続けます。逆にこれらを省略していると、フラグ基盤の障害がそのまま自社サービスの障害になります。導入時に「ツールが落ちたときの挙動」をテストで確認しておくことを強く勧めます。
アジャイル開発のスプリント運用とはどう組み合わせますか？
スプリント内に収まらない機能をフラグで隠したまま出荷し、完成したスプリントで公開する、という使い方が基本形です。これにより「スプリント末のリリース集中」を避けられます。アジャイル開発とは｜仕組み・スクラム・ウォーターフォールとの違いで触れているインクリメンタルな進め方と、相性の良い仕組みです。
関連するタグ：
