AIREITERAnthropicは10月22日、Pro、Max、Teamプランの多くのClaudeアプリで、翌週から新しいセッションのデフォルトをauto modeにすると発表しました。Enterpriseの管理者には先にメールで通知されます。一方、APIと各種クラウドプラットフォームでは、当面オプトイン方式が続きます。
10月22日に変わったこと、変わっていないこと
今回のアップデートは、Claude Codeで先行した変更を、ほかのClaudeアプリにも広げるものです。2026年8月14日以降、Pro、Max、TeamプランのClaude Codeでは、新しいセッションがauto modeで始まるようになりました。別のデフォルトを固定していたユーザーには、切り替えを一度だけ確認するプロンプトが表示されます。10月22日付のAnthropicの発表では、Pro、Max、Teamプランの多くのClaudeアプリでも、翌週から新規セッションのデフォルトとしてauto modeを展開すると説明されています。Enterpriseでは、組織の設定が変わる前に管理者へメールが届きます。
ただし、適用範囲には3つの例外があります。管理設定でデフォルトを固定しているTeam管理者のユーザーには変更がありません。Enterprise、Claude API、AWS上のClaude Platform、Amazon Bedrock、Google Cloud's Agent Platform、Microsoft Foundryも引き続きオプトイン方式で、これらでは今後1か月のうちにauto modeをデフォルトにする予定です。個人で固定したデフォルトも、切り替え確認のプロンプトを受け入れない限り維持されます。
ユーザーがどの挙動を目にするかは、バージョンにも左右されます。リリースノートの追跡情報によると、Claude Code v2.1.283以降では、permission modeを設定していない場合、対話型ターミナルとVS Codeのセッションがautoを組み込みの開始モードとして扱います。ただし、機能フラグがまだ配信されていない初回起動では、新規インストールでもmanual modeになることがあります。
Claude auto modeは何を基準に判断するのか
Anthropicの発表によると、Claude auto modeでは、各ツール呼び出しをその都度ユーザーに承認させる代わりに、専用のclassifierへ送って判定します。通常の操作は許可し、取り消しにくい操作や破壊的な操作、作業環境の外部を対象とする操作はブロックします。その場合、Claudeはより安全な手段を探すか、ユーザーに直接確認します。連続して3回ブロックされた場合、または1セッション中に合計20回ブロックされた場合は、manual modeへ戻って承認を求める仕組みです。
Claude auto modeでも、明示的なpermissionルールがclassifierより先に適用されます。permissions.denyに登録した項目は即座にブロックされ、classifierの判定で覆すことはできません。permissions.askの項目は必ず確認を求めます。一方、Bash(python:*)のように任意のコード実行を許可する広いallowルールは、auto modeが有効な間は一時的に無視されます。コマンドがclassifierを完全に迂回しないようにするためです。
classifierが見る情報は、静的なallowlistよりも多岐にわたります。Anthropicによれば、git pushやプルリクエストの送信先がprivate、trusted、publicのどれに当たるかを操作前に確認します。また、git reset --hardのような破壊的コマンドでは、現在のgit statusも判定材料になります。
Webページ、ファイルの内容、ツールの出力に含まれる外部コンテンツは、prompt injectionの検査を通ります。注入攻撃らしい内容が見つかると、Claudeのコンテキストに警告が追加されます。データの持ち出しはhard-denyの対象で、自動承認されません。この操作を実行するには、モードを切り替えるか、コマンドを直接実行する必要があります。
Anthropicが「Approveを押し続けるよりautoのほうがよい」と考える理由
Anthropicは今回の変更を、操作性の改善であると同時に、利用データに裏付けられたものだと説明しています。Claude Codeでは、ユーザーがpermissionプロンプトの97%を承認する一方、提示されたプランを拒否する割合は39%でした。Anthropicはこの差を、個々のプロンプトを吟味するより、反射的にクリックしている結果だと見ています。2026年6月時点では、アクティブなCLIユーザーの49.5%が手書きのBash allowルールを作成し、62%がbypassPermissionsまたは「don't ask again」を使い、対話型セッションの25%がbypass modeで開始されていました。
管理された調査では、この習慣が数字として示されました。Anthropicは調査会社を通じて有料のテスター1,053人を集め、各セッションのpermissionプロンプトを、明らかに危険なコマンドに1回だけ置き換えて反応を記録しました。危険なテキストが実際に実行されることはありません。人間がコマンドを見抜けた割合は13.6%（1,053人中143人）でしたが、auto modeは同じコマンドの89%（1,053件中937件）をブロックしました。
直接比較すると、auto modeは人間が承認してしまったコマンドを800件ブロックしました。一方、人間がブロックできたものの、auto modeが許可したコマンドは6件だけでした。人間の判断率は、最初の約17%から、事前に50回以上プロンプトを見た後には約5%まで低下しましたが、auto modeの性能はほぼ一定でした。
Anthropicの発表によると、本番環境と第三者によるデータも同じ傾向を示しています。2026年5月から6月にかけて、フラグが立ったセッションのうち、手動承認されたセッションでは6.3%に、ユーザーが明示的に求めていない本番レベルの被害が含まれていました。auto modeでは2.4%でした。Trajectory Labsはprompt injectionのシナリオ72件をそれぞれ10回実行し、auto modeのClaude Fable 5、Opus 5、Sonnet 5に対する720回の試行では成功例がゼロでした。対して、Codex Auto-review modeのGPT-5.6 Solでは成功率が5.83%でした。
Apollo Researchのレッドチーム評価では、リポジトリの公開範囲、gitの状態、データの扱いに関するルールを強化した結果、classifierの見逃し率が12%から7%に低下しました。Anthropicは社内で防げた事例として、オフネットワークへのアップロードがpublic paste siteへフォールバックしたケース、GPUのトレーニングジョブを脅かす約2,000個のpodに対する一括プロセス停止、請求関連ロールの過剰な権限昇格の3件も挙げています。さらに、Adobe、Nuro、Gusto、Garner Healthを含むTeamsおよびEnterpriseの導入企業では、プルリクエストが約25%増えたとしています。
切り替え後にユーザーがぶつかる問題
発表では詳しく触れられていない不満も、実際のユーザースレッドから見えてきます。特に多いのは、コミット、worktreeの整理、SSHやサーバー作業、デプロイ用コマンドなど、日常的な操作がauto modeでブロックされたり、何度も確認を求められたりするケースです。
「auto classifierはごく基本的な操作にまで許可を求めてくるのに、明示的に許可しても結局実行してくれない」— u/dfritter4（r/ClaudeCode）
特に厄介なのが、承認しても拒否を覆せない点です。ユーザーが操作を承認したにもかかわらず、ハーネス側が実行を拒否し続けるという報告が複数あり、その場合はmanual modeかターミナルへ迂回することになります。
「いったんmanualに戻し、エージェントに続行するよう伝え、手動で承認してから、またautoに戻さなければならない場面があった」— u/phoenixmatrix（r/ClaudeCode）
安全性による拒否とは別に、classifierの障害もあります。ある複数プロジェクトにまたがる障害では、ステータスページにインシデントが表示されていないにもかかわらず、各プロジェクトで「The server-side auto mode classifier gave no verdict」と表示されました。復旧するまでmanual modeへ切り替えるのが回避策でした。
品質面の不安も、デフォルト変更をめぐる議論で指摘されています。破壊的なコマンドよりも、Claudeが自律実行中に過剰設計したり、スコープから外れたり、アーキテクチャの判断を誤ったりすることを気にするユーザーもいます。こうした摩擦から、一部のユーザーは--dangerously-skip-permissionsへ戻っています。そこではgit、コンテナ、マージ前のレビューだけを頼りにしています。
Claude auto modeのままチェックポイントを残す
多くの開発者が意外に感じるデフォルトは、Claude auto modeではpushとプルリクエストの作成が許可されることです。作業中のブランチだけでなく、デフォルトブランチへのpushも対象です。force push、コミットへの秘密情報の混入、履歴の書き換えはsoft-blockのままで、明示的な意図が必要になります。「リポジトリを整理して」と指示しただけではforce pushの許可にはなりませんが、具体的な操作を指定すれば許可されます。production、release、gh-pagesのようにデプロイ先を示すブランチ名は、それぞれ本番デプロイとして個別に判断されます。
pushとPRだけを確認対象にし、それ以外ではauto modeを使いたい場合は、classifierより先に評価されるcontent-scopedのaskルールを追加します。
{ "permissions": { "ask": ["Bash(git push *)", "Bash(gh pr create *)"] } }絶対に越えてほしくない境界には、チャット上の指示ではなくpermissions.denyを使います。「レビューするまでpushしないで」という発言はコンテキストの圧縮で失われる可能性がありますが、askやdenyのルールは残ります。特定の送信先に対する拒否が繰り返される場合、classifierがそのインフラを認識できていない可能性があります。ユーザー設定または管理設定のautoMode.environmentに送信先を明記すると改善することがあります。
/permissionsのRecently deniedタブで拒否内容を確認し、rを押せば1件だけ再試行できます。設定はclaude auto-mode config、claude auto-mode defaults、claude auto-mode critiqueで確認できます。注意点は2つあります。まず、Bash(npm test)のような狭いallowルールはclassifierより先に解決されるため、見えないまま破壊的な引数を通す可能性があります。v2.1.193以降ではautoMode.classifyAllShellをtrueにすると、多少の遅延と引き換えに各シェルコマンドをclassifierで判定できます。もう1つは、カスタムのallow、soft_deny、hard_deny、environmentリストを指定すると、組み込み設定が完全に置き換わることです。組み込み設定を残すには、文字どおり"$defaults"を含める必要があります。
必要なときはオフにする
Claude auto modeは、セッション単位なら簡単に切り替えられます。CLIではShift+Tabを押してモードを切り替え、デスクトップアプリではモードのドロップダウンを使います。起動時にclaude --permission-mode manualを指定する方法もあります。変更が適用されるのは、そのセッションだけです。
manual modeを恒久的なデフォルトにするには、ユーザー設定の~/.claude/settings.jsonに次のように保存します。
{ "permissions": { "defaultMode": "manual" } }v2.1.200以降では、manualはdefaultのエイリアスです。リポジトリ単位の.claude/settings.jsonからauto modeを許可したり固定したりすることはできません。そこに設定したdefaultMode: autoやbypassPermissionsは無視されるため、オプトインとオプトアウトはユーザー設定または管理設定で行います。組織の管理者は、管理設定のdefaultModeで組織のデフォルトを固定できます。auto mode自体を完全に無効にする場合は、permissions.disableAutoModeを"disable"に設定します。v2.1.251以降では、すでに実行中のセッションにも適用されます。なお、useAutoModeDuringPlanが有効な場合、plan mode中のシェルコマンドもauto-mode classifierの判定対象になります。auto modeが利用可能な環境では、これがデフォルトです。
そのまま使うか、manual modeに固定するか
モードは、使いたい気持ちではなく、失敗したときの影響範囲で決めるのが現実的です。個人の試行錯誤、分離されたローカルリファクタリング、依存関係の更新、テスト生成、差分とテストスイートを確認したうえでのドキュメント整理は、auto modeと相性がよいでしょう。共有リポジトリで使うなら、保護対象のパス、秘密情報やデプロイマニフェストへのhard deny、そして導入前に合意したサンドボックスや使い捨てブランチが必要です。
| ワークフロー | 推奨モード | 先に設定しておくガードレール |
|---|---|---|
| 個人での探索、取り消し可能な編集 | Auto mode | Recently deniedの確認とrでの再試行を習慣化 |
| チームのリポジトリ、通常の機能開発 | push時にチェックポイントを置いたAuto mode | git push *とgh pr create *にask |
| 本番デプロイ、IAM、秘密情報、インシデント対応 | Manualまたはplan mode＋人による差分レビュー | 越えてはいけない境界にdenyルール |
| 規制対象またはHIPAA eligibleなセッション | Manual（必要ならautoへ切り替え可能） | 管理設定のdefaultMode＋変更権限を持つユーザーの監査 |
CLIとエディター連携を同じリリース系列にそろえ、管理側のデフォルトを1つ決め、保護パスとhard denyを定義します。最初の試行は、偽データを使ったdevcontainerまたは分離VMで実施し、マージ前にはgit diff、テスト実行、実際のレビューを必ず通してください。Anthropicによると、5月中旬以降のセッションの約10%でclassifierによる拒否が発生しています。
FAQ
Claude auto modeでは追加のトークン料金がかかりますか？
Anthropicによると、2026年8月7日以降、Pro、Max、Teamプランに追加料金はかかりません。Enterprise、API、クラウドプラットフォームのセッションでは、クライアント側のclassifier呼び出しが引き続きトークン使用量に計上されます。
auto modeが正当な作業をブロックしたらどうすればよいですか？
/permissionsを開き、Recently deniedタブを確認して、rを押して拒否された操作を再試行します。同じ送信先が何度も拒否される場合は、autoMode.environmentに信頼するインフラを明記してください。
mainへのpushが確認なしで通ったのはなぜですか？
auto modeでは、デフォルトブランチを含め、作業中のリポジトリにあるすべてのブランチへのpushがデフォルトで許可されます。チェックポイントを必須にするにはpermissions.askへBash(git push *)を追加し、絶対に許可しない境界にするならpermissions.denyへ追加します。
auto modeは本番作業でも安全ですか？
Anthropicは、習慣的に承認ボタンを押すよりもauto modeのほうが安全だと位置づけています。ただし、影響の大きい本番インフラの変更では、人によるレビューを推奨しています。取り消し可能な作業ではauto modeを使い、デプロイ、秘密情報、IAMではmanualまたはplan modeを選ぶのが基本です。
安全性による拒否とclassifierの障害はどう見分けますか？
安全性による拒否では、何が問題なのかが示され、通常はClaudeが別の手段を提案します。一方、「no verdict」の障害では、複数プロジェクトで書き込みやBash操作が一斉に止まります。/statusでauto-mode serverの行を確認し、障害が疑われる場合はmanual modeを試してください。
auto modeはClaude CodeとClaudeアプリで同じように動作しますか？
classifierの仕組みは共通していますが、展開時期は異なります。Claude Codeでは8月14日に先行して適用され、Claudeアプリでは翌週から展開されます。EnterpriseとAPIの各種環境は、管理者への通知が行われるまでオプトイン方式のままです。