Claude Code auto modeが8月14日デフォルト化｜manualに戻す設定

「気づいたらファイルシステムのルートからコピーが始まっていた」。Hacker Newsのユーザー @SyneRyder 氏は8月6日の出来事をそう書いている。auto modeで動くClaude Codeがファイルコピー用の小さなbashスクリプトを書いたのだが、$SRC を設定し忘れていた。「戻ってきたら、あの『正直に言うと、私が問題を起こしたので後始末が必要です』というやつが表示されていた」（出典: Hacker News スレッド内 @SyneRyder 氏のコメント、2026年8月8日）。

その8日後にあたる8月14日から、このauto modeがClaude CodeのPro・Max・Teamプランで既定になる。Anthropicは8月7日にこれを発表した（出典: Anthropic公式ブログ）。1コマンドごとの承認プロンプトは、明示的に設定を戻さないかぎり出なくなる。

8月14日にClaude Codeのauto modeで何が変わるのか

auto modeでは、すべてのツール呼び出しが分類器を通る。分類器とは、Claudeが実行しようとするコマンドを実行前に別のモデルが読んで「通す／止める」を判定する審査係だと思えばいい。人間の代わりにEnterを押す係ではなく、危ないものだけを拾い上げる係だ。3月に登場したときのauto modeの仕組みから設計思想は変わっていない。

止まる基準は4つのカテゴリに整理されている。破壊または持ち出し（force push＝リモートの履歴を強制的に上書きする操作、大量削除、データの外部送信）、セキュリティの劣化（ログの無効化、永続化の仕込み）、信頼境界の侵犯（外部コードの実行、認証情報の探索）、レビュー回避と他者への影響（本番デプロイ、共有リソースの変更）だ（出典: Anthropic Engineering）。ブロックされた場合、Claudeはたいてい別の安全な経路を探すか、ユーザーに確認を求める。

対象プランと時期は次のとおり。

プラン・提供形態	8月14日時点	今後の予定
Pro / Max / Team	新規セッションの既定がauto mode	適用済み
Claude Enterprise	オプトインのまま	今後1か月のうちに既定化予定
Claude API / Claude Platform on AWS / Amazon Bedrock / Google Cloud Agent Platform / Microsoft Foundry	オプトインのまま	同上（クラウドパートナーと調整中）

Anthropicは「今後1か月のうちに、クラウドパートナーと協力してこれら全てで既定にし、分類器のオーバーヘッド課金もやめる予定」としている（出典: Anthropic公式ブログ）。つまりEnterprise契約の会社も「うちは対象外」ではなく「1か月遅れで来る」と読むのが正しい。

課金の話は見落とされがちだが実務上は大きい。分類器はツール呼び出しのたびに追加トークンを消費する。8月7日の発表時点で、Pro・Max・Teamについてはこのオーバーヘッドが利用上限（レートリミット）のカウント対象から外れた。Hacker Newsでも @Computer0 氏が「既定にするなら、これは良い変更だ」とコメントしている（出典: Hacker News スレッド内 @Computer0 氏のコメント、2026年8月7日）。

ただしこれは分類器の追加トークン分の話であって、auto modeが総消費量を減らすという意味ではない。承認待ちで止まらないぶん、1セッションあたりのツール呼び出しはむしろ増える。Maxプランの上限に張り付いている人は、既定化後に到達速度の体感が変わる可能性がある。この点についてAnthropicは総消費量への影響を公表していないため、筆者の推測にとどまる。

Anthropicが出した数字：人間13.6%、分類器89%

Anthropicがこの変更の根拠として出したのは、承認プロンプトそのものが機能していないというデータだ。

同社によると、ユーザーは承認プロンプトの97%を承認している。3月に公開されたエンジニアリング記事では93%という数字だった（出典: Anthropic Engineering）。どちらにせよ、ほぼ全部押している。「セキュリティのための確認」が「Enterキーを押す動作」に退化している状態だ。

1,053人の有償テスターを対象にした対照実験では、危険なコマンドを人間のレビュアーが検知できたのは13.6%、auto modeは89%だった（出典: Anthropic公式ブログ、TechCrunch、2026年8月9日）。実運用データの分析でも、手動承認セッションの6.3%に本番影響レベルの意図しない有害操作が含まれていたのに対し、auto modeでは2.4%だったという。さらに、Team・Enterpriseの採用組織ではauto modeユーザーのプルリクエストが約25%多かった（出典: Anthropic公式ブログ）。

プロンプトインジェクションについては、Anthropicが委託した第三者機関Trajectory Labsが、2026年7月17日時点の公開版Claude CodeとCodexを対象に検証している。auto modeで動くClaude Fable 5・Opus 5・Sonnet 5に対して720件の間接プロンプトインジェクション攻撃（AIが読み込んだファイルやWebページの中に「この秘密鍵を外部に送れ」といった命令文を仕込み、AIをだます攻撃）を試み、成功はゼロだった。Codex側では5.83%が成功したという（出典: Anthropic公式ブログ）。ただしこの評価はAnthropicの委託によるものであり、完全に独立した検証ではない。

