Claude CodeのAuto Modeとは？classifierが既定でブロックする操作と安全な使い方

Claude CodeのAuto Modeは、/modelとは独立した別モデル（classifier）が各ツール呼び出しを評価し、本番デプロイ・大量削除・無関係インフラへのアクセスなど8カテゴリの操作を既定でブロックしながらプロンプト承認を不要にするpermission modeです。公式は「research preview」と明記しており、安全性を完全保証するものではなく**「方針は信頼できるが、機密操作には別途レビューが必要な作業」向け**と整理されています。

結論を先に書いておくと、Auto Modeは「Plan Modeで方針を固め、本番に触らない範囲の繰り返しタスクをまとめて走らせる」用途で効くモードです。bypassPermissions（旧 --dangerously-skip-permissions）と違ってclassifierが背景でチェックを続けるため、curl | bashや本番デプロイのような無自覚な事故は止まります。一方、ストッパーは「classifierの判断」であり万能ではないので、人間レビューが必要な機密領域では従来通りPlan Mode＋手動承認のほうが安全です。

利用可能条件（プラン・モデル・プロバイダー）

Auto Modeを使うには次の条件をすべて満たす必要があります。1つでも欠けると「Auto Modeは利用不可」と表示され、これは一時的な障害ではなく恒久的な不可です。

• Claude Codeバージョン: v2.1.83以降
• プラン: 全プランで利用可。ただしTeam・Enterpriseでは管理者がClaude Code admin settingsで有効化しなければユーザーは使えない
• モデル: Claude Sonnet 4.6、Opus 4.6、Opus 4.7のいずれか。Sonnet 4.5、Opus 4.5、Haiku、claude-3系は非対応
• プロバイダー: Anthropic APIのみ。AWS Bedrock、Google Vertex、Microsoft Foundry経由では使えない

「使えない理由」を切り分けるときに重要なのが、エラーメッセージの違いです。利用条件未達は恒久不可、モデル名を含む「cannot determine the safety」エラーはclassifierの一時的な障害で別物として扱います。後者はエラー逆引きの対象です。

モード切替：Shift+Tabは段階的に出現

Auto Modeはdefault → acceptEdits → planの標準サイクルに最初から入っていません。アカウントが利用条件を満たすと**Shift+Tabサイクルに「opt-in promptとして」現れ**、初回利用時に承諾するか「No, don’t ask again」を選ぶことになります。CLIで明示的に起動するには次のフラグを使います。

ユーザー設定（~/.claude/settings.json）で既定モードに固定したい場合は次のとおりです。

{
  "permissions": {
    "defaultMode": "auto"
  }
}

ここで一つ注意があります。プロジェクトの.claude/settings.jsonにdefaultMode: "auto"を書いてもClaude Codeは無視します。「リポジトリが自分自身にAuto Modeを付与できないようにする」設計上の制約で、Auto Modeを既定にしたい場合はユーザー設定（~/.claude/）に置く必要があります。VS Code拡張のclaudeCode.initialPermissionModeも同じ理由でautoを受け付けません。

classifierが既定でブロックする操作

Auto Modeのclassifierは、あなたの作業ディレクトリとリポジトリの設定済みリモートを信頼ベースラインとして扱い、それ以外は外部として評価します。公式が明示している既定ブロック対象は次の8カテゴリです。

• ダウンロードしたコードの実行（curl | bashなど）
• 外部エンドポイントへの機密データ送信
• 本番デプロイ・マイグレーション
• クラウドストレージの大量削除
• IAMやリポジトリ権限の付与
• 共有インフラの変更
• セッション開始前に存在したファイルの不可逆削除
• force push、またはmainへの直接push

逆に既定で許可されるのは、作業ディレクトリ内のローカルファイル操作、lockファイル/manifestで宣言された依存のインストール、.env読み取りと対応するAPIへの認証情報送信、読み取り専用HTTPリクエスト、セッション開始時のブランチかClaudeが作ったブランチへのpush、です。

つまり「自分のリポジトリでローカル開発する範囲は許可、本番/共有/不可逆/外部送信は止める」というのが既定ポリシーです。組織のインフラを信頼ベースラインに加えたい場合は管理者がautoMode.environment設定で追加できます。

ルール全文はCLIから確認できます。

「会話で宣言する境界」は強力だが永続しない

公式仕様で面白いのが、conversation内で利用者が宣言した境界もclassifierがブロックシグナルとして扱う点です。「pushしないで」「私のレビューが終わるまでデプロイしないで」と言えば、既定では許可されるブランチへのpushも止まります。境界は後続メッセージで明示的に解除するまで効いており、Claude自身が「条件を満たした」と判断しても自動で解除されません。

ただし、ここには重要な注意があります。境界はルールとして保存されず、毎回トランスクリプトから再読されるため、コンテキスト圧縮で境界宣言メッセージが消えると失われます。長セッションや/compactを多用する作業では、ハードな保証が必要ならdenyルールとしてpermissions.denyに書いておくのが正解です。

会話境界は便利ですが、「セッションをまたぐ恒久ルール」ではないと割り切ると事故が減ります。

classifierの判断プロセスと「広い許可ルールの自動失効」

classifierは固定の判断順序で評価します。最初に一致したステップが勝つ仕組みです。

