feature-flagging

フィーチャーフラグ

フィーチャーフラグをただ頻繁に使うのではなく、適切に活用するためのシニアエンジニア向けプレイブックです。

フィーチャーフラグはインフラストラクチャです。そのように扱えば、再デプロイなしで、キルスイッチ、段階的なロールアウト、A/B 実験、権限ゲート、運用上の切り替えを実現できます。気軽に扱うと、コードベースで最も膨れ上がる技術的負債になります。何千もの使われなくなったフラグ、競合する評価ロジック、壊れやすいターゲティング、誰も全体を把握できていない権限の範囲が生じます。

このスキルは、後者の事態を防ぐための規律です。フィーチャーフラグのプラットフォーム（LaunchDarkly、Flagsmith、Split.io、VWO FME、GrowthBook、Statsig、PostHog、Optimizely。原則においてプラットフォームは問いません）があることを前提としています。また、エンジニアリングチームがターゲティングルールと SDK の統合を実装できることも前提としています。難しいのは運用上の規律であり、このスキルで扱うのはその部分です。

このスキルを使うタイミング：フラグを導入、変更、既存フラグの監査、またはフラグ関連のガバナンスポリシーを設計しようとしているときはいつでも。

---

このスキルの目的

このスキルは、フラグの作成から廃止まで、運用上のライフサイクル全体を扱います。フラグの種類と、それらを混在させないための規律。コードレビューに耐える命名規則。後付けではなく、作成時点で組み込むライフサイクルの想定。壊れにくく組み合わせられるターゲティングルール。リリースのリスクに応じたロールアウト戦略。四半期ごとのスケジュールで行う古いフラグの管理。アクセスと監査のバランスを取るガバナンスと権限。フラグがレイテンシの負担にならないためのパフォーマンス上の考慮事項。両方の分岐を網羅するテストパターン。ロールバックの規律。ロールアウト全体を通じたオブザーバビリティ。

このスキルでは実験の設計は扱いません。仮説の記述、サンプルサイズ、MDE、根拠のある意思決定に至るための規律については、experiment-design スキルを参照してください。統計分析や分散の削減も扱いません。それらについては experimentation-analytics スキルで扱います。プラットフォーム固有のツールも対象外です。MCP コマンド、認証、プラットフォーム固有の設定については、選択したプラットフォームのドキュメントを参照してください。このスキルでは運用上の枠組みを定め、プラットフォームがそれを実装します。

---

5 種類のフラグ

フラグの種類を混在させることが、フラグの混乱の主な原因です。フラグは5種類のいずれかです。作成時に種類を決め、後から変更しないでください。

リリースフラグ。 コードは本番環境にありますが、無効になっています。新機能を無効な状態でリリースし、一定の割合のユーザーに対して有効化した後、段階的に100％へ拡大します。存続期間：短期間、数日から数週間。ライフサイクル：リリース後に確実に削除します。一般的な名前の接頭辞：release_。

実験フラグ。 ユーザーをランダムにバリアントへ割り当て、コンバージョンを測定します。フラグは、ユーザーにどのバリアントを表示するかを制御します。存続期間：中期間、1〜6週間。ライフサイクル：バリアントを選定し、コードパスを統合して、フラグを削除します。一般的な名前の接頭辞：exp_。

運用フラグ。 問題のある機能を再デプロイせずに運用チームが無効化できる、キルスイッチまたはサーキットブレーカーです。存続期間：長期間、多くの場合は数年です。ライフサイクル：通常は削除せず、待機状態で維持します。一般的な名前の接頭辞：ops_。

権限フラグ。 プランの階層、顧客グループ、または地域に基づいて、機能へのアクセスを制御します。無料プランのユーザーには一方の機能セットが表示され、エンタープライズプランのユーザーには別の機能セットが表示されます。存続期間：長期間。ライフサイクル：請求およびアクセスのインフラストラクチャとともに管理します。一般的な名前の接頭辞：perm_。

設定フラグ。 契約上の設定に基づいて、一部の顧客に異なる動作を提供します。ホワイトラベルのテナント、規制対象地域、アカウントごとのカスタムロールアウトスケジュールなどが該当します。存続期間：長期間。ライフサイクル：営業およびプロダクトに関する契約に従って管理します。一般的な名前の接頭辞：cfg_。

