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

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

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

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

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を呼ぶことも、表示状態だけを変えることもできます。重要操作では、画面から操作した場合と同じ認可、入力検証、監査記録を通します。

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

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

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

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の試験環境と最新資料が必要です。

<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>

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 };
  }
});

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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対応サイト』の共通基盤になります。いま見えているのは必然の未来ではなく、そのための有力な設計仮説です。

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

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

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

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