Claude Code 権限設定

Claude Code は階層型権限システムを使用して機能性とセキュリティのバランスを取っており、細粒度の権限ルール、権限モード、サンドボックスポリシーをサポートして、Claude がアクセスおよび実行できる操作を制御します。権限を適切に設定することで、AI が効率的にタスクを完了できるだけでなく、誤操作によるコードの破損や機密ファイルの漏洩を防ぐことができます。

Claude Code v1.1.1 以降、新しい権限設定方式が推奨されています。以前のtoolsブール設定は引き続きサポートされますが、新しい権限ルール構文への移行が推奨されます。

権限システム概要

Claude Code の権限システムは操作を3つのカテゴリに分類し、異なるタイプの操作には異なるデフォルト権限ポリシーがあります：

ツールタイプ 例 承認が必要か 永続的に許可される動作
読み取り専用操作 ファイル読み取り、Grep 検索 否 該当なし
Bash コマンド Shell コマンド実行 である プロジェクトディレクトリとコマンドごとに永続的に有効
ファイル変更 Edit/Write ファイル である セッション終了まで

3つの権限アクション

各権限ルールは最終的に以下の3つのアクションのいずれかに解決されます：

アクション 効果 適用シーン
"allow" 承認不要で、直接自動実行 低リスク・高頻度の操作（git status、npm run build など）
"ask" 承認プロンプトを表示し、許可するかどうかをユーザーが決定 一定のリスクがある操作（ファイル書き込み、危険なコマンド実行など）
"deny" 直接ブロックし、実行もプロンプト表示もされない 明確に許可されていない危険な操作（git push、rm -rf など）

ルールの優先順位：deny → ask → allow。最初に一致したルールが優先されるため、deny ルールは常に allow と ask より優先されます。

権限モード

権限モードは、Claude が操作を実行する前にユーザーに確認するかどうかを制御します。タスクによって必要な自律性のレベルが異なります。

1、利用可能な6つのモード

モード 説明 最も適したシーン
default 標準動作：各ツールを初めて使用するときに権限プロンプトを表示 入門学習、機密性の高い作業で完全な監督が必要な場合
acceptEdits セッションのファイル編集権限を自動的に受け入れる（保護ディレクトリを除く） レビュー中のコードを反復処理する場合
plan Plan Mode：Claude は分析のみ可能で、ファイルの変更やコマンドの実行は不可 コードベースの調査、リファクタリングの計画
auto ツール呼び出しを自動承認し、バックグラウンドでセキュリティチェックを実行（研究プレビュー） 長時間実行タスク、プロンプト疲れの軽減
dontAsk 権限ルールで事前承認されていない限り、ツール呼び出しを自動拒否 ロック環境、CI パイプライン
bypassPermissions 権限プロンプトをスキップするが、保護ディレクトリへの書き込みは引き続きプロンプトが表示される 隔離コンテナと VM のみ

保護ディレクトリの説明：モードに関係なく、.git、.vscode、.idea、.huskyと.claudeへの書き込みは自動承認されることはありません。ただし、.claude/commands、.claude/agentsと.claude/skills。

2、権限モードの切り替え

2、権限モードの切り替え按 Shift+Tabセッション中の切り替え：default → acceptEdits → plan → auto

循環切り替え

claude --permission-mode plan
claude --permission-mode bypassPermissions

起動時にモードを指定：

例

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

権限ルールの構文

1、基本形式

1、基本形式Tool 或 Tool(specifier)：

例

{
  "permissions": {
    "allow": ["Bash", "WebFetch", "Read"],
    "deny": ["Edit"]
  }
}

2、すべてのツール使用をマッチング

例

2、すべてのツール使用をマッチング 指定子のないルールは、そのツールのすべての使用にマッチングします：
Bash ルール
WebFetch 効果
Read すべての Bash コマンドにマッチング
Edit すべてのネットワーク取得リクエストにマッチング

Bash(*)すべてのファイル読み取りにマッチングBashすべてのファイル編集にマッチング

3、指定子を使用した細粒度制御

