【Claude Code実践入門 第5回】権限モードとauto mode ― 6つの権限モード、Codeタブでの権限の操作、auto modeが止めるもの・通すもの、分類器が見るのは「意図」

「確認の画面が毎回出て面倒なので、つい全部『許可』を押してしまいます」
「auto mode にしておけば、Claude が勝手に危ないことはしませんよね？」

第4回までで、作業の範囲を決め、走らせながら操縦し、CLAUDE.md で毎回の前提を渡すところまで来ました。次は、何を自由にやらせ、何で止めるか、つまり権限です。

権限は、任せる範囲を決める最後のつまみです。確認が多すぎると、中身を見ずに許可するようになり、確認の意味がなくなります。かといって確認を外しすぎると、取り返しのつかない操作まで通ってしまいます。Claude Code は、この間を 6つの権限モードで調整します。

第5回では、権限モードの違い、Code タブでの権限の操作、auto mode が止めるもの・通すもの、そして auto mode の分類器が見ているのは「意図」であって「正しさ」ではない、という点を扱います。個別のルール（allow・ask・deny）の書き方は第6回です。数値・仕様は2026年10月時点です。

---

6つの権限モード

権限モードは、確認なしで実行してよい範囲の基準を決めるものです。公式の文書でも、モードは基準の設定で、その上に権限ルール（第6回の「allow・ask・denyルールの書き方」）を重ねて、特定のツールを事前に許可したり止めたりする、と書かれています。

モード	確認なしで実行するもの	使いどころ（筆者の例）
手動（Manual）	読み取りだけ	本番の作業、慣れていない作業
編集を受け入れる（Accept edits）	読み取り、ファイルの編集、作業フォルダー内の mkdir・mv・cp・rm など	playbook や手順書を書かせて、後でレビューする
プラン（Plan）	読み取り（調査用のコマンドは、auto mode の分類器が認めたもの）	作業範囲を決める（第2回）
自動（Auto）	ほぼすべて。実行の前に別の分類器（auto mode）が1つずつ確認する	長い作業を任せきりにする（検証とセットで）
Don’t ask	事前に許可したものだけ。ほかは確認なしで拒否する	CI・夜間の処理（CLI だけ。Code タブにはない）
権限をバイパス（Bypass permissions）	すべて（確認なし）	隔離したコンテナ・VM の中だけ。Pro・Max では設定で有効にするまで選べない

「使いどころ」の列は、筆者の使い分けの例です。公式の推奨ではありません（公式が書いているのは、左の2列に当たる各モードの動きと、バイパスは隔離した環境だけで使うこと、です）。

補足：出典は公式の文書 https://code.claude.com/docs/en/permission-modes と、Claude Academy の「権限モード」です。どのモードでも、.git・.claude・.mcp.json・.bashrc などへの書き込みは、「権限をバイパス」以外では自動で承認されません。筆者の演習でも、.claude/settings.json への書き込みは確認になりました（承認が要る操作は -p では拒否されます）。

確認なしで実行されるものが狭い順に並べると、次のようになります。「Don’t ask」だけは段ではなく、確認の代わりに拒否する別の仕組みです。

モードごとの補足

公式の文書から、表に書ききれなかった点を足します。

• 編集を受け入れる：ファイルの編集に加えて、mkdir・touch・rm・rmdir・mv・cp・sed といったファイル操作の Bash コマンドも自動で承認される。ファイルの編集と同じく、承認されるのは作業フォルダー（または additionalDirectories）の中のパスだけ
  • 筆者が演習の準備プロンプトを「編集を受け入れる」で送ったとき（Claude Code 2.1.289 の CLI、claude -p）も、.claude/settings.json の書き込みと、git init・git commit などの git のコマンドは確認になった（承認が要る操作は -p では拒否される）。そのほかのファイルは確認なしで作られた
• プラン：読み取りが基本。auto mode が使えて、設定 useAutoModeDuringPlan が有効（既定で有効）なら、重要なパスの削除を除くシェルのコマンドは、確認の代わりに分類器が見る。認められたコマンドは実行され、却下されたものは止まる
• Don’t ask：作業フォルダー内のファイルの読み取りと、事前に許可したツールだけを実行し、確認が出るはずだったものはすべて拒否する。保護されたパスへの書き込みも拒否になる
• 権限をバイパス：確認なしで何でも実行する。公式は、コンテナ・VM・インターネットに出られない dev container のような、Claude Code がホストを壊せない隔離した環境だけで使うよう書いている。プロンプトインジェクションや意図しない操作への保護は無い。有効にしないで始めたセッションの途中からは入れないので、permissions.defaultMode に "bypassPermissions" を設定するか、起動時のオプション（--permission-mode bypassPermissions。--dangerously-skip-permissions も同じ）で始める。初めてこのモードを有効にして対話のセッションを始めると、確認なしの操作の責任を負うことに同意する警告が出る
• 保護されたパス：保護されたディレクトリは .git と .claude（いくつか例外がある）、保護されたファイルは .bashrc・.mcp.json・.claude.json など。「手動」と「編集を受け入れる」では確認になり、Don’t ask では拒否になる。「自動」では分類器が判断する。「プラン」では、auto mode が使えるときは分類器が判断し、使えないときは確認になる（「権限をバイパス」を使える対話のターミナルのセッションでは、プランでも確認なしで許可される）

