Claude Code の auto mode が既定に — Pro・Max・Team で 2026-08-14 から
Anthropic は Claude Code の auto mode を Pro / Max / Team プランの既定モードにすると発表した。適用は 2026-08-14 で、以降これらのプランの新規セッションは auto mode で起動する。ツール実行のたびに人へ承認を求める代わりに、分類器が安全性を判定する。Enterprise / API / クラウド経由は当面 opt-in のままだが、1か月以内に同様へ切り替える予定と明記された。
ニュース原文を読む ↗要約
Anthropic は 2026-08-07、Claude Code の auto mode を Pro / Max / Team プランの既定モードにすると発表しました。適用開始は 2026-08-14 で、以降これらのプランで開始する新規セッションは auto mode で立ち上がります。これまでは利用者が明示的に有効化する必要がありました。
auto mode は、ツールを実行するたびに人へ承認を求める代わりに、分類器がリクエストの安全性を評価して自律的に判断する仕組みです。不可逆な操作、破壊的な操作、実行環境の外へ出る操作をブロックする設計になっており、ブロックされた場合 Claude はより安全な代替手段を探すか、明示的な承認を求めます。
Anthropic は、統制環境での評価において auto mode が危険なコマンドの 89% をブロックしたのに対し、人間のレビュアーが検知できたのは 13.6% だったとしています。この数字の対比が、今回の既定変更の根拠として示されています。分類器には、データアクセスに関する明示ルール、破壊的操作の前に git status を確認する挙動、プロンプトインジェクションの検査、そして利用者の指示に関わらずデータ持ち出しを拒否する hard deny ルールが入っています。
Enterprise / API / AWS Bedrock / Google Cloud / Microsoft Foundry 経由の利用は当面 opt-in のままですが、1か月以内に同様へ切り替える予定と明記されています。今回の変更は個人プランで先に始まるだけで、企業契約が対象外になるわけではありません。
モードの切り替えは、CLI では Shift+Tab、デスクトップアプリではモードのドロップダウンから行います。既に別の既定を設定していた利用者には、切り替えを促す一度きりのプロンプトが出る場合があります。
同日に公開された「Running auto mode in production」では、運用側の指針として次が挙げられています。スキル設定で再帰削除や危険コマンドを明示的に拒否すること。Slack やメールなど対人コミュニケーションの自動承認を切ること。MCP のトラフィックを、ツールガードとプロンプト検査を持つプロキシ経由に寄せること。Terraform / AWS / 直接 API 呼び出しなど本番インフラの変更には手動確認を残すこと。
何が変わったか
- Pro / Max / Team の新規セッションが 2026-08-14 から auto mode で開始する
- 分類器がツール実行の安全性を評価し、承認プロンプトの大半を置き換える
- Enterprise / API / AWS / Google Cloud / Microsoft Foundry は当面 opt-in（1か月以内に変更予定）
- 管理者は managed settings の
defaultModeで既定モードを固定できる - 管理者は
disableAutoModeで auto mode 自体を組織的に無効化できる - 利用者は Shift+Tab（CLI）またはモードのドロップダウン（デスクトップ）で切り替えられる
- 既に別の既定を設定していた利用者には、一度きりの切り替えプロンプトが出る場合がある
業務インパクト（一般企業向け）
この変更で最も重要なのは、期限が切られているという点です。2026-08-14 までに何も決めなければ、決めなかったこと自体が「auto mode を受け入れる」という選択になります。管理者が能動的に判断すべき変更が、放置すると自動的に片方へ倒れる構造になっています。
まず整理すべきは、社内の運用ルールが何を前提に書かれているかです。多くの組織では、Claude Code の導入時に「危険な操作は承認ダイアログで人が止める」という説明で稟議を通しています。この前提が既定では変わります。止めるのは人ではなく分類器になり、人が見るのは分類器が判断できなかった残りだけになります。ルール文書に「実行前に必ず確認画面が出る」と書いてあるなら、それは 2026-08-14 以降、既定では正確でなくなります。
判断の材料として、Anthropic が出した 89% 対 13.6% という数字の読み方には注意が必要です。これは「auto mode の方が安全」という主張ですが、同時に「人間の承認は思ったほど機能していなかった」という主張でもあります。実際、承認ダイアログを何十回も出されると、内容を読まずに通す状態に陥るのは誰でも経験があります。従来の運用が本当に機能していたかを点検せずに「人が見ているから安全だった」と前提を置くと、比較を誤ります。一方で、この数字は統制環境での評価であり、自社の実際の作業内容やリポジトリ構成で同じ比率になる保証はありません。
管理者が 2026-08-14 までに決めるべきことは3つあります。第一に、defaultMode で既定を固定するか、Anthropic の既定に従うか。第二に、disableAutoMode で無効化する対象範囲があるか（本番環境に触れるチーム、顧客データを扱うチームなど）。第三に、auto mode を受け入れる場合に、公式が挙げる運用指針のうちどれを実装するかです。
運用指針のうち、優先度が高いのは対人コミュニケーションの自動承認を切ることです。ファイルの書き換えは間違えても直せますが、Slack やメールの送信は取り消せません。auto mode は不可逆な操作をブロックする設計とされていますが、「顧客へメールを送る」が不可逆と判定されるかは分類器の解釈に依存します。ここは組織側で明示的に拒否設定を書いておく方が確実です。同様に、Terraform や AWS の直接操作は手動確認を残すのが妥当です。
MCP のトラフィックをプロキシ経由にする指針も、実務上は重い割に効きます。MCP サーバー経由で外部システムに触る構成を持っているなら、auto mode の分類器は「Claude Code から見て安全か」しか判断できません。外部システム側での影響までは見ていないため、プロキシ層でのツールガードが実質的な最後の砦になります。
移行の進め方としては、2026-08-14 を待たずに一部のチームで先に auto mode を有効化し、1週間ほど実際の作業で回してから全体方針を決めるのが現実的です。既定になってから初めて挙動を見る状態にすると、問題が起きたときに切り分けと対処を同時にやることになります。
副業・個人活用視点
個人で Claude Code を使っている場合、2026-08-14 以降は特に何もしなくても auto mode になります。多くの人にとっては単純に作業が速くなる変更です。承認ダイアログで手が止まる回数が大幅に減ります。
ただし、意識しておくべき場面が2つあります。
1つ目は、クライアントのリポジトリで作業しているときです。自分の個人プロジェクトなら、多少乱暴な操作が走っても取り返しがつきます。受託案件のリポジトリでは事情が違います。分類器は「このリポジトリは他人のもので、勝手にブランチを消すと信用問題になる」という文脈までは判断しません。技術的に安全な操作と、契約上やってよい操作は別物です。クライアント案件では Shift+Tab で明示的にモードを戻す、という運用を自分のルールにしておく価値があります。
2つ目は、本番環境に触れる作業です。副業案件では、開発環境と本番環境の分離が甘いことが珍しくありません。デプロイスクリプトや DB のマイグレーションを Claude Code から走らせている構成なら、auto mode の既定化は事故の期待値を上げます。公式指針が「本番インフラの変更には手動確認を残せ」と書いているのは、まさにこの領域です。
一方で、案件の作り方としては機会にもなります。企業側の管理者は、2026-08-14 という期限に対して defaultMode / disableAutoMode の方針を決めなければなりません。これは技術判断というより、リスク許容度をどこに置くかという整理の作業です。「Claude Code を導入したが運用ルールが曖昧なまま」という状態の組織は多く、今回の期限はその整理を持ちかける明確な口実になります。設定値を書き込む作業自体は数十分ですが、どのチームにどの設定を当てるかを決める過程には、業務理解とヒアリングが要ります。そこが提案価値になる部分です。
提案する際は、auto mode を止めさせる方向で話を進めないことです。公式の評価データが「人間の承認より安全」と主張している以上、単純な無効化は説明が難しくなります。有効にしたうえで、対人コミュニケーションと本番インフラという2つの穴を塞ぐ、という設計にする方が筋が通ります。