MCPのセキュリティリスクと対策｜エンジニアが押さえる脅威・脆弱性と導入チェックリスト

MCP（Model Context Protocol）の登場により、生成AIに自社のデータやツールを直接操作させる開発が一気に現実的になりました。便利な反面、「AIに何を・どこまで触らせるか」の設計を誤ると、情報漏えいや意図しない操作に直結します。

実際、認証も暗号化も設定されないまま公開されているMCPサーバーが多数発見されており、悪意あるMCPパッケージが約2週間にわたって検知されずにメールデータを外部へ流出させた事例も報告されています。MCPのセキュリティは「いつか考えること」ではなく、実装初日から組み込むべき前提になりました。

この記事では、エンジニア・システム担当者がMCPを安全に扱うために、MCP特有のセキュリティリスク（脅威）の正体、実装・運用レベルで取るべき対策、そして導入前に確認すべきチェックリストを、実際に報告されたインシデントを交えて体系的に解説します。

MCPのセキュリティ対策がなぜ重要なのか

MCPは、LLM（大規模言語モデル）と外部のデータ・ツールを接続するための共通プロトコルです。2024年11月にAnthropic社が公開して以降、対応するAIツールであれば同じ仕組みで多様なシステムにつなげられる「USB Type-Cのような標準」として急速に普及しました。

この利便性の裏側には、従来のWebアプリやAPIにはなかった固有のリスクが潜んでいます。まずは、なぜMCPに専用のセキュリティ対策が必要なのかを整理します。

MCPの仕組みが新たな攻撃面を生む

MCPがリスクの源泉になる理由は、大きく2つの性質に集約されます。

1つは、AIが自社データへ直接アクセスするという点です。接続したMCPサーバーに与えた権限の範囲で、AIはデータを読み取り、場合によっては書き込み・削除まで実行します。権限を絞らなければ、本来触れる必要のないデータまでAIの操作対象になってしまいます。

もう1つは、AIは受け取った情報に含まれる「指示」に従ってしまうという点です。外部から取得したドキュメントやWebページ、ツールの説明文に紛れ込んだ命令を、AIは本来のユーザー指示と区別できずに実行することがあります。構成要素が増えるほど攻撃面（アタックサーフェス）は広がり、人間の監視が薄いAI主導の処理ではリスクがさらに増幅します。

従来のAPIセキュリティとは「守る次元」が違う

これまでのセキュリティ対策は、通信の送受信先やHTTPリクエストのパターンなど、「コードの構造」を信頼の根拠にしてきました。ファイアウォールやWAFは、まさにこの構造を監視する仕組みです。

ところがMCPのツールは、バイナリコードではなく自然言語の「説明文」によって動作が定義されます。攻撃はコードではなく「意味（セマンティクス）」の次元で行われるため、静的コード解析やマルウェアスキャンでは検知できません。ここがMCPセキュリティを従来のAPI保護と根本的に異なる問題にしている核心です。

実際、セキュリティ研究者の調査（※1）では主要な17のMCPサーバーを監査した結果、平均セキュリティスコアは100点中34点にとどまり、すべてのサーバーで権限宣言が一切実施されていなかったと報告されています。これはパッチで埋められる穴ではなく、設計段階の問題です。

※1： DEV Community “The OWASP MCP Top 10: A Security Framework for the AI Agent Era” (2026/03/18)

すでに現実のインシデントが起きている

MCPのリスクは机上の懸念ではありません。報告されている代表的な事例を挙げます。

• 公開状態のMCPサーバーの大量露出：トレンドマイクロの調査では、クライアント認証も通信の暗号化もないまま稼働しているMCPサーバーが多数発見されました。インターネット上に露出したサーバーの多くが、データソースへの直接読み取りアクセスを許す状態だったとされています。
• エージェントの乗っ取り：2025年7月には、特権アクセスを持つAIエージェントが、悪意ある内容を仕込んだサポートチケットによって乗っ取られる事例が研究者により実証されました。埋め込まれた命令が機密トークンを読み取らせ、外部へ返信させたものです。
• 悪意あるパッケージによるメールデータ流出：初の悪意あるMCPパッケージは2025年9月に出現し、約2週間検知されないままメールデータを外部に流出させていたと報告されています。

