私が最初にモデル・コンテキスト・プロトコル（MCP）について書いたときに伝えたかったことは、とてもシンプルでした。それは、MCP は“知能”そのものではなく、その土台となる“配線”であるという点です。MCPで標準化できることは、エージェントがどのようにツールを見つけ、どう使うかという仕組みであって、ガバナンスやアイデンティティ、安全性を直接提供するものではありません。この基本的な位置づけは今も変わっていません。ただし、ここ数カ月で多くの学術研究が登場し、その“配線”に負荷をかけながら検証するようになりました。
その結果、MCP の現状についてより正確で厳密な理解が得られています。具体的には、MCPは急速に成熟し、実際のプロダクトに組み込まれるケースが増えつつある一方で、運用リスクに直結するセキュリティ研究の主要対象にもなっているということです。
本記事では、そうした最新の研究をまとめ、それぞれがどのような内容を扱っているのかを整理し、MCPを実環境で運用する人にとってどんな意味を持つのかをわかりやすく解説します。そして最後に、まだ解決されていない課題と、これから必要となる取り組みについて考察します。
MCPの進化（これまで）
まず押さえておきたいのは、MCP の仕様そのものです。2025年6月18日の改訂では、クライアント側にroots、sampling、elicitationといった機能が追加され、サーバー側にもprompts、resources、tools、utilitiesなどの概念が整理されました。ただし、MCP の根幹は変わっていません。「トランスポートに依存しないチャネル上でJSON-RPCを用いる」「ツールやコンテキストを宣言的に扱う」という基本的な考え方はそのままです。この改訂では、OAuthをベースにした認可モデルが正式に位置づけられ、さらに混乱した代理問題やサプライチェーン攻撃のような、MCPならではのリスクを踏まえたセキュリティのベストプラクティス文書も追加されました。
こうした更新内容を踏まえると、MCP の進む方向がはっきりと見えてきます。プロトコルとして十分安定しており、実際の製品に組み込みやすく、企業が気にする運用面の課題にも仕様策定者が本格的に取り組み始めているということです。とはいえ、認可に関する仕様は細かな実装部分をインテグレーターに委ねており、本番運用におけるセキュリティは、MCPホスト・クライアント・サーバーの三者が協力して確保する必要があります。
MCPセキュリティに関する学術的整理
前提が固まった上で、現時点でもっとも包括的な学術レビューとして位置づけられるのが、Houらによるランドスケープ論文です。この論文は、MCP サーバーがどのように作られ、どのように運用され、どのように更新されるかというライフサイクル全体を描き出し、それぞれの段階に潜むリスクと、それに対して取り得る対策を体系的に整理しています。
この研究が価値を持つのは、技術的な側面だけではありません。セキュリティチームやプラットフォームチームにとって、共通の分類体系と段階的な思考モデルを提供しており、社内プラットフォームがサービスをオンボードし、稼働させ、廃止するプロセスと整合します。実際の運用に当てはめることも容易で、「作成」はサーバーのオンボーディングやコードレビューに、「運用」は認証・認可、ログ、可観測性などの日常的な管理に、「更新」はサプライチェーンの健全性や変更管理に対応すると捉えることができます。もし自社の MCP 運用体制がまだこうしたライフサイクルの考え方を十分に取り入れていないのであれば、この論文はその重要性を強く示すものと言えるでしょう。
安全性
Houらの研究が全体像を示す「地図」だとすれば、RadosevichとHalloranの研究は「安全性を徹底的に検証したテスト」と言えます。彼らが発表した"MCP Safety Audit "では、ツールの誤用や悪意あるサーバーをきっかけに、悪意あるコードの実行、リモートアクセス、資格情報の窃取といった、具体的な攻撃パターンがどのように発生するかを実証しています。さらに、彼らはMCPSafetyScannerという監査ツールも公開しており、対象となるMCPサーバーのツールを自動で調査し、攻撃的なプロンプトを生成し、リスクを評価したレポートを出力できるようになっています。
本番環境を担当するチームにとって、この研究は「理論」と「CI/CD 運用」をつなぐ実践的な橋渡しになります。APIやコンテナを扱うのと同じ考え方で、MCP サーバーも管理すべきだということです。つまり、サーバーを社内カタログに登録する前や更新時にはスキャンを実施し、危険な挙動が検出された場合はビルドを停止し、リスクの高いツールはより厳格な同意やポリシーを通じて利用を制限するといった運用が求められます。今回の研究によってランタイムのリスクが完全になくなるわけではありません。しかし、すぐにデリバリーパイプラインへ組み込める、再現性のある制御手段を提供しています。
スケーラビリティ
Hasanらの研究は、これまでとは別の問いを投げかけています。それは、「オープンソースのMCPサーバーのエコシステムは、大規模になるとどうなるのか」というものです。
彼らは1899のリポジトリを分析し、従来型の脆弱性に加えて、ツール汚染攻撃のようなMCP特有の問題も特定しました。また、コードの保守性に関する指標として、コードスメルやバグパターンなども定量化しています。
そのため、本番環境に当てはめて考えると厳しい現実が浮かび上がりますが、実務上は非常に有益な示唆を与えてくれます。つまり、サードパーティのサーバーを取り込むのであれば、一般的なSASTやDASTでは検知できないMCP特有のリスクを、一定の割合で含んでいるものとして扱う必要があるということです。さらに、初回の審査だけではなく、継続的な衛生管理を計画的に行うことが重要です。カタログとは、商品を眺める場所ではありません。自社が運用する「攻撃対象領域」そのものなのです。
選好操作
次の論点となっているのが「選好操作」であり、Wangらの研究はその理由を示しています。彼らが提唱するMCP Preference Manipulation Attack（MPMA）は、攻撃者がサーバーやツールのメタデータを操作することで、エージェントが選ぶツールを意図的に偏らせることができるという点です。わざとらしくメタデータを書き換える場合もあれば、説明文に対して遺伝的探索を行うなど、巧妙に仕込まれたものもあります。そうした操作によって、悪意のあるサーバーがエージェントのランキングで“上位に選ばれる”ように誘導できてしまいます。
この問題は、実運用において開発者体験やカタログのガバナンスに直結します。もしホスト側が、似たような機能を持つツールの中からエージェント自身に「最適なもの」を選ばせる仕組みを採用しているのであれば、そのランキングそのものが攻撃対象となることを前提にしておく必要があります。
この研究から導かれる実践的な対策は二つあります。まずは信頼できるサブカタログの範囲に選択を限定すること。そして人間向けに書かれた説明文とランキングモデルが利用する特徴量を切り離すか、あるいはメタデータに署名して固定化し、テキストではなくポリシーで選定基準を制御することです。
この研究は、多くのPoCで見過ごされている大きな穴を浮き彫りにしています。すなわち、「エージェントに最適なツールを自動選択させる」という設計がスマートに見える一方で、実は攻撃者に操作の余地を与えている という現実です。
MCPのその先へ
Ferragらの研究は、視点をMCPからより広い範囲まで対象を広げていますが、その結論はやはりプロトコルレベルのリスクに戻ってきます。彼らの調査では、入力操作、モデルの汚染、システムやプライバシーへの攻撃、プロトコル悪用など、30 を超える攻撃手法を分類して整理しており、その中にはMCPを標的としたものも含まれています。この研究の価値は新しい攻撃手法を示すことではなく、バラバラに見える多様なリスクを一つの脅威モデルとして統合し、チームがどこに優先順位を置くべきか判断しやすくした点にあります。
実際の運用では、この知見は複数のレイヤーにまたがる防御戦略として落とし込まれます。たとえば、RAGでは取得プロセスの強化が求められ、データやツールの出力に情報源の追跡が必要になります。ホスト側ではコンテンツセーフティポリシーを適用し、ツールの呼び出しやサンプリングについてはMCPを理解したうえでの制御が必要になります。結論として、MCPのセキュリティをエージェントのセキュリティと切り離して考えることはできません。両者をまとめて扱える、一貫した脅威モデルが必要になるということです。
攻撃の分類と防御計画
学術研究の全体像を補うものとして、もう 2 つの流れがあります。まずSongらは、MCP特有の攻撃を体系的に分類した初めての研究を示しています。そこには、ツール汚染攻撃、サーバーによるエージェントを操り（puppet attac）、悪意ある更新によるラグプルl、サーバーが参照する外部リソースを悪用する手法などが含まれています。これらを本番環境に当てはめると、署名付きアーティファクトの利用、バージョン固定、更新内容のレビュー、そしてメタデータや挙動が変化した際にツールを無効化あるいは制限できるポリシーエンジンの導入が必要になります。
同時に、防御を中心に据えた研究も進み始めています。XingらのMCP-Guardは、敵対的プロンプトやツール操作を検知する多層的なパイプラインを提案し、さらにMCP-AttackBenchという評価フレームワークを導入しています。
こうした取り組みはまだ初期段階ではありますが、MCPのトラフィックに「コードとしてのガードレール」を設けようとする人にとって重要な基盤となります。また、セキュリティ対策の低下を測るためのベンチマークとしても役立ちます。これらの技術がアイデンティティ管理やポリシーの必要性をなくすわけではありませんが、テスト可能で自動化しやすいセキュリティ基準へとエコシステムを前進させることができます。
MCPシステム評価の基盤づくり
すべての研究が攻撃手法の解明を目的にしているわけではありません。近年は、MCPシステムを現実的な条件のもと評価するための基盤を作る研究も増えてきています。
MCP-Zeroはは、大規模環境におけるツールの発見と選択を扱う中で、数百のサーバーと数千のツールを収集したデータセットを構築しました。そのほか、MCP-Universeや MCPSecBenchのようなベンチマークは、より広範なタスクやセキュリティ重視のシナリオをまとめています。これらは狭い意味での「セキュリティ研究」ではありませんが、実際のリスクが単純な事例ではなく、複雑に組み合わさった「ロングテール」の状況で表面化することを考えると、こうした基盤づくりは非常に重要です。もしアーキテクチャが手作業で選んだツールだけでテストに合格しているのであれば、それはアーキテクチャをテストしているのではなく、単に選別作業をテストしているだけです。
業界側の調査も成熟し始めており、学術研究ではなくても耳を傾ける価値があります。Red Hatのガイダンスは、ローカルサーバーとリモートサーバーでリスクが異なることを整理しつつ、混乱した代理問題やサンプリングの悪用、サプライチェーン管理の重要性を指摘しています。これはベストプラクティス文書と方向性が一致しており、運用者にとって実践的な助言が含まれています。CyberArkの詳細な分析は、レッドチームが実際の行動に移せる形で脅威モデリングを整理しており、特に多くの PoCでは問題視されない 「ツールの組み合わせの複雑さ」や「サンプリングの挙動」に焦点を当てています。
こうした研究や分析の価値は、新たな脆弱性を発見したからではありません。すでにセキュリティチームが日々使っている運用手順に、学術研究の知見をどう組み込めばいいのかを示しているからです。
MCPの注意点
現時点で解決されていない課題は何でしょうか。
まず認可の問題があります。仕様としては整備されていますが、実運用での安全性を担保できるほど標準化は進んでいません。OAuthを基盤にする考え方は正しいものの、実際には実装者が「どのように発見するか」「トークンのスコープをどう設計するか」「クライアントをどのように信頼するか」を個別に決めており、ホストやサーバーごとにばらつきがあります。相互運用できるフローを備えたリファレンス実装が普及し、より明確な形になるまでは、企業側が認可の“最後の詰め”を自分たちで固めざるを得ません。たとえば組織のSSOを強制するプロキシ、トークンの仲介、ツールごとの細かいスコープ設定などを企業側で導入する必要があります。公式仕様のベストプラクティスは参考になりますが、自社のテナント構成、データ、監査要件を理解したうえで機能するポリシーレイヤーの代わりにはなりません。
次にサプライチェーンの完全性も、まだ十分に対応が整っているとは言えません。ラグプルやツール汚染に関する研究が示す通り、本来であれば「署名付きアーティファクト」や「バージョン固定」は当たり前であるべきです。しかし現状では、URLからサーバーを取り込み、そのサーバーが報告するメタデータをそのまま信頼しています。さらに、ツール記述やサーバーの証明情報を署名付きで提供し、更新後もその正当性が保証され、必要であれば失効にも対応できるような標準は、まだ広く普及していません。こうした仕組みが整うまでは、MCPサーバーをパッケージ管理と同じように扱うべきです。つまり、署名を必須とし、情報源を検証し、更新は変更管理プロセスで審査し、挙動に異常があれば自動的にロールバックできるようにしておく必要があります。
三つ目の課題は、ツールの順位付けの信頼性と公平性が、アーキテクチャの根本からまだ十分に解決されていない点です。選好操作が成立してしまう理由は、ツールのランキングがホスト側のヒューリスティックとモデルの提案が混ざり合った結果生じるからです。このループを強化するには二つの方法が必要になります。ひとつは、モデルが判断する前に、ポリシーで候補を明確に制限すること。もうひとつは、ランキングの判断基準として、変更可能なテキストに過度に依存させないことです。研究ではすでに問題点が整理されていますが、実際に手を動かすのはプロダクトチームです。カタログやホストの UI を、いわゆる「スマートな自動選択」に頼るのではなく、ユーザーが自分で選択し、同意できる設計へと転換する必要があります。
四つ目は、実行時のガードレールがまだ初期段階にあることです。MCP-Guardなどの取り組みは期待できますが、あくまでシステムの隣に置かれた分類器であり、システムが本質的に守られるわけではありません。今後必要なのは、危険な動作より安全な動作のほうが自然に選ばれるような、プロトコルレベルの仕組みです。たとえば、ホストが必ず尊重すべき宣言的なツールの属性情報や、破壊的操作に対する標準化されたポリシー、さらにSIEMへそのまま送れる監査イベントといった機能です。仕様はより豊かな構造定義や運用指針へ進化しつつありますが、現時点ではコントロールプレーンの設計はベンダーやデプロイ環境に大きく依存しています。
最後に、計測基盤がまだ不十分です。大規模なベンチマークが出始めているのは良い傾向ですが、多くはシステムが壊れる原因となる複雑な組み合わせを再現できていません。たとえば、テナントをまたぐデータの機微を伴う長時間タスク、異なる信頼ドメインが混在する状況、ツールを連鎖的に使っていく中で3つ目の段階で秘密情報が漏れるケースといった、実運用では当たり前に起きる複雑な状況が、ほとんどのベンチマークには含まれていないのです。こうした現実的な課題を組み込んだベンチマーク、そしてそれに対してテスト可能なホスト側のポリシーが整うまでは、製品間でセキュリティ水準を比較したり、時間をかけて改善していくことは難しいままです。
現在の到達点
この一連の研究から得られる最も大きな教訓は、MCPに潜むリスクが特別なものではなく、「ソフトウェアに行動する力を与えた以上、必然的に生まれる結果」だという点です。
良いニュースとしては、今では研究のおかげで共通の言語が生まれ、実際に使える対策も見えてきました。仕様は成熟し、コミュニティはスキャナーやベンチマークを作り、企業のチームはそれらの知見を運用の指針へ落とし込み始めています。
これから重要になるのは、新たなバグを発見することではなく、ガードレールを標準として整えていくことです。たとえば、相互運用できる認可フロー、署名付きで証明を確認できるサーバー、安全性を強制できるツール情報、ホスト側での安心できるデフォルト設定、そして危険な挙動をしっかり検出できるベンチマークなどが挙げられます。こうした基盤が整うまでは、MCPは「強力なインターフェース」として扱うべきです。つまり、配線したとおりに正確に動くものとして想定し、その動きを観測できるように計測し、API やマイクロサービスと同じレベルのアイデンティティ管理・ポリシー・変更管理で制御する必要があります。MCP はエージェントを使えるものにします。エージェントを「安全に使える」ようにするのは、あなたのプラットフォームの役割です。
Markus MuellerによるMCPのさらなる考察については、本シリーズの過去記事もぜひご覧ください。
“How to Use Model Context Protocol the Right Way”
“
MCP: What’s Changed, What Still Matters, What Comes Next.”
本記事はAIのサポートを受けて執筆されました。