Claude Codeの設定｜settings.jsonの場所・優先順位・書き方

「Claude Codeの設定はどこで変えるのか」「settings.jsonというファイルがあるらしいが、どこにあるのか」「プロジェクトごとに設定を変えたい」と迷っている方も多いのではないでしょうか。

Claude Codeの設定は、JSON形式の設定ファイルに書くか、画面の/configメニューで選ぶことで変えられます。設定できる内容は、起動時のモデル、確認なしで実行してよい操作、読ませたくないファイル、画面の見た目、会社として決める制限など、多岐にわたります。

この記事では、設定の変え方と設定ファイルの場所、同じ項目を複数の場所に書いたときの優先順位を整理します。そのうえで、よく使う設定項目、権限の設定、すぐ使える設定ファイルの例、反映されないときの確認方法まで順に解説します。内容は2026年10月時点の公式ドキュメントをもとにしています。

設定の変え方

Claude Codeの設定の正体は、「項目名: 値」の組み合わせを書いたJSONファイルです。変え方は3通りあります。

/configメニューで変える

Claude Codeの画面で/configと入力すると、設定画面が開きます。メニューに並ぶのは、テーマ、エディタモード、詳細表示（Verbose output）など個人向けの項目の一部で、設定ファイルの全項目ではありません。選ぶだけで、Claude Codeが適切なファイルに保存してくれます。

保存先は項目によって異なります。多くの項目は~/.claude/settings.json、ヒント表示（Show tips）のように一部の項目はプロジェクトの.claude/settings.local.json、そのほかは~/.claude.jsonに保存されます。/config verbose=trueのように、「項目=値」の形で直接渡すこともできます。

なお/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.*)"
    ]
  }
}

1行目の$schemaは、設定ファイルの書き方を定めた公式のスキーマを指す行です。これを入れておくと、VS Codeなど対応したエディタで、項目名の候補表示と書き方の検証が効きます。ただし、スキーマは最新版のClaude Codeに追いついていないことがあるため、新しい項目に警告が出ても、設定が間違っているとは限りません。

書き換えたら、Claude Codeの画面で/statusと入力して、ファイルが読み込まれているか確かめます。

起動時に一時的に指定する

保存せずに、そのセッションだけ別の値を試すこともできます。方法は3つあります。

• --settings：項目をJSONでそのまま渡すか、JSONファイルのパスを渡す。ユーザー・プロジェクト・ローカルの設定ファイルより優先される
• 項目専用のフラグ：モデルなら--model、effortなら--effortなど
• 環境変数：モデルならANTHROPIC_MODELなど、項目と対になる変数を起動前に設定する

これらは設定ファイルを書き換えません。次に起動したときは、元の設定に戻ります。

設定ファイルの場所

設定ファイルは、場所によって「誰に効くか」が決まります。公式ドキュメントでは、これを「スコープ」と呼んでいます。

表の~/.claudeは、ホームフォルダの中の.claudeフォルダです。Windowsでは%USERPROFILE%\.claude、つまりユーザーフォルダの中の.claudeフォルダを指します。保存場所を変えたいときは、環境変数CLAUDE_CONFIG_DIRで指定できます。

表のほかに、Claude Codeが自分用に書き込む~/.claude.jsonというファイルもあります。サインインの情報やMCPサーバーの設定、プロジェクトごとの状態などが入っているため、手で編集する必要はありません。

ファイルはどうやって作るか

Claude Codeをインストールしただけでは、設定ファイルは作られません。次のどれかのタイミングで作られます。

• /configでテーマなど、ユーザー設定に保存される項目を変えたとき（~/.claude/settings.json）
• 権限の確認で「Yes, and don't ask again」を選んだとき（.claude/settings.local.json）
• 自分でエディタから新規作成したとき

プロジェクトで共有する.claude/settings.jsonは、すでに誰かがコミットしていればそれを使い、なければプロジェクトのフォルダに.claudeフォルダを作って自分で用意します。

どのファイルに書くか

迷ったときは、「誰に効かせたいか」で選びます。

チームで共有する

.claude/settings.jsonをコミットすると、リポジトリをクローンした人全員に、同じ権限・フック・プラグインが届きます。各メンバーは、自分の.claude/settings.local.jsonで個別に上書きできるので、個人の例外のためにコミットする必要はありません。

ただし、共有の設定がそのまま全員に効くとは限らない点に注意してください。permissions.allowの許可ルールなどは、各メンバーがそのフォルダを信頼（workspace trust）するまで効きません。一方、deny（拒否）とask（確認）のルールは、すぐに効きます。

