Research2026年3月27日Abcas Security Research

3,601件のMCPサーバーを検査した結果: 危険性の実態

3,601件のMCPサーバーを全件検査し、10件の詳細サンプルと合わせて、導入前レビューがどの程度必要かを整理した。

用語

用語	意味
MCP サーバー	AI エージェントが外部機能を呼び出すための接続先（Model Context Protocol）
安全判定	自動検査の結果。問題なし（PASS）/ 要確認（WARN）/ 危険（BLOCK）の3段階
出所確認	パッケージの公開元・管理者・配布経路が妥当かを検証すること
整合検証	宣言された動作と、実際に観測された動作が一致しているかを確認すること
既知データベース	過去の検査結果を蓄積し、サーバーごとの安全性評価を保持するデータベース

リード

MCP（Model Context Protocol）は、AI エージェントが外部のツールやデータソースにアクセスするための標準プロトコルとして、2025年後半から急速に普及した。開発者は MCP サーバーを通じて、ファイル操作、データベースアクセス、API 連携といった機能を AI エージェントに提供できる。

しかし、この急速な普及は安全性の検証が追いついていない状態を生み出している。npm や GitHub で公開されている MCP サーバーは数千件に達しているが、その安全性を体系的に検査した調査はほとんど存在しない。「レジストリに公開されている」「ダウンロード数が多い」「ソースコードが公開されている」といった条件は、いずれも安全性の直接的な証拠にはならない。

本稿では、3,601件の MCP サーバーを対象に全件検査を実施した結果を報告する。この規模での体系的な安全性検査は、MCP エコシステムにおいて初めての試みである。検査対象には、広く使われている人気サーバーから、公開直後のニッチなツールまでが含まれる。検査の目的は、MCP サーバーの安全性に関する定量的な実態を明らかにし、開発者や組織が導入判断を行うための根拠を提供することにある。

Key Findings

3,601件の全件検査で、処理完了率は99.9%（3,597件完了）。検査基盤自体の信頼性は確認された。
詳細検査を実施した10件のうち、70%で何らかの警告または危険判定が出た。
既知データベースとの照合では、評価対象の半数が「要注意」に分類された。
週次ダウンロード数が30万件を超えるサーバーでも、安全判定で警告が出るケースが確認された。
問題の主因は、公開元の信頼性や宣言内容と実動作の不一致に集中していた。

背景: なぜ MCP サーバーの安全性が問題なのか

AI エージェントの権限拡大

従来の API 連携と MCP サーバーの決定的な違いは、AI エージェントに付与される権限の範囲にある。MCP サーバーは単なるデータ取得の窓口ではなく、ファイルの作成・削除、コマンドの実行、外部サービスへのリクエスト送信など、広範な操作を AI エージェントに許可する。

この設計により、悪意のある MCP サーバーや、意図せず危険な動作を含むサーバーが導入された場合の被害範囲は、従来の API 経由のリスクよりも格段に大きくなる。ユーザーが明示的に承認していない操作が実行される可能性があり、これが「MCP サーバーの安全性」を単なるパッケージセキュリティではなく、エージェントセキュリティの問題として位置づける理由である。

既存のパッケージエコシステムとの類似点と相違点

npm や PyPI などのパッケージエコシステムでは、悪意のあるパッケージによるサプライチェーン攻撃が繰り返し報告されている。タイポスクワッティング（名前の類似を利用した偽パッケージ）、依存関係の乗っ取り、メンテナの認証情報窃取など、攻撃手法は多岐にわたる。

MCP エコシステムも同様のリスクに晒されているが、追加のリスク要因がある。MCP サーバーは「実行時に何を行うか」がパッケージのメタデータだけでは判断できない場合が多い。宣言されたツール定義と、実際の実行時の動作が乖離している可能性を検証するには、静的な情報の確認だけでは不十分であり、複数の観点からの検査が必要になる。

「公開されている＝安全」という誤解

オープンソースソフトウェアのエコシステムでは、「コードが公開されているから誰かがレビューしている」「多くの人が使っているから安全」という暗黙の前提が広く共有されている。しかし、この前提は実証的に否定されている。npm の事例では、数百万ダウンロードのパッケージにバックドアが仕込まれていた事例（event-stream 事件、2018年）が知られている。

MCP エコシステムはまだ歴史が浅く、コミュニティによるレビューの蓄積も限られている。したがって、「公開されている＝安全」という前提に依存することは、現時点では特にリスクが高い。

Methodology

項目	値
検査対象	3,601件の MCP サーバー（全件再検査）
検査期間	2026-03-26〜2026-03-27（31.2時間連続監視）
詳細分析	10件を抽出し、複数の検証観点で個別評価
注意	個別サーバー名は匿名化。検査手法の実装詳細は非公開

検査の範囲と方法

