Claude Code Auto Mode とは？全プランでデフォルト化・2層防御の仕組み・設定方法を徹底解説【2026年10月版】

Claude Code の Auto Mode（オートモード）は、毎回の承認プロンプトを人間の代わりに別のAIモデル（分類器）が実行直前に審査する権限モードです。2026年8月14日に Pro / Max / Team で既定になり、9月下旬（v2.1.283〜284）からは全プラン・全プロバイダの対話セッションで、権限モードを設定していなければ Auto Mode で始まります。

承認をスキップする機能ではありません。--dangerously-skip-permissions（bypassPermissions）は審査そのものを無くしますが、Auto Mode は審査の担い手を人間からモデルに替えます。この違いを押さえないと、いまの Claude Code の挙動を読み違えます。

この記事では、次の内容を扱います。

• Auto Mode が Max（2026年4月）→ Pro（5月）→ Pro/Max/Team の既定（8月）→ 全プランの既定（9月下旬）と広がった経緯
• 自分の環境が Auto Mode で始まるかどうかの判定（-p・Agent SDK・HIPAA 構成など例外込み）
• 入力層のプロンプトインジェクション検出と、出力層の2段分類器という2層防御の中身
• 既定でブロックされる操作・許可される操作（v2.1.312時点）
• 89% / 13.6% / 17% / 81% などの数字が、それぞれ何を測った値か
• /auto-mode-setup など10月までに増えた設定コマンドと、従来の承認モードに戻す方法

次のような人に向けた記事です。

• 「最近 Claude Code が承認を聞いてこない」理由と、その安全性を確かめたい開発者
• 組織として Auto Mode を許可するか止めるかを決めるテックリード・SRE・情報システム担当
• 「AIが承認を代行する」ことのリスクを社内に説明するセキュリティ責任者

Claude Code そのものの機能や料金から確認したい場合は、Claude Code とは？機能・料金・使い方を徹底解説 を先に読むと理解が早くなります。

Claude Code Auto Mode とは：承認判断を分類器モデルに委ねる権限モード

出典: Anthropic Engineering — Claude Code auto mode

Auto Mode は、Claude が定型的な承認プロンプトなしで作業を進められるようにしつつ、実行前の審査を別の分類器モデルに任せる権限モードです。公式ドキュメント（Permission modes）によると、分類器は「依頼の範囲を超える操作」「見知らぬインフラを対象にする操作」「Claude が読んだ敵対的コンテンツに誘導されたように見える操作」をブロックします。明示的な ask ルールに一致する操作は、Auto Mode でも必ずプロンプトが出ます。

「全部聞く（default）」と「何も聞かない（bypassPermissions）」の中間というより、判断する主体を人間からモデルに移した別の設計と捉えるのが正確です。

対応モデルには条件がある

Auto Mode はどのモデルでも動くわけではありません。公式ドキュメントでは、接続先ごとに対応モデルが分かれています。

審査を担う分類器は既定で Sonnet 5 です。セッションのモデルが Sonnet 4.6 の場合は Sonnet 4.6 が使われます。v2.1.302 からは環境変数 CLAUDE_CODE_AUTO_MODE_MODEL でローカル分類器のモデルを変えられますが、サーバー側分類器には効きません。

なお、2026年3月の Engineering ブログは分類器を Sonnet 4.6 として説明していました。ブログ由来の評価数値は「初出時点の設計で測った値」として読む必要があります。分類器モデルの性格は Claude Sonnet 5とは も参考になります。

Pro / Max 展開から全プラン既定化まで：経緯といまの挙動

出典: Claude 公式 — Auto mode is now the default in Claude Code

いまの Claude Code（v2.1.284以降）は、対話セッションで権限モードを指定していなければ、プランや接続先を問わず Auto Mode で起動します。 8月14日の既定化は Pro / Max / Team が対象でしたが、9月下旬に全プラン・全プロバイダへ広がりました。

提供の経緯

公式の changelog と発表記事で確認できた流れは次のとおりです。

Pro / Max への展開は「使えるようになった」段階で、8月以降の「既定になった」とは別の話です。利用可否と既定化を分けて読むと混乱しません。

自分の環境は Auto Mode で始まるか

