フィーチャーフラグ
フィーチャーフラグとは
フィーチャーフラグ(feature flag / feature toggle)は、コードを変えずに機能のON/OFFを切り替えられる仕組みです。機能トグルとも呼ばれます。
やっていることは、実質的にただの条件分岐です。
if (featureFlags.isEnabled('new-checkout')) {
renderNewCheckout();
} else {
renderLegacyCheckout();
}
重要なのは、この isEnabled の判定を設定側から動的に変えられる点です。これにより「コードを本番に置くこと(デプロイ)」と「利用者に機能を届けること(リリース)」を切り離せます。未完成の機能もOFFのまま本番へマージでき、公開の判断はスイッチ1つで行えるわけです。
何がうれしいのか
- 長寿命ブランチが要らなくなる — 機能が完成するまで別ブランチで抱え込む必要がなく、こまめに本流へ統合できます。巨大なマージ衝突が起きません
- 公開タイミングを開発から独立させられる — キャンペーン開始に合わせた公開を、デプロイ作業なしで行えます
- 問題が起きたら即座に止められる — 切り戻しのデプロイを待たず、フラグをOFFにするだけで被害を止められます([[デプロイ戦略]] の切り戻しより速い)
- 段階的な公開ができる — 「社内ユーザーのみ」「5%のユーザー」といった条件付きの公開が可能です
フラグの種類と寿命
すべてのフラグを同じ扱いにすると管理が破綻します。目的別に分けましょう。
| 種類 | 目的 | 想定寿命 |
|---|---|---|
| リリーストグル | 未完成機能を隠す・段階公開する | 数日〜数週間(短命) |
| 実験トグル | A/Bテストで効果を比較する | 実験期間中 |
| 運用トグル | 高負荷時に重い機能を止める | 長期 |
| 権限トグル | プラン別に機能を出し分ける | 恒久 |
問題になりやすいのがリリーストグルの消し忘れです。役目を終えたフラグを放置すると、条件分岐が積み重なってコードが読みにくくなり、そのまま [[技術的負債]] になります。
対策はシンプルです。作るときに削除する期限と担当者を決めておくこと。公開が完了したらフラグと不要になった分岐を削除する作業まで、リリース手順に含めてしまいましょう。
テストとの付き合い方
フラグが1つ増えるごとに、コードが通る経路は倍に増えます。フラグ3つで理論上8通りです。すべての組み合わせを [[自動テスト]] で網羅するのは現実的ではありません。
実務では、ON と OFF の両方をテストするのはリリース直前の重要なフラグだけに絞り、フラグ同士が干渉しない設計(1つの機能を1つのフラグで完結させる)にします。そして消せるフラグは早く消す — 結局これが最良のテスト削減策です。
初学者向けポイント
- 小規模なら設定ファイルや環境変数で十分始められます。専用のSaaSは、動的な切り替えや細かいユーザー条件が必要になってから検討しましょう
- 判定結果をログに残すと、障害調査で「そのとき機能はONだったか」がすぐ分かります
- OFF の分岐も本番で動くコードです。[[CI/CD]] のテストではOFF側の経路も確認しましょう
関連技術とのつながり
- [[デプロイ戦略]] — デプロイと公開を分離し、カナリアリリースをアプリ側で実現する
- [[CI/CD]] — 未完成コードも本流へ統合し続けられるようになる
- [[技術的負債]] — 消し忘れたフラグは典型的な負債になる
- [[自動テスト]] — フラグの組み合わせ爆発とどう折り合うかが課題になる
- [[DevOps]] — 小さく速くリリースする文化を技術的に支える
Q: フィーチャーフラグの最大の利点はどれ?
- [x] デプロイと機能の公開を分離できること
- [ ] コードの実行速度が上がること
- [ ] テストが自動的に不要になること
解説: コードを本番に置いたまま公開タイミングを制御でき、問題時はOFFにするだけで止められます。
Q: リリーストグルで起きやすい問題はどれ?
- [ ] フラグをONにできなくなる
- [x] 役目を終えたフラグを消し忘れ、条件分岐が負債になる
- [ ] デプロイ回数が減ってしまう
解説: 短命であるべきリリーストグルを放置すると分岐が積み重なります。作成時に削除の期限と担当を決めておくのが対策です。
Q: フラグが増えたときのテスト方針として現実的なものはどれ?
- [ ] すべてのフラグの全組み合わせを必ずテストする
- [x] 重要なフラグに絞ってONとOFFの両方をテストする
- [ ] フラグがある機能はテストしない
解説: 組み合わせは指数的に増えるため全網羅は非現実的です。重要なものに絞り、不要なフラグを早く消すのが実務的です。