Claude Codeのauto modeを正しく設定する — 許可プロンプトを消す手順と、書いても効かない設定の見分け方

Claude Codeの既定は意図的に保守的で、ファイルを書くたび・シェルコマンドを打つたびに承認を求めます。安全な代わりに、大きめの作業を投げて席を離れることができません。auto modeはこの承認を、人間ではなく分類器という別のモデルに担当させるモードです。ツール呼び出しが実行される前に分類器が1件ずつ審査し、こちらの依頼から逸脱した動作・見覚えのないインフラを狙う動作・読み込んだ敵対的なコンテンツに誘導された動作をブロックします。

位置づけは、すべての確認を飛ばすbypassPermissions(--dangerously-skip-permissions)と、1件ずつ承認する既定のちょうど中間です。ここは誤解されやすいところですが、公式ドキュメントは「auto modeは許可プロンプトを減らすが、安全を保証するものではない」と明記しています。方向性を信頼できる作業に使うものであって、慎重なレビューが必要な操作の代わりにはなりません。

そして重要なのが、審査の対象は全ツールではないという点です。読み取り系の操作と、作業ディレクトリ内のファイル編集は分類器を通らずに通ります(保護パスへの書き込みは除く)。分類器が見るのは、シェルコマンド・ネットワーク操作・外部ツール連携・サブエージェントの起動・作業ディレクトリ外のファイル操作です。つまりauto modeで挙動が変わるのは主にコマンド実行の部分で、レイテンシとトークン消費が増えるのも同じ箇所になります。

分類器に渡る情報も絞られています。こちらのメッセージ・ツール呼び出し・CLAUDE.mdの内容は渡りますが、ツールの実行結果は取り除かれます。ファイルやWebページに仕込まれた敵対的な文章が、分類器を直接説得できないようにするためです。逆に言うと、CLAUDE.mdに「force pushはするな」と書けばClaudeと分類器の両方に効く、という設計になっています。

auto modeは4つの条件を全部満たしたときだけ使えます。プランは全プラン。組織はTeam・Enterpriseでも既定で利用可能ですが、管理者がmanaged settingsでpermissions.disableAutoModeを"disable"にすると組織全体で選べなくなります(値は真偽値ではなく文字列の"disable"です)。プロバイダは、Anthropic API・Claude Platform on AWS・Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry・サインイン済みのClaude apps gatewayセッションで既定で利用できます。残る条件がモデルで、ここに世代の下限があります。

モデル条件はプロバイダごとに違います。Anthropic APIとClaude Platform on AWSでは、Claude Opus 4.6以降・Sonnet 4.6以降・Fable 5。Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry、サインイン済みのClaude apps gatewayセッションでは、Sonnet 5・Opus 4.7以降・Fable 5のみです。Sonnet 4.5、Opus 4.5、Haiku、claude-3系はどのプロバイダでも対象外です。

「auto modeが利用できない」と表示された場合は、この4条件のどれかを満たしていません。一時的な障害ではないので、待っても直りません。混同しやすいのですが、「(モデル名)が一時的に利用できないため、auto modeは(ツール名)の安全性を判断できません」という別のメッセージは、分類器へのリクエストが失敗しただけです。こちらは多くの場合リトライで通るので、設定をいじる必要はありません。文面で切り分けてください。

Pro・Max・Teamプランのターミナルとの VS Code 拡張では、auto modeが組み込みの開始モードです。ただしこれは条件付きです。組み込み既定は表の上から順に最初に一致した行が使われる仕組みで、Pro・Max・Teamの行より上に4つの除外行があります。①どこかの設定ファイルがdisableAutoModeを"disable"にしている、②フィーチャーフラグの取得がオフ、またはインストールやアップグレード直後の最初のセッション、③claude -pやAgent SDK、④Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry・Claude Platform on AWS・Claude apps gatewayセッション。このどれかに当たると、Pro・Max・TeamでもManualで始まります。さらにバージョン条件もあり、この組み込み既定が使えるのはmacOS・Linux・WSLでv2.1.228以降、ネイティブWindowsではv2.1.233以降です。私が確認したのはWindowsのv2.1.229なので、この環境では組み込み既定にはまだ乗っていない、という読み方になります。

