スターの数では守れない：MCPエコシステムにおいて人気は安全性の証にはならない

重要なポイント

9,695件のModel Context Protocol（MCP）サーバを分析した結果、人気度・活動状況・検証バッジは、いずれも安全性を確実に示す指標とはならないことが分かりました。検証済みサーバの平均的なセキュリティ問題件数は未検証サーバとほとんど変わらず、また広く採用されているリポジトリでは、利用がセキュリティ管理の追いつかない速度で広がると、影響範囲がかえって大きくなる可能性があります。
本調査では、影響を受けた2,259件のサーバにわたって4,982件のセキュリティ問題を整理しました。その中には、任意ファイルアクセス、コマンドインジェクション、サーバサイドリクエストフォージェリ（SSRF）、SQL（Structured Query Language）インジェクションなどが含まれます。これらの欠陥は、任意ファイルアクセスと認証の欠如が組み合わさるなど、複数が同時に現れることが少なくありません。これは、個別のコーディングミスというより、入力値検証や基本的なセキュリティ対策における広範な不備を示しています。
脆弱なMCPサーバは、暗号資産や分散型金融（DeFi）のツール、オフィス自動化ソフトウェア、エンタープライズ向けアプリケーションなど、幅広い領域で確認され、いずれも重大なサプライチェーンリスクをもたらします。MCPサーバは、AIエージェントをターミナル、データベース、ファイルをはじめとする特権的なリソースに接続できるため、広く採用されている、あるいは検証済みのサードパーティ製サーバであっても、リスクを免れません。
組織は、公開マーケットプレイス上の「ソーシャルスコア」を決して鵜呑みにせず、MCP連携には常にゼロトラストの考え方を適用すべきです。具体的には、導入前にサードパーティ製コードをレビューし、認証と最小権限を徹底し、入力値を検証し、トラフィックに不審な挙動がないかを監視します。MCPサーバは、人気度や検証ステータスではなく、実際に備わっているセキュリティ対策に基づいて評価すべきです。

はじめに

Model Context Protocol（MCP）は、大規模言語モデル（LLM）と、ローカルおよびリモートに散在するデータとの間を橋渡しする標準として、いまや主流の地位を確立しています。MCPは統一されたインターフェースを提供することで、AIアプリケーションを、コードの実行、データベースへの問い合わせ、クラウドインフラの管理までこなす能動的な「エージェント型ワークフロー」へと進化させます。この急速な普及により、MCPディレクトリは、台頭しつつあるAI経済の重要な基盤となっています。

しかし、この進化のスピードは、従来型のセキュリティ対策の実装を大きく上回ってきました。本リサーチチームは、前回の研究「一網打尽：AIで挑む19,000台のMCPサーバ脆弱性調査」において、多段階のアプローチとランダムな手動検証を組み合わせ、オープンソースのMCPサーバに対する自動セキュリティ分析を実施しました。この分析からは、一般に公開されているMCPサーバが実際にどれほど脆弱であるかという、憂慮すべき実態が明らかになりました。

もっとも、セキュリティ問題を洗い出すことは、全体の一部分にすぎません。こうした問題がAIエコシステムに及ぼし得る影響をより包括的に把握するには、人気度、開発の活発さ、実際の採用状況といった尺度と照らし合わせて評価することが重要です。これが、本フォローアップ研究の狙いです。

よくある思い込みとして、人気のあるアプリケーションディレクトリや、知名度が高く活発なプロバイダーを利用すれば、脆弱なアプリケーションに行き当たる可能性が下がる、というものがあります。しかし、必ずしもそうとは限りません。本リサーチはこの思い込みに疑問を投げかけるものであり、MCPのセキュリティ問題の分布が、人気のあるソフトウェア作者や、プロバイダーによって検証されているはずのサーバと、必ずしも相関しないことを示します。さらに、こうした脆弱性がAIソフトウェアのエコシステムとそのビジネスに及ぼす大きな影響を、具体例を交えて示します。

