Claude Code settings.json と権限設定の書き方

この記事で分かること
1. 設定ファイルはどこにあるか
2. 許可・確認・禁止の3つに振り分ける
3. 確認を減らすほうが、安全になる
4. 外に出す経路を分けて考える
5. サンドボックス
6. CLAUDE.md
7. まとめて見る
8. 入れる順番
9. 設定したあとの確認
まとめ

Claude Code を使っていると、たいていどちらかの不満にぶつかります。

確認が多すぎる。 ファイルを1つ書き換えるたびに「実行してよいですか」と聞かれて、Enter を押し続けることになる。

あるいは、その逆。 自動で進むようにしたら、気づかないうちにあちこち書き換わっていて、怖くなった。

どちらも、設定で調整できます。この回では、何を許して、何を確認して、何を止めるかを自分で決める方法を扱います。

先に結論を書いておきます。

確認は、多いほど安全ではありません。 多いと読まなくなります
減らすかわりに、危ないことは、そもそもできないようにします
そのための道具が、権限の設定とサンドボックスです

この記事で分かること

設定ファイルの置き場所
許可・確認・禁止の振り分け方
確認を減らして、かつ安全にする考え方
サンドボックスの使い方
CLAUDE.md の書き方
実際に運用している設定の例

1. 設定ファイルはどこにあるか

設定は settings.json というファイルに書きます。置き場所が2種類あります。

置き場所	効く範囲
`~/.claude/settings.json`	すべてのプロジェクト
プロジェクト内の `.claude/settings.json`	そのプロジェクトだけ

共通のルールはユーザー側、プロジェクト固有のものはプロジェクト側、という使い分けです。

ファイルがなければ、自分で作ります。

mkdir -p ~/.claude
touch ~/.claude/settings.json

中身は JSON です。まずは、いちばん外側の形だけ書いておきます。

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [],
    "ask": [],
    "deny": []
  }
}

なお、設定はコマンドからも触れます。

/permissions

2. 許可・確認・禁止の3つに振り分ける

権限の設定は、操作を3つのカゴに振り分ける作業です。

allow（許可）。 確認なしで実行してよいもの。

ask（確認）。 実行前に必ず聞いてほしいもの。

deny（禁止）。 絶対に実行させないもの。

2-1. allow は「読む・探す・試す」

確認を出しても意味がないものを入れます。

{
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(ls:*)",
      "Bash(cat:*)",
      "Bash(grep:*)",
      "Bash(find:*)",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(git log:*)"
    ]
  }
}

ファイルを読む、探す、差分を見る。これらに毎回確認を出しても、内容を見ずに Enter を押すだけになります。

Bash(ls:*) の * は、「ls で始まるコマンドなら何でも」という意味です。

2-2. ask は、取り消せないものだけ

ここを絞るのが、この記事でいちばん伝えたいところです。

{
  "permissions": {
    "ask": [
      "Bash(git push --tags:*)",
      "Bash(npm publish:*)"
    ]
  }
}

外に出て、取り消せないものだけを入れます。公開する、配信する、送信する。この種の操作です。

数を絞ると、確認が出たこと自体が信号になります。 「あれ、いま何か出た」と思って、手が止まる。これが狙いです。

2-3. deny は、戻せないもの

{
  "permissions": {
    "deny": [
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(~/.ssh/**)",
      "Read(**/*.pem)",
      "Bash(rm -rf /)",
      "Bash(rm -rf ~)",
      "Bash(git clean:*)",
      "Bash(git reset --hard:*)",
      "Bash(git push --force:*)",
      "Bash(sudo:*)"
    ]
  }
}

分けて考えると、こうなります。

読ませたくないもの。 .env、SSH の鍵、証明書。うっかり読み込まれて、会話の記録に残るのを防ぎます。

戻せない操作。 git clean は追跡していないファイルを消します。git reset --hard は変更を消します。git push --force はリモートの履歴を消します。

git commit や git push（force なし）は、禁止しないでください。 ここを止めると、日常の作業が回らなくなります。止めるのは、戻せないものだけです。

3. 確認を減らすほうが、安全になる

3-1. defaultMode で既定の動きを決める

{
  "permissions": {
    "defaultMode": "auto"
  }
}

auto にすると、いちいち確認せずに進むようになります。

ここで、多くの方が身構えると思います。 危ないのではないか、と。

3-2. 減らすかわりに、閉じる

確認を減らすのが安全なのは、減らすかわりに、危ないことをできなくしている場合だけです。

つまり、こういう順番になります。

危ない操作は deny に入れて、選択肢として存在しなくする。

取り消せない操作だけ ask に残す。

残りは確認なしで進ませる。

押し間違える余地を消してから、確認を減らす。 これが順番です。逆にすると、ただ危険になります。

3-3. なぜ多いと危ないのか

確認が1日に何十回も出ると、内容を読まなくなります。

これは意志の問題ではありません。同じ形の確認が繰り返し出れば、それは風景になります。風景は読み飛ばされます。

そして、いちばん読むべき1回も、同じ手つきで通してしまう。

