シンジです。AIを更に便利に賢くしてくれるMCPサーバー群ですが、安全性の担保がまちまちで、企業として接続を許可すべきかどうかは絶妙な状態が続いています。この状況を打破しようと様々な団体が活動中ですが、現時点で一発回答できる仕組みが存在していません。
「有名企業だしMCP繋いでも大丈夫でしょ…」という具合で繋いでますよね。はい、私がそうです。
現実問題として、利便性や手間を考慮しても、判断基準はここに着地せざるを得ないのが現状だと思います。それでもMCPサーバーの接続は危険と言われている、その根拠と現時点での解決策をお伝えします。
エグゼクティブサマリー
- MCPサーバーは「誰でも作れる」。 プログラミング不要で量産でき、有名企業製から個人作の野良まで玉石混交です。だからこそ「このMCPは安全か危険か」を導入前に見極める仕組みが要ります。
- 大前提：「公式に登録されている＝安全」ではありません。 公式 MCP Registry は名前空間（出所）の検証に特化し、コードのセキュリティスキャンは行わず外部に委譲すると明記。Anthropic の Directory も掲載基準のレビューはしますが各サーバーのセキュリティ監査は保証しません。つまり「出所の信頼（provenance）」と「安全性（safety）」は別物です。
- 2026年時点で、安全/危険を判断する材料は出そろいつつありますが、"このMCPは安全"という業界共通の単一シールはまだありません。 提供されているのは①出所・署名、②脆弱性スキャン、③第三者監査・脆弱性DB、④ベンダー認証、⑤運用統制の多層で、多くが preview/beta 段階です。
- MCP固有の危険として、ツールポイズニング・Rug Pull（承認後の記述子すり替え）・クロスオリジン昇格（ツールシャドーイング）・プロンプトインジェクション・トークン/秘密の漏えい・過剰権限・サプライチェーンがあり、OWASP が「MCP Top 10」として体系化を始めています。
- 実務の結論：単一の判定に頼らず、「出所 → スキャン → 既知脆弱性照合 → 権限最小化 → 運用統制」を重ねる多層判断が現実解。本記事はそのフレームワークと、緑/赤シグナルのチェックリストを提供します。
1. なぜ「MCPの安全判断」が必要なのか
MCP（Model Context Protocol）は、AIエージェントを社内外のツールやデータに繋ぐ標準プロトコルです。普及の裏で、接続先であるMCPサーバー（コネクタ）は誰でも作れて公開できるようになりました。CSA（Cloud Security Alliance）のMCP監査ツールはこの状況をこう端的に表します。
"Code audit tool that finds security vulnerabilities in MCP servers and Claude Desktop Extensions — because anyone can build them, but not everyone builds them safely."（mcpserver-audit）
（日本語訳）「MCPサーバーやClaude Desktop拡張機能のセキュリティ脆弱性を見つけるコード監査ツール。なぜなら、誰でもMCPサーバーを作れるが、誰もが安全に作れるわけではないからだ。」
問題は、「公式に並んでいる＝安全」と思い込みやすい点です。実際にはそうではありません。
- 公式 MCP Registry（Anthropic・GitHub・PulseMCP・Microsoft が支援、現在 preview）は、逆DNS名前空間とGitHub/ドメイン所有権で「誰が出したか（出所）」を保証する一方、こう明言します。
"The MCP Registry focuses on namespace authentication and metadata hosting, while relying on the broader ecosystem for security scanning of actual server code."
（日本語訳）「MCP Registryは名前空間の認証とメタデータのホスティングに重点を置き、実際のサーバーコードのセキュリティスキャンはより広いエコシステムに依存している。」
"The MCP Registry delegates security scanning to: Underlying package registries — npm, PyPI, Docker Hub... Downstream aggregators..."
（日本語訳）「MCP Registryはセキュリティスキャンを次に委譲する：基盤となるパッケージレジストリ（npm、PyPI、Docker Hub…）、下流のアグリゲーター…」
- Anthropic の Directory も「掲載基準でレビューするが、各MCPサーバーのセキュリティ監査・運用は行わない」立場です（Claude公式 managed-mcp ドキュメント）。
つまり出所の検証は安全の保証ではない。だから情シスは、別建ての「安全/危険の判断」を持つ必要があります。
2. 何が「危険なMCP」なのか（MCP固有のリスク）
一般的な脆弱性に加え、MCP特有の攻撃面があります。オープンソースのスキャナ MCP-Scan（Invariant Labs）は、次の4類型を主眼に検査します。
"MCP-Scan proactively scans installed MCP servers and their tool descriptions to identify: Tool Poisoning Attacks/ MCP Rug Pulls/ Cross-Origin Escalations/ Prompt Injection Attacks"
（日本語訳）「MCP-Scanは、インストール済みのMCPサーバーとそのツール記述子を能動的にスキャンし、次を特定する：ツールポイズニング攻撃（ツール記述子に埋め込まれた隠れた悪意ある指示）／MCP Rug Pull（初回承認後にツール記述子を無断変更）／クロスオリジン昇格（ツールシャドーイングによる信頼ツールの乗っ取り）／プロンプトインジェクション攻撃。」
これらに加え、OWASP MCP Top 10（v0.1・ベータ）が、MCP利用システムのライフサイクル全体の重大リスクを MCP01:2025〜MCP10:2025 として体系化しています（トークン管理不備・秘密の露出、権限昇格、ツールポイズニング、サプライチェーン、コマンドインジェクション等）。
実務で押さえるべき「危険の本質」は次の通りです。
- ツール記述子が攻撃ベクトル：MCPはツールの「説明文」をモデルに渡すため、説明文に隠し指示を仕込めばAIを操れる（ポイズニング/シャドーイング）。
- 時間差の裏切り（Rug Pull）：承認時は無害でも、後からツール定義を差し替えられる。ツールのハッシュ固定（Tool Pinning）が対抗策。
- 過剰権限・秘密の握り込み：必要以上のスコープ、長命トークン、ハードコードされた認証情報。
- サプライチェーン：依存パッケージ・ビルド経路・配布元の汚染。
- 野良 stdio サーバー：ローカルで勝手に動く未管理MCP。ネットワーク呼び出しや認証情報を伴うものは特に危険。
3. 安全を見極める「5つのレンズ」フレームワーク
単一の判定に頼らず、次の5観点を重ねて判断します。上ほど"入口"、下ほど"運用"です。
① 出所（Provenance）— 誰が出したか
- 公式 MCP Registry の名前空間検証（逆DNS＋GitHub/ドメイン所有権）で発行元の正当性を確認。
- Docker MCP Catalog は「known publisher（公式/検証済み）」と「community」を区別表示し、Dockerビルドのサーバーを特定コミットに固定（commit pin）＋ cosign 署名で検証可能にしている。
"Every Docker-built MCP server... is now tied to a specific Git commit, making each release precisely attributable and verifiable."
（日本語訳）「DockerでビルドされたすべてのMCPサーバーは、いまや特定のGitコミットに紐づけられ、各リリースを正確に帰属・検証できるようになっている。」
- 注意：出所が確かでも安全とは限らない。
② スキャン（Code & 挙動）— 何をするコードか
- 導入前に MCP-Scan（
uvx mcp-scan@latest）等で、ツール記述子のポイズニング・Rug Pull・クロスオリジン昇格・プロンプトインジェクションを検査。Tool Pinningで記述子の改ざんを検知。
- MCP-Scan はローカル検査に加え Invariant Guardrails API を呼び、ツール名・記述子を外部共有する点に留意（機微なサーバーでは送信ガードの検討を）。
- Docker MCP Catalog はアップストリーム差分を Claude Code と OpenAI Codex による "agentic AI security review" で解析し、
security-risk:high/security-blockedラベルを付与（人間が最終判断）。 - Cisco の
mcp-scanner等、複数スキャナでの突き合わせも有効。
③ 第三者監査・脆弱性DB — 既知の問題はないか
- CSA「Model Context Protocol Security」イニシアチブ（Cloud Security Alliance のコミュニティプロジェクト）は、
mcpserver-audit（コード監査）に加え、audit-db/vulnerability-dbを運営。
"Public audit results and vulnerability advisories for the MCP ecosystem."
（日本語訳）「MCPエコシステムのための公開監査結果と脆弱性アドバイザリ。」
- CSAI 財団（CSA が RSAC 2026 で設立）は、agentic AI 専用の CVE Numbering Authority（CNA） を運用し、エージェント/MCPエコシステムの脆弱性に正式IDを振る動きを進めている（CSA の組織認証プログラム STAR for AI は別建て）。導入候補サーバーの既知脆弱性をこうしたDB・アドバイザリで照合する。
- 具体的な手順（どこにアクセスし、何をするか）
- 既知脆弱性を照合する：vulnerability-db（Web版：modelcontextprotocol-security.io/vulnerability-db）で、導入候補サーバーの名前・配布パッケージ名・GitHubリポジトリを検索し、CVE/アドバイザリの有無、影響度、緩和策・開示時系列を確認する。
- 既存の監査結果を探す：audit-db で、対象サーバーの監査所見・コンプライアンスレポート・セキュリティ評価が登録済みか確認する。登録があれば判定材料に、なければ次の手順へ。
- 自分で監査する：mcpserver-audit を README の手順でセットアップし、対象サーバーのコードを監査する。得られた所見は責任ある開示に従って audit-db / vulnerability-db に還元する。
- 入口（ハブ）とコミュニティ：全体の入口は CSA の MCP Security Resource Center（CSA Lab 版：labs.cloudsecurityalliance.org/mcp）。質問・貢献は GitHub Discussions または Slack #mcp チャンネル（招待リンク）から。
- 新規脆弱性を見つけたら：MCP/エージェント固有の新規脆弱性は、CSAI 財団の agentic AI 向け CNA を通じて正式 ID（CVE）採番のプロセスに乗せる。
④ ベンダー認証 — 審査済みか（Microsoftのエコシステム内で）
- Microsoft の MCP server certification は、公開前に審査を課す数少ない正式認証プログラム。
- この認証は具体的には Microsoft Copilot Studio / Microsoft Copilot 向けに公開・利用される MCP サーバーを対象とした審査・継続監視プログラム。
"Microsoft evaluates the MCP server by using normal, edge-case, and adversarial scenarios to validate safety... The publisher must fix any unsafe or unexpected behavior before certification approval."
（日本語訳）「Microsoftは、通常・エッジケース・敵対的なシナリオを用いてMCPサーバーを評価し、安全性を検証する…発行元は認証承認の前に、安全でない、または予期しない挙動をすべて修正しなければならない。」
"Microsoft continuously monitors certified MCP servers for regressions, security issues, or policy violations..."
（日本語訳）「Microsoftは、回帰・セキュリティ問題・ポリシー違反がないか、認証済みのMCPサーバーを継続的に監視する…」
- verified publisher 必須・継続監視あり。ただし対象はMicrosoftのエコシステム内であり、万能の業界認証ではない点に注意。
⑤ 運用統制 — 接続後にどう抑えるか
- 最小権限スコープ、IdP経由の認可一元化（EMA/Cross App Access）、短命トークン、実行時の監視。
- クライアント側の配布統制（Claude Code の
managed-mcp.json許可/拒否リスト、Claudeアプリのコネクタ許可/ブロック）で「承認したMCPだけ」に限定。 - MCP/AIゲートウェイやネットワーク出口での未承認MCP遮断。
4. 「赤信号 / 緑信号」チェックリスト
導入可否を素早く切り分けるための実務シグナルです。
| 観点 | 🔴 危険サイン（避ける/精査） | 🟢 安全寄りサイン |
|---|---|---|
| 出所 | 発行元不明・名前空間未検証・無署名 | 検証済み発行元・署名/commit-pin・known publisher |
| ツール記述子 | 不自然に長い指示・隠しテキスト・外部URL誘導 | 明快なスキーマ・最小限の記述・スキャン済み |
| 権限 | 過剰スコープ・長命/ハードコード資格情報 | 最小権限・短命トークン・IdP経由 |
| 変更管理 | 承認後に記述子が変わる（Rug Pull）・更新不透明 | Tool Pinning・コミット固定・変更履歴が追える |
| メンテ/既知問題 | 放置リポ・脆弱性DBに登録・依存が古い | 活発な保守・脆弱性DBクリーン・SBOM公開 |
| 認証/審査 | 未審査・ベンダー認証なし・publisher未検証 | ベンダー認証済（例 Microsoft 認証・verified publisher）・継続監視下 |
| 形態 | 野良 stdio・ゲートウェイ外の直結 | リモートMCP＋ゲートウェイ/統制下 |
5. 実務フロー：導入前 → 導入時 → 運用中
- 導入前（評価）：出所確認（公式Registry/Docker known publisher）→ MCP-Scan等でスキャン → OWASP MCP Top 10 と CSA
vulnerability-dbで既知問題照合 → 必要なら社内レビュー（コード監査）。 - 導入時（最小権限で繋ぐ）：最小スコープ・短命トークン・IdP経由（EMA対応なら一元認可）。クライアント側の許可リスト（
managed-mcp.json等）に明示登録したものだけを有効化。 - 運用中（監視と失効）：ツール記述子の変更検知（Tool Pinning）、IdP/ゲートウェイのログ監視、脆弱性アドバイザリの追跡、問題時は一元失効。
6. 標準・ツールの現在地（2026年6月）と正直な限界
- 出所/署名：公式 MCP Registry（preview・出所検証のみ）、Docker MCP Catalog（署名・commit pin・AI審査）。
- スキャン：MCP-Scan（OSS）、Cisco mcp-scanner、学術（MCP-Scanner 論文・arXiv "SMCP"）。
- 第三者監査/脆弱性DB：CSA MCP Security（mcpserver-audit / audit-db / vulnerability-db、Security Baseline v0.1 は近日）。
- 基準：OWASP MCP Top 10（v0.1・ベータ）、OWASP Top 10 for Agentic Applications 2026。
- ベンダー認証：Microsoft MCP server certification。
- 組織アシュアランス/採番：CSA STAR for AI（AI Controls Matrix＋ISO 42001/27001/SOC 2、組織認証）、agentic AI 向け CNA。
限界：①「このMCPは安全」という業界共通の単一認証はまだ無い、②主要要素が preview/beta/v0.1、③レジストリが断片化（公式 / Docker / Smithery / mcp.so / PulseMCP 等）し信頼シグナルがバラバラ、④スキャン・AI審査は継続調整中。だからこそ「重ねて判断する」のが正解です。
7. よくある誤解
- 「公式Registryに載っている＝安全」ではない。 Registry/Directory が確認するのは出所（レンズ①）で、コード監査は外部委譲。安全判断はレンズ②スキャン〜⑤運用統制を重ねて初めて成立する。
- 「有名企業製＝安全」ではない。 発行元の信頼は出発点に過ぎず、過剰権限や脆弱性は別問題。
- 「IdP一元認可（EMA）を入れれば安全」ではない。 EMAは"誰が繋いでよいか"の認可であり、危険なMCPの中身や実行時リスクは別対策。
- 「一度スキャンすれば安心」ではない。 Rug Pull があるため、変更検知（Tool Pinning）と継続監視が必要。
8. まとめ
「そのMCPは安全か危険か」に万能の一発回答はまだありません。しかし出所 → スキャン → 既知脆弱性照合 → 権限最小化 → 運用統制という多層判断と、緑/赤シグナルのチェックリストを運用に組み込めば、実務的な判断は十分に可能です。MCPの普及に合わせて、OWASP・CSA・Docker・Microsoft らの取り組みが標準・認証へと収束しつつあります。現時点で出来る事として、情シスは「載っているか」ではなく「どのレンズで確認したか」で語れる状態を作ることですが、現実的には担当者判断で必要なMCPサーバーに対してのみ確認フローを入れていく、いずれ来るであろうMCPサーバーの安全確認の認証が来次第、社内ルールを整えていく、といった具合になるでしょう。
FAQ
Q. 公式MCP Registryに登録されていれば安全ですか？
A. いいえ。公式Registryは名前空間（出所）の検証に特化し、コードのセキュリティスキャンは npm/PyPI/Docker Hub 等の配布元や下流マーケットプレイスに委譲すると明記しています。出所の確認＝安全の保証ではありません。
Q. MCP固有の代表的な危険は？
A. ツールポイズニング（記述子への隠し指示）、Rug Pull（承認後のすり替え）、クロスオリジン昇格（ツールシャドーイング）、プロンプトインジェクション、過剰権限・秘密の漏えい、サプライチェーン汚染です。
Q. 導入前に何でスキャンできますか？
A. オープンソースの MCP-Scan（uvx mcp-scan@latest）等でツール記述子を検査できます。Docker MCP Catalog は署名・コミット固定・AIによるコードレビューを提供します。既知問題は OWASP MCP Top 10 と CSA の vulnerability-db で照合します。
Q. 第三者が「このMCPは安全」と認証してくれる仕組みはありますか？
A. 業界共通の単一認証はまだありません。近いものとして、Microsoftのベンダー認証（自社エコシステム内）、CSAの公開監査結果・脆弱性DB、CSA STAR for AI（組織認証）などが整備されつつあります。
Q. 安全と判断したMCPでも継続監視は必要ですか？
A. 必要です。Rug Pull により承認後に挙動が変わり得るため、ツールのハッシュ固定（Tool Pinning）、IdP/ゲートウェイのログ監視、脆弱性アドバイザリの追跡を続けます。
お気軽にご相談ください
「このMCPを社内に入れて大丈夫か」を、出所・スキャン・脆弱性照合・権限設計・運用統制の各レンズで判断できる状態にする、それが安全なAI活用の前提です。クラウドネイティブは、ゼロトラストとSaaSセキュリティの専門企業として、MCP/AI連携の棚卸し、安全性評価フローの整備、IdPを軸とした認可一元化（EMA/Cross App Access）、Claude側のMCP配布統制（許可/拒否リスト）、運用監視までを一体で支援します。「どのMCPを許可してよいか判断したい」「内製MCPを安全に統制下に置きたい」といった段階からでも、エンジニアが直接ご相談に応じます。
参考情報
一次情報
- The MCP Registry（出所検証・preview）｜Model Context Protocol｜https://modelcontextprotocol.io/registry/about
- Control MCP server access for your organization｜Claude Code Docs（Anthropicは各サーバーを監査しない／配布統制）｜https://code.claude.com/docs/en/managed-mcp
- OWASP Top 10 for Model Context Protocol（MCP Top 10・v0.1）｜OWASP｜https://owasp.org/www-project-mcp-top-10/
- OWASP Top 10 for Agentic Applications 2026｜OWASP GenAI Security Project｜2025-12-10｜https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
- Announcing the MCP Security Resource Center（mcpserver-audit / audit-db / vulnerability-db）｜Cloud Security Alliance｜2025-08-20｜https://cloudsecurityalliance.org/blog/2025/08/20/securing-the-agentic-ai-control-plane-announcing-the-mcp-security-resource-center
- mcpserver-audit（MCPサーバーのコード監査ツール）｜ModelContextProtocol-Security（CSAコミュニティ）｜https://github.com/ModelContextProtocol-Security/mcpserver-audit
- CSAI Foundation「Securing the Agentic Control Plane」（STAR for AI・agentic CNA）｜Cloud Security Alliance｜2026-03-23｜https://cloudsecurityalliance.org/press-releases/2026/03/23/csa-securing-the-agentic-control-plane
- Microsoft MCP server certification｜Microsoft Learn（公開前のセキュリティ審査・継続監視）｜https://learn.microsoft.com/en-us/microsoft-copilot-studio/mcp-certification
- Enhancing Trust in the MCP Ecosystem（commit pin・cosign署名・AIセキュリティレビュー）｜Docker｜2025-12-03｜https://www.docker.com/blog/enhancing-mcp-trust-with-the-docker-mcp-catalog/
- Introducing MCP-Scan（ツールポイズニング/Rug Pull検出）｜Invariant Labs｜2025-04-11｜https://invariantlabs.ai/blog/introducing-mcp-scan
- Cisco MCP Scanner（オープンソースの MCP サーバーセキュリティスキャナ・Apache-2.0）｜Cisco AI Defense｜2025-10-23｜https://github.com/cisco-ai-defense/mcp-scanner
二次情報・補足
- MCP-Scanner: Detecting Security Risks in Model Context Protocol Systems｜ACM/IEEE 2026｜https://dl.acm.org/doi/10.1145/3786160.3788471
- SMCP: Secure Model Context Protocol（MCP をプロトコルレベルでセキュア化する提案。スキャナーではない）｜arXiv cs.CR 2602.01129｜2026-02-01｜https://arxiv.org/abs/2602.01129
