Claude Code managed settings 設計ガイド — permissions.deny と managed-mcp.json の組織配布

Claude Code をチームで使い始めたが、各メンバーのローカル設定に任せてよいのか。permissions.deny はどこに置くべきか。MCP サーバーを自由追加させてよいのか。ここが曖昧なまま運用を広げると、Claude Code は便利な開発支援ではなく、未承認コマンドと外部接続の抜け道になります。

この記事では、Claude Code の settings 公式ドキュメント、permissions 公式ドキュメント、MCP 公式ドキュメント、security 公式ドキュメントを前提に、組織配布で最低限決めるべき設定を整理します。Claude Code 全体の使い方から入りたい場合は Claude Code の使い方実践ガイド、CLAUDE.md だけでは足りない強制境界を補いたい場合は Claude Code Hooks の使い方実践ガイドを先に押さえると、この managed settings 記事の役割が見えやすくなります。

個人向けの便利設定ではありません。対象は、Claude Code を社内標準にしたい開発組織、MCP を配りたい基盤チーム、AI コーディングツールの利用ルールを実装に落としたい人です。全体方針から作る場合は、先に AIコーディングツールの社内ガイドラインと AIの組織利用ガイドを読んでください。MCP 側の認証主体や監査まで含めて設計したい場合は、この記事を MCP エンタープライズ運用ガイドと往復しながら読むのが実務では一番ずれにくいです。

読む順番の目安としては、まず Claude Code MCP ガイドで claude mcp add と承認境界を理解し、その次に本記事で managed-mcp.json と allowlist による固定配布へ進み、さらに認証主体の分離や監査まで広げる場合は MCP エンタープライズ運用ガイドを読むと役割分担がはっきりします。本記事は「MCP をどう追加するか」ではなく、「追加させる範囲をどう固定するか」に主眼があります。

先に結論: 管理者設定で守るのは3つだけ

Claude Code の managed settings で最初に守るべき境界は、次の3つです。

危険操作を止める: permissions.deny と allowManagedPermissionRulesOnly
MCP 追加を統制する: allowedMcpServers、deniedMcpServers、allowManagedMcpServersOnly
全員に同じ接続先を配る: managed-mcp.json

逆に、全部を中央管理しようとしない方がよいです。テーマ、表示設定、個人の通知、エディタの好みまで縛ると、現場は管理外の端末や個人契約に逃げます。

組織導入で必要なのは「快適さを最大化する設定」ではなく、事故ったときに説明できる最低限の境界です。

managed settings とは何か

Claude Code の通常設定は、ユーザー設定やプロジェクト設定に置けます。一方で managed settings は、組織管理者が配布する上位ポリシーです。公式ドキュメントでは、Claude.ai 管理画面、MDM / OS ポリシー、ファイルベースの managed-settings.json など複数の配布方法が説明されています。

重要なのは、managed settings はユーザー設定やプロジェクト設定で上書きできないことです。つまり、開発者の裁量に任せてよい設定と、会社として固定すべき設定を分けられます。

実務では、次のように分けると運用しやすいです。

種類	置き場	例
組織ポリシー	managed settings	秘密情報の読み取り禁止、MCP allowlist
プロジェクトルール	`CLAUDE.md` / `.claude/settings.json`	テストコマンド、レビュー方針、プロジェクト固有の作業手順
個人の好み	`~/.claude/settings.json`	通知、表示、個人用の軽微な許可

この分離がないと、CLAUDE.md にセキュリティルールを書いて満足する状態になります。CLAUDE.md はモデルへの指示としては有効ですが、強制力のあるポリシー境界ではありません。プロジェクトルールの設計は CLAUDE.md の設計パターン集で整理していますが、組織統制は managed settings に寄せるべきです。

permissions.deny は「最後の安全網」ではなく最初に置く

Claude Code は read-only を基本にし、編集やコマンド実行時に許可を求める設計です。ただし、チーム運用では「毎回人が判断するから大丈夫」と考えない方がいいです。承認疲れが起きると、危険な操作も流れで通ります。

組織で最初に入れるべき deny は、次のような操作です。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl * | bash)",
      "Bash(wget * | sh)",
      "Bash(git push --force*)",
      "Bash(rm -rf /)",
      "Bash(npm publish*)"
    ]
  }
}

この例はそのまま全社配布するものではありません。狙いは、秘密情報、外部取得スクリプトの即時実行、破壊的 git 操作、公開操作を最初からレビュー不能な状態にしないことです。

