Claude Codeの権限設定【2026年】許可ルールとモードの決め方

1. 権限の仕組み：どの操作で確認が出るか

Claude Codeは、操作の種類ごとに「確認するかどうか」の初期値を決めている。Manual（手動）モードでの初期の動きは次のとおりだ（Configure permissions）。

操作の種類	例	確認が出るか	「今後は聞かない」を選んだとき
読み取りのみ	ファイルの読み取り、Grep	出ない（作業フォルダと追加フォルダの中）	―
Bashコマンド	シェルの実行	出る（組み込みの読み取り専用コマンドを除く）	リポジトリとコマンドごとに保存される
ファイルの変更	編集・書き込み	出る	そのセッションが終わるまで
Webの取得	WebFetch	出る（あらかじめ許可されたドキュメントのドメインを除く）	リポジトリとドメインごとに保存される
Web検索	WebSearch	出る	リポジトリごとに保存される

確認の画面で「Yes, and don't ask again」を選ぶと、そのルールはGitリポジトリのルートにある .claude/settings.local.json に allow として書き込まれ、同じリポジトリの以後のセッションにも効く。ファイル変更の承認はファイルに保存されず、セッションの終わりまでしか続かない。

2. 6つの権限モードの違い

権限モードとは、セッション全体で「どこまで聞かずに進めるか」を決める基本の設定のことだ。個別のルールはその上に重ねて効く。公式ドキュメントの一覧を整理すると次のようになる（Choose a permission mode）。

モード（設定値）	聞かずに実行されるもの	向いている場面
Manual（default）	読み取りのみ	操作を全部自分で確かめたい、機密性の高い作業
acceptEdits	読み取り、ファイル編集、mkdir・touch・mv・cpなどのよく使うファイル操作	変更を後から差分で見直す前提で進める
plan	読み取り（autoが使える場合は、分類器が認めたコマンドも）	変更する前に調べて計画を立てさせる
auto	すべて。ただし実行前に別のモデル（分類器）が確認する	長い作業、確認の多さを減らしたいとき
dontAsk	作業フォルダ内の読み取りと、事前に許可したツール。確認が必要なものは自動で拒否	CIやスクリプトなど、許可の範囲を固定したい環境
bypassPermissions	すべて（一部の操作を除く）	隔離したコンテナやVMの中だけ

切り替え方

• CLI：セッション中に Shift+Tab を押すと切り替わる。autoから押すとまずManualになり、その後は Manual → acceptEdits → plan の順に回る。画面下のステータスバーに「⏸ manual mode on」「⏵⏵ accept edits on」「⏸ plan mode on」「⏵⏵ auto mode on」などと表示される。
• 起動時に指定：claude --permission-mode plan のようにフラグで指定する。
• 初期値として指定：設定ファイルの permissions.defaultMode に書く。
• VS Code：モード表示から切り替える。新しい会話の初期モードは、VS Codeのユーザー設定 claudeCode.initialPermissionMode で決める（ワークスペースの値は読まれない）。

セッションが最初にどのモードで始まるか

ターミナルで新しいセッションを始めると、次の順で最初に当てはまったものが使われる。

1. --permission-mode フラグ（または --dangerously-skip-permissions）
2. 設定ファイルの permissions.defaultMode
3. 組み込みの初期値：ターミナルとVS Codeでは、v2.1.283以降はauto。claude -p やAgent SDKでは default（Manual）

注意したいのは、プロジェクトの .claude/settings.json や .claude/settings.local.json に "auto" を書いても効かないことだ。この場合は組み込みの初期値が使われる。同じ2つのファイルに "bypassPermissions" を書いた場合も効かず、Manualで始まる。autoを初期値にしたいなら、~/.claude/settings.json（ユーザー設定）に書く。

autoモードの条件と、止められる操作

autoモードとは、確認の画面を出す代わりに、別のモデル（分類器）が操作を実行前に確かめるモードのことだ。公式ドキュメントによると、対象プランは「すべてのプラン」。Anthropic APIで使う場合のモデルは Claude Opus 4.6以降、Sonnet 4.6以降、Haiku 5.5、Fableのモデルで、Sonnet 4.5・Opus 4.5・Haiku 4.5などの古いモデルでは使えない。TeamとEnterpriseでは初期状態で使え、管理者は管理設定で permissions.disableAutoMode を "disable" にして止められる。

分類器が初期状態で止める操作として、公式には次のようなものが並ぶ（抜粋）。

