Claude Codeの権限設定完全ガイド｜allow・ask・denyで自動化事故を防ぐ

Claude Codeを業務自動化に使うとき、最も重要なのは「何を任せるか」より先に「何を実行できない状態にするか」を決めることです。プロンプトやCLAUDE.mdに禁止事項を書くだけでは、実行権限そのものは制限されません。Anthropicの公式ドキュメントでも、指示文はClaudeが何を試みるかには影響する一方、実際に許可・拒否を強制するのは権限ルール、権限モード、PreToolUse Hookだと説明されています。

この記事では、Claude Codeのallow・ask・denyをどう分けるか、個人利用と自動実行で設定をどう変えるか、事故につながりやすい広すぎる許可をどう避けるかを、公式仕様に沿って具体化します。

結論：最初は「読み取りを広く、変更を狭く、外部送信を拒否」にする
Claude Codeの権限システムを理解する
1. 読み取り・Bash・ファイル変更で挙動が違う
2. ルール形式は Tool または Tool(specifier)
まず作るべき安全な設定例
危険な設定と、その理由
用途別の権限モード
課金・プランは権限設定と分けて判断する
導入手順：読み取りから限定実行へ段階的に広げる
失敗しやすいポイント
実務で使える最小チェックリスト
まとめ
出典
次に決めること

結論：最初は「読み取りを広く、変更を狭く、外部送信を拒否」にする

安全な初期設計は、次の三層です。

読み取り：作業ディレクトリ内のRead・Grep・Globや、公式に読み取り専用と判定されるコマンドを中心に許可する。
編集・テスト：対象ディレクトリと具体的なコマンドだけを許可する。必要に応じて毎回確認する。
公開・削除・認証変更：git push、本番デプロイ、外部APIへの書き込み、秘密情報の読み取り、破壊的削除は拒否する。

Claude Codeの権限判定は、deny → ask → allowの順です。より具体的なallowがあっても、広いdenyに一致すればdenyが優先されます。したがって「危険操作をdenyで囲い、その内側で安全な操作だけallowする」という例外設計はできません。denyは本当に全面禁止したい範囲に使い、都度判断したい操作はaskに分ける必要があります。

Claude Codeの権限システムを理解する

読み取り・Bash・ファイル変更で挙動が違う

公式ドキュメントでは、作業ディレクトリ内のファイル読み取りやGrepは原則として承認不要です。Bashは、組み込みの読み取り専用コマンドを除いて承認が必要です。ファイル編集は承認が必要で、「今後確認しない」を選んでも基本的にはセッション終了までの許可です。一方、Bashコマンドを恒久許可した場合は、Gitリポジトリ直下の.claude/settings.local.jsonへ保存され、同じリポジトリの次回セッションにも影響します。

ここが重要です。作業中に何気なく「今後確認しない」を選ぶと、その場だけではなく、同じリポジトリで将来起動するClaude Codeにも許可が残る場合があります。定期的に/permissionsを開き、どの設定ファイルからルールが来ているかを確認してください。

ルール形式は Tool または Tool(specifier)

権限ルールはToolまたはTool(specifier)で書きます。例えば、Bashだけを書くと全Bashコマンドに一致します。これは非常に広い設定です。通常はBash(npm run test *)やBash(git diff *)のように、目的が限定されたルールを使います。

ファイルアクセスでは、現在の仕様上、読み取り制限はRead(path)、編集制限はEdit(path)を使います。Write(path)やGlob(path)をパス制限として書いても、期待したファイル権限判定に使われない場合があるため注意が必要です。

まず作るべき安全な設定例

以下は、コードを調査し、テストを実行し、ドキュメントだけ編集させる想定の保守的な例です。

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(npm run test *)",
      "Bash(npm run lint *)",
      "Edit(/docs/**)"
    ],
    "ask": [
      "Bash(git commit *)",
      "Edit(/src/**)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(rm -rf *)",
      "Read(.env)",
      "Read(**/.env)",
      "Edit(/.github/workflows/**)"
    ]
  }
}

この例では、調査と検査は進められますが、ソースコード変更とコミットは確認を挟みます。外部へ影響するpush、破壊的削除、環境変数ファイルの読み取り、公開経路になり得るGitHub Actionsの変更は止めます。

ただし、設定はそのままコピペして終わりではありません。プロジェクトのテストコマンドがpytestなら、そのコマンドだけをallowへ追加します。デプロイにnpm run deployを使うなら、テスト用のnpm run *のような広いルールは避け、npm run test *とnpm run lint *に限定してください。

危険な設定と、その理由

危険例1：Bashを丸ごとallowする

{
  "permissions": {
    "allow": ["Bash"]
  }
}

Bashは全Bashコマンドに一致します。テストだけでなく、削除、認証操作、ネットワーク通信、デプロイも許可範囲になります。自動化を止めないためにBash全体を許可する設計は、短期的には楽でも、事故時の被害範囲が大きすぎます。

危険例2：curlのURLを文字列だけで制限する