ここで大事なのは、deny を「便利機能の制限」ではなく「組織の非交渉領域」として扱うことです。プロジェクトごとに許可してよい操作は変わりますが、.env の読み取りや未知スクリプトのパイプ実行を自由化する理由はほぼありません。

allowManagedPermissionRulesOnly を使う判断基準

allowManagedPermissionRulesOnly は、ユーザー設定やプロジェクト設定から allow、ask、deny の権限ルールを定義できないようにする managed settings 専用の設定です。

これを最初から全社有効にすると、現場の小さな改善まで止まります。一方で、規制産業や機密コードを扱う組織では、開発者がローカルで allow を広げられる状態は弱いです。

私なら次の基準で分けます。

組織状態	推奨
小規模チーム、導入検証中	まだ使わない。`deny` だけ管理者配布する
複数部署に展開中	高リスクリポジトリだけ有効化する
金融、医療、個人情報、規制対応	最初から有効化を検討する

大事なのは、これを「セキュリティが強いから常にオン」と雑に決めないことです。Claude Code の価値は、現場がプロジェクトごとの検証コマンドや作業フローを素早く調整できる点にもあります。締めるなら、代わりに申請と例外配布の導線を用意してください。

MCP は managed-mcp.json と allowlist を分けて考える

MCP の組織配布では、2つの仕組みを混同しない方がいいです。

managed-mcp.json: 管理者が MCP サーバー構成そのものを配る
allowedMcpServers / deniedMcpServers: どの MCP サーバーを読み込んでよいかを制限する

managed-mcp.json がある場合、ユーザーは claude mcp add や設定ファイルで自由に MCP サーバーを追加できません。つまり、固定配布の仕組みです。一方で allowlist / denylist は、名前、コマンド、URL パターンで読み込み可否を絞る仕組みです。

私なら、全社初期導入では managed-mcp.json を使います。理由は単純で、最初に必要なのは自由度ではなく棚卸し可能性だからです。

{
  "mcpServers": {
    "github-readonly": {
      "type": "http",
      "url": "https://mcp.company.example/github"
    },
    "docs-search": {
      "type": "http",
      "url": "https://mcp.company.example/docs"
    }
  }
}

ここで stdio サーバーを安易に配らない方がよいです。stdio はローカルコマンド実行そのものが境界になります。npx -y some-mcp-server を自由に許すと、MCP サーバー追加が未承認コード実行に近くなります。MCP の企業運用全体は MCP エンタープライズ運用ガイドで詳しく書いていますが、Claude Code 側ではまず配布経路を固定してください。

allowedMcpServers は名前だけにしない

allowedMcpServers は serverName、serverCommand、serverUrl で制限できます。ここで失敗しやすいのが、名前だけの allowlist です。

{
  "allowedMcpServers": [{ "serverName": "github" }]
}

この設定は読みやすいですが、stdio サーバーではコマンド制限になりません。公式ドキュメントでも、コマンドエントリがない場合は、同じ名前の stdio サーバーが任意コマンドで通る挙動が説明されています。

remote MCP を標準にするなら URL で絞る方が明確です。

