MCPエージェント評価、攻撃成功58件が誤り｜研究解説

MCPエージェント評価、攻撃成功58件が誤り｜研究解説 研究・論文

AIエージェントの安全性評価で報告される「攻撃成功率」は、エージェントの挙動ではなくラベルの付け方を測っていることがある——そう指摘する査読前論文が2026年8月13日にarXivで公開されました。あるMCPエージェントの評価キャンペーンを監査したところ、採点器が「その試行が攻撃条件だったか」というメタデータを判定の入口に使っており、条件のラベルを付け替えるだけで同じ挙動の分類が変わる状態でした。条件を伏せて採点し直すと、攻撃成功・乗っ取り試行とされていた58件が「正規の完了」に訂正されています。

情シスにとっての意味は明快です。AIエージェントやMCP連携の導入可否を、ベンダーが示す評価スコアだけで判断するのは危険だということ。ただし本研究は単一キャンペーンの測定監査であり、「AIエージェントは安全だった」という話ではありません。

この記事でわかること

  • MCPとは何で、自社に既に入り込んでいる可能性がどこにあるか
  • 安全性評価のラベルが実際の挙動とズレた仕組み（treatment leakage）
  • ベンダーの評価数値を受け取ったときに聞くべきこと
  • 同じ欠陥が自社のログ・アラート設計にも潜む理由
  • この研究の限界（査読前・単一キャンペーン）

そもそもMCPとは何か

MCP（Model Context Protocol）とは、AIアプリケーションを外部システムに接続するためのオープンな標準仕様です。ファイル・データベースといったデータソース、検索などのツール、定型の処理手順を、共通の作法でAIに繋ぎ込みます。公式ドキュメントはこれを「AIアプリケーションにとってのUSB-Cポート」に例えています。

使う場面は、社内データやSaaSにAIアシスタントを接続して調べもの・集計・定型作業をさせるケースです。導入を進めるのは開発部門や業務部門で、接続先に何を許すかを審査するのが情シスの役割になります。

「うちはMCPを導入していない」と即断できないのがこの技術の厄介なところです。MCP公式サイトは、対応クライアントとしてClaude・ChatGPTといったAIアシスタントに加え、Visual Studio Code・Cursorなどの開発ツールを挙げています。つまり全社的にMCPを採用した覚えがなくても、開発チームが日常的に使っているエディタが既に接続機能を備えている、という状態があり得ます。まずは各クライアントのMCP設定（接続先サーバの一覧）と、AIツールの利用申請・棚卸しの突き合わせから確認してください。

MCPサーバ側の実装品質については、MCPサーバの91.8%が認証を実装していないという調査を別記事で扱っています。今回はその手前、「安全性を測る物差し」の側の話です。

何が起きたのか：ラベルは終点ではない

論文はパキスタン・バーリア大学のRana Muhammad Ahmed氏とSabahat Abbas氏によるもので、保存済みのMCPエージェント評価キャンペーンを事後監査しています。監査の規模は次のとおりです。

項目 数値
追跡した実行レコード 10,200行
モデルに渡ったリクエスト 180件
意味的に区別されるリクエスト 45件
観測可能な刺激（実際の入力パターン） 15件
条件を伏せた再採点で訂正されたラベル 58件
再構成後に残った「攻撃成功」 0件

10,200行という数字が最終的に15種類の刺激まで縮むところが、まず目を引きます。実行ログの行数は、試された攻撃パターンの多様さをそのままは表していません。

そして計画されていた外部の攻撃ペイロード集は、実際には投入されていませんでした。それでも当時の集計には「攻撃成功」が並んでいた——ここが本題です。

なぜ挙動と無関係にラベルが付いたのか

原因は採点ロジックの構造にありました。当時の採点器は、ざっくり言えば「有用な完了ではない」かつ「投入面が汚染条件である」という2条件の積を取り、これが成立したときに限って攻撃成功クラスへ進む設計でした。後者は挙動の観測結果ではなく、その試行がどの実験条件に割り当てられたかというメタデータです。

この設計の帰結は2つあります。

  • 正常条件（CLEAN）の試行は、まったく同じ挙動をしても構造上「攻撃成功」になり得ない。
  • 逆に汚染条件のラベルが付いていれば、正規の作業を完了しただけでも攻撃成功側に落ちうる。

論文はこれを「treatment leakage（実験条件の漏れ込み）」と呼びます。測っているつもりのもの（攻撃が成功したか）と、実際に測れているもの（条件ラベルが何だったか）が食い違う、construct validity＝構成概念妥当性の問題です。

条件メタデータを見せずに採点し直した結果、攻撃成功または乗っ取り試行とされていた58件が「許可された正規の完了」に訂正され、確定版の集計に残った攻撃成功は0件になりました。

ただし「危険はなかった」ではない

ここは誤読されやすいので強調します。再採点後も保護対象データの移送が3件、権限のない転送が1件、実際に確認されたまま残っています。最後の1件は「目的を完了したと言えるか」という境界上の判断として、乗っ取り試行の分類が維持されました。

さらに、2名のレビュアーによる条件を伏せた一致性レビューでは、確定版が構造的に解釈可能と判断した96件について、レビュアー同士の結論は一致したものの、確定版のコード表とは4件で食い違いました。境界事例の判定は、条件漏れを直した後もなお揺れるということです。

