Permission Design Guide

Claude Code権限設定を安全に設計する｜deny・ask・allowの使い分け

Claude Codeの操作を安全に任せるには、禁止する操作をdeny、人間が内容を見て判断する操作をask、影響を限定できる反復作業をallowに分けます。評価順はdeny、ask、allowで、設定ファイルの置き場所によって適用範囲も変わります。変更後は設定元と実際の挙動を小さな検証環境で確かめてください。

Claude Codeのdeny・ask・allow権限設定

結論：拒否・確認・許可を業務ごとに分ける

まず「実行させない操作」を決め、次に「毎回判断が要る操作」をaskへ、最後に「失敗しても影響が限られ、繰り返し必要な操作」だけをallowへ整理します。たとえば秘密情報を読む操作や本番環境への破壊的変更はdeny候補、外部送信や依存関係の追加はask候補、隔離した開発環境での既存テストはallow候補です。これは業務設計の例であり、すべての組織に共通する既定値ではありません。

権限設定は確認画面を減らすためだけのものではありません。どのデータを読めるか、どの操作を人が承認するか、誤操作の影響をどこまでにするかを、業務のリスクに合わせて決めます。プロンプトやCLAUDE.mdに禁止事項を書くだけでは実行権限を制限できないため、Claude Codeの権限ルール、設定スコープ、必要に応じてサンドボックスを組み合わせます。

deny・ask・allowの評価順を理解する

公式資料では、ルールはdeny、ask、allowの順で評価され、最初に一致したルールが結果になります。具体的なルールを追加しても、この順番は変わりません。

区分役割業務での考え方
deny一致する操作を拒否する秘密情報、本番の破壊的変更など、通常の作業で実行させない対象
ask一致する操作の前に確認する外部送信、依存追加、共有範囲の変更など、内容を見て判断する対象
allow一致する操作を手動確認なしで許可する対象と影響を限定し、繰り返し実行するテストや検査

たとえば広いdenyがあるとき、そこへ一致する操作をより細かいallowで例外にすることはできません。askとallowが重なる場合もaskが優先されます。例外が必要ならallowを増やす前に、denyの対象範囲や業務上の判断基準を見直してください。ルールの順序と具体性を混同すると、意図した許可が通らないだけでなく、設定を読んだ人が実際の挙動を誤解します。

公式資料は、ツール名だけのdenyと、ツール内のパターンを指定するdenyを区別しています。Bash全体をdenyした場合、ツール自体がClaudeのコンテキストから外れる仕様です。一方、パターン指定ではツールを残したまま、一致する呼び出しを拒否します。止める範囲を先に決めてください。

設定ファイルの置き場所で共有範囲が変わる

ルールの内容だけでなく、どの設定ファイルに保存するかも確認します。公式の設定ガイドはユーザー、共有プロジェクト、プロジェクトローカル、managed settingsを区別しています。

設定の範囲主なファイル適用範囲
ユーザー~/.claude/settings.jsonこの端末のユーザーが使う各プロジェクト
共有プロジェクト.claude/settings.jsonフォルダーを使うチーム。共有する場合はリポジトリへ含める
プロジェクトローカル.claude/settings.local.jsonこのプロジェクトの自分用設定。チーム共有には使わない
管理対象managed-settings.jsonなど組織が配布するポリシー

Claude CodeはGitリポジトリ内で初めてプロジェクトローカル設定へ書き込む際、まだ除外設定がない場合にGitのグローバル除外ファイルへ加えます。手動で作成した場合は、自分で.gitignoreへ追加してください。共有するルールを個人用ファイルへ置くとチームに反映されず、逆に個人の例外を共有設定へ置くと他の利用者にも影響します。管理対象の方針を組織で配布する場合は、共有プロジェクトの設定とmanaged settingsを混同しないことが大切です。適用結果を調べるときはmanaged settingsの診断手順も参照してください。

ルールを決める前に操作を分類する

設定画面を開く前に、業務でClaude Codeに依頼する操作を一覧にします。機能名だけでなく、対象のデータ、実行場所、外部への送信有無、失敗したときの戻し方を記録すると、allowへ入れてよい範囲を判断しやすくなります。

  • 拒否する操作秘密情報や顧客データの不必要な読み取り、本番環境の破壊的操作など。必要な業務があれば、別の承認済み手順へ切り出します。
  • 毎回確認する操作外部へデータを送る操作、依存関係や共有範囲を変える操作、Git pushやデプロイなど、対象や差分によって判断が変わるもの。
  • 限定して許可する操作対象リポジトリ内で完結する既存テストや静的検査など、範囲と影響が把握できる作業。環境が変わったら許可範囲も見直します。

