はじめに
AIエージェントに「航空券を予約して」と頼んだとき、裏側で何が起きているか、想像したことはあるでしょうか。
エージェントはまず航空会社のWebサイトを表示し、画面全体のスクリーンショットを撮ります。その画像をビジョンモデル（画像を認識するAI）に送り、「出発地のフォームはこのあたりにあるはずだ」と推測させます。テキストを入力し、また画面を撮影し、「検索ボタンはたぶんここだ」とクリック位置を推測する。検索結果が表示されたら、再びスクリーンショットを撮って、結果を読み取ろうとする。
1回の航空券検索に、数十回のスクリーンショット撮影、数十回のビジョンモデル推論、そして数十回の「推測」が必要です。Webサイトのデザインが少し変わっただけで、エージェントは迷子になります。CSSが5ピクセルずれただけでボタンを見失うこともあります。
これが2026年現在、AIエージェントがWebを操作する主流の方法です。そして2026年2月、Googleはこの状況を根本的に変えるプロトコルを発表しました。
WebMCP（Web Model Context Protocol）。Webサイトが自分の「できること」をAIエージェントに直接、構造化されたデータとして伝えるための仕組みです。
本連載「WebMCP：Webサイトがアクションを話す時代」では、全5回にわたり、このプロトコルの概念から実装、ビジネスインパクトまでを解説します。第1回の今回は、「なぜWebMCPが必要なのか」「何を解決するのか」を概念レベルで理解いただくことを目指します。
AIエージェントの「苦労」— 推測で動く2000年代の方法論
現在のAIエージェントがWebサイトを操作する方法を、もう少し詳しく見てみましょう。
代表的なアプローチはスクリーンスクレイピングです。Webページの画面キャプチャを取得し、ビジョンモデル（画像認識AI）でUI要素を解析して、マウスクリックやキー入力をシミュレートする。あるいはHTMLのDOM（Document Object Model）をパースし、ボタンやフォームの位置を推測する。いずれにせよ、AIは「たぶんこれが検索ボタンだろう」と推測しながら動いています。
この方法には3つの根本的な問題があります。
第一に、遅い。 1回のアクションごとにスクリーンショットの取得とビジョンモデルの推論が必要です。高解像度の画像をAIに送り、解析結果を待ち、次のアクションを決定する。人間が数秒で完了する操作に、AIは数十秒を要します。
第二に、脆い。 Webサイトはデザイン変更、A/Bテスト、レスポンシブデザインによるレイアウト切り替えなど、UIが常に変化します。ボタンの位置が変わるたびにエージェントが誤動作するのでは、実用には耐えません。
第三に、高コストである。 スクリーンショットのキャプチャ、ビジョンモデルによる画像解析、その結果に基づく判断と行動の生成。これらすべてにトークン（AI処理のコスト単位）が消費されます。テキストベースのやりとりに比べ、画像ベースの処理は桁違いにコストがかかります。
GoogleのChrome開発チームでWebMCP仕様の設計に携わったKhushal Sagar（Staff Software Engineer）は、Web AI Summit 2025の講演において、現在のAIエージェントがWebサイトのページをパースし、UI要素をクリックし、アニメーションの完了を待つ——いわゆる「UIアクチュエーション」と呼ばれる一連のステップに依存している現状を指摘しています。これは本質的に、かつてのスクレイピングと同種のアプローチであり、WebMCPはこの構造を根本から置き換えることを目指しています。
WebMCPとは何か — Webサイトが「できること」をAIに直接伝える
WebMCPは、この「推測」を「契約」に置き換えます。
具体的にはWebサイトがTool Contract（ツール契約）と呼ばれる構造化されたデータを公開し、「うちのサイトでは、こういうパラメータを渡せば、こういう操作ができます」とAIエージェントに明示的に伝える仕組みです。
たとえば航空券の検索なら、Webサイトは次のようなツールを公開します。
ツール名：searchFlights
説明：「出発地、目的地、日付を指定してフライトを検索する」
入力パラメータ：origin（空港コード）、destination（空港コード）、date（日付）
戻り値：フライト一覧（便名、価格、時刻）
AIエージェントは、もうスクリーンショットを撮る必要がありません。「searchFlights」というツールに「JFK」「LAX」「2026-06-15」というパラメータを渡すだけで、構造化されたフライト情報がJSON形式で返ってきます。
この仕組みを支えるのが、Chromeブラウザに新しく追加されたnavigator.modelContextというブラウザAPIです。WebサイトはこのAPIを通じてツールを登録し、AIエージェントはこのAPIを通じてツールを発見・呼び出します。すべてがブラウザの内部で完結するため、外部サーバーを立てる必要はありません。
WebMCPの公式発表を行ったGoogleのAndré Cipriani Bandarra（Staff Developer Relations Engineer）は、このプロトコルの目的を次のように表現しています。ツールを定義することで、エージェントに対して自サイトとの「やりとりの方法と場所」を伝える。この直接的なコミュニケーションチャンネルがあいまいさを排除し、より速く、より堅牢なエージェントワークフローを実現する、と。
なぜ「今」なのか — Google + Microsoft + W3Cという布陣
WebMCPの発表が注目を集めた理由は、技術的な革新性だけではありません。その推進体制が異例だからです。
WebMCPはGoogleとMicrosoftが共同で設計し、W3C（World Wide Web Consortium）のWeb Machine Learningコミュニティグループで標準化作業が進められています。W3CはHTML5やCSS、Web Accessibilityガイドラインなど、Webの基盤となる標準を策定してきた国際標準化団体です。WebMCPをここで標準化するということは、「特定のブラウザやAIプラットフォームに依存しない、Webのインフラとして位置づける」という明確な意志表示です。
2026年2月10日にChrome Developers Blogで発表され、Chrome 146 Canary（開発者向けプレビュー版）でアーリープレビューが利用可能になりました。W3Cドラフト コミュニティグループレポートは2月12日に正式公開されています。Microsoftが仕様の共同著者であることから、Microsoft Edgeでのサポートもほぼ確実視されています。Chromeの安定版への正式搭載は2026年後半、Google I/OまたはGoogle Cloud Nextでの正式発表が見込まれています。
技術SEOの専門家Dan Petrovicは、この発表を「構造化データ以来最大のテクニカルSEOの変革」と評しました（Search Engine Land）。SEOコンサルタントのGlenn Gabeも「これは大きな出来事だ」と即座にコメントしています。
過去を振り返ると、Webの歴史において「GoogleとMicrosoftが共同で1つの標準を推進する」場面は多くありません。Schema.orgの設立がその代表例です。2011年6月にGoogle・Microsoft（Bing）・Yahoo!の3社が共同で立ち上げ、同年11月にYandexが参加。その後Schema.orgはWebの構造化データ標準として定着し、リッチスニペットやナレッジパネルの基盤になりました。WebMCPにも同様のインパクトが期待されます。
AnthropicのMCPとの関係 — バックエンドとブラウザの補完構造
ここで「MCP」という名前の重複について整理しておきます。
MCP（Model Context Protocol）は、Anthropicが2024年11月25日にオープンソースとして発表したプロトコルです。AIアプリケーション（Claude、ChatGPTなど）と外部ツール・データソースを接続するための標準化されたインターフェースで、「AIのUSB-C」と表現されています。2025年3月にはOpenAIが採用を発表し、同年4月にはGoogle DeepMindも対応を表明。12月にはLinux Foundation傘下のAgentic AI Foundationに寄贈され、業界標準としての地位を確立しました。
MCPはJSON-RPCベースのサーバーサイドプロトコルです。PythonやNode.jsでMCPサーバーを構築し、AIプラットフォームとバックエンドの間で構造化されたデータをやりとりします。
一方、WebMCPはブラウザネイティブのクライアントサイドプロトコルです。Webページ上のJavaScriptからツールを登録し、ブラウザ内で動作するAIエージェントがそれを呼び出します。
この2つは名前が似ていますが、補完関係にあり、競合しません。VentureBeatの分析が端的に整理しています。MCPはバックエンドサービスへの接続を担い、WebMCPはブラウザベースのインターフェースへの接続を担う。たとえば旅行会社は、ChatGPTやClaudeとのAPIレベル統合にはバックエンドMCPサーバーを使い、消費者向けWebサイトでの予約フローにはWebMCPを実装する。2つの標準は異なるインタラクションパターンに対応しており、衝突しない、と。
この補完構造を理解することは、エージェンティックWeb戦略を設計する上で不可欠です。
| プロトコル | 動作環境 | 通信方式 | 主な用途 | |
|---|---|---|---|---|
| MCP（Anthropic） | サーバーサイド | JSON-RPC | AI ↔ バックエンドAPI・データソース | |
| WebMCP（Google） | ブラウザ内 | navigator.modelContext | AI ↔ ブラウザ上のWebアプリケーション |
どちらを選ぶかではなく、どちらも必要になる。これが今後のWebサイト設計の前提です。
「ページが何であるか」から「ページが何をできるか」へ
WebMCPがもたらす根本的な転換を、一文で表すなら次のようになります。
これまでのWebは「ページが何についてか」を伝えていた。これからのWebは「ページで何ができるか」を伝える。
Schema.org（構造化データ）は「これは商品です。価格は100ドルです。評価は星4つです」というように、ページの内容を機械可読にするものでした。Googleはこの情報を使ってリッチスニペットやナレッジパネルを表示しています。
llms.txt（AIエージェント向けサイトマップ）は、サイトの最も重要なコンテンツの一覧をMarkdownで提供し、AIクローラーが効率よくサイトを理解できるようにする静的ファイルです。
WebMCPは、そこからさらに一歩進みます。「カートに追加する機能があります。商品IDと数量をパラメータとして受け付けます」というように、ページのアクションを機械可読にします。
この3つは層を成しています。
- Schema.org = 「私はこういう情報です」（記述）
- llms.txt = 「私のサイトの全体像はこうです」（案内）
- WebMCP = 「私のサイトではこういう操作ができます」（実行）
SEOの文脈で言えば、これはトランザクショナルインテント（「買いたい」「予約したい」「問い合わせたい」という行動意図を持った検索）への対応力が根本的に変わることを意味します。AIエージェントが検索結果からそのまま予約や購入を完了できるサイトと、エージェントが画面をスクリーンショットで撮りながら推測でボタンを探すサイト。ユーザーの行動を代行するAIエージェントが、どちらのサイトを「選ぶ」かは明白です。
Dan Petrovicが「構造化データ以来最大の変革」と呼ぶのは、まさにこの転換を指しています。構造化データがWebページの「意味」を検索エンジンに伝え、リッチスニペットという新しい表示形態を生んだように、WebMCPはWebページの「能力」をAIエージェントに伝え、エージェンティックWeb（AIが操作するWeb）という新しいインタラクション形態を生もうとしているのです。
効率改善の実態 — 数字で見るインパクト
概念的な話だけでは説得力に欠けるかもしれません。具体的な効率改善の試算を見てみましょう。
Kassebaum Engineeringの技術分析によれば、ビジョンベース（スクリーンショット型）のブラウジングからWebMCPベースのインタラクションに移行した場合、トークン効率が89%改善し、タスク精度が約98%に到達するとされています。MarkTechPostの分析では、計算オーバーヘッドが67%削減されるという試算も出ています。
この改善幅は直感的に理解できます。航空券検索の例で考えれば、スクリーンショット型では「画面撮影 → ビジョンモデル解析 → クリック位置特定 → 入力 → 再度撮影 → …」を数十回繰り返しますが、WebMCPなら searchFlights("JFK", "LAX", "2026-06-15") の1回のツール呼び出しで完結します。VentureBeatの分析が指摘するとおり、WebMCPの単一ツール呼び出しは、従来のブラウザ操作における数十回のやりとりを置き換えうるのです。
企業のIT部門にとっては、AIエージェント運用のトークンコスト削減に直結する話です。
現時点のステータス — 誠実に伝えるべきこと
ここで、現時点でのWebMCPの成熟度を正直にお伝えしておきます。
WebMCPは2026年3月時点でアーリープレビュー（早期プレビュー）段階です。
- Chrome 146 Canary（開発者向けプレビュー版）で利用可能。
chrome://flagsから「WebMCP for testing」フラグを有効化する必要がある - W3Cドラフトコミュニティグループレポートとして公開済み（2026年2月12日）。ただし正式なWeb標準ではまだない
- APIの仕様は変更される可能性がある。本番サイトへの導入は推奨されない
- Chrome安定版への搭載は2026年後半を予定
- Firefox、Safariは対応を表明していない（ただしW3Cでの標準化が進めば追随が見込まれる）
- ツールのディスカバリー（あるサイトがどんなツールを公開しているかをエージェントが事前に発見する仕組み）は未実装。将来的に
.well-known/webmcpのようなマニフェストが検討されている
つまり、「今すぐ本番サイトに実装すべき」段階ではありません。しかし、「今から概念を理解し、準備を始めるべき」段階であることは間違いありません。
構造化データ（Schema.org）が2011年に発表され、初期に導入した企業がリッチスニペットで年単位の先行者優位を獲得したことを思い出してください。WebMCPもまた、正式リリース前に理解し準備している企業と、リリース後にゼロから始める企業との間に、同様の差を生むことが予想されます。
Web制作会社にとっての意味 — unTypeの視座
unTypeは「Web制作」から「コミュニケーションデザイン」へと事業領域の再定義を進めています。WebMCPの登場は、この転換の妥当性を裏付けるものだと考えています。
従来のWeb制作は「人間が見て使いやすいサイトを作る」ことでした。もちろんこれは今後も重要です。しかしWebMCPの時代には、それに加えて次のことが求められます。
ツール設計。サイトのどの機能を、どういうパラメータ定義で、AIエージェントに公開するか。これはUI設計とは全く異なるスキルセットです。
エージェント体験設計。AIエージェントがツールを呼び出し、結果をユーザーに返すまでの一連の流れが、人間のユーザーにとって最適な結果になるか。ツールの戻り値のフォーマット、エラー時のハンドリング、human-in-the-loopのタイミング設計が必要です。
二重インターフェース設計。人間が見るビジュアルUI（HTML/CSS/JS）と、AIエージェントが操作するMachine UI（WebMCP Tool Contract）を、1つのサイトの中で両立させること。
これはもはや「Web制作」の範疇を超えた、「コミュニケーションの全体設計」です。人間とAI、双方のユーザーに対して、適切な情報と操作手段を適切な形で提供する。それが私たちの考える「コミュニケーションデザイン」の本質です。
まとめ — ピクセルからプロトコルへ
WebMCPが解決する問題は、突き詰めれば1つです。
AIエージェントが「推測」ではなく「契約」に基づいてWebサイトを操作できるようにすること。
スクリーンショットを撮ってビジョンモデルで解析する「ピクセルの時代」から、構造化されたTool Contractに基づいてツールを呼び出す「プロトコルの時代」へ。この転換は、Webの歴史における構造化データ（Schema.org）の登場に匹敵するインパクトを持つ可能性があります。
次回の第2回では、WebMCPの技術的な構造に踏み込みます。Declarative API（HTMLフォームに属性を追加するだけでAI対応にできるアプローチ）とImperative API（JavaScriptで動的にツールを登録するアプローチ）の2つのAPIを詳しく解説し、Tool Contractの設計思想と、ブラウザがユーザーの安全を守る「human-in-the-loop」の仕組みを紐解きます。
参考情報
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日）
ADWEEK「Google Takes a Step Toward an Internet Built for AI Agents」（2026年2月12日）
PYMNTS「Google Introduces WebMCP to Give Browser Access for AI Agents」（2026年2月20日）
Search Engine Land「Google previews WebMCP, a new protocol for AI agent interactions」（2026年2月11日）
MarkTechPost「Google AI Introduces the WebMCP to Enable Direct and Structured Website Interactions for New AI Agents」（2026年2月14日）
Kassebaum Engineering「WebMCP: How Browsers Are Becoming Native Platforms for AI Agents」（2026年2月14日）
Anthropic「Introducing the Model Context Protocol」（2024年11月25日）
Anthropic「Model Context Protocol Specification」
TechCrunch「Google says it'll embrace Anthropic's standard for connecting AI models to data」（2025年4月9日）
Linux Foundation「Formation of the Agentic AI Foundation」（2025年12月9日）
Wikipedia「Model Context Protocol」
Wikipedia「Schema.org」
The New Stack「Why the Model Context Protocol Won」（2025年12月）
この記事は「WebMCP：Webサイトがアクションを話す時代」シリーズの第1回です。
AI技術のビジネス活用やWebサイトのAIエージェント対応について、具体的なご相談はunTypeまでお気軽にお問い合わせください。
この記事をシェアする
