Permission Design Guide
Claude Codeの権限設定｜事故を防ぐdeny・ask・allowの実務設計
Claude Codeはファイルを読み、編集し、Bashコマンドや外部ツールを実行できます。権限設定は確認画面を減らすためではなく、誤変更、秘密情報の読み取り、外部送信、本番操作を業務ルールとして止めるために設計します。
結論：最初にdeny、次にask、最後に限定allowを決める
公式資料では、Claude Codeの権限ルールはdeny、ask、allowの順で評価されます。まず絶対に実行させない操作をdenyへ置き、業務判断が必要な操作をaskへ置き、失敗しても影響が限定される反復操作だけをallowへ置きます。具体的なallowを書けば広いdenyを上書きできる、という設計ではありません。
設定だけで安全運用は完成しません。プロンプトやCLAUDE.mdはモデルが何を試すかに影響しますが、何を実行できるかを強制するのは権限ルール、permission mode、サンドボックス、hooksなどです。さらに、コードの妥当性、顧客への影響、法務判断は人間が確認します。
既定の権限動作を理解する
公式の権限表では、作業ディレクトリ内のファイル読み取りやGrepなど読み取り専用操作は原則として承認不要です。Bashコマンドは組み込みの読み取り専用コマンドを除いて承認が必要で、ファイル編集も承認対象です。「読み取り専用だから安全」とは限らず、秘密情報を含むファイルや外部の命令を読むこと自体がリスクになる場合があります。
作業ディレクトリ外の読み取り、追加ディレクトリ、ネットワーク、MCP、WebFetchは別の境界として確認します。エージェントが必要と主張したことは、会社が許可すべきことを意味しません。対象業務に必要な最小範囲だけを許可します。
deny・ask・allowの意味
deny：実行させない操作
denyはツールまたはパターンに一致する操作を拒否します。たとえば秘密情報ファイルのRead、未承認ドメインへのWebFetch、クラウド本番操作、破壊的コマンドを対象にします。ツール名だけの広いdenyは、そのツール自体をモデルのコンテキストから外す動作があります。広さと意図を理解して設定します。
ask：毎回人間が判断する操作
askは一致する操作を実行前に確認します。Git push、PR作成、依存関係追加、ネットワーク送信、データベース変更、クラウド操作など、内容を見て可否が変わる操作に使います。確認者はコマンド名だけでなく、対象、目的、差分、送信データ、戻し方を見ます。
allow：承認なしで進める限定操作
allowは対象ツールを手動承認なしで使えるようにします。既存テスト、lint、型検査、検証用ディレクトリの読み書きなど、対象と影響が明確な操作から始めます。便利だからBash全体を許可するのではなく、実際のコマンドと引数範囲を絞ります。
評価順で起きやすい誤解
deny、ask、allowの順で最初に一致した結果が採用され、ルールの具体性はこの順序を変えません。公式例のようにBash(aws *)をdenyし、Bash(aws s3 ls)をallowしても、広いdenyが優先されます。例外を設けたい場合は、否定ルールの切り方自体を見直します。
askとallowでも同様です。askに一致すれば、より具体的なallowがあっても確認が優先されます。この挙動はfail-closedですが、曖昧なルールを大量に追加すると運用者が意図を説明できなくなります。変更理由、対象業務、期限、責任者をルールと一緒に記録します。
permission modeの選び方
defaultは標準的に初回利用時の確認を行います。planは読み取りと調査を中心にし、ソース変更を行わない計画段階に向きます。acceptEditsは作業範囲内の編集や一部ファイル操作を自動承認します。dontAskは事前承認されていないツールを自動拒否するため、非対話的で保守的な運用に使えます。
autoは依頼との整合性を背景チェックしながら自動承認するモードです。自動チェックがあることと、会社の禁止操作が自動で理解されることは同じではありません。managed settingsで無効化する選択肢もあります。新しいモードやバージョン条件は更新時に公式資料で再確認します。
bypassPermissionsは明示的なaskなど一部を除き確認を飛ばします。公式は、コンテナやVMなど損害範囲を外部で限定した環境だけで使うよう警告しています。開発者の通常端末、秘密鍵がある端末、本番接続端末の標準にしません。
設定スコープとmanaged settings
Claude Codeにはユーザー、プロジェクト、ローカル、管理対象など複数の設定スコープがあります。チームで共有する設定はバージョン管理し、個人端末だけに置く設定や機密値と分けます。企業標準を個人が上書きできる状態では、文書上の規則と実行境界が一致しません。
managed settingsは組織の標準を配布・強制するために使います。許可済みコマンド、禁止ファイル、MCP、プラグインマーケットプレイス、危険なpermission modeの無効化などを検討します。ただし、管理設定の配布に成功したことだけで完了とせず、対象端末で読み込まれた設定と実際の権限要求を検証します。
サンドボックスとの役割分担
権限ルールは「この操作を許可・確認・拒否する」という判断を行います。サンドボックスは、許可されたBashが触れられるファイルシステムやネットワークの技術境界を制限します。片方だけに依存せず、権限ルールで操作を絞り、サンドボックスで被害範囲を絞ります。
サンドボックスを有効にしても、作業範囲内の誤編集、間違ったテスト、機密情報を含む出力、許可済み接続先への不適切送信は起こり得ます。差分レビュー、秘密情報検出、テスト、外部送信前確認を組み合わせます。
業務別の権限例
文書修正
対象を文書ディレクトリへ限定し、ビルドとリンクチェックだけをallow候補にします。パッケージ追加、ネットワーク、Git pushはask、秘密情報ファイルと本番操作はdenyにします。
アプリ開発
リポジトリ内編集、既存テスト、lintを許可候補にし、依存関係追加、マイグレーション、外部API、Docker権限、Git操作を確認対象にします。本番認証情報を作業端末から外し、開発環境の権限に限定します。
インフラ変更
クラウドCLIの変更操作を原則askまたはdenyにし、読み取りも対象アカウントとリージョンを限定します。計画出力、差分、人間承認、変更窓口、ロールバックを必須にし、エージェント単独で本番適用させません。
人間確認ルール
- 確認画面ではコマンド、対象、理由、外部送信、戻し方を見る
- コード変更は差分、テスト、依存関係、秘密情報を確認する
- push、デプロイ、本番変更は作業者以外の承認を置く
- 承認疲れが起きたら一括許可せず、業務とルールを分解する
- 拒否した操作と例外承認を記録し、月次でルールを見直す
- 更新後は代表タスクで権限の挙動を再確認する
導入前チェックリスト
- 対象リポジトリと追加ディレクトリを限定した
- 秘密情報、顧客データ、本番操作のdenyを定義した
- 外部送信、依存追加、push、デプロイをaskにした
- allowはテストなど戻せる反復操作に限定した
- permission modeを業務別に固定した
- サンドボックスとネットワーク制御を併用した
- managed settingsの配布とreadbackを確認した
- 例外申請、緊急停止、再開承認の担当者を決めた
よくある質問
deny・ask・allowはどの順で評価されますか？
deny、ask、allowの順です。具体性では順番が変わらないため、広いdenyに一致する操作を狭いallowで例外化はできません。
bypassPermissionsを通常業務で使えますか？
通常端末の標準にはしません。公式は、損害を起こせないコンテナやVMなどの隔離環境でのみ使うよう警告しています。
CLAUDE.mdに禁止と書けば十分ですか？
十分ではありません。指示はモデルの試行に影響しますが、実行可否を強制する権限設定ではありません。deny、ask、サンドボックスなどで機械的に止めます。
確認が多すぎる時はどうしますか？
一括許可せず、繰り返す安全な操作だけを特定して限定allowへ移します。対象、引数、作業範囲を絞り、変更後に代表タスクで検証します。
公式情報
契約・データ・停止条件まで含む全体設計はClaude Code企業導入チェックリスト、他製品との違いはClaude CodeとCodexの比較も参照してください。
次の一歩
Miraigentの無料診断では、対象業務からdeny・ask・allow、人間確認、ログ、停止条件を整理します。