Claude Code を社内に配る前に決める権限とセキュリティの設定｜自動モードのまま止める操作・聞く操作と、CLI・デスクトップアプリへの配り方

開発者から「Claude Code を使いたい」と言われた情報システムの担当が、配る前に気にするのは、たとえば次のようなことです。自動で動かしてよいのか。.env や本番の鍵を読まれないか。勝手に外部のツールをつながれないか。個人のアカウントで使われないか。開発者が設定を自分で書き換えてしまわないか。

当社も、従業員100〜200名ほどのコンサルティング会社から、CLI とデスクトップアプリという2つの媒体をどう管理し、使う人の安全をどう設計するか、という相談を受けました。その会社は、権限のモードを基本は自動（auto）にすると決めていました。自動にするなら、次に決めるのは、自動のまま何を止め、何を人に聞かせるかです。

この記事では、その線引き（何を deny、何を ask にするか）と、それを書く設定のキー、開発者に書き換えられない届け方、効いているかの確かめ方を、1つの設定ファイルの作例で書きます。線引きは当社が勧めるもので、相談元が決めたことではありません。当社は Microsoft 365 と生成 AI の導入と運用を支援していて、ライセンスも Anthropic の製品も販売していません。

自動のままにする前に、設定ファイルで止まる範囲を知っておく

管理者が端末に置く「管理された設定（managed settings）」は、ユーザー・プロジェクト・ローカル・コマンドラインのどの設定よりも上に置かれます。日本語版のドキュメントは「マネージド設定」と訳しています。例外は、下の階層のほうが厳しい値を持つときにそちらを採る少数のキーだけです（設定ファイルと優先順位）。

ただ、この設定で縛れるのは Claude Code の動きまでです。権限ルールは Claude Code が自分で守るもので、Claude がふだん書く形の命令に当たるだけで、プログラムの周りの境界にはなりません（権限を設定する）。命令の書き方によらずファイルとネットワークを止めるのは、OS の側で動くサンドボックスです。macOS・Linux・WSL2 では動きますが、ネイティブの Windows では命令がサンドボックスの外で動きます（Sandboxing）。Windows の PC に配るなら、設定ファイルで止まらない範囲を WSL2 で動かして閉じるか、ネットワークの側で閉じるかを、別に決めます。サンドボックスの中身はClaude Code のセキュリティ運用の記事にあります。

もう1つ、管理された設定は、別のツールから API を呼ぶ開発者には効きません。開発者が設定を書き換える問題は、届け方で防ぎます（後の「開発者に書き換えられない経路で…」の節）。端末の管理者権限を持つ開発者は置き場所そのものを書き換えられるので、MDM で決まった間隔で配り直すことになります。

この記事に関連するサービス

Claude 導入支援Claudeを、会社の決まりの中で使える状態まで。詳しく見る →AI活用支援生成AIを、業務に組み込むところまで詳しく見る →ChatGPT 導入支援ChatGPTを、会社の決まりの中で使える状態まで。詳しく見る →AIセキュリティ診断・規約・ルール整備AIを使う前に、出す前に。安全の確認と、規約・ルールの整備を詳しく見る →Microsoft 365 導入支援Exchange・SharePoint・Teamsの移行から権限設計・Copilot活用まで詳しく見る →

自動モードのまま、何を止めて何を毎回聞くかを決める

auto モードでは、人の代わりに2つ目のモデル（分類器）が操作を見て、通すか止めるかを決めます。端末と VS Code の拡張は v2.1.283 以降、既定で auto モードで始まり、Team・Enterprise の組織でも既定で使えます（Permission modes）。

判断の順は3段です。まず管理者や開発者が書いた allow・ask・deny のルールに当たったものが、そのまま決まります。次に、読み取りと作業フォルダの中の編集が自動で通ります（保護されたパスなどを除く）。残りが分類器に回ります。

分類器は既定で、curl | bash のようにダウンロードしたコードを動かすこと、秘密のデータを外へ送ること、本番へのデプロイ、force push などを止めます。一方で、作業中のリポジトリへの push（既定のブランチを含む。production や gh-pages のように配備先と分かる名前のブランチは除く）、頼んだ内容に合う PR の作成、.env を読んでその資格情報を対応する API に送ることは、既定では聞かずに通します。公式も、auto モードは確認の回数を減らすもので安全を保証するものではない、と書いています。そこで当社は、自動のまま次の4つを管理された設定に書くことを勧めます。

