auto modeを使っているが、何が許可されて何がブロックされるかルールの中身を確認したい人向け
auto modeで作業中に「なんでこのコマンドが弾かれるの？」と詰まった場面で、判定モデルの組み込みルールと自分の上書きを照らし合わせて原因を特定するために叩く。社内向けレジストリやプライベートサーバーを信用先に追加する前にも、まずは <code>defaults</code> で現状把握し、追加ルールを書いたら <code>critique</code> で曖昧さや誤検知リスクをAIに見てもらう
auto mode（オートモード）は、Claude Codeが許可ボタンを毎回出さずに自分でコマンドを実行できるようにする動かし方です。とはいえ何でも勝手にやるわけではなく、別の判定モデルが「この操作は OK か危ないか」を毎回チェックしてからしか動きません。その判定モデルが何を許可していて何をはじいているか、組み込みのルール一覧を見るためのコマンドが claude auto-mode defaults です。
claude auto-mode にはサブコマンドが3つあります。defaults は組み込みルールだけを書き出す。config は自分の settings.json の上書きまで反映した「いま実際に効いてる設定」を見せる。critique は自分が書いた追加ルールにAIが目を通して、曖昧な記述や誤検知を起こしそうな書き方を指摘してくれる、いわばルールのレビュー係です。
噛み砕くと
会社の入退室を判定する警備員みたいなものを想像してください。Claude Codeが「ここに入っていい？」と聞くたびに、警備員（判定モデル）が「組み込みの社則」と「あなたが追加で書いた社内ルール」の両方を見て YES/NO を返します。
claude auto-mode defaults は「組み込みの社則」だけを印刷して持ってくる。claude auto-mode config は「あなたの上書きまで含めた、いま実際に運用されてる社則」を持ってくる。claude auto-mode critique は「あなたが書いた追加ルール、文章として穴が空いてないか校閲してくれ」とAIに頼むイメージです。どれもプログラム向けのテキスト形式で出てくるので、テキストエディタや jq で中身を確認できます。
auto modeで「なんでこれブロックされるの？」と詰まったら、まずこの3コマンドで答え合わせをする、というのが正しい入り口です。
大事な前提：auto modeが使える契約・モデル・接続経路は限定されている
公式ドキュメントによれば、auto modeを実際に動かせるのはMax / Team / Enterprise / API契約のときだけです。Pro契約では使えません。あとClaude Code v2.1.83以降が必要。
さらにモデルも選びます。Team / Enterprise / APIならClaude Sonnet 4.6・Opus 4.6・Opus 4.7が対象ですが、MaxプランはOpus 4.7のみ。HaikuやClaude-3系ではauto modeは動きません。また接続経路もAnthropic APIの直接接続が必要で、Bedrock / Vertex / Foundry経由では使えません。
ただし claude auto-mode defaults コマンド自体は「組み込みルールの書き出し」なので、auto modeが有効化されていない契約でも実行はできます。「ルールだけ眺める」用途なら制限がかからない、という独立した立て付けです。
「auto modeで npm install some-private-package がブロックされた」を例に、原因を追う手順
典型的な詰まりとして、auto modeで作業中に社内向けプライベートパッケージのインストールが弾かれる、というのがあります。「ロックファイルに書いてあるパッケージのインストールは許可される」はずなのに、なぜか止まる。ここから claude auto-mode defaults と claude auto-mode config を使ってルールを覗き、原因を追います。
ステップ1: 組み込みルールをファイルに書き出す
まずはターミナルに戻って、組み込みルールを丸ごとファイルに書き出します。
$ claude auto-mode defaults > rules.json> rules.json の部分は「出力結果をrules.jsonというファイルに保存する」という指示です。画面には何も出てきませんが、いまいる作業フォルダにJSONが1ファイル生まれているはず。
ステップ2: 中身を jq や less で眺める
そのまま cat rules.json しても1行で潰れて読めない場合があるので、jq で整形します。
$ jq '.' rules.json | lessallow（許可されている操作）、deny（拒否）、soft_deny（条件次第で拒否）といった分類が並んでいるはずです。ここで何が「allow」に入っていて、何が入っていないかを確認します。
ステップ3: 「allowに入ってる依存インストール」の範囲を確認
公式ドキュメントには「allowed by default」として「ロックファイルやmanifestに宣言された依存関係のインストール」が挙げられています。つまり package-lock.json や pnpm-lock.yaml に書かれているパッケージはallow対象。逆に「ロックファイルに書いていない、その場で名前指定して入れに行くインストール」はallow対象から外れる可能性があります。
ここで初心者がやりがちな勘違いがあります。「npm install some-package はnpmコマンドだから全部allow」だと思いがちですが、判定モデルは「そのパッケージがロックファイルで宣言されているか」まで見ています。新規パッケージの追加インストールは別物として扱われる。
ステップ4: 自分の上書きが効いているかを config で確認
もし settings.json 側で autoMode.environment に「うちの社内npmレジストリは信用していい」と書き足しているなら、その上書きが本当に効いているかを次のコマンドで見ます。
$ claude auto-mode configこちらは defaults と違って、組み込みルール＋自分の上書きをマージした「いま実際に効いてる設定」を出してくれます。autoMode.environment に書いたはずの社内レジストリのドメインが出力に含まれていなかったら、設定の書き方を間違えているか、settings.jsonの置き場所が読まれていない可能性が高い。
ステップ5: critique で自分のカスタムルールに穴がないかAIに見てもらう
自分で書いた autoMode.allow や autoMode.soft_deny のルールが、誤検知や曖昧さを抱えていないかをAIにレビューさせるのが critique です。
$ claude auto-mode critiqueたとえば「npm install を丸ごとallowに入れた」みたいな書き方をしていると、「これだと任意パッケージのインストールまで通ってしまいますが意図通りですか？」と指摘が返ってきます。社内レジストリの追加を書いた後にこれを1回叩いておくと、後から「想定外のものまで通ってた」と気付いて慌てる事故をだいぶ減らせます。
ステップ6: 出力を比較して差分を探す
両方をファイルに保存して diff で差分を取るのが手っ取り早いです。
$ claude auto-mode defaults > defaults.json
$ claude auto-mode config > effective.json
$ diff defaults.json effective.json差分が出てきたら、それが「あなたが上書きした分」。差分が空っぽなら、上書きが1つも効いていないということ。後者の場合はsettings.jsonの場所・スペルミスを疑います。
ステップ7: 上書きが足りなければ autoMode.environment を追記
上書きの書き方そのものは別エントリ autoMode.environment 側の話ですが、ざっくり言うと「信用してほしいレジストリやバケットを明示する」設定です。書き足したら、Claude Codeを再起動してもう一度 claude auto-mode config で反映を確認し、続けて claude auto-mode critique で書き方に穴がないかも見てもらう、というのを繰り返します。
つまり claude auto-mode は何をしてくれるのか
- やってくれる:
defaultsで判定モデルの組み込みルールを丸ごと書き出す。configで自分の上書き込みの「いま効いてる設定」を見せる。critiqueで自分が書いた追加ルールにAIが目を通し、曖昧・冗長・誤検知を起こしやすい書き方を指摘してくれる - やってくれない: ルールの書き換えはやってくれない。書き換えは
settings.json側を自分で編集する。書き出したJSONファイルを直接いじっても無視される - 意味が薄い場面: auto modeを一度も触っていない初期状態。組み込みルールだけ見ても「自分の操作のどこに引っかかるか」のイメージが湧きづらいので、まずは普通にauto modeを動かしてブロックされてから見に行くのがよい
使いどころ3シナリオ
シナリオ1: 社内プライベートnpmレジストリが弾かれて困っているとき
社内のVerdaccioから @mycompany/internal-tools を入れに行ったらauto modeがブロックを返す。claude auto-mode defaults > rules.json で組み込みルールを書き出し、レジストリのドメインで grep してみる。当然デフォルトには社内ドメインなんて入っていないので、 settings.json の autoMode.environment に社内レジストリを信用先として追加する。書き終わったら claude auto-mode critique でその追加ルールが緩すぎないかをAIに見てもらう、までを1セットにすると安心です。
シナリオ2: 本番デプロイがいつの間にか止まるようになったとき
少し前まで通っていたデプロイコマンドが、いつのバージョンからかブロックされるようになった。Claude Codeのバージョンを上げたタイミングで claude auto-mode defaults の中身が変わった可能性がある。diff で旧バージョンと新バージョンのrules.jsonを取って、deny側に新しく追加された項目を確認します。公式の挙動として「本番デプロイとマイグレーションはデフォルトで拒否」なので、最初から触れない契約だったのに気付かなかった、というケースもあります。
シナリオ3: チーム内で「auto modeの挙動が人によって違う」と揉めているとき
同じプロジェクトで作業しているのに、Aさんは通る操作がBさんでブロックされる。これは大抵 settings.json の置き場所と中身が違うのが原因です。両者で claude auto-mode config > effective-A.json / effective-B.json を取って diff すれば、どちらの環境にどんな上書きが入っているかが一発で見える。「個人のsettings.jsonとプロジェクト共通のsettings.jsonの両方が混ざる」仕様なので、揉めごとの8割はここで決着します。残りの2割は claude auto-mode critique を双方で叩いて、片方のルールにAIが警告を出していないかを比べると原因が割れます。
初心者が踏みやすい落とし穴
claude auto-modeのサブコマンドはdefaultsとconfigの2つだけではない。critiqueという3つ目があり、自分が書いた追加ルールをAIにレビューさせられる。曖昧な記述や誤検知リスクを事前に発見できるので、カスタムルールを書いたら一度叩いておくと事故が減るclaude auto-modeだけ叩いても動かない。defaults/config/critiqueのいずれかのサブコマンドが必須です。素で叩くとusageエラーが返るだけdefaultsの出力は組み込みルールだけ。自分の上書きを反映した「実際に効いているルール」を見たいならclaude auto-mode configの方を使うこと。両者を取り違えて「上書きが効いてない」と勘違いするのが定番ミス- 書き出したJSONファイルを直接いじってもルール変更にはならない。
rules.jsonを編集して保存しても、Claude Codeは見にいきません。変更はsettings.jsonのautoMode.allow/autoMode.soft_deny/autoMode.environment側で書く - 組み込みルールを丸ごと置き換えてしまう書き方に注意。
autoMode.allowに自分のルールだけ書くと、組み込みルールが消えて自分のルールだけになります。組み込みを残したまま追加したいなら、配列に"$defaults"という文字列を入れる。v2.1.119以降でサポート - Pro契約では auto mode 自体が使えない。
claude auto-mode defaultsでJSONの中身は見られますが、auto modeに切り替えようとしても弾かれます。Max / Team / Enterprise / API契約のいずれかが必要 - MaxプランでClaude Sonnet 4.6を使っているとauto modeが動かない。Maxプランでauto modeを使うにはOpus 4.7への切り替えが必要。Team / Enterprise / API契約ならSonnet 4.6・Opus 4.6・Opus 4.7のいずれでも動く。HaikuやClaude-3系は契約に関係なく非対応
- Bedrock / Vertex / Foundry経由ではauto modeが動かない。Anthropic APIへの直接接続が必須。社内方針でクラウド経由しか使えない環境では、そもそもauto modeを採用できない可能性がある
- Claude Code v2.1.110以前は
--enable-auto-modeが必要だった。v2.1.111でこのスイッチは廃止され、Shift+Tabのモード切り替えに統合済み。古い記事や社内Wikiに--enable-auto-modeが残っていたら更新時期です - 出力結果をブログやSlackに貼るときは中身を確認。
autoMode.environmentに社内のホスト名やバケット名を書いている場合、configの出力にそれが含まれます。共有時はマスキングを忘れずに
書き方
claude auto-mode defaults [> rules.json]
claude auto-mode config
claude auto-mode critiqueやってみるとこうなる
入力
claude auto-mode defaults > rules.json出力例
（組み込みの許可/拒否ルールが標準出力に出る。リダイレクトで rules.json に保存されるため画面には何も表示されない。jqなどで整形して allow / deny / soft_deny / environment の各セクションを確認する）このページに出てきた言葉
- auto mode
- Claude Codeに毎回「実行していい？」と聞かれずに作業を進めてもらう動かし方。判定モデルが事前チェックする
- 判定モデル
- auto mode専用の小さなチェック係。実行前に「依頼範囲を超えていないか」「危険な操作じゃないか」を判定する別のAI。英語ドキュメントだと classifier と呼ばれる
- defaults サブコマンド
- <code>claude auto-mode defaults</code>。組み込みの判定ルールだけを書き出す。自分の上書きは反映されない
- config サブコマンド
- <code>claude auto-mode config</code>。組み込みルール＋自分の上書きをマージした「いま実際に効いてる設定」を出す
- critique サブコマンド
- <code>claude auto-mode critique</code>。自分が書いた追加ルールにAIが目を通し、曖昧な記述や誤検知を起こしそうな書き方を指摘してくれる
- allow / soft_deny / hard_deny
- 判定モデルがコマンドを仕分ける3つの区分。それぞれ「許可」「条件次第で拒否」「絶対に拒否」を表す
- autoMode.allow / soft_deny / environment
- <code>settings.json</code> 側に書く上書き項目。許可追加・条件付き拒否・信用先の追加、をそれぞれ担当する
- $defaults 拡張
- 上書き配列の中に文字列 <code>"$defaults"</code> を入れると、組み込みルールを残したまま自分のルールを足せる仕組み。v2.1.119以降でサポート
- 信用先
- 判定モデルが「ここは信用していい」と扱う対象。デフォルトでは作業中のフォルダと、プロジェクト設定に登録された送り先サーバーだけ。英語ドキュメントだと trusted infrastructure と呼ばれる
- 対応モデル制約
- Team / Enterprise / API契約はSonnet 4.6・Opus 4.6・Opus 4.7、MaxプランはOpus 4.7のみ。Haikuやclaude-3系は非対応
- 対応経路制約
- Anthropic APIへの直接接続のみサポート。Bedrock / Vertex / Foundry経由では使えない
- jq
- JSONを整形したり、中の一部だけ取り出したりするためのコマンドラインツール