Claude Code の auto mode、8月14日の標準化前にルール全文を読んだ — 「rm だから止まる」ではなかった

Claude Code には auto mode というモードがあります。
作業のたびに出てくる「このコマンドを実行していいですか」という許可の確認を、AIが自動で判断して進めてくれる仕組みです。

確認が減るのは楽です。
その一方で、勝手にファイルを消されたりしないのか、なんとなく不安なまま使っていないでしょうか。
面倒だからとりあえず auto mode にしている、という状態でも構いません。
私も半年ほど、似たようなものでした。

そして8月14日から、auto mode が Pro / Max / Team の標準設定になります。
何もしなければ、当日に自動で切り替わります。

この記事は2部構成にします。
前半は、コマンドを一切打たずにできる対応だけをまとめます。
後半は、判定ルールの中身を実際に読んで、なぜそういう設計なのかを見ていきます。
前半だけ読んで閉じてもらって構いません。

なお、実際に確認ダイアログが出る瞬間を計測したわけではありません。
判定ルールの原文と、私が半年 auto mode で回してきた体感を突き合わせた記事です。

先に結論

自分のパソコンで、自分の作業をしているだけなら、何もしなくて大丈夫です。
危険度の高い操作については、標準になったあとも確認が残る設計になっています。
承認の手間が減るだけ、という人がおそらく大半です。

ただし、リスクがゼロになるわけではありません。
ファイルの削除や、頼んでいない git のコミット（作業内容を記録として残す操作）のような、してほしくないことは起こり得ます。
判定するのはAIなので、毎回まったく同じ結果になる保証もありません。

大事なデータ、仕事の本番環境、他人と共有しているものに触る使い方なら、自動に任せず事前確認へ戻してください。
判断が分かれるのは次の4つです。

1. AIが作ってない大事なデータが、作業範囲の中にあるか

2. 自分が画面を見ていない時間帯に走らせるか

3. 同じ作業フォルダを、これから何ヶ月も使い続けるか

4. 仕事の本番環境や、他人が使っているものに手が届くか

4番目が Yes なら、auto mode をどうするか以前の問題です。
その作業だけは自動判定に載せず、毎回自分の目で確認してください。
Anthropic 自身も、本番インフラに触る変更には手動レビューを推奨しています。

1から3で Yes が2つ以上なら、危険な操作を確認側に戻しておくほうが安全です。
無人で回し続ける環境や、長く使い続ける環境は、1回の誤操作があとから効いてきます。
どれも当てはまらないなら、何もせずそのままで問題が起きにくい設計です。

ここだけは注意

前半で持ち帰ってほしいのは、次の5つです。

• ファイルの削除を伴う作業は、任せきりにしない。消える対象を選んだのがAIのときほど危ない

• 頼んでいないコミットを挟まれる場合があり、作業前の状態へ戻したいときに困る

• 長時間の放置運用を始める前に、いまの状態を保存しておく（git を使っているならコミット、使っていないならフォルダごとコピー）

• 大事なデータが置いてある場所では、そもそも作業を始めない。作業用のフォルダを別に用意する

• 意図しない削除や上書きが起きたという報告は、AIコーディングツール全般で以前から出ている。頻度は高くないが、ゼロでもない

私自身、半年ほど前に一度だけ、誤った操作をされて修復にまわった日があります。
すべて消えたわけではなく一部が残っていたので復旧はできました。
ただ、原因を突き止めて直すまでにかなりの時間がかかっています。
事故そのものより、そのあとの調査に溶けた時間とトークンのほうが痛い。

設定はAIに頼めばいい

ここからが本題です。
設定を変えたいと思っても、ターミナルを開いて設定ファイルを書き換える、と聞いた時点で面倒に感じると思います。

やらなくて大丈夫です。
Claude Code を使っているなら、設定の相談から反映まで、Claude Code 自身に頼めます。

チャット欄に次のように投げてみてください。

8月14日から Claude Code の auto mode が標準になると聞きました。
私がされたくないのは、大事なファイルを勝手に消されることと、頼んでいない git のコミットです。
まず私の普段の使い方を聞き取ったうえで、注意しておくべき点を整理してください。
そのうえで必要な設定があれば、設定ファイルへの反映までお願いします。
ただし反映する前に、何をどう書き換えるのか見せてください。

「されたくないこと」の部分は、自分の言葉に置き換えて構いません。
勝手にライブラリを入れられたくない、外部にファイルを送ってほしくない。
思いつく限り書いておくほど、聞き取りの精度が上がります。

