flag-cleanup

flag-cleanup

古くなったフィーチャーフラグをアーカイブまたは削除します。方法は 2 つあります。アーカイブ（元に戻せるソフト無効化）または削除（完全な削除。安全策として、必ず先にアーカイブします）。このスキルは、GrowthBook の Code References API（設定されている場合）から呼び出し箇所を提示するか、ユーザーの現在のディレクトリに対して Grep を実行し、一般的な Read／Edit ツールを使ったエージェントのコードクリーンアップを調整します。

すべての API 呼び出しは、同梱のヘルパー ${CLAUDE_PLUGIN_ROOT}/scripts/gb-call を経由します。GB_API_KEY が必要です。シェルで設定するか、/growthbook:gb-setup によって ~/.config/growthbook/.env に書き込んでください。未設定または無効な場合、gb-call のエラーメッセージに /growthbook:gb-setup への案内が表示されます。

必須入力

開始する前にユーザーから情報を収集します。不足している情報を尋ねてください。

• Flag ID — ケバブケースのキーです。ユーザーが説明を提示した場合は、まず flag-search に渡して特定します。
• 操作 — archive（元に戻せます）または delete（完全な削除。アーカイブを含みます）。表現から推測します。「archive」／「disable」→ archive、「delete」／「remove」／「clean up」／「get rid of」→ delete。変更を加える前に確認します。

ワークフロー

次のチェックリストで進捗を管理します。ステップを飛ばしたり、順序を変えたりしないでください。各ステップの完了が次のステップに進む条件です。

- [ ] 1. Fetch flag, verify safety preconditions (incl. bulk experiment check)
- [ ] 2. Compute defaultValue + detect behavior-change divergences
- [ ] 3. Find call sites (Code References API → Grep fallback w/ cwd check)
- [ ] 4. Walk the user through inlining, batched by file
- [ ] 5. Archive the flag (revision-and-publish; branch to 5a on 403, 5b on 409)
- [ ] 6. Verify-or-rollback gate (delete path only)
- [ ] 7. Delete the flag (delete path only)
- [ ] 8. Report, including reverse-prerequisite limitation warning

1. フラグを取得し、安全性の前提条件を確認する

gb-call GET /api/v2/features/<flag-id>

応答から次の情報を取得します。archived（ブール値）、defaultValue、valueType、environmentSettings（有効になっている環境）、rules（experiment-ref ルールを含む配列全体）、holdout（参考情報）、project。

404 の場合は中止し、「ID <flag-id> のフラグはありません。」と伝えます。フラグの一覧表示には flag-search を提案します。

次の安全性チェックを実行します。いずれかに該当したら中止してください。

• archived === true で、ユーザーがアーカイブを求めた場合 → すでにアーカイブされています。意図を再確認する（「アーカイブするとおっしゃいましたが、このフラグはすでにアーカイブされています。削除の意味でしたか？」）か、そのまま終了します。

• archived === true で、ユーザーが削除を求めた場合 → 前回のクリーンアップセッションの続きであるか、ユーザーが UI でアーカイブした可能性があります。次のように尋ねます。

  このフラグはすでにアーカイブされています。前回のクリーンアップの続きのようです。コードベース内の呼び出し箇所では、すでにフラグの値を直接記述しましたか？

  • はい → 動作変更の確認とコードクリーンアップの手順を省略し、削除の前に確認またはロールバックするためのゲートに進みます。
  • いいえ → コード参照がまだ残っている可能性があるため、引き続きステップ 2～4 を実行します。

  はいの場合はステップ 6 に進みます（ステップ 5 のアーカイブ処理は、archived: true → true ではサーバー側に変更がないため何も行いません。ハンドラーは feature.archived が要求された値と等しい場合に処理を早期終了します）。

