Claude Code の settings.json 設定ガイド｜場所・優先順位・permissions の書き方【2026年11月】

Claude Code の settings.json は、Claude Code の動き方（使うモデル、確認なしで実行してよいコマンド、読ませないファイルなど）を決める JSON 形式の設定ファイルです。 置き場所は自分用の ~/.claude/settings.json、チームで共有する .claude/settings.json、そのプロジェクトで自分だけに効かせる .claude/settings.local.json、会社が配る管理設定（managed settings）の4つで、同じ項目が複数の場所にあると、管理設定がいちばん強く、自分用の設定がいちばん弱くなります。

「どのファイルに書けば効くのか」「書いたのに効かない」でつまずく人が多いのは、この置き場所と優先順位、それに権限ルール（permissions）の書き方に独特の決まりがあるためです。たとえば、ユーザー設定に書いた Read(/secrets/**) はプロジェクトの secrets フォルダではなく ~/.claude/secrets/ を指しますし、プロジェクトの設定ファイルに "defaultMode": "bypassPermissions" と書いても効きません。

本記事では、2026年11月7日に取得した Claude Code 公式ドキュメント（Settings files and precedence・All settings・Configure permissions・Deploy managed settings）を原典に、設定ファイルの全体像をまとめます。公開時点の最新版は CHANGELOG 上で 2.1.319 です。手元の Claude Code 2.1.306 で実際に試した結果と、ドキュメントの記載から分かることは書き分けています。

結論：settings.json は「誰に効かせたいか」で置き場所を選ぶ

settings.json の置き場所は、その設定を「自分だけ」「チーム全員」「会社全体」のどこに効かせたいかで決めます。 迷ったときは次の4つを押さえれば足ります。

1. 自分の好みは ~/.claude/settings.json：モデル、言語、表示、すべてのプロジェクトで使う自分の権限ルールなど。パソコン上のすべてのプロジェクトに効きます
2. チームで揃えたいものは .claude/settings.json：プロジェクトのフォルダに置き、Git に含めて共有します。チームの権限ルール・hooks・環境変数など
3. そのプロジェクトでだけ自分の好みに変えたいものは .claude/settings.local.json：チームの設定を自分だけ上書きするときに使い、Git には含めません
4. 会社として守らせたいものは管理設定（managed settings）：情報システム部門などが配り、利用者の設定では上書きできません

優先順位は「管理設定 ＞ 起動時の --settings ＞ ローカル ＞ 共有プロジェクト ＞ ユーザー」です。ただし permissions.allow のようなリスト形式の項目は、上が下を消すのではなく、各ファイルの内容が足し合わされます。権限ルールは「deny（拒否）→ ask（確認）→ allow（許可）」の順に照合され、どこか1か所の deny に当たれば、他の場所の allow では解除できません。

Claude への指示文（CLAUDE.md）の書き方はCLAUDE.md の書き方で紹介しています。

settings.json とは｜CLAUDE.md・~/.claude.json との違い

settings.json は Claude Code という「道具」の動きを決めるファイルで、Claude（AI）に読ませる指示文ではありません。 似た名前のファイルが3つあるので、最初に役割を分けておきます。

公式ドキュメントは、権限ルールは Claude Code が強制するもので、AI が守るかどうかに左右されないと説明しています。逆に、CLAUDE.md に「.env は読まないで」と書いても、それは AI へのお願いであって、読み取りを技術的に止めるものではありません（出典: Configure permissions）。止めたいことは settings.json の deny ルールに、進め方の希望は CLAUDE.md に書く、と覚えておくと迷いません。

MCP サーバー（外部ツールとの接続）の設定は settings.json ではなく ~/.claude.json などに保存されます。接続のしかたは公式の MCP のページを参照してください。

インストールしただけでは settings.json は作られない

Claude Code をインストールしても、settings.json は1つも作られません。 公式ドキュメントによると、次のときに初めてできます。

• /config でテーマなどを変えたとき：~/.claude/settings.json が作られる
• 権限の確認で「Yes, and don't ask again（はい、今後は聞かない）」を選んだとき：.claude/settings.local.json が作られ、許可したコマンドが allow ルールとして保存される
• 自分で作ったとき：エディタで新しく作れば、そのまま読み込まれる

「settings.json が見当たらない」のは異常ではありません。必要な場所に自分で作れば大丈夫です。

settings.json の場所4つと、それぞれが誰に効くか

settings.json の置き場所は、ユーザー・共有プロジェクト・ローカル・管理設定の4種類で、置いた場所によって「誰に効くか」が決まります。

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

ローカル設定は Git に入らないように扱われる

.claude/settings.local.json は、Claude Code が初めて書き込むときに、Git の除外設定（全体の除外ファイル）へ **/.claude/settings.local.json を足してくれます。そのため、自分の許可ルールがうっかりチームに共有されにくくなっています。ただし、自分の手で作った場合は、Claude Code が一度書き込むまで除外されないので、.gitignore に自分で足しておきます。

また、Git で管理しているプロジェクトでは、ローカル設定はプロジェクトの一番上のフォルダ（リポジトリのルート）に置かれます（Windows や、ホームフォルダがルートになっている場合などは、共有設定と同じフォルダに置かれます）。サブフォルダで起動して「今後は聞かない」を選んでも、ルートの .claude/settings.local.json に保存され、プロジェクト全体に効きます。この扱いは v2.1.211 からで、それ以前は起動したフォルダに保存されていました。

共有プロジェクト設定は「起動したフォルダ」から読まれる

共有の .claude/settings.json は、Claude Code を起動したフォルダ（主な作業ディレクトリ）から読み込まれます。リポジトリのルートに置いた設定を使うなら、ルートで起動します。作業ディレクトリの考え方はClaude Code の作業ディレクトリと add-dirで詳しく扱っています。

クラウドで動かすときは読まれない設定がある

claude.ai/code などのクラウドのセッションは、手元のパソコンではなくクラウド上の環境で動きます。そのため、ユーザー設定とローカル設定は読まれません。Git に含めた共有プロジェクト設定と、claude.ai の管理画面から配る管理設定（server-managed settings）は届きます（複数のリポジトリを扱うセッションなど、例外があります）。クラウドでも効かせたい設定は、共有プロジェクト設定に入れておくのが基本です。

同じ項目はどれが勝つか｜優先順位とリストの足し合わせ

同じ設定項目が複数の場所にあるとき、Claude Code はいちばん上の段の値を使います。 公式ドキュメントが示す順番は次のとおりです（上ほど強い）。

1. 管理設定：会社が配る設定。利用者のどの設定ファイルでも、--settings でも上書きできない
2. コマンドライン：起動時に claude --settings '…' で渡した JSON。そのセッションだけ有効
3. ローカル設定：.claude/settings.local.json
4. 共有プロジェクト設定：.claude/settings.json
5. ユーザー設定：~/.claude/settings.json

公式ドキュメントの例で考えます。自分のユーザー設定で、作業中に出る小さなヒントを消す "spinnerTipsEnabled": false を書いたとします。チームの .claude/settings.json が true にしていれば、そのプロジェクトではヒントが出ます。共有プロジェクト設定のほうが上の段だからです。このとき自分だけ消したいなら、同じプロジェクトの .claude/settings.local.json に false を書けば、ローカル設定がさらに上の段なので、自分のセッションだけヒントが消えます。一方、会社の管理設定が true にしているなら、利用者側では元に戻せません。

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

permissions.allow や permissions.deny のようなリスト形式の項目は、上の段が下の段を消すのではなく、すべてのファイルの内容がまとめて使われます。 チームの設定で allow を5つ、自分の設定で allow を2つ書けば、7つ全部が効きます。hooks も同様にファイルをまたいで足し合わされ、管理設定の hooks は他のファイルから消せません。

例外として、モデルの順番を表す fallbackModel、モデル選択画面の行を決める modelPicker、会社が使えるモデルを限る availableModels など、モデル関係のいくつかの項目は独自の決まりで扱われます。気になる項目はAll settingsの各キーの説明を確認してください。

環境変数とコマンドの引数は別扱い

環境変数（シェルで export した値）は、この5段とは別の扱いです。たとえば ANTHROPIC_MODEL を設定していると、どのファイルの model よりも優先されます。さらに起動時の --model は、その両方より優先されます。一方で、settings.json の中の env ブロックに書いた環境変数は、ふつうの設定項目として5段の順番に従います。「settings.json で model を変えたのに切り替わらない」ときは、シェルに ANTHROPIC_MODEL が残っていないかを確かめます。

弱い段の「厳しい値」が勝つ例外

いくつかのセキュリティ関係の項目では、管理設定より下の段に書いた「厳しいほうの値」が採用されます。たとえば作業ディレクトリの外の読み取りを止める permissions.blockReadsOutsideWorkingDirectories は、どのファイルで true にしても、管理設定が false でも有効です（v2.1.257 以上）。会社の設定を緩める方向には働かず、締める方向にだけ働く、と考えると分かりやすいでしょう。

まず書く設定のコピペ例

最初は「自分用の settings.json に、よく使うコマンドの許可と、秘密情報を読ませないルールを書く」だけで十分です。 以下はすべて、そのまま保存できる JSON です。

settings.json は厳密な JSON なので、// のコメントや、最後の要素の後ろのカンマ（トレーリングカンマ）があると、ファイル全体が読み込めないエラーになります。手元の 2.1.306 で、最後にカンマを付けた .claude/settings.json を作って claude doctor を実行したところ、「Invalid or malformed JSON」と表示されました。

個人用：どのプロジェクトでも使う基本設定

~/.claude/settings.json に保存します。

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

• $schema の行を入れると、VS Code や Cursor などのエディタで、キー名の補完と書き間違いの警告が出ます。ただし公式ドキュメントによると、このスキーマは最新版に追いつくまで時間がかかることがあり、新しいキーで警告が出ても設定が誤りとは限りません
• language に "japanese" を入れると、Claude が日本語で返事をします。値は確認されずにそのまま Claude に渡されるので、つづりを間違えてもエラーにはなりません
• permissions の部分は、lint とテストのコマンドは確認なしで実行してよい、.env ファイルは読ませない、という意味です

チーム共有用：プロジェクトに置いて Git で共有する

プロジェクトの .claude/settings.json に保存し、Git に含めます。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  },
  "env": {
    "NODE_ENV": "development"
  }
}

