MCPの限界とは？企業AI本番運用の壁とセキュリティをDifyで突破

はじめに：なぜ「PoCは動いたのに本番に進めない」のか

2024年11月にAnthropicが公開したMCP（Model Context Protocol）は、わずか1年あまりでAIエコシステム全体の標準仕様となりました。OpenAI、Google、Microsoftといった主要ベンダーが採用を表明し、MCPサーバーの実装は社内外を問わず急増しています。2025年12月にはAnthropicがMCPをLinux Foundation傘下のAgentic AI Foundationへ寄贈し、いまや一社の仕様ではなく、ベンダー中立なオープンガバナンスのもとで進化を続ける標準となりました。

一方で、弊社がDifyを中核としたエンタープライズAI導入をご支援するなかで、最も頻繁にいただくご相談がこちらです。

「社内のエンジニアがMCPサーバーを立てて、Claude DesktopやDifyから動かすところまでは行けた。しかし、本番運用に持っていけない。」

この状況は、MCPの仕様を読み込んだだけでは解消されません。MCPはあくまで「接続の作法」を定めるプロトコルであり、企業がAIを安心して使うために必要な要件のすべてには答えていないからです。

本記事では、Workato Japanの鈴木浩之氏による論考「『MCPとは？』を本当に理解したい人へ」を起点に、弊社がDifyベースの受託開発で蓄積した知見を重ねながら、次の論点を順に整理します。

• MCPは何を解決し、何を解決しないのか
• API・iPaaS と何がどう違うのか
• MCP不要論はどこまで正しく、どこから的を外しているのか
• 本番運用で直面する7つの壁は何か
• MCP固有のセキュリティ脅威（ツールポイズニング等）にどう備えるか
• Difyと組み合わせるとき、設計上どこに気を配るべきか

1. MCPとは何か：AIと外部ツールを繋ぐ標準プロトコル

1.1 MCPの定義

MCP（Model Context Protocol）は、Anthropicが公開した「AIが外部システムや情報源にアクセスする際の作法を定めたオープン標準仕様」です。「AIにツールを使わせるための共通言語」と捉えると理解しやすいでしょう。

仕様は活発に更新されており、初版（2024-11-05）から、リモート接続とOAuth 2.1認可を導入した2025-03-26版、サーバーをOAuthリソースサーバーとして位置づけた2025-06-18版を経て、執筆時点の安定版は2025-11-25版（非同期Tasks、OAuth強化、エンタープライズ向けガバナンスの追加）です。「MCP対応」と言っても、どの仕様バージョン・どのトランスポートに準拠しているかで、できることは大きく変わる点に注意が必要です。

1.2 なぜ標準化が必要だったのか：M×N問題

MCPが急速に広がった背景には、AI開発現場が長年抱えてきたM×N問題があります。

• AIアプリ A は Slack 用の接続コード、Salesforce 用の接続コードと、個別に実装
• AIアプリ B も同じく個別実装
• 新しいツールが増えるたび、すべてのアプリ側で実装が必要

3つのAIアプリが5つのSaaSと連携する場合、最大で3×5=15通りの実装が発生します。連携先を増やせば増やすほど、保守コストは指数関数的に膨らんでいきます。

MCPは、この「アプリ × ツール」の掛け算を「アプリ + ツール」の足し算へと変える役割を担います。AIモデルやアプリ側はMCPプロトコルにさえ対応すればよく、ツール側もMCPサーバーを1つ用意すれば、どのAIアプリからも呼び出される、という構図です。

1.3 MCPの3コンポーネント

たとえば「来週の予定を教えて」とユーザーが入力すると、Host内のAIが「Googleカレンダーを呼び出すべきだ」と判断し、対応するMCP ClientがGoogle Calendar MCPサーバーへ問い合わせ、結果を受け取って回答に組み込みます。なおDifyは外部MCPサーバーに接続するHostとして動作するだけでなく、自身のワークフローをMCPサーバーとして公開する双方向対応も備えていますが、その実装詳細は別記事「MCP × Dify 完全ガイド」に委ね、本記事では「MCPの限界をどう超えるか」に集中します。

2. MCP・API・iPaaSの違い：3つの技術を整理する

MCPを正しく評価するには、これまで企業統合の現場を支えてきた API と iPaaS の役割を一度整理しておく必要があります。

2.1 APIが解決しようとしたこと

