はじめに
CI/CDの自動化の話（headless-cicd）でも、デプロイ後の監視の話（observability）でもない。「デプロイした瞬間にリリースしない」——フィーチャーフラグでリリースをコントロールし、Claude Codeがそのフラグ管理を自動化する話だ。
本番にデプロイしたコードが、誰にも届かない状態で存在できる。フィーチャーフラグはこの「見えない状態」を制御するスイッチだ。フラグが「オフ」なら、本番環境に存在していても一切のユーザーには届かない。「デプロイと公開を切り離す」という設計思想が、リリースの怖さを変える。
しかし現実のフラグ管理には課題がある。命名規則がチームごとにバラバラ、廃止のタイミングを誰も管理していない（フラグスプロール）、段階的ロールアウト中のエラー率監視を人間が手動で行う——これらをClaude Codeが担えるようになった。
Unleash/LaunchDarkly MCP × Claude Code——フラグライフサイクルを自動化する
1コマンドでMCP接続
UnleashはClaude Code向けに公式MCPサーバーを提供している（getunleash.io）。
claude mcp add --transport stdio --scope project unleashプロジェクトルートの`.mcp.json`で設定し、認証情報は`~/.unleash/mcp.env`に格納してシェルプロファイルでsourceする。LaunchDarklyも同様に公式MCPサーバーを提供しており、Claude Codeから直接フラグのターゲティングルール・ロールアウト率・前提フラグ等を操作できる（具体的なツール名はlaunchdarkly.com/docsで確認してほしい）。
Unleash MCPの9つのツール
Unleash MCPはフラグのライフサイクル全体を9つのツールでカバーする。
| MCPツール | 用途 |
|----------|------|
| evaluate_change | コード変更にフラグが必要か判断 |
| detect_flag | 類似フラグの重複チェック |
| create_flag | 適切な命名でフラグ作成 |
| wrap_change | フレームワーク固有のフラグガードコード生成 |
| get_flag_state | フラグの現在状態取得 |
| set_flag_rollout | ロールアウト率の設定（5%→10%→25%等） |
| toggle_flag_environment | 環境別フラグの切り替え |
| remove_flag_strategy | ロールアウト戦略の削除 |
| cleanup_flag | 廃止フラグのクリーンアップ |
「フラグを管理するUI」ではなく「フラグを意識しながらコードを書く」ワークフローが実現する。
gitパイプによるバッチフラグレビューとCI/CD統合
# 直近20コミットでフラグが必要な変更を自動検出
git log --oneline -20 | claude -p "Review commits for missing flags"
# PRの差分からフラグ要否を分析
git diff main...feature-branch | claude -p "Analyze diff for flag requirements"`@anthropics/claude-code-action` GitHub Actionを使えば、PRレビュー時にフラグ要否チェックを自動実行できる。ツールと許可プロンプトを制限することでセキュリティも確保できる。
なお、本番フラグの変更はDelegateModeで人間の承認を必須にする設計を強く推奨する。Claude Codeからフラグを直接変更できる状態は、誤操作リスクを伴う。
CLAUDE.mdにFeatureOpsポリシーを書く——毎回プロンプトしない仕組み
CLAUDE.mdにチームのフィーチャーフラグ規約を定義するだけで、Claude Codeが自動的に従うようになる。プロンプトで毎回指示する必要がなくなる。
## FeatureOps Policy
### 命名規則（kebab-case必須）
- `feature-` プレフィックス: 新機能（ユーザー向け）
- `release-` プレフィックス: リリース管理用
- `ops-` プレフィックス: 運用・インフラ制御
### ドメイン固有ルール
- 決済（payments）ドメインのコード変更: 必ずフラグでラップすること
- 認証（auth）の変更: beta段階はフラグ必須
### ロールアウトルール
- 開始は10%以下から
- 各フェーズ間の最低保留時間: 24時間
- エラー率が1%を超えた場合は即座にロールバック
### 廃止ポリシー
- 100%到達後2週間以上経過したフラグは廃止候補
- /loopで週次の廃止候補フラグをスキャンするこのCLAUDE.mdが効くのは「決済ドメインは必ずフラグが必要」というルールの自動適用だ。コードレビューで「このPR、フラグ忘れてない？」という指摘が不要になる。開発中に気づく仕組みが機能する。
フラグ管理で得た判断（「このケースではフラグを分割した方が良い」等）をCLAUDE.mdに追記していくことで、セッションをまたいでチームの知見が蓄積される。CLAUDE.mdが育つほど、フラグ設計の品質が底上げされる。
フラグの環境管理にも注意が必要だ。開発・ステージング・本番でフラグ状態が一致していないと、「本番のみで起きるバグ」の温床になる。CLAUDE.mdに環境ごとのフラグ状態管理の標準を書いておくことが、この問題を防ぐ。
5%カナリアから100% GAまで——段階的ロールアウトの設計と実例
Money Forwardの横断デバッグ事例
Money ForwardのエンジニアがClaude Codeを開発パートナーとして活用し、Flipt + OpenFeatureによるフィーチャーフラグシステムを実装した事例がある（global.moneyforward-dev.jp）。
最も印象的なのはデバッグ場面だ。Flipt管理・Kubernetesマニフェスト・Terraform・バックエンド・フロントエンドの5つのリポジトリを横断して、404エラーの根本原因（Flipt ingressの評価エンドポイント不足）をClaude Codeが短時間で特定した。複数レイヤーにまたがる問題は人間が手動で追うと消耗する。Claude Codeはこの「横断的デバッグ」で特に威力を発揮する。
アーキテクチャ選定の判断も整理されている。JSONファイルや環境変数ではなく、リアルタイム更新・ユーザーターゲティング・デプロイなし変更が可能なFliptを採用した理由が開発ブログで詳述されている。Claude Codeがバックエンドの実装支援とフロントエンドのカスタムフック作成も担った。
段階的ロールアウトのフェーズ設計
sachith.co.ukが整理した実践的なパターンを参照しながら、標準的な段階を示す。
フェーズ0: 内部テスト（QA・社内ユーザーのみ）
↓ 24時間以上保留
フェーズ1: カナリア 5%（エラー率・パフォーマンス監視）
↓ 24時間以上保留
フェーズ2: アーリーアダプター 25%
↓ 24時間以上保留
フェーズ3: ワイドリリース 50%
↓ 24時間以上保留
フェーズ4: 全体公開 100% GA
↓ 30日後
フラグ廃止・コードクリーンアップ5%のカナリアでA/Bテストをしても、サンプルサイズが不十分なことがある。統計的有効性を確保するためのサンプルサイズ計算は事前に行うこと。また、高頻度コードパス（ループ内等）での同期フラグ評価はレイテンシの原因になる。LaunchDarkly/UnleashのSDKが提供するインメモリキャッシュの活用を検討してほしい。
フラグスプロール防止
管理されない廃止フラグの蓄積はコードの可読性を下げ、認知負荷を高める。sachith.co.ukが推奨するベストプラクティスがある。
大きな機能を1つのフラグで管理するのではなく、機能領域ごとに細粒度のフラグに分割する（例: `checkout-redesign-ui`, `checkout-v2-api`）。100%到達後30日でフラグを廃止するポリシーを自動化し、/loopによる週次廃止候補スキャンで「誰も触りたくないコード」が生まれる前に手を打つ。
MCPMarketのLaunchDarkly Automation Skillとして定義しておくと、週次の廃止候補フラグリストをSlackに自動投稿する運用も実現できる。
まとめ
`claude mcp add unleash` の1行から始めてみてほしい。最初のステップはフラグの「存在確認」（detect_flag）だけでいい。段階的に自動化を広げていける。
「デプロイと公開を切り離す」という設計哲学は、リリースを怖くなくする。フィーチャーフラグはその実装手段であり、Claude Codeはその管理コストを下げる道具だ。フラグが正しく管理されていれば、「本番で何かあったらすぐ戻せる」という安心感がチームのリリース速度を上げる——リスクを恐れてではなく、リスクをコントロールする力を持って、速く動けるようになる。
コメント