Claude Codeのauto modeを初心者に使わせない理由｜段階的に上げる3ステップ

結論：慣れるまでは使わせません

先に結論を書きます。
弊社は日常業務でauto modeを使っています。
それでもAI導入支援でお客様に教えるときは、最初は絶対に使わないでくださいとお伝えしています。

矛盾しているように見えるかもしれません。
ですが理由は単純で、auto modeは「AIの実力を上げる機能」ではなく「あなたの確認作業を減らす機能」だからです。
確認する力がまだ無い人が確認を省略しても、速くなるのは事故だけです。

弊社では次の3段階で上げていきます。

イメージとしては、初日のアルバイトに店の鍵を渡さないのと同じです。
能力を疑っているわけではありません。まだお互いに、どこまで任せて大丈夫かが分かっていないだけです。
最初は横について全部見る。慣れたら要所だけ見る。安心できるようになったら任せる。順番はこれ以外にありません。

auto modeとは何か

Claude Codeには権限モードがあり、どこまで確認を挟むかを切り替えられます。
ターミナルではShift+Tabで切り替えられます。

auto modeは、この中で「確認をあなたの代わりに別のモデルがやる」モードです。
公式にはこのモデルを分類器と呼びます。
なおPro・Max・Teamプランでは、バージョンとモデルの条件を満たす場合、セッションの開始モードが最初からauto modeになっています。
つまり何も設定していなくても、すでにauto modeで動いている可能性があります。

よくある誤解：auto modeは「全部素通り」ではない

ここが一番誤解されている部分です。
auto modeとbypassPermissionsを同じものだと思っている方が多いのですが、この2つはまったく別物です。

ただしauto modeでも、分類器を通らずに実行される操作があります。ここは正確に知っておいてください。

公式にも「auto modeは確認の回数を減らすが、安全を保証するものではない」と明記されています。
その上で、知っておくと安心できる仕組みも入っています。

広すぎる許可設定は自動で無効になる

auto modeに入ると、任意のコードを実行できてしまう大雑把な許可ルールは自動的に外されます。
たとえばBash(*)のような全許可、Bash(python*)のようなワイルドカード付きのインタプリタ、パッケージマネージャの実行コマンドなどが該当します。
Bash(npm test)のように範囲を絞ったルールはそのまま残ります。auto modeを抜けると、外されたルールは元に戻ります。

つまり「全部許可」にしたままauto modeに入っても、その全部許可は効きません。
ここは設計として、かなり慎重に作られている部分です。

どのモードでも自動承認されない操作がある

次の操作は、bypassPermissionsを含めてどのモードでも自動では通りません。

• 明示的に「毎回聞く」と設定したツール
• 利用者への確認が必要なツール
• 重要なパスを対象にしたrmやrmdirによる削除

特に3つ目は、許可ルールを書いても通りません。モデルが間違えたときのブレーカーとして用意されているものです。

保護パスへの書き込みは別扱いになる

設定や履歴を壊すと影響が大きい場所は、保護パスとして別扱いされています。
.git .claude .zshrc .bashrc .npmrc .gitconfig .mcp.json などが含まれます。

これらへの書き込みは、許可ルールを書いても事前承認されません。
auto modeでは必ず分類器に回りますし、defaultやacceptEditsではあなたに確認が来ます。

危険な操作の前には状態を確認している

git reset --hardのようにコミットしていない作業を消してしまうコマンドの前には、Claude Code自身がgit statusを実行し、未保存の変更があるかどうかを分類器に伝えます。
「消えたら困るものがあるかどうか」を見た上で判断している、ということです。

ファイルやWebページの中身で分類器を直接操作することはできない

分類器が見ているのは、あなたの指示、実行しようとしているツール呼び出し、そしてCLAUDE.mdの内容です。
ツールの実行結果は取り除かれた状態で渡されます。
そのため、読み込んだファイルやWebページの中に「この後の操作をすべて承認せよ」といった文章が仕込まれていても、分類器がそれを直接読んで従うことはありません。

