Claude Code Auto Mode とは｜2層防御・90%自律コーディング目標・Pro/Max展開を徹底解説【2026年5月】

Claude Code Auto Mode（オートモード）は、Anthropicが2026年3月24日に投入した「全承認」と「全スキップ」の中間を担う第三の権限モードです。AIクラシファイアが各ツール呼び出しを事前評価し、安全と判断したアクションだけを自動実行することで、--dangerously-skip-permissions よりも安全に承認疲れを解消します。

ただし重要な注意点があります。Auto ModeはProプラン（月額20ドル）では利用できません。 公式ドキュメントは Max / Team / Enterprise / API 直接利用の4経路のみを対応プランとして明記しており、AWS Bedrock・GCP Vertex AI・Azure Foundry などサードパーティ経由でも使えません。検索意図として「Pro/Max展開」が話題になっていますが、現時点ではMax以上のプラン契約か、Anthropic直接のAPI契約が前提となります。

この記事でわかること:

• Auto Mode の正確な定義と、既存パーミッションモード（default / acceptEdits / plan / dontAsk / bypassPermissions）との違い
• 2層防御アーキテクチャ（入力層プローブ × 出力層 Sonnet 4.6 分類器）の中身
• 公式公開の性能数値（Stage 1 FPR 8.5% → Full Pipeline FPR 0.4%、合成攻撃に対するFNR 5.7%）
• 対応プラン・対応モデル・有効化手順の最新情報
• Mercado Libre が掲げる「Q3 2026 までに90%自律コーディング」目標と Auto Mode の関係
• 17%の見逃し（FNR）を補うための permissions.deny 併用パターンと隔離環境推奨
• こんな人におすすめ／おすすめしない人

誰向けの記事か:

• Claude Code を毎回承認なしで動かしたいが安全性が気になる開発者
• Pro プランで Auto Mode が出ない理由を確認したい個人ユーザー
• 部下・チームに Auto Mode を解放するか判断したいテックリード・SRE
• セキュリティレビューで「AIエージェントの blast radius（影響範囲）」を説明する必要がある責任者

Auto Mode とは何か：30秒で要点

出典: Anthropic Engineering Blog — Claude Code Auto Mode

Auto Mode は、Claude Code 上で各ツール呼び出しの可否をユーザーではなく専用のClaude Sonnet 4.6 分類器（classifier）に判定させる新しいパーミッションモードです。安全と判定されたアクションは自動実行、危険または曖昧なアクションはブロックして代替案を探索、それでも進まない場合は通常の承認プロンプトへフォールバックします。

公式（Anthropic Engineering Blog）は、旧来の Claude Code でユーザーが承認していたツール呼び出しの 約93%が結局そのまま承認されていたことを発端として説明しています。つまり大半の承認は形骸化しており、人間が貴重な判断力を「ファイルを読んでもいいか」のような低リスク判定に消耗していたわけです。Auto Mode はこの93%を分類器に肩代わりさせ、人間は残り7%の本当に重要な判断に集中させる設計です。

【最重要】Auto Mode はProプランでは利用できない

出典: Claude 公式 — Pricing

検索意図でしばしば「Claude Code Auto Mode Pro」と入力されますが、2026年5月時点でProプラン（月額20ドル）ではAuto Modeは利用できません。 これは公式ドキュメント code.claude.com/docs/en/permission-modes にプラン別対応表として明記されている事実で、誤解されやすいポイントです。

加えて、2026年4月21日には Anthropic が一部の新規ユーザーに対して Pro プランから Claude Code 本体を外すテストを始めたことが The Register などで報道されました。Anthropic はこれを「テスト」と説明しており恒久的な撤回かは未確定ですが、Claude Code を本格活用するなら Max 5x 以上が現時点での実質的なスタートラインだと考えるのが現実的です。

Pro プランからのアップグレード判断基準は、Claude Code の料金プラン全体を整理した記事（Claude Code 料金プランを徹底比較）も合わせて参照してください。

既存パーミッションモードとの違い

Claude Code には Auto Mode 以前から複数のパーミッションモードが用意されていました。Auto Mode を理解する最短ルートは「他のモードと何が違うか」を整理することです。

整理すると、bypassPermissions の「全フリー」と default の「全聞く」のあいだに、AIクラシファイアによる動的判定が挟まるのが Auto Mode の独自性です。acceptEdits は静的にホワイトリスト化された行動だけを通すのに対し、Auto Mode は文脈（ユーザーの直前の指示・対象ファイル・ツール引数）まで読み取って判断するため、より広い範囲を自動化しつつ危険行動だけを止められます。

