🛡️ 技術調査 - Claude Code 企業配布の3層分離と managed settings 強制

この記事は 2026-06 時点の Claude Code 公式ドキュメント（settings / server-managed-settings / IAM / permissions / zero-data-retention 等）を一次情報として検証した技術調査です。

■概要

Claude Code は Anthropic が提供する CLI 形式の AI コーディングツールです。ファイル削除・本番環境変更・外部ネットワーク通信など、開発環境に対して広範な操作権限を持ちます。個人利用であれば柔軟性が価値になりますが、企業組織に配布するとき、その柔軟性はそのままリスクになります。

企業展開の本質的な課題は「誰が使えるか」「何を許可するか」「どんな使い方を配るか」という 3 つの問いが、それぞれ異なる仕組みで答えを持つ点にあります。これらを混同すると統制が機能しません。

Claude Code のガバナンス設計は、この 3 つの問いを層ごとに分離して管理する「3 層分離モデル」として整理できます。

3 層分離モデルの全体像

基本原則を一言で表すと次のようになります。

「道具は Starter Kit で配り、境界線は managed settings で強制する」

①②は技術的に強制できる層です。③はユーザーが編集できる推奨層であり、強制したい統制を③に置くと無効化されます。本調査は、この 3 層をどう分離し、②をどう強制するかを構造・データ・構築・利用・運用の観点で整理します。

Starter Kit 単体アプローチの限界

Starter Kit（③層）は、ワンコマンドで標準化された開発環境をセットアップするツールです。標準エージェント・コマンド・CLAUDE.md・安全網スクリプトを一括配布し、チーム全体の使い方を統一します。

しかし Starter Kit のファイルはユーザーが編集できます。ローカルの settings.json や .claude/ 以下の設定は、ユーザーが書き換えれば即座に無効化されます。Starter Kit は「推奨する使い方」を配布できますが、「外せない境界線」を強制できません。

アプローチ別比較

server-managed settings は MDM 不要で利用でき、Claude for Teams/Enterprise プランで利用可能です。ユーザーが組織の認証情報でログインすると、Anthropic のサーバーから自動的に設定が配信されます。MDM 管理デバイスでは endpoint-managed settings（macOS plist・Windows レジストリ・managed-settings.json）が OS レベルの改ざん保護を加えます。

■特徴

Starter Kit でできること

• ワンコマンドによる初期セットアップ（macOS / Windows 対応）
• 標準化されたエージェント（security-reviewer・architect 等）の配布
• 標準コマンド（/plan・/tdd 等）の配布
• CLAUDE.md によるコーディングルールの統一
• 安全網スクリプト（Safety Net）による自動検査の組み込み
• 新メンバーのオンボーディング加速

Starter Kit でできないこと

• 会社管理アカウントでのログイン強制（①層が担当）
• 個人 Claude アカウントへの切り替え禁止（②層が担当）
• MCP サーバーの組織的な制御（②層が担当）
• 全社ログ収集・監査（OpenTelemetry・Compliance API が担当）
• permissions・hooks の強制適用（②層が担当）

managed settings の特徴

• 優先度が最高: ユーザー設定・プロジェクト設定・コマンドライン引数でも上書きできません
• 複数の配信方式: server-managed settings（管理コンソール経由）・MDM/OS-level policy・ファイルベースから選択できます
• リアルタイム更新: permissions・hooks は再起動不要で即時反映されます。起動時フェッチ＋約 1 時間間隔のポーリングで取得します
• Managed-only 設定: allowManagedPermissionRulesOnly・allowManagedMcpServersOnly・forceLoginOrgUUID など、managed からのみ有効な設定キーが存在します
• フェールクローズ対応: forceRemoteSettingsRefresh: true を設定すると、設定フェッチ失敗時に CLI が起動を拒否します

個人アカウント切替が引き起こす問題

ユーザーが組織アカウントから個人の Claude Pro/Max に切り替えると、以下の影響が生じます。

• server-managed settings の配信対象外になります
• managed permissions・hooks・MCP 制御の強制が外れます
• 組織の監査ログ・billing 集計から外れます
• データ保持ポリシーが Consumer 条件（モデル改善対象になり得る）に切り替わります

この問題は単なる課金回避ではなく、監査・保持・MCP 制御の境界そのものが変わるという本質的なリスクを持ちます。forceLoginOrgUUID を managed settings に設定すると、組織外アカウントでのログインを技術的にブロックできます。ただし管理者権限を持つユーザーに対する完全な保護には MDM との組み合わせが必要です。また Amazon Bedrock / Google Vertex AI / Microsoft Foundry 経由で接続した場合、server-managed settings は配信されません。

