MCPのセキュリティリスクと対策｜安全なサーバーの選び方

｜広告運用ノウハウ公開中！

より詳しく知りたい方は資料をダウンロード！

AIに自社のデータやツールを触らせるMCPは便利な一方で、「どこまで任せて大丈夫なのか」「つないだサーバーが悪さをしたらどうなるのか」と不安になりませんか。社内で導入を判断する立場なら、なおさら根拠を持って説明したいところです。

MCP（Model Context Protocol）のセキュリティリスクは、大きく分けると「AIに渡す権限」「AIが読む外部の情報」「接続するサーバーそのもの」の3か所から生まれます。MCPの公式仕様は、こうした安全上の原則をプロトコルのレベルでは強制できないとしており、どのサーバーを、どの権限でつなぐかは使う側が決めることになります（出典：Specification｜Model Context Protocol）。

この記事では、MCP公式仕様の現行版（2026-07-28）とAnthropic・OpenAIの公式ドキュメントをもとに、MCPの主なセキュリティリスク6つ、ローカルとリモートのサーバーの違い、リスクを抑える対策、導入前のチェックリスト、安全なサーバーの選び方を解説します。

MCPそのものの基礎（定義・API連携との違い・マーケティング活用の全体像）は、MCPとは？マーケティング業務を効率化する活用方法と事例を解説で解説しています。本記事は「セキュリティと注意点」に絞って説明します。

1. なぜMCPにセキュリティ対策が必要なのか

MCPは、AIが外部のデータを参照したり、ツールを操作したりできるようにする仕組みです。便利な反面、次の2つの性質がリスクの源になります。

• AIが自社のデータに直接アクセスする：接続したサーバーに渡した権限の範囲で、AIがデータを読み書きできます。権限を絞らないと、不要なデータまで触れてしまいます
• AIは読んだ文章の中の指示に従ってしまうことがある：外部のデータやツールの説明文に紛れ込んだ「隠れた指示」を、AIが本来の指示と区別できずに実行してしまうことがあります（2章）

MCPの公式仕様は、MCPが任意のデータへのアクセスやコードの実行につながる強い機能を持つことを認めたうえで、プロトコル自体はセキュリティの原則を強制できないと明記しています。そのため、MCPを組み込むアプリやサーバーの側が、同意と認可の流れ、アクセス制御、データの保護を作り込むべきだとしています（出典：Specification｜Model Context Protocol）。

仕様が掲げる原則は次の3つです（出典：同上）。

原則	仕様に書かれていること
利用者の同意と管理	利用者は、すべてのデータへのアクセスと操作に明示的に同意し、何が共有され、何が実行されるかを自分で管理できなければならない
データの保護	AIアプリ（ホスト）は、利用者のデータをサーバーに渡す前に明示的な同意を得る。同意なくデータをほかへ送らない
ツールの安全	ツールは任意のコードの実行にあたるので慎重に扱う。ツールの説明は、信頼できるサーバーから来たものでない限り信用しない。ツールを呼び出す前に利用者の明示的な同意を得る

つまり、MCPの安全性は「仕組みがあるから安全」ではなく、「何をつなぎ、何を許可するか」という選び方と運用で決まります。

1-1. ローカルとリモートでリスクの場所が違う

MCPサーバーには、自分のPCの中で動かす「ローカル」と、インターネット上で提供される「リモート」があります。どちらを使うかで、気をつける場所が変わります。

ローカルのMCPサーバーは、インターネットから取ってきたコードを、自分のアカウントの権限で動かす普通のプログラムです。環境変数に入ったトークンやAPIキー、自分のアカウントで読めるファイル（SSHの鍵やクラウドの認証情報を含む）に触れられ、外部への通信も制限されません。MCP公式は、これらはプロトコルではなく「どう動かすか」で決まると説明しています（出典：Local Server Security｜Model Context Protocol）。

リモートのMCPサーバーは、自分のPCではコードを動かしません。設定ファイルにトークンを書く代わりにプロトコルの認可の流れ（OAuth）を使い、修正も提供元の1か所で済みます。MCP公式は、自分のPCのファイルやローカルのツールを使う必要がないサーバーなら、リモート版を使うよう勧めています（出典：同上）。