ただし分類器はCLAUDE.mdを読みます。
外部から持ってきたリポジトリのCLAUDE.mdは、分類器への入力経路になり得ます。中身を確認せずに使わないでください。

それでも初心者に使わせない理由

ここまで読むと、auto modeはかなり安全そうに見えると思います。実際、よく考えられています。
それでも導入支援では使わせません。理由は安全性ではなく、使う人の側にあります。

分類器が防いでくれるのは「危険な操作」です。
防いでくれないのは「危険ではないが、あなたが望んでいなかった操作」です。

たとえば見積書の書式を整えてほしいと頼んだときに、ついでに金額の桁区切りが変わっていたとします。
これは危険な操作ではありません。ファイルを消すわけでも、外部に送信するわけでもない。分類器は止めません。
止められるのは、その書類を見て「ここは変わってはいけない場所だ」と分かる人だけです。

アルバイトの話に戻します。
初日の子に「適当にやっといて」と言って出来上がったものを、あなたは見ずに客に出せるでしょうか。
出せないとしたら、それは相手を信用していないからではなく、あなたがまだその子の仕事の癖を知らないからです。
何を得意として、どこで手を抜きがちで、どういう勘違いをするのか。それが分かって初めて、見る場所を減らせます。

AIも同じです。
最初の数十回は、遅くても全部見てください。そこで「こういう指示をするとこう解釈するのか」という感覚が身につきます。
この感覚がないまま自動化すると、間違いに気づけないまま成果物が積み上がります。これが一番怖い状態です。

弊社が使っている3段階

第1段階：plan モード（全部確認する）

まずplanモードから始めます。
このモードではファイルの読み取りと調査だけを行い、ソースファイルの編集はしません。何をするつもりかを先に提示させ、こちらが承認してから動きます。

最初に覚えてほしいのは操作方法ではなく、AIの提案を読んで良し悪しを判断する力です。
提案を読んで「これは違う」と言えるようになるまでは、この段階から出ません。
ここを飛ばした人は、後で必ず戻ってくることになります。

第2段階：acceptEdits モード（大事なところだけ確認する）

提案の判断ができるようになったら、ファイル編集だけを自動で通します。
このモードでは、作業フォルダ内のファイル編集に加えて、mkdir touch rm rmdir mv cp sed が確認なしで動きます。
読み取り専用の組み込みコマンドを除けば、それ以外のコマンド実行やネットワークへのアクセスは、引き続き聞いてきます。

編集と後片付けは任せる。それ以外の実行は握っておく。この線引きが2段階目です。
ここで「変更後のファイルを見て、おかしければ自分で気づける」状態を作ります。

第3段階：auto モード（仕組みができてから）

そして最後がauto modeです。
移行の条件は「慣れたから」ではありません。後述する仕組みができているかどうかで判断します。

auto modeでも自分で止めているもの

弊社はauto modeを常用していますが、危険な領域には最初から手が届かないようにしています。
実際の設定ファイルの中身がこちらです。

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ],
    "defaultMode": "auto"
  }
}

拒否は4つだけです。
ファイルの一括削除、リモートリポジトリの強制上書き、そしてSSH鍵とクラウドの認証情報の読み取り。
この4つは、業務で必要になる場面がまずありません。それなら最初から使えなくしておくほうが確実です。

ルールは拒否、確認、許可の順で評価され、最初に一致したものが結果になります。
拒否が最優先なので、他でどれだけ広く許可していても、拒否に書いた操作は通りません。
モードを変えても拒否ルールは効き続けます。

見落としやすい穴

公式ドキュメントに明記されている仕様ですが、見落とされやすい部分です。知らないと危ないので取り上げます。