• curl | bash のような、コードのダウンロードと実行
• 機密データの外部への送信、本番へのデプロイやマイグレーション
• セッション前からあったファイルの取り消せない削除、force push
• git reset --hard や git clean -fd など、コミットしていない変更を捨てる操作
• 人が承認していないプルリクエストのマージ、CIのチェックを止める操作
• 有効な認証情報やトークンを会話やファイルに書き出す操作

ただし公式は「autoモードは確認を減らすが、安全を保証するものではない」と警告している。全体の方向を信頼できる作業に使い、機密性の高い操作の確認の代わりにはしない。

planモードとbypassPermissionsモード

planモードでは、Claudeはファイルを読み、調べ、計画を書くが、ソースは編集しない。計画ができると「Yes, and use auto mode」「Yes, manually approve edits」「No, keep planning」から選べる。Ctrl+G で計画をエディタで開いて直すこともできる。

bypassPermissionsモードは確認をほぼすべて省く。公式は、インターネットにつながらないコンテナやVMなど、ホストを壊せない隔離環境でだけ使うよう警告している。それでも、明示したaskルール、ルートやホームフォルダを消すような rm などは確認か拒否になる。

3. 設定ファイルの置き場所と優先順位

権限ルールは、ほかの設定と同じく4種類の設定ファイルに書ける（Settings files and precedence）。

範囲	ファイル	効く相手	向いている内容
管理（組織）	managed-settings.json など	組織が配布した全員	セキュリティの方針。ほかの設定で上書きできない
プロジェクト（ローカル）	.claude/settings.local.json	自分だけ（このプロジェクト）	個人の例外、共有前の試し
プロジェクト（共有）	.claude/settings.json	そのフォルダで作業する全員（Gitで共有）	チームの権限・フック・環境変数
ユーザー	~/.claude/settings.json	自分（このマシンの全プロジェクト）	自分の権限ルール、好みの設定

同じキーが複数の場所にあるときは「管理 → コマンドライン（--settings）→ ローカル → 共有プロジェクト → ユーザー」の順で上のものが使われる。ただし permissions.allow のようなリストは上書きではなく合算される。そして権限では、どの階層のdenyも先に判定されるため、ユーザー設定でallowしていてもプロジェクト設定でdenyしていれば止まる。逆に、ユーザー設定のdenyはプロジェクト設定のallowを止める。

読み込まれた設定ファイルは、/status の「Setting sources」の行で確かめられる。設定ファイルは保存すると実行中のセッションにもほぼそのまま反映され、permissions の変更も再起動なしで効く。

4. ルールの書き方

ルールは「ツール名」か「ツール名(指定)」の形で書く。判定は deny → ask → allow の順で、最初に当てはまったものが結果になる。より細かいルールが先に勝つわけではない。

書き方	意味
Bash	すべてのBashコマンド（Bash(*) と同じ）。denyに書くとツール自体がClaudeから見えなくなる
Bash(npm run build)	npm run build ちょうどのコマンドだけ
Bash(npm run *)	npm run で始まるコマンド（npm run 単体も含む）
Read(./.env)	作業フォルダの .env の読み取り
Edit(/src/**/*.ts)	設定ファイルの基準位置から見た src/ 以下の .ts の編集
WebFetch(domain:example.com)	example.com への取得（サブドメインは *.example.com を別に書く）
mcp__github__*	githubという名前のMCPサーバーのすべてのツール
Agent(Explore)	Exploreサブエージェント

Bashルールの注意点

• * はサブコマンドの後に置く。Bash(git log *) は git log だけを許すが、Bash(git *) はすべてのgitコマンドを許す。Bash(git * main) のように * がサブコマンドより前にあるallowルールには、起動時に警告が出る。
• * の前の空白も意味を持つ。Bash(ls *) は lsof に当たらないが、Bash(ls*) は lsof にも当たる。Bash(ls:*) は Bash(ls *) と同じ意味だ。
• つないだコマンドは1つずつ判定される。Bash(safe-cmd *) を許していても、safe-cmd && other-cmd は自動では通らない。&&・||・;・| などで区切られた全部が許可されている必要がある。
• denyは「よくある書き方」を止めるだけ。Bash(curl *) は /usr/bin/curl や sh -c 'curl ...' を止めない。Bash(git push *) は git -C . push を止めない。公式は、コマンドの文字列に頼らない制限には、OSレベルでファイルと通信を制限するサンドボックスを使うよう案内している。

ファイルのパスの書き方

Read と Edit のルールは、.gitignoreと同じパターンで書く。先頭の書き方で基準の位置が変わる。

