MCPのセキュリティリスクとは？主な脅威と企業が導入前に確認すべき対策

DXコラム

2026.11.02

AIと社内システムを連携させる際、機密情報へのアクセスや操作をどこまで許可してよいか、迷う担当者もいるのではないでしょうか。こうした連携に使われるオープンな標準プロトコルが、MCP（Model Context Protocol）です。AIアプリケーションと外部のツールやデータをつなぎ、情報の取得や業務の自動化を支えます。

一方で、接続先や権限の設定によっては、悪意ある指示をきっかけに、情報漏えいや意図しない操作が起こるおそれがあります。認証に加え、扱うデータと操作の範囲を確認することが重要です。

本記事では、MCPの主なセキュリティリスクと対策、導入・運用時の確認事項を整理します。自社で必要な対策を検討する際の参考にしてください。

※本記事は2026年10月時点の情報です。MCPの仕様やセキュリティ上の推奨事項は、今後変更される可能性があります。導入・運用にあたっては、MCPの公式ドキュメントと、利用するAIアプリケーション・MCPサーバーの提供元が公開する情報を参照し、最新の仕様や脆弱性への対応状況をご確認ください。

MCPの仕組みと安全性を左右する要素

MCPのセキュリティを考えるには、AIと外部システムがどのようにつながるかを把握することが出発点です。まずはMCPの構成要素とその役割、安全性を左右するデータや権限の関係を整理しましょう。

MCPの構成要素と役割

MCPとは、AIアプリケーションと外部のツール・データをつなぐための標準プロトコル（*1）です。接続には、主に次の3つの構成要素が関わります。

*1 プロトコル：コンピューターやシステム同士がデータをやり取りする際の共通ルール

構成要素	役割
ホスト	利用者が操作するAIアプリケーション。クライアントを管理するとともに、接続やツール実行の承認など、利用者の同意とセキュリティ上のルールを管理する
クライアント	ホスト内で動作し、MCPサーバーとの通信を担う。サーバー1つにつき1つ作られる
サーバー	データの取得や業務上の操作などの機能を提供する。利用者の端末で動くものと、ネットワーク越しに接続するものがある

たとえば、社内の売上を集計する場合、AIアプリケーションはクライアントを通じてサーバーへデータの取得を依頼します。サーバーが業務システムから取得した結果を返し、AIが回答に利用する流れです。

MCPの安全性を左右するポイント

MCPでは、AIが外部システムに接続できるからといって、すべてのデータや操作が安全に扱えるとは限りません。

これは、オフィスの入館証と似ています。建物に入る許可があっても、すべての部屋に自由に入れるわけではありません。同じように、MCPでもシステムへの接続と、その先で何ができるかは分けて考える必要があります。

MCPには、ネットワーク越しの接続でアクセス権限を確認する仕組みが定められていますが、実装によって利用状況は異なります。また、接続が認められても、AIが選んだ操作の適切さまで保証されるわけではありません。そのため、利用者ごとにアクセスできるデータや実行できる操作を適切に設定することが重要です。

たとえば、売上データを「閲覧するだけ」の場合と、「更新・削除までできる」場合では、誤操作による影響が大きく異なります。また、閲覧だけでも機密情報が漏れる可能性があるため、データの内容と操作権限の両方に注意が必要です。

△利用時に注意したいセキュリティリスク

MCPを利用する際のリスクを、原因と影響に着目して4つに整理します。これらには、AIを使った外部連携や一般的なシステムにも共通する問題が含まれます。

悪意ある指示による意図しないツール実行

外部から取得した情報に悪意ある指示を混ぜ、AIを本来の目的から逸脱させる攻撃を「間接プロンプトインジェクション」と呼びます。たとえば、AIに文書の要約を依頼した際、その文書に「内容を外部へ送信するように」という不正な指示が含まれていると、AIがそれを命令として受け取り、接続されたツールを使って情報を送信してしまうおそれがあります。

また、ツールの説明文などに不正な指示を仕込む攻撃は「ツールポイズニング」と呼ばれます。正規のツールやデータを利用していても、AIが読み込む内容によって意図しない動作が引き起こされる可能性がある点に、注意が必要です。

過剰な権限や認可の不備による情報漏えい・誤操作

認証が「誰からのアクセスか」を確認するのに対し、認可は「その利用者に何を許可するか」を決める仕組みです。

たとえば、営業部の社員がAIを通じて売上データを確認する際、アクセス権限が適切に設定されていないと、本来は閲覧できない人事部の情報まで取得してしまう可能性があります。また、閲覧だけで十分な業務に更新・削除の権限まで与えると、意図しないデータの変更につながるおそれもあります。

認証情報の漏えいによるなりすまし

APIキーやアクセストークンは、外部システムにアクセスする際に使われる認証情報です。これらが設定ファイルやログから漏れると、第三者が正規の利用者になりすましてシステムにアクセスするおそれがあります。なお、被害範囲を左右するのは、その権限と有効期限です。

たとえば、顧客管理システムへ接続するトークンが盗まれた場合、その権限と有効期限の範囲で、顧客情報の取得や変更を許してしまうことがあります。複数サービスの認証情報を1か所で管理する構成では、侵害の影響が複数の接続先へ及ぶ場合もあります。

悪意あるサーバーや脆弱性による実行環境の侵害