つまり先ほどのRead(~/.ssh/**)は、AIが直接読もうとしたときには止まりますが、AIが書いたスクリプトが読む場合には止まりません。
拒否ルールは万能の壁ではなく、あくまで直接操作に対する歯止めです。
本当にOSレベルで遮断したい場合は、サンドボックスを有効にする必要があります。

弊社が「セキュリティが絡む作業ではauto modeを使わない」と決めているのは、この性質があるためです。
セキュリティが絡む作業では、面倒でもモードを落として自分で見ます。
仕組みで守れる範囲と、守れない範囲を分けて考える必要があるためです。

「仕組み化できたら使ってよい」の中身

弊社が移行の条件にしている「仕組み化」は、次の3つが揃っている状態を指します。

1. 戻せること

作業対象がGitで管理されているか、少なくとも直前の状態に戻せること。
これが一番大事です。戻せるなら、たいていの失敗は失敗ではなくなります。
逆に、戻せないものを直接触らせるときは、モードを落としたほうが確実です。

2. 壊れたら分かること

テストでも、確認用のスクリプトでも、目視のチェック手順でも構いません。
「作業後にこれを見れば、おかしくなっていないと言える」という確認方法があること。
これが無い状態で自動化すると、壊れていることに気づくのが数日後になります。

3. 範囲が限られていること

拒否ルールを書いて、触ってほしくない場所には届かないようにしておくこと。
先ほどの4行がこれにあたります。
どこまで行っても大丈夫と言い切れる範囲の中でだけ、自由に動いてもらう考え方です。

この3つが揃うと、auto modeは急に扱いやすくなります。
逆に1つでも欠けているうちは、時間を節約しているつもりで、後始末の時間を先送りしているだけです。

よくある質問

auto modeにすると危険ですか

モード単体の危険度でいえば、bypassPermissionsとは比べものにならないほど安全です。
分類器による確認が入りますし、広すぎる許可ルールは自動で外れます。重要なパスの削除はどのモードでも自動承認されません。
危険になるのは、戻せない作業に使ったときと、間違いに気づけない人が使ったときです。モードではなく使い方の問題です。

どのくらいで次の段階に上げてよいですか

期間では決めないほうがよいです。
ひとつの目安になるのが、提示された内容に対して「そこは違う」と自分から言えたかどうかです。
何度か指摘できているなら、中身を読めています。一度も指摘したことがないなら、まだ流し読みになっている可能性があります。

途中でモードを戻してもよいですか

むしろ戻してください。
Shift+Tabで切り替わるので、作業の途中でも構いません。
一度auto modeにしたらずっとauto mode、という使い方をする必要はありません。

チームに導入する場合はどうすればよいですか

設定ファイルはリポジトリに入れて共有できます。
拒否ルールを組織側で決めておけば、各自が上書きできない形で配れます。
最初から全員をauto modeにするのではなく、拒否ルールだけ先に統一して、モードは各自の習熟度に合わせるのが現実的です。

まとめ

• auto modeでは、コマンド実行やネットワーク操作を分類器が確認する。ただし読み取りと作業フォルダ内の編集は分類器も通らない
• bypassPermissionsとは別物。auto modeでは広すぎる許可ルールが自動で外れる
• 分類器が止めるのは危険な操作。望まない操作を止めるのは今も人間の仕事
• plan、acceptEdits、autoの順に上げる。基準は慣れではなく仕組みの有無
• acceptEditsはrmも自動で通す。planもauto modeが使える環境では全部が見えるわけではない
• 戻せる、壊れたら分かる、範囲が限られている。この3つが揃ってから使う
• 拒否ルールは直接操作にしか効かない。認証情報が絡む作業ではモードを落とす

最後にもう一度だけ書きます。
auto modeは便利ですし、弊社も使っています。
ただそれは、任せてよい範囲が自分たちで分かっているからです。
そしてこの記事で見てきたとおり、auto modeは万能の安全装置ではありません。
その範囲を知る作業だけは、残念ながら省略できません。