はじめに
Feature Flagは、段階リリースやABテスト、緊急停止に効く強い武器です。
ただし「入れただけ」で安全になるわけではなく、運用設計が弱いと逆に事故ります。
- どのユーザーに何が見えるのか分からなくなる
- バグが出ても再現できない
- フラグが増えて技術的負債になる
この記事では、失敗するパターンを先に押さえたうえで、実務チェックリストとして整理します。
先に結論 まず決めるべき4点
- フラグの種類
- kill switch（緊急停止）
- release flag（段階リリース）
- experiment flag（ABテスト）
- 評価タイミング
- サーバー側で決めるか、クライアント側で決めるか
- スコープ
- ユーザー、組織、環境、リージョン
- デフォルト
- 何も設定されていない場合にONかOFFか
この4点が曖昧だと、フラグが仕様になり、運用で破綻します。
失敗する原因トップ集
1 フラグの寿命がない
フラグを入れたら必ず消す設計が必要です。
残ると分岐が増え続け、変更が怖くなります。
- 期限を入れる（いつ消すか）
- 担当とチケットを紐づける
2 どこで評価しているか分からない
- サーバーとクライアントで二重に評価
- キャッシュやCDNで古い判定が残る
対策
- 判定は原則として一箇所に寄せる
- どうしても分けるなら責務を分ける
3 判定がリクエストごとに変わる
リロードや再試行でON/OFFが変わると、ユーザー体験が壊れます。
- ユーザーIDに基づく一貫した割当
- ABテストは同一ユーザーに同一バリアントを固定
4 kill switchが間に合わない
緊急停止のためのフラグが、反映に数分かかると意味が薄れます。
- 設定配布の遅延を把握する
- 重要機能はサーバー側で即時遮断できる経路を持つ
5 監査ログがない
誰がいつフラグを変えたか分からないと、事故調査ができません。
- 変更履歴
- 変更者
- 理由
を残します。
設計チェックリスト
- フラグの種類（kill/release/experiment）が決まっている
- デフォルト値とフォールバックが決まっている
- スコープ（ユーザー/組織/環境）が明確
- 判定位置（サーバー/クライアント）が一貫している
- ABテストは割当の固定方法がある
リリース運用チェックリスト
- 段階リリースの手順（1パーセント 10パーセント 100パーセント）が定義されている
- 監視指標（エラー率、レイテンシ、離脱）が決まっている
- ロールバックとkill switchの手順が用意されている
- サポートやCSが参照できる状態になっている
負債化させないための削除フロー
- 期限到来前にリマインドされる
- 100パーセントONになったら分岐を消す
- 削除後にテストがある
- ドキュメントからもフラグを消す
レビュー観点テンプレ
- このフラグはいつ消すか
- kill switchとして使えるか
- 判定がどこで行われるか
- 監視と停止手段が揃っているか
- 再現性が担保されているか