確認を数個に絞ると、出たときに手が止まります。安全性を上げているのは、確認の数ではなく、確認の珍しさでした。

3-4. 抜け道を先に塞ぐ

もうひとつ、大事な考え方があります。

個別の危険な操作より先に、「その制限を迂回できる汎用の道」を塞ぐことです。

たとえば、コードを直接実行できるコマンドが1つでも通っていれば、他の禁止設定はすべて回避できます。1つずつ禁止を積んでも、そこが空いていれば意味がありません。

同じ理由で、設定ファイル自体の編集も止めます。

{
  "permissions": {
    "deny": [
      "Edit(~/.claude/settings.json)",
      "Edit(~/.claude/hooks/**)",
      "Edit(**/.git/hooks/**)"
    ]
  }
}

設定を書き換えられたら、設定の意味がなくなります。守るための仕組みを、守るための設定です。

4. 外に出す経路を分けて考える

もうひとつ、実務的なコツを書きます。

読む権限と、外に持ち出す経路は、別のものとして扱います。

ファイルを読んだり加工したりすることは許して、外部に送信する手段は塞ぐ、という分け方です。

{
  "permissions": {
    "allow": [
      "Bash(sed:*)",
      "Bash(awk:*)",
      "Bash(jq:*)"
    ],
    "deny": [
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Bash(nc:*)"
    ]
  }
}

読んで、加工することはできる。でも、外へ送れない。 こう分けておくと、万一おかしな指示が混ざっても、情報が出ていく経路がありません。

5. サンドボックス

5-1. 何をするものか

サンドボックスは、隔離された箱の中で動かすしくみです。

箱の中からは、決められた場所にしか書き込めませんし、決められた先にしか通信できません。設定で禁止するより一段外側で、そもそも届かなくします。

5-2. 基本の設定

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "failIfUnavailable": true
  }
}

この3行が要です。

enabled で有効にします。

autoAllowBashIfSandboxed は、サンドボックスの中で実行されるなら確認を出さない、という指定です。確認を減らせるのは、この行のおかげです。

failIfUnavailable は、サンドボックスが使えないときに実行させない指定です。ここを false にすると、何かの理由でサンドボックスが外れたときに、隔離なしで自動実行が続きます。 いちばん危ない状態なので、必ず true にしてください。

1行目と3行目はセットです。片方だけでは意味がありません。

5-3. 通信先を絞る

{
  "sandbox": {
    "network": {
      "strictAllowlist": true,
      "allowedDomains": [
        "registry.npmjs.org",
        "*.npmjs.org",
        "github.com",
        "*.github.com",
        "raw.githubusercontent.com"
      ]
    }
  }
}

書いたドメイン以外には接続できなくなります。

これは「怪しいサイトを塞ぐ」というより、依存パッケージの取得先を固定するためです。決まった場所以外を見にいく動きがあれば、それ自体が異常のサインになります。

5-4. 認証情報を渡さない