秘密のファイルの読み取りと、外へ送れる命令は deny で止める

管理された設定の permissions.deny は、分類器に聞く前に操作を止め、どこからも上書きできません（Configure auto mode）。ルールは deny、ask、allow の順に評価され、広い deny があれば狭い allow で例外を切り出すことはできません。Read の deny は Claude の読み取りの道具だけでなく、cat・head などの読む命令にも当たります。deny に道具の名前だけ（Bash など）を書くと、その道具そのものが Claude から見えなくなります。作例の土台は、公式の「Deploy managed settings」のページにある最小の例です。

{
 "permissions": {
 "deny": [
 "Read(./.env)",
 "Read(./secrets/**)"
 ],
 "disableBypassPermissionsMode": "disable"
 },
 "allowManagedPermissionRulesOnly": true
}

作例には、公式の例（Example settings files）から、チームで共有する設定の例にある Read(./.env.*) と、組織の例にある Bash(curl *) を足します。ここで、この記事でいちばん大事な限界があります。permissions のページの表では、Bash(curl *) の deny は curl https://example.com を止めても、/usr/bin/curl https://example.com と sh -c 'curl https://example.com' は止めません。外へ送る道を本当に閉じるのは、サンドボックスの宛先の許可リストか、社内のネットワークの制限です。deny は、Claude がふだん書く形を止めて、分類器に回る量を減らすものと考えてください。後の節で「書き方を変えた命令」と書くときは、この例のことです。

git push などの取り消せない操作は ask で毎回聞く

命令の中身に当たる ask のルールは、分類器より先に評価され、auto モードでも確認の画面を出します。公式の例は push と PR の作成です。

{
 "permissions": {
 "ask": [
 "Bash(git push *)",
 "Bash(gh pr create *)"
 ]
 }
}

本番へのデプロイやパッケージの公開も同じ ask に入れます。作例では、一般的な命令の形として npm publish と terraform apply を足しました（terraform apply は、公式の設定リファレンスが分類器に止めさせる例に挙げている命令です）。自社で使うデプロイや公開の命令の形に置き換えてください。どのルールも、書いた形で始まる命令にしか当たりません。たとえば Bash(git push *) は、git -C <dir> push のように書き方を変えた push には当たらず、素通りします。命令の全文を見て止めたいなら、PreToolUse のフック（道具が動く直前に呼ばれ、その操作を止められる仕組み）を管理者が配ります。

バイパスのモードは消し、auto は残す

permissions.disableBypassPermissionsMode を "disable" にすると、権限の確認を飛ばす bypassPermissions が使えなくなります。公式はこのモードをコンテナや仮想マシンのような隔離した環境でだけ使うよう書いています。似たキーの permissions.disableAutoMode を "disable" にすると auto モードのほうが消え、セッションは default（画面では Manual）で始まります。自動のまま使うなら、こちらは書きません。デスクトップアプリでは、Team・Enterprise のプランだとバイパスの切り替えが設定画面に無く、組織のポリシーで決まります（Claude Code Desktop）。

開発者が足す allow をどこまで認めるか

allowManagedPermissionRulesOnly を入れると、権限ルールの出どころが管理された設定だけになり、リポジトリの .claude/settings.json の allow も、起動時の --allowedTools も、確認の画面の「今後は聞かない」も効かなくなります（設定リファレンス）。入れない場合は、すべての出どころの allow と deny が合わさり、開発者は管理者の一覧に足せても引けません。auto モードに入ると Bash(*) のような広い allow は外され、Bash(npm test) のような狭い allow は残ります。当社の作例では入れていますが、.claude/ で allow を運用しているチームがあるなら、配る前にその一覧を管理者の側に移すかを決めます。

