Claude Code オートモード
2つ目の Sonnet モデルが、Claude Code のすべてのツール呼び出しを実行前に審査します。オートモードがブロックするもの・許可するもの、そして settings.json に追加される許可ルールについて解説します。
設定をやめて、構築を始めよう。
AIオーケストレーション付きSaaSビルダーテンプレート。
問題: Claude Code ユーザーは皆、許可プロンプトに疲れ果てます。リファクタリングの3ファイル目に差し掛かったとき、Claude が npm test を必要として、作業の前にモーダルが表示されます。承認。ファイルの読み取り。承認。マイグレーションの書き込み。承認。30回ものプロンプトの後には、もう内容を読んでいません。ただクリックしているだけです。
もうひとつの選択肢は --dangerously-skip-permissions でした。このフラグはすべての安全策を外します。コンテナの中なら問題ありません。しかし SSH キーや .env ファイル、git の認証情報が置かれたラップトップ上では、まともな大人が選ぶべきではありません。
オートモードはその中間の道です。2026年3月24日にリリースされ、バックグラウンドで2つ目の AI を動かすことで機能します。Claude が行おうとするすべてのツール呼び出しが事前に検査されます。リスクの高い呼び出しはブロックされ、その理由が Claude に返されます。安全な呼び出しはプロンプトなしで実行されます。審査役がファイルシステムと Claude の間に立ち、あなたがクリックするより速く判断を下します。
オートモードの実態
オートモードは新しい権限モードです。default(すべてを自分で確認)と bypassPermissions(何も確認されない)の間に位置します。有効にすると Claude はプロンプトの表示を止めます。各ツール呼び出しが実際に実行される前に、別の分類モデルがその時点までの会話と待機中のアクションを確認し、通過かブロックかを判断します。
判断は3つのリスクカテゴリに基づきます:
- スコープ拡大: そのアクションはあなたが実際に依頼した範囲を超えていないか?
- 信頼できないインフラ: 対象は分類器が信頼する理由を持つものか?
- プロンプトインジェクション: そのアクションは Claude がファイルやウェブページで読んだ悪意あるコンテンツに由来しているように見えないか?
通過なら実行されます。ブロックなら Claude に理由が返され、別のアプローチを試みます。あなたの手はキーボードに置かれたままです。審査役が見張り続けます。
分類器の仕組み
すべての分類器の呼び出しは、セッションがどのモデルを使っていても Claude Sonnet 4.6 で実行されます。入力はあなたのユーザーメッセージと待機中のツール呼び出しです。Claude 自身の文章と前のツール結果は意図的に除外されます。ツールの出力が分類器のコンテキストに入らないため、ファイルやページの中の悪意ある内容が判断に影響を与えることができません。
CLAUDE.md は通過します。プロジェクトのルールが分類器の受け入れ・拒否に影響します。静的な許可・拒否リストはツール名と引数を grep のようにマッチします。分類器は文章を読んで意図を推論するため、パターンマッチングでは対応できないケースも扱えます。
評価の順序
各ツール呼び出しは固定の手順を踏みます。最初のマッチが適用されます:
| ステップ | チェック | 結果 |
|---|---|---|
| 1 | 許可・拒否ルールにマッチ | 即座に解決 |
| 2 | 読み取り専用のアクションまたは作業ディレクトリ内のファイル編集 | 自動承認 |
| 3 | それ以外のすべて | 分類器へ |
| 4 | 分類器がブロック | Claude が代替アプローチで再試行 |
settings.json のルールは引き続き先に実行されます。許可リストに Bash(npm test) があれば、分類器が起動する前に実行されます。拒否リストの Bash(rm -rf *) は分類器が見る前に停止されます。
広範な許可ルールは削除される
ほとんどの人が見落とすポイントです: オートモードに切り替えた瞬間、Claude Code は任意の実行を許可する広範な許可ルールを削除します。Bash(*)、Bash(python*)、Bash(node*)、そしてすべての Agent 許可ルールは、オートモードの有効期間中に除去されます。
理由は明快です。Bash(*) が生きていたら、最も危険なコマンドが分類器を通ることなく自動承認されてしまいます。機能全体が無意味になります。
細かいルールはそのまま残ります。Bash(git status) や Bash(npm test) は引き継がれます。削除されたルールはオートモードを終了したときに戻ります。
ブロックされるものと許可されるもの
分類器がシステムを見る際に信頼境界が存在します。ローカルの作業ディレクトリは信頼されます。git リポジトリ内にいる場合、そのリポジトリに設定されたリモートは信頼されます。その境界の外にあるものは、管理者が設定しない限り外部とみなされます。
デフォルトでブロックされるもの
| カテゴリ | 例 |
|---|---|
| リモートコード実行 | `curl |
| データ漏洩 | 外部エンドポイントへの機密データ送信 |
| 本番環境の操作 | デプロイ、マイグレーション、データベース操作 |
| 大規模削除 | クラウドストレージの一括削除、既存ファイルへの rm -rf |
| 権限昇格 | IAM またはリポジトリ権限の付与 |
| インフラ変更 | 共有インフラの変更 |
| 破壊的な git 操作 | フォースプッシュ、main への直接プッシュ |
デフォルトで許可されるもの
| カテゴリ | 例 |
|---|---|
| ローカルファイル操作 | 作業ディレクトリ内のファイルの読み取り・書き込み・編集 |
| 宣言済みの依存関係 | ロックファイルまたはマニフェストに既にある依存関係のインストール |
| 認証情報の使用 | .env の読み取りと対応する API への認証情報送信 |
| 読み取り専用ネットワーク | HTTP GET リクエスト、ドキュメントの取得 |
| ブランチ操作 | 現在のブランチまたは Claude が作成したブランチへのプッシュ |
分類器が読むデフォルトのルールセット全体を確認するには:
claude auto-mode defaults
通常のチームの作業が分類器に引っかかることがあります。組織のリポジトリへのプッシュ、会社のバケットへの書き込み。分類器にはそれらがあなたのものだとわかりません。管理者は autoMode.environment 設定で信頼するインフラを設定することで解決できます。
オートモードを有効にする方法
前提条件
3つの条件が必要です:
- Claude Code Team プラン(Enterprise と API は間もなく対応)
- Claude Sonnet 4.6 または Claude Opus 4.6(Haiku、claude-3 モデル、Bedrock や Vertex などのサードパーティプロバイダーでは利用不可)
- 管理者による有効化: ユーザーが有効にする前に、管理者が Claude Code の管理設定でオートモードを有効にする必要があります
CLI
オートモードに移行できるセッションを起動します:
claude --enable-auto-mode
Shift+Tab でモードを切り替えられます: default → acceptEdits → plan → auto。現在のモードはステータスバーに表示されます。
または起動時に直接指定します:
claude --permission-mode auto
VS Code
- Claude Code 拡張機能の設定を開く
- Allow dangerously skip permissions を有効にする(これで UI のオートモードがアンロックされます)
- プロンプトボックス下部のモードインジケーターをクリック
- ドロップダウンから Auto を選択
デスクトップアプリ
- デスクトップの設定でオートモードを有効にする
- 送信ボタン横のモードセレクターを使う
- ドロップダウンから Auto を選択
デスクトップはオートモードがオフの状態で出荷されています。設定で有効にしてから選択肢に現れます。
非インタラクティブモード
スクリプト実行は -p フラグで問題なく動作します:
claude -p "refactor the auth module" --permission-mode auto
注意点があります。フォールバックが発動した場合(後述)、非インタラクティブセッションは終了します。プロンプトに答えるキーボードの前に誰もいません。
オートモード下のサブエージェント
エージェントループやマルチエージェント構成を運用しているチームは、これがサブエージェントにどう流れるかを知る必要があります。3つのチェックポイントがあります:
起動時: サブエージェントが始まる前に、分類器がその委任されたタスクの説明を読みます。「このパターンに一致するリモートブランチをすべて削除する」は入り口で拒否されます。サブエージェントは実行されません。
実行中: 子セッション内では、オートモードが親と同じ許可・ブロックルールを適用します。サブエージェントが自身のフロントマターで設定した permissionMode は無視されます。すべてのツール呼び出しは個別に分類器を通ります。
返却時: サブエージェントが終了すると、分類器がその完全なアクションログを読みます。起動時には問題なく見えた子が、読んだ内容によって途中で乗っ取られた可能性があります。返却時のパスで問題が検出されると、サブエージェントの出力の先頭にセキュリティ警告が付加され、親が対応できるようになります。
3つのチェックポイントにより、サブエージェントを盲目的に信頼する必要はありません。分類器はメインセッションと同じ方法でサブエージェントを扱います。
他のモードとの比較
Claude Code が用意するすべての権限モードの全体像です:
default | acceptEdits | plan | auto | dontAsk | bypassPermissions | |
|---|---|---|---|---|---|---|
| 権限プロンプト | ファイル編集とコマンド | コマンドのみ | default と同じ | なし(フォールバック時を除く) | なし(事前許可されたもの以外はブロック) | なし |
| 安全性チェック | 各アクションを自分で確認 | コマンドを自分で確認 | コマンドを自分で確認 | 分類器がコマンドを確認 | 事前承認ルールのみ | なし |
| トークン使用 | 標準 | 標準 | 標準 | 高め(分類器の呼び出し) | 標準 | 標準 |
| 最適な用途 | 慎重な作業 | コードのイテレーション | コードベースの探索 | 長時間タスク | CI/CD パイプライン | 隔離されたコンテナのみ |
| リスクレベル | 最低 | 低 | 低 | 中 | ルール次第 | 最高 |
トレードオフは単純です。確認済みのアクションごとにトークンを多く使い、少し時間がかかります。長いセッションをクリック作業に変えてしまうプロンプトの流れがなくなります。
使うべき場面
向いている場面:
- 承認の連続が集中を妨げる長いタスク
- 全体的な方向性は信頼できるが、粗い部分に安全網が欲しいとき
- 人間がすべての手順を確認できないエージェントループ
- コンテナ外で
bypassPermissionsより安全な選択肢が欲しいとき
向いていない場面:
- 本番インフラが対象のとき(このモードはそうしたアクションをブロックします)
- すべての手順を確認したい不慣れなコード
- 確定的で監査可能なコントロールが重要なとき(明示的な許可ルールを持つ
dontAskを使いましょう) - コストが制限されているとき(分類器の呼び出しはトークンを消費します)
フォールバック
誤検知でセッションが台無しにならないよう、フォールバックがそれを捉えます。1つのセッション内で分類器が連続3回または合計20回ブロックすると、オートモードが一時停止し、Claude Code が手動での承認に戻ります。
どちらのしきい値も調整できません。
発動した場合:
- CLI: ステータスエリアにメモが表示されます。次の手動プロンプトを承認するとブロックカウンターがリセットされ、その後もオートモードを維持できます。
- 非インタラクティブモード(
-pフラグ): セッションが終了します。誰も答えられません。
繰り返しのブロックには2つの原因があります。タスクが分類器が止めるよう設計されたものを本当に要求しているか、または実際に所有しているインフラについて分類器にコンテキストが不足しているかです。誤検知と感じたら /feedback を使いましょう。自分のリポジトリやサービスが信頼されているはずなのに繰り返し見逃される場合は、管理者に管理設定で信頼するインフラを設定してもらいましょう。
多層防御
1つの層だけで全体を守ることはできません。オートモードは bypassPermissions より多くの保護を提供し、すべての呼び出しを手動で確認するよりは少ない保護です。最も強力な構成はこれらを重ねます:
第1層: 権限ルール。 settings.json の許可・拒否リストが分類器の前に解決されます。特定のツールに対する確実な制御に使いましょう。
第2層: オートモード分類器。 ルールが対応していないすべてを捉えます。テキストパターンではなくコンテキストについて推論します。
第3層: フック。 PreToolUse フックが権限システムより前にカスタムロジックを実行します。Permission Hook は LLM を使った自動承認ツールで、3段階のフロー(高速承認・高速拒否・LLM 分析)を持ちます。フックとオートモードは共存します: フックが先に実行され、分類器が確認する前に承認・拒否・エスカレートできます。
第4層: サンドボックス化。 OS レベルのサンドボックスがカーネルでファイルシステムとネットワークアクセスを遮断します。分類器が見逃した場合でも、サンドボックスがシェルコマンドを指定した範囲内に閉じ込めます。分類器が意図を読む一方で、サンドボックスは固い壁を強制するため、これは重要です。
第5層: 自己検証エージェントとストップフック。 エージェントをタスクと対象範囲内に保ち、権限の仕組みの上にさらなる検証を追加します。
各層が他の層の隙間を埋めます。それが多層防御です。
知っておくべき制限事項
これはリサーチプレビューとしてリリースされました。その言葉の意味に正直でいましょう:
- 安全性の保証はありません。 曖昧なユーザーの意図や環境コンテキストの不足により、分類器がリスクのあるアクションを見逃すことがあります。逆(無害なものの誤検知)も起こります。
- コストが上がります。 分類器の呼び出しはトークン使用量にカウントされます。確認済みのアクションごとに会話の一部と待機中の呼び出しが送信されます。読み取り専用アクションとローカルファイル編集は分類器を完全にスキップするため、追加コストの大半はシェルコマンドとネットワーク操作から来ます。
- レイテンシは現実です。 各チェックでアクションが実行される前に往復が追加されます。高速なシェルコマンドの連続は遅く感じられます。
- 対応範囲が狭い。 現在は Team プランのみ(リサーチプレビュー)。Enterprise と API サポートは間もなく展開予定。Sonnet 4.6 または Opus 4.6 が必要。Haiku 非対応、claude-3 非対応、サードパーティプロバイダー非対応。
- 慎重な操作のレビューの代替にはなりません。 方向性が明確な作業で信頼しましょう。本番、認証情報、共有インフラに関わるものは、人間のレビューが正しい選択です。
データによってキャリブレーションが改善されます。誤検知や見逃したブロックを報告するのが /feedback です。そうした報告のひとつひとつがシステムを調整します。
次のステップ
Team プランのユーザーは、これによって新しい日常ワークフローを得られます。安全性とスピードの古いトレードオフに、3つ目の選択肢が生まれました。
オートモードを中心とした完全なセキュリティ体制のために:
- 特定のツールの確定的なコントロールのために権限ルールを書く
- 分類器が対応していないカスタム権限ロジックのためにフックを設定する
- 固い安全網として OS レベルの強制のためにサンドボックス化を有効にする
- 権限に関連するすべてのオプションのための設定リファレンスを読む
- 長時間の実行でプロンプトの削減を最大限に活用するための自律エージェントループを探る
権限プロンプトはもはやボトルネックではありません。分類器が対応します。構築に戻りましょう。
設定をやめて、構築を始めよう。
AIオーケストレーション付きSaaSビルダーテンプレート。