🧭 本記事は Claude Code実務運用シリーズ の STEP 1「安全に使う」です。
auto modeを有効化する前に、STEP 1-1のdenyリストが今も必要かを公式リストと突き合わせます。
シリーズ全体の地図と読む順は 親記事 にまとめています。
Claude Code の auto mode(分類器つき権限スキップ)を有効化する前に、既存の安全設定をどう更新すべきかを整理した記事です。公式の「デフォルトでブロック/許可されるもの」リストを、本シリーズ STEP 1-1 の deny リストと STEP 3-1 の CLAUDE.md 安全ルールに1項目ずつ突き合わせました。結論は「消してよい deny は1つもない」。実測環境は Claude Code v2.1.198(2026-07-05 時点)です。
はじめに
Claude Code に auto mode という permission mode があります。日常的な承認プロンプトなしで実行させつつ、別の分類器(classifier)モデルが個々のアクションを実行前に審査する——「手動レビュー(手動承認)」と「ガードレールなし」の中間に位置づけられた仕組みです。
- Making Claude Code more secure (auto mode) - Anthropic Engineering(2026-03-25 公開)
- Choose a permission mode - Claude Code Docs
本記事は、シリーズの既存資産(deny 22エントリ+CLAUDE.md 3ルール)を公式リストと突き合わせて更新する記事です。
結論を先に言うと、消してよい deny は1つもありませんでした。そして .env の読み取りは、auto mode がデフォルトで「許可」する側に明記されています。
このシリーズでは、これまでに2つの安全資産を配ってきました。auto mode を有効化する日、この既存の安全設定はどうなるのか。公式の「デフォルトでブロックされるもの/許可されるもの」リストと1項目ずつ突き合わせて、次の3つに答えます。
- auto mode がデフォルトで止めてくれるから、もう不要になる deny はあるか
- 逆に、auto mode がデフォルトで止めないのに、deny が塞いでいる穴はどこか
- CLAUDE.md に書いた「勝手な Git 操作禁止」は、auto mode 時代も意味があるか
この記事で分かること
- auto mode が「全許可スキップ」とどう違うのか(一次情報の逐語引用ベース)
- デフォルトでブロックされるもの・されないものの全リスト(バージョン注記つき)
-
claude auto-mode defaultsの実測(environment/allow/soft_deny/hard_denyの4分類) - STEP 1-1 の deny リスト(22エントリ)との突き合わせ結果
- STEP 3-1 の CLAUDE.md ルールと「会話中の境界」の役割分担
- コピペできる「auto mode 有効化前チェックリスト」
前提
実測環境
本記事のコマンド実測は、以下の環境で行いました(2026-07-05 時点)。
$ date
Sun Jul 5 00:08:51 JST 2026
$ claude --version
2.1.198 (Claude Code)
OS は macOS 26.5.1(arm64)です。auto mode 自体の有効化は行わず、read-only の確認コマンドと一次ドキュメントに基づいています(未検証事項は記事末尾の注意書きにまとめます)。
auto mode の利用条件(一次情報)
permission-modes ドキュメントによると、auto mode は以下のすべてを満たすアカウントでのみ利用できます(和訳は筆者)。
| 条件 | 内容 |
|---|---|
| バージョン | Claude Code v2.1.83 以降 |
| プラン | 全プラン("Plan: All plans.") |
| Owner | Team / Enterprise では、Owner が管理設定で有効化しない限り利用不可。管理者は managed settings の permissions.disableAutoMode を "disable" にしてロックオフも可能 |
| モデル | Anthropic API では Claude Opus 4.6 以降または Sonnet 4.6 以降。Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry・サインイン済み Claude apps ゲートウェイでは Claude Sonnet 5 / Opus 4.7 / Opus 4.8 のみ。Sonnet 4.5、Opus 4.5、Haiku、claude-3 系などの旧モデルはどのプロバイダでも非対応 |
| プロバイダ | Anthropic API では既定で利用可能。Bedrock / Agent Platform / Foundry / Claude apps ゲートウェイでは CLAUDE_CODE_ENABLE_AUTO_MODE を設定するまでオフ |
Web 上には「auto mode は Pro プランでは使えない(Max / Team / Enterprise / API 限定)」という二次情報がありますが、一次情報である permission-modes ドキュメントの記述は "Plan: All plans." です。本記事は一次情報を採用します。なお changelog の v2.1.111 には "Auto mode is now available for Max subscribers when using Opus 4.7" というエントリがあり、段階的ロールアウト期の情報が二次情報として残っている可能性はあります(これは推測です)。実際のブロッカーはプラン名ではなく、上表の Owner 有効化・モデル・プロバイダの組み合わせです。
また、auto mode はリサーチプレビューです。ドキュメントには次の趣旨が明記されています(和訳は筆者)。
auto mode はリサーチプレビューである。権限プロンプトを減らすが、安全性を保証するものではない。全体の方向性を信頼できるタスクに使うべきで、機微な操作に対するレビューの代替とすべきではない。
バージョン差の全体像
auto mode の保護ルールは v2.1.83〜v2.1.200 の間で継続的に拡張されており、手元のバージョンによって有効な安全機能が違います。実測環境 v2.1.198 を基準にすると次のとおりです。
| ドキュメント/changelog が言及するバージョン | 主な内容 | v2.1.198 で有効か |
|---|---|---|
| v2.1.83 | auto mode の必要バージョン(初出) | 満たす |
| v2.1.111 | Max+Opus 4.7 で利用可能に。--enable-auto-mode 不要に |
満たす |
| v2.1.136 |
hard_deny 追加(出典: changelog) |
満たす |
| v2.1.142 | プロジェクト設定からの auto 指定を無視(出典: permission-modes ドキュメント) |
満たす |
| v2.1.158 | Bedrock / Vertex / Foundry 対応(CLAUDE_CODE_ENABLE_AUTO_MODE=1) |
満たす |
| v2.1.178 | サブエージェント起動前の分類器チェック | 満たす |
| v2.1.183 | 破壊的 Git 操作・IaC destroy のブロック追加(出典: changelog) | 満たす |
| v2.1.193 |
autoMode.classifyAllShell 設定 |
満たす |
| v2.1.195 | PR 自己承認・CI 無効化等のブロックルール大量追加 | 満たす |
| v2.1.198 | 機密データ位置ルールの拡張(そのエントリが除外する宛先へのデータ送信もブロック)・/tmp ワイルドカード削除等の追加 |
満たす(実測環境そのもの) |
| v2.1.199 | MCP requiresUserInteraction 等 |
満たさない(本環境では未確認) |
| v2.1.200 | セキュリティテスト無効化の検知、PR/issue/コミットメッセージへのスコープ適用等 | 満たさない(本環境では未確認) |
この記事の各機能紹介にも、個別にバージョン条件を添えます。読者の皆さんも、まず claude --version と照合してから読み進めてください。
全体構成
auto mode の安全設計は、一次情報によると「Claude が読むものへの防御」と「Claude が行うものへの防御」の2層です。行うもの側の流れを図にするとこうなります。
そして本記事の主題は、この分類器のデフォルト判定基準(ブロック/許可リスト)と、手元の settings.json の deny・CLAUDE.md ルールとの関係です。
| 突き合わせるもの | 出典 |
|---|---|
| auto mode がデフォルトでブロックする約36項目 | permission-modes ドキュメント "What the classifier blocks by default" 節 |
| auto mode がデフォルトで許可する5項目 | 同 "Allowed by default" 節 |
| 危険コマンド deny 10 エントリ+機密ファイル Read deny 12 エントリ | STEP 1-1 |
| 安全運用ルール3つ(CLAUDE.md) | STEP 3-1 |
1. auto mode は「全許可」ではなく「審査つきの権限スキップ」
6つの permission mode の中での位置づけ
permission-modes ドキュメントに載っている6モードを整理します(和訳は筆者)。
| モード | できること | 想定用途 |
|---|---|---|
| default | 読み取りのみ(CLI / IDE 拡張では「Manual」と表示) | 導入初期・機微な作業 |
| acceptEdits | 読み取り+ファイル編集+一般的なファイルシステムコマンド(mkdir, touch, mv, cp 等) | レビュー前提のコード反復 |
| plan | 読み取りのみ | 変更前のコードベース調査 |
| auto | すべて(バックグラウンド安全チェックつき) | 長時間タスク・プロンプト疲れの軽減 |
| dontAsk | 事前承認済みツールのみ | ロックダウンされた CI・スクリプト |
| bypassPermissions | すべて | 隔離されたコンテナ・VM 専用 |
bypassPermissions が「すべて(チェックなし)」なのに対し、auto は「すべて(分類器の事前審査つき)」です。ドキュメントの定義はこうです(和訳は筆者)。
auto mode は、Claude が日常的な権限プロンプトなしで実行できるようにする。別の分類器モデルがアクションの実行前にレビューし、依頼の範囲を超えてエスカレートするもの、認識されていないインフラを対象とするもの、Claude が読んだ悪意あるコンテンツに誘導されたと見えるものをブロックする。明示的な ask ルールは引き続きプロンプトを強制する。
最後の一文が重要です。auto mode は既存の permissions 体系(allow / ask / deny)を置き換えるのではなく、その上に載る追加の層です。deny についても、後述のとおり「確実な保証が欲しければ deny ルールを追加せよ」と auto mode の文脈で公式に案内されています。
2層防御と2段階の分類器
エンジニアリング記事によると、防御は2層です(和訳は筆者)。
- 入力層: Claude が読むコンテンツに対するプロンプトインジェクション検知(server-side)
- 出力層: transcript classifier が各アクションを実行前に判定基準へ照らして評価し、「人間の承認者の代替」として機能する
分類器は2段階で動きます。まず単一トークンの高速フィルタが「ブロックか許可か」を判定し、問題ありと判定された場合のみ chain-of-thought 推論で再評価します。
なお、2026年3月公開のエンジニアリング記事の時点では、この分類器は「Sonnet 4.6 上で動作」と明記されています。継続更新される permission-modes ドキュメント側には分類器のモデル名の明記がないため、「2026年3月時点の設計では Sonnet 4.6」という時点つきの理解が安全です。
止まらなかったときの防波堤: 3回連続 / 累計20回
分類器が危険と判定すると、拒否はツール結果として Claude に返り、「境界を誠実に扱え。安全な代替を探せ。ブロックを回避しようとするな」という指示が添えられます。
そのうえで、セッション内で 3回連続の拒否、または累計20回の拒否が蓄積すると、モデルを停止して人間にエスカレーションします。エスカレーションの実体は次のとおりです。
対話モード
→ auto mode が一時停止し、通常の確認プロンプトモードに戻る
ヘッドレスモード(claude -p)
→ 人間に確認する UI がないため、プロセス自体を終了する
このしきい値(3回 / 20回)は変更できません(permission-modes ドキュメントに "These thresholds are not configurable" と明記。この一文はエンジニアリング記事側にはありません)。
分類器の精度(公式評価値)
エンジニアリング記事には評価値の表があります。どの評価軸の数字かを添えて引用します。
| 段階 | 実トラフィック FPR | 実際の過剰行動 FNR(n=52) | 合成データ流出 FNR(n=1,000) |
|---|---|---|---|
| Stage 1(高速フィルタ)単体 | 8.5% | 6.6% | 1.8% |
| Stage 1→Stage 2(全体パイプライン) | 0.4% | 17% | 5.7% |
「誤ブロック率(FPR)0.4%」は快適さの数字ですが、見逃し率(FNR)は実際の過剰行動サンプルで 17%、合成データ流出で 5.7% です。分類器は確率的な防御であり、ゼロにはならない——これが後半の突き合わせの前提になります。
2. デフォルトでブロックされるもの(バージョン注記つき全リスト)
エンジニアリング記事によると、デフォルトのブロックルールは「20種類超」で、4グループに大別されます(和訳は筆者)。
1. 破壊・流出(Destroy or exfiltrate)
2. セキュリティ態勢の劣化(Degrade security posture)
3. 信頼境界の越境(Cross trust boundaries)
4. レビュー回避・他者への影響(Bypass review or affect others)
具体的な項目は permission-modes ドキュメントの "What the classifier blocks by default" 節が正典です。以下、全項目をバージョン注記つきで転記します(和訳・要約は筆者。原文は英語)。
基本セット(ドキュメント上バージョン注記なし)
-
curl | bashのような、コードのダウンロードと実行 - 機密データの外部エンドポイントへの送信
- 本番デプロイとマイグレーション
- クラウドストレージの大量削除
- IAM またはリポジトリ権限の付与
- 共有インフラの変更
- セッション開始前から存在したファイルの不可逆な破壊
- force push、または main への直接 push
- 未コミット変更を破棄すると分類器が推定する操作(
git reset --hard、git checkout -- .、git restore .、git clean -fd、git stash drop、git stash clear) - このセッションで作られていない HEAD コミットへの
git commit --amend - (v2.1.198 以降)push 済み HEAD コミットへの
git commit --amend(メッセージのみの書き換えはブロックされない) -
terraform destroy/pulumi destroy/cdk destroy/terragrunt destroy、およびリソースを破壊する plan の適用
このうち破壊的 Git コマンド群と IaC destroy 系は、changelog では v2.1.183 のエントリとして記録されています("destructive git commands ... are now blocked when you didn't ask to discard local work" 等)。ドキュメント(注記なし)と changelog(v2.1.183)で粒度が異なるため、v2.1.183 より前のバージョンでは効かない可能性を見込んでおくのが安全です。なお changelog v2.1.183 のエントリが挙げる IaC destroy は terraform / pulumi / cdk の3種で、terragrunt destroy は changelog エントリには含まれず、ドキュメント側のみの記載です。また原文のとおり、ブロック条件には「破棄を依頼していない場合」という意図条件がつきます。
v2.1.195 以降で追加
Claude Code v2.1.195 以降は、さらに多くのカテゴリをデフォルトでブロックします(一部は environment 設定でのチューニング対象を含む)。
- シークレットマネージャへの書き込み、DNS レコードや TLS 証明書の変更
- 人間が誰も承認していないプルリクエストのマージ、Claude 自身のプルリクエストの承認、CI チェックの無効化
-
atlantis applyやボットの/deploy・/mergeのような、それ自体が自動化へのコマンドになるコメントの投稿 - 本番のフィーチャーフラグの切り替え・段階変更・削除
- 保護された IaC スコープへのインフラ変更の適用、クラスタノードの drain・削除
- 指名していないリソースにまで及ぶ、共有計算クラスタへの書き込み
- 全ノードで動作する/クラスタトラフィックに割り込む Kubernetes リソース(DaemonSet、admission webhook 等)の作成
- 機微なリモートターゲットへの対話シェルやポートフォワード
- ローカルサービスを公開インターネットから到達可能にするトンネルやリバースシェルの開設
- 生きた資格情報・トークンをトランスクリプトやファイルへ出力すること
-
environmentで機密データ位置として列挙した場所へのアクセス・そこからのコピー(v2.1.198 以降は、そのエントリが除外する宛先へのデータ送信もブロック) - 社内パッケージレジストリを迂回した公開レジストリからのインストール(v2.1.198 以降は、会話で社内レジストリの存在を伝えた場合にも適用)
-
--insecureのような、安全装置を外すフラグつきコマンドの実行 - 人間の承認もサンドボックスもない自律エージェントループの起動(
--dangerously-skip-permissionsや--no-sandboxで開始されるもの等。v2.1.198 以降はサードパーティ製エージェント・評価ハーネスの分離/承認なし実行も対象) - ページ内容・Cookie・資格情報をオリジン外へ送りうる Claude in Chrome のブラウザ操作
「PR の自己承認・CI 無効化・人間未承認 PR のマージがデフォルトでブロックされる」という話題はこのグループです。v2.1.195 以降という前提条件つきであり、また hard_deny(後述)とは別の「デフォルトのブロックルール」である点に注意してください。
v2.1.198 以降で追加
-
/tmp・$TMPDIR等の共有スクラッチ/キャッシュディレクトリでの、名前指定ではなくワイルドカード・glob・経過時間フィルタによる削除 - 他者や共有システムへ送信・アップロード・公開・書き込みする内容に、その宛先に対して許可していない機密詳細を含めること(PR・issue・コミットメッセージへのスコープ適用は v2.1.200 以降)
- Claude Code 自身の tmux ペインへキーストロークを送り、自分のインターフェースを自分で操作すること
v2.1.200 以降で追加(実測環境 v2.1.198 では未確認)
- 認証・アクセス制御・入力検証・サンドボックスなどのセキュリティ挙動を守るテストやアサーションのコメントアウト・削除・強制パス
- セッション内で Claude が作っていないステートフルリソースの削除(より具体的な削除ルールが適用されず、そのリソースを指名していない場合)
- API ベース URL・プロキシ・webhook 受信先・レジストリミラーを、タスクに合わない第三者ホストへ付け替えること(
.env.exampleのような例示ファイル内も含む) -
git remote set-url/git remote addによる push 先の変更(新しいリモートを指名した場合を除く) - 公開と知られているリポジトリへのシークレットの push、そのリポジトリ自身の作業に属さない機微情報の push
- 別リポジトリ・別組織への PR 作成、
gh repo fork、サードパーティリポジトリへの push(外部ターゲットを指名した場合を除く)
保護パス(Protected paths)の扱い
設定・ツール構成系のパスへの書き込みは、モードごとに扱いが決まっています(和訳は筆者)。
| モード | 保護パスへの書き込み |
|---|---|
| default / acceptEdits / plan | プロンプトで確認 |
| auto | 分類器に回される |
| dontAsk | 拒否 |
| bypassPermissions | 許可 |
保護対象には .git、.config/git、.vscode、.idea、.husky、.cargo、.devcontainer、.yarn、.mvn、.claude(.claude/worktrees を除く)などのディレクトリと、.gitconfig、各種シェル rc(.bashrc、.zshrc 等)、.npmrc、.pre-commit-config.yaml、.mcp.json、.claude.json などのファイルが含まれます。
3. デフォルトで「許可」されるもの(ここが本題)
ブロックリストの長さに安心しそうになりますが、本記事で一番読んでほしいのは逆側です。permission-modes ドキュメントの "Allowed by default" 節には、次の5項目が明記されています(和訳は筆者)。
| デフォルトで許可されるもの | 補足 |
|---|---|
| 作業ディレクトリ内のローカルファイル操作 | |
| ロックファイルやマニフェストに宣言済みの依存関係のインストール | |
.env を読み、その資格情報を対応する API へ送信すること |
分類器はこれを止めない設計 |
| 読み取り専用の HTTP リクエスト | |
| 開始したブランチ、または Claude が作成したブランチへの push | force push・main 直 push とは別扱い |
3つ目をもう一度読んでください。auto mode の分類器は、.env を読んで対応する API に資格情報を送る動作をデフォルトで許可します。これは公式が明記している設計であり、バグでも見落としでもありません(「対応する API へ」という条件つきの、開発を止めないための判断だと読めます)。
つまり、.env を読ませたくないなら、その防御は auto mode の外——つまり従来どおり Read(.env) の deny——で行う必要があります。この一点だけでも、STEP 1-1 の deny リストは auto mode 有効化後も現役です。
4. 実測: claude auto-mode defaults で手元のルールを見る
デフォルトルールは、手元の環境で実際に確認できます。まず claude --help で関連フラグ・サブコマンドの実在を確認しました(実測。出力は抜粋で、--fallback-model 等の無関係な行を省略しています)。
$ claude --help | grep -i "permission\|auto\|dangerously\|bypass\|dontAsk\|accept"
--allow-dangerously-skip-permissions Enable bypassing all permission checks
--dangerously-skip-permissions Bypass all permission checks.
--permission-mode <mode> Permission mode to use for the session
(choices: "acceptEdits", "auto",
"bypassPermissions", "default",
"dontAsk", "plan")
auto-mode Inspect auto mode classifier
--permission-mode の選択肢に "auto" があり、ドキュメントの6モードと一致します。そして auto-mode というサブコマンドが実在します。
$ claude auto-mode --help
Usage: claude auto-mode [options] [command]
Inspect auto mode classifier configuration
Options:
-h, --help Display help for command
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 auto-mode defaults を実行すると、デフォルトルール一式が JSON で出力されます。read-only で外部送信のないコマンドなので、auto mode を有効化する前でも安全に実行できます。
実行して確認できたことは次の3点です(出力は106行・約44KB(最長行は3,074文字)の JSON のため、全文の転記は省略します。手元で実行すればそのまま見られます)。
- ルール体系は
environment/allow/soft_deny/hard_denyの4分類 -
allowには名前付きの例外ルールが、Bash(...)のようなパターンではなく自然文で定義されている。例: "Security Discussion"(セキュリティ関連コードの議論・レビュー自体はブロックしない)、"Transient Retry"(一時的失敗のリトライをバイパス扱いしない)、"Local Operations"(作業ディレクトリ内のローカル操作) - この名前付き例外は、Configure auto mode ページの "Override the block and allow rules" 節の記述と整合する
hard_deny の初出は、changelog の v2.1.136 エントリです(和訳は筆者)。
"Added settings.autoMode.hard_deny for auto mode classifier rules that block unconditionally regardless of user intent or allow exceptions"
(ユーザーの意図や allow 例外に関係なく、無条件でブロックする auto mode 分類器ルールのためのsettings.autoMode.hard_denyを追加)
そして hard_deny / soft_deny / allow(および明示的なユーザー意図)の優先関係の正典は、Configure auto mode ページの "Override the block and allow rules" 節です(2026-07-05 に本文確認。和訳は筆者)。
"hard_deny rules block unconditionally. User intent and allow exceptions don't apply. soft_deny rules block next... allow rules then override matching soft_deny rules as exceptions"
(hard_deny ルールは無条件にブロックする。ユーザーの意図も allow 例外も適用されない。次に soft_deny ルールがブロックする……allow ルールは、一致する soft_deny ルールを例外として上書きする)
つまり通常のデフォルトブロック(soft_deny 側)はユーザーの意図・allow 例外で上書きされうる判定であるのに対し、hard_deny は無条件ブロック、という階層です。
5. 突き合わせ(1): STEP 1-1 の deny リストはどうなるか
いよいよ本題です。STEP 1-1 で配った deny は、危険コマンド10エントリ+機密ファイル Read 12エントリの計22エントリでした。これを auto mode のデフォルトブロック/許可リストに1つずつ当てます。
危険コマンド deny 10 エントリ
| STEP 1-1 の deny | auto mode デフォルトブロックでの対応 | 判定 |
|---|---|---|
Bash(sudo rm*) Bash(sudo /bin/rm*) Bash(rm -rf ~*)
|
「セッション開始前から存在したファイルの不可逆な破壊」(基本セット)が意味的に重なる。ただし分類器は意図・文脈込みの確率的判定 | 残す |
Bash(git push --force*) Bash(git push -f*)
|
「force push、または main への直接 push」(基本セット)と重なる | 残す |
Bash(git reset --hard*) Bash(git clean -f*)
|
破壊的 Git 操作ブロックと重なる。ただし changelog 上は v2.1.183 での追加であり、「破棄を依頼していない場合」という意図条件つき | 残す |
Bash(chmod 777*) Bash(chmod -R 777*)
|
公式ブロックリストに chmod の明示的な記載なし(「セキュリティ態勢の劣化」というカテゴリ名はあるが個別列挙されていない) | 残す(明示的に止めるのは deny だけ) |
Bash(eval*) |
公式ブロックリストに明示的な記載なし | 残す(同上) |
機密ファイル Read deny 12 エントリ
| STEP 1-1 の Read deny | auto mode デフォルトでの扱い | 判定 |
|---|---|---|
Read(.env) Read(.env.*)
|
「.env を読み、資格情報を対応する API へ送る」はデフォルト許可と明記 |
絶対に残す(唯一の機械的ブロック層) |
Read(**/*.pem) Read(**/*.key) Read(**/*.p12) Read(**/*.pfx) Read(**/*.token)
|
読み取り自体を止めるデフォルトルールは見当たらない。「生きた資格情報・トークンをトランスクリプトやファイルへ出力」はブロック対象(v2.1.195以降)だが、これは読んだ後の出力段の防御 | 残す |
Read(~/.aws/credentials) Read(~/.ssh/**) Read(~/.config/gh/hosts.yml) Read(~/.npmrc) Read(~/.netrc)
|
「environment で機密データ位置として列挙した場所へのアクセス」はブロック対象(v2.1.195以降)。実測では、デフォルトの environment に "Sensitive data locations & audiences: any file or store holding personal data, confidential business data, credentials, regulated data..."(抜粋)という広い自然文の定義が実在するが、具体パスの列挙はない |
残す(deny なら列挙済みで即効) |
判定: 消せる deny は1つもない
22エントリすべて「残す」になりました。理由は3つに集約できます。
1. 分類器の判定は意図条件つき
「破棄を依頼していない場合」「指名していない場合」のような条件が原文に
多数ある。依頼の解釈次第で通る余地があるのが設計思想そのもの
2. バージョン依存が強い
v2.1.195 / 2.1.198 / 2.1.200 で守備範囲が変わる。
deny はどのバージョン・どのモードの組み合わせでも同じに効く
3. 確率的である
全体パイプラインでも FNR は実過剰行動 17%(n=52)、合成データ流出 5.7%。
公式自身が「リサーチプレビュー。安全性を保証しない」と明言している
deny は前方一致の機械的パターンマッチで、意図を汲みません。STEP 1-1 で見たとおり、それは不便さでもあります(rm -rf* を丸ごと止めると rm -rf node_modules まで巻き添えになるため、パターン設計に工夫が要る)。しかし auto mode 時代には、「解釈の余地なく必ず止まる最後の層」という長所に変わります。
逆方向: deny では書けなかった領域を auto mode が埋める
突き合わせは逆向きにも意味があります。STEP 1-1 で「deny に入れない」と判断した領域を、auto mode のデフォルトブロックがカバーしています。
| STEP 1-1 で見送った/書けなかったもの | auto mode デフォルトブロック |
|---|---|
curl | bash(パターンでの正確な制御が難しく、Bash(curl *) は正当な用途まで止めるため見送り) |
「コードのダウンロードと実行」として基本セットでブロック。表面の文字列ではなく実際の効果を評価する設計のため、パターンで書けない領域を扱える |
| 機密データの外部送信(deny のパターンでは表現不能) | 基本セットでブロック |
| 本番デプロイ・クラウドストレージ大量削除・IAM 付与(同上) | 基本セットでブロック |
| PR 自己承認・CI 無効化(そもそも Bash パターンの守備範囲外) | v2.1.195 以降でブロック |
つまり関係は「置き換え」ではなく相互補完です。deny が確実に塞げる狭い穴は deny のまま、deny では書けない広い領域を分類器が確率的にカバーする——これが auto mode 有効化後の全体像です。
6. 突き合わせ(2): STEP 3-1 の CLAUDE.md ルールと「会話の境界」
「口頭の境界」は compaction で消える
permission-modes ドキュメントには、deny 設計に直結する重要な記述があります(和訳は筆者)。
分類器は、会話中で述べた境界をブロック信号として扱う。「push しないで」「デプロイ前にレビューさせて」と伝えると、デフォルトルールでは許可される場合でも該当アクションをブロックする。境界は、後のメッセージで解除するまで有効であり続ける。(中略)境界はルールとして保存されない。 分類器はチェックのたびにトランスクリプトから再読み込みするため、コンテキスト圧縮でその発言が削除されると境界も失われる可能性がある。確実な保証が欲しい場合は、代わりに deny ルールを追加すること。
これは便利な機能(会話で言うだけでデフォルト許可を上書きできる)であると同時に、明確な警告です。恒久的に守らせたい禁止事項を「会話で毎回言う」運用にしてはいけない。compaction で消えるからです。
4つの層の役割分担
STEP 3-1 では、CLAUDE.md に足す安全運用ルールを3つ配りました。
1. 読んでいないコードについて推測しない
2. 検証を実行できない場合は、理由と手動確認手順を提示する
3. 明示的に依頼されていない限り、commit / push / reset / rebase /
force-push / ファイル削除をしない
auto mode の分類器と突き合わせると、こうなります。
| STEP 3-1 のルール | auto mode 分類器との関係 | 判定 |
|---|---|---|
| 1. 未読コードの推測禁止 | 分類器が審査するのは実行前のアクションであり、回答内容の正確性は対象外 | そのまま残す |
| 2. 検証不能時の申告 | 同上 | そのまま残す |
| 3. 勝手な Git 操作禁止 | force push・main 直 push・破壊的 Git はデフォルトブロックと重なる。一方「開始したブランチへの push」はデフォルト許可なので、勝手 push はこのルールがないと止まらない | そのまま残す |
整理すると、安全装置は4つの層に分かれます。
| 層 | 実体 | 強制のされ方 | 揮発性 |
|---|---|---|---|
settings.json の deny |
機械的パターンマッチ | 一致すれば常にブロック(auto mode でも有効。一次情報が deny を「確実な保証」の手段として案内) | ファイルなので消えない |
| CLAUDE.md の行動原則 | モデルへの指示 | モデルの遵守に依存 | ファイルなので消えない |
| 会話中の境界(「push しないで」) | 分類器がトランスクリプトから読む | デフォルト許可でも該当アクションをブロック | compaction で消えうる |
| auto mode デフォルトブロック | 分類器の判定基準 | 意図・文脈込みの確率的判定 | バージョンで変わる |
CLAUDE.md に書いた禁止ルールを、分類器が「会話中の境界」と同様のブロック信号として扱うかどうかは、一次情報に明記がなく未確認です。本記事では「CLAUDE.md はモデルへの指示、確実に効かせたい操作は deny」という保守的な役割分担を採ります。
運用の指針はシンプルです。そのセッション限りの禁止は会話で言う。恒久的な禁止は deny に書く。行動の質(推測しない・検証を申告する)は CLAUDE.md に書く。 auto mode は、この3つのどれも置き換えません。
7. auto mode 有効化前チェックリスト(コピペ)
以上を、有効化する日にそのまま使えるチェックリストに落とします。
auto mode 有効化前チェックリスト(2026-07-05 時点の一次情報+v2.1.198 実測に基づく)
□ 1. claude --version が 2.1.83 以上か(auto mode の必要条件)
さらに 2.1.195 / 2.1.198 / 2.1.200 のどこまで満たすかで
デフォルトブロックの守備範囲が変わる(本文のバージョン表参照)
□ 2. claude auto-mode defaults を実行し、手元のバージョンの
environment / allow / soft_deny / hard_deny を自分の目で確認した
(read-only・外部送信なし。有効化前でも実行できる)
□ 3. 既定にする場合、defaultMode: "auto" は ~/.claude/settings.json
(ユーザー設定)に書く。プロジェクトの .claude/settings.json や
.claude/settings.local.json に書いても v2.1.142 以降は無視される
□ 4. Team / Enterprise の場合、Owner が管理設定で有効化済みか
□ 5. Bedrock / Agent Platform / Foundry / Claude apps ゲートウェイ経由なら、
CLAUDE_CODE_ENABLE_AUTO_MODE を設定したか+対応モデル
(Sonnet 5 / Opus 4.7 / Opus 4.8)か
□ 6. STEP 1-1 の deny(危険コマンド10+機密ファイル Read 12)が
入ったままか。auto mode を理由に消してよいものは1つもない。
特に Read(.env) 系は、デフォルト許可領域を塞ぐ唯一の機械的ガード
□ 7. 会話で毎回言っている禁止事項(「push しないで」等)があれば、
deny ルールに昇格したか(会話の境界は compaction で消える)
□ 8. CLAUDE.md の安全ルール(STEP 3-1 の3つ)はそのまま残したか
確認コマンドは2つだけです(いずれも本環境で実行済み)。
# 1. バージョン確認
claude --version
# 2. デフォルトルールの確認(read-only)
claude auto-mode defaults
有効化の入口は3つあります。
1. セッション単位: claude --permission-mode auto
(フラグと選択肢の実在は --help で確認済み。有効化後の挙動は本記事では未検証)
2. 既定にする: ~/.claude/settings.json に
{"permissions": {"defaultMode": "auto"}}
3. セッション中: Shift+Tab でモードをサイクル
(ドキュメントによると、アカウントが要件を満たす場合のみ auto が表示され、
確認プロンプトなしで切り替わる。本環境では表示条件を含め未検証)
2 について補足すると、プロジェクト設定からの auto 指定が無視されるのは意図された設計です。ドキュメントには「リポジトリが自分自身に auto mode を付与することはできない」(v2.1.142 以降)と明記されています。クローンしてきたリポジトリの .claude/settings.json が勝手に権限スキップを有効化する、という攻撃経路を塞ぐ仕様です。
ハマりどころ・注意点
1. defaultMode: "auto" を書いたのに default で起動する
設定の置き場所がプロジェクト側(.claude/settings.json / .claude/settings.local.json)になっているのが典型です。v2.1.142 以降はエラーなく無視されるので、~/.claude/settings.json に移してください(ドキュメントに同旨のトラブルシューティングが明記されています)。
2. 記事・ブログと手元で挙動が違う
auto mode のブロックルールはバージョンごとに増えています。本記事の v2.1.200 の項目(セキュリティテスト無効化の検知など)は、実測環境 v2.1.198 では未確認です。読んだ記事の日付と自分の claude --version を必ず突き合わせてください。
3. 「Pro プランでは使えない」という情報
前提の節に書いたとおり、一次情報の記述は "Plan: All plans." です。実際の利用可否はプラン名ではなく、Owner 有効化(Team/Enterprise)・モデル要件・プロバイダ要件で決まります。
4. 分類器のモデル名を固定的に語らない
「Sonnet 4.6 が判定する」は 2026年3月のエンジニアリング記事時点の実装です。また、auto mode の利用条件に出てくるモデル(Opus 4.6 以降等)と分類器のモデルが同一かは、一次情報間で明示的な接続がなく未確認です。
5. サブエージェントは permissionMode で抜けられない
分類器はサブエージェントの作業を3点(起動前のタスク記述評価は v2.1.178 以降/実行中の各アクション/完了時の全履歴レビュー)でチェックし、サブエージェントの frontmatter にある permissionMode は無視されます。サブエージェント側だけ緩める・締めるという設計はできません。サブエージェント運用をしている方(本シリーズの STEP 5〜6 相当)は前提に入れておいてください。
6. しきい値は変えられない
3回連続 / 累計20回のエスカレーションしきい値は変更不可です("These thresholds are not configurable")。ヘッドレス(claude -p)ではプロセス終了になるため、CI・自動化パイプラインに auto mode を組み込む場合は中断前提の設計が必要です。
本記事の未検証事項(2026-07-05 時点)
- auto mode を実際に有効化しての挙動再現は行っていません(read-only の確認コマンドと一次ドキュメントに基づく記事です)
- transcript classifier のモデルと、auto mode 利用条件の対象モデルが同一かは未確認です
- v2.1.83 の changelog に auto mode 追加の明示エントリが見当たらない件(記述漏れか別粒度か)は未確認です
-
claude auto-mode config/claude auto-mode critiqueは未実行です(defaultsのみ実行) - この環境で Shift+Tab サイクルに auto が実際に表示されるか(プラン・モデル要件の充足を含む)は未確認です
まとめ
auto mode は「全許可スキップ」ではなく、分類器が人間の承認者を代替する「審査つきの権限スキップ」でした。そして既存の安全設定との関係は、置き換えではなく積み重ねです。
- STEP 1-1 の deny 22 エントリ: 全部残す。消してよいものはゼロ
(特に Read(.env) 系は、「.env を読んで対応 API へ送る」という
デフォルト許可領域を塞ぐ唯一の機械的ガード)
- STEP 3-1 の CLAUDE.md ルール3つ: 全部残す
(分類器はアクションの危険性を見る。回答の質は見ない)
- 新しい習慣: 会話で言った禁止は compaction で消える。
恒久的な禁止は deny に昇格する
- auto mode が新たに埋めるもの: curl | bash、機密データ外部送信、
本番デプロイ、PR 自己承認(v2.1.195+)など、deny のパターンでは
書けなかった広い領域を、確率的にカバーする
有効化する日は、この記事のチェックリスト8項目と claude auto-mode defaults の実行から始めてください。
auto mode を実際に有効化した後の実運用(何がブロックされ、3回連続エスカレーションがどう見えるか)は、検証でき次第、続編として書く予定です。
参考リンク
- Making Claude Code more secure (auto mode) - Anthropic Engineering(2026-03-25 公開)
- Choose a permission mode - Claude Code Docs
- Configure auto mode - Claude Code Docs
- Claude Code changelog
- Configure permissions - Claude Code Docs
このシリーズの歩き方
Claude Code実務運用シリーズ ― 暴走させない、から仕組みにするまで。
- ◀ 前の記事: 【コピペで完了】Claude Codeの最初に入れる安全設定2つ：「危険コマンド」と「機密ファイル」を拒否する
- ▶ 次の記事: 18万スター超のCLAUDE.mdに学ぶ、Claude Codeを暴走させない運用術
- 🔍 あわせて読む: andrej-karpathy-skillsのCLAUDE.mdに足したい、Claude Codeの安全運用ルール3選 ― 本文で突き合わせたCLAUDE.md側の安全ルール
- 🗺 シリーズ全記事の地図(親記事)