• フィーチャーに neverStale: true が設定されている場合。ステール状態エンドポイントで確認します。

  gb-call GET '/api/v2/stale-features?ids=<flag-id>'
  

  応答に staleReason: "never-stale" が含まれている場合は中止します。

  このフラグには neverStale が設定されています。つまり、誰かが明示的に、これを自動クリーンアップの対象にすべきでないと指定しています（キルスイッチ、運用トグル、ライセンスゲートなど）。続行するには、まず GrowthBook UI の <host>/features/<flag-id> で neverStale フラグを解除してから、もう一度実行してください。

• 実行中の実験を指すアクティブな experiment-ref ルールがある場合。一般的なケースは、1 回の一括呼び出しで確認できます。

  gb-call GET '/api/v1/experiments?trackingKey=<flag-id>&status=running'
  

  experiment-launch は慣例として trackingKey === flag-id を設定するため、この方法で確認できます。応答配列が空でない場合は中止します。

  このフラグは、まだ実行中の実験 <exp-id>（<exp-name>）に接続されています。まずその実験を停止（experiment-stop）してから、もう一度実行してください。

  防御的な相互チェック。 一括呼び出しの結果が空でも、フラグの rules 配列に experiment-ref ルールがある場合、experimentId ≠ trackingKey として実験が手動で接続されている可能性があります。代替手段として、各 experiment-ref ルールを順に処理し、それぞれを取得します。

  gb-call GET /api/v1/experiments/<experiment-id-from-rule>
  

  いずれかが status: "running" を返した場合は、同じメッセージを表示して中止します。 一時ロールアウトの確認。 リンクされた実験を取得する際に、status: "stopped" かつ enableTemporaryRollout: true のものも確認してください。これらはブロッカーではありません（実験は停止しています）が、手順 2 ではインライン置換に勝者の値を使用する必要があります。次のリマインダーを表示してください。

  "実験 <exp-id> で一時ロールアウトが有効です。現在、すべてのユーザーに勝者の値が表示されています。手順 2 では defaultValue ではなく、勝者の値をインライン置換に使用します。"

• フラグを参照している下書き実験。 実行中の実験より優先度は低いものの、警告して確認する価値があります。別のステータスフィルターを指定して、同じ一括クエリを再利用します。

  gb-call GET '/api/v1/experiments?trackingKey=<flag-id>&status=draft'
  

  結果が空でない場合は、次のように警告します。

  注意：このフラグは、下書き実験 <exp-id> の trackingKey です。フラグを削除しても直ちに問題は起きませんが、その実験を正常に開始できなくなります。続行しますか？

• フラグの未解決の下書きリビジョン。 アーカイブすると、下書きは破棄されます。

  gb-call GET /api/v2/features/<flag-id>/revisions/latest
  

  404 の場合、下書きは存在しないため、そのまま続行します。下書きが返された場合は停止します。

  このフラグにはアクティブな下書きリビジョン（<version>）があります。フラグをクリーンアップすると、保留中の変更は破棄されます。まず GrowthBook の UI で <host>/features/<flag-id> を開き、下書きを公開するか破棄してください。

• /stale-features では古いフラグとして検出されず、ユーザーが削除を求めている場合。 警告しますが、停止はしません。

  注意：GrowthBook では、このフラグは古いフラグとして検出されていません。<env> で引き続き有効になっており、アクティブなルールがあります。続行しますか？

2. インライン置換値を計算し、動作の変更を検出する

アーカイブすると、すべてのルールの評価が停止し、すべての呼び出し元に対してフラグは defaultValue を返します。通常、インライン置換値には defaultValue を使用しますが、常にそうとは限りません。以下の一時ロールアウトのケースを参照してください。

まず、アクティブな一時ロールアウトを確認します。 フラグ内の各 experiment-ref ルールについて、リンクされた実験を取得します。

gb-call GET /api/v1/experiments/<experiment-id>

experiment.status === "stopped" かつ experiment.enableTemporaryRollout === true の場合：

• 実験の releasedVariationId から、トラフィックの 100% に提供されているバリエーションが分かります。

• そのバリエーションの値を、experiment-ref ルールの variations 配列から探します。

• その値が、defaultValue ではなく、現在すべてのユーザーに表示されている値です。