■構造

設定の優先順位・配布経路・強制の仕組みを「論理アーキテクチャ」として C4 の 3 段階で表現します。具体的な製品インフラではなく、ガバナンス機構の構造を描きます。

●システムコンテキスト図

ガバナンス機構本体と、それに関わる外部アクター・外部システムの関係を示します。

要素説明

●コンテナ図

ガバナンス機構を構成する主要コンテナとその責務・相互依存を示します。

プロビジョニング層

ポリシー強制層

標準環境配布層

設定解決エンジン

テレメトリ 監査

●コンポーネント図

各コンテナのドリルダウンです。実ファイル名・実チャネル名を含みます。

server-managed settings 経路

endpoint-managed settings 経路（macOS MDM）

endpoint-managed settings 経路（Windows GPO - Intune）

endpoint-managed settings 経路（ファイルベース）

ユーザー プロジェクト層

MCP 制御コンポーネント

パーミッション制御コンポーネント

認証 強制コンポーネント

●設定解決フロー図

スコープ優先順位にしたがって、最終的な有効設定を決定するフローを示します。

設定解決フロー 要素説明

■データ

このガバナンス設計が扱うエンティティを、概念モデルと情報モデルで表現します。

●概念モデル

●情報モデル

■構築方法

前提条件: プランと機能の対応

プランと最小バージョンの対応は更新されるため、https://code.claude.com/docs/en/server-managed-settings の現行記載を正とします。

SSO / ドメインキャプチャのセットアップ

SCIM を使う前に SSO の設定が必要です。

1. IdP 側の設定: Okta / Microsoft Entra ID / Google Workspace / OneLogin / JumpCloud 等に対し Anthropic の SAML アプリを設定します（追加 IdP は WorkOS 経由で対応します）。
2. ドメイン検証: 管理コンソールで組織ドメインを登録し、DNS TXT レコードで所有権を証明します。
3. 必要な権限:

JIT / SCIM プロビジョニングのセットアップ

前提: SSO 設定とドメイン検証が完了していること。

Organization settings > Organization and access で以下から選択します。

SCIM 設定手順（Enterprise / Console のみ）:

1. Organization and access 画面で「Setup SCIM」をクリック
2. WorkOS セットアップガイドに従い IdP を設定
3. WorkOS が生成する SCIM エンドポイント URL とトークンを IdP の Anthropic アプリに入力

• Primary Owner ロールは SCIM の自動調整から除外されます。
• プロビジョニング前に十分なシート数が必要です。

managed-settings.json の配置先（OS 別）

ドロップイン（managed-settings.d/）のマージ動作:

