Claude CodeのautoModeに独自ルールを追加する書き方

Claude Codeのauto mode設定は、autoMode.environment・allow・soft_deny・hard_denyという4つの配列でできています。それぞれに文字列"$defaults"を含めるだけで、組み込みルールを保ったまま自分のルールを足せます。逆に"$defaults"を書き忘れると、その配列の組み込みルールごと丸ごと失われます。この記事では、$defaultsの正しい書き方と設定を置く場所を扱います。/auto-mode-setupと/permissionsのAuto modeタブでの編集方法、設定後の確認コマンドも扱います。

autoMode設定はどこに書けば読まれるか

autoMode設定が読まれる場所は3か所だけです。ユーザー設定(~/.claude/settings.json)・組織の管理設定・--settingsフラグまたはAgent SDK経由のインラインJSONです。プロジェクト直下の.claude/settings.jsonや.claude/settings.local.jsonに書いても分類器には渡りません。

プロジェクト設定が除外されているのは、リポジトリにコミットされたファイルやビルドステップが勝手に許可ルールを注入する経路を塞ぐためです。v2.1.207より前は.claude/settings.local.jsonもautoModeの読み取り対象でしたが、このバージョンで外れました。そのファイルに書いていたautoModeブロックは~/.claude/settings.jsonへ移す必要があります。複数スコープに同じ配列を書いた場合、内容は結合されます。開発者はenvironment・allow・soft_deny・hard_denyに個人の項目を足せますが、管理設定が配った項目を削除することはできません。

$defaultsを含めて4つの配列に追加する

$defaultsは、組み込みルールをその位置にそのまま展開する予約文字列です。配列の中に"$defaults"を1つ入れれば、その前後に書いた項目が組み込みルールに追加され、リリースのたびに更新される組み込みルールも自動で引き継がれます。

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "$defaults",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "$defaults",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}

4つの配列は独立に評価されます。environmentだけ書いてallow・soft_deny・hard_denyを省いても、その3つは組み込みのまま残ります。問題は、配列を書くのに"$defaults"を入れ忘れたときです。soft_denyを独自ルールだけで上書きすると、force push・curl | bash・本番デプロイ・auto modeのバイパスといった組み込みの禁止事項がまとめて消えます。hard_denyを独自ルールだけで置き換えると、無条件ブロックの対象になっているデータ流出防止ルールが消えます。組み込みルールを土台にしたい配列には、必ず"$defaults"を書くことが前提になります。分類器がこの4配列をどの優先順位で評価するかは、hard_deny→soft_deny→allow→ユーザーの明示的な意図の順です。詳細はClaude Codeのauto mode分類器は何を止めているかにまとめてあるので、ここでは書き方に絞ります。

意図して組み込みルールを総入れ替えしたい場合だけは、"$defaults"を省いて構いません。その代わりclaude auto-mode defaultsで組み込みルールの中身を先に確認し、自分のパイプラインとリスク許容度に照らして1つずつ検討してから書き直します。

environmentの三層スロットで「社内」を教える

autoMode.environmentは許可・拒否のルールではなく、分類器が「社内」と「社外」を見分けるための文脈です。ここに書いていない送信先は、正規の操作でも分類器から見て潜在的な持ち出し先として扱われます。エントリは正規表現やツールパターンではなく自然文で、新しく入った同僚に説明するつもりで書きます。

claude auto-mode defaultsが出力する項目は3種類に分かれます。3種類表示になるのはv2.1.198以降で、v2.1.195より前はTrust slotsの最初の5項目だけが表示されます。

Sensitivity slotsは、具体的な対象を名指しした時点でヒューリスティックから切り替わります。名指しした対象だけに、その保護ルールが適用されます。Trust slotsはリポジトリ関連2項目(Trusted repo・Source control)を除き、明示的に書かない限りすべてNone configuredのままです。追加・削除された項目とバージョン要件は次の表のとおりです。

pushやPR作成の前に人の確認を挟む

auto modeは既定で、作業中のリポジトリのどのブランチへのpushもPR作成も許可します。productionやrelease、gh-pagesのようにデプロイ先だと分かる名前のブランチだけは既定の対象外で、分類器が個別に安全性を判定します。force pushや、CI・デプロイパイプラインを通した先で機密情報が漏れる変更は、対象ブランチによらず引き続きブロックされます。v2.1.211より前は、作業ブランチとClaudeが作ったブランチ、既定ブランチへの通常pushしか許可されていませんでした。

pushやPR作成そのものに人の確認を必ず挟みたい場合は、境界の固さに応じて3つの手段から選びます。

permissions.askはautoModeとは別の設定ブロックで、分類器より手前の段階で評価されます。

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

このルールはgit pushやgh pr createで始まるコマンドにだけ一致します。git -C <dir> pushのように書き方を変えたpushは一致しないため、コマンド全文を検査したい場合はPreToolUseフックを使います。

