managed-settings.d/（マネージド・セッティングズ・ディー）

会社で複数チームのClaude Code設定をまとめて配りたいIT管理者向け

会社で全社員のClaude Codeに強制ルールを配るとき、設定の入れ物は長いこと managed-settings.json という1ファイルだけでした。セキュリティ係も分析係もコンプラ係も、同じ1ファイルを編集することになります。誰かが上書きして他チームの行を消す、編集が衝突する、レビューが面倒になる。managed-settings.d/ は、この「1ファイルを取り合う」問題をなくすための仕組みです。

ざっくり言うと、1ファイルに全部押し込む代わりに、フォルダの中に小分けの設定ファイルをいくつも放り込めるようにしたものです。

そもそも managed-settings.d/ って何のこと？

managed設定は「会社が社員のClaude Codeに上から強制する設定」です。個人がどう書こうと、これが最優先で勝ちます。その配り方には2通りあります。

1つは昔からある managed-settings.json という1ファイル。もう1つが今回の主役、managed-settings.d/ というフォルダです。末尾の .d/ はフォルダだという目印で、Claude Code v2.1.83 から使えるようになりました。

このフォルダの中に *.json（拡張子が .json のファイル）を何個でも入れておくと、起動時に全部まとめて読まれます。これがあれば、セキュリティ係は自分用のファイル、分析係は自分用のファイル、と別々に置けます。誰も他人のファイルを触らなくていい。これが地味に効きます。

大事な前提：このフォルダは「managed-settings.json と同じ場所」に並べて置く

置き場所は個人のホームフォルダではありません。パソコン全体の管理用フォルダ、つまり managed-settings.json を置くのと同じ場所に managed-settings.d/ を並べて置きます。ここはOSによって違います。

macOS なら /Library/Application Support/ClaudeCode/ の中。Windows なら C:\Program Files\ClaudeCode\ の中です。Linux と WSL の場合は、etc という名前のフォルダの下にある claude-code/ の中になります（フルの場所は先頭にスラッシュが付く形）。

OS共通だと思い込むと、置いたのに読まれない事故になります。ここは最初に確認しておきたいところ。

「料理ブログ運営会社」を例に、実際の手順を見る

料理ブログを運営する会社のIT管理者になったつもりで進めます。セキュリティ係と分析係、それぞれの強制設定を1つのファイルに混ぜず、別々に配るのが目標です。

ステップ1: managed-settings.d/ フォルダを作る

まず、managed-settings.json と同じ場所に managed-settings.d/ という名前のフォルダを作ります。macOS ならこうです。

$ sudo mkdir -p "/Library/Application Support/ClaudeCode/managed-settings.d"

先頭の sudo は「管理者として実行する」という宣言です。システム用の場所は管理者でないと書き込めないので、これが要ります。

ステップ2: 分析係の断片を 10-telemetry.json として置く

分析係は「利用状況の記録をオンにする」設定を配りたいとします。これを 10-telemetry.json という名前で作ります。先頭の 10- は順番を決めるための番号です（理由は後で出てきます）。

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1"
  }
}

ステップ3: セキュリティ係の断片を 20-security.json として置く

セキュリティ係は「危ないコマンドを禁止する」設定を配りたいとします。これは別ファイル 20-security.json として置きます。分析係のファイルには一切触りません。ここが .d/ 方式の気持ちいいところ。

{
  "permissions": {
    "deny": ["Bash(rm -rf:*)"]
  }
}

ステップ4: 読まれる順番を理解する

Claude Code は起動時に、まず土台として managed-settings.json を読みます。次に managed-settings.d/ の中の *.json を名前のアルファベット順に並べ、上から順に重ねていきます。

今回は 10-telemetry.json → 20-security.json の順。数字の 10- 20- を頭に付けたのは、この順番を自分で決めるためです。番号を空けておくと、あとで 15- を割り込ませる余地も残せます。

ステップ5: 隠しファイルは無視されることを知っておく

ここで初心者がやりがちな勘違いがあります。「編集中だから」と .20-security.json のように先頭にドットを付けて退避させたつもりが、実は読まれません。先頭が . で始まるファイルは丸ごと無視される決まりだからです。逆に言えば、一時的にオフにしたい断片はドットを付ければ安全に外せます。

ステップ6: 重なった結果を確認する

2つの断片は別の設定項目（分析の記録と、コマンドの禁止）なので、ぶつからずに両方とも有効になります。Claude Code を起動して、利用状況の記録がオンになり、なおかつ rm -rf 系のコマンドが拒否されれば成功です。

これで、2チームが互いのファイルを一切触らずに、それぞれの強制設定を配れました。レビューもチームごとに分かれて回せます。

つまり managed-settings.d/ は何をしてくれるのか

