権限とパーミッションモード

中級

What you'll learn

3 つの権限判定（allow / ask / deny）の意味
権限ルールがツールとパターンをどう照合するか
6 つのパーミッションモードと、それぞれを使う場面
auto モードが対話型セッションの開始モードになった理由と、オプトアウトの方法
auto モードが確認プロンプトを安全性分類器に置き換える仕組み
安全性を損なわずにプロンプトを減らす、妥当な初期 allowlist の作り方
プロジェクト用と個人用の権限ルールの保存場所

権限は、Claude Code が確認のために止まらずに何をしてよいかを決めます。うまく調整すればコントロールを失わずに流れるように作業でき、下手に調整すればすべてを無条件に承認するか、プロンプトに埋もれることになります。

3 つの判定

すべての操作は、次のいずれかに決まります。

Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。

1 / 3

ルールは通常、ツールとパターンを組み合わせて照合します。例: Bash(npm run test:*) を allow、Read(./.env) を deny。

ツール + パターンを許可する

Bash(npm run test:*)

ツール + パターンを拒否する

Read(./.env)

パーミッションモード

モードはセッション全体の姿勢を決めます。モードは 6 つあります。よく使うものは Shift+Tab で切り替えるか、設定で permissions.defaultMode を指定します。

モード	確認なしで実行できること	使う場面
`default`（Manual と表示）	読み取りのみ	日常の作業、慎重を要する変更
`acceptEdits`	読み取り、ファイル編集、一般的なファイルシステムコマンド	信頼できて範囲の明確な編集セッション
`plan`	読み取りと、auto モードが利用可能な場合は分類器が承認したコマンド。ソースを編集することはない	大きい／リスクのあるタスク — Plan Mode を参照
`auto` （v2.1.283 以降、対話型セッションの開始モード）	すべて。安全性分類器が審査	プロンプト疲れが本当のリスクになる長いタスク
`dontAsk`	作業ディレクトリ内のファイル読み取りと事前承認済みツール。プロンプトが必要になる操作はすべて拒否	ロックダウンされた CI やスクリプト
`bypassPermissions`	すべて、チェックなし	サンドボックス／コンテナ専用 — シークレットのあるマシンでは絶対に使わない

auto モードが Claude Code の既定に

Claude Code v2.1.283 以降、auto はすべてのプランとプロバイダーで、対話型ターミナルおよび VS Code セッションの組み込みの開始モードです。それ以前のバージョンでは、2026 年 8 月 14 日から、Pro・Max・Team プランの新規セッションでのみ既定でした。Anthropic の根拠（1,000 人超の有料ユーザーによる自社テスト）: 分類器は有害な操作の 89% を捕捉したのに対し、手動レビューは 13.6% でした — 慣れたユーザーは手動プロンプトの約 97% を読まずに承認していたためです。

2 つの例外で意図が守られます。

あなたがユーザー設定で permissions.defaultMode を指定している場合、アプリ内の 1 回限りの切り替えプロンプトを承認しない限り、そのまま維持されます。
あなたの組織が既定を管理している場合（Team/Enterprise の管理設定）、自動的には何も変わりません。

セッションの途中でも Shift+Tab でいつでもモードを切り替えられます。これらのプランですでに有効な関連変更として、auto モードが行う分類器の呼び出しは利用上限にカウントされなくなりました。

早めにオプトイン（8 月 14 日より前）— auto を既定にする

~/.claude/settings.json
{
"permissions": {
  "defaultMode": "auto"
}
}

8 月 14 日以降も従来のプロンプト動作を維持する

~/.claude/settings.json
{
"permissions": {
  "defaultMode": "default"
}
}

auto モードの実際の仕組み

auto は、すべてについてプロンプトを出す方式と、安全性を切る方式の中間です。あなたに尋ねる代わりに、別の分類器モデルが実行前に各操作を審査し、依頼の範囲を超えて拡大するもの、認識できないインフラに触れるもの、Claude が読んだばかりの悪意あるコンテンツに誘導されたように見えるものをブロックします。明示的な ask ルールは、従来どおり停止してあなたに確認します。