ただし、リモートなら安全というわけではありません。リモートのサーバーにも、権限の与えすぎやプロンプトインジェクションといったリスクは残ります（2章）。なお、Claudeのカスタムコネクタ（リモートMCP）は、利用者のPCからではなく、Anthropicのクラウドからサーバーに接続します（出典：リモートMCPを使用したカスタムコネクタの開始｜Anthropicヘルプセンター）。

2. MCPの主なセキュリティリスク

MCPの公式仕様・公式ガイドと、Anthropic・OpenAIのドキュメントに書かれているリスクを、6つに整理します。

2-1. 権限の与えすぎ

AIに必要以上の権限（とくに書き込み・削除）を渡していると、誤動作や悪用のときに被害が広がります。

MCPの公式ガイドは、範囲の広い権限（たとえばファイル全体・データベース全体・管理者の権限）をまとめて付けたトークンが盗まれると、関係のないツールやデータまで使われ、取り消すときにもすべての作業が止まると説明しています。最初は読み取りなど危険の小さい権限だけを与え、必要になったときに追加する形を推奨しています（出典：Security Best Practices｜Model Context Protocol）。

Anthropicのヘルプも、接続の認証のときにサーバーが求める権限を確認し、不要に見える権限は拒否するよう案内しています（出典：リモートMCPを使用したカスタムコネクタの開始｜Anthropicヘルプセンター）。

2-2. プロンプトインジェクション

プロンプトインジェクションは、AIが読みそうな文章（Webページ、メール、問い合わせの本文など）に悪意のある指示を埋め込み、AIの本来の動きを乗っ取る攻撃です。AIがその指示に従うと、利用者も開発者も意図していない操作をしたり、非公開のデータを外部に送ったりするおそれがあります（出典：Building MCP servers for plugins and API integrations｜OpenAI API）。

注意したいのは、MCPサーバーの開発元を信頼していても、このリスクは消えないことです。OpenAIのドキュメントは、たとえば顧客サポートのMCPに、攻撃者が問い合わせの形で指示を送り込める場合を挙げ、安全に使うには、そのMCPで読めるすべての内容を信頼できる必要があると説明しています。別のMCP（メールなど）から入った指示で、社内ツールのデータを読ませて外へ送らせる、という組み合わせの攻撃も挙げています（出典：同上）。

2-3. ツールポイズニングと、承認後の書き換え

MCPサーバーがAIに渡すツールの名前と説明は、AIが「指示」として読む文章です。サーバーがそこに指示を隠しておくと、そのツールが一度も呼ばれなくても、ほかのサーバーのツールの使い方まで含めてAIの動きを変えられます。これはツールポイズニング、ほかのサーバーのツールを狙うものはツールシャドーイングと呼ばれます（出典：Local Server Security｜Model Context Protocol）。

さらに、ツールの定義はインストールしたときのまま固定されるとは限りません。利用者が承認したあとに、サーバーが黙って定義を書き換えることがあり（ラグプル）、最初の1回の同意やバージョンの固定だけでは防げません（出典：同上）。Anthropicのヘルプも、サーバーの開発者が予期せずツールの動作を変えることがあるとして、ツールの動作の変化を見張るよう案内しています（出典：リモートMCPを使用したカスタムコネクタの開始｜Anthropicヘルプセンター）。

2-4. トークンの漏えいと使い回し

MCPサーバーは、ほかのサービスにアクセスするためのトークンや認証情報を扱います。

MCPの仕様は、MCPサーバーが自分あてに発行されたものではないトークンを受け取ったり、そのまま別のサービスへ渡したりすること（トークンパススルー）をはっきり禁止しています。きちんと確かめずに受け取ると、1つのサービスを破った攻撃者が、そのトークンでつながっているほかのサービスにも入れてしまうためです（出典：Security Best Practices｜Model Context Protocol／Authorization｜Model Context Protocol）。