つまりこの研究が示したのは「AIエージェントは攻撃されなかった」ではなく、「その評価キャンペーンの数字は、攻撃成功率としては読めない」という測定上の指摘です。著者自身、これは母集団の攻撃成功率でも、モデルの順位付けでも、防御策の有効性評価でも、因果推定でもない、と明記しています。

情シスの実務にどう効くか

AIエージェントやMCP連携の導入審査で、情シスの手元に来る材料はたいていベンダーの評価資料です。そこに載る「攻撃成功率◯%」「プロンプトインジェクションを◯%ブロック」といった数字を、この研究の視点で読み直すと、聞くべきことが具体化します。

  • 成功／失敗はどう定義され、何を見て判定していますか。——実際の出力や副作用の観測か、それとも試行の設定値か。
  • 採点する側は、その試行が攻撃条件かどうかを知っていますか。——知っているなら、その数字は挙動ではなく条件を反映している可能性があります。
  • 試したパターンは実質何種類ですか。——総試行回数ではなく、繰り返しを畳んだ後の刺激数を聞く。
  • 計画した攻撃データは全部投入されましたか。——本研究では計画された外部ペイロード集が未投入でした。
  • エラーや異常終了はどう扱いましたか。——除外していると、失敗が見えなくなります。

論文が提案する「Integrity Chain（完全性の連鎖）」は7つの確認点からなり、実務の質問リストとしてほぼそのまま使えます。要点は、投入した内容をハッシュで固定して実際にモデル入力に含まれたか検証すること、実行時の発火を管理上の割り当てとは別に記録すること、結果の判定は条件メタデータにアクセスせずに計算すること、そして構造的な失敗を「なかったこと」にせず結果として残すこと。著者らはこれを機械的に点検する簡易ツール（endpoint-integrity linter）も公開していますが、パイプラインをまたいだ追跡まではできないと限界を認めています。

現場目線：同じ穴は自社のログ設計にもある

この論文を読んで肝が冷えたのは、正直なところ研究の話としてではありませんでした。「観測した挙動」と「事前に付けた属性」を混ぜて判定するという欠陥は、自社の監視設計でごく普通に起きているからです。

たとえば、特定のセグメントや「リスクの高い部署」に属するというだけでアラートの重大度が上がる相関ルール。開発端末だからという理由で同じ通信が正常扱いになる除外設定。インシデント対応で「あの部署だから」と当たりを付けて調査範囲を決めてしまう、あの感覚。どれも、判定の入口に挙動ではなく属性ラベルが混ざっている点で構造は同じです。集計を出したときには、それらしい数字が並びます。実際には、自分たちが最初に付けた分類を読み返しているだけ、ということが起こり得ます。

限られた人員で回している運用ほど、この手のショートカットは効率化として正当化されがちです。全部を挙動ベースで見直すのは現実的ではありません。それでも、月次でレポートに載せている数字が一つでもあるなら、「これは何を見て数えているのか」を一度だけ辿ってみる価値はあります。属性で数えていたと分かるだけでも、その数字の使い方は変わります。

AIの判定を鵜呑みにする危うさという意味では、AIの確信度は信用できないという研究や、AIトリアージの保証が「何もしない」でも達成できてしまう研究とも通じる話です。攻撃側の実像についてはプロンプトインジェクションがSSRFに化ける研究、AIエージェントのメモリ干渉も併せてどうぞ。

この研究の限界（重要）

  • 査読前のプレプリントです。arXiv公開時点で査読を経ておらず、結論は今後変わりうります。
  • 単一キャンペーンの監査です。他の評価にも同じ欠陥があるとは示されていません。逆に「安全性評価は当てにならない」と一般化するのも誤りです。
  • 攻撃成功0件は、この監査対象の確定版集計での話です。MCPエージェントが安全だという意味ではありません。実際に保護対象データの移送は残っています。
  • 提示されたツールは静的な点検にとどまり、パイプラインをまたいだ由来の追跡はできません。

情シスはどうすべきか

AIエージェント導入の判断材料として、自前で長大な検証チェックリストを組むよりも、まず公的機関の整理を土台にするのが現実的です。IPAは「情報セキュリティ10大脅威 2026」で「AIの利用をめぐるサイバーリスク」を組織向け3位に挙げており、AI利用に伴う情報漏えいや、生成結果を検証せず鵜呑みにすることによる問題を脅威として位置づけています。

そのうえで情シスが足すべきは、技術的な設定よりも利用者への地道な啓発です。エージェントに何を繋いだかを申請ベースで把握し、「AIが自動でやってくれた作業の結果は検証が要る」という前提を現場に共有しておく。評価数値の読み方が変わっても、この部分の効き目は変わりません。

まとめ

  1. ベンダーのAIエージェント評価数値は「何を見て成功／失敗を決めたか」まで確認する。採点側が実験条件を知っていると、挙動ではなく条件を測った数字になりうる。
  2. 攻撃成功0件は安全の証明ではない。同じ監査で保護対象データの移送3件と権限外の転送1件は実在として残っている。
  3. 同じ欠陥は自社のアラート・レポート設計にもある。属性ラベルで数えている数字がないか、月次の指標を一つだけでも辿ってみる。

出典

タイトルとURLをコピーしました