種類ごとに、ライフサイクル、ガバナンス、削除に関する期待が異なります。1つのフラグに複数の用途を混在させること（フラグがキルスイッチと権限ゲートを兼ね、さらに実験にも使われている状態）が、フラグの混乱の最も一般的な原因です。フラグの目的が変わったら、新しいフラグを作成して移行してください。既存のフラグに別の用途を詰め込まないでください。

---

フラグの命名規則

フラグ名には、種類、担当者、目的を含めます。この情報がないと、9か月後にはフラグの一覧が判読不能になり、references/stale-flag-cleanup-playbook.md のクリーンアップ手順でも、どのフラグを安全に削除できるか判断できません。

このスキルで推奨する規則は <type>_<owner>_<semantic_name>_<version_or_date> です。

• release_checkout_redesign_2026q2
• exp_billing_pricing_v2
• ops_search_circuit_breaker
• perm_enterprise_audit_log
• cfg_tenant_acme_custom_dashboard

snake_case または kebab-case のどちらかを選び、組織全体で統一して使い続けてください。同じプラットフォームで両方を混在させると、午前3時にタイポが原因のバグが発生します。曖昧な名前は徐々に使われなくなります。たとえば、new_feature、temp_toggle、test_flag、pricing_update_v3 などです。数か月もすると、どの pricing_update がリリース済みで、どれが使われていないのか、誰にもわからなくなります。

型付き接頭辞の表、担当者の規則、名前の付け方が不適切な既存フラグの移行計画など、詳しい説明については references/flag-naming-conventions.md を参照してください。

---

フラグのライフサイクル

すべてのフラグには5つのライフフェーズがあります。各フェーズには明確な開始条件と終了条件があります。フェーズを飛ばすと、フラグが整理されずに蓄積していきます。

誕生。 フラグを作成し、明示的なメタデータを設定します。所有者、種類、削除予定日（リリースフラグと実験フラグの場合）、ロールアウト計画、監視方法を含めます。メタデータは省略できません。これがなければ、フラグにライフサイクルの終わりはありません。

成長期。 フラグの背後にある機能を開発します。無効（現在の本番環境）ブランチと有効（新しい）ブランチの両方のコードパスが存在し、どちらもテストされています。フラグは本番環境ではオフのままです。

リリース。 本番環境へのロールアウトを開始します。割合を低く（1％または5％）設定して始め、各段階で監視し、指標に問題がなければ割合を引き上げます。ロールアウトのゲート条件は、references/flag-rollout-strategies.md に記載されています。

成熟期。 フラグのロールアウトが100％に達しています。新しいコードパスが本番環境のパスになります。ロールアウト中には現れなかった問題を検出するため、少なくとも30日間は監視を続けます。

終了。 フラグをコードから削除し（ゲート処理を削除するPR）、プラットフォームからも削除します。監査証跡には削除を記録します。

非対称なのは、誕生はすばやく進む一方（1つのPRでフラグを作成し、新しいコードをゲートできます）、終了には意図的なクリーンアップが必要な点です。フラグが整理されずに蓄積する主な原因は、終了が未完了のままになることです。誕生と終了はセットで計画する必要があり、終了計画は誕生時のメタデータに含めます。

各フェーズのチェックリストについては、references/flag-lifecycle-checklist.md を参照してください。

---

ターゲティングルールとセグメンテーション

ターゲティングルールとは、ユーザー、アカウント、またはリクエストに処理対象のブランチを適用するかどうかを決めるブール式です。ターゲット指定に役立つディメンションは4つあります。

• ユーザー属性。 user.email_domain == "acme.com"、user.signup_date > "2026-01-01"、user.plan == "enterprise"。
• アカウント属性。 account.tier == "enterprise"、account.region == "EU"、account.feature_x_enabled == true。
• リクエスト属性。 request.country == "US"、request.device_type == "mobile"、request.api_version >= 3。
• 時間ベース。 time > "2026-06-01T00:00:00Z"、time < "2026-12-31T23:59:59Z"。

AND、OR、NOT を組み合わせます。式はシンプルに保ってください。3つの句を入れ子にする必要があるなら、分類体系に問題があります。共有属性を持つユーザーの名前付きグループであるセグメントを定義して、そのセグメントをターゲットにするか、複数のフラグに分割してください。

