AIと業務システムをつなぐ標準プロトコルとしてMCPの採用が広がる一方、プロンプトインジェクションや権限過多、サプライチェーン改ざんなど新しい攻撃手法も確認されています。2025年にはMCP関連ツールにリモートコード実行（RCE）の脆弱性が報告されるなど、導入や運用の段階で警戒が欠かせません。
本記事では、最新の仕様と実際に起こりうる攻撃シナリオを踏まえ、導入判断と安全運用に必要なポイントを整理します。
あわせてご覧ください
目次
MCP導入とセキュリティの基本認識
MCPはAIと外部サービスを標準化された方法で接続できる仕組みですが、AIに操作権限を与えることで利便性と同時にリスクも高まります。 仕様ではOAuth 2.1やResource Indicators（RFC 8707）を前提に設計 され、 最小権限・監査ログ・レート制限などの運用ルールが必須 とされています。
現実に起こりうるセキュリティシナリオ
MCPサーバーや関連ツールでは、次のようなリスクが想定されます。日常の利用シーンに直結する事例として理解しておくことが重要です。
- 会話履歴の外部送信
MCPサーバーのツール説明に隠された指示をLLMが読み取り、ユーザーの会話履歴を攻撃者に送信してしまう。
対策：信頼サーバーの利用、説明文の検証、重要操作は必ず確認UIを挟む。
- サーバー更新でのすり替え
最初は無害なMCPサーバーが、更新で削除命令や外部送信を仕込まれる。
対策：バージョン固定、変更検知、更新時の再同意を徹底。
- OAuth設計不備によるなりすまし
audience未指定のままOAuthトークンを発行し、攻撃者が他サービスで利用。
対策：RFC 8707でリソース指定を必須化、短命トークンを導入。
- コマンドインジェクション
ローカルMCPサーバーが入力をそのままOSコマンドに渡し、任意コードを実行される。
対策：入力のサニタイズ、安全API利用、サンドボックス実行。
- RCE（リモートコード実行）の悪用
旧版MCP Inspectorに脆弱性があり、悪性サイトを開くだけでコマンド実行される。
対策：最新バージョンへの更新、ローカルツールを外部に公開しない。
これらのリスクを認識し、日常運用で適切な対策を講じることが安全性向上につながります。
認証・認可の設計における重要ポイント
MCPを導入する際、最も注意が必要なのは OAuthとトークンの扱い方 です。ここで設計を誤ると、正規のユーザーに見せかけて不正な操作が行われる可能性があります。以下に代表的なシナリオを紹介します。
- Resource Indicators（RFC 8707）でトークンの行き先を固定
トークンの”宛先”が曖昧なまま発行されると、攻撃者が別のサービスでそのトークンを使えてしまうことがあります。例えば、ファイル閲覧用に発行したはずのトークンが、誤って別のAPI（顧客管理システムなど）でも通ってしまうケースです。
対策：RFC 8707で定義された「resource」パラメータを必須にし、トークンが利用できるサービスを明示的に固定します。
- PKCE利用と再同意で権限濫用を防止
一度OAuthで同意を取ったあと、そのセッションを攻撃者が横取り（セッション固定やリプレイ攻撃）すると、本人の承認なしで追加の操作が走ってしまうことがあります。
対策：PKCE（Proof Key for Code Exchange）を利用することで、攻撃者が横取りしても正しいコードが生成できず、トークン発行が失敗します。また、機微な操作は「再同意」を求めるようにし、ユーザーが操作の意味を理解したうえで承認する仕組みにします。
- トークンパススルー禁止とaudience検証
MCPサーバーが受け取ったトークンを”そのまま下流サービスに中継”すると、本来許可していない操作まで実行できてしまいます。例えば、AIがメール閲覧のために受け取ったトークンが、そのままクラウドストレージへの削除操作に使われてしまう、といった具合です。
対策：MCPサーバーは必ず「このトークンは自分宛か？」「audience（利用対象）が一致しているか？」を検証し、他サービス用のトークンを受け入れない設計にします。
サーバー選定と導入時のチェック基準
MCPサーバーを導入する際は「便利だからつなぐ」のではなく、 接続先を選ぶ段階での評価基準 を設けておくことが重要です。
| 項目 | 確認内容 |
|---|---|
| 提供元 | 公式または実績ある開発元か、署名・配布チャネルは正当か |
| 更新管理 | バージョン固定と差分レビュー、改ざん検知の仕組み |
| 通信 | TLS必須、証明書検証 |
| 権限 | 必要最小限スコープ、読み取り専用優先 |
| 実行 | ローカルはサンドボックス、egress制御 |
| ログ | 誰が・何を・いつ・どこへ、を詳細に記録 |
これらの基準を運用ルールとして明文化し、 導入後も定期的に棚卸しと見直しを行うこと で、攻撃や事故の芽を早期に摘むことができます。
運用管理で求められる取り組みと誤解の回避
MCPを安全に活用するには、日常運用での制御と、ありがちな誤解を避けることが欠かせません。
まずは、運用設計で取り入れるべき基本的な仕組みです。
-
実行前確認UIで危険操作を人間が承認する
-
入出力をサニタイズし、不審な引数や出力を遮断する
-
レート制限・タイムアウトで暴走やコスト増を防ぐ
-
ログを監査可能にし、異常検知のアラートを設定する
-
定期的なアップデートと依存ライブラリの脆弱性監視を続ける
一方で、導入現場では誤解から生じるリスクも少なくありません。
「OAuthを使っているから安全だ」と思い込むと、audienceが未指定のままトークンが発行されてしまい、不正利用の余地が残ります。また「公式ツールだから安心」と過信すると、実際に報告されているリモートコード実行（RCE）の脆弱性を見落とし、更新を怠った環境が攻撃対象になることがあります。さらに「プロンプトインジェクション対策はすでに済んでいる」と考えてしまうと、説明文やユーザーインターフェース経由で攻撃が成立するケースを軽視し、人による最終確認を省略してしまいかねません。
こうした技術的対策と誤解の回避をセットで意識することで、MCPを安心して業務に組み込むための基盤が整います。
まとめ
MCPは業務の効率化を大きく前進させますが、同時に攻撃対象面を広げるため、セキュリティ設計と運用が欠かせません。認証・認可の仕様準拠、最小権限、ログと人の確認、定期的な更新という基本を徹底することで、安全に導入できます。
次のステップとして、いま接続しているサーバーを棚卸しし、ここで示したチェックリストを基に再評価することをおすすめします。