Claude Codeの権限設定｜settings.jsonのpermissions（allow・deny・ask）の書き方とセキュリティ対策

Claude Codeの権限設定は、settings.jsonの「permissions」にallow（確認なしで許可）・ask（毎回確認）・deny（禁止）の3つのリストを書いて行います。ルールはdeny→ask→allowの順に判定され、denyに入れたものはallowで例外を作れないので、まず.envの読み取りや危険なコマンドをdenyに入れ、よく使う安全な操作だけをallowに足していくのが安全な始め方です。

この記事では、Claude Codeの公式ドキュメント（Configure permissionsほか、2026年10月18日確認。確認時点の最新版はv2.1.302）をもとに、権限ルールの書き方、設定ファイルの置き場所、見落としやすい落とし穴、サンドボックスとの組み合わせまでを、そのまま使える設定例つきで説明します。権限モードのうち自動モードの詳細はClaude Code 自動モードとは？、プランモードはClaude CodeのPlan Mode（プランモード）とは？で扱っています。

最初に入れておく設定（コピーして使える例）

一般的なWeb開発のリポジトリを想定した出発点です。プロジェクトの.claude/settings.jsonに置きます。

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Bash(git reset --hard *)"
    ]
  }
}

運用のコツは、厳しく始めて、確認が煩わしいものだけをallowに足すことです。確認画面で「Yes, and don’t ask again」を選ぶと、そのコマンドの許可ルールが自動で保存されます（プロジェクトの.claude/settings.local.jsonに書かれます）。いま有効なルールと、それがどの設定ファイルから来たかは、セッション中に/permissionsで確認・編集できます。

大事な前提として、公式ドキュメントは「権限ルールを強制するのはClaude Codeであって、モデルではない」と明記しています。CLAUDE.mdやプロンプトに「rmは使わないで」と書いても、それはClaudeの振る舞いに影響するだけで、実行を止める仕組みではありません。止めたい操作は設定ファイルのルールに書きます。

allow・ask・denyの意味と判定の順番

リスト	動き
allow	確認なしで実行を許可する
ask	実行のたびに確認する
deny	実行させない

ルールはdeny → ask → allowの順に評価され、最初に一致したものが結果を決めます。ルールの細かさは順番に影響しません。たとえばBash(aws *)をdenyに入れると、Bash(aws s3 ls)をallowに書いても通りません。askとallowの関係も同じで、askに一致すれば、より細かいallowがあっても確認が出ます。

複数の設定ファイルに書いた場合も、どこかのdenyに一致すれば、ほかのファイルのallowでは許可できません。ユーザー設定でallow、プロジェクト設定でdenyならdenyが勝ち、その逆も同じです。allowなどのリストはファイル間で上書きではなく合算されます。

ツール名だけのdenyは「ツールごと消す」

書き方	動き
"deny": ["Bash"]	Bashツール自体をClaudeから見えなくする（Bash(*)も同じ）
"deny": ["Bash(rm *)"]	Bashは使えるが、一致する呼び出しだけを止める
"deny": ["mcp__*"]	すべてのMCPツールを止める（denyとaskはツール名にワイルドカードを使える）

ルールの書き方

形式はツール名またはツール名(指定子)です。代表的なツールの書き方をまとめます。

ルール	一致するもの
Bash(npm run build)	このコマンドちょうど
Bash(npm run *)	npm run build、npm run test --watch、npm run
Read(./.env)	カレントディレクトリの.envの読み取り
Edit(/src/**/*.ts)	プロジェクトのsrc以下のTypeScriptファイルの編集
WebFetch(domain:example.com)	example.comへの取得
mcp__github__get_*	githubという名前のMCPサーバーのget_で始まるツール

Bashの「*」は、サブコマンドのあとに置く

Bashのルールでは、最初の*より前の部分がそのまま一致の条件になります。Bash(git log *)ならgit logだけですが、Bash(git *)はgitのすべてのコマンド（pushも含む）を許します。公式ドキュメントの例から、迷いやすいものを抜き出します。