自分だけの設定を共有から外す

自分のためだけに設定を変えたいときは、プロジェクトの.claude/settings.local.jsonに書きます。Claude Codeがこのファイルを初めて書き込むとき、Gitの除外設定に自動で追加するため、コミットされません。手で作ったファイルの場合は、.gitignoreに自分で追加しておきましょう。

設定の優先順位

同じ項目が複数の場所に書かれているときは、いちばん優先順位の高い場所の値が使われます。高い順に並べると、次のとおりです。

つまり、範囲が狭く、自分に近い設定ほど優先される形です（管理設定だけは例外で、いちばん上に来ます）。ユーザー設定は、プロジェクトの設定に負けると覚えておくと分かりやすくなります。

リストは上書きされず、合わさる

permissions.allowのようなリストの項目は、上書きではなく結合されます。ユーザー設定とプロジェクト設定の両方に許可ルールを書くと、両方のルールが有効です。ファイルごとに足していけるので、ほかのファイルの内容を消す心配はありません。

ただし、モデルに関するリスト（fallbackModel、modelPicker、availableModels、modelSettings）は、それぞれ別のルールで扱われます。モデル関連の設定は、別の記事で詳しく解説しています。

環境変数とフラグの扱い

環境変数は、上の5段階には含まれません。項目と変数の組み合わせごとに、どちらが優先されるかが決まっています。たとえば、シェルで設定したANTHROPIC_MODELは、どの設定ファイルのmodelよりも優先されます。さらに--modelフラグは、その両方より優先されます。

設定ファイルの中のenvという項目は、環境変数をまとめて設定するための普通の項目で、上の5段階の順位に従います。

よくある上書きのパターン

チームの設定と自分の設定がぶつかったとき、どうなるかを表にまとめました。例として、spinnerTipsEnabled（作業中のヒント表示）を、自分はfalseにしているとします。

よく使う設定項目

公式の項目一覧には200を超える設定項目が載っていますが、全部を覚える必要はありません。ここでは、使う場面が多い項目を目的別に絞って紹介します。選び方は、当社が公式の項目一覧から整理したものです。全項目は公式の「All settings」で確認できます。

画面・操作

通知は、"auto"だと、iTerm2・Ghostty・Kittyではデスクトップ通知、それ以外の多くの端末では何も出ません。どの端末でも鳴らしたいときは、"terminal_bell"を指定します。

モデル・応答

languageに値を入れると、「その言語で常に答える」という指示になります。公式ドキュメントでは、値の確認はされないため、スペルを間違えてもエラーにならず、そのままClaudeに渡されると説明されています。

モデルの選び方、effort、高速モードなどの詳しい説明は、別の記事にまとめています。modelは、設定ファイルに書いても、セッション中に/modelで切り替えられます。

データ・履歴・Git

cleanupPeriodDaysで決めた日数を過ぎた記録は、起動後にバックグラウンドで削除されます。削除後は、/resumeの一覧にも出なくなります。長く残したいときは、大きな値（公式の例では3650）を入れます。

更新

更新に関する項目は次のとおりです。

• autoUpdatesChannel："latest"（最新版。未設定のときの動き）か、"stable"（通常は1週間ほど前の版で、大きな不具合のある版は飛ばす）を選ぶ
• minimumVersion：自動更新が入れるバージョンの下限を決める
• 自動更新そのものを止めたいときは、envの中でDISABLE_AUTOUPDATERを設定する

更新の確認と手動での更新方法は、別の記事で解説しています。

フックやMCPの設定

フックとMCPサーバーも、設定ファイルで管理します。それぞれ項目が多いため、別の記事にまとめています。

権限の設定

設定のなかでも、Claudeに何を確認なしでやらせ、何を禁止するかを決める権限の設定は、特に影響が大きい部分です。permissionsの中に、次の3種類のルールを書きます。

ルールはツール名(条件)の形で書きます。条件の*は、いくつかの文字の代わりになります。たとえばBash(npm run *)は、npm runで始まるコマンドすべてに当てはまります。

複数のルールに当てはまったときは、deny、ask、allowの順に評価され、最初に当てはまったルールで決まります。ルールの細かさは関係ありません。広い範囲のdenyがあれば、より狭いallowがあっても、実行は禁止されます。

起動時の動作モード

permissions.defaultModeで、新しいセッションがどのモードで始まるかを決められます。

"auto"と"bypassPermissions"は、プロジェクトの設定ファイルに書いても効きません。ユーザー設定か管理設定に書くか、起動時に--permission-modeで指定します。各モードの詳しい違いは、別の記事で解説しています。