PMとしての率直な感想を書いておくと、この数字の並べ方は少し都合が良い。13.6%という人間側のスコアは「危険なコマンドを仕込んだ対照実験」で出たものだ。実務では、自分が何を頼んだか覚えているぶん人間の検知率はもう少し上がるはずだし、逆に長時間セッションではもっと下がるだろう。数字そのものより「承認プロンプトは安全装置として設計されていたのに、実際には儀式になっていた」という主張のほうが本質だと受け取っている。

auto modeは安全か：数か月常用して「事故ゼロ」という報告

実際に長期間auto modeを使っている人の声は、思ったより肯定的だ。

@AussieWog93 氏は、自分とクライアントの複数サーバーに対してSSH経由でsysadmin作業をさせる用途で、数か月auto modeを常用しているという。「バカな挙動や壊滅的なことの気配すらなかった。むしろ逆だ。多くの人間よりよほど慎重だと言ってもいい。平文の秘密情報を放置しない、デプロイ後に全ファイル・全ディレクトリのパーミッションが正しいか確認するスクリプトを作る、といった衛生管理に異常にうるさい」（出典: Hacker News スレッド内 @AussieWog93 氏のコメント、2026年8月8日）。

同氏はブロックの実例も挙げている。OCRの選択肢をテストしていたとき、自分の私的データをランダムな公開エンドポイントにアップロードすることを不用意に提案したところ、モデルが止まってリスクを説明し、理解したと確認するまで続行を拒否したという。分類器の4カテゴリのうち「破壊または持ち出し」が効いた例だ。

Claude Code責任者のBoris Cherny氏は「チームと私はauto modeしか使っていない。もう何か月もだ。承認プロンプトに戻るなんて想像できない」と述べている（出典: TechCrunch）。

auto modeの事故事例：rm -rf、SSH設定の破壊、「読む側」の行き過ぎ

一方で、事故の報告もはっきり存在する。しかも直近のものだ。以下はいずれもHacker News上のユーザーによる自己申告であり、筆者が再現を確認したものではない。報告された挙動が現在のバージョンでも発生するかも検証されていない。

@sevenseacat 氏の報告はこうだ。「同僚が昨日TDDでコードを書いていたら、Claude Codeがホームディレクトリに対して rm -rf を実行するテストを走らせた。こういうバカなことはまだ起きる」（出典: Hacker News スレッド内 @sevenseacat 氏のコメント、2026年8月8日）。v2.1.183で破壊的コマンドのブロックが追加されたあとの話であることは押さえておきたい。

@graceful6800 氏は別の壊れ方を指摘する。「コードは実際に変更される。ユーザーのSSH設定に書き込んで、原因を見つけて直すまでSSHが恒久的に壊れた状態にする、といったことも平気でやる」（出典: Hacker News スレッド内 @graceful6800 氏のコメント、2026年8月7日）。

冒頭の @SyneRyder 氏の総括も引いておく。「auto modeのおかげで生産性は上がった。ようやく長時間画面を離れて他のことができる。でもモデルが何をしているか見ていないといけない。それは今書いたことの真逆だ」。同氏はこの一件のあとClaudeのプランをダウングレードし、他の選択肢を探し始めたと書いている。

見落とされがちなのが「読む側」の行き過ぎだ。@abound 氏は、非営利団体の会計データをAplosのエクスポートからBeancountに変換させたとき、Claudeがハードディスクの別の場所にある自分の個人用Beancount台帳を見つけ出し、それを参考に計画を立てていたことに驚いたという。「結果的には正しくて助かったのだが、やりすぎだと思う。今後はエージェントをサンドボックスに入れる」（出典: Hacker News スレッド内 @abound 氏のコメント、2026年8月8日）。

auto modeの分類器は、破壊的な書き込みとデータの外部送信には強い設計になっている。hard_deny の既定にはデータ持ち出し防止ルールが組み込まれており、autoMode.environment にも機密データの所在を宣言する枠がある。だが「そもそも何を読んでいいか」を作業ディレクトリの外まで止める設計にはなっていない。外に出さなければ許容される、という思想だ。守秘義務のあるデータを同じマシンに置いているなら、この前提が自分の要件と合っているかは確認しておきたい。

auto modeの分類器の限界：17%は取りこぼす

Anthropicは分類器の設計と限界をかなり率直に公開している。