ローカルのサーバーでは、シェルの設定でクラウドの認証情報やAPIトークンを全体に読み込んでいると、動かすすべてのサーバーがそれを読める可能性があります（出典：Local Server Security｜Model Context Protocol）。また、ClaudeのTeam・Enterpriseプランで、APIキーのような共有の認証情報を使うコネクタを追加すると、使う人全員がその認証情報の権限でサービスに届きます（出典：リモートMCPを使用したカスタムコネクタの開始｜Anthropicヘルプセンター）。

2-5. 偽のサーバー・乗っ取られたパッケージ

本物によく似た名前のパッケージ、そっくりのリポジトリ、放置されて別の人に引き継がれたプロジェクトなどを通じて、悪意のあるサーバーが入り込むことがあります。表向きは説明どおりに動きながら、裏で環境変数やファイルを持ち出すものもあります。また、作者に悪意がなくても、依存している部品の1つが乗っ取られる（サプライチェーン攻撃）ことがあります（出典：Local Server Security｜Model Context Protocol）。

MCP公式は、パッケージの配布サイトに載っていることは「お墨付き」ではなく、MCPのカタログの審査も「できる範囲で」の扱いだと注意しています（出典：同上）。

2-6. ローカルサーバーでのコード実行

ローカルのMCPサーバーは、自分のPCの上でダウンロードしたプログラムを動かします。MCPの公式ガイドは、設定に悪意のある起動コマンドを仕込まれる、サーバーの中身に悪意のあるコードが入っている、といった攻撃で、AIアプリと同じ権限で任意のコマンドを実行され、データの持ち出しや消失が起こりうると説明しています。そのため、ワンクリックでローカルサーバーを設定できるAIアプリは、実行するコマンドを省略せずに表示し、利用者の明示的な承認を得なければならない、と定めています（出典：Security Best Practices｜Model Context Protocol）。

3. リスクを抑えるための対策

技術的な実装の詳細は開発チーム向けですが、導入を判断する立場でも押さえておきたい基本は共通です。2章の6つのリスクに対して、公式が推奨している対策を7つにまとめます。

3-1. 最小権限：必要なツールとデータだけに絞る

AIに渡す権限は、作業に必要な最小限にします。MCPの公式ガイドは、最初は読み取りなど危険の小さい権限だけにし、必要なときに追加する形を推奨しています（出典：Security Best Practices｜Model Context Protocol）。ファイルを扱うサーバーなら、ホームフォルダ全体ではなく特定のフォルダだけを、できれば読み取り専用で渡します（出典：Local Server Security｜Model Context Protocol）。

AI側でもツールを絞れます。Claudeでは「検索とツール」メニューから、いまの会話に関係のないツールや、呼び出してほしくないツールを無効にできます（出典：リモートMCPを使用したカスタムコネクタの開始｜Anthropicヘルプセンター）。

ClaudeやChatGPTでMCPサーバーをつなぐ手順は、Claude MCPの設定・接続方法｜アプリ別の手順と注意点とChatGPTでMCPを設定・接続する方法｜手順と活用例で解説しています。

3-2. 提供元を確かめてからつなぐ

接続するのは、信頼できる組織が作って運営しているサーバーだけにします（出典：リモートMCPを使用したカスタムコネクタの開始｜Anthropicヘルプセンター）。ローカルのサーバーを入れる前には、MCP公式が次の確認を勧めています（出典：Local Server Security｜Model Context Protocol）。

• 公開している人や組織を特定できるか。リポジトリに最近のもっともらしい更新があるか
• パッケージ名が、公式のドキュメントに書かれた名前と完全に一致しているか（似た名前の偽物ではないか）
• バージョンを固定して入れているか（latest のまま自動で更新されないか）

3-3. 書き込みは人が確認する

MCPの仕様は、安全のために、ツールの呼び出しを拒否できる人が常に間に入るべきだとしています。AIアプリには、どのツールがAIに渡されているかを示す画面、ツールが呼ばれたときの表示、操作の前の確認を用意するよう求めています（出典：Tools｜Model Context Protocol）。

