結論：Claude Codeは2026年8月14日から、Pro・Max・Teamプランの新規セッションで「auto mode」が既定の許可モードになりました。これまでの既定「Manual（default）」は原則reads onlyでしたが、autoモードでは第2のモデル（classifier）がツール呼び出しを審査し、危険・破壊的・組織外向けと判定されない限り確認プロンプトなしで実行されます。ただし、自分やmanaged settingsで既に`defaultMode`を設定している場合は変わらず、EnterpriseプランやConsole APIキー利用は対象外です。
- 切り替わったのは「新規セッションの初期モード」だけ。実行中セッションやレジューム済みセッションは変わらず、Shift+Tabでいつでも他モードへ切り替え可能
- classifierの判定コストはPro/Max/Teamでは既に利用上限に加算されない設計（2026年9月6日時点）。Enterprise・API・Bedrock等では従来通りトークン課金対象
- `autoMode.environment`未設定のまま使うと、社内リポジトリへのpushやCI連携が「外部」判定でブロックされやすい。既定切替のタイミングで環境設定を済ませておくのが移行の要
対象読者：Claude CodeをPro/Max/Teamプランで使うエンジニア・PM、チーム/組織展開を設計する情シス・エンジニアリングマネージャー。本記事は公式ドキュメントとチェンジログを一次ソースに、何が変わったか・何が変わらないか・移行時に確認すべき7ステップ・つまずきやすい失敗パターンを整理します。
先週、手元のターミナルでclaudeを立ち上げたら見慣れない一文が出ました。「auto modeが有効になりました」。プランを変えた覚えもなく設定もいじっていないのに、ステータスバーの表示が⏸ manual mode onから⏵⏵ auto mode onに変わっていたんです。焦って公式ドキュメントを漁ったところ、これは事故ではなく2026年8月14日付けの正式な既定モード変更でした。似た戸惑いをSlackの社内チャンネルでも見かけたので、変更の中身と、チームとして何を先にやっておくべきかを一度整理しておきます。
Starting August 14, auto mode is the default permission mode for new sessions on Pro, Max, and Team plans. If you set a default mode yourself, it stays in place unless you accept the one-time switch prompt, and a default your organization manages doesn’t change. You can still switch modes at any time.
（8月14日から、Pro・Max・Teamプランの新規セッションでauto modeが既定の許可モードになる。自分でデフォルトモードを設定済みの場合はそのまま維持されるが、1回だけ表示される切り替えプロンプトを承諾すると変わる。組織がmanaged settingsで管理しているデフォルトは変わらない。モードはいつでも切り替え可能）
なお本記事は2026年9月6日時点の公式ドキュメント（Choose a permission mode）、Configure auto mode、週次リリースノート（Week 32）を一次ソースにしています。ドキュメントは更新頻度が高いので、実装時は必ず現行版を確認してください。auto mode自体の仕組みは「Claude Code自動許可モード実践｜チーム導入と安全設計」で詳しく扱っているので、classifierの内部動作を一から知りたい方はあわせてどうぞ。本記事は「8月14日の既定切替」で新たに押さえるべき点に絞ります。
何が変わったか：既定パーミッションモードの切替
公式ドキュメントの「Which mode a session starts in」に沿って整理すると、切替の中身は次の表の通りです。
| 環境 | 2026年8月14日より前 | 2026年8月14日以降 |
|---|---|---|
| Pro/Max/Teamプラン・ターミナル / VS Code拡張 | default（Manual） |
auto |
claude -p（headless）／ Agent SDK |
default |
default（変更なし） |
| Enterpriseプラン／Claude Console APIキー | default |
default（変更なし） |
| Bedrock／Vertex(Agent Platform)／Foundry／apps gateway | defaultMode設定次第（既定はManual） |
変更なし。ただしauto mode自体は利用可能 |
ユーザーが~/.claude/settings.jsonでdefaultModeを設定済み |
その設定のまま | 1回だけ「autoに変える？」の確認プロンプトが出るが、断ればそのまま維持 |
組織のmanaged settingsがdefaultModeを管理 |
その設定のまま | 変更なし |
ポイントは「切り替わるのは新規セッションの既定値だけ」という点です。実行中のセッションや--resumeで再開したセッションは、既に入っていたモードをそのまま引き継ぎます。またこの既定切替自体は、macOS・Linux・WSLではClaude Code v2.1.228以降、ネイティブWindowsではv2.1.233以降が前提条件で、これより前のバージョンでは従来通りManualが既定のままです。CIやfeature flag取得が無効な環境、インストール・アップグレード直後の最初のセッションも例外的にManualから始まります。
そもそもauto modeとは：classifierが確認プロンプトの代わりに審査する
auto modeの仕組み自体は既存記事で扱っているので要点だけ再掲します。Manualモードでは「ファイルを編集する」「シェルコマンドを実行する」といったアクションのたびにユーザーに確認を求めますが、auto modeではSonnet 5をベースにした第2のモデル（classifier）がその判断を肩代わりします。classifierはユーザーメッセージ・ツール呼び出し・CLAUDE.mdの内容を読みますが、ツールの実行結果そのものは受け取りません。Web検索結果やファイル内容に埋め込まれたプロンプトインジェクションが、classifierの判断を直接操作できない設計です。
既定でブロックされる代表的な操作は次の通りです（公式「What the classifier blocks by default」より抜粋）。
curl | bashのようなコード取得即実行- 本番環境へのデプロイ・マイグレーション
- force push、
git reset --hard、git clean -fdなど不可逆な破壊的操作 - クラウドストレージの一括削除、IAM・リポジトリ権限の付与
- シークレットや機密データを外部エンドポイントへ送信するコミット・プッシュ
- 承認されていないPull Requestのマージ、自分自身のPRの承認
逆に既定で許可されるのは、作業ディレクトリ内のファイル操作、lockファイルに宣言済みの依存関係インストール、読み取り専用のHTTPリクエスト、そして作業中リポジトリのどのブランチへのpush（デフォルトブランチ含む）です。ここは2026年7月以前の仕様（作業ブランチとClaude作成ブランチのみ許可）から広がっているので、旧仕様の記憶で運用設計をしている場合は要更新です。
何が変わらないか：3つの「あなたは対象外」パターン
既定切替のニュースを見て「うちのチームも勝手にauto modeになるのか」と身構える前に、対象外になる3パターンを確認しておくと安心です。
- Enterpriseプラン・Claude Console（API直）：既定は
defaultのまま変わりません。auto mode自体は利用できますが、明示的にdefaultMode: "auto"を設定しない限り自動では切り替わりません。 - 自分で
defaultModeを設定済みのユーザー：1回だけ「autoに変えますか」という確認が出ますが、断れば従来の設定が維持されます。「断ったのに変わった」という報告があれば、それは設定ファイルの置き場所（.claude/settings.jsonではなく~/.claude/settings.jsonである必要がある）を疑うべきです。 - 組織のmanaged settingsが
defaultModeを管理している場合：管理者が明示的に変更しない限り既定は変わりません。逆にauto mode自体を禁止したい場合は、managed settingsでpermissions.disableAutoModeを"disable"にすれば、Shift+Tabのサイクルからautoが消えます。
移行チェックリスト：確認しておきたい7ステップ
手元の検証環境と社内の小規模チームで実際に一通り触った順番で整理すると、次の7ステップに落ち着きました。
- 現在の`defaultMode`を確認する：
~/.claude/settings.json、プロジェクトの.claude/settings.json、managed settingsのどこかに既に値が入っていないか確認します。値がなければ8/14以降の対象プランでは自動的にautoが既定になります。 - モデル要件を確認する：Anthropic API・Claude Platform on AWSではOpus 4.6以降／Sonnet 4.6以降／Fable系モデル（Fable 5・5.1）、Bedrock・Vertex・Foundry・apps gatewayではSonnet 5・Opus 4.7以降・Fable系モデルのみが対応です。Sonnet 4.5やHaiku、claude-3系ではauto modeは使えません。
- `claude auto-mode config`で実効ルールを確認する：デフォルトのままだと、classifierが信頼するのは作業ディレクトリと設定済みリモートだけです。それ以外は「組織外」として扱われるため、社内の別リポジトリへのpushすらブロックされることがあります。
- `autoMode.environment`にトースト済みインフラを書く：ソースコントロールの組織名、信頼できる内部ドメイン、Jenkinsやartifact registryなど社内サービスをプレーンな自然言語で列挙します。
"$defaults"を含めれば組み込みルールを残したまま追記できます。 - 人間のチェックポイントが必要な操作に`permissions.ask`を足す：
Bash(git push *)やBash(gh pr create *)のようなルールは、auto modeでも常にプロンプトを強制します。「pushとPR作成だけは自分で見る」という運用にしたいチームはここを先に決めます。 - `autoMode.classifyAllShell`の要否を判断する：既定では
Bash(npm test)のような狭いallowルールはclassifierを経由せず素通りします。allowルールの想定外の引数まで含めて全シェルコマンドをclassifierに通したい場合はtrueにしますが、レイテンシーとclassifier呼び出し回数が増える点はトレードオフです。 - `/permissions`の「Recently denied」タブを運用に組み込む：ブロックされた操作は自動で記録されるので、
rキーでその場承認しつつ、繰り返しブロックされる宛先をautoMode.environmentへ追記していく——というフィードバックループを最初の1〜2週間は意識的に回すと定着が早いです。
コピペで使えるプロンプト・コマンド5選
移行作業でそのまま使えたプロンプト・コマンド例です。
claude auto-mode config—— 現在の実効ルール（environment / allow / soft_deny / hard_deny）をJSONで表示claude auto-mode defaults --label 'Git Destructive'—— 組み込みルールのうち特定ラベルの全文だけを確認（v2.1.208以降）- 「今のCLAUDE.mdに、production/releaseという名前のブランチへのpushは必ず確認を挟むルールを追記して」 —— classifierはCLAUDE.mdも読むため、プロジェクト単位の振る舞い調整に有効
- 「~/.claude/settings.jsonのautoMode.environmentに、社内GitHub Enterprise（github.example.com配下の全リポジトリ）とJenkins（ci.example.comのCIサーバー）を$defaultsを残したまま追記して」
claude auto-mode critique—— 自分で書いたallow/soft_deny/hard_denyルールをAIにレビューさせ、曖昧・冗長・誤検知しやすい記述を指摘してもらう
失敗パターン4選
❌ 失敗1：「勝手に自動化された」と誤解してauto modeを即オフにする
既定切替の一報だけを見て「セキュリティ的にまずい」と反射的にManualへ戻すケースです。classifierは確認プロンプトを省くだけで、危険操作の審査自体は消えていません。むしろrm -rf /のようなクリティカルパス削除は、Manualモードにはない「classifierによる二重チェック」が入ります。
⭕ 対策：まずclaude auto-mode configで自分の環境の実効ルールを見てから、本当に困る操作（例：本番デプロイの自動承認）だけをpermissions.askで個別に確認必須へ戻します。
❌ 失敗2：`autoMode.environment`を設定せずに使い続け、社内pushがブロックされ続ける
自分の検証環境でも最初の数日は、社内のミラーリポジトリへのpushがことごとくブロックされました。classifierは既定で「作業ディレクトリと設定済みリモート」しか信頼しないため、これは仕様通りの挙動です。
⭕ 対策：ブロックのたびに「Recently denied」を見て、繰り返し出てくる宛先をautoMode.environmentへ足していきます。1週間もすれば大半のブロックが収まります。
❌ 失敗3：サブエージェントのfrontmatterで個別に許可モードを指定したつもりになる
サブエージェント定義のpermissionModeフィールドを書いても、auto modeが有効なセッション中はclassifierが同じルールで審査するため、この指定は無視されます。
⭕ 対策：サブエージェント単位で挙動を変えたい場合は、親セッション側のautoModeルールやCLAUDE.mdの記述で制御する前提に切り替えます。
❌ 失敗4：classifier呼び出しのコストを不安視して導入を見送る
「AIがAIを審査するなら課金が倍増するのでは」という懸念です。Pro/Max/Teamプランでは、classifierの呼び出しは利用上限にカウントされない設計になっています（2026年9月6日時点）。コストが乗るのはEnterpriseプランやAPI・Bedrock・Vertex・Foundry経由の利用に限られます。
⭕ 対策：課金対象のクラウド経由で使っている場合のみ、読み取りと作業ディレクトリ内編集はclassifierをスキップする設計（オーバーヘッドは主にシェルコマンドとネットワーク操作から来る）を踏まえて、コスト影響を見積もってから判断します。
導入判断チェックリスト：チームとしてどう構えるか
- 個人開発・小規模チームでPro/Max/Teamを使っている → 8/14の切替をそのまま受け入れつつ、
autoMode.environmentだけ最初に埋めておけば体感の摩擦は少ない - セキュリティ要件が厳しい社内リポジトリを扱う →
permissions.askでpush・PR作成に人間のチェックポイントを明示的に残す運用が無難 - 組織として標準ルールを配りたい → managed settingsで
autoMode.environment・hard_deny・soft_denyを全社配布し、開発者側はallowで個人拡張のみ可能にする設計が公式の想定に沿う - auto modeそのものを使わせたくない組織 → managed settingsで
permissions.disableAutoMode: "disable"を設定すれば、8/14の既定切替からも除外できる
組織展開の周辺整備としては、モデル・スキルの統制を扱った「Claude Code全社ガバナンス」、支出上限の仕組みを扱った「Claude Code支出上限｜gatewayで開発者別に設定」、法人導入前の確認事項を網羅した「法人導入セキュリティ完全チェックリスト」もあわせてどうぞ。
FAQ
Q1. auto modeへの切替を完全に拒否することはできますか？
個人設定であれば、1回だけ表示される切り替えプロンプトを断れば従来のモードが維持されます。組織単位で全員に使わせたくない場合は、managed settingsでpermissions.disableAutoModeを"disable"にすると、Shift+Tabのサイクルからautoが消え、--permission-mode autoを指定してもManualで起動します。
Q2. VS Code拡張とターミナルで挙動は同じですか？
起動時に参照する設定の優先順位が異なります。VS Code拡張はclaudeCode.initialPermissionMode、直近に選んだモード、managed settings/~/.claude/settings.jsonのdefaultMode、最後にプランごとの組み込み既定という順で決まり、プロジェクトの.claude/settings.jsonは読みません。ターミナルはフラグ→defaultMode設定ファイル→組み込み既定の順です。
Q3. plan modeとauto modeはどう関係しますか？
plan modeでは編集は既定でブロックされますが、useAutoModeDuringPlan設定（既定で有効）がオンなら、調査用のシェルコマンドはclassifierが審査したうえで実行されます。プランを承認するときの選択肢に「Yes, and use auto mode」が出るのはこのためです。
Q4. classifierに判断させたくない操作を確実にブロックするには？
managed settingsのpermissions.denyを使います。classifierに相談する前の段階でブロックされ、ユーザーの意図表明やallowルールでも上書きできません。autoMode.hard_denyは自然言語ベースのルールで、classifierの判断ロジックの中で最優先されますが、tool-patternベースの確実な遮断が必要ならpermissions.denyが原則です。
Q5. Bedrock・Vertex・Foundry経由で使っている場合も8/14に既定が変わりますか？
変わりません。これらの環境とサインイン済みのapps gatewayセッションでは、auto modeはShift+Tabのサイクルには既定で出てきますが、セッションの開始モード自体は引き続きdefaultMode設定（未設定ならManual）に従います。既定からautoにしたい場合は、ユーザー設定またはmanaged settingsで明示的にdefaultMode: "auto"を書く必要があります。
まとめ：既定は変わったが、境界線の設計は依然としてチーム側の仕事
8月14日の既定切替は、Claude Codeが「確認を求めるツール」から「危険な操作だけを止めるツール」へと運用モデルを一段進めた変化です。ただし何がブロックされ何が通るかは、classifierの組み込みルールとautoMode.environmentの設定次第で決まります。切替のニュースだけで一喜一憂せず、まずclaude auto-mode configで自分やチームの実効ルールを確認し、社内インフラの信頼リストを埋め、push・PR作成のような一線だけpermissions.askで人間のレビューに残す——ここまでやって初めて、既定切替のメリットを安全に受け取れます。
前回の「複数セッション連携」と同じWeek 32のリリース群からは、自社インフラ上でクラウドセッションを動かす「self-hosted environments」の公開ベータも始まっています。次回はこちらを組織運用の観点でまとめる予定です。
Claude Codeの組織導入・権限設計を検討中の方へ
Uravationでは、Claude Codeの導入支援・個別指導を提供しています。auto modeの境界線設計、managed settingsでの全社標準化、settings.jsonのチームテンプレート整備まで、100社以上の支援実績に基づいて伴走します。「うちの権限設計はこれで大丈夫か」といった個別相談からお気軽にどうぞ。
出典
- Choose a permission mode（公式ドキュメント） — 2026年9月6日時点で確認
- Configure auto mode（公式ドキュメント・設定リファレンス）
- Week 32 · August 3–7, 2026（公式週次リリースノート）
- Claude Code changelog（公式・v2.1.220〜v2.1.235の各記載）
- Settings（公式ドキュメント・permissions.defaultMode等の設定リファレンス）
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載執筆。
