設定ファイルの仕組み

Claude Code の設定は、いくつかのファイルに分けて書きます。どのファイルに書くかによって、その設定が効く範囲（自分だけか、プロジェクトの全員か、組織の全員か）が変わります。同じ項目が複数のファイルに書かれているときに、どれが使われるかにも決まりがあります。このページでは、設定ファイルの種類、効く範囲、優先順位を整理します。03. 権限モードと、確認を減らす方法で扱った権限ルールを、どのファイルに書けばよいかも、このページで分かります。

この記事で分かること

設定ファイルの種類と、それぞれが効く範囲
設定ファイルが、いつ、誰によって作られるか
同じ項目が複数のファイルにあるときの、優先順位
プロジェクトの設定ファイルに書いても効かないもの
利用者が書いた設定が反映されないときの、原因の調べ方

用語の整理

用語	意味
設定ファイル（settings file）	Claude Code の動作を決める内容を書いたファイル。JSON という形式で書く
JSON	データを、`{ "名前": 値 }` の形で書く形式。書き方の決まりが厳密で、コメントは書けない
範囲（scope）	設定が効く相手と場所。自分だけ、プロジェクトの全員、組織の全員、など
キー（key）	設定の項目の名前。たとえば、`permissions` や `model`
優先順位（precedence）	同じキーが複数のファイルにあるときに、どのファイルの値を使うかの決まり
管理設定（managed settings）	組織の管理者が配布する設定。利用者やプロジェクトの設定では、上書きできない
信頼の確認（workspace trust）	初めて開くフォルダーで、そのフォルダーの設定を有効にしてよいかを、利用者に尋ねる仕組み

設定ファイルは 4 つある

Claude Code は、4 つのファイルから設定を読みます。これに加えて、組織が管理設定を配布している場合があります。

範囲	ファイル	効く相手	使いみち
利用者	`~/.claude/settings.json`	自分。この PC の、すべてのプロジェクト	個人の好み。自分用の権限ルール
プロジェクト（共有）	`.claude/settings.json`	そのフォルダーで作業する全員。Git のリポジトリでは、コミットすると、ほかの人にも届く	チームで共通の権限ルール、フック、プロジェクトに必要な環境変数
プロジェクト（自分だけ）	`.claude/settings.local.json`	自分。このプロジェクトだけ	1 つのプロジェクトでの、個人的な上書き。共有する前の試し
管理	管理設定（ファイル、端末を管理する仕組み、管理者用の画面からの配信）	組織が配布した、すべての相手	セキュリティの方針

表の ~/.claude は、ホームフォルダーの中の .claude フォルダーです。~ の付かない .claude は、プロジェクトのフォルダーの中の .claude フォルダーです。

効く範囲を、例で見る

PC の中に website/ と app/ の 2 つのプロジェクトがあり、app/ は、ほかの人も自分の PC に複製して使っているとします。

設定を書いたファイル	自分の `website/`	自分の `app/`	ほかの人の `app/`
`~/.claude/settings.json`	効く	効く	効かない
`app/.claude/settings.json`	効かない	効く	コミットすれば効く
`app/.claude/settings.local.json`	効かない	効く	効かない
管理設定	効く	効く	同じ組織であれば効く

もう 1 つのファイル：`~/.claude.json`

名前が似ていますが、~/.claude.json は、上の 4 つとは別のファイルです。Claude Code が自分のために書き込むファイルで、サインインの状態、MCP サーバーの設定、プロジェクトごとの状態（信頼の確認の結果など）が入っています。公式ドキュメントでは、利用者が編集する必要はない、とされています。

設定ファイルは、いつできるか

Claude Code をインストールしただけでは、設定ファイルは 1 つも作られません。ファイルは、次のときに作られます。

ファイル	作られるとき
`~/.claude/settings.json`	自分で作る。または、設定の画面（`/config`）で、利用者の設定に保存される項目を変えたとき
`.claude/settings.json`	自分で作る。Claude Code をすでに使っているプロジェクトでは、コミットされていることがある
`.claude/settings.local.json`	自分で作る。または、権限の確認の画面で、「今後は確認しない」にあたる選択肢を選んだとき
管理設定	組織が配布する。利用者は、作ることも編集することもしない

`.claude/settings.local.json` と Git

.claude/settings.local.json は、自分だけの設定なので、リポジトリにコミットしないファイルです。

Claude Code がこのファイルを初めて書き込むときは、Git の全体の除外設定に、このファイルの名前を自動で追加する。そのため、どのリポジトリでも、コミットの対象にならない。
自分の手でファイルを作った場合は、この追加が行われない。プロジェクトの .gitignore に、自分で書き加える。

