MCP は大きな問題を抱えている？導入前に検討すべき課題と知っておくべきセキュリティリスク
はじめに
こんにちは。クラウドエースの荒木です。
AI と外部システムの連携を標準化する Model Context Protocol (MCP) が、2024 年後半に Anthropic 社から発表されて以来 [1]、界隈では大きな注目を集めています。AI が様々なツールやリソースへ簡単にアクセスできるようになる「AI のための USB-C」というコンセプトは非常に魅力的です。実際に MCP に対応する Cursor や Zed といった開発ツールやさまざまな MCP サーバーなどが登場したことでエコシステムは着実に広がり、盛り上がりを見せています。私も以前、MCP の基本的な仕組みや将来性について解説する記事を書きましたが、思っていたよりも大きな反響がありました。
しかし、実際に MCP に触れたり関連情報を追っていく中で、課題も見えてきました。特に、前回良い面を中心に紹介した手前、今回はバランスを取る意味でも、MCP 導入を考える上で個人的に気になっている点について、少し紹介してみたいと思います。
課題 ①：ステートフルアーキテクチャの制約
私が課題に感じている点の 1 つが、そのアーキテクチャがステートフルであることです。これは、クライアント（AI 側）とサーバー（ツール側）の間で、stdio や SSE を用いて確立した接続を基本的に維持し続ける、という考え方ですね。
サーバーからの情報通知や後述するサンプリング機能のためにこの設計が採用されたと考えられますが、現代のクラウド開発で一般的なサーバーレスアーキテクチャとは親和性が低いという点は、個人的に少し残念に感じています。AI によるツール呼び出しの多くは短時間で完了するため、本来は必要な時だけリソースを使うサーバーレス（例：Google Cloud Functions, AWS Lambda）の方が適している場面も多いはずです。
しかし、MCP は永続的な接続を前提とするためサーバーレスでの運用が難しく、結果として仮想マシンやコンテナ等の常時接続可能なインフラが必要になります。これはサーバーレスの手軽さと比べると、どうしても運用コストや管理の複雑さが増加してしまいます。特に、迅速な開発やプロトタイピングが求められる際には、この点が課題になるのではないでしょうか。
AI がツールを使う場面は、多くの場合「これやって！」とお願いして、「できたよ！」と結果を受け取る、という一回ごとのやり取り（トランザクション）で済むことが多いと思います。それに対して、MCP は常に接続を保ち続ける必要があるので、そういったシンプルな使い方には、少し仕組みが大掛かりすぎる（＝余計な手間や制約がある）ように、感じられます。
課題 ②：サンプリング機能への疑問
次に私が課題に感じているのが、サンプリング（Sampling）機能です。これは、サーバー（ツール側）からクライアント（AI 側）に対して、LLM による応答生成をリクエストできるという、少し特殊な仕組みです。MCP の仕様書 [2] では、これによって高度な連携が可能になると説明されています。
しかし、この機能については、主に 2 つの点で本当に必要か疑問に感じています。
1 つ目は、セキュリティリスクです。サーバー側からクライアントに LLM の応答生成を要求できるという性質上、悪意のあるサーバーがこれを悪用する可能性は否定できません。例えば、巧妙なプロンプトを使って AI がアクセス可能な機密情報を引き出そうとしたり、不適切なコンテンツを生成させようとしたりする攻撃経路が考えられます。
もちろん、公式ドキュメントでは、メッセージ内容の検証や機密情報のサニタイズ、レート制限といった セキュリティ考慮事項 [2:1] が挙げられています。クライアント側（AI 側）でこれらの対策を適切に実装することが大前提となります。しかし、悪意のあるサーバーからの巧妙なリクエストを完全に防ぐための検証やサニタイズを実装することは容易ではなく、サーバーのリクエストをどこまで信頼し、どのように制御するかは、実装者にとって引き続き慎重な判断が求められるでしょう。
2 つ目は、実はこの機能はあまり使われていない可能性があるという点です。クライアント側から見れば、自身の LLM リソースを消費してまでサーバーの要求に応えるメリットは考えにくいです。実際に、主要なクライアント（Cursor など）でこの機能がサポートされているという情報は、私は今のところ見つけられていません（2025 年 4 月現在）。ステートフル設計を採用する大きな理由の 1 つとされている機能が、現実にはほとんど活用されていないように見えるのは、少し腑に落ちない点です。
プロトコルを複雑にし、ステートフルという制約の一因にもなっているこのサンプリング機能が、現状でその複雑さに見合うだけの価値を提供できているのか、個人的には懐疑的です。
課題 ③：開発者への負担とエコシステムの課題
3 つ目の課題として私が懸念しているのは、MCP を支える開発者への負担と、エコシステム全体に関わる問題です。
まず、既存 API とのアーキテクチャの違いです。MCP はステートフルな接続を要求しますが、Web API の多くはステートレスな REST アーキテクチャで作られています。既存の API を MCP に対応させるには、単にラッパーを作るだけでなく、インフラ構成の見直しが必要になる可能性があり、特にサーバーレス環境で API を提供している開発者にとっては、技術的・コスト的な負担がかなり大きいのではと感じます。
次に、MCP 対応を進める上での動機付けが弱いのではないか、という点です。開発者が対応するには工数がかかりますが、今のところ MCP エコシステムに参加することで得られる明確なメリットや収益化への道筋が見えにくい状況です。個人的には、現状の開発コストに見合うだけのメリットが提示されていない点が気になります。
加えて、AI エージェントの連携に関しては、MCP 以外のアプローチも活発に議論されています。 例えば、Google が提唱する A2A (Agent2Agent) プロトコルのように、エージェント同士の連携に特化した標準化の動きも出てきており、MCP とは異なるレイヤーでのエコシステム形成が進む可能性もあります。このように、AI とツール・エージェントの連携方法はまだ発展途上であり、MCP が唯一の標準となるかは不透明な状況と言えるでしょう。
そもそも、AI がツールを理解するために本当に複雑なプロトコルが必要なのか、OpenAPI のような標準的な「説明書」で十分なのでは？という疑問も湧いてきます。
さらに、エコシステムが拡大してきた際の運用面の課題も考えられます。MCP サーバーが増えると、ツール名やコマンド名が衝突するリスクがありますし、多数のツールを AI に登録することで LLM のコンテキストウィンドウを圧迫し、AI の応答品質が落ちる懸念も指摘されています。実際にツールが増えてくると、これらの問題はかなり現実味を帯びてくるのではないでしょうか。これらを解決するには、AI が状況に応じて適切なツールだけを選び出すような、高度なツールルーティングの仕組みが必要になるかもしれません。
課題 ④：セキュリティリスク
MCP が AI と外部ツールの連携をスムーズにする一方で、見過ごせないのが潜在的なセキュリティリスクです。この点については、arXiv で公開された論文 [3] で、MCP サーバーのライフサイクル（作成、運用、更新）全体を通じた様々な脅威が指摘されていました。読んでいて「確かにな〜」となる内容でしたので、ここで主なものを紹介します。
作成フェーズのリスク
サーバー導入時には、以下のようなリスクが考えられます。
- 名前衝突：悪意あるサーバーが正規サーバーになりすまし、ユーザーを騙してインストールさせる。
- インストーラスプーフィング：偽のインストーラにより、マルウェアを含むサーバーが導入される。
- コードインジェクション・バックドア：サーバーコード自体に悪意あるコードが埋め込まれ、後の不正アクセスを招く。
運用フェーズのリスク
サーバー稼働中にもリスクは潜んでいます。
- ツール名・コマンド競合：名前が重複し、意図しない、あるいは悪意あるツールが実行される。
- サンドボックスエスケープ：サーバーが隔離環境（サンドボックス）の脆弱性を突き、不正なアクセスを行う。
- サンプリング機能の悪用：前述の通り、サーバーからクライアントへの不正な要求が行われる可能性がある。
更新フェーズのリスク
サーバーのアップデート時にも注意が必要です。
- 権限維持： アップデート後も不正な権限が残ってしまう、または新たな脆弱性が導入される。
- 脆弱バージョンの再デプロイ： 意図せずセキュリティ修正前のバージョンに戻してしまう。
- 設定ドリフト： 更新時に意図しない設定変更（セキュリティ緩和など）が発生する。
これらのリスクは、MCP を利用するユーザー、AI 系のアプリケーション・サーバー開発者の全員が認識しておくべき重要な点だと思います。プロトコルの安全性強化はもちろん、信頼できるサーバー配布の仕組みや、利用時の適切な権限管理といった対策が、今後ますます重要になってくるでしょう。
MCP の代替案「agents.json」とその思想
MCP の課題、特にステートフル性や複雑さを考えていくと、「もっとシンプルな連携方法はないのかな？」と思うようになりました。そこで調べてみると、実際に MCP とは異なるアプローチも提案されているようです。
その中で特に興味深いと感じたのが、Wildcard AI が提唱している agents.json というアイデアです [4]。これは MCP のような専用プロトコルを作るのではなく、既存の OpenAPI Specification（OAS） [5] をベースにして、AI が API の使い方を理解するためのメタデータを標準化しよう、という考え方です。
基本的な流れはシンプルです。
- API 提供者は、まず OAS で API 仕様を記述する
- 次に、AI が API をうまく使うために必要な追加情報（自然言語での説明や利用例など）を、
agents.jsonという形式で加える - AI はこれらの情報を読んで、API の使い方を理解する
- 実際の API 呼び出しは、通常のステートレスな HTTP リクエストで行う
このアプローチの最大の魅力は、そのシンプルさと既存技術との親和性の高さだと感じます。
- ステートレス：多くの REST API と同じで、サーバーレス環境とも相性が良いです。
- 開発者の負担軽減：新しいサーバーを立てる必要がなく、既存の API 仕様に情報を追加するだけで済むのは、開発者にとって大きなメリットでしょう。
- 標準技術の活用：広く普及している OAS を活用するため、既存ツールとの連携もスムーズです。
もちろん、agents.json はまだ発展途上のアイデアであり、MCP が目指すような双方向通信はできません。しかし、「AI が外部 API を使う」という基本的な目的のためには、多くの場合はこれで十分とも思えます。複雑なプロトコルではなく、AI とツールの「共通言語」としてのメタデータ標準に焦点を当てるという考え方は、今後の AI エージェント開発において、非常に現実的で有力な選択肢の 1 つになるのではないでしょうか。
まとめと所感
さて、ここまで Model Context Protocol (MCP) について、その期待感と同時に、私が個人的に感じている課題やリスクについて、色々と紹介してきました。
MCP が目指す「AI のための USB-C」というコンセプトは、確かに魅力的です。AI が外部のツールやデータとシームレスに連携できれば、その可能性は無限に広がるでしょう。関連ツールも少しずつ出てきて、エコシステムが動き出しているのを感じます。
「でも、良いことばかりじゃないよね」というのが正直なところです。
- サーバーレス全盛の時代に、ステートフルなアーキテクチャはちょっと運用が大変そうだし、コストも気になる。
- サーバーから AI に指示を出すサンプリング機能って、セキュリティ的に怖い。 しかも、あまり使われてない様子。
- 既存の API を MCP 対応させるのは、開発者にとっては結構負担になりそう。メリットがもっと明確じゃないと、なかなか手が出せない。ツールが増えた際の名前衝突や、AI の記憶容量の問題など、運用面も心配。
- そしてやはり、セキュリティリスク。論文で指摘されていたように、導入から運用、更新まで、注意すべき点が多く存在する。
これらの課題は、MCP が本当にデファクトスタンダードになるためには、乗り越える必要のある壁だと感じています。もちろん、今後のプロトコル改善（ステートレス連携をサポートするようになるとか...）や、セキュリティ対策の強化、開発者をもっと応援する仕組みに期待したいところです。
あと、忘れてはいけないのが agents.json みたいな、もっとシンプルな代替案の存在でしょう。全部が全部 MCP じゃなくても、既存技術ベースの簡単なメタデータで十分なケースも多いんじゃないかな、とも思います。
結論として、MCP は大きな可能性を秘めていますが、その一方で、今回の記事で紹介したような課題やリスクもしっかり理解しておくことが重要だと、私は考えています。「流行ってるから」「新しいから」という理由だけで飛びつくのではなく、メリットとデメリットを天秤にかけて、自分たちの目的や状況に本当に合っているのか、冷静に見極める視点が必要なのではないでしょうか。
ただし、AI と外部システムの連携技術は日進月歩です。 Google の A2A プロトコルのような新しい標準が登場し、MCP を補完しながらエコシステム全体が進化していく可能性も十分に考えられます。MCP 自体も、今後ステートレスな連携をサポートするなど、改善されていくかもしれません。
MCP は依然として大きな可能性を秘めた技術であり、その動向を引き続き注視していく価値は大きいでしょう。 大切なのは、現時点でのメリット・デメリットを理解しつつ、将来の技術トレンドや自社の状況に合わせて、最適な連携方法を選択していく柔軟な姿勢なのかもしれません。
Discussion