11月1日、Nirmataが「How to onboard 1,000 developers to Claude Code without manual setup」と題した記事を公開した。AIコーディングツールの導入が加速する中、個人レベルの手動設定では追いつかない「1,000人規模の展開」という現実的な課題に正面から向き合った内容だ。
Claude Codeは、Anthropicが提供するAIコーディングアシスタントのCLIツールだ。個人利用なら設定ファイルを手で編集すれば済むが、開発者が数百〜数千人規模になると、全員の端末を手動でセットアップするのは現実的ではない。GithHub CopilotやCursorといった競合ツールも類似の組織展開機能を持ち始めており、エンタープライズ向けAI開発ツールの「管理可能性」が選定基準として浮上してきている背景がある。本記事はその課題に対し、マネージドポリシー（managed policy） を使った大規模展開の手順を体系的に解説している。
※編集部の考察：AIコーディングツールの普及フェーズは「個人導入」から「組織展開」へ移行しつつある。セキュリティポリシーの統一やコスト管理の観点から、管理者側がどこまで制御できるかが、ツール選定の重要な軸になってきている。
マネージドポリシーが「ユーザー設定より必ず優先される」という仕組み
最初に押さえるべき核心はここだ。Claude Codeのマネージドポリシーは、ユーザー設定・プロジェクト設定・ローカル設定・コマンドライン引数のすべてより上位に位置する。つまり、管理者が一度ポリシーを配布すれば、開発者が設定ファイルを触る必要はなく、また開発者側でマネージドキーを上書きすることもできない。
ポリシーの配布には4つのメカニズムがある。
| 配布方法 | 仕組み | 再読み込みタイミング | 適した場面 |
|---|---|---|---|
| サーバー管理 | claude.ai管理コンソール | 起動時＋1時間ごとのポーリング | Teams/Enterprise組織で一元管理したい場合 |
| MDM/OSポリシー | macOS: com.anthropic.claudecode プロファイル、Windows: HKLM\SOFTWARE\Policies\ClaudeCode |
起動時＋30分ごと | Jamf、Intune、グループポリシー導入済みの組織 |
| ファイルベース | システムディレクトリのmanaged-settings.json |
起動時＋ファイル変更時 | Linuxホスト、自社ビルドのマシンイメージ |
| HKCUレジストリ | Windows: HKCU\SOFTWARE\Policies\ClaudeCode |
起動時＋30分ごと | HKLMが書き込めない場合のフォールバック（開発者が編集・削除できるため強制力なし） |
グループごとに1つのプライマリチャネルを選ぶのがポイントだ。Claude Codeは少なくとも1つのポリシーキーを配布している最上位ランクのソースを使い、残りは無視する。
組織の既存インフラに合わせた選択が重要で、たとえばmacOS端末をJamfで管理している組織ならMDMプロファイル方式が最も親和性が高く、Linux中心のエンジニアリング環境ではファイルベースが現実的な選択肢になる。
チームをまたいだポリシー分割：managed-settings.d/
セキュリティチーム、プラットフォームチーム、コスト管理チームがそれぞれポリシーの一部を所有する場合、1つのファイルを共同編集するのは衝突のもとになる。Claude Codeはmanaged-settings.jsonと並置できる**managed-settings.d/ディレクトリ**をサポートしている。
動作ルールは以下の通りだ。
managed-settings.json（メインファイル）を先にマージする- 次に
*.jsonファイルをアルファベット順にマージする - 単一値は後のファイルの値が勝つ
permissions.denyなどのリストは重複を除去しながら結合される
ファイル命名の例：10-telemetry.json（テレメトリ設定）、20-security.json（セキュリティルール）。数値プレフィックスで適用順序を制御できる。
この設計により、各チームが独立してポリシーファイルを管理・更新できる。セキュリティチームが20-security.jsonを更新しても、コスト管理チームの30-cost.jsonには影響しない。大規模組織でよくある「誰かの変更が別チームの設定を壊す」問題を構造的に防ぐ仕組みだ。
ポリシーが届かないケースを事前に把握する
大規模展開で見落とされがちなのが、「ポリシーが届かない条件」の把握だ。以下の条件のいずれかに当てはまると、サーバー管理ポリシーのフェッチがスキップされる。
- サーバー管理ポリシーはTeams/Enterpriseプランへのログインが必須。Console APIキーは別組織のポリシーとして扱われ、自社のclaude.aiポリシーは届かない
- 開発者がシェルで
CLAUDE_CODE_USE_BEDROCKや非デフォルトのANTHROPIC_BASE_URLをexportしているセッションはフェッチをスキップする - クラウドセッションはデバイスのMDMプロファイルやマネージドファイルを読まない
AIゲートウェイを経由させたい場合も注意が必要だ。シェルでANTHROPIC_BASE_URLをexportする方法はテスト用途にとどめ、フリートへの展開ではMDMかマネージドファイルでゲートウェイURLを配布するべきとされている。
これらの「抜け穴」は、展開後に「一部の開発者にだけポリシーが当たっていない」という状況を生む。特にAWS BedrockやGCP Vertex AI経由でAPIを利用している開発者が混在する組織では、事前の棚卸しが不可欠だ。
フェイルクローズ設定：ポリシーなしで起動させない
デフォルトでは、起動時のフェッチが失敗するとキャッシュ済み設定にフォールバックする。初回フェッチ前のマシンはポリシーなしで動作してしまう。これを防ぐには、マネージドソースに**forceRemoteSettingsRefresh: true**を設定する。
{
"forceRemoteSettingsRefresh": true
}
このオプションを有効にすると、api.anthropic.comに到達できない場合はCLIが起動時に終了する。開発者がClaude Codeを使えなくなるというトレードオフを受け入れた上で使う設定だ。セキュリティ要件が厳格な組織（金融・医療・公共機関など）では、このトレードオフを受け入れてでもフェイルクローズを選ぶ判断が合理的になる場面がある。なお、claude authサブコマンドはこの制限から除外されており、認証切れの場合は再サインインが可能。
展開後の確認：/statusとclaude doctor
展開後の確認はマシンごとに行う必要がある。
/statusコマンド：「Setting sources」行にEnterprise managed settingsと配布元（(plist)、(HKLM)、(file)、(remote ...)など）が表示されていれば正常claude doctorコマンド：マネージドソースが表示されないマシンで使用。「Managed settings (remote)」行でフェッチ結果を確認できる。Claude Code v2.1.248以降が必要/permissionsコマンド：マネージドポリシー変更後の実効ルールを確認
1,000人規模の展開では全台を個別確認するのは非現実的なため、展開直後にサンプリング確認を行い、/statusの出力を収集・集計する仕組みを用意しておくことが望ましい。
変更の反映タイミングに注意
| 変更対象 | 反映タイミング |
|---|---|
| サーバー管理ポリシー | 次回起動時、または1時間ごとのポーリング |
| MDMプロファイル・レジストリ値 | 30分ごとのチェック |
modelキー |
次回起動時 |
permissions・hooks・認証情報ヘルパー |
ファイルリロード後、実行中セッションに即時反映 |
また、**ConfigChangeフックはサーバー管理ポリシーの変更時やMDMプロファイルの変更時には実行されない**点も注意が必要だ。さらに、サーバー管理ポリシーはmanaged-mcp.jsonを配布できないため、MCPサーバーのアローリストはallowedMcpServers・deniedMcpServersキーかマシン上のファイルで配布する必要がある。
反映タイミングの差異を把握していないと、「ポリシーを変更したのに即座に効かない」という問い合わせが多発する。展開担当者はこの表を社内のFAQやランブックに組み込んでおくと運用が安定する。
詳細はHow to onboard 1,000 developers to Claude Code without manual setupを参照していただきたい。