よくある落とし穴は、頻繁に変化する属性をターゲティングに使うことです。たとえば、ルールが user.last_login_date > "2026-04-01" の場合、5月1日にログインしたユーザーには処理対象のブランチが適用されます。しかし、翌日にはその値が変わり、今度は制御ブランチが適用されます。ユーザー体験が揺れ動いてしまいます。変動しやすい属性は、リアルタイムのターゲティングルールではなく、スナップショットから算出するセグメントで使用してください。

パターンの一覧とアンチパターンについては、references/targeting-rule-patterns.md を参照してください。

---

ロールアウト戦略

ローンチごとに適したロールアウト戦略は異なります。リスクプロファイルに合わせて戦略を選びます。

パーセンテージロールアウト。 リリースフラグのデフォルトです。1 または 5 パーセントから始めます。ピーク時間帯を少なくとも 1 時間、エラー率、レイテンシ、主要な成功指標を監視します。問題がなければ 10 パーセントに引き上げて監視します。次に 25 パーセント、50 パーセント、100 パーセントと引き上げます。所要時間はトラフィックによって異なりますが、一般的なパターンは 1 パーセントで 1 日、次に 10 パーセントで 2 日、50 パーセントで 2 日、最後に 100 パーセントです。4 時間未満で完了する本番環境へのロールアウトは、通常、進行が速すぎます。

コホートロールアウト。 まず社内従業員、次にベータ版の顧客、続いて無料プラン、最後に有料プランの順で進めます。各コホートは名前付きのセグメントで、フラグはそれらを順番に進みます。ロールアウトの速度よりも影響範囲が重要となる、リスクの高いローンチに使用します。

地域別段階ロールアウト。 一度に 1 つのリージョンで進めます。コンプライアンスに慎重な配慮が必要な機能（データレジデンシー、規制に関する開示、リージョン固有の UX）では、これがデフォルトです。プラットフォームのリージョンターゲティング機能と組み合わせることで、ルールを手作業で記述する必要がなくなります。

時間ベースのロールアウト。 既知の時刻に切り替えをスケジュールします。特定のタイミングでトグルを切り替える必要がある、マーケティングと連携したローンチに役立ちます。タイムゾーンに注意してください。東部時間の午前 0 時は UTC の午前 0 時ではありません。週末のオンコール体制がない限り、祝日の時間ベースロールアウトは避けてください。

「段階的に引き上げて監視する」というルール：パーセンテージを引き上げるたびに、次に進む前に少なくともピーク時間帯の 1 時間、システムを監視します。ピーク時間帯は、新しい障害モードの発生率が最も高くなる時間です。ピーク時に 1 時間システムが安定していれば、次の段階に進んでも安全です。オフピーク時に引き上げてすぐに次へ進んでも、変更を実際にテストしたことにはなりません。

戦略の詳細と、チェックアウトの再設計に関する実例については、references/flag-rollout-strategies.md を参照してください。

---

古いフラグの管理

有効なフラグはどれも、実行時のコストを増やします。評価のオーバーヘッド、保守が必要な 2 つのコードパス、コードを読むエンジニアの認知的負担です。フラグ 1 つなら問題ありません。使われなくなったフラグが 200 個もあると、生産性を継続的に損ないます。

ほとんどのプラットフォームは、一定の日数（N 日間）評価されていないフラグを報告する、古いフラグのレポート機能をサポートしています。しきい値のデフォルトは、リリースフラグと実験フラグが 30 日、運用フラグと権限フラグが 90 日です。30 日間評価されていないフラグは、本番環境で廃止済み（ターゲティングルールに該当するユーザーがいない）か、コード上で完全に使われなくなっています（ゲーティングの呼び出しは削除されたものの、フラグ自体は削除されていません）。

クリーンアップの手順は機械的です。

1. プラットフォームから古いフラグのレポートを生成します。
2. フラグごとに、オーナー、最終評価日時、種類、推奨アクションを特定します。
3. 四半期ごとのミーティングでトリアージします。維持、削除、調査のいずれかを選びます。
4. コード側の削除について、フラグごとに 1 つの PR を作成します。1 つずつならレビュー可能ですが、10 個をまとめるのは適切ではありません。
5. PR のマージ後に、プラットフォームから削除します。

