はじめに

同じClaude Codeを使っていても、「確認プロンプトばかりで作業が一向に進まない人」と、「気づいたら触ってほしくない場所まで自動でいじられた人」がいます。この差は、たいてい権限モードの選び方で説明がつきます。

コーディングエージェントを使っていると、どのツールでも必ずぶつかる問いがあります。「どこまで勝手に走らせて、どこで止めて確認させるか」です。Devinにもplanモードやaskモードがあって、走らせすぎないための仕組みが用意されています。同じ問いに、Claude Codeは6つの権限モードと、auto modeという"番人つきの自動実行"で答えを出してきました。

DevinのバックにはClaudeのモデルがいます。だからClaude Code側がエージェントの自律性をどう安全に上げているかは、Devinユーザーにとっても対岸の話ではないと思っています。特に面白いのがauto modeで、ここには専用のclassifier（判定用の別モデル）が入っていて、コマンドが実行される前に一つひとつ「これは通していいか」を判断しています。

この記事では、まず6つのモードをざっと押さえたうえで、auto modeのclassifierが何を見て、どんな順番で許可とブロックを決めているのかを掘っていきます。公式ドキュメントに「How the classifier evaluates actions（classifierはどうアクションを評価するか）」という項があって、ここがいちばんの読みどころです。

先に3行でまとめると

Claude Codeの権限モードは6種類。オーバーサイト重視のManualから、全部止めずに走らせるbypassPermissionsまで一直線に並ぶ
目玉はauto mode。専用classifierが実行前に各アクションを審査し、要求を超える危険な操作だけを止める
classifierには決まった判定順序がある。ルール → 読み取り/編集の自動承認 → それ以外はclassifier、の3段構え

この記事に出てくる用語の位置づけ

Claude Code独自の呼び名と、AI記事で一般に使う言葉が混ざります。先に整理しておくので、迷ったらここに戻ってきてください。

用語	位置づけ	ざっくりの意味
権限モード（permission mode）	Claude Code独自	何を確認なしで実行してよいかを決める設定。6種類ある
auto mode	Claude Code独自	classifierの審査つきで、許可プロンプトを出さずに走るモード
classifier	Claude Code独自	アクションを実行前に審査する判定専用モデル
protected paths（保護パス）	Claude Code独自	`.git` や `.claude` など、自動承認されない特別なパス群
allow / ask / deny ルール	Claude Code独自	ツールごとに事前許可・要確認・禁止を決める権限ルール
Manual（default）	Claude Code独自	全アクションを毎回確認する最も慎重なモード。設定値は `default`
オーバーサイト	一般用語	人間による監督・目視確認のこと
プロンプトインジェクション	一般用語	外部から読み込んだ内容でAIを不正に操る攻撃
サブエージェント	一般用語	親セッションが仕事を委譲する子エージェント

固有名詞（Claude Code独自）は「この製品の世界でだけ通じる言葉」、一般用語は「他社のAI記事でも出てくる言葉」と考えてください。

権限モードは6種類

まず全体像です。6つのモードは「どこまで確認なしで実行してよいか」の一本の軸に並びます。左に行くほど人間が見張り、右に行くほどエージェントに任せる、という並びです。

表にすると、それぞれが「確認なしで動く範囲」で性格がはっきり分かれます。

モード	確認なしで動く範囲	向いている場面
`default`（Manual）	読み取りのみ	使い始め、慎重にいきたい作業
`acceptEdits`	読み取り＋ファイル編集＋よく使うファイル操作（`mkdir` `mv` `cp` など）	レビューしながらコードを回すとき
`plan`	読み取り＋（auto mode利用時は）classifier承認済みコマンド	変更前にコードベースを調べるとき
`auto`	すべて。ただしバックグラウンドの安全チェックつき	長い作業、確認疲れを減らしたいとき
`dontAsk`	事前承認したツールだけ	ロックダウンしたCIやスクリプト
`bypassPermissions`	すべて（チェックなし）	隔離されたコンテナ・VM専用

CLIやVS Code拡張、デスクトップアプリでは、default は Manual という名前で表示されます。設定ファイルやSDKからは default を使いますが、claude --permission-mode manual のように manual という別名でも指定できます（別名の対応はv2.1.200以降）。

モードの切り替えは、Claudeにチャットで頼むのではなく、専用の操作でおこないます。CLIなら Shift+Tab で default → acceptEdits → plan を循環。起動時なら claude --permission-mode plan のようにフラグで渡します。恒久的なデフォルトにしたいなら、設定ファイルに書きます。

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

auto・dontAsk・bypassPermissions はこの循環に自動では入りません。auto modeはアカウントが要件を満たすと循環に現れ、bypassPermissionsは起動時に有効化したときだけ、dontAskは循環には出ずフラグ指定のみ、という具合です。

あなたはどのモードを使うべきか

6つ並ぶと迷いますが、日常で実際に使うのは2〜3個です。場面から選ぶと、だいたいこう収まります。

