結論：設定ファイルは適用する相手で選ぶ
Claude Codeの設定ファイルは、誰に適用したいかで選びます。自分の全プロジェクトに適用する個人設定は~/.claude/settings.json、プロジェクトの利用者と共有する設定は.claude/settings.json、自分だけのプロジェクト別設定は.claude/settings.local.jsonに置きます。組織が強制するルールは、管理設定として別に扱います。
ファイルが存在することと、意図した設定が読み込まれ、想定どおりに働くことは別です。設定の適用範囲を決めてから変更し、読み込まれた設定元と実際の挙動を確かめます。
公式のSettings files and precedenceでは、ユーザー、共有プロジェクト、プロジェクト個人用、管理設定の適用範囲を分けています。個人設定はこの端末上の自分の全プロジェクトに、共有プロジェクト設定はそのファイルを含むフォルダーで作業する人に適用されます。
設定が増えて「どのファイルを直せばよいか分からない」ときは、適用範囲と読み込まれた設定元を見て選びます。
4つの設定場所を比較する
| 適用範囲 | 代表的な場所 | 使いどころ | 確認点 |
|---|---|---|---|
| 個人 | ~/.claude/settings.json | 自分の全プロジェクトで使う表示や権限 | 他の端末や利用者には自動では届かない |
| 共有プロジェクト | .claude/settings.json | チーム共通の権限、フック、プラグイン | 共有する前に差分と設定の影響をレビューする |
| プロジェクト個人用 | .claude/settings.local.json | そのプロジェクトでの個人的な上書きや試行 | Claude Codeが作成したファイルはGit対象外。手動作成時は.gitignoreを確認 |
| 組織管理 | managed-settings.json、管理コンソール、端末管理 | 組織が配布する安全規則やコンプライアンス要件 | 通常設定より優先。より厳しい下位設定が適用される場合あり |
プロジェクト設定を共有する場合は、ファイルをリポジトリへ登録して初めて他の利用者にも届きます。一方、プロジェクト個人用の設定を手で作る場合は、.gitignoreに追加して共有対象から外します。設定にAPIキー、OAuthトークン、Cookie、個人の端末パスなどの秘密値や個人情報を直接書かず、承認済みの保管先を使います。設定の共有範囲が広がるほど、秘密値の漏えい、端末ごとの差、CIでの失敗、変更担当の不明確さが増えます。
置き場所を決める3つの基準
- 誰に適用するか：自分の全プロジェクト、特定のプロジェクトの利用者、自分だけ、組織が管理する端末のどれかを決めます。
- 何を変えるか：表示、モデル、権限、フック、プラグインなど、変更する設定項目と目的を分けます。
- 誰が戻せるか：共有設定なら変更を確認する担当者と、元に戻す手順を決めます。個人用の試行でも、変更前の値を記録します。
たとえば、表示の好みは個人設定、チームで合意したフックや権限ルールは共有設定、検証中の個人用上書きはプロジェクト個人用が候補です。プロジェクトの環境変数を管理する際の注意点は、環境変数の安全な扱い方にまとめています。
権限ルールの優先順を確認する
権限ルールでは、deny（拒否）、ask（実行前に確認）、allow（確認なしで許可）の順に評価され、最初に一致したルールが結果を決めます。ルールを細かく書いても、この順序は変わりません。たとえば、広いBash(aws *)の拒否に一致する操作は、より狭いBash(aws s3 ls)の許可では例外にできません。
この順序は権限ルールの評価であり、設定ファイル同士の適用順と混同しないでください。許可・拒否の範囲を決めるときは公式の権限ルールと評価順を読み、必要に応じてClaude Codeの権限設定ガイドでルールの書き方を確認します。
安全に設定を変更する8手順
- 作業するプロジェクトとClaude Codeの実行環境を記録します。
- 変更する設定項目を一つに絞り、期待する動作を書き出します。
- 個人・共有プロジェクト・プロジェクト個人用・組織管理のどこに置くか決めます。
- 同じ項目を複数の設定ファイルで指定していないか調べます。必要なら、起動時に渡す
--settingsも確認します。 - 共有するファイルに秘密値や端末固有の値が含まれていないか確認します。
- JSONの構文、
.gitignore、変更差分を確認します。 - Claude Code内で
/statusを実行し、Setting sources欄（設定元）を確認します。 - 影響範囲を限定したテストで、意図した挙動を確かめ、必要なら元に戻す手順を記録します。
/statusで設定元を確認できても、ファイルがあるだけで期待する動作まで確定するわけではありません。権限やフックを変更した場合は、業務データを壊さない試験対象で一つずつ確かめます。設定元や反映を確認できない場合は、別のファイルを増やす前に、同じ項目の重複指定、JSONの誤り、組織管理の適用有無を調べます。
組織管理の設定は別に扱う
管理設定は、管理者が各端末へ配布する組織向けの設定です。managed-settings.jsonのほか、端末管理や管理コンソールなど複数の配布方法があります。ファイルで配布する場合の配置先は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が公式資料に示されています。
管理設定は通常のユーザー設定、プロジェクト設定、プロジェクト個人用設定、--settingsより優先されます。ただし一部の安全性に関わる項目では、下位の設定にあるより厳しい値も適用されます。配布後は一台で/statusを開き、Setting sources欄（設定元）に組織の管理元が表示されることを確認してから展開範囲を広げます。詳しくは公式の管理設定と配布方法と管理設定の診断ガイドを参照してください。
よくある質問
Claude Codeのsettings.jsonはどこに置けばよいですか？
自分の全プロジェクトなら~/.claude/settings.json、プロジェクトの利用者と共有するなら.claude/settings.json、自分だけのプロジェクト別設定なら.claude/settings.local.jsonです。組織が配布するルールは管理設定として扱います。
settings.jsonとsettings.local.jsonの違いは何ですか？
.claude/settings.jsonはプロジェクトで共有する設定、.claude/settings.local.jsonは自分だけがそのプロジェクトで使う設定です。
プロジェクト個人用の設定はGitへ登録できますか？
個人用設定は通常共有しません。Claude Codeが作成したファイルはGit対象外になります。手作業で作る場合は.gitignoreに追加し、秘密値や端末固有の値をリポジトリに残さないでください。
allowとdenyの権限ルールはどちらが優先されますか？
deny、ask、allowの順に評価され、最初に一致したルールが適用されます。細かい許可ルールで、より広い拒否ルールの例外は作れません。
管理設定が読み込まれたかどう確認しますか？
Claude Code内の/statusでSetting sources欄（設定元）を確認します。表示された設定元と、対象の設定の挙動を照らします。
ファイルがあるのに設定が反映されないのはなぜですか？
同じ項目の重複指定、JSON構文の誤り、組織管理設定の適用、起動中のセッションを順に確認します。/statusで設定元を確認し、影響を限定した非破壊テストを一つずつ実行してください。
公式資料
- Settings files and precedence（設定ファイルの適用範囲、読み込み、優先順位）
- Configure permissions（権限ルールとdeny・ask・allowの評価順）
- Deploy managed settings（組織管理設定の配布、優先、確認方法）
設定ファイルの整理と、業務にAIを導入する判断は別の検討事項です。Miraigentの無料診断では、対象業務の外注費削減の可能性と、AI利用料・保守費・社内確認費を含む実質削減額を整理します。