分類器そのものにも、管理者が渡せる設定があります。社内のリポジトリやクラウドの保存先のように「外」として扱わせたくない宛先は autoMode.environment に書きます。既定では作業フォルダと、そのリポジトリに設定されたリモートしか信頼しないため、社内の別の宛先への push は止まります。この設定はプロジェクトの .claude/settings.json からは読まれないので、リポジトリが自分で許可を足すことはできません。一方で、管理者が autoMode.soft_deny に書く拒否は、開発者が足す autoMode.allow で上書きでき、境界にはならない、と公式は断っています（autoMode.hard_deny は分類器の中で無条件に止めます）。命令の形で分類器より先に止めたいものは、permissions.deny に書きます。なお Enterprise プランや API・クラウド経由では、分類器の呼び出しがトークンの使用量に数えられます。ただしサーバーの側でモデルへの要求と一緒に操作を見ている場合は、別の分類器の呼び出しはありません。

作例：線引きを1つの設定ファイルにする

この記事の線引きと、後の節で足すキーを1つにまとめた作例です。公式の「Deploy managed settings」「Example settings files」「Configure auto mode」「Control MCP server access」の例に、当社が勧める線引きを合わせました。組織の UUID は自社のものに、マーケットプレイスの名前（acme-corp/approved-plugins）と MCP サーバーの URL は公式の例のままなので自社のものに、ask の npm publish と terraform apply は自社で使うデプロイや公開の命令の形に置き換えて使います。公式の例と同じく、要件に合うキーだけを残してください。

{
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": [
    "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  ],
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)",
      "Bash(npm publish *)",
      "Bash(terraform apply *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "disableRemoteControl": true,
  "allowedMcpServers": [
    {
      "serverUrl": "https://api.githubcopilot.com/*"
    }
  ],
  "allowManagedMcpServersOnly": true,
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "acme-corp/approved-plugins"
    }
  ],
  "disableSideloadFlags": true,
  "allowManagedHooksOnly": true,
  "allowedHttpHookUrls": [],
  "env": {
    "DISABLE_FEEDBACK_COMMAND": "1"
  },
  "cleanupPeriodDays": 7,
  "autoUpdatesChannel": "stable",
  "requiredMinimumVersion": "2.1.283"
}

上から順に、forceLoginMethod と forceLoginOrgUUID はサインイン先の節、permissions と allowManagedPermissionRulesOnly はこの前の節、disableRemoteControl は通信と記録の節、allowedMcpServers と allowManagedMcpServersOnly は MCP の節、strictKnownMarketplaces から allowedHttpHookUrls まではプラグインとフックの節、env と cleanupPeriodDays は通信と記録の節、最後の2行は版の節で説明します。

MCP サーバーは、許可した目録からだけつなげるようにする

MCP（Model Context Protocol）は、Claude Code に外部のツールやデータをつなぐ仕組みで、つなぐ先を MCP サーバーと呼びます。既定では、Claude Code を動かす誰もが好きな MCP サーバーにつなげます。Anthropic はディレクトリに載せる前にコネクタを審査しますが、MCP サーバーのセキュリティ監査も管理もしていません（Control MCP server access for your organization）。MCP そのものの危険はClaude Code × MCP のセキュリティの記事で扱っているので、ここでは縛り方だけを書きます。

公式の「Choose a pattern」の表には、制限なしを除いて7つの縛り方があり、配る前に選ぶのは図の4つのどれかです。当社が勧めるのは「許可した目録」です。allowedMcpServers に許すサーバーを書き、allowManagedMcpServersOnly: true を添えると、開発者は目録にあるものを自分で足せ、それ以外は止まります。allowManagedMcpServersOnly を忘れると、すべての階層の許可リストが合わさり、開発者が自分の ~/.claude/settings.json で許可を広げられます。このキーは allowManagedPermissionRulesOnly とは別で、権限ルールの側を固めても MCP の許可は固まりません。

目録の項目は serverUrl（URL、* が使える）、serverCommand（起動する命令と引数の完全一致）、serverName（開発者が付けた名前）の3種類です。serverName について公式は、安全のための制御ではない（not a security control）と書いています。開発者はどんなサーバーにも github と名付けられるからです。動くサーバーを縛るなら URL かコマンドで書きます。Claude Code には開発者が目録を見て入れる仕組みが無いので、許したサーバーと claude mcp add の命令は社内の wiki などに置きます。

