Claudeアプリのauto mode既定化 — Pro・Max・Teamの対象と止め方

Claudeアプリでは、Pro・Max・Teamプランの新規セッションがauto modeで始まるようになります。10月22日の更新で「翌週から」と案内された変更です。個々の操作を承認する代わりに自動の確認が走り、安全と判断されたものは通り、危険と判断されたものは止まります。

止めたい場合の選択肢は3つあります。セッションごとにモードを切り替える、既定のモードを自分で固定する、管理者がauto mode自体を無効にする、のいずれかです。

何が変わるのか

案内の骨子は次のとおりです。

• 対象はPro・Max・Teamの新規セッションで、ほとんどのClaudeアプリで始まる
• 承認を求める代わりに自動の確認が各操作を審査する
• 安全な操作はそのまま進み、危険な操作は止まる。止まった場合、Claudeは別の経路を探す
• Enterpriseは、管理者の組織で既定になる前に管理者へメールが届く

Claude Codeのターミナル側ではこの既定化がすでに進んでいます。経緯はClaude Codeのauto mode既定化で確認したい設定にあります。今回の更新は、同じ考え方をアプリの新規セッションへ広げたものです。

対象になる条件を状況別に見る

誰の新規セッションがautoで始まるかは、プランと既存の設定で決まります。案内の記述を状況別に並べると次のとおりです。

表の3行目と4行目が肝心です。すでにモードを決めている人と、管理者が決めている組織には、既定化の影響が及びません。

「ほとんどのClaudeアプリ」の範囲は列挙されていない

更新の文面は「most Claude apps」と書くだけで、どのアプリが含まれるかを一覧にしていません。ここは推測で補わず、アプリごとに確かめるのが確実です。

手がかりになる事実はCode関連のドキュメントにあります。

• デスクトップアプリのCodeタブには、プロンプト欄の下にモードのセレクターがある。autoはauto modeが使えるときだけ表示され、専用の設定トグルはない
• claude.ai/codeにはモードのドロップダウンがあり、モバイルアプリでは「+」から「Permission」を選ぶ。クラウドセッションの選択肢はAccept edits、Plan、Autoで、Autoは組織が許可していてモデルが対応しているときだけ出る
• Coworkはこれらのモードを使わない。独自の権限モードを持ち、既定の状態ではセレクターが出ない

つまり、同じ「Claudeアプリ」でも、Codeタブとクラウドセッションで選べるモードは違います。Coworkの自動承認は別の仕組みで、Cowork自動承認モードとClaude Codeのauto modeの違いで整理しています。

新規セッションを開いたとき、モード表示がAutoになっているかを見るのが最短の確認です。

auto modeは何を審査し、止まるとどうなるか

auto modeは、各ツール呼び出しを分類器に通します。狙いは「元に戻せない」「破壊的」「環境の外に向かう」操作の阻止です。

分類器が操作をブロックしても、そこで止まりきるわけではありません。Claudeは多くの場合、自分でより安全な方法を探すか、続行してよいかを直接尋ねてきます。ブロックが3回連続するか、1セッションで合計20回に達すると、Claude Codeは手動承認に戻ります。

特に強い扱いを受けるのが「ハードデナイ」です。コードや秘密情報を外部へ送るようなデータ流出は、分類器が承認しない前提の区分です。実行したいなら、auto modeを抜けるか、自分でコマンドを実行します。

分類器が具体的に何を既定で止めるかはClaude Code auto modeブロック一覧にまとめています。

既定を止める・戻す方法

auto modeをやめたいときの手段は、手元でできるものと管理者がするものに分かれます。

個人でできること

最も手軽なのは、セッションを開いたあとにモードを切り替えることです。ターミナルではShift+Tab、デスクトップアプリではモードのドロップダウンを使います。Shift+Tabの巡回は、autoから最初に押すとManualへ、その後Accept edits、Planの順です。

デスクトップアプリで選んだモードはフォルダごとに記憶され、defaultModeより優先されます。例外はPlanで、選んでもそのセッションだけに効きます。