• これをインライン置換値として使用します。ユーザーにはっきりと警告してください。

  "このフラグでは一時ロールアウトが有効です。現在、すべてのユーザーに勝者の値 <winner_value> が表示されています。クリーンアップ後は、すべてのユーザーに defaultValue: <default_value> が表示されます。これらの値が異なる場合、正しい置換値は <default_value> ではなく、インライン化した <winner_value> です。"

valueType: "json" の場合は、JSON エンコードされた生の文字列を表示し、インラインの形式はユーザーに調整してもらいます。

この手順で本当に確認したいのは、クリーンアップによって本番環境の動作が変わるかどうかです。

rules 配列を確認し、以前 defaultValue と異なる値を返していたものをすべて特定します。

• 対象セグメントに異なる値を返す force ルール。
• アクティブな rollout ルール（coverage > 0）。条件がなくても対象です。
• experiment-ref ルール：リンクされた実験を取得します。一時ロールアウトを伴って停止している場合、勝者の値が相違する値です（上記で処理済み）。一時ロールアウトなしで通常どおりトラフィックを割り当てている場合（停止した実験）、ユーザーはバリエーションごとに分割されているため、アーカイブすると全員が defaultValue に切り替わり、処置群のユーザーにとって変更になります。

次の表を表示します。

Behavior-change check for <flag-id>:
  defaultValue (post-cleanup):  "true"

  Pre-cleanup divergences (these stop applying after archive):
    production:  rule 1 (force, "beta testers" saved-group) served "false" → those users will now get "true"
    production:  rule 2 (rollout, 25% via id)              served "false" → 25% of traffic will shift to "true"
    staging:     no divergence — all traffic gets "true" today

Is this the intent?

表が空の場合（値に相違のあるものがない場合）、クリーンアップは見た目だけの変更であり、ユーザーは追加の確認なしで続行できます。いずれかのルールで値に相違がある場合は、停止して確認してください。これは実際に動作が変わる変更です。

3. 呼び出し箇所を探す

まず Code References を試してください：

gb-call GET /api/v1/code-refs/<flag-id>

レスポンスは {codeRefs: [{ repo, branch, platform, refs: [{filePath, startingLineNumber, lines, flagKey}] }, ...]} です。（repo、branch）ごとにドキュメントが1つ返されます。Code References が複数のブランチからプッシュされている場合、1つのフィーチャーに複数のエントリーが含まれることがあります。

• 空でないレスポンス → ファイルごとにまとめた行単位の参照をユーザーに提示します。複数のブランチが含まれている場合は、ブランチ情報も示します。データは Code References から取得したものであることを明記します（ローカルの編集内容に対して古くなっている可能性があるとユーザーがわかるようにします）。

• 空のレスポンス → Code References が設定されていないか、フラグが実際に参照されていない可能性があります。Grep に切り替える前に、作業ディレクトリを確認してください：

  Code References から結果が返されませんでした。現在のディレクトリ（<pwd>）で <flag-id> を検索します。フラグを使用するコードはここにありますか。それとも、別の場所を検索した方がよいですか？

  確認後、Grep ツールを使って、プロジェクト内でフラグ ID（kebab-case のキー、完全一致）を検索します。対象は関連するファイル形式に限定します（ベンダーディレクトリではなくソースコード）。

Code References と Grep の両方で結果が空の場合は、次のように伝えます：

<flag-id> へのコード参照が見つかりませんでした。このフラグがどこでも使用されていないと確信できる場合は、手順 5 に進んでください。それ以外の場合は、作業ディレクトリを再確認するか、古いデータを確認するために <host>/features/<flag-id> の Code References をご覧ください。

4. インライン化の手順をユーザーに案内する

行ごとではなく、ファイルごとにまとめます。 1つのファイルに同じフラグへの参照が複数ある場合があります。同じファイル内の編集を N 回に分けて承認するようユーザーに求めるのは手間です。参照のあるファイルごとに、次の手順を実行します。

