AIエージェント／MCPのセキュリティ完全ガイド
「AIが自分で操作してくれる」便利さの裏で、いま“まったく新しい乗っ取り・情報漏えい”が起き始めています。
仕組みから攻撃の手口、個人と企業それぞれの守り方まで、ゼロからやさしく解説します。
📋 この記事の目次
「ChatGPTやClaudeに頼んだら、メールの下書きだけでなく送信まで自分でやってくれた」——2026年、AIはついに“答えるだけ”から“自分で手を動かす”段階に入りました。これを支えるのが MCP（Model Context Protocol） という仕組みです。とても便利な一方で、従来のウイルス対策やファイアウォールでは防げない、新しいタイプの攻撃が次々と報告されています。この記事では「専門用語ゼロ」から始めて、最後は企業の実務対策まで、一気に理解できるように解説します。
🔌 そもそも「AIエージェント」と「MCP」とは？
新しいリスクを理解する前に、まず“何がどうつながっているのか”をやさしく押さえましょう。
AIが「考える」だけでなく「手を動かす」時代へ
これまでのチャットAIは、質問に“答える”だけでした。これに対してAIエージェントとは、あなたの代わりに「メールを送る」「ファイルを整理する」「予約を取る」「プログラムを修正する」といった“操作”そのものを自分で実行するAIのことです。賢い秘書というより、あなたのパソコンやアカウントを実際に触れる助手に近い存在になりました。
では、AIはどうやって「外の世界」に手を伸ばすのでしょうか。AI本体（大規模言語モデル）は、本来は文章を生成するだけの“脳みそ”であって、GmailやGitHub、社内データベースに直接アクセスする手足を持っていません。そこで必要になるのが、AIと外部の道具（ツール）やデータをつなぐ“共通の接続規格”です。それが MCP（Model Context Protocol） です。
MCPは、2024年末にAnthropic（Claudeの開発元）が公開したオープンな規格で、2025年には主要なAI各社が相次いで採用し、2026年には“AI業界の事実上の標準”になりました。いまやAIエージェントを語るうえで避けて通れない土台です。
たとえるなら、MCPは「AI用のUSB-Cポート」
昔は周辺機器ごとにケーブルがバラバラでしたが、USB-Cで「挿せば使える」に統一されましたよね。MCPも同じで、これまでサービスごとにバラバラだったAIとの接続方法を1つの規格に統一しました。だからAIに次々と“道具”を挿して能力を拡張できる——その手軽さこそが、便利さとリスクの両方の源です。
🔧 MCPの基本構造（だれが・何を・どうつなぐ？）
もう一つ知っておきたいのが、MCPサーバーへの“つなぎ方”が2種類あることです。これは後半のセキュリティ対策に直結します。
Stdio（標準入出力）
主に自分のPCの中だけで動く
AIアプリとMCPサーバーが同じパソコンの中で会話する方式。ネットを経由しないため攻撃者が外から直接触りにくく、個人利用や開発でよく使われます。
Streamable HTTP
ネット越しにつなぐ
MCPサーバーをネットワーク上に公開して、複数人やクラウドから使う方式。便利な反面、認証を付け忘れると“誰でもアクセスできる窓口”になり、非常に危険です。本番運用では認証必須。
🧠 なぜ“危険の種類”が根本から変わったのか
「AIだから危ない」のではありません。危険の“構造”が、これまでのソフトと決定的に違うのです。
判断する場所が「設計時」から「実行時」へ移った
従来のソフトは、何をするかを人間が事前にプログラムで固定していました。動きは予測でき、テストもできます。ところがAIエージェントは、何をするかを“その場でAIが推論して決める”のです。同じ指示でも、読んだデータ次第で行動が変わる——ここが全ての新しいリスクの根っこです。
さらに重要なのが、AI（言語モデル）には「読んだ文章を“指示”として素直に受け取ってしまう」性質があることです。AIにとって、あなたが打ち込んだ命令も、Webページに書かれた文章も、メールの本文も、ツールが返してきたデータも、すべて同じ“文字の並び”です。人間なら「これは広告」「これは指示」と区別できますが、AIはこの境界があいまいなのです。
その結果、悪意のある人がAIが読むデータの中に“こっそり命令”を仕込むと、AIはそれを「ユーザーからの正規の指示」と区別できずに実行してしまう。これが、次章で説明するあらゆる攻撃の共通メカニズムです。
📊 従来のアプリ vs AIエージェント（何が違う？）
キーワードは「信頼できる指示」と「外から来たデータ」の混同
AIはこの2つを見分けるのが苦手です。これが“プロンプトインジェクション”の本質。仕組みの基礎は プロンプトインジェクションの仕組みと対策 でも詳しく解説しています。
🕷️ AIエージェント／MCPの新しい攻撃面7つ
2025〜2026年に実際に研究・報告された、代表的な攻撃の手口を1つずつ見ていきましょう。
ここからが本題です。少し専門的になりますが、「AI自身は悪くないのに、“読んだもの”や“挿した道具”に操られてしまう」という共通点さえ押さえれば、どれも同じ家族の攻撃だと分かります。まず、最も基本となる間接プロンプトインジェクションの攻撃の流れを図で見てみましょう。
🎯 攻撃の流れ：間接プロンプトインジェクション
この基本形を踏まえて、AIエージェント／MCPで特に警戒されている7つの攻撃面を整理します。
間接プロンプトインジェクション
Indirect Prompt Injection
上の図のとおり、AIが読み込む外部データ（Web・メール・PDF・ツールの返り値）に“見えない命令”を仕込む手口。ユーザーは普通の作業を頼んだだけなのに、AIが攻撃者の指示を実行します。
ツールポイズニング
Tool Poisoning
MCPサーバーが提供する“道具の説明文（メタデータ）”の中に悪意ある命令を隠す手口。説明文はAIには見えますが、人間の画面には表示されないことが多く気づけません。2025年に研究者(Invariant Labs)が実証しました。
過剰な権限・混乱した代理
Excessive Agency / Confused Deputy
「念のため全部の権限を渡しておこう」で動くエージェントは危険。攻撃者は強い権限を持つAIを“代理人”として悪用し、本来許されない操作（削除・送金・公開）を肩代わりさせます。
認証情報・トークンの漏えい
Credential / Token Leakage
MCPサーバーは、つないだサービスのOAuthトークン・APIキー・パスワードを預かります。これがログに残ったり、別のサーバーへ送られたり、盗まれたりするとアカウントごと乗っ取られます。
悪意ある／野良MCPサーバー
Malicious & Shadow MCP
出所不明のMCPサーバーを入れるのは、知らない人にPCとアカウントの合鍵を渡すのと同じ。2026年にはGitHub・WhatsApp向けなど人気実装でも脆弱性が報告。組織が把握しない“野良サーバー（Shadow MCP）”の増殖も深刻です。
ツール結果経由のデータ持ち出し
Data Exfiltration
「秘密の情報をURLの末尾に付けて画像を読み込ませる」など、正規の機能を悪用して機密を外部へこっそり送り出す手口。一見ただの画像表示でも、裏でデータが流出していることがあります。
Sampling悪用など仕様の穴
Spec-level Design Flaws
2026年初頭、Palo Alto Networksの研究者が、MCPの「Sampling（サンプリング）」機構を悪用してクライアント側のフィルタを迂回し、AI本体に命令を注入できると指摘。“バグ”ではなく“設計上の穴”が核心だと警告されています。
7つの攻撃すべてに共通するのは「AI自身は悪意ゼロなのに、“読んだ文章”や“挿した道具”に操られてしまう」という点です。だからこそ、ウイルスを見つける従来型の対策だけでは防げません。「何を読ませるか」「どんな権限を与えるか」「最後に人間が確認するか」という、新しい観点の防御が必要になります。
📊 従来のサイバー攻撃 vs AIエージェント時代の攻撃
| 観点 | 従来型の攻撃 | AIエージェント時代の攻撃 |
|---|---|---|
| 主な侵入口 | 不正な添付・偽サイト・脆弱性 | AIに読ませた“正規データ”の中の隠し命令 |
| 狙われるもの | PC・サーバーそのもの | AIの“判断”と、AIが持つ権限・トークン |
| ユーザーの自覚 | 怪しいものを開いた自覚がある程度残る | 普通の作業を頼んだだけ＝ほぼ無自覚 |
| 気づきやすさ | ||
| 有効な対策 | ウイルス対策・FW・更新 | 最小権限・人間承認・ログ監視・入力検証 |
※「気づきやすさ」は相対的なイメージ。数値が低いほど被害に気づきにくいことを表します。
🛡️ 個人ユーザーの守り方（5つの鉄則）
「自分はエンジニアじゃないから関係ない」——いいえ。ChatGPTやClaudeに“道具”を挿す人すべてに関係します。
「便利そうだから」で道具を挿さない
AIエージェントの拡張（MCPサーバーやプラグイン）は、誰でも作って公開できます。つまり“便利な皮をかぶった悪意の道具”も混ざり得るということ。難しい設定は不要です。次の5つを習慣にするだけで、リスクの大半を避けられます。
🏷️ 信頼できる提供元の道具だけを使う
公式・大手・実績あるオープンソースのMCPサーバーに限定。「個人が作った出所不明の便利ツール」は安易に挿さない。導入前に“誰が作っているか”を必ず確認しましょう。
🔑 つなぐアカウントは“最小限”に
ネット銀行・メインのメール・SNSの本アカウントを、いきなりAIエージェントに連携しない。試すときは“失っても困らない”サブ環境から。重要アカウントほど慎重に。
✋ “自動実行”より“人間が承認”
送信・削除・購入・送金・公開など取り返しのつかない操作は、必ず確認ダイアログを挟む設定に。「全部おまかせ（自動承認）」は便利ですが、罠にかかったとき止められません。
👀 AIが“何をしたか”を見る癖をつける
実行ログや操作履歴をときどき確認。「頼んでいない外部送信」「見覚えのない宛先」がないか。少しでも違和感があれば連携を止めて調べる。
🧹 連携・権限を定期的に棚卸しする
使わなくなった拡張やアカウント連携は外す。半年に一度は“何を許可しているか”を見直し、不要な権限を減らしておく。これだけで攻撃の入り口が大きく減ります。
✅ やってよいこと
- 公式ストア・公式提供のMCPを使う
- 重要操作は“都度承認”に設定
- サブアカウントで先に試す
- 履歴・権限を定期チェック
🚫 避けたいこと
- 出所不明の“神ツール”を挿す
- 全操作を自動承認にする
- 本命の銀行・メールをすぐ連携
- 怪しいページを“要約して”と丸投げ
AIエージェントに“外部の文章を読ませて、そのまま操作までさせる”使い方は最も危険なパターンです。読ませたWebページやPDFに隠し命令が仕込まれていると、要約のつもりが裏で別の操作を実行してしまうことがあります。外部データを扱わせるときほど、操作の自動化はオフにしておきましょう。
個人の合言葉は「最小権限」と「人間が最後に確認」
この2つさえ意識すれば、専門知識がなくても被害の大半は防げます。AIに関する基本リスクは ローカルAI「Ollama」の意外なセキュリティリスク や AI利用と情報漏えいのリスク もあわせてどうぞ。
🏢 企業・開発者の守り方（設計でガードする）
MCPは“新しい攻撃面”そのもの。運用で頑張るより、設計段階で危険を封じ込めるのが王道です。
「設計時に決め打ちできない」前提で守る
従来は「何をするか」を設計時に固定できました。AIエージェントはそれができません。だからこそ「権限を最小化する（被害の上限を下げる）」と「実行時を監視する（異常を捉える）」の二本柱が対策の中心になります。以下は実務でそのまま使えるチェックリストです。
🔒 最小権限の原則（Least Privilege）
ツール定義・スコープは必要最小限に。読み取りで済むなら書き込み権限は与えない。1つのエージェントに全権を集中させない。万一乗っ取られても被害の上限を下げられます。
🪪 認証を必須にする
MCPサーバーには OAuth 2.0 / APIキー などの認証を強制。匿名アクセスは禁止。リモート公開（Streamable HTTP）なら認証は“あって当然”、無くてはならない命綱です。
🧪 入力とメタデータを厳格に検証
入力は JSON Schema などで厳密にバリデーション。さらに“ツールの説明文（メタデータ）”もクライアント側で検証・可視化し、ツールポイズニングを防ぐ。MCPの仕様はクライアント側検証を必須にしていないため、ここは自衛が必要です。
📦 サーバーの出所確認＆バージョン固定（pin）
サードパーティのMCPサーバーはソースを確認し、信頼できるレジストリから導入。バージョンを固定して“勝手な自動更新で悪性コードが紛れ込む”サプライチェーン攻撃を防ぐ。野良サーバー（Shadow MCP）は棚卸しで検出・排除。
🌐 公開範囲を必ず確認する
本番は認証付きStreamable HTTP、ローカル開発はStdio。「うっかり全世界に公開」を避ける。これはローカルLLMの定番事故と同根です（参考：Ollamaのポート公開リスク）。
👤 高リスク操作は人間承認＋ログ監視
送金・削除・外部送信などは Human-in-the-loop（人間の承認） を必須に。エージェントの行動はすべてログ化し、“ふだんと違う動き”（大量送信・想定外の宛先）を異常検知する。
📊 接続方式の使い分け（Stdio vs Streamable HTTP）
| 項目 | 💻 Stdio（ローカル） | 🌐 Streamable HTTP（リモート） |
|---|---|---|
| 主な用途 | 個人利用・開発・検証 | チーム・本番・クラウド共有 |
| 外部公開 | 原則なし（PC内で完結） | あり（だから認証が必須） |
| 認証 | OSのユーザー権限に依存 | OAuth/APIキーを必ず付与 |
| 外部攻撃の受けやすさ | ||
| 鉄則 | 不要に外部公開しない | 認証なしで公開しない |
🛡️ 多層防御のイメージ（被害の上限を下げ、異常を捉える）
「設計時に静的に決め打ちできない」のがAIエージェントの本質。だからこそ“権限の最小化”と“実行時の監視”が二本柱です。さらに、業界標準のフレームワーク——OWASP Top 10 for LLM Applications、OWASP の Agentic / MCP 系セキュリティ標準、NIST AI RMF（AIリスク管理フレームワーク）、MITRE ATLAS（AIへの攻撃手法の体系）——を基準に自社のチェックリストを整備すると、抜け漏れを大きく減らせます。
🎯 まとめ：これだけは押さえる
最後に、この記事の要点を“持ち帰れる形”でまとめます。
MCPとは
AIと外部の道具をつなぐ“共通プラグ”。便利さの源でありリスクの源
何が新しい？
AIが“読んだ文章”を指示と誤認。設計時でなく実行時に行動が決まる
主な攻撃
プロンプトインジェクション／ツールポイズニング／権限悪用／鍵流出
個人の鉄則
信頼できる道具だけ・最小限の連携・人間が最後に承認
企業の鉄則
最小権限＋認証＋入力検証＋出所確認＋人間承認＋ログ監視
基準にする
OWASP（LLM/Agent）・NIST AI RMF・MITRE ATLAS
3行で言うと
① AIエージェントは“読んだもの”に操られる、まったく新しいリスクを持つ。② 個人は「信頼できる道具・最小限の連携・人間の承認」。③ 企業は「最小権限と実行時監視」を二本柱に、OWASP/NIST/MITREを基準にする。
□ 出所が信頼できるMCPサーバー／拡張だけを使っている
□ 重要な操作（送金・削除・送信・公開）は人間の承認を挟んでいる
□ AIに与えた権限・連携アカウントを最小限にしている
□ （企業）認証・入力検証・バージョン固定・ログ監視を実装している
□ AIの実行履歴を定期的に確認している
📚 出典・参考（信頼できる一次情報）
- Anthropic「Model Context Protocol」公式ドキュメント — modelcontextprotocol.io
- OWASP Top 10 for LLM Applications（プロンプトインジェクション＝最重要リスク） — owasp.org
- MITRE ATLAS（AIシステムへの攻撃手法の体系） — atlas.mitre.org
- NIST AI Risk Management Framework（AI RMF） — nist.gov
- IPA 情報処理推進機構 — ipa.go.jp ／ JPCERT/CC — jpcert.or.jp
- ツールポイズニングの実証（Invariant Labs, 2025年）、MCP脆弱性の脅威モデリング研究（arXiv, 2026年）、Sampling機構の悪用に関する Palo Alto Networks の報告（2026年初頭）、日経xTECH・NRIセキュア等のMCPセキュリティ解説
コメント