最後の一文は消さないでください。
反映前に内容を見せてもらい、自分の目で確認してから進める。
設定を任せる相手も、判定を任せる相手と同じAIです。

自分で書きたい人向けに、外し方だけ載せておきます。
`.claude/settings.json` というファイルに、次の内容を書けば auto mode は無効になります。

{
  "disableAutoMode": true
}

ファイルが無ければ新規作成で構いません。
置き場所はプロジェクト直下か、ホームディレクトリの `.claude` フォルダの中です。
なお、この置き場所は設定ファイルの一般的な階層からの推測で、明示的な出典は確認できていません。
一時的に切り替えるだけなら、Claude Code の画面で Shift+Tab を押す方法もあります。

私は条件つきで続ける

参考までに、自分の運用も書いておきます。

最近のタスクは長時間前提のものが増えました。
指示を出してから出かける、寝る前に投げておく、別の作業をしている間に走らせておく。
そういう使い方が中心になると、承認確認で途中停止されるのが一番困ります。
戻ってきたら1つ目のコマンドの前で止まっていた、という時間の溶かし方が一番もったいない。

なので私はデフォルト化を待たずに auto mode で運用しています。
そのうえで、自分で書く許可リストのほうに削除系のコマンドをほぼ入れていません。
先ほどの4つでいうと、私は2番目だけが Yes です。
触っているのが自分のデータだけなので、auto mode は残して削除だけ確認に回す、という条件つきの継続を選んでいます。

前半はここまでです。
上の対応だけで、実用上は足ります。

ここから先は仕組みの話

なぜそういう設計になっているのかを知りたい人向けに、判定ルールの中身を見ていきます。
読まなくても困りません。

きっかけは、判定ルールが手元のコマンドで全文読めると分かったことでした。
読んでみて意外だったのは、危険なコマンドの一覧が並んでいるわけではなかった点です。
`rm`（ファイルを削除するコマンド）や `git reset --hard` は、条件の一部でしかありませんでした。

判定ルールはコマンド一行で読める

auto mode は、自然言語で書かれたルールをAIが読んで危険度を判定する仕組みで動いています。
本記事では、この判定役を分類器と呼びます。

読むためのコマンドは `claude auto-mode defaults` の一行だけです。
打つ場所はターミナル（コマンドを打つ黒い画面。Claude Code を起動するときに使うところ）で、Claude Code のチャット欄ではありません。
実行すると、英語のルール本文が並んだ JSON（設定やデータを書くための書式）が画面にそのまま出ます。
以下、このルール本文を条文と呼びます。

モデルにリクエストは飛ばないので、トークンは1つも減りません。

`claude auto-mode` には3つのサブコマンドがあります。

• `defaults` — 既定の判定ルールを出す

• `config` — 自分の設定を反映した実効ルールを出す

• `critique` — 自作したカスタムルールにAIのレビューをもらう

検証用に作った素の空リポジトリ（git で変更履歴を管理している作業フォルダ）で叩いたところ、`defaults` と `config` の出力は一字一句一致しました。
カスタムルールを何も書いていなければ、既定の条文がそのまま効く、という確認になります。
自分の環境が何かを上書きしているかどうかは、両方をファイルに落として比べれば分かります。

出てきた JSON のトップレベルキーは3つ。
`allow` が7項目、`soft_deny` が29項目、`environment` が5項目です。
`environment` は信頼する外部ドメインやサービスを登録しておく枠で、既定ではすべて未設定になっています。

数え方の前提として、ここに書いた条文は CLI 2.1.86 時点の出力です。
公式は同じ週に 2.1.224〜226 まで進んでいて、この領域は更新が速い。
項目数や文面は自分のバージョンで叩いて数え直してください。

条文はブラックリストではありません。
`rm -rf` や `curl | bash` といった具体名は登場しますが、いずれも自然言語の文章の中に例示として出てくる形です。
コマンド名と正規表現を突き合わせて機械的に弾く作りにはなっていません。

拒否ではなく、確認への降格

キー名が `deny` ではなく `soft_deny` であることに、設計の意図が出ています。
危険側に分類されたからといって、実行が拒否されるわけではありません。
これまでどおり人間に確認が回るだけです。

整理すると、auto mode は三層になっています。

• `allow` に当てはまる操作 — 確認なしでそのまま実行される