検査対象は、主要な MCP レジストリおよびパッケージリポジトリに登録されている 3,601件の MCP サーバーである。これらに対して全件の再検査を実施し、検査基盤の信頼性と安全性判定の傾向を確認した。

詳細分析では10件を抽出し、複数の検証観点で個別に評価した。本稿で報告する問題パターンと比率は、この10件の探索的分析に基づくものであり、3,601件全体の分布を統計的に推定するものではない。探索的分析の目的は、自動検査がどのような種類の問題を検出できるかを定性的に示すことにある。

匿名化の方針

個別のサーバー名、パッケージ名、公開者名は本稿では一切公開しない。これは検査の目的が特定のサーバーの評判を損なうことではなく、エコシステム全体の安全性傾向を示すことにあるためである。

結果

全件検査の概要

3,601件の検査を31.2時間で完了した。処理完了率は99.9%で、失敗は2件（0.06%）のみだった。

状態	件数	比率
正常完了	3,597	99.89%
サイズ超過による運用分岐	2	0.06%
処理失敗	2	0.06%
合計	3,601	100%

失敗の2件はいずれもタイムアウトまたは取得失敗であり、検査基盤の設計上の例外として管理されている。サイズ超過の2件は、通常の処理経路では扱えない大規模パッケージに対する安全側の処理分岐であり、「失敗」とは区別される。この完了率は、3,601件規模での定期的な全件再検査が運用として成り立つことを示している。

詳細検査の安全判定（10件サンプル）

10件を抽出して複数の検証観点で詳細に検査した結果：

判定	件数	比率
PASS（問題なし）	3	30%
WARN（要確認）	6	60%
BLOCK（危険）	1	10%

7割のサーバーで、導入前に確認すべき問題が見つかった。 PASS と判定された3件は、公開元の情報が十分で、宣言内容と実際の動作に矛盾がなく、既知データベースでも相対的に低リスクと記録されていたサーバーである。

WARN 判定の6件は、いずれかの検証観点で懸念事項が検出されたが、即座に利用を遮断するほどではないと判断されたケースである。ただし、「要確認」は「低リスク」を意味しない。組織として導入する場合は、WARN 判定の根拠を確認した上で、許容可能かどうかを判断する必要がある。

BLOCK 判定の1件は、複数の検証観点で重大な問題が確認され、利用すべきでないと判断されたケースである。

既知データベースとの照合

分類	件数
低リスク寄りと判定済みのサーバー	5
要注意と判定済みのサーバー	5

過去の検査で蓄積された既知情報と照合した結果、半数が「要注意」に分類された。この結果は、MCP サーバーのリスク状態が固定的なものではないことを示している。過去に低リスク寄りと判定されたサーバーでも、パッケージの更新や依存関係の変化、メンテナの交代により状態が変化することがある。逆に、過去に要注意だったサーバーが改善されているケースもありうる。

既知データベースは蓄積的な判定履歴であるため、「現在の状態」を知るには最新の検査結果との突合が必要になる。これが定期的な再検査を推奨する理由の一つである。

ダウンロード数と安全判定の乖離

指標	値
最大ダウンロード数（週次）	309,704
最小ダウンロード数（週次）	24
倍率差	約12,900倍

10件のサンプルに含まれるサーバーの週次ダウンロード数は、24件から30万件超まで約12,900倍の差があった。しかし、ダウンロード数の多寡と安全判定の結果に相関は見られなかった。

この結果は直感に反するかもしれないが、ソフトウェアセキュリティの文脈では珍しくない。人気のあるパッケージが攻撃対象になるケース（高価値ターゲット）も、ニッチなパッケージが検証不足のまま放置されるケースも、いずれも現実に発生している。重要なのは、「ダウンロード数」は普及度の指標であって安全性の指標ではないという認識を、導入判断の前提に置くことである。

どのような問題が検出されるか

詳細検査で検出された問題は、主に以下のカテゴリに分類される。検出手法の実装詳細は非公開だが、問題の性質は公開する。

1. 公開元の信頼性に関する問題

パッケージの公開者情報が不十分、管理者と配布経路の整合がとれない、公開履歴が短すぎるなど、「このサーバーは本当に正当な公開者から提供されているか」を判断できないケースが最も多く見られた。

具体的には、以下のようなパターンが含まれる：

公開者の npm アカウントが作成直後で、他のパッケージの公開実績がない
パッケージ名が既存の人気サーバーと酷似しているが、公開者が異なる
GitHub リポジトリのオーナーとnpmパッケージの公開者が一致しない
README に記載された組織名と、実際の公開者情報に矛盾がある

これらのパターンは必ずしも悪意を意味するものではないが、正当性を確認できない状態を「低リスク」とは判断できない。特に、タイポスクワッティングの可能性がある場合は、意図的な攻撃の兆候として扱う必要がある。

2. 宣言と実動作の不一致