例

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",     3、指定子を使用した細粒度制御
      "Read(./.env)",             例
      "WebFetch(domain:example.com)"  // 正確なコマンドにマッチング
    ]
  }
}

4、ワイルドカードパターン

// example.com への取得リクエストにマッチング*4、ワイルドカードパターン

例

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",         を含む glob パターンをサポートしており、ワイルドカードはコマンド内の任意の位置に配置できます：
      "Bash(git commit *)",      例
      "Bash(git * main)",        // npm run build、npm run test などにマッチング
      "Bash(* --version)",       // git commit -m "message" などにマッチング
      "Bash(* --help *)"         // git checkout main、git merge main などにマッチング
    ],
    "deny": [
      "Bash(git push *)"         // --version パラメータを含む任意のコマンドにマッチング
    ]
  }
}

// --help パラメータを含む任意のコマンドにマッチングBash(ls *)// すべての git push 操作をブロックls -laワイルドカード前のスペースに注意：lsof；Bash(ls*)

ツール固有の権限ルール

1、Bash コマンド

にはマッチングしない。 両方にマッチングする。
Bash(npm run build) 仅 npm run build
Bash(npm run test *) npm run test、npm run test --coverage
Bash(npm *) ツール固有の権限ルール
Bash(* install) 1、Bash コマンド
Bash(git * main) git checkout main、git merge main

ルールマッチング例domain:npm で始まる任意のコマンド

2、Read と Edit（ファイル操作）

重要な制限：

