まずは安全な作業からAuto Modeを使ってみて効率を上げよう

Posted at 2026-09-20

こんにちは、ダックスフントです。

Claude Codeをデフォルトの設定（都度承認を求めるモード）で使っていると、エージェントがファイル編集やシェル実行する直前に、毎回ユーザへの承認を求めてきます。最初はちゃんと1件ずつ目を通して承認していたのですが、正直なところ確認の回数が多すぎて、途中から惰性で「はい」を押すだけになっていました。さらに困ったのは、エージェントに依頼した後バックグラウンドで作業が進んでいるつもりで別のことをしていたら、実は承認待ちで止まっていた、ということが何度もあった点です。

そんな中、2026年8月からClaude CodeのPro/Max/Teamプランで「auto mode（危険と判断した操作だけ承認を求め、それ以外は基本的に自動実行してくれるモード）」がデフォルトの承認設定になりました。エンタープライズプランでも「auto modeに切り替えましょうか？」という案内を見る機会が増え、VS Code拡張機能のチャット欄でも同様の表示を目にするようになっています。試しに、ブログ執筆やOpenSpecのchangeの計画作成といった、危険な操作を伴わない安全な作業でauto modeを使ってみたところ、驚くほど作業がスムーズになりました。

そこで今回は、auto modeがどういう仕組みで動いているのか、何を自動でやってくれて何を止めてくれるのかを調査してみました。あわせて、本番リリースやgit操作のようにauto modeが不向きな作業も整理しています。まずは身近な安全な作業からauto modeを試してみる、そのきっかけになればと思っています。

TL;DR

都度承認の権限モードはユーザへの確認回数が多く、惰性の「はい」や「気づいたら止まっていた」を招きやすい
ブログ執筆やOpenSpecのchange計画作成のような安全な作業からauto modeを使い始めたところ、作業効率が格段に上がった
auto modeは「何でも自動でやる」モードではなく、classifier（分類器）という別のAIモデルが行動の危険性を判定してから実行する仕組み
Anthropic公式・第三者機関の検証では、安全な操作の判断精度は人間とほぼ同等だが、危険な操作の検知精度は検証によって結果が分かれており（人間より高精度という結果もあれば、見逃しや突破が確認された例もある）、万全ではない
本番環境へのデプロイや元に戻せないgit操作、機密情報を扱う操作などは、影響が大きく取り返しがつかないため、auto mode単体での使用は不向き。ハーネスエンジニアリングやセキュリティ境界など多重の対策と組み合わせる必要がある
GitHub Copilotにも似た自動承認モードがあり、「Assisted permissions」（VS Code・preview）においてもAIによるチェックを行う。用語が似ている「Autopilot」は全ての承認を求めないモードなので注意
まずは安全な作業から使ってみて、自分なりに判断していくのが良い

1. 自分がauto modeを使い始めたきっかけ
2. auto modeとはどんな仕組みか
3. 具体的にどんな操作がブロックされたり許可されるのか
4. auto modeの検知性能について（Anthropic公式の検証結果）
5. 第三者機関・研究者による検証結果
6. auto modeが不向きな作業
7. 補足：GitHub Copilotにも似た機能がある
8. まずは安全な作業から、auto modeを始めてみませんか

1. 自分がauto modeを使い始めたきっかけ

都度承認モード（Manualモード）でClaude Codeを使っていると、ファイル編集やシェル実行のたびに確認画面が出ます。単純な操作なら数秒で済みますが、複雑なshellコマンドが提示されたときは、それが本当に安全かどうかを見極めるのに意外と時間がかかります。これが1セッションの中で何十回も繰り返されると、だんだん確認の意味が薄れてきます。最初のうちは差分をちゃんと読んでから承認していたはずなのに、途中から「たぶん大丈夫だろう」で反射的に「はい」を押すようになっていました。

さらに厄介だったのは、承認待ちで止まっていることに気づかないパターンです。長めのタスクを投げてバックグラウンドで進んでいるはずだと思い込み、別の作業に移っていたら、実は最初の方の操作で承認待ちのまま止まっていた、ということが何度かありました。

そんな中、Claude CodeのPro/Max/Teamプランで「auto mode」がデフォルトの権限設定になりました。この流れを受けて、エンタープライズプランのClaude Codeでも、CLIで承認を求められる際に「Yes, and switch to auto mode」というauto modeへの切り替え選択肢が表示されるようになっています。

また、VS Code拡張機能のチャット欄においても、auto modeの案内が表示されたりするようになりました。

