Claude Code組織管理ガイド — managed settingsで統制する

Claude Code組織管理で何を統制できるか

Claude Codeを組織で配る段階になると、個人が~/.claude/settings.jsonをいじる話では済まなくなります。管理者設定(managed settings)は、ユーザー・プロジェクト・コマンドライン引数のどの設定よりも優先されます。権限、使えるモデル、起動できるバージョン、MCPサーバー、プラグインの取得元まで、開発者が自分では緩められない境界線を組織側から引けます。

統制の軸は大きく4つです。管理者設定をどの経路で端末に届けるか、モデル選択をどこまで縛るか、動くバージョンをどこで足切りするか、そして設定ファイルを配らずに管理コンソールだけで効かせられる制御は何か。権限やサンドボックスの境界設計はClaude Codeセキュリティ・権限ガイドに譲り、この記事はsettings.jsonの全フィールドを網羅する参照ガイドでもなく、組織導入の意思決定を1つずつ潰していく実務ガイドとして書いています。統制した後に「実際どれだけ使われているか」を可視化したい場合は、OpenTelemetryで利用量とコストを可視化するが対になる記事です。

管理者設定(managed settings)はどう配信すればいいか

配信経路は4つあり、Claude Codeは優先順位の高い順に中身のある設定を1つだけ採用します。マージはしません。

サーバー管理設定は認証時とセッション中1時間おきに再取得され、エンドポイント側の準備なしに配れます。ただしClaude for TeamsまたはEnterpriseプランが必要です。Bedrock・Google Cloud's Agent Platform・Foundryのようなサードパーティ経由では届かないため、Claude apps gatewayを立てるか、ファイルベースかplist/レジストリの経路に切り替えます。HKCUは管理者権限なしで書き換えられるので、統制の手段ではなく初期値の便宜としてだけ扱うのが安全です。

複数プロバイダーを併用している組織では、claude.aiユーザー向けにサーバー管理設定を設定しつつ、それ以外のユーザー向けにファイルベースをフォールバックとして併用する構成が実務的です。WSLはデフォルトでLinux側の/etc/claude-codeパスしか読みません。Windowsレジストリの内容をWSLにも及ぼすには、wslInheritsWindowsSettings: trueをHKLMまたはファイルベースの管理設定側に明示的に配る必要があります。

配信経路を決めたら、permissions.allow / permissions.denyのような配列項目はスコープをまたいでマージされる一方、fallbackModelとavailableModelsは最高優先度のソースが丸ごと置き換えることを覚えておいてください。開発者が個人設定に追加したモデルが黙って無視される事故は、この違いを知らないまま起きます。

モデル選択の許可リスト(availableModels)をどう運用するか

availableModelsは/model、--modelフラグ、ANTHROPIC_MODEL環境変数、サブエージェントやスキルのfrontmatter、フォールバックチェーンまで、モデルを指定できるほぼ全経路に効きます。ファミリー名(sonnet)、バージョンプレフィックス(claude-sonnet-4-5)、フルIDのいずれでもエントリを書けます。

{
  "availableModels": ["sonnet", "haiku"],
  "enforceAvailableModels": true
}

ここで見落とされやすいのがDefaultモデルの扱いです。availableModelsを設定しただけでは、モデルピッカーの「Default」はアカウント種別のランタイム既定値に解決され、許可リストの外側にあっても素通りします。Defaultまで縛るにはenforceAvailableModels: trueを同じ管理設定ソースに書く必要があります(Claude Code v2.1.175以降)。2つのキーは同一の管理設定ソースにまとめて配置してください。管理設定ソース間ではキーごとのマージが起きないため、ファイルベースに書いたペアが管理コンソール配信によって丸ごと無視される、という取りこぼしが起きます。

許可リストから外れた選択がどう扱われるかは、指定元によって変わります。/modelでの切り替えはエラーで拒否、--modelフラグやmodel設定は起動時に警告付きで許可モデルへ置き換え、サブエージェントの上書きはリードモデルへフォールバックします。ファミリーエイリアス(opus等)を許可した場合は、そのファミリー内で許可された最新版に解決される点も実務では効いてきます — 例えば["sonnet", "claude-opus-4-6"]と書くと、/model opusは最新のOpusではなく許可されたclaude-opus-4-6に解決されます。

配信面ごとの到達性も一様ではありません。管理コンソールからのサーバー管理設定はCLI・IDE・Desktop・Web/モバイル・クラウドセッション・Agent SDKまで届きますが、Coworkには設計上配信されません。逆にMDMやファイルベースの管理設定ファイルは、Anthropicホスト型のWeb/モバイル/クラウドセッションには届かず、セルフホスト環境でだけランナーイメージ側の設定として効きます。「クラウドセッションだけモデル制限が効いていない」という問い合わせの大半は、この面ごとの到達差が原因です。

バージョンの強制(requiredMinimumVersion)はどう設定するか

バージョン統制には性格の異なる2つのキーがあります。minimumVersionは自動更新とclaude updateがそれより下のバージョンをインストールするのを止めるフロアで、起動そのものは妨げません。対してrequiredMinimumVersionは起動を拒否する強制フロアです。実行中のバージョンがこれより古いと、Claude Codeは起動時点で終了し、組織が承認した更新手順に従うよう案内します。

{
  "requiredMinimumVersion": "2.1.150"
}

requiredMaximumVersionと組み合わせれば、許容バージョンの範囲そのものを管理設定側で決められます。ロールアウト直後の不具合を避けたい組織では、上限を設けて「まだ検証していない最新版には上げさせない」運用も可能です。

