CI/CD・デプロイ

フィーチャーフラグふぃーちゃーふらぐ

フィーチャートグルカナリアリリースA/Bテストブランチ戦略ダークローンチロールアウト

フィーチャーフラグについて教えて

簡単に言うとこんな感じ！

新機能の「電源スイッチ」をコードの中に埋め込んでおくイメージだよ！リリースせずに本番環境へ送り込んでおいて、スイッチをONにするだけで機能を有効にできるんだ。失敗したらスイッチOFFにすれば即元通り！って感じで、安全に新機能を届けられる仕組みなんだ。

フィーチャーフラグとは

フィーチャーフラグ（Feature Flag）とは、ソフトウェアの特定の機能をコードの変更なしに「ON/OFF」切り替えられる仕組みのことです。フィーチャートグル（Feature Toggle）とも呼ばれます。機能のコード自体はすでに本番環境にデプロイされていても、フラグがOFFになっている間はユーザーには見えないため、「いつ・誰に・どの機能を公開するか」を細かくコントロールできます。

従来のリリースは「コードをデプロイする＝機能が公開される」という一体化した構造でした。フィーチャーフラグを使うと「デプロイ」と「リリース（機能公開）」を切り離すことができます。たとえば、大きな機能開発中でもこまめにメインブランチへ統合（マージ）でき、長期間ブランチを分岐させ続けることで起きるコンフリクト（衝突）地獄を回避できるのが大きなメリットです。

実務では、新しい決済フローを一部のユーザーだけに先行公開したり、障害が起きた機能をサービス停止なしにOFFにしたりといった用途で活躍します。開発チームだけでなく、マーケティング担当が「キャンペーン開始と同時に機能を公開する」といったビジネス判断のタイミングにも使えるため、技術とビジネスをつなぐ便利な道具として注目されています。

フィーチャーフラグの種類と使い方

フィーチャーフラグは目的によっていくつかの種類に分類されます。用途を間違えると管理が煩雑になるため、使い分けが重要です。

種類	目的	寿命	代表的な使い方
リリーストグル	デプロイとリリースを分離	短期（数日〜数週間）	新機能の段階的公開
実験トグル	A/Bテスト・多変量テスト	短期〜中期	UI変更の効果測定
オプストグル	ユーザー個別の設定	長期（永続的）	プレミアム機能のON/OFF
権限トグル	ロールや属性による出し分け	中期	社内ユーザー限定プレビュー
キルスイッチ	障害時の緊急停止	長期（永続的）	高負荷時のレコメンド機能停止

覚え方：「旗を立てて機能を開く」

Feature（機能）＋ Flag（旗）。旗が立っていれば機能ON、旗がなければ機能OFF、とシンプルに覚えましょう。「機能の旗立て係」がフィーチャーフラグです。

実装の最小イメージ

// フラグがONなら新しいUIを見せる、OFFなら従来版を見せる
if (featureFlag.isEnabled("new-checkout")) {
    showNewCheckoutFlow();   // 新機能（旗がON）
} else {
    showOldCheckoutFlow();   // 従来版（旗がOFF）
}

コードの中にこのような分岐を埋め込んでおき、フラグ管理ツールやDBの設定値を変えるだけでどちらの画面を出すか切り替えられます。

歴史と背景

2000年代初頭 — 大規模なWebサービス（Googleなど）が、長期ブランチのマージコストを減らすために「コードを分岐させる代わりにコード内にフラグを埋め込む」手法を実践し始める
2009年 — Flickrのエンジニアが「Continuous Deployment at Flickr」として発表。1日10回以上のデプロイを支える技術としてフィーチャーフラグが注目を集める
2011年 — トランクベース開発（Trunk-Based Development）の普及とともにフィーチャーフラグが必須技術として確立。長期ブランチを作らずメインブランチへ直接統合するスタイルを支える
2017年 — Martin Fowlerが「Feature Toggles (aka Feature Flags)」を体系的に整理・公開。種類・管理方法が広く共有される
2010年代後半〜現在 — LaunchDarkly・Split・Unleashなどフラグ専用のSaaSが登場。フラグの一元管理・監査ログ・段階的ロールアウトをGUIで操作できるようになる

デプロイ戦略との関係

フィーチャーフラグは単独で使うだけでなく、さまざまなデプロイ戦略と組み合わさって真価を発揮します。

主なデプロイ戦略との対応

比較：ブランチ戦略 vs フィーチャーフラグ

比較軸	長期ブランチ戦略	フィーチャーフラグ
マージ作業	大規模・高コスト	小さく頻繁にマージ可
リリース判断	デプロイと同時	デプロイ後に任意のタイミング
障害時の対応	再デプロイが必要	フラグOFFで即時停止
ユーザー別出し分け	困難	柔軟に対応可能
管理コスト	ブランチ数の増大	フラグの負債（フラグ腐れ）リスク

⚠️ フラグの「負債」に注意

使い終わったフィーチャーフラグをコードから削除せずに放置すると、「フラグ腐れ（Flag Debt）」と呼ばれる技術的負債が溜まります。OFFにしたはずのフラグが原因で予期せぬ動作が起きたり、コードの可読性が落ちたりします。「短命フラグは必ず期限を決めて削除する」ルールを徹底することが重要です。