Claude Code auto モード完全ガイド｜仕組み・設定・使えない原因と組織導入【2026年9月版】

Claude Code を起動したら、以前は毎回出ていた「このコマンドを実行してよいですか？」という確認がほとんど出なくなった。ステータスバーには ⏵⏵ auto mode on と表示されている。── 2026年8月14日以降、Pro・Max・Team プランでこの状態になった人は多いはずです。

これは auto モードという権限モードで、Anthropic が8月7日に「新規セッションの既定にする」と発表したものです。ところが検索上位の解説記事の一部は3月の提供開始時点に書かれたままで、「起動時にフラグで有効化する」「Team プラン以上が対象」といった、いまの仕様とは違う前提のまま残っています。

本記事では、2026年9月25日に取得した Anthropic 公式ドキュメントを原典に、auto モードの仕組み・既定でブロックされる操作・設定方法・使えないときの確認点・組織での導入判断までを1本にまとめます。手元の Claude Code v2.1.145 と最新の v2.1.282 で実行したコマンドの結果も載せており、実機で確認した内容とドキュメント記載の内容は書き分けています。

結論：2026年9月時点の auto モード

auto モードとは、Claude Code がファイル編集やコマンド実行の前に人へ確認する代わりに、別のモデル（分類器）が危険かどうかを判定して、安全なものだけを自動で実行する権限モードです。 2026年9月時点で押さえるべき点は次の4つです。

1. Pro・Max・Team では既定が auto になった：8月14日以降、ターミナルと VS Code 拡張の新規セッションは auto モードで始まります（Claude Code v2.1.228 以降。ネイティブ Windows は v2.1.233 以降）
2. Enterprise・API キー・クラウド経由は、まだ既定が Manual：使えないわけではなく、自分で切り替えれば使えます
3. 確認がゼロになるわけではない：本番デプロイや force push など、既定でブロックされる操作があります。ブロックが続くと自動的に手動承認へ戻ります
4. 管理者は止められる：managed settings の disableAutoMode で、組織全体から auto モードを外せます

自分のセッションがどのモードで始まるかは、次の表の上から順に最初に当てはまる行で決まります（ターミナルまたは VS Code 拡張で起動した場合）。

出典：Choose a permission mode（Claude Code Docs）の「Which mode a session starts in」

ただし、この「組み込みの既定」より優先されるものが2つあります。起動時の --permission-mode フラグと、設定ファイルの permissions.defaultMode です。すでに ~/.claude/settings.json で別のモードを既定にしている人は、そのモードのまま始まり、一度だけ「auto に切り替えますか」と聞かれます。

auto モード（自動承認）とは

auto モードとは、人の代わりに分類器が一つひとつの操作をレビューする権限モードです。Claude Code には権限モードが6つあり、auto はそのひとつです。

どのモードをどんな作業に使うかは、後半の「作業別：どの権限モードを選ぶか」で整理しています。すべての操作を人が確認するモードは、CLI・VS Code・デスクトップアプリで「Manual」と表示されます。設定値は従来どおり default で、v2.1.200 以降は manual という別名でも指定できます。

よくある3つの取り違え

「auto モード」という言葉は、Web 上で別の機能と混同されていることがあります。

• モデルの自動切り替えではない：タスクの難しさに応じて Opus と Sonnet を切り替える機能と誤解されることもありますが、auto モードは権限（確認を出すかどうか）のモードです。モデルの使い分けを自動化したい場合は、plan モードでは Opus、実行時は Sonnet を使う opusplan エイリアス（Model configuration）など、別の仕組みを使います
• 許可リストに登録したツールを確認なしで動かす機能ではない：それは permissions.allow ルールの役割です。auto モードでは、むしろ Bash(*) のような広すぎる許可ルールが一時的に無効になります（後述）
• --dangerously-skip-permissions と同じではない：こちらは bypassPermissions モードで、チェックを一切行いません。auto モードは、確認は出さずにチェックだけ残すモードです

