Claude Code auto modeの環境設定を自動生成する/auto-mode-setupの使い方と注意点

Claude Codeに、auto modeの環境設定を自動生成する/auto-mode-setupというコマンドが追加されています。プロジェクトや最近のセッション、必要ならシェル履歴まで読み取って、「この環境で何を信頼してよいか」をauto modeの判定モデルに教える設定を下書きしてくれるセットアップウィザードです。

このコマンドは、2026年8月17日時点で公式ドキュメントにもCHANGELOGにも記載がありません。一方で、現行バージョン（v2.1.233）には実在し、実行すると動作します。

この記事では、公式ドキュメントに記載のあるauto mode本体の仕様と、v2.1.233での実際の実行結果をもとに、/auto-mode-setupが何をするコマンドで、何が収集され、どこに何が保存されるのかを整理します。ドキュメント未掲載の機能のため、細部は将来のバージョンで変わる可能性があります。

/auto-mode-setupとは

/auto-mode-setupは、auto modeの判定モデルに渡す環境情報（autoMode設定ブロック）を自動生成するコマンドです。 auto modeのオンオフを切り替えるコマンドではありません。

Claude Codeのセッション内でスラッシュコマンドとして実行します。

/auto-mode-setup

実行すると、いくつかの質問に答えたあとバックグラウンドでスキャンが走り、「Gathering data and drafting your auto-mode setup; back soon」というメッセージが表示されます。スキャン完了後にレビュー画面が表示され、承諾するとユーザー設定ファイル（~/.claude/settings.json）にautoModeセクションが書き込まれます。

生成されるautoMode設定は、これまで公式の設定リファレンスを読みながら手書きする必要がありました。 /auto-mode-setupは、その手書き作業を「環境を自動調査して下書きし、人間はレビューだけする」形に置き換えるものです。

前提となるauto modeと分類器の仕組み

auto modeは、Claude Codeの権限モードの一つです。確認プロンプトの代わりに、分類器（classifier）と呼ばれる別のモデルがツール呼び出しを検査し、「不可逆な操作、破壊的な操作、環境の外側へ向かう操作」だけをブロックします。正確には、許可、確認、拒否のルールに一致した操作と、読み取りや作業ディレクトリ内の編集のような明らかに安全な操作が先に処理され、残りが分類器に渡ります。

権限モードのドキュメントによると、対応モデル（Opus 4.6以降、Sonnet 4.6以降、Fable 5など）を使っていればすべてのプロバイダで利用できます。ターミナルで使うPro、Max、Teamプランのセッションでは、v2.1.228以降、既定の開始モードがautoになっています。ただしヘッドレス実行（claude -p）やAgent SDK、Enterpriseプランなどは従来どおりManual始まりで、TeamとEnterpriseでは管理者側で無効化もできます。

分類器が初期状態で信頼するのは、作業ディレクトリと、現在のリポジトリに設定されたリモートだけです。それ以外の場所への操作（社内の別リポジトリへのpush、クラウドバケットへの書き込み、内部ドメインへのリクエストなど）は、autoMode.environmentに信頼する対象として書くまでブロックされます。

つまりauto modeを快適に使えるかどうかは、「自分の環境を分類器にどれだけ正確に教えてあるか」で決まります。 /auto-mode-setupが自動化するのは、この「教える」部分です。

なおauto mode自体も比較的新しい機能です。 CHANGELOGを遡ると、v2.1.111で「Opus 4.7利用時にMaxサブスクライバーでも使える」ようになり、同時にオプトイン用フラグの指定も不要になりました。以後120以上のバージョンにわたって、分類器の改善が続いています。 /auto-mode-setupはその延長で追加されたと見られますが、追加バージョンの告知は見つかりませんでした。

実行から保存までの流れ

v2.1.233で実行した際の流れは次のとおりです。

まず「Set up auto mode for your environment?」という質問画面が表示されます。ここでは、この環境でのClaude Codeの使い方（仕事、オープンソース、趣味、混在）を選び、追加でスキャンする対象を決めます。シェル履歴のスキャンと、ホームディレクトリ配下の他のリポジトリのスキャンはオプションで、シェル履歴は既定でオンです。

すでにautoMode設定が保存されている場合は、その前に「既存設定に追記する（Add to them）」か「environmentセクションを作り直す（Start fresh）」かを聞かれます。