まだ使い道が決まっていないなら、managed-mcp.json に空の mcpServers を置いて、開発者が足すサーバーをいったん全部止める手もあります。それでも、managedMcpServers で管理者が配るサーバー、セッションを始めたアプリが自分で登録するサーバー（VS Code の拡張のサーバーや、デスクトップアプリが渡すコネクタ）、管理者が許した Claude in Chrome は読み込まれます。置き場所は Windows が C:\Program Files\ClaudeCode\managed-mcp.json で、サーバーから配る設定では届けられません。端末の誰でも読めるファイルなので、API キーなどの資格情報は書きません。

{
 "mcpServers": {}
}

デスクトップアプリには例外があります。アプリのローカルと SSH のセッションでは、アプリが claude.ai でつないだコネクタを Claude Code に直接渡すため、MCP の設定も managed-mcp.json も届きません（MCP）。ここで効くのは、組織の管理画面でコネクタのツールを blocked にする設定だけです。管理画面の ask はアプリのセッションの Claude Code に届かず、毎回の確認にはならず、そのセッションのふつうの権限ルールが当たります。アプリのローカル・SSH 以外のセッション（端末、VS Code、クラウドのセッションなど）では、管理画面の ask で毎回確認が出ます。アプリでコネクタを使わせたくないなら、ツールを blocked にするか、アプリの Claude Code そのものを切ります。

プラグインとフック、claude.ai から降りてくるものの出どころを絞る

プラグイン（スキル・エージェント・フック・MCP サーバーをまとめて配る単位）は、マーケットプレイスから入れます。管理された設定の strictKnownMarketplaces（許可リスト）と blockedMarketplaces（拒否リスト）が、入れてよい出どころを決めます（Manage plugins for your organization）。許可リストを空の配列にすると、Anthropic の公式のマーケットプレイスも含めてすべて止まるので、空にするのは締め出したいときだけです。ただし起動のときに --plugin-dir・--plugin-url・--agents・--mcp-config を付けると、その1回だけは許可リストの外のものを読み込めます。この抜け道を閉じるのが disableSideloadFlags で、許可リストと対で入れます。

フック（Claude Code の動きに合わせてシェルの命令などを動かす仕組み）を管理者のものだけに限る理由は、リポジトリに置かれたフックの動き方にあります。permissions のページの表では、リポジトリの設定ファイルにあるフックは、親のフォルダだけを信頼した状態でも、画面を出さずに1回だけ動かす claude -p でフォルダを一度も信頼していない状態でも使われます。親のフォルダだけを信頼した中のフォルダや、claude -p で動かしたフォルダでは、信頼の確認を経ずに、リポジトリに書かれた命令が動きうる、ということです（親のフォルダの中にある別の git リポジトリは、対話のセッションなら信頼の確認が出ます）。allowManagedHooksOnly: true にすると、管理者が配ったフック（と、管理者が強制で有効にしたプラグインのフックなど）だけが動きます。

HTTP で外に投げるフックは allowedHttpHookUrls で宛先を絞れ、空の配列なら HTTP のフックがすべて止まります。この許可リストは管理者のフックにも効きます。ただしこのキーはすべての設定ファイルの一覧が合わさるので、管理者の一覧が空でも、ユーザー・プロジェクト・ローカルの設定に書いた URL は効きます。作例のように allowManagedHooksOnly と対で使います。

端末の出どころを絞っても、開発者が claude.ai のアカウントで有効にしたスキルとプラグインは端末に降りてきます。止めるなら syncClaudeAiSkills と syncClaudeAiPlugins を false にします（組織向けに Claude Code をセットアップする）。この2つは false だけが意味を持つキーです。claude.ai のコネクタは disableClaudeAiConnectors で、どの設定ファイルの true でも効きます。スキル・エージェントまで含めてユーザーとプロジェクトのフォルダから読ませない strictPluginOnlyCustomization もありますが、リポジトリの .claude/ に置いたスキルまで止まるので、作例には入れていません。

個人のアカウントで使われないように、サインイン先を固定する

開発者が会社の PC で個人の Pro・Max のアカウントや、別の組織の API キーでサインインすると、そのセッションにはサーバーから配る設定（claude.ai の管理画面で書く設定）が届きません。サーバーの設定は、認証に使った資格情報の組織のものが届くからです。端末に置いた設定（HKLM やファイル）は届きます。ゼロデータ保持の契約がある組織でも、個人のアカウントや別の組織のキーでのセッションは対象外です（Zero data retention）。