APIは、異なるシステム同士がデータをやり取りするための「窓口」を定める仕組みです。ただし、APIが普及するほど、前述のM×N問題が顕在化しました。連携先ごとに認証方式・スキーマ・エラー処理が異なり、開発者が個別に対処する必要がある世界です。

2.2 iPaaSが解決しようとしたこと

iPaaS（Integration Platform as a Service）は、M×N問題を「アプリ + ツール」の足し算に圧縮するために登場しました。

• 数千のシステム向けコネクターをプラットフォーム側があらかじめ用意
• 利用者はそれを選んで繋ぐだけ
• 認証管理・アクセス制御・監査ログ・エラーリトライをプラットフォームレベルで提供

重要なのは、iPaaSが「人間が設計したワークフローを効率的に動かす」ことに最適化された基盤だという点です。フローを描くのも、判断するのも人間。AIは登場しません。

2.3 MCPが解決しようとしていること

MCPの前提は、iPaaSとは根本的に異なります。AIエージェント自身が「どのツールを、いつ、どう使うか」を判断し、自律的に実行する時代に対応するための標準化です。

AIが自律的に判断するためには、ツール側がAIにとって読みやすい形で機能を公開している必要があります。MCPはまさに、その「AIから見たツール仕様の共通言語」を定めています。

2.4 三者の比較

技術進化の文脈で眺めると、次のような流れになります。人間が全部手で繋ぐ時代（API）から、プラットフォームが人間のワークフローを抽象化する時代（iPaaS）を経て、AIが自律的に判断・実行する時代（MCP）へ。

3. MCP不要論への回答：本当に問うべきは「コントロールプレーン」

MCPの普及と並行して、エンジニアコミュニティでは「MCPは不要ではないか」という議論が一定の支持を得ています。代表的な論点は次の3つです。

3.1 不要論の主な論点

1. トークン効率の悪さ
   MCPでは利用可能なツール定義がコンテキストにまとめてロードされるため、使わないツールの定義までトークンを圧迫します。これは仕様の生みの親であるAnthropic自身が認めている課題でもあります。同社が2025年11月に公開した「Code execution with MCP」では、多数のMCPサーバーを接続するとエージェントがユーザーのリクエストを読む前に5万トークン以上を消費しうること、ツールをコードとして扱う方式に切り替えると、ある事例ではトークン消費を約15万から約2,000へ（98.7%削減）圧縮できたことが報告されています。
2. CLI／APIの直接呼び出しの方が自由度が高い
   シェルスクリプトやAPIを直接叩く方が、抽象化の中間層がない分、開発者の意図通りに動かしやすい場面があります。
3. 標準化のコストとリスク
   MCPサーバーを用意・運用するコストが発生し、悪意あるサーバーや設定ミスによるセキュリティリスクも生まれます（具体的な攻撃ベクトルは第5章で扱います）。

どれも技術的には正当な指摘です。とくにトークン効率の問題は、当のAnthropicが自ら改善策を打ち出していることからも、傾聴に値します。開発者単体が小規模に自動化を組む場合、CLIや直接APIで十分というケースも確かに存在します。

3.2 不要論が見落としていること：コントロールプレーンの不在

ただし、企業のAI活用という視点から見ると、議論の軸は「プロトコルの優劣」ではなく「コントロールプレーンが存在するか」に置き直す必要があります。

CLIで直接実装した場合、何が実行され、誰がどこにアクセスし、何が失敗したかという情報は、すべて実装者の手元に分散します。エージェントが扱うシステムが増え、判断の自律性が高まるほど、組織にとっては「何がどこで何をしているのか分からない」状態が広がっていきます。エンタープライズの監査・コンプライアンス文脈では、これは受け入れがたい状態です。

企業のAI活用で先に問うべきは「MCPを採用するかどうか」ではなく、「コントロールプレーンとして何を採用するか」です。MCP自体は、その上に乗る通信仕様にあたります。

4. 企業AI本番運用で直面する「MCPの7つの壁」

MCPは素晴らしい標準ですが、プロトコルである以上、企業がLLMを実務で使い切るための要件をすべてカバーしているわけではありません。受託開発の現場で、PoCから本番運用へ移行する際に必ず突き当たる7つの壁を整理します。

4.1 接続できるシステム範囲の壁

当然のことですが、MCPで触れるのはMCPサーバーが用意されているシステムだけです。一方で、企業内には数十〜数百の業務システムが存在し、その多くは独自開発の業務システム・古いERP・自社固有のSaaS設定で構成されています。