データセットの調査とセキュリティ問題の内訳

2025年11月から2026年3月にかけて、本リサーチチームは、主要な4つのMCPディレクトリ（GitHub、Glama、Lobehub、PulseMCP）をクロールし、人気度、作者、コミット数、使用言語など、関連するメタデータをすべて抽出しました。そのうえで、これらのディレクトリの登録情報を、前回の研究で発見したセキュリティ問題と突き合わせました。

全体として、ディレクトリのメタデータが取得できたMCPサーバは、重複を除いて9,695件を特定しました（表1）。そのほとんどはGitHubに掲載されており、同時に他のディレクトリの1つ以上にも掲載されている場合があります。そのため、ディレクトリごとの件数は互いに重複しており、単純に合算できるものではありません。

各ディレクトリからは、MCPサーバに関するメタデータ、その説明、ユーザーが残したコメント、スター数や活動状況のレポート、そのほかディレクトリ固有の情報まで、すべて抽出しました。

9,695件のサーバのうち、本調査のセキュリティ監査では、5,832件のサーバにセキュリティ問題が見つかりました。前回も述べたとおり、認証の欠如のみを理由に「安全でない」と判定された3,573件のサーバは、ここには含めていません。認証の欠如は、他のセキュリティ問題と組み合わさった場合には依然として悪化要因とみなされますが、それ単体でMCPサーバを問題ありと判定するほど深刻だとは考えませんでした。その結果、セキュリティ問題が確認されたサーバは2,259件となりました。

単なる認証の欠如以外のセキュリティ問題が見つかったこれらのサーバからは、表2に示すとおり、4,982件の問題を特定しました。

各問題は、次の3つのリスクカテゴリのいずれかに分類しました。

脆弱性：開発者が意図せず作り込んでしまった、悪用につながり得るセキュリティ問題
設計上の脆弱性：サーバにとって有害となり得る挙動を生む設計上の問題。コードインジェクションは、開発者の仕様に従い、ユーザーの入力要求を通じてローカルで実行されるコードを指します。
悪意ある挙動：プロンプトインジェクションなど、クライアントや関連するエージェント型システムに害を及ぼし得る挙動

よくある思い込みを検証する

リポジトリの活動状況から見たセキュリティ問題の傾向

次に、別の思い込み、すなわち「開発活動が活発なサーバほど安全かもしれない」という考えを検証しました。

コミットの総数は、これまでの開発の積み重ねと、継続的なメンテナンスの度合いを表します。人気度を測るスター数とは異なり、コミット数は、どれだけのコードが書かれ、変更されてきたかを表します。コミット数が多いほど、コードの面積は広がり、リファクタリングも増え、その分だけ作り込まれるセキュリティ問題も増えがちですが、一方で修正の機会も多くなります。

非常に活発なサーバ（コミット100以上）：コードベースが最も大きく、変更も最も蓄積されているリポジトリです。ここでの問題件数の多さは、怠慢というより、コードパスの多さ、連携の多さ、エッジケースの多さといった、純粋な複雑さの表れである可能性があります。
活発なサーバ（コミット50〜99）と中程度のサーバ（コミット10〜49）：MCP開発の主流を占めるグループです。概念実証（PoC）の段階は越えているものの、本番運用に耐える成熟度には達していないプロジェクトです。急速な機能開発の過程で作り込まれた脆弱性が、まだレビューも対処もされていない、という状態が典型的に見られます。
活動の少ないサーバ（コミット1〜9）：コードベースが最も小さく、最も発展途上のグループです。
コミットのないサーバ（0件）：コミット履歴が記録されていないリポジトリで、ミラー、新規コミットのないフォーク、あるいは正しくインデックスされていないリポジトリである可能性が高いものです。その問題の傾向は、独自の開発活動ではなく、フォーク元のソースを反映しています。

