Claude Codeのsettings.jsonは、使うモデル、確認なしで実行してよいコマンド、読ませないファイルなど、Claude Codeの動きを決める設定ファイルです。置き場所は「自分のすべてのプロジェクト」「チーム全員」「このプロジェクトの自分だけ」「会社が配る管理設定」の4種類です。同じ項目を複数の場所に書いた時は、会社の管理設定がいちばん強く、次にこのプロジェクトの自分だけの設定、チーム全員の設定、自分のすべてのプロジェクトの設定の順に優先されます。設定が効かない時は、まず/statusで読み込まれたファイルを確かめます。
この記事は、Anthropicの公式ドキュメント（設定ファイルと優先順位、設定例、権限、設定の不具合の調べ方のページ）と公式の変更履歴を2026年10月23日に確認して書いています。画像は公式ドキュメントに掲載されたものです。編集部はClaude Codeの中で設定を変えて動きを確かめる実測は行っていません。記事内の設定例は、公式の例をもとに、JSONとして正しく読めることだけを確かめています。
公式の変更履歴で確かめた時点の最新版はv2.1.309です。設定の項目は版ごとに増えるため、細かい仕様は手元の版の公式ドキュメントで確かめてください。
Claude Codeのsettings.jsonとは：動きを決める設定ファイル
公式ドキュメントは、設定を「Claude Codeの動きを変えるJSONの項目」と説明しています。最初に使うモデル、確認なしで実行してよいこと、読ませないファイル、ターミナルでの見た目、会社として強制したいことなどを、settings.jsonに書きます。
似た名前のファイルと役割が違うので、最初に区別しておきます。
| ファイル | 役割 | 自分で書くか |
|---|---|---|
settings.json | Claude Codeの動きを決める設定（モデル、権限、環境変数、hooks＝決まったタイミングで自動で動かす処理など） | 書く |
| CLAUDE.md | プロジェクトの進め方や前提をClaudeに伝える指示書。Claudeが読んで判断する材料 | 書く |
~/.claude.json | Claude Codeが自分で書き込むファイル。アカウント情報、MCPサーバーの設定、フォルダーを信頼したかの記録などを保存する | 通常は書かない |
公式の説明では、CLAUDE.mdは「ここではこう進める」という案内に使い、絶対に起きてはいけないことは権限やhooksで止める、と使い分けています。settings.jsonは、この「止める」側の決まりも置ける場所です。
settings.jsonの場所は4種類：誰に効かせるかで選ぶ
Claude Codeは、次の4か所から設定を読みます。どこに書くかで、設定が効く人とプロジェクトの範囲が決まります。~/.claudeはホームフォルダーの中の.claudeフォルダー、先頭に~のない.claudeはプロジェクトの中の.claudeフォルダーです。
| 種類 | ファイルの場所 | 効く範囲 | 向いている設定 |
|---|---|---|---|
| ユーザー設定 | ~/.claude/settings.json | 自分の、このパソコンのすべてのプロジェクト | 見た目、普段のモデル、自分用の権限ルール |
| プロジェクト共有設定 | .claude/settings.json | そのフォルダーで作業する全員（Gitで共有した場合） | チームの権限、hooks、プラグイン、必要な環境変数 |
| プロジェクトの個人設定 | .claude/settings.local.json | このプロジェクトの自分だけ | チームの設定を自分だけ変える、共有前に試す |
| 管理設定 | managed-settings.jsonなど | 会社が設定を配った社員全員 | セキュリティの方針、守らせたい決まり |
Windowsでは、~/.claudeは%USERPROFILE%\.claudeのことです。環境変数CLAUDE_CONFIG_DIRを設定すると、ホームフォルダー側の設定や会話の履歴を別の場所に置けます。
settings.jsonが見つからない時は自分で作る
Claude Codeをインストールしただけでは、settings.jsonは作られません。ファイルがない時は、上の表の場所に自分で新しく作ってください。作ったファイルはそのまま読み込まれます。Claude Codeが自動で作る場合もあります。/configでテーマなどを変えると~/.claude/settings.jsonが作られ、許可を求める画面で「次回から聞かない」を選ぶと.claude/settings.local.jsonが作られます。
許可の画面で「次回から聞かない」を選ぶとsettings.local.jsonに書かれる
Claudeがコマンドを実行してよいか聞いてきた時に「Yes, and don't ask again」（はい、次回から聞かない）を選ぶと、その許可がallow（許可）のルールとして.claude/settings.local.jsonに保存されます。Gitで管理しているフォルダーなら、保存先は原則としてリポジトリの一番上のフォルダーです（Windowsなど一部の環境では例外があります）。
公式画像：コマンドの実行前に許可を求める画面。2番目を選ぶと許可のルールが保存される（Anthropic「Configure permissions」掲載。2026年10月23日確認）
Claude Codeが.claude/settings.local.jsonを初めて作る時は、このファイルがGitに入らないよう、パソコン全体に効くGitの除外リスト（Gitで記録しないファイルの一覧）に自動で登録します。自分の手でこのファイルを作った場合は登録されないので、.gitignoreに自分で追加してください。
settings.jsonの優先順位：同じ項目はどれが使われるか
同じ項目を複数の場所に書くと、Claude Codeは上の階層の値を使います。公式ドキュメントの順番は次のとおりです。
- 管理設定：会社が配る設定。原則として、自分の設定ファイルや起動時の指定では上書きできません
- 起動時の指定：
claude --settingsで渡した設定。その回のセッションだけ - プロジェクトの個人設定：
.claude/settings.local.json - プロジェクト共有設定：
.claude/settings.json - ユーザー設定：
~/.claude/settings.json
たとえば、自分のユーザー設定で作業中のヒント表示をオフにしていても、チームの.claude/settings.jsonでオンになっていれば、そのプロジェクトではヒントが出ます。自分だけ消したい時は、そのプロジェクトの.claude/settings.local.jsonに書けば、チームの人の設定は変わりません。
許可のルールのような一覧は合わさる
permissions.allowのように一覧で書く項目は、すべてのファイルに書いた内容が足し合わされて使われます。チームの許可ルールに、自分の許可ルールを足せるということです。ただし、モデルの一覧など一部の項目は、合わさらない例外として公式に挙げられています。
公式の権限のページによると、許可と拒否がぶつかった時は、どの階層に書いたかに関係なく、deny（拒否）が勝ちます。ユーザー設定で許可し、プロジェクト設定で拒否したコマンドは、拒否されます。逆に、ユーザー設定の拒否は、プロジェクト設定の許可より強く働きます。
環境変数とフラグは項目ごとに決まる
シェルで設定する環境変数は、上の順番とは別の扱いです（公式の環境変数のページ）。環境変数と設定ファイルのどちらが使われるかは、項目ごとに決まっています。たとえば、シェルでANTHROPIC_MODELを設定すると、どのファイルのmodelよりも優先されます。claudeコマンドの後ろに付けて起動する指定（フラグ）の--modelは、その回だけ環境変数よりも優先されます（会社の管理設定で使えるモデルが決まっている場合は、その中からだけ選べます）。設定を書いたのに別のモデルで始まる時は、環境変数やフラグも確かめてください。なお、settings.jsonの中のenvに書いた環境変数は普通の設定項目なので、上の順番に従います。
settings.jsonの書き方：3つの変え方
設定は、/configの画面、ファイルの直接編集、起動時の指定の3つの方法で変えられます。
/configの画面で変える
Claude Codeの中で/configと入力し、Configのタブを開きます。テーマや入力の操作方法など、よく変える個人の設定だけが並んでいて、すべての項目があるわけではありません。選ぶとClaude Codeが保存してくれます。保存先は、ほとんどの項目で~/.claude/settings.jsonです。/config verbose=trueのように、画面を開かずに1つだけ変えることもできます。/configはターミナル版の機能で、VS Codeのチャット欄やデスクトップアプリでは開けません。
ファイルを直接編集する
エディターで設定ファイルを開き、項目を書き足します。次は、公式の例をもとにした設定です。lint（コードの書き方の検査）とテストのコマンドを確認なしで実行させ、パスワードなどを入れる.envファイルは読ませません。
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"permissions": {
"allow": [
"Bash(npm run lint)",
"Bash(npm run test *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)"
]
}
}注意点は2つです。1つは、settings.jsonは厳密なJSONだということです。//のコメントや、最後の項目のあとのカンマがあると書式の誤りになり、次の起動時にエラーが出ます。もう1つは、1行目の$schemaです。この行を入れると、VS CodeやCursorなどのエディターで項目名の候補が出て、書き間違いをその場で知らせてくれます。ただし、項目名の候補の一覧（スキーマ）は、新しい項目に追いついていないことがあります。警告が出ても、設定が間違っているとは限りません。
保存した設定の多くは、Claude Codeを再起動しなくても、実行中のセッションに反映されます。権限やhooksの変更もそうです。一方、model（モデル）やeffortLevel（考える深さ）のように、起動時にだけ読む項目もあります。実行中に変えたい時は、/modelや/effortを使います。
その回だけ試す
ファイルを書き換えずに試したい時は、起動時に指定します。--settingsでJSONかファイルのパスを渡すと、その回のセッションだけ、ユーザー・プロジェクトの設定より優先されます（管理設定より下です）。
claude --settings '{"model": "claude-opus-5-5"}'--modelのように項目ごとのフラグや、ANTHROPIC_MODELのような環境変数でも、その回だけ変えられます。
settings.jsonの設定例：個人用とチーム用
公式ドキュメントの設定例のページには、個人・チーム・会社の3種類の設定例が載っています。公式は「おすすめの初期設定ではない」と断ったうえで、形の見本として示しています。必要な項目だけを写して使います。
個人用の~/.claude/settings.jsonの例
公式の個人用の例から、分かりやすい項目を抜き出しました。普段使うモデル、ヒント表示を消す設定、確認なしで実行してよい読み取りのコマンド（git diff）と、確認なしで読んでよいファイル（~/.zshrc）を書いています。
{
"model": "claude-sonnet-5",
"spinnerTipsEnabled": false,
"permissions": {
"allow": [
"Bash(git diff *)",
"Read(~/.zshrc)"
]
},
"autoUpdatesChannel": "stable",
"cleanupPeriodDays": 20
}autoUpdatesChannelは更新を安定版に絞る設定、cleanupPeriodDaysは手元の会話の記録などを何日で消すかの設定です。
チームで共有する.claude/settings.jsonの例
チーム用は、リポジトリの一番上の.claude/settings.jsonに置いてGitに入れます。公式の例から、権限の部分を抜き出すと次のとおりです。
{
"permissions": {
"allow": [
"Bash(npm run *)"
],
"ask": [
"Bash(git push *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)"
]
}
}allowは確認なしで実行、askは毎回確認、denyは拒否です。ただし公式ドキュメントは、ルールが止めるのは書いたとおりの形のコマンドだけだ、とも注意しています。たとえばRead(./.env)の拒否は、ファイルを名指しするcat .envは止めますが、フォルダー全体をgrep -rで検索するコマンドは止めません。公式のチーム用の例では、この穴をサンドボックス（コマンドの読み書きを制限する仕組み）の設定でふさいでいます。重要な情報を守る設定は、Claude Codeの情報漏洩対策の記事も参考にしてください。決まった時点で処理を動かすhooksも同じファイルに書きます。書き方はClaude Code hooksの記事で解説しています。
settings.jsonが読み込まれたか確かめる方法
保存したら、Claude Codeの中で/statusを実行します。StatusのタブにあるSetting sourcesの行に、今のセッションで読み込んだ設定ファイルの種類（ユーザー設定、プロジェクトの個人設定など）が並びます。会社の管理設定が効いている場合は、どの経路で届いたかも表示されます。
ただし、この行で分かるのは「どのファイルを読んだか」だけで、「どの項目がどのファイルから来たか」までは分かりません。そのほかの確認には、次のコマンドを使います。
| コマンド | 分かること |
|---|---|
/status | 読み込んだ設定ファイルの種類、管理設定が効いているか |
/permissions | 今効いている許可・拒否のルール |
claude doctor | ターミナルから実行。セッションを始めずに、設定ファイルの誤りや受け付けられなかった項目を表示する |
/doctor | セッションの中で実行。設定の誤りなどを調べ、直し方を提案する（直す前に確認がある） |
/hooks | 今のセッションで登録されているhooks |
設定ファイルが壊れている時の表示
設定ファイルにJSONの書き間違いや受け付けられない値があると、対話のセッションを始めた時に知らせてくれます。書式の誤りや受け付けられない値のせいでファイルを読み込めない時は「Settings Error」の画面が出て、Claudeと一緒に直す、終了する、壊れた設定なしで続ける、から選べます。一部の項目だけがおかしい時は「Settings Warning」が出て、その項目だけを飛ばし、残りの設定は効いたままになります。
claude -pのように画面を出さない実行では、壊れたファイルや項目を飛ばして処理が続きます。-pで設定が効いていないようなら、claude doctorで何が飛ばされたかを確かめてください。
settings.jsonが効かない時の確認
設定を書いたのに効かない時は、まず/statusで、そのファイルが読み込まれているかを確かめます。読み込まれているのに効かない時は、次の原因を順に確かめます。
上の階層で同じ項目が設定されている
別の設定ファイル、--settings、会社の管理設定のどれかが、同じ項目を上の階層で設定している可能性があります。会社の管理設定が決めている項目は、原則として自分では変えられません（モデルの初期値のように、会社が許す範囲で自分で切り替えられる項目もあります）。/statusで管理設定の経路を確かめ、変える必要があれば管理者に相談します。環境変数やフラグが項目を上書きしていないかも見てください。
そのファイルでは効かない項目を書いている
項目によっては、書ける場所が決まっています。たとえば、権限の初期モードを決めるpermissions.defaultModeのautoとbypassPermissionsは、プロジェクトの設定ファイルに書いても効きません。ユーザー設定か管理設定に書くか、その回だけなら--permission-modeで指定します（v2.1.257より前の版では、bypassPermissionsはどのファイルからでも効いていました）。各項目をどこに書けるかは、公式の設定項目の一覧の「Scope」の列で確かめられます。権限のモードについてはautoモードの記事でも解説しています。
チームの設定がほかの人に効かない
Gitで共有した.claude/settings.jsonのうち、permissions.allowの許可ルールや、ほとんどのenvの値は、それぞれの人がそのフォルダーを「信頼する」と答えるまで効きません。リポジトリに書かれた許可が、知らないうちに広がらないようにするためです。拒否（deny）と確認（ask）のルールは、信頼する前からすぐに効きます。
また、共有の.claude/settings.jsonは、Claude Codeを起動したフォルダーから読まれます。リポジトリの一番上に置いたファイルを使うなら、そのフォルダーで起動します。
「次回から聞かない」を選んだのにまた聞かれる
ターミナル版で許可の画面の「次回から聞かない」を選ぶと、自分の.claude/settings.local.jsonに許可のルールが保存されます（VS Code拡張では保存先を選べ、共有の設定ファイルを選ぶとチーム全員に効きます）。しかし、チームのプロジェクト設定や会社の管理設定に、同じコマンドのask（毎回確認）のルールがあると、自分の許可より確認が優先されます。/permissionsで効いているルールを確かめてください。
どの設定が原因か分からない時
原因を切り分ける時は、claude --safe-modeで起動します。CLAUDE.md、スキル、プラグイン、hooks、MCPサーバーなどの自分の追加設定を止めた状態でClaude Codeが動きます。認証、モデルの選択、権限は普段どおり働きます。会社の管理設定のうちhooksと設定の方針は効いたままですが、会社が配ったプラグイン、スキル、CLAUDE.md、MCPサーバーは止まります。問題が消えれば、止めたもののどれかが原因です。
自分の設定ファイルそのものを疑う時は、空のフォルダーで、設定のない状態から起動して確かめる方法が公式の不具合の調べ方のページに載っています。
mkdir -p ~/claude-clean/empty && cd ~/claude-clean/empty
CLAUDE_CONFIG_DIR=~/claude-clean/config claude --setting-sources user初回の設定画面がもう一度出れば、空の設定で起動できています。この方法でも、会社の管理設定は効いたままです。この状態で問題が消えれば、原因は自分のユーザー設定かプロジェクト設定にあります。
クラウドのセッションでは一部の設定しか読まれない
ブラウザから使うクラウドのセッションは、自分のパソコンではなく、リポジトリを新しく複製した別の環境で動きます。そのため、自分の~/.claude/settings.jsonと.claude/settings.local.jsonは読まれません。リポジトリが1つのセッションなら、Gitに入れた.claude/settings.jsonは読まれます（Claudeのプロジェクト機能のスレッドでは、権限ルールやhooksは読まれません）。会社の管理設定のうち、クラウドのセッションに届くのは、claude.aiの管理画面などからサーバー経由で配った設定だけです。パソコンに置いた管理設定ファイルは届きません（自分たちで用意した実行環境では、その環境に置いた管理設定ファイルも読まれます）。詳しくは公式のクラウドのセッションの説明にあります。
まとめ：settings.jsonは「誰に効かせるか」で置き場所を決める
Claude Codeのsettings.jsonは、自分のすべてのプロジェクト用、チーム共有用、プロジェクトの自分用、会社の管理用の4か所に置けます。同じ項目は上の階層が優先され、許可のルールのような一覧は合わさります。まず自分用の~/.claude/settings.jsonから小さく始め、チームで揃えたい権限やhooksだけを.claude/settings.jsonで共有すると、混乱が少なくなります。
効かない時は、/statusで読み込まれたファイルを確かめ、上の階層の設定、書ける場所の決まり、フォルダーの信頼、askのルールの順に確かめましょう。Claude Code全体のできることや使い始め方を確認したい方は、Claude Codeとは？できること・料金・利用環境の選び方から読み始めてください。