書き方	基準の位置	例
//path	ファイルシステムのルート（絶対パス）	Read(//Users/alice/secrets/**)
~/path	ホームフォルダ	Read(~/Documents/*.pdf)
/path	その設定ファイルの基準位置	Edit(/src/**/*.ts)
path または ./path	現在のフォルダ	Read(*.env)

/Users/alice/file のように先頭がスラッシュ1本のものは絶対パスにならない。プロジェクト設定なら作業フォルダが、ユーザー設定（~/.claude/settings.json）なら ~/.claude が基準になる。ユーザー設定に Read(/secrets/**) と書くと、止まるのは ~/.claude/secrets/** だ。全プロジェクトで効かせたいなら // か ~/ で書く。

5. 権限設定を作る手順

手順は「今の状態を見る → 止めるものを決める → よく使うものを許す → 共有と個人を分ける → 確かめる」の順だ。

1. /permissions で今のルールを見る。すべてのルールと、それがどの settings.json から来ているかが一覧で出る。ここから追加・削除もでき、変更は次のツール呼び出しから効く。
2. まず deny を決める。読ませたくない秘密のファイル（.env や secrets フォルダ）と、どのモードでも実行させたくない操作を書く。
3. 取り消しにくい操作を ask にする。git push のように、毎回自分の目で確かめたい操作だ。askルールはautoモードでも確認を出す。
4. よく使う安全なコマンドを allow にする。テストやビルドなど、毎回承認している操作をまとめて許す。
5. 共有するものと個人のものを分ける。チーム共通のルールは .claude/settings.json に書いてコミットし、個人の例外は .claude/settings.local.json に書く。
6. 読み込まれたかを確かめる。/status の Setting sources を見て、書き間違いがあれば claude doctor で、捨てられたルールの一覧を確かめる。
7. 初期モードを決める。自分のマシンの全セッションに効かせるなら ~/.claude/settings.json の permissions.defaultMode に書く。

プロジェクトの .claude/settings.json の記入例は次のとおりだ。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npm test *)",
      "Bash(git diff *)",
      "Bash(git commit *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

自分のマシンのセッションをすべてManualで始めたい場合は、~/.claude/settings.json に次のように書く（公式ドキュメントの例）。次のセッションのステータスバーに「⏸ manual mode on」と出れば反映されている。

{
  "permissions": {
    "defaultMode": "default"
  }
}

6. 保護されたパスとワークスペースの信頼

保護されたパス：allowでも自動では通らない

Claude Codeには、書き込みが自動では承認されない「保護されたパス」がある。bypassPermissionsモードなどの一部を除き、Manual・acceptEditsでは確認が出て、autoでは分類器に回り、dontAskでは拒否される。設定ファイルの permissions.allow に Edit(.claude/**) と書いても、この判定は変わらない。

• 主なフォルダ：.git、.vscode、.idea、.husky、.devcontainer、.claude（Claude自身のワークツリーや自動メモリのMarkdownなどは例外）
• 主なファイル：.gitconfig、.bashrc、.zshrc、.profile、.npmrc、.pre-commit-config.yaml、.mcp.json、.claude.json

ワークスペースの信頼：他人のリポジトリのallowは、信頼するまで効かない

プロジェクトの .claude/settings.json にある permissions.allow と additionalDirectories は「できることを広げる」設定なので、そのフォルダの信頼ダイアログを承認するまで適用されない。ダイアログには、そのフォルダが与えようとしているルールが一覧で出る。denyとaskは制限するだけなので、信頼の前から効く。

ダイアログが出ない claude -p で、自分が書いていないリポジトリを動かすときは注意が要る。公式は、--setting-sources user でプロジェクトの設定と .mcp.json を読ませない、--bare でフック・スキル・.mcp.json のサーバーなどを読ませない、といった対策を挙げている。MCPサーバーの設定はClaude CodeのMCP設定方法で扱っている。

7. つまずきやすい点と対処

症状	原因と対処
「今後は聞かない」を選んだのに、また聞かれる	その選択はローカル設定にallowを足すだけで、プロジェクトや管理設定のaskルールには勝てない。/permissions でどのファイルのaskが当たっているかを見る
defaultMode を "auto" にしたのにManualで始まる	.claude/settings.json か .claude/settings.local.json に書いている。~/.claude/settings.json に移す
Write(docs/**) や Grep(docs/**) が効かない	パスの判定は Edit と Read のルールで行われる。Write の代わりに Edit(docs/**)、Grep・Glob の代わりに Read(docs/**) と書く
/Users/... と書いた絶対パスが効かない	先頭がスラッシュ1本だと設定ファイルの基準位置からの相対になる。//Users/... と書く
.claudeignore に書いたファイルが読まれる	.claudeignore は効果がないと公式に明記されている。Read のdenyルールに移す
claude -p でツールが拒否される	v2.1.302以降、モード未指定の -p はManualで始まり、承認が必要な操作は拒否される。--allowedTools "Bash(npm test)" で許すか、--permission-mode auto で始める
autoモードが選べない	モデルが対象外、設定ファイルに disableAutoMode がある、Anthropic側で一時的に止まっている、のいずれか。新しいセッションでやり直す
起動時に Settings Warning が出る	書き間違えたルールなど、一部の値だけが無効。その値を飛ばして残りは使われる。claude doctor で詳細を確かめる

ログイン・利用上限・429などのエラーはClaude Codeのエラー一覧と対処法で扱っている。

8. 欠点・制限事項（わからないこと）

• Bashのdenyルールは安全の境界ではない。公式自身が、別の書き方で呼ばれた同じプログラムは止められないと書いている。確実に止めたいならサンドボックスやコンテナを併用する。
• Read・Editのdenyは、スクリプトの中の読み書きまでは止めない。PythonやNodeのスクリプトがファイルを開く場合などは対象外で、OSレベルで止めるにはサンドボックスが必要とされる。
• autoモードの分類器は安全を保証しない。どの操作をどこまで正しく止められるかの数値は、確認した公式ページには記載がない。
• バージョンによって挙動が変わる。初期モードがautoになったのはv2.1.283以降で、それより前はプランによって異なる。-p の扱いもv2.1.302で変わった。古いバージョンでは本記事のとおりに動かないことがある。
• 記入例は公式のテンプレートではない。公式の書式に沿って作った例で、自分のプロジェクトのコマンドに合わせて直す必要がある。

9. よくある質問

まとめ

Claude Codeの権限は、6つのモードで全体の確認の度合いを決め、allow・ask・denyのルールで個別に上書きする仕組みだ。判定は deny → ask → allow の順で、どの階層のdenyもallowでは打ち消せない。v2.1.283以降はautoモードが初期値だが、プロジェクトの設定ファイルからautoやbypassPermissionsを初期値にはできない。CLAUDE.mdでは操作を止められないので、止めたいものは必ずルールに書く。

今すぐできるアクション：

1. 今日：/permissions を開き、今どのルールがどのファイルから来ているかを確かめる。.env と秘密のフォルダを Read のdenyに入れる。
2. 今週：git push など取り消しにくい操作をaskに、毎回承認しているテストやビルドをallowに入れる。チーム共通のものは .claude/settings.json にまとめてコミットする。
3. 来月：claude -p やCIで使う場合は、--permission-mode dontAsk と --allowedTools で許可の範囲を固定する。サンドボックスの併用も検討する。

本記事の内容は、2026年11月7日にClaude Codeの公式ドキュメントで確認したもの。Claude Codeは頻繁に更新され、モード・初期値・必要なバージョンは変わることがある。最新の情報は本文中のリンク先で確認できる。設定ファイルの例は公式のテンプレートではない。

関連記事

• Claude Code完全ガイド｜使い方・料金・最新モデル・活用法
• CLAUDE.mdの書き方【2026年】例・置き場所・効かない原因（CLAUDE.mdの書き方｜例・置き場所・効かない原因）
• Claude in Chromeの使い方【2026年】始め方と権限・接続エラー（Claude in Chromeの使い方｜始め方と権限・接続エラー）
• Claude CodeのMCP設定方法｜claude mcp addの使い方・スコープ・.mcp.json
• Claude Codeのエラー一覧と対処法｜ログイン・利用上限・429・529・PATH
• Claude Codeの料金｜Pro・Max・Team・APIの違いと選び方
• 1PasswordとAIの連携方法｜Claude CodeでのAPIキー管理

出典

• Claude Code Docs「Configure permissions」（権限の仕組み・ルールの書き方・優先順位・ワークスペースの信頼。2026年11月7日確認）
• Claude Code Docs「Choose a permission mode」（6つのモード・初期モード・autoモードの条件・保護されたパス。2026年11月7日確認）
• Claude Code Docs「Settings files and precedence」（設定ファイルの場所と優先順位。2026年11月7日確認）
• Claude Code Docs「Use Claude Code in VS Code」（initialPermissionMode。2026年11月7日確認）