コマンドの引数を制約しようとする Bash 権限パターンは脆弱になる可能性があります。URL 前のオプション、異なるプロトコル、リダイレクト、変数、余分なスペースによりマッチングに失敗する可能性があります。WebFetch ツールと 権限を組み合わせて URL フィルタリングを行うことをお勧めします。 2、Read と Edit（ファイル操作）
//path ファイルパスは複数のパスプレフィックスパターンをサポートしています： Read(//Users/alice/secrets/**)パターンプレフィックス/Users/alice/secrets/**
~/path 意味 Read(~/Documents/*.pdf)例/Users/alice/Documents/*.pdf
/path 絶対パス（ファイルシステムのルートから） Edit(/src/**/*.ts)<project root>/src/**/*.ts
path 或 ./path にマッチング Read(*.env)ホームディレクトリのパス<cwd>/*.env

例

{
  "permissions": {
    "allow": [
      "Edit(/docs/**)",          にマッチング
      "Read(~/.zshrc)",         // ホームディレクトリの .zshrc の読み取りを許可
      "Edit(//tmp/scratch.txt)", // 絶対パスの一時ファイルの編集を許可
      "Read(src/**)"            // カレントディレクトリの src サブディレクトリ内のファイルの読み取りを許可
    ],
    "deny": [
      "Read(*.env)",            // .env ファイルの読み取りをブロック（秘密鍵の漏洩防止）
      "Edit(//etc/**)"          // システムディレクトリ内のファイルの編集をブロック
    ]
  }
}

注意：Read および Edit の deny ルールは Bash サブプロセスには適用されませんcat .envOS レベルの強制力を得るには、サンドボックスを有効にする必要があります。

3、WebFetch（ネットワークリクエスト）

例

{
  "permissions": {
    "allow": [
      "WebFetch(domain:github.com)",    // GitHub へのアクセスを許可
      "WebFetch(domain:api.example.com)" // 内部 API へのアクセスを許可
    ],
    "deny": [
      "WebFetch(domain:untrusted.com)"  // 信頼できないドメインへのアクセスをブロック
    ]
  }
}

4、MCP（Model Context Protocol）

例

{
  "permissions": {
    "allow": [
      "mcp__puppeteer",                      // puppeteer サーバーが提供する任意のツールを許可
      "mcp__puppeteer__*"                    // puppeteer サーバーからのすべてのツールを許可
    ],
    "deny": [
      "mcp__puppeteer__puppeteer_navigate"  // 特定のツールをブロック
    ]
  }
}

5、Agent（サブエージェント）

例

{
  "permissions": {
    "allow": [
      "Agent(Explore)",           // Explore サブエージェントの使用を許可
      "Agent(Plan)"               // Plan サブエージェントの使用を許可
    ],
    "deny": [
      "Agent(my-custom-agent)"    // カスタムサブエージェントをブロック
    ]
  }
}

作業ディレクトリ設定

デフォルトでは、Claude Code は起動時の作業ディレクトリとそのサブディレクトリへのアクセスのみを許可します。プロジェクトディレクトリ外のパスにアクセスする必要がある場合は、明示的な設定が必要です。

1、アクセス拡張方法

  • 起動時：使用するもの--add-dir <path>CLI パラメータ
  • セッション中：使用するもの/add-dirコマンド
  • 永続設定：settings.json に追加するadditionalDirectories

例

{
  "additionalDirectories": [
    "~/projects/personal/**",    // 個人プロジェクトディレクトリへのアクセスを許可
    "~/projects/work/**",        // 作業プロジェクトディレクトリへのアクセスを許可
    "~/dotfiles/**"               // 設定ファイルディレクトリへのアクセスを許可
  ]
}

2、例外ケース

追加ディレクトリを設定した後でも、追加設定なしでアクセスできるもの：

  • .claude/skills/内の Skills（ライブリロード付き）
  • .claude/settings.json内のプラグイン設定（enabledPluginsとextraKnownMarketplaces）
  • CLAUDE.md ファイルおよび.claude/rules/（設定した場合のみCLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1）

自動モード（Auto Mode）

自動モードは Claude Code に導入された新しいメカニズムで、モデル駆動型の分類器が人手による承認を代替し、効率を確保しながらリスクを可能な限り制御します。

1、利用可能な条件

  • Team、Enterprise、API プランのみ
  • Claude Sonnet 4.6 または Claude Opus 4.6 が必要
  • Haiku、claude-3 モデル、またはサードパーティプロバイダーでは利用不可
  • 管理者が Claude Code の管理者設定で有効化する必要があります

2、動作原理

各操作の実行前に、独立した分類器モデルが会話を審査し、その操作がユーザーの要求に一致するかどうかを判断します。

防御の階層：

  1. サーバー側プローブが受信したツール結果をスキャン
  2. 分類器はツール結果を決して参照しないため、インジェクション命令が判断に影響を与えるのを防ぎます

操作の評価順序：

  1. 許可または拒否ルールに一致する操作は即座に解決
  2. 読み取り専用操作と作業ディレクトリ内のファイル編集は自動承認（保護ディレクトリを除く）
  3. その他の内容は分類器に送信
  4. 分類器がブロックした場合、Claude は理由を受け取り、代替方法を試みます

3、分類器のデフォルト動作

操作タイプ 動作
デフォルトでブロック
コードのダウンロードと実行 curl | bash 等
外部エンドポイントへの機密データの送信 データ漏洩リスク
本番環境へのデプロイと移行 本番環境の変更
クラウドストレージでの大規模な削除 データ損失リスク
IAM またはリポジトリ権限の付与 権限昇格リスク
共有インフラストラクチャの変更 他のユーザーへの影響
ファイルを不可逆的に破棄 セッション開始前に存在するファイル
破壊的なソースコード管理操作 フォースプッシュ、main への直接プッシュ
デフォルトで許可
作業ディレクトリ内のローカルファイル操作 安全な範囲内
宣言された依存関係のインストール package.json に既存の依存関係
.env を読み取って認証情報を送信 対応する API に送信
読み取り専用の HTTP リクエスト GET リクエスト
起動時のブランチへのプッシュ 安全なブランチ操作

4、自動モード設定

例

{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ],
    "allow": [
      "Deploying to the staging namespace is allowed",
      "Writing to s3://acme-scratch/ is allowed"
    ],
    "soft_deny": [
      "Never run database migrations outside the migrations CLI",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow"
    ]
  }
}

5、フォールバック機構

分類器が操作を連続 3 回ブロックした場合、または 1 セッションで合計 20 回ブロックした場合、自動モードは一時停止し、Claude Code は操作ごとのプロンプト表示に戻ります。

/permissions  # 在 "最近拒绝" 选项卡查看被拒绝的操作

サンドボックスと権限の関係

サンドボックスと権限は補完的なセキュリティレイヤーであり、連携して動作します：

側面 権限 サンドボックス
制御対象 Claude Code が使用できるツールを制御 Bash コマンドがアクセスできるファイルシステムとネットワークコンテンツを制限
評価のタイミング すべてのツールの実行前に評価 Bash コマンドとそのサブプロセスのみに適用
適用範囲 すべてのツール：Bash、Read、Edit、WebFetch、MCP など Bash コマンドのみ

1、サンドボックスの有効化

/sandbox

コマンドを実行して/sandboxサンドボックスを有効化すると、サンドボックスモードを選択するメニューが開きます。

2、サンドボックスの設定

例

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],    // これらのパスへの書き込みを許可
      "denyWrite": ["~/important/**"],            // 重要なディレクトリへの書き込みをブロック
      "denyRead": ["~/"]                           // ホームディレクトリの読み取りをブロック
    },
    "network": {
      "httpProxyPort": 8080,                       // HTTP プロキシポート
      "socksProxyPort": 8081                       // SOCKS プロキシポート
    }
  }
}

多層防御：権限とサンドボックスは同時に有効化する必要があります。権限の deny ルールは Claude が制限されたリソースへのアクセスを試みるのを防ぎ、サンドボックスの制限は Bash コマンドが定義された境界外のリソースに到達するのを防ぎます。

Hooks を使用した権限の拡張

PreToolUse hooks は権限プロンプトの前に実行され、以下が可能です：

  • ツール呼び出しの拒否
  • プロンプトの強制
  • プロンプトをスキップして呼び出しを続行

例

#!/bin/bash
# PreToolUse hook の例：危険なコマンドをインターセプト
COMMAND=$(cat | jq -r '.tool_input.command // empty')

if echo "$COMMAND" | grep -qE 'rm\s+(-[rf]+\s+)*(\/|~|\.\.\/)'; then
    echo "BLOCKED: rm on sensitive path"
    exit 2  # 終了コード 2 でツール呼び出しをブロック
fi
exit 0  # 続行を許可

重要：プロンプトをスキップしても権限ルールはバイパスされません。Deny ルールと ask ルールは、hook が "allow" を返した後も引き続き評価されます。ブロックする hook が終了コード 2 で終了した場合、権限ルールが評価される前にツール呼び出しが停止されます。

設定の優先順位

Claude Code の設定は以下の優先順位で有効になります（高い順から低い順）：

  1. マネージド設定- 他のどのレベルでも上書き不可（管理者制御）
  2. コマンドライン引数- 一時的なセッションの上書き
  3. ローカルプロジェクト設定 (.claude/settings.local.json)
  4. 共有プロジェクト設定 (.claude/settings.json)
  5. ユーザー設定 (~/.claude/settings.json)

重要なルール：ツールがどのレベルで拒否された場合でも、他のレベルで許可することはできません。

実用的な設定例

例1：保守モード（すべての操作で承認が必要）

Claude Code を初めて使用する場合や、重要なプロジェクトで作業する場合に適しています：

例

{
  "permissions": {
    "defaultMode": "default"
  }
}

例2：開発での一般的な設定（読み取り操作は許可、コマンド実行は承認）

日常の開発に適しています：Claude がコードを自由に読み取り・検索できるようにしつつ、ファイルの変更とコマンドの実行には確認が必要です：

例

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(git status *)",      // git ステータスを確認
      "Bash(git log *)",         // git ログを確認
      "Bash(git diff *)",       // git 差分を確認
      "Bash(npm run *)",         // npm スクリプトを実行
      "Bash(npm test *)",        // テストを実行
      "Bash(ls *)",              // ディレクトリを一覧表示
      "Bash(grep *)"             // コンテンツを検索
    ],
    "deny": [
      "Bash(rm *)",              // ファイルの削除：直接ブロック
      "Bash(git push *)",        // コードのプッシュ：直接ブロック
      "Bash(mkdir / *)",         // システムディレクトリの作成：直接ブロック
      "Edit(*.env)"              // .env ファイルの編集をブロック
    ]
  }
}

例3：ロック環境設定（事前承認済み操作のみ許可）

CIパイプラインや厳格な制御が必要な環境に適しています：

例

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Read(*)",                  // すべてのファイルの読み取りを許可
      "Bash(npm run build *)",    // ビルドコマンドを許可
      "Bash(npm test *)"          // テストの実行を許可
    ],
    "deny": [
      "Edit(*)",                  // すべてのファイル編集を禁止
      "Bash(git *)",              // すべてのgit操作を禁止
      "Bash(curl *)",             // ネットワークリクエストを禁止
      "Bash(ssh *)"               // SSH接続を禁止
    ]
  }
}

例4：複数プロジェクトへのアクセスを許可

Claudeが複数のプロジェクトディレクトリにまたがって作業する必要がある場合：

例

{
  "permissions": {
    "allow": [
      "Edit(/src/**)",            // srcディレクトリの編集を許可
      "Edit(/docs/**)"            // ドキュメントディレクトリの編集を許可
    ],
    "deny": [
      "Edit(/docs/**/*.md)"       // ドキュメントファイルの編集を禁止（読み取り専用）
    ]
  },
  "additionalDirectories": [
    "~/projects/personal/**",     // 個人プロジェクトへのアクセスを許可
    "~/projects/work/**",         // 業務プロジェクトへのアクセスを許可
    "~/dotfiles/**"               // 設定ファイルへのアクセスを許可
  ]
}