こんなとき	おすすめモード	ひとこと
使い始め、機微なコードを触る	`default`（Manual）	まず全部見て、慣れたら緩める
差分をレビューしながら回す	`acceptEdits`	編集は任せ、`git diff` で後追い確認
変更前に方針を固めたい	`plan`	壊さず調べさせて計画を作る
長い作業をまるごと任せたい	`auto`	番人つきで確認疲れを減らす
CI・自動化スクリプト	`dontAsk`	事前許可以外は即拒否で待たない
隔離コンテナ・VM限定	`bypassPermissions`	それ以外の場所では使わない

個人的に落ち着いているのは、auto を土台にしつつ「pushとPR作成だけは必ず確認」に寄せる形です。任せる範囲は広げたいけれど、外に出ていく操作だけは目視したい、という欲張りをそのまま設定にできます。~/.claude/settings.json にこう書きます。

{
  "permissions": {
    "defaultMode": "auto",
    "ask": ["Bash(git push *)", "Bash(gh pr create *)"]
  }
}

このバランスの意味を理解するためにも、ここから先はauto modeの中身を詳しく見ていきます。

auto modeは"番人つきの全自動"

auto modeは、いちいち許可を求めずにClaudeを走らせるモードです。とはいえ野放しではありません。裏で別のclassifierモデルがアクションを実行前に審査していて、次のようなものをブロックします。

あなたの要求を超えてエスカレートする操作
見覚えのないインフラをターゲットにする操作
Claudeが読み込んだ悪意ある内容に誘導された気配のある操作

明示的なaskルールがあれば、auto modeでもちゃんと確認プロンプトが出ます。

公式は「auto modeは許可プロンプトを減らすが、安全を保証するものではない」とはっきり書いています。方向性を信頼できるタスクで使うものであって、機微な操作のレビューを丸ごと肩代わりするものではない、という位置づけです。

ひとつ知っておきたいのが、2026年8月14日から、Pro・Max・Teamプランの新規セッションではauto modeがデフォルトの権限モードになるという告知です（自分で設定したデフォルトは、一度だけ出る切り替え確認を承認しない限り維持され、組織が管理するデフォルトは変わりません）。つまりこれから多くの人にとって、auto modeは「わざわざ選ぶモード」ではなく「最初からそこにいるモード」になります。だからこそ、その番人が何を見ているかを知っておく価値があります。

classifierの判断順序

ここが本題です。classifierは思いつきで判断しているわけではなく、決まった順序でアクションを評価します。上から順に見ていって、最初に当てはまったステップで結論が出る、という仕組みです。

言葉にするとこうです。

まず、あなたのallow / ask / denyルールに一致するアクションはその場で確定します。ただし保護パスへの書き込みは、allowルールに一致してもclassifierに回されます。組織が ask に設定したコネクタツールや、requiresUserInteraction が付いたMCPツールは、allowに一致しても直接あなたに確認します
読み取り系のアクションと、作業ディレクトリ内のファイル編集は自動承認されます（保護パスへの書き込みは除く）
それ以外はすべてclassifierに回されます
classifierがブロックしたら、Claudeは理由を受け取って別の手段を試します。多くのセッションでは、その理由は固定文言の Blocked by classifier です（v2.1.208以降）

面白いのは、auto modeに入った瞬間、任意コード実行を許してしまう"広すぎるallowルール"が無効化される点です。Bash(*) や PowerShell(*)、Bash(python*) のようなワイルドカード付きインタプリタ、パッケージマネージャの実行コマンド、Agent のallowルールなどが対象です。一方 Bash(npm test) のような具体的なルールはそのまま生きます。無効化されたルールは、auto modeを抜けると元に戻ります。

そしてセキュリティ設計として上手いのが、classifierが見る範囲です。classifierはユーザーのメッセージ、ツール呼び出し、そして CLAUDE.md の内容を見ますが、ツールの実行結果は取り除かれます。つまりファイルやWebページに仕込まれた悪意ある内容が、classifierを直接操ることはできません。加えてサーバー側の別のプローブが、Claudeが読む前に届いたツール結果をスキャンして怪しい内容をフラグ立てします。番人自身が汚染されないように、そもそも汚染源を見せない作りになっています。

会話で伝えた境界も、ブロックの合図になる

ルールを書かなくても、会話の中で言った制約はそのまま効きます。「まだpushしないで」「レビューするまでデプロイは待って」とClaudeに伝えると、classifierはデフォルトなら許すはずの操作でもブロックします。境界は、あとのメッセージで自分が解除するまで有効です。「条件を満たした」というClaude自身の判断で勝手に解除されることはありません。

ただしこの境界はルールとして保存されるわけではなく、classifierが毎回トランスクリプト（会話履歴）から読み直しています。だからコンテキストの圧縮でその発言が消えると、境界も失われる可能性があります。確実に守らせたいなら、会話で言うのではなくdenyルールを足すのが堅実です。

サブエージェントは3つのタイミングで見張られる

Claudeがサブエージェントに仕事を委譲するときも、classifierはちゃんと目を光らせています。チェックは3ヶ所です。