公式ドキュメントは、Bashの文字列パターンでcurlの接続先を安全に制限することは脆弱だと説明しています。オプションの位置、リダイレクト、変数展開、短縮URLなどで意図した制限を外れる可能性があります。

外部通信を限定する場合は、Bashのcurlやwgetをdenyし、許可ドメインを指定できるWebFetch(domain:example.com)を使う方が明確です。さらに強い制御が必要なら、PreToolUse HookでURLを検査します。

危険例3：bypassPermissionsを日常環境で使う

bypassPermissionsは多くの確認を省略します。公式ドキュメントも、コンテナやVMのような隔離環境でのみ使うよう警告しています。普段使いのMacや、秘密情報と本番認証が存在するリポジトリで常用すべき設定ではありません。

確認を減らしたい場合は、まずacceptEditsか、必要なコマンドだけをallowする方法を検討します。非対話実行では、許可されていない操作を自動拒否するdontAskも選択肢です。止まらずに何でも実行する状態ではなく、許可済み操作だけで完結するワークフローを先に設計してください。

用途別の権限モード

調査・設計だけ：plan

planは、ファイルを読み、読み取り専用のシェルコマンドで調査しながら、ソースファイルを変更しない用途に向きます。未知のリポジトリを最初に把握するとき、変更案だけ欲しいとき、レビュー前の影響範囲調査に適しています。

対話しながら編集：default または acceptEdits

defaultは標準的な運用です。初回の操作ごとに確認し、信頼できるコマンドだけを段階的に許可できます。acceptEditsは作業ディレクトリ内の編集と一部ファイル操作を自動承認しますが、すべてのBashやディレクトリ外操作まで無条件に許すわけではありません。

無人実行：dontAsk＋明示的allow

GitHub Actionsや定時処理のように人が確認できない環境では、未許可操作を都度質問する設計は停止原因になります。だからといって権限を全部飛ばすのではなく、dontAskと明示的allowを組み合わせ、必要なツールだけで処理が完結するようにします。

例えば「記事ファイルを生成してstateブランチへ保存する」処理なら、読み取り、指定ディレクトリへの新規作成、特定の検査コマンド、特定ブランチへの保存だけを許可します。WordPress公開、X投稿、mainへのpushは別工程に分離し、生成担当から権限を外します。これにより、文章生成の誤りがそのまま外部公開へ直結しません。

課金・プランは権限設定と分けて判断する

権限設定は「何を実行できるか」の制御であり、料金プランそのものではありません。Claude Codeへの認証経路は複数あります。個人はClaude ProまたはMaxのClaude.aiアカウントでログインでき、チームはTeams・Enterprise、API課金を使う組織はClaude Console、クラウド基盤を使う組織はAmazon BedrockやGoogle Cloudなどを選べます。

個人が対話中心で使うなら、まず既存のProまたはMax契約内で利用状況を確認するのが分かりやすい設計です。CIや無人処理で利用量を明確に分離したい場合は、ConsoleのAPI課金やクラウドプロバイダー経由を検討します。どの認証方式でも、権限を広くする必要はありません。認証・課金経路と、ツール権限は別の層として管理してください。

また、環境変数にANTHROPIC_API_KEYが残っていると、サブスクリプションでログインしていてもAPIキーが優先される場合があります。想定外の課金や認証エラーを避けるため、/statusで実際のログイン方式を確認し、サブスクリプションを使いたい場合は不要なAPIキーを環境から外します。

導入手順：読み取りから限定実行へ段階的に広げる

planで開始する：リポジトリ構造、テスト方法、公開経路、秘密情報の位置を調査する。
禁止対象を先に決める：本番公開、push、削除、課金変更、認証情報、外部送信をdenyまたは別工程へ分離する。
必要な検査だけallowする：git diff、テスト、lintなど、結果を確認できる操作を個別に許可する。
編集範囲を限定する：最初はdocsや作業用ディレクトリだけにし、ソース変更はaskへ置く。
無人実行はdontAskで試験する：不足権限があれば停止する状態でドライランし、必要なルールだけ追加する。
/permissionsを監査する：一時的な作業で増えた恒久許可を削除し、設定元も確認する。

失敗しやすいポイント

CLAUDE.mdだけで禁止したつもりになる：指示は行動方針であり、強制境界ではありません。
denyの中にallow例外を作ろうとする：denyが先に評価されるため、例外allowは通りません。
ワイルドカードを広げすぎる：Bash(npm *)は、テスト以外のnpmコマンドも対象になります。
複合コマンドを一つの安全操作だと思う：&&、;、パイプなどで分かれた各サブコマンドが個別に判定されます。
Read/Editルールで任意のスクリプト内部まで防げると思う：PythonやNodeのプログラムが内部でファイルを開く処理までは、ファイルルールだけで完全に防げません。必要ならOSレベルのsandboxを併用します。
無人処理にブラウザログインだけを使う：長時間処理ではログイン期限切れで停止する可能性があります。CI向けの認証方式と期限監視を用意します。