CI/CD のように完全に決定的な承認が欲しい場面では dontAsk の方が適しています。Auto Mode と GitHub Actions・dontAsk の使い分けは Claude Code GitHub Actions 連携の実装ガイド も参照してください。

仕組み：2層防御アーキテクチャ

出典: Claude 公式ブログ — Auto mode for Claude Code

Auto Mode の中核は 「入力層プローブ × 出力層分類器」の2層防御 です。攻撃や誤動作は入口と出口の両方で検知されるため、単一の判定モデルに依存するよりも回避が困難になります。

入力層：サーバーサイド プロンプトインジェクション プローブ

ファイル読み取り、Web fetch、シェルコマンドの出力、外部ツールからの応答などが Claude のコンテキストに入る前にスキャンされます。「ignore previous instructions」「forget your guidelines」のような攻撃文字列を検知すると、結果と一緒に警告メッセージを注入し、Claude にユーザーの本来の意図への再アンカリングを促します。

出力層：Transcript Classifier（Claude Sonnet 4.6 で動作）

各ツール呼び出しが実行される前に、別個の Claude Sonnet 4.6 インスタンスがその安全性を評価します。重要なのは分類器が「ユーザーメッセージ」と「ツール呼び出し本体（ツール名と引数）」だけを見て、メインの Claude のアシスタント文やツール出力は意図的に排除している点です。

この設計により、メインの Claude が「クラシファイアにこう説明して通そう」と誘導するような自己説得・社会的証明攻撃を防いでいます。エージェントが分類器を「説き伏せて」危険行動を通すことができない構造です。

2段階分類（Two-Stage Classification）

出力層の分類器は、応答性とコストを両立させるために2段階で動きます。

ほとんどのアクションは Stage 1 で「安全」と判断されてそのまま流れ、怪しいものだけ Stage 2 が深く考える、という二段ロケット構造です。これにより通常運用ではレイテンシ増加を最小化しつつ、危険行動には詳細な推論を当てられます。

公式公開の性能数値：FPR 0.4%・FNR 17%

Auto Mode は Anthropic Engineering Blog に実測ベンチマークが公開されている、珍しい AI 安全機構です。日本語記事ではほとんど引用されていない数値ですが、運用判断には欠かせません。

読み解きのポイント:

• FPR 0.4%：通常作業では1000回のツール呼び出しのうち4回しか誤ブロックされない。承認疲れを解消する目的に対して十分な精度
• 過剰行動の見逃し17%：main ブランチへの直接 push、本番環境への危険コマンド実行など、Auto Mode の「観点」に入っている攻撃の17%は通してしまう
• 合成 exfiltration の見逃し5.7%：機密データの外部送信を装う合成データセットでは19/20件をブロック
• 17% の根本原因は、分類器が「ユーザー承認の影響範囲（blast radius）」を完全に推定できない構造的限界。たとえば「ユーザーが事前にこのコマンドを意図したか」を確実に判別する手段がない

公式は「Auto Mode は --dangerously-skip-permissions よりリスクは小さいが、ゼロではない。隔離環境（コンテナ・VM・dev container）での利用を推奨する」と明記しています。Auto Mode は『安全保証』ではなく『承認疲れを許容できるレベルまで下げる仕組み』として位置づけるのが正確です。

セキュリティ観点での AI コーディングの全体リスクは AI コーディングのセキュリティリスクと対策 も合わせて確認してください。

デフォルトでブロック／許可されるアクション

Auto Mode を有効化すると、特に設定をしなくても以下のルールが適用されます。記事の核となる「何が自動で動いて、何が止まるか」を把握しておきましょう。

デフォルトでブロックされるアクション（破壊的・外部影響系）

• curl | bash のようなリモートコードの取得＋即時実行
• 機密データを外部エンドポイントへ送信する操作
• 本番環境へのデプロイやマイグレーション
• クラウドストレージの大量削除（S3 / GCS / Azure Blob）
• IAM ロール変更・リポジトリ権限付与
• 共有インフラ（Terraform、本番DB スキーマ）への変更
• セッション開始時から存在したファイルの不可逆な破壊
• main ブランチへの直接 push、force push

デフォルトで許可されるアクション（局所・低リスク系）

• 作業ディレクトリ内のローカルファイル操作（読み書き）
• package.json や lockfile に宣言済みの依存関係インストール
• .env 読み取りと、対応する公式 API への credential 送信
• 読み取り専用 HTTP リクエスト
• セッション開始ブランチや、Claude が新規作成したブランチへの push

