WebMCPとMCPの違いは?使える場所とサイト側の対応を整理

「WebMCP」はMCPと名前が似ていますが、MCPの新しい版でも、MCPの代わりでもありません。MCPがAIを外部のサービスへつなぐ常設の接続口なのに対し、WebMCPは開いているWebページ自身がAIに「使える操作」を差し出す仕組みです。

本記事では、両者の違いを公式資料で整理し、2026年10月時点で使える場所と、MCPを使う側・サイト運営者のそれぞれが今やることをまとめます。

WebMCPとは?

Webページが「AIに使わせる操作」を自分で差し出す仕組み

WebMCPは、Webサイトが「検索する」「予約する」といった操作を、AIエージェント向けの道具(ツール)として登録しておく仕組みです。AIは画面のボタンを見て意味を推測せず、サイトが用意した道具を直接呼び出します。要素は3つです。

  • 道具の発見:ページが「checkout」「filter_results」のような道具をAIに知らせる決まった方法があります。
  • 入力の型:道具に渡す値と返る値をJSON Schemaで明示し、AIの思い違いを減らします。
  • ページの状態:いま開いているページで何を操作できるかを、AIとページが共有します。

図解:WebMCPとは?

W3Cの正式な標準ではなく、提案段階の仕様

仕様書はW3C(Webの標準を作る団体)のWeb Machine Learning Community Groupが公開しており、最新版は2026年10月9日付の「Draft Community Group Report」です。編集者はMicrosoftのBrandon Walderman氏、GoogleのKhushal Sagar氏とDominic Farolino氏の3名です。WebMCPの仕様書の冒頭には、位置づけが次のように書かれています。

It is not a W3C Standard nor is it on the W3C Standards Track.(W3Cの標準ではなく、W3Cの標準化の手順にも乗っていません)

名前や書き方は今後変わる前提で読む必要があります。

WebMCPとMCPの違い

違いを表で比べる

Chromeの公式解説の比較表をもとに、「誰が用意するか」の行を加えて整理しました。

比べる点 MCP WebMCP
目的 AIがいつでもどこでもデータと操作を使えるようにする サイトを開いたときに、AIがすぐ操作できるようにする
存在する期間 常設(サーバーとして動き続ける) その場限り(タブを開いている間だけ)
使える範囲 パソコン・スマホ・クラウド・Webのどこからでも ブラウザに組み込まれたAIエージェントだけ
画面との関係 画面を持たず、外部から操作する ブラウザの中で、ページの中身を見ながら操作する
見つけ方 AIの側で接続先として登録する ページを開いたときに道具が登録される
用意する人 ツールやサービスの提供会社 そのWebサイトの運営者

MCPは「いつでもつながる窓口」、WebMCPは「開いているページの店員」

Chromeの解説は、MCPを「ヘルプのコールセンター」、WebMCPを「店舗の専門家」にたとえています。店員はお店にいる間だけ、目の前の商品を一緒に見ながら案内してくれます。OpenAIの説明でも、WebMCPの道具はページを閉じると使えなくなる一方、利用者は別途MCPサーバーを入れなくてもサイトの機能をAIに使わせられます。

関連記事:MCPとAPIの決定的な違い|動的連携を実現する仕組みと導入コスト

WebMCPはMCPの代わりではない

「WebMCPはMCPに取って代わるのか」という質問に対して、Chromeの公式解説ははっきり否定しています。

WebMCP は、MCP の拡張機能や代替機能ではありません。

WebMCPはMCPをそのままJavaScriptにしたものではなく、「MCPにインスパイアされたAPIのセット」とされています。OpenAIも、1つのサイトが両方に対応してよいとしています。

WebMCPを今使える場所(2026年10月時点)

ChatGPTデスクトップアプリの内蔵ブラウザ(Site tools)

OpenAIはWebMCPへの対応を「Site tools」という名前で提供しています。2026年8月下旬に提供開始が報じられました。OpenAIの公式ドキュメントは、Site toolsを次のように説明しています。

Site tools are ChatGPT's implementation of the proposed WebMCP standard.(Site toolsは、提案中のWebMCP標準をChatGPTが実装したものです)

ChatGPTデスクトップアプリの内蔵ブラウザでサイトを開くと、ChatGPT WorkとCodexがそのページの道具を見つけて使います。道具の一覧はアドレスバーの「Site tools」から確認でき、OpenAIのドキュメントサイト自体も検索(search_openai_docs)など5つの道具を用意しています。

使える条件:モデル・プラン・設定

  • モデル:GPT-5.6 SolかGPT-6 Solを使います。
  • 使えないモデル:GPT-5.6 LunaではWebMCPが現在無効です。
  • Enterprise:管理者がワークスペースのポリシーでSite toolsを許可する必要があります。
  • Edu:教育機関向けのワークスペースでは使えません。
  • アプリ:ChatGPTデスクトップアプリを最新版にします。

提供は順次です。止めたい場合は、設定のブラウザ権限(英語表記で「Settings > Browser > Permissions」)にある「Enable site tools」をオフにします。

まだ使えない書き方:HTMLフォーム型とiframe内の道具

ChatGPTの内蔵ブラウザが対応しているのは、WebMCPの一部だけです。HTMLのフォームに属性を付けて道具にする書き方(宣言型API)と、iframe(ページ内に埋め込んだ別ページ)の中で登録した道具は認識されません。ChatGPTで使わせるには、JavaScriptでトップのページに道具を登録します。

