Claude Code 権限設定｜allow/deny・最小権限【2026】

Claude Codeの権限設定は、エージェントにどのツールやコマンドの実行を許可/拒否するかを制御する、安全に使ううえで最初に押さえるべき仕組みです。本記事ではその設定方法を実務目線で解説します。

セキュリティ全般は Claude Codeセキュリティにまとめています。本記事は権限(allow/deny)設定の方法に絞ります。

Claude Code 権限設定の完全ガイド｜実務で使える設定例と運用ノウハウ

Claude Code を仕事で使うとき、最初に決める必要があるのが権限設定です。ファイルの書き換え、コマンドの実行、外部へのアクセスを、どこまで確認なしで任せるかを決めます。ゆるすぎると意図しない変更が起きやすくなり、厳しすぎると確認ばかりで作業が進みません。

この記事では、権限の仕組み、settings.json の書き方、用途別の設定例、チームでの運用までを、公式ドキュメント（Configure permissions、2026年10月12日確認）と、実際に動かした画面（v2.1.296）で説明します。クリスタルメソッドでは Claude Code を開発の実務で日常的に使っており、その中で落ち着いた運用も合わせて紹介します。

まず、権限の確認がどのように出るかを、実際の操作の録画で見てください。

関連記事Claude Code（クロードコード）とは？できること・料金・使い方を初心者にもやさしく解説【2026年版】 ／ Claude Code 使用量を完全制御する実装ガイド【2026年版】 ／ Claude Code ログイン方法・できない時の対処法｜2026年版ガイド

Claude Codeの権限モデル：3つのレイヤーを理解する

Claude Code の動作を制御している場所は、大きく3つに分けて考えると整理しやすくなります。

レイヤー	何で決まるか	変えられるか
① モデル側の安全上の制約	Anthropic がモデルに持たせている安全上の方針	設定では変えられない
② 権限ルールと権限モード	settings.json の permissions（allow・ask・deny）、権限モード、/permissions の画面	自分やチームで決める
③ その場の確認	ルールに無い操作が出たときに表示される確認画面	その都度、自分で答える

細かく決められるのは②です。公式ドキュメントは、権限ルールを守らせているのは Claude Code 本体であって、モデルではないと説明しています。プロンプトや CLAUDE.md に書いた指示は Claude の行動に影響しますが、何が許可されるかは変えません。許可と禁止を確実に決めたいときは、②のルールを使います。

確認が必要かどうかは、道具の種類によって違います（手動で確認するモードの場合）。

道具の種類	確認が出るか	「今後は確認しない」を選んだとき
読み取り（ファイルを読む、検索する）	作業フォルダの中なら出ない	—
コマンドの実行（Bash）	出る（読み取りだけの一部のコマンドを除く）	そのリポジトリとコマンドについて、ずっと有効
ファイルの変更（Edit／Write）	出る	そのセッションが終わるまで
Web ページの取得（WebFetch）	出る（一部の公式ドキュメントのサイトを除く）	そのリポジトリとドメインについて、ずっと有効

設定ファイルの場所と優先順位

権限ルールは、次の設定ファイルに書きます。

スコープ	ファイルパス	適用範囲
ユーザー（グローバル）	~/.claude/settings.json	自分のすべてのプロジェクト
プロジェクト（共有）	.claude/settings.json（リポジトリの直下）	チーム全員。Git で管理する
プロジェクト（個人）	.claude/settings.local.json	自分だけ。Git には入れない
管理者（managed）	組織の管理者が配布する設定	組織全体。ほかの設定では上書きできない

ふつうの設定項目は、管理者 ＞ プロジェクト（個人）＞ プロジェクト（共有）＞ ユーザーの順で優先されます。ただし、権限ルールには大事な決まりがあります。どこか1か所で deny（拒否）されたものは、ほかのどの場所でも allow（許可）にできません。ユーザー設定で許可していても、プロジェクト設定で拒否していれば拒否されます。逆も同じです。

どのルールが有効になっているかは、Claude Code の中で /permissions を実行すると一覧で確認できます。下の画面は、プロジェクト共有の設定に deny を3つ書いた状態の Deny タブです。