優先順位

同じキーが複数の場所に書かれているとき、Claude Code は、優先順位が最も高い場所の値を使います。順位の高いものから並べると、次のとおりです。

順位	場所	内容
1	管理設定	組織が配布する設定。利用者の設定ファイルでも、起動時の指定でも、上書きできない
2	起動時の指定	ターミナル版で、`--settings` を付けて起動したときに渡す設定。そのセッションだけに効く
3	`.claude/settings.local.json`	このプロジェクトでの、自分だけの設定
4	`.claude/settings.json`	プロジェクトで共有する設定
5	`~/.claude/settings.json`	すべてのプロジェクトでの、自分の設定

「範囲が狭いものほど、優先される」と覚えると、分かりやすくなります。利用者の設定より、プロジェクトの設定が優先され、その中でも、自分だけの設定が優先されます。管理設定は、そのすべてより上にあります。

一覧の形のキーは、合わせて使われる

permissions.allow のように、値が一覧になっているキーは、扱いが違います。複数のファイルに同じキーがあると、どれか 1 つを選ぶのではなく、それぞれの一覧を合わせて使います。あるファイルに書いたルールが、別のファイルのルールを消すことはありません。

権限ルールは、deny が常に勝つ

権限ルールには、さらに決まりがあります。どこか 1 つの場所で deny（禁止）にされた操作は、ほかの場所で allow（許可）にしても、許可されません。

利用者の設定	プロジェクトの設定	結果
allow	deny	禁止される
deny	allow	禁止される

これは、03 で見た「deny、ask、allow の順に調べる」という決まりが、ファイルをまたいで働くためです。

同じ理由で、次のことも起こります。権限の確認の画面で「今後は確認しない」を選ぶと、allow ルールが .claude/settings.local.json に保存されます。しかし、プロジェクトの設定や管理設定に、同じ操作についての ask ルール（毎回確認する）があると、ask ルールが先に当てはまるので、確認は出続けます。

プロジェクトの設定ファイルの注意点

プロジェクトの設定ファイルは、リポジトリと一緒に、ほかの人の PC に届きます。受け取った側から見ると、内容を自分で決めていない設定です。そのため、プロジェクトの設定ファイルには、いくつかの制限があります。

信頼の確認を待つもの

プロジェクトの .claude/settings.json に書いた次の項目は、利用者がそのフォルダーについて信頼の確認を承認するまで、有効になりません。

permissions.allow（許可するルール）
permissions.additionalDirectories（追加の作業フォルダー）
env（環境変数）の大部分

これらは、Claude ができることを広げる設定です。信頼の確認の画面には、そのフォルダーの設定が許可しようとしているルールとフォルダーが一覧で表示されるので、承認する前に内容を確かめられます。

一方、deny ルールと ask ルールは、制限するだけの設定なので、信頼の確認を待たずに、すぐに有効になります。

書いても効かないもの

プロジェクトの設定ファイル（.claude/settings.json と .claude/settings.local.json）に書いても、効かない値があります。代表的なものは、権限モードの既定値です。

キー	プロジェクトの設定ファイルで効かない値	書く場所
`permissions.defaultMode`	`auto`、`bypassPermissions`	`~/.claude/settings.json` か、管理設定

ほかにも、利用者の設定や管理設定からしか効かないキーがあります。それぞれのキーが、どの範囲で効くかは、公式ドキュメントの設定の一覧（Settings reference）に書かれています。

設定の変え方

設定を変える方法は、3 つあります。

方法	内容	保存される場所
設定の画面を使う	セッションの中で `/config` と入力する。テーマなど、個人向けの一部の項目を変えられる。すべてのキーが並んでいるわけではない	多くは `~/.claude/settings.json`
設定ファイルを編集する	エディターでファイルを開いて、キーを書き足す	編集したファイル
1 回のセッションだけ変える	ターミナル版で、起動時に `--settings` などを指定する	保存されない

デスクトップアプリでは、/config と入力すると、アプリの設定画面（Settings → Claude Code）が開きます。権限ルールなどは、設定ファイルを直接編集します。

設定ファイルの書き方

設定ファイルは、厳密な JSON で書きます。// で始まるコメントや、最後の項目のあとの余分なカンマがあると、誤りとして扱われます。

利用者の設定に、権限ルールを書く例です。lint とテストのコマンドを確認なしで実行できるようにし、.env ファイルを読めないようにしています。

json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

1 行目の $schema は、設定ファイルの書き方の定義を指しています。VS Code など、対応しているエディターでは、この行があると、キーの入力の補完と、誤りの表示が働きます。

変更が反映されるタイミング

