既存プロダクトにFeature Flagを後付けする方法

「大きな機能を一気にリリースしたら本番で事故った」「不具合が出てもロールバックはデプロイのやり直しで、復旧まで30分かかる」——こうした相談を受けるプロダクトの多くは、リリース＝全ユーザーに即時公開という一択しか持っていません。段階的に出す・一部ユーザーだけに試す・問題が起きたら即座に止める、という選択肢がそもそも存在しない状態です。

Feature Flag（機能フラグ）は、この「オールオアナッシングのリリース」を分解する仕組みです。この記事では、既にユーザーがいる既存プロダクトに後からFeature Flagを導入する方法を、発注者が判断に迷いやすいポイントに絞って解説します。

Feature Flagで何が変わるのか

Feature Flagとは、コードに埋め込んだ条件分岐のオン/オフを、デプロイをせずに切り替えられる仕組みです。効果は主に4つあります。

• 段階公開: 新機能を全ユーザーの1%→10%→50%→100%と段階的に開放できる。1%の時点で問題があれば、それ以上被害が広がる前に気づける
• カナリアリリース: 社内ユーザーや特定の契約プランだけに先行公開し、実際のトラフィックで動作確認してから一般公開する
• A/Bテスト: 同じ機能の2つの実装をユーザー群で出し分け、指標を比較して意思決定できる
• 緊急オフ（キルスイッチ）: 本番で問題が発覚した際、デプロイのやり直しなしに機能を即座に止められる。これが一番効きます。デプロイ→ロールバック→再デプロイという手順は早くても10〜30分かかりますが、フラグオフは管理画面の操作1つで数秒〜数十秒です

「リリースのたびに事故が多い」プロダクトの実態は、機能自体の品質問題よりも「一発で全員に出す」というリリース方式そのものが事故率を上げていることが多いです。Feature Flagは機能を直すのではなく、リリースの仕方を直す施策だという点を押さえておくと、投資判断がしやすくなります。

自前実装 vs SaaS、どちらを選ぶか

Feature Flagの導入方法は大きく2つです。判断基準は「フラグの数」と「誰が切り替えるか」です。

自前実装（DBテーブル + 管理画面）が向くケース
- フラグの数が少ない（数個〜十数個程度）
- 切り替えるのがエンジニアのみで、非エンジニアの運用担当が触らない
- 外部SaaSへの依存・月額コストを増やしたくない

実装は、feature_flags テーブル（key・有効/無効・対象条件のjsonb程度）と、それを引く薄いサービスクラス（例: FeatureFlag.enabled?(:new_checkout, user: current_user)）があれば最小構成で足ります。既存のRailsアプリなら管理画面（admins名前空間）にCRUDを1本足すだけで、実装工数は数日〜1週間程度が目安です。

SaaS（LaunchDarkly、Flagsmith、Unleashなど）が向くケース
- フラグの数が数十〜数百に増える見込みがある
- PdMやカスタマーサクセスなど非エンジニアが切り替え操作をしたい
- ユーザー属性・地域・契約プランなど複雑なターゲティング条件を細かく作りたい
- 監査ログ（誰がいつ切り替えたか）が必要

SaaSは初期構築が速い一方、月額数万円〜のランニングコストと、既存コードへのSDK組み込みが発生します。フラグが10個以下で運用者もエンジニアだけなら、自前実装の方が総コストは安いケースがほとんどです。 「将来使うかもしれないから」で最初からSaaSを入れるのは過剰投資になりやすい領域です。

後付け導入の進め方 — いきなり全部やらない

既存プロダクトへの後付けで失敗しやすいのは、「まず基盤を完璧に作ってから使う」という順番です。実際には逆で、1つの機能をフラグで出す実践を通して基盤を育てる方が早く安全に根付きます。

