Guardian からカスタム Semgrep ルール（ユーザーが作成したセキュリティチェック規則）を削除します。インストール済みのルールを一覧表示し、対象のルールがどのファイルに入っているかを確認してから、ユーザーまたはリポジトリのルールディレクトリから削除または編集で除外します。 次のような場合に使用: - Guardian が特定の項目をフラグする（警告する）のを止めたい - カスタムルールの削除、無効化を希望している - ルール数の上限に余裕を作りたい
Remove a custom Semgrep rule from Guardian — list what is installed, work out which file holds the rule, and delete or edit it out of the user or repo rules directory. Use when someone wants Guardian to stop flagging something, asks to remove, delete or disable a custom rule, or wants to clear room under the rule limit.
カスタムルールは2つのディレクトリに保存されているテキストファイルで、スキャンを実行するたびに読み込まれます：
~/.semgrep/guardian-rules/ — ユーザースコープ（個人の開発環境のみ）<repo root>/.semgrep/guardian-rules/ — リポジトリスコープ（リポジトリをクローンした全員）削除機能が提供されていない理由は、クラウドサービスには「元に戻す」という概念がないためです。ルールをディスクから取り外すだけで完了しますが、正しいルールを削除し、他に影響する人がいないか確認することが重要です。
list_developer_semgrep_rules を呼び出します。このコマンドは両方のディレクトリを対象に、すべてのルールファイルをスコープとパスともに表示し、ルールが実際に送信されているか、デプロイのルール数上限がいくつかも報告します。1つのファイルが複数のルールを含むこともあるため、削除前にファイルの内容を確認してください。ファイルを削除するとそこに含まるすべてのルール数が減ります。
機能がデプロイで無効化されているため一覧表示を拒否された場合でも、ディスク上のルールは単なるファイルであり、送信されていないため、削除を進めても問題ありません。この場合は2つのディレクトリを自分で確認して進めてください。
ユーザーは通常、ファイル名ではなく検出結果の名前でルールを指名します。ユーザーが説明する内容（ルールID、繰り返し表示されるメッセージ、ファイルパスなど）を一覧と照合してください。複数のルールが該当する場合は、各ルールのID、スコープ、パスを示して AskUserQuestion で確認し、推測で判断しないでください。
一覧を確認する際の3つの注意点：
ルール数が上限に達しているため、ルールが全く送信されていない場合があります。この場合、ルール削除は「片付け」ではなく「修正」になります。現在すべてのルールは機能していないため、Guardianはスキャン対象のコードの書き込みをブロックしており、ルール数を上限以下に戻すまでこの状態が続きます。
エラーとともに報告されたファイルは全く送信されていません（ファイルサイズが大きすぎる、読み込み不可、または使用可能なルールではない）。削除してもスキャン対象は変わりませんが、エラー内容をまず確認してください。パース（解析）に失敗したファイルはそこに含まるすべてのルールを無効化するため、ユーザーが他のルールを保持したい場合もあります。
「開発者ルールが有効ではない」というメッセージですべての書き込みがブロックされている場合があります。スキャナーは送信されたルールを実行前に検証し、失敗したルールはスキャン全体を止めるため、そのルールが修正されるか削除されるまでスキャンは実行されません。Semgrepのエラーメッセージに何が問題かが記載されているため、削除するより修正を最初に提案してください。
何もする前に、ユーザーにパスとルールIDを告知し、リポジトリスコープの場合は、そのルールがリポジトリをクローンした全員と共有されているため、削除すると全員から取り外されることを伝えてください。リポジトリスコープ削除の確認を取ってください。
ファイルにそのルールだけが含まれている場合 — ファイルを削除します。
ファイルに複数のルールが含まれている場合 — そのファイルは既に拒否されているため、ルールは実行されません。ユーザーが保持したいルールを同じディレクトリ内の独立したファイルに移し、ルールIDをファイル名とします。その後、元のファイルを削除してください。削除後に一覧を確認し、各新規ファイルが使用可能でカウントされていることを確認します。
2つのルールディレクトリ内のファイルだけを操作し、ステップ3で指名したファイル以外には触れないでください。ディレクトリそのものは削除しないでください。
ユーザーがルールを「削除ではなく一時的に無効化したい」という場合は、削除せず、ファイル拡張子を読み込まれないものに変更（例: no-eval.yaml.off）するか、ルールディレクトリのサブディレクトリに移動してください。ディレクトリ直下にある .yaml、.yml、.json ファイルだけが読み込まれるため、どちらの方法でもルールは実行されなくなり、テキストは後で復元できます。
list_developer_semgrep_rules を再度実行し、ユーザーに以下を報告してください：
Custom rules are plain files in two directories, both read on every scan:
~/.semgrep/guardian-rules/ — user scope, this developer everywhere<repo root>/.semgrep/guardian-rules/ — repo scope, everyone who clones the repositoryThere is no removal tool, because there is nothing to undo in a service: taking a rule off disk is the whole of it. What matters is removing the right one, and knowing who else loses it.
Call list_developer_semgrep_rules. It reports both directories, every rule file
with its scope and path, whether the rules are being sent, and the deployment's
limit. A file holds one rule or several, so check what a file carries before
removing it: the count drops by every rule in it.
If it refuses because the feature is off for the deployment, the rules on disk are still just files — nothing is being sent, so removal is still fine. List the two directories yourself and carry on.
The user will usually name a finding, not a file. Match what they describe — a
rule id, a message they keep seeing, a path — against the listing. If more than
one fits, ask with AskUserQuestion, showing the id, the scope and the path for
each; do not guess between two plausible rules.
Three cases worth noticing in the listing:
Before touching anything, tell the user the path, the rule id, and — for repo scope — that the rule is shared, so removing it takes it away from everyone who clones the repository. Get a yes for a repo-scope removal.
Only ever touch files inside the two rules directories, and only the file you named in step 3. Never delete a directory.
If the user wants the rule off for now rather than gone, do not delete it:
rename it to an extension that is not read — no-eval.yaml.off — or move it into
a subdirectory of the rules directory. Only .yaml, .yml and .json files
directly in the directory are loaded, so either way the rule stops running and
the text is still there to restore.
Run list_developer_semgrep_rules again and tell the user:
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。