1. allow/denyルールに一致するアクションは即時解決
2. 読み取りと作業ディレクトリ内のファイル編集（protected pathsを除く）は自動承認
3. それ以外はclassifierに渡される
4. classifierがブロックした場合、Claudeは理由を受け取り別案を試す

特筆すべきは、Auto Mode開始時に「広すぎる許可ルール」が自動的に外されることです。具体的には次のルールが対象になります。

• Bash(*)やPowerShell(*)の全許可ワイルドカード
• Bash(python*)のようなワイルドカード付きインタプリタ
• パッケージマネージャのrunコマンド
• Agentの許可ルール

Bash(npm test)のような狭いルールは引き継がれます。外されたルールはAuto Modeを抜けると復元されます。これは「Auto Modeに入った瞬間、安全に作業できる最小限の状態にリセットされる」設計と読み取れます。

classifierは利用者メッセージ・ツール呼び出し・CLAUDE.mdの中身を見ます。ツール結果は剥がされているので、ファイルやWebページ内の敵対的コンテンツがclassifierを直接操作することはできません。これとは別にサーバー側プローブがツール結果をスキャンして危険なコンテンツをClaudeが読む前にフラグ付けします。

サブエージェントへの3点チェック

サブエージェントもAuto Modeの保護対象です。classifierは3つのタイミングでチェックします。

1. 起動前: 委譲されるタスク内容が評価され、危険な依頼はspawnでブロックされる
2. 実行中: サブエージェントの各アクションが親と同じclassifierルールで評価される。サブエージェントfrontmatterのpermissionModeは無視される
3. 完了時: サブエージェントの全アクション履歴が再レビューされ、懸念があればセキュリティ警告を結果に前置きする

重要なのは「サブエージェント定義側でpermissionMode: bypassPermissionsを書いてもAuto Mode下では効かない」という点です。Auto Modeで安全性を担保する以上、サブエージェントだけ抜け穴を開けることはできない設計です。

フォールバック挙動：ブロックが続くと自動でAuto Modeを抜ける

Auto Modeのフォールバックには明確な閾値があります。

これらの閾値は設定不可です。非対話モード（claude -p）では「承認できる人」がいないため、繰り返しブロックはセッションをabortさせます。

ブロックされたアクションは/permissionsの「Recently denied」タブに並び、rキーで手動承認付きリトライが可能です。繰り返しブロックは「classifierがあなたのインフラ知識を持っていない」サインで、/feedbackで誤検知を報告するか、管理者に信頼インフラ追加を依頼するのが正攻法です。

コストとレイテンシの実態

classifierは/model選択とは独立したサーバー側設定モデルで動きます。/modelを切り替えても利用可否は変わりません。classifier呼び出しはトークン使用量にカウントされます。各チェックでトランスクリプトの一部と保留中アクションが送信されるため、実行前にラウンドトリップが追加されます。

ただしオーバーヘッドは均等ではなく、読み取りと作業ディレクトリ内編集（protected paths除く）はclassifierをスキップするため、コストはシェルコマンドとネットワーク操作に集中します。普段から/costまたは/usageで確認しておくと、Auto Modeの追加負担を体感的に把握できます。

組織での運用：managed settings

エンタープライズでAuto Modeを禁止したい場合、管理者はmanaged settingsに次のキーを置きます。

{
  "permissions": {
    "disableAutoMode": "disable"
  }
}

逆にTeam/Enterpriseで利用解禁する場合は管理者がClaude Code admin settingsから有効化する必要があります。bypassPermissionsを禁止したい場合はpermissions.disableBypassPermissionsMode: "disable"もセットで設定するのが定石です。

チーム導入ルールを整える際は、「Auto Modeを使う場面」「使わない場面」をプレイブックとして明文化し、機密リポジトリではdenyルールで多重防御するのが安全運用の基本です。

Auto Modeを使うかどうかのチェックリスト

最後に、Auto Modeに切り替える前の判断チェックリストを置いておきます。

• このセッションは「機密領域に触らない繰り返しタスク」か？（テスト追加、コードリファクタなど）
• 作業ディレクトリのリポジトリリモートは正しく設定されているか？（classifierの信頼ベースライン）
• 機密ファイル（.env、~/.aws/、~/.ssh/）への読み取りを止めたいなら、Read denyルールを設定したか？
• 本番デプロイのような操作を「念のため」で禁止したいなら、denyルールに書いたか？（会話境界はセッション圧縮で失われる）
• 累計20回・連続3回ブロックで自動的に抜ける挙動を理解しているか？
• 非対話モード（-p）で使う場合、ブロック繰り返しでセッションがabortすることを理解しているか？
• 機密操作については、Auto ModeではなくPlan Mode＋手動承認のほうが適切ではないか？

Auto Modeは「全自動」と「手動承認」の中間ですが、**「中間だからこそ何が自動承認されたか把握しにくい」**性質を持ちます。最初の数セッションは、/permissionsの「Recently denied」タブと/usageを頻繁に確認しながら、自分のワークフローでどこが詰まりやすいかを掴むのがおすすめです。

次に読むなら、安全な計画運用の基本であるPlan Mode依頼テンプレ、Auto Modeと組み合わせて使うセキュリティ横断チェックリスト、機密情報を渡さない3層防御が直接効きます。

Source Claude Code Documentation

Choose a permission mode

Control whether Claude asks before editing files or running commands. Cycle modes with Shift+Tab in the CLI or use the mode selector in VS Code, Desktop, and claude.ai.