Tech

Claude Code Auto Mode 徹底解説 — 権限プロンプトを自動判定する新しい開発体験

nidoneko · · 13 min read
Claude CodeAI開発効率化セキュリティ
🚀

「Yes」を押す回数、1日に何回？

Claude Code を日常的に使っていると、ある問題にぶつかります。権限プロンプトの多さです。

ファイルを編集するたびに「許可しますか？」、bash コマンドを実行するたびに「許可しますか？」。1日に数十回、場合によっては100回以上。これが「consent fatigue（承認疲れ）」と呼ばれる現象で、本来はセキュリティのための仕組みが、逆にセキュリティを弱めています。毎回「Yes」を押すことが条件反射になり、本当に危険なアクションも見逃してしまうからです。

2026年3月24日、この問題に対する公式の回答が出ました。Auto Mode です。

この記事では、Auto Mode の仕組みから実践的な設定方法まで、公式ドキュメントだけでは読み取りにくい部分も含めて解説します。

Auto Mode とは何か

Auto Mode は Claude Code の新しい権限モードです。一言で説明すると、**「AIが各アクションのリスクを判定し、安全なものは自動実行、危険なものはブロックする」**仕組みです。

従来の権限モードと比較すると位置づけが明確になります。

モード動作安全性開発体験
default全アクションで確認プロンプト高中断が多い
acceptEditsファイル編集のみ自動承認中〜高やや改善
auto分類器が安全と判断したら自動実行中大幅に改善
bypassPermissions全チェック省略低最も快適だが危険

Auto Mode は default の「毎回聞く」と bypassPermissions の「何も聞かない」の中間に位置する選択肢です。

分類器はどう判断しているのか

Auto Mode の核心は「セキュリティ分類器」です。Claude がツール呼び出しを行うたびに、実行前に分類器がそのアクションをレビューします。

分類器がブロックするのは主に以下の3パターンです。

  1. ファイルの大量削除 — rm -rf や広範囲の上書き
  2. 機密データの外部送信 — API キーや認証情報の流出につながる操作
  3. 悪意あるコード実行 — curl | bash のようなパイプ実行パターン

重要なのは、分類器の判定ロジックは単純なパターンマッチではないという点です。自然言語で記述されたルールを読み取って判断します。後述する autoMode.environment に「このドメインは信頼できる」と書けば、そのドメインへの通信はブロックされなくなります。

ブロック時の挙動

分類器がアクションをブロックした場合、Claude は別のアプローチを試みます。それでも繰り返しブロックされた場合は、最終的にユーザーに確認プロンプトを表示します。つまり、完全に自律するわけではなく、「判断できない場面では人間に聞く」というフォールバックが組み込まれています。

有効化の手順

CLI の場合

# Auto Mode を有効化（初回のみ）
claude --enable-auto-mode

# 起動後、Shift+Tab でモードを切り替え
# default → acceptEdits → plan → auto → ...

VS Code 拡張機能の場合

  1. Settings → Claude Code を開く
  2. 「Auto mode」をトグルオン
  3. セッション内のドロップダウンから auto を選択

settings.json でデフォルト設定

{
  "defaultMode": "auto"
}

現時点の対応モデルは Claude Sonnet 4.6 と Claude Opus 4.6 です。Team プランでリサーチプレビューとして利用可能で、Enterprise プランと API ユーザーへも順次提供予定です。

—dangerously-skip-permissions との決定的な違い

「Auto Mode があるなら --dangerously-skip-permissions は不要？」と思うかもしれません。実際、多くの開発者がこのフラグを使っていました。しかし、両者には決定的な違いがあります。

--dangerously-skip-permissions:
  全てのアクション → そのまま実行（チェックなし）

Auto Mode:
  全てのアクション → 分類器でレビュー → 安全: 実行 / 危険: ブロック

--dangerously-skip-permissions は文字通り全ての安全チェックを無効化します。bash コマンド、ファイル編集、ネットワークリクエスト、MCP ツール呼び出し、すべてがノーチェックで実行されます。

一方、Auto Mode はアクションごとに判定します。npm run build は自動実行されるが、git push --force origin main はブロックされる、という具合です。

実務での体感差

私の体験では、Auto Mode に切り替えてから権限プロンプトの表示回数が体感で8〜9割減しました。残る1〜2割は本当に判断が必要なアクション（本番環境への操作、未知のドメインへの通信など）で、むしろこれらに集中してレビューできるようになりました。

これは「consent fatigue」研究が示す理想形です。アラートの総量を減らすことで、残ったアラートへの注意力が上がる。Auto Mode はまさにこの原則に沿った設計です。