迷う操作を一律にallowへ寄せると、人間の確認を省く理由が曖昧になります。逆に全操作をdenyにすると、必要な作業の例外が個別に増えます。まず業務ごとに拒否・確認・許可の判断を決め、チームで理由を共有できる形にしてから設定へ反映してください。

検証用リポジトリで挙動を確かめる

  1. 本番認証情報や顧客データがない検証用リポジトリを用意し、現行設定と変更理由を記録する。
  2. 代表操作を「拒否される」「確認が出る」「手動確認なしで進む」に分類し、期待する結果を先に書く。
  3. 設定を一度に複数変えず、ルールを一つずつ追加する。対象と設定ファイルの範囲が合っているかを確認する。
  4. セッション内で/permissionsを開き、各ルールと、どのsettings.jsonから来たかを照合する。
  5. ダミーのファイルやテスト用操作で代表ケースを試し、表示された結果が期待と一致するかを確認する。重なるdeny・ask・allowがあれば評価順も確かめる。

承認を求められた場合は、コマンド名だけで判断しません。対象ファイルや環境、実行目的、差分、外部送信の有無、失敗時の戻し方を見てください。検証で不要な確認が分かった場合も、同じコマンド全体を許可するのではなく、対象・引数・実行場所を狭められるか先に検討します。リスクを伴う設定を実際の本番環境で試してはいけません。

サンドボックスと人間確認を組み合わせる

権限ルールは「その操作を拒否・確認・許可するか」を決めます。サンドボックスはBash操作について、ファイルシステムとネットワークの隔離を行う機能です。役割が異なるため、どちらか一方で他方を置き換えないでください。サンドボックスを使っていても、許可された作業範囲内の誤編集や、期待と違うコード変更が起きる可能性は残ります。

権限設計の例を整理し、秘密ファイルの読み取りを遮断する構成を確認したい場合は秘密ファイルをdenyする手順へ進めます。組織全体の権限、対象業務、例外承認、利用者教育まで決める場合はClaude Code企業導入チェックリストを参照してください。

人間が確認する操作では、目的、対象、実行コマンド、外部送信、差し戻し方法を記録します。承認者が作業者と同じか、組織の基準に合うかは業務で定めてください。権限ルールだけでコードの正しさや本番影響まで保証するわけではないため、差分レビュー、テスト、デプロイ承認を別に保ちます。

導入前に確認する項目

  • deny、ask、allowへ分類する業務操作と理由がある
  • 最初に一致したルールが適用されることを確認した
  • 広いdenyをallowで例外にできると思い込んでいない
  • ユーザー、共有プロジェクト、プロジェクトローカル、管理対象の保存先を区別した
  • /permissionsで読み込まれたルールと設定元を確認した
  • 本番情報を含まない環境で代表操作を試した
  • サンドボックス、差分レビュー、デプロイ承認の役割を分けた
  • ルールの変更理由と例外の見直し担当を記録した

よくある質問

deny・ask・allowはどの順で評価されますか？

deny、ask、allowの順です。最初に一致したルールで決まり、具体性が高いallowでも広いdenyやaskを上書きできません。

広いdenyを具体的なallowで例外にできますか？

できません。denyが一致する操作は拒否されます。必要な例外がある場合は、まず拒否対象の範囲と業務上の条件を見直してください。

チームで共有する設定ファイルはどれですか？

共有プロジェクト設定の.claude/settings.jsonが候補です。共有するときは、そこに置く内容がチーム全体へ適用される範囲を確認します。組織で配布する管理ポリシーはmanaged settingsと分けます。

CLAUDE.mdに禁止と書けば実行を止められますか？

止められません。指示はClaudeが何を試すかに影響しますが、実行可否は権限ルールなどClaude Code側の設定で制御します。

公式情報

ルールの定義と設定の適用範囲は公式ドキュメントで更新されるため、導入や改定時に対象バージョンと現在の設定元を確認します。

次の一歩

業務ごとに権限、例外承認、データの扱い、利用者向け手順を整理したい場合は、Miraigentの無料診断をご利用ください。