ポイントは、「どこからどこへ何が漏れる可能性があるか（流出経路）」が判定基準になっていることです。同じ「ファイルを書く」操作でも、作業ディレクトリ内で完結するものは許可、/etc/ や ~/.ssh/ のような外部影響範囲が大きい場所は止められます。

サブエージェントは3点でチェックされる

出典: GitHub — anthropics/claude-code

Claude Code の subagent（並列タスク実行用の子エージェント）も Auto Mode の対象です。攻撃者がサブエージェント経由で安全チェックを回避することを防ぐため、3つのタイミングで分類器が走ります。

特に2点目が重要で、「サブエージェント側で permissionMode: bypassPermissions を設定すれば回避できる」と考えがちですが、Auto Mode 配下では子の指定は無効化されます。これは「子エージェント経由でメインの安全網を抜ける」攻撃を防ぐ設計です。

サブエージェント自体の使い方や効率的な並列化は Claude Code サブエージェント徹底ガイド を参照してください。

有効化と設定方法

Auto Mode を使うには、(1) 対応プラン契約、(2) Claude Code v2.1.83 以降、(3) 組織管理者の許可（Team/Enterprise の場合）の3点が前提です。

起動方法

CLI で対話セッション中に /permissions を開き、モードを auto に切り替えます。--enable-auto-mode フラグは2026年4月16日以降は不要になりました（既定で利用可能）。

# 対話セッション内
/permissions
# → Mode: auto を選択

非対話モードで起動する場合は settings.json の defaultMode を auto に設定します（VS Code 拡張は claudeCode.initialPermissionMode への auto 指定は不可で、settings.json 経由のみ）。

autoMode 設定ブロック

autoMode 設定により、組織固有の信頼境界・例外ルールを追加できます。

⚠️ 注意：autoMode.soft_deny を配列で書く際、"$defaults" を含めないと組み込みデフォルトが消える仕様です。公式ドキュメントにも Danger 警告として明記されており、独自ルールを足したい場合は必ず先頭に "$defaults" を入れて継承させます。

CLI コマンド

特に critique は、自然言語の autoMode.environment が曖昧で意図通りに解釈されないケースを早期に検出できる便利な機構です。

フォールバック挙動と運用の落とし穴

自動停止：3回連続ブロック or セッション通算20回ブロック

Auto Mode は閾値を超えると一時停止して通常の承認プロンプトに戻ります。

• 3回連続でブロックが起きた場合
• セッション通算で20回ブロックに達した場合

これは Claude が「ループに入って同じ危険操作を繰り返す」事態を防ぐためで、ユーザーが手動で介入できる状態を必ず確保します。非対話モード（-p フラグ・CI 利用）では繰り返しブロックでセッション自体が中断します。

/permissions の "Recently denied" タブ

ブロックされたアクションは /permissions の "Recently denied" タブに記録され、r キーで再試行できます。意図的なブロックだったか、誤検知だったかを確認しながら運用を改善できます。

落とし穴：Boundaries は context compaction で消える

会話中に「don't push to main」「wait until I review」と指示すると、デフォルト許可ルールでも分類器が一時的にブロックします。これを Anthropic は Boundaries（会話で述べた境界）と呼びますが、長時間セッションで context compaction（会話履歴の要約）が走ると失効する可能性があります。

ハードな保証が必要な場合は、permissions.deny ルール（managed settings）に書いておくのが確実です。Auto Mode の17%見逃しを補う実務テクニックとして、permissions.deny でクリティカルな操作を明示禁止する併用が公式・コミュニティ双方で推奨されています。

// .claude/settings.json（例）
{
  "permissions": {
    "deny": [
      "Bash(git push --force*)",
      "Bash(rm -rf /*)",
      "Bash(terraform apply*)"
    ]
  },
  "autoMode": {
    "environment": "このリポジトリは社内検証用です。本番デプロイ系のコマンドは行わないでください。"
  }
}

セキュリティ重視の設定例は Claude Code セキュリティ設定ガイド も合わせて参考にしてください。

「90%自律コーディング目標」と Auto Mode の関係

検索意図でしばしば話題になる「90%自律コーディング目標」は、3つの異なる文脈が混在しています。記事ではこれを正しく分けて理解することが重要です。

① Mercado Libre の Q3 2026 コミットメント

ラテンアメリカ最大級のEコマース企業 Mercado Libre は、Code with Claude 2026（2026年5月6日サンフランシスコ）で 「Q3 2026 までに自社開発の90%を自律コーディングに移行する」 と宣言しました。これはユーザー側企業のKPIであり、Anthropic の公式目標ではありません。

② Dario Amodei（Anthropic CEO）の予測