forceLoginMethod を "claudeai" に、forceLoginOrgUUID に自社の組織の UUID を書くと、ほかの組織の claude.ai のアカウントはエラーになり、起動の時点で止まります。ANTHROPIC_API_KEY などの API キーで認証するセッションも起動で止まります（Authentication）。VS Code の拡張や Agent SDK のログインも forceLoginMethod に従います（v2.1.212 以降）。ただし端末の対話のログイン画面（/login や初回の案内）は方式を選んでおくだけで強制しないので、"claudeai" にしても Console のログインを最後まで進められます。Console のログインでは、forceLoginOrgUUID で組織を確かめません。claude setup-token と /install-github-app も、確かめるのは forceLoginMethod だけです。

この2つは MDM（Intune のような、端末をまとめて管理する仕組み）かファイルで配ります。サーバーから配る設定は、開発者が組織にサインインした後にしか届かないので、最初のサインインを向け直せないからです。サーバーから配る設定も使っている会社は、すべての端末が v2.1.299 以降になるまで、サーバーの設定にも両方のキーを書きます。また、Claude Code の側に書いても、デスクトップアプリのサインイン画面は変わりません。アプリのほうはアプリ自体のポリシーに forceLoginOrgUUID を書きます（デスクトップアプリの節の表）。Microsoft Foundry のように、Anthropic の API ではなく各社のクラウドを通して Claude を使う経路と、それを使わせない設定はFoundry 経由で使う記事に書いています。

外に出る通信と、端末に残る会話の記録をどこまで減らすか

プロンプトとモデルの出力は TLS 1.2 以上で暗号化して API に送ります。商用（Team・Enterprise・API・クラウド経由）では、Anthropic は Claude Code に送ったコードとプロンプトを生成モデルの学習に使いません。顧客がモデルの改善にデータを出すと選んだ場合（Developer Partner Program など）は除きます（データ使用）。決めるのは、それ以外の通信と、会話の記録の置き場所です。止め方と、止めたときに失うものは次の表のとおりです。環境変数は管理された設定の env に、設定のキーは管理された設定にそのまま書くと、全員分が止まります。

{
 "env": {
 "DISABLE_TELEMETRY": "1"
 }
}

当社が止めるものと、残すもの

当社は、まず /feedback を止めることを勧めます。会話の記録をコードごと Anthropic に送る命令で、送った記録は5年保持されるからです。失うのは、開発者が Claude Code から不具合を報告する手段です。

メトリクスは、利用状況を見たい会社は残します。止めると、組織の分析ダッシュボードの使用量のデータも止まるからです。エラー報告とセッションの品質の調査は、表のとおり送られる条件が限られているので、社内の規程が止めると決めているかで決めます。

表の最後の CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC は1行で済みますが、DISABLE_TELEMETRY と同じく機能の切り替えの確認も止めるので、Remote Control が使えなくなることがあります（DISABLE_ERROR_REPORTING は影響しません）。WebFetch の確認と、公式マーケットプレイスの自動導入（CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALL で止める）は、これでは止まりません。

WebFetch のホスト名の確認

WebFetch は、ページを取りに行く前にホスト名だけを api.anthropic.com に送り、Anthropic が持つ危険なホストの一覧と照らします。この確認は、どの経路で Claude を使っていても動きます。社内のネットワークで api.anthropic.com を止めていると WebFetch が失敗するので、ドメインを許すか skipWebFetchPreflight: true にします。確認を飛ばしたうえで行き先を絞る必要があるなら、WebFetch の権限ルールと組み合わせるよう公式は書いています。

Anthropic の API 以外の経路で使うとき

Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry、Claude Platform on AWS のように、各社のクラウドを通して Claude を使う場合は、エラー報告・メトリクス・/feedback が既定でオフです。セッションの品質の調査と WebFetch の確認だけは、経路によらず動きます。

自社の収集先で使い方を見る

止めるのではなく自社で見たい会社は、管理された設定の env に CLAUDE_CODE_ENABLE_TELEMETRY と OTEL_EXPORTER_OTLP_*（OpenTelemetry の送り先）を書きます。開発者が自分で別の送り先に向けた変数は起動時に外されます（Monitoring）。これらの変数はリポジトリの .claude/settings.json からは効かないので、リポジトリが勝手に送り先を変えることはできません。プロンプトの本文は OTEL_LOG_USER_PROMPTS を入れない限り記録されません。

