以前このブログで、Claude Codeのauto modeがterraform destroyを公式にブロックするようになった話を紹介した。あのときはまだ「使いたい人が有効にする実行モードの一つ」だったが、状況が変わった。2026年8月14日から、Claude CodeのPro・Max・Teamプランでは新規セッションの既定パーミッションモードそのものがauto modeになる。公式ドキュメントで確認できたので、何が変わり何が変わらないのかを整理する。

何が起きるのか

auto modeは、ファイル編集やコマンド実行のたびに人間の承認を求める代わりに、分類器(classifier)が都度「不可逆・破壊的・作業環境の外に向かう操作かどうか」を判定し、安全と判断されたものは確認なしで実行する仕組みだ。これまではdefaultモード(読み取りのみ自動、それ以外は逐次承認)が新規セッションの既定だったが、8月14日以降はこの既定がauto modeに置き換わる。

ただし全員が強制的に切り替わるわけではない。公式ドキュメントには次のようにある。

Starting August 14, 2026, auto mode becomes the default permission mode for new sessions on Pro, Max, and Team plans. You can switch modes at any time. A default you set yourself stays in place unless you accept the one-time switch prompt, and a default your organization manages is unchanged.

つまり、すでに自分でパーミッションモードの既定を設定している場合はワンタイムの切替案内が出るだけでそのまま維持され、組織(Team/Enterpriseプラン)側で既定を管理している場合もその設定が優先される。影響を受けるのは「今まで何も設定していなかった」新規セッションだ。

なぜ変えるのか

Anthropicは変更の根拠として、独立機関による安全性テストの結果を公開している。この数値についてはAnthropic公式ブログ(claude.com/blog)へ本セッションから直接アクセスできなかったため、Anthropic公式のX(@ClaudeDevs)・Threads(@claudeai)アカウントでの引用と、TechCrunchやThe New Stack等の複数の独立した海外メディアが一致して報じている範囲の数字にとどめる。

数値自体はAnthropicが自社で実施・公開した検証の結果であり、母集団も特定の条件下でのものなので、自社の環境やチームにそのまま当てはまるとは限らない。あくまで「人間の逐次承認は疲労で形骸化しやすい」という傾向を示す参考値として見るのが妥当だ。

「既定」の中身も変わっている

もう一つ実務上見落としやすいのが、auto modeの分類器が信頼する範囲は既定でかなり狭いという点だ。公式ドキュメントによれば、分類器が最初から信頼しているのは「作業ディレクトリ」と「現在のリポジトリに設定されているリモート」だけで、自社のクラウドバケットや社内ドメイン、内部サービスは、autoMode.environmentに明示的に追加しない限り「外部」として扱われる。

一方で、pushやプルリクエスト作成については、2.1.211以降は作業中のリポジトリのデフォルトブランチへのpushも既定で許可されるようになった(それ以前は自分の作業ブランチとClaude自身が作ったブランチへのpushのみが既定許可だった)。「pushだけは必ず人に確認してほしい」というチームは、この既定に任せずpermissions.askで明示的に固定する必要がある。

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

中小企業が今週決めておくこと

  1. 8月14日より前に、自社のパーミッションモードの既定を一度確認する。 何も設定していないチームは自動的にauto modeへ切り替わる対象になる。「まず様子を見たい」なら、切替案内が出た時点で従来のモードを選び直せばよい
  2. push・PR作成・本番デプロイなど「絶対に人に確認してほしい操作」はpermissions.askで明示的に固定する。 分類器の判定に委ねるか、会社のルールとして固定するかは、ハーネスの権限設計として最初に線引きしておくべきポイントだ
  3. autoMode.environmentに自社の信頼境界(ソースコード管理・クラウドバケット・社内ドメイン等)を自然文で書いておく。 未設定のままだと、日常的な社内操作まで「外部への操作」として都度ブロックされ、かえって現場の摩擦が増える

ベンダーの既定値は変わり続ける

前回の記事でも書いたが、ベンダー側の既定値は今回のように数か月単位で変わっていく。「そのうち安全になるだろう」と待つのではなく、ハーネスの考え方に沿って、どの操作を分類器に委ね、どこを自社のルールで固定するかを自分たちの言葉で決めておくことが、結局はもっとも効く対策になる。この権限設計の線引きはパイロット・構築のフェーズで詰めるテーマの一つだ。自社の運用でどう設計すべきか整理したい場合は、30分の無料診断で相談できる。