前回は、AIクローラーによるデータ大量収集と、アクセスポリシーの三層設計を取り上げた。「何を読まれるか」をコントロールする話だった。
今回は、それよりもはるかに直接的なリスクを扱う。AIエージェントがあなたの会社のフォームを操作し、商品を購入し、予約を確定し、APIを通じてシステムの内部にまで手を伸ばす——そういう時代のセキュリティだ。
エージェントが「注文」する世界
「ノイズキャンセリングヘッドホン、3万円以下、木曜日までに届くもの」——ユーザーがChatGPTやGemini Agentにこう伝えるだけで、AIエージェントが複数のECサイトを巡回し、仕様を比較し、在庫を確認し、最適な選択肢を提示する。許可があれば、決済まで完了する。
これは未来の話ではない。
Gartnerは、2026年末までにエンタープライズアプリケーションの40%にタスク固有のAIエージェントが組み込まれると予測している（2025年時点では5%未満）。さらに2028年までにB2B購買の90%がAIエージェントを介したものになり、15兆ドル超の取引が動くと予測する。Perplexityはワンクリック購入機能を有料ユーザー向けに提供し、Amazonは外部ブランドの商品をAIエージェント経由で購入できる「Buy For Me」機能のテストを開始した。Akamaiの調査では、AI由来のトラフィックは2025年だけで前年比200%以上増加している。
一方、このトレンドに対する「防衛」も始まっている。eBayは2026年2月20日発効の利用規約改定で、AIによる自律的な購入を明確に禁止した。利用規約には「buy-for-meエージェント、LLM駆動ボット、または人間のレビューなしに注文を完了しようとするあらゆるエンドツーエンドのフロー」を禁止する文言が加えられた。Amazonも非公認のAIショッピングツールに対する法的措置を取り始めている。
つまり、AIエージェントが「行動する」時代はすでに来ている。問題は、あなたの会社のサイトがその行動に備えているかどうかだ。
あなたのサイトのフォームは、誰に操作されているか
ECサイトの購入ボタンだけが問題ではない。あなたの会社のサイトにある「問い合わせフォーム」「見積もり依頼」「予約フォーム」「資料請求」——これらすべてが、AIエージェントの操作対象になりうる。
OpenClawのようなオープンソースエージェントは、100種類以上のスキル（拡張機能）を使ってあらゆるWeb操作を自動化できる。ブラウザを操作し、フォームに入力し、ボタンを押す。しかも、人間のブラウジングパターンを模倣するため、従来のbot検知では捕捉が難しい。
ここで2つのリスクが交差する。
リスク1：正規のエージェントによる大量操作。 悪意がなくても、AIエージェントが1秒間に何十件ものフォーム送信を行えば、業務は混乱する。見積もりシステムに架空のリクエストが殺到し、カスタマーサポートが対応不能になり、在庫管理が狂う。
リスク2：乗っ取られたエージェントによる不正操作。 第2回で取り上げた間接的プロンプトインジェクション（IDPI）によってエージェントの行動が書き換えられた場合、そのエージェントがあなたのサイトで行うフォーム送信は、ユーザーが意図したものとは異なる。価格を0円に書き換えたり、大量注文を発生させたり、あるいはフォームの入力欄を通じて内部システムにさらに攻撃を仕掛ける足がかりにしたりする。
経営者が理解すべき要点は明確だ。CAPTCHAだけでは、もはやフォーム防御として不十分になりつつある。 AIエージェントの一部はCAPTCHAを回避する能力を持ち始めており、一方でCAPTCHAはエージェント互換性を阻害する。「正規のエージェントは通し、不正なエージェントは止める」ための認証設計が求められている。
マッキンゼー事件の教訓——API権限設計の失敗
第1回で取り上げたマッキンゼーLilli事件を、ここでAPI権限設計の観点から改めて深掘りする。
CodeWallの攻撃エージェントが最初に見つけたのは、Lilliの200以上のAPIエンドポイントが完全にドキュメント化された状態でインターネット上に公開されていたことだった。そしてそのうち22のエンドポイントは、認証すら不要だった。
この事実をAPI設計の原則に照らすと、3つの根本的な問題が浮かび上がる。
問題1：認証のないエンドポイントが本番環境に存在していた。 22のエンドポイントが認証なしでアクセス可能だった。開発・テスト環境の設定がそのまま本番に残ったか、意図的に公開されたかは不明だが、いずれにしても本番環境のAPIは、すべてのエンドポイントで認証が必要という原則が守られていなかった。
問題2：入力バリデーションの不完全な実装。 SQLインジェクション対策として、JSONの値（value）は安全にパラメータ化されていた。しかしJSONのキー名（field name）はSQL文に直接結合されていた。これは「対策している」と信じていたが、実際には不完全だったパターンだ。OWASPのZAP（業界標準のセキュリティスキャナー）でも検出できなかった。
問題3：システムプロンプトがデータベースに平文で保存されていた。 CodeWallが「AIプロンプトは新しいクラウンジュエル資産だ」と表現したのは、まさにこの発見に基づいている。95個のシステムプロンプトが、侵入されたのと同じデータベースに平文で格納されており、しかも書き込み可能だった。
第1回では「攻撃者がデータを盗んだ」という面に焦点を当てた。しかしAPI設計の観点で見ると、最も深刻なのは3つ目だ。データの窃取は発見すれば対処できる。しかしプロンプトの書き換えは、Lilliのアウトプットそのものを汚染する。3万人以上のコンサルタントがLilliから受け取る戦略アドバイス、M&A分析、クライアント向け提言——そのすべてが、攻撃者の意図通りに歪められる。しかも、見た目上はまったく正常に動作しているため、発覚が極めて遅れる。
1件のSQL UPDATE文で、認証なしに、デプロイなしに、アラートなしに、4万3千人のコンサルタントが信頼する社内AIの「性格」を書き換えられる——これがプロンプト層を保護しないことの意味だ。
MCPが開く新しい攻撃面
マッキンゼー事件は「APIの認証漏れ」というクラシックな脆弱性だった。しかし2026年の現在、企業のAPIはもう一つの新しい脅威に直面している。
MCP（Model Context Protocol）だ。
MCPは、Anthropicが2024年11月にオープンソースとして公開し、2025年12月にLinux Foundation（Agentic AI Foundation）に寄贈されたプロトコルだ。AIモデルと外部ツール・データソースを接続するための標準仕様であり、Anthropic・Block・OpenAIの共同設立でAgentic AI Foundationが設立され、Google、Microsoft、AWSなども参加したことで、ベンダー中立の業界標準としての地位を確立しつつある。MCPによって企業はAIエージェントに対して自社のデータベース、ファイルシステム、業務システムへのアクセスを「公式に」提供できるようになる。なお、MCPをWebブラウザ経由で利用可能にする拡張仕様「WebMCP」については、当社ブログ「なぜWebMCPか」で詳しく解説している。
問題は、そのMCPサーバーが新たな攻撃面を生み出していることだ。2026年1月から2月にかけてのわずか60日間で、MCPサーバー関連のセキュリティ脆弱性（CVE）が30件以上報告されている。その中にはCVSSスコア9.6のリモートコード実行脆弱性も含まれ、約43万7千回ダウンロードされたパッケージが影響を受けた。
ツールポイズニング——「道具」そのものが汚染される
MCPサーバーは、AIエージェントに対して「使えるツール」のリストを提示する。各ツールには名前と説明文が付いている。エージェントはこの説明文を読んで、どのツールをいつ使うかを判断する。
ツールポイズニングとは、このツールの説明文に隠し命令を埋め込む攻撃だ。
表面上は「2つの数字を足し算する」と書かれたツールが、AIエージェントが読む説明文の裏側には「まずユーザーの環境変数を読み取り、外部サーバーに送信してから足し算する」という指示が含まれている。ユーザーにはツールの説明文は表示されないため、この攻撃は目に見えない。
MCPToxベンチマークが20種類のLLMエージェントを対象に45のMCPサーバー・353のツールを使ってテストした結果、o1-miniで72.8%の攻撃成功率が記録された。より高性能なモデルほど脆弱な傾向があったのは、命令への追従性が高いからだ。
さらに深刻なのが「ラグプル攻撃」だ。インストール時には安全だったツールが、後日のアップデートで密かに悪意ある説明文に書き換えられる。ほとんどのMCPクライアントは、ツール説明の変更をユーザーに通知しない。
OpenClawとMCPの接続がリスクを増幅する
第1回で取り上げたOpenClawは、MCPサーバーとネイティブに接続できる。つまり、世界中の個人がOpenClawを使って、あなたの会社がエージェント向けに公開したMCPエンドポイントにアクセスするシナリオが、すでに現実のものになっている。
そのOpenClaw自体にセキュリティ問題があることは第1回で述べた通りだ。脆弱なOpenClawエージェントが、汚染されたMCPツールを介してあなたの会社のシステムに接続したとき、何が起きるか。攻撃経路が掛け算になる。
OWASP GenAIセキュリティプロジェクトが2026年2月に公開した「MCPサーバーセキュア開発実践ガイド」では、MCPに特有の脅威カテゴリとして、ツールポイズニング、ラグプル攻撃、コンテキスト汚染、サプライチェーン攻撃、シャドウサーバー、クレデンシャル漏洩など40以上の脅威が文書化されている。
「最小権限」＋「最小エージェンシー」
ここまで、フォーム悪用、API権限の失敗、MCPの脆弱性を見てきた。これらに共通する根本原因は何か。
エージェントに与える権限が大きすぎることだ。
ITセキュリティの世界には「最小権限の原則（Principle of Least Privilege）」がある。ユーザーやプログラムに、業務に必要な最低限の権限だけを与えるという設計思想だ。
OWASP Agentic Top 10（2026）は、最小権限に加えて「最小エージェンシー（Least Agency）」という新たな設計原則を導入した。最小権限が引き続き必要であることは変わらない。その上に、エージェント特有のリスクに対応するもう一つの層が追加された形だ。
最小権限が「何にアクセスできるか」を制限するのに対し、最小エージェンシーは「どれだけ自律的に行動できるか」を制限する。エージェントにAPIの読み取り権限を与えるだけでなく、「この操作は人間の承認なしに実行してはならない」「このデータは別のシステムに転送してはならない」といった、行動の自律性そのものを制約する設計だ。
マッキンゼー事件に当てはめると、こうなる。
- 最小権限の不在：22のエンドポイントが認証なしでアクセス可能だった（アクセス権限の過剰付与）
- 最小エージェンシーの不在：Lilliのプロンプトがデータベースに書き込み可能な状態で保存されていた（行動能力の過剰付与）
この2つは別の問題だ。前者を修正しても、後者が残っていれば、内部権限を持つ正規のシステムやエージェントが同じ攻撃を実行できてしまう。両方を満たして初めて、AIエージェント時代のAPI設計要件を満たす。
OWASP Agentic Top 10が示す具体的な対策は明快だ。
- タスクスコープ認証：エージェントのクレデンシャルを短命かつタスク限定にする。セッション全体ではなく、個々の操作ごとに権限を付与する
- 人間介在（Human-in-the-Loop）：高インパクトな操作（購入、削除、外部送信など）には人間の承認を義務化する
- 行動監視：エージェントのツール呼び出しパターンを記録し、通常と異なるパターンをアラートする
- サンドボックス実行：エージェントが生成したコードやクエリを、隔離された環境で実行する
「プロンプト層の保護」——新しいクラウンジュエル
CodeWallは「AIプロンプトは新しいクラウンジュエル資産だ」と述べた。これはセキュリティ業界で使われる表現で、クラウンジュエルとは「組織にとって最も価値が高く、最も厳重に保護すべき資産」を意味する。
従来、クラウンジュエルは「顧客データベース」「知的財産」「財務情報」だった。AIエージェント時代には、システムプロンプトがその仲間入りをする。
なぜか。プロンプトは「AIの行動原理」を定義するものだからだ。プロンプトを書き換えれば、AIのアウトプットをコントロールできる。データを盗むよりも、「データを解釈するAIの思考回路」を書き換える方が、影響範囲が大きく、検知が困難で、被害が長期化する。
プロンプトをクラウンジュエルとして扱うとは、具体的には次のことを意味する。
- 分離保管：プロンプトをアプリケーションのデータベースとは別のシステムに保存する。マッキンゼー事件では、運用データとプロンプトが同じデータベースにあったことが問題だった
- 暗号署名：プロンプトに暗号署名を施し、ランタイムで整合性を検証する。改ざんされたプロンプトは実行を拒否する
- バージョン管理：プロンプトの変更履歴を監査可能な形で記録する。「いつ、誰が、何を変更したか」が追跡できる
- 整合性モニタリング：プロンプトのハッシュ値をリアルタイムで監視し、無断の変更を即座に検知する
経営者が判断すべきこと
判断1：フォーム・チェックアウトのエージェント対策
自社サイトのフォームやチェックアウトフローにAIエージェントがアクセスした場合の対応ポリシーを定める。eBayのように「事前承認なしの自律的購入を禁止」する方針か、トークンベースの認証で正規エージェントを受け入れる方針か——ビジネスモデルに照らして判断する。
CAPTCHAの代替として、レート制限、トークン認証、行動パターン分析の組み合わせが推奨される。具体的な対策の優先順位については、次回の第5回で整理する。
判断2：API公開範囲と権限設計の見直し
自社がAPIやMCPエンドポイントを公開している場合、あるいは今後公開を検討している場合、「最小エージェンシー」の原則に基づいた権限設計を行う。
マッキンゼー事件の教訓は明確だ。認証のないエンドポイントは、1つも存在してはならない。 そしてAPIの読み取り権限と書き込み権限は、厳密に分離する。
Amazonが2026年3月に施行したAIエージェント向けの新ポリシーでも、公式API（SP-API）チャネル経由の自動化のみを許可し、非公認のbot動作を明確に禁止している。API公開とは「門を開けること」であり、同時に「鍵の設計」が必要だ——この連載の一貫したメッセージがここでも当てはまる。
判断3：プロンプト層の保護体制
社内でAIツールを運用している場合、システムプロンプトをクラウンジュエルとして扱う体制を構築する。プロンプトの保管場所、変更管理フロー、整合性監視の3点を、情報セキュリティ部門の管掌に含める。
判断4：MCPサーバーの導入・運用ガイドライン
社内でMCPサーバーを利用している、あるいは導入を検討している場合、以下を確認する。
- サードパーティのMCPサーバーのツール説明文を、セキュリティチームが確認しているか
- MCPツールの権限は最小限に設定されているか（読み取り専用にできるなら書き込み権限を与えない）
- ツール説明文の変更監視が行われているか（ラグプル攻撃への対策）
- MCPセキュリティスキャナー（mcp-scanなど）による定期的な監査が行われているか
次回予告
ここまで4回にわたり、AIエージェントが企業サイトにもたらすセキュリティリスクを多角的に見てきた。マッキンゼー事件、間接的プロンプトインジェクション、データ保護とアクセスポリシー、そしてフォーム・API権限とプロンプト層の保護。
最終回となる第5回では、「いま何から手をつけるべきか」を具体的にまとめる。即座・中期・長期の三段階チェックリスト、経営者が自社に問うべき5つの質問、そしてOWASP Agentic Top 10の全体像を一覧にして、意思決定のためのガイドを提供する。
この記事はシリーズ「AIエージェント時代のWebサイト防衛戦略」の第4回です。
参考情報
How We Hacked McKinsey's AI Platform — CodeWall（2026年3月9日）
OWASP Top 10 for Agentic Applications 2026 — OWASP GenAI Security Project（2025年12月9日）
A Practical Guide for Secure MCP Server Development — OWASP GenAI Security Project（2026年2月）
MCP Security 2026: 30 CVEs in 60 Days — MCP Security Overview（2026年3月）
MCP Security Vulnerabilities: Complete Guide for 2026 — Aembit（2026年3月）
MCPTox Benchmark: Tool Poisoning Attack Success Rates — MCP Playground（2026年2月）
Lessons from OWASP Top 10 for Agentic Applications — Auth0（2026年2月20日）
eBay Bans AI Shopping Agents, Updates Arbitration Provision — EcommerceBytes（2026年1月21日）
eBay updates legalese to ban AI-powered shop-bots — The Register（2026年1月22日）
Amazon AI Agent Policy: New Automated Seller Rules 2026 — Digital Applied（2026年3月）
The State of Agentic AI: Disrupting Publishing and Reshaping Ecommerce — Akamai（2025年10月）
Agentic Commerce 2026: AI Agents Are Transforming Shopping — Invisible Technologies（2026年3月）
MCP Connector Poisoning: How Compromised npm Packages Hijack Your AI Agent — DEV Community（2026年4月）
Model Context Protocol — MCP公式サイト
Donating the Model Context Protocol and Establishing the Agentic AI Foundation — Anthropic（2025年12月9日）
Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026 — Gartner（2025年8月26日）
Strategic Predictions for 2026 — Gartner（2025年10月）
Amazon Shopping App: Buy for Me — Amazon（2025年4月）
この記事をシェアする