Dario は2025年3月のインタビューで「3〜6ヶ月で AI が全コードの90%を書くようになる」「12ヶ月で実質100%」と発言しました。2026年に入ってからは Anthropic CPO が「Anthropic 内部の一部プロダクトでは実質100%」とコメントしています（OfficeChai 報道）。

ただしこれは Anthropic 社内のコード生成比率の話であり、外部ユーザーの自律コーディング目標とは別文脈です。Redwood Research の懐疑的な分析では「マージ済み行ベースでは50%程度にとどまる」との反論もあり、定義によって数値は大きくぶれます。

③ Auto Mode は「90%自律時代」の前提条件

①②に共通するのは、90%自律で動かすには毎回ユーザー承認を待っていられないという現実です。Auto Mode は単発の便利機能ではなく、自律コーディングを安全にスケールさせるためのガードレールとして設計されています。

つまりタイトルの「90%自律コーディング目標」は Anthropic が掲げる業界ビジョン × 顧客の宣言 × Auto Mode が支える前提の3点セットで読むのが正確です。Anthropic 公式が「Auto Mode で90%自律を実現する」と直接表現したエビデンスは現時点では確認できていません。

メリット・デメリット

メリット

• 承認疲れの解消：旧来 Claude Code でユーザーが承認していたツール呼び出しの93%は形骸化していた。Auto Mode はその大半を分類器に肩代わりさせる
• --dangerously-skip-permissions より安全：FPR 0.4% / FNR 17% の数値が公開されており、完全フリーよりはリスクが定量的に低い
• 追加課金なし：分類器のトークン消費はあるが、新しい料金プランは不要
• サブエージェントも自動的に対象：子エージェントの permissionMode を信用しない設計で、回避経路が少ない
• permissions.deny と併用可能：ハードブロックを併用すれば17%見逃しを大きく補える
• 長時間タスクが現実的に：夜間バッチや大規模リファクタリングが「席を立てる」作業になる

デメリット・注意点

• Pro プランで使えない：Max 5x（100ドル/月）以上が事実上の入口
• Bedrock / Vertex / Foundry で使えない：エンタープライズで主要クラウドに統合済みの企業は API 直契約か Enterprise が必要
• 17%の見逃し（過剰行動カテゴリ）：分類器は「ユーザー承認の blast radius」を完全には推定できない
• research preview：2026年5月時点でも公式は GA 表記をしておらず、仕様変更の可能性
• Boundaries は揮発性：会話で指示した境界は context compaction で消えうる。重要事項は permissions.deny へ
• 隔離環境推奨：公式が「コンテナ・VM・dev container」での利用を推奨。本番リポジトリ・本番クラウド資格情報のあるホストでの直接利用は要注意
• VS Code 拡張の claudeCode.initialPermissionMode には auto 指定不可：settings.json の defaultMode 経由のみ
• Claude Code on the web / Remote Control セッション非対応

関連アップデートのタイムライン（2026年）

Code with Claude 2026 では、Auto Mode の周辺機能として Dreaming（過去セッションのレビューによる自己改善・research preview）、Claude Managed Agents + Outcomes（マルチエージェント編成・public beta）、Code Review／CI auto-fix／Security Reviews などが紹介されました。これらは Auto Mode を前提とした「自律して動くエージェント」群の構成要素です。

こんな人におすすめ／おすすめしない人

こんな人におすすめ

• Max 5x 以上を契約済みで、Claude Code を毎日数時間以上使う個人開発者：承認疲れが慢性化している
• 隔離環境（dev container、Docker、専用 VM、ephemeral cloud workspace）で Claude Code を運用しているチーム：blast radius が物理的に限定されている
• 長時間バッチ・大規模リファクタリングを Claude Code に任せたい SRE・テックリード：席を立てる時間を作りたい
• permissions.deny を組織共有設定として整備できる企業：17%見逃しをハードブロックで補える
• Team / Enterprise で Sonnet 4.6 / Opus 4.6 を含めた柔軟なモデル選択をしたい組織

おすすめしない人

• Pro プラン契約のみのユーザー：そもそも Auto Mode が利用不可。Max への切り替えか、API 直接利用が必要
• AWS Bedrock / GCP Vertex / Azure Foundry 経由で Claude を利用している企業：現時点で全プロバイダ非対応
• 本番リポジトリ・本番クラウド資格情報のあるホストで Claude Code を直接動かしているユーザー：FNR 17% の影響をそのまま被る
• 完全な決定論的承認制御が必要な CI/CD パイプライン：dontAsk モード＋静的な permissions.allow の方が運用に向く
• 会話途中の指示（Boundaries）にハードな保証を求める運用：context compaction で揮発する。permissions.deny の併用が前提

