MCP導入のセキュリティリスクと対策｜公式が挙げる攻撃パターンとチェックリスト

「MCPを社内で使いたいが、セキュリティ面で何を確認すればいいかわからない」とお困りではないでしょうか。

MCPには、規格として想定される攻撃と対策が公式に文書化されています。 つまり「まだ誰も検証していない未知の領域」ではなく、何に注意すべきかは明文化されています。

本記事では、MCP公式のセキュリティベストプラクティスに沿って、攻撃パターンと導入側が取るべき対策を整理します。

記事のポイント

• MCPには公式のセキュリティベストプラクティス文書がある
• 導入側にとって最大のリスクはローカルMCPサーバー（クライアントと同じ権限で任意コードを実行できる）
• confused deputy 問題・トークンパススルー・SSRF は主にサーバー実装側の論点
• 権限は「認可したアカウントの閲覧範囲がすべてAIに渡る」前提で設計する
• 導入前チェックリスト10項目

目次

• MCPのセキュリティは公式に文書化されている
• 導入側が最も注意すべきリスク: ローカルMCPサーバーの侵害
• 権限設計の原則
• サーバー実装側の論点（発注・選定時の確認事項）
• スコープは最小から始める
• 導入前チェックリスト
• 社内展開の進め方
• よくある質問
• まとめ

MCPのセキュリティは公式に文書化されている

MCP公式は、認可仕様（MCP Authorization）を補完する形で Security Best Practices の文書を公開しています。想定読者は「MCP認可フローを実装する開発者、MCPサーバーの運用者、MCPベースのシステムを評価するセキュリティ専門家」とされています（出典: MCP 公式仕様（Security Best Practices））。

文書内では規範表現（MUST / MUST NOT / SHOULD）が使われており、何が必須で何が推奨かが区別されています。

利用側（導入する企業）の立場で読むと、論点は大きく2つに分かれます。

論点	誰の責任か	導入側がやること
ローカルMCPサーバーの実行	利用側	出所の確認・権限の最小化
認可フローの実装（OAuth周り）	サーバー / クライアント実装側	選定時に対応状況を確認

まず前者から見ます。

導入側が最も注意すべきリスク: ローカルMCPサーバーの侵害

なぜ最も危険か

ローカルMCPサーバーは、利用者のマシン上でダウンロードされ実行されるバイナリです。公式文書は、適切なサンドボックスと同意の仕組みが無い場合に次の攻撃が成立すると述べています。

1. 攻撃者がクライアント設定に悪意ある起動コマンドを混ぜる
2. 攻撃者がサーバー自体に悪意あるペイロードを仕込んで配布する
3. localhost で動かしっぱなしの安全でないサーバーに、DNSリバインディングでアクセスする

公式文書は、設定に埋め込まれうる悪意あるコマンドの例まで挙げています。データの外部送信や権限昇格を狙うものです。

リスクの中身

• 任意コード実行 — MCPクライアントの権限で任意のコマンドが実行できる
• 可視性の欠如 — 何のコマンドが実行されているかユーザーには見えない
• コマンドの難読化 — 複雑なコマンドで正当なものに見せられる
• データの外部送信 — 侵害されたJavaScript経由で正当なローカルサーバーにアクセスされる
• データ消失 — 攻撃やバグで復旧不能なデータ損失が起きうる

対策

利用側でできる最も効果的な対策は次の3つです。

1. 出所の分からないMCPサーバーを設定ファイルに書かない

設定ファイルの command に書かれた内容は、そのまま実行されます。GitHubのスター数やブログの紹介だけを根拠に設定に貼り付けないでください。

2. アクセスを許可する範囲を最小限にする

ファイルシステムサーバーであれば、args に書いたディレクトリがそのまま許可範囲になります。公式も「自分が手作業でできるファイル操作はすべて実行できる」と警告しています。ホームディレクトリ全体を渡さないでください。

3. 実行前の同意画面を必ず読む

公式は、ワンクリックでローカルMCPサーバーを設定できるクライアントに対して、実行前の同意機構の実装を MUST としています。要件は次のとおりです。

• 実行されるコマンドを省略せずに表示する（引数・パラメータを含む）
• ユーザーのシステム上でコードを実行する危険な操作であることを明示する
• 明示的な承認を必須とする
• キャンセルできるようにする

この画面を流れ作業で押していると、保護が実質的に無効になります。

Claude Desktop での具体的な設定手順と承認の仕組みは「ClaudeでMCPを接続する方法」で解説しています。

権限設計の原則

MCP経由で取得できるデータは、通常そのサービス上のアカウント権限に紐づきます。したがって原則は1つです。

認可したアカウントが閲覧できるデータは、すべてAIに渡る前提で設計する。

具体的に実施すべきことは次の3点です。

1. AI連携専用の閲覧アカウントを用意する

個人の業務アカウントで認可すると、その人の閲覧範囲全体（人事情報や未公開の計画を含む）が対象になります。必要なデータだけが見えるアカウントを別に作ってください。

2. 組織として接続を管理する