Claude Code 全体の機能や導入手順はClaude Code 完全ガイドにまとめています。

仕組み：分類器は何を見て、どう判定するか

auto モードでは、Claude が操作を実行する前に、決まった順番で判定が進み、最初に当てはまった段階で結論が出ます。

1. 権限ルール：permissions の allow・ask・deny ルールに当てはまる操作は、その場で決まります。ただし保護パスへの書き込みなど一部の例外は分類器に回ります
2. 読み取りと作業ディレクトリ内の編集：自動で承認されます（保護パスへの書き込みと、作業ディレクトリ外への最初の読み取りを除く）
3. それ以外はすべて分類器へ：シェルコマンド、ネットワークアクセス、外部ツール、サブエージェントの起動など
4. 分類器がブロックした場合：Claude に理由が返り、Claude は別の方法を試みます

つまり、日常的なファイルの読み書きには分類器の往復が発生せず、判定コストがかかるのは主にシェルコマンドと外部との通信です。

分類器が見るもの、見ないもの

Claude Code 自身が送る分類器リクエストでは、分類器が見るのはユーザーのメッセージ、Claude のツール呼び出し（ファイル読み取りや検索などの読み取り専用のものを除く）、CLAUDE.md の内容です。ツールの実行結果は取り除かれます。ファイルや Web ページに悪意ある指示が紛れ込んでいても、それが分類器の判断を直接ゆがめることはない、という設計です。

Anthropic の技術解説（Claude Code auto mode, 2026年3月25日）によると、Claude 自身の発言も分類器の入力から外しており、これを「reasoning-blind（推論を見ない）」設計と呼んでいます。Claude が「これは安全です」ともっともらしく説明しても、分類器はその説明ではなく実際の操作だけで判断します。

分類器が CLAUDE.md を読むという点は、実務上とても重要です。CLAUDE.md に「force push はしない」と書いておけば、Claude 本体と分類器の両方にその方針が効きます。CLAUDE.md の書き方はCLAUDE.md の書き方ガイドで解説しています。

2段階の判定

同じ技術解説によると、分類器は2段階で動きます。1段目は「ブロックするか、しないか」だけを即答する高速なフィルタで、疑わしいものは止める側に倒すよう調整されています。1段目が引っかけたものだけを、2段目がじっくり推論して再評価します。社員の実利用データ1万件での誤ブロック率は、1段目だけなら8.5%、2段目まで通すと0.4%でした（当時の分類器は Sonnet 4.6。現在の既定は後述のとおり Sonnet 5）。

サブエージェントも3回チェックされる

サブエージェントに仕事を任せた場合、分類器は（1）起動前に任せる内容、（2）実行中の各操作、（3）終了時の報告内容、の3回チェックします。サブエージェントの定義ファイルで permissionMode を指定していても、auto モードの親セッションから起動した場合は無視されます。

auto モードに入ると外される許可ルール

auto モードに入ると、任意のコードを実行できてしまう広い許可ルールは一時的に外されます。

• Bash(*) や PowerShell(*) のような全許可
• Bash(python*) のようなインタプリタのワイルドカード
• パッケージマネージャーの run コマンド
• Agent の許可ルール、Monitor の許可ルール

Bash(npm test) のような狭いルールはそのまま有効です。外されたルールは、auto モードを抜けると元に戻ります。設定ファイル自体は書き換えられません。

既定でブロックされる操作・許可される操作

分類器は、作業ディレクトリと、セッション開始時に設定されていたリモートリポジトリだけを信頼します。それ以外はすべて「外部」とみなされ、社内のサーバーや会社のクラウドバケットであっても、設定で信頼先として登録するまではブロックされることがあります。

公式ドキュメントに記載されている主な既定ルールを整理すると、次のとおりです（Claude Code v2.1.195 以降で追加されたものを含みます）。