会話が端末の外に置かれる機能

作例は Remote Control を止めて始めています。会話の記録を Anthropic のサーバーに置いてよいかを社内の規程で決めるまでは、使えるようにしておく理由が無いからです。会社の PC の外から作業を続けたい開発者が出て、規程が記録の置き場所を許すなら、そのときに外します。Anthropic がホストする環境で動くクラウドのセッションも、同じ基準で決めます。こちらは組織の管理画面で使わせるかを切り替えます。

Remote Control は、つないでいる間、会話の記録を Anthropic のサーバーに置いて端末の間で同期します（セキュリティ）。disableRemoteControl: true にすると、claude remote-control、起動時のフラグ、自動での接続、セッションの中の切り替えのどれも断られ、組織のポリシーで止めていると表示されます（設定リファレンス）。

このほか、セッションを裏で動かす機能（claude agents・--bg・/background で始めるバックグラウンドのエージェント）は、disableAgentView で止められます。

端末に残る記録

セッションの記録は ~/.claude/projects/ に平文で、既定で30日残ります。暗号化はされず、ツールが .env を読めば、その値も記録に書かれます（The .claude directory）。deny で .env を止めるのは、この記録に秘密を残さないためでもあります。日数は cleanupPeriodDays で縮めます。デスクトップアプリで始めた会話の記録は既定では何日たっても消えませんが、管理された設定で cleanupPeriodDays を配ると、同じ日数で消えるようになります。作例は公式の組織向けの例と同じ 7 です。

作業フォルダの外を読ませたくないなら permissions.blockReadsOutsideWorkingDirectories を true にします。このキーの true は、管理された設定が false でも、どの階層からでも効きます（v2.1.257 以降）。

開発者に書き換えられない経路で、CLI とデスクトップアプリに届ける

経路は4つあり、1台に複数あるときは既定で最上位の1つだけが効き、ほかは無視されます（マネージド設定をデプロイする）。端末、VS Code・JetBrains の拡張、デスクトップアプリの Code タブ（アプリの中で Claude Code を使う画面）、Claude Code を組み込んだ自社のプログラム（Agent SDK）は、どれも同じ経路を読みます。

ファイルの場所は、Windows が C:\Program Files\ClaudeCode\managed-settings.json、macOS が /Library/Application Support/ClaudeCode/managed-settings.json、Linux と WSL が /etc/claude-code/managed-settings.json です。Windows の旧パス C:\ProgramData\ClaudeCode\managed-settings.json は読まれません。MDM で配る場合、Windows は HKLM\SOFTWARE\Policies\ClaudeCode の下に Settings という名前の REG_SZ か REG_EXPAND_SZ の値として JSON を置きます（Anthropic の GitHub の ADMX の見本は、1行の JSON で書きます）。読み直す間隔は、サーバーからの設定が1時間ごと、MDM・レジストリが30分ごと、ファイルは変わったときです。

開発者の書き換えを防ぐ要は、どこに置くかです。当社は、Intune で PC を管理している会社には、HKLM に ADMX（グループ ポリシーの設定項目を定義するファイル）を取り込んで配ることを勧めます。HKLM は書くのに管理者権限が要るので改ざんに強く、HKCU は管理者権限なしで書けるので強制の経路にはならない、と管理者向けのページが書いているからです（組織向けに Claude Code をセットアップする）。裏を返すと、端末の管理者権限を持つ開発者は、置き場所そのものを書き換えられます。公式は、だから MDM の道具で決まった間隔で配り直せるようにしてあり、HKLM の置き場所があるのだ、と書いています（マネージド設定をデプロイする）。

見本は Anthropic が GitHub に置いていて、プラットフォーム スクリプトでファイルを書く方法と、ADMX で HKLM に書く方法の2つがあります（MDM Deployment Examples）。コミュニティが保守する見本で正しくないことがある、と断り書きがあります。Intune の画面はFoundry 経由で使う記事に写真があります。

