その権限プロンプト、読んでますか？ — Claude Code の auto mode がデフォルトになった

はじめに

Claude Code の権限プロンプト、正直ちゃんと読んでますか？

筆者は読んでいるつもりでした。でも夕方の疲れた頭で、20回目の「Bash command を実行していいですか？」に対して自分が何をしているかというと、内容を2秒眺めて Enter。これ、レビューしてるというより儀式ですよね。

Anthropic もそれを分かっていて、2026年8月14日から Claude Code の auto mode が Pro / Max / Team プランのデフォルトになりました。公式ブログ Auto mode is now the default in Claude Code には、その判断の根拠になったデータが赤裸々に書かれています。いわく、ユーザーは権限プロンプトの97%を承認している。ですよね、という数字です。

筆者はこれまで「権限プロンプトが多い → 読み取り専用コマンドを allowlist に登録して減らす」という運用をしてきて、グローバルの settings.json には手で育てた許可ルールが54個あります。auto mode がデフォルトになった今、この畑はどうなるのか。公式ブログとドキュメントを読み込みつつ、実際に切り替えた設定と合わせて整理してみます。

元記事はこちら: https://claude.com/blog/auto-mode-default-in-claude-code

TL;DR

8月14日から Pro / Max / Team の新規セッションは auto mode で開始（Enterprise は当面オプトイン）
auto mode は「全部自動実行」ではなく、分類器（第2のモデル）が毎回のツール実行を審査し、危険な操作だけブロックする仕組み
根拠データが強烈: 人間のレビューは危険コマンドの 13.6% しか捕捉できず、auto mode は 89% をブロックした（1,053名の統制実験）
手動承認セッションの方が、意図しない有害アクションを含む率が高い（6.3% vs 2.4%）
既存の allowlist は無駄にならない。narrow なルールはそのまま生き、逆に ask ルールで「ここだけは毎回確認」というチェックポイントも作れる
戻したければ Shift+Tab で切り替え、または settings.json の defaultMode で固定

auto mode とは何か

auto mode は permission mode の一つで、位置づけとしてはこうなります：

モード	挙動
default	書き込み系の操作は毎回ユーザーが確認
acceptEdits	ファイル編集と基本的なファイル操作は自動
plan	読み取りのみで計画を立てる
auto	全操作を実行しつつ、分類器が毎回審査してブロック判断
bypassPermissions	全操作をノーチェックで実行（隔離環境用）

ポイントは、auto mode が「確認を全部スキップする」モードではないことです。bypassPermissions とは別物で、毎回のツール実行を第2のモデル（分類器）がレビューし、ユーザーの指示にない危険な操作をブロックします。ブロックされた場合、Claude は安全な代替案を探すか、ユーザーに確認を求めてきます。

面白いのは逃げ道の設計で、3回連続、またはセッション中20回ブロックされると、自動的に手動確認モードに切り替わります。分類器と揉め続けるくらいなら人間に戻せ、という割り切りですね。

なぜデフォルトにしたのか: 「人間のレビュー」の実力

公式ブログがこの変更の根拠として出してきた数字が、なかなか身も蓋もないです。

ユーザーは権限プロンプトの 97%を承認している
一方、Claude が「計画」を提示したときは 39%が拒否される。個別の権限プロンプトの拒否はわずか3%
1,053名の統制実験では、人間のレビューは危険コマンドの 13.6% しか捕捉できなかった。auto mode の分類器は 89% をブロック
手動承認のセッションの方が、意図しない有害アクションを含む率が高かった（6.3% vs 2.4%）

つまり、計画レベルの判断では人間はちゃんと機能しているのに、コマンド単位の承認になると「読まずに Enter」になっている。権限プロンプトは安全装置として機能していないどころか、機能している気にさせるぶん悪い、というデータです。

外部のレッドチームも入っていて、Apollo Research の敵対的テストでは対策後に攻撃の見逃し率が12%から7%に低下。Trajectory Labs の評価では、720件の攻撃試行が auto mode の Claude（Fable 5 / Opus 5 / Sonnet 5）に対して1件も成功しなかったそうです（競合エージェントの攻撃成功率は5.83%）。

Anthropic 社内でも、外部への公開アップロードを阻止した例、破壊的な大量 pod 操作を寸前で止めた例、read-only のつもりの依頼が full admin への権限昇格になりかけたのを検出した例と、実際に3件のインシデントを防いだと書かれています。

ブロックの基準: hard deny と soft deny

分類器の判断には2段階あります。