よくある質問（FAQ）

Q1. Auto Mode に追加料金はかかりますか？

A. プランの追加料金はありません。ただし出力層の Sonnet 4.6 分類器がツール呼び出しごとに評価を行うため、分類器分のトークン消費が少量加算されます。コスト全体の最適化は Claude Code コスト最適化完全ガイド を参照してください。

Q2. Pro プランで Auto Mode を使う方法はありますか？

A. 現時点では公式に対応する手段はありません。Max 5x（100ドル/月）以上、Team、Enterprise、または Anthropic 直接の API 契約が必要です。Bedrock・Vertex・Foundry 経由でも利用できません。

Q3. Auto Mode は Opus 4.7 でしか使えないのですか？

A. 利用するプランで対応モデルが異なります。Max プランは Opus 4.7 のみ、Team / Enterprise / API は Sonnet 4.6 / Opus 4.6 / Opus 4.7 のいずれも利用可能です。Haiku や Claude 3 系では利用できません。

Q4. --dangerously-skip-permissions と何が違いますか？

A. bypassPermissions はチェック一切なしで全ツール呼び出しを実行します。Auto Mode は同じく承認プロンプトを出さない動作ですが、各呼び出しを Sonnet 4.6 分類器が事前評価し、危険行動はブロックします。公式測定では合成 exfiltration の95%程度を阻止していますが、5.7%は通る点に注意してください。

Q5. 17% の見逃しが怖いのですが、どう運用すべきですか？

A. 公式・コミュニティ双方が推奨するのは以下の3点です。

1. 隔離環境で動かす：コンテナ・VM・dev container を使い、blast radius を物理的に限定する
2. permissions.deny を併用する：force push、rm -rf /、本番デプロイ系コマンドなどクリティカルな操作はハードブロック
3. autoMode.environment で環境を明示する：自然言語で「このリポジトリは検証用」「本番ドメインへのアクセスは禁止」と書いておく

Q6. CI/CD で Auto Mode を使うべきですか？

A. 推奨されません。CI/CD では非対話モード（-p）でブロックが繰り返されるとセッションが中断されます。CI には事前承認ホワイトリスト方式の dontAsk モード＋ permissions.allow の方が運用安定性が高く、Claude Code GitHub Actions 連携の実装ガイド でも Auto Mode 以外を推奨しています。

Q7. Auto Mode は GA（正式版）になりましたか？

A. 2026年5月時点で、公式ドキュメントは依然「research preview（研究プレビュー版）」と表記しています。仕様や挙動は変更される可能性があるため、本番運用に組み込む際は公式ページで最新情報を確認してください。

Q8. Boundaries（会話で述べた境界）と permissions.deny の違いは？

A. Boundaries はユーザーが会話中に「don't push to main」と言ったような自然言語の制約で、Auto Mode の分類器がその文脈で動作中だけ尊重します。context compaction（会話履歴要約）で失効する可能性があります。一方 permissions.deny は静的な設定ファイルで、Auto Mode より前段で必ず評価されるハードブロックです。重要な制約は permissions.deny に書くのが鉄則です。

まとめ

Claude Code Auto Mode は「全承認」と「全スキップ」のあいだに AIクラシファイアによる動的判定を挟む第三の権限モードです。重要ポイントを整理します。

• Pro プランでは利用不可。Max / Team / Enterprise / API 直接の4経路のみ対応
• 入力層プローブ × 出力層 Sonnet 4.6 分類器の 2層防御。Stage 1+2 の構造で FPR 0.4% / FNR 17% という公開数値を持つ
• 17% の見逃しは構造的限界。permissions.deny 併用と隔離環境が公式推奨
• サブエージェントの permissionMode 指定は無視され、子も親と同じルールで評価される
• Boundaries（会話の境界）は context compaction で揮発する。ハードな制約は設定ファイルに書く
• 「90%自律コーディング目標」は Mercado Libre の Q3 2026 コミットメント・Dario の予測・Auto Mode の前提条件という3視点で読む

Claude Code 全体の理解を深めたい方は、まず上位概念を整理した Claude Code とは？機能・料金・使い方を徹底解説 から、料金詳細は Claude Code 料金プランを徹底比較 を、安全な活用設計は AI コーディングのセキュリティリスクと対策 を順に読むことで、Auto Mode を組織で導入する判断材料が揃います。

Auto Mode はまだ research preview ですが、Anthropic が「90%自律時代」の本気度をプロダクトとして示した最初の実装です。安全側に倒して隔離環境で試し、permissions.deny で守りを固めながら使う——これが2026年5月時点での最も合理的なスタートラインです。