• Read ツールを使って、ファイル全体を読み込みます（1回だけ）。
• ファイルパス、参照数、フラグを参照している行を含む、ファイルごとの概要を提示します。
• ファイル内のすべての参照を defaultValue（またはユーザーが確認したインライン値）に置き換える単一の Edit を提案します。
• Edit は Claude Code の通常の権限フローで処理されます。ユーザーはファイル全体への変更を一度確認して承認します。
• ユーザーは「このファイルはスキップ」と伝えることも、「一部だけ編集し、残りは編集しない」と伝えることもできます（後者の場合は、そのファイル内だけ参照ごとの Edit に切り替えます）。

処理済みのファイルとスキップしたファイルを記録します。ユーザーが「インライン化完了」と伝えたとき（または呼び出し箇所がない場合）は、次に進みます。

ユーザーがコードのクリーンアップをすべて後回しにして「今はフラグだけをアーカイブして、コードのクリーンアップは後で行う」と希望する場合は、それを認めてください。アーカイブは元に戻すことができ、ユーザーは後でこのスキルを再実行して、削除前にコードのクリーンアップを完了できます。

5. フラグをアーカイブする

echo '{"archived": true}' \
  | gb-call POST /api/v2/features/<flag-id> -

サーバー側での動作。 これはメタデータのパッチではありません。archived を設定すると、サーバー側で createAndPublishRevision が実行され、新しいリビジョンが作成されてアトミックに公開されます。v2 の公開に影響するものと同じ失敗ケースが適用されます。

• 2xx → アーカイブ済みです。手順 6（削除する場合）または手順 8（アーカイブのみの場合）に進みます。
• 403、「approval required」本文 → 手順 5a に進みます。
• 409 → 手順 5b に進みます（マージの競合。こちらの GET とアーカイブ POST の間に、別のアクターがフラグを変更しました）。
• その他の 4xx → 本文の内容を伝えて処理を停止します。

アーカイブイベントのリビジョン履歴エントリーが表示されます。手順 8 でこれを提示します。

5a. アーカイブに承認が必要な場合

flag-targeting と同じ3つの選択肢がありますが、アーカイブと削除の間には、重大な違いが1つあります。

組織では、このフラグをアーカイブする前に承認が必要です。続行するには：

A. 標準のレビュー手順（推奨）— 変更のレビューをリクエストします。チームメイトが GrowthBook UI の <host>/features/<flag-id> で承認します。その後、処理を再開するために、もう一度呼び出してください。

B. 組織全体でのバイパス — 管理者が Settings → General → Approvals で「REST API always bypasses approval requirements」を有効にします。この設定1つで、アーカイブと最後の削除ステップの両方が許可されます。

C. トークンごとのバイパス — bypassApprovalChecks 権限を持つ PAT を使用します。**この権限で許可されるのはアーカイブのみで、削除は許可されません。**トークンごとの権限は、意図的にレビュー手順のみをバイパスするものであり、破壊的な操作を許可するものではありません。最終的にアーカイブのみを行うのであれば、これで問題ありません。削除する場合は、引き続きオプションBの組織全体の設定が必要です（または管理者がUIで削除する必要があります）。ユーザーがCを選ぶ前に、この違いを伝えてください。ステップ7で初めて気づくことがないようにしてください。

パスAの場合は、ドラフトのレビューをリクエストして停止します：

echo '{"comment":"Auto-requested by flag-cleanup"}' \
  | gb-call POST /api/v2/features/<flag-id>/revisions/<version>/request-review -

submit-review は試さないでください。API によって自己承認が拒否されます。

5b. アーカイブ時のマージコンフリクト

アーカイブの POST で 409 が返された場合、ドラフトのベースリビジョンが古くなっています。つまり、ステップ1（GET）とステップ5（POST）の間に、チームメイト（または別のエージェントの呼び出し）が同じフラグの変更を公開しています。**自動でリベースしないでください。**次のメッセージを表示して停止します：

<flag-id> のアーカイブを適用できませんでした。最後に確認したときからフラグが変更されています。解決するには：

