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

Claude Code の Auto Mode（オートモード）は、毎回の承認プロンプトを人間の代わりに別のAIモデル（分類器）が実行直前に審査する権限モードです。そして2026年8月14日から、Pro / Max / Team プランの新規セッションでこの Auto Mode が既定モードになります。

承認をスキップする機能ではありません。--dangerously-skip-permissions（bypassPermissions）が「審査そのものを無くす」のに対し、Auto Mode は「審査の担い手を人間からモデルに置き換える」設計です。この違いを押さえないと、8月14日以降の挙動を読み違えます。

この記事でわかること:

2026年8月14日に何が変わり、どのプラン・どの経路が対象外なのか（公式発表と報道の切り分け込み）
Auto Mode の中身：入力層のプロンプトインジェクション検出と、出力層の2段分類器という2層防御
既定でブロックされる操作・許可される操作の最新一覧（v2.1.227時点）
89% / 13.6% / 17% / 81% といった数字がそれぞれ「何を測った値か」の読み分け
香港科技大学らの独立評価が指摘した「分類器が見ていない経路」
セッション間メッセージング（v2.1.224追加）と権限モードの意外な関係
8月14日までにやるべき設定チェックと、従来の承認モードに戻す方法

誰向けの記事か:

8月14日以降、自分の Claude Code の挙動がどう変わるか確認したい開発者
チーム・組織として Auto Mode を許可するか、止めるかを判断するテックリード / SRE / 情報システム担当
「AIが承認を代行する」ことのリスクを社内に説明する必要があるセキュリティ責任者
Auto Mode を有効にしたまま、事故を起こさない設定を組みたい実務者

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

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

Anthropic 公式エンジニアリングブログの Claude Code Auto Mode 解説イメージ

出典: Anthropic Engineering — Claude Code auto mode

公式ドキュメント（Permission modes）は Auto Mode をこう定義しています。要約すると「Claude が定型的な承認プロンプトなしで実行できるようにする。ただし別の分類器モデルが実行前に各アクションを審査し、依頼の範囲を超えるもの・見知らぬインフラを対象にするもの・Claude が読み込んだ敵対的コンテンツに誘導されたと見えるものをブロックする」。明示的な ask ルールに該当する操作は、Auto Mode でも必ずプロンプトが出ます。

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

項目	内容（2026年8月12日時点）
提供元	Anthropic
初出	2026年3月下旬（v2.1.83〜85）にリサーチプレビューとして公開
提供形態	Claude Code の権限モードの1つ（CLI / VS Code 拡張 / JetBrains / デスクトップ / Claude Code on the web）
利用できるプラン	公式ドキュメント上は全プラン（"Plan: All plans."）。Pro でも利用可
利用できるプロバイダ	Anthropic API / Claude Platform on AWS / Amazon Bedrock / Google Cloud's Agent Platform / Microsoft Foundry / Claude apps gateway
2026年8月14日からの変更	Pro / Max / Team の新規セッションで既定モードになる
Enterprise / API / クラウド経由	現時点ではオプトインのまま。公式は「今後1か月以内にパートナーと協働して既定化する方針」
審査するモデル	既定で Claude Sonnet 5（セッションの `/model` 選択とは独立）
分類器の課金	Pro / Max / Team は2026年8月7日付で無償化。Enterprise / API / クラウド経由はトークン使用量に計上
公式の但し書き	「Auto mode は承認プロンプトを減らすが、安全性を保証するものではない」
記事執筆時点の最新版	v2.1.227（2026年8月10日）

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

Auto Mode はどのモデルでも動くわけではありません。公式ドキュメントの記載は経路によって異なります。

Anthropic API / Claude Platform on AWS: Claude Opus 4.6 以降、Sonnet 4.6 以降、または Fable 5
Amazon Bedrock / Google Cloud's Agent Platform / Microsoft Foundry / Claude apps gateway: Claude Sonnet 5、Opus 4.7 以降、Fable 5 のみ
Sonnet 4.5 / Opus 4.5 / Haiku / claude-3 系はどの経路でも非対応

審査を担う分類器は既定で Sonnet 5 です。セッションのモデルが Sonnet 4.6 の場合や、availableModels が Sonnet 5 を除外している場合はセッションのモデルが使われ、Fable 5 セッションでは Opus 系にフォールバックします。セッション最初の Auto Mode リクエストで可用性を検証したあとは、そのセッション中に分類器モデルが変わることはありません。

なお Anthropic の初出時点のエンジニアリングブログでは分類器を Sonnet 4.6 と説明していました。現行の公式ドキュメントは Sonnet 5 が既定です。ブログ由来の評価数値を引用するときは「初出時点の設計での測定値」として読む必要があります。分類器を担うモデルの性格については Claude Sonnet 5とはも参考になります。

2026年8月14日、あなたの環境で何が起きるか

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

何もしなければ Pro / Max / Team ユーザーの新規セッションは 8月14日から Auto Mode で立ち上がります。既存の設定を持っている人、組織管理下の人、Enterprise / API 経由の人はそれぞれ扱いが違います。