開始モードは起動のしかたとバージョンで決まります。

迷ったら、起動直後の表示か Shift+Tab で切り替わるモード表示を見るのが確実です。

Enterprise は「ドキュメント」と「公式記事」で書き方が違う

ここは公式内でも表記が揃っていません。Permission modes ドキュメントは、v2.1.283〜284 以降は全プラン・全プロバイダの対話セッションで auto が開始モードだと書いています。一方、10月22日に追記された公式記事は「Enterprise の管理者には、組織で auto が既定になる前にメールで知らせる」としています。

後者は CLI ではなく、デスクトップや Web などの Claude アプリ側の展開を指していると読むのが自然ですが、どのアプリが対象かは明記されていません。社内アナウンスでは「CLI / VS Code はバージョンで決まる」「Claude アプリ側は Pro / Max / Team から順次、Enterprise は管理者への通知後」と分けて書くのが安全です。

分類器の課金はほぼ発生しなくなった

Pro / Max / Team は8月7日から分類器のオーバーヘッドを課金していません。Enterprise / API / クラウド経由も、v2.1.278 以降はサーバー側分類器が既定になりました。サーバー側ではモデルリクエストの一部として審査するため、別個の分類器呼び出しが発生せず、その分の課金もありません。

例外は、サーバー側分類器が使えずローカル分類器にフォールバックした場合と、CLAUDE_CODE_AUTO_MODE_SERVER=0 で無効化した場合です。このときは分類器の呼び出しがトークン使用量に数えられ、VS Code / JetBrains では続行するかの確認が出ます。どちらで動いているかは /status の「Auto mode server」行で確認できます。

Auto Mode 自体に追加料金はなく、Claude Code が使えるプランに含まれます。

料金は改定が多いため、契約前に Claude 公式の料金ページ で確認してください。プラン別の使い分けは Claude Code の料金プラン、トークン消費の抑え方は Claude Code コスト最適化完全ガイド にまとめています。

仕組み：入力層プローブ × 出力層分類器の2層防御

Auto Mode の中核は、危険を入口と出口の2か所で捕まえる構造です。片方をすり抜けても、もう片方で止まる余地を残しています。

入力層：サーバー側のプロンプトインジェクション・プローブ

ツールの実行結果が Claude のコンテキストに入る前に、サーバー側の検出器がスキャンします。インジェクションらしき内容を見つけると、コンテキストに警告を足し、その内容を疑ってかかり本来のユーザー意図に立ち返るよう Claude に指示します。完全に遮断するのではなく、「疑わしいと知らせた上で読ませる」処理です。

出力層：トランスクリプト分類器（2段構成）

各ツール呼び出しの実行前に、別のモデルが安全性を評価します。速度とコストを両立させるため2段に分かれています。

2026年9月からは、対応環境でサーバー側分類器が既定です。審査はモデルリクエストの一部としてサーバー側で行われ、判定が返らない操作は拒否されます。判定なしが10回続くとそのターンは止まります。

分類器にかかる操作・かからない操作

すべての操作が分類器を通るわけではありません。公式の設計では次のように分かれています。

• 分類器を通らない: 読み取り専用ツール（許可リスト）、プロジェクト内のファイル編集
• 分類器を通る: シェルコマンド、Web取得、プロジェクト外のファイル操作

プロジェクト内のファイル編集が審査対象外である点は、Auto Mode の限界を考えるうえで最も重要です。書かれたコードの中身（ロジックの誤りや仕込まれた処理）は分類器では止まりません。

分類器は Claude の言い分を見ない（reasoning-blind）

分類器が見るのはユーザーのメッセージとツール呼び出しだけです。Claude 自身の発言とツールの実行結果は取り除かれます。これで2つの攻撃経路を塞いでいます。

1. Claude が「これは安全です、なぜなら〜」と自分で書いた正当化で分類器を説得すること
2. ファイルや Web ページに仕込まれた敵対的コンテンツが、分類器を直接操作すること

その代わり、分類器はコマンドの出力を知りません。たとえば gh repo view の結果でリポジトリが public だと分かっても、分類器はその出力を根拠にできません。中身を確認できないシェル変数を使った rm -rf "$VAR" も、削除対象を検証できないためブロックされます。分からないものは止める方針です。