このような流れを受けて、自分もauto modeを試してみたくなりました。ただ、いきなり大胆な作業で使うのは不安だったので、まずは確実に安全で限定的な作業だと思えるブログ執筆やOpenSpecのchange計画作成から試してみることにしました。
実際に使用してみると、ブログ執筆において今までの承認モードでは、下書きの修正やファイルの整理といった細かい編集のたびに承認のやり取りが何往復も発生し、テンポが悪かったです。auto modeにしてからは確認待ちで手を止められることがほとんどなくなり、書きながら考えるという作業のリズムが崩れなくなりました。OpenSpecのchange作業でも、ファイルの読み書きを繰り返す場面で確認のたびに思考が中断されたり、待ち時間が発生することがなくなり、はっきり効率が上がったと感じています。

ただし、今も自分はauto modeを全面的に信頼しているわけではありません。危険性も踏まえて、「危険な操作が絡む作業には使わず、安全で限定的な作業だけに使う」ようにしています。auto modeが不向きな作業については、6章で具体的に整理します。

2. auto modeとはどんな仕組みか

「auto mode」はAnthropicが定義した権限モードの一つです。auto modeの使用に関する追加料金は発生しません。名前の響きだけ見ると似ている従来のモード--dangerously-skip-permissions（bypassPermissionsモード）もありますが、こちらはどんな操作でも一切確認を求めない仕組みで、挙動は全く別物であるため、注意が必要です。
また、GitHub Copilotの「Assisted permissions」やCursorの「Auto-Run」（旧YOLO mode）のように、他社にも似た機能はありますが、用語の定義や仕組みは製品ごとに異なるので、こちらも注意が必要です。

Claude Codeの権限モードは、全部で6種類あります（詳細は公式ドキュメント「Choose a permission mode」を参照）。

モード	確認なしで実行される範囲	用途
`default`（CLIでの表示上はManual）	読み取りのみ	1件ずつ確認したい・機密性の高い作業
`acceptEdits`	読み取り＋ファイル編集＋基本的なコマンド	レビュー前提でコードを反復編集
`plan`	読み取り＋（auto mode利用可能なら）classifier承認済みコマンド	変更前にコードベースを調査
`auto`	全部（安全性チェック付き）	長時間タスク・確認疲れの軽減
`dontAsk`	事前承認済みツールのみ	ロックダウンされたCI・スクリプト
`bypassPermissions`	全部（チェックなし）	隔離されたコンテナ・VM限定、auto modeが発表されてからは基本的にauto modeの方が推奨

従来のdefaultでは、エージェントの行動（ファイル編集・シェル実行・ネットワークアクセスなど）をユーザーが逐次チェックする必要がありましたが、auto modeでは、classifier（分類器）と呼ばれる別の専用AIモデルが、エージェントの行動をユーザーの代わりにチェックする仕組みになっています。classifierは毎回使われるわけではありません。実際には、以下の3段階の判定があり、classifierはその3番目として呼ばれます。

1. Claude Codeに組み込まれている固定のツール許可リストとユーザー設定によるチェック

Claude Codeに標準で組み込まれている固定のツール許可リストでチェック（ファイルの検索や読み取りなどが許可されている）
ユーザーが設定したsettings.jsonなどのツール許可リストでチェック

2. 操作対象のファイルがプロジェクト内かどうかのチェック

プロジェクト内のファイルであれば、ファイルの書き込みと編集はclassifierを呼び出すことなく許可される

3. classifierを使用したチェック

エージェントが読むものに、動作を乗っ取る指示が含まれていないかをチェック
エージェントが取ろうとしている行動について、「ユーザーの発話内容」と「ツール呼び出しコマンド」を元にチェック

auto modeの内部の仕組みも紹介します（詳細は公式ドキュメント「How we built Claude Code auto mode: a safer way to skip permissions」を参照）。
auto modeは内部で2階層のチェックをしています。

1階層目：エージェントが読むものに対する防御

エージェントが読み取るコンテンツ（ファイルやWeb、シェルの出力など）に対するプロンプトインジェクション対策
コンテンツの中に動作を乗っ取ろうとする指示が含まれている可能性がある場合、エージェントに「疑わしいものとして扱い、ユーザーから実際に要求した内容に焦点を当てるように」と指示する
ただし、コンテンツ自体がブロックされるわけではないので、そこは注意が必要

2階層目：エージェントが行うことに対する防御