サービス側に管理機能がある場合は必ず使います。例えば Notion はワークスペースオーナーが Settings → Connections でアクセスを管理できます。

個々のメンバーが自由に接続できる状態は、誰がどの範囲をAIに渡しているか把握できません。

3. 読み書き可のサーバーは承認運用を決める

Notion MCP のように作成・更新ができるサーバーでは、AIが既存データを書き換えるリスクがあります。承認をどう扱うかを運用として決めてから展開してください。

サーバー実装側の論点（発注・選定時の確認事項）

以下は主にMCPサーバーを実装する側の責任範囲ですが、MCPサーバーを外部に発注する場合や、自社でSaaSにMCPを実装する場合の確認事項になります。

confused deputy 問題

サードパーティAPIに繋ぐMCPプロキシサーバーで発生する脆弱性です。静的なクライアントID・動的クライアント登録・同意クッキーの組み合わせを悪用され、ユーザーの同意なしに認可コードが攻撃者に渡ります。

公式は、MCPプロキシサーバーに対して**クライアントごとの同意（per-client consent）**の実装を MUST としています。要件は次のとおりです。

• ユーザーごとに承認済み client_id のレジストリを保持する
• サードパーティ認可フローを開始する前にレジストリを確認する
• 同意ページで要求元クライアント名・スコープ・リダイレクトURIを明示し、CSRF対策とiframe禁止を行う
• redirect_uri は完全一致で検証する（ワイルドカード不可）
• OAuth の state は同意承認後に保存し、コールバックで完全一致を検証、単回利用・短期失効とする

同意クッキーを同意承認の前に設定してしまうと、同意画面が無意味になる点が明確に MUST NOT とされています。

トークンパススルー

MCPサーバーが、自分宛てに発行されたものでないトークンを受け入れて下流APIに転送してしまうアンチパターンです。監査ログの追跡不能、レート制限などのセキュリティ制御の回避、信頼境界の破壊につながります。

公式は明確に述べています。

MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server.

audience クレームの検証をしているかは、実装の確認事項として押さえてください。

SSRF（サーバーサイドリクエストフォージェリ）

MCPクライアントが、悪意あるMCPサーバーに指示されて内部ネットワークやクラウドのメタデータエンドポイントへリクエストしてしまう攻撃です。http://169.254.169.254/ のようなクラウドメタデータへのアクセスでIAM認証情報が流出しえます。

推奨対策は、OAuth関連URLでのHTTPS必須化、プライベートIP帯（10.0.0.0/8・172.16.0.0/12・192.168.0.0/16・169.254.0.0/16 など）のブロック、リダイレクト先の同様の検証、エグレスプロキシの利用です。

公式は「IP検証を自前で実装することは避けよ」とも注記しています。8進数・16進数・IPv4射影IPv6などのエンコーディング技法を自作パーサーは見落としがちだからです。

OAuth認可URLの検証

悪意あるMCPサーバーが javascript: スキームの認可URLを返し、クライアントがそれをそのまま window.open() に渡すとXSSが成立します。プロキシ構成と組み合わさるとリモートコード実行まで到達します。

公式は、クライアントに対して次を MUST としています。

• 認可URLは http://（ループバックのみ）と https:// だけを許可する
• javascript: data: file: vbscript: などのスキームを拒否する
• URLを開くのにシェルコマンドを使わない（cmd.exe / sh / PowerShell）

state handle hijacking

MCPは 2026-07-28 版でステートレスなプロトコルとして整理され、プロトコルレベルのセッションを持ちません。複数リクエストにまたがる状態は、サーバーが明示的なハンドル（カートIDなど）を発行し、ツール引数として受け取ります。

このハンドルを推測・入手した第三者が他人の状態を操作できてしまうのが state handle hijacking です。公式は次を MUST としています。

MCP servers MUST NOT treat possession of a state handle as authentication.

推奨は、安全な乱数生成による非決定的なハンドル、<user_id>:<handle> のようにサーバー側で認証済みユーザーに紐づける設計です。

注意: 以前の版（2025-11-25 以前）では「session hijacking」として整理されていました。古い解説記事はセッションIDの話をしています。 現行仕様とは前提が違います。

スコープは最小から始める

公式は、過大なスコープを最初から要求する設計の問題を挙げています。

• 盗まれたトークン1つで無関係なツール・リソースにアクセスできる（blast radius の拡大）
• 最大権限のトークンを失効させると全ワークフローが止まる
• 単一の包括スコープでユーザーの意図が監査ログから読めなくなる
• 過大なスコープ一覧を見てユーザーが同意を諦める

避けるべき実装として、* / all / full-access のようなワイルドカード・包括スコープが明示されています。

推奨は、最小の初期スコープ（低リスクな読み取り・探索のみ）から始め、特権操作が必要になった時点で段階的に昇格させる設計です。

利用側としては、「接続時に要求されるスコープが妥当か」を同意画面で確認するのが実務上の対応になります。

導入前チェックリスト

社内展開の前に、次の10項目を確認してください。