npm のスクリプトとコミットは確認なし、プッシュ（共有先への送信）は毎回確認、.env と secrets フォルダは読ませない、という設定です。env には、このプロジェクトで Claude Code が動かすコマンドに渡したい環境変数を書きます。

ここで注意したいのは、共有プロジェクト設定の allow ルールは、各メンバーがそのフォルダを「信頼する」と答えるまで効かないことです。初めてそのフォルダで Claude Code を起動すると、フォルダを信頼するかを尋ねる画面（workspace trust）が出て、許可されるルールの一覧が表示されます。deny と ask は制限する方向なので、信頼の前から効きます。env の多くの値や、作業ディレクトリを広げる permissions.additionalDirectories も、信頼のあとで効きます。

個人の上書き：チームの設定を自分だけ変える

チームの設定が Sonnet を既定にしていて、自分だけ Opus を使いたい場合は、同じプロジェクトの .claude/settings.local.json に次のように書きます。

{
  "model": "claude-opus-5-5"
}

ローカル設定は共有プロジェクト設定より上の段なので、自分のセッションだけ切り替わり、チームのメンバーには影響しません。

permissions の書き方｜allow・ask・deny とルールの書式

permissions は、Claude Code がツールを使うときに「確認なしで許可する（allow）」「毎回確認する（ask）」「拒否する（deny）」を決める設定です。 照合の順番は deny → ask → allow で、最初に当たったものが結果になります。より細かいルールが優先されることはありません。

