MCP server を社内で増やし始めると、最初は「どの server が便利か」に目が行きます。GitHub、Sentry、Notion、Slack、社内検索、データ基盤。ひとつずつは便利ですが、数が増えた瞬間に「誰が許可したのか」「どの scope で動くのか」「いつ見直すのか」が見えなくなります。
この記事では、remote MCP server を組織で許可する前に作る MCP サーバーカタログ の設計を整理します。認証・監査・配布統制の全体像は MCP エンタープライズ運用ガイド、Claude Code から MCP をつなぐ手順は Claude Code MCP ガイド、prompt injection と tool poisoning の防御は MCP prompt injection 対策ガイド、AIエージェント全体の監査ログは AIエージェント監査ログ設計ガイド に分けています。
今回はその手前にある「どの MCP server を、誰の責任で、どの条件なら組織に入れてよいか」を扱います。
先に結論: allowlist の前に catalog が必要
MCP の統制でよくある失敗は、いきなり allowlist を作ることです。
allowlist は重要です。ただし、allowlist は「許可するものの一覧」であって、「なぜ許可したのか」「いつ見直すのか」「何をしてよいのか」までは説明してくれません。実務では、allowlist の前に catalog が必要です。
私なら、MCP サーバーカタログには最低限これを持たせます。
| 項目 | 例 | 目的 |
|---|---|---|
| server id | github-readonly-mcp | 同名・類似名を避ける |
| owner | platform team / data team | 障害時と棚卸し時の責任者を決める |
| transport | Streamable HTTP / SSE / stdio | 接続方式ごとのリスクを分ける |
| endpoint | https://mcp.company.example/github | allowlist と監査ログへつなぐ |
| auth | OAuth / service account / header secret | 権限主体を説明する |
| scope | repo:read, issues:read | 最小権限を固定する |
| tool risk | read / draft / write / external action | 承認要否を決める |
| data boundary | public / internal / customer data | 扱う情報の機密度を決める |
| review date | 2026-09-01 | 放置された server を止める |
| kill switch | DNS / gateway / managed settings | 緊急停止の場所を決める |
ここまでそろっていない MCP server は、便利でも組織標準にはしません。個人検証と組織配布は別物です。
なぜ今 catalog が必要なのか
MCP Registry の remote server 定義では、server.json の remotes に transport type と URL を持たせられます。remote server は Streamable HTTP が推奨され、SSE も指定できます。さらに URL template variables や HTTP headers も定義できます。
これは公開・発見の仕組みとしては便利です。一方で、組織利用では「発見できる」ことと「許可してよい」ことを分ける必要があります。
たとえば、同じ remote MCP でも次はリスクが違います。
- 社内 docs を read-only で検索する server
- GitHub issue を読み、PR comment も書ける server
- 顧客データを検索し、CRM に更新を書き戻せる server
- API key を header secret として受け取る multi-tenant server
MCP の authorization 仕様では、HTTP transport 向けに OAuth ベースの authorization flow が定義され、scope selection や resource parameter、token handling が整理されています。つまり remote MCP は単なる URL ではなく、外部 system の権限主体を伴う接続です。
だから catalog では URL だけでなく、scope、認証主体、tool risk、data boundary まで同じ行に置く必要があります。
catalog の単位は server ではなく「許可された用途」
同じ vendor の MCP server でも、用途が違えば catalog では分けます。
悪い例:
GitHub MCP: allowed良い例:
github-readonly-mcp
purpose: PR / issue / repo metadata の読み取り
scopes: repo:read, issues:read
tools: list issues, read PR, read file metadata
risk: read
expires: 2026-09-01
github-review-comment-mcp
purpose: PR への review comment 下書きと投稿
scopes: pull_requests:write
tools: create review comment
risk: external action
approval: required
expires: 2026-07-15この分け方にすると、「GitHub を許可するか」ではなく、「GitHub のどの操作を、どの文脈で許可するか」を議論できます。
MCP 導入の事故は、server 名の粒度が粗いと起きやすいです。read-only の便利さに引っ張られて、write tool まで同じ許可枠に入ってしまうからです。
初回審査で見るべき7項目
MCP server を catalog に入れるとき、私は次の7項目を見ます。
1. 所有者がいるか
owner がいない MCP server は組織標準にしません。
owner は「使いたい人」ではなく、次を説明できる人です。
- なぜ必要か
- どの data に触るか
- scope をなぜその範囲にしたか
- 障害時に誰が止めるか
- version update を誰が見るか
MCP は一度入れると、AIエージェントの作業面に自然に組み込まれます。owner 不在の server は、時間が経つほど誰も外せなくなります。
2. endpoint と transport が固定されているか
remote MCP は、endpoint の固定が重要です。
MCP Registry の remote server 定義では URL template variables を使えます。multi-tenant には便利ですが、組織配布では変数の値が統制点になります。tenant_id や region をユーザーが自由入力できるなら、どの endpoint へ接続してよいかを別途制限する必要があります。
私なら catalog には、解決後の endpoint も残します。
server_id: docs-search-mcp
transport: streamable-http
declared_url: https://{tenant_id}.docs.example.com/mcp
approved_values:
tenant_id:
- jp-prod
- us-prod
resolved_endpoints:
- https://jp-prod.docs.example.com/mcp
- https://us-prod.docs.example.com/mcpこれをしないと、「公式定義は正しいが、接続先は別 tenant」という抜け道が残ります。
3. scope が用途と一致しているか
MCP authorization 仕様では、clients は必要な scope を選び、server は WWW-Authenticate header などで必要 scope を示せます。実務では、ここをそのまま流さず catalog 側で用途と照合します。
たとえば docs search なのに write scope があるなら、初回審査で落とします。PR comment が必要なら、read-only catalog とは別 server id にします。
scope は「技術的に必要か」だけでなく、「この業務で必要か」で見ます。
4. tool list の変更をどう検知するか
MCP server は tool を提供します。問題は、server version の更新で tool list が変わることです。
初回審査で read-only だった server が、後から write tool を追加する可能性があります。これを allowlist だけで見るのは難しいです。
私なら、catalog に次を残します。
approved_tools:
- search_docs
- read_document
blocked_tools:
- update_document
- export_customer_data
tool_list_hash: sha256:...
last_tool_reviewed_at: 2026-06-06hash そのものは運用環境によって実装が違って構いません。重要なのは、「server が変わったら再審査する」というルールを catalog に持たせることです。
5. header secret や API key を誰が管理するか
MCP Registry の remote server 定義では、HTTP headers を isSecret 付きで要求できます。これは便利ですが、組織では secret の置き場所が統制点になります。
個人の local config に API key を散らすなら、退職・異動・漏洩時に回収しにくくなります。標準配布する server なら、secret は個人ファイルではなく、gateway、IdP、secret manager、managed config のどこかに寄せます。
catalog には secret の値ではなく、管理方法を残します。
secret_owner: platform-security
secret_location: 1password-connect
rotation: 90d
user_supplied_secret_allowed: false6. prompt injection の入力経路を分けているか
外部コンテンツを読む MCP server は、read-only でも安全とは限りません。issue、web page、docs、chat、customer support log には、モデルへの指示に見える文字列が混ざります。
ここは既存の MCP prompt injection 対策ガイド の範囲ですが、catalog にも最低限の分類を持たせます。
input_trust:
external_text: true
user_generated_content: true
internal_only: false
session_policy: read_only_session_required
write_tools_same_session: deniedつまり、server を許可するときに「未信頼入力を持ち込むか」を先に分類します。あとから承認プロンプトで頑張るより、この方が効きます。
7. 失効条件が書かれているか
catalog の一番大事な項目は、実は失効条件です。
次のどれかに当てはまったら、MCP server は再審査または停止にします。
- owner がいなくなった
- endpoint が変わった
- tool list が変わった
- scope が増えた
- secret rotation に失敗した
- audit log が取れなくなった
- vendor の security notice が出た
- 90日使われていない
導入時の審査だけでは足りません。MCP server は運用中に変わるので、catalog も生きている必要があります。
catalog から managed settings へ落とす
catalog は文書で終わらせない方がいいです。可能な限り、配布設定へ落とします。
Claude Code の managed MCP docs では、managed-mcp.json で組織管理の MCP server を配布できます。また managed settings 側には、管理対象 server だけを尊重させる設定や、ユーザー設定からの拡張を抑える設定があります。Claude Code から個別に MCP を追加する手順や allowlist / denylist の詳細は Claude Code の MCP docs を確認してください。
実務では、catalog と managed settings を次のように対応させます。
| catalog | managed config 側の対応 |
|---|---|
| approved endpoint | managed-mcp.json の server URL |
| denied endpoint | denylist |
| approved stdio command | command 固定 |
| user-added server 禁止 | managed server only |
| write tool 要承認 | permission rule / approval policy |
| owner / expiry | catalog と棚卸し job |
ここで注意すべきは、managed config だけでは owner や expiry までは表現しにくいことです。だから catalog が必要です。設定ファイルは enforcement、catalog は説明責任と棚卸しに使います。
小さく始める catalog 例
最初から大きな台帳システムを作る必要はありません。Markdown か YAML で十分です。
server_id: github-readonly-mcp
title: GitHub read-only MCP
owner: platform-team
status: approved
purpose: PR, issue, repo metadata の調査
transport: streamable-http
endpoint: https://mcp.company.example/github
auth:
type: oauth
subject: user
scopes:
- repo:read
- issues:read
tool_risk:
max_level: read
write_tools_allowed: false
data_boundary:
allowed:
- company repositories
denied:
- personal repositories
- secrets
prompt_injection:
external_text: true
same_session_write_tools: denied
audit:
log_fields:
- actor
- server_id
- tool_name
- target
- result
- scope
review:
approved_at: 2026-06-06
expires_at: 2026-09-06
kill_switch: managed-mcp denylistこれくらいの粒度でも、「便利そうだから入れる」よりはかなり安全です。
審査フローは3段階で十分
大企業向けの重い審査フローを最初から作ると、現場が迂回します。小さく始めるなら3段階で十分です。
1. Trial
個人または小チームで検証する段階です。
- 期限は短くする
- write tool は原則禁止
- 個人 token を本番自動化に使わない
- 検証ログを残す
2. Approved
組織で使ってよい段階です。
- owner がいる
- endpoint と scope が固定されている
- audit log が取れる
- managed config に落ちている
- review date がある
3. Deprecated
使わない、または置き換える段階です。
- 新規利用を止める
- 既存利用者を棚卸しする
- replacement を決める
- expiry で denylist へ移す
この3段階を catalog に持たせるだけで、「入れたら終わり」から抜け出せます。
OpenAI / ChatGPT 側の custom MCP でも同じ考え方を使う
OpenAI の Developer mode と MCP apps のヘルプでも、未信頼の MCP server には prompt injection などのリスクがあると説明されています。ChatGPT 側で custom MCP app を試す場合でも、考え方は同じです。
remote MCP の認証については、2026年5月公開の計測研究でも OAuth 対応 server の動的 client registration や delegated authorization 周辺に多くの不備が見つかったと報告されています。研究結果をそのまま自社環境へ一般化するのは乱暴ですが、少なくとも「公開 server を見つけたら即採用」ではなく、catalog で審査する理由にはなります（A First Measurement Study on Authentication Security in Real-World Remote MCP Servers）。
違うのは、配布先や承認UIです。共通して必要なのは次です。
- 誰が server を所有するか
- どの endpoint を信頼するか
- どの data に触るか
- どの tool が write / external action か
- いつ失効させるか
MCP client が Claude Code でも ChatGPT でも、自社が持つべき catalog の項目はほぼ変わりません。client ごとの設定差分を catalog の下流に置くと、運用を乗り換えやすくなります。
まとめ
MCP server の組織導入で一番危ないのは、server が増えること自体ではありません。許可理由、owner、scope、tool risk、失効条件が見えないまま増えることです。
MCP Registry や remote server 定義により、server の公開と発見は進みます。OAuth 仕様により、認証の標準化も進みます。だからこそ、自社側では「どの server をどの用途で許可するか」を catalog として持つ必要があります。
私なら、最初の MCP 統制は allowlist ではなく catalog から始めます。server id、owner、endpoint、scope、tool risk、data boundary、review date、kill switch を1行に置く。そこから managed settings、監査ログ、定期棚卸しへ落とす。
それができて初めて、MCP は「便利な外部接続」ではなく、組織で運用できる AIエージェントの接続基盤になります。