#	確認項目
1	そのMCPサーバーの提供元は公式か。第三者実装ならコードの出所を確認したか
2	ホスト済み（リモート）か自前運用（ローカル）か。ローカルなら実行コマンドの中身を読んだか
3	ローカルサーバーの場合、アクセス許可の範囲は最小限か（ホームディレクトリ全体を渡していないか）
4	接続に使うアカウントはAI連携専用の閲覧アカウントか
5	そのアカウントの閲覧範囲に機密データが含まれていないか
6	サーバーは読み取り専用か、書き込みもできるか。書き込み可なら承認運用を決めたか
7	同意画面で要求されるスコープが用途に対して妥当か
8	サービス側に組織単位の接続管理機能があるか。あれば有効にしたか
9	接続先AIツールのデータ利用ポリシー・保持期間を確認したか
10	レート制限を把握し、想定する使い方が上限に収まるか

MCPは経路の規格であり、渡した先のAIツールがそのデータをどう扱うかは規定していません。 9番は特に見落とされやすい項目です。

社内展開の進め方

1. 読み取り専用・ホスト済みから始める

導入工数が軽く、誤操作のリスクも無い組み合わせです。まずここで運用の型を作ります。

2. 接続アカウントと承認の方針を先に決める

技術的な設定より、誰のアカウントで繋ぐかの方が事故につながります。ここを決めずに各自に任せると、後から範囲を把握できなくなります。

3. 数字の検証手順を決める

セキュリティとは別ですが、実害が出やすい論点です。AIに集計クエリや取得条件を出力させ、元データと突き合わせる手順を決めてください。MCPは取得を速くしますが、正しさは保証しません。

4. ローカルサーバーは最後に、限定的に

任意コード実行のリスクがあるため、必要性が明確な用途に絞り、許可範囲を最小化したうえで導入してください。

よくある質問

Q. MCPは安全ですか？

A. 「安全かどうか」ではなく「どう使うか」で決まります。MCPには公式のセキュリティベストプラクティス文書があり、想定される攻撃と対策が明文化されています。特にローカルMCPサーバーはクライアントと同じ権限で任意コードを実行できるため、出所の確認と権限の最小化が必須です。

Q. リモートMCPサーバーとローカルMCPサーバーはどちらが安全ですか？

A. 利用側の観点では、提供元がホストするリモートサーバーのほうがリスクは限定的です。ローカルサーバーは自分のマシン上で任意のコードを実行するため、侵害された場合の影響が大きくなります。

Q. MCPで渡したデータはAIの学習に使われますか？

A. MCPはデータを渡す経路を定めた規格であり、渡した先の扱いは規定していません。接続先AIツールのデータ利用設定と保持ポリシーを個別に確認する必要があります。

Q. セキュリティチェックシートにMCPの項目を入れるべきですか？

A. AIツールと外部データを接続する運用があるなら入れるべきです。確認軸は本記事のチェックリストが目安になります。特に「接続に使うアカウントの権限範囲」「読み書きの範囲」「AIツール側のデータ利用ポリシー」の3点は必須です。

Q. 古いMCPの解説記事は参考になりますか？

A. 前提が変わっている箇所があります。仕様は 2026-07-28 版で sampling と logging が非推奨になり、セッション管理は「state handle」の考え方に整理され直しました。セッションIDの話をしている解説は以前の版が前提です。

まとめ

MCP導入のセキュリティで押さえるべき要点は次の3つです。

• 利用側にとって最大のリスクはローカルMCPサーバー。クライアントと同じ権限で任意コードを実行できるため、出所の確認と許可範囲の最小化が必須
• 権限は「認可したアカウントの閲覧範囲がすべてAIに渡る」前提で設計する。AI連携専用の閲覧アカウントを用意する
• confused deputy・トークンパススルー・SSRF は主に実装側の論点。発注・選定時の確認事項として使う

そして、MCPは経路の規格であり、渡した先の扱いは規定していません。 接続先AIツールのデータ利用ポリシーの確認が、技術的な対策と同じくらい重要です。

MCPの基礎は「MCPとは？マーケティング業務での活用方法と2026年最新仕様」で解説しています。

CVR改善ならDejam！セキュリティ要件が厳しい商談でも使える体制

Dejamは、LP制作・ヒートマップ分析・ABテスト・AI自動解析をオールインワンで提供するCVR改善特化ツールです。

Dejamが選ばれる理由

• ISMS認証取得: ISO/IEC 27001:2022 認証取得済み。セキュリティチェックシートへの回答が必要な商談にも対応
• 2段階認証に対応: ユーザー単位で必須/非必須を選択でき、メール・SMSによる認証に対応
• 分析から実行までワンプロダクト: LP制作・ヒートマップ分析・ABテストを単一ツールで完結
• 月額3万円〜利用可能: PV数に応じた従量課金
• ユーザー課金なし: 何名で使っても追加費用は発生しない

Dejam は2026年9月時点でMCPサーバー・公開APIを提供していません。 外部のAIツールにデータを渡す経路を持たない構成のため、AIによる改善案の提示はツール内のCROサジェスト・LPOチェッカーで提供しています。

Dejamの詳しい機能を見る →　無料トライアルを申し込む →