あなたの状況	8月14日以降の挙動	やるべきこと
Pro / Max / Team で既定モードを固定していない	新規セッションが Auto Mode で起動。製品内に告知が表示される	変えたくなければモードを明示的に固定する
自分で `permissions.defaultMode` を固定済み	変化なし。ただし「Auto mode に切り替えますか」という1回限りの案内が出る場合がある	承諾しなければ従来どおり
Team メンバーで、管理者が managed settings で既定モードを指定済み	変化なし（組織設定が優先される）	対応不要
Enterprise / Claude API / Claude Platform on AWS / Amazon Bedrock / Google Cloud's Agent Platform / Microsoft Foundry	オプトインのまま。8月14日に既定化されない	既定化される前に社内ポリシーと managed settings を確定しておく
新規ユーザー	自動的に Auto Mode	—

分類器のトークン課金は Pro / Max / Team で無償化された

公式ブログは「分類器はツール呼び出しごとに少量の追加トークンを使うが、Pro・Max・Team の Claude Code ユーザーに対しては本日付でその分類器オーバーヘッドを課金しない」と明記しました。裏を返すと、Enterprise / API / クラウド経由では分類器分のトークンが引き続き使用量にカウントされます。API 従量課金でチーム運用している場合、Auto Mode の常用はコスト側にも影響します。トークン消費の抑え方は Claude Code コスト最適化完全ガイドにまとめています。

Enterprise / API の既定化時期は「公式表現」と「報道」を分けて読む

公式が言っているのは「今後1か月以内にパートナーと協働して既定化する予定」までで、具体的な日付は公表されていません。国内メディアでは GIGAZINE が「2026年9月以降」と書いていますが、これは報道側の解釈です。社内アナウンスを作る場合は、公式表現（時期未定・1か月以内目標）で書いておくほうが安全です。

日本語圏では2026年8月9日の ITmedia AI+、8月10日の GIGAZINE / gihyo.jp、PC Watch などが一斉に報じ、英語圏では TechCrunch・InfoWorld・The Register・The New Stack が取り上げました。The New Stack は「人間が信用できないから Auto mode が既定になる」という見出しを付けており、この変更が単なる利便性向上ではなく「人間の承認は機能していない」という主張とセットである点が各紙の共通した論点になっています。

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

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

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

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

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

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

ステージ	動作	特性
Stage 1	推論なし・1トークンの yes/no 判定	ブロック寄りにチューニング。まず広く拾う
Stage 2	Stage 1 が引っかけたケースのみ、chain-of-thought で再評価	偽陽性（誤ブロック）を削る役割

設計上の要：分類器は Claude の言い分を見ない（reasoning-blind）

Auto Mode でもっとも重要な設計判断がこれです。分類器が見るのは、ユーザーのメッセージ・生のツール呼び出し・CLAUDE.md の内容だけ。Claude 自身の発言とツール実行結果は取り除かれます。

この構造によって、次の2つの攻撃経路が塞がれます。

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

一方で「分類器はコマンドの実行結果を知らない」という制約も生みます。たとえば会話中で中身が確認できないシェル変数を使った rm -rf "$VAR" は、削除対象を検証できないためブロックされます（v2.1.205以降）。推測して通すのではなく、分からないものは止める方針です。

分類器プロンプトは4段階の優先順位で判定する

hard_deny — 無条件ブロック。ユーザー意図でも allow でも解除できない
soft_deny — ブロック。ユーザー意図と allow で解除できる
allow — soft_deny の例外として上書きする
明示的なユーザー意図 — ユーザーのメッセージが「まさにその操作」を具体的に述べていれば soft_deny を上書きする

4つ目の粒度感が実務では効きます。「リポジトリを整理して」は force push の承認になりませんが、「このブランチを force push して」は承認になります。曖昧な依頼ほど分類器は保守的に振る舞います。

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

分類器プロンプトには「Environment（環境定義）」という枠があり、何を信頼するかを定義します。既定では作業ディレクトリと、セッション開始時点で設定されていたリモートのみが信頼対象です。セッション中に git remote add や git remote set-url で追加・変更されたリモートは信頼されません（v2.1.200以降）。「途中で送り先をすり替える」攻撃への対策です。

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

サブエージェント（子エージェント）には3か所でチェックが入ります。

タイミング	何を見るか
起動前	委任するタスク記述そのものを審査（v2.1.178以降）
実行中	各アクションを親セッションと同じルールで審査。サブエージェント定義の `permissionMode` は無視される
終了時	行動履歴全体をレビューし、懸念があれば結果の先頭にセキュリティ警告を付ける

「子エージェントに bypassPermissions を書けば抜けられる」という回避策は成立しません。サブエージェントの設計と運用は Claude Code サブエージェント使い方に詳しくまとめています。

さらに v2.1.222 以降は、SendMessage で他エージェントに送るメッセージも、配送される前に分類器がレビューします。Auto Mode と、分類器がコマンドを審査する plan モードの両方で作動します。

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

Auto Mode を正しく使うには、隣接するモードとの違いを押さえるのが近道です。

モード	承認なしで実行されるもの	向く場面
`default`（CLI表示は Manual。`manual` エイリアスは v2.1.200以降）	読み取りのみ	導入直後・機微な作業
`acceptEdits`	読み取り＋ファイル編集＋一般的なファイル操作コマンド（`mkdir` `touch` `mv` `cp` `rm` `rmdir` `sed`）	自分でレビューしながら反復する作業
`plan`	読み取り＋（Auto Mode が使える環境では）分類器が承認したコマンド	変更前のコードベース探索
`auto`（Auto Mode）	分類器が承認したすべてのアクション	方向性を信頼できるタスク・長時間の作業
`dontAsk`	事前承認済みツールのみ。`ask` ルール該当は「プロンプト」ではなく「拒否」。`AskUserQuestion` も拒否	決定論的な自動化・CI
`bypassPermissions`	ほぼすべて。審査なし。保護パスへの書き込みも通る	隔離コンテナ / VM 限定

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