判定の優先順位は4段階

1. hard_deny：無条件ブロック。ユーザー意図でも allow でも解除できない
2. soft_deny：ブロック。ユーザー意図と allow で解除できる
3. allow：soft_deny の例外として上書きする
4. 明示的なユーザー意図：ユーザーのメッセージがその操作をはっきり述べていれば soft_deny を上書きする

「リポジトリを整理して」は force push の承認になりませんが、「このブランチを force push して」は承認になります。依頼が曖昧なほど、分類器は慎重に振る舞います。

信頼境界は作業ディレクトリとセッション開始時のリモートだけ

既定で信頼されるのは作業ディレクトリと、セッション開始時点で設定されていたリモートだけです。セッション中に git remote add や git remote set-url で足したリモートは信頼されません。社内ドメインやクラウドのバケットは、autoMode.environment に自然言語で書くまで分類器にとって「見知らぬインフラ」です。

サブエージェントとセッション間メッセージも審査対象

サブエージェントには、起動前（委任するタスク記述）・実行中（各アクション）・終了時（行動履歴全体と報告内容）の3か所でチェックが入ります。サブエージェント定義に permissionMode: bypassPermissions を書いても無視されるため、子エージェント経由で審査を抜けることはできません。設計と運用は Claude Code サブエージェント 使い方 で詳しく扱っています。

SendMessage で他のエージェントに送るメッセージも、配送前に分類器がレビューします。

権限モード6種のなかでの Auto Mode の位置づけ

Auto Mode は「承認なしで動く範囲」が最も広いモードの1つですが、審査がある点で bypassPermissions とはまったく違うモードです。6種類を並べると違いがはっきりします。

.git や .claude のような保護パスへの書き込みは、bypassPermissions 以外では自動承認されません。Auto Mode では allow ルールに一致していても分類器に回ります。

rm -rf / のようなクリティカルパスの削除は、Auto Mode でもターミナルでは確認が出ます（v2.1.281 以降は2分のカウントダウン付き）。ターミナル外では拒否されます。bypassPermissions にも同様のサーキットブレーカーは残っていますが、設計思想として「審査あり」と「審査なし」はまったく別です。権限モード全体の設計指針は Claude Codeのセキュリティと安全な使い方 で整理しています。

既定でブロックされる操作・許可される操作（v2.1.312時点）

Auto Mode には組み込みのブロックルールがあり、バージョンごとに追加されています。現行の一覧は claude auto-mode defaults で確認できます。ここでは実務で当たりやすいものを抜き出します。

既定でブロックされる主な操作

基本セット

• curl | bash のようなダウンロードと即時実行
• 機微データの外部への送信
• 本番デプロイ・本番マイグレーション
• クラウドストレージの大量削除、IAM / リポジトリ権限の付与、共有インフラの変更
• force push
• git reset --hard / git checkout -- . / git restore . / git clean -fd / git stash drop などの取り消せない git 操作
• terraform destroy / pulumi destroy / cdk destroy など、破棄を伴う IaC 操作
• 人間が承認していないPRのマージ、自分のPRの承認、CIチェックの無効化
• 生の認証情報をトランスクリプトやファイルに出すこと
• --dangerously-skip-permissions / --no-sandbox などによる自律エージェントループの起動

バージョンごとの追加分（抜粋）

既定で許可される主な操作

• 作業ディレクトリ内のローカルファイル操作
• lock ファイル / マニフェストに宣言済みの依存関係のインストール
• .env の読み取りと、その認証情報を対応するAPIへ送ること
• 読み取り専用の HTTP リクエスト
• 現在のリポジトリの任意ブランチへの push（デフォルトブランチを含む）
• セッション内で自分が作ったジョブの削除
• 同じマルチエージェントセッション内のメッセージ

誤解が残りやすい点：main への push は既定で通る

「Auto Mode は main への直接 push を止めてくれる」と書いた記事がまだありますが、作業中リポジトリのデフォルトブランチへの push は既定で許可されています。production や gh-pages のようにデプロイ先を示す名前のブランチは別扱いで、push の内容（シークレット混入など）は他のルールでチェックされます。