質問に答えるとバックグラウンドでスキャンが始まります。スキャンはバックグラウンドタスクとして登録されるため、待っている間も通常の作業を続けられます。

スキャンが終わると、モデルが設定の提案を作り、進行中の作業の区切りで「Review proposed auto-mode setup」というレビュー画面が表示されます。レビュー画面には、信頼する環境（Environment）、許可の例外（Allow carve-outs）、追加のブロックルール（Extra soft blocks、Extra hard blocks）、そしてメモ（Notes。収集できなかった項目、既定値のまま残した項目、本来確認したかった点）が並びます。

選択肢は「Looks good — save it」と「Discard and exit」の二つです。承諾するまで設定ファイルには何も書き込まれず、Discardを選べば何も保存されません。

保存後に、もう一つ確認画面が出る場合があります。ユーザー設定のpermissions.allowに広すぎる許可ルールがあると、その削除を提案してくるものです。この削除に応じると、auto mode以外のモードでも該当操作で再び確認プロンプトが出るようになります。削除はスキップでき、スキップしてもautoMode設定自体は保存されます。

スキャンで収集されるデータ

実行時の表示とバイナリ内の実装文言から確認できたスキャン対象は次のとおりです。

現在のプロジェクトのCLAUDE.mdとドキュメント類
リポジトリの基本情報と、ghコマンド経由のリポジトリ公開範囲、ブランチ保護設定
設定ファイル類から抽出した名前（パッケージレジストリのURL、DockerfileのFROM行のレジストリホスト、CIワークフローが参照するシークレット名、package.jsonのスクリプト名など）
過去セッションのBashコマンドから抽出した識別子（接続先のホスト名、クラウドバケット名、Kubernetesの名前空間、非標準のCLI名。いずれも出現回数付き）
過去にauto modeの分類器が拒否した操作とその理由
既存のautoMode設定と、ユーザー設定のうちauto modeが無視する広すぎるpermissions.allowエントリ
シェル履歴（コマンド部分のみ。~/.zsh_history、~/.bash_historyなど。オプション、既定オン）
ホームディレクトリ配下の他のgitリポジトリ（リポジトリのパスと、リモートのホスト、組織、リポジトリ名。オプション）

コマンド履歴や利用状況は、コマンド文字列を逐語で送るのではなく、抽出した識別子と頻度に丸めて扱われます。ただし、接続先のホスト名やバケット名のような、引数に由来する識別子は含まれます。

それでも、スキャン範囲には注意が必要です。シェル履歴のスキャンは既定でオンのため、履歴に顧客名やプロジェクト名を含むコマンドが残っている場合、それが分析対象に入ります。ホームディレクトリ配下に顧客のリポジトリを置いている場合も同様です。分析させたくない情報がある場合は、最初の質問画面でスキャン対象を「このプロジェクトとセッションだけ」に絞れます。

保存される設定の中身

保存先は、ユーザー設定の~/.claude/settings.jsonだけです。 autoMode設定は、プロジェクト側の.claude/settings.jsonと.claude/settings.local.jsonのどちらからも読み込まれません（後者はv2.1.207で読み込み対象から外れました）。どちらもリポジトリ配下に置かれるファイルのため、チェックインされた設定から許可ルールを注入される事態を防ぐ設計です。

生成されるautoModeは、信頼する環境の記述（environment）を中心に、必要に応じて許可ルールとブロックルール（allow、soft_deny、hard_deny）が加わる構成です。筆者の環境で生成されたのはenvironmentのみで、組織の説明、リポジトリの公開範囲、シークレットの置き場所、本番環境の識別ルールなどが自然言語で列挙されていました。一部を汎用化して抜粋します。

{
  "autoMode": {
    "environment": [
      "**Repository visibility**: Private (ghで確認済み)",
      "**Secrets management**: リポジトリ直下の.env（gitignore済み）にAPIキーを保持",
      "**Source control**: 現在のリポジトリのoriginのみを信頼",
      "**Sensitive remote targets**: 名前にprodやproductionを含むリモート先はすべて要注意扱い",
      "**Primary use of Claude Code**: コンテンツ運用（記事の調査、執筆、入稿の自動化）"
    ]
  }
}