書き方	一致する	一致しない
Bash(ls *)	ls -la、ls	lsof
Bash(ls*)	ls -la、lsof	―
Bash(git * main)	git merge main、git push origin main	git log
Bash(npm run build)	npm run build	npm run build --watch

末尾の*の前のスペースもルールの一部です。Bash(ls:*)のように:*で書いても、Bash(ls *)と同じ意味になります。

ReadとEditのパスの書き方

ReadとEditのパスはgitignoreと同じ書式で、先頭の記号で起点が変わります。/1つは「ファイルシステムのルート」ではない点に注意してください。

書き方	起点	例
//path	ファイルシステムのルート（絶対パス）	Read(//Users/alice/secrets/**)
~/path	ホームディレクトリ	Read(~/Documents/*.pdf)
/path	その設定ファイルの場所（プロジェクト設定ならプロジェクト、ユーザー設定なら~/.claude）	Edit(/src/**/*.ts)
path・./path	カレントディレクトリ	Read(*.env)

たとえばユーザー設定（~/.claude/settings.json）にRead(/secrets/**)と書くと、守られるのは~/.claude/secretsで、プロジェクトのsecretsではありません。全プロジェクト共通で.envを守りたいなら、ユーザー設定にRead(//**/.env)のように書きます。

また、Edit・ReadのほかにWrite(...)のようなパスのルールを書いても、Claude Codeは受け付けるだけで判定には使いません（起動時に警告が出ます）。書き込みを止めたいときはEdit(...)で書きます。なお.claudeignoreというファイルを置いても効果はなく、公式ドキュメントはReadのdenyルールに移すよう案内しています。

Bashのdenyは「うっかり防止」で、抜け道がある

ここが最も誤解されやすい部分です。Bashのルールは、Claudeが書いたコマンドの文字列に対して照合されます。同じプログラムでも書き方が違えば一致しません。

denyのルール	止まる	止まらない
Bash(curl *)	curl https://example.com	/usr/bin/curl https://example.com、sh -c 'curl ...'
Bash(rm *)	rm -rf build/	/bin/rm -rf build/、bash -c 'rm -rf build/'
Bash(git push *)	git push origin main	git -C . push origin main、git 'push' origin main

公式ドキュメントも、Bashのdeny・askルールは「Claudeが普段書く形を止めるもので、プログラムの周りのセキュリティ境界ではない」と説明しています。本当に閉じたい場合は、後述のサンドボックスかフックを併用します。

複合コマンドとラッパーの扱い

• 複合コマンドは分解して判定：&&・||・;・|・&・改行で区切られた各コマンドが、それぞれallowに一致する必要があります。逆にdenyとaskは、サブシェルやコマンド置換（$(...)）の中も含めてどれか1つが一致すれば働きます
• 剥がされるラッパー：timeout・time・nice・nohup・stdbufなどは照合前に取り除かれるので、Bash(npm test *)はtimeout 30 npm testにも一致します
• 剥がされないラッパー：npx・docker exec・devbox run・direnv execなどはそのままです。Bash(devbox run *)をallowに入れるとdevbox run rm -rf .まで許可されるので、Bash(devbox run npm test)のように中のコマンドまで書きます

Readのdenyが効かない読み方

ReadとEditのdenyは、Claude Codeの組み込みのファイル操作に加え、Bashのcat・head・tail・sedなど認識できるコマンドやリダイレクトにも効きます。ただし、grep -r pattern .のようにファイル名を指定しない読み方や、PythonやNode.jsのスクリプトの中でファイルを開く処理までは止められません。秘密情報を確実に守るなら、サンドボックスのfilesystem.denyReadも併用します。

権限モードの使い分け

個別のルールとは別に、セッション全体の構えを決めるのが権限モードです。設定ファイルのdefaultModeで開始時のモードを指定できます。

