Claude Codeのmanaged settings｜企業で上書き不可の設定を分ける方法

企業導入で最初に分けたいのは、設定ファイルの場所ではなく「誰が変更できるべきか」です。2026年8月24日確認時点の公式ドキュメントでは、ユーザー、共有プロジェクト、プロジェクトローカル、managedというスコープが示されています。共有プロジェクトはチーム設定、プロジェクトローカルはそのプロジェクトだけの個人設定、managedは組織のセキュリティポリシーやコンプライアンス要件に使う位置付けです。

したがって実務上は、全社で解除させない禁止・コンプライアンス要件をmanaged、リポジトリを利用するチームの標準を共有プロジェクト、同じプロジェクト内でも共有しない個人差をプロジェクトローカル、どの案件にも共通する個人嗜好をユーザー設定へ置きます。保存せず一度だけ試す変更はCLIです。これは公式の各スコープ用途をもとにした配置判断であり、設定キーがそのスコープに対応するかは個別確認が必要です。

同じキーが複数箇所にある場合、2026年8月24日確認時点の基本優先順位は次の並びです。ここでprojectは二層あり、個人用のプロジェクトローカルが、チームで共有するプロジェクト設定より上にあります。CLIの--settingsは一つのセッションにだけ適用され、設定ファイル自体を変更しません。

【高】managed settings → CLI（1セッション）→ project local → shared project → user【低】

配置フローに直すと、「全社強制か？」がYesならmanaged、「一時検証か？」がYesならCLI、「チーム共有か？」がYesならshared project、「特定プロジェクト内の個人差か？」がYesならproject local、それ以外の個人嗜好はuser、となります。managedは原則として下位レベルやCLIから上書きできませんが、公式には少数のsecurity-sensitive exceptionsが明記されています。そのため「managedなら例外なく絶対」とは扱いません。

また、環境変数はこの優先順位スタックの独立した段ではありません。対応する設定キーとの関係は組み合わせごとに決まります。図へ一律に足さず、キーごとに公式仕様を確認してください。公式に単純な上書き規則が示されていないキーやリストについても、種類ごとに公式仕様を確認するのが安全です。

permissionsでは、ファイルの優先順位だけを見て設計すると誤解が生じます。2026年8月24日確認時点の公式仕様では、権限ルールはdeny、ask、allowの順で評価され、最初に一致した結果が使われます。どのスコープにあるdenyも、別スコープのallowより先に評価されます。つまり下位スコープで禁止を追加することはできますが、managedなど上位にある禁止をallowで解除する設計にはできません。

全社で外せない禁止事項はmanagedのdeny等へ置き、チーム側には必要な範囲の追加ルールを置く、という役割分担が基本です。さらに管理者は、allowManagedPermissionRulesOnlyで権限ルールをmanaged由来に限定する構成や、permissions.disableBypassPermissionsModeで権限バイパスを無効化する構成を選べます。これらは強い統制になるため、対象キーの現行仕様と必要性を確認して採用します。

allow・ask・denyの書き分けはClaude Codeのpermissions解説に譲り、本記事では「禁止をどこへ置くか」に集中します。重要なのは、通常キーの優先順位と、権限ルールの評価順を同じものとして扱わないことです。

permissions.allowのような同じリスト型キーは、通常、最上位の配列だけを残すのではなく、複数レベルの配列を結合します。このため、上位ファイルへ同名リストを書けば下位の値が消える、と考えるのは危険です。fallbackModelとavailableModelsには別ルールがあることも公式に示されています。

ここまでをレビューするときは、①通常の同一キーなら基本優先順位、②リストなら結合規則、③permissionsならdeny→ask→allow、④managedでもsecurity-sensitive exceptions、という四つの確認欄を分けます。キーやリストの種類ごとに公式仕様を確認し、単純な順位が公式に書かれていないものを推測で補わないでください。

設定の目的も併記すると運用しやすくなります。たとえば「全社禁止なのでmanaged」「チーム標準なのでshared project」のように、置き場所と変更権限の理由をセットにします。将来設定を移す際にも、単なるファイル整理ではなく統制範囲の変更としてレビューできます。導入時の論点全体は企業向けClaude Code導入ガイドも参照してください。

managed settingsの配信手段には、claude.ai管理コンソールまたはself-hosted gatewayによるserver-managed、macOS plistやWindows registryなどのOSポリシー、所定のシステムパスに置くmanaged-settings.jsonがあります。ただし、複数の配信手段を用意すれば内容がすべて合成されるとは限りません。

2026年8月24日確認時点では、managed tier内で少なくとも一つのpolicy keyを配信する最初のソースが選ばれ、server-managed、plist/HKLM、ファイルベース、Windows HKCUの順で確認されます。原則としてmanagedソース同士はマージされません。移行期に新旧の配信元を並存させる場合は、どちらが選ばれるかを前提に設計します。

適用中の設定ソースはClaude Code内の/statusにあるSetting sourcesで確認できます。ただし、この表示だけでは各キーをどのファイルが供給したかまでは分かりません。配信元、設定内容、端末側の確認結果を切り分け、期待するソースが読み込まれたかを検証してください。

実装前には、設定を「組織の禁止」「チーム標準」「プロジェクト内の個人差」「全案件の個人嗜好」「一時検証」に分類します。次に配置図へ当てはめ、各キーが対象スコープで利用できるか、リスト結合か、permissionsの評価対象か、managedの例外に関係するかを公式リファレンスで確認します。最後に/statusで設定ソースを確認し、想定した禁止が下位のallowで解除できないことや、共有設定が意図した範囲にだけ届くことを検証します。

Cotomuでは、2026年8月24日確認時点の案内として、導入研修30万円／回、導入パッケージ50万円〜、伴走顧問月15万円〜、初回60分無料相談を用意しています。料金・内容は公開前または相談時に最新情報をご確認ください。導入成果や効果を保証するものではなく、CotomuはAnthropicの公式パートナーであることを示すものでもありません。