MCPに設計レベルの欠陥、AI各社が揃って「仕様通り」と回答

AnthropicのMCPに最大20万台のサーバー乗っ取りを許しうる設計欠陥が見つかった。研究者が修正を求めると「仕様通り」。AIを売り込みながら責任は下流に投げる、業界の構造的な姿勢が問われている。

情報の灯台

2026年4月20日

MCPのSTDIOが孕む問題

セキュリティ企業Ox Security（オックス・セキュリティ）が2025年11月から調査を開始し、AnthropicのMCPに深刻な設計上の問題を発見した。

MCP（Model Context Protocol）はLLMとアプリケーションが外部システムやデータに接続するための基盤プロトコルで、AnthropicがPython・TypeScript・Java・Rustを含む複数言語向けに公式SDKを提供している。問題はローカル通信に使われる STDIO（標準入出力）トランスポートにあった。本来はMCPサーバーをサブプロセスとして起動する仕組みだが、認証やサニタイズなしに任意のOSコマンドを実行できる経路として機能してしまう。

完全なサーバー制御の奪取につながるこの欠陥は、最大20万台のサーバーをリスクにさらし、 1億5000万 ダウンロード超のソフトウェアパッケージに波及しうるとOxは主張している。MCPを採用した開発者はAnthropicの公式SDKを使う以上、この問題を継承することになる。4つの攻撃ベクターが確認されており、非認証コマンドインジェクション、ハードニングバイパス（保護機能の迂回）、AIコーディング環境へのゼロクリックプロンプトインジェクション、MCPマーケットプレイス経由の感染がそれぞれ実証されている。

Oxのチームは繰り返しAnthropicに根本修正を求めた。しかしAnthropicはSTDIOの設計について「セキュアなデフォルトではないと認識しているが、これはMCPの仕様の一部だ」という立場を崩さず、プロトコルのアーキテクチャ変更を拒否し続けた。設計の問題と自認しながら修正しないという矛盾が、この問題の核心だ。

Oxの研究者たちは、プロトコルレベルで1つのアーキテクチャ変更を加えるだけで、MCPを使用するすべての下流プロジェクトと開発者を守ることができたと指摘している。それをしなかったことで、各パッケージが独立してパッチを積み上げ続けるという状況が生まれた。

Anthropicは報告の1週間後にセキュリティポリシーを更新し、STDIOアダプタを慎重に使うよう促した。Oxは「何も修正されていない」と断言する。注意書きを追加することと根本対処は別物だ。

GitHub Actionsでも同じパターン

MCPの問題とは別に、Anthropicの「Claude Code Security Review」、Googleの「Gemini CLI Action」（ジェミニ・CLI・アクション）、MicrosoftのGitHub Copilotという3つのAIエージェントに、GitHub Actionsを通じてAPIキーやアクセストークンを窃取できる脆弱性が発見された。

3社ともバグバウンティには応じた。Anthropicは 深刻度9.4 と評価しながら100ドルを支払い、GitHubは最初「再現できない」と回答した後に500ドル、Googleは1337ドルをそれぞれ支払った。

しかし3社いずれもCVEを発行せず、公開セキュリティアドバイザリも出さなかった。

深刻度9.4の問題へのバグバウンティが100ドルというのは、数字だけで十分に物語っている。発見した研究者はともかく、何も知らされないまま次の利用者になる可能性はそのまま残された。

責任が落ちる先は常に下流

「AIでセキュリティを強化せよ」と企業に促しながら、そのAI自体に欠陥が見つかると「仕様」「既知の問題」として開発者とユーザーに責任を転嫁する。そのパターンが一連の事例を通じて改めて浮き彫りになった。

プロンプトインジェクション（prompt injection）のように技術的な根本解決が困難な問題も確かに存在する。AIの非決定論的な性質に起因する場合、ベンダーレベルでの対処に限界がある。だがMCPのSTDIOの問題はそれとは質が異なり、Oxが指摘するようにプロトコルレベルの修正によって対処できたはずだ。

MCP関連の高・重大CVEはすでに 10件 に達しており、今後も増える見込みだ。プロトコルの開発元が動かない限り、個々のパッケージが独立してパッチを積み上げ続けるしかない状況が続く。

米国にはAI企業のセキュリティ対応を強制する連邦規制が現状存在しない。Anthropicは先日、自社の最新モデルが高度な脆弱性発見能力を持つとして一般公開を見送ったばかりだ。自社製品のリスクを認識しながら、同じ自社製品のセキュリティ問題を「仕様通り」で処理する非対称な姿勢は、規制の空白の中でどこまで続くのか。