生成AIの「エージェント」が業務に入り始めた一方で、Web操作の自動化は依然として不安定で高コストです。ボタン位置の推定や画面解析にトークンと時間を浪費し、UI変更で簡単に壊れる――この課題に対し、Chromeが早期プレビューとして提示したのがWebMCP（Web Model Context Protocol）です。WebMCPは、各Webサイトを「AIが呼び出せる構造化ツール」として公開するための新しいブラウザAPIを提案し、スクレイピング中心の時代を終わらせる可能性があります。本記事では、B2Bの意思決定者・企画担当者向けに、仕組みと企業ITへの影響、MCPとの使い分け、普及ロードマップまでを整理します。
1. WebMCP登場の背景：スクレイピング頼みのWebエージェントが抱える課題
現行のWebエージェントは、Webサイトを「人間向けUI」としてしか理解できず、実質的に“言語の通じない観光客”のように振る舞います。代表的な手法は、(1)スクリーンショットをマルチモーダルモデルに渡して要素を推定する方法、(2)DOM/HTMLを解析してクリック対象を探す方法です。どちらも、モデルにとって無関係な情報が大量に混ざるため、コストと失敗率が企業運用のボトルネックになります。
スクリーンショット方式では、画像1枚あたり数千トークン相当のコストが発生しやすく、推論レイテンシも伸びます。DOM方式でも、HTML/CSS/JSのノイズを読み込むことでコンテキストを圧迫し、ページ構造の微妙な差異や動的レンダリング（SPA、遅延読み込み）で失敗が増えます。結果として、人間なら数秒の「検索→フィルタ→結果確認」が、エージェントでは多数の推論呼び出しと試行錯誤に分解され、運用費（トークン課金、API費、監視工数）と開発費（壊れた自動化の改修）が膨らみます。
企業側の観点では、UI変更が頻繁なSaaSやEC、社内ポータルほど影響が大きく、「自動化できるはずの業務が、保守できない自動化になる」という逆転現象が起きがちです。WebMCPは、この“人間向け表現とAIが必要とする構造のギャップ”を、ブラウザ標準で埋めようとする試みです。
2. WebMCPの仕組み：navigator.modelContextと2つのAPI（Declarative/Imperative）
WebMCPは、サイトがエージェントに対して「呼び出し可能なツール（関数）」を構造化して公開するための提案仕様です。中核となるのが新しいブラウザAPIである
（概念としての入口）で、エージェントはページのUIを推測する代わりに、サイトが提示するツール定義に基づいて確実に操作できます。
WebMCPは大きく2系統のAPIで構成されます。ひとつは既存HTML資産を活かしやすいDeclarative API、もうひとつは複雑な動的操作を扱えるImperative APIです。両者を併用することで、「フォーム中心の定型処理」と「JavaScriptで実現している高度なUIロジック」の双方を、エージェントにとっての“関数呼び出し”へ落とし込めます。
Declarative API：既存フォームを“ツール化”する近道
Declarative APIは、HTMLフォームのような標準的UIを、追加のメタ情報（ツール名、説明など）でエージェントから呼べるようにする方向性です。フォーム設計が整っている企業サイトであれば、ページの作り替えやバックエンド新設をせずに、比較的軽微な変更で「入力→送信→結果取得」をツールとして公開できる余地があります。すでに入力項目が明確でバリデーションも整っている場合、導入効果が出やすいのが特徴です。
Imperative API：registerTool()で高度な操作を関数として公開
Imperative APIは、JavaScriptでツールを登録し、引数スキーマと説明を含む「呼び出し契約」を提示する考え方です。イメージとしては、OpenAIやAnthropicのツール定義に近いものを“ブラウザ内で”提供します。たとえばECならsearchProducts(query, filters)、印刷発注ならorderPrints(copies, pageSize)のように、UI上の複数ステップ操作を1回のツール呼び出しに集約できます。
重要なのは、従来なら「フィルタを開く→選ぶ→適用→ページ送り→結果を読む」といった多数の操作と推論が必要だった処理を、1回の構造化呼び出し＋構造化レスポンス（JSON等）に置き換えられる点です。これにより、エージェントは画面の“解釈”ではなく、明示された“能力”を使ってタスクを進められます。
3. 企業ITへのインパクト：コスト削減・信頼性向上・開発速度の加速
WebMCPが企業ITに与えるインパクトは、単なる「新しいAPI」ではなく、エージェント運用の費用対効果を決める3要素（コスト、信頼性、開発生産性）を同時に改善し得る点にあります。特に、Web操作が絡む業務支援（営業支援、調達、カスタマーサポート、社内申請）で効果が出やすいでしょう。
- コスト削減：スクリーンショット解析やDOM解釈の反復が減り、推論回数・トークン消費・待ち時間を圧縮できます。タスクが「多数の推測ステップ」から「少数の確定ステップ」へ変わるため、見積もり可能性も上がります。
- 信頼性向上：UI変更やレイアウト崩れ、動的コンテンツによる失敗が、ツール化された範囲では大幅に減ります。「この関数があり、引数はこれ、返り値はこれ」という契約があるため、エージェントが迷いにくくなります。
- 開発速度の加速：別途MCPサーバーや専用APIを立てずとも、既存フロントエンドのJavaScriptロジックを再利用してツール化できるため、アーキテクチャ変更を最小化できます。特に“ページを作り直さずにエージェント対応する”という選択肢は、既存資産の大きい企業ほど価値があります。
意思決定者の観点では、WebMCPは「PoCでは動くが本番で壊れる」問題を減らし、運用監視・例外対応・改修の隠れコストを抑える方向に働きます。結果として、エージェント導入のROIが“モデル性能”ではなく“接続方式”で左右される局面において、標準化の恩恵が大きくなります。
4. Human-in-the-loop前提の設計：自律型ではなく協調型ブラウジングへ
WebMCPの設計思想で特徴的なのは、完全自律のヘッドレス自動化を主目的にしていない点です。仕様は、ユーザーがブラウザ上に存在し、エージェントと協調しながら進めるHuman-in-the-loop（人間参加型）を前提にしています。企業利用では、誤操作や誤発注、権限逸脱のリスクを考えると、この前提はむしろ現実的です。
提案では、協調型の柱として「コンテキスト（ユーザーの状況理解に必要な情報）」「ケイパビリティ（代理実行できる行為）」「コーディネーション（人とエージェントの引き継ぎ制御）」が重視されます。たとえば購買担当が条件を指示し、エージェントがサイトのツールを呼んで候補を絞り込み、最終判断や例外条件は人が握る、といった分業が設計しやすくなります。
この方向性は、内部統制や監査ログ、承認フローと相性が良い一方で、「完全無人で大量処理したい」用途には別の仕組みが必要になります。WebMCPは“ブラウザでの共同作業”を強化する標準として捉えるのが適切です。
5. MCPとの違いと使い分け：バックエンド連携とブラウザ内ツールの補完関係
WebMCPは名前にMCPを含みますが、AnthropicのModel Context Protocol（MCP）を置き換えるものではありません。MCPが主にクライアント（AI）とサーバー（ツール提供者）を結ぶバックエンド連携の枠組みであるのに対し、WebMCPはブラウザ内でサイトがツールを公開し、ページ文脈のままエージェントが利用することを狙います。通信方式や前提（JSON-RPC等）も同一ではありません。
企業アーキテクトの観点では、「どこで実行し、どこに責任境界を置くか」で使い分けるのが要点です。バックエンドのMCPは、サービス間連携やバッチ的自動化、UI不要の処理に向きます。一方WebMCPは、ログイン済みセッション、画面共有の文脈、ユーザーの確認が必要な操作など、“ブラウザにいること自体”が価値になる領域に向きます。
- MCPが向く例：在庫照会API、価格計算、社内マスタ参照、RPA置き換えのサーバー処理、複数システム横断の自動実行。
- WebMCPが向く例：予約・申込・購買などの画面フロー、サポート担当の共同閲覧、ユーザー入力を伴うフォーム処理、UI上での候補提示と最終承認。
実務的には「バックエンドはMCPで統合しつつ、顧客向け/従業員向けWebはWebMCPでツール公開する」という二層構えが自然です。両者は競合ではなく、接点の違う補完関係として設計できます。
6. 提供状況と今後の見通し：Chrome Canaryから標準化・普及までのロードマップ
WebMCPは、Chrome 146 Canaryで早期プレビューとして提供が始まった段階で、chrome://flagsの「WebMCP for testing」から有効化して試す位置づけです。GoogleとMicrosoftのエンジニアが共同で進め、W3CのWeb Machine Learningコミュニティグループでインキュベートされてきた経緯が示す通り、単独ベンダーの実験というより“標準化を見据えた実装先行”に近い動きです。
今後の普及は、(1)仕様がコミュニティ段階から正式ドラフトへ進むこと、(2)Chromeでの実装成熟（セキュリティ、権限、UX、互換性）、(3)他ブラウザの追随、(4)Web開発者側の採用、の順で進むのが一般的です。共同開発にMicrosoftが関与している点から、Edge系での展開も期待されますが、時期は確定ではありません。
B2B企業としては、現時点で全社標準に組み込むというより、「エージェント活用がROIを左右する特定業務」を選び、Canaryでの技術検証と設計指針づくりを先行するのが現実的です。特に、フォームが整備された業務画面や、フロントエンドに既存ロジックが厚い領域は、少ない改修で効果が出る可能性があります。
まとめ
WebMCPは、スクリーンショット解析やDOMスクレイピングに依存してきたWebエージェントの不安定さ・高コスト構造を、ブラウザ標準で転換しようとする提案です。navigator.modelContextを起点に、Declarative/Imperativeの2つのアプローチで「サイトの操作を構造化ツールとして公開」できれば、推論回数の削減、UI変更耐性の向上、開発・運用の省力化が同時に狙えます。
また、完全自律ではなくHuman-in-the-loopを前提にした協調型ブラウジングは、企業の統制・責任分界と整合しやすい設計です。バックエンド連携のMCPと競合するのではなく、ブラウザ内ツールとして補完し合う構図で捉えると、全体アーキテクチャの見通しが良くなります。Chrome Canaryでの早期プレビュー段階から、影響の大きい業務領域を選んで検証を始めることが、標準化・普及局面での優位につながるでしょう。
