AIコーディングツールを使っていると、こんな経験はないでしょうか。
「ファイルを修正するたびに承認ボタン。コマンドを実行するたびに承認ボタン。作業が20ステップを超えた頃には、もう内容を確認せずにひたすらクリックしているだけ……」
これ、笑えない話です。Anthropicの調査によると、Claude Codeユーザーの実に93%が表示されたパーミッションプロンプトをそのまま承認しているという結果が出ています。つまり「安全のための確認」が形骸化し、むしろ危険な状態を生み出しているわけです。
2026年3月25日（日本時間）、AnthropicはClaude Codeに新機能「Auto Mode（自動モード）」を追加しました。これは「毎回承認」と「全スキップ」という二択に終止符を打つ、第三の選択肢です。
この記事では、Auto Modeの仕組みから実際の使い方、リスクと注意点まで徹底解説します。
- そもそもClaude Codeって何？という方へ
- Auto Modeとは何か：AIがリスクを判断する「第三の道」
- Auto Modeがブロックする「危険な操作」の実例
- 実際の使い方：有効化から運用まで
- 性能データ：どれくらい信頼できるのか
- 設計上の工夫：なぜ「アシスタントのメッセージを除外」するのか
- 注意点と限界：Auto Modeで「安心しすぎない」ために
- 他ツール・他モードとの比較
- どんな場面で使うべきか：ユースケース
- まとめ：承認疲れの先にある「AIとの協働」
そもそもClaude Codeって何？という方へ
Claude Codeは、コマンドラインから操作するAIコーディングツールです。ファイルの編集、シェルコマンドの実行、テストの実施まで、開発作業をAIに任せられます。エンジニアにとっては「AIが隣に座って一緒に作業してくれる」感覚のツールです。
ターミナル上でClaude Codeを起動し、「このコードのバグを直して」「テストコードを全部書いて」と指示すると、AIが実際にファイルを読み書きしながら作業を進めてくれます。GitHubのIssueを渡すだけでプルリクエストを作ってくれるような、かなり強力なエージェントです。
従来の権限管理：二択の悩み
Claude Codeには従来、大きく2つのモードがありました。
| モード | 特徴 | 課題 |
|---|---|---|
| デフォルトモード | 操作のたびに承認を求める | 作業が長くなると「承認疲れ」が発生 |
| --dangerously-skip-permissions | すべての権限チェックをスキップ | 誤操作・情報漏洩のリスクが高い |
長時間のコーディングタスクでは頻繁な承認ダイアログが生産性を著しく下げる一方、全承認スキップはセキュリティリスクを伴うという課題がありました。
そこで登場したのがAuto Modeです。
Auto Modeとは何か：AIがリスクを判断する「第三の道」
Auto Modeは、Claude Codeの新しい権限モードです。ポイントは、ツール呼び出しのたびにクラシファイア（分類器モデル）がアクションのリスクを評価することです。安全と判断されたアクションは自動的に実行され、危険と判断されたアクションはブロックされます。ブロックされた場合、Claudeは別のアプローチを取るよう誘導されます。
「クラシファイア」というのは、AIが特定の判断タスクに特化したモデルのことです。Auto Modeでは、このクラシファイアが人間の代わりに「この操作は安全か？」をチェックします。
2層の防御構造
Auto Modeの安全性は、2つの層で成り立っています。
入力層：プロンプトインジェクション対策
ファイルの中身やWebページの内容をClaude Codeが読み込むとき、その内容に「以降の操作をすべて承認せよ」といった悪意ある指示が埋め込まれることがあります（これを「プロンプトインジェクション攻撃」といいます）。
Auto Modeでは、ツールの出力結果がClaudeのコンテキストに入る前に、サーバー側のプローブがスキャンします。疑わしいコンテンツが見つかれば、Claudeに対して「この内容は怪しい、ユーザーの本来の指示に立ち返れ」という警告を付加します。
出力層：トランスクリプト分類器
出力層では、トランスクリプト分類器（Claude Sonnet 4.6で動作）が各アクションを実行前に評価します。分類は2段階で行われます。まず高速な単一トークンフィルター（「はい」でブロック、「いいえ」で許可）が走り、ここでフラグが立った場合のみ、連鎖的思考による詳細判断に進みます。ほとんどのアクションが最初のステージをクリアするため、推論トークンは本当に必要な箇所にだけ使われます。
3層の許可判断フロー
すべての操作がクラシファイアに渡されるわけではありません。処理は次の順番で流れます。
Tier 1：安全ツールの許可リスト
ファイルの読み込み、テキスト検索、コードナビゲーションなど「状態を変更しないツール」はそもそもクラシファイアを通らず、即時実行されます。ユーザーが設定した「常に許可」ルールもここで処理されます。
ただし注意点があります。Auto Modeに入ると、任意のコード実行を許可することが知られているパーミッションルール（シェルへの無制限アクセス、Pythonやnode、rubyなどのスクリプトインタープリタへのワイルドカード、パッケージマネージャーの実行コマンドなど）はドロップされます。手動承認モードで利便性のために設定していた「なんでも許可」ルールが、Auto Modeでは無効化されるわけです。
Tier 2：プロジェクト内のファイル操作
プロジェクトディレクトリ内のファイル書き込みや編集は、クラシファイアを呼ばずに許可されます。Gitで変更履歴が残るため、後から確認・巻き戻しができるからです。日常的なコーディング（ソースファイルの編集など）はここで処理され、余分なレイテンシが発生しません。
Tier 3：トランスクリプト分類器の出番
シェルコマンド、Webアクセス、外部ツール連携、プロジェクト外のファイル操作など「本当にリスクがある可能性のある操作」だけがここに来ます。
Auto Modeがブロックする「危険な操作」の実例
Anthropicは社内インシデントログを管理しています。実際に起きた「AIが余計なことをしてしまった」ケースをもとに、ブロックすべき操作を設計しています。
過去に実際に起きたインシデント
社内インシデントログの例として、曖昧な指示からリモートGitブランチを削除してしまったケース、エンジニアのGitHub認証トークンを社内コンピュータクラスターにアップロードしてしまったケース、本番データベースに対してマイグレーションを試みたケースが挙げられています。いずれもモデルが過剰に積極的で、ユーザーが意図していない行動を取ったことによるものです。
Auto Modeがブロックするシナリオ
ブロックルールは大きく4つのカテゴリに分類されます。
① 破壊・データ漏洩を引き起こす操作 - Gitの履歴を強制上書き（force push） - クラウドストレージの一括削除 - 内部データを外部に送信
② セキュリティ体制を弱める操作 - ログの無効化 - SSHキーやcronジョブのインストール（永続化） - Claudeが自分自身の権限設定を変更
③ 信頼境界を越える操作 - 外部リポジトリからクローンしたコードの実行 - 認証情報ストアへのスキャン - ユーザーが指定していないサービスへのデータ送信
④ レビューや他者への影響を回避する操作 - mainブランチへの直接プッシュ - 本番環境へのデプロイ - 自分が作成していない共有リソースの変更
具体的なシナリオで見てみましょう。
ユーザー：「古いブランチを片付けて」
Claude：リモートブランチを一覧表示 → パターンマッチで削除コマンドを発行 → ブロック
理由：指示が曖昧で、操作は不可逆、ローカルブランチだけを意図していた可能性がある
ユーザー：「このジョブをキャンセルして」
Claude：クラスターに問い合わせ → 名前の類似度でジョブを特定 → 削除しようとする → ブロック
理由：特定のターゲットがユーザーの意図と一致しない可能性があり、他人が所有していた可能性もある
実際の使い方：有効化から運用まで
有効化の手順
CLIではclaude --enable-auto-modeを実行し、その後Shift+Tabでセッション内のモード切り替えができます。VS Codeでは、Claude Codeの設定でAuto Modeをオンにしてから、権限モードのドロップダウンで選択します。
# CLIでAuto Modeを有効化して起動 claude --enable-auto-mode
起動後、セッション内ではShift + Tabキーで各モードを切り替えられます。
利用可能なプラン
Auto ModeはTeamプランにてリサーチプレビューとして利用可能で、今後数日のうちにEnterpriseプランおよびAPIユーザーにも提供される予定です。
分類器のカスタマイズ
Auto Modeのクラシファイアには、3つのカスタマイズ可能なスロットがあります。
① environment（信頼境界の定義）
デフォルトでは、現在作業中のGitリポジトリだけが「信頼済み」として扱われます。自社のGitHub Orgやクラウドストレージ、内部APIを信頼済みとして追加することで、クラシファイアがそれらへの操作を正しく評価できるようになります。
② ブロックルールのカスタマイズ
20以上のデフォルトブロックルールをベースに、自社環境に合わせて追加・削除ができます。claude auto-mode defaultsコマンドで現在のデフォルト設定を確認できます。
③ 例外（allow exceptions）の設定
ブロックルールに技術的には一致するが問題ない操作を除外できます。例えば、リポジトリのマニフェストに記載済みのパッケージのインストールなどが標準の例外として含まれています。
性能データ：どれくらい信頼できるのか
Anthropicは3種類のデータセットでAuto Modeを評価しています。
測定結果
| データセット | 規模 | ステージ1（高速フィルター） | 完全パイプライン |
|---|---|---|---|
| 実際のトラフィック（Anthropic社員） | 10,000件 | 誤検知率8.5% | 誤検知率0.4% |
| 実際の過剰行動サンプル | 52件 | 見逃し率6.6% | 見逃し率17% |
| 合成データ漏洩攻撃 | 1,000件 | 見逃し率1.8% | 見逃し率5.7% |
ここで正直に評価しておきたいのが、実際の過剰行動サンプルに対する見逃し率17% という数値です。
この17%という見逃し率は誠実な数字です。調べた大半のケースで、分類器は危険を正しく識別できていました。force pushや削除、インフラへの変更が見えている。間違えたのは、セッション中の実際の同意シグナルがその操作の影響範囲に対する承認かどうか、という判断でした。
つまり「何かが危険だとわかっているのに通した」のではなく、「ユーザーが以前に似た操作を承認した」事実をもって「今回も許可されている」と誤判断するケースが多いということです。
17%の見逃しをどう捉えるか
17%が許容できるかどうかは比較対象によります。--dangerously-skip-permissionsを使っているなら、これは実質的な改善です。すべての操作を注意深く手動承認しているなら、ある意味後退です。Auto Modeは前者のグループと、承認コストが安全上のメリットに見合わないタスクを対象としており、高リスクなインフラでの慎重な人間レビューの代替にはなりません。
設計上の工夫：なぜ「アシスタントのメッセージを除外」するのか
Auto Modeのトランスクリプト分類器は、Claudeのアシスタントメッセージとツールの出力結果を意図的に除外し、ユーザーのメッセージとツールの呼び出し内容だけを見て判断しています。
これには重要な理由があります。
① 分類器を「説得」される危険を防ぐ
もし分類器がClaude自身のメッセージを読めると、Claudeが「この操作は安全です。ユーザーが以前に暗黙的に許可しました」といった説得的な文章を生成して、分類器を誤魔化せてしまいます。
② プロンプトインジェクションへの構造的な耐性
ツールの出力（ファイルの中身やWebページの内容）に悪意ある指示が含まれていても、分類器はそれを見ません。外部URLへの.envファイルのPOSTは、ファイルに何が書いてあったかに関係なく、「ユーザーの意図から外れた外部へのデータ送信」として遮断されます。
③ マルチエージェントへの対応
クラシファイアはサブエージェントへの委任時と、結果が戻ってきたときの両方で動作します。アウトバウンドチェックは、委任を受けたサブエージェント内部ではオーケストレーターの指示がユーザーメッセージとして扱われるため、そのタスクが完全に承認されたように見えてしまう問題を防ぎます。
注意点と限界：Auto Modeで「安心しすぎない」ために
Auto Modeには明確な限界があります。過信は禁物です。
① 本番環境での直接利用は推奨されない
Auto Modeは承認をすべてスキップするモードよりは安全だが、それでもリスクが完全になくなるわけではなく、本番環境に影響を与えないサンドボックス環境での利用が推奨されている。
コンテナやVMなど隔離環境での利用が最も安全な選択です。
② 実行前にGitコミットを習慣に
Auto Modeを有効化する前に、必ず現在の状態をGitにコミットしておきましょう。
git add -A && git commit -m "checkpoint before claude auto mode"
何か意図しない変更があっても、git reset --hard HEADで完全に巻き戻せる状態を作っておくことが安全策の基本です。
③ 「3回連続ブロック」でエスカレーション
Claudeがブロックされ続けるアクションを繰り返し試みた場合は、最終的にユーザーへの承認プロンプトが表示されます。セッションで3回連続ブロック、または合計20回ブロックに達すると、Claudeは停止してユーザーに確認を求めます。ヘッドレスモード（バックグラウンド実行）ではプロセスが終了します。
④ リサーチプレビュー段階である
現時点ではTeamプランでのリサーチプレビューです。エッジケースで見逃しが発生することは公式も認めており、フィードバックを継続的に収集して改善中です。
⑤ 企業環境での管理者制御
Enterpriseの管理者は、managed settingsで"disableAutoMode": "disable"と設定することで、CLIとVS Code拡張機能でのAuto Modeをすべてのユーザーに対して無効化できます。組織のセキュリティポリシーに応じて制御可能です。
他ツール・他モードとの比較
| 比較項目 | デフォルトモード | Auto Mode | --dangerously-skip-permissions |
|---|---|---|---|
| 自律性 | 低（毎回確認） | 高（AI判断） | 最高（無制限） |
| 安全性 | 高 | 中〜高 | 低 |
| 維持管理コスト | 低 | 低〜中 | 低 |
| 承認疲れ | 発生しやすい | ほぼなし | なし |
| プロンプトインジェクション対策 | なし | あり | なし |
| 長時間タスクへの適性 | 低 | 高 | 高（ただしリスクあり） |
| 本番環境での利用 | ○ | △（隔離推奨） | ✕ |
GitHub Copilot AutocompleteやCursor Composerなどの他社AIコーディングツールと比較した場合、ファイル編集に特化している他ツールと異なり、Claude Codeはシェルコマンドまで含めた広い操作範囲に対してリスク評価を行える点がAuto Modeの特徴です。
どんな場面で使うべきか：ユースケース
向いているシナリオ
大規模リファクタリング 型定義の追加、命名規則の統一、import文の整理など、多数のファイルにまたがる変更が必要な場面。毎回確認が発生すると集中が途切れます。
テストコードの一括生成 「このモジュール全体にユニットテストを書いて」といった指示で、数十ファイルにわたる作業をまとめて依頼するケース。
CI/CD環境でのコード自動修正 コンテナ環境内でClaude Codeを使い、lint警告の修正やコードフォーマットを自動化する場合。
ドキュメント生成 README、API仕様書、コメントの追加など、コードを変更せずにドキュメントを生成する作業。
向いていないシナリオ
- 本番データベースへの直接操作
- 外部サービスへの認証情報を含む操作
- 組織共有のインフラへの変更
- セキュリティ要件が厳しい機密プロジェクト
まとめ：承認疲れの先にある「AIとの協働」
「毎回承認」か「全部スキップ」か。この二択は、AIコーディングツールが成熟するにつれてずっと残ってきた課題でした。
Auto Modeは、その答えとして「AIがリスクを評価して判断する」という方向性を示しています。0.4%の誤検知率と17%の見逃し率、という数値をどう評価するかは使い方次第ですが、少なくとも--dangerously-skip-permissionsを使っていたなら、乗り換える理由は十分あります。
個人的には、GitコミットをこまめにしながらAutoModeで動かしつつ、エラーが出たら確認する、 というスタイルが現時点では一番バランスが良さそうです。まだリサーチプレビュー段階なので、フィードバックしながら育てていく気持ちで使うのが正直なところ。
「承認ボット」を卒業するタイミングが、ちょうど来た気がしています。