/auto-mode-setupと/permissionsのAuto modeタブで書く

設定ファイルを直接編集しなくても、autoMode設定を組み立てる手段が2つあります。/auto-mode-setupは、プロジェクトと直近のセッションからautoMode.environmentのたたき台を作るコマンドです。

読む対象は、プロジェクトのCLAUDE.md・README・設定ファイル・gitのリモートです。既存のautoModeとpermissions.allow、直近のセッションでClaudeが実行したコマンドのホスト名・バケット名・コマンド名も読みます。ユーザーのメッセージは読みません。

任意のスキャンが2つあり、実行前にどちらを回すか確認されます。1つはシェル履歴の各コマンドの先頭単語、もう1つはホームディレクトリ配下のリポジトリのリモートのホスト名とリポジトリ名です。

ドラフトを承諾すると~/.claude/settings.jsonに書き込まれます。allow・soft_deny・hard_denyに項目を足すときは、既存の"$defaults"を書いていない場合を除いて"$defaults"が自動で添えられます。保存後は、autoモードが無視するBash(*)のような許可ルールをpermissions.allowから削除するかどうかも聞かれます。

/auto-mode-setupの提供条件は次のとおりです。

• Pro・Max・Teamプランとv2.1.228以降が必要
• ネイティブWindowsではv2.1.233以降が必要
• Claude Code on the webでは実行できません

もう1つの手段は/permissionsダイアログのAuto modeタブです(v2.1.246以降、auto modeが使えるセッションでのみ表示)。allow・soft_deny・hard_deny・environmentの各セクションでは、その区分に組み込みルールが効いているかどうかを確認できます。区分に最初の1件を足すと"$defaults"が自動で挿入されます。管理設定や--settingsフラグ由来のエントリは読み取り専用として表示され、それ以外の変更はすべて~/.claude/settings.jsonに保存されます。environmentはドキュメント全体をエディタで編集する形式です。未設定の状態から開くと、組み込みの全文が最初から入った状態で開きます。/permissions全体の使い方(allow・ask・denyのスコープ別管理や「最近の拒否」タブでの再試行)はClaude Codeの/permissionsコマンドにまとめています。

設定後に効いているかを確認する4つのコマンド

autoMode設定を保存したら、実際に反映されているかを目で確認します。設定ファイルを直接読み返すよりも、分類器が使う最終形をコマンドで出力する方が確実です。

claude auto-mode config

claude auto-mode defaultsに--labelを渡すと、ルール名の先頭一致で1件だけをjqなしで読めます(v2.1.208以降)。大文字小文字は区別されません。claude auto-mode resetは管理設定や--settingsフラグ由来のautoMode設定までは削除しないため、組織のルールはリセット後も残ります。

よくあるつまずき

environmentを書けばallow・soft_deny・hard_denyも一緒に緩むと誤解する。environmentは分類器の文脈情報で、ルールそのものではありません。信頼する接続先を教えても、破壊的な操作を許可したことにはならず、そこは別途allowか明示的な意図表明が必要です。

allowルールを足せば組織のhard_denyも上書きできると思い込む。hard_denyは無条件ブロックで、ユーザーの意図もallowの例外も効きません。開発者が個人設定に足したallowが上書きできるのは組織のsoft_denyだけで、hard_denyには届きません。

disableAutoModeとautoModeの4配列を混同する。前者はauto mode自体をShift+Tabの切り替え候補から外す設定で、後者はauto modeが有効な前提で分類器のルールを調整する設定です。auto modeを完全に使わせたくない場合は前者を管理設定に置きます。

classifyAllShellを4配列のどれかに書こうとする。これはautoModeブロック直下の独立したブール値キーで、$defaultsを含む配列とは別枠です。既定ではBash(*)のような広い許可ルールだけが分類器を経由します。trueにすると、auto mode中のBash・PowerShell許可ルールがすべて一時停止します。この間、コマンドは例外なく分類器を通ります。

プロジェクトの.claude/settings.jsonに書いて反映されないと悩む。前述のとおりautoMode設定はユーザー設定・管理設定・--settingsフラグからしか読まれません。設定ファイルの階層とスコープの全体像はClaude Code settings.json完全ガイドで扱っています。既定でブロックされる操作の一覧はClaude Code auto modeブロック一覧にまとめてあります。

まとめ

autoMode設定の$defaultsは、既存ルールを消さずに足すための構文であって、置き換えの手段ではありません。組み込みルールを本当に総入れ替えしたいときだけ"$defaults"を省き、それ以外は常に含めておくのが安全側の書き方です。設定を置く場所を間違えると、静かに無視されます。まず~/.claude/settings.jsonか管理設定に置いたことを確認します。保存後はclaude auto-mode configで実際に効いているルールを見てから運用に入るのが、手戻りの少ない順序です。