MCPに「設計上の欠陥」

何が起きたか：4月15日のOXセキュリティ開示

2026年4月15日、イスラエルのセキュリティ企業OXセキュリティが衝撃的な報告書を公開した。タイトルは「The Mother of All AI Supply Chains（全AIサプライチェーンの母）」——Anthropicが開発・維持するModel Context Protocol（MCP）の中核に、任意コード実行（RCE）を可能にする設計上の欠陥が存在するという内容だ。

この報告は単なる「実装のバグ」を指摘したものではない。MCPのアーキテクチャ設計そのものに起因する根本的な問題であり、Pythonを含む全サポート言語（Python、TypeScript、Java、Rust）のSDKに影響するという。

OXセキュリティの調査によれば、影響を受ける可能性のある範囲は：合計1.5億回以上のダウンロード、7,000以上の公開MCPサーバー、そして最大20万件の脆弱なインスタンスだ。

脆弱性の仕組み：なぜSTDIOがRCEを可能にするのか

MCPはAIエージェントとツールを接続するプロトコルだ。その通信方式の一つがSTDIOインターフェイスで、ローカルにMCPサーバープロセスを起動して通信する。

問題はこのプロセス起動の仕組みにある。MCPのSTDIO実装では、指定されたコマンドがMCPサーバーの起動に成功したかどうかに関わらず、そのコマンドが実行される。つまり、悪意あるコマンド文字列を「MCPサーバーの起動コマンド」として渡すと、コマンドが実行されてエラーが返る——しかしコマンド自体は既に実行済みだ。

この欠陥の本質は「コマンドをデータとして検証せず、直接実行する」設計にある。通常のウェブアプリケーション開発では「入力値をそのままシェルに渡してはいけない」というのは常識だが、MCPのSTDIO設計はこれを構造的に行っている。

影響範囲：1.5億DL・20万サーバー・Claude Codeも対象

OXセキュリティが確認した直接的に影響を受けるツールは以下の通りだ：

• Claude Code（Anthropic公式CLI）✅ 影響確認済み
• Cursor（AI対応IDEとして主要製品）✅ 影響確認済み
• VS Code（GitHub Copilot MCP拡張含む）✅ 影響確認済み
• Windsurf（CodeiumのAI IDE）✅ 影響確認済み
• Gemini-CLI（GoogleのMCPクライアント）✅ 影響確認済み

つまり、これはAnthropicだけの問題ではない。MCPという標準プロトコルを採用した全てのクライアントが影響を受ける、エコシステム全体に及ぶサプライチェーン上の問題だ。

TechRepublicはこの開示を「AIエラーの『Open Redirect』モーメント」と評した。Open Redirectとはウェブセキュリティの古典的な脆弱性で、URL検証の欠如がフィッシングやリダイレクト攻撃を可能にするものだ。MCPのSTDIO問題はこれと同様に、設計段階の決定がエコシステム全体の攻撃面を広げる構造になっている。

4つの攻撃ファミリー

OXセキュリティはこの脆弱性を悪用する攻撃方法を4種類のファミリーに分類している：

Anthropicの対応：「修正しない」という決断

最も議論を呼んでいるのがAnthropicの公式対応だ。OXセキュリティの報告を受けたAnthropicは、STDIOの動作を「設計上の期待された動作（Expected Behavior）」と位置付け、プロトコルアーキテクチャの変更を拒否した。

Anthropicの立場は「STDIOの実行モデルはデフォルトで安全であり、サニタイズはデベロッパーの責任だ」というものだ。つまり、MCPサーバー設定に信頼できないコマンドを含めることを防ぐのは、MCPを利用するデベロッパー・ベンダー側の実装責任であるという解釈だ。

このAnthropicの対応に対しセキュリティコミュニティからは批判も上がっている。「設計上の決定がサプライチェーン全体のリスクを生む場合、プロトコル設計者には修正責任があるのではないか」という議論だ。一方で「オープンプロトコルとして他の実装者が対処すべき」という見方もある。

エコシステムの対応：パッチを出したベンダー

Anthropicが修正しない中、自社製品にパッチを提供したベンダーが確認されている（✅ 複数情報源で確認済み）：

• DocsGPT：修正版をリリース済み
• Bisheng：修正版をリリース済み
• LiteLLM：修正版をリリース済み
• Upsonic：修正版をリリース済み

ただし、Claude Code、Cursor、VS Code、Windsurf等の主要MCPクライアントについては、各ベンダーが独自の緩和策を提供している可能性があるが、公式発表の有無は各製品ページで個別確認が必要だ。

MCP Registryのセキュリティ審査体制についても懸念が高まっている。OXセキュリティのテストで示された「11のレジストリ中9つで悪意あるパッケージが通過」という結果は、現時点でのMCPエコシステムのセキュリティ成熟度を象徴するものだ。

日本SaaSへの影響と今すぐすべき対応

KanseiLinkが把握する限り、現在日本SaaSで公式MCPサーバーを提供しているサービスにはfreee、Money Forward、kintone、Backlog、Garoonなどがある。これらのMCPサーバーを運営するベンダー、およびこれらのサーバーを利用する開発者・エージェント運営者は以下の対応を検討すべきだ。

MCPサーバーを「提供している」ベンダー向け

• STDIO設定のバリデーション強化：MCPサーバーの設定受け付け部分で、コマンド文字列のサニタイズとホワイトリスト制御を実装する。実行可能なプロセスを明示的に許可リストで管理する。
• セキュリティアドバイザリーの発行：自社MCPサーバーのユーザーに向けて、OXセキュリティの開示を受けた安全な使用方法を案内する。
• 依存パッケージの審査：使用しているMCP関連パッケージ（npm、PyPI等）の依存関係を棚卸しし、未検証パッケージがないか確認する。

MCPサーバーを「利用している」開発者・エージェント運営者向け

• MCPクライアントを最新版に更新：使用しているClaude Code、Cursor、VS Code等を最新バージョンに更新し、ベンダー提供のパッチを適用する。
• 信頼済みソース以外のMCPパッケージを禁止：npmレジストリや野良配布のMCPパッケージを組織のエージェント環境に追加しないポリシーを設ける。公式・検証済みのMCPサーバーのみを利用する。
• MCP設定ファイルのアクセス制御：mcp_config.json等の設定ファイルを書き込み可能な状態で外部コンテンツにさらさない。リポジトリのクローンや外部ファイルの読み込みがMCP設定を変更できない構成にする。
• サンドボックス環境での実行：エージェントが使用するMCPサーバーをサンドボックス（コンテナ、VM等）内で動作させ、ホスト環境への影響を限定する。

まとめ：MCPセキュリティの新しい現実

OXセキュリティの開示は、MCPが「AIエージェントの標準プロトコル」として普及するにつれて、セキュリティが後回しにされてきた構造的な問題を浮き彫りにした。

この問題の核心は技術的なバグではなく、設計上のトレードオフの問題だ。「簡単に使えるSTDIOインターフェイス」を選択した結果として、開発者がその安全な使用を保証する責任を負うことになった。Anthropicがこれを「Expected Behavior」とする立場は、技術的には一貫しているが、1.5億回ダウンロードされたプロトコルの設計者としての責任という観点では議論が続くだろう。

日本のSaaS・AIエージェントエコシステムにとって重要なのは、この問題が「Anthropicの問題」ではなく「MCPを使う全員の問題」だという認識だ。MCPサーバーを運営するベンダーも、MCPを使うエージェントを開発する事業者も、今日から対応を始める必要がある。

KanseiLinkは引き続き各MCPサーバーの安全性とセキュリティ対応状況を追跡し、AEOスコアに反映していく。