毎回切り替えたくないなら、既定のモード自体を固定します。デスクトップアプリはCLIと同じ設定ファイルを読み、新しいローカルセッションに適用します。Manualに固定する例は次の形です。

{
  "permissions": {
    "defaultMode": "default"
  }
}

defaultはアプリの表示ではManualにあたります。ここで固定すれば、冒頭の表のとおり、既定化の影響は受けません。

注意点が1つあります。このdefaultModeが読まれるのは、デスクトップアプリの新しいローカルセッションです。クラウドセッションやモバイルのモード選択は別の枠で、Autoが出るかは組織の許可とモデルの対応に左右されます。

管理者ができること

Team以上の管理者には、2つの手段があります。

• 管理設定のdefaultModeで、組織全体の既定を固定する
• 管理設定のdisableAutoModeを"disable"にして、モード一覧からautoを外す

後者は、実行中のセッションにも効きます。管理元の設定が届いたセッションはautoを離れ、auto mode disabled by settingsと表示されます。この設定はユーザー設定やプロジェクト設定にも書けますが、管理設定に置いたほうが利用者に上書きされません。

autoで始まらないときの切り分け

既定化の対象のはずなのにAutoで始まらない場合は、上から順に確かめます。

「14%対89%」の数字をどう読むか

既定化の根拠として、案内は1,053人の有償テスターによる実験を挙げています。「14%対89%」と要約されやすい数字なので、条件を確かめておきます。

実験の設計には、読み方を左右する条件があります。

• テスターは、この研究のために用意された環境で作業した。自分のコードベースや実プロジェクトではない
• セッションの途中で、承認を求める1つのプロンプトが、明らかに危険なコマンドに差し替えられた。承認しても、実際に危険なものが実行されることはない
• 同じ状況で、autoだけが止めたものが800件、人間だけが止めたものは6件だった
• セッションが長くなるほど人間の阻止率は下がる。序盤は約17%、50回以上の承認を重ねた後は約5%。autoの阻止率は長さに関係なく一定

この結果からは、手動承認を重ねるほど確認が形骸化する傾向が読み取れます。一方で、「単発の明白な危険コマンド」への反応を測った実験であり、あらゆる場面でautoのほうが安全だと示すものではありません。

敵対的なレッドチーム試験では、分類器の見逃し率が12%から7%に下がったと報告されています。ただしこれは、分類器の弱点を探すために作られた合成の攻撃での値で、実運用の見逃し率ではないと明記されています。

案内自身も、auto modeは分類システムに依存するためリスクをなくすものではなく、本番インフラへの重要な変更は自分で確認することを勧めています。

既存の許可ルールはどうなるか

手動承認の時代に積み上げた許可ルールは、auto modeでも原則として先に働きます。ただし例外があります。python:*のように任意のコード実行を許してしまうほど広い許可ルールは、auto modeの間は脇に置かれます。分類器を素通りしてしまうためです。

設定ファイル自体は書き換えられません。別のモードに切り替えた瞬間、そのルールはまた有効になります。

料金への影響

Claude Codeの利用者向けには、分類器が1回のツール呼び出しごとに少量のトークンを使うことが説明されています。Pro・Max・Teamでは、この分類器の分は課金されません。アプリ側で同じ扱いになるかは、更新の文面には書かれていません。

まとめ

アプリ側のauto mode既定化は、既定のモードを何も決めていないPro・Max・Teamの利用者に効く変更です。すでに固定している人と、管理設定で決めている組織は影響を受けません。

迷うなら、新規セッションのモード表示を見て、Autoのままでよいかを決めます。本番環境に触れる作業が多い人は、その作業のセッションだけManualに切り替えるのが現実的な線引きです。Enterpriseの管理者は、事前メールを受け取ってからdisableAutoModeを入れるか、defaultModeで固定するかを判断できます。

ターミナル側の設定の優先順位はClaude Codeのauto mode既定化で確認したい設定、CLI側の変更点はClaude Code v2.1.284にあります。