エージェントが「画面を読む」から「ツールを呼ぶ」へ
homulaは、エンタープライズ企業向けにAIエージェントの戦略策定・PoC・実装・運用・内製化までを一気通貫で支援するAIインテグレーターです。日々のMCP（Model Context Protocol）導入支援で扱うのは、主にサーバーサイドの連携——社内システムやSaaSの機能を、エージェントが安全に呼べるツールとして公開する仕事です。
ところが2026年に入り、ここにもう一つの層が立ち上がりつつあります。WebMCP（Web Model Context Protocol）です。Google I/O 2026（2026年5月19日開幕）で、GoogleがMicrosoftと共同開発する提案標準として発表したもので、ひとことで言えば「Webサイト自身が、ブラウザ内のAIエージェントに対して構造化されたツールを直接公開する」仕組みです（Chrome for Developers）。
これまでブラウザ上でタスクをこなすエージェントは、スクリーンショットやDOM解析で画面を“推測”し、人間のようにクリックや入力を模倣してきました。壊れやすく、トークンも食う方式です。WebMCPは、この**「画面を読む」アプローチを「ツールを呼ぶ」アプローチに置き換える**提案です。本記事は、WebMCPとは何か、サーバーサイドMCPとどう違うのか、そしてエンタープライズが今“考え始めるべき”統制とセキュリティの論点を整理します。
前提整理：MCPはAIエージェントと外部ツール／データを標準化された方法でつなぐオープンプロトコルです。基礎から押さえたい方は「MCPとは」を、エンタープライズ本番運用での認証・監査・スケールは「MCPの2026年進化」をどうぞ。本記事は“ブラウザ側”という新しい層に焦点を当てます。
WebMCPの中身：ページが「自分にできること」を宣言する
WebMCPの核心は、ブラウザに新しいAPI（navigator.modelContext）が加わり、Web開発者がページ上に「ツール」を登録できるようになる点です。各ツールは、名前・説明・入力スキーマ・実行コールバックを持ち、そのページのコンテキスト（DOM、ユーザーのログインセッション、既存のクライアント側ロジック）の中で実行されます（Chrome for Developers: Imperative API）。
// 命令型API：ページが自分の「できること」をツールとして登録する
navigator.modelContext.registerTool({
name: "search_products",
description: "商品カタログをキーワードで検索する",
inputSchema: {
type: "object",
properties: {
query: { type: "string" },
category: { type: "string" },
},
},
execute: async ({ query, category }) => {
const results = await catalog.search(query, category);
return { products: results };
},
});
ポイントは、execute がブラウザ内で動くことです。サーバーに新しいエンドポイントを生やすのではなく、サイトが既に持っているフロントエンドのロジックや認証済みセッションをそのまま使い、「検索する」「カートに入れる」「フォームを送信する」といった操作を、エージェントが曖昧さなく呼び出せる契約（コントラクト）として差し出します。HTML属性で宣言する宣言型のやり方も提案されており、単一ページアプリ向けに registerTool() / unregisterTool() で画面状態に応じてツールを出し入れすることもできます。
学術研究でも、スクリーンショットやDOM操作に頼る方式に比べ、WebMCP型のクライアントサイド連携がトークン効率と信頼性を改善すると報告されています（arXiv: webMCP）。「画面を見せて推測させる」から「やれることを構造化して渡す」への移行は、速度・安定性の両面で理にかなっています。
サーバーサイドMCPとの違い——競合ではなく“もう一つの層”
ここで誤解しやすいのが「WebMCP＝ブラウザ版のMCP」という捉え方です。正確には別の層を埋めるもので、両者は補完関係にあります。
| 観点 | サーバーサイドMCP | WebMCP |
|---|---|---|
| 実行場所 | サーバー（Node等のプロセス、stdio/HTTP） | ブラウザ（ページのコンテキスト内） |
| 公開するもの | バックエンドのツール・データ・SaaS連携 | いま開いているページの操作・状態 |
| 認証 | サーバー側の資格情報・トークン | ユーザーの既存ログインセッションを流用 |
| 向くタスク | 社内システム・DB・ワークフロー（ページ非依存） | ライブ検索・購入導線・編集など“見ている画面”での操作 |
実務的な指針はシンプルです。ページを開いて操作する文脈ならWebMCP、ページに依存しないバックエンド連携ならサーバーサイドMCP。両者は「AIエージェント時代のプロトコルスタック」として、しばしば三層で語られます——MCP（サーバーのツール）＋ A2A（エージェント同士の連携）＋ WebMCP（ページ＝Webの操作）（The New Stack）。WebMCPは、これまで埋まっていなかった「クライアント／ページ」のスロットを担います。
いま、どこまで実在するのか——標準化と提供状況
「提案標準」という言葉の温度感を正確に押さえておきます。WebMCPはW3CのWeb Machine Learning Community Groupのドラフトであり、正式なW3C勧告（Recommendation）トラックには乗っていません。コミュニティグループの草案という段階です。
提供のタイムラインは次の通りです。
- 2026年2月：Chrome 146が、フラグで有効化する形の早期プレビューを追加（Chrome Canary）。
- 2026年5月18〜19日（Google I/O 2026）：WebMCPをChrome 149のオリジントライアルに進めると発表。あわせて、サイトが構造化ツールを宣言する方法の公式ドキュメントが公開された（Chrome for Developers: origin trial）。
つまり本記事執筆時点（2026年6月）でWebMCPは、**「一部ブラウザで試せる実験段階」**です。APIの名前や形（命令型／宣言型）はまだ動いており、本番採用というより「自社のWeb資産をエージェント対応にする準備を始める」フェーズと捉えるのが妥当です。確定仕様として実装を急ぐ段階ではない——ここを取り違えないことが、過剰投資を避ける第一歩です。
標準が固まる前から「Webサイト＝エージェントの入口」という前提自体は進みます。検索・推薦・購入をエージェントが代行する世界では、自社サイトが構造化ツールを出していなければ、エージェントは結局スクレイピングで“推測”するか、対応済みの競合サイトに流れます。仕様の確定を待つのと、設計の検討を始めるのは別問題です。
見落とされがちな本題：未知のエージェントに「操作」を渡すリスク
エンタープライズにとって、WebMCPの本当の論点は利便性ではなくセキュリティと統制です。ツールのコントラクトは、要するに**「訪れたあらゆるエージェントに対して、どんな操作が・どんな引数で・どんな状態遷移を伴って可能か」を機械可読で開示する“API仕様書”**です。相手は信頼できるとは限りません。
Chrome自身が、WebMCPがAIエージェントの乗っ取り（hijack）に悪用され得ると明確に警告しています（Search Engine Journal）。具体的には次のような経路です（Chrome for Developers: tool security）。
- ツール定義への隠し命令：ツール名・説明・引数に、エージェントを乗っ取る指示を仕込む。
- ツール応答経由の間接プロンプトインジェクション：一見信頼できるサイトでも、リアルタイムの応答（ユーザーのコメント等の第三者データ）に悪意ある指示が混入する。
LLMは命令もデータも「ひとつのトークン列」として扱うため、間接プロンプトインジェクションに本質的に弱い——これはMCP全般に共通する構造的弱点で、WebMCPでは「自社サイトがその注入経路になり得る」という点が新しいのです。Chromeのガイダンスは「攻撃者はツール説明・出力・第三者コンテンツに悪意ある指示を置くことに成功する」と最初から想定し、アクセス制御・コンテンツ隔離・人間による監督・監視・独立した検証を組み合わせた多層防御を推奨しています（Chrome for Developers: agent security）。
この構図は、homulaが繰り返し説いてきた「無人で走るエージェントに鍵を渡さない」設計とまったく同じです。WebMCPは攻撃面を自社のWebフロントにも拡張する——だからこそ、便利さの前に統制の設計が要ります。
homulaの視点：三層を別々に守らず、ひとつのガバナンスに束ねる
WebMCPの登場は、エンタープライズに「層が増えた」という現実を突きつけます。サーバーサイドMCPで社内システムをつなぎ、A2Aでエージェントを協調させ、WebMCPで顧客接点のWeb操作を開く——入口が増えるほど、ばらばらに守ると穴が空く。homulaの基本方針は、これらをひとつのガバナンスに束ねることです。
homulaのAgensは、MCPを活用したエンタープライズ向け統合プラットフォームとして、200以上のツールと構築ゼロで接続します。WebMCPのような新しい層が増えても、エージェントから見た接続点と権限の付与を共通の枠組みで扱えるようにしておくことで、層ごとに連携を作り込む保守負債を避けられます。
そして、本記事で見た「未知のエージェントに操作を渡す」リスクに直接効くのがAgens Controlです。承認フロー・DLP・5年分の監査ログ・RBACをセットで提供し、**「誰の・どのエージェントが・どのツールを・どの権限で呼んだか」**を、サーバー側であれWeb側であれ横断的に追える状態をつくります。WebMCPが推奨する多層防御の「アクセス制御・人間による監督・監視」を、技術ごとに作り直すのではなく、企業全体の統制に乗せる発想です。
導入の順序としては、いきなりWeb全体をエージェント対応にするのではなく、(1) リスクの低い読み取り系の操作（検索・参照）から限定公開 → (2) 承認・監査の境界をAgens Controlで設計 → (3) 書き込み系（送信・購入・更新）を段階的に解放、が現実的です。homulaのAIエージェント・ブートキャンプでは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で行い、この最初の一歩を素早く形にします。
まとめ
WebMCPは、エージェントの相互作用を「画面を読む」から「ツールを呼ぶ」へ移す、Webの新しい層です。GoogleとMicrosoftが共同で進める提案標準で、Chrome 149のオリジントライアルとして試せる段階にあり、まだ確定仕様ではありません。だからこそ、本番実装を急ぐより、自社のWeb資産をエージェント対応にする「準備」と、増える入口をどう統制するかの「設計」を先に進めるのが賢明です。
要点は二つ。第一に、WebMCPはサーバーサイドMCPの代替ではなく補完であること——MCP・A2A・WebMCPの三層を前提に役割を切り分けること。第二に、ツールの公開は未知のエージェントへのAPI開示であり、間接プロンプトインジェクションを織り込んだ多層防御が不可欠であること。便利さは、統制の上にしか乗りません。
エージェントが使えるWebは、これから企業の競争条件になります。自社のどの操作を・どの順序でエージェントに開き、どこで承認・監査の境界を引くか——標準の確定を待つ前に、層をまたいだガバナンスの設計から始めることが、安全な先行のカギです。