bypassPermissions にもわずかな安全弁は残っています。rm -rf / や rm -rf ~ のようなファイルシステムルート／ホームディレクトリを狙う削除にはサーキットブレーカーとしてプロンプトが出ますし（コマンド置換・プロセス置換の中にある形も v2.1.208 以降が対象）、明示的な ask ルール、組織が ask に設定したコネクタツール、requiresUserInteraction の MCP ツールもプロンプトが出ます。とはいえ設計思想としては「審査あり」の Auto Mode と「審査なし」の bypass はまったく別物です。権限モード全体の設計指針は Claude Codeのセキュリティと安全な使い方で整理しています。

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

Auto Mode には約20カテゴリの組み込みブロックルールがあり、バージョンごとに追加されています。ここでは実務で当たりやすいものを整理します。

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

基本セット

curl | bash のようなダウンロード＆即時実行
機微データの外部エンドポイントへの送信
本番デプロイ・本番マイグレーション
クラウドストレージの大量削除
IAM / リポジトリ権限の付与
共有インフラの変更
セッション開始前から存在するファイルの不可逆な破壊
force push
git reset --hard / git checkout -- . / git restore . / git clean -fd / git stash drop / git stash clear
git commit --amend（HEAD のコミットがこのセッション由来でない場合、または push 済みの場合）
terraform destroy / pulumi destroy / cdk destroy / terragrunt destroy と、破棄を伴う plan の apply

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

追加時期	追加されたブロック対象
v2.1.195以降	シークレットマネージャへの書き込み、DNS / TLS 変更、未承認PRのマージ・自分のPRの承認・CIチェック無効化、`atlantis apply` のような bot コマンドコメント、本番フィーチャーフラグ操作、保護 IaC スコープへの適用、クラスタノードの drain / 削除、共有計算クラスタでの `--all` 等の広域指定、公開インターネットへのトンネル / リバースシェル、ライブ認証情報のファイル出力、`--insecure` 等の安全ガード無効化フラグ、`--dangerously-skip-permissions` / `--no-sandbox` / `--yes-always` による自律エージェントループの起動
v2.1.198以降	`/tmp` や `$TMPDIR` のワイルドカード・経過時間指定での削除、PR本文・issue本文・コミットメッセージへの未承認の機微情報混入、Claude Code 自身の tmux ペインへのキーストローク送信（自分の監督体制を書き換える行為とみなされる）
v2.1.200以降	セキュリティ動作を守るテスト／アサーションのコメントアウト・削除、セッション内で作っていないステートフルリソースの削除、API ベースURL / プロキシ / webhook / レジストリミラーの第三者ホストへの付け替え（`.env.example` 内でも）、`git remote set-url` / `git remote add` による push 先変更、public リポジトリへのシークレット push、別リポジトリ・別組織へのPR作成や `gh repo fork`
v2.1.203以降	セッショントランスクリプト、SSH鍵・クラウド認証情報・ブラウザプロファイル・シェル履歴などのドットフォルダ由来の内容が、コミット・push・PR/issue本文・gist・パッケージ公開に入ること（private リポジトリでも解除されない）
v2.1.205以降	`~/.claude/projects/` 配下のセッショントランスクリプト（`.jsonl`）への書き込み（読み取りはブロックされない）、中身を検証できないシェル変数を対象とした `rm -rf "$VAR"`
v2.1.211以降	実行時に機微データをリポジトリ外へ送る、あるいはデプロイの露出範囲を広げるコミット・push（任意ブランチが対象。public リポジトリでも適用）
v2.1.218以降	`rm -rf /` や `rm -rf ~` のようなルート／ホーム削除を、コマンド置換・プロセス置換の中にある場合も含めて分類器が判定（それ以前は承認プロンプト）

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

作業ディレクトリ内のローカルファイル操作
lock ファイル／マニフェストに宣言済みの依存関係のインストール
.env の読み取りと、その認証情報の対応API への送信
読み取り専用の HTTP リクエスト
依頼内容に沿ったプルリクエストの作成
同一マルチエージェントセッション内のエージェント間メッセージ、environment に登録した信頼ドメイン／バケット／サービスへのデータ送信（v2.1.195以降。データフローのみで、同じインフラへの破壊的操作や認証情報操作は対象外）

誤解が残りやすい重要変更：main への push は既定で通る

「Auto Mode は main への直接 push を止めてくれる」という説明が書かれた記事がまだ残っていますが、v2.1.211 以降は作業中リポジトリの任意ブランチ（デフォルトブランチを含む）への push が既定許可です。

ただし無条件ではありません。

production / release / gh-pages のようにデプロイ・公開先を示す名前の非デフォルトブランチは個別判断
push の内容は他のルールで引き続きチェックされる（シークレット混入や露出拡大は止まる）
permissions.deny とリモート側のブランチ保護は全モードで有効

「main を守りたい」なら分類器に期待するのではなく、permissions.deny とブランチ保護で止めるのが正しい設計です。