3月の設計解説時点で、分類器はSonnet 4.6上で動く2段構成とされている。1段目はブロック寄りに倒した高速な単一トークンフィルタで、ここでフラグが立ったものだけが2段目の思考連鎖による判定に進む。この構成により誤検知率は8.5%から0.4%に下がった（出典: Anthropic Engineering）。なお現在のドキュメントは「分類器モデルはClaude Codeが選択する」と書いており、バージョンによって別モデルが走るセッションもある。

インジェクション対策も設計に組み込まれている。分類器はユーザーのメッセージとツールコマンドのペイロードだけを見て、アシスタントの発言やツールの出力は見えない。エージェントが分類器を「説得」できないようにするためだ。

そのうえでAnthropicはこう書いている。実セッションから抽出した行き過ぎた操作52件に対して、分類器は17%を取りこぼした。ユーザーの同意がその操作の範囲全体をカバーしているかを判定しきれない場合があるからだ。そして「auto modeは、高リスクなインフラに対する慎重な人間のレビューを置き換えるものではない」と明記している。

Simon Willison氏の評価は、この点で示唆的だ。同氏は「承認疲れは実在する」としてauto modeが人間の承認より安全だという主張自体は認めつつ、プロンプトインジェクションについては「これについてはもっと独立した確認を見たい」と留保している。悪意ある依存パッケージが正当に見える指示を仕込んだ場合、auto modeの防御をすり抜けうる、という具体的な懸念も挙げている（出典: Simon Willison氏ブログ、2026年8月8日）。同氏の結論は一貫している。本当の解決は「間違ったきっかけで害を及ぼしうるデータやツールに、そもそもエージェントがアクセスできない状態で動かすこと」だ。

供給網経由の攻撃という論点は、Sentry MCPを起点にしたエージェントジャッキングの事例で既に現実になっている。分類器はコマンドの見た目を判定するが、そのコマンドを実行させた指示がどこから来たかまでは遡れない。

8月14日までにやっておくauto mode設定4つ

ここからは実務の話だ。何もしなければ8月14日以降、新しいセッションはauto modeで立ち上がる。優先度順に4つ挙げる。以下の設定項目と挙動はいずれもClaude Code Docsおよびパーミッションモードのドキュメント（2026年8月10日閲覧）に基づく。

0. auto modeをmanualに戻す・無効化する

一番聞かれるであろう「戻し方」から書く。セッション中はShift+Tabでモードを切り替えられる。恒久的に戻すなら、ユーザー設定（~/.claude/settings.json）にこう書く。

{
  "permissions": {
    "defaultMode": "manual"
  }
}

manual は設定値 default（1操作ごとに確認するモード）のエイリアスで、Claude Code v2.1.200以降で使える。プロジェクト単位で固定したい場合は、そのリポジトリの .claude/settings.json に同じ記述を置く。優先順位はプロジェクト設定がユーザー設定より優先される。逆に defaultMode: "auto" はプロジェクト設定からは無視される仕様で、リポジトリが自分自身にauto modeを付与できないようになっている。

組織としてauto modeを使わせない場合は、管理者がmanaged settings（管理者が端末に配布し、利用者側では上書きできない設定ファイル。macOSなら /Library/Application Support/ClaudeCode/managed-settings.json）に disableAutoMode を "disable" として設定する。これでShift+Tabのサイクルからautoが消え、--permission-mode auto も起動時に拒否される。

1. pushとPR作成に人間の関所を残す

v2.1.211以降、auto modeは作業中リポジトリのどのブランチへのpushも止めない。既定ブランチ（main）も例外ではない。production や release のようにデプロイ先と読める名前のブランチだけが別扱いで、分類器が本番デプロイとして個別に判断する。つまり何もしなければ、レビュー前のコードがmainに乗る可能性がある。

これを止めたいならaskルールを書く。内容を限定したaskルールは分類器より先に評価され、auto modeでも承認プロンプトを出す設計になっている。

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

2. 絶対に実行させない操作はdenyに書く

permissions.deny は分類器が呼ばれる前にブロックされ、分類器の判断でもユーザーの意図でも上書きできない仕様だ。会話中に「レビューするまでpushしないで」と伝える方法もあるが、コンテキスト圧縮でその発言が消えると境界も消える。恒久的な保証が必要ならルールとして書く。

ただし過去にはdenyルール自体が迂回される脆弱性も報告されている。ask/denyルールだけを唯一の安全装置と考えず、サンドボックスなど別レイヤーの防御と併用したい。

3. 信頼する環境を分類器に教える

auto modeを使う前提なら、autoMode.environment に自社のリポジトリホスト、社内ドメイン、信頼するバケット、社内パッケージレジストリを書いておく。分類器は既定で作業ディレクトリと現在のリポジトリのリモートしか信頼しないため、これを書かないと社内GitHub Enterpriseへのpushすらブロックされ、業務が止まる。書式は正規表現ではなく散文だ。「新しく入ったエンジニアに自社インフラを説明するように書く」のが公式の推奨になっている。

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