サーバーが宣言している操作内容と、実際に観測された動作の間に矛盾があるケース。今回の10件では2件（20%）で矛盾が検出され、いずれも最終判定に影響を与えた。

例えば、「読み取り専用のデータ取得ツール」として宣言されているにもかかわらず、実行時にファイルシステムへの書き込みや外部APIへのPOSTリクエストを行う能力を持つケースが該当する。このような不一致は、意図的な隠蔽か、開発上の不注意かを問わず、リスクとして扱うべきである。

矛盾の検出率（今回は20%）自体は高くないが、矛盾が検出された場合の影響は大きい。2件とも、矛盾の検出が最終判定を WARN 以上に引き上げる要因となった。運用上は「矛盾の発生率」よりも「矛盾が最終判定を変えた件数」が重要な指標となる。

3. 依存関係のリスク

サーバーが使用するライブラリやパッケージに既知の脆弱性が含まれるケース。サーバー自体に悪意がなくても、依存先の問題が間接的にリスクとなる。

この問題は MCP 固有ではなく、ソフトウェアサプライチェーン全体に共通する課題である。しかし、MCP サーバーの場合は AI エージェントの広範な権限と組み合わさるため、依存関係の脆弱性が悪用された場合の影響範囲が通常のライブラリ利用よりも大きくなる可能性がある。

考察

「公開されている＝安全」ではない

MCP サーバーは誰でも公開できる。レジストリに登録されていること、ダウンロード数が多いこと、GitHub にソースコードがあることは、いずれも安全性の証明にはならない。これは既知の事実だが、MCP エコシステムでは特に重要である。

理由は2つある。第一に、MCP サーバーは AI エージェントに広範な操作権限を付与するため、問題のあるサーバーの被害範囲が大きい。第二に、エコシステムが急速に成長しているため、コミュニティによる自然なレビューが普及速度に追いついていない。

自動検査なしでは問題を検知できない

上記の問題の多くは、サーバーの説明文やREADMEを読むだけでは判断できない。パッケージの公開者情報の整合性、宣言と実動作の一致、依存関係の脆弱性は、いずれも自動化された検査によって初めて可視化される。

これは、人間によるコードレビューが不要だという意味ではない。しかし、3,601件のサーバーすべてに人的レビューを実施することは現実的ではなく、自動検査による一次スクリーニングが、人的リソースの効率的な配分の前提条件となる。

定期的な再検査が必要

一度安全と判定されたサーバーでも、パッケージの更新や依存関係の変化により状態が変わりうる。3,601件の全件再検査を31.2時間で完了できたことは、定期再検査が実運用で成り立つことを実証している。

ソフトウェアサプライチェーンの監視では、「ポイント・イン・タイム」の検査だけでなく、継続的なモニタリングが標準的なプラクティスとなりつつある。MCP エコシステムでも同様に、導入時の一回限りの検査ではなく、定期的な再検査を組織のセキュリティプロセスに組み込むことが推奨される。

組織が取るべき対応

本稿の結果から、以下の対応を推奨する：

導入前検査の義務化: MCP サーバーを組織のシステムに導入する前に、自動検査を実施し、安全判定を確認する。
ダウンロード数に依存しない判断基準: サーバーの人気度ではなく、公開元の信頼性と動作の整合性を判断基準とする。
定期的な再検査: 導入済みのサーバーに対して、定期的に再検査を実施し、状態の変化を監視する。
WARN 判定の運用ルール: WARN 判定が出た場合の対応フロー（調査→承認→監視 or 除外）を事前に定義しておく。

限界

詳細分析は10件の探索分析であり、統計的一般化ではなく問題パターンの確認を目的としている。3,601件全体の安全判定分布は別途公開予定である。
検査手法の実装詳細は非公開としている。これは検査の回避手法を開示しないためである。
外部公開向けに個別サーバー情報は除外しており、匿名化された集計データのみを報告している。
本稿は単一の検査ウィンドウ（2026年3月26-27日）のスナップショットであり、時系列的な変化は追跡していない。
10件のサンプルは検査の能力を示すための探索的サンプルであり、層化抽出やランダム抽出ではない。

Conclusion

MCPサーバーのリスクは、公開状態やダウンロード数からは判断できない。3,601件の全件検査と10件の詳細分析を通じて、自動検査で初めて可視化される問題が多数存在することを示した。

特に、公開元の信頼性に関する問題と宣言・実動作の不一致は、README の確認やダウンロード数の参照では検知できない。MCP エコシステムが AI エージェントに広範な操作権限を付与する性質を持つ以上、導入前の検査と定期的な再検査は、推奨事項ではなく必須のプラクティスである。

今後の課題として、3,601件全体の安全判定分布の公開、時系列的な変化の追跡、およびサンプルサイズを拡大した詳細分析の実施を予定している。

MCP Guard は、MCPサーバーのリスクを自動検査で評価し、導入判断を支援します。