一般企業に勤めるSE向けに、AI関連の最新情報を「実務での判断」に翻訳して届ける。

調達

既定が変わった。何も選ばなかった人の設定が変わった

  • 8/14既定が auto mode に変わった日
  • 2つ許可判断に関わるモデル
  • 4段分類器内部の優先順位

8月14日から、Claude Code の新規セッションは auto mode で始まるようになった。Pro、Max、Team の各プランが対象である。

機能が増えたのではない。既定値が変わった。

ただし全員ではない。公式の告知はこう書いている。

自分で既定のモードを設定している場合はそのまま残る(一度きりの切り替え確認を承諾しない限り)。組織が管理している既定は変わらない。

つまり変わったのは、自分でも組織でも既定を決めていなかった人だけである。裏を返せば、決めていなければ変わった。

auto mode とは何か

通常、Claude Code はファイルを書き換えたりコマンドを実行したりする前に人に確認を求める。auto mode ではその確認を、分類器と呼ばれる2つ目のモデルが代わりに行う。

分類器が止めるのは「取り返しがつかない、破壊的、あるいは環境の外に向かう」操作だと定義されている。

重要なのは、何を「外」と見なすかの既定値である。公式ドキュメントはこう書いている。

既定では、分類器は作業ディレクトリと現在のリポジトリの設定済みリモートだけを信用する。

つまりそれ以外の宛先はすべて流出先の候補として扱われる。自社の別リポジトリへの push も、チームのクラウドバケットへの書き込みも、明示的に登録するまで止まる。厳しい側に倒してある。

止め方には階層がある

ここが実務で効く。止める手段は1つではなく、評価される順番が決まっている。

分類器より前に評価されるものが2つある。

  • deny — 実行させない。分類器に届く前に止まり、分類器も利用者の意図も覆せない
  • ask — 必ず確認を出す。auto mode でも分類器が勝手に承認できない

分類器の中では、さらに4段の優先順位がある。

操作のリクエスト deny 実行させない。分類器に届く前に止まる ask 必ず確認を出す。自動で承認されない ここまでは上書きできない 分類器(2つ目のモデル) 1hard_deny無条件に止まる 2soft_deny破壊的な操作を止める 3allowsoft_deny の例外として上書きする 4明示的な意図残った soft_deny を上書きする 実行
評価は上から順に進む。破線の2つは soft_deny を上書きできる側で、実線の deny と ask は分類器より前にあるため上書きされない。

4番目には条件がある。「リポジトリを整理して」は force push の承認にならないが、「このブランチを force push して」は承認になる、と例示されている。曖昧な指示は通らない。

で、SEの実務ではどう使うか

情シスや調達の審査で確認すべき点は3つある。

止めたいもの 書く場所 開発者が上書きできるか
絶対に止める managed settings の permissions.deny できない
必ず人を挟む ask ルール できない(確認は必ず出る)
破壊的な操作を既定で止める 分類器の soft_deny できる(開発者の allow が例外になる)

1つめ。組織の設定は、開発者が上書きできる場合がある。

管理者が配布した設定を開発者が削除することはできない。ただしドキュメントは続けてこう書いている。

allow ルールは分類器内部で soft block ルールの例外として働くため、開発者が追加した allow は組織の soft_deny を上書きできる。組み合わせは追加式であって、ポリシーの境界ではない。

「組織で禁止した」つもりが、禁止になっていない。 ここを取り違えると、審査資料と実態がずれる。

2つめ。絶対に止めるものは、分類器に判断させない。

公式が明示している。無条件に止めたい操作は、managed settings の permissions.deny に書く。これは分類器が呼ばれる前に評価され、上書きできない。分類器の設定で止めるのと、その前で止めるのは別物である。

3つめ。分類器はプロジェクト内の設定ファイルを読まない。

リポジトリ直下の設定は、分類器の設定としては無視される。理由も書かれている。チェックインされたリポジトリやビルド手順が、自前の allow ルールを注入できてしまうからである。外部から持ち込まれた設定で緩められない作りになっている。

もう1点、見落としやすい挙動がある。狭い範囲の Bash 許可ルールは、分類器を通らずに実行される。 auto mode が停止させるのは任意コード実行を許すような広いルールだけで、限定的なルールはそのまま通る。すべてを分類器に通したい場合は、その旨の設定を有効にする必要がある。

push や PR 作成の前に人を挟みたい場合は、ask ルールを置けば auto mode のまま実現できる。

審査すべきは機能ではなく既定値

この変更で新しくできるようになったことは無い。auto mode 自体は以前からあった。変わったのは、何も選ばなかった人がどれになるかである。

そして先に見たとおり、組織が既定を管理していれば変わらなかった。 管理していなかった組織だけが、告知を読んでいなければ気づかないまま切り替わっている。

導入判断の資料は、たいてい「その機能を使うか」で書かれる。だが実際に効くのは、使うと決めていない人が置かれる状態のほうだ。既定値は告知なく変わりうるし、実際に変わった。

確認すべきなのは「auto mode を使うか」ではない。**「いま自分の組織はどのモードで動いているか」と「絶対に止めたいものが、上書きできない場所に書かれているか」**である。

出典

一次ソース確認済み
  1. https://code.claude.com/docs/en/permission-modes
  2. https://code.claude.com/docs/en/auto-mode-config
  3. https://code.claude.com/docs/en/whats-new/2026-w32