Claude Code権限モデルの変遷 — なぜ確認せずに動くようになったのか

Claude Codeの権限モデルは、2025年2月の公開時点では「既定で読み取り専用、変更は毎回ユーザーに確認」でした。それから約1年半後の2026年8月、v2.1.228でPro・Max・Teamプランの既定はauto modeになりました。9月のv2.1.284以降は、ターミナルとVS Code拡張の既定がプランを問わずauto modeです。正反対に見えるこの2つの設計は、実は同じ問題への答えです。この記事では、その間に挟まった3つの発明 — 権限ルール、サンドボックス、分類器 — を時系列で追い、「なぜ確認しなくなったのか」に答えます。

出発点 — 既定で読み取り専用、変更は全部きく

Claude Codeは2025年2月24日、Claude 3.7 Sonnetの発表と同時にリサーチプレビューとして公開されました。当初の権限モデルは単純です。既定では読み取りだけが許され、ファイルの変更とコマンドの実行は原則すべてユーザーの承認を待ちます。echoやcatのような安全なコマンドだけが自動許可の例外でした。

この設計は安全側に倒した出発点としては正しく、一方で使うほどに問題が見えてきます。エージェントが自律的に働くほど承認ダイアログの回数は増え、ユーザーは内容を読まずに承認し始める。Anthropicはのちに、許可プロンプトの93%が承認されているという計測を公開しています。ほぼ全部通すのに毎回きくのは、安全装置として機能していません。以降の変遷は、この「承認疲れ」をどう解消するかの積み重ねです。

ルールの時代 — allow・ask・denyで例外を書く

最初の答えは「例外をユーザーに書かせる」でした。v0.2.26(2025年2月)で承認済みツールを管理する/approved-toolsコマンドが入り、v0.2.67ではプロジェクト共有の権限ルールを.claude/settings.jsonに保存できるようになります。v1.0.7(2025年5月30日)では/allowed-toolsが/permissionsに改名され、allowedToolsの設定も.claude.jsonからsettings.jsonへ移りました。

ルールは今も権限モデルの土台です。評価の順番はdeny、ask、allowで、最初に一致したものが結果を決めます。内容で一致するaskルール(Bash(git push *)など)は、後述のauto modeでも確認に落ちます。ただし、ルールだけでは承認疲れは解けませんでした。Bash(npm test)のような前方一致で書ける操作は限られ、初めての操作は結局すべてダイアログに落ちるからです。ルール設計の実践はClaude Code settings.json完全ガイドにまとめています。

Readのdenyルールは同じパスへのEdit・Writeも塞ぐ仕様のため、意図せず編集まで止まることがあります。この挙動とNotebookEditが対象外になる理由は「Read deny rule」エラーの対処で扱っています。

境界の時代 — サンドボックスの二層分離

2025年10月20日、Anthropicは発想を変えた2つ目の答えを出します。操作ごとに許可を判断するのではなく、先に「安全に動ける範囲」を引いてしまい、その内側では確認しない。v2.0.24で入ったBashツールのサンドボックスです。

境界は2本あります。ファイルシステム分離は作業ディレクトリの外への書き込みを遮断し、ネットワーク分離は許可されたホスト以外への接続をプロキシで止めます。片方だけでは不十分で、両方そろって初めてプロンプトインジェクションを受けても被害が外へ出ない構造になる、というのが設計の核心です。Anthropicは社内利用で許可プロンプトが84%減ったと報告しており、詳細はClaude Codeのサンドボックス設計で解説しています。

サンドボックスの意義は「許可の判断を減らしたのではなく、判断が要らない空間を作った」点にあります。ただし境界の外に出る操作 — 本番への接続、外部ドメインへの送信 — は相変わらずユーザー確認に落ちます。承認疲れの最後の一角は残りました。

判定の時代 — auto modeの分類器