MCPサーバーが存在しないシステムは、AIから「見えない」ままです。ここを埋めるには、自前でのMCPサーバー実装か、別の連携手段（APIラッパー、iPaaS、Dify上のコードノードなど）を組み合わせる設計判断が必要になります。

4.2 エンタープライズガバナンスの壁

初期のMCP（2024-11-05版）は通信方式しか定めておらず、認証や認可は完全に実装者任せでした。その後、2025-03-26版でOAuth 2.1ベースの認可フレームワーク（PKCE必須化・動的クライアント登録・ロールベースのアクセス制御）が導入され、2025-06-18版ではMCPサーバーをOAuthリソースサーバーとして分類し、Resource Indicators（RFC 8707）によって「悪意あるサーバーが他サービス向けのトークンを盗む」攻撃を防ぐ仕組みが加わりました。認証まわりは着実に強化されています。

ただし、これらは認証・認可の基本パーツが揃ったという段階です。企業がLLMを業務に乗せるうえで本当に必要なのは、その上に立つ運用ガバナンス層であり、次の要件は依然としてプロトコルの外側に残ります。

• 複数サーバー・複数エージェントを横断した操作の監査ログと可観測性
• データの暗号化・マスキング・最小権限のポリシー統制
• どのMCPサーバーへの接続を許すかという接続ポリシーの一元管理
• SOC2・GDPR・改正個人情報保護法などのコンプライアンス対応

論点は「MCPが認証を持つか」ではなく、「組織として一貫したコントロールプレーンを持てるか」に移っています。仕様が認可を取り込んだ今こそ、その上の運用設計が企業の責任範囲として残り続けます。

4.3 MCPサーバーの乱立と管理の複雑化

MCPの普及により、社内外で各部門・各個人が独自のMCPサーバーを立てる状況が起き始めています。AIエージェントが「とりあえず使えそうなサーバー」に勝手にアクセスし、誰がどこに繋がっているか把握できない、というガバナンスリスクが顕在化しつつあります。

対策としてMCPゲートウェイ（複数MCPサーバーへのアクセスを一元化するレイヤー）が注目されていますが、ゲートウェイ自体はMCPプロトコルの外側に位置する設計判断であり、誰がどう実装するかが問われます。

4.4 ビジネスプロセスの複雑性

MCPは「AIがツールを呼び出す」までを定めますが、複数システムをまたぐ業務プロセスの制御は守備範囲外です。

たとえば、次のようなフローを考えてみてください。

受注情報がSalesforceに登録されたら、在庫を確認し、NetSuiteに受注を登録し、Slackで担当者に通知し、例外時は人間が承認する。

このプロセスを安定して回すには、エラーハンドリング、リトライ、人間承認フロー、状態管理が必要です。MCPプロトコル単体ではここまで踏み込めません。

4.5 AIに渡すコンテキストの設計

AIが受け取る情報は、多すぎても少なすぎても精度を落とします。本質的な課題は「必要な情報を、適切な粒度で、AIに渡せるか」という設計問題です。

単にAPIをラップしただけのMCPサーバーは、AIが使わない項目までごっそり渡してしまい、重要な情報をノイズに埋もれさせ、コンテキストウィンドウを圧迫します。本番品質のMCPサーバーは、サーバー側にビジネスロジックを持ち、AIに必要な情報だけを返す設計になっています。

4.6 エンタープライズ級実行基盤の不足

MCPは接続仕様であり、実行基盤ではありません。本番運用に必要な次の要件は、すべてプロトコル外で担保する必要があります。

• 大量リクエストへのスケーラビリティ
• 障害時のフェイルオーバー
• SLAの担保
• レート制御・キュー管理

4.7 LLMの不確実性の制御

MCPは「AIに何ができるか」を定めますが、「AIに何をやらせてはいけないか」は何も決めていません。LLMは確率的に応答するため、同じ入力でも異なる出力が返ることがあります。

基幹業務のように「揺らぎを許容できない領域」では、重要な意思決定に人間レビューを挟む（Human-in-the-Loop）、誤判断時のフォールバックを用意する、決定論的な処理に切り替える、といったアーキテクチャ上の工夫が不可欠です。

5. 本番運用で直面するMCP固有の5つのセキュリティ脅威