{
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.company.example/*" },
    { "serverUrl": "https://*.internal.example/*" }
  ],
  "deniedMcpServers": [{ "serverName": "filesystem" }]
}

stdio を許可するなら、名前ではなくコマンドを固定します。

{
  "allowedMcpServers": [
    {
      "serverCommand": ["node", "/opt/company-mcp/approved-server/index.js"]
    }
  ]
}

この粒度まで決めないなら、MCP はまだ全社展開しない方が安全です。

allowManagedMcpServersOnly は「自由追加を止める」設定ではない

allowManagedMcpServersOnly は、managed settings の allowedMcpServers だけを尊重する設定です。ユーザーは MCP サーバーを追加できても、管理者が定義した allowlist に合わないものは読み込まれません。

ここは誤解しやすいです。完全固定にしたいなら managed-mcp.json を使う。現場追加の余地を残しつつ、接続先を制限したいなら allowManagedMcpServersOnly を使う。役割が違います。

私なら次の3段階で導入します。

固定配布: managed-mcp.json だけで read-only ツールを配る
許可制追加: allowedMcpServers と allowManagedMcpServersOnly で社内ドメインだけ許可する
例外運用: チームごとの追加は申請し、managed-settings.d/ のような分割配布で管理する

最初から「各チームで自由に MCP を追加してよい」にすると、後から棚卸しできません。MCP は接続先が増えるほど価値が出ますが、組織では接続先が増えるほど監査対象も増えます。

実務で使う最小構成

初期導入なら、私は次のような構成から始めます。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl * | bash)",
      "Bash(wget * | sh)",
      "Bash(git push --force*)",
      "Bash(npm publish*)"
    ]
  },
  "allowedMcpServers": [{ "serverUrl": "https://mcp.company.example/*" }],
  "deniedMcpServers": [{ "serverName": "filesystem" }],
  "allowManagedMcpServersOnly": true
}

これで守れるのは、次の範囲です。

秘密情報ファイルを Claude Code が読む事故を減らす
危険なパイプ実行や公開操作を止める
MCP 接続先を社内ドメインに寄せる
個人が任意の remote MCP を足しても読み込まれないようにする

これでも完璧ではありません。プロジェクト内の通常ファイルに秘密情報が混ざっていれば読めますし、許可済み MCP サーバー側の権限が過大なら事故ります。Claude Code の managed settings は、開発統制の一部であって、データ分類、SaaS 権限、監査ログを置き換えるものではありません。

Auto Mode と混ぜるときの注意

Auto Mode を使う場合でも、managed settings の permissions.deny は重要です。Auto Mode はアクションのリスクを分類しますが、組織として絶対に許可しない操作は分類器の判断に委ねるべきではありません。

考え方は単純です。

permissions.deny: 組織として禁止する操作
Auto Mode: 日常操作の承認疲れを減らす仕組み
CLAUDE.md: プロジェクトの作業方針を伝える文書
Hooks: 実行前後に検証や通知を挟む仕組み

Auto Mode の設定やチーム導入の考え方は Claude Code Auto Mode 解説に分けています。managed settings 記事では、分類器に任せない境界を明確にすることを優先します。

ロールアウト手順

いきなり全員に厳格な設定を配ると、開発体験が壊れます。段階的に進める方が失敗しません。

1. 現状棚卸し

まず、各チームが何を許可しているかを見ます。

.claude/settings.json
.claude/settings.local.json
.mcp.json
個人の ~/.claude/settings.json
MCP サーバーの実行コマンドと接続先

この棚卸しなしに managed settings を配ると、普段の作業が急に止まります。

2. deny だけ先に配る

最初は permissions.deny だけで十分です。秘密情報、危険コマンド、公開操作を止める。これで大きな事故の確率を下げつつ、現場の自由度は残せます。

3. MCP を read-only から固定配布する

次に managed-mcp.json で read-only な MCP サーバーだけ配ります。GitHub 参照、ドキュメント検索、社内ナレッジ参照のような用途から始めるのが堅いです。書き込み系、デプロイ系、DB 操作系は後回しにします。

4. 例外申請を作る

最後に、チーム固有の MCP や追加許可をどう申請するか決めます。ここを用意しないと、現場は設定を迂回します。

最低限、申請には次を書かせるとよいです。

追加したい MCP サーバー名
remote URL または stdio コマンド
必要な権限
読み取り専用か書き込みありか
監査ログの保存場所
代替手段がない理由

よくある失敗

失敗1: CLAUDE.md に禁止事項だけ書く

CLAUDE.md に「.env を読まないで」と書くのは悪くありません。ただし、それは強制ではありません。禁止操作は permissions.deny に入れてください。

失敗2: managed-mcp.json だけで安心する

固定配布しても、配った MCP サーバー自体が過大権限なら危険です。MCP サーバー側の OAuth scope、サービスアカウント、監査ログも同時に見ます。

失敗3: stdio を名前だけで許可する

名前だけでは実行コマンドの固定になりません。stdio を許すなら serverCommand で実体を固定してください。

失敗4: denylist だけで運用する

denylist は既知の危険を止めるには有効ですが、未知の MCP サーバーや未知の URL を止めるには allowlist の方が向いています。組織配布では、denylist より allowlist を主にした方が説明しやすいです。

まとめ

Claude Code の managed settings は、細かい便利設定を配るための機能ではありません。組織として譲れない境界を、ユーザー設定やプロジェクト設定より上位で固定するための仕組みです。

最初にやるべきことは多くありません。

permissions.deny で秘密情報と危険操作を止める
MCP は managed-mcp.json で read-only から配る
remote MCP は serverUrl、stdio MCP は serverCommand で絞る
allowManagedMcpServersOnly は自由追加を残したい段階で使う
CLAUDE.md、Auto Mode、Hooks と managed settings の役割を混ぜない

Claude Code を組織で安全に使うコツは、AI を信用しすぎないことではありません。信用してよい範囲を設定ファイルで狭く、明確に、棚卸し可能にすることです。