Model Context Protocol（MCP）のセキュリティリスクや対策|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年09月01日更新日時: 2026年09月01日

Model Context Protocol（MCP）は、AIエージェントから外部ツール、データベース、SaaS、ファイル、クラウドAPIなどへ接続するための標準プロトコルです。

AIごとに個別の連携処理を開発する必要を減らし、共通方式で「何ができるか」をAIエージェントへ提供できる点が急速な普及につながっています。

一方、MCPサーバーはAIから見れば「外部システムを操作するための権限の入口」です。認証なしでインターネットへ公開したり、バックエンドの強力な資格情報を持たせたり、サーバーが提示するツール説明を無条件で信頼したりすると、情報漏えい、データ変更、クラウド資格情報窃取、コード実行などにつながる可能性があります。

米国NIST NCCoEは2026年2月に公表したAI Agent Identity and AuthorizationのConcept Paperで、MCPをAIエージェントが外部ツール・データ・サービスへ接続する標準として明示し、OAuthやOpenID Connectによる権限委任・認証を検討対象にしています。

イスラエル発のクラウドセキュリティ企業Wiz Researchは2026年7月、同社が観測するクラウド環境の80％でMCPの存在を確認し、約6環境に1つで少なくとも1台のMCPサーバーが外部公開されていたと報告しました。

MCPの普及速度に対して、認証・資産管理・最小権限が追いついていない企業では、「AI連携の便利な標準」がそのまま新しい攻撃面になる可能性があります。

MCPセキュリティのサマリー

【確認済み】NIST NCCoEはMCPをAIモデル・エージェントが外部ツール、データ、サービスへアクセスするための標準として扱っています。
【確認済み】NISTはMCPがOAuth、OIDCなど既存のアイデンティティ標準を利用すると整理しています。
【確認済み】MCP公式仕様ではHTTPベースの認証にOAuth 2.1を採用し、アクセストークンの対象リソース検証、PKCE、HTTPSなどを要求しています。
【確認済み】2026年7月28日のMCP仕様では認可サーバーの取り違え対策など、Authorizationがさらに強化されました。
【確認済み】Wizの観測データでは、同社が確認したクラウド環境の80％にMCPが存在し、約6環境に1つで少なくとも1台のMCPサーバーが外部公開されていました。
【確認済み】Wizが確認した公開MCPサーバーの約70％は匿名アクセスでツールカタログを返し、約42％はツール実行時に実データを返しました。
【確認済み】NVDには2026年、MCP関連で認証不備、SSRF、セッション混同、環境変数の露出など複数の脆弱性が登録されています。
【重要】Wizの数字は同社が観測するクラウド環境の統計であり、世界全体のMCP導入率を示すものではありません。
【本記事の整理】企業のMCP対策では「サーバーを発見する」「認証する」「バックエンド権限を絞る」「ツール実行を監査する」の4段階が最低限必要です。

主なリスク	何が起きるか	対策
認証なし公開	誰でもツールを呼べる	OAuth、ネットワーク制限
過剰なバックエンド権限	MCP経由でDB/IAMを広範操作	最小権限、専用サービスID
トークン誤用	別サービス向けトークンを悪用	audience検証、token passthrough禁止
SSRF	内部サービスやクラウドメタデータへ接続	URL検証、内部IP遮断
プロンプトインジェクション	AIが不正なツール呼出を実行	入力分離、実行ポリシー、人間承認
MCPサプライチェーン	悪性・侵害済みサーバーを追加	許可リスト、署名・提供元検証
監査不足	不正操作を後から追えない	prompts/tool calls/結果のログ

MCPとは

MCPは、AIエージェントと外部システムの接続方法を標準化するプロトコルです。

従来、AIからGitHub、データベース、クラウド、社内APIなどを使うには、サービスごとに個別の接続ロジックを作る必要がありました。

MCPではサーバー側が提供可能な「Tools」「Resources」などを機械可読な形で提示し、対応クライアントが同じ方式で呼び出せます。

セキュリティ対策Labでは、Xが公式MCPサーバーを公開した事例をX（旧Twitter）がMCPサーバーを提供開始で取り上げています。