先ほどと同様に、1台あたりのセキュリティ問題件数を平均してみると（図2）、実際に開発が行われている各階層の間では、相関はほとんど、あるいはまったく見られません。例外はコミットのないサーバで、平均が最も高くなっていますが、これはミラーやフォークという性質を反映したものです。これらの問題は、自らの開発を通じて作り込まれたものではなく、上流のソースから受け継いだものです。いずれにせよ、より活発に開発されているMCPサーバであっても、セキュリティ問題の影響を免れてはいません。

検証済みサーバと未検証サーバの比較

もう1つのよくある思い込みは、検証ステータスがあれば、そのソフトウェアパッケージが安全であると確実に分かる、というものです。MCPディレクトリは、掲載するサーバの信頼性を、さまざまな方法で検証しています。たとえば、MCP Inspectorを用いてコードに脆弱性がないかを調べる、ソーシャルプルーフ（スター数、訪問者数、更新の新しさ）を追跡する、所有者を確認しサーバを審査する、といった手法です。こうした手法は、特にアプリマーケットプレイスのモバイルアプリでは効果を上げてきましたが、MCPエコシステムでは、まだ同じようには機能していないようです。

図3では、検証済みのソースと未検証のソースについて、1台あたりの平均セキュリティ問題件数を比較しました。

図3. 検証済みサーバと未検証サーバにおける、1台あたりの平均セキュリティ問題件数

ここでもやはり、検証済みリポジトリと未検証リポジトリとの間で、1台あたりの平均問題件数に有意な差は見られませんでした。

細部にこそ問題が潜む

セキュリティとソフトウェア採用に関する代表的な思い込みを検証してきましたが、ここからは、MCPディレクトリのより注目すべき側面に目を向けます。なお、倫理上および法律上の理由から、データは匿名化しています。本リサーチの目的は、特定の開発者を名指しすることではなく、エコシステム全体の性質をとらえることにあるためです。

エコシステムへの影響

人気度の指標としてのGitHubのスター数と、深刻度の指標としてのセキュリティ問題件数を突き合わせることで、深刻度で重み付けした波及度の指標が得られます。たとえば、スターが80,000件あり、問題件数が中程度のサーバは、広く採用されているがゆえに、大きな影響と広がりを生み出します。

図4では、横軸にスター数のロングテール分布を示しています。右上の象限に位置するサーバ（スターが多く、かつ問題件数も多いサーバ）は、AIエコシステムにとって戦略上最も大きなリスクを表します。これらは、最も広くインストールされていると同時に、セキュリティ問題の影響も最も大きく受けているサーバです。情報が公開されれば、最も即座に大きな影響が及ぶのも、こうしたサーバです。

図4. MCPエコシステム全体における、人気度とセキュリティ問題の交差（注：バブルの大きさは、公開されているMCPツールの数を表します）

図4のバブルの大きさは、公開されているMCPツールの数を表しており、これは各サーバの攻撃対象領域（アタックサーフェス）を測るもう1つの指標でもあります。サーバが公開するツールが多いほど、それぞれのセキュリティ問題が悪用される可能性も高まります。

セキュリティ問題の共起

もう1つの注目すべきパターンは、影響を受けたMCPサーバ全体で確認された、セキュリティ問題の共起です。本リサーチでは、これを出現頻度の高い順に並べました。各サーバには、検出された問題のすべて（スキャン間での重複は除外）を割り当て、その組み合わせそのものを1つの「指紋（フィンガープリント）」として扱います。

図5の横棒グラフは、影響を受けたサーバ数に基づき、最も多く見られた問題の組み合わせの上位10件を示しています。

単一の問題のみを抱えるサーバと、複数の問題が組み合わさったケースを並べて比較することで、大半のセキュリティ問題が個別に独立して見つかるものなのか、それとも予測可能なまとまりとして固まって現れる傾向があるのかが見えてきます。

ソフトウェア作者ごとのリスクプロファイル

セキュリティ問題のレポートと、ディレクトリから得た作者のメタデータを突き合わせ、セキュリティ問題の件数や深刻度の点で際立つソフトウェア作者がいないかを評価しました。

