# フィーチャーフラグ ## 定義 フィーチャーフラグ(feature flags)は、「デプロイ」(コードのビルド・テスト・本番へのロールアウトというエンジニアリング上の行為)と「リリース」(ユーザー体験を意味のある形で変更する行為)を分離するための道具である。実装はデータベースの2カラムのテーブル程度の単純なものから高機能な専用システムまで幅広いが、いずれも現代的なソフトウェアシステムの必須構成要素とされる。デプロイは継続的に行われるべきエンジニアリングの問題である一方、リリースはプロダクトやマーケティングの意思決定によって変動する。この分離を怠ると、デプロイ・リリースの少なくとも一方をうまく扱えなくなるとされる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]]) フィーチャーフラグはさらに、まだ一般公開の準備ができていない差分を本番に着地・デプロイして段階的に検証する、内部ユーザーや自己選択した顧客に限定公開する、地域・料金プラン・言語などの属性でユーザー群を定義してアクセスを制御する、1%単位で段階的に展開比率を引き上げる、問題発生時に再デプロイなしで即座に機能を無効化する、といった応用に使われる。フィーチャーフラグそのものは新しい技術ではないが、実装・運用のオーバーヘッドと専用ツールの未成熟さが導入の障壁になってきた。この障壁はAIによるコスト低下で大きく下がったとされる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]]) ## 横断的知見 - **第2章が示したフィーチャーフラグ×オブザーバビリティのコホート比較は、第6章で具体的な属性・クエリレベルに落とし込まれる**: 第2章は「精密で制御可能な本番スライスをフィーチャーフラグで狙い、同じスライスのテレメトリを取り出して比較する」ことをフライホイールの核だと述べたが、具体的な実装は示さなかった。第6章は`feature_flag.auth_v2`のようにフラグ値そのものを構造化イベントの属性として直接持たせ、`GROUP BY feature_flag.auth_v2, exception.slug`という単純なクエリで新旧コードパスのエラー傾向を比較する具体例を提示する。これは第2章の未解決の問いに対する、同一書籍内の別ソースからの具体的な回答にあたる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]], [[@2026__OReilly__Observability Engineering 2E - Chapter 6 Making Structured Events Arbitrarily Wide]]) ## 未解決の問い - フィーチャーフラグの実装・運用コストをAIがどの程度下げたかを定量的に示すデータはあるか(本章の記述は定性的な主張にとどまる)。 - カナリアデプロイ・ブルーグリーンデプロイ([[カナリアテスト]]参照)とフィーチャーフラグは、どちらも段階的な本番曝露を実現する手段だが、両者を併用する場合の設計上の役割分担(インフラレベルのトラフィック制御 vs アプリケーションレベルの機能制御)はどう整理されるか。 - `feature_flag.*`属性を構造化イベントに持たせる設計は、フラグの数が増えるにつれ属性のカーディナリティ・スキーマ管理コストをどの程度押し上げるか。第6章はこの点に触れていない。 ## 関連 - 概念: [[カナリアテスト]](インフラレベルの段階展開という隣接技法)/ [[オブザーバビリティ]](フィーチャーフラグの価値を最大化する前提条件)/ [[構造化イベント]](フィーチャーフラグ値を載せる先の属性基盤) - ソース: [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 6 Making Structured Events Arbitrarily Wide]] ## 出典 - [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]] — Practice 4「Decouple Deploys from Releases Using Feature Flags」、デプロイ/リリース分離の定義と応用例 - [[@2026__OReilly__Observability Engineering 2E - Chapter 6 Making Structured Events Arbitrarily Wide]] — "Feature Flags"節、`feature_flag.*`属性とコホート比較クエリの具体例