Claude Codeの権限設定は、「確認せず進める操作」「その都度確認する操作」「使わせない操作」をツールごとに決める仕組みです。設定する入口は/permissions、ファイルで管理する場所はsettings.jsonのpermissionsです。迷ったら、いつも許可している小さな操作を一つだけ登録し、実際に一致する範囲を確かめるところから始めます。
この記事は2026年10月28日に確認した公式資料をもとに、編集部が設定例と点検の順序を作成しています。掲載例は説明用で、Claude Code上での実測・動作保証ではありません。利用中の版と組織の管理設定も確認してください。
Claude Codeの権限設定で決めること
たとえば、資料フォルダーの読み取りは任せ、ファイルの書き換えは確認し、認証情報のある場所は読ませたくない場合があります。これを「慎重に作業して」と文章で伝えるだけでなく、利用するツールへのルールとして記述します。公式資料では、ルールを適用するのはモデルではなくClaude Code本体だと説明されています。CLAUDE.mdに書く業務上の約束と、ツールの許可は役割が違います。
ただし、権限ルールを設定すれば端末全体を隔離できるわけではありません。コマンドの書き方や別のプログラム経由のアクセスには限界があります。後述するsandboxとの違いまで含めて、何を任せるかを決めます。仕様の根拠は公式の権限設定です。
権限ルールはdeny・ask・allowの順に確認する
| 項目 | 目的 | 決めるときの問い |
|---|---|---|
deny | 一致した操作を拒否する | この作業で触る必要があるか |
ask | 一致した操作で確認を求める | 実行のたびに対象や影響を見たいか |
allow | 一致した操作を手動確認なしで許可する | 指定した範囲を繰り返し任せられるか |
評価順はdeny、ask、allowです。具体的に書いたallowが、広く書いたdenyに勝つわけではありません。たとえばBash(git *)をdenyに入れると、allowにBash(git status)を加えても、git statusは拒否の対象です。例外を後から足せると考えて広いdenyを置くと、必要な仕事まで止まります。
一方、allowだけを並べても、その一覧にないすべての操作が拒否されるわけではありません。ルールに一致しない操作は、権限モードやツールの扱いなどに従います。許可一覧にない操作がすべて拒否されるとは限らないため、実際に試す操作と設定を照合してください。非対話実行で利用可能な組み込みツール自体を絞りたい場合は、CLIの--toolsも別に検討します。
権限設定は/permissionsから小さく始める
Claude Codeで/permissionsを実行すると、登録済みのルールと、各ルールの読み込み元であるsettings.jsonを確認できます。確認が多いからと新しく登録する前に、すでに似たルールがないか、別の場所のdenyやaskが優先していないかを見ます。
個人の好みを試す段階なら、チーム全員に配る設定と分けて扱います。共有用の.claude/settings.jsonへ書くときは、同じ作業をする人にも必要な範囲かを確認します。ファイルの配置と設定の優先順位はsettings.jsonの解説にまとめています。
以下は、プロジェクトのルートで使う説明用の抜粋です。既存settings.jsonを丸ごと置き換えず、同じpermissions項目があれば内容を照合して追加します。実際のコマンドやフォルダー名に合わせて、使わない行は入れません。
{
"permissions": {
"allow": ["Bash(git status)"],
"ask": ["Edit(/drafts/**)"],
"deny": ["Read(/private-example/**)", "Edit(/private-example/**)"]
}
}この例では、git statusという表記の呼び出しを許可し、drafts配下の編集では確認を求めます。private-exampleは架空の保護用フォルダーです。実際の秘密情報を置いて動作確認するのではなく、無害な練習ファイルで一致・不一致を確かめます。この数行は、あらゆる経路からのアクセスを閉じる完成済みの安全設定ではありません。
権限ルールの書き方で間違えやすい3点
ツール名だけと、括弧付きでは範囲が違う
BashだけならBash全体を対象にします。Bash(git status)ならそのコマンド文字列です。ファイルの範囲は読み取りならRead、編集ならEditを使います。現在の公式資料では、Write(path)やGlob(path)のようなパス付きルールは、そのファイル操作の判定に一致しないと説明されています。書き込みの範囲にはEdit、読み取りの範囲にはReadを使います。
ワイルドカードは、任せる範囲を広げる
Bash(git status)とBash(git *)は意味が大きく違います。後者はgitのさまざまな操作へ一致します。必要な引数を許可するなら、プログラム名だけでなく、何をするサブコマンドかまで固定して考えます。Bash(ls *)はlsとその引数、Bash(ls*)はlsofのような別名にも一致し得ます。空白一つも対象範囲の一部です。
コピーした設定の星印を見つけたら、「この場所にはどの文字列まで入るか」を説明できるか確認します。便利さのために範囲を広げる場合も、必要な作業と一致していることが先です。コマンドを連結した場合には部分ごとの判定もあるため、単独で通ったコマンドが、連結しても同じように通るとは限りません。
パスの先頭のスラッシュを読み違えない
ReadとEditでは、//から始めるパスはファイルシステムの絶対パス、~/はホームからのパスです。先頭の/が一つだけなら、設定の保存場所に対応する基点から解釈されます。プロジェクト設定の/drafts/**と、ユーザー設定に同じ文字列を書いた場合を同一視しないでください。
相対パスには現在の作業ディレクトリも関係します。複数プロジェクトで使い回す設定ほど、「どこで開始した会話か」「どのファイルへ保存したルールか」を一緒に記録すると、意図しない一致を見つけやすくなります。細かな深さの判定は、公式資料のパスパターン表を確認します。
権限設定とsandboxは役割を分ける
ReadやEditの拒否ルールは、組み込みファイルツールやClaude Codeが認識する一部のファイルコマンドなどを対象にします。ただし、任意のPythonプログラムが内部でファイルを開くような間接的なアクセスまで、同じ文字列ルールで制限できるとは限りません。Bashの拒否パターンも、実行されるプログラム自体をOSレベルで封じる境界ではありません。
したがって、機密ファイルを扱う業務では「denyを一行足したので、どんなプログラムからも読めない」と説明しないことが大切です。OSレベルでのファイル・ネットワーク制限は、公式のsandbox解説と組織の実行環境を確認します。権限ルールは操作の判断、sandboxは実行環境の制約という二つの観点で設計します。
また、planやautoなどのモードを選ぶ話と、個々のツールへルールを書く話は別です。計画だけ先に見たい場合はプランモードの使い方へ進んでください。本記事の設定例を、すべてのモードの完全な動作保証として扱わないでください。
権限設定が効かないときの確認順
- 今使われている設定を確認する。/permissionsでルールと由来ファイルを見て、編集したファイルが実際に使われているか照合します。
- deny・ask・allowの重なりを見る。同じ呼び出しに一致する上位の拒否・確認がないか調べます。
- ツール名とパスを照合する。表示上の名前と正式なツール名の違い、ReadとEdit、基点と現在地を確認します。
- 実際の呼び出しを読む。余分な引数が付いていないか、別のプログラムを経由して呼び出していないか、コマンドの表記や連結の有無を確認します。
- 組織の管理設定と起動警告を見る。個人設定だけで変更できない制約や、無効なルールを見落としていないか確認します。
点検は「通したかった操作」と「止めたかった操作」の両方で行います。一方だけ確かめると、仕事が進む代わりに許可範囲が広すぎる設定や、何でも止まる設定を見逃します。日時、Claude Codeの版、保存先、試した無害な操作、期待と結果を短く残しておくと、チームへ渡す際の説明にも使えます。
設定項目の正式な定義は公式の設定リファレンスで確認できます。問題を直すときは、いったん全許可にする前に、一致していない一つのルールを特定してください。
Claude Codeの権限設定は、作業の範囲から決める
最初に決めるのは、ルールの数ではなく、毎回任せる操作と確認を残す操作です。/permissionsで現状を読み、狭いルールを一つ加え、意図した一致と不一致を確かめます。ファイルとコマンドの書き方による限界も押さえ、必要ならsandboxや組織管理と組み合わせます。
会社の仕事へ広げる場合は、担当者が承認する箇所、入力資料、完成後の確認方法までそろえると運用を設計しやすくなります。自社業務に合わせた範囲の切り分けは、PLaiのAI社員導入支援でも相談できます。
