2026年2月10日、Google Chromeチームがひっそりと公開したブログ記事が、Web業界を揺るがしている。
「WebMCP」——Web Model Context Protocolと名づけられたこの新標準は、AIエージェントがWebサイトを操作する方法を根本から変える。スクリーンショットを撮ってボタンの位置を推測する時代は、終わりに向かっている。
Chrome 146 Canaryのフィーチャーフラグに隠されたこの機能は、GoogleとMicrosoftのエンジニアが共同開発し、W3CのWeb Machine Learningコミュニティグループで標準化が進められている。Chrome限定の実験ではない。ブラウザレベルのオープン標準だ。
SEOの世界では、著名な技術SEO専門家ダン・ペトロヴィッチ（DEJAN）が「構造化データ以来、最大のテクニカルSEOの転換点」と評した。大げさに聞こえるかもしれないが、中身を見ると、その表現が妥当に思えてくる。
—
AIエージェントはいま、Webサイトで何に苦しんでいるのか
現在のAIエージェントがWebサイトを操作する方法は、大きく分けて2つある。どちらも、正直なところ「力技」だ。
スクリーンショット方式では、ページの画面をキャプチャし、マルチモーダルモデル（ClaudeやGeminiなど）に「このボタンはどこか？」「この入力欄は何用か？」と画像ごと推論させる。1回のキャプチャで数千トークンを消費し、レイテンシも大きい。
DOM解析方式では、生のHTMLとJavaScriptを丸ごと取り込む。CSSルール、装飾用のdivタグ、本来エージェントには不要な構造情報がコンテキストウィンドウを圧迫し、推論コストを押し上げる。
どちらの場合も、エージェントは「人間の目のために作られたUI」と「モデルが必要とする構造化データ」の間で翻訳作業を強いられている。人間なら数秒で終わる商品検索が、エージェントだとフィルター操作・ページスクロール・結果の解析と、数十回のAPI呼び出しに化ける。
企業にとっての問題は明確だ。コストが高く、壊れやすい。サイトのデザインをちょっと変えただけで、エージェントの動作が止まる。
—
WebMCPの仕組み——2つのAPIが実現すること
WebMCPは、ブラウザに新しいAPI「navigator.modelContext」を追加する。このAPIを通じて、Webサイトは自分の機能を「ツール」としてAIエージェントに公開できる。
Declarative API（宣言型・HTML連携）
すでにHTMLフォームが整備されているサイト向けの軽量オプション。既存のフォームタグにtoolnameとtooldescription属性を追加するだけで、ブラウザがそのフォームをエージェントが呼び出せるツールに変換する。
たとえばレストラン予約フォームなら、こんな具合だ。フォームのHTMLに2行の属性を加えれば、AIエージェントがそのフォームを発見し、構造を理解し、必要なパラメータを埋めて送信できる。
エージェントがツールを呼び出すと、ブラウザがフォームにフォーカスを移し、フィールドを視覚的に埋め、ユーザーの確認を待つ。自動送信を有効にしない限り、人間のチェックが入る設計だ。
Imperative API（命令型・JavaScript連携）
より複雑な動的処理が必要な場合はこちら。navigator.modelContext.registerTool()で、ツール名・説明文・入力スキーマ（JSON Schema）・実行関数を登録する。
たとえばECサイトなら、searchProducts(query, filters)というツールを公開できる。エージェントはフィルターのドロップダウンをクリックして→スクロールして→結果をスクリーンショットして……という手順を踏む必要がなくなる。1回の構造化された関数呼び出しで、構造化されたJSON結果を受け取れる。
ページの状態に応じてツールを動的に登録・解除できるのも強力だ。カートに商品がある時だけチェックアウトツールが出現し、日付選択後にだけ予約ツールが現れる。エージェントは常に「今のコンテキストで使えるもの」だけを見る。
—
従来のMCPとの違いを整理する
「MCP」という名前を聞いて、Anthropicが提唱したModel Context Protocol（MCP）を思い浮かべた人も多いだろう。両者は補完関係にあり、競合ではない。
| 項目 | 従来のMCP（Anthropic発） | WebMCP（Google/Microsoft発） |
|---|---|---|
| 動作場所 | サーバーサイド（JSON-RPC） | ブラウザタブ内 |
| 認証 | 別途セットアップが必要 | ブラウザのセッション（SSO・Cookie）を継承 |
| 最適な用途 | バックエンドAPI操作 | Web UI操作 |
| ページ状態へのアクセス | なし | あり（フルアクセス） |
| 対象範囲 | ツール・リソース・プロンプト | ツールのみ（現時点） |
| ステータス | 広く普及 | 早期プレビュー（Chrome 146） |
重要なのは、WebMCPはモデルに依存しない点だ。Gemini専用ではない。Claude、GPT、オープンソースモデル——ブラウザ上で動作するあらゆるエージェントがWebMCPのツールを使える。デモ拡張機能はGemini 2.5 Flash APIを使っているが、標準自体は特定のモデルに縛られていない。
—
企業サイトへの影響——3つの実務的インパクト
1. コスト削減が数字で見える
スクリーンショット→マルチモーダル推論→反復的DOM解析、というチェーンが1回のツール呼び出しに集約される。トークン消費量の大幅な削減が見込める。航空券予約のような複雑なタスクでは、従来数十回必要だったエージェントのインタラクションが1〜2回で済むケースも出てくる。
2. 壊れなくなる
サイトが「ここにこの関数がある。パラメータはこれ。戻り値はこう」と明示的に宣言するため、UI変更やダイナミックコンテンツの読み込みタイミングに左右されない。デザインリニューアルのたびにエージェントが動かなくなる問題が解消に向かう。
3. 既存の資産がそのまま使える
WebMCPの仕様は、「ユーザーがUIで実行できるタスクは、そのページの既存JavaScriptコードの多くを再利用してツール化できる」と明記している。新しいサーバーフレームワークを学ぶ必要も、エージェント用の別APIを構築する必要もない。フロントエンド開発者が既存のコードベースをそのまま活かせる。
—
テクニカルSEOの地殻変動が始まる
ここからが、日本の企業サイト担当者にとって最も重要な話だ。
思い出してほしい。検索エンジンが構造化データを理解し始めた時、何が起きたか。sitemap.xml、robots.txt、canonical、schema.org——Webサイトをクローラーに「読める」ようにする技術群が、テクニカルSEOという専門領域を生んだ。
WebMCPは、同じパラダイムシフトのAIエージェント版だ。
ツールの発見可能性は、新しいインデックス問題になる。現時点では、エージェントがどのサイトにWebMCPツールがあるかを事前に知る方法がない。WebMCPの仕様書自体がこれを「未解決の制約」と認めている。検索エンジンやディレクトリがこのギャップを埋める可能性が示唆されており、その発見レイヤーが登場した時、そこへの最適化が新たな専門分野になる。
ツールの説明文は、新しいメタディスクリプションだ。ツールの名前、説明、スキーマの品質が、エージェントがそのツールを選ぶかどうかを直接決める。仕様書のベストプラクティスには「明確な動詞を使え」「オプションの理由を説明しろ」「肯定的な表現を優先しろ」と、まるでコンバージョンコピーライティングのガイドラインのような記述が並ぶ。ただし読者はLLMだ。
AIエージェント経由のコンバージョン最適化も登場する。Chrome拡張機能のツールインスペクターは、すでにLLMでツールをテストし、正しく呼び出されるかを検証する機能を持っている。A/Bテストの対象が「人間のクリック」から「エージェントのツール呼び出し」に広がる日は近い。
AIエージェント対応のWebサイト最適化について詳しくは、AIO対策とは？AI Overview最適化の実践ガイドもあわせてご覧ください。
—
「Human-in-the-loop」が設計の中心にある理由
WebMCPには、もう1つ見逃せない設計思想がある。完全自律のエージェントを想定していない点だ。
仕様書は明確に3つの柱を掲げている。
- Context（文脈）：エージェントがユーザーの行動を理解するためのデータ。画面に見えていないコンテンツも含む
- Capabilities（能力）：エージェントがユーザーに代わって実行できるアクション。フォーム入力から質問回答まで
- Coordination（協調）：エージェントが自力で解決できない状況に直面した時の、ユーザーへの引き渡し管理
ヘッドレスブラウジングや完全自律シナリオは「非目標」と明記されている。それらのユースケースにはGoogleのAgent-to-Agent（A2A）プロトコルなど別の仕組みがある。
企業のIT部門にとって、これは朗報だ。AIエージェントが従業員の承認なしに重要なアクションを実行するリスクが、プロトコルレベルで抑制されている。AIエージェントのガバナンスについては、AIエージェントに社員証を発行する時代｜MS Zero Trust for AIも参考になるだろう。
—
いま企業のWeb担当者がやるべき3つのこと
WebMCPの正式リリースは2026年中盤〜後半と見られている。だが準備は今日から始められる。
1. 自社サイトのフォーム品質を棚卸しする
WebMCPのDeclarative APIは、きれいなHTMLフォームがあれば8割方対応できるとSemrushの解説記事が指摘している。ラベルが明確で、入力形式が予測可能で、送信後のリダイレクトが安定しているか。テクニカルSEOの基礎として取り組んできたことが、そのままWebMCP対応の下地になる。
2. 主要なユーザーアクションを「ツール」として言語化する
自社サイトでユーザーが行う主要なアクション——商品検索、問い合わせ送信、見積もり依頼、予約——を洗い出し、それぞれに名前・説明・パラメータをつけてみる。実装はまだ先でも、この「ツール設計」の思考訓練は、WebMCPが来た時に差をつける。
3. Chrome 146 Canaryのフラグで試す
Chrome 146 Canaryをインストールし、chrome://flagsで「WebMCP for testing」フラグを有効にすれば、今すぐプロトタイプを作れる。Model Context Tool Inspector拡張機能を使えば、登録したツールの検証やLLMでのテストも可能だ。Googleの早期プレビュープログラムに参加すれば、ドキュメントとデモへのアクセスも得られる。
—
筆者はこう見ている
WebMCPの本質は、Webサイトに「第三の読者」が加わることだ。
これまでWebサイトの読者は2種類だった。人間と、スクリーンリーダー（アクセシビリティ）だ。WebMCPは、AIエージェントを3番目の読者として公式に位置づける。
レスポンシブデザインがモバイル時代の分水嶺だったように、WebMCPはAIエージェント時代の分水嶺になる可能性がある。早期に対応したサイトが、エージェント経由のトラフィックという新しいチャネルで先行者利益を得る構図は、モバイルSEOの初期と驚くほど似ている。
ただし、まだ早期プレビュー段階であることも忘れてはならない。Chrome Canaryのフラグの奥に隠れた機能であり、正式なWeb標準として確定したわけではない。ツールの発見可能性、セキュリティモデル、ブラウザ間の互換性など、未解決の課題は残っている。
それでも、GoogleとMicrosoftがW3Cの枠組みで共同開発している事実は、これが特定企業の実験ではなく、Webの次のレイヤーになる可能性を示唆している。
—
参考・出典
- WebMCP is available for early preview — Chrome for Developers（参照日: 2026-03-22）
- Google Chrome ships WebMCP in early preview, turning every website into a structured tool for AI agents — VentureBeat（参照日: 2026-03-22）
- Google previews WebMCP, a new protocol for AI agent interactions — Search Engine Land（参照日: 2026-03-22）
- WebMCP — DEJAN（参照日: 2026-03-22）
- WebMCP: What It Is, Why It Matters, and What to Do Now — Semrush（参照日: 2026-03-22）
- WebMCP Specification — W3C Web Machine Learning Community Group（参照日: 2026-03-22）
—
この記事はUravation編集部がお届けしました。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
