Claude Codeのauto modeとは？仕組み・設定方法・注意点を解説

「Claude Codeが何度も『実行してよいですか』と聞いてくるので、作業が止まってしまう」「確認を全部飛ばす設定は怖くて使えない」と感じている方も多いのではないでしょうか。

その中間にある選択肢が、auto mode（オートモード）です。毎回の確認の代わりに、別のモデルが操作を1つずつ確かめ、危険と判断したものだけを止めます。Claude Codeを新しいバージョンで起動した場合、ターミナルとVS Codeでは最初からこのモードで始まるようになっています。

この記事では、auto modeが何をしていて、ほかの権限モードと何が違うのかを最初に整理します。そのうえで、使える条件、切り替え方、止められたときの対処、自社の環境に合わせる設定、安全に使うための注意までを順に解説します。内容は2026年10月時点の公式ドキュメントをもとにしています。仕様や対応バージョンは変わることがあるので、実際の画面や公式ページもあわせて確認してください。

Claude Codeのauto modeとは

Claude Codeは、ファイルを書き換えたり、コマンドを実行したりして作業を進めます。何をするたびに許可を求めるのか、どこまで自動で進めるのかを決めるのが権限モードです。auto modeは、その権限モードの1つです。

公式ドキュメントによると、auto modeでは「分類器（classifier）」と呼ばれる別のモデルが、実行の前に操作を確かめます。依頼の範囲を超えた操作、見覚えのない外部の環境に向かう操作、読み込んだ文章の中の指示に操られたように見える操作は止められ、それ以外は確認の画面なしで進みます。

確認の画面が出る場面は減る

通常のモード（Manual）では、ファイルの編集やコマンドの実行のたびに、人が許可を出します。auto modeでは、ふつうの作業にあたる操作は分類器が確かめて通すので、人が画面の前で「はい」を押し続ける必要がなくなります。長い作業を任せて席を外したいときに向いています。

一方で、確認を省くモードなので、扱いを間違えると影響が大きくなります。公式ドキュメントにも「確認の画面を減らすが、安全を保証するものではない」という警告があります。この点は、後半の「安全に使うための注意」で詳しく取り上げます。

最初からauto modeで始まる

公式ドキュメントでは、Claude Code v2.1.283以降では、ターミナルとVS Codeのセッションは、最初からauto modeで始まると説明されています。それより前のバージョンでは、Pro・Max・Teamプランだけが最初からauto modeでした。

初めてauto modeで始まったときには、ターミナルの上部に説明の通知が1回だけ出ます。「いつの間にか確認が出なくなった」と感じたときは、まず画面下のステータス表示を見てください。auto modeのときは「auto mode on」と表示されます。

確認を出す従来の動きに戻したいときは、後述の方法で、最初に始まるモードを変えられます。

どんな操作を通して、どんな操作を止めるのか

細かい一覧は後の章で扱います。ここでは大まかな分け方だけ押さえておきましょう。

ほかの権限モードとの違い

Claude Codeの権限モードは、auto modeを含めて6つあります。公式ドキュメントの内容を表にまとめました。

名前に「auto」と付いていても、acceptEditsとは別物です。acceptEditsはファイルの編集と基本的なファイル操作だけを自動にするモードで、そのほかのコマンド実行（テストやビルドなど）は引き続き確認が出ます。auto modeは、コマンド実行やネットワークへのアクセスも含めて、分類器が確かめたうえで進めます。

bypassPermissionsとの違い

確認を全部飛ばす--dangerously-skip-permissions（bypassPermissions）との違いは、安全確認が残るかどうかです。bypassPermissionsは、確認も安全チェックも行わず、保護されたファイルへの書き込みも通します。公式ドキュメントでは、このモードは「プロンプトインジェクションや意図しない操作に対する保護はない」とされ、コンテナや仮想マシンなどの隔離された環境だけで使うよう書かれています。

