2026年9月3日現在、Claude Code v2.1.259以降なら、管理者はmanagedMcpServersという1つの管理設定から、承認済みのHTTP/SSE MCPサーバーを組織の利用者へ直接配布できます。従来のmanaged-mcp.jsonや利用者追加分の許可リストとは役割が異なるため、まず3方式を分け、その後に7段階で小さく展開するのが安全です。
先に結論
- 配布：
managedMcpServersは管理設定からHTTP/SSEサーバーを配り、利用者側では削除できない組織配布向けの仕組みです。 - 統制：v2.1.259では
allowedMcpServersの対象が、利用者・プロジェクト・プラグインなどから追加されるMCPへ整理されました。deniedMcpServersは管理配布分にも優先します。 - 導入：全社一括ではなく、棚卸し→設計→管理設定→認証→ポリシー→カナリア→段階展開の7手順で進めます。
対象読者：Claude Codeを業務導入する開発リード、Platform Engineering、SRE、情シス、セキュリティ担当。今日やること：現行MCPを「組織配布」「利用者追加」「廃止」の3列で棚卸ししてください。
この記事はAnthropicの公開ドキュメントと2026年9月2日付の公式changelogをもとにした構成例です。特定企業の導入実績や未公開の測定値ではありません。MCP接続そのものが初めてなら、先にClaude Code MCP実践ガイドで.mcp.jsonとスコープの基本を確認すると読みやすくなります。
Managed MCP Serversで何が変わったのか
Anthropicは2026年9月2日、Claude Code v2.1.259の更新として管理設定managedMcpServersを追加しました。管理者がHTTPまたはSSEのMCPサーバー定義を管理設定に置くと、Claude Codeはそれを組織から提供された接続として読み込みます。定義の各エントリは.mcp.jsonのサーバー定義と同じ形で、commandを指定するstdio型は読み飛ばされます。
重要なのは「MCPの設定ファイルが1つ増えた」ことではありません。サーバー定義の配布を、端末へ別ファイルとして置く作業から、既存の管理設定配布へ寄せられる点です。Team/Enterpriseではサーバー管理設定をAnthropic側から配信でき、MDMやOS上のmanaged-settings.jsonでも同じ管理層を構成できます。権限、モデル、フックなどの組織管理設定とMCP配布を同じ変更管理に載せやすくなりました。
v2.1.259で許可リストの意味も整理された
同日のchangelogでは、allowedMcpServersの扱いも明確化されています。組織自身がmanagedMcpServersで配る接続は、同じURLを許可リストへ重ねて書かなくても利用できます。一方、ユーザー設定、プロジェクトの.mcp.json、ローカル設定、--mcp-config、エージェント定義、プラグイン、claude.aiコネクターなど、利用者側から入る接続は引き続き許可リストで制御されます。
deniedMcpServersは例外です。拒否はすべてのスコープに優先するため、管理者が配ったサーバーでも拒否条件に一致すればブロックされます。「管理配布だから無条件で動く」わけではありません。URLの統廃合や緊急遮断を想定し、拒否リストを独立した停止装置として扱います。
3つのMCP配布方式を混同しない
| 方式 | 置き場所 | 向く用途 | 利用者による変更 |
|---|---|---|---|
.mcp.json |
プロジェクト | リポジトリ固有の共有設定 | リポジトリ変更権限の範囲で可能 |
managed-mcp.json |
OSの管理パス | 端末管理でMCP集合を固定 | 通常不可 |
managedMcpServers |
Claude Codeの管理設定 | HTTP/SSE接続を組織から配布 | 削除不可 |
.mcp.jsonは開発チームがコードと一緒に管理する方式です。プロジェクトごとに違うMCPを宣言しやすい反面、中央管理の境界にはなりません。managed-mcp.jsonはmacOSなら/Library/Application Support/ClaudeCode/managed-mcp.json、Linux/WSLなら/etc/claude-code/managed-mcp.json、WindowsならC:\Program Files\ClaudeCode\managed-mcp.jsonに置く専用ファイルで、MCPの集合を端末側から固定したい場合に向きます。
managedMcpServersは、管理設定の中にサーバー定義を含める方式です。すでにpermissionsやavailableModelsを管理設定で配っている組織なら、変更申請、レビュー、カナリア展開、ロールバックを同じ運用面にまとめられます。比較するときはMCPのOAuth認証とチーム配布もあわせてください。
導入前に決める4つの境界
管理設定を先に書くと、あとで認証や障害対応の責任分界が崩れます。構成ファイルより前に、次の4点を決めます。
境界1：サーバーの所有者
社内MCP、SaaS公式MCP、第三者MCPを同じ扱いにしないことです。社内MCPなら運用チーム、SaaSなら契約管理者とベンダー、第三者MCPなら採用可否を決めるレビュー担当を明記します。障害時に「Claude Codeの不具合なのか、MCPサーバー側なのか」を切り分ける連絡先まで台帳へ入れます。
境界2：読み取りと書き込み
MCPが提供するツールを、参照系と変更系に分けます。ドキュメント検索とチケット作成では、誤操作時の影響が違います。サーバーを配布できることと、その全ツールを無条件で許可することは別です。Claude Code全体のツール権限はチーム向け権限設計ガイドと合わせて設計します。
境界3：認証主体
共有トークンを全端末へ配るのか、各利用者がOAuthで自分として認証するのかを決めます。監査性を重視する業務システムでは、利用者ごとのOAuthを優先します。管理設定に秘密値を直書きせず、MCPサーバー側でも最小権限のスコープを用意してください。
境界4：停止方法
配布開始より先に停止条件を決めます。認証障害、誤更新、想定外の書き込み、ベンダー障害が起きたら、管理設定から定義を外すのか、deniedMcpServersで緊急遮断するのかを決めます。削除や拒否が端末へ反映されるまでの監視方法も運用手順に含めます。
Managed MCP Serversを7手順で導入する
ここからは、架空の社内ドキュメントMCPを配る想定シナリオで説明します。ホスト名mcp.example.comは例示用です。実在サービスへの接続情報ではありません。
手順1：現行MCPを3列で棚卸しする
各リポジトリの.mcp.json、ユーザー設定、プラグイン、claude.aiコネクターを確認し、「組織が配る」「利用者が追加できる」「廃止する」に分類します。サーバー名だけでなく、実URL、transport、認証方式、提供ツール、データ送信先、所有者を記録します。
あなたはPlatform Engineering担当です。以下のMCP台帳を、
1. managedMcpServersで組織配布
2. allowedMcpServersで利用者追加を許可
3. deniedMcpServersで拒否
4. 廃止候補
に分類してください。判断理由、データ送信先、書き込み権限、所有者の不足も指摘してください。
[ここにMCP台帳を貼る]手順2：HTTP/SSEだけを配布候補にする
v2.1.259のmanagedMcpServersが受け付けるのはHTTPとSSEです。commandを持つstdio型のエントリはスキップされます。ローカルプロセス起動が必要なMCPは、従来の管理ファイルや別の配布手段に残すか、組織で管理できるリモートMCPへ移行するかを検討します。
新規導入ならHTTPを第一候補にします。AnthropicのMCPドキュメントではSSEを後方互換のための方式として扱い、リモートサーバーではHTTPを推奨しています。既存SSEを即座に壊す必要はありませんが、新設と更新の判断基準は分けます。
手順3：管理設定にサーバー名をキーとして定義する
managedMcpServersはサーバー名をキーにしたオブジェクトです。Claude Desktopで使われる同名キーの配列形式ではなく、.mcp.jsonのmcpServersと同じ「名前→定義」の形で書きます。
{
"managedMcpServers": {
"internal-docs": {
"type": "http",
"url": "https://mcp.example.com/docs/mcp"
},
"incident-events": {
"type": "sse",
"url": "https://mcp.example.com/incidents/sse"
}
}
}キー名は利用者に見える識別子になるため、用途が伝わり、将来も変えにくい名前を選びます。prodのような短すぎる名前ではなく、internal-docsのように対象が分かる名前にします。
手順4：利用者ごとの認証に分離する
配布するのは接続先と方式であり、共有資格情報ではありません。HTTP型MCPがOAuth 2.0に対応しているなら、各利用者が/mcpから認証します。セッション外から認証する公式CLIはclaude mcp login <name>です。OAuthトークンは安全な資格情報ストアに保存され、自動更新されます。
OAuth非対応でヘッダーが必要な場合も、管理設定へ固定トークンを埋め込む設計は避けます。認証経路とローテーション手順を別途決め、誰の権限でMCPが動くかを監査可能にしてください。
次のMCP認証設計をレビューしてください。
共有トークン、利用者別OAuth、サービスアカウントの3案について、
本人識別、最小権限、失効、ローテーション、監査ログ、退職者対応の6軸で比較し、
本番採用前に確認すべき未決事項だけを列挙してください。
[認証要件を貼る]手順5：利用者追加分と緊急拒否を分ける
組織配布分と利用者追加分を同じ許可リストで二重管理しないのがv2.1.259の要点です。次の構成例では、internal-docsを組織から配り、利用者が自分で追加できるMCPはゼロにし、廃止URLを拒否しています。
{
"managedMcpServers": {
"internal-docs": {
"type": "http",
"url": "https://mcp.example.com/docs/mcp"
}
},
"allowedMcpServers": [],
"deniedMcpServers": [
{ "serverUrl": "https://mcp.example.com/legacy/*" }
]
}利用者による追加を一部認める場合は、allowedMcpServersへserverUrlまたはserverCommandを追加します。serverNameは利用者が変えられるラベルなので、セキュリティ境界としてはURLまたは完全なコマンドを優先します。拒否と許可が両方一致した場合は拒否が勝ちます。
手順6：少人数でカナリア展開する
まずPlatform/SREなど少人数へ配り、接続が見えること、認証できること、必要なツールだけが呼べること、拒否対象が出ないことを確認します。Claude Codeでは/mcpで接続状態と認証を確認でき、CLIではclaude mcp listとclaude mcp get <name>で構成を確認できます。
# 配布されたMCPの一覧と状態を確認
claude mcp list
# 特定サーバーの詳細を確認
claude mcp get internal-docs確認結果は「接続できた」だけで終わらせません。読取ツール、書込ツール、認証期限切れ、利用者権限不足、拒否リスト一致、MCPサーバー停止の各ケースで期待する表示と連絡先を決めます。ここでの値は環境依存なので、未実施の応答時間や成功率を記事の一般値として置かないでください。
手順7：段階展開とロールバックを同じ変更票にする
対象を開発基盤チーム、特定プロジェクト、全開発者の順に広げます。各段階で、対象者、開始時刻、設定バージョン、MCPサーバー所有者、ロールバック担当を記録します。異常時は管理設定から対象エントリを外し、必要ならdeniedMcpServersでURLを緊急遮断します。
以下のManaged MCP Servers変更案から、
カナリア対象、合格条件、中止条件、監視項目、連絡先、ロールバック手順を
1枚の変更票に整理してください。未記入の事実を推測せず「要確認」と表示してください。
[変更案を貼る]
管理設定を本番へ出す前に、権限・認証・停止手順を第三者レビューしませんか。
UravationのClaude Code導入支援では、既存リポジトリとセキュリティ要件に合わせて、管理設定、MCP、フック、権限の構成を一緒に整理します。
管理設定の配布経路と優先順位
Claude Codeの管理設定は、主に3経路で配れます。Team/Enterpriseのサーバー管理設定、macOS/WindowsのMDM、OS上のmanaged-settings.jsonです。公式の優先順位は、サーバー管理設定、MDM、ファイルの順です。既定は「最も優先度が高い管理ソースだけが採用される」ため、複数経路へ同じつもりで分散しても自動的に合成されるとは限りません。
| 管理経路 | 主な対象 | 更新方法 | 注意点 |
|---|---|---|---|
| サーバー管理設定 | Team/Enterprise | 管理コンソールから配信 | 端末側より高い優先度 |
| MDM | macOS/Windows管理端末 | 構成プロファイル/ポリシー | JSONの型とエスケープを確認 |
managed-settings.json |
各OS | 構成管理ツール等で配置 | 管理者権限のパスを使う |
ファイル方式の標準パスはmacOSが/Library/Application Support/ClaudeCode/managed-settings.json、Linux/WSLが/etc/claude-code/managed-settings.json、WindowsがC:\Program Files\ClaudeCode\managed-settings.jsonです。ユーザーが書き換えられる通常のsettings.jsonへmanagedMcpServersを書いても、管理配布としては扱われません。
本番投入前のレビュー用プロンプト5選
MCPに接続できるかだけでなく、設定差分と運用手順をレビューするためにClaude Codeを使います。機密値は貼らず、未記入を推測させない指示を必ず加えます。前章の台帳分類、認証レビュー、変更票作成と合わせて5つです。
設定差分から影響範囲を洗い出す
次のmanaged-settings.jsonの変更前後を比較し、
追加・削除されるMCPサーバー、transport、接続先ホスト、
allowedMcpServersとdeniedMcpServersへの影響を表にしてください。
推測はせず、JSONから判断できない項目は「不明」と書いてください。
[変更前JSON]
[変更後JSON]障害訓練の確認項目を作る
Managed MCP Serversの障害訓練チェックリストを作ってください。
想定は「認証失敗」「MCPサーバー停止」「誤った書き込みツール公開」
「拒否リストの緊急適用」です。
各項目に、観測点、一次切り分け、停止操作、復旧判定、証跡を含めてください。
未提示の社内手順は作らず「要確認」にしてください。プロンプトの出力はレビューのたたき台です。ポリシーの正否は公式ドキュメント、実際の管理設定、MCPサーバー側の仕様を突き合わせて確定します。Claude Codeの提案だけで本番設定を自動変更しないでください。
失敗しやすい4パターンと直し方
- ❌ stdio型を
managedMcpServersへ移す：commandを含むエントリはスキップされます。⭕ 修正：HTTP/SSEだけを管理設定で配り、stdioはmanaged-mcp.json等の別方式に残します。 - ❌ 管理配布分を
allowedMcpServersへ重複登録する：v2.1.259では組織配布分に許可リスト登録は不要です。⭕ 修正：許可リストは利用者側から追加されるサーバーの境界として設計します。 - ❌
deniedMcpServersの既存条件を見ずに配る：拒否は管理配布分にも優先します。⭕ 修正：配布URLを既存拒否パターンと照合し、緊急遮断用の条件を別に記録します。 - ❌ 全社員へ一度に展開する：認証やサーバー側権限の不一致が同時多発します。⭕ 修正：少人数のカナリアで読取・書込・失効・障害の各ケースを確認し、ロールバックできる状態で段階展開します。
MCPは外部データとツール実行をClaude Codeへ持ち込む境界です。法人導入全体の観点はClaude Code法人導入セキュリティチェックリストも参照してください。
導入判定チェックリスト
- □ 配布対象がHTTPまたはSSEである
- □ サーバー名、URL、所有者、データ送信先を台帳化した
- □ 読取ツールと書込ツールを分けてレビューした
- □ 利用者ごとの認証方式と失効手順を決めた
- □
allowedMcpServersを利用者追加分として設計した - □
deniedMcpServersとの一致を確認した - □ 管理設定の配布元と優先順位を確認した
- □ カナリア対象と合格・中止条件を決めた
- □ 管理設定から外す手順と緊急拒否の手順を用意した
- □
/mcpとclaude mcp listで反映を確認する担当を決めた
変更記録に残すべき項目
管理MCPは、設定ファイルだけを保存しても十分に追跡できません。同じURLでもMCPサーバー側の公開ツールや認証スコープが変われば、Claude Codeから実行できる操作が変わるからです。変更票には、少なくとも次の情報を残します。
| 記録項目 | 確認する内容 | 証跡の例 |
|---|---|---|
| 設定の識別 | 配布元、設定バージョン、変更者、レビュー者 | 管理コンソールの変更履歴、構成管理のコミット |
| 接続先 | サーバー名、完全なURL、HTTP/SSE、所有者 | 承認済みMCP台帳 |
| 認証 | OAuthか別方式か、要求スコープ、失効担当 | IdP設定、MCPサーバーの認証仕様 |
| ツール | 読取・書込の区分、追加・削除されたツール | MCPサーバーのtools/list結果や公開仕様 |
| ポリシー | 許可・拒否との一致、緊急停止条件 | レビュー済み管理設定 |
| 展開 | カナリア対象、全体展開日、中止条件 | 変更票、反映確認記録 |
特に見落としやすいのが、MCPサーバー側の変更です。Claude Codeの管理設定が同じでも、サーバーが新しい書き込みツールを公開すればリスクは変わります。管理設定の更新日だけでなく、MCPサーバーのリリースノートやツール一覧を定期レビューの対象にします。
ロールバック記録には「元のJSON」を貼るだけでなく、誰が、どの管理経路で、どの状態へ戻すかを書きます。サーバー管理設定を使っているのに、端末ファイルだけを戻しても優先順位の関係で反映されない可能性があります。実際に採用している管理ソースを起点に戻してください。
次の管理MCP変更記録を監査してください。
接続先、認証、ツール権限、許可・拒否、カナリア、中止条件、ロールバックのうち、
証跡がない項目を列挙してください。
記載がない事実は補わず、不足理由と確認先だけを示してください。
[変更記録を貼る]この形式にすると、開発チームは「使えるか」、セキュリティ担当は「何が許可されたか」、運用担当は「止められるか」を同じ変更票から確認できます。MCPサーバーを追加するたびにゼロから議論せず、確認軸を再利用できるのも利点です。
managed-mcp.jsonから移行する判断基準
すでにmanaged-mcp.jsonでMCPを固定配布している組織は、新しいキーが増えたからという理由だけで全件を移さないでください。判断軸は「既存の管理設定運用へ統合したいか」と「stdioを含むか」です。HTTP/SSEだけを配り、権限やフックと同じ管理設定経路でレビュー・配信したいなら、managedMcpServersへ寄せる意味があります。一方、端末上のMCP集合を専用ファイルで固定したい、またはstdio型が必要なら、従来方式を残す理由があります。
| 現在の状態 | 基本判断 | 先に確認すること |
|---|---|---|
| HTTP/SSEのみ | managedMcpServersを候補にする |
管理設定の配布元、拒否条件、利用者認証 |
| stdioを含む | 従来方式を残すか分離する | ローカルコマンド、実行権限、配布責任者 |
| 利用者追加も許可 | 組織配布と許可リストを分離する | URL/コマンド単位の許可・拒否 |
| 複数の管理経路がある | 移行前に優先順位を整理する | サーバー管理、MDM、管理ファイルの採用元 |
移行はコピーではなく再承認として扱う
旧ファイルのJSONをそのまま別キーへ移すのではなく、サーバーごとに再承認します。まずエントリをHTTP、SSE、stdioに分類し、HTTP/SSEについて所有者、接続先、認証方式、公開ツールを確認します。次に管理設定へ候補を作り、既存のallowedMcpServersとdeniedMcpServersへどのように一致するかをレビューします。
移行前後の証跡には、旧定義、新定義、除外したstdioエントリ、ポリシー差分、検証担当、戻し先を含めます。「JSONとして同じURLがある」ことだけでは同等性を証明できません。認証スコープやMCPサーバー側のツール集合が変わっていないかも確認対象です。
二重配布を避けて切り替える
同じサーバーを複数経路から配ると、どの設定が採用されたかを利用者が判断しにくくなります。検証環境では、採用している管理ソースとMCPサーバー名を記録し、claude mcp get <name>で接続先を確認します。切り替え日は、旧経路を外す操作と新経路を有効にする操作を同じ変更票に置き、異常時にどちらへ戻すかを明記します。
全体展開後も、旧ファイルをすぐ削除するのではなく、社内の保存ルールに従って監査用の原本を残します。ただし、端末上で有効な配布元を複数残すことと、履歴として安全な場所に保存することは分けて考えてください。運用中の設定は一意にし、履歴は変更管理側で保持します。
移行完了は利用者視点で判定する
管理画面の保存成功ではなく、対象端末で期待したMCPだけが見え、各利用者が正しい本人権限で認証し、拒否対象が使えず、緊急停止が反映されることをもって完了とします。ここまで確認できない場合は、対象を広げず、旧経路へ戻して原因を切り分けます。
Managed MCP ServersのFAQ
Q. managedMcpServersはどのバージョンから使えますか？
A. Anthropicの2026年9月2日付changelogでは、Claude Code v2.1.259の追加機能として記載されています。組織で使う前に、対象端末のClaude Codeが対応版以降であることを確認してください。
Q. stdio型MCPも配れますか？
A. managedMcpServersでは配れません。公式changelogはHTTP/SSEを対象とし、commandを持つエントリはスキップするとしています。stdioを中央固定する場合はmanaged-mcp.jsonなど別方式を検討します。
Q. allowedMcpServersにも同じURLが必要ですか？
A. v2.1.259では、組織がmanagedMcpServersで配布するサーバーは追加登録不要です。allowedMcpServersは、利用者やプロジェクトなどから追加されるMCPを制限するために使います。
Q. 管理者が配ったMCPを緊急停止できますか？
A. 管理設定から定義を外す方法に加え、deniedMcpServersで対象URLを拒否できます。拒否リストは管理配布分にも優先します。実際の停止手順と反映確認は事前に訓練してください。
Q. managed-mcp.jsonからすぐ移行すべきですか？
A. 一律移行ではありません。端末管理でMCP集合を固定したい場合やstdioが必要な場合は、managed-mcp.jsonの役割が残ります。HTTP/SSEを既存の管理設定運用へ統合したい場合にmanagedMcpServersが向きます。
Q. 通常のsettings.jsonへ書いても動きますか？
A. 組織配布として有効になるのは管理者が制御する管理設定ソースです。通常のユーザー設定やプロジェクト設定へ同じキーを書いて、利用者が管理MCPを自己追加する用途では使えません。
結論と次の一歩
managedMcpServersは、MCPを「各開発者が追加する便利機能」から「組織が責任を持って配布する開発基盤」へ移すための選択肢です。ただし、設定キーを追加しただけでは安全になりません。サーバー所有者、書き込み権限、利用者認証、拒否リスト、ロールバックを1つの運用単位として扱う必要があります。
- 今日：既存MCPを組織配布・利用者追加・廃止の3列で棚卸しする。
- 今週：HTTP/SSEの1サーバーを選び、管理設定と拒否条件をレビューする。
- 本番前：少人数で認証・読取・書込・障害・緊急停止を確認し、証跡を残す。
設定例を自社リポジトリと運用に合わせたい方へ
UravationではClaude Codeの個別指導と導入支援を提供しています。MCPだけでなく、権限、フック、サンドボックス、管理設定を含む構成を、実際の開発フローに合わせて整理できます。相談内容が固まっていなくても、現行設定の棚卸しから始められます。具体的な構成レビューはお問い合わせ・無料相談から連絡してください。
次回予告：管理設定を複数経路で配る場合のmanagedSourcesBehaviorと、優先順位・マージ時のレビュー方法を扱います。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・シリーズ累計50,000部突破）。SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆。
公式一次情報
- Anthropic「Claude Code Changelog」（2026年9月2日、v2.1.259） https://code.claude.com/docs/en/changelog
- Anthropic「Connect Claude Code to tools via MCP」 https://code.claude.com/docs/en/mcp
- Anthropic「Control MCP server access with managed MCP configuration」 https://code.claude.com/docs/en/managed-mcp
- Anthropic「Claude Code settings」 https://code.claude.com/docs/en/settings
- Anthropic「Enterprise deployment overview」 https://code.claude.com/docs/en/third-party-integrations
- Anthropic「Security」 https://code.claude.com/docs/en/security
仕様は更新されます。この記事は2026年9月3日時点の公式情報に基づきます。導入時は上記changelogと公式ドキュメントの最新版を再確認してください。