• GrowthBook UI で <host>/features/<flag-id> を開きます。
• 変更内容を調整します（保留中のアーカイブをリベースするか、破棄して新しいライブ状態を基に処理をやり直してください）。

コンフリクトを解決した後、もう一度呼び出してください。

コンフリクトの本文はそのまま表示します。オプトインによる解決には POST /api/v2/features/<id>/revisions/<version>/rebase エンドポイントを利用できます。v1 が引き続き慎重な対応をとるのは、flag-targeting と同じ理由によるものです。マージの解決には、コンフリクトが発生したフィールドごとに人間の判断が必要です。

6. 確認またはロールバックのゲート（削除パスのみ）

アーカイブが成功したら、停止してユーザーに確認します。削除が取り消せないことは、ユーザーが読んでいない可能性のあるガードレールだけでなく、プロンプト自体で伝えてください。

フラグはアーカイブ済みです。**この時点では操作を完全に取り消せます。**UIでアーカイブを解除するか、「rollback」と返信すれば、すべて元に戻ります。削除すると、フラグとすべてのリビジョンは永久に失われ、元に戻せません。

削除する前に：

• コードベースで問題が起きていないことを確認してください。テストを実行し、ステージング環境にデプロイし、古いルールの代わりに defaultValue を使ってアプリが正しく動作することを確認してください。通常行っているフラグ削除後の確認を実施してください。
• 問題ないと確信できたら、「proceed」と返信してください。削除します。
• 「rollback」と返信すると、アーカイブを解除します。

このスキルで最も重要なのが、このゲートです。永久削除は一方通行であり、少なくとも1回の確認サイクルが終わるまでは、ユーザーがアーカイブ済み・未削除の状態を維持できるようにしてください。ユーザーが急かしても、2つのステップを1つにまとめないでください。

**ユーザーが「rollback」を選んだ場合：**同じエンドポイントで archived: false を設定し、アーカイブを元に戻します。

echo '{"archived": false}' \
  | gb-call POST /api/v2/features/<flag-id> -

これはアーカイブと同じリビジョン作成・公開のフローで行われるため、承認が必要な場合とマージコンフリクトが発生した場合の失敗パターンも同じです。処理が正常に完了することを確認し、結果を伝えて終了します。

7. フラグを削除する（削除パスのみ）

gb-call DELETE /api/v2/features/<flag-id>

• 2xx と {deletedId} → レポートに進みます。
• 403 → ほぼ確実に restApiBypassesReviews 設定がオフです。フラグはアーカイブ済みですが、API 経由では削除できません。次の内容を表示します。

  API 経由でフラグを削除するには、組織で「REST API always bypasses approval requirements」設定を有効にする必要があります。フラグはアーカイブ済みです。次のいずれかを実行できます。

  • 管理者に設定を有効にしてもらって（Settings → General → Approvals）、削除を完了するために私を再実行してください。
  • GrowthBook UI の <host>/features/<flag-id> で手動で削除してください（アーカイブ済みのフラグもここに表示されます）。

  トークン単位の bypassApprovalChecks では許可されません。これは意図的にレビューのワークフローのみを迂回するものであり、破壊的な操作を許可するものではありません。

• その他の 4xx → 本文を表示して停止します。

サーバー側のクリーンアップ。 削除すると、フィーチャーレコード、そのすべてのリビジョン、すべてのリビジョンログが削除され、このフラグが linkedFeatures に含まれていた実験とのリンクが解除されます。実験自体は削除されず、古いトラッキングキーを持ったまま残ります。実験がまだ存在することをユーザーに知らせるため、この内容をステップ 8 に表示します。

8. レポート

次の概要を表示します。

