モデルコンテキストプロトコル(MCP)とは ― AIツール連携の新規格とそのセキュリティ

Picsum ID: 177

2024年11月、AnthropicはAIアシスタントと外部ツール・データを接続する標準プロトコル「Model Context Protocol(MCP)」をオープンソースとして公開した[1]。公開から1年あまりでClaude Desktop、Cursor、Cline、Zed、Windsurfなど主要AI開発環境が対応し、数千のサードパーティサーバが公開されるデファクト規格となった[2]。一方でMCPはAIエージェントに強力な権限を授ける仕組みであるがゆえに、認証・権限境界・プロンプトインジェクション経由のツール悪用という新種のリスクを連れてきた。本稿ではCISO・情シス担当者向けに、MCPの技術的輪郭、既知の脅威、実運用で取るべき守りの設計を整理する。

MCP誕生の経緯と採用状況

MCPはAnthropicが2024年11月25日に公開したオープン仕様で、「LLMアプリケーションに外部コンテキスト・ツール・データを接続する標準化インターフェース」を目指す[1]。それまでOpenAI Function calling、LangChain Tools、各社独自プラグインが乱立し、同じGoogle Drive連携でも実装ごとに仕様が異なる「M×Nの組み合わせ爆発」を抱えていた。MCPはこれをUSB-Cのように「M+N」へ圧縮することを狙った[3]。公開と同時にGitHub・Slack・Postgres・Puppeteer・Filesystemなどリファレンス実装が公開され[4]、2025年にはOpenAI Agents SDKがMCPクライアント対応を表明、Google・Microsoftも追随、特定ベンダ仕様から業界標準へ急速にシフトした[5]。Block、Apollo、Replit、Sourcegraphなど早期採用事例も相次ぎ、2026年現在エンタープライズAIエージェント基盤の前提技術となっている。

プロトコル概要:Server/Client/Transport

MCPはJSON-RPC 2.0をメッセージ層に採用したクライアント・サーバ型プロトコルで、三概念が核となる[6]ServerはAIに公開したい機能を「Tools(副作用のある関数)」「Resources(参照可能データ)」「Prompts(テンプレート)」の三種で提供する。ClientはClaude DesktopやCursorなどホストアプリに常駐しLLM-Server間を仲介する。Transportは通信路で、ローカル子プロセス経由のstdio、HTTPベースのSSE、2025年3月改訂で導入されたStreamable HTTPの三系統がある[7]。初期initializeでプロトコルバージョンとケーパビリティを合意し、以降tools/listtools/callresources/readが続く。ツール定義はJSON Schemaで記述され、LLMはそれを読んだ上で呼び出しを決定する。OpenAI Responses APIのFunction callingが「モデルへの関数定義の渡し方」に閉じた規約であるのに対し、MCPは「プロセス間・ネットワーク間の標準プロトコル」にまで拡張した点が本質的な違いとなる[8]

セキュリティ観点の主要リスク

MCPが解消した「M×N」問題の裏返しとして、「一度サーバを掌握すれば複数クライアントに攻撃できる」非対称性が生まれた。主要リスクは五系統。(1)認証・認可の未成熟。初期仕様には明確な認証層がなく、環境変数でトークンを流す運用が一般化した。2025年6月改訂でOAuth 2.1が必須化されたが[9]、既存の野良サーバの多くは未対応だ。(2)Indirect Prompt Injection。Resource本文やツール結果に命令文が混入するとLLMが従う。GitHub IssueやSlackメッセージなど外部由来コンテンツは全て攻撃面になる[10](3)Tool Poisoning / Rug Pull。Invariant Labsが2025年に報告した、初回は無害なツール記述を後から書き換えて機密窃取を促す手法[11](4)トークン窃取とConfused Deputy。MCPサーバはGitHub PAT・AWS鍵・DB資格情報を預かるため、サーバ汚染で資格情報が一括流出する。(5)サプライチェーン攻撃。npm・PyPI配布のMCPサーバにtyposquatや悪意あるアップデートが紛れ込むリスクは、通常のOSS依存関係攻撃と同質かつ影響範囲がより広い[12]

Transport別の攻撃面

Transportごとに攻撃面の性質は大きく異なる。stdioはローカル子プロセス起動のためネットワーク境界の攻撃面は持たないが、ユーザ権限で任意コード実行可能な実行ファイルを常駐させることを意味する。npxuvxでの起動設定が広く流布しているが、これは実質「未監査OSSを毎回最新版で自動実行」でありマルウェア配布経路として極めて危険だ[13]SSE(および後継Streamable HTTP)はリモート配置が可能になる代わりに、認証・TLS終端・CORS・DNSリバインディング耐性を正しく設計する必要がある。Invariant Labsは2025年、ローカルSSE型サーバへのブラウザ経由DNS rebinding PoCを公表した[11]。エンタープライズ導入ではstdio型を管理端末で直接動かさず、隔離ゾーンのリモートMCPサーバをmTLSとOAuthで保護する構成が推奨される。

実在する脆弱性・事故

2025年前半以降、MCPセキュリティ研究が相次いで公表された。Invariant Labsは、GitHub Issues経由で注入された命令がClaude Desktop上のGitHub MCPサーバを悪用し、プライベートリポジトリ内容をパブリックPRで漏洩させるPoCを公開した[10][11]。HiddenLayerはツール記述自体に隠された指示を埋め込むことでLLMに意図しない行為をさせられることを示した[14]。Trail of Bitsや独立研究者からは、複数サーバ同時接続時に「別サーバのツール呼び出しを奪う」シャドーイング攻撃、ローカルサーバのコマンドインジェクション、公式filesystemサーバのパストラバーサル類の指摘も挙がっている[15]。2025年にはコミュニティ製MCPサーバがポストインストールスクリプトで環境変数を外部送信していた事案も報告され、OSS MCPサーバ監査の必要性が改めて認識された[12]

