MCP サーバーガバナンス：申請の受付から廃止まで
MCP サーバーのインベントリを管理し、利用前にサーバーを承認し、ツールを一つずつレビューし、定義の変更を新たな判断として扱い、サーバーを確実に廃止する方法を解説します。
決定の概要
MCP サーバーガバナンスでは、各サーバーを、社内システムに対して操作を実行できるソフトウェアとして扱います。すべてのサーバーについて担当者を記載したインベントリを管理し、明確な基準に照らしてサーバーを承認し、サーバー単位だけでなくツールを一つずつレビューし、ツール定義の変更は新たな判断として扱います。ノートパソコン上で動くサーバーは隔離して影響範囲を抑え、サーバーを廃止するときは設定だけでなく認証情報も失効させます。レジストリへの掲載やスキャンの合格は判断材料にはなりますが、それだけで判断が決まるわけではありません。
MCP サーバーガバナンスの対象範囲
MCP サーバーは、エージェントの構成の中で実際の処理を行う部分です。課題の作成やデータベースへのクエリなどのツールを提供し、サーバーが持つ認証情報とアクセス権でそれらを実行します。HTTP 経由でアクセスするリモートのサーバーもあれば、各自のノートパソコン上で起動するローカルのプロセスもあります。
MCP サーバーガバナンスでは、そうしたサーバーのうちチームが使ってよいものを決め、その判断を最新の状態に保ちます。その流れはライフサイクルに沿っています。既存のサーバーを把握し、基準に照らして承認し、ツールをレビューし、変更を監視し、不要になったら廃止します。各段階に担当者と記録が必要です。
これと並ぶのがアクセスガバナンスで、承認済みのサーバーを誰が、どのデータで使ってよいかを決めます。通常はサーバーガバナンスが先です。信頼すると決めていないサーバーへのアクセスを管理しても、あまり意味がないからです。現在ベータ版のプロジェクトである OWASP の MCP Top 10 は、サプライチェーン攻撃、ツールポイズニング、シャドーMCP サーバーをリスクに含めています。
最新の状態を保てるインベントリをつくる
MCP サーバーは、誰かが承認する前から使われていることがよくあります。MCP プロジェクトのガイダンスでも、事前に相談されることはないものと想定しておくよう管理者に伝えています。まずは、すでに存在するものを一覧にしましょう。ゲートウェイや AI クライアントの管理設定を通じて接続されたリモートサーバーと、Claude Code や Cursor などのツールの設定ファイルにあるローカルサーバーです。
クライアントの設定ファイルは決まった場所に保存されるため、エンドポイント管理ツールで継続的に収集できます。デバイスのインベントリからわかるのは何が設定されているかであり、実際に何が接続され、使われているかとは異なります。証拠としてではなく、話し合いのきっかけとして扱いましょう。
後で判断をすばやく下せるよう、各サーバーについて十分な情報を記録します。
| 項目 | 重要な理由 |
|---|---|
| オーナー | 変更を承認し、問い合わせに対応する人が明確になる |
| 公開元と入手元 | 誰を信頼しているのか、アップデートがどこから届くのかがわかる |
| バージョンまたはエンドポイント | 変更に気づき、セキュリティアドバイザリーに対応できる |
| 実行場所 | ローカルサーバーにはエンドポイント側の対策が必要で、リモートサーバーではゲートウェイを使える |
| 認証情報とスコープ | サーバーが誰かの権限で何をできるかがわかる |
| 有効化したツール | エージェントが実際にサーバーに何を依頼できるかがわかる |
| ユーザーとチーム | 変更や廃止の影響を受けるのが誰かがわかる |
| 次回レビュー日 | 承認がなし崩しに恒久化するのを防ぐ |
明確な基準に照らしてサーバーを承認する
短く明文化した基準を公開しておけば、承認がより速く、一貫したものになります。MCP プロジェクトの組織向けガイダンスでは、バージョンを固定した審査済みサーバーの許可リストと、身元を確認できる公開元、閲覧可能なソースコード、来歴メタデータ、ソフトウェア部品表（SBOM）といった基準を提案しています。
レジストリが役立つのはサーバーを見つけるときであり、承認の代わりにはなりません。まだプレビュー段階の公式 MCP Registry は、公開元が名前空間を管理していることを確認し、セキュリティスキャンはパッケージレジストリや下流のカタログに任せています。プロジェクト自身の言葉を借りれば、レジストリへの掲載は推奨を意味するものではありません。承認の判断のほとんどは、次の質問で確認できます。
- サーバーの公開元は誰で、ソースコードを読むことはできますか？
- ローカルで実行する必要がありますか、それともリモート版がありますか？
- どのように認証し、誰の認証情報を使いますか？
- どのスコープを要求し、それは機能する範囲で最小限のものですか？
- どのツールを提供し、そのうちどれがデータを変更したり人に連絡したりしますか？
- どのデータを読み取り、その結果はどこに送られますか？
- アップデートはどのように公開され、脆弱性の情報はどうやって入手できますか？
共有システムにはリモートサーバーを優先する
SaaS の API をラップするだけのサーバーなら、すべてのノートパソコンで動かしても得るものはありません。MCP のガイダンスでは、リモート版がある場合はそちらを推奨しています。リモート版はユーザーのマシン上でコードを実行せず、ローカルファイルに保存したトークンではなくプロトコルの認可フローを使い、修正も一か所で適用できるためです。
リモートサーバーには、すべてのリクエストにアクセスルールと記録が適用される、管理された経路を通じてアクセスすることもできます。ローカルサーバーは、作業ツリーの読み取りやローカルツールの操作など、本当にそのマシンが必要な作業に限って使いましょう。
サーバーだけでなく、ツールを一つずつレビューする
サーバーを承認することは、そのサーバーができることすべてを承認することとは違います。たとえばプロジェクト管理用のサーバーには、課題の閲覧、編集、削除、権限の変更を行うツールがあるかもしれません。業務フローに必要なツールだけを有効にし、それ以外は無効のままにしておきましょう。
ドキュメントだけでなく、ツール定義も読んでください。ツールの名前や説明はモデルが読む指示であり、悪意のあるサーバーはそこに命令を隠すことができます。Invariant Labs は、2025 年 4 月にこの攻撃を実証した際、これをツールポイズニングと呼びました。MCP の仕様では、ツールが読み取り専用であることを示すヒントなどのツールアノテーションは、サーバーが信頼できる場合を除き、信頼できないものとしてクライアントが扱わなければならないとしています。
ツールの一覧は、呼び出し元によって異なる場合もあります。現在の仕様では、リクエストが提示する認可に応じて、サーバーが異なるツールを返すことが認められています。そのため、各ロールから実際に見えるツールをレビューしてください。
変更は新たな判断として扱う
サーバーは、承認された後でツール定義を変更できます。これはラグプルと呼ばれることもあります。プロトコルは、定義が変わったときにクライアントが改めて確認を求めることを義務付けていないため、その対策はクライアント、ゲートウェイ、または運用プロセスで担う必要があります。
承認したものは固定しましょう。ローカルのパッケージはバージョンを固定します。ただし、npx や uvx などのランチャーで固定できるのはトップレベルのパッケージだけです。一方、ダイジェストで固定したコンテナイメージなら、依存関係ツリー全体を固定できます。ツールについては、レビュー済みの定義を記録し、変更されたものは誰かがレビューするまで保留します。
自社側の変更も対象です。新しいスコープ、新しいチーム、本番環境などの新しい環境が加わるときは、承認を黙って広げるのではなく、改めてレビューする機会にしましょう。
ローカルで動くサーバーを隔離する
ローカルサーバーは、ユーザーの権限で動く通常のプロセスです。そのユーザーが読めるファイルや環境変数を読み取り、ネットワーク上のどこにでも接続できます。MCP プロジェクトは、プロセスの分離を何よりも効果の高い対策としています。
各自に任せるのではなく、標準の設定方針を決めておきましょう。サードパーティのサーバーは、必要なもの以外は何もマウントしないコンテナで実行し、各サーバーにはそのサーバー専用の、範囲を絞った認証情報だけを与え、ファイルシステムへのアクセスと外部への接続を制限します。ワンクリックでのインストールを提供するクライアントは、実行前に実際のコマンドをそのまま表示しなければなりません。
承認ごとに記録を残す
チャットのスレッドにしか残っていない承認は、後から見直すのが困難です。短い記録を残しておけば判断の内容が明確になり、次のレビュー担当者が照らし合わせる基準にもなります。以下は一例です。
記録はインベントリの該当項目と一緒に保管し、サーバー、ツール、認証情報が変わるたびに更新してください。
| 項目 | 例 |
|---|---|
| サーバー | 課題管理ツール（ベンダーがホストするリモートサーバー） |
| オーナー | プラットフォームエンジニアリングのリーダー |
| 承認範囲 | エンジニアリングチーム、本番ワークスペース |
| 有効化したツール | 課題の検索、課題の閲覧、課題の作成 |
| 無効のままのツール | 課題の削除、プロジェクト権限の変更 |
| 認証情報 | 各ユーザー自身の OAuth 認可（課題関連のスコープに限定） |
| 条件 | 最初の 1 か月間は課題の作成をレビューする |
| 次回レビュー | 3 か月後（ツールやスコープが変わった場合はそれより前） |
サーバーを確実に廃止する
サーバーの廃止は、設定の項目を削除するだけでは終わりません。利用していた全員のアクセス権を削除し、サーバーが保持していた認証情報を失効させ、可能な範囲でローカルの設定も削除します。MCP のガイダンスでは、サーバーを削除する際に、そのサーバーが保持していたものをすべてローテーションすることを提案しています。
履歴は残しておきましょう。サーバーが行った操作の記録は、サーバーがなくなった後も調査に役立ちます。また、廃止したサーバーがインベントリに再び現れた場合は、新しい申請として扱うべきです。
Durinが適している場所
Durin は、リモートの MCP サーバーを管理された 1 つの経路にまとめます。メンバーはカタログから接続を申請するか、アドレスと利用目的を添えてカスタムサーバーを提案でき、管理者がその申請を承認または却下します。承認しただけで何かが有効になることはありません。その後も、プロバイダーの設定、ツールのレビュー、読み取り専用のテスト、有効化の手順が続きます。
各ツールは、データを読み取るのか変更するのか、どのリソースにアクセスしてよいかも含めて、使用前にレビューされます。未レビューのツールはブロックされたままです。サーバーがツールの定義を変更した場合、そのツールには改めてレビューが必要になり、それまでの承認は取り消されます。管理者は、接続の利用範囲を特定のチームに限定したり、設定と履歴を残したままインストールを無効にしたりできます。
Durin の外にあるサーバーについては、シャドーMCP の検出機能が、登録済みデバイスに設定されている MCP サーバーの報告を収集します。報告は観測結果であり、現在接続されていることを証明するものではありません。また、レビューのステータスによってアクセスがブロックされることもありません。検出されたサーバーを管理するには、「接続」から追加し、クライアントの接続先を Durin に切り替えてください。