AIエージェントの業務活用が進む一方で、Web操作の自動化は依然として高コストかつ不安定です。画面解析やDOM解析に大量のトークンを消費し、UI変更ですぐ壊れる。この構造的課題に対し、Chromeが早期プレビューとして提示したのがWebMCPです。
WebMCPは、WebサイトをAIが直接呼び出せる構造化ツールとして公開するための新しいブラウザAPI構想です。従来のスクレイピング中心のWebエージェントから脱却し、AIとWebの接続方式そのものを変える可能性があります。本記事では、企業のIT担当者・企画責任者向けに、WebMCPの仕組み、企業ITへのインパクト、MCPとの違い、導入検討のポイントまで整理します。
1. なぜWebMCPが必要なのか？スクレイピング型Webエージェントの限界
現在のWebエージェントは、Webサイトを「人間向けUI」としてしか理解できません。そのため、次のような方法に頼っています。
・スクリーンショットをAIに渡して要素を推定
・DOMやHTMLを解析してクリック対象を探す
しかし、この方式には大きな問題があります。
コストが高い
スクリーンショット方式では、画像1枚で数千トークン相当の処理が発生しやすく、推論回数も増えます。DOM解析でも不要なHTML/CSS/JSを大量に読み込むため、コンテキストを圧迫します。
壊れやすい
UI変更やレイアウトの微調整、SPAの動的レンダリングなどで簡単に動作が不安定になります。結果として、検索 → フィルタ → 確認という人間なら数秒の操作が、AIでは多数の推論呼び出しに分解されます。
運用コストが膨張する
・トークン課金
・API利用料
・監視工数
・自動化修正コスト
特にUI変更が頻繁なSaaSやECサイトでは、「自動化したはずなのに保守負担が増える」という逆転現象が起きがちです。WebMCPは、この人間向けUIとAIが必要とする構造のギャップを、ブラウザ標準で埋めようとする取り組みです。
2. WebMCPの仕組み：navigator.modelContextと2種類のAPI
WebMCPは、Webサイト側がAIエージェントに対して呼び出し可能なツールを構造化して公開するための仕様提案です。中核となるのが、ブラウザAPIであるnavigator.modelContextという概念的な入口です。これにより、エージェントはUIを推測するのではなく、明示されたツールを呼び出せるようになります。WebMCPは大きく2種類のアプローチを持ちます。
2-1. Declarative API：既存フォームをツール化
Declarative APIは、HTMLフォームをベースにツール化する仕組みです。フォームにツール名や説明などのメタ情報を付与することで、入力 → 送信 → 結果取得 という一連の流れをAIが直接呼び出せるようにします。
フォーム設計が整備されている企業サイトであれば、大規模なバックエンド改修をせずに導入できる可能性があります。既存資産を活かせる点は、企業ITにとって大きなメリットです。
2-2. Imperative API：JavaScriptで高度な操作を登録
Imperative APIでは、JavaScriptを用いてregisterToolのような形でツールを登録します。たとえばECサイトなら、searchProducts(query, filters)。印刷発注なら、orderPrints(copies, pageSize)のように、複数ステップのUI操作を1回の関数呼び出しに集約できます。
従来は、フィルタを開く → 条件選択 → 適用 → ページ送り → 結果確認 という複数の推論が必要でした。WebMCPでは、1回の構造化呼び出しとJSONレスポンスで処理できます。これは単なるAPI追加ではなく、「UI解釈」から「能力呼び出し」への転換です。
3. 企業ITへのインパクト：コスト削減と信頼性向上
WebMCPは、エージェント運用の3大要素を同時に改善する可能性があります。
コスト削減
・推論回数の削減
・トークン消費の圧縮
・待ち時間短縮
・見積もり精度向上
多数の推測ステップが、少数の確定ステップに変わります。
信頼性向上
UI変更や動的レンダリングの影響を受けにくくなります。関数名、引数、返り値という契約があるため、エージェントが迷いにくくなります。
開発生産性向上
・既存フロントエンド資産を再利用可能
・専用MCPサーバーを立てなくてもよいケースがある
・段階的導入が可能
特に「PoCでは動いたが本番で壊れる」という課題を減らせる点は、企業導入において大きな意味を持ちます。
4. Human-in-the-loop前提の設計思想
WebMCPは、完全自律型自動化を主目的としていません。ユーザーがブラウザ上に存在し、AIと協調するHuman-in-the-loop前提の設計です。これは企業利用においてかなり現実的なものです。
・誤発注リスク
・権限逸脱
・監査対応
・承認フロー
こうした統制要件と整合しやすい構造になっています。購買担当が条件を入力し、AIが候補を絞り込み、最終判断は人が行う。この分業設計がしやすくなります。
MCPとの違い：バックエンド連携との使い分け
WebMCPは、AnthropicのModel Context Protocolを置き換えるものではありません。両者の違いは実行場所と責任境界です。
MCPが向く領域
・在庫照会API
・価格計算
・社内マスタ参照
・複数システム横断処理
・バッチ自動実行
主にバックエンド連携向けです。
WebMCPが向く領域
・予約や申込の画面フロー
・ログイン済みセッション利用
・フォーム処理
・ユーザー承認が必要な操作
このように、WebMCPはブラウザ上での共同作業に適しています。実務的には、バックエンドはMCP、フロントエンドはWebMCPという二層構成が自然となるでしょう。つまり、MCPとWebMCP競合ではなく補完関係にあります。
5. WebMCPの提供状況と今後のロードマップ
WebMCPはChrome Canaryで早期プレビュー段階です。chromeのflags設定から有効化して検証できます。GoogleとMicrosoftが関与し、W3Cのコミュニティグループで議論されている点から、標準化を見据えた動きといえます。そして今後の普及は次の流れが想定されます。
- 仕様の成熟
- Chrome実装の安定化
- 他ブラウザの追随
- Web開発者の採用
企業としては現時点で全社標準に組み込むのではなく、以下のアプローチが現実的です。
・ROIインパクトの大きい業務を特定
・技術検証を実施
・設計ガイドラインを先行整備
まとめ：WebMCPはAIエージェント活用の転換点になるか
WebMCPは、スクリーンショット解析やDOMスクレイピング依存のWebエージェント構造を見直す提案です。navigator.modelContextを起点に、DeclarativeとImperativeの2方式でサイト操作を構造化ツールとして公開できれば、以下を同時に実現できる可能性があります。
・推論回数削減
・UI変更耐性向上
・開発運用コスト圧縮
エージェント導入のROIは、モデル性能だけでなく接続方式に左右される時代に入っています。WebMCPはその接続方式を再定義する技術です。標準化の動きを注視しつつ、影響の大きい業務領域から検証を進めることが、企業競争力の差につながるでしょう。
