Claude Code auto modeの中身 — 93%が承認される現実と、分類器で許可疲れを減らす設計

Anthropicは2026年3月25日、engineering blogで「Claude Code auto mode: a safer way to skip permissions」を公開しました。著者はJohn Hughes氏。Claude Codeの許可プロンプトのうち93%がユーザーによって承認されているという運用実態を出発点に、分類器(classifier)とプロンプト注入プローブを組み合わせた二層防御で「許可疲れ(approval fatigue)」を減らす設計が解説されています。本記事では、この設計の中身と、Claude Codeの利用者にとって実務的に何が変わるのかを読み解きます。

背景: なぜ「許可をスキップする安全な方法」が要るのか

Claude Codeは既定で、エージェントが新しいツールを使うたびにユーザーに承認を求めます。この設計はエージェントがユーザーの意図しない範囲に踏み込むのを防ぐためのもので、コーディングエージェントの基本動作として広く採用されています。Claude Codeの許可周りの全体像はClaude Code完全ガイド2026でまとめており、auto modeはその上に乗る発展機能と位置付けられます。

問題は、毎回の承認操作が積み重なると判断が雑になっていく点です。Anthropicの計測によると、Claude Codeのユーザーは許可プロンプトの93%を承認しているとのことです。さらに「人は時間が経つにつれて細部を見なくなる」という許可疲れの現象が、別途エンジニアリングblogでも論じられています。ほぼすべて承認するなら、毎回ダイアログを出すのは安全装置として機能していないのが現状認識です。

auto modeはこの状況に対する答えとして提示されています。承認の大半が「自動で通すのと変わらない」のなら、人間の代わりに機械的に判断する仕組みを入れて、危険なものだけをユーザーに見せる、という発想です。ただし「許可スキップ」自体は既に--dangerously-skip-permissionsフラグで可能で、これは名前の通り危険行為を素通しにします。auto modeはこの中間、つまりスキップしつつ、危険なものだけを止めるポジションを狙っています。

脅威モデル: 何から守るのかを4つに分解

Anthropicは記事の中で、auto modeで起こり得る危険な行動を4つのカテゴリに整理しています。

このうち1〜3はChatGPT / Cursor / 他のコーディングエージェントでも同様に起きる一般的なリスクで、4は将来のアラインメント研究も視野に入れた表現です。実装上の主たるターゲットは1〜3で、特にprompt injection対策が二層防御の動機になっています。

ここで重要なのは、「危険な行動が起きる原因は1つではない」と分解した上で、入力側(injection対策)と出力側(行動評価)の両方にガードを入れていることです。単一の判定器で全部を捌くより、原因に対して防御層を分けたほうが、片方の取りこぼしをもう片方が拾える可能性が上がります。

二層防御の構造: 入力側プローブと出力側分類器

auto modeの中核は、エージェントの入出力の両端に判定器を置く構造です。

入力側: プロンプト注入プローブ

ファイル読み込み・Web取得・シェルコマンドなどのツール出力は、エージェントの文脈に入る前にサーバ側のプローブで走査されます。乗っ取りを試みる文字列(「これまでの指示を忘れて〜」のような典型パターン)を検出すると、ツール出力に警告が付与され、エージェントが続けて実行する判断材料に注入の存在が反映されます。プローブ自体が指示を書き換えるのではなく、疑わしさのフラグを立てて後段に渡すという役割分担です。

出力側: トランスクリプト分類器

エージェントが次にツールを呼ぼうとするたび、その行動はSonnet 4.6で動くトランスクリプト分類器の評価を通過します。分類器は会話履歴の断片を見て「この行動を許可するか / 止めてユーザーに確認するか」を判定します。

二層に分けた狙いは、injection検出と行動評価で必要な視点が違う点にあります。前者は文字列パターン主体の検査、後者は文脈と意図を踏まえた行動評価で、得意な機構が違います。片方の専門性に寄せると、もう片方の取りこぼしが出やすいので、別々の機構として配置されています。

分類器の二段構成: 高速フィルタと深い推論の使い分け

分類器自体もまた二段構成になっています。

1. 第一段: 単一トークンフィルタ ツール呼び出しを「yes(止める) / no(通す)」の1トークンで即決する高速判定。低レイテンシ・低コストで通常の操作を素通しします。
2. 第二段: chain-of-thought推論 第一段が「止める」と判定したものだけ、より深い推論で再評価します。誤検出を絞り込むための工程で、第一段で疑わしいと出ても第二段で覆れば通します。

この設計が効くのは、実際に止めるべき行動が全体のごく少数だからです。ほぼ全てを高速で通し、怪しいものだけ深く考える、という効率配分が成立します。逆に常時chain-of-thoughtを動かすと、レイテンシとコストが許可疲れ以上の体験悪化を生むため、二段に分けるのが現実解になっています。