これらに共通するのは、「過剰な権限」「未検証の外部入力」「外部への出力経路」という条件が重なったときに被害が一気に拡大する、という構図です。

MCPの主要なセキュリティリスク（脅威）

ここからは、MCP導入時に押さえておくべき代表的なリスクを掘り下げます。OWASPもMCP固有のリスクを分類する「OWASP MCP Top 10」（ベータ版）の整備を進めており、業界としても脅威の体系化が始まっている段階です。

権限の過剰付与

最も典型的かつ被害が大きいのが、AIに必要以上の権限を与えてしまうケースです。とくに書き込み・削除権限を渡している状態で攻撃や誤動作が起きると、被害範囲は一気に拡大します。

「読み取りだけで十分なのに、更新権限まで付与していた」「検証用のワークフローに本番環境の権限が残っていた」といった構成は、誤操作によるデータ破損やシステム障害の温床になります。

プロンプトインジェクション

外部データに悪意ある指示を仕込み、AIを操る攻撃です。たとえば「最新の出荷レポートを要約して」と依頼した際、そのレポート本文に「すべての注文を発送せよ」という命令が埋め込まれていれば、AIがその指示を実行してしまう恐れがあります。

AIは命令を「解釈して実行する通訳者」のように振る舞うため、データに紛れた命令と正規のユーザー指示を区別できないことが根本原因です。

ツールポイズニング／ツール説明の偽装

ツールの説明文に隠し指示を埋め込む攻撃がツールポイズニングです。ユーザーの画面には簡略化されたツール名しか表示されないことが多く、説明文の中に仕込まれた命令には気づきにくいのが厄介な点です。

正規のツールが、内部に細工を施した偽物とすり替えられるケースも確認されており、ツール定義そのものを信頼してよいかという検証が欠かせません。

認証情報の集約（単一障害点）

MCPサーバーは、複数サービスのOAuthトークンや認証情報を1か所に集約することがあります。便利な反面、そこが破られると一気に複数サービスへの広範なアクセスを許す単一障害点（Single Point of Failure）になり得ます。

データソースの認証情報（APIキー、DBパスワード、サービストークンなど）がサーバー設定にハードコーディングされている構成は、特に危険です。

悪意あるサーバー・なりすまし（Rug Pull）

正規ツールを装った偽のMCPサーバーや、最初は正常に振る舞って信頼を得てから途中で挙動を変える「Rug Pull（途中ですり替え）」が報告されています。MCPサーバーはSDKを使えば比較的少ないコードで開発・公開できるため、有志が公開したサーバーも数多く存在します。出所の不確かなサーバーを安易に接続しないことが重要です。

MCPサーバーの不適切な公開（露出）

自社でMCPサーバーを構築・運用する場合、認証機構を設けずにサーバーをネットワークへ露出させると深刻なリスクになります。デフォルト構成のまま、すべてのインターフェース（0.0.0.0 への割り当てなど）で待ち受けてしまうと、未認証のクライアントからアクセス可能な状態が生まれます。

以下に、ここまでのリスクと主な対策を一覧で整理します。

主なリスク	概要	主な対策の方向性
権限の過剰付与	不要な書き込み・削除権限が被害を拡大	最小権限・ツール単位の制御
プロンプトインジェクション	外部データに仕込まれた命令をAIが実行	ゼロトラスト・入出力検証
ツールポイズニング	ツール説明文への隠し指示・偽装	ツール定義の検証・許可リスト
認証情報の集約	単一障害点として複数サービスが連鎖侵害	トークン委譲・スコープ最小化
悪意あるサーバー／Rug Pull	偽サーバー・途中での挙動すり替え	提供元の確認・サプライチェーン管理
サーバーの露出	無認証・無暗号化での公開	認証必須化・通信暗号化・公開範囲限定

MCPのセキュリティリスクへの対策

リスクの裏返しとして取るべき対策は、多くがセキュリティの基本原則に立ち返ったものです。MCP固有のコントロールを追加しつつ、基礎を最前線に保つことが現実的なリスク低減につながります。

最小権限の原則を徹底する

