2026年8月14日、Pro/Max/Teamプランの新規セッションでauto modeが既定になった。個別の許可プロンプトは97%が承認されていた——読まれずにクリックされる形骸化した確認だったと公式は認めている。何が変わり、何を確認すべきかを一次情報から読み解く。
1,053人の実測データ（危険コマンド検出率：人間13.6% 対 auto mode 89%）と、Nuro・Gusto・Garner Healthの本番運用の線引きを、公式ブログの一次情報から翻訳します。
Claude Codeは、ツールを実行するたびに「これを実行していいですか」と個別に確認する許可プロンプト方式を標準にしてきた。2026年8月14日、この前提がPro・Max・Teamプランの新規セッションで変わった。auto modeが既定になったのだ。
公式ブログが理由として挙げた数字が率直だった。従来の許可プロンプトは97%が承認されていた。一方、Claudeが立てた作業プラン（何をどう進めるかの提案）は39%が却下されている。同じ「AIの提案にYES/NOを出す」行為でも、プラン提案には人間はちゃんと吟味して口を出すのに、実行の許可プロンプトはほぼ反射でクリックしている——公式はこの対比を、個別許可プロンプトが「安全確認」として機能していなかった証拠として扱っている。
代わりに導入されたのが、ツール呼び出しの内容を都度検査する分類器（classifier）によるチェックだ。危険な操作だけを止め、それ以外は流す。人間の目視確認から、機械的な内容検査へ主役が交代した。分類器のコストはPro・Max・Team利用者には課金されない。
「機械的なチェックの方が甘いのでは」という直感に反する結果が出ている。
有償テスター1,053人による統制テストで、人間によるレビューが危険なコマンドを検出できたのはわずか13.6%だったのに対し、auto modeは89%を検出した。数字だけ見ると、機械的な分類器の方が人間の目視確認より圧倒的に見落としが少ない。
同じテストの中で、auto modeは人間が承認してしまった危険なコマンドを800件ブロックした。逆にauto modeが許可したものを人間が止めたのはわずか6件。片方向に極端に偏った差が、単なる誤差ではないことを示している。
テスト環境だけでなく、実際の利用データでも意図しない害を防いだ頻度は手動承認時の2倍以上だった。「テストでは良かったが実運用は別」という定番の落とし穴が、今回は起きていないと公式は説明している。
この数字が意味するのは、「人間の確認が形骸化していた」という話であって、「人間の判断力が機械に劣る」という話ではない。97%を反射で承認していた時点で、そのプロンプトはもう安全弁として機能していなかった——分類器はその空いた穴を埋めただけだ。
既定化と同じタイミングで公式が公開した実務編には、Teams・Enterprise導入企業3社の運用実例が載っている。共通しているのは、auto modeを全部任せにはしていないという点だ。
結果として、Claude Code全体の利用でセッションは以前の既定より9倍長く中断なく実行されるようになった。Nuroの例では夜10時から翌朝5時まで無人で稼働し、プルリクエストを3件生成している。Teams・Enterprise導入企業では、auto mode利用者は約25%多くPRを配信しているという数字も出ている。
つまり「速くなった」のは、危険な操作を止めなくなったからではなく、止めるべき箇所だけを事前に絞り込んでおいたから、途中で人間の判断待ちが挟まらずに済んでいる、という構造だ。
この変更は新規セッションに自動で適用される。気づかないまま使い続けている個人開発者も多いはずなので、まず自分の環境を確認したい。
Shift+Tabでモードを切り替えられる。今どのモードで動いているかもここで確認できる。defaultModeの管理設定で、組織全体の既定モードを強制できる。実務での線引きは、Nuro・Gusto・Garner Healthの3社が示した通りだ。「何を自動に任せ、何を手動に戻すか」を先に自分で決めておく——危険なコマンドの拒否リスト、対人コミュニケーション系ツールの除外、外部連携（MCP等）の検査、これくらいは個人開発でも最初のひと手間で設定できる。
「どのタスクにどこまで任せるか」をエージェンシーとオーケストレーションの2軸で決める考え方は自律性レベルを2軸で決める記事で扱った。今回のauto mode既定化は、その判断をモデル任せの分類器に一段委ねる話でもある。どのモード・エフォートを選ぶかの基本整理はモデルとエフォートは別軸という記事もあわせて読むと繋がりやすい。