Claude Codeの権限設定｜settings.jsonの安全な書き方

Claude Codeにテストを任せたいだけなのに、コマンドごとに確認画面が出る。逆に Bash を丸ごと許可すると、削除や強制pushまで確認なしで動く可能性があります。

この問題は二択ではありません。読み取りとテストは自動許可、編集は確認、秘密情報と危険操作は拒否。この3段階を settings.json に書きます。

この記事の要点

• 評価順は deny → ask → allow。拒否、確認、自動許可の順です。
• プロジェクト内の読み取りは標準で確認不要です。信頼済みのテストだけをallow、編集・外部通信・pushをask、秘密情報と破壊操作をdenyにします。
• Bash(git *) は広すぎます。git reset --hard や git push --force まで含むため、コマンド単位で絞ります。
• Read(.env) だけでは子プロセスを完全に止められません。強い隔離にはsandboxも使います。
• 設定後は /permissions と /status で、どのファイルのルールが有効か確認します。

Claude Codeに任せる範囲と、人が判断する範囲

Claude Codeに任せる	人が確認する	常に止める
ファイル検索、差分確認、テスト	ファイル編集、commit、push、依存追加	秘密情報の読み取り、強制push、hard reset、大量削除
Read、Grep、git diff	Edit、git commit、npm install	.env、git push --force、git reset --hard、rm -rf

戻せない操作、外部送信、認証情報へのアクセスは、人の確認か拒否に寄せます。

まず貼るsettings.json

プロジェクト直下に .claude/settings.json を作り、次の内容から始めます。チームで共有する安全側の設定です。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run lint *)"
    ],
    "ask": [
      "Edit",
      "WebFetch",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git push *)",
      "Bash(git clean *)",
      "Bash(git restore *)",
      "Bash(npm install *)",
      "Bash(npm uninstall *)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/secrets/**)",
      "Edit(.env)",
      "Edit(.env.*)",
      "Edit(**/secrets/**)",
      "Bash(git push --force *)",
      "Bash(git reset --hard *)",
      "Bash(rm -rf *)",
      "Bash(rm *)",
      "PowerShell(Remove-Item *)"
    ]
  }
}

この例は、package.json のscriptsを確認済みのリポジトリ向けです。初見のリポジトリでは allow を空にし、テストコマンドの中身を読んでから追加してください。Bash(npm test *) は npm test と引数付きの形に一致します。

settings.jsonを置く場所

種類	場所	用途
User	~/.claude/settings.json	自分の全プロジェクトに共通する設定
Project	.claude/settings.json	Gitで共有するチーム標準
Local	.claude/settings.local.json	このPCだけの個人設定。Gitには入れない
Managed	管理者が配布する設定	組織で上書き不能にするルール

優先順位はManaged、コマンドライン、Local、Project、Userの順です。ただし permissions.allow などの配列は複数scopeから連結されます。上位設定で同じキーを書けば下位の配列が丸ごと消える、という意味ではありません。denyはどこにあってもallowより先に評価されます。共通denyはProject、変更させたくない組織ルールはManagedへ置きます。

allow・ask・denyの読み方