この順番のため、Bash(aws *) を deny にしていると、別のファイルに Bash(aws s3 ls) の allow を書いても実行できません。allow で deny に例外を作ることはできない、というのが公式ドキュメントの説明です。同じように、ask に当たれば、もっと細かい allow があっても確認が出ます。

ルールの書式

ルールは ツール名 または ツール名(条件) の形で書きます。

ファイルの書き込みを止めたいときは Edit(…) で書きます。公式ドキュメントによると、Write(docs/**) や Grep(docs/**) のようにパスを付けたルールは、書いても照合に使われません。書き込みは Edit(docs/**)、検索や一覧は Read(docs/**) で書き換えます。

* の位置で意味が変わる

* は「その場所に入る任意の文字」を表します。公式ドキュメントは、* はサブコマンド（git log の log の部分）の後ろに置くよう注意しています。

• Bash(git log *)：git log で始まるコマンドだけを許可する
• Bash(git *)：git のすべてのコマンドを許可する（push も削除系も含む）
• Bash(git * main)：git merge main だけでなく git push origin main にも当たる。サブコマンドの前に * がある allow ルールには、起動時に警告が出る
• Bash(ls *)：ls と ls -la に当たるが lsof には当たらない。Bash(ls*) と空白を消すと lsof にも当たる

また、Bash(git push *) を deny にしても、git -C . push のように書き方を変えたコマンドには当たりません。シェルコマンドのルールは文字列での照合なので、「止めたつもり」にならないよう、本当に止めたいことはサンドボックス（後述）と組み合わせます。

パスの基準は「/」の数で変わる

Read と Edit のルールのパスは、先頭の書き方で基準が変わります。ここは書き間違いがいちばん多いところです。

ユーザー設定に Read(/secrets/**) と書くと、プロジェクトの secrets ではなく ~/.claude/secrets/ を指します。 すべてのプロジェクトに効くルールをユーザー設定に書くなら、// の絶対パスか ~/ を使います。また、/Users/alice/file のように先頭が / 1つのパスは、絶対パスとは扱われない点にも注意してください。

なお、.claudeignore というファイルを置いても効果はありません。公式ドキュメントは、その内容を Read の deny ルールに移すよう案内しています。

Read の deny で止まるもの・止まらないもの

Read の deny ルールは、Claude のファイル読み取りツールに加えて、cat・head・sed など Claude Code が見分けられるシェルコマンドや、> file のようなリダイレクトにも適用されます。同じパスへの Edit と Write（新しく作ることも含む）も止まります（Write の確認は v2.1.228 以上）。

一方で、ファイル名を書かずに読むコマンド（そのフォルダでの grep -r パターン . など）や、Python・Node.js のスクリプトが中で開くファイルは止まりません。 すべてのプロセスからの読み取りを OS の仕組みで止めたいなら、サンドボックス（sandbox.enabled）を有効にします。サンドボックスは macOS・Linux・WSL2 で使え、シェルコマンドとその子プロセスのファイルと通信を制限する仕組みです。有効にする方法と、止まること・止まらないことはClaude Code のサンドボックスの記事にまとめました。公式のSandboxingも参照してください。

起動時の権限モード（defaultMode）

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

auto と bypassPermissions は、共有プロジェクト設定とローカル設定に書いても効きません（bypassPermissions は v2.1.257 から）。ユーザー設定か管理設定に書くか、起動時に --permission-mode で渡します。リポジトリに置かれた設定ファイルで、勝手に確認なしのモードにされるのを防ぐための決まりです。auto モードの仕組みと使いどころはClaude Code の auto モードで解説しています。

最初の allow ルールの決め方

allow ルールは「毎回聞かれて、毎回はいと答えているコマンド」から足していくのが安全です。 最初から Bash(git *) や Bash(npm *) のように広く許可すると、削除や送信のような取り消しにくい操作まで確認なしで通ってしまいます。

おすすめの進め方は次のとおりです。まずは何も allow を書かずに使い始め、確認の画面で「Yes, and don't ask again」を選んだコマンドが .claude/settings.local.json にたまっていくのを待ちます。1〜2週間たったら、そのファイルを開いて中身を見直し、チーム全員にとって安全なもの（テストや lint の実行など）だけを共有の .claude/settings.json に移します。取り消しにくい操作（プッシュ、デプロイ、ファイルの削除など）は、allow ではなく ask に書いておくと、うっかり許可済みにしてしまうことを防げます。

なお、ファイルの編集を「今後は聞かない」で許可しても、その許可はセッションが終わるまでしか続かず、ファイルには保存されません。シェルコマンドとページ取得（WebFetch）の許可は、リポジトリごとに保存されます。

設定ファイルを書かずに /permissions で管理する

Claude Code の中で /permissions を実行すると、すべての権限ルールと、それぞれがどの settings.json から来ているかが一覧で表示されます。ここから追加・削除もでき、作業の途中で変えても次のツール実行から反映されます（v2.1.234 以上）。JSON を直接書くのが不安な場合は、まずこの画面から始めるのが確実です。

よく使う設定キーの一覧

settings.json に書ける項目は数百ありますが、最初に使うのは一部です。 2026年11月7日時点の公式のAll settingsから、よく使うものをまとめました。「書ける場所」が「すべて」のものは、4か所のどこに書いても効きます。

hooks は書き方が長くなるので、公式の Hooks のページで、使えるきっかけ（イベント）の一覧と例を確かめてください。

手元で確かめた cleanupPeriodDays の注意

cleanupPeriodDays は会話の記録（/resume で開き直せる履歴）を何日残すかの設定で、既定は30日です。期限を過ぎた記録は、知らせなしに消されます。「消さないでほしい」つもりで 0 を書く人がいますが、0 は受け付けられません。手元の 2.1.306 で "cleanupPeriodDays": 0 を書いて claude doctor を実行すると、「1以上にすること、長く残すなら 3650（約10年）のような大きな数にすること」という趣旨の修正案が表示されました。以前は 0 がすべての記録の保存を止めてしまっていたため、拒否するようになったという説明も出ます。長く残したいときは 3650 のように書きます。

設定はいつ反映されるか

Claude Code は設定ファイルを見張っていて、ほとんどの変更は保存した時点で、動いているセッションに反映されます。permissions や hooks の変更も、再起動はいりません。ただし model と effortLevel はセッションの開始時にだけ読まれるので、途中で変えたいときは /model や /effort を使います。

会社で配る設定｜管理設定（managed settings）と情シスへの依頼文

会社として全員に守らせたいルールは、利用者の設定より強い「管理設定（managed settings）」で配ります。 管理設定は settings.json と同じ形の JSON で、届け方は次の4通りです。

ファイルで配る場合の置き場所は、OS ごとに次のとおりです。

• macOS：/Library/Application Support/ClaudeCode/managed-settings.json
• Linux・WSL：/etc/claude-code/managed-settings.json
• Windows：C:\Program Files\ClaudeCode\managed-settings.json

置いたあと、1台で Claude Code を起動して /status を実行し、「Setting sources」の行に Enterprise managed settings (file) と出れば、届いています。公式ドキュメントが示す最小の例は次のような内容です。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true
}

.env と secrets の読み取りを禁止し、確認なしで全部動かす bypass モードを使えなくし、さらに allowManagedPermissionRulesOnly で、利用者やプロジェクトの設定ファイルに書かれた権限ルールを無視させる設定です。最後の項目は管理設定でしか効かない項目の1つで、ほかにも hooks を会社の配ったものだけにする allowManagedHooksOnly などがあります。

なお、model を管理設定に書いても「最初に選ばれるモデル」が決まるだけで、利用者は切り替えられます。使えるモデルそのものを限りたいときは availableModels を使います。

管理設定で先に決めておくこと

管理設定に何でも入れると、利用者が自分の環境に合わせて調整できなくなります。管理設定には「破られると困ること」だけを入れ、使い勝手に関わることは共有プロジェクト設定に任せると、運用で困りにくくなります。

破られると困ることの代表は、秘密情報のファイルを読ませない deny ルール、確認なしのモードを使えなくする設定、使ってよいモデルの範囲、会社が認めた hooks や MCP サーバーだけを使わせる設定です。一方、どのテストコマンドを確認なしにするか、どの環境変数を渡すかはプロジェクトごとに違うので、各チームの .claude/settings.json で決めます。

また、管理設定のファイルが壊れていて JSON として読めない場合、Claude Code は起動を止めて、どのファイルが原因かを表示します。配る前に、1台で /status と claude doctor を確かめてから全体に広げると安心です。

情シスに頼むときの依頼文の例

社内で Claude Code を使い始めるとき、開発チームから情報システム部門へ頼む文面の例です。会社の事情に合わせて書き換えてください。

Claude Code（Anthropic 社の開発支援ツール）を開発チームで使うにあたり、全員の端末に共通の設定（管理設定）を配っていただけないでしょうか。設定は JSON ファイル1つで、macOS は /Library/Application Support/ClaudeCode/managed-settings.json に置きます。内容は「.env など秘密情報のファイルを読ませない」「確認を省く bypass モードを使えなくする」の2点です。利用者の設定では上書きできません。配布後は、1台で Claude Code の /status を実行し、設定が読み込まれたことを確認します。参考：https://code.claude.com/docs/en/managed-settings

設定が効かないときの確認手順

設定が効かないときは、まず /status で読み込まれたファイルを確かめ、次に claude doctor で書き方の誤りを探します。 原因はおおむね「ファイルが読まれていない」「上の段が同じ項目を決めている」「その場所では効かない項目」「JSON が壊れている」のどれかです。

/status で読み込まれたファイルを見る

Claude Code の中で /status を実行すると、Status タブの「Setting sources」の行に、そのセッションで読み込んだ設定ファイル（User settings、Project local settings など）が並びます。管理設定が効いていれば、その届き方も表示されます。ここに自分のファイルが出ていなければ、置き場所か起動したフォルダが違います。

ただし、この行は「どのファイルを読んだか」だけで、「どの項目がどのファイルから来たか」までは出ません。権限ルールの出どころは /permissions の一覧で確かめられます。

claude doctor で書き方の誤りを探す

ターミナルで claude doctor を実行すると、セッションを始めずに、壊れた設定ファイルや受け付けられなかった項目を一覧にしてくれます。セッションの中の /doctor は、修正案を出して直すところまで手伝ってくれます。

手元の 2.1.306 で、わざと誤りを入れた .claude/settings.json を用意して claude doctor を実行したところ、次の2つが「Invalid settings」として表示されました。

• MCP のツールにかっこ付きの条件を書いたルール（mcp__github__create_issue(repo:x)）：MCP のルールはかっこ付きの条件に対応していないので、かっこを外すよう案内され、そのルールだけ読み飛ばされた
• "cleanupPeriodDays": 0：1以上にするよう案内された

同じファイルに書いた "defaultMode": "bypassPermissions" は、この一覧には出ませんでした。公式ドキュメントのとおり、プロジェクト設定のこの値は「エラーではなく、効かない値」として扱われます。doctor に何も出ないのに効かない場合は、その場所に書けない項目ではないかを、キーの説明の「書ける場所」で確かめます。

よくある原因と直し方

それでも分からない場合は、公式のDebug your configurationが、設定を空にして試す手順などを案内しています。

状況別の読み分け早見表

やりたいことに合わせて、この記事のどこを読めばよいかをまとめました。

よくある質問

まとめ

• settings.json は Claude Code の動きを決める JSON ファイルで、置き場所はユーザー（~/.claude/settings.json）・共有プロジェクト（.claude/settings.json）・ローカル（.claude/settings.local.json）・管理設定の4種類です
• 優先順位は「管理設定 ＞ --settings ＞ ローカル ＞ 共有プロジェクト ＞ ユーザー」。ただし permissions.allow などのリストは足し合わされ、環境変数や --model は別扱いです
• 権限ルールは deny → ask → allow の順に照合され、deny に例外は作れません。* はサブコマンドの後ろに置き、ユーザー設定の /パス は ~/.claude/ 基準になる点に注意します
• 共有プロジェクト設定の allow ルールは、フォルダを信頼するまで効きません。auto と bypassPermissions はプロジェクト設定では効きません
• Read の deny はスクリプトの中からの読み取りまでは止めません。OS の仕組みで止めたいならサンドボックスを使います
• 会社として守らせたい設定は管理設定で配り、/status の「Setting sources」で届いたことを確かめます。効かないときは /status と claude doctor から調べます