Chromeの試験提供(origin trial)

Chromeの開発者ガイドによると、サイト運営者はChrome 149からWebMCPのorigin trial(期間限定の試験提供)に参加できます。手元で試すだけなら、Chromeで「chrome://flags/#enable-webmcp-testing」を有効にします。Webアプリの開発フレームワークでは、Angularが試験的に対応しています。

ただし人が画面を見ている前提の仕組みで、画面を持たない自動実行(ヘッドレス)向けではありません。

サイト側はどう対応するのか

書き方は2種類:JavaScript型とHTMLフォーム型

  • 命令型API(JavaScript):フォーム入力・ページ移動・状態の管理など、さまざまな道具をJavaScriptで定義します。
  • 宣言型API(HTMLフォーム):ふつうのHTMLフォームに注釈を付けて、そのまま道具にします。

ChatGPTの内蔵ブラウザで使えるのは今のところ命令型だけなので、始めるなら命令型が確実です。

注釈で「読むだけ」「重要な操作」を申告する

道具には「注釈(annotations)」を付けられます。仕様で定められているのは次の4つで、初期値はどれも「false(付けない)」です。

  • readOnlyHint:読み取りだけの道具であることを示す目印です。
  • consequentialHint:結果の重い操作であることを示す目印です。
  • untrustedContentHint:信頼できない内容を扱うことを示す目印です。
  • debugging:開発時のデバッグ用であることを示す目印です。

このうちconsequentialHintは後から加わったもので、2026年7月に提案され、9月に仕様へ取り込まれました(GitHubの提案 #217)。仕様が決めているのは名前と初期値までで、注釈を受けたAIがどう振る舞うかは、各ブラウザやエージェントの実装に任されています。

公式のコード例

OpenAIの公式ドキュメントに載っている、ページのタイトルを返すだけの読み取り専用の道具です。ブラウザが対応しているかを先に確かめてから、document.modelContext.registerToolで登録しています。

if (typeof document.modelContext?.registerTool === "function") {
  await document.modelContext.registerTool({
    name: "get_page_title",
    description: "Read the title of the current page.",
    inputSchema: {
      type: "object",
      properties: {},
      additionalProperties: false,
    },
    annotations: { readOnlyHint: true },
    execute: async () => ({ title: document.title }),
  });
}

古い解説記事にはnavigator.modelContextという書き方が出てくることがあります。現在の仕様とOpenAIの例はdocument側に登録する形なので、書き写す前に最新の仕様書で確かめてください。

安全面の注意と、批判の声

サイトが出す道具は「信用しない前提」で扱われる

OpenAIは、サイトが提供する道具を初めから信用しない前提で扱うと明記しています。

Website-provided tool definitions and results are untrusted content.(Webサイトが提供する道具の定義と結果は、信頼できない内容です)

道具の名前や「読み取りだけ」という申告は、実際の動きの証拠にはならない、とも書かれています。内蔵ブラウザでは呼び出しのたびに実行前の安全確認が入り、送信・購入・削除・権限変更のような重い操作には通常の確認がそのまま適用されます。

「アクセシビリティの仕組みで足りる」という反対意見

WebMCPそのものに疑問を投げる声もあります。2026年2月にGitHubで起票された議論 #91では、「アクセシビリティツリー(読み上げソフトなどがページの構造を理解するための情報)がすでに何を操作できるかを機械に伝えているので、別の仕組みは要らない」という主張が出ました。ページの説明が二重になり、時間がたつとずれていく、という指摘です。

今やること:使う側とサイト運営者で分けて考える

MCPサーバーを使う側:これまで通りでよい

社内システムやSaaSをMCPでAIにつないでいるなら、WebMCPが出てきたからといって作り直す必要はありません。ページと関係なく裏で動く連携は、これからもMCPの役割です。

関連記事:MCPサーバー カオスマップ|カテゴリで探すインタラクティブ一覧

サイト運営者:仕様は変わる前提で、小さく試す

OpenAIは、アプリがすでに持っている操作から始めることを勧めています。例として、ダッシュボードの期間を切り替えてグラフの元データを見せる道具や、文書の該当箇所を探してコメントを残す道具が挙がっています。

注意点は、入力を絞る・副作用(何が変わるか)を説明に書く・認証や権限はアプリの既存の仕組みを使う・対応していないブラウザのためにふつうの画面を残す、の4つです。仕様は提案段階なので、読み取り専用の道具1つから始めれば、書き直しになっても影響は小さく済みます。

まとめ

  • WebMCPは、開いているWebページがAIに道具を差し出す仕組みで、MCPの代わりではありません。
  • MCPは常設の接続口、WebMCPはタブを開いている間だけの道具という違いがあります。
  • 仕様はW3Cの正式な標準ではなく、コミュニティでの提案段階です。
  • 2026年10月時点で使えるのは、ChatGPTデスクトップアプリの内蔵ブラウザ(Site tools)とChromeの試験提供です。

MCPを使っている方は今の連携をそのまま続け、サイト運営者は自社サイトの操作のうち「AIに任せたい読み取り系の操作」を1つ書き出すところから始めてください。

メルマガ登録CTA B2(MCPカオスマップ無料プレゼント)