Claude Code オートモードの安全な使い方（2026）：実リポジトリ向け実務フロー

まず結論

Claude Code の auto mode は実務でも使う価値がある。ただし前提は、task boundary が十分に狭く、repo を「agent が作業してよい隔離環境」として扱えることだ。2026-03-26 時点で Anthropic は auto mode を research preview と位置づけており、Team plan を先行対象にし、admin enablement を必要とし、今も sensitive な production repo ではなく isolated environment で使うことを勧めている。

見落としやすいのは、auto mode が単なる「file edit を速く承認する機能」ではないことだ。Anthropic の現行 docs では、default trusted environment に current working directory、immediate child directories、current branch、matching git remotes、一部の declared dependency に紐づく package-manager action、さらに matching API / website に既に login 済みなら repo 内 .env credential を送る挙動まで含まれうる。だから安全な使い方は「とりあえず auto を有効化する」ではない。正しい順序は、まず plan、次に defaults の確認、worktree や container で repo を隔離し、本当に触れてほしくない範囲へ deny rules を置いてから、1 つの bounded task を実行させることだ。

Auto Mode で変わったこと

Anthropic は 2026-03-24 に Claude Code auto mode を公開した。これが重要なのは、permission prompt が coding agent を「面白い demo」から「毎日使える workflow」へ変える最大の分岐点の 1 つだからだ。

auto mode 以前、多くの team は次の 2 つの微妙な選択肢に挟まれていた。

• 重要な action を毎回手動で承認する
• --dangerously-skip-permissions で permissions を丸ごと飛ばす

auto mode の価値は、その中間層を作った点にある。ある action は自動承認され、ある action は block され、ある action は classifier に回され、解決できない時だけ人に聞く。つまり本当に考えるべきなのは、「auto mode があるかどうか」ではなく、「default で何を trust し、その trust boundary を実 repo 向けにどう狭めるか」だ。

何が変わり、何が変わっていないのか

多くの人が見落とす点：Auto Mode は file edit 以上を信頼する

この文章で 1 つだけ覚えるなら、ここだ。

Anthropic の現行 permission docs では、default auto-mode trust envelope に次のようなものが含まれうる。

• read-only tool call
• current working directory とその immediate child directories 内での edit
• current git remotes と同一ドメインの page 取得
• project file に既に declared された dependency に紐づく package-manager / registry action
• current branch、または Claude 自身が作成した branch に対する action
• working directory や child directories の .env credential を、matching API / website に login 済みの場合に送ること

最後の bullet が特に重い。repo に live credential が入っているなら、「ただの refactor だから大丈夫」とは言えない。

さらに 2 つの detail が重要だ。

• Anthropic は、auto mode に入る時点で危険な broad allow rules を落とすと明記している。たとえば Bash(*)、Bash(python *) のような wildcard interpreter rule、Bash(npm run *) のような broad package-manager pattern、そしてあらゆる Agent allow rule だ。
• Read(.env*) のような deny rule は、Claude Code の built-in file tool だけを止める。Bash の cat .env は止められない。本当に hard protection が必要なら、sandboxing、devcontainer、あるいは secret を含まない worktree を使うべきだ。

どういう task なら Auto Mode に向いているか

Claude Code auto mode を使う価値があるのは、次の条件がすべて揃う時だ。

• repo または worktree が local で、isolated で、blast radius が小さい
• task が multi-step で、prompt ごとの確認が明らかに遅い
• goal が具体的で、Claude が done を判断しやすい
• 最後に diff と verification output を自分で review する前提がある

向いている例：

• lint、types、formatting rule に合わせた一括更新
• 1 つの subsystem にまとまった test failure の修正
• 境界が明確な folder set 内での file / symbol rename
• docs、example、internal tooling のような低リスク変更で、stop rule が明確なもの
• verification command がはっきりしている constrained refactor

向いていない例：

• active working tree に production secret が入っている repo
• deployment script、cloud infra、DNS、billing、auth change
• shared environment での database migration
• よく知らない repo での destructive cleanup
• Bash 1 発の誤りが高くつく task

実リポジトリ向けの、より安全な workflow

Step 0: permission を考える前に、作業コピーを隔離する