Claude Code は、設定ファイルを見張っていて、変更があると読み込み直します。そのため、permissions や hooks などの変更の多くは、セッションを始め直さなくても、実行中のセッションに反映されます。

ただし、セッションの開始時に 1 回だけ読まれるキーもあります。たとえば、model（使うモデル）は、設定ファイルを書き換えても、実行中のセッションには反映されません。セッションの途中でモデルを変えるときは、/model を使います。

管理設定は、保存した時点ではなく、決められた間隔で、実行中のセッションに届きます。

デスクトップアプリと、VS Code の拡張機能での設定

02. Claude Code を使う場所で見たとおり、デスクトップアプリも、VS Code の拡張機能も、ターミナル版と同じ設定ファイルを読みます。~/.claude/settings.json に書いた権限ルールは、どこから使っても適用されます。

そのうえで、それぞれに、アプリや拡張機能だけの設定があります。この 2 種類を区別しておくと、設定を探すときに迷いません。

使う場所	Claude Code の設定（共有される）	その場所だけの設定
デスクトップアプリ	設定ファイル	アプリの設定画面（Settings → Claude Code）。モードの選択欄で選んだモードは、フォルダーごとに記憶される
VS Code の拡張機能	設定ファイル	VS Code の設定の中の、拡張機能の設定（Extensions → Claude Code）。始まるときの権限モードを決める `claudeCode.initialPermissionMode` など

「設定ファイルに書いたのに、そのとおりにならない」ときは、その場所だけの設定が、別の値になっていないかも確かめます。たとえば、始まるときの権限モードは、デスクトップアプリでは、選択欄で選んだモードが defaultMode より優先されます。VS Code の拡張機能では、拡張機能の設定が、設定ファイルより先に見られます。

何が読み込まれたかを確かめる

セッションの中で /status と入力すると、今のセッションで有効になっている設定の出どころを確かめられます。表示の中の「Setting sources」の行に、読み込まれた設定ファイルが並びます。管理設定が有効な場合は、その届き方も表示されます。

この行で分かるのは、どのファイルが読み込まれたかまでです。それぞれのキーの値が、どのファイルから来たかは、表示されません。

利用者が書いた設定が、Claude Code の動きに反映されないとき

設定ファイルに書いたのに、Claude Code が、そのとおりに動かないことがあります。理由は、大きく 3 つに分けられます。

別の場所に書かれた設定が、優先されている
その設定は、書いた場所からは効かない
設定ファイルが、正しく読み込まれていない

どれに当たるかを調べるために、まず、セッションの中で /status と入力して、どのファイルが読み込まれているかを確かめます。

別の場所に書かれた設定が、優先されている

同じキーが、優先順位が上の場所にも書かれていると、そちらの値が使われます。

確かめること	対処
プロジェクトの設定、起動時の指定、管理設定に、同じキーがないか	優先順位が上の場所の値を直す。管理設定の場合は、利用者の側では変えられない

その設定は、書いた場所からは効かない

キーや値によっては、効く場所が決まっています。

確かめること	対処
`permissions.defaultMode` の `auto` や `bypassPermissions` を、プロジェクトの設定ファイルに書いていないか	利用者の設定（`~/.claude/settings.json`）に書く

設定ファイルが、正しく読み込まれていない

ファイルの書き方に誤りがあると、ファイルの全体、または誤っている項目が、読み飛ばされます。

確かめること	対処
JSON の書き方に誤りがないか。コメントや、最後の項目のあとの余分なカンマがないか	誤りを直す

誤りがあるとき、Claude Code は、セッションの開始時に知らせます。

表示	状況	動き
Settings Error	ファイル全体が、JSON として読めない。または、受け付けられない値がある	直す、終了する、壊れた設定なしで続ける、のどれかを選ぶ画面が出る
Settings Warning	一部の項目だけが誤っている。たとえば、権限ルールの書き方の誤り	誤っている項目だけを飛ばして、残りは有効になる

権限ルールが、利用者の期待どおりに働かない

権限ルールは、複数の場所のルールが組み合わされるので、1 つのファイルだけを見ても、結果が分からないことがあります。

起きていること	原因	対処
確認の画面で「今後は確認しない」を選んだのに、確認が出る	保存されたのは allow ルール。優先順位が上の場所に、同じ操作についての ask ルールがあると、ask ルールが先に当てはまる	プロジェクトの設定と管理設定に、ask ルールがないかを確かめる
利用者が書いた権限ルールが、使われない	管理設定で、権限ルールが、管理設定に書かれたものだけに限定されている	利用者の側では変えられない。管理者に確認する

プロジェクトの設定が、ほかの人に届かない