利便性の裏側にあるのは、「AIが外部へ何を実行できるか」を共通化する仕組みでもあるという点です。

MCPサーバーにDB更新、メール送信、IAM変更、シェル実行などのツールが登録されていれば、AIはそれらを一連の作業として呼び出せます。

NISTもMCPを「AIエージェントの権限管理」の論点として扱う

NIST NCCoEが2026年2月に公開したConcept Paper「Accelerating the Adoption of Software and AI Agent Identity and Authorization」では、AIエージェントのID・認証・認可を検討する中でMCPが明示されています。

NISTはMCPについて、AIモデルやエージェントシステムが外部ツール、データソース、サービスを発見・利用するためのプロトコルと説明し、権限委任や認証にOAuth、OIDCなど既存標準を利用すると整理しています。

重要なのは、NISTがMCPを「AI固有の独立した認証方式」とは位置付けていないことです。

企業のIAMで使ってきた、

誰がアクセスするか
どのリソース向けの権限か
何を実行できるか
誰から委任された権限か
いつ失効するか

という原則をAIエージェントとMCPにも適用する方向です。

なお、このNIST資料は2026年2月時点のConcept Paperであり、確定した規格・義務ではありません。

MCP公式仕様はOAuth 2.1を採用

MCPの公式仕様では、HTTPベースのAuthorizationを利用する場合、OAuth 2.1に基づく認証・認可フローを定めています。

主なセキュリティ要件には以下があります。

アクセストークンをURLクエリへ含めない
HTTPSを利用する
PKCEを利用する
MCPサーバーは自分自身向けに発行されたトークンか確認する
別サービス向けトークンをそのまま下流へ渡すToken Passthroughを禁止する
OAuthのResource Indicatorsを使って対象リソースを明示する
不正なredirect URIを防止する

2026年7月28日の仕様更新では、Authorization Server Mix-Upへの対策として発行者情報の検証なども追加され、認証周辺の安全性がさらに強化されました。

MCP導入企業では「MCP対応している＝安全」ではなく、自社が利用しているクライアント・サーバーがどのプロトコル版を実装し、どの認証方式を有効にしているかを確認する必要があります。

Wiz調査では約6環境に1つでMCPサーバーを外部公開

Wiz Researchは2026年7月、クラウド環境に存在するMCPサーバーの露出状況を調査しました。

同社の観測データでは、

MCPは80％のクラウド環境で確認
約6環境に1つで少なくとも1台のMCPサーバーが外部公開
公開サーバーの約70％は匿名アクセスでツールカタログを返す
約42％はツールを呼ぶと実データを返す
約10％は機微なバックエンドへ接続
一部ではSSRFによってクラウドメタデータの一時資格情報へ到達

という結果でした。

これはWizが観測している環境を母集団とする調査です。世界中の全クラウド環境の80％にMCPがあるという意味ではありません。

それでも、MCPサーバーの存在を情報システム部門が把握していない「シャドーMCP」が現実的な管理課題になっていることを示しています。

なぜ公開MCPサーバーは通常のAPIより危険になりやすいのか

認証なしのAPIが危険なのはMCPに限りません。

一方、WizはMCP固有の特徴として、サーバー自身が機能を機械可読な形で説明することを挙げています。

MCPクライアントはtools/listなどを使い、利用可能なツール名、説明、引数のスキーマを取得します。

開発者にとっては便利ですが、認証なしで公開されていれば、攻撃者にとっても「このサーバーで何ができるか」を自動列挙する手段になります。

さらにMCPサーバーがバックエンドへ、

DB接続文字列
クラウドサービスアカウント
APIトークン
IAM権限

などを使って接続している場合、MCP側の認証不備がバックエンドの権限へ直結します。

MCPサーバーは単なる中継APIではなく、「特権プロキシ」になり得ると考えるべきです。

2026年にはMCP関連CVEも相次ぐ

NVDでは2026年、MCP関連の複数の脆弱性が登録されています。

代表例として以下があります。

