# フィーチャーフラグとは：デプロイとリリースを切り離す技術 URL: https://upstreamapi.com/ja/journal/feature-flags-to-wa Type: blog Locale: ja Published: 2026-08-29 Updated: 2026-08-31 --- > フィーチャーフラグはデプロイとリリースを切り離す仕組みです。SLOゲート、キルスイッチ設計、フラグ負債管理の実践的アプローチで、本番環境でのブラスト半径を最小化する方法を解説します。 ## フィーチャーフラグとは：デプロイとリリースを切り離す技術 フィーチャーフラグとは、アプリケーションコード内の条件分岐で、新しいビルドをシップすることなく、特定のユーザー、セッション、環境に対してどのコードパスを実行するかを制御する仕組みだ。`new_checkout_flow` というフラグをユーザーベースの99%に対して `false` に設定しているなら、そのコードは2週間前にデプロイ済みだ。まだオンにしていないだけ。この仕組みが確立する契約は明確だ: デプロイとリリースは2つの独立したイベントになる。継続的デプロイを規模でおこなうチームにとって、この契約は根幹となる。 ## デプロイとリリースは別々のイベントだ ほとんどのチームは、痛いロールアウトの失敗を経験してからこの違いを学ぶ。火曜日の午後に機能がシップされ、水曜日の朝にはリクエストトレースで何かが変な挙動を始め、誰かが調査を開始した時点ではdiffが4コミットと2つのサービス境界にまたがっている。そのシナリオで原因を特定するのは本当に難しい。 フィーチャーフラグは精度を強制する。フラグの背後にあるコードがマージされてデプロイされると、本番環境で不活性な状態で存在し続ける。デプロイが成功したことを確認し、数時間または数日間ベースラインのメトリクスを観察する。それから1%のトラフィックに対してフラグを有効にする。これで帰属可能な変数が1つになった。フラグが有効なパスでエラーレートが上昇しても、コードdiffをデバッグしているのではない。設定値を切り替えているだけだ。 この分離は主に速度の話ではない。ブラスト半径の話だ。1%のセッションに影響するリリースが問題を起こしても、数分で回復できる。100%のセッションに影響するリリースが問題を起こすと、大規模インシデントになる。 実装自体はシンプルだ。TypeScriptでのフラグ評価はこうなる: `const showNewCheckoutFlow = flagClient.variation( 'new_checkout_flow', { userKey: session.userId, custom: { plan: user.plan } }, false // フラグサービスに到達できない場合のデフォルト ); if (showNewCheckoutFlow) { return renderNewFlow(cart); } return renderLegacyFlow(cart);``false` のデフォルト値は形式的なものではない。フラグ評価サービスがネットワーク分断に陥った場合にユーザーが経験する挙動だ。偶発的にではなく、意図的に定義しろ。 ## 本番環境で重要な4つのフラグタイプ すべてのフィーチャーフラグが同じ運用目的を果たすわけではない。コードベースと管理ツールで同一視すると、インシデント時の混乱とフラグ負債の蓄積につながる。 **リリースフラグ**は開発とロールアウト中の新機能をゲートする。一時的であることが前提だ。機能ブランチの作業開始時に作成し、機能が100%のユーザーに展開されてチームが安定性を確認した後に削除される。削除日も担当オーナーも決まっていないリリースフラグは、コードベースの恒久的な家具になる。 **実験フラグ**はA/Bテストと多変量実験を動かす。分析のコホート識別子に紐付き、ライフサイクルは実験に制限される。実験が終わればフラグも一緒に消える。よくある失敗: 勝者のバリアントをフラグの背後に無期限に残す判断。2年後、その実験フラグはクリティカルパスの一部になり、どのバリアントが有効か誰も覚えていない。 **opsフラグ**はキルスイッチとサーキットブレーカーだ。リリースフラグとは異なり、永続的なインフラとして設計される。`disable_ml_recommendations` のようなフラグは、ドキュメントを読まなくても午前3時に使えるものでなければならない。ローカルで評価され、文書化されたフォールバックを持ち、通常の運用中に定期的にテストされるべきだ。 **パーミッションフラグ**はユーザー層、アカウントプラン、ベータコホートによるアクセスを制御する。設計上、長命だ。パーミッションフラグは経緯を知らない読み手にはリリースフラグのように見えることが多い。他のどこよりも明確な命名規則が重要だ。 ![段階的なソフトウェアロールアウトの可視化：同心円のノードで割合ベースのトラフィックルーティングを示す](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/e28abc-inline1.webp) ## SLOゲートなしのパーセンテージロールアウトはただの遅いデプロイだ ほとんどのフィーチャーフラグ実装が止まるのはここだ。プラットフォームチームがロールアウトスケジュールを組む: 月曜日1%、火曜日5%、水曜日25%、金曜日100%。これをプログレッシブデリバリーと呼ぶ。 しかし、各ステップに検証条件のない「プログレッシブ」は、リスクの削減ではなくリスクの先延ばしだ。パーセンテージのダイヤルはエクスポージャーを制御する。安全性を検証しない。 段階的ロールアウトを運用上意味あるものにするのは、各ステージ間のSLOゲートだ。5%から25%に進む前に問わなければならない: フラグが有効なコードパスのエラーレートはSLOバジェット内か？p99レイテンシはコントロールグループと同じ範囲か？エラーバジェットはベースラインより速く消費されていないか？これらが計測されていなければ、ロールアウトスケジュールはタイムラインであって検証ループではない。 本番環境で機能するセットアップ: 2つのSLO評価ウィンドウを定義する。短いウィンドウ（15分）は高速な障害をキャッチする。長いウィンドウ（24時間または1トラフィックサイクル）は緩やかな劣化をキャッチする。どちらかが違反されたら、ロールアウトを停止してオンコールをページする。 パーセンテージはダイヤルだ。SLOウィンドウはゲートだ。両方必要だ。 ## キルスイッチの設計：必要になる前に作れ キルスイッチはフォールバックではない。機能コードの最初の1行を書く前に存在しなければならない、ファーストクラスの設計決定だ。 プレッシャーの下で設計されたキルスイッチは、検証されていない前提を抱えたキルスイッチだ。アクティブなインシデント中に、PagerDutyの通知から開いたターミナルセッションで、5人がSlackスレッドを見ている前で初めてテストすることになる。opsフラグがセッションIDでユーザーをターゲットしていて、セッションサービスが現在劣化していることをそこで発見する。最悪のシナリオだ。 ![SLOモニタリングダッシュボード：エラーバジェット消費レートとフィーチャーロールアウト制御のキルスイッチインジケーター](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/dd1477-inline2.webp) 本番環境で使うキルスイッチに交渉の余地がない3つの特性: - **50ms以下のローカル評価**: フラグチェックはリモートの評価サービスへのネットワーク呼び出しであってはならない。評価が劣化し得るサービスに依存していたら、インシデント対応パスに循環依存がある。 - **明示的なフォールバック値**: フラグサービスが到達不能な場合、フラグは何を返すのか？文書化され、コードで定義され、テストされなければならない。「SDKのデフォルト」は答えではない。 - **依存関係の障害下でのテスト**: キルスイッチはカオスエンジニアリングのローテーションに含まれるべきだ。認証が劣化したシナリオ、フラグサービス自体がダウンしたシナリオ、評価エンドポイントへのネットワークレイテンシが2秒を超えたシナリオで検証しろ。 インシデント対応をクリーンに実行するチームはリハーサルしたチームだ。キルスイッチはランブックの一部だ。退屈なものにしろ。 ## フラグ負債：誰もロードマップに載せない技術的負債 フィーチャーフラグを積極的に採用するチームはフラグ負債を蓄積する。目的を達成したが削除されなかったフラグだ。機能はシップされ、実験は終了し、ベータは終わった。フラグは残った。 50フラグなら些細な問題だ。分散システム全体で500フラグになると、積極的な運用リスクだ。各フラグはインシデント調査中にメンテナンス、テスト、理解が必要なコードブランチだ。午前2時に障害を理解しようとしている開発者は、関連するものを見つけるために40の条件分岐をトレースしたくない。 複数のプラットフォームチームで観察されるパターン: フラグ評価ミドルウェアがp99レイテンシのスタックフレームのトップ5に現れる。原因は大半の場合、リクエストごとに数十の条件を評価する複雑なターゲティングルールを持つ古いフラグで、誰も削除を決断しなかった2年前の意思決定の重みを背負っている。 対策は技術的というよりは組織的だ。作成されるすべてのフラグには3つの属性が必要だ: オーナー、タイプ（リリース、実験、ops、パーミッション）、期待される削除日。リリースフラグは完全ロールアウトから2スプリント以内に削除されるべきだ。実験フラグは実験終了時に削除する。フラグのインベントリはオンデマンドで監査可能であり、エンジニアリングヘルスダッシュボードに表示されるべきだ。 ## ターゲティングの粒度：エンタープライズ規模で崩壊する次元 ほとんどのフィーチャーフラグプラットフォームはパーセンテージベースのロールアウトと基本的なユーザー属性ターゲティングをサポートする。エンタープライズ規模で浮上するギャップはターゲティングの粒度だ。維持不可能なほど複雑にならずに、十分に具体的なロールアウトルールを表現できる能力。 プラットフォームチームレベルでの本番ロールアウトに有用なターゲティング階層: - **環境レベル**: 本番、ステージング、プレビュー。最初のゲートであって唯一ではない。 - **インフラセグメント**: データセンター、アベイラビリティゾーン、Kubernetesクラスタ。地理的ブラスト半径の隔離に有用。 - **アカウントまたはテナント**: B2B SaaSプラットフォームでは、ユーザー割合よりもアカウント単位のロールアウトの方が安全なことが多い。統計的なサンプルではなく、アカウント全体のトラフィックパターンを観察できる。 - **ユーザーコホート**: ベータユーザー、内部ユーザー、アクティビティ層別パワーユーザー。 - **セッション属性**: 実験フラグには有用だが、opsフラグには危険。 これをうまく実装しているプラットフォーム（LaunchDarklyとStatsigがSREチームに最も引用される）は、アクティブなロールアウト中にターゲティングロジックを変更するためのエンジニアリング時間を必要とせずに、複雑なルール合成を可能にする。そのセルフサービス能力が、30秒のロールアウト一時停止とプラットフォームチームへのチケットの違いだ。 これをうまく実装していないプラットフォームは、ターゲティングの粒度と運用のシンプルさの間のトレードオフを強制する。そのトレードオフは午前3時に浮上する。 ## ポストモーテムが繰り返し見つけること 機能に関連する本番インシデントのすべてのポストモーテムは、同じ一連の質問をする。機能はフラグの背後にゲートされていたか？ロールアウトは段階的だったか？ステージ間に検証条件はあったか？インシデントの前にキルスイッチはテストされていたか？ 4つの答えがすべてYESなら、インシデントは調整の問題だ。閾値の設定が緩すぎた、ターゲティングルールにエッジケースがあった、ネットワーク分断下でのSDK評価の挙動が考慮されていなかった。これらは設定変更とランブックの更新で解決できる。 いずれかの答えがNOなら、インシデントはアーキテクチャの問題だ。フィーチャーフラグはデバッグの便宜ではない。デプロイのアーキテクチャ決定だ。その決定は機能がシップされる前に存在するか、まったく存在しないかだ。 次のリリースの前に答える価値のある質問: 今夜何か問題が起きたとしたら、このロールアウトについてポストモーテムは何と言うだろうか？ ## FAQ ### フィーチャーフラグとは何ですか？ フィーチャーフラグとはアプリケーションコード内の条件分岐で、新しいビルドをシップすることなく、特定のユーザーやセッションに対してどのコードパスを実行するかを制御する仕組みです。デプロイとリリースを2つの独立したイベントとして分離できます。 ### フィーチャーフラグの主なタイプは何ですか？ 主に4タイプがあります: リリースフラグ（新機能のロールアウト）、実験フラグ（A/Bテスト）、opsフラグ（キルスイッチとサーキットブレーカー）、パーミッションフラグ（アクセス制御）。それぞれ異なるライフサイクルと運用目的を持ちます。 ### SLOゲートとは何ですか？なぜ重要なのですか？ SLOゲートとはロールアウトの各ステージ間で自動的に安全性を検証する仕組みです。エラーレート、p99レイテンシ、エラーバジェット消費率などを評価し、SLO違反があればロールアウトを自動停止します。SLOゲートなしのパーセンテージロールアウトはリスクを削減しているのではなく先延ばしにしているだけです。 ### キルスイッチ設計で守るべき原則は何ですか？ 3つの原則があります: 50ms以下のローカル評価（ネットワーク呼び出しを避ける）、明示的なフォールバック値（フラグサービス到達不能時の挙動を定義）、依存関係の障害下でのテスト（カオスエンジニアリングで検証）。キルスイッチはランブックの一部として退屈なものにすることが目標です。 ### フラグ負債とは何ですか？どう防ぐのですか？ フラグ負債とは目的を達成したが削除されないまま残ったフィーチャーフラグの蓄積です。各フラグにオーナー、タイプ、削除予定日を設定し、リリースフラグは2スプリント以内に削除、実験フラグは実験終了時に削除することで防げます。500フラグ以上になるとp99レイテンシへの悪影響が観察されています。 ### フィーチャーフラグ市場はどのくらい成長していますか？ フィーチャーフラグ市場は2024年の14億5000万ドルから2033年には51億9000万ドルに成長すると予測されています（Zylos Research 2026年2月）。AIを活用したフラグプラットフォームは静的なパーセンテージロールアウトと比較してロールアウト関連インシデントを73%削減します。 ### フィーチャーフラグはどのプラットフォームで実装すればいいですか？ SREチームの間で最も多く引用されるのはLaunchDarklyとStatsigです。LaunchDarklyはエンタープライズガバナンスと複雑なターゲティングが強みで、Statsigはフラグと実験とプロダクト分析を統合しています。自社のスケールと要件に応じて選択してください。