AIエージェントが「ボタンを押す」時代は終わる — GoogleのWebMCPが変えること

AIエージェントにWebサイトを操作させる。2026年の今、その方法は基本的に「画面を見て、ボタンを探して、クリックする」だ。人間がやるのと同じことを、AIが画像認識とDOM解析で再現している。動くが、遅い。壊れやすい。サイトのデザインが変わったら動かなくなる。

Googleはこの力業を根本から変えようとしている。

Google I/O 2026で発表されたWebMCPは、Webサイト側がAIエージェントに「ここにこういう機能がある。こう呼び出せる」と構造化された情報を提供する仕組みだ。エージェントはもう画面をスクレイピングする必要がない。サイトが直接、機能のカタログを差し出す。

MCPとは何が違うのか

ここで混乱しやすいのが、既に普及しているMCP（Model Context Protocol）との関係だ。

MCPはAnthropicが提唱し、今やCursor、Claude Code、GitHub Copilotなど主要なAIツールが採用するプロトコル。ローカルやクラウドのサーバーを介して、AIモデルに外部ツールへのアクセスを提供する。

WebMCPは名前こそ似ているが、レイヤーが違う。

MCP: AIアプリケーション ↔ 外部ツール/データ（サーバー間通信） WebMCP: AIエージェント ↔ Webページ（ブラウザ内通信）

MCPは「AIに道具を渡す」仕組み。WebMCPは「Webサイトが自分自身を道具として公開する」仕組み。競合ではなく、補完関係にある。たとえばMCPサーバーがWebMCP対応サイトを発見し、そのツールを使う — という連携も想定されている。

具体的に何ができるのか

WebMCPに対応したサイトでは、開発者がJavaScript関数やHTMLフォーム要素に構造化されたアノテーションを付ける。すると、ブラウザ上のAIエージェントはそれを読み取り、「このサイトではフライト検索、ホテル予約、レビュー閲覧ができる」と理解する。

従来のアプローチとの違いを整理すると:

手法	動作原理	信頼性	速度
スクレイピング型	DOMを解析してUI要素を推測	低い（UI変更で破綻）	遅い
画面キャプチャ型	スクリーンショットから操作対象を認識	中程度	非常に遅い
WebMCP	サイトが機能を構造化して公開	高い（仕様に基づく）	速い

ExpediaはGoogle I/OでWebMCPツールをライブデモした。ShopifyとBooking.comもテスト中。正直、まだ対応サイトは少ないが、Google・Microsoft共同でW3C Web Machine Learning Community Groupで標準化を進めている。Chromeだけの話ではなくなる可能性が高い。

Chrome 149でオリジントライアル開始

2026年5月19日、GoogleはWebMCPをChrome 149のオリジントライアルとして公開すると発表した。開発者は今すぐChromeフラグでローカル開発ができ、オリジントライアルに参加すれば本番環境でもテスト可能になる。

GoogleChromeLabs/webmcp-toolsリポジトリには開発ユーティリティとデモが公開されており、WebMCP Model Context Tool Inspectorという拡張機能でツールが正しく公開されているか検証できる。

実装のイメージ

WebMCPの実装は2つの方法がある。

JavaScript API方式 — 関数として機能を登録する。検索APIやデータ取得など、バックエンド処理が必要な操作に向く。

HTML属性方式 — 既存のフォーム要素にアノテーションを追加する。連絡フォームや予約フォームなど、UIとして既に存在する操作に向く。

どちらの場合も、エージェントはユーザーの明示的な許可なしに操作を実行しない。「予約を確定しますか？」「このフォームを送信しますか？」とユーザーに確認を求める安全設計になっている。

何が実現するか

WebMCPが普及した世界を想像してみる。

「来月の京都出張を手配して」とAIに伝える。エージェントはExpediaのWebMCPツールでフライトを検索し、Booking.comのツールでホテルの候補を絞り、Instacartのツールで出発前日に必要な荷物の買い物を手配する。すべてブラウザ内で、各サイトが公開したAPIを直接呼び出す形で。スクリーンショットを撮って「このボタンっぽい」と推測する必要はない。

もう一つ。WebMCPはSEOならぬAEO（AI Engine Optimization）の入口になる。検索エンジン最適化の次は「AIエージェントに見つけてもらう最適化」が来る。WebMCPツールを公開しているサイトは、AIエージェントから優先的に利用される可能性がある。ECサイトやSaaS企業にとっては、無視できない話だ。

正直な評価

WebMCPのコンセプトは正しい。スクレイピングやスクリーンショット型の力業に比べ、はるかに堅牢で速い。Google・Microsoftが共同で標準化を進めている点も心強い。

ただし、課題もある。

サイト側が対応しないと何も始まらない。schema.orgがSEOのために普及したように、WebMCPもサイト運営者にインセンティブが必要だ。「AIエージェント経由の流入が増える」というインセンティブが現実化するには、まずエージェント側のユーザー数が臨界点に達する必要がある。鶏と卵の問題。

また、セキュリティの懸念もある。サイトが「何でもできるツール」を公開してしまうと、悪意あるエージェントに悪用されるリスクがある。Google側はユーザー許可の仕組みで対処しようとしているが、フィッシングサイトがWebMCPツールを偽装するケースなど、新たな攻撃ベクトルが生まれる可能性は否定できない。

開発者は今何をすべきか

まだ早期プレビュー段階なのでプロダクションに投入するタイミングではない。ただし以下は今から始めて損はない。

• Chrome for Developers公式ドキュメントを読む
• GoogleChromeLabs/webmcp-toolsのデモを動かす
• 自社サイトのどの機能をWebMCPツールとして公開できるか棚卸しする

MCPがAIアプリの「裏側」を標準化したように、WebMCPはAIエージェントの「表側」を標準化しようとしている。Webの構造が変わる話だ。少なくとも、schema.orgの時と同じ規模のインパクトはあると見ている。