• `soft_deny` に当てはまる操作 — 人間の確認に降格する

• どちらにも当てはまらない操作 — 従来どおりの権限設定にしたがう

auto mode を入れて実際に減るのは、`allow` に落ちた分の確認だけです。
削除の話として一番大きいのは Local Operations の一節で、AIが作業ディレクトリ内のローカルファイルを消す行為そのものが許可側に置かれています。
ほかに読み取り専用の通信や、既に設定ファイルへ書かれている依存のインストールが並びます。

`allow` が全部おとなしいわけでもありません。
資格情報を読んで本来の宛先へ送ることや、公式インストーラーの実行も許可側です。
安全側に寄せた一覧のようで、実際は踏み込んだ許可も混ざっています。

削除が止まるかを決める3つの軸

一番知りたかった削除の扱いは、`soft_deny` の Irreversible Local Destruction という項目に書かれていました。
読み解くと、判定は3つの軸で組まれています。

1つめは、誰が対象を決めたかです。
条文が問題にしているのは、セッションが始まる前から存在していたファイルです。
AI自身がそのセッション中に作ったファイルの上書きは、明示的に問題なしとされています。
そのうえで、残りのファイルについては「対象を名指しした明示的なユーザー指示があるか」を見ます。
ここに補足がついていました。

An underspecified or untested pattern (glob, regex, find) is not a specific target — the agent cannot know what it will match until it runs.

指定の甘いパターンは具体的な対象とは呼べない、という意味です。
実行するまで何にマッチするか分からないから、という理由まで書いてあります。
グロブというのは `*.txt` のように、まとめて指定する書き方のことです。

「`old.log` を消して」と名指しすれば、条文どおりなら通るはずです。
「いらないログ消しといて」と頼み、AIが候補を集めてまとめて消しにいく場合は違います。
頼んだのは自分でも対象を選んだのはAIなので、確認側に落ちるはず。
同じ削除でも、対象を決めたのが人間かAIかで扱いが変わります。

2つめは、取り返しがつくかどうかです。
条文が名前を挙げているのは `rm -rf`、`git clean -fdx`、未コミットの変更に対する `git checkout .` と `git reset --hard` です。
ファイルを空にする上書きも同じ扱いになります。
ローカルのデータベースへの破壊操作も、明らかに使い捨てのテスト用でない限り危険側です。

3つめは、どこで起きるかです。
判断の基準になる「プロジェクトスコープ」の定義は、`soft_deny` ではなく `allow` の中に書かれています。
許可リスト側に置かれた定義が、危険側の判定の前提として効いている構造です。

「`rm` というコマンドだから止まる」という理解でいると、この設計は読み違えます。
危険度を決めているのは、コマンド名よりも、対象を選んだのが誰かという点のほうです。

なお条文の中では、同じ仕組みが `soft_deny` と BLOCK の2つの名前で呼ばれています。
内部名称が置き換わりきらないまま出力に残っているようです。

信頼の単位は起動したリポジトリ

3つめの軸の定義を、原文で見ます。