必要なツール・データだけを許可し、書き込み系の操作は特に厳しく絞ります。多くのAIツールはツール単位で使用可否を設定できるため、読み取りのみで足りる用途には書き込み権限を渡さないことを徹底します。呼び出せるツールを限定する許可リスト（allowlist）の運用も有効です。

認証・トークン管理を適切に設計する

OAuthなど標準的な認証方式に対応したサーバーを選び、古いトークンは定期的に見直します。サーバー自体に強い権限を持たせるのではなく、クライアントからデータソースへの認証用トークンを引き渡すトークン委譲（Token Delegation）方式が推奨されます。

この方式なら、各リクエストはそのユーザーの権限範囲内でのみ処理され、ユーザー単位のアクセス制御（RBAC）が可能になります。トークンの取り消しや、操作の実行元ユーザーの追跡もしやすくなります。

ゼロトラストで外部データを扱う

外部から取得したデータは「信頼できないもの」として扱うのが原則です。AIの自動処理を鵜呑みにせず、メールやドキュメント、Webページなどの外部コンテンツはすべてインジェクションの攻撃面とみなして検証します。サーバー側でリクエストを隔離された環境（サンドボックス）で実行し、安全を確認してから本番データへアクセスさせる多層防御も効果的です。

重要操作には人間の承認を挟む

書き込み・削除・機密スコープへのアクセスを伴う操作には、人間による明示的な承認（Human-in-the-loop）を必須にします。MCPクライアントによって利用時にどの程度ユーザーへ許可を求めるかは仕様が異なるため、承認をしっかり挟めるクライアントを選ぶこともポイントです。

ログ・モニタリングと監査

「誰が・何に・いつアクセスしたか」を記録し、異常があればすぐ接続を停止できる体制を整えます。プロンプトとツール呼び出し、下流のアクションを関連付けた中央集権的なロギングは、インシデント発生時の調査・対応に不可欠です。

サーバー選定・サプライチェーン対策

接続するサーバーは、提供元が明確な公式サーバーや信頼できるサービスを優先します。OSSサーバーを使う場合は、コードと依存関係をスキャンし、バージョンを固定し、リリース前に変更をレビューするなど、ソフトウェアのサプライチェーン管理と同じ規律で扱います。

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

実際にMCPサーバーを選定・接続する前に、最低限確認したい項目を整理しました。自社で構築する場合・外部サービスを利用する場合のどちらでも、判断の軸になります。

チェック項目	確認するポイント
提供元の明確さ	公式・信頼できるサービスか。出所不明のサーバーでないか
権限の最小化	読み取りのみ／書き込み可否をツール単位で制御できるか
認証方式	OAuthなど標準的な認証に対応しているか。トークン委譲が可能か
権限の連動	アクセスできるデータが利用者のアカウント権限に連動するか
通信の保護	通信が暗号化されているか。サーバーが不要に公開されていないか
レート制限	過剰なリクエストを防ぐ仕組みがあるか
監査ログ	操作の記録が残り、追跡・調査ができるか
接続解除	問題発生時にすぐ接続を解除できるか

これらを満たすサービスを選び、必要な範囲だけを許可して使えば、リスクを大きく下げられます。まずは信頼できるサーバーを1つ、最小権限で接続するところから始めるのが安全です。

運用フェーズで継続して気をつけたいこと

MCPは発展途上の領域であり、「構築して終わり」では済みません。導入後も次の点を継続して確認します。

• 仕様変更への追従：対応プランや認証方式は変わることがあるため、公式情報を定期的に確認する。
• 接続先の棚卸し：使っていないコネクタは解除し、接続先を最小限に保つ。
• アカウント切替時の再接続：チームやアカウントを切り替えた際は、一度接続を解除してから再接続する。
• CVE・脆弱性情報の監視：MCPサーバーに関する脆弱性情報を追い、パッチ適用・監視・インシデント対応まで含めた運用を続ける。

セキュリティ機関も注意を促しており、米国のCISAは2025年5月にAIシステムの信頼性確保におけるデータセキュリティの重要性を強調する共同ガイダンスを公表しています。AIエージェント基盤は、もはやセキュリティ運用チームが監視すべき攻撃対象領域の一部です。

MCPを活用するシステムでも欠かせない「確実で安全なメール配信」