サーバーから配る設定（claude.ai の管理画面）は Team・Enterprise で使えますが、api.anthropic.com に直接つながるセッションにしか届きません。Claude Console（Anthropic の API の管理画面）で発行した API キーを使う CI のジョブや Foundry 経由のセッションには届かないので、そうした端末には MDM かファイルで配ります（Configure server-managed settings）。逆に、Anthropic がホストする環境で動くクラウドのセッションには、端末の MDM もファイルも届かず、サーバーから配る設定だけが効きます。

最上位の1つだけが効くという決まりには例外があります。allowManagedMcpServersOnly・deniedMcpServers・disableClaudeAiConnectors などのいくつかのキーは、すべての管理者の経路から読まれ、下の経路に書いても効きます。HKLM とファイルを両方置いている会社は、古いファイルの中身が残っていないかも見ておきます。

WSL2 で Claude Code を動かす開発者がいるなら、もう1つ設定が要ります。WSL は既定で Linux 側の /etc/claude-code/managed-settings.json しか読まず、Windows の HKLM やファイルの設定は届きません。wslInheritsWindowsSettings: true を HKLM か Windows のファイルに書くと、WSL でも Windows 側の設定を読みます。WSL2 の中のプロセスは、Windows 側に入れた端末の監視のソフト（EDR）から見えない、と管理者向けのページは注意しています。

デスクトップアプリで使わせるときは、アプリだけの設定も決める

デスクトップアプリは CLI と同じ設定ファイルを読み、新しいローカルのセッションに権限のモードを当てます。作例のキーのうち、権限・MCP・フックなどはアプリの Code タブでもそのまま効きます（サインイン先の2つは、アプリのサインイン画面を変えません）。そのうえで、アプリだけが読むキー（管理された設定に書く）と、アプリ自体のポリシー（HKLM\SOFTWARE\Policies\Claude。Claude Code の ClaudeCode とは別のキー）があります。

決める順は3つです。1つ目は、アプリで Claude Code を使わせるか。使わせないなら、表の1行目で切れば、ほかのキーは要りません（Claude Code Desktop）。2つ目は、使わせる範囲です。端末の上のセッション、SSH の先、アプリの中のブラウザを、それぞれ表のキーで止められます。3つ目は、サインインする組織と更新をアプリのポリシーで固めることです。アプリのポリシーは HKLM と HKCU の両方にあるときは HKLM が勝つので、HKLM に置きます（Enterprise configuration for Claude Desktop）。

WSL のセッションは、アプリが管理された設定のファイルがある PC などを組織の管理下の端末と判断して、既定で閉じます。WSL2 で使わせるなら、表のとおり HKLM に disableWslSessions を置きます。管理された設定のファイルは置いたままで構いません（組織向けに Claude Code をセットアップする）。

配るときの注意が2つあります。ファイルで配る場合は、PC を使う各ユーザーのアカウントがそのファイルを読めるようにしておきます。読めないファイルのキーは、アプリでは使われません。アプリの配布は MSIX で、ユーザーごとに入るパッケージなので、全ユーザーに入れるなら Add-AppxProvisionedPackage で端末に置きます（Deploy Claude Desktop for Windows）。MDM で版を管理するなら、表の disableAutoUpdates を入れます。

Cowork のセッションでは、Claude Code は管理画面の設定も取りに行きません。Cowork を使わせるかは、Claude Code とは別に決めます。

1台で /status を見てから全台に広げる

配ったら、全台に広げる前に1台で確かめます。Claude Code の中で /status を開くと、Setting sources の行に Enterprise managed settings と、選ばれた経路が括弧で出ます。(file) はファイル、(HKLM) か (plist) は MDM・OS のポリシー、(remote) はサーバーからの設定です。行が無いときは、ポリシーのキーを1つも含む経路が見つかっていません。配った経路と違う名前が出るときは上位の経路が勝っていて、Skipped sources の行に自分の経路が出ます。claude doctor は、読めずに落とした項目を示します。

書き損じの扱いは、場合で分かれます。ファイル・plist・HKLM の値が JSON として読めないと、Claude Code は起動せず、出どころを名指しするエラーを出します。JSON として読めても値が誤っている場合は、直せる項目（誤った権限ルール1つなど）を飛ばし、それでも誤っている値は落とすのが原則です。厳しい側に倒れるのは決まったキーだけで、allowManagedPermissionRulesOnly のような制限の値が1つしかないキーは直すまでその制限として効き、allowedMcpServers は空の許可リストとして効きます。逆に、作例の requiredMinimumVersion は、値が誤っていると落とされて効きません。JSON の誤りは全員を止め、値の誤りは気づかないまま効かなくなることがあるので、1台で起動と claude doctor まで見ます。