ブロックされるのは、curl | bash、force push、本番へのデプロイとマイグレーション、未解決の変数に対する rm -rf、トランスクリプトの改ざん、未コミットの作業を破棄する破壊的な git コマンド、シークレットの外部エンドポイントへの送信などです。一方で、日常的な作業（ローカルでの編集、宣言済みの依存関係のインストール、読み取り専用の HTTP、自分のブランチへの push）はそのまま通します。同じ操作が繰り返しブロックされると、auto モードは一時停止し、プロンプトの判断をあなたに戻します。

auto モードは安全性の保証ではありません — プロンプトを減らすものであって、慎重を要する操作をレビューする必要がなくなるわけではありません。利用可否はプラン、モデル、そして（Team/Enterprise では）管理者のトグルに依存します。cron、クラウドセッション、CI など本当に無人で動かす場合は、Hardening Autonomous Runs と組み合わせてください — auto は bypassPermissions ではありません。

Watch out

bypassPermissions はサンドボックスの中で使うものです。実機ですべてのプロンプトを切って動かすと、エージェントが触ってはいけないものに触れてしまいかねません。使い捨ての環境に限ってください — 本当に欲しいのがプロンプトの削減なら、代わりに auto モードを使います。/docs/security/hardening-autonomous-runs の Hardening Autonomous Runs を参照してください。

妥当な初期 allowlist

目標: 安全で繰り返しの多い操作はあらかじめ許可し、破壊的な操作は ask か deny のままにします。

Guided walkthrough1 of 3

ファイルの読み取り、テスト／lint／ビルドコマンドの実行、git status/diff。

プロジェクトのルールは settings.json（共有）に、個人用の上書きは settings.local.json に保存します。

Pro tip

プロンプトから学びましょう。同じ安全なコマンドを数回承認すれば、allowlist に何を追加すべきかがはっきり分かります — 繰り返されるプロンプトを 1 回限りのルールに変えられます。

Key takeaways

3 つの判定: allow（プロンプトなし）、ask（既定 — 一時停止して確認）、deny（決して実行しない）。
ルールはツールとパターンを組み合わせて照合する。例: Bash(npm run test:*) や Read(./.env)。
6 つのモードがセッションの姿勢を決める: default（Manual）、acceptEdits、plan、auto、dontAsk、bypassPermissions。
v2.1.283 以降、auto はすべてのプランで対話型ターミナルおよび VS Code セッションの開始モード。自分で設定した defaultMode はそのまま維持され、組織が管理する既定には影響しない。
auto モードは、プロンプトの代わりにすべての操作を安全性分類器で審査する — プロンプト疲れに使うのはこちらで、bypassPermissions ではない。
allowlist を作る: 安全で繰り返しの多いものは allow、中程度のリスクは ask、破壊的なものは deny。
共有ルールは settings.json、個人用の上書きは settings.local.json に置く。

理解度チェック

0/6

明示的に許可も拒否もされていない操作に対して、既定の 'ask' 判定は何をしますか？
サンドボックスやコンテナの中でのみ安全で、シークレットのあるマシンでは決して使ってはいけないパーミッションモードはどれですか？
長いタスクで権限プロンプトを大幅に減らしたいが、安全網は残したい場合、どのモードを使いますか？
共有のプロジェクト権限ルールと個人用の上書きは、それぞれどこに保存すべきですか？
妥当な初期 allowlist で 'deny' リストに入れるべきものはどれですか？
2026 年 8 月 14 日、ユーザー設定ですでに permissions.defaultMode を 'default' にしていた場合、Pro プランでは何が起きますか？

settings.json: 設定システム
Hooks — allow/deny を超えて、ルールを決定論的に強制する
Sandbox Credential Masking — サンドボックス内のコマンドが本物のシークレットを保持することなく、gh、npm、aws に認証させる
セキュリティと責任ある利用

このページを共有

3 つの判定​