はじめに

前回の記事で、「ルールは善意で守られるもので、設定は強制されるもの」という話を書きました。今回はその「強制」の中身である managed settings を、実務でどう設計するかの話です。

ご相談を受けていると、「利用ガイドラインは作ったんですが、守られている自信がない」という声をよく聞きます。実際にユーザーにヒアリングするとガイドラインは読んでいない、さらにはガイドラインがあることを知らなかったというケースもあります。

ガイドラインは(読んで欲しいけど)読まれない前提でガードレールのような仕組みが必要です。

managed settings は、そのガードレールにあたる仕組みです。管理者が決めた設定を、ユーザー側では上書きできない形で Claude Code に適用できます。この記事では、配り方の選択と、最初に何を強制するかを整理します。導入を任された情シス担当者の方の参考にしてもらえると幸いです。

強制する仕組み

Claude Code の設定は何層かに重なっていて、同じ項目がぶつかったときは強い層が勝つ、という作りになっています。弱い方から並べると次の順です。

  1. ユーザー個人の設定
  2. プロジェクト(フォルダ)の設定
  3. 起動時のコマンドライン引数
  4. 管理設定（managed settings）← 最強

たとえば同じ項目をユーザー設定とプロジェクト設定の両方に書いた場合、使われるのはプロジェクト側の値です。そして管理設定は、この階層の一番上にいます。

つまり管理設定に書いた内容は、ユーザーが自分の設定ファイルをどういじっても、起動時にどんなフラグを付けても、覆せません。

ここで大事なのは、1〜3の層はどれもユーザー自身の手で書き換えられる、ということです。

会社がセットアップ手順書やスクリプトで「この設定で使ってください」とユーザー設定を整えてあげることはできますが、それはあくまで初期値（推奨設定）で、ユーザーが後から変えられてしまいます。管理設定の層に置いて、はじめて書き換えられない強制になります。前回の記事で「推奨設定だけ配って統制した気になっているケースがある」と書いたのは、この違いの話です。

配り方は2通り — 管理画面 or MDM

managed settings の配り方は大きく2つあります。

  • サーバー管理設定: Claude の管理画面（Admin Settings > Claude Code）に設定のJSONを登録しておく方式。組織のアカウントでログインした Claude Code が、起動時とその後1時間ごとに設定を自動で取りに来ます
  • エンドポイント管理設定: Jamf や Intune などのMDMで、設定ファイルやOSのポリシー（macOSの構成プロファイル、Windowsのレジストリ）を端末に直接配る方式

なお、MDMがなくても、管理者権限で保護された場所（macOSなら /Library/Application Support/ClaudeCode/ など）に設定ファイル（managed-settings.json）を直接置く方法もあります。エンドポイント管理設定の亜種という位置づけで、キッティング時にスクリプトで仕込む、といった使い方ができます。ただし本人がローカル管理者権限を持つ端末では書き換えられてしまうので、MDMでポリシーとして継続的に管理する方式より保証は一段落ちます。

どちらを選ぶかの判断軸は、実はシンプルです。

  • MDMが入っていない、または管理外の端末が混ざる → サーバー管理設定。MDMのような端末側への配布の仕込みが要らないのが最大の強みです
  • MDMで端末を管理できている → エンドポイント管理設定。設定ファイルがOSレベルで保護されるので、保証としてはこちらの方が強いです（なおブラウザ版の Claude Code にはエンドポイント管理設定が届かないため、併用する場合はサーバー管理設定も検討してください）
  • 部署ごとに設定を変えたい → 現状はMDM一択です。サーバー管理設定は組織の全ユーザーに一律で適用される仕様で、グループ別の出し分けにはまだ対応していません

なお両方を設定した場合、2つは原則マージされません。サーバー管理設定が配信されていればそちらが使われ、なければエンドポイント側が効く、という動きです。「MDMで基本を配りつつ、一部だけ管理画面で上書き」のような合わせ技はできないので、どちらを正とするかは最初に決めておいてください。

最初に入れる設定は3つで十分