分類器のカスタマイズ — 実はここが本題

公式ドキュメントを読み込んで気づいたのですが、Auto Mode の真価は autoMode 設定ブロックによるカスタマイズにあります。日本語の解説記事でここまで踏み込んだものはまだ見当たりません。

autoMode.environment — 信頼するインフラを教える

デフォルトでは、Auto Mode は作業ディレクトリと現在のリポジトリのリモートだけを信頼します。つまり、自社の S3 バケットにアップロードする操作や、社内 API にリクエストを送る操作が「データ流出の可能性あり」としてブロックされます。

これを解決するのが autoMode.environment です。

{
  "autoMode": {
    "environment": [
      "Organization: nidoneko. Primary use: web development",
      "Source control: github.com/nidoneko",
      "Trusted internal domains: nidoneko.dev",
      "Key internal services: Cloudflare Pages, Cloudflare Workers"
    ]
  }
}

ポイントは、この設定が正規表現やツールパターンではなく自然言語で書くということです。分類器がこれを読み取って判断材料にします。公式ドキュメントにも「新しいエンジニアにインフラを説明するように書いてください」とあります。

この「自然言語で環境を伝える」設計は、CLAUDE.md の書き方 設計パターン集で触れた WHAT / WHY / HOW の考え方とも相性が良いです。Auto Mode の環境説明が曖昧だと誤ブロックが増えますし、逆に細かい強制ルールまで詰め込み始めると、今度は Hooks で扱うべき責務を混ぜてしまいます。

設定の読み込み元に注意

autoMode 設定はユーザー設定（~/.claude/settings.json）、ローカルプロジェクト設定（.claude/settings.local.json）、管理者設定から読み込まれます。

重要なのは、共有プロジェクト設定（.claude/settings.json）からは読み込まれないことです。チェックインされたリポジトリが自分自身の allow ルールを注入するリスクを防ぐためです。これはセキュリティ上、非常に合理的な設計です。

soft_deny と allow — 上級者向けルールカスタマイズ

autoMode.soft_deny でブロックルールを、autoMode.allow で例外ルールを定義できます。

{
  "autoMode": {
    "environment": ["Source control: github.com/nidoneko"],
    "allow": [
      "Deploying to Cloudflare Pages preview is allowed: preview deploys are isolated"
    ],
    "soft_deny": [
      "Never modify .env files directly: use .env.example and local overrides"
    ]
  }
}

ここで絶対にやってはいけないことがあります。soft_deny を設定する場合、デフォルトのルールリストが完全に置き換わります。つまり、1行だけ書くと、force push、データ流出、curl | bash など全てのデフォルトブロックルールが消えます。

安全なカスタマイズ手順は以下の通りです。

# 1. デフォルトルールを出力
claude auto-mode defaults

# 2. 出力をコピーして settings に貼り付け、編集

# 3. 設定が正しく適用されたか確認
claude auto-mode config

# 4. カスタムルールのレビューを受ける
claude auto-mode critique

claude auto-mode critique は設定内容を AI がレビューし、曖昧な記述や誤検知の原因になりそうなルールを指摘してくれます。

よくある誤解と落とし穴

誤解1: 「Auto Mode = 安全」ではない

公式ドキュメントにも明記されていますが、Auto Mode はリスクを低減するものであり、排除するものではありません。分類器の判断が不完全な場合があり得ます。具体的には以下のケースです。

  • 曖昧な意図のアクション（ファイルの一括置換が「リファクタリング」なのか「破壊」なのか）
  • 環境情報の不足（信頼すべきドメインが environment に未記載）
  • 良性アクションの誤ブロック（false positive）

公式の推奨は「隔離された環境での使用」です。Docker コンテナや VM の中で使うのが最も安全です。

誤解2: 「トークン消費量は変わらない」

分類器が各アクションをレビューする分、若干のトークン消費とレイテンシが追加されます。公式には「小規模な影響」とされていますが、大量のファイルを一括処理するタスクでは積もります。コスト意識の高いフリーランスや個人開発者は認識しておくべきポイントです。

誤解3: 「permissions.deny ルールを Auto Mode が上書きする」

permissions.deny で設定したルールは、Auto Mode の分類器より先に評価されます。deny ルールが設定されたアクションは、分類器に到達する前にブロックされます。つまり、Auto Mode は既存の権限設定を「緩める」ことはありません。

チーム運用のベストプラクティス

組織で Auto Mode を導入する場合、管理者設定（managed settings）で組織全体のポリシーを定義できます。

