AI時代のフィーチャーフラグ活用ベストプラクティス

SUZURI 事業部エンジニアのkromiiiです

SUZURI ではオープンソースで開発されている機能フラグ（以下、フィーチャーフラグ）サービス Unleash を使ったリリース運用を行なっています^[1]

昨年 GitHub Actions を使ってフィーチャーフラグの削除漏れを通知する仕組みをテックブログに書きました

https://tech.pepabo.com/2024/09/27/check-stale-unleash-flag/

今回はこの取り組みを拡張して 2025 年現在の SUZURI におけるフィーチャフラグ活用の全体像をお話しできたらと思います。

フィーチャフラグと技術的負債

Unleash をはじめとしたフィーチャーフラグはアプリの機能をコードの変更やデプロイなしに動的に有効・無効にできるソフトウェアツールです

本番環境のみ特定の機能を無効化することもできるので、細かく機能を追加していくアジャイル開発と相性が良い感触を得ています

一方でリリースが完了し動作が安定したあとも検証用に付与したフィーチャーフラグが削除されず残ってしまう問題があり、これは Unleash の公式ドキュメントで「技術的負債（Technical debt）」と呼ばれるものです

https://docs.getunleash.io/reference/technical-debt

ここに書いてある通り、役目を終えたフィーチャフラグがコードベースに残っていると、Unleash サーバーに無駄なリクエストを送っていることになりますし、何よりコード内に無駄な条件分岐が増えてコードの可読性が悪くなります

技術的負債に対する戦略

この問題に対する一般的な戦略は、定期的に Unleash の管理画面を見に行って役目を終えたフラグがないかをチェックすることです^[2]

例えばヘルスレポートを見れば、使われていない可能性の高いフラグ（potentially stale なフラグ）は何か、そしてそれらが全体のうちのどのくらいを占めているのかがわかります

とはいえ毎日 Unleash の管理画面をチェックするのは物理的に大変であるのも事実です

そこで SUZURI では以下のような GitHub Actions を用意して、Unleash によって potentially stale と判定されたフラグを Slack に通知するようにしています^[3]

name: Stale Flag Detector

on:
  schedule:
    - cron: "0 3 * * 1-5"
  workflow_dispatch:

jobs:
  stale-flag-detection:
    runs-on: ubuntu-latest
    steps:
      - name: Detect stale flags
        id: stale-flag-detector
        uses: kromiii/stale-flag-detector@d73551c774afb65958a3b13763d8f88075313849 # v1.2.1
        with:
          unleash-api-endpoint: ${{ secrets.UNLEASH_API_ENDPOINT }}
          unleash-api-token: ${{ secrets.UNLEASH_API_TOKEN }}
          output-format: markdown-task-list
          github-pat: ${{ secrets.X_GITHUB_PAT }}
      - name: Notify
        uses: rtCamp/action-slack-notify@e31e87e03dd19038e411e38ae27cbad084a90661 # v2.3.3
        env:
          SLACK_MESSAGE: |
            古くなった Feature flag を発見しました
            ${{ steps.stale-flag-detector.outputs.flags }}
            フラグの種類を変えるかアーカイブすることを推奨します
          SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
          SLACKIFY_MARKDOWN: true

Actions の中身自体は昨年とほぼ同じですが、GitHub のカスタムアクション化したことによってすっきりと書けるようになりました

使い方の詳細は stale-flag-detector の README を参照してください

https://github.com/kromiii/stale-flag-detector

AI による自動修正

今年はさらに一歩すすんで、発見されたフラグに対する自動修正の仕組みも用意しました

以下のようなスラッシュコマンドを用意することで Claude Code によるフラグの整理が可能になります

.claude/commands/remove-stale-flag.md

# Remove Stale Unleash Flag

コードベースから指定されたstaleなUnleash feature flagを削除します。

## Arguments

- `flag_name` (required): 削除するfeature flagの名前

## Instructions

指定されたUnleash feature flag `{{flag_name}}` をコードベースから完全に削除してください。

### 手順

1. **フラグの使用箇所を検索**
   - `{{flag_name}}` が使用されている全てのファイルを検索
   - フラグのチェック、条件分岐、インポート文などを特定

2. **フラグの削除を実行**
   - フラグのチェック部分を削除
   - 常にtrueまたはfalseとして扱われるべきか判断し、適切な分岐のコードのみを残す
   - 不要になった条件分岐を削除
   - 未使用のインポート文を削除

3. **コードのクリーンアップ**
   - 削除後の余分な空行や不要なコメントを整理
   - コードの可読性を保つ

4. **変更内容の確認**
   - 修正したファイルのリストを表示
   - 各ファイルでの主な変更内容を要約

5. **テストファイルの確認**
   - テストファイル内でのフラグの使用も確認し、必要に応じて削除

### 注意事項

- フラグが有効(true)として扱われていた場合は、有効時のコードパスを残す
- フラグが無効(false)として扱われていた場合は、無効時のコードパスを残す
- 削除前に必ず該当するコードの文脈を理解してから作業を進める
- 不明な場合は、変更内容を説明してユーザーに確認を求める

使い方は Claude Code のターミナルで

/remove-stale-flag [削除対象のフラグ名]

と入力するだけです

コードベースからフラグを削除する作業は意外と複雑で、これまで自動化しようとして断念していたポイントではあったのですが^[4]、Claude Code をはじめとした Agentic なソフトウェアの登場によって可能になりました

SUZURI におけるフィーチャフラグ活用の現在地

これらの取り組みによって SUZURI ではフラグの作成から古いフラグの検知、そしてコードベースからの削除のサイクルを確立させることができました

現在フィーチャフラグを活用していて、古いフラグの整理にお困りのサービスがあればぜひ導入してみてください

脚注

1. https://tech.pepabo.com/2023/06/19/suzuri-uses-unleash

2. https://docs.getunleash.io/concepts/technical-debt#project-status

3. GitHub Enterprise Server 用のアクションを GitHub 向けに一部書き直したものです

4. https://github.com/kromiii/unleash-checker-ai