強制フロアにはフェイルオープン設計があります。不正な値が管理設定に混入した場合、Claude Codeはその値を無効として起動を許可します。ポリシー配信のタイプミス1つで組織全体のClaude Codeが起動不能になる、という最悪のシナリオを避けるための挙動です。ただしrequiredMinimumVersion自体が導入される前の古いバージョンは、このキーの存在を無視して起動してしまう点には注意してください。バージョン設定を変えたら、本番配信の前に必ずテスト機でclaude doctorを実行し、無効なエントリが無いかを確認します。

設定ファイルを配らずに制御できることは何か

ここまでのavailableModelsやrequiredMinimumVersionはいずれも設定ファイルやMDM経由で配る仕組みですが、Claude Enterpriseプランには管理コンソールだけで完結する制御が別に3つあります。設定を配信するインフラを持たない組織でも使えるのが特徴です。

• 組織のモデル制限: claude.ai管理コンソールで個別モデルを無効化。ユーザーのログインまたはAPIキー使用時にサーバー側が強制し、availableModelsとは独立に働きます。Haikuモデルだけは無効化できず、最低1つの使えるモデルが必ず残ります
• 組織の既定モデル: 組織全体、またはカスタムロールごとにDefaultモデルを指定できます。あくまで初期値で、--modelフラグやユーザー自身の/model選択の方が優先されます(一部組織向けの上書きオプションを除く)
• 組織のエフォート上限: カスタムロールごとにモデルごとの最大エフォートレベルを設定し、それを超える指定は上限に丸められます

これら3つはAnthropic APIまたはclaude.ai経由のセッションにのみ届き、Bedrock・Google Cloud's Agent Platform・Foundry・Claude Platform on AWSには届きません。それらのプロバイダーでモデルを制御するには、引き続きavailableModelsを管理設定ファイル側で使います。管理コンソール制御とavailableModelsは両方とも満たしたときだけモデルが選べる、という重ね掛けの関係にある点も忘れずに設計してください。

設定ファイル完全ガイドと組織管理ガイドはどう役割分担するか

Claude Code設定ガイドはsettings.jsonの全フィールドを辞書的に引くための記事で、個人からチームまでの設定を1本で扱います。この記事が扱うのは、その中でも組織が開発者に対して境界を強制するためだけの判断です。settings.jsonのフィールド1つ1つを知りたいときは前者を、管理者としてどの経路でどこまで縛るべきかを決めたいときは本記事を、という使い分けが実務的です。

導入の初期段階でつまずきやすいのは、availableModelsだけ設定してenforceAvailableModelsを忘れ、「許可リストを配ったのに一部のユーザーがDefaultで許可外のモデルを使えている」と報告が来るパターンです。もう1つは、requiredMinimumVersionをファイルベースの管理設定にだけ書き、管理コンソールからサーバー管理設定を並行配信している組織で、後から配ったサーバー管理設定に更新版キーが含まれていないため、ファイルベース側の値が丸ごと無視されるケースです。管理設定は「最高優先度のソース1つが勝つ」設計なので、統制したいキーは常に同じソースにまとめて配ることが事故を防ぐ最短経路になります。

よくある質問

managed settingsとCLAUDE.mdの管理者向け配布はどう違いますか

管理者設定は権限・モデル・バージョンのような振る舞いの制約を配るための仕組みで、CLAUDE.mdの管理ポリシーパスは全セッションに読み込まれる指示文を配るための別の仕組みです。両方とも個別設定で除外できない点は共通していますが、前者はJSONスキーマで検証され、後者はプレーンテキストとして毎回コンテキストに載ります。

管理設定に無効な値が混ざるとどうなりますか

キーごとに挙動が異なります。多くのキーはそのエントリだけがストリップされ、残りの有効な設定は執行されます。availableModelsやallowedMcpServersのようなセキュリティ関連キーは、値全体が不正だと空の許可リストとして扱われ、意図せず全モデル・全MCPサーバーが締め出されます。反対にrequiredMinimumVersionは不正時にフェイルオープンし、起動を止めません。配信前にclaude doctorでストリップされたエントリを確認する運用が必須です。

CoworkにもmanagedSettingsは効きますか

managed-settings.jsonのようなファイルベースの管理設定は、セッションが実行される場所にファイルが存在すれば適用されます。ただしサーバー管理設定(管理コンソール配信)はCoworkには設計上配信されません。リモートのCoworkセッションはAnthropic管理VM上で動くため、端末にファイルを配ってもそこには存在しない点にも注意が必要です。

バージョンの許可範囲はどのくらいの幅にするのが現実的ですか

明確な基準は公式に示されていませんが、requiredMinimumVersionで古すぎるバージョンの起動を止めつつ、requiredMaximumVersionは設けないか、社内検証が済んだ直近版まで緩めに取る運用が現実的です。上限を厳しくしすぎると、Anthropic側の新機能ロールアウトのたびに組織側の許可範囲更新が追いつかなくなります。

まとめ

Claude Codeの組織管理は、配信経路(サーバー管理が基本、それ以外はファイルベースで補完)・モデル制限(availableModels+enforceAvailableModels)・バージョン強制(requiredMinimumVersion)・管理コンソール限定の制御(モデル制限・既定モデル・エフォート上限)の4つを組み合わせて設計します。設定を配る前にclaude doctorで検証し、統制したいキーは同じ配信ソースにまとめておくことが、後からの「効いていない」問い合わせを減らす最も確実な方法です。