Code タブと CLI の違い

Code タブで選べるモードは、公式の文書の比較表では「手動」「編集を受け入れる」「プラン」「自動」の4つです。CLI は Don’t ask を含むすべてのモードを選べます。「権限をバイパス」は、有効にしたあとでモードの選択に現れます。有効にする方法は、次の節で説明します。

CLI では、Shift＋Tab でモードを切り替えます。auto から始まったセッションで最初に押すと「手動」になり、その後は「手動」→「編集を受け入れる」→「プラン」の順に回ります（プランの後に、有効にしたモードが続きます）。第2回の「Codeタブでのプランモード」の「CLI では」と同じ内容です。Code タブの切り替え方は、次の節です。

---

Code タブでの権限の操作

Code タブでの権限の操作を、順に見ます。

• モードの切り替え：入力欄の下のモード表示から選ぶ、または Ctrl＋Shift＋M（第2回の「Codeタブでのプランモード」で紹介した、プランモードの切り替えと同じ方法）
• 既定のモード：新しいセッションの始まりのモードは、アカウントや設定で変わる。筆者の個人のアカウントでは、新しいセッションは「自動」から始まった（2026-10-04 の記録）
  • 公式の文書も、Claude Code v2.1.283 以降では、auto mode が、ターミナルと VS Code の対話のセッションの始まりのモードになる、と書いている（どのプランでも）。始めのモードを決めるときは、設定の permissions.defaultMode を使う
• 確認の画面：「手動」では、コマンドの実行やファイルの変更の前に確認が出る。筆者の環境では、ファイルの変更では、その場で差分も表示された
• 3つの選択肢：筆者の環境では、確認の画面に「拒否」（Esc）、「常に許可」（Ctrl＋Shift＋Enter）、「一度だけ許可」（Ctrl＋Enter）が並んだ。迷ったら「一度だけ許可」
  • この選択肢とショートカットは、公式の文書には見当たらず、筆者の環境の記録（2026-10-04、Code タブ 2.1.284）
  • 公式の文書には、確認の画面が一度だけの承認しか出さないこともある、とある。保存するルールが許すことになる範囲を画面ですべて示せるときだけ、「今後は確認しない」などの選択肢を出すため（https://code.claude.com/docs/en/permissions ）
• 「常に許可」の保存先：リポジトリの .claude/settings.local.json に、そのコマンドだけに一致するルール（例：Bash(ansible-playbook -i inventory/stg site.yml)）が書かれる。オプションが1つ違えば、また確認が出る
  • 公式の文書（CLI の「Yes, and don’t ask again」）も、Bash のコマンドや WebFetch のドメインのように永続的に保存される承認は、git リポジトリのルートの .claude/settings.local.json に保存される、と書いている。一方、ファイルの変更の承認は、ファイルには保存されず、セッションが終わるまで有効
• /permissions は使えない：Code タブでは「この環境では使えない」と表示される。公式の文書にも、ターミナルで対話のパネルを開くコマンドのうち、/permissions のように引数の形が無いものは isn't available in this environment と返る、と書かれている。ルールは .claude/settings.json を直接編集する（Claude に編集させてもよい）
• 「権限をバイパス」：Pro・Max では、設定の Claude Code にある「Allow bypass permissions mode」（公式の文書の表記）を有効にすると、モードの選択に現れる。Team・Enterprise では設定の切り替えは無く、組織のポリシーが決める。使うのは、サンドボックス化したコンテナや VM の中だけ
• 「自動」（auto mode）：公式の文書では、すべてのプラン（All plans）で使える（2026年10月時点）

補足：出典は公式の文書 https://code.claude.com/docs/en/desktop と https://code.claude.com/docs/en/permissions です。

auto mode が使える条件

公式の文書は、auto mode が使えるのは、次の条件を満たすアカウントだけ、と書いています（2026年10月時点）。

• プラン：すべてのプラン
• 組織：Team と Enterprise では、既定で使える。管理者は、管理された設定の permissions.disableAutoMode を "disable" にして、組織で無効にできる
• モデル：Anthropic API と Claude Platform on AWS では、Claude Opus 4.6 以降、Sonnet 4.6 以降、Haiku 5.5、または Fable のモデル

