Claude Code 権限設定完全ガイド|settings.json・Hooks・allowlist を徹底解説

Claude Code は非常に強力なファイル操作・コマンド実行能力を持っています。その力を安全に制御するのが 権限設定 (permissions) です。「なんとなく使っている」状態から脱して、意図通りに動く Claude Code を設計しましょう。

この記事では、.claude/settings.json の全設定項目、Hooks の実装パターン、環境別の権限設計まで、動くコードで徹底解説します。

権限設定の全体像

Claude Code の権限は 3レベル で制御します。

レベル	キー	動作
許可	allow	確認ダイアログなしで自動実行
確認	ask	毎回ユーザーの承認を要求
拒否	deny	一切実行できない (エラーで弾く)

設定は公式には settings.json で管理します。ユーザー全体なら ~/.claude/settings.json、プロジェクト共有なら .claude/settings.json、個人上書きなら .claude/settings.local.json に置きます。MCP など一部の状態は ~/.claude.json に残りますが、権限ルールの基本は settings.json 側です。

優先順位 (高い順):
Managed settings
    > コマンドライン引数
        > Local .claude/settings.local.json
            > Project .claude/settings.json
                > User ~/.claude/settings.json

permission rules はスコープをまたいでマージされ、deny -> ask -> allow の順で評価される

settings.json の基本構造

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)"
    ]
  },
  "hooks": {
    "PreToolUse": [],
    "PostToolUse": []
  }
}

ツール名とパターン構文

権限設定に書くのは 「ツール名(引数パターン)」 の形式です。

主要ツール一覧

ツール名	内容
Read	ファイル読み取り
Write	ファイル新規作成
Edit	既存ファイルの部分変更
Bash	シェルコマンド実行
Glob	ファイルパターン検索
Grep	内容検索
WebFetch	URL 取得
Agent	サブエージェント起動

パターン構文

"Read(**)"          // 全ファイルの読み取りを許可
"Read(src/**)"      // src/ 以下のみ許可
"Read(*.md)"        // .md ファイルのみ許可
"Bash(npm run *)"   // npm run ではじまるコマンドのみ許可
"Bash(git *)"       // git コマンド全般を許可
"Bash(rm -rf *)"    // rm -rf を拒否

** はディレクトリを含む全パスに、* は単一セグメントにマッチします。

実践パターン集

パターン1: 個人開発 (比較的自由)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm *)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git add*)",
      "Bash(node *)",
      "Bash(echo *)",
      "Bash(cat *)",
      "Bash(ls *)"
    ],
    "deny": [
      "Bash(rm -rf /)",
      "Bash(rm -rf ~*)",
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(rm *)"
    ]
  }
}

パターン2: チーム開発 (セキュリティ重視)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm run lint)",
      "Bash(npm run test)",
      "Bash(npm run typecheck)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git branch*)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(git push -f*)",
      "Bash(git reset --hard*)",
      "Bash(git rebase *main*)",
      "Bash(git rebase *master*)",
      "Bash(DROP *)",
      "Bash(TRUNCATE *)",
      "Bash(curl * | bash)",
      "Bash(wget * | sh)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(git add*)",
      "Bash(npm install*)",
      "Bash(*deploy*)"
    ]
  }
}

パターン3: 本番環境 (読み取り専用)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git show*)",
      "Bash(cat *)",
      "Bash(ls *)",
      "Bash(ps *)",
      "Bash(df *)",
      "Bash(top *)"
    ],
    "deny": [
      "Write(**)",
      "Edit(**)",
      "Bash(git push*)",
      "Bash(git commit*)",
      "Bash(git reset*)",
      "Bash(rm *)",
      "Bash(mv *)",
      "Bash(*deploy*)",
      "Bash(*restart*)",
      "Bash(*kill *)"
    ],
    "ask": []
  }
}

本番用の作業ツリーや本番に近いリポジトリでは、この設定を .claude/settings.json として置き、claude --permission-mode plan か事前承認済みの dontAsk で開始します。別ファイルを環境変数で差し替える運用に寄せるより、公式の scope と permission mode に寄せたほうがレビューしやすくなります。

