Claude Code settings.json入門｜設定ファイルと優先順位

Claude Code を使い込むと、「最初に使うモデル」「確認なしで実行してよいコマンド」「読ませたくないファイル」など、決めておきたいことが増えてきます。こうした決まりごとを書いておく場所が settings.json などの設定ファイル です。

この記事では、公式ドキュメント「Settings files and precedence」（2026年11月1日確認）にもとづいて、どのファイルに何を書くか、同じ項目を複数の場所に書いたらどれが効くかを、表を中心に整理します。

結論：置き場所で「効く人」が決まる

設定ファイル選びで迷ったら、「この決まりを誰に効かせたいか」 で選びます。自分だけならホームの ~/.claude/settings.json、チーム全員ならプロジェクトの .claude/settings.json、このプロジェクトで自分だけなら .claude/settings.local.json です。

表の ~/.claude はホームフォルダの中の .claude、先頭に ~/ が付かない .claude はプロジェクトの中の .claude を指します。

なお、インストールしただけでは設定ファイルは作られません。/config でテーマなどを変えたとき、または確認画面で「Yes, and don't ask again」を選んだときに、Claude Code が自分で作ります。

優先順位：上の段が勝つ

同じ項目が複数の場所にあるときは、いちばん上の段の値が使われます。 強い順に並べると次のとおりです。

たとえば、チームのファイルで "model": "claude-sonnet-5" となっていても、自分だけ別のモデルにしたいなら、.claude/settings.local.json に "model" を書けば自分のセッションだけが変わります。

環境変数はこの段のどこにも入りません。たとえばシェルで設定した ANTHROPIC_MODEL は、どのファイルの model よりも優先されます。どちらが勝つかは項目ごとに決まっています。

リストは「足し算」になる

permissions.allow のようなリストの項目は、上書きではなく合わさります。 チームのファイルと自分のファイルの両方に許可ルールを書けば、両方が効きます。許可ルールの書き方は Claude Codeの権限設定 で解説しています。

ただし fallbackModel や modelPicker など、モデルの一覧を持つ一部の項目は、いちばん上の段の値をまるごと使うなど、別の決まりで動きます。

書き方：3つの変え方

ふだんは /config で変え、細かい項目はファイルを直接書き、お試しは起動時に1回だけ指定する と覚えると迷いません。

ファイルを直接書くときは、厳密なJSON で書く点に注意します。// のコメントや、最後の要素の後ろのカンマはエラーになります。先頭に "$schema": "https://json.schemastore.org/claude-code-settings.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.*)"]
  }
}

書いたらすぐ効くもの・再起動が要るもの

多くの項目は保存した時点で、動いているセッションに反映されます。 許可ルールやフックの変更もそうです。一方で model や effortLevel は起動時に1回だけ読まれるため、途中で変えたいときは /model や /effort を使います。モデルを切り替えると会話の読み直しが起きる点は プロンプトキャッシュの記事 で説明しています。

確かめ方：/status を見る

設定を書いたら /status を開き、Setting sources の行に目的のファイルが出ているかを確かめます。 この行は「どのファイルを読んだか」を示すもので、どの項目がどのファイルから来たかまでは出ません。読み込めなかった項目を一覧で見たいときは claude doctor を使います。

JSONが壊れていると、起動時に Settings Error（ファイル全体の問題）や Settings Warning（一部の項目だけの問題）が出ます。Warning のときは、問題の項目だけ飛ばして残りは効いたままです。

効かないときの見直し表

チーム共有の .claude/settings.json に書いた permissions.allow や多くの env は、仲間がそのフォルダを信頼するまで効きません。 一方で deny と ask のルールはすぐに効きます。守りのルールが先に効く作りです。共有のフックの作り方は Claude Codeのフック を参考にしてください。

クラウドで動かすときの違い

クラウドのセッションでは、自分用とプロジェクトの自分用のファイルは読まれません。 手元のパソコンにあるファイルだからです。リポジトリにコミットしたチーム共有のファイルは、リポジトリ1つのセッションなら読まれます。設定を変えたいときは、クラウドの環境に環境変数を設定する方法もあります。

まとめ

• 設定ファイルは4種類。誰に効かせたいか で置き場所を選ぶ
• 同じ項目は 組織の管理 → --settings → プロジェクトの自分用 → チーム共有 → 自分用 の順で強い。リストは合わさる
• 書いたら /status で確かめ、効かないときは上の段・書けない場所・JSONの壊れを順に見る

出典

• Claude Code 公式ドキュメント「Settings files and precedence」

この記事はAIを使って下書きし、著者が事実確認・加筆しています。ツールの機能や料金は変わることがあるため、最新の情報は各社の公式ページでご確認ください。