個人の Pro・Max では、組織の設定は関係しません。組織のプランで auto mode や「権限をバイパス」が選べないときは、管理者の設定（disableAutoMode、disableBypassPermissionsMode）かもしれません。

---

auto mode が止めるもの・通すもの

auto mode は、Claude が何かを実行する前に、別の分類器のモデルがその操作を確認し、危ないものを止める仕組みです。何を止めて何を通すかは、既定の一覧があります。

区分	例
既定で止める（インフラ関係）	本番へのデプロイやマイグレーション、terraform destroy、DNS・TLS の変更、シークレットの保管庫への書き込み、IAM の権限付与、クラウドのメタデータ（169.254.169.254）へのアクセス
既定で止める（そのほか）	force push、git reset –hard、取得したコードをそのままシェルに流す、機密データを外部へ送る、作業の前からあったファイルを取り返しのつかない形で壊す
通す	プロジェクト内の編集、ロックファイルからの依存関係のインストール、読み取り、作業中のリポジトリへの push（既定のブランチも含む。デプロイや公開先とわかる名前の枝は除く）
手動の確認に戻る	3回続けて、または合計20回止められたとき

補足：出典は公式の文書 https://code.claude.com/docs/en/permission-modes と、Claude Academy の「権限モード」です。止める対象の一覧は変わることがあるため、最新の一覧は claude auto-mode defaults（CLI。完全なルールの一覧を JSON で出力する）や公式の文書で確認してください。

公式の文書にある、表に載せなかった項目

表は要点です。公式の文書の「Blocked by default」と「Allowed by default」から、そのほかの項目を足します。

既定で止めるもの

• 本番へのデプロイやマイグレーション、共有のインフラの変更、IAM やリポジトリの権限の付与
• シークレットの保管庫への書き込み、DNS レコードや TLS 証明書の変更
• curl | bash のように、取得したコードをダウンロードして実行すること
• 機密データを外部のエンドポイントへ送ること、クラウドのストレージの大量削除
• force push
• セッションの前からあったファイルの、取り返しのつかない破壊
• git reset --hard、git checkout -- .、git restore .、git clean -fd、git stash drop、git stash clear。分類器は、コミットしていない変更を捨てるものとみなす
• terraform destroy、pulumi destroy、cdk destroy、terragrunt destroy。リソースを消す plan の適用も同じ
• クラウドのインスタンスのメタデータのエンドポイント（169.254.169.254 など）に認証情報を求めること、またはクラウド・クラスター・レジストリへの呼び出しを、そのマシン自身のサービスアカウントやノードの ID で認証すること。Claude Code v2.1.257 以降は、これも既定で止める
• 人が承認していない pull request をマージすること、Claude 自身の pull request を承認すること、CI のチェックを無効にすること

既定で通すもの

• 作業フォルダーの中のローカルのファイル操作
• ロックファイルやマニフェストに書かれた依存関係のインストール
• 読み取り専用の HTTP リクエスト
• 作業中のリポジトリのどのブランチへの push も（既定のブランチを含めて）。ただし、production や gh-pages のように、デプロイや公開先とわかる名前の、既定ではないブランチは対象外

手動の確認に戻る条件

• 分類器が同じ作業を3回続けて、または合計20回止めたとき、auto mode は一時停止し、Claude Code は確認を出す状態に戻る

ここで気づくのは、「通す」に既定のブランチへの通常の push が入っていることです。force push は止まりますが、普通の git push は通ります。push の前に必ず確認が欲しいなら、auto mode に任せず、ask のルールで書きます（第6回の「Ansibleの作業での設定例（筆者の例）」の Bash(git push *)）。

---

分類器が見るのは「意図」で「正しさ」ではない

auto mode では、Claude が何かを実行する前に、別の分類器のモデルがその操作を確認します。分類器が見ているのは、頼まれた範囲を超えて危険な方向に進んでいないかという「意図」です。公式の文書の言い方では、依頼を超えて話を大きくするもの、見覚えのないインフラを対象にするもの、Claude が読んだ敵対的な内容に操られているように見えるものを止めます。

コードや設定が正しく動くかどうかは、見ていません。 たとえば、NTP の設定変更を頼み、Claude が参照先のアドレスを間違えた playbook を書いたとします。間違った設定は危険な操作ではないので、分類器はそのまま通します。そのため、auto mode は、終わった後に正しさを確かめる仕組みと組み合わせて使います（第7回の「検証を強制する4段階」「フックで止める」）。

• 分類器は危険な意図を止めるが、正しさは見ない。間違った設定はそのまま通る
• auto mode は、正しさを確かめる検証（第7回の「検証を強制する4段階」）と組み合わせる
• 会話で伝えた制限はコンパクトで消えることがある。続けて守らせるなら deny ルールに書く

