フィーチャーフラグとは？｜デプロイとリリースを切り離し、段階公開と計測をつなぐ仕組み

新しい機能を本番に出すとき、あなたのチームはどれくらい緊張しますか。リリース当日は全員が画面に張り付き、何かあればすぐに巻き戻せるよう身構えている、という光景は珍しくありません。

この緊張の正体は、多くの場合コードを本番に置くことと、ユーザーに機能を見せることが同じ瞬間に起きていることにあります。フィーチャーフラグ（feature flag）は、この2つを切り離すための仕組みです。

本記事では、フィーチャーフラグとは何か、どんな種類があり、プロダクトマネージャーや小さなチームがどう使い分けるべきかを体系的に整理します。あわせて、フラグを使った段階公開を計測とどうつなぐか、そして放置されたフラグが生む負債についても扱います。

フィーチャーフラグとは何か

フィーチャーフラグとは、コードの中に条件分岐を置き、その分岐をどちらに倒すかを外部の設定で切り替えられるようにする仕組みです。フィーチャートグル、機能フラグとも呼ばれます。

デプロイとリリースを分ける

ここで大事なのは、デプロイとリリースという2つの言葉を区別することです。デプロイはコードを本番環境に配置する技術的な作業で、リリースはその機能を実際のユーザーに使える状態にするビジネス上の判断です。

フラグがない世界では、この2つは同時に起きます。新しい決済画面のコードを本番に置いた瞬間に、全員がその画面を見ることになるわけです。

フラグがあれば、コードは先に本番へ置いておき、機能はオフのまま待機させられます。準備が整ったら、設定を変えるだけで公開できますし、問題があればコードを巻き戻さずに設定ひとつで止められます。

最小の形はただのif文

仕組み自体は驚くほど単純です。次の例は、設定値を読んで新旧どちらの画面を出すかを決めるだけのコードです。

// 説明用の擬似コード
if (flags.isEnabled("new-checkout", { userId, country, plan })) {
  renderNewCheckout()
} else {
  renderOldCheckout()
}

第2引数に渡している userId や国、プランといった情報は、評価コンテキストと呼ばれます。フラグの判定側は、このコンテキストを見てユーザーごとにオンかオフかを決めます。

つまりフラグは単なるオン・オフのスイッチではなく、誰に見せるかを細かく制御できる配信の仕組みでもあるのです。この性質が、後で触れる段階公開や実験につながっていきます。

フィーチャーフラグの4つの種類

ひとくちにフラグと言っても、目的によって寿命も扱い方もまったく違います。実務では、次の4つに分けて考えると整理しやすくなります。

短命なフラグと長命なフラグ

この表で一番大切なのは、寿命の列です。リリースフラグと実験フラグは使い終わったら消すことが前提の短命なフラグで、運用フラグと権限フラグは製品の一部として長く残ります。

この違いを意識せずに同じ管理方法で扱うと、消すべきフラグが何年も残り、残すべきフラグが誰かの片付けで消される、という事故が起きます。作るときに種類を決めておくだけで、後の掃除がずっと楽になります。

権限フラグは料金プランと地続き

権限フラグは、プロダクトの料金設計と直結しています。有料プランだけに出す機能や、一部の顧客にだけ先行公開するベータ機能は、多くの場合この種類のフラグで実装されています。

ここで注意したいのは、権限フラグは事実上の契約条件になるという点です。誤ってオフにすれば、お金を払っている顧客から機能を取り上げることになるため、リリースフラグよりも慎重な変更手順が必要になります。

段階公開（プログレッシブデリバリー）という使い方

フラグの最も代表的な使い方が、段階公開です。最初は社内だけ、次に全体の1%、5%、25%と、少しずつ公開範囲を広げていきます。

リングで少しずつ広げる

段階公開では、公開範囲の一段一段をリングと呼ぶことがあります。社内の従業員を最初のリングにし、次に早期アクセスを希望した顧客、最後に全ユーザーというように、外側へ向かって広げていくイメージです。