使う側では、AIのツール承認のリクエストをよく読み、「常に許可」は信頼するサーバーとツールにだけ使います。Claudeのリサーチ機能では、AIが承認なしでコネクタのツールを呼ぶことがあるため、書き込みのできるツールは無効にするよう案内されています（出典：リモートMCPを使用したカスタムコネクタの開始｜Anthropicヘルプセンター）。OpenAIも、書き込みの操作は実行されるたびに、意図したものか、共有してはいけないデータが含まれていないかを確認するよう勧めています。信頼できない人が書いた内容を含みうるMCPは、開発元を信頼していても使わないことも挙げています（出典：Building MCP servers for plugins and API integrations｜OpenAI API）。

3-4. 認証はOAuthで、トークンはサーバーごとに分ける

リモートのサーバーは、OAuthで認証するものを選びます。ClaudeでOAuthを使うコネクタを追加すると、アプリに安全にサインインして特定の権限を与える流れになり、Claudeが実際のパスワードを見ることはありません。与えた権限は、コネクタの接続を切れば、いつでも取り消せます（出典：リモートMCPを使用したカスタムコネクタの開始｜Anthropicヘルプセンター）。

ローカルのサーバーに渡すトークンは、サーバーごとに、範囲を絞ったものを別々に発行します。トークンは設定ファイルに平文で置かず、OSの鍵の保管場所を使えるならそちらを使い、サーバーを外したら、そのサーバーに渡していたトークンを作り直します（出典：Local Server Security｜Model Context Protocol）。

3-5. ツールの説明と、その変化を見張る

使い始める前に、サーバーが出しているツールの一覧と説明を読みます。ツールの役目と関係のない指示が書かれていたら、そのサーバーは外します。承認したときのツール定義を記録し、変わったときに確認を求めてくるAIアプリを選ぶのも有効です。つなぐサーバーの数を少なく保つことも、MCP公式が勧める対策です（出典：Local Server Security｜Model Context Protocol）。

3-6. ローカルで動かすなら隔離する

ローカルでしか動かせないサーバーは、コンテナなどの隔離した環境で動かし、必要なフォルダ以外は見せないようにします。MCP公式は、隔離をこのガイドの中で最も効果の大きい対策としています。外部と通信する必要のないサーバーは、ネットワークも切っておきます（出典：Local Server Security｜Model Context Protocol）。

3-7. 記録を残し、使っていないものを外す

どのサーバーの、どのツールが、いつ使われたかを記録しておくと、問題が起きたときに、権限から推測するのではなく実際の動きを確かめられます。会社で使う場合は、各PCのAIアプリの設定を集めて「誰が、どのサーバーを、どのバージョンで使っているか」を把握することを、MCP公式が出発点として挙げています（出典：Local Server Security｜Model Context Protocol）。

4. 導入前に押さえるチェックリスト

非エンジニアや導入を判断する立場の方が、MCPサーバーをつなぐ前に最低限確認したい項目です。

#	確認すること	根拠
1	提供元を特定できるか（公式・信頼できる組織か、名前が公式と完全に一致するか）	Anthropicヘルプ・MCP公式
2	自分のPCで動かす必要があるか（不要ならリモート版を選ぶ）	MCP公式
3	認証はOAuthか（AIにパスワードを渡さずに済むか）	Anthropicヘルプ
4	求められる権限は作業に見合っているか（読み取りだけで足りないか）	MCP公式・Anthropicヘルプ
5	取得できるデータが、使う人の権限に連動しているか（共有の認証情報で全員が同じ範囲を見ないか）	Anthropicヘルプ
6	書き込みのツールはどれか。実行前に人が確認できるか	MCP公式・OpenAI
7	呼び出しの回数に上限（レート制限）があるか	MCP公式（サーバーはツールの呼び出しを制限しなければならない）
8	問題が起きたら、すぐに接続を切れるか	Anthropicヘルプ
9	ツールの定義が変わったときに気づけるか	MCP公式

7のレート制限は、MCPの仕様がサーバー側の義務として定めているものです（出典：Tools｜Model Context Protocol）。それ以外の根拠は、2章・3章の出典のとおりです。