.claude/settings.json に書いた設定が、同じリポジトリを使うほかの人の環境で、効いていない場合です。

原因	対処
ファイルが、コミットされていない	ファイルが、Git の管理の対象になっているかを確かめる
相手が、そのフォルダーについて、信頼の確認を承認していない	allow ルールなどは、承認するまで有効にならない。相手に、承認してもらう

実際にやってみる

このサイトのリポジトリで、設定ファイルが今どうなっているかを確かめました。

設定ファイルが、あるかどうかを確かめる

ファイル	結果
`~/.claude/settings.json`	ない
`.claude/settings.json`	ない
`.claude/settings.local.json`	ない
`~/.claude.json`	ある

設定ファイルは、3 つとも、ありませんでした。「インストールしただけでは、設定ファイルは作られない」という説明のとおりです。Claude Code を使い始めてから、設定の画面で項目を変えることも、権限の確認の画面で「今後は確認しない」を選ぶことも、していなかったことになります。

~/.claude.json は、ありました。このファイルは、Claude Code が自分で書き込むものです。中には、このリポジトリについての、信頼の確認の結果（承認済み）などが入っていました。

読み込まれる設定の範囲を確かめる

デスクトップアプリが Claude Code を起動するときの指定を、実行中のプロセスの一覧から確かめました。

bash

ps -axo command | grep 'claude-code' | grep -o -- '--setting-sources=[a-z,]*'

text

--setting-sources=user,project,local

利用者（user）、プロジェクトの共有（project）、プロジェクトの自分だけ（local）の 3 つの範囲を読み込む指定になっていました。ファイルを作れば、読み込まれる状態です。

このリポジトリでは、共有の設定がコミットされない

プロジェクトの .gitignore を確かめたところ、次の行がありました。

text

# Claude Code のローカル設定（Mac 固有のパスを含む）
.claude/

.claude フォルダーの全体を、Git の管理の対象から外しています。この状態では、.claude/settings.json を作っても、コミットされません。つまり、ほかの人には届かず、自分だけの設定と同じ働きになります。

この行は、プレビュー用のファイル（.claude/launch.json）に、PC ごとに違うパスが入っているために、書いたものです。プロジェクトで共有する設定を置きたくなったときは、フォルダーの全体ではなく、共有しないファイルだけを外す書き方に、変える必要があります。

text

.claude/*
!.claude/settings.json

1 行目で .claude の中のファイルをすべて外し、2 行目で settings.json だけを、管理の対象に戻しています。この変更は、まだ行っていません。共有する設定が必要になったときに行います。

禁止のルールを書いて、働くことを確かめる

設定ファイルを実際に作り、ルールが働くかを確かめました。実験なので、害のないコマンド 1 つだけを禁止します。決まった文字列を表示するだけのコマンドです。

まず、ルールがない状態で、コマンドを実行しました。

bash

echo study-lab-deny-test before

text

study-lab-deny-test before

そのまま実行されました。次に、セッションを続けたまま、.claude/settings.local.json を新しく作り、次の内容を書きました。

json

{
  "permissions": {
    "deny": [
      "Bash(echo study-lab-deny-test *)"
    ]
  }
}

ファイルを保存した直後に、同じ形のコマンドを 3 つ実行しました。

実行したコマンド	結果
`echo study-lab-deny-test after`	拒否された
`echo study-lab-allow-test after`	実行された
`pwd && echo study-lab-deny-test chained`	拒否された

拒否されたときは、次のように表示されました。

text

Permission to use Bash with command echo study-lab-deny-test after has been denied.

最後に、.claude/settings.local.json を削除して、もう一度、最初と同じ形のコマンドを実行しました。

bash

echo study-lab-deny-test removed

text

study-lab-deny-test removed

実行されました。禁止は、解除されています。

この実験で確かめられたことは、次のとおりです。

セッションの途中で作った設定ファイルが、読み込まれる。 セッションを始め直さなくても、保存した直後から、ルールが働いた。
ルールに当てはまるコマンドだけが、止められる。 文字列が 1 か所違うコマンドは、そのまま実行された。
&& でつないだコマンドは、それぞれが調べられる。 禁止したコマンドが 2 つ目にあっても、全体が拒否された。03 で見た説明のとおりになっている。
ファイルを削除すると、すぐに元に戻る。
このセッションは auto モードで動いているが、deny ルールは働いた。 権限モードが確認を減らす設定であっても、禁止のルールは守られる。

あわせて、このファイルが Git の管理の対象にならないことも確かめました。このリポジトリでは、上で見たとおり、.gitignore で .claude フォルダーの全体を外しています。それとは別に、Git の全体の除外設定（~/.config/git/ignore）にも、次の行が入っていました。

text

**/.claude/settings.local.json