チームでは、「守らせたい決まりはプロジェクト共有の設定に書き、個人の便利さのための許可は settings.local.json に書く」と分けるのが実用的です。クリスタルメソッドでも、本番に関わる決まりはプロジェクト共有の設定に書いて Git で管理しています。

permissions（権限設定）の構造と書き方

settings.json の permissions に、allow（確認なしで許可）、ask（毎回確認する）、deny（拒否）の3種類のルールを書きます。

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

allowとdenyのルール評価順序

ルールは deny → ask → allow の順で調べられ、最初に当てはまったものが結果になります。書いた順番や、ルールの細かさは関係ありません。そのため、広い deny の中から allow で一部だけ例外にすることはできません。たとえば Bash(aws *) を deny にすると、Bash(aws s3 ls) を allow に書いても拒否されます。一部だけ許可したい場合は、deny のほうを狭く書きます。

下の画面は、練習用のフォルダに deny を2つ（Bash(rm *) と Read(./.env)）書いた状態で、ファイルの削除と .env の表示を頼んだ結果です。どちらも拒否され、ファイルは残っています。

ツール種別ごとの権限指定

ルールは 道具の名前 または 道具の名前(条件) の形で書きます。よく使うのは次の4つです。

ツール種別	記法例	制御できる操作
Bash	Bash(git commit *)	シェルコマンドの実行。影響が大きいので、細かく書く
Read	Read(./.env)	ファイルの読み取り。deny に書くと、同じ場所への編集と新規作成も止まる
Edit	Edit(/src/**)	ファイルの作成・編集。Write ではなく Edit で書く
WebFetch	WebFetch(domain:api.example.com)	外部のページの取得（ドメイン単位）

条件を付けずに道具の名前だけ（Bash など）を書くと、その道具のすべての使用に当てはまります。deny に名前だけを書くと、その道具そのものが Claude から見えなくなります。

グロブパターンの使い方

コマンドとファイルの場所では、書き方の決まりが違います。

コマンド（Bash）：* は空白を含む任意の文字に当てはまります。* が無いルールは、そのコマンドと完全に同じときだけ当てはまります。

• Bash(npm run *)：npm run で始まるコマンドすべて
• Bash(git log *)：git log だけ。Bash(git *) と書くと git のすべてのコマンドになるので、* はサブコマンドのあとに置く
• Bash(ls *) は lsof には当てはまらない（* の前の空白もルールの一部）
• && や | でつないだコマンドは、それぞれが別々に調べられる

ファイルの場所（Read・Edit）：.gitignore と同じ書き方で、先頭の記号によって起点が変わります。

書き方	起点	例
//path	ファイルシステムの最上位（絶対パス）	Read(//Users/alice/secrets/**)
~/path	ホームフォルダ	Read(~/Documents/*.pdf)
/path	その設定ファイルのあるプロジェクトの最上位	Edit(/src/**/*.ts)
path または ./path	いまいるフォルダ	Read(*.env)

間違えやすいのは、/Users/alice/file のように先頭が斜線1つの書き方です。これは絶対パスではなく、プロジェクトの最上位からの場所として扱われます。絶対パスは斜線2つで始めます。

実務で使える設定テンプレート集

用途別の設定例を3つ示します。コピーして、プロジェクトに合わせて調整してください。ファイルの読み取りは作業フォルダの中なら確認なしで行われるので、allow に Read を書く必要はありません。

パターン①　フロントエンド開発（Node.js / React）