開始前のタスク内容の審査（①）はv2.1.178以降で、危険そうな委譲を起動の時点で止められます。実行中（②）は、サブエージェントのフロントマターに書かれた permissionMode は無視され、親と同じルールで審査されます。子だけこっそり緩める、ができないわけです。

auto modeが自動実行を諦めるとき

番人が働きすぎて、かえって邪魔になることもあります。そのための引き際も決まっています。classifierが3回連続、または合計20回ブロックすると、auto modeは一時停止して、Claude Codeは普通に許可プロンプトを出す状態に戻ります。プロンプトを承認すればauto modeが再開します。このしきい値は変更できません。

連続カウンタは、許可されたアクションが1つでもあればリセットされます。合計カウンタはセッション中ずっと積み上がります。ちなみに -p を使う非対話モードでは、聞く相手がいないので、ブロックが続くとセッションごと打ち切られます。

拒否が続くのは、たいていclassifierがあなたのインフラの文脈を知らないからです。この「教えてあげる」設定は次の記事のテーマなので、ここでは「詰まったらインフラを登録すれば直ることが多い」とだけ覚えておいてください。

コストとレイテンシの話

classifierは、あなたが /model で選んだモデルではなく、既定でClaude Sonnet 5で動きます（Anthropicがサーバー側で別のclassifierモデルを指定していれば、そちらが優先されます）。

Enterpriseプランや、Claude API・各クラウドプロバイダを使うアカウントでは、classifierの呼び出しがトークン使用量に計上されます。各チェックはトランスクリプトの一部と実行しようとしているアクションを送るので、実行前に往復が1回増えます。ただし読み取りと作業ディレクトリ内の編集（保護パス以外）はclassifierを通らないので、オーバーヘッドの主役はシェルコマンドとネットワーク操作です。裏で頻繁に走るぶん、ゼロコストではない、というのは頭の隅に置いておくとよいです。

使う前に押さえておくこと

auto modeは全プランで使えますが、いくつか要件があります。Team・Enterpriseでは既定で利用可（管理者が permissions.disableAutoMode を "disable" にすればオフにできます）。モデルは、Anthropic APIとClaude Platform on AWSではOpus 4.6以降・Sonnet 4.6以降・Fable 5、Bedrock/Google Cloud/Microsoft FoundryなどではSonnet 5・Opus 4.7以降・Fable 5が対象です。Sonnet 4.5やOpus 4.5、Haiku、claude-3系は対象外です。

もし defaultMode: "auto" を設定したのにdefaultモードで起動する場合、その設定がプロジェクトの .claude/settings.json に書かれている可能性が高いです。v2.1.142以降は、リポジトリが自分にauto modeを付与できないよう、プロジェクト設定からの auto を無視します。~/.claude/settings.json に移してください。

やりがちな失敗

最後に、権限モードまわりで踏みがちな地雷をまとめておきます。どれも本文で触れた話ですが、失敗の形で並べたほうが避けやすいはずです。

やりがちな失敗	なぜまずいか	どうする
`bypassPermissions` を普段使いにする	全チェックが無効。プロンプトインジェクションに無防備	隔離環境だけに限定し、普段は `auto`
`.claude/settings.json` に `defaultMode: "auto"` を書く	プロジェクト設定からは無視され、`default` で起動する	`~/.claude/settings.json`（ユーザー設定）に書く
会話で「pushしないで」と言って安心する	圧縮でその発言が消えると境界も失われる	恒久的に守るなら `deny` / `ask` ルール
auto mode＝安全、と思い込む	公式も「安全は保証しない」と明記している	機微な操作は自分の目でレビューする

とくに2つめは、私も最初にやりました。リポジトリに設定を置けば効くだろうと .claude/settings.json に auto を書いて、いつまでもdefaultのまま起動して首をかしげる、という定番の落とし穴です。

おわりに

auto modeのclassifierを追っていて感心したのは、「自律性を上げる」と「安全を保つ」を、根性論ではなく仕組みで両立させにいっている点でした。決まった判定順序があり、番人自身は汚染源を見ず、行きすぎたら自分で引く。どれも派手さはないけれど、エージェントに任せる範囲を広げるうえで地味に効く設計です。

Devinのplan/askモードもそうですが、コーディングエージェントの成熟は結局「どこまで安心して手を離せるか」に集約されていく気がします。次の記事では、このclassifierに「うちのインフラは信頼していい」と教えて、余計なブロックを減らすための設定（auto-mode-config）を掘ります。デフォルトのままだと自社リポジトリへのpushすら止められることがあるので、実務で使うならセットで読んでおくと効きます。

🚀 Devin専門の解説メディア「StartDevin」を運営中！
Devinの導入・使い方・最新アップデート・活用事例を、日本語でまとめています。
👉 StartDevin をチェックする（startdevin.jp）

この記事にぜひ いいね❤️ していただけると励みになります 🙌

参考リンク

Choose a permission mode（Claude Code公式ドキュメント）（一次情報。6モードとclassifierの判定順序）
Configure auto mode（Claude Code公式ドキュメント）（次の記事で扱う設定リファレンス）
Permissions（allow / ask / denyルール）