4章で挙げた壁、とりわけガバナンスの欠如（4.2）とMCPサーバーの乱立（4.3）は、抽象的なリスクにとどまりません。MCPの普及とともに、具体的な攻撃ベクトルが次々と報告され、実害も出ています。とくに情シス・セキュリティ部門が本番導入を判断する際は、最低限これらの脅威を理解しておく必要があります。

5.1 ツールポイズニング（Tool Poisoning）

ツールの説明文やメタデータに、AIへの隠れた指示を埋め込む手口です。MCPの脅威モデリング研究（arXiv 2603.22489）では、クライアント側で最も多く、影響の大きい脆弱性として整理されています。AIはツール定義を「信頼できる情報」として読むため、説明文に紛れ込んだ命令にそのまま従ってしまいます。スキーマ全体を汚染する手口（Full Schema Poisoning）や、より巧妙な変種（Advanced Tool Poisoning）も報告されています。

実際の被害例として、2025年4月にInvariant Labsが公表したツールポイズニング攻撃の検証では、無害に見えるツールの説明文に隠した指示によって、AIエージェントにWhatsAppのメッセージ履歴を攻撃者へ転送させられることが示されました。ユーザーの操作ログには信頼済みツールしか現れないため、検知が極めて困難です。

その深刻さは定量的にも裏づけられています。ツールポイズニングのベンチマークMCPTox（arXiv 2508.14925）による20種のLLMエージェントの評価では、o1-miniの攻撃成功率が72.8%に達し、命令追従能力の高いモデルほど逆に騙されやすいという皮肉な結果が示されました。攻撃を拒否できたモデルもごく少数で、最も拒否率の高いClaude 3.7-Sonnetでも3%未満でした。

5.2 間接プロンプトインジェクション

ツールポイズニングが「ツールの定義」を汚染するのに対し、間接プロンプトインジェクションは「AIが読み込む外部データそのもの」（メール本文、issue、サポートチケットなど）に攻撃用の指示を仕込む手口です。代表的な実例として、サポートチケット経由のインジェクションにより、データベースへ直接アクセスできるMCPサーバーを通じて非公開テーブルが露出しうることが実証されています（高権限のサービスロールで動くCursorエージェントが、チケット本文に紛れた指示をSQLとして実行してしまうケース）。「過剰な権限を持つAI × 信頼できない入力 × 外部への通信経路」が揃うと、自然言語だけで情報漏えいが成立してしまいます。

5.3 Rug Pull と クロスサーバー・ツールシャドウイング

• Rug Pull（定義のすり替え）：承認時は無害だったツールが、後から定義を書き換えてAPIキーを攻撃者へ送るよう変化する。CVE-2025-54136（MCPoison）として登録された構造的脆弱性で、従来のセキュリティツールはツール説明文や設定の変化を監視しないため気づきにくい。
• ツールシャドウイング：複数サーバーを同一エージェントに接続している場合、悪意あるサーバーが信頼済みサーバーへの呼び出しを横取り・上書きする。

5.4 トランスポート起因のリモートコード実行（RCE）

MCPのSTDIOトランスポートにおいて、設定値がサニタイズされないままシェル実行に渡る設計上の欠陥が報告されており、複数のフレームワークでRCE（リモートコード実行）につながりました。対策としては、HTTPベース（Streamable HTTP）のサーバー採用と、設定値の無検証実行の排除が基本となります。実装パターン全般のチェックはOWASP MCP Security Cheat Sheetが便利です。

5.5 サンプリング機能を経由した攻撃

MCPのサンプリング機能（サーバーがクライアントにLLM呼び出しを要求できる仕組み）も新たな攻撃面になっています。Palo Alto Unit 42の調査では、サンプリングを経由したプロンプトインジェクションにより、AIに本来許されない処理を実行させる攻撃ベクトルが報告されています。サーバー側に「LLMを呼び出す権限」を与えることのリスクを設計時点で評価する必要があります。

5.6 参照すべきセキュリティ枠組み

自社のMCP導入をレビューする際は、業界標準のチェックリストを起点にすると漏れが減ります。

• OWASP MCP Top 10：MCP固有のリスクを分類した最初の業界標準フレームワーク（OWASP公式プロジェクト、2025年）。トークン管理の不備や権限の過剰付与など10カテゴリを整理。
• CISA「AI Data Security」共同ガイダンス（2025年5月22日）：CISA・NSA・FBIに加え、英・豪・NZの政府機関が共同でまとめたAIデータセキュリティの指針。PDF原本はこちら。