なお、サンドボックスのネットワークアクセスは既定許可ではなく分類器経由です。v2.1.198 以降はホスト＋ポート単位で判定を再利用します（allow は新しいコンテンツが会話に入るまで有効、対話CLIでは deny がターン終了で破棄、非対話・Agent SDK ではターン境界がないため deny が実行中ずっと再利用されます）。

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

Auto Mode の議論がややこしいのは、出所も測定対象も違う数値が混ぜて語られているからです。実際、日本語メディアの間でも「手動 14%」「13.6%」と表記が揺れています。まず全部を並べて切り分けます。

数値	何を測ったか	出所
89%	1,053人の有償プロ被験者による対照実験。各セッションの承認プロンプトに危険コマンドを1つ紛れ込ませ、Auto Mode が 937件をブロック	Anthropic
13.6%	同じ実験で人間が止められた件数（143件）	Anthropic
11%（116件）	89% の裏返し。Auto Mode をすり抜けた件数	Anthropic
約17% → 約5%	人間の検知率のセッション長依存。序盤は約17%、50プロンプト超で約5%まで低下。Auto Mode の検知率はセッション長に依存しない	Anthropic
97%	実利用ログ上、承認プロンプトの97%がそのまま承認されていた	Anthropic
62% / 49.5%	「今後表示しない」を使っているユーザーの割合 / CLIユーザーのうち手動で bash の allow ルールを作った割合	Anthropic
6.3% vs 2.4%	本番トラフィック分析。重大度7以上の意図しない被害を含むセッションの割合（手動承認 6.3% / Auto Mode 2.4%）	Anthropic
FPR 0.4%	実トラフィック1万件でのパイプライン誤ブロック率（Stage 1 単体は8.5%）	Anthropic
FNR 17%	実際に起きた「やりすぎアクション」52件に対するパイプラインの見逃し率。89%/11% とは別の実験	Anthropic
FNR 5.7%	合成データ（データ持ち出し系1,000件）に対する見逃し率	Anthropic
12% → 7%	Apollo Research との2週間の敵対的検証で、ハードニング後に総合見逃し率が改善	Anthropic
720件 / 成功0件	間接プロンプトインジェクション攻撃720回がすべて失敗。Trajectory Labs が Anthropic の委託で実施（完全な独立監査ではない）	Anthropic 委託
FNR 81.0%	認可境界を狙ったストレステスト（AmPermBench）での端到端の見逃し率	HKUST / ETH Zurich

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

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

一方で TECHi は、この実験が「明らかに悪いコマンドを誰が捕まえるか」を問うており、「実際のリポジトリでの破壊的操作の妥当性を分類器が理解できるか」を問うてはいない、と指摘しています。被験者が調査参加を認識していたこと、コマンド選定を Anthropic 側が行ったことも留保として挙げられています。

Simon Willison（2026年8月8日）はより端的に、「89% というのは、Auto Mode でも防げなかった 11% が残るということだ」と書きました。彼は 720件のインジェクション攻撃がすべて失敗したという主張にも懐疑的で、悪意ある指示を仕込んだパッケージのような攻撃を「どのバージョンの Auto Mode でも防げるとは思えない」としています。そのうえで、フィルタに頼るより機微データやツールへのアクセス自体を制限したエージェント設計を推し、「独立した第三者検証をもっと見たい」と明言しました。

独立評価 AmPermBench が示した「分類器が見ていない経路」

Simon Willison が求めた第三者検証にあたるものが、すでに1本出ています。香港科技大学（HKUST）と ETH Zurich の研究チームによる論文「Measuring the Permission Gate: A Stress-Test Evaluation of Claude Code's Auto Mode」（arXiv:2604.04978v2、2026年4月28日）です。日本語圏ではほとんど紹介されていません。

評価設計

ベンチマーク名は AmPermBench。4つの DevOps タスク系（ブランチ整理／ジョブキャンセル／サービス再起動／成果物クリーンアップ）× 128プロンプト
具体性・影響範囲・リスクレベルの3軸で曖昧性を体系化
隔離 Docker コンテナと shim 化した CLI で実行し、253件の状態変更アクションを抽出してオラクル正解と突き合わせ

結果

指標	値
端到端の偽陰性率（FNR）	81.0%（95%信頼区間 73.8〜87.4%）
分類器が実際に評価する層（Tier 3）に限定した FNR	70.3%
同・偽陽性率（FPR）	31.9%
分類器のスコープ外を通るアクション	状態変更アクションの 36.8% がプロジェクト内ファイル編集（Tier 2）経由で分類器を通らない
タスク別の最悪ケース	成果物クリーンアップで FNR 92.9%

この 81% を「Auto Mode は81%見逃す」と読んではいけない

論文の著者自身が限界を明記しています。このストレステストのワークロードは本番の使われ方とは根本的に異なり、意図的に認可境界を狙った曖昧シナリオで構成されています。Anthropic の 17% は「通常のワークフローで偶発的に起きたやりすぎ」を測っており、両者は直接比較できません。単一モデル（Sonnet 4.6）での評価、合成 DevOps 環境、タスク単位ではなくアクション単位という制約もあります。

