フィーチャーフラグ（フィーチャートグルとも呼ばれます）は、コードの中に「この機能を有効にするか」という分岐を仕込み、その ON/OFF をデプロイし直すことなく実行時に切り替えられるようにする仕組みです。新機能のコードは本番に配置済みだがフラグは OFF、準備が整った瞬間にフラグを ON にして公開する — つまり「コードを本番に置くこと（デプロイ）」と「機能をユーザーに見せること（リリース）」を別々のタイミングで行えるようになります。
この「デプロイとリリースの分離」が本質です。エンジニアは好きなタイミングで安全にデプロイし、プロダクトマネージャーはビジネス上最適なタイミングでリリースする。障害が起きても、デプロイのロールバックではなくフラグを OFF にするだけで機能を引っ込められる。さらに「全ユーザーの10%だけ ON」「社内ユーザーだけ ON」といった段階的な公開や A/B テストにも使えるため、単なる if 文の工夫を超えて、リリース戦略そのものを支えるインフラになっています。
なぜ生まれたか
背景にあるのは、ブランチ運用の苦しみです。かつては大きな機能を数週間かけて専用のブランチ（Git の枝）で開発し、完成してから main に統合するのが普通でした。しかし長生きしたブランチ同士の統合は衝突だらけの「マージ地獄」になり、CI/CD（継続的インテグレーション）が目指す「小さく頻繁に統合する」という理想と真っ向から対立します。かといって未完成の機能を main に混ぜれば、次のデプロイで作りかけの画面がユーザーに見えてしまう。「統合は頻繁にしたい、公開はまだしたくない」— この矛盾を解いたのがフィーチャーフラグです。未完成コードをフラグで隠したまま main に統合すれば、ブランチを長生きさせずに済みます。全員が main に直接小さくコミットしていくトランクベース開発は、フィーチャーフラグがあって初めて現実的に回る開発スタイルです。フラグで出し分ける考え方自体は古くからありますが、2009年ごろに Flickr が「ブランチを切らずに毎日何十回もデプロイする」運用の要としてフラグを紹介したことが、この組み合わせを広く知らしめました。
そこで割合での公開は、ユーザーIDをハッシュ化して決めるのが定石です。「フラグ名＋ユーザーID」をハッシュ関数に通し、出てきた値を 0〜1 の数（あるいは 0〜99 のバケット番号）に写して、それが公開率より小さければ ON にします。ハッシュは同じ入力に必ず同じ値を返すので、同じ人は何度来ても同じ側に入ります。公開率を 10% から 30% に上げたときも、しきい値が右へ動くだけなので、すでに ON だった 10% の人は ON のまま、新たに 20% の人が加わります。フラグ名を混ぜるのは、フラグごとに別の人たちを選ぶためです。ユーザーIDだけで決めると、どの実験でも同じ「先頭10%」の人が毎回新機能の実験台になってしまいます。
下の部品で確かめてください。粒の1つ1つがユーザーで、横の位置がそのハッシュ値です。しきい値の線を右へドラッグすると公開が広がり、全員がリロードしても粒は動きません。判定を「毎回ランダム」に切り替えると、リロードのたびに粒が飛び回って表示が入れ替わります。最後にキルスイッチを押すと、デプロイなしで全員が OFF に戻ります。
フィーチャーフラグ最大の落とし穴は、役目を終えたフラグがコードに残り続けることです。リリーストグルは全ユーザーに ON になった時点で用済みですが、削除は誰の緊急タスクでもないため放置されがちです。フラグが溜まると、分岐の組み合わせが爆発してテストすべき状態数が増え、「この分岐はもう通らないのか、誰も分からない」というデッドコードが蓄積します。フラグ管理の失敗例としてよく引かれるのが、2012年8月に米国の証券会社 Knight Capital が約45分間で4億6000万ドル以上を失った事故です。同社の注文システムには、2003年に使われなくなった「Power Peg」という古い機能のコードが9年間残っていました。新機能を出すとき、その古い機能が使っていたフラグを新機能用に再利用し、しかも新しいコードの配布が8台のサーバのうち1台だけ漏れていました。フラグを ON にした瞬間、新しいコードが入った7台では新機能が、配布漏れの1台では眠っていた Power Peg が動き出し、大量の誤発注を出し続けたのです。本質は、消さずに残した死んだコードと、意味の違う用途へのフラグの再利用、そしてデプロイの確認漏れが重なったことにあります。
対策は運用の規律です。フラグ作成時に削除期限とオーナーを決める、管理サービスの「最終評価日時」で使われていないフラグを検出する、全公開から一定期間たったフラグの削除をスクラムのスプリントの定常タスクに組み込む、といった仕組みで「作ったら消すまでがフラグ」を徹底します。フラグ名は用途ごとに使い捨てにし、別の意味に使い回さないことも Knight Capital の教訓です。また、フラグの評価結果はデバッグの重要な手がかりになるため、ログや分散トレーシングのスパンに「このリクエストはどのフラグがどう評価されたか」を記録しておくと、「一部のユーザーだけ挙動が違う」という調査が格段に楽になります。
