承認ダイアログは出るのに、確認はだんだん短くなる
Claude Codeがシェルコマンドを実行するたびに承認を求めると、最初は内容を注意深く読みます。しかし、テストやファイル探索が続くにつれて、承認ダイアログは安全装置というより作業を中断する通知のように感じられます。やがて広範な許可ルールを作ったり、権限確認を省略したくなったりします。
実際の利用データでも、権限リクエストの97%が承認されました。ただし、この数字だけで、すべてのユーザーが内容を読まずに反射的にクリックしたと断定することはできません。観測期間とプロンプト総数は公開されておらず、大半は通常の無害な日常コマンドだった可能性もあります。正確な解釈は、繰り返される承認がリスクを適切に見分ける仕組みなのか、あらためて検討する理由が生まれたという程度です。
Anthropicはこの問題に対応するため、2026年8月14日からPro・Max・Teamプランの新しいセッションで、オートモードを組み込みの開始モードとして適用しました。すでに別のデフォルトモードを指定しているユーザーと組織の管理設定は維持されます。
同じ危険なコマンドで、人は143回、オートモードは937回停止した
統制実験では、オートモードは繰り返しの手動承認よりはるかに多くの危険なコマンドをブロックしました。Anthropicは、有償の専門テスター1,053人が参加するコーディング研究環境で、1つの権限リクエストを明らかに危険なコマンドに置き換えました。コマンドは実際には実行されず、人とオートモードが同じ1,053個のコマンドをどう扱うかを比較しました。
| 判断主体 | ブロックした危険なコマンド | ブロック率 |
|---|---|---|
| 手動承認ユーザー | 143件 / 1,053件 | 13.6% |
| オートモード | 937件 / 1,053件 | 89% |
人のブロック率はセッション序盤の約17%から、先行する権限リクエストが50件を超えると約5%まで下がりましたが、オートモードのブロック率はセッションの長さによって変わりませんでした。 この結果は、承認リクエストが積み重なる環境では、自動分類がより一貫したデフォルトの統制になり得ることを示しています。
89%をあらゆる開発作業の安全性にまで一般化してはいけません。参加者は実際のリポジトリではなくテスト環境で作業し、評価中であることも認識していました。区間ごとの標本数、信頼区間、危険なコマンドの一覧も公開されていません。したがって、インフラ変更を慎重にレビューする専門家よりオートモードが常に優れている証拠ではありません。
オートモードはすべてのコマンドをAIに尋ねる仕組みではない
オートモードはまず明らかに安全な作業を通し、潜在的に危険な作業だけを2段階の分類器に送ります。読み取り専用ツール、プロジェクト内ファイルの編集、範囲の狭いユーザー許可ルールは前段で処理されます。分類器の第1段階は疑わしい操作を感度高く選び出し、第2段階はフラグ付けされた操作を再度推論して不要なブロックを減らします。
分類器は、Claudeが書いた説明や実行理由ではなく、ユーザーメッセージと実際のツール入力を中心に判断します。エージェントが作ったもっともらしい説明に安全判断が引きずられないよう、入力を分離した設計です。
機密情報を外部へ送る操作、本番デプロイとマイグレーション、共有インフラの変更、強制プッシュ、既存ファイルの不可逆な破壊などは、デフォルトのブロックカテゴリに含まれます。 ただし、およそ20個のルールすべてを、どんな状況でも解除できない絶対的な禁止事項と理解するのは適切ではありません。ユーザーはオートモードを離脱でき、組織は別途deny・askポリシーを追加する必要があります。
既存の許可ルールも範囲を確認する必要があります。Bash(npm test)のような狭いルールは維持されますが、Bash(*)や、インタープリタ・パッケージマネージャーに広範なコード実行権限を与えるルールは、オートモードに入る際に除外される場合があります。モードを離れると、除外されていたルールは復元されます。
分類器にも見逃しはある：実際の過剰行動52件のうち17%
オートモードの利点はリスクをなくすことではなく、繰り返しの承認より一貫して選別することです。配備された2段階分類器は、Anthropic従業員のセッションから収集した実際の過剰行動サンプル52件のうち17%を許可しました。合成データ流出試行1,000件では5.7%を見逃し、正常な内部トラフィック1万件を誤ってブロックした割合は0.4%でした。
ここでの17%は、実利用コマンド全体の失敗率ではありません。すでに拒否されたか、後から問題として示された52件だけを集めた小さく偏った標本です。反対に、89%のブロック率も実際の本番環境全体を代表するものではありません。この2つの数値は、オートモードが有用である一方、高リスク作業の人によるレビューを置き換えられないことをあわせて示しています。
権限モードは作業の可逆性で分けてください。ローカルのコード修正やテストのように、diffで確認して元に戻せる作業は、オートモードで始められます。本番デプロイ、共有インフラの変更、機密情報の送信、大量データの変更では、別途人による承認と組織ポリシーを維持する方が安全です。
最初の確認はテストリポジトリで始める
オートモードが自分の環境でどう動くかは、コミット・プッシュ・デプロイが不要なバージョン管理リポジトリでまず確認してください。選択したアカウント、組織、モデルがオートモードをサポートしている必要があり、どの設定ファイルにもpermissions.disableAutoModeが"disable"として指定されていてはいけません。Team・Enterpriseでは、管理者がこの値を組織設定として配布している可能性があります。
実習前にプロジェクトの依存関係をインストールし、既存のテストコマンドで繰り返し再現できる失敗テストが1つあるリポジトリを用意してください。失敗テストがない場合は、コードをわざと壊さず、チームがすでに修正対象として決めたテストリポジトリを使うとよいでしょう。
- Claude Codeとテストリポジトリを準備します。
まだインストールしていない場合は、公式QuickstartでOSに合ったインストール方法を選んでください。インストール後、claude --versionで確認し、用意したプロジェクトディレクトリでclaudeを実行してログインします。 - まず自分で失敗を再現します。
リポジトリに定義されたテストコマンドを実行し、同じテストが繰り返し失敗することを確認してください。このとき、実行したコマンドと失敗したテスト名を記録します。依存関係の不足や外部サービスの障害など、コード修正で解決する問題でなければ、別のテストを選びます。 - 新しいセッションでAutoを選びます。
CLIではShift+Tabで権限モードを切り替え、ステータスバーにauto mode onと表示されることを確認します。DesktopとVS Codeでは、入力欄の近くにあるモードセレクターでAutoを選びます。 - 再現した失敗を1件だけ任せます。
「今実行したテストコマンドで失敗したテスト1件の原因を分析し、最小限のコード修正で直した後、同じコマンドをもう一度実行してください。コミット、プッシュ、デプロイ、外部サービスへの送信はしないでください」と入力します。 - 成功とブロック記録をあわせて確認します。
同じテストコマンドが成功し、git diffにその失敗を直すために必要な変更だけが残っていることを確認してください。作業がブロックされた場合は、/permissionsのRecently deniedでブロック項目を見つけ、すぐに迂回するのではなく、リクエストの範囲と信頼境界をさらに狭めてから再試行します。
同じセッションで連続3回、または累計20回ブロックされると、オートモードは一時停止し、手動承認プロンプトに戻ります。ユーザーが作業を承認すると、オートモードが再開します。非対話型の実行では承認ダイアログに切り替わらず、その作業を実行せずに他の作業を続けます。
さらに深く知りたいなら
Auto mode is now the default in Claude Code for Pro, Max, and Team plansでは、97%の承認率、1,053人による統制実験の設計、デフォルトモード変更の背景を確認できます。claude.com
How we built Claude Code auto mode: a safer way to skip permissionsは、2段階分類器、デフォルトのブロックカテゴリ、実データ・合成データによる評価結果を説明するエンジニアリング原文です。anthropic.com
Choose a permission modeでは、モードの切り替え方法、除外される許可ルール、ブロックのしきい値、管理設定を確認できる現在の製品ドキュメントです。code.claude.com
