承認ボタンの連打から「危険だけ止める」方式へ
Claude Codeを初めて触った経営者の方から、いちばん多く聞く不満がこれです。 「作業を頼むたびに『このコマンドを実行してもいいですか？』と何度も聞かれて、結局ずっと画面に張り付いていた」。 AIに仕事を任せたはずが、承認ボタンを押す係になってしまう――これが従来のClaude Codeの姿でした。
この確認は安全のための仕組みです。ファイルの書き換えやコマンドの実行を、AIが勝手に行わないようにする関所の役割を果たします。 ただしAnthropicの利用データ分析によると、表示された確認のうち93%はそのまま「許可」が押されていたそうです。 ほぼ全部OKを押すのに毎回聞かれる。すると人は次第に内容を読まずに押すようになり、 安全のための確認が形だけになっていく。手間は増えるのに安全性は上がらない、という悪循環です。
この問題を根本から解決するのが、本ページで解説するauto modeです。 「毎回人間に聞く」のでも「全部素通しにする」のでもなく、危険な操作だけを自動で見分けて止めるという第三の方式で、権限まわりの常識を塗り替えました。
auto modeでは、作業を担当するAIとは別の監視役AI（分類器と呼ばれます）が、 すべての操作を実行前にチェックします。空港の保安検査場をイメージしてください。 通常の荷物はそのまま流れ、怪しい荷物だけが止められて確認される。あの仕組みと同じです。
重要なのは、これが「全部許可」ではないという点です。 むしろ人間が確認疲れで内容を読まずにOKを押すより、 機械が全件を同じ基準で審査するぶん、見落としは減ります。 Anthropicの実測では、1万件の実トラフィックに対する誤ブロック率（本当は安全なのに止めてしまう率）は 最終的に0.4%まで抑え込まれています。
ポイント: auto modeは「確認を省略するモード」ではなく「確認を機械に任せるモード」です。 人間は承認ボタン係から解放され、AIは長い作業を中断なしで進められる。 それでいて危険な操作には自動でブレーキがかかります。 非エンジニアの方こそ恩恵が大きい機能です。
監視役の分類器には、乗っ取り対策も組み込まれています。 AIが読み込んだファイルやWebページに「これを実行しろ」という悪意ある指示が仕込まれていても（プロンプトインジェクションと呼ばれる攻撃です）、 分類器はその内容に影響されない設計になっており、さらに別の検査層が怪しい内容を事前に検出して警告します。
具体的なイメージを持っていただくために、標準設定での判定例を挙げます。
つまり「社内の机の上での作業は自由に、会社の外に影響が出る行動は要確認」という、 新入社員に与える権限とよく似た線引きです。 万一ブロックが続く場合の保険もあり、3回連続、または合計20回ブロックされると auto modeは一時停止して従来の確認方式に戻ります。暴走したまま進む設計にはなっていません。
auto modeの意外な特長は、会話の中で伝えた制約がそのままブレーキとして効くことです。 分類器はあなたとAIのやり取りを読んでおり、あなたが宣言した境界を判定基準に組み込みます。
Claude Codeにこう頼んでください。
本番環境に関わる操作と、外部への公開・送信は、
私が「OK」と言うまで実行しないでください。
それ以外の作業は確認なしで進めて構いません。これだけで、標準では通る操作であっても、宣言に触れるものは分類器がブロックするようになります。 しかも「AIが『条件を満たしたと判断した』から解除」とはなりません。 解除できるのは、あなたが後のメッセージで明示的に許可したときだけです。 設定ファイルを1行も書かずに、日本語の一文で権限の境界を引ける―― これが非エンジニアにとってのauto modeの実用的な価値です。
逆に、ブロックされてしまった操作を通したいときも言葉で解決できます。 たとえば「リポジトリを整理して」という漠然とした依頼では強制的な上書き保存は許可されませんが、 「このブランチを強制的に上書きして反映して」と具体的に指示すれば、 あなたの明確な意図として分類器が通します。曖昧な依頼は安全側に、具体的な指示は意図どおりに。この原則を覚えておけば十分です。
ポイント: 会話で宣言した境界は、長いセッションで古い会話が整理（要約）されると失われる可能性があります。 「絶対に破られては困る一線」は会話ではなく、後述するdenyルールとして設定ファイルに書いてください。 日常の柔らかい境界は会話で、恒久的な禁止事項は設定で、という使い分けです。
ここは正直にお伝えしたいのですが、ネット上にあるClaude Codeの権限解説の多くは、 auto mode登場前の前提で書かれており、現在では出発点が変わっています。
従来は「よく使うコマンドをひとつずつ許可リスト（allowlist）に登録し、確認回数を減らしていく」のが定石でした。 この方法は今も有効ですが、リストの整備には手間がかかり、 想定外のコマンドが出るたびに確認が発生します。 auto modeでは分類器が文脈ごと判断するため、リストを育てる作業そのものが原則不要になりました。 なお、auto mode中は「何でも実行できる」広すぎる許可ルールは安全のため自動的に無効化され、 範囲の狭いルールだけが引き継がれます。細かく育てた許可リストほど役割が縮小した、ということです。
もうひとつの定番が、確認を完全に無効化する--dangerously-skip-permissionsという起動オプションでした。 「危険を承知で全部通す」モードで、確認疲れに耐えかねた利用者の間で広く使われてきましたが、 これはブレーキのない車で公道を走るのと同じです。 公式ドキュメントも現在は、このモードの利用を外部から隔離された実験環境に限定すべきとし、 「確認を減らしたいならauto modeを使うように」と明記しています。 個人ブログ等で「とりあえずこのオプションを付けよう」と勧める記事を見かけたら、 auto mode登場前の古い情報だと判断してください。
整理すると、選択肢はこう変わりました。
auto modeとセットで理解しておきたいのがsandbox（サンドボックス）です。 両者は競合する機能ではなく、守り方の異なる2枚の壁として併用します。
柵の内側でも監督は目を光らせ、監督の目が届く範囲でも柵はあったほうがいい。 2本立てにすることで、片方をすり抜ける事態にもう片方が備える構造になります。 実際、sandboxの外部アクセス許可の判断はauto modeの分類器が担うなど、両者は連携して動作します。 sandboxの具体的な設定方法はセキュリティと権限設計のページで解説しているので、あわせてお読みください。
auto modeは現在、すべてのプランで利用できます（TeamやEnterpriseでは管理者が組織単位で無効化することも可能です）。 比較的新しいモデル（Opus 4.6以降・Sonnet 4.6以降など）で動作し、古い世代のモデルでは使えません。
使い方はシンプルで、Claude Codeの画面でShift+Tabキーを押してモードを切り替えるだけです。 条件を満たしたアカウントでは、切り替え候補の中に「auto mode」が現れます。 画面下部に「auto mode on」と表示されれば有効です。
毎回切り替えるのが手間なら、既定のモードとして設定しておけます。 Claude Codeにこう頼んでください。
ホームディレクトリの ~/.claude/settings.json を開いて、
permissions の defaultMode を "auto" に設定してください。設定ファイルには次のような記述が入ります。
// ~/.claude/settings.json
{
"permissions": {
"defaultMode": "auto"
}
}ひとつ注意点があります。この設定はホームディレクトリ側の設定ファイル（ユーザー設定）でのみ有効で、 プロジェクトフォルダ内の設定ファイルに書いても無視されます。 これは不便のようでいて、実は安全設計です。 もし外部から受け取ったプロジェクトが自分自身にauto modeを付与できてしまうと、 悪意あるプロジェクトを開いただけで防御が緩む恐れがあるため、意図的にそうなっています。
最後に、私たちがClaude Codeの導入を支援する際に推奨している、実務向けの設定指針をまとめます。 高度なカスタマイズは不要です。次の三段構えで十分に実用と安全が両立します。
日常業務はauto modeで回します。資料作成・データ整理・社内ツールの改修といった作業なら、 標準のブロックルールだけで危険はほぼ塞がれます。 そのうえで、案件ごとの注意点（「このフォルダは触らない」「公開前に必ず見せて」など）は 作業開始時に一言宣言する。前述のとおり、それだけで分類器のブロック対象になります。
会社の外に影響する操作――たとえばコードの共有リポジトリへの反映は、 自動で通る設定のままにせず、毎回確認を求める設定を足しておくのが現実的です。 設定ファイルに次のようなaskルールを追加すると、 auto mode中でも該当の操作だけは必ず人間に確認が来ます。
// ~/.claude/settings.json
{
"permissions": {
"ask": [
"Bash(git push *)",
"Bash(gh pr create *)"
]
}
}また「絶対に実行させない操作」はdenyルールで指定します。 denyルールは分類器より先に評価される最優先の禁止で、auto modeでも会話の指示でも覆せません。 機密ファイルの読み取り禁止など、denyルールの具体例はセキュリティと権限設計のページを参照してください。
導入したら一度、何がブロック対象なのかをAI自身に説明させておくと安心です。 Claude Codeにこう頼んでください。
claude auto-mode defaults を実行して、
標準でブロックされる操作を、専門用語を使わずに
日本語で箇条書きにまとめてください。claude auto-mode defaultsは、分類器の標準ルール一覧を出力する公式コマンドです。 そのままでは英語の技術文書ですが、AIに要約させれば経営判断に使える形で把握できます。 運用を始めてから正当な操作が繰り返しブロックされる場合は、 自社で使っているサーバーやサービスを「信頼できる環境」として設定に追記する仕組み （autoMode.environment）も用意されています。 そこまで必要になったら、導入支援の専門家に相談するタイミングです。
ポイント: ブロックされた操作は消えてしまうわけではありません。/permissions画面の「Recently denied」から個別に承認して再実行できますし、 次のメッセージで意図を具体的に伝え直せばAIが再試行します。 「止まった＝失敗」ではなく「止まった＝確認の合図」と捉えるのが、auto modeと付き合うコツです。
auto modeは、Claude Codeの最大の離脱点だった「承認ボタンの連打」を解消する新しい権限方式です。 監視役のAIが全操作を審査し、危険な操作だけを自動で止める。 会話で宣言した境界がそのままブレーキになり、設定ファイルに触れなくても実用的な安全運用が始められます。 許可リストを手作業で育てる方法や、確認を全スキップする起動オプションを勧める解説は、もう過去のものです。 sandboxという物理的な仕切りと組み合わせた2本立てを基本に、 外部に影響する操作にだけaskルールで人間の確認を挟む。 この構えができれば、AIに長い作業を安心して任せる体制は完成です。