結論：auto（自動許可）モードは「分類器でリスク行為だけ止める」第4の権限モード
Claude Code v2.1.83 以降で使える auto モードは、毎回の許可プロンプトをなくしつつ、別の分類器モデルが「取り返しのつかない行為・環境外への送信・敵対的コンテンツ由来の行為」だけをブロックする仕組みです。bypassPermissions のように全部素通しにするのではなく、安全境界を残したまま手を止めずに走らせられる、というのが核心です。
この記事の要点
- 要点1：
autoはdefault / acceptEdits / plan / dontAsk / bypassPermissionsと並ぶ権限モードの1つ。Shift+Tab巡回か--permission-mode autoで入る。 - 要点2：分類器は
hard_deny / soft_deny / allow / environmentの4層で判断。autoMode設定で自社の信頼インフラを教えると誤検知が減る。 - 要点3：チーム導入では
permissions.deny（分類器より前で効く絶対境界）とautoMode.environment（信頼先の宣言）を分けて設計するのが安全。
対象読者：Claude Code を実務で回しているエンジニア・PM・SRE、そして組織展開を任された開発リード。今日できること：自分の端末で auto を一度試し、claude auto-mode defaults で既定ルールを読み、自社用の autoMode.environment を1行書き始めること。
権限モードを試して詰まった話：bypassは怖い、defaultは遅い
正直なところ、最初に --dangerously-skip-permissions（＝bypassPermissions）でブン回していた時期がありました。速いんです。ただ、コンテナの外で使うと「やらかしたら全部素通し」という不安がずっと付きまとう。かといって default モードに戻すと、長いリファクタの途中で mkdir ひとつにも止まって、集中が切れる。この「速度と安全のトレードオフ」をちょうど真ん中で埋めるのが auto モードでした。
公式ドキュメントでも auto モードは「リサーチプレビュー（research preview）」と明記されていて、許可プロンプトを減らすが安全を保証するものではないと書かれています。だから「方向性は信頼できるが、機微な操作のレビューを置き換えるものではない」という前提で使うのが正解です。ここを履き違えると事故ります。
auto モードの位置づけ：6つの権限モード比較
Claude Code の権限モードは公式に6種類あります。それぞれ「プロンプトなしで何が動くか」が違います。
| モード | プロンプトなしで動く範囲 | 向いている場面 |
|---|---|---|
default |
読み取りのみ | 機微な作業・はじめての利用 |
acceptEdits |
読み取り＋ファイル編集＋一部のファイル系コマンド（mkdir / touch / mv / cp 等） |
レビュー前提でコードを回す |
plan |
読み取りのみ（変更しない） | 変更前にコードベースを調査 |
auto |
バックグラウンドの安全チェック付きで「ほぼ全部」 | 長時間タスク・プロンプト疲れの軽減 |
dontAsk |
事前承認済みツールのみ（それ以外は自動拒否） | ロックダウンした CI・スクリプト |
bypassPermissions |
全部（チェックなし） | 隔離コンテナ・VM 専用 |
bypassPermissions 以外のすべてのモードで、保護パス（.git や .claude、各種 dotfiles）への書き込みは自動承認されないのがポイントです。auto モードの場合、保護パスへの書き込みは「拒否」ではなく「分類器に回す」挙動になります。
auto モードに入る方法：Shift+Tab・フラグ・既定設定
auto モードへの入り方は3通りです。いずれも「チャットで Claude に頼む」のではなく、モード自体を切り替えます。
1. セッション中に巡回する。Shift+Tab で default → acceptEdits → plan を巡回します。アカウントが auto の要件を満たしていれば、巡回の最後に auto が現れ、初回はオプトインの確認が出ます。
2. 起動時にフラグで指定する。
claude --permission-mode auto3. 既定モードにする。~/.claude/settings.json（ユーザー設定）に書きます。
{
"permissions": {
"defaultMode": "auto"
}
}ここで重要な落とし穴があります。defaultMode: "auto" はプロジェクト設定（.claude/settings.json）やローカル設定では無視されます。v2.1.142 以降、リポジトリが自分自身に auto を付与できないようにする仕様で、ユーザー設定（~/.claude/settings.json）か管理設定に置く必要があります。「設定したのに default で起動する」場合はここを疑ってください。
分類器が既定でブロックするもの・許可するもの
auto モードの安全性は「分類器モデル」が担保します。分類器は作業ディレクトリと、リポジトリに設定済みのリモートだけを信頼し、それ以外はすべて「外部」とみなします。claude auto-mode defaults で全ルールを JSON で確認できます。
既定でブロックされる代表例
curl | bashのようなコードのダウンロード実行- 機微データの外部エンドポイントへの送信
- 本番デプロイ・マイグレーション
- クラウドストレージの大量削除、IAM・リポジトリ権限の付与
- force push、
mainへの直接 push git reset --hard/git checkout -- ./git clean -fd/git stash dropなど、未コミット変更を捨てると推定される操作（v2.1.182 以降）terraform destroy/pulumi destroy/cdk destroyや、リソースを破壊する plan の適用
既定で許可される代表例
- 作業ディレクトリ内のローカルファイル操作
- ロックファイル・マニフェストに宣言済みの依存インストール
.envを読み、その対応 API に資格情報を送る- 読み取り専用の HTTP リクエスト
- 開始したブランチ、または Claude が作成したブランチへの push
「会話の中で宣言した境界」も分類器はブロック信号として扱います。「push しないで」「レビューするまでデプロイ待って」と伝えると、既定では許可される行為でもブロックされます。ただしこれはルールとして保存されず、コンテキスト圧縮で該当メッセージが消えると失効します。確実に止めたいなら後述の permissions.deny を使ってください。
autoMode 設定：自社の信頼インフラを分類器に教える
誤検知（false positive）の多くは「自社のリポジトリに push しようとして止まる」「社内バケットに書こうとして止まる」というものです。これは autoMode.environment で信頼先を宣言すると解消します。設定は正規表現やツールパターンではなく自然言語の散文（prose）で書くのが特徴です。新しく入ったエンジニアにインフラを説明するつもりで書きます。
{
"autoMode": {
"environment": [
"$defaults",
"Source control: github.example.com/acme-corp and all repos under it",
"Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
"Trusted internal domains: *.corp.example.com, api.internal.example.com",
"Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
]
}
}"$defaults" という文字列を配列に含めると、組み込みの既定ルールがその位置に差し込まれます。逆に "$defaults" を入れずに environment / allow / soft_deny / hard_deny を書くと、そのセクションの既定ルールを丸ごと置き換えてしまう点に注意してください。たとえば soft_deny を "$defaults" なしで書くと、force push や本番デプロイの既定ブロックまで消えます。
分類器が autoMode を読むスコープは限定されています。ユーザー設定（~/.claude/settings.json）、ローカル設定（.claude/settings.local.json）、管理設定、--settings フラグ。共有プロジェクト設定（.claude/settings.json）からは読み込まれません。チェックインされたリポジトリが勝手に allow ルールを注入できないための設計です。
4層の優先順位：hard_deny / soft_deny / allow / ユーザー意図
分類器の内部判断は4段階の優先順位で動きます。最初にマッチした段が勝ちます。
| 優先 | 層 | 挙動 |
|---|---|---|
| 1 | hard_deny |
無条件にブロック。ユーザー意図も allow 例外も効かない（データ持ち出し・auto バイパスなどのセキュリティ境界） |
| 2 | soft_deny |
次にブロック。ユーザー意図や allow で上書きできる（破壊的操作） |
| 3 | allow |
マッチする soft_deny の例外として上書き |
| 4 | 明示的なユーザー意図 | ユーザーの発言が「いま実行しようとしている行為そのもの」を具体的に指していれば、soft_deny にマッチしても許可 |
ここで言う「明示的な意図」は具体性が必要です。「リポジトリを片付けて」は force push を許可しませんが、「このブランチを force push して」は許可します。一般的なお願いは意図としてカウントされません。
組織固有のルールを足したい場合は、各リストに "$defaults" を含めつつ追記します。
{
"autoMode": {
"soft_deny": [
"$defaults",
"Never run database migrations outside the migrations CLI, even against dev databases",
"Never modify files under infra/terraform/prod/"
],
"hard_deny": [
"$defaults",
"Never send repository contents to third-party code-review APIs"
]
}
}auto-mode CLI で「効いている設定」を検証する
設定を書いたら、実際に分類器が使う有効ルールを必ず確認します。公式に用意されているサブコマンドは3つです。
# 組み込みの既定ルールを JSON で出力
claude auto-mode defaults
# 自分の設定を適用した「実際に使われる」有効ルールを JSON で出力
claude auto-mode config
# 自作の allow / soft_deny / hard_deny ルールに AI のフィードバックをもらう
claude auto-mode critique運用のコツとしては、設定を保存したら claude auto-mode config を回して "$defaults" がその場で展開された状態を目視確認すること。自作ルールを書いたら claude auto-mode critique で「曖昧・冗長・誤検知を招きそう」なエントリを洗い出してもらうこと。この2コマンドを習慣にするだけで、設定ミスによる事故がかなり減ります。
フォールバックとサブエージェントの扱い
分類器が3回連続、または通算20回ブロックすると、auto モードは一時停止して通常の許可プロンプトに戻ります。プロンプトを承認すると auto モードが再開します。これらの閾値は変更できません。許可された行為があると連続カウンタはリセットされますが、通算カウンタはセッション中持続します。-p による非対話モードでは、ブロックが続くとプロンプトする相手がいないためセッションが中断します。
サブエージェントについても分類器は3点でチェックします。(1) サブエージェント開始前に委任タスクの説明を評価（v2.1.178 以降）、(2) 実行中は各アクションを親と同じルールで評価し、フロントマターの permissionMode は無視、(3) 終了時に全アクション履歴をレビュー。並列サブエージェントを多用するチームは、ここを理解しておくと「なぜ止まったか」が読めるようになります。
なお auto モードに入ると、Bash(*) や Bash(python*)、パッケージマネージャの run コマンド、Agent の allow ルールといった「任意のコード実行を許す広い allow ルール」は一時的に外されます。Bash(npm test) のような狭いルールは引き継がれ、auto を抜けると外したルールは復元されます。
失敗パターンと回避策
実際にチームで回して踏んだ・聞いた失敗を、❌→⭕の形でまとめます。
失敗1：会話の境界だけで本番を守ろうとする
❌「デプロイしないで」と一度言ったから安心、とコンテキストを延々と伸ばす。圧縮で発言が消えて境界が失効。
⭕ 絶対に動いてほしくない行為は permissions.deny（管理設定）で固める。これは分類器より前で効き、上書きされません。
失敗2："$defaults" を入れ忘れて既定を全消し
❌ soft_deny に1行だけ書いて、force push の既定ブロックまで消えていた。
⭕ 既定を残すなら必ず "$defaults" を含める。全置換したい時だけ claude auto-mode defaults の出力をコピーして編集する。
失敗3：プロジェクト設定に autoMode / defaultMode: "auto" を書く
❌ チームで共有したくて .claude/settings.json に書いたが効かない。
⭕ autoMode も auto 既定もユーザー設定か管理設定が正。組織展開は管理設定（managed settings）で配布する。
失敗4：bypassPermissions の代わりに auto を「安全な全自動」と誤認
❌ プロンプトインジェクション対策込みだと思い込む。
⭕ auto はリサーチプレビュー。機微な操作はレビューを残す。完全自律で走らせたいなら隔離コンテナ＋dev container 構成を使う。
Bedrock / Vertex AI / Foundry での有効化
Anthropic API では auto モードは既定で利用可能ですが、Amazon Bedrock・Google Cloud Vertex AI・Microsoft Foundry では、環境変数を設定するまで Shift+Tab 巡回に現れません。
{
"env": {
"CLAUDE_CODE_ENABLE_AUTO_MODE": "1"
}
}この変数は v2.1.158 以降で有効で、これらのプロバイダでは Claude Opus 4.7 と Opus 4.8 のみが対応です。組織全体で有効化するなら同じ env ブロックを管理設定に置きます。逆に開発者が有効化できないようにするには、管理設定で disableAutoMode を "disable" にします（有効化変数より優先されます）。Team・Enterprise プランでは、利用前に Owner が Claude Code の管理設定で auto モードを有効化しておく必要があります。
FAQ
Q. auto モードと bypassPermissions はどう違いますか？
A. bypassPermissions はチェックなしで全部素通しにします（隔離環境専用）。auto は分類器がリスク行為だけをブロックするので、安全境界を残したまま許可プロンプトを大幅に減らせます。公式も「より少ない許可プロンプトでバックグラウンド安全チェックが欲しいなら bypass ではなく auto を使え」と案内しています。
Q. 分類器の利用はコストがかかりますか？
A. 分類器はサーバ側で設定されたモデルで動き、/model の選択とは独立です。分類器の呼び出しはトークン使用量に計上され、実行前に1往復のレイテンシが加わります。読み取りと作業ディレクトリ内の編集（保護パスを除く）は分類器をスキップするため、オーバーヘッドは主にシェルコマンドとネットワーク操作で発生します。
Q. 必要なバージョンは？
A. auto モード自体は v2.1.83 以降。サブエージェントのタスク事前評価は v2.1.178 以降、Bedrock/Vertex/Foundry の有効化変数は v2.1.158 以降です。
Q. 誤検知が多いときは？
A. まず autoMode.environment に該当の信頼先を追記し、claude auto-mode config で反映を確認します。拒否は /permissions の「Recently denied」タブに記録され、r キーで手動承認して再試行できます。プログラム的に反応するなら PermissionDenied フックが使えます。
まとめ：今日やる3アクション
auto モードは「速度を取るために安全を全部捨てる」ではなく、「分類器に下支えさせて、危険な行為だけ手前で止める」モードです。チーム導入の肝は、permissions.deny（絶対境界）と autoMode.environment（信頼先の宣言）を役割分担させる設計にあります。
- 自分の端末で
claude --permission-mode autoを一度試し、どこで止まるかを観察する。 claude auto-mode defaultsで既定ルールを読み、自社のautoMode.environmentを"$defaults"付きで1行から書き始める。- 絶対に動いてほしくない操作を
permissions.deny（管理設定）に固め、claude auto-mode configで有効ルールを検証する。
次回予告：本記事の deny 設計を、チーム展開向けの managed settings 一式としてどう配るか（権限設計の全体像）を別記事で深掘りします。
権限設計の全体像はClaude Code権限設計ガイド【2026】を、分類器より前で効くサンドボックス分離はClaude Codeサンドボックスで安全に自動実行【2026】を、設定ファイル全般はClaude Code settings.json設定完全ガイド【2026】を合わせて読むと、権限まわりの設計が一通り揃います。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。