main を守りたいなら、分類器に期待するのではなく permissions.deny とリモート側のブランチ保護で止めるのが確実です。

数値の読み方：89% / 13.6% / 17% / 81% は何を測った数字か

Auto Mode の議論がややこしいのは、出所も測定対象も違う数値が混ぜて語られているからです。主な数字を並べて切り分けます。

「89%」の実験は何を示し、何を示していないか

Anthropic が既定化の根拠として最も強く打ち出したのは 89% vs 13.6% です。危険コマンドを1つ紛れ込ませたとき、分類器は89%止め、人間は13.6%しか止められなかった。承認疲れが実在することを示すデータとしては説得力があります。

一方で、この実験は「明らかに危険なコマンドを誰が捕まえるか」を測っており、実際のリポジトリでの操作の妥当性まで分類器が判断できるかを測ってはいません。Simon Willison は「89%というのは、11%が残るということだ」と指摘し、機微データやツールへのアクセス自体を絞ったエージェント設計を勧めています。

独立評価と突破報告が示した「分類器が見ていない経路」

公式評価だけでは、Auto Mode の弱点は見えにくいままです。2026年には、前提の違う外部の検証が2つ出ています。

AmPermBench：状態変更の36.8%が分類器の外を通る

論文「Measuring the Permission Gate: A Stress-Test Evaluation of Claude Code's Auto Mode」（arXiv:2604.04978、最新版 v3 は2026年10月22日）は、4種類の DevOps タスク（ブランチ整理・ジョブキャンセル・サービス再起動・成果物クリーンアップ）×128プロンプトで、あえて曖昧な指示を与えて Auto Mode を試しています。

この81%を「Auto Mode は81%見逃す」と読むのは誤りです。ワークロードは本番の使われ方とは違い、認可境界をわざと狙った曖昧なシナリオで組まれています。Anthropic の17%は通常の作業で偶発的に起きたやりすぎを測った値で、直接は比べられません。初版は2026年4月公開で、評価したモデルや分類器の構成も現在の既定（Sonnet 5 の分類器、サーバー側分類器）とは異なる可能性があります。

実務で価値があるのは、状態変更の36.8%がプロジェクト内のファイル編集という経路を通り、そもそも分類器の判定対象になっていないという構造の指摘です。想定していた CLI が使えないと、エージェントはファイル編集で目的を果たそうとします。ガードのある経路を塞ぐと、ガードのない経路に流れるわけです。

Auto Mode は「シェルコマンドと外向き操作の門番」であって、「書かれたコードの中身の門番」ではない。

Auto Mode を入れてもコードレビューは減らせません。AIが書いたコードに固有のリスクは AIコーディングのセキュリティリスクと対策、エージェントが破壊的操作をした実例は AIエージェントがデータを全削除した事故まとめ で扱っています。

Opus 5 の Auto Mode でインジェクション連鎖が成功した報告

2026年8月26日、セキュリティ研究者の Johann Rehberger 氏が、Opus 5 の Auto Mode で「この Web ページを要約して」という依頼から、細工したサイトとアーカイブ経由で攻撃者のコードを実行させる連鎖を公開しました。本人の小規模検証での成功率は60〜80%で、独立した再現は確認できていません。

Anthropic 委託評価の「720回中0件」と食い違って見えますが、条件が違う検証です。Cloud Security Alliance のリサーチノートは、どちらの結果も「Auto Mode がインジェクションに耐える一般的な確率」を示すものではないとし、信頼できないサイトやリポジトリを扱うならサンドボックスと監視を併用するよう勧めています。経緯と攻撃の流れは Claude Code Auto Mode が間接プロンプトインジェクションで突破された件 で詳しく整理しています。

セッション間メッセージング × Auto Mode：見落とされている組み合わせ

Auto Mode のセッションは、他の Claude Code セッションからのメッセージを既定でそのまま受け取ります。全プランで Auto Mode が既定になったいま、人の承認を挟まずにセッション同士が横につながる状態が標準になっています。

セッション間メッセージングは、別ターミナルで動く Claude Code セッション同士が ListAgents / SendMessage でやり取りする機能（v2.1.224 で追加）です。送られるのはプレーンテキストの要約だけで、会話履歴やファイルは渡りません。