性能の数値は以下の通りです(本文Table 1より)。

FPR(false positive rate, 偽陽性率)は「本来通してよかったのに止めてしまった割合」、FNR(false negative rate, 偽陰性率)は「本来止めるべきだったのに通してしまった割合」です。実トラフィックでは第一段単独で8.5%だったFPRが、二段目を通すと0.4%まで下がっており、二段構成の効果が定量的に出ています。

許可決定のティア構造: どの操作がどう判定されるか

auto modeでは、操作のリスクに応じて3層のティアが用意されています。

Tier 1とTier 2は「安全と分かっているものに毎回分類器を回す必要はない」という効率設計で、Tier 3が分類器の本領発揮の場です。分類器が動かない領域があるのは抜け穴に見えますが、ここはユーザー設定とプロジェクト境界という確定した安全条件で守る、という役割分担で整理されています。

Claude Codeの設定面の詳細はClaude Code設定の全項目、セキュリティ周りの全体像はClaude Codeセキュリティの考え方で扱っているので、ティアの位置付けと自分の運用設定がどう噛み合うかは、そちら側の文脈と合わせて見ると理解しやすくなります。

設計上の工夫: 分類器を「説得」されないために

実装の細部にいくつか興味深い判断があります。

アシスタントの説明文とツール出力を剥がす

分類器に渡す前に、エージェントが書いた説明文や説得的な推論を取り除いています。理由は、エージェントが「この操作は安全です、なぜなら〜」のような説得を生成して分類器を誘導するのを防ぐためです。分類器は行動そのものを評価する立場で、その行動を取った理由は判断材料にしない、という割り切りです。

マルチエージェントの委譲点で監視する

サブエージェント呼び出しでは、分類器が委譲時と戻り時の両方で動きます。子エージェントに渡す指示が乗っ取られていないか、戻ってきた成果物に注入が紛れていないかを、それぞれの方向で評価します。エージェント連携が深くなるほど経路が増えるので、各境界で判定を入れるのは合理的です。

Deny-and-continue: 拒否の連鎖を抑える

分類器が止めた場合、auto modeは即座にユーザーへ確認を求めるのではなく、エージェントに拒否を伝えて続行させます。これにより1つの拒否でセッション全体が止まるのを避けつつ、3回連続で拒否される、または通算20回拒否されると、流れがおかしいと見なしてユーザー確認に切り替えます。「拒否の閾値」を入れることで、無限ループや遠回りで危険な操作を達成しようとするパターンを抑制する作りです。

編集視点 — auto modeは「許可をなくす」のではなく「許可の質を上げる」設計

ここまでを整理すると、auto modeのポイントは「許可プロンプトを減らすこと」そのものではなく、ユーザーに見せる許可プロンプトの質を上げることにあります。93%が形骸化しているプロンプトを止めて、本当に判断が必要なものだけを残す、という再配分です。

これはClaude Codeのレベルアップというよりも、コーディングエージェント全体に対するAnthropicの問題提起として読めます。承認の高い受諾率は他社のエージェントでも同様に起きていると見られ、許可疲れは業界共通の課題です。Anthropicが分類器を入れて0.4%のFPRと17%のFNRという非対称な許容を選んだことは、「過剰に止めるくらいなら、ある程度の取りこぼしを残してでもユーザー体験を守る」という設計判断の表明とも読めます。

その上で、17%のFNRは残るリスクを正直に出している点も注目に値します。「完璧ではないが、無防備よりは大幅に安全」というスタンスは、AUPの観点でも誠実です。auto modeを使う側の意識としては、「これで全部安全になった」ではなく「危険の母数が大きく下がった」として運用するのが実態に合います。

エージェント周りの設計思想はClaude Codeワークフロー設計でもまとめており、auto modeは「自動化を進めつつ、人間の判断を要所に残す」流れの一例として位置付けられます。

まとめ

Claude Code auto modeは、許可プロンプトの93%が承認される運用実態を出発点に、入力側のプロンプト注入プローブと、Sonnet 4.6で動く二段構成のトランスクリプト分類器を組み合わせた二層防御として設計されています。Tier 1〜3の許可決定構造、サブエージェントの委譲点での監視、deny-and-continueと閾値ベースのユーザー確認といった実装細部は、いずれも「許可疲れを減らしつつ、判断を残すべき場所を残す」方向で整理されています。

実トラフィックでFPR 0.4% / overeager事例でFNR 17%という数値は、auto modeが完璧な防壁ではなく、許可の質を底上げする仕組みであることを率直に示しています。Claude Codeを長時間運用するチーム、自動化と安全性のバランスを設計するエンジニアには、本記事の解説と合わせて、自分たちの利用形態でTier 3に何が落ちるかを一度確認しておく価値がありそうです。