人気は低リスクの代わりにならない: 10件のMCPサーバーで見たダウンロード数と判定のズレ
10件のMCPサーバーを見た範囲では、ダウンロード数と検査判定は連動しなかった。人気は普及度のシグナルにはなるが、低リスクの根拠にはならない。
用語
| 用語 | 意味 |
|---|---|
| ダウンロード数 | npm の週次ダウンロード回数。普及度を示す指標 |
| 検査判定 | PASS / WARN / BLOCK の最終判定 |
| リスクの代理指標 | 本来見るべき根拠の代わりに使われる間接指標 |
| 出所確認 | 公開者の身元と配布経路が妥当かを見ること |
リード
実際の導入判断では、ダウンロード数や GitHub Star が「なんとなく信頼できそう」という近道として使われがちである。「多くの人が使っているなら、重大な問題はもう見つかっているだろう」という発想だ。
本稿で見るのは、もっと実務的な問いである。10件のMCPサーバーを詳細に見ると、人気は本当に判定と連動していたのか。今回のサンプルでは、そうではなかった。重要なのは「人気が無意味」という話ではなく、人気はリスク判断の代わりにはならないという点である。
Key Findings
- 10件のサンプルで、週次ダウンロード数は 24件から309,704件 まで約12,900倍の差があった。
- ダウンロード数と検査判定の間に一貫した関係は見られなかった。
- 週次30万超のサーバーでも WARN 判定が出た。
- ダウンロード数が小さいサーバーでも PASS 判定は存在した。
- 人気は普及度を示しても、攻撃者にとっての価値を高める面もある。
データセット
| 項目 | 値 |
|---|---|
| 対象 | 10件のMCPサーバー |
| 観測期間 | 2026-03-26 〜 2026-03-27 |
| 比較指標 | 週次ダウンロード数と最終検査判定 |
| 位置づけ | 探索的サンプルであり、正式な相関分析ではない |
実際に観測されたこと
サンプル内の人気の差は大きかった。
| 指標 | 値 |
|---|---|
| 最大週次ダウンロード数 | 309,704 |
| 最小週次ダウンロード数 | 24 |
| 倍率差 | 約12,900倍 |
対応する検査判定は以下だった。
| 判定 | 件数 | 比率 |
|---|---|---|
| PASS | 3 | 30% |
| WARN | 6 | 60% |
| BLOCK | 1 | 10% |
ここで重要なのは、人気順と判定順がきれいに並ばなかったことである。
観測された具体例:
- 高ダウンロードのサーバーでも WARN になった
- 低ダウンロードのサーバーでも PASS になった
- ダウンロード数の順位と判定の厳しさに一貫した傾向はなかった
この時点で、「人気ならすでに十分に検証されているだろう」という近道は、運用判断の根拠として弱い。
なぜ人気はリスクの代理指標にならないのか
1. ダウンロード数が示すのは普及であって検証ではない
ダウンロード数が答えるのは「どれだけ多くインストールされたか」であって、次の問いではない。
- セキュリティレビューされたか
- ランタイムの挙動が確認されたか
- 公開者の身元が確認されたか
- 危険な部分まで見られたのか、それとも CI で機械的に入っただけか
普及と検証は別の情報である。
2. MCPサーバーでは信頼ミスの被害が大きくなりやすい
通常のライブラリは、既存のアプリ権限の中で実行されることが多い。MCPサーバーは違う。AIエージェントに対してツールや実行時操作を露出するため、信頼判断を誤ると、そのままファイル操作、外部通信、コマンド実行に結びつきやすい。
だから、仮に従来のパッケージエコシステムで人気が弱い安心材料になっていたとしても、MCPではさらに弱い。
3. 人気は攻撃者の動機にもなりうる
広く使われているパッケージは、侵害できれば影響範囲が大きい。攻撃者にとっては、ニッチなツールより投資対効果が高い場合がある。
この意味で、人気は「安全ラベル」どころか、攻撃対象としての価値の一部でもある。
代わりに何を見るべきか
ダウンロード数の代わりに、導入前に確認すべきなのは次のような根拠である。
- 出所: 公開者の身元は確認できるか。配布経路は自然か。
- 宣言と実動作の整合性: サーバーは宣言どおりに動いているか。
- 過去の検査履歴: 継続的に問題が少ないのか、たびたびレビューが必要なのか。
- 依存関係の健全性: 引き込んでいるライブラリに既知問題はないか。
- 機能構成: 実行、送信、ファイル操作などが危険な形で同居していないか。
これらは人気指標ではなく、導入リスクに直接つながる材料である。
この文章が主張していないこと
本稿は、母集団全体で「人気とリスクは絶対に無関係だ」と証明するものではない。サンプルは10件であり、その主張には小さい。
本稿が支えるのは、もっと狭くて実務的な結論である。
- 今回の10件では、人気は判定の信頼できる近道ではなかった
- したがって、導入判断で人気を代用指標にすべきではない
これだけでも運用判断としては十分に強い。
限界
- 10件の探索的サンプルであり、正式な統計的相関分析ではない。
- 比較したのは週次ダウンロード数のみで、Star や Fork は扱っていない。
- 母集団全体を代表するよう設計されたサンプルではない。
- 記事の目的は判断軸の説明であり、個別サーバーを名指しすることではないため、実名は出していない。
まとめ
今回の10件のMCPサーバーでは、ダウンロード数は低リスクの信頼できる代理指標にはならなかった。人気が説明していたのは普及度であって、検査結果ではない。
実務上、最初に問うべきは「どれだけ人気か」ではなく「何の根拠があるか」である。出所、実動作、過去の検査履歴、依存関係、機能構成。導入判断を支えるのは、そうした直接根拠である。
MCP Guard は、人気指標ではなく検査根拠に基づいてMCPサーバーを評価する。