{
  "permissions": {
    "allow": [
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git diff *)",
      "Bash(git status)",
      "Bash(git log *)",
      "Bash(npm run lint)",
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Edit(/src/**)",
      "Edit(/public/**)"
    ],
    "ask": [
      "Bash(npm install *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(git reset --hard *)",
      "Bash(rm *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

ポイントは、git push と .env を deny にしていることです。確認なしでリモートに送られる事故と、鍵などの入ったファイルを読まれる・書き換えられる事故を防ぎます。Read の deny は、同じファイルへの編集も止めます。

パターン②　Pythonデータ分析・機械学習

{
  "permissions": {
    "allow": [
      "Bash(python *)",
      "Bash(pytest *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Edit(/src/**)",
      "Edit(/notebooks/**)"
    ],
    "ask": [
      "Bash(pip install *)"
    ],
    "deny": [
      "Bash(sudo *)",
      "Bash(rm -rf *)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

パターン③　読み取り専用レビューモード

コードレビューや調査など、「読むだけ・提案だけ」にしたい場面の設定です。クリスタルメソッドでは、初めて Claude Code を使うメンバーに、まずこの設定から始めてもらっています。

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Bash(git log *)",
      "Bash(git diff *)",
      "Bash(git status)"
    ],
    "deny": [
      "Edit"
    ]
  }
}

この例では、編集（Edit）だけを deny にし、defaultMode を dontAsk にしています。dontAsk は、確認が必要になる操作を自動で拒否するモードです。allow に書いたコマンドと、ファイルの読み取りだけが動きます。

下の画面は、この設定を入れた練習用のフォルダで試した結果です。ファイルへの追記は拒否され、git status は実行できています。

–dangerously-skip-permissions フラグの扱い

--dangerously-skip-permissions は、確認を出さずに実行させる起動時の指定で、権限モードの bypassPermissions に当たります。公式ドキュメントは、コンテナや仮想マシンのように、Claude Code が壊しても困らない隔離された環境でだけ使うよう注意しています。

権限モードは6つあります。確認を減らしたいだけなら、このフラグより先に、ほかのモードを検討します。

モード	動き
default（画面の表示は Manual）	道具を初めて使うときに確認する
acceptEdits	作業フォルダ内のファイル編集と、mkdir・mv などの基本的な操作を確認なしで行う
plan	読み取りと調査だけを行い、ファイルは編集しない
auto	ふだんの確認を出さず、コマンドの実行などの前に、別の判定役が依頼に合っているかを確かめる
dontAsk	確認が必要になる操作を自動で拒否する
bypassPermissions	確認を出さない。隔離された環境専用

このフラグを使う前に、次の4つを確認します。

• 実行する場所が、コンテナなどの隔離された環境であること
• deny に、止めたいコマンドが書かれていること
• 本番環境や機密のデータに届かないこと
• 実行の記録を残し、あとで確認できること

組織で使わせたくない場合は、設定の permissions.disableBypassPermissionsMode を "disable" にすると、このモードを使えなくできます。クリスタルメソッドでは、手元の開発機ではこのフラグを原則使わず、ネットワークを制限した Docker 環境でのテストの自動化に限っています。

インタラクティブ承認モードの活用

ルールに無い操作が出ると、Claude Code は実行の前に確認を出します。ここでは、実際の画面で流れを追います。

手順1：確認画面の選択肢を読む

下は、「node --test を実行して」と頼んだときに出た確認画面です。実行しようとしているコマンドと、選択肢が表示されます。

選択肢	意味
Yes	今回の1回だけ許可する。設定ファイルは変わらない
Yes, and don’t ask again for: …	許可し、表示されたルールを保存する。コマンドの場合は .claude/settings.local.json に保存され、以後は確認が出ない
Yes, and switch to auto mode	許可し、auto モードに切り替える（表示されない場合もある）
No	今回は拒否する

手順2：保存されたルールを確認する

2番目の「今後は確認しない」を選ぶと、ルールが保存されます。/permissions を実行して Allow のタブを見ると、追加されたルールを確認できます。

手順3：設定ファイルの中身を見る

保存先のファイルを開くと、いま選んだルールが allow に書かれています。下の画面の2つ目は、あらかじめ自分で書いておいたプロジェクト共有の deny ルールです。

「今後は確認しない」を続けて選んでいると、個人用の設定に許可が積み上がっていきます。クリスタルメソッドでは、この選択肢を使ったあとに settings.local.json を見直し、本当に残してよい許可かを確かめるようにしています。ファイルの編集についての「今後は確認しない」は、ファイルには保存されず、そのセッションが終わるまでの許可です。

CLAUDE.md との連携：権限設定の意図を伝える

CLAUDE.md は、プロジェクトの決まりや背景を文章で Claude に伝えるファイルです。権限ルールと組み合わせると、「なぜその決まりがあるのか」を伝えられます。

## セキュリティルール
- `.env`ファイルは絶対に編集・読み取りしないこと
- git pushは必ず人間が手動で行う
- 外部APIへの直接リクエストは行わない
- `secrets/`ディレクトリ以下には一切アクセスしない

## 推奨される作業の流れ
1. まず既存コードをReadで把握する
2. 変更案を提案してから実装に移る
3. 変更後は必ずlintとテストを実行する

下の画面は、この内容を CLAUDE.md に書いた状態で、決まりについて尋ねた結果です。CLAUDE.md を読んで答えていることが分かります。

ただし、CLAUDE.md に書いただけでは、禁止は保証されません。公式ドキュメントも、指示は Claude の行動に影響するが、許可される範囲は変えないと書いています。確実に止めたいものは deny に書き、CLAUDE.md には理由と手順を書く、という役割分担にします。

権限設定のよくある失敗パターンと対処法

失敗①　allowとdenyの優先順位を誤解する

「allow を先に書けば優先される」という誤解があります。実際は、書いた順番に関係なく deny → ask → allow の順で調べられます。一部だけ許可したい場合は、deny を狭く書きます。以前のこの記事の「読み取り専用」の設定例も、allow に git のコマンドを書きながら deny に Bash(*) を書いていて、この失敗に当たっていました。同じ形の設定で試すと、下の画面のように、allow に書いた git status も実行できません。

失敗②　環境変数ファイルを守れていない

Edit(.env*) を deny にするだけでは、読み取りは止まりません。Read(./.env) を deny に書くと、読み取りも、同じファイルへの編集も止まります。ただし、この deny が効くのは、Claude Code のファイル操作の道具と、cat などファイル名を指定するコマンドです。自作のスクリプトが中で読む場合までは止められないので、OSの段階で止めたいときはサンドボックスを使います。

失敗③　ユーザー設定にプロジェクト固有のルールを書いてしまう

~/.claude/settings.json に特定のプロジェクト向けのルールを書くと、ほかのプロジェクトで思わぬ動きになります。プロジェクト固有のルールは、プロジェクトの設定ファイルに書きます。

失敗④　コマンドの deny を過信する

Bash(git push *) を deny にしても、git -C . push のように書き方が違うコマンドには当てはまりません。公式ドキュメントも、Bash のルールには当てはまらない書き方があると説明しています。コマンドの deny は「うっかり」を防ぐものと考え、外部への通信を確実に止めたい場合はサンドボックスや隔離された環境と組み合わせます。

失敗⑤　deny を見直さないまま使い続ける

最初の設定のまま半年、1年と使っていると、想定していなかった操作が増えてきます。/permissions の「Recently denied」のタブや settings.local.json を定期的に見て、ルールを更新します。

権限設定で実際に効いた運用ルール（一次情報）

監修者・河合継は、Claude Code を1年以上、実務で使ってきました。権限はゆるめれば楽になりますが、そのぶん危険が残ります。使い続けて落ち着いた考え方を3つ挙げます。

• 「全部許可」にしない。確認を飛ばす設定は快適ですが、意図しない実行がそのまま通る事故と隣り合わせです。影響の小さい操作だけを確認なしにして、壊す可能性のある操作は必ず確認する、と線を引くのが、結局いちばん安全で速い方法でした。
• 狭く始めて、必要になったら広げる。最初から広く許可するより、狭く始めて、詰まったところだけ開けるほうが、何を許可しているかを把握しやすくなります。
• 権限の理由を CLAUDE.md に残す。なぜこの権限にしているかを書いておくと、チームでも、あとの自分でも、理由を知らずに設定をゆるめてしまうことが減りました。

1年以上の実運用で権限設定を育てた記録

権限設定は、一度書いて終わりではありません。実際に問題が起きるたびに見直して育てていくものです。監修者は、AIアバターのシステム開発で1年以上 Claude Code を日常的に使っています。運用の決まりをまとめた CLAUDE.md は、最初は20項目ほどでした。確認なしに危険な操作が実行されかけた、同じ書き間違いが繰り返された、といった実際の失敗を1件ずつ文章にして加えていった結果、いまは100項目を超えています。数よりも大事なのは、「一度起きた問題は必ず決まりとして書き、二度目を仕組みで防ぐ」という姿勢です。これは、deny や設定例を作ったまま放っておかない、という考え方と同じです。

ファイル編集の事故に備えて、編集の道具が動く前に自動でバックアップを取るフック（PreToolUse）も入れています。日付ごとのフォルダに、時刻を付けて保存します。allow と deny で絞るだけでなく、許可した操作で問題が起きても元に戻せるようにして、二重に備えています。複数の端末やプロジェクトで同じ決まりを使う場合は、端末ごとの記憶に頼らず、共有の文書に書いておかないと、同じ間違いが端末ごとに繰り返されます。これも実際に運用して分かったことです。

チーム開発における権限設定の運用ルール

チームで使う場合は、権限設定そのものの管理が必要です。クリスタルメソッドで実際に採用している決まりを紹介します。

• プロジェクト共有の設定は、レビューを通す：.claude/settings.json の変更は、コードと同じように、1名以上の承認を必要とする
• 必ず deny にするものを決めておく：組織で共通の「必ず拒否するコマンド」を文書にし、すべてのプロジェクトに入れる
• settings.local.json は Git に入れない：個人の設定がリポジトリに混ざらないようにする
• 新しいプロジェクトは、ひな形から始める：権限設定を入れたひな形を用意し、設定の手間と漏れを減らす
• 問題が起きたら記録する：意図しない操作が起きたら、原因と対処を書き残し、設定の見直しに使う

組織として必ず守らせたい決まりは、管理者用の設定（managed settings）で配布できます。ここに書いた deny は、利用者の設定や起動時の指定では上書きできません。

利用できるモデルも更新が続いており、2026年10月時点の現行はFable 5.1・Opus 5.5・Sonnet 5.5・Haiku 5.5の4つです。

よくある質問

Q. allowとdenyはどちらが優先されますか？

A. deny が優先されます。ルールは deny → ask → allow の順で調べられ、最初に当てはまったものが結果になります。書いた順番やルールの細かさは関係ありません。

Q. 設定ファイルはどこにありますか？

A. 自分の全プロジェクト用が ~/.claude/settings.json、チームで共有するプロジェクト用が .claude/settings.json、自分だけのプロジェクト用が .claude/settings.local.json です。組織の管理者が配布する設定もあります。どこか1か所で deny にしたものは、ほかの設定では許可できません。

Q. 確認画面の「Yes, and don’t ask again」を選ぶとどうなりますか？

A. コマンドの場合は、表示されたルールが .claude/settings.local.json の allow に保存され、以後は確認が出なくなります。ファイルの編集の場合は保存されず、そのセッションが終わるまでの許可になります。

Q. いま有効な権限ルールを確認するにはどうすればいいですか？

A. Claude Code の中で /permissions を実行します。Allow・Ask・Deny のタブでルールを確認・追加でき、最近拒否された操作も見られます。

Q. .envファイルを読ませないようにするにはどう書きますか？

A. permissions の deny に Read(./.env) を書きます。Read の deny は、同じファイルへの編集と新規作成も止めます。

Q. –dangerously-skip-permissionsフラグとは何ですか？

A. 確認を出さずに実行させる起動時の指定で、権限モードの bypassPermissions に当たります。公式ドキュメントは、コンテナや仮想マシンなどの隔離された環境でだけ使うよう注意しています。

Q. CLAUDE.mdに「禁止」と書けば実行されませんか？

A. 保証されません。CLAUDE.md の指示は Claude の行動に影響しますが、許可される範囲は変えません。確実に止めたいものは permissions の deny に書きます。

まとめ

権限設定は、「何を任せるか」と「何を人が守るか」を決める作業です。要点をまとめます。

• 権限ルールは allow・ask・deny の3種類で、deny → ask → allow の順に調べられる
• どこか1か所で deny にしたものは、ほかの設定では許可できない
• .env などは Read の deny で守る。編集も同時に止まる
• 確認画面の「今後は確認しない」は .claude/settings.local.json に保存される。ときどき見直す
• CLAUDE.md は理由と手順を伝えるもの。確実に止めたいものは deny に書く
• --dangerously-skip-permissions は、隔離された環境でだけ使う

権限設定は、プロジェクトやチームの変化に合わせて見直し続けるものです。まずはこの記事の設定例から始めて、自分たちの決まりに合う形に育ててください。

関連記事

• Claude Codeとは
• Claude Code のAPI料金
• Claude Code と Codex の比較
• Claude Code と Cursor の比較
• Claude Code のフック（hooks）
• Claude Codeのセキュリティと安全な使い方