Claude Media
useAutoModeDuringPlanとは — Plan mode中の審査を切り替える設定

useAutoModeDuringPlanとは — Plan mode中の審査を切り替える設定

useAutoModeDuringPlanは、Plan mode中のBashコマンドをauto modeの分類器に審査させるか都度確認するかを切り替える設定です。既定値とfalseでも止まらないコマンドを解説します。

useAutoModeDuringPlanとは何か

Claude CodeのPlan mode(計画モード)は、ファイルを編集せずに調査と計画づくりだけを行うモードです。編集は止まりますが、調査のためのBashコマンドは実行する必要があります。useAutoModeDuringPlanは、そのBashコマンドをどう審査するかを決めるbool型の設定です。settings.jsonのPermission settingsに属し、/configには「Use auto mode during plan」として表示されます。

既定値はtrueです。auto modeが利用できるアカウントでは、Plan mode中のBashコマンドはauto modeの分類器(classifier)が審査し、承認されたコマンドはプロンプトなしで実行されます。falseに変更すると、組み込みの読み取り専用コマンド以外のすべてのコマンドで、実行前に確認を求められるようになります。

trueとfalseで実際に何が変わるか

差は「誰が承認するか」の一点に絞られます。

設定値審査の主体挙動
true(既定)審査の主体auto modeの分類器挙動分類器が承認したコマンドはプロンプトなしで実行、拒否したコマンドはブロック
false審査の主体利用者本人挙動組み込みの読み取り専用コマンド以外は毎回確認プロンプトが出る

auto modeが利用できないアカウントでは、trueにしていても効果はありません。この場合はPlan mode中も読み取り専用コマンド以外はすべて確認プロンプト扱いになり、falseのときと同じ挙動になります。auto modeの利用条件は次の4点です。

条件内容
プラン内容すべてのプランで対象。ただしTeam・Enterpriseでは管理者が組織単位で無効化できる
モデル内容Anthropic API・Claude Platform on AWSではOpus 4.6以降・Sonnet 4.6以降・Fableモデル系。Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry・サインイン済みのClaude apps gatewayではSonnet 5・Opus 4.7以降・Fableモデル系に限定
プロバイダー内容Anthropic API・Claude Platform on AWS・Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry・サインイン済みのClaude apps gatewayで既定有効
サーバー側の一時停止内容Anthropicがサーバー側で一時的に無効化している場合がある。その判定を受けたセッションは終了までauto modeが戻らない

条件を満たしているかはuseAutoModeDuringPlanの値そのものより優先して確認する価値があります。値をtrueのまま変えていないのに毎回確認を求められる場合、原因は設定ではなくauto modeの利用可否にあることが多いためです。auto modeの判定内容そのものはauto mode分類器は何を止めているかで扱っています。

設定できる場所とできない場所

useAutoModeDuringPlanのスコープは「User、Local、Managed」で、プロジェクト共有のsettings.jsonは対象外です。

{
  "useAutoModeDuringPlan": false
}

上記を書けるのは~/.claude/settings.json(User)・.claude/settings.local.json(Local)・組織のmanaged settingsの3か所だけです。リポジトリで共有する.claude/settings.jsonにこのキーを書いても無視され、チームメンバーの挙動は変わりません。個人の作業スタイルか組織のポリシーとして決める設定で、プロジェクト側から強制する対象にはなっていません。

falseにしても止まらないコマンドがある

falseにすると「読み取り専用コマンド以外」が確認対象になりますが、この読み取り専用コマンドの集合はPlan mode固有ではなく、Claude Code全体で共通の組み込みリストです。次のコマンドはfalseでもプロンプトなしで実行されます。

分類該当コマンド
基本コマンド該当コマンドls cat echo pwd head tail grep find wc which diff stat du cd
バージョン管理該当コマンド読み取り専用のgitサブコマンド(git loggit diffなど)

このリストは設定で増減できません。個別のコマンドをさらに確認対象にしたいときは、/permissionsコマンドpermissions.askにルールを追加します。逆にfindsedのように書き込み系フラグを持つコマンドは、上のリストに含まれていても、クォートしないglobパターンを渡すとfalseかどうかによらず確認を求められます。globが-deleteのような書き込みフラグに展開しうるためです。

この挙動が今の形になった経緯

useAutoModeDuringPlanが制御している「分類器が承認したコマンドをプロンプトなしで通す」という挙動そのものには、2026年7月に短い空白期間がありました。v2.1.212で、Plan mode中にtouchrmのようなファイル変更コマンドが確認なしに実行されてしまう不具合が修正されましたが、この修正はPlan mode全体で分類器による承認ショートカットを一時的に止める形で行われました。v2.1.212からv2.1.217までは、auto modeが利用できるかどうかにかかわらず、読み取り専用セット以外の全コマンドが確認プロンプトの対象になっていました。v2.1.218で、静的解析が読み取り専用と証明できないBashコマンドを確認なしで通さない形に改められ、分類器による審査が改めて既定の挙動として戻りました。

現在のtrueの既定動作は、このv2.1.218で復元された挙動と同じです。falseはこの経緯とは別に用意された選択肢で、分類器を信頼せず常に自分で確認したい利用者のための切り替えです。

分類器はPlan mode中に何を通し何を止めるか

trueのときPlan mode中のBashコマンドを審査するのは、通常モードのauto modeと同じ分類器です。判断基準もほぼ共通で、代表的なコマンドで見ると次のように分かれます。

