この連載では4回にわたり、AIエージェントが企業サイトにもたらすセキュリティリスクを多角的に見てきた。
第1回では、マッキンゼーのAIプラットフォーム「Lilli」がAIエージェントにわずか2時間で侵入された事件を取り上げ、問題の深刻さを示した。第2回では、サイトのコメント欄やフォームがAIエージェントへの攻撃の「踏み台」にされるリスクを解説した。第3回では、AIクローラーによるデータ大量収集と三層アクセスポリシーの設計を取り上げた。第4回では、フォーム操作・API権限・MCPの脆弱性と、「最小権限＋最小エージェンシー」の設計原則を論じた。
最終回となる今回は、「で、うちは何から手をつければいいのか」という問いに答える。
経営者が自社に問うべき5つの質問
具体的なアクションに入る前に、まず自社の現状を把握する必要がある。以下の5つの質問に、あなたは即座に答えられるだろうか。
質問1：自社サイトに今日、何種類のAIクローラーがアクセスしたか。
第3回で取り上げた通り、確認されているAIクローラーは226種類に上る。自社のアクセスログでAIクローラーのトラフィックを識別・計測できているか。できていなければ、守るべき対象の実態すら見えていない。
質問2：自社のrobots.txtは、AIクローラーに対して何を許可し、何を禁止しているか。
robots.txtが「設定して終わり」になっていないか。トレーニングクローラー、検索クローラー、ユーザー起動型エージェントの3カテゴリそれぞれに対する方針が明文化されているか。最後にrobots.txtを見直したのはいつか。
質問3：自社サイトのフォームやAPIに、AIエージェントがアクセスした場合の対応ポリシーがあるか。
問い合わせフォーム、見積もり依頼、予約フォームに対して、AIエージェントによる大量送信が発生した場合にどう対処するか。レート制限は設定されているか。CAPTCHAだけに頼っていないか。
質問4：社内でAIツールを導入している場合、システムプロンプトの管理体制はあるか。
マッキンゼー事件の最大の教訓は「プロンプト層の保護」だった。自社のAIツールのシステムプロンプトは、誰が管理し、どこに保管し、変更履歴は追跡されているか。
質問5：「AIエージェント対応」を担当する部門は明確か。
AIエージェント時代のセキュリティは、情報システム部門だけの課題ではない。マーケティング（アクセスポリシー）、法務（利用規約）、カスタマーサポート（フォーム防御）、経営企画（API公開戦略）が横断的に関わる。担当部門が不明確であれば、対策は進まない。
この5つの質問のうち、3つ以上に即座に答えられなければ、対策の優先度は「高」だ。
三段階チェックリスト
対策は一度にすべてを実行する必要はない。重要なのは、リスクの高いものから順に着手することだ。以下に、「即座（1〜2週間）」「中期（1〜3か月）」「長期（3〜6か月）」の三段階でチェックリストを示す。
即座に実行すべきこと（1〜2週間）
robots.txtの棚卸し。 現在のrobots.txtを確認し、主要なAIクローラー（GPTBot、ClaudeBot、Google-Extended、PerplexityBot等）に対する指示が明記されているか確認する。未設定であれば、第3回で解説した「トレーニングはブロック、検索は許可」の基本方針を検討し、設定する。
アクセスログのAIクローラー識別。 サーバーログでAIクローラーのUser-Agent文字列を検索し、どのクローラーがどの頻度でアクセスしているかを把握する。既存のアクセス解析ツールにAIクローラーのフィルタリング設定を追加する。
フォームのレート制限確認。 問い合わせフォーム、見積もり依頼フォーム等に、IP単位・セッション単位のレート制限が設定されているか確認する。未設定の場合、WAF（Web Application Firewall）やサーバー設定で基本的なレート制限を導入する。
公開APIの認証状況確認。 自社が外部向けにAPIを公開している場合、マッキンゼー事件の教訓に照らして、認証なしでアクセスできるエンドポイントが存在しないか確認する。開発環境の設定が本番に残っていないかも含めてチェックする。
中期的に取り組むべきこと（1〜3か月）
三層アクセスポリシーの設計。 robots.txt（第1層）、llms.txt（第2層）、利用規約（第3層）の三層構造を設計・実装する。llms.txtの導入により、AIエージェントに「読ませたい情報」を能動的に制御できるようになる。
利用規約のAIエージェント条項追加。 法務部門と連携し、AIエージェントによるアクセスに関する条項を利用規約に追加する。EU著作権指令やNYT vs. OpenAI訴訟の動向を踏まえた条項設計を行う。
UGCサニタイズの強化。 第2回で取り上げた間接的プロンプトインジェクション（IDPI）対策として、コメント欄、レビュー欄、フォーム入力のサニタイズ処理を見直す。不可視テキスト（白文字、フォントサイズ0、CSSでの非表示）の検出・除去フィルターを導入する。
偽装エージェント検知の導入。 正規のAIクローラーのIPアドレス範囲を公式ソースから取得し、DNSリバースルックアップまたはIP照合で偽装ボットを識別する仕組みを構築する。
AIツールのプロンプト管理体制構築。 社内でAIツールを運用している場合、システムプロンプトの保管場所を運用データベースから分離し、変更管理フロー（承認・バージョン管理・監査ログ）を整備する。
長期的に整備すべきこと（3〜6か月）
API/MCP権限設計の「最小エージェンシー」対応。 第4回で解説した「最小権限＋最小エージェンシー」の原則に基づき、API/MCPエンドポイントの権限設計を全面的に見直す。タスクスコープ認証（短命・限定的なクレデンシャル）、高リスク操作への人間承認フローを導入する。
エージェント行動監視基盤の構築。 AIエージェントによるアクセスパターンを継続的に監視する基盤を構築する。通常と異なるアクセスパターン（異常な速度、特定ページへの集中アクセス、通常のクロール順序と異なるパターン）をアラートする仕組みを整備する。
robots.txtの定期レビュー体制。 AIクローラーのUser-Agentは頻繁に変更・追加される。四半期ごとにrobots.txtをレビューし、新しいクローラーに対する指示を追加する運用体制を確立する。
web-bot-authプロトコルへの準備。 第3回で取り上げたCloudflare提案の暗号署名認証プロトコル「web-bot-auth」の標準化動向を追跡し、対応準備を進める。
OWASP Agentic Top 10——全体像
この連載を通じて何度も参照してきたOWASP Agentic Top 10（2026）の全10項目を、ここで一覧として整理する。100名以上のセキュリティ研究者が策定したこのフレームワークは、AIエージェントのセキュリティリスクを体系的に理解するための基準線となる。
ASI01：エージェント目標ハイジャック（Agent Goal Hijack）——攻撃者がエージェントの意思決定経路や目的を操作し、意図しない行動を取らせる。間接的プロンプトインジェクション（第2回で解説）がこの典型的な手口。
ASI02：ツールの悪用と搾取（Tool Misuse & Exploitation）——エージェントが正規のツールを安全でない方法で使用する。ツールの連鎖利用による意図しないデータ流出や、MCPのツールポイズニング（第4回で解説）が該当。
ASI03：アイデンティティと権限の悪用（Identity & Privilege Abuse）——エージェントがユーザーセッションや認証情報を継承・流用し、本来の権限を超えた操作を行う。マッキンゼー事件の認証なしエンドポイント（第1回・第4回で解説）はこの典型。
ASI04：エージェントサプライチェーン脆弱性（Agentic Supply Chain Vulnerabilities）——サードパーティのツール、MCPサーバー、プラグインが改ざんされ、エージェントの動作を汚染する。ラグプル攻撃やOpenClawのスキル汚染（第1回・第4回で解説）が該当。
ASI05：予期しないコード実行（Unexpected Code Execution）——エージェントが生成・実行するコードが攻撃者に制御され、リモートコード実行（RCE）に至る。
ASI06：メモリとコンテキストの汚染（Memory & Context Poisoning）——エージェントの長期記憶やRAGのデータストアに悪意あるデータが注入され、将来の判断を歪める。
ASI07：エージェント間通信の不備（Insecure Inter-Agent Communication）——マルチエージェント環境でのメッセージが認証・暗号化されておらず、偽装や改ざんが可能になる。
ASI08：連鎖的障害（Cascading Failures）——一つのエージェントの異常動作が、連携する他のエージェントやシステムに波及し、障害が拡大する。
ASI09：人間—エージェント信頼の悪用（Human-Agent Trust Exploitation）——エージェントの流暢な応答に人間が過度に信頼を寄せ、攻撃者がそれを利用して人間に危険な操作を承認させる。
ASI10：ローグエージェント（Rogue Agents）——エージェントが設計意図から逸脱し、制御不能な状態で自律的に行動する。OpenClawエージェントが勝手にマッチングサービスにプロフィールを作成した事件（第1回で解説）がこの兆候。
この連載で扱ったリスクとOWASP Agentic Top 10の対応関係は、上の図解に示した通りだ。ASI07〜ASI10はマルチエージェント環境で顕在化するリスクであり、今後AIエージェントの導入が進むにつれて、企業が直面する課題の第2波となる。
監査ログと可観測性——「見えないリスク」を見える化する
チェックリストやポリシーを整備しても、実際に何が起きているかが見えなければ、対策は機能しない。
OWASP Agentic Top 10が「最小エージェンシー」と並んで強調するもう一つの設計原則が「強力な可観測性（Strong Observability）」だ。エージェントが何をしているか、なぜそれをしているか、どのツールとアイデンティティを使っているかを、常に把握できる状態を維持する。
Webサイト運営者にとっての可観測性とは、具体的には以下を指す。
AIクローラーの識別と計測。 どのAIクローラーが、どのページに、どの頻度でアクセスしているかを継続的に記録する。異常なパターン（急激なアクセス増、特定ページへの集中、深夜の大量クロール）をアラートする。
フォーム送信の行動パターン分析。 フォーム送信のタイミング、入力速度、送信元IP、セッション特性を記録し、人間のパターンとbot/エージェントのパターンを区別する。
API呼び出しの監査ログ。 すべてのAPI呼び出しを、呼び出し元・操作内容・タイムスタンプ・成否とともに記録する。特に書き込み操作や権限変更操作は、即時アラートの対象とする。
robots.txt/llms.txtの遵守状況のモニタリング。 robots.txtでブロックしているにもかかわらずアクセスしてくるクローラーを検知し、対応する（IP範囲の照合、必要に応じたブロック）。
可観測性なしに最小エージェンシーを適用することは、「制限はかけたが、守られているか確認できない」状態を意味する。逆に、可観測性だけあっても最小エージェンシーがなければ、「エージェントの逸脱をリアルタイムで見ているが、止められない」状態になる。両方を揃えて初めて、実効性のあるセキュリティ体制が成立する。
自社の実践——unTypeのプロンプト保護設計
この連載で「プロンプトはクラウンジュエル資産だ」と繰り返し述べてきた以上、当社自身のAIツールがその原則を守れているかは当然問われるべきだ。
unTypeが提供するAIエージェント互換性診断のPro版は、AIモデルを使ってサイトの分析レポートを生成する。つまり、システムプロンプトが存在する。マッキンゼー事件を受けて、当社はこの診断ツールのプロンプト保護状況についてコードベースの実地検証を実施した。
結論を先に述べると、マッキンゼー事件と同型のリスクは構造的に発生しない設計になっている。以下、第4回で整理した「3つの失敗」に対応する形で、当社の設計判断を開示する。
マッキンゼーの失敗1（認証なしAPI）に対して。 当社のAI分析を実行するエンドポイントはすべてサーバーサイドで処理され、管理者認証（社内ドメイン制限）または決済完了（Stripe webhook検証）を経由しなければアクセスできない。無料版の診断はスコアリングのみを行い、AIモデルを呼び出さない。認証なしでプロンプトに触れる経路は存在しない。
マッキンゼーの失敗2（入力バリデーションの穴）に対して。 ユーザーがAIプロンプトに影響を与えられる経路は、業種選択（定義済みマスタリストからの選択のみ）とURL（スキーム・長さ・プライベートIP等のバリデーション済み）の2つに限定されている。診断チェック項目もすべてホワイトリスト変換を経由しており、フリーテキストがプロンプトに直接入ることはない。さらに、診断対象サイトからAIモデルに渡されるのはHTMLの全文ではなく、各ページのURL・タイトル・ディスクリプション・見出し・構造化データ型名などの抽出済みメタデータのみだ。攻撃者が仮に自サイトのtitleタグにプロンプトインジェクションを仕込んだとしても、影響範囲はその1件の診断結果に限定され、プロンプト本体は書き換わらず、他のユーザーに波及しない。
マッキンゼーの失敗3（プロンプトのDB平文保存）に対して。 当社のシステムプロンプトはデータベースには一切保存されていない。ソースコード内に定数として定義され、Gitでバージョン管理されている。変更するにはGitへのコミット、ビルド、デプロイという一連のプロセスが必要で、改変の痕跡が必ず残る。データベースに保存されるのはAIが生成した分析結果（出力）のみであり、プロンプト（入力の命令文）は保存されない。したがって、マッキンゼー事件の核心であった「SQLインジェクションでプロンプトを書き換える」という攻撃は、物理的に実行不可能だ。
また、AIモデルのAPIキーはサーバーサイドの環境変数としてのみ管理されており、クライアント側のコードには一切含まれない。漏洩経路がない設計になっている。
これはunTypeだけが特別な設計をしているわけではない。第4回で示したチェックリストの項目——プロンプトの分離保管、暗号署名、バージョン管理、整合性モニタリング——を実装に落とし込んだ結果にすぎない。自社のAIツールをお持ちの企業は、同様の観点でコードベースの検証を行うことを推奨する。
「互換性」と「セキュリティ」は表裏一体
この連載を貫いてきたメッセージを、最後にもう一度整理する。
AIエージェント時代のWebサイト戦略には、2つの方向性がある。
一つは「互換性の向上」——AIエージェントが自社サイトを正しく理解し、適切にアクセスし、取引できるように整備すること。llms.txt、構造化データ、MCP/APIの公開がこれに当たる。当社の「AIエージェントがあなたの会社と取引する日」シリーズで詳しく解説してきた世界だ。
もう一つが本連載で扱った「セキュリティ」——AIエージェントが自社サイトを悪用・搾取できないように防御すること。アクセスポリシー、フォーム防御、API権限設計、プロンプト保護がこれに当たる。
この2つは対立するものではない。門を開くなら、鍵の設計を同時に考える——これが、AIエージェント時代にWebサイトを運営するすべての企業に求められる姿勢だ。
互換性だけを追求すれば、攻撃面が広がる。セキュリティだけを追求すれば、AIエージェント経由の顧客接点やビジネスチャンスを失う。どちらか一方ではなく、両方を設計として統合することが、これからのWebサイト戦略の要件になる。
「備える」は「攻める」の前提条件
AIエージェント時代のWebサイトセキュリティは、「守り」の話に聞こえるかもしれない。しかし本質は逆だ。
セキュリティが整備されていなければ、AIエージェント向けにAPIを公開することも、llms.txtで情報を構造化することも、MCPサーバーを立てることも、リスクが大きすぎて踏み切れない。セキュリティは、AIエージェント時代の「攻めの戦略」を実行するための前提条件なのだ。
マッキンゼーの事例が示したように、世界最高水準のセキュリティ投資を行っている企業でさえ、AIエージェント時代の脅威には脆弱だった。しかし同時に、マッキンゼーが責任ある開示を受けてから24時間以内にパッチを適用した対応速度は、セキュリティ体制が整っている組織の底力でもある。
重要なのは、完璧なセキュリティを目指すことではない。現状を把握し、優先順位をつけ、一つずつ着手することだ。
この記事の冒頭で示した5つの質問から始めてほしい。もし3つ以上に答えられなかったなら、まず現状把握から手をつける必要がある。
この記事はシリーズ「AIエージェント時代のWebサイト防衛戦略」の最終回です。
参考情報
OWASP Top 10 for Agentic Applications 2026 — OWASP GenAI Security Project（2025年12月9日）
OWASP Top 10 for Agentic Applications – The Benchmark for Agentic Security — OWASP GenAI Security Blog（2025年12月9日）
Addressing the OWASP Top 10 Risks in Agentic AI with Microsoft Copilot Studio — Microsoft Security Blog（2026年3月30日）
OWASP Top 10 for Agentic Applications 2026 Is Here — Palo Alto Networks（2025年12月18日）
How We Hacked McKinsey's AI Platform — CodeWall（2026年3月9日）
A Practical Guide for Secure MCP Server Development — OWASP GenAI Security Project（2026年2月）
Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026 — Gartner（2025年8月26日）
llms.txt — 公式仕様
draft-meunier-web-bot-auth-architecture — IETF（web-bot-authプロトコル ドラフト）
この記事をシェアする