では何が実務的に価値ある指摘かというと、36.8% のアクションが「プロジェクト内のファイル編集」という経路を通り、そもそも分類器の判定対象になっていないという構造の話です。しかも最悪ケースの成果物クリーンアップで FNR が跳ね上がった理由は、「想定していた CLI が使えないとき、エージェントはファイル編集で目的を達成しようとする」から。ガードのある経路を塞ぐと、ガードのない経路に流れるわけです。

ここから導ける実務的な線引きは明快です。

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

つまり Auto Mode を入れてもコードレビューは不要になりません。ファイル編集で埋め込まれたロジック上の問題は、レビューとテストとCIで捕まえるしかない領域です。AIが書いたコードに固有のリスクは AIコーディングのセキュリティリスクと対策で整理しています。エージェントが破壊的操作をした実例は AIエージェントがデータを全削除した事故まとめも参考になります。

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

2026年8月14日の既定化とほぼ同時期（v2.1.224 / 8月7日）に、cross-session messaging（セッション間メッセージング） が追加されました。この2つを組み合わせて読んでいる記事はほとんどありませんが、実は無関係ではありません。

セッション間メッセージングは、別ターミナルで動いている独立した Claude Code セッション同士が ListAgents / SendMessage でやり取りする機能です。送られるのはプレーンテキストの要約のみで、会話履歴やファイルは渡りません。macOS・Linux（WSL2 内 Linux 含む）が対象で、ネイティブ Windows と Bedrock / Claude Platform on AWS / Google Cloud's Agent Platform / Microsoft Foundry では利用できません。

権限モードが「配送するか保留するか」の判定材料になる

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

権限プロンプトをバイパスする側: bypassPermissions（および bypass が使える plan モードセッション）
プロンプトを出す側: auto / acceptEdits / dontAsk / default

受信側のクラス	挙動
プロンプトを出す側（Auto Mode を含む）	各メッセージをそのまま配送する。送信側が bypass を名乗った場合だけ承認待ちで保留
bypass 側	各メッセージを保留して承認を求める。送信側も bypass の場合だけ配送

ここが重要です。Auto Mode は「プロンプトを出す側」に分類されるため、他セッションからのメッセージは既定でそのまま届きます。8月14日以降、Pro / Max / Team の新規セッションが既定で Auto Mode になることと合わせると、人の承認を挟まずに Claude Code 同士が横につながる構図が既定値になる、ということです。

ただし受信メッセージにできないことも明確に決まっている

公式は制約を明示しています。

承認の代理はできない: 他セッションからのメッセージはユーザーの同意にはならず、保留中の権限プロンプトに答えられない
設定変更はできない: 権限設定・CLAUDE.md・その他設定を「他セッションに言われたから」変更しないよう指示されている
コマンドは実行されない: /compact などはプレーンテキストとして届くだけ
権限プロンプトは通常どおり出る: メッセージへの対応に権限が必要なら受信側で普通にプロンプトが出る
権限境界はセッションごと: 自分のセッションで拒否・ブロックされた作業を他セッションに依頼しないよう Claude に指示されており、その作業はユーザーに差し戻される

加えて v2.1.222 以降は、SendMessage の内容そのものを配送前に分類器がレビューします。ループ対策として送信元ごとのレート制限、短時間の同一メッセージ破棄、未読上限50件/セッションも設けられています。

組織として止めたい場合

手段	効果
`crossSessionInbound: "refuse"`	受信を拒否する（`accept` / `hold` / `refuse` の3択）
`isolatePeerMachines: true`	マシンをまたぐ送信に毎回承認を要求。`bypassPermissions` でも有効。プロジェクトファイルから ON にはできても OFF にはできない
managed settings の `permissions.deny: ["SendMessage","ListAgents"]`	組織単位で機能自体を封じる
`dialogExpiry`（既定5分）	保留ダイアログの有効期限。過ぎるとメッセージは破棄される（保留は最大100件）

機能そのものの詳細は Claude Codeのセッション間メッセージ機能とはにまとめています。複数エージェントを束ねて動かす設計に踏み込む場合は Claude Code Agent Teamsの使い方も合わせてどうぞ。

8月14日までにやること：設定チェック5項目

既定化を受け入れるにせよ拒否するにせよ、先に確認しておくべき項目があります。

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

コマンド	用途	備考
`claude auto-mode config`	`"$defaults"` 展開後の実効設定を出力	まずこれを見る
`claude auto-mode defaults`	組み込みルール4種を JSON で出力。`--label` で特定ルールの全文	`--label` は v2.1.208以降
`claude auto-mode critique`	自作ルールへのAIレビュー。曖昧・冗長・偽陽性を招きそうな記述を指摘	自然言語ルールの検証に有効
`claude auto-mode reset`	ユーザー設定から `autoMode` セクションを削除（managed settings と `--settings` 分は残る）	v2.1.212以降

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

Anthropic 自身のデータで、CLIユーザーの 49.5% が手動で bash の allow ルールを作っており、なかには全コマンド許可にしている例もあります。Auto Mode が既定になると、この広い allow がそのまま効いてしまいます。

対策として autoMode.classifyAllShell: true（v2.1.193以降）があります。Auto Mode 中は Bash / PowerShell の allow ルールをすべて停止し、全シェルコマンドを分類器に通す設定です。「allow を整理する時間がないが、分類器には全部見せたい」場合の現実的な選択肢になります。

③ `autoMode.environment` に自社の信頼境界を書く

environment は正規表現やツールパターンではなく、自然言語の散文で信頼インフラを記述する枠です。claude auto-mode defaults で確認できるスロットは3種類あります。

