はじめに
本連載もいよいよ最終回です。第1回で「なぜ」を、第2回で技術構造を、第3回で実装手順を、第4回でSEO/GEOへのインパクトを解説してきました。
最終回のテーマはセキュリティと未来です。
WebMCPは、AIエージェントにWebサイトの「操作権」を部分的に委ねるプロトコルです。それだけに、セキュリティ設計は技術的な関心にとどまらず、経営判断に直結するテーマです。「どこまでAIに任せ、どこで人間が判断するか」——この線引きの設計が、WebMCP導入の成否を分けます。
本記事では、WebMCPのpermission-first設計の詳細、未解決の課題、そして2026年後半〜2027年のロードマップを整理し、「今、何をすべきか」を経営判断として提示します。
permission-first ― WebMCPのセキュリティ哲学
WebMCPの設計を貫く原則はpermission-first（許可優先）です。MarkTechPostの解説によれば、WebMCPは「AIエージェントがブラウザの仲介なしにツールを実行することは許されない」という前提で設計されています。
これは「便利さのために安全性を犠牲にしない」という強い設計思想であり、WebMCPをスクレイピングやRPA（Robotic Process Automation）と根本的に区別するものです。
ブラウザが「仲介者」である意味
従来のスクリーンスクレイピングでは、AIエージェントが直接Webサイトを操作します。Webサイト側には「今操作しているのがAIか人間か」を区別する手段がほとんどありません。
WebMCPでは、ブラウザが仲介者としてすべてのツール呼び出しを仲裁します。この仲介により、以下の制御が可能になります。
ユーザー確認の要求。ブラウザはツール実行前にユーザーに確認を求めることができます。第2回で解説したrequestUserInteraction()がこの仕組みの中核です。「AIがこのフライトを予約しようとしています。許可しますか？」というような確認ダイアログが、ブラウザレベルで表示されます。
ツールの性質に応じた制御。readOnlyHintアノテーションにより、読み取り専用ツールと書き込みツールを区別し、リスクレベルに応じた確認フローを適用できます。
エージェント起動の識別。Declarative APIのSubmitEvent.agentInvokedにより、フォーム送信がAIエージェント経由かどうかをサーバーサイドで判別できます。
ブラウザプラットフォームのセキュリティ境界
WebMCPは新しい独自のセキュリティモデルを構築するのではなく、ブラウザが20年以上かけて培ってきた既存のWebセキュリティモデルの上に構築されています。
Same-Origin Policy（同一オリジンポリシー）
ツールは登録されたオリジン（ドメイン）のセキュリティ境界を継承します。example.comで登録されたツールはexample.comのコンテキストでのみ動作し、other-site.comのデータにはアクセスできません。
これはWebセキュリティの最も基本的な原則であり、WebMCPでもそのまま適用されます。
Content Security Policy（CSP）
WebMCPのAPIはサイトのCSP設定を遵守します。たとえば、サイトのCSPがインラインスクリプトを禁止している場合、WebMCPツールもその制約の範囲内で動作します。
HTTPS必須
navigator.modelContextはセキュアコンテキストでのみ利用可能です。HTTPのサイトではAPIが存在しません。ローカル開発のlocalhostのみが例外として許可されます。
セッション継承
WebMCPツールはユーザーの既存ブラウザセッションを継承します。Bug0の解説によれば、ブラウザはユーザーの認証セッションを共有するため、エージェントが別途認証情報を持つ必要がありません。エージェントは、ユーザーが持っている権限の範囲でのみ操作を実行します。
未解決のセキュリティ課題
permission-firstの設計思想は堅牢ですが、WebMCPにはまだ解決されていないセキュリティ上の課題が存在します。Bug0の分析によれば、プロンプトインジェクション、ツールチェインによるデータ流出、破壊的操作の実行制御などのセキュリティ上の懸念は認識されているものの、完全には解決されていない段階にあるとされています。
プロンプトインジェクション
AIエージェントはtooldescriptionを読んでツールの使い方を判断します。もし悪意あるサイトが巧妙な説明文でエージェントを誘導し、意図しないツール呼び出しを引き起こすことができれば、セキュリティ上の脅威になります。
MCPのエコシステムでは、この種の攻撃はすでに報告されています。2025年4月、セキュリティ研究者のSimon Willisonは、MCPサーバーのツール説明文を操作することでLLMの行動を誘導できるプロンプトインジェクション脆弱性を指摘しました。Palo Alto Networksの分析でも、MCPサンプリングを通じた新たな攻撃ベクトルが報告されています。
WebMCPの場合、ツール定義はサイト側が管理するため、信頼できるサイトのツールであれば問題は軽減されます。しかし、ユーザーが悪意あるサイトを訪問した場合のリスクは残ります。
「Deadly Triad」（致命的な三つ組）
W3C仕様リポジトリのセキュリティ・プライバシー文書やMCP-Bプロジェクトのセキュリティ分析で特に懸念が示されているのが「Deadly Triad」シナリオです。AIエージェントが同時に複数のタブ——たとえば銀行サイト、メールクライアント、SNSアカウント——にアクセスしている場合、あるタブで取得した情報を別のタブのツールに渡すことで、意図しないデータ漏洩が発生するリスクがあります。
WebMCPのドメインレベル分離（Same-Origin Policy）と呼び出しごとの同意フローがこのリスクの緩和策として設計されていますが、エージェントが複数タブの情報を統合する能力を持つ以上、完全な防御は困難です。
マルチエージェント競合
2つのAIエージェントが同じページで同時に操作しようとした場合、互いのアクションを上書きするリスクがあります。Bug0によれば、Pointer Lock APIに類似したロックメカニズムが提案されていますが、現時点では仕様に含まれていません。
ツール公開のガバナンス設計
技術的なセキュリティ境界に加え、「何を公開し、何を公開しないか」というガバナンスの設計も重要です。
公開すべきでないもの
以下のような機能は、WebMCPツールとして公開すべきではありません。
管理者向け機能。ユーザー管理、権限設定、データベース操作など、管理者のみがアクセスすべき機能。これらはWebMCPツールとして登録しないことが最も確実な防御です。
機密情報を返すツール。エージェントのレスポンスにPII（個人を特定できる情報）やその他の機密データが含まれると、エージェントのログやコンテキストウィンドウを通じて情報が漏洩する可能性があります。awesome-webmcpリポジトリのセキュリティガイドラインでも、ツールのレスポンスに機密情報やPIIを含めることを避けるよう推奨されています。
不可逆で高リスクな操作。アカウント削除、大量データの一括操作など。これらはWebMCPで公開するにしても、requestUserInteraction()による二重確認に加え、サーバーサイドでの追加認証（再ログイン要求など）を組み合わせるべきです。
開発チーム向けガバナンスチェックリスト
第3回のStep 5で提示したチェックリストに加え、ガバナンスの観点から以下を確認してください。
- 公開ツールのリストは社内でレビュー・承認されているか
- ツールの追加・変更時にセキュリティレビューのプロセスが定義されているか
- エージェント経由のツール呼び出しログが監査可能な形で保存されているか
- ツール呼び出しのレート制限が実装されているか
- インシデント発生時のツール無効化手順が文書化されているか
ロードマップ ― 2026年後半〜2027年の見通し
WebMCPの今後の展開を、複数のソースから整理します。なお、以下はGoogleの公式発表に基づく確定事項と、業界の観測に基づく予測が混在しています。それぞれを明確に区別してお伝えします。
確認されている事実
W3Cコミュニティグループで仕様作業が進行中。WebMCPはW3C Web Machine Learningコミュニティグループでドラフト仕様として公開されています（2026年2月12日）。Declarative/Imperative両APIの更新議論やエディタの追加など、仕様策定作業は活発に進んでいます。一般論として、コミュニティグループ仕様がW3Cの正式標準プロセスに移行する場合には数ヶ月単位の時間がかかることが多いものの、WebMCP固有のタイムラインは現時点で未定です。
Microsoftが仕様の共同著者。Bug0の分析によれば、仕様の著者にはMicrosoft（Brandon Walderman、Leo Lee、Andrew Nolan）とGoogle（David Bokan、Khushal Sagar、Hannah Van Opstal）のエンジニアが名を連ねています。
Chrome安定版への搭載は未発表。2026年3月時点で、Googleは安定版のリリース時期を公式に発表していません。
業界の観測に基づく予測
Chrome安定版リリースは2026年後半が有力。VentureBeatをはじめとする業界観測者は、2026年後半のGoogle I/OまたはGoogle Cloud Nextでの正式発表を予想しています。
Microsoft Edgeの対応。Microsoftのエンジニアが仕様の共同著者となっていることから、業界ではEdge対応が有力視されています。ただし、2026年3月時点で公式な実装タイムラインは発表されていません。
Firefox / Safari。Mozilla（Firefox）とApple（Safari）はW3Cワーキンググループに参加していますが、実装のコミットメントやタイムラインは発表していません。W3Cでの正式標準化が進めば追随が見込まれますが、時期は不確定です。
仕様の今後の進化
現時点のWebMCP仕様には、将来的な拡張が複数検討されています。
ツールディスカバリー。現在、AIエージェントがサイトのツールを発見するにはそのページを訪問する必要があります。Bug0の解説では、「robots.txt登場前のSEO」に例えられています。将来的に.well-known/webmcpのようなマニフェストファイルが導入されれば、エージェントはページを開く前にどんなツールが利用可能かを知ることができるようになります。
非テキストデータの対応。現行の仕様はJSONレスポンスに焦点を当てていますが、画像やファイルなどのバイナリデータをどう扱うかは今後の課題です。
ツールバージョニング。ツール定義のセマンティックバージョニング（例：searchFlights@v2）により、エージェントが特定バージョンのツールを要求できる仕組みが検討されています。
批判的視点 ― 知っておくべき反論
バランスの取れた判断のために、WebMCPに対する批判的な視点も紹介しておきます。
「ブラウザ支配の強化」という指摘
セキュリティ研究者のGregory GolbergはDEBEDbで、WebMCPがブラウザ（すなわちChromium = Google + Microsoft）をすべてのAIエージェントとWebサイトの間の「ゲートキーパー」に据える構造を批判しています。すべてのエージェント-サイト間インタラクションがブラウザを経由する以上、ブラウザベンダーがインターネットの新しいチョークポイントを支配する可能性がある、という指摘です。
「HTMLフォームの再発明」という批判
同じくDEBEDbの記事では、WebMCPのDeclarative APIが「1993年から存在するHTMLフォームをAIエージェント向けに再発明しただけ」であり、既存のRESTアーキテクチャやHATEOAS原則で解決できる問題を新しいプロトコルで複雑にしている、という批判がなされています。
これらの批判をどう評価するか
いずれの批判も技術的に的を射ている部分があり、議論の価値があります。ブラウザ依存のリスクは、WebMCPがW3C標準として複数ブラウザに実装されることで緩和される可能性がありますが、現時点ではChromium系のみの実装であることは事実です。
一方で、HTMLフォームの「再発明」という批判に対しては、既存のフォームにtoolnameとtooldescriptionを追加するだけでAIエージェント対応になるという実装コストの低さが、まさにWebMCPの価値提案の核心であるとも言えます。完全に新しい技術ではなく、既存のWeb基盤に最小限のレイヤーを追加するアプローチだからこそ、実用的な採用が見込めるのです。
今、何をすべきか ― 段階的導入のアクションプラン
最後に、本連載全体の内容を踏まえた、経営判断としての推奨アクションを整理します。
今すぐ（2026年前半）
理解と実験のフェーズ
- 本連載を社内の技術チーム・マーケティングチームと共有し、WebMCPの概念を組織全体で理解する
- Chrome Canaryで第3回の手順に沿って実験環境を構築し、自社サイトの既存フォームをDeclarative APIで試験的にWebMCP対応にする
- Schema.orgの実装品質を棚卸しし、NLWeb対応も見据えた構造化データの強化を開始する
- llms.txt記事を参考に、llms.txtの設置を検討する
Chrome安定版リリース前後（2026年後半見込み）
準備と段階的公開のフェーズ
- 第3回のフェーズ分けに沿って、Phase 1（読み取り専用ツール）をステージング環境で公開
- Tool Contract設計のレビュー体制を構築し、tooldescriptionの品質を第4回の基準で最適化する
- ツール呼び出しログの記録・監視基盤を整備する
正式標準化後（2027年〜）
本格運用のフェーズ
- Phase 2（書き込みツール）→ Phase 3（トランザクションツール）へと段階的に拡大
- エージェント経由のコンバージョンを定量的に計測し、ROIを評価する
- NLWebとの統合も含めた、エージェンティックWebの全体戦略を策定する
シリーズ総括 — ピクセルからプロトコルへ、そしてその先へ
全5回にわたる「WebMCP：Webサイトがアクションを話す時代」シリーズを通じて、以下を解説してきました。
第1回では、AIエージェントがスクリーンショットと推測に頼る「ピクセルの時代」の限界と、WebMCPがそれをTool Contractに基づく「プロトコルの時代」に置き換えることを論じました。
第2回では、Declarative API（HTML属性追加）とImperative API（JavaScript）の2つの実装パスと、human-in-the-loopの設計思想を技術的に解説しました。
第3回では、Chrome Canaryのセットアップからツール棚卸し、実装、テスト・デバッグまでをハンズオン形式で示しました。
第4回では、WebMCPがSEO/GEOに与えるインパクト——「発見可能性」から「実行可能性」への拡張——を論じました。
そして本記事（第5回）では、permission-firstのセキュリティ設計、未解決の課題、ロードマップ、そして批判的視点を含めた全体像を提示しました。
WebMCPはまだ標準化の途上にあります。APIの仕様は変わるかもしれません。ブラウザのサポート状況は流動的です。しかし、Webサイトが「読まれるもの」から「使われるもの」へ進化する方向性は、もはや変わりません。Schema.orgが「コンテンツの意味」を、llms.txtが「サイトの全体像」を、WebMCPが「サイトの能力」を伝える。この三重のレイヤーが揃ったとき、Webサイトは人間にもAIにも最大限の価値を提供できる存在になります。
その準備を始めるのに、早すぎることはありません。
参考情報
Google Chrome Developers「WebMCP is available for early preview」（2026年2月10日）
W3C Web Machine Learning Community Group「WebMCP Specification」（2026年2月12日）
VentureBeat「Google Chrome ships WebMCP in early preview, turning every website into a structured tool for AI agents」（2026年2月12日）
MarkTechPost「Google AI Introduces the WebMCP to Enable Direct and Structured Website Interactions for New AI Agents」（2026年2月14日）
MCP-B Wiki「Known Security Issues With WebMCP」
Bug0「WebMCP just landed in Chrome 146」（2026年2月11日）
Patrick Brosset (Microsoft Edge)「WebMCP updates, clarifications, and next steps」（2026年2月23日）
A B Vijay Kumar「WebMCP: Agents are learning to browse better」（2026年2月）
Gregory Golberg (DEBEDb)「WebMCP: A Solution In Search of the Problem It Created」（2026年2月14日）
Simon Willison「Model Context Protocol has prompt injection security problems」（2025年4月9日）
Palo Alto Networks Unit 42「New Prompt Injection Attack Vectors Through MCP Sampling」（2025年12月）
innFactory AI Consulting「WebMCP: How the Proposed W3C Web Standard Revolutionizes AI Agents and Websites」（2026年2月）
GitHub「awesome-webmcp」
この記事は「WebMCP：Webサイトがアクションを話す時代」シリーズの最終回（第5回）です。
AI技術のビジネス活用やWebサイトのAIエージェント対応について、具体的なご相談はunTypeまでお気軽にお問い合わせください。
この記事をシェアする