{
  "autoMode": {
    "environment": [
      "Organization: Acme Corp. Primary use: SaaS development",
      "Source control: github.com/acme-corp",
      "Cloud provider: AWS",
      "Trusted cloud buckets: s3://acme-builds, s3://acme-staging",
      "Trusted internal domains: *.acme-internal.com",
      "Key internal services: Jenkins at ci.acme.com"
    ]
  }
}

管理者設定の environment はユーザー設定と加算的にマージされます。開発者は自分の設定でエントリを追加できますが、管理者が設定したエントリを削除することはできません。

ただし、allow ルールは加算的にマージされるため、開発者が追加した allow エントリが組織の soft_deny を上書きする可能性があります。これがハードなポリシー境界にならない点は設計上の注意点です。本当にブロックしたいアクションは permissions.deny で管理者設定に入れるべきです。

Auto Mode のチーム導入を検討している場合、AIツール全般の組織導入における利用ルールやガバナンス設計についてはAIの組織利用ガイドで整理しています。ローカル操作のガードレールをより堅くしたいときは、Claude Code Hooks の使い方 実践ガイドとセットで読むと、承認判定と実行制御をどう分担するべきかが見えやすくなります。

段階的ロールアウトの推奨手順

  1. デフォルト設定で開始 — まずは何もカスタマイズせず使い始める
  2. ソースコントロールと主要サービスを追加 — 最も一般的な false positive が解消される
  3. 信頼ドメインとクラウドバケットを追加 — 日常的なワークフローがスムーズに
  4. ブロックが発生したら対応 — claude auto-mode critique でルールをレビュー

Auto Mode を使うべき人、使うべきでない人

使うべき人:

  • Claude Code で長時間のコーディングセッションを行う開発者
  • 権限プロンプトの多さにストレスを感じている人
  • Docker/VM 環境で開発している人

慎重に検討すべき人:

  • 本番環境のサーバーで直接 Claude Code を使っている人
  • セキュリティポリシーが厳格な組織の開発者
  • Claude Code を使い始めたばかりで、何が実行されているか把握したい人

私の結論は明確です。個人開発では Auto Mode をデフォルトに設定し、autoMode.environment で自分のインフラを定義する。これが 2026年3月時点での最適解です。consent fatigue を解消しつつ、本当に危険なアクションにだけ注意を向けられるようになります。

まとめ

Auto Mode は「全て許可」と「毎回確認」の間にある、現実的な落としどころです。分類器による自動判定という仕組みは完璧ではありませんが、人間の注意力が有限であるという現実を踏まえた、実用的な設計だと評価しています。

設定のポイントを振り返ります。

  1. claude --enable-auto-mode で有効化、Shift+Tab で切り替え
  2. autoMode.environment で信頼するインフラを自然言語で定義
  3. soft_deny / allow をカスタマイズする場合は必ずデフォルトルールをベースにする
  4. permissions.deny は Auto Mode より優先される — 既存の deny ルールは維持される
  5. 隔離環境での使用が推奨 — 本番環境での利用は慎重に

Claude Code のエージェント的な使い方が加速する中で、Auto Mode は人間がボトルネックにならないための必然的な進化です。ただし、信頼は検証の上に成り立つもの。まずは小さなプロジェクトで試し、分類器の判断を観察してから、メインの開発環境に導入することをおすすめします。

Auto Mode を含む Claude Code の導入から運用までの全体像は、Claude Code 実践ガイドにまとめています。

WRITTEN BY nidoneko

Full-stack engineer with 8+ years of experience in TypeScript, React, Node.js, and cloud-native development across healthcare, finance, HR, and IoT domains.

View Profile →
// Related articles View All
🧠
Claude Code

Claude Code サブエージェント運用ガイド — 並列委譲・コンテキスト分離・レビュー役分担の実践

·14 min read

Claude Code のサブエージェント運用を実務目線で解説します。main 会話との使い分け、並列委譲、レビュー役分担、権限とツール制限、worktree 分離まで、実際に事故りやすい論点に絞って整理しました。

Read More →
⏱️
Codex

Codex Automations 実践ガイド — 定期実行・worktree運用・安全な回し方

·11 min read

Codex Automations を実務に入れたいが、何を定期実行し、どこで止め、どう review するべきか分からない人向けに、worktree 分離・sandbox・PR 運用まで実体験ベースで整理します。

Read More →
📋
AIコーディング

AIコーディングツールの社内ガイドライン — 安全運用テンプレと判断基準

·10 min read

AIコーディングツールを社内導入したいが、何を禁止し何を許可すべきか曖昧な方向けに、最小構成の社内ガイドラインをテンプレ付きで整理します。入力データ、実行権限、レビュー境界、監査、MCP の扱いまで実務向けにまとめました。

Read More →