ローカルで動かすMCPサーバーは、利用者の端末上で実行されるプログラムです。不正な処理や脆弱性があると、実行権限の範囲でファイルの窃取や不正なコマンドの実行につながるおそれがあります。

導入時に問題が見つからなかったサーバーでも、更新後に同じ安全性が保たれるとは限りません。承認後にツールの説明や動作を悪意ある内容へ変える手法は、「ラグプル」と呼ばれます。導入時の安全性確認だけでは防げないため、継続的な確認が欠かせません。

セキュリティリスクを抑える基本対策

MCPの安全性を高めるには、各対策の役割と限界を踏まえ、複数の対策を組み合わせることが重要です。

接続先とソフトウェア変更の管理

利用するサーバーは、提供元や保守状況を確認し、組織が承認したものに限定します。名称だけで判断せず、配布元のURLや接続先が正しいかも確かめましょう。

導入後は、ツールの説明や要求する権限の変更も確認対象です。バージョン固定で意図しない更新を抑えつつ、脆弱性の修正は検証して適用する運用が必要です。

利用者と操作に応じたアクセス権限の制限

権限は、業務に必要な最小限の範囲に設定します。売上集計だけが目的なら、対象データの閲覧に限定し、更新・削除を許可する必要はありません。

AIへの指示だけに頼らず、サーバーや接続先のシステム側で利用者の権限を検証します。こうした制御は、アクセスの正当性を継続的に確かめるゼロトラストアーキテクチャの考え方に基づくものです。

認証情報の適切な保管・検証

APIキーやアクセストークンは、アクセスを制限した保管先で管理し、AIへの入力やログに含めないようにします。漏えい時に無効化できる手段も欠かせません。

トークンを受け取る側では、発行元や有効期限に加え、自分のサービス向けに発行されたものかを検証します。別のサービス向けのトークンをそのまま受け入れて接続先へ転送する設計は、MCPの仕様でも明確に禁止されています。

重要な操作と外部通信の制御

データの削除や外部送信など、影響の大きい操作には実行前の承認を設けます。承認画面では、対象データや送信先を明示し、実行内容を判断できることが重要です。ただし、人の確認だけでは見落としを防ぎきれません。操作や通信先をシステム側でも制限し、誤って承認した場合の被害を抑えましょう。

実行環境の隔離と操作の監視

ローカルのサーバーは、ファイルやネットワークへのアクセスを制限した環境で実行します。コンテナを使う場合（*2）でも、端末全体のファイルや強い権限を与えると、隔離の効果は弱まります。

運用中は、実行者・操作対象・結果を追えるログを残し、異常を監視することが重要です。ログには認証情報などの秘密情報を記録せず、調査に必要な情報を確保しましょう。

*2 コンテナ：アプリケーションやその実行に必要な環境をパッケージ化する仮想化技術のこと

各対策の役割と、単独では防ぎきれないことを整理すると、次のとおりです。

対策	主な役割	単独では防ぎきれないこと
権限制限	操作できる範囲を狭める	許可範囲内での不正利用
実行前の承認	意図しない操作に気づく機会を設ける	利用者の見落とし
実行環境の隔離	端末や他の処理への影響を抑える	許可された通信先への情報流出
ログ・監視	異常の発見と原因調査を支える	不正操作そのものの阻止

MCPの導入・運用を進める3ステップ

MCPの導入では、接続できることに加え、必要な制御が働くかを確かめます。利用範囲の決定、限定環境での検証、運用体制の整備という順で進めましょう。

STEP1：接続目的とデータ・操作の範囲を決める

最初に、「営業担当者が自部門の月次売上を集計する」など、対象業務を具体化します。データ管理部門と開発担当者で、閲覧範囲や更新の要否、外部送信の可否を確認しましょう。こうした役割分担をAIガバナンスの管理体制と結び付けることで、現場だけの判断に依存しない運用につながります。

STEP2：限定した環境で制御と記録を検証する

本番導入前に、テスト用データや権限を制限したアカウントを使い、動作を検証します。たとえば売上集計なら、必要なデータを取得できる一方、他部署の情報へのアクセスや許可していない更新操作が拒否されるかを確認します。

また、操作履歴が適切に記録され、問題が起きた際に原因を追えることも確認しましょう。検証結果は記録し、本番導入の判断に活用します。

STEP3：運用責任者と更新・停止の手順を決める

本番利用を始める前に、接続設定の管理者と、異常時の対応責任者を決めます。担当者の異動や退職に伴う権限の見直しも、運用に含めておきましょう。

更新やツールの追加時には、アクセス範囲や承認の動作を再確認します。異常時に接続を止め、認証情報を無効化する手順も必要です。確認事項を記録すると、担当者間で共有しやすくなります。

確認項目	確認先・残す記録	未確認時の対応例
提供元・接続先	提供元の公式情報、接続設定	確認が取れるまで接続を保留する
データ・操作の範囲	データ管理部門、権限設定と検証結果	テスト用データに限定する
承認・ログの動作	開発担当者、動作確認の記録	影響の大きい操作を許可しない
更新・変更の管理	運用担当者、変更履歴と再確認項目	本番への変更適用を保留する
停止・認証情報の無効化	対応責任者、手順と連絡先	本番利用前に手順を整備する