Claude Codeが8月14日からauto mode既定に｜自動実行される操作と、ブロックされる操作

Anthropicが8月7日に告知、8月14日から新しいセッションの権限モードが変わる

Anthropicは2026年8月7日、Claude Codeの権限モードの既定を auto mode へ変更すると公式ブログで告知しました。適用は2026年8月14日からで、対象はPro、Max、Teamプランで新しく開始するセッションです。

Claude Codeはこれまで、ファイルの書き換えやシェルコマンドの実行のたびに「実行してよいか」を利用者へ確認していました。auto modeはこの確認をやめる代わりに、実行前に別のAIモデルが操作を1件ずつ判定します。取り返しがつかない操作、環境の外へ向かう操作だと判定されればブロックされ、そうでなければ確認なしに実行されます。

Enterpriseプラン、Claude API、Amazon Bedrockなどのほかの提供形態では、既定は当面変わりません。auto mode自体はこれらでも選べますが、使うには利用者が自分でモードを切り替える必要があります。Anthropicはこれらについても1か月以内に既定へ切り替える予定だと説明しています。

この記事では、8月14日に自分の環境で何が変わるのか、auto modeで自動実行される操作とブロックされる操作は何か、変更前に何を確認しておくべきかを、公式ドキュメントと手元のClaude Code 2.1.226で確かめた結果からまとめます。

3分で把握

実行してよいかの判定が、人からAIへ移る

Pro / Max / Teamプランで新しく始めるセッションだけが対象です。自分で別の既定を設定している場合は、その設定が優先されます。

適用日

8月14日

この日以降に開始する新しいセッションから。

対象プラン

Pro / Max / Team

Enterpriseとクラウド各社経由は当面そのまま。

危険性を判定するのは

別のAIモデル

実行前に1件ずつ危険性を判定してブロックする。

追加料金

請求しない

Pro / Max / Teamでは判定用トークンを課金対象から外す。

auto modeは許可を聞く代わりに、別のAIが実行前に判定する

Claude Codeには6つの権限モードがあります。モードによって、確認なしに実行できる範囲が変わります。auto modeはそのうちの1つで、2026年3月24日に研究プレビューとして公開され、7月10日に全利用者へ提供されました。今回の変更は新機能の追加ではなく、どのモードで起動するかの既定値が変わるという話です。

8月13日までの既定

Manual（設定値は default）

読み取り以外は毎回確認します。ファイルを1つ書き換えるたび、コマンドを1つ実行するたびに手が止まります。

向く場面：本番に近い環境、初めて触るリポジトリ

8月14日からの既定

Auto（設定値は auto）

確認を出さずに実行し、危険だと判定された操作だけをブロックします。判定するのは会話の応答とは別のAIモデルです。

向く場面：方向性を任せてよい長い作業

選べるほかのモード

Plan / Edit automatically

Planは調査と計画だけを行い、編集はしません。Edit automaticallyは作業フォルダ内のファイル編集だけを確認なしで通します。

向く場面：先に方針を固めたいとき、差分を後でまとめて見たいとき

auto modeと混同しやすいモード

Bypass permissions

確認も安全判定もどちらも行わずに実行します。auto modeとは別物で、Anthropicはコンテナや仮想マシンなど隔離された環境だけで使うよう求めています。

向く場面：壊れても影響が閉じる使い捨て環境

この判定を担当するAIモデルは、公式ドキュメントでは classifier、日本語の記事では分類器と呼ばれます。分類器には、利用者のメッセージ、実行しようとしているツール呼び出し、プロジェクトの CLAUDE.md が渡されます。ファイルの中身やWebページの取得結果は渡されません。公式ドキュメントは、読み込んだファイルやページに攻撃者の指示が仕込まれていても、判定する側を直接操作できないようにするためだと説明しています。

すべての操作が判定に回るわけではありません。ファイルの読み取りと、作業フォルダ内のファイル編集は判定を経ずに実行されます。判定が入るのは主にシェルコマンドとネットワーク通信です。ただし .git や .claude など、Claude Codeが保護対象として扱うパスへの書き込みは、作業フォルダ内でも判定に回ります。

Claude Codeが確認なしで実行する操作と、ブロックされる操作

何が通って何が止まるかは、公式ドキュメントに一覧があります。設定を書かない初期状態で信頼されるのは、作業中のgitリポジトリと、セッション開始時点で設定されていたリモートだけです。それ以外の送信先はすべて「外部」として扱われます。

確認なしで実行される操作

  • 作業フォルダ内でのファイル作成、編集、削除
  • package.json などに書かれている依存関係のインストール
  • .env の読み取りと、その認証情報を対応するAPIへ送ること
  • 読み取りだけのHTTPリクエスト
  • 作業中のリポジトリへのプッシュとPull Requestの作成

