claude code 権限設定｜2026年版ガイド

Claude Code 権限設定の完全ガイド｜実務で使える設定例と運用ノウハウ

Claude Codeを業務で活用する際、最初の壁になるのが権限設定です。ファイルの読み書き、コマンド実行、ネットワークアクセス──どこまでClaudeに許可するかを誤ると、意図しないファイル変更や外部通信が発生するリスクがあります。一方で制限しすぎると、自動化の恩恵が半減してしまいます。

当社（クリスタルメソッド）ではClaude Codeを開発・AIプロジェクトの実務で日常的に利用しており、権限設定の最適解を試行錯誤してきました。本記事では、Claude Codeの権限モデルの基本構造から、settings.jsonの具体的な設定例、チームでの運用ルールまで、実際の現場ノウハウを交えて体系的に解説します。

Claude Codeの権限モデル：3つのレイヤーを理解する

Claude Codeの権限設定を正しく理解するには、まず「どこで何を制御しているか」という3レイヤー構造を把握することが重要です。

実務上、最も細かくコントロールできるのがレイヤー②の設定ファイルです。ここを適切に設計することで「自動化したい操作は承認なしでスムーズに進める」「危険な操作は必ず手動確認する」という二段構えが実現できます。

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

Claude Codeは設定ファイルを複数の場所から読み込み、スコープに応じて優先順位が決まります。

スコープ	ファイルパス	適用範囲
グローバル	~/.claude/settings.json	全プロジェクト共通の基本設定
プロジェクト（共有）	.claude/settings.json（リポジトリルート）	チーム全員が共有する設定。Gitで管理可能
プロジェクト（個人）	.claude/settings.local.json	個人の好みや環境固有の設定。.gitignore推奨

優先順位はプロジェクト（個人）＞プロジェクト（共有）＞グローバルの順です。チーム開発では「セキュリティポリシーはプロジェクト共有設定に書き、個人の利便性設定は.local.jsonに逃がす」という分離が実用的です。当社でも同様の運用をしており、本番に関わる設定はすべてプロジェクト共有設定でGit管理しています。

permissions（権限設定）の構造と書き方

settings.json内のpermissionsキーが権限設定の核心です。以下が基本的な構造です。

{
  "permissions": {
    "allow": [
      "Bash(git *)",
      "Bash(npm run *)",
      "Read(**)",
      "Edit(**)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)"
    ]
  }
}

allowとdenyのルール評価順序

重要なのはdenyがallowより常に優先される点です。同じコマンドがallowとdenyの両方にマッチする場合、必ずdenyが勝ちます。「基本は広く許可し、危険なものだけ明示的に禁止する」戦略と、「基本は全拒否し、必要なものだけ許可する」戦略のどちらでも設計できますが、セキュリティ観点では後者（ホワイトリスト型）が推奨されます。

ツール種別ごとの権限指定

Claude Codeが使用するツールは大きく4種類に分類され、それぞれ異なる粒度で制御できます。