会話で伝えた制限は消えることがある

もう1つ注意があります。会話の中で「push はしないで」と伝えると、分類器はそれを止める理由として使います。公式の文書にも、「push しないで」「私がレビューするまでデプロイを待って」のように会話で伝えた境界を、分類器は止める合図として扱い、既定のルールが通すはずの操作でも止める、と書かれています。

しかし、この指示はコンパクトで消えることがあります。境界はルールとして保存されるのではなく、分類器が確認のたびに会話の記録から読み直します。そのため、コンテキストの圧縮（compaction）が、その境界を書いたメッセージを取り除くと、境界は失われます。長い作業でずっと守らせたい制限は、会話で伝えるのではなく、deny ルールとして設定ファイルに書いてください。公式の文書も、確実な保証がほしいなら deny ルールを足すように書いています。書き方は第6回の「allow・ask・denyルールの書き方」で扱います。

分類器のモデルと使用量

• 分類器は、/model で選んだモデルではなく、既定では Claude Sonnet 5 で動く
• 読み取りと、保護されたパスの外にある作業フォルダー内の編集は、分類器を通らない。分類器の負荷がかかるのは、主にシェルのコマンドとネットワークの操作
• 公式の文書では、Enterprise のプランと、Claude API・Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry などを使うアカウントでは、分類器の呼び出しがトークンの使用量に数えられると書かれている。ただし、サーバー側で確認が行われるセッション（server-side classifier review）では、確認はモデルのリクエストの一部として行われ、別の分類器の呼び出しは発生しない
• Pro・Max・Team については、Anthropic が2026年8月7日の公式ブログで、分類器の分のトークンを課金しないと発表している（Auto mode is now the default in Claude Code for Pro, Max, and Team plans）。課金の案内のページも、Pro・Max・Team では分類器の課金の通知は出ないと書いている

---

考えてみよう

1. いま使っている Claude Code の新しいセッションは、どのモードで始まりますか。「手動」に切り替えてから、ファイルを編集させる依頼と、コマンドを実行させる依頼を1つずつ出し、確認の画面にどんな選択肢が出るか見てみてください。
2. 「push はしないで」と会話で伝えて長い作業を任せるとします。この制限が途中で守られなくなる可能性があるのはなぜですか。確実に守らせるには、どこに何を書きますか。
3. 次の操作のうち、auto mode の分類器が止めそうなものと、通しそうなものを分けてください。①git reset --hard ②NTP の参照先のホスト名を1つ間違えた playbook の保存 ③既定のブランチへの通常の git push ④terraform destroy。通しそうなもので、困るものがあれば、何で防ぎますか。

ヒント：1は「Code タブでの権限の操作」、2は「会話で伝えた制限は消えることがある」、3は「auto mode が止めるもの・通すもの」の節を見直してください。

---

まとめ

• 権限モードは確認なしで実行する範囲の基準。「手動」（読み取りだけ）から「権限をバイパス」（すべて）まで6つあり、「Don’t ask」は確認の代わりに拒否する別の仕組み
• どのモードでも、.git・.claude・.mcp.json・.bashrc などへの書き込みは、「権限をバイパス」以外では自動で承認されない
• Code タブでは、入力欄の下のモード表示か Ctrl＋Shift＋M で切り替える。迷ったら「一度だけ許可」。「常に許可」は .claude/settings.local.json に、そのコマンドだけのルールを書く。/permissions は使えない
• auto mode は、公式の文書ではすべてのプランで使える（2026年10月時点）。インフラの破壊・本番へのデプロイ・force push などを既定で止めるが、既定のブランチへの通常の push は通る
• 分類器が見るのは意図で、正しさは見ない。間違った設定はそのまま通るので、検証とセットで使う
• 会話で伝えた制限は、コンパクトで消えることがある。長く守らせたい制限は、deny ルールに書く

この回の内容は、第8回の演習の手順3（「編集を受け入れる」への切り替え）と、第9回の演習の手順6（「手動」のまま stg への本実行を頼み、確認の画面を見る）で試せます。

次回は、allow・ask・deny のルールの書き方、前方一致の落とし穴、設定ファイルの階層、Ansible の作業での設定例を扱います。

---

連載「Claude Code実践入門」全9回

1. 任せる前に知っておくこと
2. 作業範囲を決める
3. 走らせながら操縦する
4. CLAUDE.mdを育てる
5. 権限モードとauto mode（この記事）
6. allow・ask・denyのルールと設定ファイル
7. 検証で終わらせる
8. 演習（前編）：準備から実装と検証まで
9. 演習（後編）：巻き戻し・差分・権限と振り返り