フレームワーク活用ガイドひとことで言うと#
「コードのデプロイ」と「機能の公開」を切り離す仕組み。フラグ（スイッチ）で機能のON/OFFを制御することで、特定ユーザーだけに新機能を試したり、問題があればすぐに巻き戻したりできる。開発のリスクを劇的に下げるプロダクト戦略。
押さえておきたい用語#
- フィーチャーフラグ（Feature Flag）
- コード内に埋め込む機能のON/OFFスイッチを指す。トグル（Feature Toggle）とも呼ばれる。
- カナリアリリース
- 全ユーザーのうちごく一部（1〜10%）にだけ新機能を公開し、問題がないか確認してから段階的に拡大する手法を指す。
- キルスイッチ
- 本番環境で問題が発生した際に、即座に機能をOFFにできる運用フラグのこと。障害時の被害を最小限に抑える。
- フラグ負債
- 役目を終えたフラグを削除せず放置し続けることで生まれる技術的負債である。コードの複雑性を増し、バグの温床になる。
フィーチャーフラグ戦略の全体像#
こんな悩みに効く#
- 大きな機能リリースのたびに障害が起きて冷や汗をかく
- 「全ユーザーに一気に公開」が怖くてリリースが遅れる
- ベータテストをしたいが、環境を分けるコストが高い
基本の使い方#
フィーチャーフラグには用途の異なる4種類がある。
- リリースフラグ: 未完成の機能をデプロイしつつ非公開にする。完成したらONにする
- 実験フラグ: A/Bテスト用。ユーザーをランダムに振り分ける
- 運用フラグ: パフォーマンス問題時に特定機能を一時的にOFFにする（キルスイッチ）
- 許可フラグ: 特定の顧客やプランにだけ機能を公開する
それぞれのフラグの寿命が異なる: リリースフラグは短命（数日〜数週間）、許可フラグは永続的。
新機能を一気に全ユーザーに公開するのではなく、段階的に広げる。
- 第1段階: 社内テスト（0.1%） — 社内メンバーで動作確認
- 第2段階: ベータユーザー（1〜5%） — 協力的なユーザーにフィードバックをもらう
- 第3段階: カナリアリリース（10〜20%） — 指標を監視しながら少しずつ広げる
- 第4段階: 全体公開（100%） — 問題がなければ全員に公開
各段階で見るべき指標を事前に定義しておく: エラー率、パフォーマンス、主要KPIの変化。
フラグが増えすぎると技術的負債になる。管理ルールが必要。
- 命名規則:
release_new_dashboard_2026q1のように用途と時期がわかる名前にする - 期限の設定: リリースフラグは30日以内に削除する
- オーナーの明確化: 各フラグの責任者を決める
- 定期棚卸し: 月次で不要なフラグを掃除する
フラグの数が50を超えたら危険信号。放置されたフラグはコードの複雑性を増し、バグの温床になる。
フィーチャーフラグは技術ツールだが、プロダクト戦略にも活用できる。
- エンタープライズ顧客限定機能: 許可フラグで特定プランにのみ公開
- 地域別の機能展開: 法規制や文化に合わせて国ごとに機能を制御
- イベント連動: キャンペーン期間中のみ特別機能を公開
- 段階的な機能廃止: 使われていない機能を徐々に非公開にする
営業やCSチームとの連携が重要: 顧客ごとのフラグ状態を把握できる仕組みを作る。
具体例#
状況: ECサイトの決済フローをリニューアルしたい。しかし決済は売上に直結するため、失敗のリスクが大きい。
フィーチャーフラグ戦略:
- リリースフラグで並行開発: 新しい決済フローをフラグの裏で開発。既存の決済フローには一切影響しない
- 段階的ロールアウト:
- Week 1: 社内テスト（全社員で購入テスト）
- Week 2: ベータユーザー500人（購入後アンケート実施）
- Week 3: 全ユーザーの10%（CVR、エラー率を監視）
- Week 4: 50%に拡大
- Week 5: 100%に公開
- 監視指標:
- Primary: 決済完了率（既存比-1%で一時停止）
- ガードレール: 決済エラー率、ページ読み込み時間
結果: Week 3で一部のクレジットカードブランドでエラーが発生（エラー率+0.5%）。一時的に10%に留めて修正。修正後に再度拡大し、最終的にCVRが8%改善。
フラグがなかったら全ユーザーにいきなり公開して、決済エラーが全ユーザーに影響していた。段階的ロールアウトが年間推定3,000万円の損失を防いだ。
状況: BtoB SaaS（従業員300名、MAU2万人）。AI搭載のレコメンド機能を開発したが、精度に不安がある。的外れなレコメンドを出すと顧客の信頼を損なうリスク。
フィーチャーフラグ戦略:
- 実験フラグで3群に分割: A群（レコメンドなし）、B群（AI v1）、C群（AI v2・より保守的なモデル）
- 各群5,000ユーザー、期間3週間
結果:
| 指標 | A群（なし） | B群（AI v1） | C群（AI v2） |
|---|---|---|---|
| クリック率 | 2.1% | 4.8% | 3.9% |
| 「役に立たない」報告 | — | 8.2% | 2.1% |
| NPS変化 | ±0 | -3 | +5 |
判断: B群はクリック率が高いが不満も多い。C群はバランスが良いため採用。以降はC群をベースにモデル改善を続ける方針。
いきなり全体に出していたらB群のモデルを選んでNPSが下がっていた。実験フラグによる3群比較が「効果とリスクの最適解」を見つけてくれた。
状況: 預金者80万人の地方銀行。住宅ローンのオンライン申込機能を開発。金融規制上のリスクと、高齢顧客の操作ミスによるトラブルを懸念。
フィーチャーフラグ戦略:
- 許可フラグで段階展開: まず40歳以下かつモバイルバンキング利用者（約5万人）にのみ公開
- 6週間のパイロット後、問題なければ全顧客に拡大
- 運用フラグ（キルスイッチ）で、申込殺到時やシステム負荷時に即座にOFFにできる設計
結果（パイロット6週間）:
- オンライン申込数: 342件（窓口比+28%の申込増）
- 申込エラー: 12件（すべてバリデーション改善で解消）
- 窓口問い合わせ: 想定の1/3（FAQページが機能）
| 指標 | 窓口のみ時代 | オンライン導入後 |
|---|---|---|
| 申込〜審査開始の平均日数 | 5日 | 1日 |
| 顧客あたり対応コスト | 18,000円 | 4,500円 |
| 申込件数（月間） | 120件 | 154件 |
金融サービスのような「失敗が許されない」領域こそ、フィーチャーフラグの段階的展開が効く。パイロットで12件のエラーを発見・修正してから全体展開できたことで、80万人の顧客への影響をゼロに抑えられた。
やりがちな失敗パターン#
- フラグを削除しない — リリース完了後も放置されるフラグが増え続け、「このフラグは何のためにあるの？」状態になる。リリース完了後すぐに削除タスクを作る
- フラグの条件分岐が複雑になる — 「フラグAがONで、フラグBがOFFで、ユーザーがプランCの場合」のような組み合わせ爆発は危険。フラグはシンプルに保つ
- テスト環境でフラグのON/OFF両方をテストしない — フラグONの動作だけテストして、OFFの場合にバグがあることに気づかない。両方のパスをテストする
- フラグの棚卸しをしない — 月次で全フラグを一覧にして、不要なものを削除する「フラグクリーンアップデー」を設ける
まとめ#
フィーチャーフラグは「安全にリリースする」ための最強ツール。段階的ロールアウトによるリスク低減、A/Bテストによる効果検証、顧客別の機能制御まで、プロダクト運営のあらゆる場面で活用できる。ただし、フラグの管理を怠ると技術的負債になる。「フラグを立てたら、削除計画も一緒に立てる」を鉄則にしよう。