• フラグ ID と最終状態（archived または deleted）。
• アーカイブの場合：リビジョン履歴のエントリーが作成されたこと（ユーザーの監査ログに表示されます）。
• 削除の場合：リンクされた実験とのリンクが解除されたこと（実験自体は削除されていません）。それらのトラッキングキーは、現在存在しないフラグを参照しています。
• 見つかった呼び出し箇所の数、編集したファイル、スキップしたファイルがあればその数。
• 使用したインライン置換値（フラグの defaultValue）。透明性を確保するために表示します。
• UI リンク：<host>/features/<flag-id> — アーカイブ済みのフラグでのみ使用できます（削除済みのフラグは 404 を返します）。GB_API_URL の api. を app. に置き換えて <host> を導出します。
• 制限に関する警告：「ご注意ください：他のフラグがこのフラグを前提条件として使用しているかどうかは検出できません。確信が持てない場合は、削除する前に GrowthBook UI の「Used by」パネルを確認してください。アーカイブは元に戻せるため、アーカイブ後、削除前に確認することもできます。」
• ホールドアウトに関する警告（feature.holdout が存在する場合）：「このフラグはホールドアウト <holdout-id> に関連付けられていました。ホールドアウトの linkedExperiments が、このフラグを参照していた実験を引き続き参照している可能性があります。それらのトラッキングキーは現在古くなっています。実験分析でホールドアウトを正確な状態に保つ必要がある場合は、GrowthBook UI で監査してください。」
• 推奨するフォローアップ：Code References（CLI/Action）を再実行し、ダッシュボードにクリーンアップ後のコードベースの状態を反映させてください。

ガードレール

• 稼働中のフラグでは、削除前にアーカイブするのが標準的な流れです。 バックエンドは、組織全体で restApiBypassesReviews が設定されていない限り、アーカイブされていない機能への DELETE を拒否します。この設定が有効な場合でも、安全のため、アーカイブ→確認→削除の順に進めてください。
• アーカイブすると、リビジョンが作成されて公開されます。 POST /v2/features/<id> で archived: true を設定すると、サーバー側でリビジョンが作成され、公開されます。v2 の公開に影響する一般的な失敗モードも適用されます。承認が必要な場合（5a）とマージコンフリクト（5b）です。
• bypassApprovalChecks の適用範囲は、アーカイブと削除で異なります。
  • アーカイブ：トークン単位の bypassApprovalChecks が機能します（updateFeatureV2.ts は組織全体とトークン単位の両方を確認します）。
  • 削除：トークン単位の bypassApprovalChecks は機能しません（deleteFeature.ts の明示的なコメント：「レビュー ワークフローのバイパスであり、破壊的操作のオーバーライドではない」）。
  • 両方を許可するのは、組織全体の restApiBypassesReviews のみです。承認オプションをユーザーに提示する際に、これらを混同しないでください。
