Claude Codeの設定は、settings.json というファイルに書きます。
同じ名前のファイルが最大4か所にあり、同じ項目が複数の場所にあると、優先順位の高いほうが使われます。
- 自分の全プロジェクトの設定：ホームフォルダの .claude/settings.json
- チームで共有する設定：プロジェクトの .claude/settings.json
- このプロジェクトの自分だけの設定：プロジェクトの .claude/settings.local.json
- 強い順：組織の管理設定 → 起動時の –settings → settings.local.json → プロジェクトの settings.json → ユーザーの settings.json
この記事は、2026年9月29日時点の公式ドキュメントと、Claude Code v2.1.284 で実際に動かした結果にもとづいています。
settings.jsonの場所
| 種類 | 場所 | 効く範囲 |
|---|---|---|
| ユーザー | ホームフォルダの .claude/settings.json | 自分の全プロジェクト |
| プロジェクト（共有） | プロジェクトの .claude/settings.json | そのプロジェクトの全員（Gitに入れる） |
| ローカル | プロジェクトの .claude/settings.local.json | そのプロジェクトの自分だけ（Gitに入れない） |
| 組織の管理 | managed-settings.json・MDM・claude.aiの管理画面 | 組織が配ったPCやアカウント全部 |
Windowsでは、ホームフォルダの .claude は %USERPROFILE%\.claude のことです。
Claude Codeを入れただけでは、settings.json はどこにも作られません。
/config で変えた設定や、権限の確認で「今後は聞かない」を選んだときに、はじめて作られます。
~/.claude.jsonは別物
ホームフォルダには、.claude.json という似た名前のファイルもあります。
こちらはClaude Codeが自分で書くファイルで、ログインの情報やMCPサーバーの登録、フォルダを信頼したかどうかなどが入っています。
手で直す必要はありません。
優先順位を実際に確かめた
練習用のフォルダで、同じ環境変数 DEMO_LEVEL を2つのファイルに書き、どちらが使われるかを見ました。
// .claude/settings.json（プロジェクト）
{
"env": { "DEMO_LEVEL": "project" },
"permissions": { "allow": ["Bash(echo *)"] }
}
// .claude/settings.local.json（ローカル）
{
"env": { "DEMO_LEVEL": "local" }
}設定ファイルにはコメントを書けないので、上の // の行は説明のために付けています。
| 試したこと | echo $DEMO_LEVEL の結果 |
|---|---|
| プロジェクトとローカルの両方に書いた | local |
| さらに起動時に –settings で cli を渡した | cli |
| ローカルのファイルを消した | project |
ローカルがプロジェクトに勝ち、起動時の –settings がさらにローカルに勝っています。
claude --settings '{"env":{"DEMO_LEVEL":"cli"}}'–settings はその回だけの設定で、ファイルは書き換わりません。
組織の管理設定は、–settings を含めてどこからも上書きできません。
リストの設定は足し合わされる
permissions.allow のようなリストの項目は、上の順位で1つに決まるのではなく、全部のファイルの中身が足し合わされます。
チームの settings.json で許可したコマンドに、自分の settings.local.json で許可を追加する、といった使い方ができます。
一方、model のように値が1つの項目は、順位のいちばん高いファイルの値だけが使われます。
環境変数は、この順位の外にあります。
同じことを環境変数と設定の両方で決められる項目は、どちらが勝つかが項目ごとに決まっています。
よく使う設定項目
| 項目 | 決めること |
|---|---|
| permissions | 使ってよいコマンドや読んではいけないファイル（allow・ask・deny） |
| env | Claude Codeが使う環境変数 |
| model | 使うモデル |
| hooks | 決まったタイミングで動かすコマンド |
| statusLine | 画面下の表示 |
| cleanupPeriodDays | 会話の記録を残す日数 |
| attribution | コミットやプルリクエストに付ける署名 |
| autoMemoryEnabled | 自動メモリのオンとオフ |
| claudeMdExcludes | 読み込まない CLAUDE.md |
書き方の例です。
{
"$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などで項目名の補完と入力チェックが効きます。
ただしスキーマの更新は新しい版より遅れることがあるので、新しい項目に警告が出ても間違いとは限りません。
書き間違えると、そのファイルごと効かなくなる
settings.json は厳密なJSONなので、コメントや末尾のカンマは書けません。
試しにプロジェクトの settings.json の末尾にカンマを付けたところ、そのファイルの設定がすべて効かなくなりました。
{
"env": { "DEMO_LEVEL": "project", },
}出力は空でした（`DEMO_LEVEL` は未設定です）。対話モードで起動すると、壊れたファイルは Settings Error として知らされます。
claude -p で動かしたときはエラーが画面に出なかったので、スクリプトから使う場合は特に気をつけます。
設定が効かないときの確かめ方
- 対話中に /status を実行し、Setting sources の行に目的のファイルが出ているかを見る
- JSONの書き間違い（コメント・末尾のカンマ）がないかを見る
- 同じ項目を上の順位のファイルで決めていないかを見る
- 組織の管理設定で決められていないかを見る
/config で変えられる設定は、画面のメニューから選ぶだけで保存されます。
/config verbose=true のように、項目と値を直接書いて変えることもできます。
/config はターミナルの画面だけの機能で、VS Codeの拡張機能やデスクトップアプリでは開けません。
CLAUDE.mdとの使い分け
settings.json に書いた権限は、Claudeの判断に関係なく必ず守られます。
CLAUDE.md に書いたことは、指示として読まれるだけで、必ず守られるとは限りません。
「このファイルは読ませない」のように確実に止めたいことは settings.json に、書き方の好みは CLAUDE.md に書きます。
CLAUDE.md の置き場所と読み込まれる順番は、Claude CodeのCLAUDE.mdの書き方と置き場所で紹介しています。
まとめ
- 自分用はホームの .claude/settings.json、チーム用はプロジェクトの .claude/settings.json
- 自分だけの例外は .claude/settings.local.json に書く
- 強い順は、組織 → –settings → ローカル → プロジェクト → ユーザー
- リストの項目は足し合わされ、値が1つの項目は強いほうが使われる
- JSONの書き間違いはファイルごと無視されるので、/status で確かめる
参考：Claude Code公式ドキュメント「Settings files and precedence」（2026年9月29日に確認）。