3つ目の答えが、確認の主体そのものを置き換える発明でした。2026年3月25日にengineering blogで公開されたauto modeは、ユーザーの代わりに別のモデル(分類器)がツール呼び出しを審査します。読み取りと、保護パスを除く作業ディレクトリ内の編集は素通しです。それ以外は分類器に回し、要求の範囲を超える操作・見覚えのないインフラへの操作・読み込んだ敵対的コンテンツに駆動された操作をブロックします。サーバー側で審査するセッションでは、読み取り専用のシェルコマンドも審査を待ちます。設計の全体像はClaude Code auto modeの中身、運用者が書き換えられるルール層はauto mode分類器は何を止めているかで扱っています。

分類器のルールはユーザーが見られます。claude auto-mode defaultsは、組み込みのルールをJSONで出力するコマンドです。v2.1.289で実行すると、次の内訳が出力されます(モデルは呼ばれません)。

claude auto-mode defaults | python3 -c "import sys,json; [print(k, len(v)) for k,v in json.load(sys.stdin).items()]"

allow 17
soft_deny 72
hard_deny 1
environment 21

hard_denyの1件は、信頼する範囲の外へ機密データが出る操作を止める「Data Exfiltration」です。soft_denyの72件には、Git Destructive(共有ブランチへの強制pushなど)、Production Deploy、Permission Grantといった名前のルールが並びます。ルールの上書き方法は上で挙げた記事にあり、claude auto-mode configで自分の設定を反映した結果も確かめられます。

起動の敷居は公開後に段階的に下がりました。フラグ不要化、同意画面の撤廃、クラウド各社での解禁の順は、後の年表にまとめています。

既定化 — v2.1.228から「聞かない」が標準になった

2026年8月11日のv2.1.228で、Pro・Max・TeamプランのセッションはmacOS・Linux・WSLで既定からauto modeで始まるようになりました。ネイティブWindowsはv2.1.233で続きます。それ以前のバージョンでは、組み込みの既定はManualです。約1年半かけて、権限モデルの既定は「全部きく」から「分類器が見る」へ反転しました。この転換点はv2.1.228のリリースノートでも触れています。

v2.1.228の時点で既定化の対象だったのは、Pro・Max・Teamプランの、フィーチャーフラグを取得するセッションだけでした。EnterpriseプランやAPIキー、サードパーティプロバイダでは、Manualのままです。その線は9月に外れていきます。

• v2.1.283(9月25日): サードパーティプロバイダ、またはテレメトリ無効のインタラクティブセッションも、権限モードが未設定ならautoで始まる
• v2.1.284(9月28日): ターミナルとVS Code拡張が、全プラン・全プロバイダで未設定ならautoで始まる
• v2.1.285(9月29日): claude -pとPython Agent SDKも、サードパーティプロバイダ・テレメトリ無効のセッションではautoで始まる

いま残っている区切りは、プランではなく起動経路です。claude -pとAgent SDKは、フィーチャーフラグを取得するセッションではManual(default)で始まります。組織のポリシーがautoの既定を見送らせている場合も、Manualです。

起動時のモードは、次の順で最初に当てはまるものが決めます。

v2.1.289のclaude --helpは、--permission-modeの選択肢を次のように出力します。

claude --help | grep -A3 -e "--permission-mode"

  --permission-mode <mode>              Permission mode to use for the session
                                        (choices: "acceptEdits", "auto",
                                        "bypassPermissions", "manual",
                                        "dontAsk", "plan")

インストール直後の最初のセッションは、フィーチャーフラグが届く前に始まるため、上の順どおりにならないことがあります。既定でautoが初めて適用されるときは、端末では最上部に1回、VS Code拡張では新規会話画面のカードで通知されます。~/.claude/settings.jsonに別のdefaultModeがある場合は、その設定が優先されます。このとき、autoへ変えるかを一度だけ尋ねられます。対象はPro・Max・Teamプランと、フィーチャーフラグを取得しないセッション(サードパーティプロバイダ・テレメトリ無効)です。