• やってくれる: 1つのフォルダに小分けの設定ファイルを複数置かせて、起動時に全部まとめて読み込む。チームごとに断片を分けて配れる
• やってくれない: ファイル名から自動で意味を判断したりはしない。読む順番は名前のアルファベット順で決まるだけ。順番を効かせたいなら自分で番号を振る
• 意味が薄い場面: 設定を配るチームが1つしかない個人や小規模の場合。managed-settings.json 1ファイルで足りる

マージのされ方は型で変わる（ここが一番ハマる）

「後から読まれたファイルが常に全部勝つ」と思い込むと痛い目を見ます。実際は値の型によって合わさり方が3通りに分かれます。表にするとこうです。

禁止コマンドのリストは「上書き」ではなく「足し算」になる、というのが大事なところです。各チームが禁止したいコマンドを別々のファイルに書いても、全部合算されて効きます。これは正直よくできてると思います。

使いどころ3シナリオ（具体題材で再現）

シナリオ1: 料理ブログ運営会社で部門ごとに係が分かれているとき

セキュリティ係・分析係・コンプラ係が別々の人で、それぞれ配りたい設定が違う。1ファイルに全部書くと、誰かの編集が他の人の行を巻き込んで壊します。10-telemetry.json 20-security.json 30-compliance.json と係ごとにファイルを分ければ、各係が自分のファイルだけ責任を持てます。レビューも係単位で完結します。

シナリオ2: ECサイト運営会社が全社員のPCに一括配布するとき

家電ECを運営していて、社員300人のClaude Codeに同じ強制設定を配りたい。1台ずつ手で設定するのは現実的ではありません。Claude Code公式は Jamf / Intune / Group Policy 向けの配布テンプレートを用意しています。これでMDM経由で全台に managed-settings.d/ を配れます。管理者が1回設定すれば、新しく入った社員のPCにも自動で乗ります。

シナリオ3: 既存の managed-settings.json を壊さずに新ルールを足したいとき

レシピ動画の制作会社で、すでに managed-settings.json が運用中。ここに「新しい禁止コマンドを1つ足したい」だけのとき、既存ファイルを直接いじると事故が怖い。managed-settings.d/ に 50-extra-deny.json を1枚足すだけで済みます。禁止コマンドは配列なので足し算で合算され、既存の設定はそのまま残ります。試しに外したくなったら、そのファイルにドットを付けて隠せばオフにできます。

初心者が踏みやすい落とし穴

• managed設定は1ファイルだけだと思い込む。managed-settings.json の隣に managed-settings.d/ を置けば、*.json を何枚でも分けて配れます。チーム分割の基本はこちら
• 読まれる順番が適当だと思う。まず managed-settings.json が土台、その上に .d/ の中身を名前のアルファベット順で重ねます。順番を効かせたいなら 10- 20- の番号を頭に付けて自分で決める
• 後のファイルが常に全部勝つと思う。後勝ちはスカラー（1つの値）だけ。配列は連結して重複を除き、オブジェクトは深い階層まで合体します。型で挙動が違うのが要注意
• 個人の設定で managed を上書きできると思う。たいていの設定、たとえば model のような1つの値は managed が最優先で、社員が自分の settings.json に逆を書いても勝てません。ただし許可・拒否ルールだけは例外で、次の項目のとおりマージされます
• 許可・拒否ルール（permissions）も managed が全部上書きすると思う。公式は「permission rules はスコープをまたいで、上書きではなくマージ（合算）される」と明記しています。permissions.allow / permissions.deny は managed・project・user の分が足し合わさって効くので、ここだけは「1つの値の設定」と挙動が違います
• 先頭にドットを付けたファイルも読まれると思う。. 始まりは無視されます。これは「一時的にオフにする」手段として逆に使えます
• どのOSでも置き場所が同じだと思う。macOS・Windows・Linux で場所が違います。3つとも本文の「大事な前提」で確認してから置く
• 拡張子が .json 以外でも読まれると思う。.d/ の中で読まれるのは *.json だけ。メモ用に .txt を置いても設定としては効きません

書き方

<システム用のフォルダ>/managed-settings.d/10-telemetry.json
<システム用のフォルダ>/managed-settings.d/20-security.json

やってみるとこうなる

入力

# macOSの場合、フォルダを作って断片を2枚置く
sudo mkdir -p "/Library/Application Support/ClaudeCode/managed-settings.d"
# 10-telemetry.json と 20-security.json をその中に保存

出力例

起動時に managed-settings.json を土台として読み、次に managed-settings.d/ の中の *.json を名前のアルファベット順（10-telemetry → 20-security）に重ねる。スカラーは後勝ち、配列は連結して重複を除去、オブジェクトは深い階層まで合体。先頭が . のファイルは無視。managed は全スコープ中で最優先なので個人の設定では覆せない

関連項目

• settings.json（セッティングス・ジェイソン）
• .claude Directory（ドット・クロード・ディレクトリ）
• Sandboxing（サンドボックス）
• /permissions（パーミッションズ）

公式ドキュメント

https://code.claude.com/docs/en/settings