Anthropicのブログでも、auto modeは--dangerously-skip-permissionsの「より安全な代わり」と位置づけられています。ただし、同じ記事の中で「リスクを減らすが、なくすわけではない」と明記されています。

planモードとの関係

planモードは、ファイルを書き換えずに調べて計画を立てるモードです。auto modeが使える環境では、計画中のコマンドも、確認の画面の代わりに分類器が確かめます（useAutoModeDuringPlanという設定が、既定でオンになっています）。計画ができあがったあとの選択肢には「Yes, and use auto mode」があり、承認と同時にauto modeに切り替えて、そのまま実装に進めます。

どう使い分けるか

使える条件と切り替え方

auto modeを使うには、いくつかの条件があります。公式ドキュメントの内容は次のとおりです。

条件を満たしていないセッションでは、auto modeに設定していてもManualで始まります。「auto modeが出てこない」ときは、まず使っているモデルと、管理者の設定を確認してください。Anthropic側で一時的に無効にされている場合もあり、その場合は新しいセッションを始め直す必要があります。

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

ターミナルでは、Shift+Tabでモードを順番に切り替えられます。auto modeで始まっているときは、1回押すとManualになり、続けてacceptEdits → planと進みます。auto modeが使える環境では、planの次にauto modeへ戻ります。ステータス表示は次のように変わります。

ManualやacceptEditsのとき、コマンドの許可を求める画面に「Yes, and switch to auto mode」という選択肢が出ることがあります。その場で承認しながらauto modeに切り替えられます。ただし、この選択肢が出るのはBashコマンドの画面で、PowerShellツールの画面には出ません。askルールやフックで強制された確認の画面にも出ません。

起動時や初期値を指定する

起動するときに指定するなら、フラグを使います。

claude --permission-mode auto
claude --permission-mode default

2行目のdefaultはManualのことです。manualという別名でも指定できます。毎回指定したくない場合は、settings.jsonのpermissions.defaultModeで、最初に始まるモードを決められます。たとえば、毎回Manualで始めたいときは、ユーザーフォルダの.claude/settings.jsonに次のように書きます。

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

VS Code・デスクトップアプリでの切り替え

VS Code拡張機能では、入力欄の下にあるモードの表示（mode indicator）をクリックして切り替えます。表示名は、Manual・Edit automatically・Plan・Autoです。デスクトップアプリのCodeタブでは、送信ボタンの横にあるモード選択から選びます。名前は、Manual・Accept edits・Plan・Auto・Bypass permissionsです。

どちらも、auto modeが使えるときだけ「Auto」が選択肢に出ます。デスクトップアプリには、auto mode専用の設定のスイッチはありません。VS CodeのclaudeCode.initialPermissionModeにはautoを指定できないので、Autoで始めたいときは、設定を空にしたまま、一度モードの表示からAutoを選びます。

分類器が止めるもの・通すもの

auto modeの安全確認を担っているのが分類器です。何を基準に止めているのかを知っておくと、止められたときに原因を考えやすくなります。

判定の順序

公式ドキュメントでは、1つの操作が次の順番で判定されると説明されています。最初に当てはまった段階で結果が決まります。

1. 許可・確認・拒否のルールを見る自分で書いたallow・ask・denyのルールに当てはまれば、そのとおりに処理されます。ただし、保護されたパスへの書き込みなど、ルールに当てはまっても分類器に回されるものがあります。
2. 読み取りと、作業フォルダ内の編集を通す読み取り専用の操作と、作業フォルダの中のファイル編集は、そのまま通ります。
3. それ以外は分類器に回すシェルコマンドやネットワークへのアクセスなどは、分類器が確かめます。
4. 止められたら、理由がClaudeに返るブロックされると、Claudeには理由が返ります。多くの場合は「[Data Exfiltration]」のように、当てはまったルールの名前が示されます。

