Claude Code Auto Mode 完全攻略 2026——2段階分類器の仕組み・カスタマイズ設定・安全な使い方
Claude Code Auto ModeはShift+Tabで起動する自律承認モード。2段階分類器の仕組み（17%見落とし率含む）、--dangerously-skip-permissionsとの違い、カスタマイズJSON設定、Enterprise封鎖設計まで網羅。
エンジニアのゆとです。
Claude Code Auto Mode は2026年3月24日にリリースされた。Shift+Tab で起動すると、AIが権限プロンプトを自動判断して承認・拒否を行うモードだ。
「便利そう」「でも危なそう」で終わってる記事が多い。「Shift+Tab で起動できます、危険なのでご注意を」——それだけじゃ何も決断できない。
この記事では、Anthropic の公式エンジニアリングブログで公開されている技術的な仕組みを日本語で解説しつつ、--dangerously-skip-permissions との本質的な違い、カスタマイズ設定の書き方、Enterprise向けの封鎖設計まで整理する。「仕組みを理解して使う」ための情報が目的だ。
Auto Mode とは何か（2026年3月リリース）
Claude Code のパーミッション設計を整理すると、もともとは2つの極端な選択肢しかなかった。
一方は、デフォルトの「毎回確認」モードだ。ファイルを読むたびに、コマンドを実行するたびにプロンプトが出る。安全だが、作業リズムが崩れる。
もう一方は --dangerously-skip-permissions フラグを使った「全部スキップ」だ。確認が一切出ない。CI環境やDockerコンテナの中で使うことを想定しており、名前の通り権限チェックを完全に無効化する。
Auto Mode はその中間に位置する。
毎回確認（デフォルト）
↕
Auto Mode ← ここが新しい
↕
全スキップ（--dangerously-skip-permissions）「人間の代わりに AI が判断する」というモードだ。危険そうなアクションは自動でブロック、安全そうなアクションは自動で承認する。人間がいちいちプロンプトに答えなくていい。
なぜ Anthropic がこのモードを作ったか
Anthropic がこのモードを作った理由は明確だ。Claude Code を長時間・大規模タスクで使うときの現実的な問題を解決するためだ。
たとえば「このリポジトリ全体をリファクタリングして」という指示を出すと、数十〜数百回の権限プロンプトが発生する。人間が全部に答えていたら意味がない。かといって全スキップにすると、意図しない操作がすり抜けるリスクが上がる。
Auto Mode はこの問題に対して「AIが安全を判断する」というアプローチで回答した。
Shift+Tab で起動する
Auto Mode の起動方法は2通りある。
一つ目はキーボードショートカット。セッション中に Shift+Tab を押すと、モードが切り替わる。--auto と表示されたら Auto Mode が有効だ。
二つ目はコマンドラインオプション。
claude --permission-mode autoこのフラグをつけて起動すると、最初から Auto Mode になる。
注意点として、Auto Mode の設定はユーザーレベル（~/.claude/settings.json）でのみ有効だ。プロジェクトの .claude/settings.json に書いても無視される。後ほど詳しく説明する。
2段階分類器の仕組み（他の記事が書いていない）
Auto Mode が「どうやって安全を判断するのか」が最も重要な部分だ。
Anthropic の公式エンジニアリングブログ（2026年3月）で公開されている仕組みによると、Auto Mode は2段階の分類器を使っている。ベースモデルは Sonnet 4.6 だ。
ステージ1：ブロック偏向の高速フィルター
ステージ1は単一トークン（“yes” か “no”）を出力する高速フィルターだ。
設計思想として「ブロック偏向」を採用している。判断が難しいケースは積極的に「ブロック」に倒す。精度よりも安全側に外れることを優先する設計だ。
このフィルターが通過させたアクションは即承認される。フラグが立ったアクションはステージ2に進む。
ステージ2：思考チェーンによる再評価
ステージ2は思考チェーン（Chain of Thought）を使った詳細な再評価だ。
ステージ1でフラグが立ったアクションだけが対象になる。より時間をかけて、コンテキストも含めて「これは本当に危険か」を判断する。ステージ2でも危険と判断されたアクションはブロックされる。
「エージェント自身の出力を参照しない」設計の意味
この設計で自分が注目したのは「分類器はユーザーメッセージとコマンドのみを参照する。エージェント自身の出力は参照しない」という部分だ。
これは自己正当化を防ぐための設計だ。
仮にエージェント自身の出力を参照できる設計だったとしたら、こういうことが起きる可能性がある。エージェントが「このコマンドは安全なのでブロックしないでください」という説明を出力として生成し、それを分類器が読んで承認する——という自己ループだ。
「エージェントが自分のアクションを自分で正当化できてしまう」構造は、安全設計として明らかに問題がある。Anthropic はこれを意図的に排除した。
公式が認めた17%の見落とし率とその意味
Anthropic のエンジニアリングブログには、分類器の性能について数値が公開されている。危険なアクションの見落とし率が約17%だという記述がある。
これをどう解釈するか。
「17%も見逃すのか、使えない」と思うか、「83%はブロックできている」と思うか——どちらも正しくない。
大事な文脈は「どういう状況での17%か」だ。エンジニアが長時間離席して大規模タスクを任せる場面では、Auto Mode なしなら100%の確認作業が人間に来る。その中には明らかに安全なものが大半を占める。Auto Mode が83%を自動承認し、17%を見落として人間が対処する必要があるとしても、総合的な負荷は大幅に下がる。
一方で、「分類器が17%見落とす」という事実は、Auto Mode を使う際のリスク認識として正直に持っておくべき数値だ。セキュリティクリティカルな環境でAuto Modeを有効にするなら、この数値を前提に設計する必要がある。
後述するカスタマイズ設定と組み合わせることで、実質的な見落とし率を下げることができる。
Auto Mode vs —dangerously-skip-permissions の違い（最重要）
混同されがちなので、ここは明確にしておく。
--dangerously-skip-permissions は Auto Mode ではない。全くの別物だ。
Auto Mode：分類器が判断する
Auto Mode は分類器が動いている。危険と判断したアクションはブロックされる。
人間の代わりに AI が承認・拒否を行うが、「判断プロセス」は存在する。
—dangerously-skip-permissions：判断自体がない
--dangerously-skip-permissions は文字通りパーミッションシステムを完全にスキップする。
分類器は動いていない。承認・拒否の判断プロセス自体が存在しない。全てのアクションが無条件で実行される。
このフラグの公式な用途は「Docker コンテナの中」か「隔離された CI 環境」だ。コンテナ内なら、最悪の事態が起きてもホストシステムへの影響を封じ込められるという前提がある。
比較表
| 項目 | Auto Mode | —dangerously-skip-permissions |
|---|---|---|
| 分類器 | 動いている（2段階） | 動いていない |
| 判断プロセス | あり | なし |
| ブロック機能 | あり | なし |
| 想定環境 | 通常の開発環境 | Docker/CI の隔離環境 |
| 起動方法 | Shift+Tab / --permission-mode auto | --dangerously-skip-permissions フラグ |
| カスタマイズ | 可能（JSON設定） | 不可（全スキップのみ） |
「危ないから使わない」ではなく「何が違うかを理解して使う」が正しいスタンスだ。
Auto Mode は分類器という安全網がある。--dangerously-skip-permissions は安全網が存在しない。それが本質的な違いだ。
Auto Mode のカスタマイズ設定（競合記事にない差別化）
Auto Mode には詳細な設定オプションがある。デフォルトの挙動を上書きして、プロジェクトや用途に合わせた判断ルールを定義できる。
設定ファイルの場所と注意点
Auto Mode の設定は ~/.claude/settings.json（ユーザーレベル）にのみ書く。
プロジェクトレベルの .claude/settings.json や .claude/settings.local.json に書いても、Auto Mode に関しては無視される。これは重要な制約だ。「設定を書いたのに効かない」というハマりポイントになりやすい。
設計の意図としては「Auto Mode はユーザーが自分の責任で設定するもの」だ。プロジェクト側からAuto Modeの挙動を制御できてしまうと、悪意あるプロジェクトが意図的に危険な設定を注入できる。ユーザーレベル限定にすることで、この攻撃ベクターを塞いでいる。
基本的な設定構造
{
"autoApprove": [
"Read(**)"
],
"autoReject": [
"Bash(curl *)",
"Bash(wget *)"
]
}この書き方で「ファイル読み取りは全部自動承認、外部通信は全部自動拒否」という設定になる。
4つのルール種別
Auto Mode の設定には4種類のルールがある。
allow
分類器を通さずに即承認するルールだ。
{
"autoApprove": [
"Read(**)",
"Bash(git status)",
"Bash(git log *)",
"Bash(git diff *)",
"Bash(ls *)",
"Bash(cat *)",
"Bash(echo *)"
]
}分類器の計算コストを省けるので、頻繁に使う安全なコマンドはここに入れておくと効率的だ。
soft_deny
分類器が「安全」と判断しても、このルールにマッチする場合は人間に確認を求める。
{
"autoReject": [],
"softDeny": [
"Bash(npm publish *)",
"Bash(git push --force *)",
"Bash(docker push *)"
]
}「基本はAuto Modeで任せるが、本番環境への影響がある操作だけは必ず確認したい」というユースケースに向いている。
hard_deny
分類器の判断に関わらず、無条件でブロックする。
{
"hardDeny": [
"Bash(rm -rf /)",
"Bash(sudo rm *)",
"Bash(chmod 777 *)",
"WebFetch(http://*)"
]
}「これだけは絶対にやらせない」というルールをここに書く。分類器の17%見落とし率を補完するために有効な設定だ。
$defaults
上記のどのルールにもマッチしなかったアクションに対する挙動を定義する。
{
"defaults": "auto"
}"auto" を指定すると分類器に委ねる（デフォルト）。"allow" にするとマッチしなかったものを全承認、"deny" にすると全拒否になる。
実用的な設定例
パターン1：リサーチ・分析用途（外部通信はブロック）
{
"autoApprove": [
"Read(**)",
"Bash(git *)",
"Bash(ls *)",
"Bash(find * -name *)",
"Bash(grep *)",
"Bash(cat *)",
"Bash(head *)",
"Bash(tail *)",
"Bash(wc *)",
"Bash(sort *)",
"Bash(uniq *)"
],
"hardDeny": [
"Bash(curl *)",
"Bash(wget *)",
"Bash(npm *)",
"Bash(pip *)",
"Bash(brew *)",
"Bash(rm *)",
"Bash(mv /*)",
"WebFetch(*)"
],
"defaults": "auto"
}ファイル読み取りと Git 操作を全自動承認にして、外部通信・パッケージインストール・削除系は全ブロックする。コードベース分析やドキュメント生成のような「読み取り主体のタスク」に向いている構成だ。
パターン2：テスト自動化用途（書き込みあり）
{
"autoApprove": [
"Read(**)",
"Write(**/*.test.*)",
"Write(**/*.spec.*)",
"Bash(npm test *)",
"Bash(npm run test *)",
"Bash(pytest *)",
"Bash(git status)",
"Bash(git diff *)"
],
"softDeny": [
"Write(**/*.json)",
"Write(**/package.json)",
"Bash(npm install *)",
"Bash(git commit *)",
"Bash(git push *)"
],
"hardDeny": [
"Bash(curl *)",
"Bash(rm -rf *)"
],
"defaults": "auto"
}テストファイルへの書き込みとテスト実行は全自動承認。設定ファイル変更やパッケージ操作は確認要求。外部通信と再帰削除は全ブロック。TDD ワークフローの自動化に向いた構成だ。
パターン3：最小権限（慎重運用）
{
"autoApprove": [
"Read(**)"
],
"hardDeny": [
"Bash(rm *)",
"Bash(mv /*)",
"Bash(sudo *)",
"Bash(curl *)",
"Bash(wget *)",
"Bash(ssh *)",
"Bash(scp *)"
],
"defaults": "auto"
}読み取りだけを全自動承認にして、危険な操作は明示的にブロックし、残りは分類器に委ねる。Auto Mode を初めて使う場合の出発点として適切な構成だ。
Enterprise/チーム向け：disableBypassPermissionsMode で封鎖する
チームや組織でClaude Codeを使う場合、個人がAuto Modeや--dangerously-skip-permissionsを自由に使えてしまうと、セキュリティポリシーが形骸化する。
この問題に対応するのが disableBypassPermissionsMode 設定だ。
設定方法
組織の Managed 設定（最高優先度のスコープ）に以下を追加する。
{
"disableBypassPermissionsMode": "disable"
}この設定が有効になると、そのマシンでは --dangerously-skip-permissions フラグが機能しなくなる。Auto Mode も含めて「自動承認モード」が封鎖される。
誰がこの設定を使うべきか
disableBypassPermissionsMode を使うべき場面はいくつかある。
一つ目は、開発環境のセキュリティポリシーを統一したいCTO・セキュリティ担当者だ。個人の設定によって穴が生まれることを防げる。
二つ目は、クライアントのコードベースにアクセスする受託開発チームだ。「Auto Mode は使わない」という契約上の約束を技術的に強制できる。
三つ目は、コンプライアンス要件がある環境だ。金融・医療・法律系のプロジェクトでは、AIが自動でファイルを読み書きすることが規制上問題になるケースがある。
Managed 設定の全体像
Managed 設定（/Library/Application Support/ClaudeCode/managed_settings.json など）は最高優先度で適用される。
{
"disableBypassPermissionsMode": "disable",
"permissions": {
"deny": [
"Bash(curl https://competitor.com/*)",
"Bash(ssh *)",
"WebFetch(https://github.com/competitor/*)"
]
},
"env": {
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
}
}組織レベルで「禁止する操作」を一括で定義できる。個人の ~/.claude/settings.json より必ず優先されるため、設定の抜け穴を防げる。
Auto Mode が向いているユースケースとリスク管理
Auto Mode を使う判断は「何をやらせるか」で決まる。
向いている作業
ファイル読み取り主体のリサーチ
「このリポジトリ全体を読んでアーキテクチャを説明して」のような指示は Auto Mode と相性がいい。読み取り操作は分類器が高確率で承認するし、仮に何かを見落としても「読む」だけなら直接的な被害が生まれにくい。
テスト自動化
TDD のサイクル（テスト書く→実装する→テスト通す）を Auto Mode で自動化する場合、テストファイルへの書き込みとテスト実行は繰り返し発生する。これを毎回確認していたら効率が出ない。テストファイルのパスを autoApprove に入れておけば問題なく回せる。
ドキュメント生成
コードから README やドキュメントを生成するタスクも Auto Mode に向いている。ソースコードの読み取りが大量に発生するが、生成物はドキュメントファイルへの書き込みだけだ。生成先ディレクトリを限定して autoApprove に入れれば安全に使える。
ログ分析・エラー調査
「このログファイルを分析してエラーの原因を特定して」というタスクは読み取りがほぼ全てだ。Auto Mode との相性は高い。
向いていない作業
本番データベースへのアクセス
本番環境への接続情報がある状態でAuto Modeを使うのは慎重にすべきだ。分類器が17%見落とすという事実と、「データが消えたら取り返せない」という事実を天秤にかけると、ここはデフォルトの毎回確認が正解だ。
外部API呼び出し（本番エンドポイント）
Stripe の決済APIや SendGrid のメール送信APIを呼ぶタスクで Auto Mode を使うと、誤って本番操作が実行されるリスクがある。外部APIの呼び出しは hardDeny に入れるか、Auto Mode を使わない判断が適切だ。
インフラ操作（Terraform・AWS CLI）
terraform apply や aws s3 rm を含む作業は Auto Mode の対象にしない方がいい。こういった操作は全て hardDeny か softDeny に入れて、人間が必ず確認するフローにする。
リスクを下げる設定の組み合わせ
Auto Mode を使う際のリスク管理として、以下の組み合わせが現実的だ。
{
"autoApprove": [
"Read(**)"
],
"hardDeny": [
"Bash(rm *)",
"Bash(sudo *)",
"Bash(curl *)",
"Bash(wget *)",
"Bash(ssh *)",
"Bash(terraform *)",
"Bash(aws *)",
"Bash(gcloud *)",
"Bash(kubectl delete *)",
"Bash(kubectl apply *)"
],
"defaults": "auto"
}「読み取りは全承認、インフラ系・外部通信は全ブロック、残りは分類器に委ねる」という構成だ。
17%の見落とし率を意識した設計をするなら「失われたら困るもの（データ・お金・インフラ）への操作は hardDeny で塞ぐ」がシンプルなルールになる。
コスト面での考慮
CPC $26 というキーワード単価が示す通り、Auto Mode に関心を持つユーザーは「実際にどうコストに影響するか」も気にしていると思う。
分類器のトークン消費
Auto Mode が有効な状態では、権限プロンプトが発生するたびに分類器が動く。この分類器もトークンを消費する。
Anthropic が公開している情報によると、ステージ1の高速フィルターは単一トークンの判断なので消費量はごく少ない。ステージ2の思考チェーン評価はより多くのトークンを消費するが、ステージ1でフラグが立った場合のみ動く。
実際の影響は「どれだけ権限プロンプトが発生するタスクを実行するか」に依存する。ファイル読み取り主体のタスクで autoApprove を適切に設定していれば、分類器がほとんど動かない状態にできる。
Max プランとの相性
Claude Code Max プランは料金が定額だ。トークン消費量に関わらず月額固定なので、分類器のオーバーヘッドを気にする必要がない。
Auto Mode を積極的に使うなら Max プランとの組み合わせが一番合理的だ。API従量課金の場合は分類器のコストも発生するため、コスト試算に含める必要がある。
FAQ
Q: Auto Mode と Plan Mode の違いは？
Plan Mode（--plan フラグ）は、実行前に「何をするか」の計画を提示して人間に確認を求めるモードだ。Auto Mode は「個々の操作ごとに自動判断する」モード。
どちらを使うべきかは作業の性質による。「全体方針を確認してから進めたい大規模変更」は Plan Mode、「細かい操作を止めずに流したい繰り返し作業」は Auto Mode という使い分けになる。
Q: Auto Mode でファイルが壊れたらどうなる？
分類器は「危険かどうか」を判断するが、「意図通りの変更かどうか」は判断しない。
誤った書き込みが発生した場合、git で管理しているファイルなら git checkout や git reset で戻せる。Auto Mode を使う前提として、変更対象のファイルは必ず Git 管理下に置いておくことを推奨する。
Q: チームで統一設定を配布できる？
できる。Managed スコープ（/Library/Application Support/ClaudeCode/managed_settings.json など）を MDM（Mobile Device Management）ツールや Ansible 等で配布すれば、チーム全員に同じ制約を適用できる。
個人の ~/.claude/settings.json より必ず優先されるため、「管理者が設定した制約は個人では上書きできない」という状態を作れる。
Q: 17%の見落とし率は実際に問題になるレベル？
「危険なアクションのうち17%が見落とされる」という数値をどう評価するかは用途による。
たとえば100回の操作のうち17回が危険なアクションで、その17回全てを見落とすわけではない。実際のタスクでは「危険なアクション」自体の発生頻度は低い。大半の操作（ファイル読み取り・Git 操作・テスト実行）は安全と分類され、適切に承認される。
ただし、本番データベースやインフラ操作が絡む場面では「17%見落とす可能性がある」という事実は無視できない。そういった操作は hardDeny でそもそも分類器に委ねない設計にすることを推奨する。
Q: Windows でも Auto Mode は使える？
使える。Claude Code は Windows（WSL2 環境）でも動作する。Auto Mode の機能は OS に依存していない。
ただし、hardDeny に書く Bash コマンドのパターンは OS 環境によって変わる。Windows 環境では PowerShell コマンドの扱いに注意が必要だ。設定のテストはローカル環境で必ず行う。
まとめ
Auto Mode の要点を整理する。
Auto Mode は「デフォルトの毎回確認」と「全スキップ（—dangerously-skip-permissions）」の中間に位置する、2段階分類器ベースの自律判断モードだ。
分類器の仕組みとして重要なのは2点だ。エージェント自身の出力を参照しないことで自己正当化を防いでいること、そして公式が17%の見落とし率を認めていること。この数値を前提に、hardDeny でリスクを塞ぐ設計が必要だ。
--dangerously-skip-permissions との違いは「判断プロセスの有無」だ。Auto Mode は分類器が動いている。--dangerously-skip-permissions は判断自体がない。混同してはいけない。
カスタマイズ設定は ~/.claude/settings.json に書く。autoApprove・hardDeny・softDeny・defaults を組み合わせて、用途に合わせた設定を作る。
Enterprise/チーム環境では disableBypassPermissionsMode: "disable" で組織全体の自動承認モードを封鎖できる。
仕組みを理解して適切に設定すれば、Auto Mode は「AIに任せつつ、外せない安全網は自分で張る」という運用ができる。