1. 最初のフラグは「次にリリースする機能」で使う: 抽象的な基盤づくりから始めず、直近リリース予定の機能1つに絞ってフラグを噛ませる。ここで命名規約・削除運用・管理画面の使い勝手を実地で検証する
2. 命名規約を最初に決める: feature_new_checkout のような機能単位のもの、experiment_pricing_ab のようなA/Bテスト単位のものを混在させると、後から棚卸しできなくなる。最低限「種別プレフィックス + 対象機能名」の規約は最初の1本目から適用する
3. オーナーと削除予定日をフラグ作成時に必須項目にする: これが次項の「技術負債化防止」の核です
4. キルスイッチ用途からリスクの高い機能に広げる: 決済・認証まわりなど、事故時の被害が大きい機能から優先的にフラグ化すると投資対効果が高い

フラグの寿命管理 — 技術負債化を防ぐ

Feature Flagは導入した瞬間から負債化が始まるという性質を持ちます。ここを軽視すると、1年後には「誰も意味を知らない if 文」がコードベースに何十個も残ります。

• 恒久フラグと一時フラグを分けて管理する: 段階公開・A/Bテスト用のフラグは「一時」で、機能が100%到達したら必ず削除する。プラン別機能制御のような恒久フラグと同じ扱いにしない
• 削除予定日をフラグ作成時に決める: 「100%到達から2週間後に削除」のようなルールを運用に組み込む。この期限を管理画面やチケット管理と連携させ、超過したフラグを可視化する
• コードのif分岐が2つ以上のフラグでネストしたら黄色信号: if flag_a && flag_b のような組み合わせは、テストすべき状態組み合わせが指数的に増える。1機能=1フラグを崩さない
• 四半期に一度、フラグの棚卸しをする: 「有効/無効が固定されたまま半年動いていないフラグ」は、恒久化するか削除するかを決める。判断を先送りにした未整理フラグの数が、そのままコードの複雑さに直結する

実務上、フラグの数が20〜30を超えたあたりから「このフラグ何のためにあるんだっけ」という状態が発生し始めます。棚卸しの仕組みをフラグ数が少ないうちに作っておくのが、後から一括整理するより圧倒的に安く済みます。

外注時に確認すべきこと

Feature Flag導入を外部に依頼する場合、次の点を発注前後で確認すると手戻りが少なくなります。

• 対象範囲を最初から絞ってもらう: 「全機能をフラグ化」ではなく、直近のリリース予定機能・事故時の被害が大きい機能から着手する提案になっているか
• 削除運用まで含めた設計になっているか: フラグを「作る」仕組みだけでなく「消す」仕組み・棚卸しの運用ルールまで提案に入っているか。ここが抜けている見積もりは、導入後1年で負債化するリスクが高い
• 自前実装かSaaS導入かの判断根拠が示されているか: フラグ数・運用者・予算感を踏まえた比較なしに、いきなりSaaS導入前提で見積もりが出てきた場合は、過剰投資でないか確認する価値がある

Feature Flag自体は事故を減らす手段であって、既存プロダクトの改善を検討する際は、まずデプロイやロールバックの体制がどこまで整っているかを合わせて確認することをおすすめします。デプロイが属人化している場合はデプロイが属人化したシステムを改善する方法、ロールバックの仕組みそのものに課題がある場合はロールバックできない本番運用を改善する方法も合わせてご覧ください。Feature Flagはこれらの土台の上で最大限効果を発揮します。

まとめ

• Feature Flagは「一発リリースで事故が多い」状態を、段階公開・カナリア・緊急オフという選択肢に分解する仕組みで、特にデプロイなしで即座に機能を止められるキルスイッチ効果が大きい
• 導入方法はフラグ数と運用者で判断する。数個〜十数個でエンジニアのみが運用するなら自前実装、数十以上に増える見込みや非エンジニアの運用が必要ならSaaSが向く
• 導入は基盤を完璧に作ってから始めるのではなく、直近の1機能で実践しながら命名規約・削除運用を育てる進め方が失敗しにくく、フラグ作成時に削除予定日を必須にすることが負債化防止の鍵になる

「リリースのたびに事故が心配」「新機能を一部ユーザーだけに試したいが仕組みがない」という段階でも、torcheees はご相談を受け付けています。まずは「既存プロダクト改善」の診断で現状のリリース体制を確認し、改善の優先順位と概算費用をご提示します。お問い合わせフォームからお気軽にご連絡ください。改善・モダナイゼーション支援の詳細もあわせてご覧ください。