• neverStale: true のフラグは、意図的に恒久的なものです。 ユーザーから削除を求められた場合は停止してください。まず UI でそのフラグを明示的に削除する必要があります。
• 実行中の実験があるとクリーンアップできません。 running 状態の実験を参照する experiment-ref ルールがあるフラグはクリーンアップできません。実験の停止は別の判断事項であり、experiment-stop に振り分けます。
• 未解決のドラフトがあるとクリーンアップできません。 ドラフトを提示し、まず破棄するか公開するようユーザーに依頼してください。
• 完全削除は後戻りできません。 アーカイブと削除の間でスキルを停止し、問題が起きていないことをユーザーが確認できるようにしてください。ユーザーに強く求められても、この2つの手順をまとめないでください。不可逆であることは、このガードレールだけでなく、ユーザー向けの確認メッセージにも明記してください。
• コードのクリーンアップは、ファイル単位で承認を得てまとめて行います。 呼び出し箇所をファイルごとにまとめ、ファイルごとに1つの編集を提案してください。複数のファイルをまたいでまとめないでください。また、エージェント標準の編集ツールの権限フローをバイパスしないでください。
• コード参照が古い場合があります。 データに反映されるのは、最新の CLI／GitHub Action の実行時点の情報であり、現在の作業ツリーの情報ではありません。コード参照にまだ反映されていない編集があるとユーザーから報告された場合は、作業ツリーを信頼するか、CLI を再実行してください。
• /code-refs が空でも、「コード内で使われていない」とは限りません。 コード参照が設定されていないか、ユーザーの作業ディレクトリが適切なコードベースではない可能性があります。フラグに参照がないと判断する前に、必ず作業ディレクトリを確認してください。
• 実験の一括検索1回は、ルールごとの検索N回より優先します。 主な確認には listExperiments?trackingKey=<flag-id>&status=running を使用してください。一括呼び出しで結果が空でも experiment-ref ルールがある場合に限り、フォールバックとしてルールごとに取得してください（手動設定の例外ケース）。
• アーカイブ後はすべてのルールの評価が停止し、呼び出し元に返されるのは defaultValue です。 手順2の目的は、ユーザーごとの動作を計算することではありません。defaultValue と異なるルールを列挙し、クリーンアップによって本番環境の動作が変わるかどうかを検出することです。
• 逆方向の依存関係検出は対象外です。 API では「このフラグに依存するもの」を逆引きできません。レポートでこの制限を示し、このケースを見落としたままにしないでください。
• 削除時にホールドアウトとの関連付けが明示的にクリーンアップされることはありません。 機能の削除ハンドラーはホールドアウトのレコードを更新しません。ホールドアウトと関連付けられたフラグを削除すると、ホールドアウトの linkedExperiments に古い参照が残る可能性があります。feature.holdout が設定されていた場合は、レポートでユーザーに警告してください。
• 削除すると実験との関連付けは解除されますが、実験自体は削除されません。 このフラグを参照していた実験は、古い trackingKey の値を持ったまま残ります。削除する場合は、この点をレポートに記載してください。
• 削除後に更新済みのコード参照をプッシュしないでください。 CLI／Action は次回のコードベーススキャン時に自動で処理します。参照を事前に消すと、コードが実際には更新されておらず、依然として壊れた状態であることを隠してしまう可能性があります。

使用するエンドポイント

• GET /api/v2/features/<id> — フラグの状態を取得します（rules、defaultValue、archived、environmentSettings、holdout、project）
• GET /api/v2/stale-features?ids=<id> — 古さを確認し、neverStale の理由を調べます
• GET /api/v1/experiments?trackingKey=<flag-id>&status=running（および &status=draft）— このフラグに紐付けられた実験を一括検索します
• GET /api/v1/experiments/<id> — 手動で紐付けられた場合に備えた、防御的な照合用フォールバックです
• GET /api/v2/features/<id>/revisions/latest — 未解決のドラフトを検出します（404 の場合はありません）
• GET /api/v1/code-refs/<id> — Code References が設定されている場合、行単位の呼び出し箇所を返します。空の場合は 404 ではなく {codeRefs: []} を返します
• POST /api/v2/features/<id> — アーカイブ（本文：{archived: true}）またはアーカイブ解除（{archived: false}）を行います。リビジョンの作成と公開が実行されます
• DELETE /api/v2/features/<id> — 完全に削除します。有効なフラグには restApiBypassesReviews が必要です（設定されていない場合は拒否されます）
• POST /api/v2/features/<id>/revisions/<version>/request-review — 5a の承認分岐でのみ使用します

引き継ぎ先

• flag-search — 古いフラグをクリーンアップする前に検索・監査します（flag-search の Path C が自然な呼び出し元です）。
• flag-graph — フラグをアーカイブまたは削除する前に、そのフラグに依存するものを確認します。
• flag-targeting — ユーザーが削除ではなく、フラグの動作を変更したい場合に使用します。
• flag-revisions — アーカイブする前に解決が必要な未完了のドラフトを確認します。
• flag-publish — アーカイブ時に承認が必要な分岐（5a）とマージ競合の分岐（5b）に対応します。
• experiment-stop — 実行中の実験に紐付けられたフラグをクリーンアップする前に必ず実行します。
• 手動の UI 操作（スキルなし）：アーカイブ済みでまだ削除されていないフラグのアーカイブを解除する場合は、<host>/features/<flag-id> で行います。スキルのロールバック手順ではセッション内のケースに対応します。セッション外では、ユーザーは UI を使用します。