権限モードが「配送するか保留するか」を決める

crossSessionInbound を設定していない場合、Claude Code はセッションを2つに分けます。

Auto Mode は「プロンプトを出す側」に入るため、メッセージは止まりません。

受信メッセージにできないこと

• 承認の代理はできない（保留中の権限プロンプトに答えられない）
• 権限設定や CLAUDE.md を「他セッションに言われたから」変更しない
• /compact などのコマンドはプレーンテキストとして届くだけ
• 自分のセッションで拒否された作業を他セッションに頼まない

SendMessage の内容は配送前に分類器がレビューします。

組織として止めたい場合

機能の詳細は Claude Codeのセッション間メッセージ機能とは、複数エージェントを束ねる設計は Claude Code Agent Teamsの使い方 で扱っています。

今すぐ確認したい設定チェック6項目

すでに既定で Auto Mode が動いている前提で、受け入れるにせよ止めるにせよ確認しておきたい項目です。

① /auto-mode-setup で信頼境界の下書きを作る

v2.1.304（10月19日）で追加された /auto-mode-setup は、プロジェクトと最近のセッションを読んで autoMode.environment の下書きを作り、~/.claude/settings.json に保存します。自社の内部ドメインやバケットを分類器に教える最短の方法です。

② 実効設定を出力して現状を把握する

③ 広すぎる allow ルールを見直す

Bash(*) やインタプリタ全許可のような広い allow ルールは、Auto Mode 中は自動で無効化されます。注意が要るのは狭い allow ルールのほうで、分類器より先に解決されるため、想定外の引数を分類器に通さないまま許可してしまうことがあります。

全シェルコマンドを分類器に見せたいなら autoMode.classifyAllShell: true を設定します。Auto Mode 中は Bash / PowerShell の allow ルールがすべて止まり、すべてのシェルコマンドが分類器に回ります。

④ autoMode.environment に信頼境界を書く

environment は正規表現ではなく、自然言語で信頼するインフラを書く欄です。既定では信頼リポジトリとソース管理以外の項目（社内ドメイン、クラウドバケット、社内パッケージレジストリなど）は空です。何も書かなければ、分類器は自社の内部インフラを知らないまま判断しています。誤ブロックが多い環境ほど、ここを書く効果が大きくなります。

⑤ 最大の落とし穴："$defaults" の書き忘れ

environment / allow / soft_deny / hard_deny のいずれかを "$defaults" なしで設定すると、そのセクションの組み込みルールが丸ごと消えます。

• soft_deny を上書きすると、force push、curl | bash、本番デプロイなどの組み込みブロックが全部消える
• hard_deny を上書きすると、組み込みのデータ持ち出しルールが消える

ルールを1つ足したかっただけで組み込みのガードがすべて消えるので、独自ルールには必ず "$defaults" を含めます。

⑥ 硬い境界は permissions.deny に書く

開発者は個人設定で allow を追加でき、allow は soft_deny の例外として働きます。つまり開発者が足した allow は、組織が書いた autoMode.soft_deny を上書きできてしまいます。絶対に通したくない操作は managed settings の permissions.deny に書きます。

Bash(git push *) のような ask ルールは git -C <dir> push などの書き方に一致しないことがあります。コマンド全文を検査したいなら PreToolUse フックを使います。フックの書き方は Claude Code Hooks 使い方 で解説しています。

設定の読み取り範囲にも注意が要ります。分類器が autoMode を読むのは ~/.claude/settings.json、managed settings、--settings フラグ / Agent SDK のインラインJSONだけです。.claude/settings.json と .claude/settings.local.json からは読みません。プロジェクト設定に defaultMode: "auto" を書いても効きません。リポジトリ経由で権限を注入されないための仕様です。

組織への展開手順は Claude Code チーム導入ガイド にまとめています。なお、Auto Mode で社内ツールの試作が速く作れるようになっても、それを社内の実データや既存システムにつないで業務で使う段階では、権限の切り分け・レビュー体制・運用保守の担当を別に決める必要があります。その段階で何が必要になるかは バイブコーディング・Lovableで作ったアプリを本番運用するには で整理しています。