managed settings で設定できる項目はかなり多いのですが、最初から作り込む必要はありません。事故につながる穴を塞ぐという観点だと、初期セットはこの3つです。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true
}
  • 読ませないファイルの指定（permissions.deny）: APIキーや認証情報が入りがちな場所を、そもそも読めなくします。前回の記事で「線引きの表を作りましょう」と書きましたが、その「絶対ダメ」の行を機械的に裏付けるのがここです
  • 権限バイパスの封じ込め（disableBypassPermissionsMode）: Claude Code には確認プロンプトを全部スキップする起動方法があり、便利な反面、統制上は一番の抜け道になります。組織として封じておくのが無難です
  • 権限ルールの追加禁止（allowManagedPermissionRulesOnly）: 権限ルールを管理設定で定義したものだけに限定します。管理設定の deny 自体はユーザー側から覆せませんが、これを入れないと、deny に書いていない操作をユーザーが自分の allow ルールで確認なしに通せる状態が残ります。統制の主導権を管理側に置くための設定です

運用が回り始めてから、MCPサーバーの許可リスト、利用できる最低バージョンの指定、操作を記録するフックあたりを次の一手として足していく、という順番がおすすめです。（最初から全部盛りにすると、何が原因で動かないのか切り分けられなくなります）

ガードレールも完全ではない

ここは正直に書いておきたいのですが、managed settings は万能ではありません。公式ドキュメント自身が「クライアント側の制御であって、セキュリティ境界ではない」と明言しています。

実務で押さえておきたい隙間は3つです。

  • 初回起動の空白: サーバー管理設定は起動時に取りに行くため、取得が終わるまでのごく短い間、設定が当たっていない状態が生まれます。ここが許容できない環境向けに、取得に失敗したら起動させない設定（forceRemoteSettingsRefresh）が用意されています
  • 経路によっては届かない: Amazon Bedrock などサードパーティのクラウド経由で使う構成では、サーバー管理設定は配信されません。この構成の会社は、MDMによるエンドポイント管理が前提になります
  • 古いクライアント: managed settings に対応する前のバージョンの Claude Code は、そもそも設定を取りに来ません。最低バージョンの強制（requiredMinimumVersion）とセットで考えてください

要するに、managed settings 単体で統制が完結するわけではなく、端末管理やアカウント統制と組み合わせて初めて機能する、という位置づけです。玄関に鍵を掛けても、窓が開いていれば入れてしまうのと同じですね。

一度自分で回してみる

設定を全社に流す前に、テスト端末での確認を挟んでください。やることは難しくありません。

  • 設定を当てた端末で claude doctor を実行し、設定が正しく読めているかを見る
  • /status でどの管理ソース（サーバー管理／エンドポイント管理）が効いているかを確認する
  • /permissions で、意図した権限ルールが実際に当たっているかを確認する

特に deny リストは、書き方を間違えると「効いていると思っていたのに効いていなかった」が起きやすい場所です。禁止したはずのファイルを読ませようとして、ちゃんと断られるかまで見ておくと安心です。

あとは、設定を変えたら記録を残すこと。管理設定の変更は、各ユーザーの次回起動や定期更新のタイミングで全員に波及していくので、「いつ・誰が・何を・なぜ変えたか」は変更管理として残しておいてください。ISMSを運用している会社なら、既存の変更管理プロセスにそのまま載せれば大丈夫です。

おわりに

前回のチェックリスト記事の4番と5番（設定の強制・配布方法）を、実際に手を動かすところまで掘り下げました。まとめると、

  • MDMがなければ管理画面から、部署別にしたければMDMから
  • 最初の強制は「読ませない・バイパスさせない・足させない」の3点
  • ただしガードレールにも隙間はあるので、端末管理・アカウント統制とセットで

という設計です。なお、この領域は機能の追加・変更がかなり速いので、実際に設定を組む際は必ず最新の公式ドキュメントを確認してください。

自社の構成だとどの配り方が正解か、deny リストに何を入れるべきか、といった個別の設計を相談したい方は、生成AI・Claude Codeの社内統制支援のページをご覧ください。環境をお伺いした上で、設定の中身までご一緒に設計しています。

参考リンク