つまり、ファイルの読み取りと作業フォルダの中の編集は、分類器を通らないため、待ち時間も増えません。分類器が確かめるのは、おもにシェルコマンドとネットワークの操作です。

また、auto modeに入るとき、広い範囲のコマンドを許可していたルール（Bash(*)やBash(python*)のようなもの）は、一時的に無効になります。Bash(npm test)のような限定したルールは、そのまま残ります。auto modeを抜けると、元に戻ります。

既定で止められる操作

公式ドキュメントに載っている、既定でブロックされる操作のうち、おもなものを分類しました。

このほか、v2.1.257以降は、クラウドのメタデータエンドポイントから認証情報を取得する操作や、同じ環境にある別のコンテナ・Podへの接続なども、既定でブロックされます。

既定で通る操作

反対に、次のような操作は、そのまま通ります。

• 作業フォルダの中のファイル操作
• ロックファイルやマニフェストに書かれた依存関係のインストール
• .envの読み取りと、対応するAPIへの認証情報の送信
• 読み取りだけのHTTPリクエスト
• 作業中のリポジトリの、どのブランチへのpush（既定のブランチも含む）
• セキュリティ関連のコードや設定を、作業の一部として読み書きすること

pushについては、デプロイ先を示す名前のブランチ（productionやgh-pagesなど）は別扱いで、分類器が個別に判断します。また、秘密情報が含まれる変更のpushは、どのブランチでも止められます。

信頼されるのは、作業フォルダと設定済みのリモートだけ

分類器が「信頼できる」と見なすのは、作業フォルダと、セッション開始時に設定されていたGitのリモートです。会社のGitHub組織や、チームのクラウドストレージも、設定しない限りは「外部」として扱われます。そのため、社内の別のリポジトリにpushしようとして止められる、ということが起こります。対処の方法は、後述の「自社の環境に合わせる設定」で扱います。

プロンプトインジェクションへの備え

プロンプトインジェクションとは、Webページやファイルの中に、AIへの指示を紛れ込ませて操ろうとする手口です。公式ドキュメントでは、次の2段の備えがあると説明されています。

• Claude Code自身が分類器に送る内容から、ツールの実行結果（ファイルやWebページの中身）を取り除く。そのため、外部の文章が分類器を直接だますことはできない
• サーバー側で、読み込んだ内容を調べて、怪しいものをClaudeが読む前に警告する仕組みがある

それでも「完全に防げる」とは書かれていません。社外から届いたファイルや、出所の分からないWebページを大量に読ませる作業では、auto modeに頼りきらないようにしてください。

サブエージェントも確認される

サブエージェント（手分けして動く別のClaude）に仕事を任せる場合も、分類器は確認します。公式ドキュメントでは、次の3か所で確認されると説明されています。

• サブエージェントを起動する前に、依頼内容が確認される
• 動いている間の操作は、親のセッションと同じ基準で確認される
• 終わったときに、作業内容と最終報告が確認される。問題があれば、報告に警告が付いて親に渡される

サブエージェントの定義ファイルにpermissionModeを書いていても、auto modeの間は無視されます。

止められたときの対処

auto modeで作業していると、操作が止められることがあります。慌てずに、次の順で確認します。

止められた操作を確認する

操作が止められると、通知が出て、/permissionsの「Recently denied」タブに記録されます。タブの中でrを押すと、その操作を再試行するよう指示できます。会話の中で止められた操作を見たいときは、Ctrl+Oでトランスクリプトを開くと、折りたたまれた内容も展開されます。

止められたときの表示の「Denied by auto mode classifier」の横に、[Production Deploy]のような名前が付いています。これは当てはまったルールの名前です。claude auto-mode defaults --label '名前の先頭'で、そのルールの全文を読めます（v2.1.208以降）。

止め方に合った対処を選ぶ

「force pushしていい」のように動詞だけを伝えても、分類器の判断は変わりません。公式ドキュメントでは、操作と、危険な点の具体的な内容（対象のブランチなど）を書く必要があると説明されています。また、承認は書いた1回の操作にだけ効きます。