注目すべきは、単なる設定値の羅列ではなく「gh経由でPrivateと確認済み」「設定ファイル由来で実際の利用実績は未確認」のように、根拠と確度まで書き分けられている点です。分類器はこの記述を判断材料として読むため、確度の書き分けがそのまま判定の慎重さに反映されます。

なお、この設定を手書きする場合、allowやsoft_denyなどのルール配列は先頭に"$defaults"を置かないと、出荷時のルールを丸ごと置き換えてしまいます。 environmentは逆に"$defaults"を使わず、書かなかった項目には出荷時の文面がそのまま使われる仕様です。ウィザードの出力はこの決まりに沿って生成されるため、レビューの際に意識する必要はありません。

設定の確認と取り消し方法

保存された設定は、CLIのサブコマンドで確認できます。

claude auto-mode config     # デフォルトルールと合成した実効設定を表示
claude auto-mode defaults   # 出荷時ルールの全文を表示
claude auto-mode critique   # 自作のallow、soft_deny、hard_denyルールへのAIレビュー

取り消し方法は状況によって異なります。

状況	対処
スキャン実行中	`/tasks`でバックグラウンドタスク一覧を開いて停止
レビュー画面が表示された	Discard and exitを選ぶ（何も保存されない）
保存済みの設定を全部戻す	`claude auto-mode reset`（v2.1.212以降）
一部だけ直す	`~/.claude/settings.json`の`autoMode`を直接編集

claude auto-mode resetは実行時に確認プロンプトを出します（--yesで省略可）。注意点は二つあります。リセットが戻すのはautoModeセクションだけで、セットアップ時にpermissions.allowから削除したルールは復元されません。また、対象は~/.claude/settings.jsonのみで、組織の管理設定（managed settings）由来のautoModeには影響しません。

auto modeそのものをやめたい場合は別の操作です。セッション中はShift+Tabでモードを切り替えられ、恒久的に変えるなら設定のpermissions.defaultModeを使います。組織として無効化するなら、管理設定（managed settings）のpermissions.disableAutoModeを使います。

利用時の注意点

第一に、レビュー画面ではenvironmentの内容を必ず読むことを勧めます。自動生成の性質上、信頼すべきでない対象が信頼リストに混ざる可能性があります。たとえば顧客のリポジトリや共有バケットが信頼対象として書かれていると、そこへの操作が自動承認側に倒れます。レビューで確認すべきは「ここに書かれた範囲への操作は、確認なしで実行されてよいか」です。

第二に、pushやプルリクエスト作成の前に人間の確認を挟みたい場合、autoModeではなくpermissions.askを使います。公式ドキュメントによると、次の例のように操作内容まで指定したaskルールは分類器より先に評価され、auto modeでも必ずプロンプトを出します。

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

会話の中で「pushしないで」と伝える方法もありますが、長いセッションでは文脈の圧縮とともに指示が失われる可能性があるため、恒久的な境界には設定ファイルを使うほうが確実です。

第三に、分類器はClaude本体と同じCLAUDE.mdを読みます。プロジェクトのCLAUDE.mdに書いた制約は分類器の判断にも効くため、プロジェクト固有のルールはそちらに書く選択肢もあります。

最後に、繰り返しになりますが/auto-mode-setupはドキュメント未掲載の機能です。この記事の実行フローや画面構成はv2.1.233での確認結果であり、正式なアナウンスの際に変更される可能性があります。 auto mode本体の仕様は公式の設定リファレンスと権限モードのドキュメントで確認できます。

まとめ

/auto-mode-setupは環境設定の自動生成ウィザード：auto modeの分類器に渡すautoMode設定を、プロジェクトとセッション履歴の分析から下書きする
承諾するまで何も保存されない：レビュー画面でDiscardすれば設定は書き込まれず、保存後もclaude auto-mode resetで戻せる
スキャン範囲は自分で絞れる：シェル履歴のスキャンは既定オンのため、見せたくない情報がある場合は質問画面で対象を狭める
レビューの焦点は信頼範囲：environmentに信頼しすぎの記述がないかを確認し、pushの人間チェックが必要ならpermissions.askを併用する

auto modeを日常的に使うなら、分類器に環境を教える設定はいずれ必要になります。手書きするつもりだった方は、まずこのウィザードに下書きさせてレビューする流れを試す価値があります。