パターン4: コンテンツ生成専用 (このサイトで使っているパターン)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Write(site/src/content/**)",
      "Write(content/**)",
      "Edit(site/src/content/**)",
      "Edit(content/**)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(node scripts/*)",
      "Bash(QIITA_TOKEN=* node scripts/qiita-publish.mjs)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Edit(.env*)",
      "Read(.env*)"
    ],
    "ask": [
      "Bash(git add*)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(bash scripts/deploy.sh*)"
    ]
  }
}

Write(site/src/content/**) のように 書き込みを特定ディレクトリに制限 するのがポイントです。

Hooks: 権限の前後に処理を挟む

Hooks はツール実行の 前後に自動でコマンドを実行 する仕組みです。セキュリティチェックや自動整形に使えます。

PreToolUse: 実行前フック

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo '🚨 .env の追加を検出！' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(git commit*)",
        "hooks": [{
          "type": "command",
          "command": "node scripts/secret-scan.mjs"
        }]
      },
      {
        "matcher": "Bash(rm*)",
        "hooks": [{
          "type": "command",
          "command": "echo '⚠️ 削除コマンドを検出。5秒後に実行します。Ctrl+C で中止。' && sleep 5"
        }]
      }
    ]
  }
}

フックコマンドが exit code 1 を返すとツールの実行がブロック されます。これが最も重要なポイントです。

PostToolUse: 実行後フック

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npx tsc --noEmit 2>&1 | head -20 || true"
        }]
      },
      {
        "matcher": "Bash(git commit*)",
        "hooks": [{
          "type": "command",
          "command": "git log --oneline -3"
        }]
      }
    ]
  }
}

PostToolUse は 実行後の確認や副作用 に使います。ファイル編集後に自動で型チェック、コミット後に最新3件のログを表示するなど。

実用的な Hooks レシピ集

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(npm install*)",
        "hooks": [{
          "type": "command",
          "command": "echo '📦 パッケージを追加します。package.json を確認してください。'"
        }]
      },
      {
        "matcher": "Bash(*deploy*)",
        "hooks": [{
          "type": "command",
          "command": "read -p '🚀 デプロイを実行します。続けますか？ [y/N] ' ans && [ \"$ans\" = 'y' ] || exit 1"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write(*.ts)|Edit(*.ts)",
        "hooks": [{
          "type": "command",
          "command": "npx eslint --fix $CLAUDE_TOOL_INPUT_FILE_PATH 2>/dev/null || true"
        }]
      }
    ]
  }
}

Permission Modes: 起動時の権限レベル

claude コマンドの起動時にモードを指定することもできます。

# 通常モード (settings.json に従う)
claude

# 全ての操作を自動承認 (危険！ 信頼できる環境のみ)
claude --dangerously-skip-permissions

# 特定の操作のみスキップ
claude --allowedTools "Read,Grep,Glob"

# 非対話モード (CI/CD で使用)
claude -p "テストを実行して結果を報告して" --dangerously-skip-permissions

--dangerously-skip-permissions は CI/CD の自動実行 や完全に把握した自動化スクリプトでのみ使用し、日常的な対話では避けるべきです。

2026年版: 最初の permission budget と運用レビュー

ここでいう permission budget は公式の機能名ではなく、「最初の1週間に自動実行を許す範囲」を決める実務上の枠です。2026年6月1日時点の公式Docsでは、permission rules は deny -> ask -> allow の順に評価され、PreToolUse hooks は追加判定を挟めますが、deny と ask を hooks の allow で上書きすることはできません。つまり最初は、作業速度よりも「間違えても戻せる範囲」を優先します。

最初の安全な budget は次の程度で十分です。allow は Read、Glob、Grep、git status、git diff、git log、npm run lint、npm run test などの読み取りと検証だけ。ask は Edit、Write、git add、git commit、git push、npm install、deploy 系。deny は .env、secrets/**、rm -rf、git reset --hard、git push --force、curl | bash、wget | sh、本番DBに触るコマンドです。bypassPermissions はコンテナ、VM、devcontainer など壊れてよい隔離環境以外では使いません。

チームでは、PRで .claude/settings.json をレビュー対象にします。見る観点は単純です。allow に入れるのは何度実行されても安全な検証コマンドだけか、ask に破壊的ではないが人間の意図確認が必要な操作が入っているか、deny に秘密情報・強制 push・削除・本番操作が入っているか。管理者がいる組織なら server-managed settings で disableBypassPermissionsMode と disableAutoMode を "disable" にし、allowManagedPermissionRulesOnly で個人やプロジェクト側の権限ルール追加を止める選択肢もあります。

危険な失敗例は、Bash(git *) や Bash(node *) を広く allow して、.env の Read deny だけで安心してしまうケースです。公式Docsでも、Read/Edit の deny は Claude Code が認識する組み込みファイル操作や一部の Bash 読み取りには効きますが、任意の Node/Python スクリプトがファイルを開く動きまではOSレベルで止めません。秘密情報を本当に守るなら、広すぎる Bash allow を避け、sandbox、OS権限、PreToolUse hook の組み合わせで守ります。

復旧手順も決めておきます。意図しない編集が入ったら、まず /permissions で有効なルールと出所を確認し、git diff で変更を見ます。戻すときは git restore -p のように差分単位で戻し、未追跡ファイルは git clean -n で確認してから削除します。秘密情報を読ませた可能性がある場合は、権限設定を直すだけでなくトークンのローテーションまで行います。

この記事を読んで自分のリポジトリに落とすなら、まず permission budget loop と permission audit checklist で棚卸ししてください。コピペできる教材で早く固めたい場合は Claude Code 教材一覧 を、チーム導入や権限レビューを一緒に設計したい場合は 導入相談 を使うと、記事の知識をそのまま運用ルールにできます。

設定ファイルの優先順位と上書き

複数の設定ファイルが存在する場合:

~/.claude/settings.json     ← User (全プロジェクト共通)
.claude/settings.json       ← Project (git管理)
.claude/settings.local.json ← Local (個人上書き、gitignore)
managed-settings.json       ← Managed (組織ポリシー、最優先)

permission rules はマージされ、deny が常に allow より先に評価される

個人用の追加設定は .claude/settings.local.json に書いて gitignore します。チームの deny リストを個人設定で上書きできないよう、deny は settings.json のみに書く のが安全な設計です。

# .gitignore に追加
.claude/settings.local.json

落とし穴5選

1. パターンのワイルドカードを間違える

// ❌ これは "git" という単一コマンドにしかマッチしない
"Bash(git)"

// ✅ git 以降の引数も含めてマッチ
"Bash(git *)"
"Bash(git*)"  // スペースなしでも動くが * で明示するほうが安全

2. deny が ask より優先されることを忘れる

// この設定で Bash(rm -rf /tmp/test) は deny に引っかかってブロックされる
// ask には到達しない
{
  "deny": ["Bash(rm -rf*)"],
  "ask": ["Bash(rm*)"]  // ← rm -rf は deny 側で処理される
}

3. Hooks の exit code を意識していない

# PreToolUse フックのコマンドが常に exit 0 を返すと
# スキャンが失敗してもブロックできない

# ❌ エラーでも通ってしまう
"command": "node scan.mjs"

# ✅ 明示的に exit code を制御
"command": "node scan.mjs || exit 1"

4. settings.json を gitignore してしまう

チームで共有するために git 管理したい settings.json を誤って .gitignore に入れてしまうケースがあります。プロジェクト設定は git 管理、個人設定の settings.local.json のみ gitignore が正解です。

5. 本番環境設定を手動で切り替えるのを忘れる

# ❌ 普段使いの設定のまま本番作業してしまう

# ✅ 本番作業前は plan か dontAsk で開始し、作業ツリー側の .claude/settings.json を本番用にする
claude --permission-mode plan

エイリアスを登録しておくと忘れにくい:

# ~/.bashrc or ~/.zshrc
alias claude-prod='claude --permission-mode plan'

設定のデバッグ方法

「なぜこのコマンドがブロックされるのか」がわかりにくい場合:

# 現在の設定を確認
claude --print-settings 2>/dev/null || cat .claude/settings.json

# どのルールにマッチしているか確認 (verbose モード)
claude --verbose -p "git push を実行して"

まとめ: 設定設計のベストプラクティス

1. まず deny から決める
   → 絶対に実行させたくないコマンドを列挙
   → rm -rf, git push --force, DROP TABLE は必須

2. 次に ask を設定
   → 本人確認が必要な「書き込み系・デプロイ系」

3. 残りを allow
   → 読み取り系・CI系は全部 allow で効率化

4. Hooks でセキュリティ自動化
   → コミット前スキャン、型チェック後自動実行

5. 環境別設定ファイルを用意
   → settings.json (開発), settings.production.json (本番)

権限設定を適切に入れると、「承認ボタンを機械的に押す」習慣がなくなり、本当に確認が必要な操作だけに集中できるようになります。最初の30分で設計しておけば、その後の数百時間の作業が安全になります。

関連記事

• Claude Code セキュリティ対策完全ガイド
• Claude Code セキュリティ失敗事例7選
• CLAUDE.md ベストプラクティス

参考資料

• Claude Code settings 公式ドキュメント
• Claude Code permissions 公式ドキュメント
• Claude Code server-managed settings 公式ドキュメント
• Claude Code hooks 公式ドキュメント