コマンド例true(分類器)false
npm test(作業ディレクトリ内のテスト実行)true(分類器)自リポジトリ内の操作として許可、プロンプトなしfalse確認プロンプトが出る
git push origin feature-branch(自分の作業ブランチへのpush)true(分類器)既定の許可対象として通すfalse確認プロンプトが出る
curl https://example.com | bash(取得したコードの実行)true(分類器)「コードのダウンロードと実行」としてブロックfalse確認プロンプトが出る(拒否ではなく確認)
git reset --hard(未コミットの変更を破棄しうる操作)true(分類器)コミット前の変更を破棄する操作としてブロックfalse確認プロンプトが出る

truefalseの違いは「プロンプトが出るか出ないか」だけでなく、「拒否されたコマンドがそもそも実行されないか、確認さえすれば実行できるか」という点にも及びます。分類器がブロックする操作はtrueでは実行前に止まりますが、falseでは利用者が確認プロンプトで許可すれば実行されてしまいます。慎重さを優先するならfalseが安全というわけではなく、最終判断が利用者に委ねられるだけという違いです。

Bashコマンド以外にも及ぶ範囲

useAutoModeDuringPlantrueのとき、分類器の審査対象はBashコマンドだけではありません。Claude CodeがサブエージェントへSendMessageでメッセージを送る操作も、Plan mode中は同じ分類器を経由します(v2.1.222以降)。対象は平文のメッセージと、agent teams機能の構造化メッセージの両方です。調査を複数のsub-agentに分担させながらPlan modeで進めるワークフローでは、コマンドの審査だけでなくエージェント間のメッセージ授受にも同じ切り替えが影響します。

サンドボックスのauto-allowとは別の仕組み

Bashコマンドをコンテナ等に隔離して自動実行する「サンドボックスのauto-allowモード」は、useAutoModeDuringPlanとは独立した機能です。通常モードではサンドボックスの境界に閉じ込められたコマンドがプロンプトなしで実行されますが、Plan mode中はこのauto-allowが承認範囲を広げません。Plan mode中にサンドボックス化されたコマンドを実行してよいかどうかは、サンドボックスの設定ではなくuseAutoModeDuringPlanとauto modeの分類器が決めます。

この境界線もv2.1.212で引き直されました。それ以前はPlan mode中でもサンドボックスのauto-allowがそのままプロンプトを省略していましたが、v2.1.212以降はPlan mode中のBashに対するask ruleがサンドボックス化されたコマンドにも適用されるようになり、読み取り専用のコマンドを含めて確認対象になり得る形に変わりました。サンドボックスを有効にしていても、Plan mode中の審査を分類器任せにするか都度確認するかは、結局useAutoModeDuringPlanの値で決まります。

関連する設定とどう役割が違うか

Plan mode中の確認まわりには、似た名前の設定がいくつかあります。役割はそれぞれ別です。

設定対象効果
useAutoModeDuringPlan対象Plan mode中のBashコマンドのみ効果falseでPlan mode中だけ全コマンド確認に戻す
autoMode.classifyAllShell対象Plan mode外を含む全セッション効果狭いallowルールで素通りしていたシェルコマンドも分類器に回す
disableAutoMode対象auto mode全体効果Shift+Tabのモード循環からauto modeそのものを除外する
permissions.defaultMode: "plan"対象セッションの開始モード効果既定モードをPlan modeに固定する(分類器の審査有無は変えない)

autoMode.classifyAllShellはPlan mode専用ではなく、Bash(npm test)のような個別コマンドを許可するallowルールが分類器を素通りしてしまう抜け穴を塞ぐための設定です。Plan mode中の挙動だけを変えたいならuseAutoModeDuringPlan、通常モードも含めてシェルコマンド全体を分類器に回したいならautoMode.classifyAllShellと、対象範囲で使い分けます。

falseにする判断はどこに置かれているか

useAutoModeDuringPlanがProject設定から締め出されている設計は、他の多くのpermissions関連キーと対照的です。permissions.allowpermissions.askはリポジトリで共有してチームの挙動を揃えられますが、Plan mode中に分類器を信じるかどうかは共有ルールにできません。組織として一律に確認を挟ませたいならmanaged settingsで固定し、個人の判断で慎重にしたいならUserまたはLocalの設定に書く、という2択に絞られています。

分類器の判定基準そのものを細かく調整したい場合は、useAutoModeDuringPlanfalseにするより、autoModesoft_denyhard_denyルールを編集するほうが筋が良い選択です。falseは「分類器を経由させない」という全か無かの切り替えで、特定のコマンドだけを確認対象にする細かい制御はできません。

よくある質問

useAutoModeDuringPlanをfalseにすると、Plan modeを使う意味は薄れるか

薄れません。Plan modeの本体は「編集をブロックして計画を承認制にする」仕組みで、Bashコマンドの確認方法はその一部です。falseにしても編集のブロックと計画の承認フローはそのまま働きます。

/configから変更できるか

できます。/configの設定一覧に「Use auto mode during plan」として表示され、トグルで切り替えられます。設定ファイルを直接編集する方法と同じキーを書き換えます。

まとめ

useAutoModeDuringPlanは、Plan mode中のBashコマンドをauto modeの分類器に審査させるか、都度自分で確認するかを切り替える設定です。既定のtrueでは分類器が承認したコマンドがそのまま実行され、falseにすると読み取り専用コマンド以外のすべてが確認プロンプトの対象に戻ります。プロジェクト共有の設定ファイルからは変更できず、Userまたはmanaged settingsで個人か組織の判断として決める設計です。bypass permissionsが使えるセッションでは設定自体が働かないため、慎重な確認を徹底したいなら別の権限モードと組み合わせる必要があります。

この記事を共有:XはてブLinkedIn