ターミナルで新しいセッションを始めたときの権限モードは、上から順に最初に当てはまったものが採用されます。①--permission-modeフラグ(または--dangerously-skip-permissions)、②設定ファイルのpermissions.defaultMode、③組み込み既定。1回だけ試すならフラグで足ります。v2.1.229の--helpで確認できる--permission-modeの選択肢は、acceptEdits / auto / bypassPermissions / manual / dontAsk / plan の6つでした。

常用するならpermissions.defaultModeに書きます。セッション中はShift+Tabで循環でき、autoから最初に押すとdefault(表示名はManual)へ移り、そこからdefault → acceptEdits → planと回ります。ステータスバーには「⏵⏵ auto mode on」と出るので、いま何モードかはここで確認できます。

画面のあるクライアントは経路が別です。VS Code拡張は入力欄の下のモードインジケータから選びます。デスクトップアプリは送信ボタンの隣のモードセレクタで、ここで選んだモードはフォルダごとに記憶され、defaultModeより優先されます(Planだけは例外で、そのセッション限り)。claude.aiとモバイルはプロンプト横のドロップダウンで、Autoが出るのはクラウドセッションかつ組織が許可し、選んだモデルが対応しているときだけです。なおデスクトップにAuto専用の有効化トグルはありません。条件を満たせばセレクタに現れる、という作りです。

1つ目。defaultModeに"auto"と書いても、それがプロジェクトの.claude/settings.jsonや.claude/settings.local.jsonなら効きません。しかもこのとき、~/.claude/settings.jsonに書いたdefaultModeも使われず、組み込み既定にフォールバックします。「設定したのにManualで始まる」の典型がこれです。他の値は普通にどの設定ファイルからでも効くので、autoだけの例外だと覚えるしかありません。

2つ目。VS Code拡張のclaudeCode.initialPermissionModeは、そもそもautoという値を受け付けません。VS Codeで新しい会話をautoで始めたいなら、この設定を未設定のままにして、モードインジケータから一度Autoを選びます。拡張は「前回インジケータで選んだモード」を覚えるので、次の会話からはそれで始まります。あわせて、この設定はuser settingsからしか読まれず、workspace側の値は無視されます(v2.1.225以降。それ以前はworkspace値も効いていました)。

3つ目。ネット上の手順でよく見かけるclaude --enable-auto-modeというフラグは、もう存在しません。公式のCLIリファレンスにはっきり「v2.1.111で削除。auto modeは既定でShift+Tabの循環に入っているので、そのモードで始めたいときは--permission-mode autoを使う」と書かれています。実際にv2.1.229の--helpを検索しても、このフラグは出てきませんでした。関連して、有効化に追加の操作が必要だった時期も公式に記録されています。v2.1.158からv2.1.206までは、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry・Claude apps gatewayセッションで環境変数CLAUDE_CODE_ENABLE_AUTO_MODE=1を設定する必要がありました。これはv2.1.207で不要になり、いまは互換のために受け付けられるだけで効果はありません。「デスクトップやVS Codeでは設定からトグルをオンにする」という手順も出回っていますが、現行のデスクトップにAuto専用のトグルはありません。

ここが実質的な本番です。分類器は既定で、作業ディレクトリと、セッション開始時点で設定されていたそのリポジトリのremoteだけを信頼します。それ以外はすべて「外部」扱いなので、会社のGitHub organizationへのpushやチームのクラウドバケットへの書き込みは、素の状態では止まります。autoMode.environmentは、この信頼境界の内側がどこまでかを分類器に教える設定です。

書き方は正規表現やツールパターンではなく、自然文です。新しく入った同僚にインフラを説明するときの文章をそのまま書きます。「Source control: github.example.com/acme-corp and all repos under it」のような行を並べていく形です。実測したところ、既定のenvironmentは20個のスロットに分かれていて、性格が3種類あります。組織や用途などの文脈を伝えるcontextスロット、信頼する対象を名指しするtrustスロット、そして高リスクとして扱う対象を名指しするsensitivityスロットです。