クリーンアップが自動的に行われない理由は、フラグの削除にはレビュー、テスト、デプロイのオーバーヘッドを伴うコード変更 PR が必要だからです。PM がそれを評価することはありません（機能はすでにリリース済みです）。やがて SRE は、そのノイズにうんざりします。解決策は、削除を個別の作業にせず、ローンチチェックリストの一部にすることです。フラグを作成するときに、メタデータに削除日を記録します。ローンチチケットには、30 日後に「フラグ X を削除」と記載されたフォローアップのサブチケットを予定として追加します。ローンチが順調に進めば、そのサブチケットは完了します。

孤立したフラグのオーナー交代を含む四半期ごとの全サイクルについては、references/stale-flag-cleanup-playbook.md を参照してください。

---

ガバナンスと権限

役割によって必要なアクセス権は異なります。エンジニアリングチームは幅広くフラグを作成できます。プロダクトチームは開発環境とステージング環境でターゲティングルールを作成できます。本番環境のターゲティング変更は、より少人数の承認者による承認が必要です。

推奨する権限レベル：

• 閲覧者。 すべての環境で読み取り専用です。エンジニアリング、プロダクト、サポートの大半が対象です。
• 編集者。 開発環境とステージング環境でフラグを作成、変更できます。フラグを担当するチームが対象です。
• 承認者。 フラグの変更をステージング環境から本番環境に反映できます。少人数のグループで、通常はチームリーダーとオンコールエンジニアが対象です。
• 管理者。 フラグの削除、権限の変更、監査ログへのアクセスなど、すべてを管理できます。最少人数のグループで、プラットフォームチームとバックアップ担当者が対象です。

本番環境に影響するフラグの変更は、チャットではなくデプロイと同様にレビューを通します。変更リクエストには、ルールの差分、ロールアウト計画、ロールバック条件を記載します。承認者がレビュー後に変更を適用します。誰かがボタンをクリックしただけで、ルールが本番環境にひそかに反映されることはありません。

監査証跡：すべてのフラグ変更について、実行者、タイムスタンプ、変更前後のルール、理由を記録します。ほとんどのプラットフォームでこの機能が利用できます。他のインフラストラクチャイベントとあわせて、中央ログアグリゲーターに書き込むよう設定してください。

環境への反映：開発環境でルールをテストし、ステージング環境、本番環境へと順に反映します。本番環境で直接ルールを作成すると、ステージングテストとレビューゲートの両方をスキップすることになります。デプロイと同様に、各段階で同じレビューと承認を行い、開発環境 → ステージング環境 → 本番環境の順で進めてください。

緊急時のオーバーライド：午前3時にキルスイッチを操作できるのは誰ですか？手順を文書化し、インシデント訓練でテストし、オーバーライド経路が実際に機能することを確認してください。誰も見つけられないキルスイッチは、キルスイッチではありません。

---

フラグの依存関係と競合

フラグ同士の相互作用によって生じる、2つの障害パターンがあります。

依存関係。 フラグ B のコードパスが、フラグ A がオンであることを前提としています。ほとんどのプラットフォームではモデル化が困難です。SDK はフラグ間の関係を認識しません。可能な限り避けてください。表現する必要がある場合は、フラグの説明に記載し、A がオフで B がオンの場合に失敗するユニットテストを追加してください。

競合。 2つのフラグが同じ箇所をターゲットにしている場合は、後勝ちになります。結果は評価順序に依存し、その評価順序は SDK の実装に依存し、SDK の実装はプラットフォーム内部の仕組みに依存します。共有キー監査で検出してください。同じコードパス上でターゲティングルールが重複するフラグは、競合候補です。通常、プラットフォームはこれに警告を出しません。チームが監査する必要があります。

チーム間の競合は、特に危険なケースです。チーム Alpha のチェックアウト再設計用リリースフラグが、チーム Bravo の価格ページでの実験と相互作用します。両方のフラグが適用され、ユーザーに壊れた UI が表示されるまで、この相互作用に気づけません。解決策は、experiment-design で説明されている実験レジストリを使って、事前に調整することです。午前2時のインシデントで発覚するのではなく、計画段階でローンチ前に見つけてください。