これらの脅威に共通するのは、「AIが自然言語レベルで騙される」という点です。シグネチャ検知型の従来型セキュリティでは防ぎきれず、AIの推論プロセスそのものを設計でガードする必要があります。具体的な打ち手は、続く6章でDifyの実装パターンとして見ていきます。

6. Difyで「MCPの先」を実装する設計指針

ここまで挙げた7つの壁とセキュリティ脅威は、「MCPの上にどんな実行基盤を載せるか」という問題に帰着します。弊社では、その答えのひとつとしてDifyを中核としたエンタープライズAI基盤を提案・構築しています。本章では、Difyを用いて「MCPの先」をどう設計するか、実装観点で解説します。

6.1 Difyワークフローで決定論的フローを担保する

DifyのWorkflow機能は、ノードを連結したフロー上で「どの順序で・どの条件で・どのツールを呼ぶか」を事前に設計できます。LLMの揺らぎを許容できない業務において極めて有効です。

• LLMノードで「判断」させる箇所と、コードノードで「決定論的に処理する」箇所を明確に分離する
• 外部ツールの呼び出しは、自由度の高いエージェントではなく、フロー上の明示的なノードとして配置する
• 分岐ノード（IF/ELSE）で例外フローを必ず用意する

MCPサーバーで公開されたツールも、Dify Workflow上では「他のノードと同じく一つの工程」として扱えます。AIに丸投げするのではなく、フローの作者が制御の手綱を握る設計が可能です。これは、ツールポイズニングのように「AIが自律的にツールを選ばされる」ことを起点とする攻撃の入り口を、構造的に塞ぐことにもつながります。

6.2 認証・認可ノードを必ず挟む

Difyではコードノード（Python／JavaScript）を介して、JWT検証・IP制限・テナントIDチェックなどをツール呼び出しの前段で必ず通すことができます。MCPサーバー側だけに依存せず、Host側でも認可を二重化することで、ガバナンス上の最後の砦を作れます。あわせて、接続先MCPサーバーにはResource Indicators（RFC 8707）に対応したものを選び、トークン横取り（Confused Deputy）への耐性を持たせることが望ましいです。

# Difyコードノードでの認可チェック例（概念）
def main(user_claims: dict, target_resource: str) -> dict:
    allowed_roles = {"finance_admin", "ops_manager"}
    role = user_claims.get("role")
    tenant = user_claims.get("tenant_id")

    if role not in allowed_roles:
        return {"authorized": False, "reason": "role_not_permitted"}
    if not target_resource.startswith(f"tenant:{tenant}:"):
        return {"authorized": False, "reason": "cross_tenant_access"}

    return {"authorized": True}

このノードの直後にIF/ELSEノードを配置し、authorized == Falseの場合はツール呼び出しに進ませず、エラーメッセージを返して即時終了させます。返り値だけ作って後段で参照し忘れる、という設計ミスを避けるために、認可ノードと分岐ノードは必ずワンセットで運用するのが弊社の標準です。

6.3 コードノードでデータの粒度を整える

外部システムから戻ってきたJSONをそのままLLMに渡すと、トークンが膨れ上がるうえ、AIの判断精度が落ちます。Difyのコードノードを挟み、AIが意思決定に使う項目だけを抽出・正規化してから次のLLMノードへ渡すと、安定性とコスト効率の両方が改善します。これは第3章で触れたAnthropicの「Code execution with MCP」が示した方向性、すなわち「データの加工は決定論的なコードに任せ、LLMには判断に必要な情報だけを渡す」と同じ考え方です。

弊社の受託開発では、この「整形ノード」を入れるだけで1呼び出しあたりのトークン消費量を30〜50%削減できたケースが珍しくありません（削減幅は案件・データ構造により異なります）。

6.4 HITL（Human-in-the-Loop）ノードで人間レビューを組み込む

重要な意思決定（金額の確定、契約書のドラフト送付、本番DBへの書き込みなど）の手前には、人間承認のステップを設計します。Difyでは承認待ちノードやSlack／メール連携を組み合わせ、AIの提案を人間がワンクリックで承認／差し戻しできるフローを実装可能です。

この「人間の最終判断ポイント」を必ず1か所以上設けることで、LLMの確率的な誤りや、第5章で挙げた間接プロンプトインジェクションによる不正な操作が、そのまま本番事故に直結するリスクを大きく下げられます。