ツール種別	記法例	制御できる操作
Bash	Bash(git *)	シェルコマンドの実行。最もリスクが高くきめ細かい設定が必要
Read	Read(src/**)	ファイル・ディレクトリの読み取り
Edit / Write	Edit(src/**)	ファイルの作成・編集・削除
WebFetch	WebFetch(domain:api.example.com)	外部URLへのHTTPアクセス

グロブパターンの使い方

パスやコマンドの指定にはグロブパターンが使えます。よく使う記法を整理します。

• *：単一ディレクトリ内の任意の文字列（サブディレクトリは含まない）
• **：再帰的に任意のパス（サブディレクトリを含む）
• Bash(npm run *)：npm runで始まる全コマンドを許可
• Read(src/**)：src以下の全ファイルを読み取り許可
• Edit(*.md)：カレントディレクトリのMarkdownファイルのみ編集許可

実務で使える設定テンプレート集

当社の実運用経験から、用途別の設定テンプレートを紹介します。そのままコピーして、プロジェクトに合わせて調整してください。

パターン①　フロントエンド開発（Node.js / React）

{
  "permissions": {
    "allow": [
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git diff *)",
      "Bash(git status)",
      "Bash(git log *)",
      "Bash(npm run lint)",
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(npm install)",
      "Read(**)",
      "Edit(src/**)",
      "Edit(public/**)",
      "Edit(*.json)",
      "Edit(*.md)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(git reset --hard *)",
      "Bash(rm *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Edit(.env*)"
    ]
  }
}

このテンプレートのポイントは、git pushと.envファイルの編集を明示的にdenyしている点です。誤ったコードが自動でリモートにプッシュされる事故と、APIキーが書き換えられるリスクを排除しています。

パターン②　Pythonデータ分析・機械学習

{
  "permissions": {
    "allow": [
      "Bash(python *)",
      "Bash(pip install *)",
      "Bash(pytest *)",
      "Bash(git *)",
      "Read(**)",
      "Edit(*.py)",
      "Edit(*.ipynb)",
      "Edit(*.yaml)",
      "Edit(*.csv)",
      "Edit(requirements.txt)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(sudo *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Edit(.env*)",
      "Edit(secrets/*)"
    ]
  }
}

パターン③　読み取り専用レビューモード

コードレビューやドキュメント調査など、「読むだけ・提案だけ」させたい場面に使うミニマル設定です。当社ではオンボーディング中のメンバーが初めてClaude Codeを触るときに、まずこの設定から始めてもらっています。

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Bash(git log *)",
      "Bash(git diff *)",
      "Bash(git status)"
    ],
    "deny": [
      "Bash(*)",
      "Edit(*)"
    ]
  }
}

ここで注意が必要なのは、denyに"Bash(*)"を書いた場合、allowに書いたBashコマンドよりdenyが優先される点です。上記テンプレートではallowにBashコマンドを書きつつdenyにもBash(*)があるため、Bashは全て拒否されます。読み取り専用を徹底するなら、allowからBashを削除し、denyのみに記述するか、またはallowをReadのみにした上でBash系は一切書かないのが明確です。

–dangerously-skip-permissions フラグの扱い

Claude Codeには--dangerously-skip-permissionsというフラグがあり、これを指定すると全ての権限確認をスキップして自動実行します。CI/CDパイプラインや完全自動化スクリプトで使われることがありますが、名前が示す通り「危険な使い方」です。

当社では、このフラグをローカル開発機では原則使用しないルールにしています。使用するのは、ネットワーク制限を施したDocker環境内でのテスト自動化のみです。

インタラクティブ承認モードの活用

設定ファイルに書かれていない操作が発生した場合、Claude Codeはデフォルトでインタラクティブに確認を求めます。このとき選択できる選択肢は以下の通りです。

「Yes, and don’t ask again」を安易に使うと、意図せずローカル設定が積み上がっていく問題があります。当社では、このオプションを使った後に必ずsettings.local.jsonの内容を見直し、本当に永続許可すべきか確認する習慣を設けています。

CLAUDE.md との連携：権限設定の意図を伝える

権限設定はsettings.jsonだけでなく、CLAUDE.mdファイルとの組み合わせでより効果を発揮します。CLAUDE.mdはClaudeに対してプロジェクト固有の文脈・制約・ルールを自然言語で伝えるファイルです。

例えば以下のような記述をCLAUDE.mdに加えることで、権限設定の意図を補強できます。

## セキュリティルール

- `.env`ファイルは絶対に編集・読み取りしないこと
- git pushは必ず人間が手動で行う
- 外部APIへの直接リクエストは行わない
- `secrets/`ディレクトリ以下には一切アクセスしない

## 推奨される作業の流れ

1. まず既存コードをReadで把握する
2. 変更案を提案してから実装に移る
3. 変更後は必ずlintとテストを実行する

settings.jsonが機械的な実行制御なのに対し、CLAUDE.mdは「なぜその制約があるのか」という文脈をClaudeに理解させます。両方を使うことで、技術的制約と意図の両面からリスクをコントロールできます。

権限設定のよくある失敗パターンと対処法

失敗①　allowとdenyの優先順位を誤解する

「allowを先に書けばdenyより優先される」と誤解するケースがあります。Claude Codeのdenyは評価順序に関係なく常にallowに優先します。部分的に許可したいコマンドがある場合は、denyのパターンをより狭く書くことで対処します。

失敗②　環境変数ファイルをallowに含めてしまう

"Edit(**)"と書くと.envファイルも含まれます。必ず"Edit(.env*)"をdenyに追加するか、allowを"Edit(src/**)"のように具体的なディレクトリに絞りましょう。

失敗③　グローバル設定に業務固有のルールを書いてしまう

~/.claude/settings.jsonに特定プロジェクトのパスや制約を書くと、別プロジェクトで意図しない挙動を招きます。業務固有のルールは必ずプロジェクトスコープの設定ファイルに書く習慣をつけましょう。

失敗④　denyリストが育っていないまま運用を続ける

初期設定のまま半年・1年運用していると、当初想定していなかった操作が増えてきます。週次や月次の定期レビューで「最近どんなインタラクティブ承認が発生したか」を確認し、denyリストをアップデートすることが重要です。

チーム開発における権限設定の運用ルール

個人利用と違い、チームでClaude Codeを使う場合は権限設定のガバナンスが必要になります。以下は当社が実際に採用している運用ルールです。

1. プロジェクト共有設定はPRレビュー必須：.claude/settings.jsonの変更はコードレビューと同様、最低1名のレビュー承認を必要とする
2. denyリストはデフォルトセットを定義：組織共通の「絶対にdenyするコマンド」セットをドキュメント化し、全プロジェクトに適用
3. settings.local.jsonは.gitignoreに追加：個人設定がリポジトリに混入しないよう徹底する
4. 新規プロジェクトはテンプレートから開始：権限設定済みのプロジェクトテンプレートを用意し、ゼロから設定する手間と抜け漏れを防ぐ
5. インシデントログを残す：意図しない操作が発生した場合は原因と対処をドキュメント化し、設定改善に活かす

セキュリティ強化のための追加設定

ネットワークアクセスの制御

WebFetchツールのドメイン制限は、意図しない情報流出対策として有効です。

{
  "permissions": {
    "allow": [
      "WebFetch(domain:docs.anthropic.com)",
      "WebFetch(domain:api.github.com)"
    ],
    "deny": [
      "WebFetch(*)"
    ]
  }
}

ただし上述の通り、denyは常にallowより優先されるため、"WebFetch(*)"をdenyに書くとallowのWebFetchも全てブロックされます。ホワイトリスト方式で運用するには、denyにWebFetch(*)を書くのではなく、allowに明示的に許可するドメインのみを列挙し、denyにはWebFetchを書かないアプローチが正確です。または、Claude Codeのドキュメントで最新の評価ロジックを確認した上で設計してください。

機密ディレクトリへのReadアクセスも制限する

Editだけでなく、Readも制限すべきディレクトリがあります。.ssh/、secrets/、credentials/などは以下のようにdenyします。

{
  "permissions": {
    "deny": [
      "Read(.ssh/**)",
      "Read(secrets/**)",
      "Read(credentials/**)",
      "Read(.env*)",
      "Edit(.ssh/**)",
      "Edit(secrets/**)",
      "Edit(.env*)"
    ]
  }
}

まとめ

Claude Codeの権限設定は、「何を自動化するか」と「何を人間が守るか」を明確にするための設計作業です。本記事で解説したポイントを整理します。

• 権限は3レイヤー構造で管理され、settings.jsonがユーザー制御の核心
• 設定ファイルはグローバル・プロジェクト共有・個人の3スコープで優先順位がある
• denyはallowに常に優先する。この挙動を前提に設計すること
• 用途（フロントエンド開発・データ分析・レビュー専用など）に応じてテンプレートを使い分ける
• CLAUDE.mdと組み合わせて「機械的制御＋文脈の伝達」を両立させる
• チーム運用ではPRレビュー・デフォルトdenyセット・テンプレート化がガバナンスの基盤

権限設定は一度決めて終わりではなく、プロジェクトの進化やチームの変化に合わせて継続的に見直すものです。当社でも定期的に設定を棚卸しし、「過剰に制限していないか」「新たなリスクが生まれていないか」を確認しながら運用しています。まずは本記事のテンプレートを出発点にして、自社のセキュリティポリシーに合った設定を育てていくことをおすすめします。

関連記事

• Claude Codeとは（総合ガイド）
• claude code api 料金
• claude code codex 比較
• claude code cursor 比較
• claude code hooks