Claude Code の settings.json で権限管理してみてわかったこと【2026年実体験】

Claude Code を使っていて、「このコマンドを実行していいですか？」によくわからず Yes 連打してる方、今すぐ Claude にこう聞いてみてください。

私の .claude/settings.json を見直して

自分もそうやってたら、気づいたら MySQL の DB パスワードが平文で入っていた。Cドライブ全体が読み取り対象になっていたりもした。

settings.json は「触らなくていいファイル」じゃなくて、ちゃんと設計が必要だと気づいた。この記事では、どこに何を書けばいいか、allow と deny をどう使い分けるか、整理してわかったことをまとめます。

Kana

パスワードそのまま入ってたの…

settings.json って何をするファイル？

Claude Code の動作と権限を設定するファイルです。

「このコマンドは毎回確認しなくていい」「このファイルは絶対読ませない」といった設定を書いておくと、作業中の確認プロンプトが減って快適になります。

主に設定できるのはこのあたりです。

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

設定ファイルは3か所に置けます。

優先度（高い順）
1. .claude/settings.local.json    プロジェクト内・自分専用（自動 gitignore）
2. .claude/settings.json          プロジェクト内・チーム共有（Git 管理対象）
3. ~/.claude/settings.json        全プロジェクト共通・ユーザー設定

settings.local.json の落とし穴

直感に反しますが、settings.local.json は settings.json より優先度が高いです。

チームで .claude/settings.json を共有していても、個人の settings.local.json が上書きします。「設定が効いていない」と思ったら、ローカルファイルが干渉しているかもしれません。settings.local.json は Claude Code が自動で .gitignore に追記してくれるので、誤って commit することはないです。

permissions の評価順序

ルールは deny → ask → allow の順に評価されます。最初にマッチしたルールが勝つので、deny が書いてあれば allow があっても拒否されます。

Lyze

どのスコープで allow しても、deny が1つでもあれば拒否されます。ユーザー設定の deny がプロジェクト設定の allow を上書きし、逆も然りです。

現在の設定を確認するコマンド

設定がどう読み込まれているか確認するには、Claude Code のチャット内でこのコマンドを使います。

「自分の設定がどうなっているかわからない」と思ったらまず /status を叩くのがおすすめです。

自分用 settings.json を作る

必要な設定にチェックを入れると、そのまま使える JSON が生成されます。

まず入れておきたい設定（コピペ用テンプレート）

ユーザー設定（~/.claude/settings.json）の最小セットです。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git commit *)",
      "Bash(git pull *)",
      "Bash(git fetch *)",
      "Bash(npm run *)",
      "WebSearch",
      "WebFetch"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(git reset --hard *)",
      "Bash(rm *)"
    ],
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ]
  },
  "language": "japanese",
  "effortLevel": "high"
}

各設定の意味と防げること

allow（確認なしで通す）

ask（毎回確認する）

deny（絶対に通さない）

その他

$schema を書いておくと VS Code や Cursor でオートコンプリートが効くようになります。地味に便利です。

language: "japanese" で Claude の返答が日本語になります。デフォルトは英語なので入れておくと快適です。

allow / deny / ask の書き方

ツール名は大文字始まり（Bash、Read、Edit、WebFetch など）。Bash は括弧内にコマンドパターンを書きます。

"Bash(git status)"              完全一致
"Bash(npm run *)"               * はスペース以降の任意の文字列
"Bash(git *)"                   git に続く全コマンド
"Read(./.env)"                  特定ファイル
"Read(**/.env)"                 任意の深さの .env ファイル
"WebFetch(domain:github.com)"   ドメイン指定
"WebFetch"                      全ドメイン許可

複合コマンドの注意点

&& や || で繋がれた複合コマンドは、各サブコマンドが独立して評価されます。

"Bash(safe-cmd *)" を allow していても、safe-cmd && rm -rf . は通りません。各コマンドがそれぞれ評価されるので、rm -rf . の部分で ask または deny が判定されます。