3回連続・20回合計で一時停止する

分類器が操作を3回続けて、または合計20回ブロックすると、auto modeが一時停止して、確認の画面が出るようになります。確認の画面で承認すると、auto modeが再開します。この回数は変更できません。

何度も止められるのは、分類器が環境の情報を持っていないことが多い原因です。同じ送信先で止められ続けるときは、次の章で説明するように、信頼する環境を設定してください。

なお、-p（非対話の実行）では、確認の画面を出せません。回数の上限に達すると、その操作は実行されず、Claudeは作業を続けます。

エラーが出たとき

止められたのではなく、分類器が答えを返せなかった場合は、別のメッセージが出ます。公式ドキュメントのErrorsのページに、主なものがまとまっています。

自社の環境に合わせる設定

初期状態の分類器は、作業中のリポジトリしか信頼しません。自社のGitHubの別のリポジトリや、社内のサーバー、チームで使っているクラウドストレージなどを使う作業では、どこが信頼できる場所なのかを分類器に教えると、無駄な停止が減ります。

設定を書く場所

分類器の設定は、autoModeという項目に書きます。読み込まれる場所は次のとおりです。

信頼する環境を伝える

多くの組織では、autoMode.environmentだけを設定すれば足ります。信頼するリポジトリ、クラウドストレージ、社内のドメインなどを、文章で書きます。正規表現やツールのパターンではなく、新しく入った人に社内の環境を説明するように書くのが公式の考え方です。

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts",
      "Trusted internal domains: *.corp.example.com"
    ]
  }
}

先頭の"$defaults"は、既定の内容を残したまま、自分の項目を足すための書き方です。保存したあとは、claude auto-mode configで、分類器が実際に使う設定を確認できます。

/auto-mode-setup で下書きを作る

書き方に迷うときは、/auto-mode-setupを実行します。プロジェクトのCLAUDE.mdやGitのリモート、最近のセッションで実行したコマンドを読んで、autoMode.environmentの下書きを作ってくれます。承認すると~/.claude/settings.jsonに書き込まれます。

公式ドキュメントによると、このコマンドはPro・Max・Teamプランとv2.1.228以降（Windowsのネイティブ版はv2.1.233以降）で使え、クラウドセッションでは実行できません。

確認を必ず出したい操作を決める

auto modeでも、pushやpull requestの作成の前には、必ず人が確認したいという場合があります。その場合は、permissions.askにルールを書きます。内容を指定したaskルールは、分類器より先に評価され、auto modeでも必ず確認の画面が出ます。

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

このルールは、コマンドがgit pushやgh pr createで始まる場合に当てはまります。git -C フォルダ pushのような書き方のpushは、当てはまりません。厳密に確かめたいときは、フック（PreToolUse）を使います。

確実に守らせたいことは、会話で伝えるのではなく、askかdenyのルールに書いておく必要があります。

CLAUDE.md の内容も読まれる

分類器は、Claude自身が読み込むのと同じCLAUDE.mdの内容も読みます。たとえば、プロジェクトのCLAUDE.mdに「force pushはしない」と書いておけば、Claudeと分類器の両方に効きます。プロジェクトごとの決まりごとは、まずCLAUDE.mdに書くのが手軽です。

設定を確認・やり直すコマンド

/permissionsの「Auto mode」タブ（v2.1.246以降）では、設定ファイルを開かずに、分類器のルールと環境の項目を見たり、編集したりできます。

安全に使うための注意

auto modeは便利ですが、使い方を間違えると、確認なしで取り返しのつかない操作が通ることがあります。ここでは、使う前に押さえておきたい点をまとめます。

「安全が保証される」わけではない