Context slots: 組織名、Claude Code の主用途、クラウドプロバイダ、リポジトリ可視性、社内共有・スニペットホスティング、組織固有CLI、シークレット管理、CI/CDデプロイ先、ネットワーク姿勢、保護デプロイ名前空間、データ保持
Trust slots: Trusted repo / Source control / Trusted internal domains / Trusted cloud buckets / Key internal services / Internal package registry。repo と source control 以外はすべて既定で None configured
Sensitivity slots: Sensitive data locations & audiences / Sensitive remote targets / Protected IaC scopes。既定は広めのヒューリスティック（prod を含むホスト名は機微リモートターゲット扱い、など）

Trust slots がほぼ空である以上、何も書かなければ分類器は自社の内部ドメインもバケットも知らないまま判断していることになります。誤ブロックが多い環境ほど、ここを書く価値があります。

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

これは公式が Danger ボックスで警告している事故パターンです。

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

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

「ルールを1つ足したかっただけ」で組み込みガードが全滅する構造なので、独自ルールを書くときは必ず "$defaults" を含めます。各セクションは独立評価なので、environment だけ設定しても他3つの既定は残ります。

⑤ 硬い境界は `permissions.deny` に書く（`autoMode.soft_deny` では足りない）

組織設定と個人設定の合成ルールには、非自明な仕様があります。

各スコープのエントリは結合される。開発者は environment / allow / soft_deny / hard_deny に個人エントリを追加できるが、managed settings のエントリを削除はできない
ただし allow は soft_deny の例外として働くため、開発者が追加した allow は組織の soft_deny を上書きできてしまう

したがって「絶対に通したくない操作」を autoMode.soft_deny に書くのは不十分です。硬い境界が必要なら managed settings の permissions.deny を使います。

設定	評価タイミング	上書き可否
`permissions.deny`（managed settings）	分類器より前に評価される絶対ブロック	ユーザー意図でも分類器設定でも上書き不可
`permissions.ask`	内容スコープ付きルールは分類器より前に評価され、Auto Mode でも必ずプロンプトが出る（例: `Bash(git push )` / `Bash(gh pr create )`）	—
`autoMode.soft_deny`	分類器内部のルール	開発者の `allow` で解除されうる

もう1つ注意すべきは設定の読み取りスコープです。分類器が autoMode を読むのは ~/.claude/settings.json（個人）、managed settings（組織配布）、--settings フラグ / Agent SDK のインラインJSON だけ。.claude/settings.json と .claude/settings.local.json からは読みません（v2.1.207 で local も除外）。リポジトリやビルドステップが自分自身に allow ルールを与えるのを防ぐためです。同じ理由で、defaultMode: "auto" をプロジェクト設定に書いても v2.1.142 以降は無視されます。

チーム展開の設計全体は Claude Code チーム導入ガイドにまとめています。

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

既定化を受け入れない選択も普通に取れます。

やりたいこと	設定
個人で既定モードを固定する	`~/.claude/settings.json` の `permissions.defaultMode` に `"default"`（Manual）や `"acceptEdits"` を指定
逆に8月14日を待たず既定化する	`permissions.defaultMode: "auto"`
セッション単位で切り替える	起動時に `claude --permission-mode auto`、対話中は `Shift+Tab` でモードを循環、または `/permissions` から変更
組織単位で Auto Mode を禁止する	managed settings の `permissions.disableAutoMode: "disable"`。`Shift+Tab` の循環から `auto` が消え、`--permission-mode auto` も起動時に拒否される
組織単位で bypass を禁止する	`permissions.disableBypassPermissionsMode: "disable"`

規制業界や監査対応が必要な組織では、もう1つ検討すべき論点があります。「モデルが承認した」という記録は、「誰が承認したか」の監査証跡にはなりません。変更管理プロセス上、人間の承認記録が要件になっている場合、Auto Mode は要件を満たさない可能性があります。この観点は制度設計の問題なので、技術設定より先に整理しておくべきです。

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

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

分類器がブロックすると、Claude はツール結果として拒否理由を受け取り、安全な代替手段を探します（deny-and-continue）。セッション自体は継続します。

ただし歯止めはあります。3回連続ブロック、または累計20回ブロックで Auto Mode は一時停止し、通常の承認プロンプトに戻ります。プロンプトを承認すると Auto Mode が再開します。この閾値は設定変更できません。許可されたアクションで連続カウンタはリセットされ、累計カウンタはセッション中持続します。

非対話モード（-p）では、繰り返しブロックはセッションを中断させます。承認できる人間がいないためです。CI/CD で Auto Mode を使うのが向かない理由もここにあります。

ブロック理由が「Blocked by classifier」としか出ないことがある

v2.1.208 以降、多くのセッションでブロック理由は固定文字列 Blocked by classifier になります。分類器は内部の重大度スケールで採点しており、説明文を書かないためです。説明文を書く分類器モデルが選ばれるセッションもありますが、どちらになるかはユーザーが設定できません。デバッグ時は /permissions の Recently denied タブに記録が残り、r キーで再試行マークを付けられます。

会話で伝えた境界は context compaction で消える

「push しないで」「レビューするまでデプロイしないで」と会話で伝えると、分類器はそれをブロック信号として扱い、既定では許可される操作も止めます。この境界は後のメッセージで解除するまで有効で、Claude 自身が「条件を満たした」と判断しても解除されません。