Windows のパス表記

Windows ではパスが内部で POSIX 形式に変換されます。

C:\kanalyzelab\  →  //c/kanalyzelab/
C:\Users\alice\  →  //c/Users/alice/

パスを deny / allow に書くときは //c/ 形式が正確です。

実際に気づいたこと：見落としていた3つ

自分の設定を見直してみて、気になる点が3つありました。

① Cドライブ全体が読み取り対象になっていた

additionalDirectories に "C:\\" が入っていました。Claude Code が Cドライブ全体にアクセスできる状態です。

目的は別フォルダへのアクセスを許可することだったんですが、気づかずにCドライブ全体を開放していた。"Read(//c/Users/username/**)" も同様で、ユーザーホーム以下の全ファイルが読み取れる状態でした。

→ additionalDirectories は必要なフォルダだけ明記するようにしました。

② DBパスワードが平文で入っていた

過去に SSH + MySQL でサーバーの設定を確認するコマンドを実行したとき、毎回の確認プロンプトに OK を押し続けていたら、コマンドごと allow に残っていた。

そのコマンドにパスワードが埋め込まれていたので、Git 管理のファイルにそのまま残ることに。ヒヤっとしました。

→ パスワードが入ったコマンドは allow に書かない。都度確認を受け入れるか、スクリプト化して環境変数経由にするのが正解です。

③ deny と allow の優先関係を勘違いしていた

「deny: Edit(C:/**) でCドライブ全体を拒否しつつ、allow: Edit(c:/kanalyzelab/**) でプロジェクトだけ許可できる」と思っていたんですが、できません。

公式ドキュメントに明記されていました。

“Rules are evaluated in order: deny → ask → allow. The first matching rule wins, so deny rules always take precedence.”

deny が先にマッチした時点で終了なので、allow は評価されません。

正しいやり方は「外のパスだけ deny に列挙」です。プロジェクトパスは deny に書かないことで、defaultMode: acceptEdits が効くようになります。

"deny": [
  "Edit(//c/OtherFolder/**)",
  "Edit(//c/Users/**)"
]
// c:\kanalyzelab は書かない → deny にひっかからない → 自動許可

プロジェクト設定と個人設定の使い分け

実際の使い分けイメージはこんな感じです。

~/.claude/settings.json
  → git コマンド・npm・基本の deny セット
  → どのプロジェクトでも共通の設定

.claude/settings.json
  → プロジェクト固有の Bash コマンド
  → defaultMode や外部ディレクトリの設定

.claude/settings.local.json
  → 試したいコマンドを一時的に allow したいとき
  → チームには影響させたくない個人設定

settings.local.json は settings.json より優先度が高いので、チームの設定を個人だけ上書きしたいときにも使えます。

公式ドキュメント

詳細は公式を参照してください。

• Settings — Claude Code 公式
• Configure permissions — Claude Code 公式

まとめ

• deny → ask → allow の順に評価。deny が最優先でスコープをまたいでも覆せない
• deny(C:/**) + allow(c:/project/**) は効かない。外のパスだけ deny に列挙するのが正解
• additionalDirectories は必要なフォルダだけに絞る
• パスワードや秘密情報が入ったコマンドは allow に書かない
• settings.local.json は settings.json より優先される（直感に反しやすい）
• $schema を書くとエディターで補完が効く

よくある質問

Q: 今の設定がどうなっているか確認する方法は？ Claude Code のチャットで /status を入力すると、読み込まれている設定ファイルの一覧が表示されます。/permissions で現在の allow / deny ルールも確認できます。

Q: .env ファイルを Claude Code に読ませないようにするには？ deny に "Read(./.env)" と "Read(./.env.*)" を追加します。これだけでプロジェクト内の .env ファイルへの Read が完全に拒否されます。

設定ファイルは一度作ったら終わりじゃなくて、使いながら育てるのが現実的だと思います。気になる人は X で感想聞かせてください。

KanalyzeLab — データ×AIで好きをカタチに