最も安全な auto-mode session は main checkout 上ではない。使い捨て branch、git worktree、あるいは devcontainer 上だ。

例：

git worktree add ../repo-auto-mode -b claude-auto-mode-safe
cd ../repo-auto-mode
claude

これで Claude の permission system が働く前に、まず blast radius を小さくできる。もし environment を分けられないなら、少なくとも secret は working directory から外し、deploy や billing 関連 path を scope 外にするべきだ。

Step 1: 最初は /plan。いきなり autonomous edit に入らない

Anthropic の current workflow docs でも、plan mode は安全な read-first step として位置づけられている。session を直接 plan mode で開始できる。

claude --permission-mode plan

すでに Claude Code 内にいるなら、同じ session で /plan を使えばよい。

Claude には、境界の狭い planning brief を渡す。

Analyze this repository and propose the smallest plan to update the API client tests.
Do not edit files or run commands yet.

Tell me:
1. which files are likely to change
2. which commands you expect to run
3. which risky paths or secrets should stay off-limits
4. what the smallest verification command is

ここが本当の safety gate だ。plan 自体が雑なら、auto mode はその雑さを高速実行するだけになる。

Step 2: auto を有効にする前に、実際の defaults を確認する

Anthropic は今、推測ではなく確認のための command を用意している。

claude auto-mode defaults
claude auto-mode config

custom rule を触る前提なら、次の command も docs にある。

claude auto-mode critique "This task may need tests, a package install, and docs edits. Is my config too broad?"

現行 docs で実務的に大事なのはこの 2 点だ。

• autoMode.allow と autoMode.softDeny は defaults を置き換える。merge ではない。つまり expert setting と考えるべき。
• autoMode.environment は user setting と .claude/settings.local.json から読み込まれ、shared project setting からは読まれない。repo に commit された設定が全員の trust boundary を勝手に広げない、という意味で安全側だ。

Step 3: scope、stop condition、verification command を 1 本に絞って明示する

auto mode は、task の shape が狭いほど安定する。

コピペ用 prompt：

You are working in a supervised Claude Code auto-mode session.

Goal:
Update the API response parsing in src/api and fix the directly affected tests.

Allowed paths:
- src/api
- tests/api
- docs/api-migration.md

Forbidden paths:
- deployment/
- infra/
- scripts/release/
- .env*
- package.json
- lockfiles

Rules:
- Prefer the smallest possible change.
- Do not install or update packages.
- Do not push, deploy, or open unrelated network destinations.
- Run only one focused verification command unless I approve a broader one.
- If the fix requires touching more than 5 files outside the allowed paths, stop and ask.
- If the same category of action is blocked twice, summarize what is missing instead of improvising.

Return at the end:
1. files changed
2. commands run
3. verification result
4. remaining risks

派手さはないが、この prompt は強い。goal、fence、stopping point が揃っているからだ。

Step 4: 本当に「絶対に触るな」を意味するなら deny rules を足す

本当に off-limits な path や command family があるなら、その意思を prose に埋め込むだけでは足りない。permission に明示すべきだ。

考える価値がある例：

• .env file の read を deny する
• deployment/、infra/、terraform/ 配下の edit を deny する
• git push を deny する
• package install command を deny する

Anthropic の current docs では、これを /permissions または Claude Code settings で管理することを案内している。ただし限界も同じだ。Read や Edit の deny rule は arbitrary shell access を止めない。OS レベルの防御が必要なら、permissions と sandboxing、または disposable environment を組み合わせるべきだ。

Step 5: Auto Mode に任せるのは「面倒な中間工程」だけにする

plan が正しく、boundary が明示できたら auto mode を有効にする。

claude --enable-auto-mode

CLI では Shift+Tab でも mode を切り替えられる。対応 surface なら、planning 後に mode selector から切り替えてもよい。

健全な pattern はこうだ。

1. plan mode で repo を読む
2. 自分で plan を確認する
3. 1 つの bounded task にだけ auto mode を使う
4. Claude に edit と 1 つの focused verification command を任せる
5. 最後は自分で diff を review する

不健全な pattern はこうだ。

1. test を直す
2. 関係ない warning も片づける
3. dependency も更新する
4. config も書き換える
5. 「ついでに build も改善して」と足していく