相互排他的な実験グループ（プラットフォームが、ユーザーはテスト A かテスト B のいずれか一方にのみ属し、両方には属さないよう強制する場合）については、mutex の適用に関する experiment-design スキルの説明を参照してください。

---

パフォーマンスに関する考慮事項

フラグの評価は、関数呼び出し（低コスト）に、場合によってはプラットフォームへのネットワーク呼び出し（高コスト）が加わるものです。パフォーマンス上の問題は、後者にどれだけコストがかかるかです。

積極的にキャッシュしてください。ほとんどのサーバーサイド SDK では、リクエスト単位、セッション単位、またはユーザー単位でフラグ値をキャッシュできます。ネットワーク呼び出しがフラグを確認するたびではなく、関連するスコープごとに一度だけ発生するようにキャッシュを設定してください。50 個のフラグを評価するリクエストでは、50 回ではなく、リクエスト開始時に一度だけプラットフォームにアクセスするべきです。

一括評価：ほとんどのプラットフォームでは、ユーザーまたはコンテキストに対するすべてのフラグを一度の呼び出しで評価できます。これを利用してください。「50 個のフラグを個別に確認する」場合のレイテンシコストは、確認ごとのオーバーヘッドの50倍です。「50 個すべてを返す一括評価を一度行う」場合のレイテンシコストは、1回のラウンドトリップに、確認ごとの高速な検索を加えたものです。

SDK の選択：レイテンシ、セキュリティ、鮮度が重要な機密性の高いロジックには、通常、クライアントサイド SDK よりサーバーサイド SDK が適しています。クライアントサイド SDK は、ユーザーが DevTools でフラグ値を確認できる UI 専用の動作に適しています。両方を混在させると一貫性が損なわれます。サーバーとクライアントでユーザーに異なるフラグ値が返されると、UI が壊れます。

レイテンシ予算：リクエストごとに50個のフラグを評価する場合、一般的なケースで追加される時間は5 ms以内に抑えるべきです。それを超える場合は、SDK の設定に問題があります（キャッシュなし、一括評価なし、ホットループ内での評価など）。スケールする前に監査してください。

---

フラグで制御するコードのテスト

両方の分岐をテストする必要があります。無効な分岐は既存の本番環境の動作で、有効な分岐は新しいコードです。ユニットテストでは、テストのセットアップ時に明示的にフラグを上書きして、両方をテストしてください。

切り替わるときの挙動をテストしてください。セッション中にユーザーのフラグ値が変わると、どうなるでしょうか。適切に動作するほとんどのシステムでは、ユーザーはリクエスト開始時の値で現在のリクエストを完了し、次のリクエストで新しい値を確認します。この前提を明示的に文書化してください。セッション中にシステムがユーザーの値を切り替えるなら、通常それはバグです。

フラグを上書きする統合テスト：ほとんどのプラットフォームでは、本番環境に影響しない、テスト専用のフラグ上書きに対応しています。両方の分岐を実行するエンドツーエンドテストで利用してください。テスト用の上書きがなければ、統合テストでは本番環境のフラグ設定を共有する必要があります。その場合、本番環境でまだ無効になっている新機能をテストできません。

よくある失敗例：成果が出た実験をリリースしたものの、適切なターゲティングルールが設定されていたのはテスト環境だけだったケースです。テスト環境では、緩やかなルールによってテストユーザーの100％が対象になっていましたが、本番環境のルールはより厳しく、対象は20％に限られています。測定した効果は本番環境では再現されません。段階的ロールアウトで検出してください。本番環境で最初の1％に展開した時点で、さらに拡大する前にテスト結果と一致するべきです。

---

ロールバックの手順

フラグは、フラグで制御する変更を即座にロールバックするのに便利です。コードのロールバックの代わりにはなりません。フラグで制御されていないコード（既存の経路に対する修正や、同じデプロイに含まれる無関係な変更）でバグが発生した場合、フラグを切り替えても何も変わりません。フラグによるロールバックは複数ある手段の一つとして扱い、唯一の手段にはしないでください。

フラグを切り替えて問題が解決する場合は、ロールバック手順を文書化してください。解決しない場合は、バグがフラグで制御されていないコードか、フラグの依存関係にあります。それに応じて原因を診断し、フラグが機能しなかったと思い込まないでください。