図6は、影響を受けたサーバ数の多い順に上位20のソフトウェアプロバイダーを、セキュリティ問題のカテゴリ別に分解して示したものです。問題の種類を、脆弱性、設計上の脆弱性、悪意ある挙動という3つの大きなカテゴリに集約することで、各プロバイダーのリスクプロファイルの性質が明確になります。

リスクの圧倒的大部分は「脆弱性」に分類されます。つまり、設定上の弱点というより、悪用可能な欠陥です。「設計上の脆弱性」（認証なし、コードインジェクション）は無視できないものの、あくまで二次的であり、通常は本来の脆弱性に重なる形で現れる悪化要因です。「悪意ある挙動」（プロンプトインジェクション）は、依然としてニッチではあるものの、特に自然言語による問い合わせインターフェースを公開しているサーバを抱えるプロバイダーにとって、増大しつつある懸念です。カテゴリの構成がプロバイダー間で比較的均一であることは、弱点が個別的なものではなく、構造的なものであることを示唆しています。根本にあるのは、特定のプロバイダーの怠慢ではなく、MCPツールのパラメータにおける入力値検証の欠如が業界全体に及んでいることです。

ユースケース

調査結果をさらに詳しく見ていく中で、より深い分析に値するいくつかのユースケースを特定しました。AIエコシステムが進化しがちな速さを踏まえると、これらの例は、そのまま活用できる脅威情報というより、教訓を示す事例としてとらえるべきものです。

Provider_1

この作者は、数多くのMCPサーバを公開しており、そのすべてが暗号資産取引と分散型金融（DeFi）の領域に属します。ここは、ユーザーの金銭的資産を扱う重大な領域であり、それだけに、コードから見つかったセキュリティ問題の件数は一層憂慮されます。

たとえば、取引ニュースの取得を担うMCPサーバでは、サーバサイドテンプレートインジェクションが確認されました。悪意を持って細工されたニュースコンテンツによって、サーバサイドでの完全なコード実行を許してしまう恐れがありました。さらに、取引を分析するMCPサーバではプロンプトインジェクションが見つかり、これによって、そのMCPサーバを利用するエージェントの挙動が直接書き換えられる可能性がありました。

金融システムへのアクセス、認証の欠如、そして多数のサーバ群にまたがる複数のコード実行経路。これらが組み合わさることで、このプロバイダーは、MCPサーバの提供元として最もリスクの高い部類に入ります。ツールを読み込んだClaudeデスクトップアプリのセッションが1つ侵害されるだけで、不正なブロックチェーン取引、認証情報の窃取、あるいはサーバの完全な乗っ取りにつながりかねません。

Provider_5

この作者は、人気のあるMCPサーバをいくつか開発しており、中にはGitHubで最大1,000件のスターを獲得しているものもありますが、セキュリティ機能はほとんど、あるいはまったく顧みられていませんでした。スターが100件を超えるあるサーバでは、MCPツールが直接「eval()」を呼び出しており、Pythonコードを直接実行できてしまうコードインジェクションの欠陥が見つかりました。また、オフィス関連のあるMCPサーバでは、パストラバーサルも見つかりました。

Provider_3

Provider_3は、エンタープライズ特有のリスクプロファイルを示します。これらのサーバは、企業の財務、人事、ID管理の各システムに、本番環境で組み込まれることを想定して設計されています。にもかかわらず、本リサーチでは、複数のMCPサーバでSQLインジェクションを確認しました。AIエージェントに公開されたMCPツールにSQLインジェクションが存在すると、巧妙に細工された自然言語クエリによってそれが引き起こされ、想定されているはずのLLMによるサニタイズの層を回避されてしまう可能性があります。

さらに、Active Directory（AD）へのクエリに認証なしでアクセスできる状態も確認しました。これは、LLMエージェントが、MCP層でのアクセス制御を受けることなく、ADのオブジェクトや属性を列挙できてしまうことを意味します。悪意ある攻撃者は、これを偵察や権限昇格に悪用する可能性があります。

