モデルコンテキストプロトコル(MCP)とは ― AIツール連携の新規格とそのセキュリティ
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/list・tools/call・resources/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はローカル子プロセス起動のためネットワーク境界の攻撃面は持たないが、ユーザ権限で任意コード実行可能な実行ファイルを常駐させることを意味する。npxやuvxでの起動設定が広く流布しているが、これは実質「未監査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 の結論
- 事実: MCPは2024年11月に公開され、1年で主要AIクライアントが追随するデファクト標準となった一方、Tool Poisoning・Indirect Prompt Injection・サプライチェーン攻撃など複数の実証済み脅威が公表されている。
- 判断軸: 「どのMCPサーバを」「どのTransportで」「どの権限トークンと」「誰の承認で」動かすかという四軸を、従来のサードパーティリスク管理フレームに接続して評価する。
- 打ち手: 許可リスト配布+最小権限トークン+リモート集約ゲートウェイ+Human-in-the-loop+監査ログの五点セットを最短で構築し、野良MCPの端末直起動を段階的に廃止する。
経営者視点で考えるべきこと
MCPの真のインパクトは「プロトコル」そのものではなく、AIエージェントが社員のPCと社内システムを直接操作する時代が実運用フェーズに入った点にある。「AIに何を答えさせるか」で十分だった企業は、今後「AIに何を実行させてよいか」「誰の名義で、どのログ下で」を定義する必要がある。これは情報セキュリティにとどまらず、内部統制(J-SOX)、個人情報保護、契約上の再委託条項にまで波及する論点だ。経営者が問うべきは、(1)AIエージェント誤作動時のインシデント対応プレイブックが存在するか、(2)AIの行為責任を特定できる監査証跡が残っているか、(3)サードパーティMCPサーバの利用が調達・法務レビューを通っているか、の三点。MCPは生産性のレバーであると同時に、これまで人間に閉じていた「権限濫用リスク」をソフトウェアに拡張する装置でもある。AI活用の競争力と統制の両立は、ガバナンス設計解像度を一段上げた企業のみが勝ち残るフェーズに入った。
参考文献・出典
- Anthropic「Introducing Model Context Protocol」2024-11-25
- MCP公式 https://modelcontextprotocol.io/
- MCP Architecture docs https://modelcontextprotocol.io/docs/concepts/architecture
- GitHub modelcontextprotocol/servers
- OpenAI Agents SDK — MCP support 2025
- MCP Specification https://spec.modelcontextprotocol.io/
- MCP Spec「Streamable HTTP transport」2025-03-26
- OpenAI Docs「Function calling / Responses API」
- MCP Spec「Authorization, OAuth 2.1」2025-06-18
- Invariant Labs「GitHub MCP Indirect Prompt Injection」2025
- Invariant Labs「MCP Tool Poisoning Attacks」2025
- Snyk「Malicious MCP servers on npm」2025
- Simon Willison「MCP prompt injection problems」2025
- HiddenLayer「Tool Description Injection」2025
- Trail of Bits「Auditing the MCP ecosystem」2025
- OWASP「Top 10 for LLM Applications 2025」
- Cloudflare「Remote MCP servers」2025