ルール	意味
Read	組み込みの読み取り操作すべてに一致。プロジェクト内は標準で読めるため、裸のallowは通常不要
Bash(npm test)	npm testだけに完全一致
Bash(npm test *)	npm testと、その後ろに引数がある形に一致
Bash(ls*)	ls -laだけでなくlsofにも一致するため広い
Read(//Users/me/secrets/**)	ファイルシステムの絶対パスに一致
Edit(/src/**/*.ts)	このProject設定なら、プロジェクトのsrc以下に一致
WebFetch(domain:docs.anthropic.com)	指定ドメインへのWebFetchに一致

Bash(git *) は git push origin main や git reset --hard も対象です。安全なコマンドは個別指定します。

ReadとEditだけで秘密情報を守り切れない理由

ReadとEditのパスはgitignore形式です。

書き方	基準	例
//path	ファイルシステムのルート	Read(//Users/me/secrets/**)
~/path	ホームディレクトリ	Read(~/.ssh/**)
/path	設定ファイルの基準位置	Project設定なら Edit(/src/**)
pathまたは./path	現在の作業ディレクトリ	Read(.env)

先頭スラッシュ1個は絶対パスではありません。Read(.env) は組み込みツールと認識されるファイルコマンドに適用されますが、Node.jsなどの間接アクセスは別です。

認証情報を扱うならsandbox設定も使い、OS側で制限します。sandboxはmacOS、Linux、WSL2で利用でき、ネイティブWindowsでは動きません。Windows利用者はWSL2か隔離コンテナを使い、PowerShell側のdenyも残します。

3つのUse case

Use case 1: 個人開発でテストだけ自動化する

入力: ソース、テスト、Git差分。出力: 修正案とテスト結果。人の確認: 編集、依存追加、commit、push。

最小設定を使い、編集はaskに残します。繰り返し使う安全な操作だけを後からallowへ移します。

Use case 2: チームで危険操作を共通拒否する

入力: 許可コマンドと禁止操作。出力: Git管理された設定。人の確認: deny追加と例外作業。

Project設定へ .env、強制push、hard resetのdenyを書きます。変更させたくない組織ルールはManaged設定へ移します。

Use case 3: 本番リポジトリを調査だけさせる

入力: 障害ログとGit履歴。出力: 原因候補と修正計画。人の確認: 編集、デプロイ、外部送信。

起動時にPlan Modeを選びます。

claude --permission-mode plan

書き込みが必要になったら、作業用ブランチか隔離環境へ移してから承認します。

具体的な失敗例と直し方

失敗	なぜ起きるか	直し方
Bash(git *) をallowに入れる	git pushやgit reset --hardまで同じ範囲に入る	副作用を確認したコマンドだけを個別にallowにする
deny: Bash(aws *) に allow: Bash(aws s3 ls) を足す	deny → ask → allowの順なので、狭いallowでも例外にできない	denyを狭めるか、安全な操作を別のコマンド境界に分ける
Read(.env) だけでNode.jsも止まると思う	Read/Editルールは内蔵ツールと認識済みファイルコマンド向け	sandboxの denyRead やcredentials設定を併用する
Localでallowを消したのに動く	配列ルールはscope間で連結され、UserやProjectのallowが残る	/permissions でルール元、/status で読み込んだscopeを確認する

実際の事故パターンはClaude Codeのセキュリティ失敗事例、導入全体の点検はセキュリティ・ベストプラクティスに分けて解説しています。

permission modeの選び方

モード	向いている場面	注意点
default	初めてのリポジトリ	必要な操作で確認が出る
acceptEdits	変更範囲を理解した開発作業	編集と一般的なファイル操作が自動承認される
plan	調査、設計、本番障害の読み取り	ソースを変更しない
auto	背景の安全判定を使う作業	依頼との整合性を分類器が判定するため、明示denyを併用する
dontAsk	事前許可した操作だけを無人実行	未許可操作は確認せず拒否される
bypassPermissions	破棄できるコンテナやVM	通常のPCや本番環境では使わない

sandboxの autoAllowBashIfSandboxed は標準で true です。sandbox内では裸の Bash askが省略される場合がありますが、Bash(git push *) のような内容付きask、明示deny、Plan Modeの制限は残ります。

Pitfall: 広いallowをフックだけで補う

Bash を丸ごとallowし、危険操作だけPreToolUseフックで止めると、配置ミスや判定漏れが唯一の境界を崩します。

原因: 許可範囲が広く、フック1本が唯一の境界になっている。

修正方法: denyと狭いallowを先に書き、フックは動的判定の追加層にします。denyとaskはフックのallow結果より優先されます。

動く確認コード

次のスクリプトは .claude/settings.json がJSONとして読めるか、最低限の危険操作がdenyに入っているかを確認します。

// scripts/check-claude-permissions.mjs
import { readFileSync } from "node:fs";

const path = ".claude/settings.json";
const settings = JSON.parse(readFileSync(path, "utf8"));
const deny = new Set(settings.permissions?.deny ?? []);
const required = [
  "Read(.env)",
  "Edit(.env)",
  "Bash(git push --force *)",
  "Bash(git reset --hard *)",
  "Bash(rm *)",
  "PowerShell(Remove-Item *)",
];

const missing = required.filter((rule) => !deny.has(rule));
if (missing.length > 0) {
  console.error(`不足しているdeny: ${missing.join(", ")}`);
  process.exit(1);
}

console.log("権限設定の最低限チェック: OK");

node scripts/check-claude-permissions.mjs

これは安全性の証明ではなく、最低限のdenyが消えたことをCIで検知するチェックです。

設定が効かないときの確認順

1. /permissions でルールと出典ファイルを確認する。
2. /status で読み込まれた設定階層を確認する。
3. 空白・パスのアンカー・sandboxの自動許可を見直す。

よくある質問

Q. Bash(git *) をallowしても大丈夫ですか？

A. 強制pushやhard resetも対象になるため、必要なGitコマンドを個別に許可します。

Q. .env をdenyすれば秘密情報は守れますか？

A. 子プロセスには別の制限が必要です。認証情報を扱う環境ではsandboxも使います。

まとめ

最初に .claude/settings.json へ最小設定を貼り、/permissions で確認します。

プロジェクト内の読み取りは標準動作に任せ、確認済みのテストだけをallow、編集と外部操作はask、秘密情報と破壊操作はdenyにします。

この設定を自分のリポジトリ向けに調整する人は、Claude Code教材一覧の権限テンプレートと導入チェックリストを主導線にしてください。

参考資料

• Configure permissions（Claude Code公式）
• Claude Code settings（Claude Code公式）
• Choose a permission mode（Claude Code公式）
• Configure the sandboxed Bash tool（Claude Code公式）
• Debug your configuration（Claude Code公式）
• Security（Claude Code公式）
• Hooks reference（Claude Code公式）

実際に試した結果

2026年7月22日、掲載したJSONを10言語すべてで JSON.parse し、Node.jsチェックを一時プロジェクトで実行しました。6個の必須denyが揃う設定は終了コード0、git reset --hard のdenyを削除した設定は終了コード1になりました。これは安全性を証明するテストではありません。まず自分の環境で /permissions と /status を開き、ルール元を確認してください。