スピードが重要です。本番環境でどれだけ速くフラグを切り替えられますか。目標は、UI または MCP 経由で60秒以内、API と認証を経由して5分以内です。プラットフォームでフラグ変更が反映されるまでに15分かかるなら、それはインシデント対応における実際の制約であり、チーム全員が把握しておくべきです。

練習してください。インシデント訓練にフラグのロールバックを含めてください。キルスイッチを初めて切り替えるのは、収益が落ちている午前3時ではなく、全員が落ち着いている訓練の場であるべきです。

---

フラグのオブザーバビリティ

他のリクエストデータと合わせて、フラグの評価をログに記録します。評価時点のフラグ値は、コンテキストフィールドとしてリクエストログに記録されます。遅いリクエストやエラーを調査するとき、ログで有効だったフラグ値を確認できます。

フラグの評価率の変化をアラートで通知します。フラグの評価率が突然低下した場合、ルールの設定ミス（該当するユーザーがいない）か、SDK の故障が考えられます。いずれの場合も、チームが数分以内に把握できるようにしてください。

本番環境のロールアウト用にダッシュボードを作成します。地域、プラン、デバイスなどの内訳ごとに、どの割合のユーザーが処置群と対照群を見ているかを確認できます。ダッシュボードがなければ、ロールアウトの状況はブラックボックスです。ダッシュボードがあれば、SQL クエリを書かずに「セグメント間で実際に均等にロールアウトできているか」をチームが確認できます。

エラートラッキングと連携します。ロールアウト中にエラーが急増した場合、ダッシュボードでエラーとフラグ値に相関があるかどうかを確認できるようにします。処置群のブランチで急増している場合は、フラグをロールバックします。両方のブランチで急増している場合は、問題はフラグと無関係であり、フラグをロールバックしても解決しません。

---

よくある失敗（簡易版）

短いパターン集です。詳細は references/ を参照してください。

• 「リリースしたのに、ユーザーの 90 パーセントに古いバージョンが表示される」は、ロールアウトルールに誤りがあることを意味します。実際のユーザー属性に照らしてルールを監査してください。
• 「フラグを無効にしたのに、まだバグが起きている」は、問題のコードパスがフラグで制御されていない、値がキャッシュされている、または依存するフラグがまだ有効であることを意味します。
• 「使われなくなったフラグが 400 個あり、削除するのはリスクが高すぎる」は、クリーンアップが一度も行われていないことを意味します。今すぐ四半期ごとのサイクルを始め、フラグごとに PR を作成してください。
• 「同じコードパスを対象にするフラグが 2 つあり、どちらが優先されるのかわからない」は、競合を意味します。共有キーを監査し、どちらかを正規のフラグとして決め、もう一方を廃止してください。
• 「フラグ評価器がレイテンシの急増を引き起こしている」は、一括評価またはキャッシュが不足していることを意味します。SDK の設定を監査してください。
• 「財務チームに機能トグルへのアクセス権を与えたいが、本番ルールは変更させたくない」は、権限の階層化が必要であることを意味します。財務チームには閲覧者、担当チームには編集者、チームリードには承認者の権限を付与してください。

---

フレームワーク：持続可能なフィーチャーフラグ運用のための 14 の考慮事項

フィーチャーフラグを設計または監査するときは、次の 14 の考慮事項を確認してください。

