フィーチャーフラグ

フィーチャーフラグとは

フィーチャーフラグ（フィーチャートグル）は、機能のオン/オフを実行時に切り替えるスイッチ をコードに埋め込む手法です。これにより、「デプロイ（コードを本番に置く）」と「リリース（ユーザーに機能を見せる）」を分離 できます。

if featureFlags.isEnabled("new-checkout", user):
    新しいチェックアウト画面を表示
else:
    従来のチェックアウト画面を表示

新機能のコードは オフの状態で本番にデプロイ済み にしておき、準備が整ったタイミングで フラグを切り替えるだけ で公開します。コードの配置と機能の公開を別々のイベントにできる、という点がすべての利点の源です。

なぜデプロイとリリースを分けるのか

両者が密結合だと、「デプロイ＝即・全ユーザーに公開」になり、リリースは常に 全か無か の賭けになります。分離すると、こうした運用が可能になります。

• 準備中の機能をマージし続けられる：未完成でもオフなら本番に置ける → 巨大ブランチの長期分岐を避けられる（後述のトランクベース開発）。
• 公開タイミングを技術と切り離せる：マーケのキャンペーン日に合わせて、エンジニアの作業なしでフラグを ON。
• 問題が起きてもデプロイし直さない：フラグを OFF に戻すだけで瞬時に撤退できる。

主な使いどころ

フラグは1種類ではなく、目的別に性格が異なります。寿命の長短を意識すると管理しやすくなります。

種類	目的	寿命
リリーストグル	開発中の機能を隠す／段階公開	短命（公開したら消す）
実験トグル	A/B テストで効果を測る	実験期間だけ
Ops トグル	高負荷時に重い機能を一時停止	長命（運用スイッチ）
権限トグル	特定プラン・ユーザーだけに機能提供	長命（恒久的な出し分け）

• 段階的リリース／カナリア：「まず社内 → 5% → 50% → 全員」と対象を広げ、各段階で指標を確認する（/devops/deployment-strategies/）。
• A/B テスト：ユーザーを2群に分け、新旧どちらが指標を改善するかを実測する。
• キルスイッチ：障害時や負荷時に、特定機能だけを即座に止める安全弁。

即時ロールバックという強み

フラグ最大の実務メリットが ロールバックの速さ です。通常、不具合が出たら 前バージョンを再デプロイ する必要があり、ビルドからやり直すと時間がかかります。

フラグなら、問題の機能をオフにするだけ。再ビルドも再デプロイも不要で、設定変更が即座に反映されます。障害対応（/devops/incident-postmortem/）の初動で「まず止血」を秒単位で打てるのは大きな価値です。

トランクベース開発との関係

フィーチャーフラグは トランクベース開発（全員が短命ブランチで頻繁に main へマージする進め方）と強く結びつきます。未完成の機能でも フラグでオフにしておけば main にマージできる ため、長期間生きるブランチを作らずに済み、巨大なマージ衝突を避けられます。CI/CD（/devops/ci-cd/）の「小さく頻繁に統合する」思想と噛み合います。

つまずきポイント：フラグは負債になる

便利ゆえに、フラグは増えすぎると管理不能 になります。

• 分岐の爆発：フラグが N 個あると、理論上 2^N 通りの状態が生まれ、テストが追いつかなく なる。
• 死んだフラグ：役目を終えたのに残ったフラグが、コードを読みにくくし、誤操作の温床になる。
• 設定ミスの事故：本番で誤って未完成機能を ON にする、といった事故も起きうる。

まとめ

• フィーチャーフラグは 機能のオン/オフを実行時に切り替える スイッチで、デプロイとリリースを分離 する。
• 段階的リリース・A/Bテスト・カナリア・キルスイッチ に使え、トランクベース開発と相性が良い。
• 不具合時は フラグを戻すだけで即ロールバック（ただしデータ変更は別問題）。
• 増えすぎると 負債 化する。短命フラグは 使い終えたら消す 運用を徹底する。