transcript classifier（分類器）で、エージェントが実際に取ろうとしている行動そのものをチェック
この分類器は2段階構成になっていて、まず単純なトークンフィルタで高速に判定する。フィルタに該当しなければ「yes」でそのまま許可、該当してさらに判断が必要な場合は「no」として2段階目の推論トークンを使った推論で本当にブロックすべきか判断する
少量の推論トークンが発生するが、その推論トークンに対するユーザへの課金は発生しない
classifierが判断する際、「エージェントの発話内容」は使わず、「ユーザーの発話内容」と「ツール呼び出しコマンド」だけを使用。これにより、エージェントが仮に「ユーザーが過去に承認した安全な行動です」のような説得力のある発言を生成してしまっても、classifierの判断を誤らせないようにしている

auto modeは、Claude Codeの様々な利用形態に対応しています。CLI（ターミナル）から実行する場合はもちろん、VS Code拡張機能、JetBrainsプラグイン、Claude Desktopアプリから使う場合でも利用できます。切り替え方法は利用形態ごとに少し違いますが、どれも簡単です。CLIではShift+Tabで切り替えられます。VS Code拡張機能やClaude Desktopアプリは、プロンプト入力欄下部のUIから切り替えられます。

他のClaude製品であるCoworkにも権限モードがありますが、こちらはClaude Codeとは異なる独自の権限モード体系を持っていて、Claude Codeのclassifierとは別物が採用されている可能性が高いです。

3. 具体的にどんな操作がブロックされたり許可されるのか

auto modeのclassifierが許可したりブロックする操作の例は、公式ドキュメントに掲載されています。アップデートのたびに検知対象の例が増えているので、classifierも継続的に更新され続けていることが分かります。今回紹介するのは代表的な例なので、詳細や他の例も確認したい場合は、公式ドキュメント（https://code.claude.com/docs/en/permission-modes#what-the-classifier-blocks-by-default）をご参照ください。
デフォルトでブロックされる操作の例

curl | bashのようなコードのダウンロード＆実行
機密データの外部エンドポイントへの送信
本番環境へのデプロイやマイグレーション
git reset --hardやgit clean -fdのような未コミットの変更を破棄するコマンド
force pushやレビューなしのPRマージ
terraform destroyのようなインフラ破壊コマンド
認証情報の出力

デフォルトで許可される操作の例

作業ディレクトリ内のローカルファイル操作
ロックファイルに記載済みの依存関係インストール
読み取り専用のHTTPリクエスト

classifierの特徴として、「ユーザーの発話」も判断基準に含まれるという点があります。会話中に「pushしないで」「レビューするまでデプロイを待って」とユーザーが言うと、classifierはそれをブロック基準として扱い、デフォルトのルールでは許可されている行為でも会話上の指示を優先してブロックしてくれます。ただし、これは永続的な判断基準として保存されるわけではありません。コンテキストが圧縮されたり、セッションがクリアされて過去の発言が消えてしまうと、そこまで積み上げてきた判断基準も一緒に失われてしまいます。永続的な判断基準として加えたい場合は、CLAUDE.mdなどに記載しておいたほうが良いと考えます。

4. auto modeの検知性能について（Anthropic公式の検証結果）

ここでは、auto modeの性能（危険な操作をどれだけ検知できるか）について、公開されているいくつかの検証結果を紹介します。最初に紹介するのは、Anthropicが公開している2種類の検証結果です。

検証1. Anthropic社の従業員と合成データを対象とした検証結果

2026年5月に公開された検証結果では、3種類のデータセットに対して、以下のような偽陽性率（分類器が誤って安全な行動をブロックしてしまう割合）と偽陰性率（分類器が誤って危険な行動を通過させてしまう割合）が得られています。
結果の詳細は公式サイト（https://www.anthropic.com/engineering/claude-code-auto-mode）をご参照ください。

Anthropic社の従業員によるClaude Codeツールの実際の呼び出し履歴（10,000件）での結果

トークンフィルタのみ：偽陽性率8.5%
トークンフィルタ＋classifier：偽陽性率0.4%
従業員が許可したツール呼び出しとほぼ同じ精度（誤ってブロックしたのは0.4%のみ）でツール呼び出しできることが分かります

従業員が実際に承認しなかったツール呼び出しの履歴（52件）での結果

トークンフィルタのみ：偽陰性率6.6%
トークンフィルタ＋classifier：偽陰性率17%
- 推論を行うclassifierを組み合わせることで、むしろ悪化（危険な行動を許可しやすくなってしまう）する結果です
つまり、危険な行動に対しては人間と同じ精度で判断できておらず、17%の危険な行動を見逃してしまう恐れがあることが分かります
- 毎回慎重に確認したうえで承認しているようなケースでは、auto modeを適用することで、むしろ危険な行動を許可してしまうリスクがあります

危険なツール呼び出し（機密データの外部送信やgit pushなど）を想定した合成データ（1,000件）での結果