hard deny（問答無用でブロック）: curl | bash のようなコード直接実行、外部への機密データ送信、force push、terraform destroy のようなリソース破壊、リバースシェルなど。

soft deny（文脈次第でブロック、ユーザーの意図があれば通る）: 本番デプロイ、クラウドストレージの大量削除、IAM 権限の付与など。

地味に便利だと思ったのは、会話の中で言った境界を分類器が拾うことです。「レビューが終わるまで push しないで」と言っておけば、それがそのままブロック条件になる。ただし会話内の境界はコンテキストの compact で消えるので、恒久的なルールは設定に書け、とドキュメントは釘を刺しています。

54個の allowlist はどうなるのか

さて、筆者の本題です。筆者の ~/.claude/settings.json には、WebFetch(domain:github.com) みたいな読み取り系の許可ルールが54個並んでいます。権限プロンプトに疲れるたびに、頻出の安全なコマンドを登録して育ててきた畑です。auto mode で無駄になるのかと思いきや、ドキュメントを読むと関係はこう整理されていました：

deny ルール → 分類器より先に問答無用でブロック
ask ルール → 分類器より先に必ずプロンプト表示
allow ルール → マッチすれば分類器をスキップして実行
どれにも当たらなければ → 分類器が判定

つまり narrow な allow ルール（Bash(npm test) など）はそのまま生きて、分類器の審査すら通らず即実行になります。allowlist は「プロンプトを減らす道具」から「分類器のショートカット」に役割が変わったわけです。畑は無駄になりませんでした。よかった。

そして個人的に発見だったのが ask ルールの使い方です。auto mode は大半を自動で通すからこそ、「ここだけは毎回自分が見る」というチェックポイントを明示的に置ける。たとえば git push には必ず確認を入れたい人は、Bash(git push *) に ask ルールを設定すれば auto mode でも毎回聞いてくれます。全部を見るのをやめる代わりに、見る場所を自分で選ぶ。これが auto mode 時代の権限設計なんだと思います。

切り替えてみた・注意点

筆者もさっそく defaultMode: auto に切り替えました。とはいえ切り替えたばかりなので、ブロックとの付き合い方はまだ語れるほどの体験がありません。ここは数週間使ってから続報を書きます（分類器と3連続で揉めて手動に戻された、みたいな話ができるようになっているはず）。

代わりに、調べていて引っかかった注意点を置いておきます：

プロジェクトの .claude/settings.json に defaultMode: "auto" を書いても無視されます。セキュリティ上の理由で、auto の指定はユーザーのグローバル設定か CLI フラグのみ有効です。リポジトリをクローンしただけで auto mode にさせられる、を防ぐためですね
claude -p（非対話モード）や Agent SDK は引き続き default で始まります
対応モデルに制限があります（Opus 4.6+ / Sonnet 4.6+ / Fable 5。古いモデルでは使えません）
分類器に誤ブロックされたら /permissions の「Recently denied」から retry マークで上書きできます
手動に戻したいときは Shift+Tab。組織管理者は managed settings の disableAutoMode で無効化もできます

所感

「AI に全部任せるのは怖いから、1個ずつ確認できる方が安全」という直感が、データで否定されたのが面白い記事でした。97%承認している時点で、確認は安全装置ではなく単なる摩擦だった。それなら摩擦を取り除いて、審査は疲れない分類器に任せ、人間は計画レベルの判断（ちゃんと39%拒否できているところ）に集中する方が、実測でも安全だった、と。

安全のためにやっていた儀式が実は安全に貢献していなかった、というのは権限プロンプトに限らず思い当たる節があります。形骸化したチェックリスト、読まれない確認ダイアログ。「人間が確認してるから大丈夫」の「確認」が本当に機能しているか、たまに疑った方がよさそうです。

まとめ

8月14日から Pro / Max / Team プランで auto mode がデフォルトに。分類器が毎回のツール実行を審査する仕組みで、ノーチェックの bypassPermissions とは別物
根拠データ: 権限プロンプトの97%は承認されており、人間のレビューは危険コマンドの13.6%しか捕捉できない（分類器は89%）
既存の allowlist は分類器のショートカットとして生き続ける。ask ルールで「ここだけは毎回確認」のチェックポイントを置くのが新しい権限設計
会話で伝えた境界（「push しないで」等）も分類器が拾う。ただし恒久ルールは設定に書く
手動に戻すのは Shift+Tab、固定は settings.json の defaultMode

ブロック体験の続報はまた書きます。ではまた！