安全な導入パターン

エンタープライズ展開の設計原則は七点。(1)許可リスト運用—Claude Desktop/Cursorの設定ファイル(claude_desktop_config.json等)を情シスが管理配布し、任意追加をMDM/EDRで制御する。(2)最小権限トークン—GitHubはfine-grained PATで単一リポジトリ・読取限定、クラウド鍵はIAMでAPIを絞る。(3)サーバ固定化npx @latestのような実行時フェッチを避け、ハッシュ固定コンテナか社内プロキシ配信にする。(4)リモート集約—端末直起動をやめ、ゲートウェイに集約して監査ログ・レート制御・DLPを挟む。(5)Human-in-the-loop—破壊的ツール(書込・送金・外部送信)はユーザ承認を必須化する。(6)間接プロンプト対策—Resource出力は「命令として解釈するな」と明示し、サニタイズとコンテンツタイプのラベル付与を行う。(7)監査ログ—ツール呼出・引数・結果を構造化ログで保全しSIEMへ転送する。OWASP “Top 10 for LLM Applications” のLLM06(Excessive Agency)はMCP設計レビュー観点として直接使える[16]

チェックリスト

  • MCPサーバの導入は情シス承認制とし、許可リスト管理している
  • 各サーバに払い出す資格情報は最小権限で、漏洩時の影響を1サービス1リポジトリ等に封じ込めている
  • OAuth 2.1対応(2025-06仕様以降)か、未対応サーバはネットワーク隔離している
  • 破壊的ツールはユーザ承認必須・監査ログをSIEMに連携している
  • 外部由来コンテンツ(Issue・メール・DB行)を扱うツールに対しIndirect Prompt Injection対策を講じている

打ち手

短期では、社内利用中MCPサーバの棚卸しから着手するのが現実的。Claude Desktop/Cursor/Clineの設定ファイルは端末ローカルにあるため、EDR経由でclaude_desktop_config.jsonを収集し、サーバ種別・発行トークン・Transport方式を台帳化する。中期ではリモートMCPゲートウェイを自社構築または商用(Cloudflare MCP、Anthropic公式リモートMCPなど[17])で導入し、認証・監査・DLPを一元化する。長期ではMCPをAIガバナンスポリシーに正式に組み込み、プロンプトインジェクション評価・レッドチーミング・社員教育のサイクルを確立したい。

ツールを与える前に、境界と監査を設計せよ。

Omamori AI の結論

  1. 事実: MCPは2024年11月に公開され、1年で主要AIクライアントが追随するデファクト標準となった一方、Tool Poisoning・Indirect Prompt Injection・サプライチェーン攻撃など複数の実証済み脅威が公表されている。
  2. 判断軸: 「どのMCPサーバを」「どのTransportで」「どの権限トークンと」「誰の承認で」動かすかという四軸を、従来のサードパーティリスク管理フレームに接続して評価する。
  3. 打ち手: 許可リスト配布+最小権限トークン+リモート集約ゲートウェイ+Human-in-the-loop+監査ログの五点セットを最短で構築し、野良MCPの端末直起動を段階的に廃止する。

経営者視点で考えるべきこと

MCPの真のインパクトは「プロトコル」そのものではなく、AIエージェントが社員のPCと社内システムを直接操作する時代が実運用フェーズに入った点にある。「AIに何を答えさせるか」で十分だった企業は、今後「AIに何を実行させてよいか」「誰の名義で、どのログ下で」を定義する必要がある。これは情報セキュリティにとどまらず、内部統制(J-SOX)、個人情報保護、契約上の再委託条項にまで波及する論点だ。経営者が問うべきは、(1)AIエージェント誤作動時のインシデント対応プレイブックが存在するか、(2)AIの行為責任を特定できる監査証跡が残っているか、(3)サードパーティMCPサーバの利用が調達・法務レビューを通っているか、の三点。MCPは生産性のレバーであると同時に、これまで人間に閉じていた「権限濫用リスク」をソフトウェアに拡張する装置でもある。AI活用の競争力と統制の両立は、ガバナンス設計解像度を一段上げた企業のみが勝ち残るフェーズに入った。

参考文献・出典

  1. Anthropic「Introducing Model Context Protocol」2024-11-25
  2. MCP公式 https://modelcontextprotocol.io/
  3. MCP Architecture docs https://modelcontextprotocol.io/docs/concepts/architecture
  4. GitHub modelcontextprotocol/servers
  5. OpenAI Agents SDK — MCP support 2025
  6. MCP Specification https://spec.modelcontextprotocol.io/
  7. MCP Spec「Streamable HTTP transport」2025-03-26
  8. OpenAI Docs「Function calling / Responses API」
  9. MCP Spec「Authorization, OAuth 2.1」2025-06-18
  10. Invariant Labs「GitHub MCP Indirect Prompt Injection」2025
  11. Invariant Labs「MCP Tool Poisoning Attacks」2025
  12. Snyk「Malicious MCP servers on npm」2025
  13. Simon Willison「MCP prompt injection problems」2025
  14. HiddenLayer「Tool Description Injection」2025
  15. Trail of Bits「Auditing the MCP ecosystem」2025
  16. OWASP「Top 10 for LLM Applications 2025」
  17. Cloudflare「Remote MCP servers」2025
SHARE 𝕏 in f

あわせて読みたい