MCP と auto モードは別の命令で見ます。claude mcp list には読み込まれたサーバーが出ます。managed-mcp.json を置いた場合は、claude mcp add が「Cannot add MCP server: enterprise MCP configuration is active and has exclusive control over MCP servers」というエラーで止まることも見ます。claude auto-mode config は、autoMode に書いた内容を含めて分類器が実際に使う規則を出します。

サーバーから配る設定は、起動時に取りに行けないと前回の控えで動きます。届かないなら起動させたくない会社は forceRemoteSettingsRefresh: true を入れます。ただしデスクトップアプリの Code タブでは承認の画面を出せないため、フックを含むサーバーからの設定は、その回だけの適用になります（Configure server-managed settings）。

配った後は、版の下限と更新の経路をそろえる

この記事のキーの多くは、効く版が決まっています。auto モードが既定になったのは v2.1.283、blockReadsOutsideWorkingDirectories がどの階層からでも効くのは v2.1.257 以降です。古い版の PC が残ると、同じ設定を配っても動きがそろいません。公式のインストーラーで入れた Claude Code は裏で自動で更新されますが、WinGet などのパッケージ管理で入れたものは既定では手で更新します（Set up Claude Code）。

そろえる道具は3つです。autoUpdatesChannel を "stable" にすると、おおむね1週間前の版で、大きな不具合のあった版を飛ばして更新されます。requiredMinimumVersion に下限を書くと、それより古い版は起動の時点で止まり、会社の決めた方法で更新するよう案内が出ます（v2.1.163 以降。claude update は下限より下でも動きます）。作例では auto モードが既定になった v2.1.283 を下限にしています。自社で検証した版だけを配りたい会社は、環境変数の DISABLE_UPDATES で手動の更新も含めて止めます。DISABLE_AUTOUPDATER は裏の確認を止めるだけで、claude update は通ります。

この設定では止まらないものと、閉じる手段

モデルの制限と組織の CLAUDE.md の置き場所は、管理者向けのページとMemoryのページにあります。

この記事で扱わないこと

配った後の運用、つまり誰が何に使ったかの記録をどこまで取るか、使いすぎをどこで止めるか、辞めた人や異動した人の端末をどう止めるか、チームで CLAUDE.md やスキルを配るときに何が危ないか、デスクトップアプリを Intune で配る詳しい手順、社内の証明書やプロキシとの付き合い方は、この記事では扱いません。すでに書いた記事として、SSO・SCIM・監査ログ・保持期間のように法人プランの管理画面で決めることはTeam・Enterprise の管理機能の記事に、Foundry 経由で使うときの違いはFoundry 経由で使う記事にあります。

配る前に開発者へ渡すものとして、公式は4つを挙げています。最初のセッションを通しで案内する Quickstart、コードレビューやリファクタリングなどふだんの作業の進め方をまとめた Common workflows、Claude Academy の無料の講座 Claude Code 101 と Claude Code in Action です（組織向けに Claude Code をセットアップする）。Intune の設定と Microsoft 365 の管理をそろえて生成 AI を入れたい場合は、Microsoft 365 の導入支援でご相談を受けています。

この記事の確かめ方

設定の動き・キー・置き場所・版は、2026年11月1日に Anthropic の Claude Code のドキュメント（管理者向けの「Set up Claude Code for your organization」、Deploy managed settings、settings reference、permissions、permission modes、auto mode、managed MCP、desktop など）と、Claude ヘルプセンターのデスクトップアプリの配布のページを開いて、原文に沿って書きました。図の出典も同じです。管理者向けのページの「Decide what to enforce」の表には2026年11月1日時点で 19 行あり、この記事ではそのうち配る前に決めるものに絞っています。相談の場面は当社が受けた相談によるもので、社名は伏せています。線引きは当社が勧めるもので、当社が全台に配って動かした結果ではありません。画面の写真は載せていません。ドキュメントは更新が続いているため、配る前に各ページの最新を確かめてください。