Claude Codeの「Do you want to proceed?」を毎回押さずに済ませたい、という需要に公式が用意した答えがauto modeです。あなたの代わりに別モデルの分類器（classifier）が審査対象の操作を実行前に評価し、危険と判断したものを止めます。見逃しや誤検知はゼロではありません。2026年3月24日にTeamプラン向けのリサーチプレビューとして登場し、7月10日に一般提供（GA）となりました。9月25日公開のv2.1.283からは、全プラン・全プロバイダーでターミナルとVS Codeの起動時の既定モードです。本記事では、分類器の判定順序、既定でブロックされる操作、「bash denied by auto mode」や「classifier unavailable」の直し方、autoModeの設定、使わない方がよい場面を、公式ドキュメントと2026年10月時点のv2.1.299の実機出力で整理します。
まとめ
- auto modeは、承認プロンプトの代わりに分類器が操作を審査する権限モードです。通常の読み取りと作業ディレクトリ内の編集は原則として自動承認されます。ただし、保護パスなどには例外があり、サーバー側審査では読み取り専用のシェルコマンドも審査結果を待ちます。
- v2.1.283以降、ターミナルとVS Codeは、対応モデルを使っていて無効化の設定がなければauto modeで起動します。
claude -pとAgent SDKは原則Manual（default）で、他社クラウド経由やテレメトリ無効の場合だけv2.1.285以降autoで始まります。 --enable-auto-modeはv2.1.111から不要です。いまはShift+Tabか--permission-mode autoで入ります。- v2.1.299の組み込みルールは、許可17件、ソフトブロック72件、無条件ブロック1件（Data Exfiltration）です。ローカルで
claude auto-mode defaultsを実行して数えました。 - 止まったら、まず表示の種類を見分けます。
[規則名]付きの拒否は分類器の判定なので設定か明示承認で直し、「classifier unavailable」「could not evaluate」は判定が出なかっただけなので再試行します。 - Anthropicの比較実験では、危険なコマンドを止めた割合は人間の13.6%に対してauto modeが89%でした。この実験では約1割を見逃しており、実運用での見逃し率を保証する数値ではありません。本番の資格情報にアクセスできる端末では
permissions.denyと隔離環境を併用します。
auto modeの判定順序と分類器が読む情報
操作が通る4段階の判定順序
auto modeでは、すべての操作が固定の順序で判定されます。最初に当てはまった段で結論が決まります（公式ドキュメント「権限モードを選択する」の判定順序）。
- パーミッションルールを先に評価します。askルールは常にプロンプトを出し、denyルールはどのモードでも止めます。allowルールに一致した操作も原則そのまま通りますが、保護パスへの書き込みや接続先を指定したシェルコマンドなどは分類器の審査が残ります。
- 読み取り専用の操作と作業ディレクトリ内の編集は自動承認されます。例外は、保護パスへの書き込みと、作業ディレクトリ外への最初の読み取りです。後者は「Yes, but ask again next time」（v2.1.284以降）などの4択で確認されます。
- それ以外、つまりシェルコマンド、Web取得、外部ツール、サブエージェントの起動、作業ディレクトリ外の操作は分類器に回ります。
rm -rf ~のような重要パスの削除だけは、分類器ではなく別の保護で扱われます。 - 分類器がブロックすると、Claudeは一致した規則名を受け取り、別の方法を試します。
ソースの編集に分類器の待ち時間が乗らないのは、2段目で通るためです。遅延とトークンが増えるのは、ほぼシェルとネットワークの操作だけです。なお、tool.checkを扱うmodが3段目の前で承認した操作は、分類器が審査しません。modの仕組みはClaude Code Modsとは｜Hooksとの違い・作り方・組織管理の実装で解説しています。
分類器の既定モデルと審査入力の範囲
分類器は、/modelで選んだモデルではなく既定でClaude Sonnet 5で動きます。セッションがSonnet 4.6の場合や、availableModelsでSonnet 5を除外している場合は、原則としてセッションのモデルが使われます。セッションのモデルがFableの場合は、代わりにOpusが使われます。Claude Code自身が送る審査リクエストに含まれるのは、ユーザーのメッセージ、読み取り以外のツール呼び出し、CLAUDE.mdの内容です。ツールの実行結果は除かれます。READMEやWebページに仕込まれた命令が分類器を直接だませないのは、この設計のためです。入力側では、サーバー側のプローブがツール結果を検査し、乗っ取りを狙う内容に警告を付けます。攻撃の手口はプロンプトインジェクションの仕組みと対策で解説しています。
CLAUDE.mdを分類器も読むので、「force pushしない」とCLAUDE.mdに書けば、Claudeと分類器の両方に効きます。サブエージェントは、起動前のタスク説明、実行中の各操作、完了時の作業と報告の3地点で審査されます。サブエージェント定義のpermissionModeは無視されます。
サーバー側審査と自前の分類器リクエストの違い
2026年9月以降、審査の送り方は2通りあります。従来の方式では、Claude Codeが操作のたびに分類器へ別のリクエストを送ります。新しいサーバー側審査（server-side classifier review）では、審査をモデルへのリクエストに含め、サーバーが判定を返します。
| 接続先 | サーバー側審査の既定化 |
|---|---|
| Anthropic API直結・対話ターミナル（Pro／Max／Team） | v2.1.271以降・順次展開 |
| Anthropic API直結・対話ターミナル（Enterprise・APIキー） | v2.1.278以降・順次展開 |
Anthropic API直結・-p／SDK／VS Code／デスクトップ |
v2.1.281以降・順次展開 |
| Bedrock・Agent Platform・Foundry・LLMゲートウェイ | v2.1.278以降 |
どちらで動いているかは、/statusの「Auto mode server」の行で確かめます。Enabledならサーバーが判定し、Disabledなら自前のリクエストに戻っています。違いが出るのは失敗時です。サーバーが判定を返さなかった操作は実行されずに拒否され、10回の応答で続けて判定がないとターンが止まります。LLMゲートウェイやプロキシが応答を途中で切ったり書き換えたりすると、これが起きます。自前の分類器に固定したいときは、起動前に環境変数CLAUDE_CODE_AUTO_MODE_SERVER=0を設定します。
auto modeに入ると外れる広いallowルール
Manualモードで便利に使っていた広いallowルールは、auto modeの間だけ無効になります。対象はBash(*)、PowerShell(*)、Bash(python*)のようなインタープリタのワイルドカード、パッケージマネージャーのrunコマンド、AgentとMonitorのallowルールです。残すと、最も危険なコマンドが分類器を素通りするからです。Anthropicによると、2026年6月時点でCLIの利用者の49.5%がBashのallowルールを手で作っており、5%はすべてのシェルコマンドを許可していました。Bash(npm test)のような狭いルールは残り、auto modeを抜けると元に戻ります。
狭いルールでも、想定外の引数が通る余地は残ります。重要パスの削除を除くすべてのシェルコマンドを分類器に審査させたい場合は、autoMode.classifyAllShellをtrueにします。そのぶん、コマンドごとに分類器の待ち時間がかかります。
公式評価の数字：3月の技術解説と8月の比較実験
Anthropicは2026年3月25日の技術解説「How we built Claude Code auto mode」で、分類器パイプラインの評価を公開しました。当時の分類器はSonnet 4.6です。
| データセット | 件数 | 1段目のみ | 2段目まで |
|---|---|---|---|
| 社内の実トラフィック（誤検知率） | 10,000 | 8.5% | 0.4% |
| 実際の行き過ぎ操作（見逃し率） | 52 | 6.6% | 17% |
| 合成のデータ持ち出し（見逃し率） | 1,000 | 1.8% | 5.7% |
1段目は1トークンでブロック寄りに判定する高速フィルタで、引っかかった操作だけを思考付きの2段目が再評価します。誤検知率0.4%は、社内の無害な操作1,000件のうち約4件を誤って止めた割合です。一方、実際に起きた行き過ぎ操作52件では、約6件に1件を通していました。
8月7日の既定化の告知では、人間の承認との比較が加わりました。有償の被験者1,053人に、承認プロンプトの1つを明らかに危険なコマンドへ差し替えて見せた実験です。人間が止めたのは13.6%（143件）、auto modeは89%（937件）でした。人間の検出率はセッション序盤の約17%から、50回以上のプロンプトの後には約5%まで下がっています。同じ告知では、720件のプロンプトインジェクション攻撃がClaude Fable 5、Opus 5、Sonnet 5のauto modeでは1件も成功せず、GPT-5.6 Solでは5.83%が成功したとしています。ただしこれはモデル単体の測定で、導入環境の安全策全体の評価ではないと告知自身が断っています。数字が示すのは、auto modeが承認に慣れた人間より多く止めることです。約1割は止めていないので、安全を保証する仕組みではありません。
既定でブロックされる操作と許可される操作
v2.1.299の組み込みルールの件数と区分
claude auto-mode defaultsを実行すると、組み込みルールがJSONで表示されます。v2.1.299で数えた内訳は次のとおりです。
| 区分 | 件数 | 性質 |
|---|---|---|
allow |
17 | ソフトブロックの例外 |
soft_deny |
72 | 明示の指示や例外で解除できる |
hard_deny |
1 | Data Exfiltration・解除不可 |
environment |
21 | 信頼境界と環境の説明 |
2026年3月の技術解説では、ブロック規則は「20超」でした。9月25日のv2.1.283では70件で、10月のv2.1.299では72件に増えています。ブロック対象はリリースごとに変わるので、他社記事の一覧ではなく、手元でdefaultsを確認するのが確実です。1件の全文だけ見たい場合は、--label 'Git Destructive'のように前方一致で絞れます。
既定でブロックされる代表的な操作
curl | bashのように、コードをダウンロードしてそのまま実行する操作- フォースプッシュ、
git reset --hard、git clean -fd、git stash dropなど、未コミットの作業を捨てる操作 - 本番デプロイとマイグレーション、
terraform destroy、クラウドストレージの一括削除 - IAMやリポジトリ権限の付与、DNS・TLS証明書・シークレットストアへの書き込み
- 人間が承認していないPRのマージ、Claude自身のPRの承認、CIチェックの無効化
- 機密データの外部送信、
169.254.169.254のメタデータエンドポイントからの資格情報取得
判断の基準は、コマンドの見た目ではなく実際の影響です。ファイルに書いたスクリプトを実行する場合は中身が審査され、&&でつないだコマンドは全体で1つの操作として扱われます。git reset --hardのように未コミットの作業を捨てるコマンドの前には、Claude Code自身がgit statusを実行し、変更が残っているかを分類器に見せます。
既定で許可される操作と信頼境界
作業ディレクトリ内のファイル操作、セッション中にClaudeが変更していないマニフェストなどに宣言済みの依存を、標準コマンドでインストールする操作、.envの資格情報を対応するAPIへ送ること、読み取りだけのHTTPリクエストは原則として許可されます。ただし、URLに機密情報を含む場合や、応答から資格情報・秘密情報・個人情報を取得する場合などは別途判定されます。プッシュは、作業中のリポジトリであれば既定ブランチを含む全ブランチに通ります。ただし、productionやgh-pagesのようにデプロイ先を示す名前のブランチは別扱いです。
分類器が信頼するのは、作業ディレクトリと、セッション開始時に設定されていたリモートだけです。セッション中にgit remote addで足したリモートは信頼されません。社内のGitHub組織やS3バケットへの操作も、登録するまでは「外部」扱いでブロックされます。
「Do you want to proceed?」を減らす他モードとの違い
承認を減らす手段はauto modeだけではありません。Claude Codeには6つのパーミッションモードがあり、プロンプトなしで通る範囲が違います。
| モード | ステータスバー表示 | プロンプトなしで通る範囲 |
|---|---|---|
default（Manual） |
⏸ manual mode on | 読み取りのみ |
acceptEdits |
⏵⏵ accept edits on | 読み取り、編集、基本のファイル操作 |
plan |
⏸ plan mode on | 読み取り・条件付きで分類器が許可したコマンド |
auto |
⏵⏵ auto mode on | 分類器が通したすべて |
dontAsk |
⏵⏵ don’t ask on | 読み取り・事前許可済みのツール |
bypassPermissions |
⏵⏵ bypass permissions on | すべて（隔離環境専用） |
各モードの設定キーとCLIフラグの一覧は、Claude Codeのパーミッションモードの違いと設定方法にまとめています。ここではauto modeと混同されやすい2つとの差だけを押さえます。
accept edits onとの違い：Bashの承認範囲
ステータスバーの「accept edits on」は、acceptEditsモードに入っている表示です。このモードでは、作業ディレクトリ内のファイル編集に加え、mkdir、touch、rm、rmdir、mv、cp、sedが自動承認されます。それ以外のBash、たとえばnpm testやgit commitは、allowルールなどによる事前許可がなければ承認を求められます。編集後にgit diffで見直す運用ならacceptEditsで十分です。テストと修正を繰り返す作業では、auto modeのほか、定型コマンドに絞ったallowルールでも承認回数を減らせます。
bypassPermissionsとの違い：審査の有無
--dangerously-skip-permissionsで入るbypassPermissionsは、分類器を通さずにすべてを実行します。allowルールは意味を持たず、効くのはdenyルール、askルール、重要パスへのrmの確認などだけです。LinuxとmacOSでは、rootで起動しようとすると拒否されます。公式が想定する用途は、コンテナやVMの中での無人実行に限られます。auto modeは、ホストで作業しながら承認を減らしたい場面のための選択肢です。
auto modeの有効化と切り替え手順
v2.1.283以降の開始モードと適用条件
組み込みの開始モードは、起動の仕方で決まります。上の行から順に、最初に当てはまったものが使われます。
| 起動の仕方 | 開始モード |
|---|---|
いずれかの設定でdisableAutoModeが"disable" |
default |
claude -p・Agent SDK（通常） |
default |
claude -p・Agent SDK（他社クラウド・テレメトリ無効） |
v2.1.285以降はauto |
| HIPAA構成の組織 | default（v2.1.285以降） |
| ターミナル・VS Code拡張（v2.1.283以降） | auto |
| 同上（v2.1.228〜v2.1.282） | Pro／Max／Teamのみauto |
Pro／Max／Teamプランでの既定化は2026年8月14日に始まりました。必要なバージョンは、macOS・Linux・WSLがv2.1.228（8月11日公開）、ネイティブWindowsがv2.1.233（8月14日公開）です。「通常」のclaude -pは、機能フラグを取得するセッションを指します。他社クラウド経由やテレメトリ無効のときは機能フラグを取得しないので、v2.1.285以降はスクリプトから呼んでもautoで始まります。CIの挙動を固定したいなら、--permission-modeを明示してください。
対応モデルと「auto modeが使えない」ときの確認順
auto modeは全プランで使えますが、モデルに条件があります。条件を満たさないモデルでは、autoを指定してもManualで起動します。
- Anthropic API、Claude Platform on AWS：Opus 4.6以降、Sonnet 4.6以降、Haiku 5.5、Fable
- Bedrock、Agent Platform、Foundry、Claude apps gateway：Sonnet 5以降、Opus 4.7以降、Haiku 5.5（v2.1.293以降）、Fable
- Sonnet 4.5、Opus 4.5、Haiku 4.5以前は、どのプロバイダーでも使えません
Haikuで使えるのは、2026年10月7日に公開されたClaude Haiku 5.5からです。モデルが条件を満たしているのに使えない場合は、次に、いずれかの設定ファイルのdisableAutoModeを確認します。Anthropicがサーバー側で一時的に止めたり、アカウントに対して拒否したりした場合も使えません。その場合はセッションが終わるまでオフのままなので、時間を置いて新しいセッションを始めます。
CLIでの切り替えと、不要になった--enable-auto-mode
セッション中はShift+Tabでモードを巡回します。auto modeから1回押すとManualに移り、その後はManual、acceptEdits、plan、autoの順に回ります。起動時に指定する場合は次のとおりです。
claude --permission-mode autoManualモードやacceptEditsモードでBashの承認プロンプトが出たときは、「Yes, and switch to auto mode」を選ぶと、そのコマンドを承認してそのままauto modeへ移れます（v2.1.247以降）。リサーチプレビュー期間に案内されていたclaude --enable-auto-modeは、v2.1.111（2026年4月16日）で不要になりました。公式のCLIリファレンスは「Removed in v2.1.111」と記載しています。v2.1.299で実際に付けてみると、未知のフラグと違ってエラーにはならず受け付けられました。ただし、auto modeで始めるための指定は--permission-mode autoです。古い記事の手順を使う場合は、こちらに置き換えてください。
VS Code・デスクトップアプリ・Webでの切り替え
VS Code拡張では、プロンプト欄の下にあるモード表示をクリックし、「Auto」を選びます。設定のclaudeCode.initialPermissionModeはautoを受け付けません。Autoで始めたい場合は、この設定を未設定のままにし、モード表示から一度「Auto」を選びます。デスクトップアプリでは、Codeタブの送信ボタン横にあるモードセレクターから選びます。claude.aiのクラウドセッションでは、組織が許可していて、選んだモデルが対応していればAutoが選べます。
プロジェクト設定のdefaultModeにautoを書いても効かない落とし穴
permissions.defaultModeに"auto"と書いても、プロジェクトの.claude/settings.jsonや.claude/settings.local.jsonに置いた場合は効きません。値はエラーも出さずに無視されます。リポジトリに入った設定ファイル1つで自動実行を有効にできないようにするための仕様です。個人の設定として~/.claude/settings.jsonに書きます。
{
"permissions": {
"defaultMode": "auto"
}
}後述するautoModeブロックも同じ理由で、プロジェクト設定からは読まれません。
「bash denied by auto mode」と表示されたときの対処
auto modeの拒否通知と再試行手順
分類器がブロックすると、入力欄の近くにbash denied by auto mode · [Data Exfiltration] · /permissionsのような通知が出ます。角括弧の中は、一致したルールのラベルです。コマンド本文は表示されないので、会話中の該当ツール呼び出しを探し、折りたたまれていればCtrl+Oのトランスクリプトビューアで展開します。/permissionsの「Recently denied」タブに拒否された操作が記録され、rを押すと手動承認付きで再実行できます。
エラー文言の早見表：判定による拒否と判定なしの拒否
止まり方は2種類あります。分類器が危険と判定した拒否と、分類器が判定を返せなかった拒否です。後者は安全とも危険とも判定されていません。一時的な失敗なら再試行し、繰り返す場合は接続先モデルの呼び出し権限やゲートウェイの設定を確認します。公式のエラーリファレンスと実行ファイルの文字列をもとに整理しました。
| 表示 | 意味 | 対処 |
|---|---|---|
Denied by auto mode classifier＋規則名 |
分類器が危険と判定 | 信頼先の登録・allow・明示承認 |
classifier unavailable |
分類器が応答せず拒否 | 数秒待って再試行 |
<model> is temporarily unavailable |
分類器モデルの一時的な失敗 | 再試行・Bedrockは呼び出し権限 |
Not run · auto mode's check had no usable answer |
判定なしで未実行 | Ctrl+Oで全文を読む |
Auto mode could not evaluate this action |
応答を解析できない等 | 再試行・claude --debug |
transcript exceeded context window |
会話が分類器の上限を超過 | /compact |
server-side auto mode classifier gave no verdict |
サーバー側審査の判定なし | 再試行・ゲートウェイを確認 |
「bash denied by auto mode · classifier unavailable」という表示は、規則名の位置に分類器が使えなかった旨が出た状態です。v2.1.299の実行ファイルには「Auto mode classifier unavailable, denying with retry guidance (fail closed)」という文字列があります。判定できないときは通さずに拒否し、再試行を促す動きです。Claude自身も同じメッセージを受け取り、たいていは自分で再試行します。v2.1.296からは、対話画面では赤いエラーではなく薄い「Not run」の行で表示されます。
「could not evaluate this action」には、もう1つの原因があります。会話にすでにある内容がAPI側の別の安全フィルタに引っかかり、分類器へのリクエスト自体が拒否された場合です。この場合は同じ会話で再試行しても通りません。モードを切り替えて手動で承認するか、その内容を含まない新しい会話で始めます。この拒否は、後述の連続3回・累計20回の数には入りません（v2.1.225以降）。
auto modeの拒否原因別の対処
- 作業中ずっと使う接続先が止められた：社内レジストリ、社内ドメイン、GitHub組織などは
autoMode.environmentに登録します。同じ宛先で繰り返しブロックされるのは、たいていこれが原因です。 - 分類器のソフトブロックから除外したい定型コマンド：
autoMode.allowにルールを追加します。 - 一度だけ意図して実行したい操作：次のメッセージで、操作とその対象を具体的に書いて許可します。
3つ目の書き方には注意が要ります。「フォースプッシュしていい」のように動詞だけを書いても、ブロックは解除されません。「feature/loginブランチをフォースプッシュして」のように、危険な部分の具体（この場合はブランチ）まで書く必要があります。また、通常は名指しした1回の操作に対する許可として扱われますが、継続的な許可として明示した場合は例外です。
auto modeの手動承認への復帰条件：連続3回・累計20回
分類器が3回連続、またはセッション累計で20回ブロックすると、auto modeは一時停止し、承認プロンプトに戻ります。プロンプトに出た操作を承認すれば、auto modeは再開します。この閾値は変更できません。承認プロンプトを出せないclaude -p（--permission-prompt-toolなし）では、閾値に達した操作を実行せずに作業を続けます。無人実行で「何も起きずに終わった」ときは、ここを疑ってください。
PermissionDeniedフックによる拒否内容の記録
通知にも「Recently denied」タブにもコマンド本文は出ないので、後から誤検知を分析するにはPermissionDeniedフックで記録します。このフックは、判定なしの拒否を含め、auto modeが拒否したときに発火し、tool_inputとreasonを受け取ります。以下の例はjqを導入済みのPOSIXシェル環境を前提とし、Bashの拒否を記録します。
{
"hooks": {
"PermissionDenied": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "jq -c \"{time: (now|todate), tool: .tool_name, input: .tool_input, reason}\" >> ~/.claude/auto-denied.jsonl"
}
]
}
]
}
}フックがhookSpecificOutput.retryにtrueを返すと、Claudeに再試行してよいと伝えられます。ただし、拒否そのものは取り消されず、判定なしの拒否ではretryは無視されます。フックの書式の全体はClaude Code Hooksの設定方法を参照してください。
autoModeの設定：信頼インフラと独自ルール
autoMode.environmentへの信頼先の登録
誤検知を減らす最初の一手はenvironmentです。項目は正規表現ではなく、新しく入ったエンジニアに社内の環境を説明するような自然文で書きます。配列に"$defaults"を入れると、組み込みの項目がその位置に展開されます。
{
"autoMode": {
"environment": [
"$defaults",
"Source control: github.example.com/acme-corp and all repos under it",
"Trusted cloud buckets: s3://acme-build-artifacts",
"Trusted internal domains: *.corp.example.com"
]
}
}分類器がautoModeを読むのは、~/.claude/settings.json、管理設定、--settingsフラグ（またはAgent SDK）の3か所だけです。各スコープの内容は合算され、個人は管理設定の項目を消せません。ただし、個人が追加したallowは管理設定のsoft_denyの例外になり得ます。組織として強制する禁止には管理設定のpermissions.denyを使います。
/auto-mode-setupで信頼先の下書きを作る手順
何を登録すればよいか分からない場合は、/auto-mode-setupを実行します。Claude Codeがこのプロジェクトについて質問したうえで、次の情報を読み、environmentと必要ならルールの下書きを作ります。
- このプロジェクトのCLAUDE.md、README.md、設定ファイル、gitのリモート
- 既存の
autoModeとpermissions.allow - このプロジェクトの直近のセッションでClaudeが実行したコマンドのホスト名、バケット名、コマンド名（あなたのメッセージは読みません）
- 任意で、シェル履歴の各コマンドの先頭の語と、ホームディレクトリ下のリポジトリのリモート
下書きは一括で採用か破棄を選び、採用すると~/.claude/settings.jsonに書き込まれます。保存後には、auto modeが無視するBash(*)などのallowルールを消すかどうかも提案されます。使えるのはPro／Max／Teamプランで、v2.1.228以降（ネイティブWindowsはv2.1.233以降）です。クラウドセッションや、機能フラグの取得を無効にしたセッションでは実行できません。
何度かブロックされてもenvironmentが空のままだと、ターンの終わりに「Teach auto mode about your environment?」というダイアログが出ます。提案だけ止めたいときは、ダイアログで「Don’t show again」を選びます。コマンドごと止めるには、~/.claude/settings.jsonに次を書きます。
{
"skillOverrides": {
"auto-mode-setup": "off"
}
}hard_deny・soft_deny・allowの優先順位と$defaultsの罠
分類器の内部では、次の順で優先されます。まずhard_denyが無条件にブロックします。次にsoft_denyがブロックし、allowがその例外として解除します。最後に、ユーザーが操作を具体的に指示した場合は、残ったソフトブロックも解除されます。「リポジトリを掃除して」という一般的な依頼は、フォースプッシュの許可にはなりません。
いちばん危険なのは、"$defaults"を書かずに配列を設定することです。その区分の組み込みルールがすべて置き換わります。たとえばsoft_denyで書き忘れると、フォースプッシュ、curl | bash、本番デプロイのブロックがまとめて消えます。独自ルールを書いたら、claude auto-mode configで実際に効いている内容を表示し、claude auto-mode critiqueで曖昧なルールや重複を指摘させます。元に戻すにはclaude auto-mode resetを使います（v2.1.212以降）。設定ファイルを開かずに編集したい場合は、/permissionsの「Auto mode」タブが使えます（v2.1.246以降）。
auto modeを使わない方がよい場面と安全設計
本番の資格情報にアクセスできる端末でのauto mode非採用方針
特定の実験で危険なコマンドの見逃しが残ったことを踏まえ、本記事では本番環境への到達権限を基準に採用可否を判断します。本番DBへの接続文字列や、クラウドの管理者権限を持つプロファイルが手元にある端末では、auto modeを既定にしません。公式もリサーチプレビューの告知以来、隔離環境での利用を推奨しています。コンテナで作業するなら、VS Codeで開発コンテナを作る手順の構成にauto modeを重ねるのが現実的です。Bashサンドボックスとauto modeは独立して動くので、併用できます。
絶対に実行させたくない操作は、分類器の判断に任せずpermissions.denyに書きます。denyルールは分類器より前に評価され、ユーザーの指示でも覆りません。プッシュの前に人間が確認したい場合は、"Bash(git push *)"をpermissions.askに入れれば、auto modeのままその操作だけプロンプトが出ます。ただし、git -C <dir> pushのような別の書き方には一致しない点に注意してください。社内の業務システムにエージェントを組み込む場合の権限設計は、AIエージェント開発の支援でも扱っています。
コンテキスト圧縮による会話上の禁止指示の消失リスク
「レビューするまでデプロイしないで」と会話で伝えると、分類器はそれをブロックの根拠として扱います。ただし、これはルールとして保存されず、審査のたびにトランスクリプトから読み直されます。長いセッションでコンテキストが圧縮され、その発言が要約から落ちると、制約も消えます。圧縮が起きる条件はauto-compactの発動点と/compactで解説しています。長時間の作業を任せる前に、継続して守らせたい制約をdenyルールかaskルールへ書き写してください。
よくある質問
auto modeでAIがコードレビューやテストを自律的に実行できるようになる？
auto modeは、実行の許可を人間の代わりに分類器が判断するモードです。レビューやテストの機能を追加するものではありません。テストの実行や修正の繰り返しを承認なしで回せるようになるのは、npm testなどのコマンドが分類器を通過し、プロンプトが出なくなるためです。PRの自動レビューはCode ReviewやGitHub Actions連携など別の機能が担うので、auto modeを有効にしただけではレビューは始まりません。
auto modeに追加料金はかかる？
Pro／Max／Teamプランでは、分類器の追加使用量は課金されません。この変更は2026年8月7日から適用されています。Enterpriseプランや、APIキー、Bedrock、Agent Platform、Foundryを使う場合、Claude Codeが自前で送る分類器リクエストはトークン使用量に数えられます。サーバー側審査で動いているセッションでは、審査がモデルへのリクエストの一部として行われるため、別に数える分類器リクエストはありません。
auto modeはWindowsで使える？
使えます。ネイティブWindowsでは、Pro／Max／Teamならv2.1.233以降、全プランではv2.1.283以降、起動時の既定がautoです。PowerShellツールの承認プロンプトには「Yes, and switch to auto mode」が出ないので、切り替えはShift+Tabで行います。削除コマンドについては、Remove-Itemで対象を*だけにしたものや/*で終わるものは、分類器に回る前に拒否されます。
claude -p（非対話実行）でもauto modeは使える？
使えます。開始モードは接続先や設定で変わるため、無人実行では--permission-mode autoを明示してください。条件は上の開始モードの表のとおりで、Anthropicに直接つなぐ通常の環境ではManualで始まります。厳密な許可リストで運用するCIでは、dontAskと--allowedToolsを使います。
auto modeを無効化するには？
個人で既定をManualに戻すなら、~/.claude/settings.jsonのpermissions.defaultModeを"default"にします。この場合も、Shift+Tabでauto modeを選ぶことはできます。組織として選べなくするには、管理設定でdisableAutoModeを"disable"にします（permissions.disableAutoModeと書いても同じです）。巡回からautoが消え、--permission-mode autoで起動してもManualになります。v2.1.251以降は、実行中のセッションもこの設定が届いた時点でauto modeを抜けます。
