ログイン中: ゲストモード

Deep Dive2026年2月15日Abcas Security Research

人気は低リスクの代わりにならない: 10件のMCPサーバーで見たダウンロード数と判定のズレ

10件のMCPサーバーを見た範囲では、ダウンロード数と検査判定は連動しなかった。人気は普及度のシグナルにはなるが、低リスクの根拠にはならない。

用語

用語意味
ダウンロード数npm の週次ダウンロード回数。普及度を示す指標
検査判定PASS / WARN / BLOCK の最終判定
リスクの代理指標本来見るべき根拠の代わりに使われる間接指標
出所確認公開者の身元と配布経路が妥当かを見ること

リード

実際の導入判断では、ダウンロード数や GitHub Star が「なんとなく信頼できそう」という近道として使われがちである。「多くの人が使っているなら、重大な問題はもう見つかっているだろう」という発想だ。

本稿で見るのは、もっと実務的な問いである。10件のMCPサーバーを詳細に見ると、人気は本当に判定と連動していたのか。今回のサンプルでは、そうではなかった。重要なのは「人気が無意味」という話ではなく、人気はリスク判断の代わりにはならないという点である。

Key Findings

  1. 10件のサンプルで、週次ダウンロード数は 24件から309,704件 まで約12,900倍の差があった。
  2. ダウンロード数と検査判定の間に一貫した関係は見られなかった。
  3. 週次30万超のサーバーでも WARN 判定が出た。
  4. ダウンロード数が小さいサーバーでも PASS 判定は存在した。
  5. 人気は普及度を示しても、攻撃者にとっての価値を高める面もある。

データセット

項目
対象10件のMCPサーバー
観測期間2026-03-26 〜 2026-03-27
比較指標週次ダウンロード数と最終検査判定
位置づけ探索的サンプルであり、正式な相関分析ではない

実際に観測されたこと

サンプル内の人気の差は大きかった。

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

対応する検査判定は以下だった。

判定件数比率
PASS330%
WARN660%
BLOCK110%

ここで重要なのは、人気順と判定順がきれいに並ばなかったことである。

観測された具体例:

  • 高ダウンロードのサーバーでも WARN になった
  • 低ダウンロードのサーバーでも PASS になった
  • ダウンロード数の順位と判定の厳しさに一貫した傾向はなかった

この時点で、「人気ならすでに十分に検証されているだろう」という近道は、運用判断の根拠として弱い。

なぜ人気はリスクの代理指標にならないのか

1. ダウンロード数が示すのは普及であって検証ではない

ダウンロード数が答えるのは「どれだけ多くインストールされたか」であって、次の問いではない。

  • セキュリティレビューされたか
  • ランタイムの挙動が確認されたか
  • 公開者の身元が確認されたか
  • 危険な部分まで見られたのか、それとも CI で機械的に入っただけか

普及と検証は別の情報である。

2. MCPサーバーでは信頼ミスの被害が大きくなりやすい

通常のライブラリは、既存のアプリ権限の中で実行されることが多い。MCPサーバーは違う。AIエージェントに対してツールや実行時操作を露出するため、信頼判断を誤ると、そのままファイル操作、外部通信、コマンド実行に結びつきやすい。

だから、仮に従来のパッケージエコシステムで人気が弱い安心材料になっていたとしても、MCPではさらに弱い。

3. 人気は攻撃者の動機にもなりうる

広く使われているパッケージは、侵害できれば影響範囲が大きい。攻撃者にとっては、ニッチなツールより投資対効果が高い場合がある。

この意味で、人気は「安全ラベル」どころか、攻撃対象としての価値の一部でもある。

代わりに何を見るべきか

ダウンロード数の代わりに、導入前に確認すべきなのは次のような根拠である。

  1. 出所: 公開者の身元は確認できるか。配布経路は自然か。
  2. 宣言と実動作の整合性: サーバーは宣言どおりに動いているか。
  3. 過去の検査履歴: 継続的に問題が少ないのか、たびたびレビューが必要なのか。
  4. 依存関係の健全性: 引き込んでいるライブラリに既知問題はないか。
  5. 機能構成: 実行、送信、ファイル操作などが危険な形で同居していないか。

これらは人気指標ではなく、導入リスクに直接つながる材料である。

この文章が主張していないこと

本稿は、母集団全体で「人気とリスクは絶対に無関係だ」と証明するものではない。サンプルは10件であり、その主張には小さい。

本稿が支えるのは、もっと狭くて実務的な結論である。

  • 今回の10件では、人気は判定の信頼できる近道ではなかった
  • したがって、導入判断で人気を代用指標にすべきではない

これだけでも運用判断としては十分に強い。

限界

  1. 10件の探索的サンプルであり、正式な統計的相関分析ではない。
  2. 比較したのは週次ダウンロード数のみで、Star や Fork は扱っていない。
  3. 母集団全体を代表するよう設計されたサンプルではない。
  4. 記事の目的は判断軸の説明であり、個別サーバーを名指しすることではないため、実名は出していない。

まとめ

今回の10件のMCPサーバーでは、ダウンロード数は低リスクの信頼できる代理指標にはならなかった。人気が説明していたのは普及度であって、検査結果ではない。

実務上、最初に問うべきは「どれだけ人気か」ではなく「何の根拠があるか」である。出所、実動作、過去の検査履歴、依存関係、機能構成。導入判断を支えるのは、そうした直接根拠である。


MCP Guard は、人気指標ではなく検査根拠に基づいてMCPサーバーを評価する。