WebMCP入門：AIとWebページが同じ画面で協働する仕組み
この記事で学べること
- 従来のブラウザ操作でAIが画面から推測していたもの
- WebMCPがサイトの機能と入出力をAIへ明示する方法
- JavaScriptで機能を登録する方法と、HTMLフォームで伝える方法の違い
- MCP、OpenAPI、A2A、NLWeb、従来のブラウザ操作との境界
- WebMCPの導入前に権限・確認・評価・代替操作を決める理由
WebMCPはWebページの機能をAIへ分かる形で伝える提案
WebMCPは、Webサイトが「商品を探す」「フォームへ入力する」といった機能をAIへ直接説明するための提案です。利用者が見ているページの中でAIも同じ機能を使うため、画面の見た目からボタンや入力欄の意味を毎回推測する必要を減らせます。人は同じ画面で入力内容や結果を確認できます。
ここで扱うWebMCPは、W3C Web Machine Learning Community Groupの提案です。2026年9月10日版はCommunity Groupの草案で、W3C標準ではありません。[1] MCP自体の基本構造はMCP入門で説明しています。
この記事では、「WebMCPは従来のブラウザ操作やMCPと何が違い、どのような考え方で安全に試せばよいか」という問いに焦点を当て、中心概念の仕組み、混同しやすい境界、実務での判断材料を扱います。
最後まで読むと、「WebMCPは従来のブラウザ操作やMCPと何が違い、どのような考え方で安全に試せばよいか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。
WebMCPは画面から意図を推測する操作を、サイトが示す明示的な契約へ変える
従来のブラウザ操作AIは、画面画像やページ内部の構造を読み、人のようにクリックと文字入力を繰り返します。ページ内部の構造には、HTML要素の並びを表すDOMや、支援技術へボタンなどの役割を伝えるアクセシビリティツリーがあります。
この方式では、AIが「このボタンは購入」「この入力欄は姓」と推測します。画面が変わったり、よく似たボタンが並んだりすると、解釈を誤る余地があります。手順が長いほど、小さな誤りが後の操作へ影響します。Chromeの解説では、画面を見て操作するこの方式をactuationと呼んでいます。[2]
WebMCPでは、旅行サイトなら「旅行を検索する」という機能名、必要な入力、実行される処理をサイト側が一つの道具として示します。AIはボタンの位置を当てる代わりに、目的と入力の形を読んで機能を呼びます。
図書館にたとえると、従来の操作は棚の形や案内板から貸出手順を推測する方法です。WebMCPは、図書館側が「本を探すには題名か著者名を渡す」と受付方法を示す考え方に近いものです。
ここでいう契約は法律上の契約ではなく、機能の目的、受け取る情報、返す結果についての共通ルールを意味します。
ただし、画面は消えません。道具は開いているページの中で動き、検索結果や入力状態を同じ画面へ反映します。人とAIがページ、ログイン状態、現在の入力を共有できることが、画面の外にあるAPIだけを使う方式との大きな違いです。
WebMCPそのものがAIとの通信方法を一つに決めるわけでもありません。外部の道具とAIをつなぐMCPなどを併用できます。中心にあるのは、サイトが機能を宣言し、ブラウザが現在のページ状態と権限の境界で仲介する考え方です。[1]
JavaScriptとHTMLフォームは、複雑な機能と小さな機能に向く2つの伝え方
WebMCPには、JavaScriptで機能を登録する方法と、通常のHTMLフォームへ説明を加える方法があります。名称では難しく見えますが、違いは「アプリの処理を直接まとめるか」「人が使うフォームをAIにも説明するか」です。
| 伝え方 | 何を使うか | 向く場面 | 人向け画面との関係 |
|---|---|---|---|
| JavaScriptで登録 | 機能名、入力形式、実行処理を一組にする | 複数の画面状態を扱う検索、編集、既存アプリ処理 | 実行結果を同じ画面へ返せる |
| HTMLフォームで宣言 | 既存フォームと入力欄に説明を加える | 検索、問い合わせ、絞り込みなど小さな入口 | WebMCP非対応でも通常のフォームとして残る |
JavaScriptの経路は、開発者がページ上の処理を一つの道具として登録します。AIは公開された名前と入力形式を読み、構造化された入力を渡します。現行草案には、道具の登録、一覧取得、実行、登録解除や中止に関する仕組みがあります。[3]
HTMLフォームの経路では、検索欄や問い合わせ欄に「このフォームは何をするか」「各入力は何を意味するか」という説明を加えます。ブラウザがそれを読み、AIへ必要な入力を伝えます。最終送信を人へ任せる構成も選べます。[4]
初心者が大切にしたいのはAPI名の暗記ではありません。既存の画面を保ったまま、AIが使える入口を一つずつ明確にする設計です。小さな検索フォームなら宣言型から始め、画面状態と深く結び付く処理だけをJavaScriptで登録すると考えると整理できます。
WebMCP対応にAI専用の別画面は必要ありません。人が理解できる検索欄や確認画面を土台にし、その裏にある一つの機能をAIにも誤解しにくい形で説明します。
人向けの分かりやすさとAI向けの明確さを同じ設計で支えるのが理想です。
WebMCP・MCP・OpenAPI・A2A・NLWebは、どこにある機能を誰につなぐかが違う
似た言葉を覚えるより、「機能はどこにあるか」「いつまで使えるか」「誰と誰をつなぐか」で比べると理解しやすくなります。
| 技術 | 主に接続する対象 | 得意な用途 | WebMCPとの違い |
|---|---|---|---|
| WebMCP | 今開いているWebページと、その中で動くAI | 人とAIが同じ画面とログイン状態で進める操作 | ページを閉じると、その入口は使えなくなる |
| MCP | AIアプリと、画面の外にあるデータや道具 | 複数アプリから使う処理、画面を閉じても続く処理 | ページの裏側を補えるが、同じ画面の状態が中心ではない |
| OpenAPI | Web APIを提供する側と利用する側 | APIの場所、入力、応答、認証を機械が読める形で説明する | WebMCPの内側から呼ぶ既存APIにも使える |
| A2A | 独立したAI同士 | AI同士が仕事を見つけ、任せ、結果を返す | ページ機能ではなくAI同士の連携を扱う |
| NLWeb | Webサイトの掲載情報と自然言語の質問 | 商品、レシピ、場所などを会話で探す | 開いている画面の操作より、サイト内容への質問が中心 |
| 従来のブラウザ操作 | 人向け画面と自動操作プログラム | WebMCP非対応サイトを含む幅広い操作 | 対応範囲は広いが、画面の意味を推測する |
Chromeの比較では、MCPを画面の裏側にあるサーバーへ継続してつなぐ方法、WebMCPを開いているタブに結び付く一時的な機能として整理しています。[5] MCPはAIアプリと外部のデータや道具をつなぐプロトコルです。[6] OpenAPIはWeb APIの契約を機械可読に記述します。[7]
A2Aは独立したAI同士の発見、仕事の委任、結果交換を扱い、公式文書もMCPのagent-to-toolとA2Aのagent-to-agentを補完関係と説明しています。[8] NLWebはSchema.orgなどを利用し、Webサイトへ自然言語の質問口を設ける構想です。[9]
商品情報を会話で探すならNLWeb、開いている商品ページの絞り込みを操作するならWebMCP、サイトを閉じても注文履歴へ接続するならMCPや通常のAPIが候補です。一つに統一せず、接続の境界から選びます。
入力が明確でも安全とは限らないため、権限・確認・評価・代替操作を先に設計する
機能名と入力が決まっていれば、AIの推測は減ります。しかし、安全性が自動的に保証されるわけではありません。ページは利用者のログイン状態を持つため、意図しない購入、設定変更、情報の取り出しにもつながり得ます。外部文章の中の命令をAIが利用者の指示と誤認する、間接プロンプトインジェクションにも注意が必要です。
Chromeの暫定的な指針には、読み取り専用か、信頼できない出力を返すか、大きな影響を与えるかをAIへ伝えるヒントがあります。[10] ただし、これは注意書きであり、本人確認や業務ルールの代わりではありません。
| 確認する条件 | 最初の検証で求める設計 | 満たせない場合 |
|---|---|---|
| 変更の影響 | 検索・表示・下書きなど、読み取り専用か取り消せる操作から始める | 購入、送信、削除は公開しない |
| 本人確認と権限 | サーバー側で「誰が何をしてよいか」を確認する | ログイン済みだけを許可の根拠にしない |
| 人の確認 | 実行内容、対象、金額、送信先を確定前に見せる | 影響の大きい操作を自動確定しない |
| 入力と出力 | 項目と形式を狭くし、必要な結果だけを返す | 自由記述やページ全文を無条件で扱わない |
| 評価 | 道具の選択、入力、順序、失敗途中の停止を確かめる | 一度の成功デモで本番判断しない |
| 代替操作 | WebMCPがなくても人が同じ目的を達成できる画面を残す | 重要操作を一つの対応ブラウザだけに依存させない |
通常の処理は決まった入力で繰り返し検査し、AIが関わる部分は正しい機能を選ぶか、入力と順序が正しいか、途中の失敗で安全に止まるかを別に評価します。Chromeの評価ガイドも、通常のテストとモデル接点の確率的な評価を分けています。[11]
まとめ：現在は検証段階なので、読み取り専用の一機能から始めて成熟を待つ
2026年9月時点のWebMCPは、仕様案、対応ブラウザ、試作品、商用導入を分けて見る必要があります。一般利用者が設定なしで広く使える標準ではなく、参加登録や開発者向け設定を使う検証段階です。
- 仕様： Community Group草案であり、APIや安全設計は変わる可能性があります。[1]
- Chrome： Chrome 149から期間限定のorigin trialが案内され、開発者自身の端末では実験設定を使う方法があります。[2]
- 試作例： 旅行検索、商品構成、注文追跡、編集、ブラウザ内データ分析などが公開されています。[12][13]
- 周辺サービス： Cloudflareは既存サイトへ橋渡しを加えるdeveloper previewを発表しています。[14]
これらは「何ができそうか」を示しますが、同じ成功率や効果で本番運用できる証明ではありません。現時点で相性がよいのは、人がページを開いたまま結果を目で確認する検索、絞り込み、診断、下書きなどです。
検証では「機能が一度動いたか」だけでなく、人が結果を理解できたか、誤った入力を止められたか、非対応環境でも同じ目的を達成できたかを記録します。
仕様の成熟とは、機能が増えることだけでなく、異なるブラウザで同じ境界と確認方法を再現できることです。
私の見立てでは、WebMCPが成熟してもMCPやAPIを置き換えるのではなく、役割を分けて組み合わせる構成が増えます。WebMCPは現在の画面と人の確認を扱い、MCPやAPIは永続データや長時間処理を担当できます。
最初の一歩は、情報を読むだけで、結果が画面に現れ、失敗しても影響が残らない機能を一つ選ぶことです。人向けの操作を残し、現在の草案で公開範囲を確認し、AIが見た機能と実行結果を記録します。サイトを閉じた後も続く処理が必要なら、WebMCPではなくMCPや通常のAPIから考えます。
本記事は一般的な情報整理であり、法的助言ではありません。実務判断は専門家に確認してください。
参考文献
- W3C Web Machine Learning Community Group, WebMCP, 2026年9月10日
- Chrome for Developers, WebMCP, 2026年8月7日更新
- Chrome for Developers, Imperative API, 2026年9月1日更新
- Chrome for Developers, Declarative API, 2026年5月18日
- Chrome for Developers, When to use WebMCP and MCP, 2026年5月19日更新
- Model Context Protocol, Specification (2026-07-28), 2026年7月28日
- OpenAPI Initiative, Introduction
- A2A Protocol, A2A Protocol
- NLWeb, What is NLWeb?
- Chrome for Developers, WebMCP tool security, 2026年9月1日更新
- Chrome for Developers, Test WebMCP with Evals, 2026年5月28日更新
- Chrome for Developers, 15 updates from Google I/O 2026, 2026年5月19日
- OpenAI, WebMCP Challenge
- Cloudflare, Give any website a WebMCP interface, 2026年8月6日
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。