auto modeの分類器に判定を委ねず、事前許可したツール呼び出しだけを実行して他は全部拒否したい場合はdontAskモードを選びます。v2.1.259で入った--permission-prompts noneは別の道具で、モードはそのままに、確認が必要になる操作だけを自動で拒否します。CI組み込みの手順とつまずきどころはClaude Code dontAskモードとはにまとめています。

変遷をバージョンで振り返る

判定の軸は「コマンドの形」から「会話の文脈」へ移った

この1年半で変わったのは確認の回数だけではありません。何を根拠に許可を判断するかが入れ替わっています。

会話で述べた境界も、分類器は判定材料にします。「レビューまでpushしないで」と書けば、ルールに無くてもブロック信号として扱われます。ただし、この境界は保存されたルールではありません。分類器が毎回、会話の記録から読み直しています。コンテキストの圧縮でその発言が消えると、境界も失われます。確実に止めたい操作は、denyルールに書く必要があります。

承認の側にも同じ性質があります。「force-pushしていいよ」と動詞だけを伝えても、ブロックは解除されません。操作とその危険の源(どのブランチへの強制pushか)まで名指しすると、その1回に限って通ります。繰り返す定型の操作は、autoMode.allowに書く運用です。

象徴的なのは、auto modeに入るとBash(*)のような広範なallowルールが一時停止される仕様です。auto modeを抜けると、停止されたルールは戻ります。ユーザーが自分で書いた「全部許可」よりも、文脈を読む分類器の判定を優先する設計です。一方でこの構造は、判定の正しさが分類器の精度に依存することも意味します。誤ブロックが3回連続または累計20回に達するとauto modeは一時停止して従来の確認に戻る、というフォールバックが用意されているのは、その依存への保険です。この2つの閾値は設定で変えられません。

よくある質問

昔のように毎回確認する動作に戻せますか

戻せます。セッション中はShift+TabでManualモードに切り替えられ、~/.claude/settings.jsonのpermissions.defaultModeに"default"を設定すれば毎セッションManualで始まります。手順の詳細は自動承認をオフにする手順にまとめています。

bypassPermissionsとauto modeは何が違いますか

bypassPermissionsは分類器を含む安全チェックを無効化して即実行するモードで、コンテナやVMなど隔離環境専用と位置付けられています。auto modeは確認を省く代わりにシェルコマンドなど審査対象の操作すべてに分類器が入る点で別物です。

分類器の判定にもトークン料金がかかりますか

EnterpriseプランとClaude API、Claude Platform on AWS、Bedrock、Vertex(Google CloudのAgent Platform)、Foundry経由の利用では、分類器の呼び出しがトークン使用量に計上されます。読み取りと、保護パスを除く作業ディレクトリ内の編集は分類器を通らないため、上乗せは主にシェルコマンドとネットワーク操作で発生します。サーバー側で審査するセッションでは、別個の分類器呼び出しが発生せず、計上もされません。

組織として既定化を止められますか

止められます。管理設定(managed settings)でpermissions.disableAutoModeを"disable"にすると、組織内のセッションからautoモードが選択肢ごと消えます。特定の操作だけ人間の確認を挟みたい場合は、auto modeを残したままpermissions.askルールを配る方法もあります。確認しておきたい設定の一覧はauto mode既定化で確認したい設定を参照してください。権限ルールを管理設定のものだけに縛るにはallowManagedPermissionRulesOnlyを使います。

まとめ

権限モデルの変遷は、確認をなくす方向ではなく、確認の担い手をユーザーから仕組みへ移す方向でした。既定に乗るか、Manualへ戻すか、askルールやdenyルールで要所だけ人間の確認を残すか — 選択肢は今も3段階とも使えます。auto modeの既定化後は、会話で伝えた制約を分類器に任せきらず、止めたい操作だけdenyルールに書くという線引きが判断の中心になります。