Auto Mode を使わない・元に戻す方法

既定が Auto Mode になっても、従来の承認モードに戻すことはいつでもできます。

規制業界や監査対応のある組織では、もう1つ論点があります。「モデルが承認した」という記録は、「誰が承認したか」の監査証跡にはなりません。変更管理で人間の承認記録が必須なら、Auto Mode はその要件を満たさない可能性があります。組織で使う場合は、OpenTelemetry の tool_decision イベント（classifier_verdict / permission_mode など）や、v2.1.307 で追加された claude_code.safety_event を監査ログに取り込むことも検討してください。

フォールバック挙動と運用の落とし穴

分類器がブロックしてもセッションは止まらない

分類器がブロックすると、Claude は拒否理由を受け取って別の安全な方法を探し、セッションは続きます。通知が出て、/permissions の「Recently denied」タブに記録が残り、r キーで手動承認付きの再試行ができます。

ただし、3回連続または累計20回ブロックされると Auto Mode は一時停止し、通常の承認プロンプトに戻ります。この回数は変更できません。-p ではブロックされた操作は実行されず、Claude は作業を続けます。

会話で伝えた境界は会話の圧縮で消える

「レビューまで push しないで」と会話で伝えると、分類器はそれをブロックの根拠にします。ただし境界はルールとして保存されず、分類器は毎回トランスクリプトから読み直します。会話履歴の圧縮（context compaction）で該当メッセージが消えると、境界も消えます。長いセッションほど踏みやすい落とし穴です。恒久的に守りたいなら permissions.deny / permissions.ask に書くよう、公式も勧めています。

8月以降に挙動が変わった主な点

「90%自律コーディング」は Anthropic の公式目標ではない

Auto Mode と一緒に語られる「90%自律コーディング目標」という表現について、Anthropic が Auto Mode でこれを目指すと公式に述べた一次情報は、2026年10月29日時点でも確認できていません。いくつかの別々の話が混ざって広まったものとみられます。

Auto Mode が減らすのは「人間が押す承認ボタンの回数」です。どれだけのコードを AI が書くかとは別の指標なので、社内説明では混同しないよう注意してください。

こんな人におすすめ／おすすめしない人

Auto Mode をそのまま使ってよいかは、動かす環境と、組織が人間の承認記録を必要とするかでほぼ決まります。

Auto Mode をそのまま使うのがおすすめの人

• 隔離環境で Claude Code を動かしている個人・チーム：影響範囲が限られるため、残る見逃しを受け止めやすい
• 承認プロンプトをほぼ惰性で押している開発者：公式データどおりなら、分類器に任せたほうが検知率は上がる
• 長い反復作業を任せたいテックリード・SRE：人間の検知率がセッションの長さとともに落ちる領域で、検知率が横ばいという分類器の特性が役に立つ
• permissions.deny と autoMode.environment を組織で整備できる企業：分類器の手前に絶対ブロックを置きつつ、誤ブロックも減らせる

Auto Mode を既定のままにしないほうがよい人

• 本番リポジトリと本番クラウド認証情報が同じホストにある人：見逃しがそのまま本番に届く
• 人間の承認記録が監査要件になっている組織：「モデルが承認した」は証跡にならない
• CI/CD パイプライン：dontAsk と静的な permissions.allow のほうが挙動が安定する
• Auto Mode をコードレビューの代わりと考えている組織：プロジェクト内のファイル編集は分類器の判定対象外
• 信頼できない Web ページやリポジトリを日常的に読ませる人：インジェクション突破の報告があり、サンドボックスとの併用が前提

よくある質問

Q1. 最近 Claude Code が承認を聞いてこなくなりました。設定が勝手に変わったのですか？

勝手に変わったのは設定ではなく既定値です。権限モードを指定していなければ、v2.1.283〜284（2026年9月下旬）以降の対話セッションは Auto Mode で起動します。従来どおり確認してほしい場合は ~/.claude/settings.json の permissions.defaultMode を "default" にすると固定できます。

Q2. Pro プランでも Auto Mode は使えますか？

使えます。Pro は2026年5月中旬に利用可能になり、8月14日からは既定モードの対象にも入りました。現在は Free を除く Claude Code の全プランで利用でき、既定でも Auto Mode です。