まとめ

MCPエコシステムの急速な拡大は、エージェント型AIの未来に、機会とリスクの両方をもたらします。MCPは、LLMがエージェント型システムへと進化するための不可欠な基盤を提供する一方で、本リサーチの結果は、人気度やリポジトリの活動状況といった日常的な指標が安全性の代わりになる、という思い込みに疑問を投げかけます。GitHubのスター、活発なコミット履歴、検証バッジといったこれらのシグナルは、現時点では、重大な脆弱性がないことを確実に保証するものではありません。

本リサーチの分析は、開発者が現在MCPサーバを調達している方法そのものに潜む、重大なサプライチェーンリスクを浮き彫りにします。こうしたツールの多くは、ターミナルでの実行、ファイルシステムの操作、データベースへの問い合わせといった、低レベルのシステムアクセスを行えるよう設計されているため、その性質上「特権的」です。

コード監査を行わずにサードパーティ製のMCPサーバを組み込むことには、大きなリスクがあります。利用者は、主に2つの脅威を認識しておく必要があります。

脆弱なリポジトリ：善意で作られてはいるものの、セキュリティが不十分なコードであり、外部の攻撃者にとっての侵入口（たとえばSSRFやSQLインジェクションを介したもの）となります。
悪意あるリポジトリ：エージェントに接続された途端に、認証情報を窃取したり、暗号資産ウォレットを空にしたり、内部ネットワークの偵察を行ったりするために、意図的に作り込まれたサーバです。

エコシステムが成熟していく中で、開発者は「デフォルトで信頼する（trust-by-default）」という発想から脱却し、「信頼するが検証する（trust-but-verify）」という姿勢を取る必要があります。インターネットから入手したMCPサーバはすべて、未検証のサードパーティ製コードとして扱うべきです。

静的コード解析は不可欠ですが、それだけですべてを解決できるわけではありません。この状況を乗り切るために、AI業界には、次のことができるリアルタイムのセキュリティソリューションが求められます。

トラフィック検査：AIエージェントとMCPサーバ間の通信を監視し、異常なペイロードを検出すること
問題の予防：プロンプトインジェクションやコマンド列といった悪意ある入力を、実行層に到達する前に自動的に捕捉し、ブロックすること
挙動のベースライン化：MCPサーバが本来の機能から逸脱した瞬間を特定すること。たとえば、「天気ツール」が突然「/etc/passwd」へアクセスを試みるような場合です。

TrendAI™は、こうした防御の転換の最前線に立ち、AIアプリケーションの導入環境を保護するために設計された専用ソリューションを提供しています。トラフィックをリアルタイムにスキャンする保護層を実装することで、TrendAI™は、組織が脆弱性を緩和し、サプライチェーンの脅威を無力化できるよう支援します。これにより、エージェント型ワークフローへの移行を、生産性と安全性の両面を保ちながら進めることができます。

MCPは、AIにおける「思考」と「行動」の隔たりを、これからも橋渡ししていきます。最終的に、セキュリティの責任は、コードを書く開発者と、その実行を監視する高度なセキュリティシステムとの間で分担されなければなりません。

著者について

TrendAI™ Researchのフォーワードスレットリサーチチーム（Forward-Looking Threat Research Team）は、1〜3年先の技術を見通すことを専門とし、技術の進化、その社会的影響、そして犯罪への応用という3つの異なる側面に焦点を当てています。同チームは、2020年以来、AIとその悪用の可能性を監視してきました。同年には、Europol（欧州刑事警察機構）および国連地域間犯罪司法研究所（UNICRI）と共同で、このテーマに関する研究論文（英語）を執筆しました。

参考記事

Stars Don’t Save You: Popularity Is Not Security in the MCP Ecosystem
By: Vincenzo Ciancaglini , Marco Balduzzi , Alfredo Oliveira , and David Fiser

翻訳：与那城務（Platform Marketing, TrendAI Research）

タグ