🔓 MCP脆弱性の本質｜AIエージェント時代の『サプライチェーン攻撃』がなぜ防げないのか

目次

• MCPの脆弱性は「バグ」ではなく「設計思想」の問題
• そう考える3つの理由
  • 「実行してから検証」というアーキテクチャの致命性
  • 影響範囲が桁違い——AIエージェントのサプライチェーン
  • Anthropicが修正を拒否した理由とその代償
• まとめ：エージェント時代のセキュリティを今から考える

---

MCPの脆弱性は「バグ」ではなく「設計思想」の問題

セキュリティ企業OX Securityが4月16日に公開したレポートは、AIエージェント業界に激震を走らせた。AnthropicのModel Context Protocol（MCP）——AIエージェントが外部ツールと通信するための事実上の標準規格——にアーキテクチャレベルの重大な脆弱性があるというものだ。

しかもこれは「うっかり入ったバグ」じゃない。MCPの設計思想そのものに根ざした構造的な問題。Anthropicが修正を「想定された動作」として拒否したことが、それを物語っている。

わたしはこのニュースを見て、「AIエージェントのセキュリティって、思ってたよりずっと根が深いんだな」と感じた。そしてこれは、MCPを使っている開発者だけの問題じゃなく、AIエージェントの時代に突入する全てのSaaS企業やユーザーにとっての重要な問題だと思う。

---

そう考える3つの理由

「実行してから検証」というアーキテクチャの致命性

まずMCPの脆弱性の技術的な核心を理解しておきたい。

MCPはローカル通信にSTDIO（標準入出力）というメカニズムを使っている。AIアプリケーションがMCPサーバーをサブプロセスとして起動し、その入出力を通じてコマンドをやり取りする仕組みだ。

問題は、このプロセス起動の段階。MCPクライアントが「サーバーを起動するコマンド」として受け取った文字列を、そのままOSコマンドとして実行してしまう。正当なMCPサーバーが立ち上がればハンドルを返すし、全く別のコマンド——例えばファイルの削除やデータの送信——でも、エラーを返す前に実行は完了してしまう。

The Registerの報道によれば、この「Execute First, Validate Never（実行してから検証——いや、検証すらしない）」というパターンが、Python、TypeScript、Java、Rustの全ての公式SDKに組み込まれている。

従来のWebアプリのセキュリティなら、「入力のバリデーション→実行」が基本中の基本。でもMCPはその順序が逆転している。これは個別の実装ミスではなく、プロトコル設計そのものの問題。だから個々のMCPサーバー開発者がいくら頑張っても、根本的には防げない。

影響範囲が桁違い——AIエージェントのサプライチェーン

この脆弱性の怖さは、影響範囲のスケールにある。

OX Securityの調査によると：

• 150M+のダウンロード（MCP SDKの累計）
• 7,000+の公開サーバー
• 最大200,000の脆弱なインスタンス
• Cursor、VS Code、Windsurf、Claude Code、Gemini-CLIが影響対象

さらにOXは実際に、LiteLLM、LangChain、IBM LangFlowを含む6つの本番プラットフォームでコマンド実行に成功している。理論上の脆弱性じゃなくて、実際に悪用できることが証明済み。

なぜこれほど影響が広がるのか？それはMCPが「プロトコル」として設計されているからだ。MCPは1つのアプリケーションのセキュリティホールじゃない。エコシステム全体のインフラ。MCPの上に構築されたすべてのツール、サーバー、クライアントが、この設計上の欠陥を「継承」してしまう。

これはまさに「サプライチェーン攻撃」の構造そのもの。2020年のSolarWinds事件では、1つの監視ツールの侵害が米政府機関を含む18,000の組織に波及した。MCPの脆弱性は、AIエージェント版のSolarWindsリスクとも言える。

Anthropicが修正を拒否した理由とその代償

OXはAnthropicに対して「根本的な修正」を複数回提案したが、Anthropicはこれを拒否し、「想定された動作である」と回答したと報じられている。

なぜ修正しないのか？推測だけど、MCPのSTDIO転送は「ローカル環境で信頼できるプロセスを起動する」という前提で設計されているのだろう。つまりAnthropicの立場からすると、「誰がどんなコマンドをMCPクライアントに渡すか」は、MCP自体の責任範囲外——それを管理するのは各アプリケーション開発者の責任、という考え方だ。

技術的には一理ある。しかし現実問題として、MCP SDKを使う開発者の多くはセキュリティの専門家ではない。7,000以上の公開サーバーの開発者全員が、STDIO転送の挙動を完全に理解した上で適切なサンドボックスを実装しているとは考えにくい。

しかも10件のCVEが発行されているにもかかわらず、プロトコルレベルの修正が行われないということは、この脆弱性は今後も存在し続けることを意味する。

---

まとめ：エージェント時代のセキュリティを今から考える

MCP脆弱性の問題は、単なるセキュリティインシデントを超えた、AIエージェント時代の構造的課題を浮き彫りにしている。

AIエージェントは「ツールを自律的に操作する」存在だからこそ価値がある。でもその「自律性」は、セキュリティの観点からすると「攻撃の自動化」と紙一重。エージェントが増えれば増えるほど、サプライチェーンの各ノードに潜む脆弱性の影響は指数関数的に拡大する。

今後MCPベースのツールを導入・開発する際は、少なくとも以下の点を確認すべきだと思う。

1. MCP サーバーの起動コマンドをバリデーションしているか——自前で入力検証レイヤーを追加する必要がある
2. サンドボックス環境で実行しているか——コンテナやE2Bなどの隔離環境が必須
3. ネットワークアクセスを制限しているか——MCPサーバーからの外部通信を最小限に絞る

AIエージェントの利便性とセキュリティのバランスは、2026年最大の技術的テーマの一つになるだろう。MCPの脆弱性問題は、その最初の大きな警鐘だ。

ソース:

• Anthropic won't own MCP 'design flaw' putting 200K servers at risk — The Register
• Critical, Systemic Vulnerability at the Core of MCP — OX Security
• Systemic Flaw in MCP Protocol Could Expose 150 Million Downloads — Infosecurity Magazine

よくある質問

Q.この記事はどんな内容ですか？

A.Anthropic MCPプロトコルに発覚した致命的脆弱性の技術的本質を解説。200Kサーバー・150M+ダウンロードに影響するアーキテクチャ上の欠陥から、AIエージェント時代のセキュリティ課題を深堀り考察。

Q.情報はいつ時点のものですか？

A.2026-04-18 時点でまとめた情報です（2026-04 の動向）。AI関連の動きは速く、最新状況は変動する可能性があるため、公式発表や一次ソースもあわせて確認してください。

Q.読者としてどう受け止めればよいですか？

A.本記事は「世間の見方」「筆者の見解」「データ・事実」「これから考えておきたいアクション」の流れで整理しています。AIツールの使い方や仕事のあり方に関わる動きとして、自分の状況に置き換えて読んでみてください。