例5：サンドボックスを使用して Bash 操作を制限

サンドボックスを有効にすると、OSレベルの追加保護が提供されます：

例

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["/tmp/build", "~/projects/myapp/**"],
      "denyRead": ["~/secrets/**"]
    },
    "network": {
      "httpProxyPort": 8080
    }
  },
  "permissions": {
    "allow": [
      "Bash(*)",                  // サンドボックス内で全てのコマンドを許可
      "WebFetch(domain:api.github.com)"
    ],
    "deny": [
      "WebFetch(domain:untrusted.com)"
    ]
  }
}

マネージド設定（管理者設定）

管理者は、ユーザーやプロジェクト設定で上書きできない管理設定を展開できます。

設定 説明
allowManagedHooksOnly ユーザー、プロジェクト、プラグインのフックの読み込みを防止
allowManagedMcpServersOnly 管理設定のMCPサーバーのみを尊重
allowManagedPermissionRulesOnly ユーザーおよびプロジェクト設定が権限ルールを定義するのを防止
sandbox.filesystem.allowManagedReadPathsOnly 管理設定の読み取りパスのみを尊重
sandbox.network.allowManagedDomainsOnly 管理設定の許可ドメインのみを尊重
permissions.disableBypassPermissionsMode "disable"に設定するとbypassPermissionsモードの使用を防止
permissions.disableAutoMode "disable"に設定すると自動モードの使用を防止

セキュリティのベストプラクティス

  1. 制限的な設定から始める：最小権限から始め、必要に応じて拡張する
  2. サンドボックスを使用：サンドボックスはOSレベルの追加保護を提供し、同時に有効にする必要があります
  3. 機密ファイルを保護：ルールを使用してdenyアクセスをブロック.env、キーファイルなど
  4. ネットワークアクセスを制限：必要なドメインのみにアクセスを許可し、データ漏洩を防止
  5. bypassPermissionsを回避：隔離環境（コンテナ、VM）でのみ使用
  6. autoモードのsoft_denyを使用：過度に制限せずにセキュリティガイダンスを提供
  7. 設定を定期的にレビュー：サンドボックス違反の試行と拒否された操作を確認

セキュリティ警告：bypassPermissionsこのモードは、プロンプトインジェクションや予期しない操作に対する保護を提供しません。バックグラウンドのセキュリティチェックを引き続き維持する、より安全な代替手段としては、autoモードを使用する必要があります。

その他の拡張機能