ブロックされる操作

  • curl | bash のような、ダウンロードしたコードの実行
  • 秘密情報を外部の送信先へ送ること
  • 本番環境へのデプロイ、データベースの移行
  • 強制プッシュ、git reset --hard、terraform destroy
  • セッション開始前から存在するファイルを元に戻せない形で消すこと
  • IAMやリポジトリの権限付与、共有インフラの変更

作業中のリポジトリへのプッシュが確認なしで通る点は、初めて読むと不安に感じるかもしれません。ただしプッシュの中身は別途検査され、秘密情報が混ざるコミットや、CIが動いたときに情報を外部へ渡すことになる設定変更はブロックされます。production や gh-pages のように、公開先だと分かる名前のブランチへのプッシュも個別に判定されます。

会話の中で述べた制限も判定に使われます。「レビューするまでプッシュしないで」と伝えると、既定では許可される操作でもブロックされます。ただしこの制限は規則として保存されず、会話の履歴が圧縮されて該当メッセージが消えると失われます。確実に止めたい操作は、後述する設定ファイルの規則で指定するほうが安全です。

人が承認するより、auto modeのほうが危険なコマンドを止めた

既定を変える根拠として、Anthropicは自社で実施した対照実験の結果を公開しています。調査会社を通じて集めた有償の職業テスター1,053人に、実験用の環境でClaude Codeを操作してもらい、セッションの途中で許可プロンプトの1件を明確に危険なコマンドへ差し替えました。承認しても危険な操作は実行されず、画面に表示される文面だけが変えられています。

横棒グラフ。危険なコマンドを止めた割合は、人間のテスターが13.6%（1,053件中143件）、auto modeの分類器が89.0%（1,053件中937件）。
同じ1,053件を母数にした比較。出典：Anthropic「Auto mode is now the default in Claude Code for Pro, Max, and Team plans」2026年8月7日

人間のテスターが危険なコマンドを止められたのは13.6%でした。同じコマンドをauto modeは89%ブロックしています。Anthropicは背景として、Claude Codeで表示される許可プロンプトの97%が承認されていることも挙げています。確認画面が出ていても、内容を読まずに通している場合が多いという説明です。

作業量の面では、auto modeを使うチームのPull Request数が約25%多いとしています。ただしこれは導入企業の傾向として示された数字で、上の実験のような対照条件で測ったものではありません。

今回の発表で気になったのは、承認率97%という数字のほうです。確認を出すこと自体が安全対策になっていたのか、それとも作業を止めていただけなのかを、Anthropicが自社の利用データで問い直した形になっています。

実行前に判定するAIも、危険な操作の一部は見逃す

auto modeは安全性を保証するものではありません。Anthropicは公式ドキュメントに「auto modeは許可の確認を減らすが、安全を保証しない」と明記し、開発の経緯を説明した記事では判定の精度を数字で公開しています。

  • 社内の実際の操作1万件に対して、問題のない操作を誤ってブロックした割合は0.4%
  • 社内で実際に起きた行き過ぎた操作52件のうち、17%は判定をすり抜けた
  • データ持ち出しを模した合成データ1,000件では、5.7%がすり抜けた

危険な操作の2割近くが通ってしまう可能性がある、というのがAnthropic自身の測定結果です。同記事は、高リスクなインフラ作業について人間のレビューを置き換えるものではないと書いています。

ブロックが続いた場合の動きも決まっています。3回連続、または1セッションで合計20回ブロックされると、auto modeは一時停止して従来の確認へ戻ります。表示された操作を承認すると、auto modeが再開します。このしきい値は設定で変更できません。

解除できない禁止規則は、実は多くありません。手元で確認したところ、利用者の指示でも解除できない hard_deny は「秘密情報が信頼範囲の外へ出ること」の1件だけでした。それ以外の禁止は、利用者が実行したい操作を具体的に指示すれば通ります。「リポジトリを整理して」のような漠然とした依頼では強制プッシュは通りませんが、「このブランチを強制プッシュして」と書けば通る、という設計です。

手元のClaude Code 2.1.226で、初期状態の禁止ルールを数えた

公式ドキュメントは禁止規則の分類を説明していますが、実際に何件の規則が働いているかは書かれていません。手元のmacOSで claude auto-mode config を実行し、この環境で有効になっている設定を出力しました。

# 組み込みの既定ルールを表示する
claude auto-mode defaults

# 自分の設定を反映した、実際に使われるルールを表示する
claude auto-mode config

解除できない禁止

1件

秘密情報が信頼範囲の外へ出ること

指示で解除できる禁止

65件

強制プッシュ、本番デプロイなど

禁止の例外

17件

禁止に当たっても通してよい操作

環境の定義

20項目

うち13項目が「未設定」のまま

設定ファイルへ何も書いていない状態でも、65件の禁止規則が働いていました。defaults と config の出力は完全に一致し、この環境では既定値がそのまま使われていることも確認できました。

一方、環境を説明する20項目のうち13項目は「未設定」でした。社内で使うドメイン、クラウドのバケット、社内向けのパッケージ配布先、CI/CDの配布先などが、すべて未設定のままです。この状態では、それらはすべて信頼範囲の外として扱われます。個人の開発では困りませんが、社内システムへ接続する作業では、ブロックが繰り返される原因になります。