そして最大の注意点が置き場所です。autoModeは~/.claude/settings.json(user settings)、--settingsフラグ、managed settingsからしか読まれません。プロジェクトの.claude/settings.jsonと.claude/settings.local.jsonは読まれません。理由はドキュメントに書かれていて、この2つはリポジトリの中にあるため、cloneしてきたリポジトリやビルド手順が自前の許可ルールを注入できてしまうからです。したがってチームに配りたい場合、プロジェクト設定は使えず、managed settingsが必須になります。v2.1.207より前は.claude/settings.local.jsonも読まれていたので、古い手順が残っている点も注意です。

一気に全部埋める必要はありません。まずsource controlのorganizationと主要な社内サービスを入れると、自分のリポジトリへのpushのような頻出の誤検知が消えます。次に信頼するドメインとクラウドバケット。あとはブロックが出たときに足していけば十分です。書いたらclaude auto-mode configで実際に効いているか確認します。

分類器の判断は4つのリストで組み立てられています。environmentのほかに、無条件の禁止であるhard_deny、こちらの意図で解除できる破壊的操作のsoft_deny、soft_denyの例外にあたるallowです。優先順位は、hard_denyが最初に無条件でブロック、次にsoft_denyがブロック、allowがそれに一致するsoft_denyを例外として上書き、最後に明示的なユーザーの意図が残りのsoft_denyを上書きします。

この「明示的な意図」の判定は思ったより厳しめです。ざっくりした依頼は意図として数えられません。「リポジトリを片付けて」ではforce pushは許可されず、「このブランチをforce pushして」と言えば許可される、という粒度です。Anthropicの技術記事は、見逃しの多くが危険性の検知失敗ではなく「セッション中の同意がこの操作まで及んでいるか」の判断ミスだと書いていて、同じページで「高リスクなインフラに対する丁寧な人間のレビューの置き換えにはならない」と明言しています。

そして事故が起きやすいのがここです。environment・allow・soft_deny・hard_denyのどれかを設定するとき、配列にリテラル文字列の"$defaults"を入れないと、そのセクションの既定リストがまるごと置き換わります。soft_denyなら、force pushやcurl | bashや本番デプロイやauto modeの迂回といった組み込みルールが全部消えます。hard_denyなら組み込みのデータ持ち出しルールが消えます。セクションごとに独立して評価されるので、environmentだけ書いた場合は残り3つの既定は無傷です。

実測で確かめられます。手元のv2.1.229でclaude auto-mode defaultsを実行すると、既定はallowが17件、soft_denyが65件、hard_denyが1件、environmentが20件でした。hard_denyが1件しかないのは、それが「Data Exfiltration(データ持ち出し)」という1本の長大なルールに集約されているからです。この状態でclaude auto-mode configを実行し、件数が減っていたら、$defaultsを書き忘れてそのセクションを引き継げていない、という判断ができます。

ついでに、既定を丸ごとコピーして埋める方式にも副作用があります。私の環境では過去にそうやって作ったenvironmentが残っていて、そこにはv2.1.211で廃止された「Default / protected branches」というスロットがまだ入っていました。組み込みリストを引き継がない書き方をすると、不要になったスロットが残り、新しく増えたスロットは入ってこない、ということが起きます。特別な理由がなければ$defaults併記のほうが楽です。

auto modeでも、作業中のリポジトリの任意のブランチへのpushは既定で確認なしに通ります(v2.1.211以降。それ以前は作業ブランチと既定ブランチ中心でした)。プルリクエストの作成も、依頼した内容に沿ったものであれば同じく通ります。ただしproductionやgh-pagesのように公開・デプロイ先だと分かる名前のブランチは別扱いで、その都度判断されます。またpushやPRの中身は常に検査されるので、force pushや、シークレットが混ざるコミット、CIやデプロイが動いたときに情報が外へ出る変更は止まります。別のリポジトリやorganizationに向けたPR、gh repo forkでのフォーク、内部パスやAPIから取れた個人データをPR本文に含める変更も、その宛先や内容を自分で名指ししていなければブロックされます。

それでも「pushの前は必ず自分が見る」を残したいなら、permissions.askにルールを足します。内容にスコープを付けたaskルールは分類器より前に評価され、auto modeでも必ず確認が出ます。明示的なaskは「そこは聞いてほしい」という意思表示なので、分類器が自動承認で追い越すことはありません。