Microsoftの研究者による論文 Safe Velocity: A Practical Guide to Software Deployment at Scale using Controlled Rollout（ICSE-SEIP 2019）は、このリングによる段階公開と比較実験を組み合わせる考え方を、制御された展開（controlled rollout）として整理しています。論文では、どの母集団にどれだけの期間公開するか、各リングを通過させる判定基準をどう決めるかといった、実務上の論点が扱われています。

各リングに合否の基準を置く

段階公開を単なる時間稼ぎにしないためには、リングごとに次へ進む条件を先に決めておくことが欠かせません。条件がなければ、1%で公開したまま誰も数字を見ず、なんとなく翌週に100%にする、という形骸化が起きます。

次の表は、条件の書き方の一例です。数値はすべて説明用の仮定で、実際の閾値は自社の基準値から決めてください。

ここで見るべき指標は、改善したい主指標よりも、壊してはいけない指標が中心になります。エラー率や表示速度、決済完了率のように、悪化したら即座に止めるべき数字のことで、詳しくはガードレール指標とは？で整理しています。

フラグと実験・計測をつなぐ

段階公開とA/Bテストは、どちらもユーザーの一部にだけ新しい体験を見せるという点でよく似ています。ただし目的が違うため、両者を混同すると数字の読み方を誤ります。

段階公開と実験は問いが違う

段階公開が答えようとしている問いは、この変更で何かが壊れていないかです。一方、A/Bテストが答えようとしているのは、この変更で成果が上がったかです。

前者は安全確認なので、悪化の兆候が見えたらすぐ止めることが正解になります。後者は効果の推定なので、事前に決めた期間とサンプル数を守り、途中で結論を出さないことが正解になります。

同じフラグの仕組みで両方を実行できるのは便利ですが、いまどちらの問いに答えようとしているのかは、チームで明示しておく必要があります。安全確認のつもりで1%公開した期間のデータを、そのまま効果の証拠として報告してしまうのは、よくある失敗の型です。

振り分けの偏りに気をつける

フラグで群を分けるとき、意外な落とし穴になるのが振り分けの偏りです。たとえば、新しいアプリのバージョンを入れた人だけがフラグを評価できる場合、オンの群には自動更新をしている熱心なユーザーが集まりやすくなります。

こうした偏りがあると、群ごとの人数比が設計からずれ、効果の比較そのものが信用できなくなります。人数比のずれを検知する方法はSRM（サンプル比率の不一致）とは？で詳しく解説しています。

公開した機能が使われているかを見る

フラグをオンにしたあとは、その機能が実際に使われているかを確認する段階に入ります。公開しただけで満足してしまい、誰もボタンを押していないことに数か月後に気づく、というのはよくある話です。

ここで役立つのが、ページ単位やボタン単位の行動データです。フラグでオンにした画面への到達数、その画面内のボタンのクリック、そこから先のコンバージョンまでをファネルで追えば、公開が成果につながっているかが見えてきます。

機能の利用状況をどう測り、どう直していくかは、機能の定着率（アダプション）の記事が参考になります。たとえばMonaLensのようにCookieを使わずページやボタンの行動を記録できるツールでも、フラグごとの画面の違いをページやボタンの条件として指定すれば、この確認は十分に行えます。

作る前に確かめる道具としてのフラグ

フラグは完成した機能を安全に出すためだけの道具ではありません。まだ作っていない機能の需要を確かめるためにも使えます。

需要検証とフラグ

たとえば、新機能の入口となるボタンだけを一部のユーザーに表示し、どれくらいの人が押すかを測る方法があります。押した人には準備中である旨を正直に伝え、関心の強さだけを先に確かめるやり方です。

この手法はフェイクドアテストと呼ばれ、その設計と信頼を損なわないための注意点はフェイクドアテストとは？でまとめています。フラグがあれば、表示する対象や割合を後から自由に変えられるため、小さく試して反応を見るという動きが取りやすくなります。

小さなチームほど恩恵が大きい

