Claude CodeのmanagedMcpServersを組織運用する

結論：HTTP・SSEだけを管理設定へ置き、配布前にtoolとデータを審査する

一次情報はClaude Code公式changelogのv2.1.259、および公式settingsです。changelogはHTTP/SSEサーバーの組織配布と、commandを指定するentryのスキップを明記しています。設定が存在することだけを確認せず、利用者の端末でどのserverとtoolが読み込まれたかをreadbackしてください。

managedMcpServersと他のMCP設定を比較する

方式	対象と向く場面	確認すべき境界
managedMcpServers	組織がHTTP・SSE serverを全員へ提供	全利用者への影響、tool、認証、停止手順
.mcp.json	project単位の共有設定	repositoryの出所、review、clone後の挙動
個人MCP設定	一人の試験やローカル用途	業務データを送らない、期限を決める
command型server	ローカルプロセスを起動する構成	managedMcpServersではentryがスキップされる

管理設定は、便利なserverを一度登録すれば利用者の判断が不要になる機能ではありません。組織で配る以上、serverの所有者、提供目的、許可するrepository、認証の更新担当、ログの保持範囲、障害時の連絡先を設定変更と同じ台帳へ置きます。利用者に見えないままデータが外部へ送られる設計は採用しません。

HTTPとSSEはネットワーク越しに接続するtransportです。URLを置くだけで通信が安全になるわけではなく、TLS、認証、endpointの到達範囲、proxy、server側のtool実装を確認します。serverが返す説明文だけを信頼せず、実際のrequestとresponseに含まれるデータをテスト用の無害な入力で確認してください。

導入手順：一つのread-only serverを8ステップで配る

1. serverの業務目的、所有者、利用対象、停止条件を一文で定義します。
2. HTTPまたはSSEのtransport、接続先、認証方式、TLS条件をserver管理者から取得します。
3. commandを実行するentryを混ぜず、公式仕様で対象となるserver形を確認します。
4. 公開されるtoolを一覧化し、read-onlyと書込・送信・削除操作を分けます。
5. テスト用repositoryと無害なデータを用意し、serverが受け取る項目と返す項目を記録します。
6. 組織のmanaged settingsへ変更を入れる前に、管理者二名でentry、URL、認証、scopeをレビューします。
7. 代表端末でClaude Codeを再起動または設定反映し、読み込まれたserverとtoolをreadbackします。
8. 利用量、エラー、データ送信、権限逸脱を観測し、問題があればmanaged entryを停止して利用者へ通知します。

初回は検索や参照だけのtoolに限定します。書込みtoolを同時に配ると、server側の障害、誤ったrepository、Claudeの判断が一つの変更へ連鎖します。read-onlyで接続、認証、timeout、監査記録を確認してから、業務影響の小さい一つの書込み操作を別の承認で追加してください。

認証情報を設定ファイルやrepositoryへ直書きしないことも重要です。管理された認証経路を使い、ログ・エラー・screen shareに秘密情報が出ないことを確認します。認証が切れた時に無制限に再試行したり、利用者へ別の認証情報を配布したりせず、server ownerへエスカレーションします。

反映後の確認は、設定ファイルの存在ではなく動作結果で行います。代表端末のversion、対象組織、server名、transport、tool一覧、確認時刻、test結果を保存します。設定を受け取れない端末があれば、全員に届いたとみなさず、managed settingsの適用状態と接続経路を分けて調べます。

企業運用の判断：全員へ配る価値と集中リスクを比べる

全員へ同じMCPを提供すると、設定のばらつきと個人管理の負担を減らせます。一方、serverの障害や誤設定が全利用者へ同時に影響します。導入判断は「便利か」ではなく、影響範囲、データ分類、停止の速さ、代替手段、ownerの稼働時間で行います。

既存のMCPセキュリティ確認はserverの出所、権限、送信範囲、認証を扱い、MCP接続トラブルの切り分けは接続失敗を扱います。managed settings変更の承認と組み合わせ、entryの追加・変更・削除を同じchange recordへ残してください。

また、全員へ配る設定と、各projectが必要とするserverを混ぜないことがカニバリゼーションと権限過多を防ぎます。組織共通のserverは利用目的が広く、データ範囲が限定され、停止経路が明快なものに絞ります。特定projectだけの接続はproject側で所有者と期限を持たせ、managedへ昇格させる条件を決めます。

チェックリスト：managed MCPを有効化する前に

目的とownerがあるか／HTTPまたはSSEのtransportを確認したか／command型entryを除外したか／URLとTLSを検証したか／認証の保管場所と更新者が明確か／toolをread-onlyと変更操作へ分類したか／送受信データを無害な入力で確認したか／代表端末でserverとtoolをreadbackしたか／停止とrollbackができるか／利用者への通知方法があるか、を確認します。

接続できない時に、command型へ置き換えて回避するのは危険です。managedMcpServersの対象外なら、方式の要件を満たすserverへ戻し、個人設定を全員へコピーしないでください。接続を復旧できない場合は、そのserverだけをHOLDし、他のClaude Code運用を止める範囲を管理者が判断します。

よくある質問

managedMcpServersは誰に適用されますか？

公式changelogでは、組織がHTTP・SSEのMCP serverをevery userへ提供するmanaged settingとして説明されています。契約や管理設定の適用範囲は組織ごとに確認し、代表端末で実際の反映を記録します。

既存の.mcp.jsonは不要になりますか？

不要にはなりません。project固有のserverと組織共通のserverは目的とownerが異なります。全員へ配る必要がない接続をmanagedへ移さず、出所とreviewを分けます。

HTTP・SSEならcommandより安全ですか？

transportだけで安全性は決まりません。TLS、認証、serverのtool、データ範囲、監査、停止手順を確認し、read-onlyから段階的に広げます。

公式情報と無料診断

managedMcpServersの追加はClaude Code公式changelog、設定のscopeは公式settingsで公開直前に確認します。Miraigentの無料診断では、MCPの出所、データ経路、権限、監査、停止条件を企業の導入判断へ整理できます。