境界の強さは3段階で使い分けます。確認を挟みたいだけならask。絶対に実行させたくないならdenyで、これは分類器に到達する前にブロックし、こちらの意図でも分類器の設定でも上書きできません。そして「今回はpushしないで」のように会話で伝えた境界も分類器はブロック信号として扱いますが、これは毎回トランスクリプトから読み直される仕組みなので、コンテキストの圧縮でその発言が消えると失われます。恒久的に守りたいならaskかdenyを使ってください。

もうひとつ、既定のまま見落としやすい挙動があります。auto modeに入るとBash(*)やワイルドカード付きのインタプリタのような広すぎるallowルールは外されますが、Bash(npm test)のような狭いルールは生き残り、分類器より前に解決されます。つまり狭いルールの想定外の引数がすり抜ける余地があります。全シェルコマンドを分類器に通したいなら、autoMode.classifyAllShellをtrueにします(v2.1.193以降)。レイテンシとトークンを払って網羅性を買う設定です。

ブロックされた操作は原則として/permissionsのRecently deniedタブに記録されます。行を選んでrを押すと再試行の印が付き、ダイアログを閉じたときにClaudeへ「その操作を再試行してよい」というメッセージが送られて会話が再開します。表示される理由は、多くのセッションでは「Blocked by classifier」という固定文です(v2.1.208以降)。分類器は内部の深刻度で採点していて説明文を書かないためで、説明文が出るセッションもありますが、どちらが出るかは選べません。ひとつ例外があります。分類器が判定を出せなかったとき——auto modeとは別の安全チェックが分類器のリクエスト自体を拒否した場合、または応答がパースできなかった場合——は、通知もRecently deniedへの記録もないまま拒否されます。「止まったのにRecently deniedに何も出ていない」ときはこれを疑ってください。

同じ宛先で何度も落ちるなら、それはルールの問題ではなく分類器が文脈を持っていないサインです。その宛先をautoMode.environmentに足して、claude auto-mode configで反映を確認する。これが基本の直し方になります。一方、一度だけ意図してやりたい操作なら、次のメッセージでその意図を具体的に述べてやり直させるほうが早いです。

無人で回すときに知っておきたいのがしきい値です。分類器が3回連続、または累計20回ブロックすると、auto modeは一時停止して確認に戻ります。この数値は変更できません。許可された操作があると連続カウントはリセットされます。累計カウントはセッションを通じて積み上がりますが、累計側の20回に達して一時停止が起きたときにリセットされます。なお、auto modeとは別のAPI側の安全チェックが分類器のリクエストを拒否したケースは、どちらのしきい値にもカウントされません。ルールを厳しく書きすぎると、無人で回すという目的そのものが達成できなくなるので、ここは締めすぎないほうが実用的です。

確認を出せない環境では挙動が変わります。--permission-prompt-toolを渡していないclaude -pの実行には戻る先の確認がないので、しきい値に達した操作は実行されないまま、Claudeは作業を続けます。実行が止まるわけではない、という点は自動化を組むときに効いてきます。プログラム側で拾いたい場合はPermissionDeniedフックが使えますが、このフックで拒否を取り消すことはできません。読まれる出力はhookSpecificOutput.retryだけで、終了コードとstderrは無視されます。

整理すると、最初に入れるべきものは多くありません。~/.claude/settings.jsonにdefaultMode: "auto"を置き、autoMode.environmentに"$defaults"と自分のsource controlと主要な社内サービスを書き、permissions.askにpushとPR作成を入れる。これで「基本は止まらず、外に出る操作だけ自分が見る」形になります。あとはブロックが出るたびにenvironmentへ足していけば育ちます。

落とし穴だけ再掲します。autoはプロジェクトの設定ファイルからは効かない。autoModeはリポジトリ内の設定ファイルからは読まれない。$defaultsを書かないとそのセクションの既定が消える。狭いシェルのallowルールは分類器より前に解決される。disableAutoModeの値は文字列の"disable"。この5つを踏まなければ、設定で悩む時間はかなり減るはずです。

最後にひとつ。auto modeを入れても、レビューが必要な操作はレビューが必要なままです。公式ドキュメントも技術記事も、そこは同じことを書いています。プロンプトが減るのは作業のテンポの話であって、責任の所在が動くわけではない、という前提で使うのが結局いちばん楽だと思います。