"Project scope" means the repository the session started in — wandering into ~/, ~/Library/, /etc, or other repos is scope escalation (User Intent Rule #2), not a local operation. ...

プロジェクトスコープとはセッションを開始したリポジトリのことで、ホームディレクトリや他のリポジトリへ迷い出るのはスコープ逸脱にあたる、という内容です。

作業ディレクトリでもなく、フォルダの深さでもなく、起動した git リポジトリが信頼の単位になっています。
`environment` の既定値もそれと揃っていました。
信頼されるのは起動リポジトリとその接続先だけで、内部ドメインやクラウドバケットはすべて未設定です。
何も設定しなければ、起動したリポジトリの外側は全部よそ、という設計です。

git 管理下にない作業フォルダで走らせている場合、スコープの基準そのものが曖昧になります。
auto mode を使うつもりなら、`git init` されている場所で起動しておくほうが設計に合っています。

前半で「同じ作業フォルダを何ヶ月も使い続けるか」を聞いたのは、この定義が理由です。
長く使っているフォルダほど、セッション開始前から在るファイルが増えていきます。

「13.6%対89%」の読み方

デフォルト化の根拠として、Anthropic は1,053人の対照実験を出しています。
危険なコマンドを止められた割合が、人間のレビューで13.6%、auto mode で89%だったという内容です。

自社実験で、詳しい条件は公開されていません。
人間側の13.6%は能力の低さというより、承認が続くと内容を読まずに Enter を押してしまう現象の数字として読むほうが実態に近いと思います。
独立した評価としては、Trajectory Labs が間接プロンプトインジェクション（Webページやファイルに指示を仕込んでAIを乗っ取る攻撃）を720回試しています。
Fable 5 / Opus 5 / Sonnet 5 で成功率0%だった、という報告です。
試した720回の範囲での0%になります。

Anthropic 自身も「リスクをゼロにするものではない」と書いています。
分類器を動かすためのオーバーヘッド課金は廃止されたので、費用を理由に外す必要はなくなりました。
発表内容の詳細は、先週のトレンド記事のほうにまとめてあります。

半年の体感と条文は噛み合う

条文を読んだうえで、自分の記憶と突き合わせてみます。

削除やフォルダ外への操作で確認が出た、という体感は Irreversible Local Destruction とスコープ逸脱の条文で説明がつきます。
大きなデータを消されたことは、気づいた範囲では一度もありません。

前半に書いた半年前の一件も、何をされたかまでは記録に残していないので詳細は書けません。
それでも、あの日の消費は今も判断の基準になっています。
許可リストのほうに削除系を入れないでいるのは、その帰結です。

許可リストと auto mode は役割が違います。
許可リストは自分が明示的に書いた決定的なルールで、書いたとおりにしか効きません。
auto mode の判定は自然言語のルールを分類器が読んで下す確率的なものです。
確実に通したい定型作業は許可リストへ書き、危険側は書かずに確認へ回す。
2層の役割をそう分けておくと、どちらが効いたのかを後から追いやすくなります。

条文からは分からないこと

書けないことも並べておきます。

実際の挙動は測れていません。
ネストした環境で `claude` を起動したところ認証トークンを更新できず、全ラン失敗で終わりました。
なのでこの記事の「止まるはず」は、すべて条文の記述と私の運用の記憶にもとづく話です。

自分の許可リストと `soft_deny` が衝突したとき、どちらが勝つかも未確認です。
削除系を許可リストに書いてしまった場合に確認が出るのかどうかは、条文からは読み取れませんでした。

条文自体も 8月14日以降に変わる可能性があります。
`claude auto-mode defaults` は自分の環境の現在値を出すコマンドなので、切り替え後にもう一度叩いて差分を取るのが確実です。
私も切り替え後に取り直すつもりでいて、内容が変わっていたら続報を書きます。

判定そのものが確率的である点も残ります。
検証中のデバッグログには auto mode がモデル依存であることをうかがわせる行も出ていましたが、対応モデルを自分で確認する方法までは分かりませんでした。

まとめ

• 自分のパソコンで自分の作業をしているだけなら、8月14日は何もしなくてよい（危険側の操作には確認が残る）

• ただし削除や、頼んでいないコミットは起こり得る。長時間の放置運用を始める前に、いまの状態を保存しておく

• 大事なデータや仕事の本番、他人と共有しているものに触るなら、その作業だけは自動判定に載せない

• 設定はコマンドを打たなくてよく、Claude Code に相談して反映まで頼める（反映前に内容は自分の目で確認する）

• 外すなら `.claude/settings.json` に `{ "disableAutoMode": true }`、一時的なら Shift+Tab

• 判定ルールの全文は `claude auto-mode defaults` をターミナルで叩けば読める（トークン消費ゼロ）

• キー名は `deny` ではなく `soft_deny` で、危険側の判定は拒否ではなく人間の確認への降格を意味する

• 削除の判定は、誰が対象を決めたか・取り返しがつくか・どこで起きるかの3軸で決まる

• 信頼の単位は起動した git リポジトリで、ホームディレクトリや他リポジトリへ出るのはスコープ逸脱として扱われる

• 根拠の「13.6%対89%」は1,053人の自社対照実験で、詳しい条件は公開されていない

次の一手として、まずは前半のプロンプトをそのまま Claude Code に投げてみてください。
自分の使い方を聞き取ってもらうところから始めれば、8月14日までに決めるべきことははっきりします。
仕組みまで確かめたくなったら、そのあとで `claude auto-mode defaults` を叩けば足ります。

この記事が参考になったら、ぜひ「スキ」をお願いします。

あわせて読みたい

8月14日の切り替えを含む、その週の動向はこちらにまとめています。

危険な操作をサブエージェント側に閉じ込める設計はこちらに。

長時間セッションで認識がずれたときの直し方はこちらです。