ダウンロード数が実際に数えているもの
npmのダウンロード数は、パッケージがレジストリから何回取得されたかを測ります。これにはすべてのnpm install、すべてのCI/CDパイプライン実行、すべてのDockerビルド、すべてのロックファイル解決が含まれます。プッシュごとにCIを走らせる単一プロジェクトは、人間がパッケージを見ていなくても、各依存関係について1日に何十回ものダウンロードを発生させ得ます。
つまり、ダウンロード数は自動化に大きく影響されます。人気のあるCIツールの依存関係になっているパッケージは、それ自体としての有用度に関係なく膨大なダウンロード数を持つことになります。開発者がローカル利用のために手動でインストールするパッケージは、広く評価されていてもはるかに低い数字となります。
これがAIツールにとって意味すること
AIツール、特にMCPサーバーには、ダウンロード数がうまく捉えない利用パターンがあります。多くのMCPサーバーは一度インストールされ、その後何ヶ月もローカルで動き続けます。インストール時に1ダウンロードが発生し、それ以降は毎日使われていてもダウンロード数はゼロです。これを、何千もの他パッケージの依存ツリーに含まれているために週に何百万回もダウンロードされるユーティリティライブラリと比べてみてください。
週500ダウンロードの極めて有用なMCPサーバーは、週5万ダウンロードのユーティリティライブラリよりも、日次のアクティブユーザーが多いかもしれません。ダウンロード数の比較ではライブラリが100倍人気だと示唆されますが、現実はかなり違うのです。
CI/CDによる水増し
CI/CD水増し効果はかなり大きいものです。あるパッケージがあるプロジェクトの依存関係として記載されており、そのプロジェクトに自動テストがあれば、テストの実行ごとにパッケージはダウンロードされます。100人のコントリビューターが日に何度もテストを走らせる人気プロジェクトは、CIだけで週に何千回もダウンロードを発生させます。これらは正当なダウンロードですが、100人のユーザーがインストールを決断した結果ではありません。
他パッケージの依存関係としてではなく、独立したアプリケーションとしてインストールされることが多いAIツールでは、CI水増しの影響は小さくなります。しかしAIツールのダウンロード数を、CI水増しの恩恵を受けるパッケージのダウンロード数と比べることは、誤解を招く比較を生み出します。
地理的・プラットフォーム的な変動
ダウンロード数は、パッケージレジストリ利用の地理的パターンも反映します。地域ごとのnpmミラー、別レジストリ、企業プロキシは、公式ダウンロード数に反映されることもされないこともあります。中国で人気のパッケージは、ダウンロードがメインレジストリとローカルミラーに分かれて、npmjs.comの統計だけでは真の普及度を測りにくいかもしれません。
プラットフォーム分布も重要です。Pythonパッケージとして配布されるMCPサーバーはnpm統計には現れず、その逆も然りです。パッケージエコシステムをまたいでダウンロード数でツールを比較することは、異なる測定システムを比較することになります。
代わりに何を使うか
ダウンロード数は複数のシグナルの一つとしては有用ですが、AIツールの主要な評価メトリクスにすべきではありません。より情報量の多いシグナルとしては、GitHub IssueとDiscussion(活発な利用を示す)、フォーク数(派生作業を示す)、コントリビューター数(コミュニティの投資を示す)、ディレクトリ掲載状況(キュレーションを示す)があります。
複数シグナルを組み合わせた複合メトリクスは、より信頼できる評価を提供します。中程度のダウンロード数だが活発なIssue、定期的な更新、キュレーション済みディレクトリへの掲載があるツールは、高いダウンロード数だが最近の活動がないツールよりも良い選択である可能性が高いものです。
MCPサーバーに関する限り、最も信頼できる利用指標はしばしばコミュニティの証言です。フォーラムでの体験記、ツール推薦、プロジェクトへの貢献などです。これらの定性的シグナルは、ダウンロード数より集約しにくいものですが、実際の利用と満足度については、はるかに多くを語ってくれます。