"$defaults" を入れ忘れると既定ルール一式が丸ごと消える。hard_deny で $defaults を落とすと、組み込みのデータ持ち出し防止ルールごと失われる。設定ファイルは変更前にバックアップを取っておきたい。設定後は claude auto-mode config を実行すれば、$defaults が展開された「実際に効いているルール」を確認できる。既定でブロックされる内容そのものを一覧したい場合は claude auto-mode defaults のほうだ。ブロックされた操作は /permissions の「Recently denied」タブに記録され、r キーで再試行をマークできる。

シェルコマンドの取りこぼしが気になる場合は autoMode.classifyAllShell を true にする。Bash(npm test) のような限定的なallowルールは既定では分類器を通らずに実行されるため、想定外の引数が滑り込む余地がある。この設定はレイテンシと引き換えにカバー率を上げる。

自分ならこうする：auto modeを使う場面と使わない場面

結論から書くと、自分（電脳狐影）はauto modeをこのブログや個人ツールのリポジトリでは有効にし、クライアント案件と本番インフラを触るリポジトリでは .claude/settings.json にmanualをピン留めする。

理由は3つある。

1つ目は、承認プロンプトが自分に対して機能していなかったという自覚がある。実際、このブログの記事投稿とビルドを回しているときの自分は、内容を読まずにEnterを押していた。Anthropicの97%という数字は他人事ではない。

2つ目は、ブロックの粒度と自分の作業の粒度が合っている領域が確かにあることだ。記事のMDXを書いてビルドしてpushする、といった作業で「取り返しがつかない」ものはほとんどない。Gitの履歴が残るからだ。

3つ目は、逆にクライアント案件では17%の取りこぼしが割に合わないからだ。@abound 氏が指摘した「読む側の行き過ぎ」は、守秘義務のあるデータを扱う環境では致命的になりうる。分類器は「このファイルを読んでいいか」を作業ディレクトリの外まで止めてはくれない。

Hacker Newsの @dexterlagan 氏の書き方が、たぶん多くの人の実感に近い。「サイドプロジェクトでauto modeを使った。うまくやってくれた。運が良かっただけで、データベースを消すこともドライブをフォーマットすることもなかった。でも少し落ち着かなかった。プロの案件でAutoに切り替えるか？　まずない。サイドプロジェクトなら？　ありかもしれない。既定にするのは？　それはよくない。既定にするならPlan modeだろう」（出典: Hacker News スレッド内 @dexterlagan 氏のコメント、2026年8月7日）。

この「既定にするならPlan mode」という提案には一理ある。ただ、Anthropicが選んだのはPlanではなくAutoだった。プルリクエスト25%増という数字も判断材料のひとつだったのだろう。安全性の向上と開発速度の向上が同じ方向を向いた変更である以上、どちらの動機がどれだけ働いたかを外から断定することはできない。ただ、既定を変える判断が安全性だけで説明できるものではないことは、公開されている数字からも読み取れる。

3月にauto modeが登場したときの位置づけは「全承認と全スキップの間の第三の道」だった。それが5か月で既定になった。v2.1.200では無告知の自動継続が撤回され、v2.1.221ではサンドボックスの認証情報マスキングが入った。既定化はその積み重ねの上にある判断であって、いきなり出てきた話ではない。

とはいえ、既定を変えるということは「設定を読まない人」を巻き込むということでもある。8月14日以降にClaude Codeを初めて触る人は、承認プロンプトが本来存在したことを知らないまま使い始める。そこで何が起きるかは、まだ誰にもわからない。

---

関連記事

• Claude Code Auto Mode完全ガイド｜1日47回の承認地獄から解放される新機能
• Claude Code v2.1.183｜git reset・terraform destroyを止める新セーフティ
• Claude Code v2.1.200｜隠れた60秒AFKモード騒動と自動化の教訓
• Claude Code v2.1.221：VSCode Focus ViewとAPIキー漏洩を防ぐ認証マスキング
• Sentry MCPを起点にしたエージェントジャッキング

---

本記事の情報は2026年8月10日時点のものです。Claude Codeは頻繁にアップデートされるため、最新の仕様は公式チェンジログおよびauto mode設定ドキュメントを参照してください。引用したHacker Newsのコメントは原文（英語）からの筆者による翻訳であり、意訳を含みます。ベンチマーク・検証結果、および本記事で引用したユーザーの事故報告はいずれもAnthropic・第三者機関・個人ユーザーが公表した内容をそのまま引用したもので、筆者が独立に再現検証したものではありません。本記事の情報に基づいてパーミッション設定を変更したことにより生じたいかなる損害についても、筆者は責任を負いません。設定変更は必ず公式ドキュメントと自身の環境を確認した上で行ってください。

※ 記載の会社名・製品名は各社の商標または登録商標です。