1. タイプの明確化。 リリース、実験、運用、権限、または設定のいずれかを選びます。作成時に 1 つ選び、その後変更しないでください。
2. 命名。 タイプのプレフィックス、所有者のプレフィックス、意味が明確な名前を使用します。曖昧な名前は避けてください。
3. ライフサイクルの計画。 作成時に導入時期と廃止時期を決めます。メタデータに削除日を記録してください。
4. ターゲティングの分類体系。 ユーザー、アカウント、リクエスト、または時間ベースのいずれかを選びます。変動しやすい属性は避けてください。
5. ルールの単純化。 AND、OR、NOT のみを使用します。ネストした節が 3 つあるなら、分類体系に誤りがあります。
6. ロールアウトの適合性。 リスクプロファイルに合った戦略を選びます。低リスクにはパーセンテージ、中リスクにはコホート、コンプライアンスには地域、協調が必要なローンチには時間ベースを使用してください。
7. 段階的な引き上げの徹底。 パーセンテージの各段階で、ピーク時間を 1 回設けます。4 時間のロールアウトは行わないでください。
8. 古いフラグの定期的な整理。 四半期ごとにクリーンアップします。削除ごとに PR を 1 つ作成します。ローンチチェックリストに削除を含めてください。
9. 権限の階層化。 閲覧者／編集者／承認者／管理者を設定します。管理者の数は承認者より少なく、承認者の数は編集者より少なくしてください。
10. 環境間のプロモーション。 レビューゲートを設けて、開発環境からステージング環境、本番環境へと進めます。本番環境で本番ルールを作成しないでください。
11. 競合の監査。 同じ対象領域に 2 つのフラグがある場合は競合です。共有キーの監査で検出し、実験レジストリを通じてチーム間で調整してください。
12. パフォーマンス予算。 一括評価、キャッシュ、機密性の高いロジック向けのサーバーサイド SDK を使用します。フラグを 50 個チェックする場合の合計予算は 5 ms です。
13. ブランチのテスト。 両方のコードパスをテストで網羅します。遷移時の動作を文書化してください。
14. オブザーバビリティ。 すべてのフラグ評価をログに記録します。すべてのロールアウトをダッシュボードで可視化します。インシデント発生時は、エラーとフラグ値の相関を確認します。

---

必要なデータを入手できない場合

このスキルの出力は、それ自体では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースを利用できない、あるいは検証できない場合、認められる出力は、何が必要だったのか、実際に何を取得または検証できたのか、そして出力のどの部分に影響するのかを明示した成果物です。成果物を完成させるために必要な数値を捏造、推定、または補間することは、決して認められません。不足している情報を明示すれば、それで完全な回答です。

---

参照ファイル

以下の参照ファイルは、このスキルを補足します。

• references/flag-naming-conventions.md：型を示すプレフィックス、オーナーを示すプレフィックス、意味に基づく命名パターン、および既存の不適切な名前のフラグに対する移行計画。
• references/flag-lifecycle-checklist.md：ライフサイクルの各段階に沿った、作成から削除までのチェックリスト。
• references/flag-types-reference.md：5 種類のフラグの詳細、具体例、よくある落とし穴。
• references/stale-flag-cleanup-playbook.md：四半期ごとの整理プロセスと、オーナー不在のパターン。
• references/targeting-rule-patterns.md：ターゲティングルールの一般的なパターンとアンチパターン。
• references/flag-rollout-strategies.md：パーセンテージ、コホート、地域、時間ベースの戦略と、それらを組み合わせた戦略、および具体例。
• references/governance-and-permissions.md：権限レベル、環境への昇格、承認ワークフロー、緊急時のオーバーライド。

---

結び：フラグを削除するとき

フラグは、削除するのが基本です。コードベースに恒久的に残るフラグ（運用上のキルスイッチ、課金に紐づく権限フラグ、契約に紐づく設定フラグ）は例外であり、標準ではありません。ほとんどのリリースフラグと実験フラグは、リリース判断から 30 日以内に削除してください。

フラグを残すコストは現実のものです。使われなくなったフラグがひとつあるたびに、保守すべきコードパスが 2 つ、正常な状態を保つべきテストスイートが 2 つ増え、次の四半期にファイルを読むエンジニアの認知的負担がひとつ増えます。そのコストは、何百ものフラグにわたって累積します。

フラグを削除する規律は、次の四半期に自分が作業するコードベースを大切にする規律です。デプロイ後の後片付け、使われていないインポートの削除、インシデントから 1 週間以内のポストモーテムの作成と同じ規律です。どれも今日の機能リリースにはつながりません。しかし、すべてが明日の機能リリースを容易にします。

プラットフォーム固有のパターン（どのプラットフォームがどのフラグタイプに最適か、MCP コマンドの形式、注意すべき落とし穴の所在）については、選択したプラットフォームのドキュメントを参照してください。このスキルの上位にある実験設計の層（仮説に関する規律、サンプルサイズ、意思決定）については、experiment-design スキルを参照してください。このスキルの下位にある分析の層（分散の低減、逐次検定の数理、ベイズ的な代替手法）については、experimentation-analytics スキルを参照してください。