6.5 脅威とDify側の対策の対応関係

第5章で挙げたMCP固有の脅威は、Difyの各設計パターンと次のように対応づけられます。図3でパイプライン全体を概観したうえで、続く表に脅威ごとの対応を詳述します。MCP対応そのものではなく、この対応表を満たせるかどうかが本番運用の分かれ目です。

7. まとめ：MCPは入場券、本番運用は実装力で決まる

本記事の論点を振り返ります。

• MCPはAIと外部システムを繋ぐ標準プロトコルとして、AIエコシステム全体の前提を変えた。仕様も活発に進化し、OAuth 2.1ベースの認可など認証のプリミティブは取り込まれつつある。
• しかしMCPは「接続の作法」を定めるだけで、企業がLLMを安心して業務に乗せるための要件のすべてには答えていない。
• 本番運用では、運用ガバナンス・ビジネスプロセス制御・データ品質・決定論的実行基盤といった「MCPの外側」を誰がどう実装するかが決定的に重要になる。
• さらに、ツールポイズニングや間接プロンプトインジェクションといったMCP固有の攻撃ベクトルへの対処も、最終的には実装側の設計に委ねられる。
• 「MCP対応しているか」は、いわば入場券のようなもの。本当の評価軸はその裏側の実装品質である。

これら「7つの壁」と「5つのセキュリティ脅威」をすべて自社で設計・実装し切るのは、社内のエンジニア数名で抱えるには負荷の大きい仕事です。プロトコルの上に載せる業務基盤・ガバナンス層・脅威モデリングを、過去の受託開発の知見と組み合わせて素早く設計できるパートナーが、PoCから本番運用への分岐点で大きな価値を発揮します。

私たちが受託開発の現場でクライアントに必ず投げかけている問いがあります。

あなたの会社が検討しているMCPサーバーは、プロトコルへの対応だけでなく、ここで挙げた「7つの壁」と「5つのセキュリティ脅威」への対策を満たしていますか？

この問いへの答えが、自社のAI活用を「PoC止まり」にするか「本番運用」へ進めるかを分けます。

参考文献

• 鈴木浩之「『MCPとは？』を本当に理解したい人へ」Workato Japan
  https://www.workato.com/the-connector/ja/what-is-mcp/
• Anthropic「Introducing the Model Context Protocol」（2024年11月）
• Anthropic「Code execution with MCP: Building more efficient agents」（2025年11月）
  https://www.anthropic.com/engineering/code-execution-with-mcp
• MCP公式仕様、現行安定版 2025-11-25（主要マイルストーン：初版 2024-11-05／OAuth 2.1・Streamable HTTP導入の 2025-03-26／OAuthリソースサーバー分類・RFC 8707の 2025-06-18）
  https://modelcontextprotocol.io/specification/2025-11-25/changelog
• Linux Foundation / Agentic AI Foundation へのMCP寄贈（2025年12月、ベンダー中立ガバナンスへ移行）
• OWASP MCP Top 10（MCPリスク分類フレームワーク）
  https://owasp.org/www-project-mcp-top-10/
• OWASP MCP Security Cheat Sheet
  https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html
• CISA／NSA／FBI／豪・英・NZ「AI Data Security」共同ガイダンス（2025年5月22日）
  https://www.cisa.gov/news-events/alerts/2025/05/22/new-best-practices-guide-securing-ai-data-released
  （PDF原本：CSI_AI_DATA_SECURITY.PDF）
• Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning（arXiv 2603.22489）
  https://arxiv.org/abs/2603.22489
• Zhiqiang Wang et al.「MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers」（arXiv 2508.14925、2025年8月。o1-mini 攻撃成功率72.8%／Claude 3.7-Sonnet 拒否率3%未満の出典）
  https://arxiv.org/abs/2508.14925
• Invariant Labs「MCP Security Notification: Tool Poisoning Attacks」（2025年4月、WhatsAppメッセージ履歴の漏えい実証）
  https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
• TrueFoundry「MCP Tool Poisoning（CVE-2025-54136 / MCPoison）」
  https://www.truefoundry.com/blog/blog-mcp-tool-poisoning-gateway-defense
• Palo Alto Unit 42「New Prompt Injection Attack Vectors Through MCP Sampling」
  https://unit42.paloaltonetworks.com/model-context-protocol-attack-vectors/