8 月 14 日に既定が変わる
結論から言うと、2026 年 8 月 14 日から Claude Code の新規セッションは auto mode で始まります。 対象は Pro・Max・Team プランです。
公式の記述はこの一文です。
Starting on August 14, new sessions on Pro, Max, and Team plans will run in auto mode.
判断の軸を先に置きます。これは「承認をやめる」変更ではなく、「承認を求める場所を絞る」変更です。 ここを取り違えると、必要以上に警戒するか、逆に油断するかのどちらかになります。
何が変わるのか
auto mode は、ツール呼び出しのたびに確認を求める代わりに、分類器が危ないと判定したものだけ確認を挟む 実行モードです。判定の対象になるのは、不可逆な操作、破壊的な操作、環境の外へ影響する操作です。
| モード | 確認のタイミング |
|---|---|
| 従来 (手動) | ツールを呼ぶたびに確認 |
| auto mode | 危ないと判定されたときだけ確認 |
止まる回数は減ります。ただし、危ない操作は止まります。 承認という仕組みそのものが外れるわけではありません。
公表されている数値
安全性について、2 つの数値が示されています。ここは判断材料になるので、そのまま引きます。
危険なコマンドの検出率。 有償テスターを対象にした管理実験で、人によるレビューが 13.6% だったのに対し、auto mode は 89% でした。
実運用での有害な操作。 手動承認のセッションでは 6.3% に有害な意図しない操作が含まれていたのに対し、auto mode では 2.4% でした。
逆に言えば、人が全部を承認する運用のほうが危険を見逃していた という結果です。直感には反しますが、理由は想像がつきます。承認を求められる回数が多いと、内容を読まずに通すようになるためです。
注意
この数値は「auto mode なら安全」を意味しません。人の承認が形骸化しやすいことを示しているだけです。判断は依然として人が持ちます。
「分類器が判定する」とはどういうことか
止める・止めないを決めているのは、固定のルール表ではありません。操作の内容を見て、危ないかどうかを判定する仕組みが挟まっています。
この違いは実務に効きます。ルール表の方式だと、書かれていないコマンドは素通りします。判定する方式だと、見たことのない形でも危なさで捕まえられます。前掲の検出率の差は、ここから来ていると考えられます。
一方で、判定である以上は外すこともあります。危なくないものを止める側に外れれば作業が止まり、危ないものを通す側に外れれば事故になります。 どちらの方向にも外れうる、という前提は持っておいてください。
そのうえで、外れる可能性を織り込んでも回るように作るのが権限設計です。判定の精度に依存しすぎない範囲設定 をしておけば、どちらに外れても被害が限定されます。
影響を受けるのは誰か
対象を整理します。
| 契約 | 8 月 14 日以降 |
|---|---|
| Pro | 既定で auto mode |
| Max | 既定で auto mode |
| Team | 既定で auto mode |
| Claude Enterprise | 当面 opt-in |
| Claude API | 当面 opt-in |
| Claude Platform on AWS / Amazon Bedrock | 当面 opt-in |
| Google Cloud の Agent Platform | 当面 opt-in |
| Microsoft Foundry | 当面 opt-in |
全社導入で Enterprise を使っている場合、今回の変更では何も起きません。 影響するのは、個人やチーム単位で Pro・Max・Team を使っている場合です。
社内で契約が混在しているなら、そこを先に確認してください。「うちは Enterprise だから関係ない」と一括りにすると、個人契約で使っている人が取り残されます。
既にデフォルトを変えている場合
自分で別のデフォルトを設定している場合の扱いも案内されています。
If you've already set a different default yourself, you may get a one-time prompt asking whether you want to switch to auto mode. If you have a pinned default, nothing changes for you.
一度きりのプロンプトが出て、切り替えるかを聞かれます。 固定 (pinned) にしている場合は、何も変わりません。
意図せず切り替わるのを避けたいなら、8 月 14 日より前に固定しておくのが確実です。 プロンプトが出たときに慌てて選ぶより、先に決めておくほうが落ち着きます。
FIXIT
Tsukasa逆です。数値上は、人が全部承認する運用のほうが見逃しています。
FIXITTsukasa判断の軸は回数です。多すぎると、読まずに通すようになります。
数値をどう読むか
公表された数値は自社で追試できないものなので、読み方を添えておきます。
測っているのは「危険なコマンドを止められたか」であって、「成果物の質」ではありません。 auto mode にすると仕事の質が上がる、という話ではないので、そこは分けて考えてください。
比較対象は「人が全部を承認する運用」です。 権限設定で範囲を適切に絞っているチームと比べた数値ではありません。既に許可を絞り込んでいるなら、手動側の 13.6% はもっと高いはずです。
サンプルは有償テスターと実運用のログです。 自社の作業の性質とは異なる可能性があります。
そのうえで、方向としては信じてよい数値だと考えます。 承認の回数が多いほど読まれなくなる、というのは実感とも合います。逆に言えば、この数値は auto mode の優秀さより、人の承認が量に弱いこと を示しているものとして受け取るのが正確です。
受け入れるかどうかの判断軸
そのまま受け入れるか、手動に戻すか。判断の軸は 1 つで、入力の出どころです。
自分で書いた指示だけを与えている作業なら、auto mode で問題ありません。むしろ承認の回数が減るぶん、残った確認を読むようになります。
一方、外部から来た内容を読ませている作業では、慎重に構える理由があります。 Web の内容、届いたファイル、チケットの本文。これらに指示めいた記述が混ざっている場合、確認の回数が減ることは経路が太くなることを意味します。
| 使い方 | 判断 |
|---|---|
| 自分が書いた指示だけで作業する | auto mode のままでよい |
| 外部から来た内容を読ませる | 手動に戻すか、範囲を絞る |
| 本番環境に触れる作業 | 手動に戻す |
| 初めて任せる種類の作業 | 手動で挙動を見てから決める |
切り替えが Shift+Tab で済むので、作業ごとに変えられます。 一律で決める必要はありません。
切り替えたあとに見るもの
受け入れると決めたら、しばらくは 2 つだけ見ておいてください。
1 つは、確認を求められた回数。極端に減ったなら、それは判定が緩いのではなく、そもそも危ない操作をしていなかったということです。逆に頻繁に止まるなら、権限の設定が広すぎる可能性があります。
もう 1 つは、止まったときに内容を読んでいるか。回数が減ったぶん、1 回あたりを読むようになっていれば狙いどおりです。減った回数すら読まずに通しているなら、モードの問題ではありません。
コツ
最初の 1 週間だけでよいので、止まった内容を意識して読んでみてください。何が「危ない」と判定されるかの感覚が掴めると、その後の判断が速くなります。
8 月 14 日までにやること
準備としてやることは多くありません。
- 自分の契約が対象かを確認する (Pro・Max・Team か)
- 固定したい設定があるなら、先に固定する
- チームで使っているなら、切り替わる旨を一言流す
- 外部入力を扱う作業がある人には、モードの戻し方を伝える
3 番が抜けると、当日に「承認が出なくなった」という問い合わせが来ます。変わること自体を知っていれば、それは問い合わせになりません。
4 番は、該当する人にだけ伝えれば足ります。全員に長い説明を配ると読まれません。
周知の文面は 2 行で十分です。「8/14 から承認の出方が変わります。戻したい人は Shift+Tab で切り替えられます」。理由や数値は、聞かれてから答えれば足ります。
承認の設計そのものを見直す機会でもある
少し引いた話をします。今回の変更が示しているのは、「全部止めれば安全」という設計が実際には機能していなかった ということです。
承認を求める回数が多すぎると、人は読まずに通します。これは注意力の問題ではなく、量の問題です。安全のために全部を止める設計は、結果として何も見られない状態を作ります。
自社の権限設定を見直すときも、同じ観点が使えます。許可の範囲を適切に絞ることは、承認の回数を減らし、残った承認を読ませるための施策でもあります。この考え方は Claude Code の権限と settings.json 設計 に整理しています。
なお、権限チェックそのものの不具合が直近で連続して修正されています。auto mode を使うかどうかに関わらず、バージョンは上げておいてください。経緯は Claude Code の権限バイパス修正が続いた 3 リリース にまとめました。
よくある誤解を 3 つ
社内で説明していると出てくる誤解を挙げておきます。
「auto mode は何でも勝手にやる」。 違います。不可逆・破壊的・環境の外へ影響する操作は止まります。止まる範囲が絞られただけで、無条件に進むわけではありません。
「手動に戻せば安全」。 これも正確ではありません。手動でも、内容を読まずに通していれば同じことです。公表された数値が示しているのは、むしろこちらの危うさです。
「Enterprise なら永久に関係ない」。 現時点では opt-in ですが、公式には今後 1 か月ほどで展開するとも書かれています。判断を先送りできるだけで、免除ではありません。
3 つ目が実務では効いてきます。いま Enterprise を使っていて何もしなくてよい状態でも、同じ判断が近いうちに回ってきます。 今回のうちに方針を決めておけば、そのときは配るだけで済みます。
組織で使っている場合の考え方
Team プランで使っているなら、組織としてどうするかを決めておくほうが揃います。 個人ごとにばらつくと、事故が起きたときの説明が難しくなります。
決めることは 2 つです。
既定をどうするか。 そのまま auto mode を受け入れるか、手動に固定するか。数値を見るかぎり、受け入れる側に妥当性があります。
例外をどう扱うか。 本番環境に触れる作業や、外部の内容を扱う作業で手動に戻す、というルールを 1 行決めておきます。
全社規模での展開まで進んでいるなら Claude Code 全社導入 完全ガイド も合わせて参照してください。Enterprise では当面 opt-in なので、今回は判断を先送りできます。 ただし公式には今後 1 か月ほどで展開するとも書かれているので、そのうち同じ判断が回ってきます。
決めた内容は、口頭ではなく 1 行でよいので書き残してください。この種の既定は、今後も変わります。 そのたびに議論をやり直すより、「当社は原則こう。例外はこの場合」と書いてあるほうが、次回は差分の確認だけで済みます。定着の進め方そのものは Claude Code を現場に定着させる進め方 にまとめています。
まとめ
- 2026 年 8 月 14 日から、Pro・Max・Team の新規セッションが auto mode で始まる
- 承認が無くなるのではなく、危ないと判定されたものだけ確認が入る形になる
- 公表値では、危険なコマンドの検出率が人 13.6% に対し auto mode 89%
- Enterprise・API・クラウド経由は当面 opt-in。全社導入なら今回は影響しない
- 既定を自分で変えている人には一度きりのプロンプトが出る。固定していれば何も変わらない
- 判断の軸は入力の出どころ。外部の内容を扱う作業では手動に戻す
- Enterprise も今後 1 か月ほどで展開の予定。免除ではなく、判断の先送りにすぎない