モード	動き	向いている場面
default（Manual）	ツールの初回使用時に確認する	通常の作業
acceptEdits	作業ディレクトリ内のファイル編集とmkdir・mvなどを自動で許可	編集が多く、あとでまとめて確認するとき
plan	読み取りと読み取り専用のコマンドだけで調べ、ソースは書き換えない	大きな変更の前に方針を固めるとき
auto	確認なしで進め、シェルコマンドなどの実行前に分類器が依頼と合っているかを確認	確認の回数を減らしたいとき
dontAsk	確認が必要な操作はすべて自動で拒否（allowにあるものは実行）	許可済みの操作だけで回したいとき
bypassPermissions	確認をほぼすべて省略	コンテナやVMなど隔離された環境だけ

bypassPermissionsでは、.gitや.claudeなどの保護されたパスへの書き込みも確認なしで通ります。公式ドキュメントは、壊れても影響が閉じるコンテナやVMの中でだけ使うよう警告しています。使わせたくない場合は、次の設定で無効にできます。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "disableAutoMode": "disable"
  }
}

どの設定ファイルにも書けますが、組織で強制するなら後述の管理ポリシー設定（managed settings）に置きます。

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

優先順位	ファイル	影響する範囲
1（最優先）	管理ポリシー設定（managed-settings.json、MDM、claude.aiのコンソールからの配信）	組織が配布した全員。利用者側では上書きできない
2	コマンドライン（--settingsなど）	そのセッションだけ
3	.claude/settings.local.json	自分＋そのプロジェクト。gitには入れない
4	.claude/settings.json	そのプロジェクトの全員（gitで共有）
5	~/.claude/settings.json	自分の全プロジェクト

出典：Settings files and precedence（2026年10月18日確認）。権限ルールについては前述のとおり、どの階層のdenyも他の階層のallowより強く働きます。組織でルールを統制するなら、管理ポリシー設定に置かないと利用者側で緩められる余地が残ります。管理ポリシー設定でallowManagedPermissionRulesOnlyを指定すると、権限ルールを管理ポリシー設定だけから読むようにもできます。企業での導入の進め方はClaude Codeの企業導入ガイドにまとめています。

他人のリポジトリでは「信頼」の前に中身を見る

プロジェクトの.claude/settings.jsonにあるallowルールや追加ディレクトリは、そのフォルダを信頼する確認ダイアログ（workspace trust）を承認するまで適用されません。ダイアログには、そのフォルダが有効にするルールが一覧されます。一方で、claude -pやSDKでの実行では信頼のダイアログが出ず、リポジトリの設定に書かれたフックや.mcp.jsonのサーバーなどが使われる場合があります。公式ドキュメントは、自分が書いていないリポジトリでclaude -pを実行する前に、--setting-sources userでプロジェクトの設定を読まない、--bareで起動する、といった対策を挙げています。

作業ディレクトリという境界

Claude Codeは、起動したディレクトリとその配下を作業範囲とします。範囲を広げるときは、起動時の--add-dir、セッション中の/add-dir、設定ファイルのadditionalDirectoriesを使います。作業範囲の外の読み取りを全モードで拒否したい場合は、permissions.blockReadsOutsideWorkingDirectoriesを設定します。

追加したディレクトリは、ファイルを読み書きできるようになるだけで、そこにある.claude/settings.jsonやCLAUDE.mdがそのまま有効になるわけではありません（スキルなど一部は--add-dirで読み込まれます）。

サンドボックスで本当に閉じる

ルールはコマンド文字列の照合なので、前述の抜け道があります。OSのレベルでファイルとネットワークを制限したい場合はサンドボックスを使います（Configure the sandboxed Bash tool）。サンドボックスは初期状態ではオフで、セッション中に/sandboxを実行するか、設定ファイルでsandbox.enabledをtrueにすると有効になります。macOS・Linux・WSL2で動き、Windowsでそのまま動かすとサンドボックスなしになります。

	権限ルール	サンドボックス
対象	Bash・Read・Edit・WebFetch・MCPなど全ツール	Bashなどのシェルコマンドと、そこから起動したプロセス
判定のしかた	Claudeが書いた呼び出しの内容で照合	実行中のプロセスをOSが制限
既定の制限	（設定したルールしだい）	書き込みは作業ディレクトリと一時ディレクトリなど、ネットワークは許可したドメインだけ（初期は空）
役割	意図しない操作を止める	被害の範囲を限定する