逆に、既定で許可される操作は次のとおりです。

• 作業ディレクトリ内のローカルなファイル操作
• ロックファイルやマニフェストに書かれた依存パッケージのインストール
• .env を読んで、その認証情報を対応する API に送ること
• 読み取り専用の HTTP リクエスト
• 作業中のリポジトリへの push（デフォルトブランチを含む。ただし production や gh-pages のように、名前がデプロイ先を示すブランチは個別に判断されます）

最後の「デフォルトブランチへの push も既定で許可」は v2.1.211 以降の仕様で、古い版では扱いが異なります（後述の実機検証で比較しています）。main への直接 push を人の確認なしに行わせたくない組織は、後述の permissions.ask ルールで明示的に止める必要があります。

完全な一覧は、手元で claude auto-mode defaults を実行すると JSON で確認できます。

許可ルールでも素通りできない「保護パス」

.git、.claude（.claude/worktrees を除く）、.vscode、.husky、.devcontainer などのディレクトリと、.bashrc・.zshrc・.gitconfig・.npmrc・.mcp.json などのファイルは保護パスと呼ばれます。auto モードでは、これらへの書き込みは必ず分類器の判定を通ります。許可ルールで Edit(.claude/**) と書いても、事前承認にはなりません。

同様に、ファイルシステムのルートとその直下のディレクトリ、ホームディレクトリ、作業ディレクトリとその親などを対象にした rm・rmdir は、許可ルールや PreToolUse hook の allow では承認されません。auto モードでは必ず分類器の判定に回ります。

使い方：切り替えと開始モードの固定

セッション中に切り替える

注意点が2つあります。ひとつは、スマホや Web から自分の PC のセッションを操作する Remote Control では、アプリ側から Auto を選べないことです。Web・スマホからの操作の全体像はClaude Code Web版・スマホ完全ガイドで解説しています。もうひとつは、auto モードが使えない環境では、選択肢そのものに Auto が出てこないことです。

v2.1.247 以降は、Manual や acceptEdits モードで Bash コマンドの確認が出たとき、「Yes, and switch to auto mode」を選ぶと、そのコマンドを承認したうえで auto モードに切り替わります。

起動時に指定する

# このセッションだけ auto モードで始める
claude --permission-mode auto

# このセッションだけ Manual（全操作を確認）で始める
claude --permission-mode default

既定の開始モードを固定する

毎回同じモードで始めたい場合は、permissions.defaultMode を設定します。たとえば、自分の PC ではすべてのセッションを Manual で始めたい場合は、~/.claude/settings.json に次のように書きます。

{
  "permissions": {
    "defaultMode": "default"
  }
}

ここでつまずきやすいのが、"auto" はプロジェクトの .claude/settings.json や .claude/settings.local.json に書いても効かないという点です。"bypassPermissions" も同じ扱いです。auto を既定にしたい場合は、ユーザー設定（~/.claude/settings.json）か managed settings に書きます。

VS Code 拡張の場合は、claudeCode.initialPermissionMode という拡張側の設定で開始モードを固定できますが、この設定は auto を受け付けません。VS Code で auto から始めたいときは、この設定を空のままにして、モード表示から一度「Auto」を選んでおけば、次の会話からそのモードで始まります。

plan モードと組み合わせる

大きな変更を任せるときは、plan モードで方針を固めてから auto モードで実装させる流れが使いやすくなります。

auto モードが使える環境では、plan モード中のシェルコマンドも分類器が審査します（useAutoModeDuringPlan 設定。既定でオン）。調査のためのコマンドのたびに確認が出ることはありません。計画ができあがると、次の選択肢が表示されます。

• Yes, and use auto mode：計画を承認し、auto モードで実装を始める
• Yes, manually approve edits：計画を承認し、編集を1つずつ確認しながら進める
• No, keep planning：plan モードのまま、修正点を伝える

auto モードが使えない環境では、1つめの選択肢は「Yes, auto-accept edits」（編集だけを自動承認）に変わります。計画の段階では人がしっかり確認し、実装の細かい確認は分類器に任せる、という分担ができます。

auto モードが使えない・選択肢に出てこないときの確認点

auto モードは全プランで利用できますが、次の条件をすべて満たす必要があります。

「Auto が選択肢に出てこない」「auto を指定したのに Manual で始まる」という場合は、次の順に確認します。

1. モデル：/model で選んでいるモデルが上の表の対応モデルか
2. disableAutoMode：ユーザー設定・プロジェクト設定・managed settings のどこかに書かれていないか（どの設定ファイルに書いても効きます）
3. 設定の置き場所："defaultMode": "auto" をプロジェクトの .claude/settings.json や .claude/settings.local.json に書いていないか（そこでは効かないため ~/.claude/settings.json に移す）
4. 操作している画面：Remote Control ではアプリ側から Auto を選べない
5. クラウド経由の古い版：Amazon Bedrock などのクラウド経由で v2.1.158〜v2.1.206 を使っている場合は、環境変数 CLAUDE_CODE_ENABLE_AUTO_MODE=1 の設定も必要でした（v2.1.207 で不要になりました）
6. 一時停止：Anthropic 側で止められている、またはサーバーが auto モードを拒否した場合、そのセッションが終わるまで auto モードはオフのままです。時間をおいて新しいセッションを始めます

実機検証：v2.1.145 と最新 v2.1.282 の既定ルールを比べる

auto モードの判定ルールは、Claude Code のアップデートのたびに追加・変更されています。そこで、手元の macOS 環境にある Claude Code v2.1.145 と、2026年9月25日時点の npm 上の最新版 v2.1.282 で同じコマンドを実行し、既定ルールの違いを確認しました（v2.1.282 は作業用ディレクトリに入れ、設定ディレクトリも分けて実行しています）。

実行したコマンドと結果

$ claude --version
2.1.145 (Claude Code)

$ claude auto-mode --help
Commands:
  config              Print the effective auto mode config as JSON: your
                      settings where set, defaults otherwise
  critique [options]  Get AI feedback on your custom auto mode rules
  defaults            Print the default auto mode environment, allow,
                      soft_deny, and hard_deny rules as JSON
  help [command]      display help for command

$ claude --version
2.1.282 (Claude Code)

$ claude auto-mode --help
Commands:
  config              Print the effective auto mode config as JSON: your
                      settings where set, defaults otherwise
  critique [options]  Get AI feedback on your custom auto mode rules
  defaults [options]  Print the default auto mode environment, allow, soft_deny,
                      and hard_deny rules as JSON
  help [command]      display help for command
  reset [options]     Reset auto mode configuration to the shipped defaults by
                      removing the autoMode section from your user settings file

claude auto-mode defaults の出力（JSON）を区分ごとに数えると、次のとおりでした。

ブロック側（soft_deny）のルールは2倍以上に増えています。一方で hard_deny は Data Exfiltration の1つだけになり、v2.1.145 で hard_deny だった Safety-Check Bypass（フラグや別名を使って権限チェックをすり抜ける操作）と同じ内容は、v2.1.282 では soft_deny の Auto-Mode Bypass に含まれています。

バージョンで変わった点

同じ「auto モード」でも、バージョンによって何が止まり何が通るかが変わります。 とくに「main への push」は、v2.1.145 では止まり、v2.1.282 では通るという逆向きの変化を実機で確認できました。チームで挙動がそろわないときは、まず全員の claude --version を確認してください。

なお、この検証は2つのバージョンのヘルプ表示と既定ルールの出力までです。auto モードで実際に操作を実行させたときの判定結果は検証していません。

ブロックされたとき・auto モードが止まったとき

1回ブロックされた場合

分類器がブロックすると、画面に通知が出て、その操作が /permissions の Recently denied タブに記録されます。対象の操作を選んで r を押すと、手動で承認して再実行できます。Claude 側も理由を受け取り、多くの場合は別の安全な方法を自分で探します。

入力欄付近の通知には bash denied by auto mode · [Data Exfiltration] · /permissions のように、ツール名と、角かっこで囲まれたルール名が表示されます。

ブロックが続いた場合（手動確認への自動切り替え）

分類器が連続3回、またはセッション中に合計20回ブロックすると、auto モードは一時停止し、通常の確認プロンプトに戻ります。 この回数は変更できません。確認に出てきた操作を承認すると、auto モードが再開します。

claude -p による非対話実行では確認を出せないため、この回数に達するとその操作は実行されず、Claude はそのまま作業を続けます。CI で auto モードを使う場合は、「止まったら気づける」仕組みを別に用意しておく必要があります。

直し方の3択

ブロックの理由を見て、次のどれかを選びます。

3つめの「会話での承認」には条件があります。操作と、その操作を危険にしている具体的な対象の両方を名指しする必要があります。 「force push していいよ」だけでは解除されず、「feature/login ブランチに force push してよい」のように伝える必要があります。また、この承認は原則としてその1回の操作にしか効きません。

同じ接続先で何度もブロックされるのは、分類器が社内環境の情報を知らないことが原因の場合がほとんどです。次の節の autoMode.environment で信頼先を登録すると、多くの場合は解消します。

なお、「分類器が一時的に利用できない」といった分類器側のエラーでブロックされた場合は、通常は設定を変える必要はありません（Amazon Bedrock では、指定されたモデルをアカウントが呼び出せるようになるまで繰り返すことがあります）。エラー文ごとの対処はClaude Code エラー対処法にまとめています。

危険な rm の確認は2分で自動的に拒否される（v2.1.281 以降・主に bypassPermissions）

CHANGELOG によると、v2.1.281（2026年9月23日 UTC 公開）から、auto モードと --dangerously-skip-permissions で出る危険な rm の確認は、2分以内に応答がなければそのコマンドを拒否し、書き換え方のヒントを Claude に返すようになりました。 人が席を外していても、無人のセッションが確認待ちで止まり続けないようにするための変更です（出典：Claude Code CHANGELOG）。

ただし公式ドキュメントの表では、ルートやホームディレクトリなど重要なパスを対象にした rm に確認を出すのは Manual・acceptEdits・plan・bypassPermissions の各モードで、auto モードでは確認を出さずに分類器の判定に回るとされています（前述）。CHANGELOG が挙げる2つのうち、確認が出る典型は --dangerously-skip-permissions（bypassPermissions モード）です。公式ドキュメントは、そこで出る確認の例として、rm -rf "$DIR"/* のように変数の直下を消すコマンドに対し、rm -rf "${DIR:?}"/* のように変数が空ならエラーで止まる書き方を案内するとしています。

2分での自動拒否を止めて確認を待ち続けたい場合は、CHANGELOG によると環境変数 CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1 を設定します（2026年9月25日時点で、公式の環境変数一覧には未掲載）。手元の v2.1.282 の実行ファイルにも、この環境変数名が含まれていることを確認しました。

設定：autoMode ブロックの書き方

どこに書くか

分類器の設定は autoMode というブロックに書きます。分類器が読むのは次の3か所だけです。

プロジェクトの .claude/settings.json と .claude/settings.local.json の autoMode は読まれません。 リポジトリ内のファイルに許可ルールを仕込まれるのを防ぐためです（.claude/settings.local.json が対象外になったのは v2.1.207 から）。

信頼先を登録する（environment）

多くの組織では、autoMode.environment を設定するだけで十分です。書き方は正規表現ではなく、新しく入ったエンジニアに社内環境を説明するような文章です。

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/example-corp and all repos under it",
      "Trusted internal domains: *.internal.example.com",
      "Key internal services: CI at ci.example.com, package registry at npm.example.com"
    ]
  }
}

まずは GitHub などのソース管理の Organization と主要な社内サービスを登録し、ブロックが出るたびに信頼するドメインやバケットを足していくのが、公式ドキュメントが勧める進め方です。保存したら claude auto-mode config で、実際に使われる設定に反映されたかを確認します。

"$defaults" を書き忘れると、既定ルールが消える

設定例の先頭にある "$defaults" は、組み込みの既定ルールをその位置に差し込むという意味です。これを書かずに soft_deny や hard_deny を設定すると、その区分の既定ルールがすべて置き換わります。 たとえば soft_deny を "$defaults" なしで書くと、force push や外部スクリプトの実行、本番デプロイのブロックが丸ごと外れます。

ルールの追加には次の3つの区分を使います。

独自ルールを書いたら claude auto-mode critique を実行すると、曖昧なルールや誤ブロックを招きやすいルールを AI が指摘してくれます。

そのほかの便利な機能

• /auto-mode-setup：プロジェクトの CLAUDE.md・README・設定ファイル・git リモートや、最近のセッションで実行したコマンドのホスト名などから、environment の下書きを作ってくれるコマンドです。Pro・Max・Team プランと v2.1.228 以降が必要です
• /permissions の Auto mode タブ：設定ファイルを開かずにルールを追加・編集できます（v2.1.246 以降）
• autoMode.classifyAllShell：true にすると、Bash(npm test) のような狭い許可ルールも無効にし、すべてのシェルコマンドを分類器に通します。確実性は上がりますが、その分だけ待ち時間と判定回数が増えます（v2.1.193 以降）

防御レイヤーの使い分け

auto モードには「止める仕組み」が複数あり、効き方が違います。絶対に実行させたくない操作を、分類器や会話での指示だけに任せないことが要点です。

「main への push の前には必ず人が確認したい」という場合は、次のように permissions.ask を書くのが最も直接的です。

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

ただし、このルールは git push で始まるコマンドにしか一致しません。コマンドの全文を見て判定したい場合は、PreToolUse hook を組み合わせます。hook の書き方はClaude Code Hooks 自動化ガイドを参照してください。

また、個人が autoMode.allow に追加したルールは、組織が soft_deny に入れたルールを上書きできます。組織として絶対に越えさせたくない線は、managed settings の permissions.deny に置くのが公式ドキュメントの推奨です。

安全性データとコスト

公式が公表している数字の読み方

Anthropic は8月7日の発表（Auto mode is now the default in Claude Code for Pro, Max, and Team plans）で、既定化の根拠となるデータを公開しています。

また、3月25日の技術解説（当時の分類器による社内評価）では、社員のセッションから集めた「頼まれていない過剰な操作」52件のうち17%を、分類器が見逃したと報告されています。分類器は確認疲れした人よりは多くを止めるが、すべてを止めるわけではないというのが、公表データの正確な読み方です。公式ドキュメントも「auto モードは確認を減らすが、安全を保証するものではない」と明記し、機密性の高い操作ではレビューの代わりにしないよう注意を促しています。8月7日の発表でも、本番インフラへの重要な変更は人が確認することを勧めています。

料金とレイテンシ

• Pro・Max・Team：分類器が使う追加トークンは、8月7日から課金対象外になりました
• Enterprise・Claude API・Amazon Bedrock などのクラウド経由：分類器の呼び出しはトークン使用量に計上されます（サーバー側で審査された操作を除く）
• 待ち時間：確認のたびに会話の一部と実行予定の操作が送られるため、実行前に1往復分の待ち時間が加わります
• サーバー側での審査：分類器を別に呼び出す代わりに、モデルへのリクエストの中でサーバー側が操作を審査する方式があります。サーバー側で審査された操作には、別途の分類器呼び出しは発生しません。公式ドキュメントによると、Anthropic API への直接接続（対話型のターミナルセッション）では Pro・Max・Team が v2.1.271 以降、Enterprise と Claude API が v2.1.278 以降で順次対象になり、クラウド経由や LLM ゲートウェイ経由では v2.1.278 以降で既定です
• v2.1.281 以降（2026年9月23日 UTC 公開）：サーバー側の審査があるセッションでは、読み取り専用のシェルコマンドやサンドボックス内のコマンドも審査を待ち、問題ありと判定されればブロックされます
• v2.1.282 以降（2026年9月24日 UTC 公開）：テレメトリを無効にしているなどで機能フラグを取得しないセッションでも、既定でサーバー側の審査を使うようになりました。自前の分類器呼び出しに戻したい場合は CLAUDE_CODE_AUTO_MODE_SERVER=0 を設定します（Anthropic API への直接接続では v2.1.281 以降が必要。手元の v2.1.282 の実行ファイルにもこの環境変数名が含まれていることを確認しました）
• 分類器は、/model で選んだモデルではなく、既定で Claude Sonnet 5 で動きます（例外あり）

読み取りと作業ディレクトリ内の編集は分類器を通らないため、コストが増えるのは主にシェルコマンドとネットワーク操作です。プランごとの料金体系はClaude Code 料金プラン完全ガイドで比較しています。

作業別：どの権限モードを選ぶか

auto モードは万能ではなく、作業によっては別のモードのほうが適しています。公式ドキュメントの「Common setups」をもとに、目的別に整理すると次のとおりです。

CI のように人が画面を見ていない環境では、auto モードより dontAsk のほうが結果を予測しやすい点に注意してください。auto モードは分類器の判断で操作が止まることがあり、claude -p ではブロックが続くと操作がスキップされたまま処理が進みます。許可するコマンドが決まっている作業なら、許可リストを明示する dontAsk のほうが向いています。

チェックなしで動かす場合のコンテナ設計は、Claude Code × Docker 活用ガイドで解説しています。

組織導入：情シス・開発責任者が決めること

組織として決める前に、利用条件はauto モードが使えないときの確認点で確認しておいてください。

方針別の managed settings 雛形

組織全体に配る設定は managed settings に書きます。公式ドキュメントに記載されたキーだけを使った雛形を2つ示します。社名やドメインは自社のものに置き換えてください。

A. auto モードを採用し、越えさせない線を固定する場合

{
  "permissions": {
    "defaultMode": "auto",
    "disableBypassPermissionsMode": "disable",
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  },
  "autoMode": {
    "environment": [
      "$defaults",
      "Organization: Example Corp. Primary use: software development",
      "Source control: github.com/example-corp and all repos under it",
      "Trusted internal domains: *.internal.example.com"
    ]
  }
}

• defaultMode: "auto" で、Enterprise や API キー利用でもターミナルのセッションは auto モードから始まります（対応モデルを使っている場合）。Enterprise・API キー利用時の VS Code 拡張は managed settings の開始モードを読まないため、各自がモード表示で選びます
• disableBypassPermissionsMode で、チェックなしの bypassPermissions モードを禁止します
• ask で push と PR 作成の前に人の確認を入れ、deny で秘密情報のファイルを読ませないようにします

B. 当面は auto モードを使わせない場合

{
  "disableAutoMode": "disable"
}

Shift+Tab の選択肢から auto が消え、--permission-mode auto で起動しても Manual で始まります。管理者が配信した設定が届くと、すでに auto モードで動いているセッションも auto モードを抜けます（v2.1.251 以降）。

Enterprise プランについて、Anthropic は8月7日の発表で、Enterprise・Claude API・クラウド経由のすべてで「今後1か月のうちに既定にする予定」とし、Enterprise の管理者には事前に通知するとしていました。本記事執筆時点（2026年9月25日）に取得したドキュメントでは、Enterprise の開始モードはまだ Manual です。既定が変わる前に、A と B のどちらの方針にするかを決めておくことをおすすめします。

段階的に広げる進め方

いきなり全社で auto モードを既定にするより、次の3段階で広げるほうが、誤ブロックと見落としの両方を減らせます。

1. 一部のチームで試す：autoMode.environment にはソース管理と主要な社内サービスだけを登録し、一定期間使ってもらいます。ブロックされた操作は /permissions の Recently denied タブに残るので、その内容を集めます。記録を仕組みで集めたい場合は、ブロックされた操作の入力を受け取れる PermissionDenied hook を使います
2. 記録から設定を育てる：同じ接続先で繰り返しブロックされているものは environment に、定型的で安全な操作は allow に追加します。独自ルールを書いたら claude auto-mode critique で曖昧な書き方がないかを確認し、claude auto-mode config で反映を確かめます
3. managed settings で全社に配る：固まった設定を managed settings で配信し、あわせて Claude Code のバージョンの下限を社内ルールとして決めます

導入前チェックリスト

• 社内で使われている Claude Code のプラン（Pro・Max・Team・Enterprise・API キー・クラウド経由）を把握した
• 全員の Claude Code のバージョンを確認し、下限を決めた（判定ルールがバージョンで変わるため）
• auto モードを使う・使わないの方針を決め、managed settings で配信した
• bypassPermissions を禁止するかどうかを決めた
• 本番環境・秘密情報・顧客データの所在を洗い出し、permissions.deny と autoMode.environment に反映した
• main への push や PR 作成に人の確認を入れるかどうかを決めた
• 社内のソース管理・パッケージレジストリ・CI を autoMode.environment に登録した
• CLAUDE.md に、チーム共通の禁止事項（force push 禁止など）を書いた
• claude -p を CI で使う場合、ブロックの上限に達して操作がスキップされたことに気づく仕組みを用意した
• ブロックの記録を集めたい場合、PermissionDenied hook での記録方法を決めた

セキュリティ評価の全体像はClaude Code のセキュリティ対策と企業導入、全社展開の進め方はClaude Code エンタープライズ導入ガイドで解説しています。

情シスへの確認依頼テンプレート

開発チームから情シスへ確認を依頼するときは、次の文面をそのまま使えます。

件名：Claude Code の auto モード（自動承認）の利用方針についてご確認のお願い

Claude Code では 2026年8月14日から、Pro・Max・Team プランの新規セッションが
「auto モード」で始まるようになりました。auto モードでは、コマンド実行やファイル編集の
前の確認が出ず、AI の分類器が危険かどうかを判定します。

以下の点について、方針のご確認をお願いします。

1. 当社で auto モードを利用してよいか（利用しない場合、managed settings で
   disableAutoMode を配信いただく必要があります）
2. 確認なしの bypassPermissions モードを禁止するか
3. AI に読ませてはいけないファイル・ディレクトリ（秘密情報、顧客データ）の範囲
4. 社内の信頼できる接続先（GitHub Organization、社内ドメイン、パッケージレジストリ）
5. main ブランチへの push や PR 作成の前に、人の確認を必須にするか

参考：https://code.claude.com/docs/en/permission-modes

よくある質問

まとめ

• auto モードは、確認を出さずにチェックだけを残す権限モード。2026年8月14日から Pro・Max・Team の既定になった
• Enterprise・API キー・クラウド経由は、2026年9月時点でまだ Manual 開始。今後の既定化に備えて方針を決めておく
• 分類器は作業ディレクトリと既存のリモートだけを信頼する。社内の接続先は autoMode.environment に登録する
• "$defaults" を書き忘れると既定のブロックルールが消える
• 判定ルールはバージョンで変わる。v2.1.145 では main への push が止まり、v2.1.282 では通る
• 絶対に越えさせたくない線は、分類器ではなく managed settings の permissions.deny で止める