権限の設定で気をつけること

サンドボックスは、Bashコマンドの実行範囲を、OSの仕組みで制限する機能です。既定はオフで、LinuxとWSL2ではbubblewrapとsocatが必要です。

また、確認の画面で「Yes, and don't ask again」を選ぶと、その操作の許可ルールが.claude/settings.local.jsonに保存されます。許可が増えすぎたと感じたときは、/permissionsで、いま有効なルールと、それが書かれているファイルを確認できます。

設定ファイルの例

ここまでの内容を組み合わせた、個人用とチーム用の例を紹介します。公式の設定例を参考に、本記事で説明した項目だけで組み立てました。そのまま貼り付けて使えますが、値は自分の環境に合わせて直してください。

個人用（ユーザー設定）

自分のすべてのプロジェクトに効く設定の例です。~/.claude/settings.jsonに保存します。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "model": "sonnet",
  "language": "japanese",
  "spinnerTipsEnabled": false,
  "preferredNotifChannel": "terminal_bell",
  "permissions": {
    "allow": [
      "Bash(git diff *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  },
  "autoUpdatesChannel": "stable",
  "cleanupPeriodDays": 30
}

この例では、モデルをSonnetにして、日本語で答えるように指定し、ヒントの表示を消して、完了時にターミナルのベルを鳴らします。差分の確認コマンドは確認なしで実行でき、.envファイルは読ませません。更新は安定版を追い、記録は30日で消えます。

チーム用（共有のプロジェクト設定）

チームで決めたルールを共有する例です。プロジェクトの.claude/settings.jsonに保存して、コミットします。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

npmのスクリプトは確認なしで実行でき、git pushの前には必ず確認が入ります。環境変数のファイルと、secretsフォルダの中身は読ませない設定です。

設定ファイルを作って確かめる手順

1. 置き場所を決める自分だけならユーザー設定、チームで共有するならプロジェクトの.claude/settings.jsonにします。迷ったら、個人のプロジェクト設定（.claude/settings.local.json）で試してから、共有に移します。
2. ファイルを作って書くフォルダがなければ作り、上の例を貼り付けて、必要な項目だけ残します。コメントや末尾のカンマが入っていないか確認します。
3. Claude Codeで確かめる保存すると、多くの項目は再起動なしで反映されます。/statusでファイルが読み込まれていることを、/permissionsで権限のルールを確認します。
4. 共有する場合はコミットするチーム用の設定は、コミットしてはじめてほかのメンバーに届きます。各メンバーには、フォルダを信頼する操作が必要な項目があることも伝えておきます。

設定ファイルは、Claude Codeが変更を監視しているため、多くの項目は保存するだけで、実行中のセッションにも反映されます。permissions、hooks、apiKeyHelperなども含まれます。一方、modelとeffortLevelは、実行中のセッションでは/modelや/effortで切り替えます。

設定が反映されないとき

書いた設定が効かないときは、原因がほとんどの場合、次のどれかです。ファイルが読み込まれていない、別の場所の設定が優先されている、そのファイルでは設定できない値だった、のいずれかです。

確認に使うコマンド

設定の確認には、次のコマンドが使えます。

設定ファイルのどの項目が拒否されたかは、claude doctorで分かります。/statusは「どのファイルを読んだか」を示しますが、「どの項目がどのファイルの値か」までは示さない点に注意してください。

原因が分からないときは、claude --safe-modeで、CLAUDE.md・スキル・プラグイン・フック・MCPサーバーなどをオフにして起動し、問題が消えるかを試します。消えれば、原因はオフにした項目のどれかです。

クラウド上のセッションで使われる設定

Claude Code on the webのようなクラウド上のセッションは、手元のパソコンとは別のマシンで動きます。そのため、読み込まれるのは、リポジトリにコミットされた.claude/settings.jsonだけです。手元の~/.claude/settings.jsonと.claude/settings.local.jsonは読まれません。クラウドでも使いたい設定は、共有のプロジェクト設定にコミットしておきます。

よくある質問

まとめ

設定は、一度に全部を整える必要はありません。まずは自分用のユーザー設定で、言語と通知、権限の拒否ルールだけを入れてみて、困った場面が出たら項目を足していくのがおすすめです。

チームや会社で使う段階では、共有する設定、権限のルール、管理設定をどこまでかけるかを決める必要があります。INTERCREATE JAPANでは、Claude Codeの導入から、社内ルールに合わせた設定づくり、使い続けられる仕組みづくりまでをお手伝いしています。