1. managed-settings.json をベースとして読み込みます
2. managed-settings.d/*.json をアルファベット順にマージします
3. スカラー値は後のファイルが上書きします
4. 配列は連結し重複排除します
5. オブジェクトはディープマージします
6. . で始まる隠しファイルは無視します

/etc/claude-code/
  managed-settings.json     # ベース
  managed-settings.d/
    10-telemetry.json       # テレメトリ設定
    20-security.json        # セキュリティポリシー
    30-mcp-policy.json      # MCP ポリシー

server-managed settings（管理コンソール配信）の有効化

MDM インフラが不要な配信方法です。ユーザーが認証した際に Anthropic サーバーから自動取得されます。

1. 管理コンソールで Admin Settings の Claude Code セクションを開く
2. JSON で設定を入力（settings.json と同じキーが使用可能）
3. Save で保存
4. クライアントは次回起動時、またはポーリングで設定を取得

設定例:

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "forceLoginOrgUUID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

制限事項:

• 組織全ユーザーに一律適用します（グループ別設定は未対応）。
• managed-mcp.json はサーバー配信できません（MDM またはファイルベースで配布します）。

managed tier 内の優先順位（公式 server-managed-settings の記載）:

• server-managed settings と endpoint-managed settings は、ともに設定階層の最上位 tier を占めます。CLI 引数を含む他のどのスコープでも上書きできません。
• managed tier 内では「最初に非空の設定を返したソースが勝つ」方式です。最初に server-managed settings を確認し、次に endpoint-managed settings を確認します。
• ソースはマージされません。server-managed settings がキーを 1 つでも返すと、endpoint-managed settings は完全に無視されます。server-managed settings が何も返さない場合に endpoint-managed settings が適用されます。
• endpoint-managed の内部（plist / レジストリ / managed-settings.json ファイル）の優先順位は公式に明示されていません。

server-managed の設定を管理コンソールで消して endpoint-managed（plist / レジストリ）へフォールバックする際は、クライアントのキャッシュ（~/.claude/remote-settings.json）が次回フェッチ成功まで残る点に注意します。/status で現在有効な managed ソースを確認できます。

MDM 配布テンプレート

公式テンプレート: https://github.com/anthropics/claude-code/tree/main/examples/mdm

Windows のレジストリは HKLM\SOFTWARE\Policies\ClaudeCode の Settings 値（REG_SZ）に JSON 文字列を格納します。ユーザーレベルの HKCU\SOFTWARE\Policies\ClaudeCode は最低優先で改ざん耐性が弱くなります。

Linux は構成管理ツールでファイルを配置します。

# Ansible タスク例
- name: Deploy Claude Code managed settings
  copy:
    src: managed-settings.json
    dest: /etc/claude-code/managed-settings.json
    owner: root
    group: root
    mode: '0644'

requiredMinimumVersion の指定

クライアントの最小バージョンを強制します。条件を満たさない場合は起動をブロックします。

{
  "requiredMinimumVersion": "2.1.150",
  "requiredMaximumVersion": "2.1.200"
}

■利用方法

主要 managed settings キー一覧

permissions の deny / ask / allow 記法

優先順位: deny → ask → allow の順に評価し、最初のマッチが結果を決定します。

スコープをまたいだマージ: 全スコープ（managed / local / project / user）の allow・ask・deny 配列は union でマージされます。managed の deny はユーザーレベルの allow で上書きできません。

{
  "permissions": {
    "deny": [
      "Bash(sudo *)",
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/secrets/**)",
      "Read(~/.ssh/**)"
    ],
    "ask": [
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(npm run test *)",
      "Bash(npm run lint *)"
    ]
  }
}

ツールパターン記法:

allowManagedPermissionRulesOnly: true を設定すると、managed settings 以外（user / project / local）の allow・ask・deny 定義が無視されます。

disableBypassPermissionsMode: "disable" は bypassPermissions モード（--dangerously-skip-permissions フラグ相当）を禁止します。permissions ブロック内に置きますが、全スコープで有効です。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

hooks（PreToolUse / PostToolUse）

PreToolUse フックの command が非ゼロの終了コードを返すと、対象ツールの実行をブロックできます。実行時の設定変更を監視するには ConfigChange フックで変更を記録し、適用前にブロックします。

設定例:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/usr/local/bin/validate-bash.sh"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "/usr/local/bin/audit-edit.sh"
          }
        ]
      }
    ]
  }
}

HTTP フックを使う場合は許可 URL を明示します。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "http",
            "url": "https://hooks.example.com/audit"
          }
        ]
      }
    ]
  },
  "allowedHttpHookUrls": ["https://hooks.example.com/*"]
}

allowManagedHooksOnly: true を設定すると、managed settings のフック・SDK フック・enabledPlugins で明示的に有効化したプラグインのフックのみロードします。シェルコマンドを含むフックはユーザーにセキュリティ承認ダイアログを表示します。

MCP 制御

managed-mcp.json の形式:

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "company-internal": {
      "type": "stdio",
      "command": "/usr/local/bin/company-mcp-server",
      "args": ["--config", "/etc/company/mcp-config.json"],
      "env": {
        "COMPANY_API_URL": "https://internal.example.com"
      }
    }
  }
}

managed-mcp.json はサーバー配信できません。MDM またはファイルベースで配布します。
env ブロックに API キー等の機密情報を直書きしません。${VAR} 展開を使います。

allowedMcpServers / deniedMcpServers のマッチキー:

{
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverCommand": ["npx", "-y", "@modelcontextprotocol/server-filesystem", "."] }
  ],
  "deniedMcpServers": [
    { "serverName": "dangerous-server" }
  ],
  "allowManagedMcpServersOnly": true
}

allowManagedMcpServersOnly: true を設定すると、user / project / local の allowedMcpServers は無視されます。deniedMcpServers は全スコープからマージされます。

認証強制

{
  "forceLoginOrgUUID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "forceLoginMethod": "claudeai",
  "forceRemoteSettingsRefresh": true
}

組織 UUID は管理コンソールで確認します。forceRemoteSettingsRefresh 有効化前に、Anthropic への API エンドポイントへのネットワークアクセスを確認します。claude auth サブコマンドは fail-closed チェックから除外されるため、認証情報の失効時はユーザーが再ログインできます。

限界: ドメインキャプチャ（Enterprise 限定）が無効な場合、ユーザーが別メールアドレスで個人アカウントを新規作成する経路は forceLoginOrgUUID だけでは技術的に塞げません。完全な境界強制にはドメインキャプチャと MDM の組み合わせが必要です。

プラグイン / マーケットプレイス制御

{
  "blockedMarketplaces": [
    { "source": "github", "repo": "untrusted/plugins" }
  ],
  "strictKnownMarketplaces": ["acme-corp-plugins", "claude-plugins-official"],
  "strictPluginOnlyCustomization": true
}

サンドボックス

Bash コマンドの OS レベルのファイルシステム・ネットワーク分離を設定します。

{
  "sandbox": {
    "filesystem": {
      "allowRead": ["/home", "/tmp", "/usr"],
      "denyRead": ["/etc/passwd", "/etc/shadow"],
      "allowManagedReadPathsOnly": true
    },
    "network": {
      "allowedDomains": ["*.internal.example.com", "api.github.com"],
      "deniedDomains": ["*.social.example.com"],
      "allowManagedDomainsOnly": true
    }
  }
}

JSON 上は sandbox 配下にネストして記述します。allowManagedReadPathsOnly は sandbox.filesystem に、allowManagedDomainsOnly は sandbox.network に置きます。

設定の確認コマンド

# 設定の健全性チェック（無効な設定値の一覧表示）
claude doctor

# MCP サーバーのリスト確認
claude mcp list

インタラクティブセッション内では /status（有効な設定ソース確認）と /permissions（有効な権限ルール確認）を使います。

■運用

監査ログ

• Enterprise organizations 専用の機能です。Team プランでは利用できません。
• 過去 180 日間 の管理イベントを保持します。
• エクスポートしたダウンロードリンクの有効期限は 24 時間です。

組織の Owner / Primary Owner が管理コンソールの Data and Privacy から CSV をエクスポートします。記録対象はユーザー認証・プロジェクト管理・組織メンバー管理・ファイル操作・会話管理など 30 種以上のイベントです。記録フィールドは created_at・actor_info・event・event_info・entity_info・ip_address・device_id・user_agent・client_platform 等です。

チャット本文とプロジェクトタイトルはエクスポート対象外です。本文取得には Compliance API を使います。Claude Code セッション固有の監視（ツール実行・コスト等）には OpenTelemetry / Analytics API を使います。

Compliance API

Claude Enterprise 顧客向けに、組織内の活動・チャット・ファイル・プロジェクト・ユーザー情報へプログラムからアクセスする API です。

• 認証: x-api-key ヘッダー
• レート制限: 親組織ごとに 600 リクエスト/分の共有制限

Audit log エクスポートとの差異:

テレメトリ（OpenTelemetry）

CLAUDE_CODE_ENABLE_TELEMETRY=1 で有効化します。managed settings の env ブロックに記載した値は最高優先度で適用され、ユーザーが上書きできません。

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.example.com:4317"
  }
}

主要な環境変数:

export OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform,cost_center=eng-123"

値にスペースは含められません。必要な場合はパーセントエンコードします。

主要メトリクスは claude_code.session.count・claude_code.lines_of_code.count・claude_code.pull_request.count・claude_code.commit.count・claude_code.cost.usage・claude_code.token.usage・claude_code.code_edit_tool.decision・claude_code.active_time.total 等です。

SIEM 連携時の注意:

• OTEL_LOG_USER_PROMPTS=1 を有効化するとプロンプト本文がログに含まれ、ログ自体の機密度が上がります。
• Bedrock / Vertex / Foundry 経由のセッションではテレメトリはデフォルト無効です。
• OTEL_* 変数は Claude Code が起動するサブプロセス（Bash ツール・MCP サーバー等）には引き継がれません。

Claude Code Analytics API

日次集計の利用メトリクスをプログラムから取得する API です。Console / API 顧客は Admin API キーを使います。Claude Enterprise 組織では Enterprise Analytics API と専用の Analytics API キーを使い、Admin API キーとは別系統になります。

curl "https://api.anthropic.com/v1/organizations/usage_report/claude_code?starting_at=2026-06-17&limit=20" \
  --header "anthropic-version: 2023-06-01" \
  --header "x-api-key: $ADMIN_API_KEY"

取得できる指標はディメンション（date / actor / organization_id 等）・コアメトリクス（セッション数・追加削除行数・コミット数・PR 数）・ツールアクション（Edit / Write 等の承認拒否数）・モデル別トークンと推定コストです。

• データは最大 1 時間の遅延があります。リアルタイム監視には OTel を使います。
• Bedrock / Vertex / Foundry 経由の利用は対象外です。

データ保持

Zero Data Retention（ZDR）:

• 対象は Claude for Enterprise の適格アカウントのみです。標準の Enterprise プランには含まれません。
• セールスまたは担当 Anthropic チームに連絡して個別に有効化します。
• 適用単位は組織ごとです。新規組織には自動適用されません。

一部のモデルはデータ保持を必須とするため ZDR 組織では利用できません。公式 ZDR ドキュメントは Claude Fable 5 を ZDR 非対応モデルとして明記しています（このモデルクラスはデータ保持を要求します）。

ZDR 有効時は会話履歴のサーバー側ストレージを要する機能（Claude Code on the Web、Desktop アプリのクラウドセッション、/feedback 送信）が無効化されます。ポリシー違反対応や法令遵守のために、最大 2 年間データを保持する例外があります。

クライアントはセッション再開のためトランスクリプトを ~/.claude/projects/ に平文で保存します。デフォルトの保持期間は 30 日で、cleanupPeriodDays 設定で変更できます。

Bedrock / Vertex / Foundry 利用時は各クラウドプロバイダーの暗号化・保持ポリシーが適用され、Compliance API / audit log の対象外になります。

設定の更新運用

• requiredMinimumVersion を引き上げると、古いバージョンのユーザーを起動時に締め出せます。claude update / claude install / claude doctor はブロックされず、復旧操作が可能です。
• forceRemoteSettingsRefresh: true は起動時にリモートの managed settings を必ず新規取得し、失敗時はキャッシュを使わず起動をブロックします。
• ドロップイン方式（managed-settings.d/）で、セキュリティ・コンプライアンス・テレメトリの設定を番号付きファイルに分割し、段階的に適用できます。
• 設定変更後は claude doctor で無効な設定値を確認します。

個人アカウント切替のリスクと検知

予防策は forceLoginOrgUUID の設定です。ただし Bedrock / Vertex / Foundry 経由の認証はこの制御外です。検知には OTel の organization.id 属性の監視や、Compliance API の Activity Feed でのログイン認証イベントのポーリングを使います。

■ベストプラクティス

「道具は Starter Kit で配り、境界線は managed settings で強制する」原則

Starter Kit はユーザーが編集可能な領域に置かれます。セキュリティ設定をここに置くとユーザーが削除できます。企業として外せない統制は managed settings に配置します。

Starter Kit に含まれるセキュリティ設定（deny リスト等）は managed settings に「昇格」させます。

MCP の段階的解禁

企業規模別の推奨パターン

最小限の deny リスト

企業として最低限 managed settings の permissions.deny に含める設定です。

{
  "permissions": {
    "deny": [
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/secrets/**)",
      "Read(~/.ssh/**)",
      "Bash(sudo *)",
      "Bash(rm -rf *)",
      "Bash(git push --force *)"
    ]
  },
  "allowManagedPermissionRulesOnly": true
}

Bedrock / Vertex AI / Foundry 利用時の注意

これらの経由を採用する場合は各クラウドの IAM（AWS IAM / Google Cloud IAM / Azure RBAC）で制御します。

■トラブルシューティング

■まとめ

Claude Code の企業統制は「誰が使えるか（プロビジョニング層）」「何を許すか（ポリシー強制層）」「どんな使い方を配るか（標準環境配布層）」の 3 層を分離し、外せない境界線だけを managed settings で強制する設計が要になります。Starter Kit はユーザーが編集できる推奨層なので、セキュリティ境界は server-managed settings や MDM へ昇格させ、個人アカウント切替・MCP・データ保持の境界変化まで含めて統制します。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNS でのシェアをいただけると励みになります！

■参考リンク

起点記事

• Claude Code 企業配布、標準環境と強制ポリシーの3層分離（CloudNative BLOGs）

Anthropic / Claude Code 公式

• Claude Code settings
• Configure server-managed settings
• Identity and access management（IAM）
• Manage permissions
• Plugin marketplaces
• Zero data retention
• Data usage
• Compliance API
• Claude Code Analytics API
• Set up JIT or SCIM provisioning
• Access audit logs

GitHub / テンプレート

• anthropics/claude-code — examples/mdm
• anthropics/claude-code — examples/settings
• cloudnative-co/claude-code-starter-kit

関連解説

• Claude Code admin controls: a complete guide for IT and DevOps teams（eesel AI）
  </content>
  </invoke>