トークンフィルタのみ：偽陰性率1.8%
トークンフィルタ＋classifier：偽陰性率5.7%
- こちらも推論classifierを組み合わせることで、むしろ悪化する結果です
人間がチェックした場合の偽陰性率は測定されていないようです。手間がかかり集中力も要る作業のため、人間による評価自体が難しかったのではないかと考えられます。

この結果を踏まえてAnthropicは、「慎重に毎回人間がレビューしていたようなリスクの高い作業において、auto modeは人間の判断を単純に置き換えるものではない」と述べています。ただし、この検証は2026年5月時点のもので、毎回人間側が全力で確認する前提の条件だったこともあり、あまり良い結果にはなりませんでした。その後もclassifierは継続的に更新されているようで、次に紹介する2026年8月時点の検証では、また違った結果が出ています。

検証2. Claudeの有料ユーザーを対象とした検証結果

こちらは、auto modeのデフォルト化を発表した2026年8月公表のブログ（https://claude.com/blog/auto-mode-default-in-claude-code）に示されている、有料テスター1,053人を対象にした比較実験の結果です。テスターには事前に検証内容を伝えず、調査専用のテスト環境の中で、承認を求める場面にあえて明らかに危険なコマンドを混ぜておき、それをブロックできるかどうかを測定しています。

人間によるチェックで気づけた危険な行動の割合：13.6%
- セッションが長くなるにつれて、見逃しが多くなる
  - 最初の方に出現した場合は17%の割合でブロックできたが、50回以上の承認作業を行うと約5%まで低下した
auto modeで検知できた割合：89%
- 人間に比べて、セッションの長さに関係なく、一定の精度を維持できた

この検証を踏まえてAnthropicは、「人間によるレビューは負荷が掛かるほど重要なものを見落としやすくなるが、auto modeはセッションの長さに関係なく一貫して、人間よりも高い精度で危険な行動を検知できる」と述べています。この結果を踏まえて、Adobe、Nuro、Gusto、Garner Healthといった企業では、本番環境にもauto modeを採用しているようです。

5. 第三者機関・研究者による検証結果

Anthropic公式の検証だけでなく、第三者機関やセキュリティ研究者が独自に検証した結果も公開されています。

検証1. Trajectory Labsによる評価

第三者評価機関のTrajectory Labsが、Anthropicの委託で実施した評価です。詳細はauto modeのデフォルト化発表ブログ（https://claude.com/blog/auto-mode-default-in-claude-code）で紹介されています。

間接プロンプトインジェクション攻撃の検証結果

72種類の間接プロンプトインジェクション攻撃シナリオを、各10回・合計720回試行
- 機密データの漏洩、金融詐欺、認証情報のフィッシングなど、ユーザーに損害を与える可能性のある取り返しのつかないケースを想定
auto modeにおける攻撃成功率：0.00%
- Claude Fable 5、Opus 5、Sonnet 5のいずれのモデルを使用中でも、すべての攻撃を防ぐことができました
- 類似製品のCodexのAuto-reviewモードでは、GPT-5.6 Solを使用中に、5.83%の攻撃が成功してしまいました

検証2. セキュリティ研究者による検証

セキュリティ研究者のJohann Rehberger氏（embracethered.com）は、2026年8月に公開した検証記事（https://embracethered.com/blog/posts/2026/breaking-claude-code-opus-5-and-automode/）で、単純なWebサイトの要約リクエストから始まる攻撃チェーンによって、Opus 5使用中のauto modeにおいて、60〜80%の確率で突破できたと報告しています。

攻撃の流れ

ユーザーが「このWebサイトを要約して」と依頼するだけの、ごく普通のやり取りから始まる
攻撃者のサーバーがHTTP 415エラーを返すことで、ClaudeがWebFetchツールからcurlコマンドの直接実行に切り替わるよう誘導される（攻撃者側は何も指示していないのに、Claudeが自分でその経路を選んでしまう）
curlコマンドでダウンロードしたZIPアーカイブには、怪しいバイナリと、正体を隠した悪意のあるPythonファイルstruct.pyが同梱されている
Claudeはこのバイナリの実行は正しく拒否するが、「安全のため」自分でPythonのデコーダー（zip内のPythonファイルを復元する処理）を書いて実行しようとする
そのスクリプトを展開済みのZIPディレクトリ内で実行するため、正体を隠していた悪意のあるPythonファイルが実行されてしまう（モジュールシャドーイングと呼ばれる手口）
この瞬間に外部からペイロードがダウンロード・実行され、C2（Command and Control）通信が確立されてしまう