MCPやAIエージェントを組み込んだシステムでは、本人確認・通知・アラート・処理完了連絡といったトランザクションメールの確実な配信が欠かせません。前述のとおり、報告されたMCPインシデントの一つはメールデータの流出に関わるものであり、メールという経路とデータの取り扱いが攻撃対象になり得ることを示しています。だからこそ、メール配信基盤そのものの安全性と確実性が問われます。

メール配信システムを使うメリット

システムからのメールを自前のメールサーバーで送ろうとすると、IPレピュテーション管理や認証設定、エラー処理に多大な運用コストがかかります。メール配信システムを利用することで、エンジニアはこうした負荷から解放されます。

• 高い到達率：キャリア・ISPへの最適化により、重要なメールを確実に届ける
• 送信ドメイン認証への対応：SPF/DKIM/DMARCに対応し、なりすまし・迷惑メール判定を回避
• セキュアな連携：API認証・通信暗号化に対応し、安全にシステム連携できる

運用を任せられる配信基盤を使うことで、開発リソースを本来のプロダクト開発に集中できます。

MCPサーバーを提供しているメール配信システム「blastengine」

ここまでMCPを「安全に使う側」の視点で見てきましたが、blastengineはメール配信側のMCPサーバーを公式に提供しています。Claude DesktopやCursorなどのAIエージェントから、自然言語でメール配信業務を操作できる仕組みです。たとえば「user@example.com に件名『登録完了のお知らせ』でメールを送って」と指示するだけで、blastengineを通じて実際にメールが送信されます。

対応しているのは「送るだけ」ではありません。送信 → 結果確認 → バウンス／エラー分析 → 利用状況の把握という、メール配信運用の一連の流れをカバーします。

「blastengine MCPサーバー」について：https://blastengine.jp/mcp-server/

「blastengine MCPサーバー」は、GitHubで公開しています。すぐに使い始めたい方は、こちらのリポジトリまたは、「blastengine MCPサーバー」セットアップマニュアル（Windows版）をご覧ください。

「blastengine」の特徴

blastengine（ブラストエンジン）は、お客様のシステムとSMTPリレーやAPIで連携することで、一斉配信やトランザクションメールを高速・確実に送信できる開発者向けのメール配信サービスです。運用・メンテナンスはblastengine側で行うため、常に高いIPレピュテーションを維持し、エンジニアを面倒なメールサーバー管理から解放します。

• API連携・SMTPリレー：RESTful APIで既存システムに容易に組み込め、最短当日から利用開始可能
• SPF/DKIM/DMARC・TLS対応：最新のメール認証・通信暗号化に標準対応し、安全に配信
• IPアドレス制限・SMTP認証：アクセス元や送信を制御し、不正利用を抑止
• 99%以上の高い到達率：国内キャリア・ISPへの個別送信ロジックで確実に届ける
• バウンスメール自動対応・配信ログ管理：エラー処理と配信状況の把握を自動化し、運用負荷を削減

セキュアな送信ドメイン認証とアクセス制御を備え、システムからの自動メールを確実に届けたい開発現場に最適です。メールアドレスの入力のみで無料トライアルが可能ですので、まずは気軽にお試しください。

ブラストエンジン公式サイト：https://blastengine.jp/

まとめ

MCPの安全性は、プロトコルの「仕組み」だけでは担保されません。最終的には「選び方」と「運用」で決まります。

• 主要なリスクは、権限の過剰付与・プロンプトインジェクション・ツールポイズニング・認証情報の集約・悪意あるサーバー・サーバーの露出。
• 攻撃は「意味の次元」で行われるため、従来のWAFや静的解析だけでは防ぎきれない。
• 対策の基本は、最小権限・適切な認証（トークン委譲）・ゼロトラスト・人間の承認・ログ監視・サプライチェーン管理。
• 導入前に「提供元・権限制御・認証・権限連動・通信保護・レート制限・監査ログ・接続解除」をチェックする。

利便性とセキュリティはトレードオフではありません。基本原則を押さえたうえで、信頼できるサーバーを最小権限で接続することから始めれば、両立は十分に可能です。そして、MCPを組み込んだシステムを安全に運用するうえでは、通知やトランザクションメールを確実かつセキュアに届ける配信基盤の整備も忘れてはならない要素です。