auto mode は ambiguity を解決しない。定義済みの task を、中断少なく実行するためのものだ。

それでも Auto Mode が広すぎると感じるなら

正解が「auto mode をもっと厳しくすること」ではなく、「別の permission mode を使うこと」である場合もある。

特に比較したいのは dontAsk だ。Anthropic の現行 docs では、既存の allow rules の範囲でのみ Claude が動き、それ以外は単に聞かない mode として説明されている。明示的な command policy がある環境では、auto mode を bypass に近づくまで緩めるより、こちらの方が安全なことがある。

hard guarantee が必要なら、classifier 単体に頼るより次を組み合わせた方がよい。

• plan：read-only で repo を理解する
• acceptEdits：少数ファイルの edit に絞る
• dontAsk：pre-approved rule ベースの controlled workflow に使う
• sandboxing、devcontainers、worktrees：実際の isolation を与える

すぐ使える判断表

FAQ

auto mode は acceptEdits と同じ？

違う。acceptEdits は file edit 周りの friction を減らす mode だ。auto mode はそこからさらに進み、一部 action を自動承認し、別の action は classifier に回し、rules でも classifier でも解決しない時だけ prompt に戻る。

そもそも auto mode が見えないのはなぜ？

提供条件がまだ限られているからだ。Anthropic は現在、auto mode を Team 先行の research preview と説明しており、admin enablement も必要で、対応 surface と model も限定している。Haiku、Claude 3、Bedrock、Vertex、Foundry、あるいは Claude の web-control session なら、toggle が見えなくても不思議ではない。

deny rules だけで secret を守れる？

完全ではない。Read(.env*) のような deny は Claude Code の file tool には効くが、Bash の cat .env には効かない。本当に secret を見せたくないなら、working directory から外すか、credential を含まない隔離環境で実行する方が安全だ。

auto mode はコストが高い？

高くなる。Anthropic は classifier check が token usage と round-trip latency を増やすと明言しており、classifier は現在 Sonnet 4.6 で動く。多くの prompt と permission confirm を減らせる時だけ、この追加コストは正当化しやすい。

どんな時は auto mode を使わない方がいい？

repo に sensitive credential がある、task が曖昧、command surface に deploy や infra action が含まれる、あるいは Bash 1 発の誤りのコストが高い。こういう時は最初から避けた方がよい。

結論

Claude Code auto mode は便利だが、正しい mental model は「trusted autopilot」ではない。正しくは、「自分で boundary を定義し、その内側で classifier-assisted execution を使う」だ。

短く覚えるなら、この checklist で十分だ。

1. worktree、branch、container で repo を隔離する
2. まず /plan
3. claude auto-mode defaults を確認する
4. 本当に触れてほしくないものへ deny rules を足す
5. Claude には 1 つの bounded task だけを任せる
6. 最後は diff と verification output を自分で review する

reckless autonomy よりは遅いが、延々と manual prompt を処理するよりは速い。そして repo surprise をかなり減らせる。

検証メモ

2026-03-26 に確認。

• Anthropic の公式 auto mode announcement で、2026-03-24 の公開日、research preview 状態、Team 先行 rollout、admin enablement、対応 model、isolated environment の推奨を確認：https://claude.com/blog/auto-mode。
• Anthropic の公式 permission-mode docs で、現在の対応 surface、非対応 provider、action evaluation order、classifier model、削除される broad allow rules、そして 3 回連続 / 合計 20 回 block 後に prompting へ戻る挙動を確認：https://code.claude.com/docs/en/permission-modes。
• Anthropic の公式 permissions docs で、trusted infrastructure defaults、.env credential の扱い、deny rules が Bash には及ばない点、autoMode.environment の読込元、/permissions、claude auto-mode critique を確認：https://code.claude.com/docs/en/permissions。
• Anthropic の公式 CLI reference で、claude --enable-auto-mode、claude auto-mode defaults、claude auto-mode config を確認：https://code.claude.com/docs/en/cli-reference。
• Anthropic の公式 common workflows / sandboxing docs で、/plan、mode handoff、worktree guidance、devcontainers、そして sandboxing を defense in depth として使う考え方を確認：https://code.claude.com/docs/en/common-workflows と https://code.claude.com/docs/en/sandboxing。