{
  "sandbox": {
    "credentials": {
      "files": [
        { "path": "~/.ssh", "mode": "deny" },
        { "path": "~/.aws", "mode": "deny" },
        { "path": "~/.gnupg", "mode": "deny" },
        { "path": "~/.npmrc", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

鍵やトークンを、箱の中に持ち込ませない設定です。

自分が使っているサービスの認証情報も、忘れずに足してください。 決済サービスのキー、デプロイ先の認証情報など。その環境で「これが漏れたらいちばん困る」ものから書くのが確実です。

5-5. サンドボックスから外すもの

{
  "sandbox": {
    "excludedCommands": ["git", "gh", "docker"]
  }
}

正直に書くと、これは妥協です。

git や gh は認証情報と外部通信を使うので、隔離された箱の中だと素直に動きません。無理に押し込めると、結局サンドボックス自体を切ることになります。

なので、この3つは箱の外に出して、かわりに権限の設定で縛ります。 すべてを1つの層で守ろうとしない、という割り切りです。

5-6. Windows の方へ

2026年8月時点で、サンドボックスは Windows ネイティブでは使えません。

Windows でサンドボックスを使いたい場合は、WSL 上で動かす必要があります。第1回で触れた「WSL を選ぶ理由」の1つが、これです。

6. CLAUDE.md

6-1. 何を書くファイルか

settings.json が「何をさせないか」を決めるファイルなら、CLAUDE.md は「どうしてほしいか」を伝えるファイルです。

プロジェクトのルートに置きます。第3回で触れた /init を実行すると、下書きが自動で作られます。

6-2. 書き方のコツ

判定できる形で書きます。

× 読みやすいコードを書いてください
○ 関数は20行以内、ネストは3段まで

「読みやすい」の基準は人によって違います。こちらの頭の中にしかない基準は、伝わりようがありません。

禁止には理由を添えます。

× この関数は使わない
○ この関数は使わない（外部入力が混ざると危険なため）

理由があると、状況が変わったときに「これは当てはまるか」で判断してくれます。理由がないと、例外扱いで破られます。

6-3. 長くしすぎない

あれもこれもと書き足すと、いちばん守ってほしい一行が埋もれます。

常駐させるのは、プロジェクトの間ずっと変わらないものだけにしてください。そのときだけ必要な指示は、依頼文で渡せば足ります。

6-4. 方針を変えたときは、古いほうを名指しで否定する

これは、長く使うほど効いてきます。

方針を変えて古い記述を削除すると、手元からは消えるのに、振る舞いには残っていることがあります。 忘れた頃に、やめたはずの書き方が戻ってくる。

なので、削除せずに廃止として残します。

# 廃止した方針

- ~~Aの書き方~~ → 廃止（理由）。今後はBを使う。
  Aが出てきたら、それは古い指示です。

見た目はきれいではありませんが、古いものが出てきたときに否定する根拠が、文書の側に残ります。

7. まとめて見る

ここまでの内容を、1つの設定にまとめます。そのままコピーして、自分の環境に合わせて調整してください。

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Edit",
      "Bash(cd:*)",
      "Bash(ls:*)",
      "Bash(cat:*)",
      "Bash(grep:*)",
      "Bash(find:*)",
      "Bash(sed:*)",
      "Bash(awk:*)",
      "Bash(jq:*)",
      "Bash(mkdir:*)",
      "Bash(cp:*)",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git push:*)",
      "Bash(git branch:*)",
      "Bash(npm run:*)",
      "Bash(npm test:*)",
      "Bash(npm install:*)"
    ],
    "ask": [
      "Bash(git push --tags:*)",
      "Bash(npm publish:*)"
    ],
    "deny": [
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(**/*.pem)",
      "Edit(~/.claude/settings.json)",
      "Edit(~/.claude/hooks/**)",
      "Edit(**/.git/hooks/**)",
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Bash(nc:*)",
      "Bash(sudo:*)",
      "Bash(rm -rf /)",
      "Bash(rm -rf ~)",
      "Bash(git clean:*)",
      "Bash(git reset --hard:*)",
      "Bash(git push --force:*)",
      "Bash(git push -f:*)",
      "Bash(git stash drop:*)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "failIfUnavailable": true,
    "excludedCommands": ["git", "gh", "docker"],
    "network": {
      "strictAllowlist": true,
      "allowedDomains": [
        "registry.npmjs.org",
        "*.npmjs.org",
        "github.com",
        "*.github.com",
        "raw.githubusercontent.com"
      ]
    },
    "credentials": {
      "files": [
        { "path": "~/.ssh", "mode": "deny" },
        { "path": "~/.aws", "mode": "deny" },
        { "path": "~/.gnupg", "mode": "deny" },
        { "path": "~/.npmrc", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

3つの層になっています。

いちばん外がサンドボックス。そもそも届かないようにする層です。

その内側が権限の設定。通すものを決める層です。

そして CLAUDE.md。どうしてほしいかを伝える層です。

外側の層があるから、確認を減らせます。確認を減らせるのは、確認以外で止まる仕組みがあるときだけです。

8. 入れる順番

全部いっぺんに設定しなくて大丈夫です。効く順に並べます。

1. サンドボックスの3行。 enabled / autoAllowBashIfSandboxed / failIfUnavailable。ここだけで、確認の量と安全性の両方が変わります。

2. deny の基本。 秘密ファイルの読み取り、sudo、外部への送信手段、戻せない git 操作。

3. ask を絞る。 取り消せない操作だけ。

4. allow を広げる。 読む・探す・試すものを入れて、日常が止まらない状態にします。ここが狭いままだと、結局うるさいままです。

5. CLAUDE.md。 プロジェクトのルールを書きます。

9. 設定したあとの確認

書いたら、必ず動作を確認してください。

/permissions

いまの権限設定が表示されます。書いたつもりが反映されていない、というのはよくあります。 JSON の書式ミスで、ファイル全体が読み込まれていないこともあります。

/status

こちらでも、設定の状態を含めた全体を確認できます。

まとめ

設定は ~/.claude/settings.json（全体）と、プロジェクト内の .claude/settings.json
操作を 許可・確認・禁止 の3つに振り分ける
allow は「読む・探す・試す」を広めに。狭いとうるさいままになる
ask は取り消せないものだけ。 絞るほど、出たときに読む
deny は「戻せないもの」と「秘密ファイル」。git commit を止めない
抜け道を先に塞ぐ。 設定ファイル自体の編集も禁止する
読む権限と、外に持ち出す経路（curl など）は分けて考える
サンドボックスは enabled と failIfUnavailable をセットで
Windows ネイティブではサンドボックス非対応（WSL が必要）
CLAUDE.md は判定できる形で書く。長くしすぎない
設定したら /permissions で反映を確認する

次回は、MCP・Skill・Plugin を扱います。「MCP という言葉を見かけるけれど、何なのか」「3つの違いが分からない」という方向けの回です。結局どれを使えばいいのか、という問いに直接答えます。

※本記事の情報は2026年8月時点のものです。設定項目は変更されることがあるため、最新の情報は公式ドキュメントをご確認ください。