公式ドキュメントにある、「Claude Code がこのファイルを初めて書き込むときに、全体の除外設定に追加する」という説明と合う内容です。この行があるので、ほかのリポジトリでも、このファイルはコミットの対象になりません。

まとめ

設定ファイルは、利用者（~/.claude/settings.json）、プロジェクトの共有（.claude/settings.json）、プロジェクトの自分だけ（.claude/settings.local.json）の 3 つと、組織が配布する管理設定がある。どこに書くかで、効く範囲が決まる。
インストールしただけでは、設定ファイルは作られない。自分で作るか、設定の画面や、権限の確認の画面での操作によって作られる。
優先順位は、管理設定、起動時の指定、プロジェクトの自分だけ、プロジェクトの共有、利用者、の順に高い。
一覧の形のキーは、複数のファイルの内容を合わせて使う。権限ルールは、どこか 1 つで deny にされると、ほかで allow にしても許可されない。
プロジェクトの設定ファイルの allow ルールは、信頼の確認を承認するまで有効にならない。auto などの一部の値は、プロジェクトの設定ファイルに書いても効かない。
利用者が書いた設定が反映されないときは、/status で読み込まれたファイルを確かめ、優先順位、書いた場所、ファイルの書き方の順に調べる。

確認の記録

項目	内容
最終確認日	2026 年 10 月 12 日
Claude Code のバージョン	2.1.295（macOS のデスクトップアプリ）
検証の状況	「実際にやってみる」は、macOS のデスクトップアプリと、このサイトのリポジトリで確かめた結果。設定ファイルを作り、deny ルールが働くことと、削除すると解除されることを、実際に操作して確かめた。それ以外の節は、公式ドキュメントの内容をもとに書いている
確かめていない内容	allow ルールと ask ルール、複数のファイルの間の優先順位、`/status` と `/config` の表示、信頼の確認の画面、壊れた設定ファイルの表示は、実際には操作していない

分野 3：Claude Code の設定と使い方

設定ファイルの仕組み ​

この記事で分かること ​

用語の整理 ​

設定ファイルは 4 つある ​

効く範囲を、例で見る ​

もう 1 つのファイル：~/.claude.json ​

設定ファイルは、いつできるか ​

.claude/settings.local.json と Git ​

優先順位 ​

一覧の形のキーは、合わせて使われる ​

権限ルールは、deny が常に勝つ ​

プロジェクトの設定ファイルの注意点 ​

信頼の確認を待つもの ​

書いても効かないもの ​

設定の変え方 ​

設定ファイルの書き方 ​

変更が反映されるタイミング ​

デスクトップアプリと、VS Code の拡張機能での設定 ​

何が読み込まれたかを確かめる ​

利用者が書いた設定が、Claude Code の動きに反映されないとき ​

別の場所に書かれた設定が、優先されている ​

その設定は、書いた場所からは効かない ​

設定ファイルが、正しく読み込まれていない ​

権限ルールが、利用者の期待どおりに働かない ​

プロジェクトの設定が、ほかの人に届かない ​

実際にやってみる ​

設定ファイルが、あるかどうかを確かめる ​

読み込まれる設定の範囲を確かめる ​

このリポジトリでは、共有の設定がコミットされない ​

禁止のルールを書いて、働くことを確かめる ​

まとめ ​

確認の記録 ​

設定ファイルの仕組み

この記事で分かること

用語の整理

設定ファイルは 4 つある

効く範囲を、例で見る

もう 1 つのファイル：`~/.claude.json`

設定ファイルは、いつできるか

`.claude/settings.local.json` と Git

優先順位

一覧の形のキーは、合わせて使われる

権限ルールは、deny が常に勝つ

プロジェクトの設定ファイルの注意点

信頼の確認を待つもの

書いても効かないもの

設定の変え方

設定ファイルの書き方

変更が反映されるタイミング

デスクトップアプリと、VS Code の拡張機能での設定

何が読み込まれたかを確かめる

利用者が書いた設定が、Claude Code の動きに反映されないとき

別の場所に書かれた設定が、優先されている

その設定は、書いた場所からは効かない

設定ファイルが、正しく読み込まれていない

権限ルールが、利用者の期待どおりに働かない

プロジェクトの設定が、ほかの人に届かない

実際にやってみる

設定ファイルが、あるかどうかを確かめる

読み込まれる設定の範囲を確かめる

このリポジトリでは、共有の設定がコミットされない

禁止のルールを書いて、働くことを確かめる

まとめ

確認の記録