Claude Code Auto Modeは、Anthropicが追加した research preview の権限モードです。対象は、Claude Codeをまだ知らない人ではなく、すでに日常的に使っていて、長いセッションのたびに同じような低リスク承認を何度も求められることに疲れている開発者です。2026年3月28日時点で確認した公式ドキュメントでは、Auto ModeはTeam向け機能として説明されており、低リスクなリポジトリ内作業は自動で通しつつ、ダウンロードしたコードの実行、本番デプロイ、main への force push のような爆発半径の大きい操作は止めるために、別の Sonnet 4.6 安全分類器を使います。問題が「長時間タスクで確認が多すぎる」ことならAuto Modeは検討に値します。問題が本番インフラ、破壊的データ操作、あるいは曖昧な外部システムへのアクセスなら、Auto Modeは狙うべき近道ではありません。
“エビデンス注記: この記事は Anthropic の公式 Auto mode announcement、permission modes docs、Claude Code product page、Claude Code changelog を2026年3月28日に確認して作成しています。
TL;DR
- Auto Modeは2026年3月24日に公開され、
--dangerously-skip-permissionsより安全な長時間タスク向けモードとして位置づけられています。 - 現在の公式ドキュメントではTeam向け機能として書かれており、EnterpriseとAPIはまだロールアウト中です。個人のProやMaxだけで使えると決めつけないほうが安全です。
- 向いているのは、長時間・リポジトリ内・境界が明確な作業です。たとえばマルチファイルのリファクタ、依存更新、テスト修正ループなどです。
- 多くの人が想像するより保守的です。Anthropicは
curl | bash、本番デプロイ、共有インフラの破壊的変更、mainへの直接 push / force push などを明示的にブロック対象として挙げています。 - ただ編集承認を減らしたいだけなら
acceptEditsで十分なことが多いです。先に実行計画を見たいならplan。完全な無人実行をしたいなら、本物の作業マシンではなく隔離環境を先に作るべきです。
Claude Code Auto Mode が実際に変えるもの
AnthropicがAuto Modeを出した理由は、通常の permission prompts と完全な bypassPermissions の間が空きすぎていたからです。通常の default モードでは、Claude はファイル編集やコマンド実行の前に確認を求めます。これは未知のリポジトリや敏感な作業では正しい挙動ですが、1時間かかるようなリファクタ中に細かな承認が何十回も挟まると、体験としてはかなり鈍くなります。逆に --dangerously-skip-permissions は極端です。使い捨てコンテナや強い sandbox がある CI なら成立しても、実際の認証情報や本番経路を持つ普段使いのマシンには向きません。
Auto Modeはその中間にあります。ただし、それは「Claudeに何でも任せられるようになった」という意味ではありません。より正確には、「作業が信頼できるローカルリポジトリ境界に収まっている間はClaudeを前に進めやすくし、曖昧または危険に見える操作では別の安全レイヤーが介入する」ということです。ここを理解しておかないと、Auto Modeの価値も、初回利用時に“想像より厳しい”と感じる理由も見誤ります。
Anthropicが自動化したいのは、すべての承認ではなく、退屈で予測可能な承認です。現在の working directory 内でのファイル編集と、外部からコードを落として実行するシェル操作は、同じ自動化対象ではありません。GETでドキュメントを読むのと、本番インフラに変更を入れるのも同じではありません。Auto Modeはまさにその差を前提に設計されています。リポジトリ内で完結し、意味が読みやすく、外への広がりが小さい作業は通しやすくし、作用範囲が大きくなりそうな操作には強い疑いを向けます。
だからこそ、この機能が最も刺さるのは「Claudeにこの仕事をやらせること自体はもう信頼しているが、そのたびに似た確認を繰り返したくない」という人です。たとえば、ある抽象を三十ファイル横断で名前変更し、テストを直し、ローカルスイートを回すと決めているなら、Auto Modeはそのセッションをかなり滑らかにできます。逆に、仕事そのものをまだ信頼していないなら、Auto Modeは本質的な問題を解決しません。変えるのは作業の正当性ではなく、中断の頻度です。
公式ドキュメントで特に重要なのは、Auto Modeのclassifierが見るのはユーザーメッセージとtool callであり、Claude自身の説明テキストや生のtool resultではないという点です。つまり安全レイヤーは、要求されている操作と意図を見て判断しているのであって、セッション全体を全知的に審査しているわけではありません。だからAuto Modeは“狭い境界のガードレール”として理解すべきであって、“これで安全が証明された”と読むべきではありません。
今使えるのか、どうやって有効化するのか
多くの読者が最初に欲しいのは思想ではなく資格確認です。Anthropicの現在の見せ方は、マーケティング上は広く見えるのに、実際の利用条件はずっと狭いので、plan、管理者設定、モデル、利用 surface を順に確認するのが最も早いです。
最初に見るべきは plan です。 現在の permission modes ドキュメントでは、Auto ModeはTeamで利用可能、EnterpriseとAPIはロールアウト中と説明されています。つまり、個人のClaude ProやMaxを持っていることと、Auto Modeが使えることは同義ではありません。個人アカウントで mode が出てこないなら、まず plan の問題を疑うべきです。Claude Code のアクセス条件全体を見比べたいなら、Claude Code pricing guide を参照してください。
次に管理者設定です。 Team と Enterprise では、管理者が先にAuto Modeを有効にしないと、ユーザーは切り替えられません。これは単なる個人設定ではなく、チームとして許容する作業フローの選択だということです。正しい plan にいるのに見えない場合、CLI をいじるより先に管理者に確認したほうが早いことが多いです。
モデル条件も狭いです。 Anthropicは現在、Claude Sonnet 4.6 と Claude Opus 4.6 を対応モデルとして挙げています。Haiku、Claude 3 系、Bedrock、Vertex、Foundry などの third-party provider surface は対象外です。Claude Code自体が動いていても、Auto Modeだけが使えないのは十分ありえます。
surface も同じではありません。 基本はローカルCLIで考えるべきです。公式ドキュメントでは claude.ai/code のクラウドセッションにはAuto Modeがなく、Remote Control では Ask permissions、Auto accept edits、Plan mode が表示されると書かれています。つまり、ブログで見たAuto ModeをそのままクラウドやRemote Controlで探しても、前提が違います。
条件を満たしているなら、CLIでの有効化はシンプルです。
- Team 管理者が Auto Mode を有効にしていることを確認する。
--enable-auto-modeを付けてローカル Claude Code セッションを開始する。- セッション中に
Shift+Tabで permission mode を切り替え、autoが出るまで進める。 - それでも出ないなら、plan、model、surface のどれかを取り違えていないか見直す。
Anthropicは、起動時に --enable-auto-mode を付けなければ auto は mode cycle に現れないと明記しています。最初の失敗が多いのはここです。まだClaude Code本体の導入や更新が済んでいないなら、先に Claude Code install guide を確認してください。
VS Code拡張にもひとつ注意点があります。より permissive な mode は、「Allow dangerously skip permissions」という設定を有効にしたあとでないと表示されません。これは bypassPermissions を使えと言っているのではなく、Anthropicが高権限 mode を意図的に“見つけにくく”しているということです。Auto Modeは、偶然触るものではなく、明示的に選ぶものとして設計されています。
もうひとつ実用的なのが changelog の記述です。2026年3月27日の Claude Code 2.1.86 では、表示メッセージが “temporarily unavailable” から “unavailable for your plan” に変わりました。小さな修正ですが、実際の混乱がどこにあったかをよく示しています。多くの場合、問題は“まだ順番が回ってきていない”ことではなく、“そもそもそのplanでは使えない”ことです。
Auto Mode が通すもの、止めるもの、そして fallback する理由
ここがAuto Modeの価値を決める本体であり、ニュース記事が省略しがちな部分です。
Anthropicは、Auto Modeの中で二種類の経路を説明しています。ひとつは明らかに低リスクな fast path で、classifier すら不要なものです。代表例は current working directory 内のファイル編集です。これは自然です。Claude Codeの仕事の多くは、既知のローカルリポジトリ内でファイルを読み、編集し、整理することです。ここを毎回危険扱いしていてはAuto Modeの意味がありません。Anthropicは他にも、read-only HTTP request、lockfile に沿った依存インストール、.env を読んで対応するAPIにだけ認証情報を送る狭いリクエストを許可対象として挙げています。
もうひとつが、別の安全モデルが意味を持つ経路です。Anthropicによると、Auto ModeはSonnet 4.6上で動く classifier を使って、“明らかな低リスク”に入らない操作を判定します。これは追加レイテンシと追加コストを伴います。主セッションとは別にもう一回モデル判定が走るからです。ただし、その代わりに数十回分の承認を減らせるなら、多くの長時間タスクでは十分に釣り合います。逆に、短くて単純なタスクなら、その層自体が過剰です。
重要なのは classifier の存在そのものより、Anthropic が書いている default block list です。公式には次のようなカテゴリが挙げられています。
- インターネットからコードをダウンロードして実行する
- サービスのデプロイや本番DB migration
- Terraform や CloudFormation など共有インフラへの高リスク変更
- クラウドストレージでの大量削除
- IAM や repository permission の変更
- 既存ファイルへの不可逆な破壊的操作
mainへの direct push / force push
この列挙を見ると、Anthropic が何を守ろうとしているのかがかなり明確になります。Auto Modeは、ローカルソフトウェア作業がリポジトリ境界の中に留まる限りは前向きですが、作用範囲が広がる、不可逆性が強まる、外部システムに踏み込む、といった瞬間に慎重になります。つまり“repo autonomy with infrastructure skepticism”です。
この境界があるからこそ、初回利用で肩透かしを食う人も出ます。“--dangerously-skip-permissions を少しだけ安全にしたYOLOモード”を期待していたなら、厳しすぎると感じるでしょう。“リポジトリ内長時間タスクで確認疲れを減らしつつ、明らかな危険操作だけは止めるモード”を期待していたなら、かなり理にかなって見えるはずです。この摩擦はランダムではなく、Anthropicが意図している境界そのものです。
公式ドキュメントで特に価値が高いのが fallback の説明です。classifier が3回連続でブロックするか、1セッション内で合計20回ブロックすると、Claude Code は manual prompt mode に戻ります。これは賢い設計です。そこまで何度も guardrail に当たるなら、そのタスクは最初から Auto Mode 向きではないか、Claude が Auto Mode の境界を越える実行パスを探り始めているということです。どちらの場合も、正しい対応は“押し通す”ことではなく、mode を変えるか、タスクを切り直すことです。
Anthropicはさらに、Auto Modeに入ると Bash(*) や Agent のような broad allow rules を落とすとも書いています。これはAuto Modeが単なる名称変更ではないことの証拠です。以前の“何でも通しやすい設定”が classifier 層を無効化することを、Anthropic自身が防ぎにいっています。
Auto、acceptEdits、plan、bypassPermissions をどう使い分けるべきか
この機能で最も危険なのは、“今後は全員Autoが新標準だ”と考えることです。実際には、多くの開発者にとって acceptEdits のほうがまだ自然なベストバランスです。acceptEdits は最も頻繁な file edit approval を減らしつつ、shell execution の判断は人間の目に残します。普段のセッションが「コードを直す + いくつかのコマンドは自分でも見たい」という形なら、それだけで十分に快適になります。
plan はさらに別物です。Auto Mode の軽量版でも重量版でもありません。必要なのが execution ではなく、architecture、sequence、tradeoff の先出しなら、plan を選ぶべきです。未知のリポジトリ、複雑な migration、大きい変更をどう切るか曖昧なときは、Auto Mode ではなく plan が効きます。
default も依然として正しい答えです。新規リポジトリ、インシデント対応、認証情報の掃除、権限周りの整理など、“速度より可視性が本題”の場面では普通の確認モードに残るべきです。遅いのは欠点ではなく、守るべきものがあるからです。
bypassPermissions は Auto Mode の“上位版”ではありません。契約が違います。「この環境は十分に隔離され、十分に捨てられて、失敗の影響も吸収できる」と自分で言えるときにだけ成立します。そうでないなら、そこに行くべきではありません。AnthropicがAuto Modeを出した理由そのものが、“default では遅い、でも total bypass までは行きたくない”という実務の隙間を埋めることだからです。
実用的な判断表にすると、こうなります。
| 次のタスクが… | 向いている mode | 理由 |
|---|---|---|
| 新規 repo、敏感な修正、危険度の高い cleanup | default | 最大の可視性がまだ必要 |
| ローカル実装だが shell command は確認したい | acceptEdits | 編集だけ軽くし、コマンド判断は隠さない |
| 設計整理、migration planning、範囲確認 | plan | 本当に必要なのは実行前の思考 |
| 長時間の repo-scoped refactor、test loop、dependency cleanup | auto | まさに approval fatigue を解くための mode |
| 使い捨て container や高隔離 sandbox | bypassPermissions | 完全自動は失敗を吸収できる環境でだけ成立 |
私のおすすめは単純です。問題を解決できる“最も軽い mode”を選んでください。Auto Modeは名前が強そうだから選ぶものではなく、確認疲れが本当のボトルネックになっているときにだけ選ぶものです。
Auto Mode が向いているタスクと、外したほうがいいタスク
Auto Modeが真価を発揮するのは、Claudeが“正しいけれど細かい”作業を大量にこなす場面です。マルチファイルのリファクタは典型例です。抽象名を変更し、importを更新し、テストを直し、branch を整える。ここで辛いのは“Claudeが改めてよいか”ではなく、“なぜ似た承認をこんなに何度も押すのか”です。依存更新も向いています。特に lockfile と整合する変更なら相性がいいです。テスト修正ループも同様で、多くの小編集と繰り返しコマンドが発生するため、承認負荷が高くなりやすいからです。
これらのタスクに共通するのは、単に“コーディングである”ことではありません。範囲が狭く、効果が局所的で、あとから review しやすいことです。作業が branch に残り、変更差分が追え、ミスの影響もほぼ repo 内に閉じます。これが classifier-gated mode が成立する条件です。
逆に、コーディングと operational authority が混ざった瞬間に、Auto Mode は弱くなります。本番デプロイ、インフラ変更、破壊的DB操作、権限変更、大量削除。こうした作業は“承認を減らす”こと自体を目的にすべきではありません。Anthropic がデフォルトで止めているのは良いことですが、もっと重要なのは、こちら側の判断軸です。
さらに厄介なのが中間地帯です。たとえば、Claudeがコードを直しているリポジトリに、本物の認証情報、デプロイスクリプト、クロスサービスの管理ツールがぶら下がっている場合です。自然言語の依頼が“このモジュールをリファクタして”だったとしても、環境そのものの広さを考えると acceptEdits や plan のほうが安全です。Auto Mode が最も機能するのは、要求の表面だけでなく、環境自体が狭いときです。
この話は Claude Code の rate limit ガイド ともつながります。Auto Mode は長時間セッションの体感を良くしますが、無料化したり、上限を消したりするわけではありません。Anthropic も classifier による追加コストと追加レイテンシを明記しています。すでに長時間の利用量で頭打ちになる人にとって、Auto Mode は“抜け道”ではなく“摩擦軽減”です。
かなり実務的なルールに落とすなら、“その仕事を、十分に注意深いジュニアエンジニアに repo 内で任せられるか”で判断するのがいいです。本番権限を持つ上級オペレータにしか任せたくない仕事なら、Auto Mode に載せるべきではありません。
unavailable と出る理由、想像より厳しく感じる理由
一番多い失敗は、単純に利用不可であることです。auto が見えないなら、まず地味な確認をしてください。plan は合っていますか。管理者は有効にしていますか。Sonnet 4.6 か Opus 4.6 ですか。ローカルCLIですか。起動時に --enable-auto-mode を付けましたか。多くの“壊れている”報告は、このどれかです。
次によくあるのが、会話が block を踏み続け、最後に manual prompt mode へ戻るケースです。そのとき一番ありえる説明は、“classifier が賢くない”ではなく、“そのタスクが Auto Mode の trust boundary から外れた”です。ダウンロード実行に寄っているのかもしれないし、共有インフラの変更に流れているのかもしれません。あるいは、以前の broad allow rules が Auto Mode 開始時に落とされているのかもしれません。いずれにせよ、fallback はノイズではなくシグナルです。
三つ目の不満は、“名前は advanced なのに acceptEdits より厳しい”という感覚です。これは本当です。acceptEdits はファイル編集を軽くする代わりに、shell は人に残します。Auto Mode は shell-heavy な長時間作業まで通したいので、Anthropic は別 classifier と明確な block list を入れざるをえません。自動化の範囲が広いぶん、境界も強くなります。
さらに Anthropic は、Claude Code の interface ごとに permission mode の見え方が違うと明記しています。ローカルCLI、VS Code extension、Remote Control、クラウドホストセッションを行き来しているなら、同じ mode 一覧や同じ挙動を前提にしないでください。
最後に、これはまだ research preview です。このラベルは“怖いから触るな”ではなく、“恒久仕様だと思い込むな”という意味です。Anthropic は今後、対応範囲も classifier も UI も変えるかもしれません。挙動が以前の記憶と違ったら、まず最新 docs を見直すべきです。
で、結局オンにすべきか
次の4つが全部当てはまるなら、答えはたいてい Yes です。
- 今日その機能にアクセスできる
- タスクが十分に長く、繰り返し承認が本当の摩擦になっている
- 作業が信頼できる repo、branch、tool boundary の中に収まる
- 結果をエンジニアとして review するつもりがある
逆に、どれかひとつでも当てはまるなら、少なくとも今は No です。
- 現在の docs 上では未対応の個人 plan を使っている
- タスクが本番、共有インフラ、破壊的操作に触れる
- 環境自体が広すぎて repo 境界が安全境界にならない
- 欲しいのは編集承認の削減だけで、
acceptEditsで足りる
Claude Code Auto Mode を理解する最も役に立つ視点は、“Anthropic がついに完全自律を解禁した”ではありません。もっと狭く、もっと実務的です。Claudeにこの仕事をさせること自体はもう信頼している。でも毎回の手動承認コストは払いたくないし、total bypass のリスクも負いたくない。その中間地帯のために Anthropic が用意したのが Auto Mode です。自分の課題がその中間地帯にあるなら有用ですし、ないなら unavailable、厳しすぎる、危なすぎる、のどれかに見えるはずです。その反応自体が、この機能の適用境界を教えてくれます。