ただし、MCP公式は、サーバーが何をするかを前もって証明できるチェックはないとも書いています。リポジトリや署名、カタログへの掲載は、誰を信頼しているかを教えてくれるだけで、その信頼が正しいことまでは保証しません。だからこそ、確認に加えて、渡す権限そのものを小さくしておくことが大切です（出典：Local Server Security｜Model Context Protocol）。

社内でMCPを使う場合は、確認を通ったサーバーを、バージョンも含めて短い「承認済みリスト」にまとめ、新しいサーバーを加えるときの条件（提供元が特定できる・ソースが読める、など）も決めておく方法が、MCP公式で紹介されています（出典：同上）。目的別にどんなMCPサーバーがあるかは、MCP対応ツール・サーバーおすすめ比較｜選び方とカテゴリ別一覧で紹介しています。

5. 【実例】チェックリストで見るMCPの例：Squad beyond MCP

チェックリストを実際のサービスに当てはめると、どう見えるか。LPの制作・ABテスト・効果測定ができるSquad beyondが提供する「Squad beyond MCP」を例に、公式FAQに書かれていることを4章の項目ごとに並べます。Squad beyond MCPは、ChatGPTやClaudeなどのAIツールとSquad beyondを接続し、AIからデータの参照・調査・分析ができるようにする機能で、料金は利用しているプランによって異なります（出典：Squad beyond MCPについて｜Squad beyond FAQ）。

チェック項目	Squad beyond MCP（公式FAQの記載）
1. 提供元	接続先のサーバーのURL（https://mcp.mysquadbeyond.com/mcp）と、AIツールごとの設定手順が公式FAQに載っている
2. どこで動くか	AIツールにサーバーのURLを登録して接続する。動作確認されているのはChatGPT・Claude Code・Codex・Gemini CLI・Antigravity CLI・Notion AI
3. 認証	ChatGPTとNotion AIの設定手順は「認証：OAuth」。Claude Codeでは、Squad beyondのログイン画面でログインして連携を承認する
5. 権限との連動	「取得出来るデータはSquad beyond上の権限に紐づいています」
6. 書き込みのツール	HTMLのアップロード、下書きの本番反映、配信割合の変更、ページの複製などもAIへの指示で実行できる
7. レート制限	1分間に10回まで。上限に達しても自動で解除される
8. 接続を切る	Squad beyond側でチームやアカウントを切り替えたときは、AIツール側に自動で反映されないため、一度接続を解除してから再接続する

出典：Squad beyond MCPについて｜Squad beyond FAQ／MCPの活用方法について｜Squad beyond FAQ

5の「権限」は、Squad beyondのオーナー・メンバー・フリーユーザーの権限です。たとえばメンバーは、オーナーから権限を付与されたフォルダだけを編集・閲覧できます（出典：権限について｜Squad beyond FAQ）。AIに見せたい範囲が決まっているなら、MCPで接続する人の権限そのものを絞っておく、という使い方ができます。2026年8月からは、MCPから、いまログインしているメンバーの名前・メールアドレス・チーム・権限情報を取得できるようになりました（出典：2026/08_リリース情報｜Squad beyond FAQ）。AIがどの権限で動いているかを、会話の中で確かめられます。

6のとおり、Squad beyond MCPには配信中のページに影響する操作も含まれます。3-3のとおり、本番反映や配信割合の変更のような操作は、AIに「常に許可」を出さず、実行前に内容を確認する運用にしておくと安心です。

MCPの認証は、Squad beyondのアカウントへのログインを通じて行われます。Squad beyondは「Googleでログイン」と2要素認証に対応しているので、アカウントそのものの保護もあわせて設定しておきましょう（出典：Squad beyondのセキュリティ対策について（Googleログイン/2要素認証）｜Squad beyond FAQ）。

6. 運用時に継続して気をつけたいこと

導入したあとも、次の点を続けて確認します。