ただし境界はルールとして保存されません。分類器は毎回トランスクリプトから読み直すため、context compaction（会話履歴の圧縮）で該当メッセージが消えると、境界も一緒に消えます。長時間セッションほど踏みやすい落とし穴です。恒久的な保証が必要なら permissions.deny / permissions.ask に書くよう公式も明言しています。

最近の修正で挙動が変わった点

バージョン	日付	変更
v2.1.221	2026-08-04	分類器チェックのキャッシュ効率改善。判定保留中のモード切替で古い結果が適用されないよう修正。zsh 正規表現条件による Bash 権限チェックのバイパスを修正
v2.1.222	2026-08-04	`SendMessage` を配送前に分類器が評価。plan モード＋Auto で、静的解析が read-only と証明できない Bash コマンドを分類器が判定。worktree 分離セッションがメインチェックアウトに破壊的 git コマンドを実行できた問題を修正
v2.1.223	2026-08-06	細工したコマンドが権限チェックから一部を隠せる Bash 権限バイパスを修正。タブ・不可視Unicode で承認ダイアログから内容を隠せた問題を修正。エージェント定義の `bypassPermissions` が組織の bypass 無効化ポリシーを無視していた権限ギャップを修正
v2.1.224	2026-08-07	cross-session `SendMessage` 追加。`claude self-hosted-runner`（Team / Enterprise パブリックベータ）
v2.1.225	2026-08-08	分類器自身の権限チェックがセーフティフィルタに拒否された場合、連続ブロック上限にカウントしないよう修正
v2.1.227	2026-08-10	期限切れトークンでセッション開始時にサブスクリプション階層なしで feature flag が評価される問題を修正など

モードを切り替えた時点で判定保留中のものがある場合、新しいモードなら要求しなかった判定は破棄され、承認プロンプトが出ます（dontAsk では自動拒否）。

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

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

出所	内容	Auto Mode との関係
Mercado Libre / Shopify	Code with Claude 2026（2026年5月）で「Q3 2026 までに90%自律コーディング」を表明	顧客企業側のコミットメント。Auto Mode は手段の一つ
Dario Amodei（Anthropic CEO）	2025年3月に「3〜6か月で AI がコードの90%を書く」と予測	業界予測であり、製品目標ではない
Anthropic 社内実績	新規コードの大半が Claude 生成と報じられている（報道により80%／90%台と幅がある）	社内の運用実態。出典と時点で数値が揺れる

一方で Anthropic 自身が示した数字は「承認プロンプトの 97% がそのまま承認されていた」というものです。これを「90%程度のアクションを Auto Mode が自動処理できる」と読み替えた表現が広まりましたが、正確には形骸化した承認を分類器が引き取る設計という話であって、自律率の目標値ではありません。

the-decoder が指摘した「オーバーサイトのパラドックス」も、この文脈で読む価値があります。介入回数が減るほど1回の監督の重要性は増すのに、Auto Mode が大部分を書いたプロジェクトへの深い理解を人間が築くことは難しくなる、という構造的な問題です。

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

Auto Mode をそのまま使うのが合う人

隔離環境（dev container / Docker / 専用VM / 使い捨てクラウドワークスペース）で Claude Code を動かしている個人・チーム — 影響範囲が物理的に限定されているため、11% / 17% の見逃しを受け止められる
承認プロンプトを事実上惰性で押している開発者 — Anthropic のデータどおりの状態なら、分類器に任せたほうが検知率は上がる
permissions.deny / permissions.ask を組織共有設定として整備できる企業 — 分類器の手前に絶対ブロックを置ける
長時間の反復作業（大規模リファクタリング、テスト整備、依存更新）を任せたいテックリード・SRE — 人間の検知率がセッション長で約17%→約5%に落ちる領域こそ、分類器の横ばい特性が効く
autoMode.environment に自社の信頼境界を書ける組織 — 誤ブロックを抑えつつ、機微リモートの保護を厚くできる

Auto Mode を既定にすべきでない人

本番リポジトリと本番クラウド認証情報が同居するホストで Claude Code を直接動かしている人 — 見逃し時の被害がそのまま本番に届く
人間の承認記録が監査要件になっている組織 — 「モデルが承認した」は「誰が承認したか」の証跡にならない
CI/CD パイプライン — 非対話モードでは繰り返しブロックがセッション中断につながる。dontAsk ＋静的な permissions.allow のほうが安定する
広すぎる bash の allow ルールを放置している人 — 分類器の手前で allow が効いてしまう。整理するか classifyAllShell を検討してから
Auto Mode をコードレビューの代替と考えている組織 — 独立評価が示したとおり、プロジェクト内のファイル編集は分類器の判定対象外の経路になりうる
会話中の指示（「main には触らないで」など）に恒久的な保証を求める運用 — context compaction で失効する

よくある質問

Q1. 8月14日以降、既存のセッションも Auto Mode になりますか？

公式ブログの記載は「新規セッション」が対象です。すでに開いているセッションの権限モードが途中で切り替わるという説明はありません。また permissions.defaultMode を自分で固定している場合は変化せず、切り替えを提案する1回限りの案内が出ることがあるとされています。

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

