# WebサイトをAIから操作しやすくする WebMCPの導入で誰の仕事が変わるか

- 媒体: 知能圏（CHINOUKEN）
- 公開日: 2026-08-17
- カテゴリー: エージェント・ソフトウェア
- タグ: WebMCP、ブラウザ、標準化
- 想定読了時間: 約20分
- 調査基準日: 2026年8月17日
- 出典: 16件（末尾の「参照リンク」に番号順で記載）
- ページ: https://www.chinouken.com/articles/webmcp-who-builds-and-uses
- このMarkdown: https://www.chinouken.com/articles/webmcp-who-builds-and-uses.md
- 利用条件: 引用する場合は出典として「知能圏（chinouken.com）」と該当ページのURLを明記してください。本文の再配布は行わず、要約や引用の範囲で使ってください。

WebMCPは、WebサイトがAIへ検索や入力補助の操作を明示する提案です。サイト側の実装とブラウザ側の対応がそろって初めて使えます。手元のChromeではAPIが利用できなかったため、会議室検索の通常画面と入力検査を試し、実行できた部分と仕様だけを確認した部分を分けて説明します。

![一つのWebサイトが人の見る画面とAIの使う操作口を持ち、同じアプリの状態へつながる概念図](https://www.chinouken.com/images/articles/webmcp-who-builds-and-uses/hero.png)

*WebMCPは画面を消すのではなく、同じWebアプリへAIが迷いにくい操作口を加えます。*

## 利用者は画面を開いたまま仕事を頼む

WebMCPが目指す体験は、利用者とAIエージェントが同じWebページを見ながら仕事を進めることです。たとえばホテル予約サイトを開き、『東京駅から30分以内、朝食付きで二泊できる部屋を探して』とブラウザ内のエージェントへ頼みます。サイトが検索条件の入力や候補表示をWebMCPのツールとして登録していれば、エージェントは画面上の入力欄を一つずつ推測せず、用途と入力形式が明示された操作を選べます。

便利さの条件は、サイトが現在のページ状態とログイン状態を使って操作を実行できることです。検索結果を画面へ反映し、選択中の部屋や日付を保ったまま人へ確認を返せます。同じ仕組みは、エージェントがログイン済みの権限で購入、投稿、削除などを行える可能性も作ります。

設計課題は、エージェントにサイト全体を自由操作させるかどうかの二択ではありません。サイトがどの操作を登録し、ブラウザが誰へ見せ、エージェントがどの条件で呼び、どの操作を人の確認で止めるかを分担する必要があります。WebMCPは、その分担に使うWeb標準の候補です。

## APIが使えないブラウザでも検索を残す

2026年9月5日、手元のChrome 152で、架空の会議室を人数で探すローカルページを開きました。公式資料のdocument.modelContextと、以前の入口であるnavigator.modelContextは、どちらもundefinedでした。この環境ではWebMCPの登録と呼び出しへ進めず、通常の画面操作だけを試しています。

入力に4人を指定すると定員4人と8人の二部屋、6人では定員8人の一部屋が表示されました。0人では「人数は1〜20の整数を指定してください」と返りました。WebMCPの入口がなくても、同じ検索処理をボタンから使い、入力の誤りを処理側で止められました。

ここで分かったのは、仕様に沿ったコードを用意することと、そのブラウザで使えることは別の確認になる点です。提供条件とAPIの存在を先に調べ、通常の画面で動く処理を残したうえで、対応環境で登録・発見・呼び出しを検証します。今回の結果をWebMCP経由の実行成功や、すべてのChrome 152での非対応とは扱いません。

## 誰が作り ブラウザのどこで動くのか

『誰がWebMCPを作るのか』には、仕様、ブラウザ機能、サイトのツール、AIエージェントという異なる成果物が含まれます。一社が一式を作って利用者へ渡す構造ではありません。サイト開発者が自分のページへツールを登録し、ブラウザ事業者がその登録と呼び出しを実装し、エージェント開発者が利用機能と安全策を作ります。

現行の仕様草案は、W3CのWeb Machine Learning Community Groupが公開しています。編集者はMicrosoftのBrandon Walderman、GoogleのKhushal SagarとDominic Farolinoです。W3Cの名前が付いていても、現時点ではW3C標準でも標準化過程の勧告候補でもなく、コミュニティグループの草案です。

ブラウザ内の位置で見ると、WebMCPはページのJavaScriptとブラウザ側のエージェントの間にあります。ツールは開いている文書へ結び付いて動き、ページを閉じれば原則として使えなくなります。AIモデル自体がクラウドにあっても、道具の発見とページへの受け渡しはブラウザ側の機能が担います。

サイトの裏側にある在庫、決済、会員情報、業務ルールは残ります。WebMCPの実行処理は、既存のJavaScriptからサーバーAPIを呼ぶことも、表示状態だけを変えることもできます。重要操作では、画面から操作した場合と同じ認可、入力検証、監査記録を通します。

![利用者、ブラウザ内のAIエージェント、WebMCP、ページ処理、画面、業務サーバーのアクセス関係図](https://www.chinouken.com/images/articles/webmcp-who-builds-and-uses/figure-browser-boundary.png)

*WebMCPが追加するのは、開いているページとAIの間の操作契約です。既存の画面、サーバー、認可はそのまま使います。*

**WebMCPに関わる五つの役割**

| 役割 | 作るもの | 主な責任 |
| --- | --- | --- |
| 仕様の策定者 | 共通APIと安全上の規則 | 公開議論と仕様草案 |
| ブラウザ事業者 | APIの実装と仲介機能 | 出所、権限、発見、呼び出し |
| Webサイト開発者 | ページ内のツール | 説明、入力、実行、結果 |
| エージェント開発者 | AIによる利用機能 | 選択、安全策、承認 |
| 利用者 | 目的と最終判断 | 依頼、条件追加、重要操作の確認 |

## 一つの予約で追う実行の流れ

ホテル検索から予約までを追うと、各役割の受け渡しが見えます。利用者はサイトを開いて必要なら自分でログインし、ページは現在使える検索や候補表示のツールをブラウザへ登録した状態です。利用者が地域、日付、人数、予算を伝えると、エージェントは登録済みツールの説明と入力形式を読み、目的に合うものを選びます。

エージェントは依頼を構造化した引数へ変換し、ブラウザへ呼び出しを要求します。ブラウザがページの実行処理へ渡した後、ページが使うのは既存の検索処理やサーバーAPIです。候補が画面へ表示され、結果がエージェントへ返ると、エージェントは元の条件と照合し、不足があれば質問するか別の検索を行います。

予約確定や決済の前では、内容と金額を画面へ示し、利用者の確認を求めます。提案文書が目標とするのは、タブを開いた人が進行を見て制御できる共同作業で、画面なしの大量実行や完全自律処理は対象外です。

![利用者の目的からツール選択、引数への変換、ページでの実行、画面確認、条件不足時の再検索までの流れ](https://www.chinouken.com/images/articles/webmcp-who-builds-and-uses/figure-request-loop.png)

*自然言語の依頼をそのままサイトへ投げず、登録済みツールと入力形式を介してページ処理へ渡します。*

## サイト開発者が選べる実装方法

Webサイト側には、既存のフォームを使う宣言型APIと、JavaScriptで処理を登録する命令型APIがあります。どちらも、サイトが『このページでは何ができるか』をツールとして表現する方法です。

宣言型APIは、HTMLフォームへtoolnameとtooldescriptionを加えるだけで、ブラウザが既存のinputやlabelから入力形式を組み立てます。下の例では、エージェントが宿泊日と人数を入力してフォームへ焦点を当てますが、自動送信を指定していないため、利用者は画面で確認して検索ボタンを押せます。

命令型APIのツール登録は、document.modelContext.registerTool()へツール名、説明、JSON Schemaによる入力形式、実行処理を渡す形です。下の検索ツールは読み取り専用で、既存のsearchRooms()を呼び、同じ候補を画面とエージェントの両方へ返します。WebMCP用に業務処理を作り直すのではなく、既存のページ処理へ明示的な入口を付けるイメージです。

このAPIは提案中に変わっています。Chrome 150では以前のnavigator.modelContextが非推奨になり、現行文書はdocument.modelContextを使います。冒頭の記事にあるnavigator.webMCP.registerTool()やwebmcp-tool属性は、2026年8月時点の公式APIと一致しません。試すときはChromeの試験環境と最新資料が必要です。

**既存フォームをツールとして見せる**

```HTML
<form
  toolname="searchRooms"
  tooldescription="宿泊日と人数から空室を検索する"
>
  <label>
    チェックイン
    <input name="checkIn" type="date" required>
  </label>
  <label>
    人数
    <input name="guests" type="number" min="1" required>
  </label>
  <button type="submit">空室を検索</button>
</form>
```

**JavaScriptで検索ツールを登録する**

```JavaScript
await document.modelContext.registerTool({
  name: "search_rooms",
  description: "宿泊日と人数から空室を検索する",
  inputSchema: {
    type: "object",
    properties: {
      checkIn: { type: "string", format: "date" },
      guests: { type: "integer", minimum: 1 }
    },
    required: ["checkIn", "guests"]
  },
  annotations: {
    readOnlyHint: true,
    untrustedContentHint: true
  },
  async execute(args) {
    const rooms = await searchRooms(args);
    renderRooms(rooms);
    return { rooms };
  }
});
```

**Webサイトがツールを登録する二つの方法**

| 方法 | 使うもの | 向く操作 |
| --- | --- | --- |
| 宣言型API | HTMLフォームの属性 | 問い合わせ、申請、予約条件 |
| 命令型API | JavaScriptの登録処理 | 検索、絞り込み、状態変更 |

## メリットは操作の速さより曖昧さの削減

WebMCPの価値を『AIがクリックを速くする』だけで捉えると小さく見えます。価値の中心は、サイトが操作の意味、必要な入力、返す結果を先に示し、エージェントの推測を減らすことです。ボタンの位置やCSSが変わっても、ツールの契約が保たれれば同じ目的を実行できます。

利用者はフォーム間の転記を減らし、サイトは壊れやすい画面解釈に依存されにくくなります。エージェントは少ない手順で候補を取得し、ブラウザは出所とタブの境界を使って仲介できます。一方で、サイトにはツール説明とSchemaの保守、エージェントには不正な返却値の隔離、利用者には重要操作の承認が残ります。

この変化は、全員が単純に得をする自動化というより、曖昧な画面操作を、誰が作り、誰が許可し、どこで実行したか説明しやすい契約へ置き換える試みです。信頼性の向上と同時に、責任の境界も表へ出ます。

**関係者ごとに変わることと残る責任**

| 関係者 | 得られるもの | 残る責任 |
| --- | --- | --- |
| 利用者 | 目的から候補表示までの手数を減らす | 条件追加と重要操作の最終確認 |
| Webサイト | 操作の意味を自社で明示できる | Schema、認可、監査、互換性の保守 |
| AIエージェント | DOM推測を減らし構造化結果を得る | ツール選択、未信頼情報の隔離、承認 |
| ブラウザ | ページとAIの共通仲介点になる | 出所、権限、可視性、停止手段 |
| 業務サーバー | 既存APIと業務ルールを再利用する | 認証、整合性、二重実行の防止 |

## 向くのは画面とAIが共同で進める仕事

WebMCPに向くのは、利用者がすでにサイトを開き、現在の画面やログイン状態を使いながら、いくつかの条件をまとめて処理したい仕事です。検索、絞り込み、入力補助、下書き、比較のように、結果を画面で確かめられる操作ほど始めやすくなります。

旅行なら条件に合う便や部屋の検索、ECなら用途と予算から候補を絞る処理、SaaSなら期間を指定したレポート作成、サポートなら注文状態を参照した問い合わせ下書きに使えます。購入、返金、公開、削除まで進める場合は、検索や下書きと別のツールへ分け、直前に人へ確認を返します。

反対に、画面を開かない定期集計、大量の背景処理、複数サービスを長時間横断する自律処理に合うのは、MCPや通常のAPI、ジョブ基盤の方です。見た目、地図、文章の微妙な差を人が判断する仕事では、WebMCPだけで画面を置き換えられません。

**WebMCPを試しやすいユースケース**

| 分野 | 最初のツール | 人が確認する点 |
| --- | --- | --- |
| 旅行 | 条件から便や客室を検索 | 日程、料金、キャンセル条件 |
| EC | 用途と予算から商品を絞る | 仕様、数量、購入金額 |
| 業務SaaS | 期間を指定してレポート作成 | 対象範囲、共有先 |
| 顧客サポート | 注文状態を読み問い合わせを下書き | 送信内容、返金や変更 |
| 開発者向け画面 | ログ条件を指定して障害候補を抽出 | 原因判断、修正の実行 |

## MCPとの違いは場所と寿命

WebMCPとModel Context Protocol（MCP）は、どちらもAIへツールの名前、説明、入力形式を見せますが、同じ通信規格ではありません。MCPはAIアプリと外部のサーバーを接続するためのクライアント・サーバー型プロトコルです。WebMCPはその考え方を参考に、ブラウザの文書、オリジン、権限、タブの寿命へ合わせて作られたWeb APIです。

『MCPはバックエンド、WebMCPはフロントエンド』という説明は入口としては便利ですが、境界を単純化しすぎます。WebMCPのツールからバックエンドAPIを呼ぶことはでき、MCP側も画面を返す構成を持てます。実務上の違いは、エージェントがサービスへ直接つながるのか、利用者が開いているページをブラウザ経由で使うのかです。

**MCPとWebMCPの主な違い**

| 観点 | MCP | WebMCP |
| --- | --- | --- |
| 接続先 | 外部のMCPサーバー | 開いているWebページ |
| 実行場所 | ローカル処理または遠隔サーバー | ページのJavaScript環境 |
| 寿命 | 接続やサービスが続く間 | 原則としてページを開いている間 |
| 現在状態 | サーバー側の状態 | 画面とログイン状態を共有しやすい |
| 主な用途 | 外部操作と背景処理 | 表示中サイトで人と共同操作 |

## 画面操作との併存

WebMCPが広がっても、スクリーンショット、文書構造、アクセシビリティ情報を読んでクリックする画面操作は残ります。WebMCPのツールは、サイト開発者が登録した機能しか扱えず、エージェントはサイトを訪れるまでツールの存在を知れません。ツールがない処理や未対応サイトでは、従来の画面操作へ戻る必要があります。

サイト側も、すべてのボタンを一対一でツールにする必要はありません。検索、絞り込み、下書き作成、入力補助のように、画面解釈では手順が多く、目的と入力を明確に表せる操作から登録する方が適しています。見た目を比較する、地図上の位置を判断する、微妙な編集結果を確認する仕事では、画面そのものが重要です。

WebMCPは人向け画面を消す仕組みではなく、同じWebアプリへ機械が迷いにくい操作口を加える仕組みです。人向けの表示とエージェント向けのツールは、同じ状態を共有しながら役割を分けます。

## 仕様だけでは安全にならない

WebMCPは、エージェントがログイン済みのページで動けるため、検索の効率化と購入や削除の危険が同じ接続から生まれます。仕様草案が主要な危険として挙げるのは、ツールの説明と実際の動作が一致する保証がないこと、ツールの説明や返却値に悪意ある指示が混ざるプロンプトインジェクション、必要以上の個人情報を引数へ入れる漏えいなどです。

サイト開発者は、読み取り専用のツールを明示し、外部由来の内容を信頼できないデータとして示し、公開先のオリジンを限定します。実行処理では、画面から操作した場合と同じ認可と入力検証を通し、同じ依頼の再実行で二重購入が起きないようにします。ツールの説明だけを安全境界にしてはいけません。

エージェント開発者は、ページやツールの文章を利用者の命令より下位の信頼できない入力として扱い、依頼に不要な別サイトとの通信を制限します。読み取り専用だと確認できない操作は状態を変えるものとして扱い、送信、購入、公開、削除では、対象と変更内容を利用者へ見せて確認を求めます。

2026年6月に公開された研究は、第三者スクリプトが実行中にツール一覧や説明を差し替える攻撃を試作し、ツール登録と呼び出しの記録、出所に結び付いた識別、ライフサイクルの整合性を対策候補に挙げました。査読前の研究ですが、ツールがいつ、どの出所から現れたかも監査対象になることを示しています。

## Chromeの実験から始まった提案

2026年8月時点のWebMCPは、複数ブラウザで安定して使えるWeb標準ではありません。Chromeは149から156までオリジントライアルを予定し、登録したサイトが実利用者の環境で試せるようにしています。ローカルでは試験用フラグを有効にでき、Chrome 149の開発者ツールには、登録ツール、入力形式、呼び出し履歴、結果を確認する試験機能が入りました。

標準化の支持も固まっていません。Mozillaの標準化姿勢は中立です。WebKitは反対を表明し、API設計、重複、国際化、移植性、プライバシー、セキュリティ、利用者の意味ある同意などへ懸念を付けています。W3Cの技術設計レビューも、複数の関係者による支持が不足している状態として継続中です。

Chromeの実験が成功しても、現在の名前やAPIがそのまま全ブラウザへ入るとは限りません。WebMCPは不可避の標準と結論づける段階ではなく、WebサイトがAIへ操作方法を明示する価値と、その権限・同意モデルを検証している段階です。

## 普及すればブラウザは操作の仲介者になる

ここからは筆者の見立てです。WebMCPの考え方が普及すると、Webサイトは人向け画面とエージェント向け操作口を同じ製品の二つの入口として設計する方向へ進みます。アクセシビリティやAPI設計に加え、『AIが操作の意味を誤解しないか』『実行結果を人が画面で確かめられるか』がフロントエンド品質の一部になります。

そのときブラウザは、文書を表示するだけでなく、どのページがどのツールを登録し、どのエージェントが呼び、いつ人へ確認を返すかを扱う仲介者になります。検索エンジンがWebページの発見を担ったように、ブラウザやエージェントがページ内の能力を発見する層になる可能性があります。ただしWebMCPのツールは、現行案ではページを訪れるまで見つからないため、検索やAPIディレクトリをそのまま置き換えるものではありません。

画面もバックエンドも消えません。画面は比較、説明、信頼、承認の場所として重要になり、バックエンドは認可、在庫、決済、監査の最終的な境界としてさらに重要になります。変わるのは、その間にあった何度ものクリックや転記が、意味付きのツール呼び出しへ圧縮される部分です。

最大の不確実性は相互運用性です。Chromeだけの機能にとどまれば、サイトは通常の画面とブラウザ固有実装を併用する必要があります。複数ブラウザとエージェントが同じ契約を使えるようになって初めて、WebMCPは『AI対応サイト』の共通基盤になります。いま見えているのは必然の未来ではなく、そのための有力な設計仮説です。

> 観測メモ: 見立て：価値の中心はUIの消滅ではなく、画面と操作契約が同じ状態を共有することです。標準化が進むほど、ブラウザはAIとサイトの権限仲介へ責任を持つようになります。

## 読み取りと入力補助から試す

導入を検討するサイトは、まず利用者が画面で繰り返している仕事を洗い出します。その中から、検索、絞り込み、状態確認、フォーム入力の下書きなど、失敗しても確認して戻せる操作を一つ選びます。標準フォームで表せるなら宣言型API、ページ固有の状態や処理が必要なら命令型APIが候補です。

次に、正しい依頼だけでなく、日付不足、曖昧な人数、上限を超える値、関係のない依頼、同じ操作の再実行を含む評価を作ります。確認するのは、エージェントが適切なツールを選べるか、誤った入力を処理側が拒否するか、画面と返却結果が一致するかの三点です。

購入、送信、削除を追加する場合は、検索や下書きと別のツールへ分け、実行直前に対象、金額、宛先、変更差分を人へ示します。未対応ブラウザやツールが見つからない場合に、通常の画面操作をそのまま使えることも確認します。

導入の成否を決めるのは、登録コードの短さより、サイト、ブラウザ、エージェントの責任を利用者から理解できる形にできるかです。実験段階のいまは、低リスクな一操作で共同作業の価値を測り、標準化と他ブラウザの動きを見ながら広げるのが現実的です。

- 読み取り、検索、絞り込み、入力下書きから一つ選ぶ
- 不足値、無効値、無関係な依頼、再実行を評価する
- 画面の状態とツールの返却結果を照合する
- 購入、送信、削除は別ツールと人の確認へ分ける
- 未対応環境では通常の画面操作へ戻せるようにする

## 参照リンク

1. [W3C Web Machine Learning Community Group: WebMCP — Draft Community Group Report](https://webmachinelearning.github.io/webmcp/)
2. [WebMCP Contributors: WebMCP Explainer](https://github.com/webmachinelearning/webmcp)
3. [Chrome for Developers: WebMCP](https://developer.chrome.com/docs/ai/webmcp)
4. [Chrome for Developers: WebMCP Imperative API](https://developer.chrome.com/docs/ai/webmcp/imperative-api)
5. [Chrome for Developers: WebMCP Declarative API](https://developer.chrome.com/docs/ai/webmcp/declarative-api)
6. [Chrome for Developers: When to use WebMCP and MCP](https://developer.chrome.com/docs/ai/webmcp/compare-mcp)
7. [Chrome for Developers: WebMCP best practices](https://developer.chrome.com/docs/ai/webmcp/best-practices)
8. [Chrome for Developers: WebMCP tool security](https://developer.chrome.com/docs/ai/webmcp/secure-tools)
9. [Chrome for Developers: Agent security considerations for WebMCP](https://developer.chrome.com/docs/agents/security)
10. [Chromium blink-dev: Intent to Experiment: WebMCP](https://groups.google.com/a/chromium.org/g/blink-dev/c/gmYffo5WOE8/m/OJxuQRP3AAAJ)
11. [Mozilla Standards Positions: WebMCP #1412](https://github.com/mozilla/standards-positions/issues/1412)
12. [WebKit Standards Positions: WebMCP #670](https://github.com/WebKit/standards-positions/issues/670)
13. [Chrome for Developers: What's new in DevTools 149](https://developer.chrome.com/blog/new-in-devtools-149)
14. [Model Context Protocol: Architecture](https://modelcontextprotocol.io/specification/2025-06-18/architecture)
15. [Lee et al.: WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents](https://arxiv.org/abs/2606.06387)
16. [W3C Technical Architecture Group: Incubation: WebMCP #1238](https://github.com/w3ctag/design-reviews/issues/1238)

2026年8月17日時点の公式資料を確認しています。仕様は更新される可能性があります。

---

© 知能圏 https://www.chinouken.com/articles/webmcp-who-builds-and-uses