公式ドキュメントは、auto modeについて「確認の画面を減らすが、安全を保証しない」と明記しています。Anthropicのブログでも、分類器は、ユーザーの意図があいまいなときや、環境についての情報が足りないときに、危険な操作を通してしまうことがあると説明されています。反対に、問題のない操作が、まれに止められることもあります。

公式には、誤判定の割合などの数値は示されていません。信頼できる方向性の作業に使い、重要な操作の確認の代わりにはしない、というのが公式の考え方です。

取り返しがつく状態で使う

分類器があっても、操作を間違える可能性はゼロになりません。次のような備えをしておくと、間違えたときの影響を小さくできます。

• 作業の前に、変更をGitにコミットしておく。元に戻せる状態にしておく
• 本番のデータや認証情報が入った環境では使わない。作業用のコピーで試す
• 大事な作業は、まずplanモードで計画を確認してから、auto modeで実行する
• 社内の機密情報を扱うフォルダは、作業フォルダに含めない

公式ドキュメントでは、サンドボックスやコンテナと組み合わせると、守りがさらに厚くなると説明されています。auto modeの確認と、サンドボックスの制限は、それぞれ独立して動きます。

それでも確認が出る操作がある

auto modeでも、確認が省かれない操作があります。公式ドキュメントでは、次のようなものが挙げられています。

• askルールに当てはまる操作
• .gitや.claude、.bashrc、.mcp.jsonなどの保護されたパスへの書き込み（分類器に回され、自動では承認されない）
• ホームフォルダや作業フォルダなど、重要なパスに対するrm・rmdirによる削除
• 作業フォルダの外のファイルを、初めて読むとき（確認が1回出る）

重要なパスの削除は、ターミナルでは確認の画面が出ます（2分のカウントダウン付き）。VS Codeの会話画面、デスクトップアプリ、-pでは、確認の画面を出せないため、即座に拒否されます。

コストと待ち時間

分類器は、既定ではClaude Sonnet 5で動き、/modelで選んだモデルとは別に動作します。公式ドキュメントによると、確認の際には会話の一部と実行しようとする操作が送られるため、実行の前に1往復分の待ち時間が増えます。ただし、読み取りと作業フォルダの編集は分類器を通らないので、待ち時間が増えるのは、おもにシェルコマンドとネットワークの操作です。

費用の扱いは、アカウントによって異なります。公式ドキュメントでは、EnterpriseプランやAPIを使うアカウントでは、分類器の呼び出しがトークン使用量に数えられると説明されています。一方で、サーバー側で確認される場合は、別の分類器の呼び出しがないため、数えられません。LLMゲートウェイを通している場合などは、サーバー側の確認が使えず、Claude Code自身が分類器を呼び出すことがあります。そのとき、アカウントによっては通知が出ます。

確認したいときは、/statusの「Auto mode server」の行を見ます。「Enabled」ならサーバー側の確認が動いています。

会社で使うときに決めておくこと

チームや会社でClaude Codeを使う場合は、auto modeについても次のような決まりごとを先に作っておくと、人によって使い方がばらばらになるのを防げます。

組織全体の設定では、管理者が配った項目を、個人の設定で削除することはできません。ただし、個人が自分でallowを足すと、組織のsoft_denyを上書きできてしまう点には注意が必要です。公式ドキュメントでも、「分類器の設定は足し算であり、変更できない強制の仕組みではない」と説明されています。絶対に実行させたくない操作は、管理設定のpermissions.denyに書いてください。

よくある質問

まとめ

auto modeは、確認の手間を減らしながら、ある程度の安全を保つための仕組みです。まずは小さな作業で試して、どの操作が止められるのかを確かめながら、使う範囲を広げていくのがおすすめです。

社内でClaude Codeを使い始める段階では、権限のルールや、信頼する環境の設定、使ってよい作業の線引きなど、決めることが増えます。INTERCREATE JAPANでは、Claude Codeの導入から、社内で使い続けられる設定やルールづくりまでをお手伝いしています。