• 仕様の版を確かめる：MCPの仕様は「2026-07-28」のような日付の形で版を表し、後方互換のない変更が入った日を示します。2026年11月2日時点の現行版は2026-07-28です（出典：Versioning｜Model Context Protocol）。AIツールやサーバーの対応状況は変わるので、公式の情報を定期的に確認します
• 接続しているサーバーの棚卸し：使っていないサーバーは外し、残すものは出どころとバージョンを把握しておきます（出典：Local Server Security｜Model Context Protocol）
• 脆弱性の告知が出たら更新する：バージョンを固定していると、告知が出たときに古いまま残ります。固定と、意図して更新する習慣をセットにします（出典：同上）
• アカウント切り替え時の再接続：Squad beyond MCPのように、チームやアカウントを切り替えたら接続を解除して再接続するサービスもあります（出典：Squad beyond MCPについて｜Squad beyond FAQ）
• 悪意あるサーバーに気づいたら報告する：Anthropicは脆弱性開示プログラムへの報告を、OpenAIは security@openai.com への報告を案内しています（出典：リモートMCPを使用したカスタムコネクタの開始｜Anthropicヘルプセンター／Building MCP servers for plugins and API integrations｜OpenAI API）

7. MCPのセキュリティでよくある失敗3つ

MCPを使い始めたときに起こりやすい失敗を、症状・原因・対策・回避策の順に整理します。

7-1. 失敗例1：書き込みのツールまで「常に許可」にする

• 症状：書き込みのツールまで「常に許可」にすると、AIが読んだ文章に仕込まれた指示で、意図しない更新や送信が実行されても止められなくなる
• 原因：プロンプトインジェクションは、サーバーの開発元を信頼していても防げない。承認の確認を外すと、人が止める機会もなくなる
• 対策：「常に許可」は信頼するサーバーの読み取りのツールだけにし、書き込みのツールは実行のたびに内容を確認する
• 回避策：使い始める前に、ツールの一覧を「読み取り」と「書き込み」に分け、書き込みのツールの扱いを決めておく。不要なツールは無効にする

7-2. 失敗例2：個人の広い権限のトークンを複数のサーバーで使い回す

• 症状：アカウント全体に効くトークンを複数のサーバーに渡すと、1つのサーバーから漏れたときに、関係のないデータまで読まれる
• 原因：トークンの範囲が広く、どのサーバーにも同じものを渡している
• 対策：サーバーごとに範囲を絞ったトークンを別々に発行し、漏えいが疑われたら、そのトークンだけを止めて作り直す
• 回避策：リモートのサーバーはOAuthで接続するものを選び、ローカルのサーバーのトークンは設定ファイルに平文で置かない

7-3. 失敗例3：入れたまま使っていないサーバーを放置する

• 症状：使っていないサーバーを残したままにすると、承認後にツールの説明が書き換えられても、気づかないうちにAIの動きが変わる
• 原因：つないだサーバーは、すべてが同じAIの文脈を共有するので、1つが増えるたびにほかのサーバーまで影響を受ける範囲が広がる。定義は承認後にも変わりうる
• 対策：時期を決めて定期的に接続中のサーバーを一覧にし、使っていないものを外す
• 回避策：ツールの定義が変わったときに確認を求めるAIアプリを選び、承認済みのサーバーをリストで管理する

8. MCPのセキュリティについてよくある質問（FAQ）

9. まとめ

MCPの安全性は、仕組みがあるかどうかではなく、何をつなぎ、何を許可するかという「選び方と運用」で決まります。

• 主なリスクは、権限の与えすぎ・プロンプトインジェクション・ツールポイズニングと承認後の書き換え・トークンの漏えいと使い回し・偽のサーバー・ローカルサーバーでのコード実行の6つ
• 対策の基本は、最小権限・提供元の確認・書き込みは人が確認・OAuthとトークンの分離・ツール定義の監視・ローカルの隔離・記録と棚卸し
• 導入前には、提供元・動く場所・認証・権限・データの連動・書き込み・レート制限・切断・定義の変化をチェックする

どのチェックも、サーバーの動きを前もって保証するものではありません。だからこそ、まずは信頼できるサーバーを1つ、最小の権限でつなぎ、書き込みの操作を確認しながら使うところから始めてみてください。

　

Squad beyondサービス紹介資料はこちらからダウンロード