Q3. Enterprise や API キー利用でも Auto Mode が既定になっていますか？

CLI と VS Code の対話セッションについては、公式ドキュメント上 v2.1.283〜284 以降は全プラン・全プロバイダで既定です。一方で公式記事は、Claude アプリ側の既定化について Enterprise 管理者へ事前にメールで知らせるとしています。組織で止めたい場合は、managed settings の disableAutoMode を先に配布しておくのが確実です。

Q4. 分類器の分だけ料金や使用量が増えますか？

ほとんどの環境で増えません。Pro / Max / Team は8月7日から分類器分を課金しておらず、Enterprise / API / クラウド経由も9月19日以降は、別の呼び出しが発生しないサーバー側分類器が既定です。ローカル分類器にフォールバックしたときだけ使用量に数えられ、/status で確認できます。

Q5. --dangerously-skip-permissions と何が違うのですか？

bypassPermissions には審査そのものがありません。Auto Mode も承認プロンプトは出しませんが、各操作を分類器が実行前に審査し、危険と判断すればブロックします。ただし公式は「安全性を保証しない」と明記しています。

Q6. CI や claude -p でも Auto Mode になりますか？

既定ではなりません。-p と Agent SDK は default で始まり、Auto Mode を使うには --permission-mode auto を指定します。人が承認できない環境では、dontAsk と事前の allow ルールで動かすほうが予測しやすくなります。GitHub での使い方は Claude Code GitHub Actions 使い方 を参考にしてください。

Q7. 誤ブロックが多いのですが、どう減らせばよいですか？

/auto-mode-setup で autoMode.environment の下書きを作り、社内ドメイン・バケット・パッケージレジストリなどを書き足します。そのあと claude auto-mode config で実効設定を確認し、claude auto-mode critique で記述の曖昧さをチェックします。

Q8. Auto Mode を使えばコードレビューを減らせますか？

減らせません。プロジェクト内のファイル編集は分類器を通らないため、書かれたコードの誤りや仕込まれた処理は審査されません。独立研究では、状態変更の36.8%がこの経路を通っていました。

Q9. 組織として Auto Mode を全面的に止められますか？

止められます。managed settings で permissions.disableAutoMode: "disable" を配布すると、Shift+Tab の候補から auto が消え、v2.1.251 以降は実行中のセッションにも反映されます。セッション間メッセージも止めたい場合は permissions.deny: ["SendMessage","ListAgents"] を併用します。

まとめ

Claude Code の Auto Mode は、承認の判断を人間から分類器モデルに移す権限モードです。Max（4月）、Pro（5月）と利用範囲が広がり、8月14日に Pro / Max / Team で既定化、9月下旬からは全プラン・全プロバイダの対話セッションで既定になりました。

• いまの既定は Auto Mode。-p・Agent SDK・HIPAA 構成・disableAutoMode 配布環境は default で始まる
• 仕組みは2層防御。入力層でインジェクションを検出し、出力層の2段分類器が実行前に審査する。分類器は Claude の発言とツール結果を見ない
• 分類器の課金はほぼなくなった。9月以降はサーバー側分類器が既定
• 数値は出所で読み分ける。89%は危険コマンド混入実験、17%は実際のやりすぎ52件、81%は認可境界を狙ったストレステストで、直接は比べられない
• ファイル編集は審査されない。コードレビュー・テスト・CIは引き続き必要
• 設定の事故で多いのは "$defaults" の書き忘れ。硬い境界は permissions.deny に書く
• 「90%自律コーディング」は公式目標ではない

Claude Code 全体の機能は Claude Code とは、安全な運用設計は Claude Codeのセキュリティと安全な使い方、AIエージェント全般の権限設計は AIエージェントのセキュリティ対策 で個別に整理しています。

Auto Mode は承認疲れという実在の問題への現実的な答えですが、公式自身が安全を保証しないと明記している仕組みでもあります。隔離環境で動かし、permissions.deny で硬い境界を先に引き、分類器が見ていない部分はレビューとテストで押さえる。この3点をそろえて使うのが、2026年10月時点で最も無理のない運用です。