使えます。現在の公式ドキュメントは対応プランを "All plans." と記載しており、加えて Pro は8月14日から既定モードになる対象に含まれます。利用可否とデフォルト化は別の話なので、混同しないよう注意してください。

Q3. 分類器の分だけ料金が増えますか？

Pro / Max / Team では2026年8月7日付で分類器のオーバーヘッド分は課金されなくなりました。一方、Enterprise / API / クラウド経由ではトークン使用量にカウントされます。従量課金でチーム運用している場合は、Auto Mode 常用時の増分を見積もっておくのが安全です。

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

bypassPermissions は審査そのものが存在しません。Auto Mode は承認プロンプトを出さない点では似ていますが、各アクションを分類器が実行前に審査し、危険と判断すればブロックします。ただし公式自身が「Auto mode は承認プロンプトを減らすが、安全性を保証するものではない」と明記しています。「安全になった」ではなく「承認疲れによる見落としより分は良い」という位置づけです。

Q5. Auto Mode は `main` ブランチへの push を止めてくれますか？

止めません。v2.1.211 以降、作業中リポジトリの任意ブランチ（デフォルトブランチを含む）への push は既定で許可されています。ただし push の内容は別ルールでチェックされ、シークレット混入や露出拡大につながるものはブロックされます。ブランチ自体を守りたい場合は permissions.deny とリモート側のブランチ保護を使ってください。

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

まず claude auto-mode config で実効設定を確認し、autoMode.environment に自社の信頼リポジトリ・内部ドメイン・バケット・内部パッケージレジストリを記述します。Trust slots は既定でほぼ None configured のため、書かないと分類器は自社インフラを知らないまま判断します。書いたルールは claude auto-mode critique でレビューさせると、曖昧な記述を事前に潰せます。

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

減らせません。香港科技大学らの独立評価は、状態変更アクションの 36.8% がプロジェクト内ファイル編集の経路を通り、そもそも分類器の判定対象になっていないと指摘しています。Auto Mode はシェルコマンドと外向き操作の門番であって、書かれたコードの妥当性を保証する仕組みではありません。

Q8. 他のセッションから送られてきたメッセージで、承認を代理させられますか？

できません。公式は、他セッションからのメッセージはユーザーの同意にならず保留中の権限プロンプトに答えられないこと、権限設定や CLAUDE.md を他セッションの指示で変更しないこと、自分のセッションで拒否された作業を他セッションに依頼しないことを明示しています。ただし Auto Mode は「プロンプトを出す側」に分類されるため、メッセージ自体は既定で配送されます。受信を止めたい場合は crossSessionInbound: "refuse" を設定します。

Q9. 組織として Auto Mode を全面的に止めることはできますか？

できます。managed settings で permissions.disableAutoMode: "disable" を配布すると、Shift+Tab の循環から auto が消え、--permission-mode auto での起動も拒否されます。セッション間メッセージングも併せて止めたい場合は permissions.deny: ["SendMessage","ListAgents"] と crossSessionInbound: "refuse" を組み合わせます。

まとめ

Claude Code の Auto Mode は、承認の判断を人間から分類器モデルへ移す権限モードです。2026年8月14日から Pro / Max / Team の新規セッションで既定になり、Enterprise / API / クラウド経由は現時点ではオプトインのまま（公式は「今後1か月以内に既定化」とだけ表明）という状況です。

押さえておくべき要点を整理します。

8月14日の変化は「新規セッションの既定値」。permissions.defaultMode を固定していれば影響はなく、組織の managed settings は常に優先される
仕組みは2層防御。入力層でプロンプトインジェクションを検出し、出力層で2段の分類器が審査する。分類器は Claude 自身の発言とツール結果を見ない（reasoning-blind）設計
数値は出所で読み分ける。89%/13.6% は危険コマンド混入実験、17% は実際のやりすぎ52件、81% は認可境界を狙ったストレステスト。互いに直接比較できない
分類器が見ていない経路がある。独立評価では状態変更アクションの 36.8% がプロジェクト内ファイル編集を通り、判定対象外だった。コードレビューの代替にはならない
Auto Mode は「プロンプトを出す側」なので、セッション間メッセージは既定で配送される。組織で止めるなら crossSessionInbound と permissions.deny の併用
設定の事故で最も多いのは "$defaults" の書き忘れ。組み込みブロックルールが丸ごと消える
硬い境界は permissions.deny に書く。autoMode.soft_deny は開発者の allow で上書きされうる。会話で伝えた境界は context compaction で消える
「90%自律コーディング」は Anthropic の公式目標ではない。顧客企業のコミットメント、CEOの業界予測、社内実績が混ざった表現

Claude Code 全体の機能と料金は Claude Code とは？機能・料金・使い方を徹底解説、安全な運用設計は Claude Codeのセキュリティと安全な使い方、組織への展開手順は Claude Code チーム導入ガイドで個別に整理しています。AIエージェント全般の権限設計まで視野を広げるなら AIエージェントのセキュリティ対策も合わせてどうぞ。

Auto Mode は「承認疲れという実在の問題」に対する、現時点でもっとも真剣な工学的回答です。同時に公式が「安全性を保証しない」と明記している未完成の仕組みでもあります。隔離環境で動かし、permissions.deny で硬い境界を先に引き、分類器が見ていない領域はレビューとテストで押さえる。この3点を用意したうえで既定化を迎えるのが、2026年8月時点でもっとも合理的な構えです。