この攻撃が成立するのは、auto modeが「外部から渡されたコードは警戒するが、Claude自身が生成したコードは信用してしまう」という、classifierではカバーしきれない穴を突いているためです。Anthropicはこの報告を受けて、「auto modeはベストエフォート型のclassifierに支えられた便利機能であり、セキュリティ保証ではない。本当にセキュリティを担保したい場合は、OSレベルの分離とネットワーク制御が必要である」と回答しています。

また、Anthropicと第三者の両者の検証結果を踏まえると、auto modeには次のような特徴があることが分かります。

安全な行動の判断精度は人間とほぼ同等（偽陽性率0.4%）なので、確認の手間をかけずに効率よく作業を進められる
悪意のある行動の検知精度は、検証によって結果が分かれている
- 2026年8月の検証では、人間よりも高い精度（89% vs 13.6%）で検知でき、セッションが長くなっても精度が落ちない
- 一方、2026年5月の検証や独立研究者による検証では見逃しや突破が確認されており、万全ではない
悪意のある攻撃を完全に防ぎたい場合は、auto mode以外にOSレベルの分離やネットワーク制御といったセキュリティ境界の対策も組み合わせる必要がある

6. auto modeが不向きな作業

ここまでの内容を踏まえて、単純にauto modeを用いる場合は、個人的に以下の作業は不向きだと考えます。

本番環境やインフラに影響する操作：デプロイやマイグレーション、terraform destroyのようなコマンドは、影響範囲が広く、失敗したときの被害も大きくなります。
元に戻せないgit操作：git reset --hardやforce push、レビューなしのPRマージ、CIチェックの無効化などは、一度やってしまうと取り返しがつきません。
機密情報を扱う操作：認証情報の出力や、機密データを外部エンドポイントへ送信してしまうと、情報漏洩につながるリスクがあります。
出自が不明な外部コンテンツを扱う作業：製作元や公開元が怪しいWeb記事の要約や外部リポジトリの取り込み、未知の添付ファイルの解析などは、プロンプトインジェクションが含まれているリスクがあります。

ただ、Anthropic公式の検証結果でもご紹介したのですが、本番環境での作業にもauto modeを適用している企業もあります。この場合は、問題のある行動を防ぐ他の防御策も適用した上でauto modeを使っている可能性が高いと推測されます。例えば、スキルやフックを用いたハーネスエンジニアリングを作りこんだうえで、auto modeを活用している可能性が高いと考えます。

7. 補足：GitHub Copilotにも似た機能がある

auto modeはClaude Code特有の権限モードの名称ですが、承認をAIの仕組みで自動化する機能自体は、他のコーディングアシスタント（GitHub Copilot、Codex、Cursor）でも提供されています。ここでは、類似機能としてGitHub Copilotでの仕組みを紹介します。

「Assisted permissions」（Claude Codeのauto modeに近い仕組み）

LLMジャッジ（別モデル）が各ツール呼び出しを個別に評価する仕組みで、Claude Codeのclassifierに近い設計
- GitHub公式は「ベストエフォートの便利機能であり、セキュリティの境界ではない」と公言
現状はpreview版での提供で、実験的機能のためまだデフォルトではない
VS Codeのチャット入力欄の権限ドロップダウンメニューから選択可能
- なぜか自分のVS Codeでは「Assisted permissions」が表示されておらず、選択できない

なお、名前が似た「Autopilot」機能もありますが、Claude Codeのauto modeとは仕組みが全く異なるため注意が必要です。

承認が必要な操作もすべて自動実行される仕組みで、個々の行動を判定するAIチェックはない
- Claude CodeのbypassPermissionsに近い挙動
Copilot CLIでは正式リリース済みの機能で、VS Codeから選択する場合はpreview版として表示されている

8. まずは安全な作業から、auto modeを始めてみませんか

ここまでの内容から、auto modeには大きく2つの特徴があると分かります。

何気なくClaude Codeを使っている状態の人間よりも高い精度で危険な行動を検知しつつ、安全な行動は承認を求めずに進めてくれるので、エージェントに安心して作業を任せやすくなる便利な機能である
一方で、セキュリティを完全に保証するものではなく、あくまでベストエフォート型の機能なので、本番環境やインフラへの作業のように慎重さが求められる場面では、auto mode単体で使うのは向いていない。ハーネスエンジニアリングやセキュリティ境界も組み合わせる必要がある。

この2つを踏まえたうえで、「エージェントの自律性を高めて、もっと作業効率を上げたい」という方は、まずは身近な小さな作業や、安全だと確信できる作業からauto modeを試してみてはいかがでしょうか。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up