公式ドキュメントは両方を併用することを勧めています。プロンプトインジェクションでClaudeの判断がゆがめられても、サンドボックスの制限は残るためです。ただしサンドボックスはシェルコマンドだけが対象で、ReadやWebFetchなどの組み込みツール、フック、MCPサーバーは外側で動きます。また初期状態では、~/.sshなどを含めマシンの大半を読めるので、秘密情報はfilesystem.denyReadで閉じます。

フックで独自の検査を挟む

「この条件のときだけ止めたい」といった、ルールでは書けない判断はPreToolUseフックで実行前にスクリプトを挟みます。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": ".claude/check-command.sh" }
        ]
      }
    ]
  }
}

スクリプトが終了コード2で終わると、その実行はallowルールより先に止められます。逆に、フックが許可を返してもdenyやaskのルールは無視されません。フックの書き方はClaude Code Hooksとは？で解説しています。

見落とされがちなリスク

外から入ってくるテキストは「指示」ではない

Webページ、issueのコメント、MCPサーバーの応答、依存パッケージのREADMEに「この手順を実行せよ」と書かれていても、それはデータです。こうしたプロンプトインジェクションへの対策として、公式ドキュメントは、提案されたコマンドを承認前に確認する、信頼できない内容をそのままClaudeに流し込まない、外部のWebサービスとやりとりするときは仮想マシンを使う、などを挙げています（Security）。MCPで外部サービスをつなぐときは、とくに書き込み系のツールをallowに入れるかどうかを慎重に決めてください。

curlやwgetは既定で自動許可されない

Webから内容を取ってくるcurlやwgetは、既定では自動で許可されず、Manualモードでは毎回確認が出ます。使わせたくない場合はdenyに入れます。

Claude Codeを業務で使いこなしたい方には、生成AI（ChatGPT・Claude・Claude Code・Codex・Cursor・Gemini）やAIエージェントを使ったアプリ開発・業務効率化を未経験から学べる、テックジムのAI駆動開発コースもあります。Claude Codeの全体像はClaude Codeとは？使い方・始め方の基本にまとめています。

よくある質問

Q. 確認が多すぎて作業が進みません。全部許可してもいいですか？

全部を素通しにするより、頻繁に出る安全な操作だけをallowに足すほうが安全です。確認画面で「Yes, and don’t ask again」を選ぶと、そのコマンドの許可ルールが自動で保存されます。

Q. CLAUDE.mdに「rmは使わないで」と書けば防げますか？

防げません。CLAUDE.mdはClaudeの振る舞いに影響しますが、実行を許すかどうかを決めるのは権限ルールです。止めたい操作はdenyに書いてください。

Q. denyに入れたコマンドをallowで一部だけ許可できますか？

できません。ルールはdeny、ask、allowの順に判定され、denyに一致した時点で禁止されます。一部だけ許可したい場合は、denyのルールを狭く書き直します。

Q. .envファイルをClaudeに読ませないにはどうすればいいですか？

permissionsのdenyにRead(./.env)やRead(./.env.*)を入れます。スクリプト経由の読み取りまで確実に防ぐなら、サンドボックスのfilesystem.denyReadも併用します。

まとめ

• 権限はsettings.jsonのpermissionsのallow・ask・denyで設定し、/permissionsで確認できる
• 判定はdeny→ask→allowの順。allowでdenyの例外は作れない
• Bashの*はサブコマンドのあとに置く。Bashのdenyは文字列の照合なので抜け道がある
• パスの/1つは設定ファイルの場所が起点。絶対パスは//
• bypassPermissionsは隔離環境だけ。組織では管理ポリシー設定で禁止できる
• 確実に閉じたいならサンドボックス、条件付きの判断はフックを併用する

無料のClaude Code講座のご案内

テックジム東京本校では、Claude Codeの体験講座を毎週土曜15時から無料で開いています。ノートPCを持参し、対面のハンズオンで1時間、未経験の方でも参加できます（中学生以上）。詳しくはゼロから始めるClaude Code講座【東京本校・リアル開催】をご覧ください。