フラグというと大企業の仕組みに聞こえるかもしれませんが、実は一人で開発するインディーハッカーやAIソロプレナーにこそ向いています。検証担当も運用担当もいない環境では、出してから戻すまでの速さがそのまま安全性になるからです。

たとえば、自分のアカウントだけで新機能をオンにして本番で触ってみる、問題なければ有料ユーザーの一部に広げる、という使い方なら、専用の検証環境を作らなくても本番の実データで確認できます。

フラグ負債と事故を防ぐ運用

便利なフラグにも、大きな副作用があります。それは、消し忘れたフラグがコードの中に積もり続けることです。

フラグ負債はなぜ生まれるのか

フラグが1つ増えるたびに、コードの通り道は2倍になります。10個のフラグが独立に存在すれば、組み合わせは理論上1024通りになり、そのすべてをテストすることは現実的ではありません。

しかもリリースフラグは、機能が全員に公開されて役目を終えた瞬間から、誰にとっても関心の外になります。消しても誰も褒めてくれず、消し忘れても当面は困らないため、放置されやすいのです。

古いフラグの再利用が招いた事故

フラグの管理不足が深刻な事故につながった例として、2012年に米国の証券会社ナイト・キャピタルで起きた売買システムの障害がよく知られています。広く知られている経緯では、使われなくなった旧機能を起動するためのフラグを新機能の起動用に転用したところ、新しいコードが行き渡っていなかった一部のサーバーで旧機能が動き出し、短時間で巨額の損失を出しました。

ここから学べるのは、使い終わったフラグを放置せず、フラグ名を別の用途に使い回さないことの重要性です。名前を再利用すると、どのコードがどの意味でそのフラグを読んでいるのかが、誰にもわからなくなります。

消すところまでを手順に組み込む

フラグ負債を防ぐ一番確実な方法は、作るときに消す日を決めることです。チームで最低限そろえておきたいルールは次の3つです。

• フラグを作るときに、種類（リリース・実験・運用・権限）と所有者と削除予定日を必ず記録する
• 全体公開が終わったリリースフラグは、次のスプリントで削除するチケットを自動で起票する
• フラグ名は使い回さず、役目を終えたものは新しい名前で作り直す

このルールに加えて、定期的にフラグの一覧を棚卸しし、長期間すべてのユーザーで同じ値を返し続けているものを洗い出すと効果的です。全員にオンのまま何か月も変わらないフラグは、多くの場合もう消してよいフラグです。

ベンダーに縛られない書き方

フラグ管理を専用のサービスに任せる場合、コードの中にそのサービス固有の書き方が広がっていきます。後から乗り換えようとすると、すべての分岐を書き換える必要が出てきます。

この問題に対しては、OpenFeatureという仕様が公開されています。フィーチャーフラグの評価APIをベンダー中立に定めたオープンな仕様で、アプリ側は共通のAPIで書き、実際の判定はプロバイダーと呼ばれる差し替え可能な部品に任せる設計になっています。

小さなチームなら、最初は設定ファイルや環境変数で十分です。ただし、フラグを読む箇所を1つの関数にまとめておくだけでも、後で専用ツールに移るときの手間は大きく変わります。

まとめ：フラグは「いつ見せるか」を設計する道具

フィーチャーフラグの本質は、デプロイとリリースを切り離し、誰に・いつ見せるかをコードの外で決められるようにすることです。これにより、段階公開で安全を確かめ、実験で効果を測り、需要検証で作る前に確かめる、という動きがひとつの仕組みの上で行えます。

一方で、フラグは作るよりも消すほうが難しい道具です。種類を決め、所有者と期限を記録し、使い終わったら消すところまでを手順に組み込んでおけば、フラグは負債ではなく、チームの速さと安全を両立させる資産になります。

まずは次のリリースで、1つだけリリースフラグを使ってみてください。社内だけで公開し、壊れていないことを確かめてから広げるという小さな体験が、リリースのたびの緊張を確実に和らげてくれるはずです。