CVE	概要
CVE-2026-35568	MCP Java SDKのDNS Rebinding。ローカル／内部MCPサーバーのツール呼出につながる可能性
CVE-2026-40159	PraisonAIのMCPプロセスへ親プロセスの環境変数を引き継ぎ、APIキー等が露出する可能性
CVE-2026-45609	MCP Security実装のOAuthメタデータ取得でSSRF対策不足
CVE-2026-52869	MCP Python SDKでセッションIDと認証主体の紐付け不足により、別クライアントからメッセージ注入の可能性
CVE-2026-44192	Ansible Lightspeed MCP Serverで間接的プロンプトインジェクションとPath Traversalが連鎖

これらは「MCPというプロトコル自体に一つの致命的欠陥がある」という意味ではありません。

SDK、フレームワーク、認証実装、ツール側の入力処理など、MCPエコシステムを構成するソフトウェアに従来型の脆弱性とAI固有の問題が同時に現れているということです。

プロンプトインジェクションとMCPが組み合わさると何が起きるか

MCPのリスクは認証だけではありません。

AIエージェントがWebページやメールなどから悪意ある指示を読み込み、その指示に従ってMCPツールを呼び出す場合、攻撃者がMCPサーバーへ直接アクセスできなくても間接的に操作できる可能性があります。

例えばAIに、

「受信メールを要約する」
「必要ならCRMを更新する」

という権限を与えている場合、悪意あるメール本文から間接的プロンプトインジェクションを受け、CRMの不正更新や外部送信ツールを実行する可能性があります。

MCP側が正しくOAuth認証していても、AIエージェント自身が正規ユーザーとして正規トークンを利用するため、通常の認証ログ上は不正アクセスに見えない場合があります。

このため必要なのは、認証だけでなく「許可された目的に沿ったツール呼出か」を判断する実行時ポリシーです。

MCPサーバーを「サービスアカウント」と同じように管理する

MCPサーバーがバックエンドへ接続する資格情報は、通常のサービスアカウントと同じ原則で管理します。

Wizも、MCPサーバーの役割を特権サービスアカウントと同様に扱い、最小権限を適用するよう推奨しています。

例えば、顧客検索だけが必要なMCPサーバーにDB管理者権限を与える必要はありません。

GitHub Issueを読むだけなら、リポジトリへのPush権限は不要です。

重要なのは、「エージェントが将来何をするか分からないから広い権限を与える」という設計を避けることです。

必要なツールごとに権限を分離し、書き込み、削除、外部送信、権限変更などは別の承認境界を設けます。

情報システム部門が実施すべきMCP棚卸し

まず必要なのは、社内にどのMCPサーバーが存在するかを把握することです。

開発者がClaude Desktop、Cursor、VS Code、各種AI IDEなどへローカルMCPサーバーを追加している場合、中央管理側から見えないことがあります。

確認項目は以下です。

社内端末で利用されているMCPクライアント
設定されているMCPサーバー
ローカル／社内／インターネット公開の区分
サーバー提供者と配布元
使用しているプロトコルバージョン
認証方式
利用可能なTools
バックエンド資格情報
読み取り／書き込み／削除権限
外部通信先
ログ取得状況

開発者が個別に追加したMCPサーバーを禁止するだけでは、シャドーIT化する可能性があります。

業務で必要なMCPサーバーを許可リスト化し、安全性審査・アップデート・監査ログを中央で管理できる仕組みが必要です。

MCP導入時のセキュリティチェックリスト

項目	確認内容
資産管理	MCPサーバーとクライアントを台帳化しているか
公開範囲	不要にインターネット公開していないか
認証	OAuth等を有効化しているか
Audience	トークンの対象MCPサーバーを検証するか
Token passthrough	下流APIへユーザートークンをそのまま渡していないか
権限	バックエンド資格情報は最小権限か
Tool	書込・削除・実行系ツールを分離しているか
SSRF	URL入力で内部IPやmetadata endpointを遮断するか
Prompt Injection	外部データ由来の命令で高リスクToolを実行しないか
Human approval	送信・削除・権限変更などを人間確認するか
Logging	prompts、tools/list、tools/call、結果を記録するか
更新	SDK・MCP Serverの脆弱性情報を監視するか