ここまではmacOS 26.5.1、Claude Code 2.1.226という単一の環境で確認した結果です。公式ドキュメントは禁止項目がバージョンごとに追加・変更されてきたと記載しているため、別のバージョンで同じ件数になるとは限りません。

リポジトリの中に置いた設定ファイルは、auto modeの判定に使われない

auto modeの設定を書く場所には制限があります。判定に使われるのは、利用者ごとの ~/.claude/settings.json、組織の管理設定、起動時の --settings の3か所だけです。リポジトリの中にある .claude/settings.json と .claude/settings.local.json からは読み込まれません。公式ドキュメントは、リポジトリやビルド手順が自分自身に許可を与えられないようにするためだと説明しています。

これを実際に確かめました。空のフォルダを作り、そのプロジェクト設定へ目印になる信頼ドメインを書きます。

// .claude/settings.json （この書き方では反映されません）
{
  "autoMode": {
    "environment": [
      "$defaults",
      "Trusted internal domains: verify-marker.example.com"
    ]
  }
}

このフォルダで claude auto-mode config を実行すると、目印 verify-marker.example.com は出力に1件も現れませんでした。同じ内容を --settings でその場で渡した場合は、信頼ドメインとして出力に現れます。書き方の誤りではなく、プロジェクト設定という置き場所そのものが読まれていません。

この違いはエラーも警告も出ません。設定を書いた本人は効いていると思い込んだまま作業を続けることになります。auto modeの設定を書くなら、~/.claude/settings.json へ置いてください。

8月14日までに、自分の既定モード設定を確認しておく

やるべきことは、使っているプランと現在の設定で変わります。

質問1：Pro、Max、Teamプランのいずれかを使っていますか

いいえ（Enterprise、Claude API、クラウド各社経由）：8月14日の変更対象ではありません。既定は当面そのままです。使ってみたい場合は Shift+Tab でモードを切り替えられます。

はい：次の質問へ進んでください。

質問2：~/.claude/settings.json に permissions.defaultMode を自分で設定していますか

設定している：その設定が優先されます。auto modeへ切り替えるかどうかを尋ねる確認が1回だけ表示される場合があり、承認しなければ今のモードのまま使えます。

設定していない：8月14日以降の新しいセッションはauto modeで始まります。従来どおり毎回確認したい場合は、事前に "defaultMode": "default" を書いておいてください。

auto modeを使いつつ、特定の操作だけ確認したい場合

permissions.ask に操作を書くと、auto modeでも必ず確認が表示されます。この規則は判定より先に評価されます。

プッシュとPull Request作成の前に必ず自分で確認したい場合は、次のように書きます。ほかの操作はauto modeのまま動きます。

// ~/.claude/settings.json
{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

従来どおり毎回確認する運用へ固定するなら、既定モードを指定します。設定値は default です。画面上の表示名は「Manual」ですが、設定ファイルへ書く値は異なります。Claude Code 2.1.200以降なら "manual" と書いても同じ意味になります。

// ~/.claude/settings.json
{
  "permissions": {
    "defaultMode": "default"
  }
}

セッションの途中で切り替えたいときは Shift+Tab を押します。現在のモードは画面下部に表示されます。auto modeでブロックされた操作は /permissions の「Recently denied」に残り、r キーで手動承認へ回せます。

Teamプランの管理者は、組織全体でauto modeを無効にできます。管理設定で permissions.disableAutoMode を "disable" にすると、メンバーはこのモードを選べなくなります。

モードは作業の種類で分け、既定は自分で決めておく

8月14日の変更は、これまで人が押していた承認ボタンを、判定用のAIモデルへ引き渡すものです。Anthropicの実験では分類器のほうが危険なコマンドを多く止めました。ただし同社の測定では、実際に起きた行き過ぎた操作の17%がすり抜けています。人もAIも取りこぼす、というのが公開されている範囲から言えることです。

実際に選ぶなら、作業の種類でモードを分けるのが現実的だと思います。個人のリポジトリで長い実装を進める作業はauto modeに任せ、本番環境の設定を触るセッションは Shift+Tab でManualへ戻す、という使い分けです。Anthropicが公開している導入企業の事例でも、機微な作業では手動確認へ切り替える運用が紹介されています。

まずは自分の ~/.claude/settings.json を開いて、permissions.defaultMode が書かれているかを確認してください。書かれていなければ、8月14日以降の新しいセッションはauto modeで始まります。それでよいかを決めてから当日を迎えるほうが、初回の起動で慌てずに済みます。

参考資料

ルール件数と設定の反映結果は、2026年8月11日にmacOS 26.5.1・Claude Code 2.1.226で確認しました。バージョンによって件数や既定の挙動は変わります。

AI活用・自動化

Posted by Negichou Lab 編集部