2026年10月のWebMCP：ウェブサイトをAIエージェントに使えるようにする方法と、オリジントライアルが実際に意味すること

WebMCPを使うと、ウェブページはAIエージェントに、できることの短い一覧を渡せます。各項目には名前、説明、入力スキーマがあります。エージェントがスクリーンショットとDOMからページの仕組みを推測する必要はありません。エージェントがcheck_order_statusというツールを見つければ、注文番号を渡して呼び出せます。このツールがなければ、エージェントは正しい入力欄を探し、正しいボタンをクリックしなければなりません。

これが期待されている姿です。2026年10月22日時点の状況は、多くの解説記事が伝えるよりも限定的です。WebMCPはW3Cコミュニティグループの提案であり、標準ではありません。Chromeはオリジントライアルとして実行しており、正式に搭載するかどうかはまだ決まっていません。ツールを呼び出す一般消費者向けのエージェントは1つ（ChatGPTデスクトップアプリに組み込まれたブラウザ）だけで、そのエージェントは、10月8日に仕様から削除された宣言型のフォーム版を無視します。Safariのエンジンチームは提案に反対しており、Mozillaは中立です。

この記事は、今WebMCPを追加すべきかどうかを判断する開発者とプロダクトオーナーに向けたものです。APIの内容、誰がそれを呼び出すのか、実際の訪問者に向けて有効にする方法、エージェントに危険なものを持たせないツールの書き方、そしてエージェントに自社サイトを使ってもらいたい場合にまず何を直すべきかを取り上げます。

WebMCPとは

仕様は、ページがツールを登録するためのdocument.modelContext上のJavaScript APIを定めています。「WebMCP APIは、ウェブアプリケーションがJavaScriptベースのツールをAIエージェントに提供することを可能にする」。ツールにはname、description、executeコールバックがあり、任意でtitle、inputSchema（JSON Schema）、annotationsを指定できます。エージェントがツールを呼び出すと、ページ自身のコードがユーザーのセッションで実行されます。

誤解しやすい点が3つあります。

• 標準ではありません。 この文書はWeb Machine Learning Community GroupのDraft Community Group Reportで、そのことが明記されています。「W3C標準ではなく、W3C標準化トラックにも載っていない」。Chrome自身のドキュメントも「提案されているウェブ標準」と呼んでいます。報告書の日付は10月中、数日ごとに変わっており、編集者はMicrosoftとGoogleの所属です。
• MCPは含まれていません。 仕様は、これを使うページは「クライアントサイドのスクリプトでツールを実装するModel Context Protocolサーバーと考えることができる」としたうえで、「ツールがブラウザエージェントに公開される形式を定めるものではない」と述べています。Mozillaのレビューははっきり指摘しました。「名前は誤解を招く……ここにMCPはない」。WebMCPのツールは御社のバックエンドのMCPサーバーにはつながらず、その代わりにもなりません。
• 見つけてもらえるようにはなりません。 Chromeのドキュメント自身が制約を挙げています。「ツールを呼び出せるかどうかは、クライアントやブラウザがサイトを直接訪れなければ分からない」。WebMCPが助けるのは、すでに御社のページにいるエージェントです。見つけてもらうことには何の役にも立ちません。

このAPIはセキュアコンテキストに限られ、既定の許可リストが'self'であるtoolsのPermissions Policyで制御されるため、クロスオリジンのiframeは、埋め込み元のページが許可しない限りツールを登録できません。

2026年10月22日時点の状況

当初のトライアル期間の最後のリリースであるChrome 156は、2026年10月20日に安定版チャンネルに到達しました。申請された延長の終点であるChrome 162は、2027年2月2日に安定版になる予定です。延長が有効になっているかどうかは、トライアルのコンソールからは確認できませんでした。そのため、おそらく有効だが確実ではないという前提で計画してください。

延長を申請した理由から、Chromeがもっと時間を求めている事情が分かります。「オリジントライアルのフィードバックはAPIの改善点を示しており、それを実装している」。同じスレッドで、GoogleのDominic Farolino氏は、チームが「延長期間のうちにI2Sに進みたいと考えている」、つまり搭載を申請したいと書き、「命令型APIは宣言型よりはるかに人気があるので、ユーザーのニーズに応えてそちらにより多く投資している」とも書きました。さらに、継続API、ツール安定性API、ツールのサイズ上限を試作中だとも述べています。今書いているAPIは、今後変わります。

実際にツールを呼び出すのは誰か

ツールの登録には何も要りません。使うにはエージェントが必要で、そのエージェントの一覧は短いものです。

Chrome自身のテスト用拡張機能。 Chromeのドキュメントは、デモや自社のページでツールを試すための拡張機能を2つ紹介しており、その1つがModel Context Tool Inspectorです。自分のモデルのAPIキーが必要で、Chromeは「これらの拡張機能はChrome内のGeminiとは別のものである」と注記しています。これらは開発者向けのツールであり、顧客ではありません。

ChatGPTの内蔵ブラウザ。 OpenAIのスタッフは、2026年8月25日に開発者フォーラムへの投稿で「サイトツールは、提案されているWebMCP標準のChatGPTによる実装である」と述べました。そのドキュメントには条件があります。特定のモデル、最新のデスクトップアプリ、Enterpriseワークスペースでは管理者による許可、Eduワークスペースは対象外、そして「利用可否はロールアウトにも左右される」ことです。非対応のものも挙げられています。「宣言型API：HTMLのフォーム属性で定義されたツールはサイトツールとして利用できない」、そしてiframe内に登録されたツールは、同一オリジンのものも含めて利用できません。OpenAIの指示は明快です。「JavaScriptを使い、最上位のページにツールを登録する」。ChatGPTがページのツールを認識するために、Chromeのオリジントライアルのトークンが必要かどうかは、ドキュメントに書かれていません。

Chrome内のGemini。 Googleは5月に「まもなくWebMCP APIに対応する」と述べました。その後、対応したと書かれた一次情報は見つかっていません。まだこれを前提に計画を立てないでください。

それ以外のエージェントは従来の方法に戻ります。 どのブラウザのどのエージェントも、今もこれまでどおりページを読んでいます。Chromeは自身のリスク評価でこう述べています。「Chromeのブラウザエージェントは、ユーザーの操作をシミュレートすることで、これまでどおりサイトを操作し続けられる」。OpenAIも同様です。「適切なツールがない場合でも、エージェントは通常のブラウザ機能を使えることがある」。WebMCPのないサイトがエージェントから見えないわけではありません。ボタンが壊れていて、入力欄にラベルがないサイトは、どのエージェントにとっても使いにくいのです。

命令型API

仕様が定めているのはこちらのバージョンで、ChatGPTが対応し、開発者に好まれるとChromeが述べているのもこちらです。ツールは、ページにすでにあるロジックを包みます。以下は、Chromeのドキュメントの形とOpenAIの機能検出に沿った、ログイン中の顧客向けの読み取り専用の照会です。

if (typeof document.modelContext?.registerTool === 'function') {
  const tools = new AbortController();

  await document.modelContext.registerTool({
    name: 'check_order_status',
    description: 'Look up the status and tracking link of one of the signed-in customer\'s orders by its order number.',
    inputSchema: {
      type: 'object',
      properties: {
        orderNumber: { type: 'string', description: 'Order number as printed in the confirmation email' },
      },
      required: ['orderNumber'],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber }, { signal }) => {
      const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}`, { signal });
      if (!res.ok) return `No order ${orderNumber} was found on this account.`;
      const order = await res.json();
      return `Order ${orderNumber}: ${order.status}. Tracking: ${order.trackingUrl ?? 'not available yet'}.`;
    },
  }, { signal: tools.signal });

  // When the page state no longer fits the tool:
  // tools.abort();
}

ポイントは次のとおりです。

• モデルが読むのは、名前、説明、スキーマです。 Chromeは、ツールの説明は最大500文字、パラメータの説明は150文字、ツール名とパラメータ名は30文字、ツールの出力は1.5K文字までを推奨しており、「これらの推奨値は変更されることがある」と注記しています。仕様のexplainerは「多すぎるツール（数十から数百）を公開すると、エージェントの性能が著しく低下しかねない」と警告しています。現在のページの状態に必要なものだけを登録し、残りはAbortControllerのシグナルで削除してください。
• executeの第2引数にはAbortSignalが入っているので、キャンセルされた呼び出しは、実行中のリクエストを止められます。
• アノテーションはヒントです。 readOnlyHintは照会であることを示します。consequentialHintは、予約、購入、送信、削除、送金を行うものすべてに付け、Chromeのドキュメントによれば「エージェントやブラウザが、ユーザーへの確認プロンプトを必須にできるようになる」ものです。untrustedContentHintは、レビュー、ユーザーの投稿、第三者のデータを含む出力に付けます。debuggingアノテーションはChrome 156から存在します。
• ページのコードからもツールの一覧取得と実行ができます。 document.modelContext.getTools()とexecuteTool()を使い、一覧が変わるとtoolchangeイベントが発生します。executeTool()にJSON文字列化した引数を渡す方法は、Chrome 155から非推奨です。

React、Angular、Vueにはそれぞれ実験的なヘルパーがあり、webmcp-typesのnpmパッケージはTypeScriptの型定義を提供します。navigator.modelContextを呼ぶ古いチュートリアルは古くなっています。仕様は2026年5月27日に、このAPIをdocumentに移しました。

宣言型API：Chromeのトライアルにはあるが、仕様からは外れた

宣言型のバージョンは、2つの属性で既存のHTMLフォームをツールに変えます。ほかに何も変える必要がないので、古くてフォームの多いサイトには魅力的です。

<form toolname="request_quote"
      tooldescription="Send a request for a quote. The user reviews the form and submits it."
      action="/quote" method="post">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>
  <label for="details">What you need</label>
  <textarea id="details" name="details" required></textarea>
  <button type="submit">Send</button>
</form>
<script>
  document.querySelector('form[toolname]').addEventListener('submit', (e) => {
    e.preventDefault();
    const sent = sendQuoteRequest(new FormData(e.target)); // your existing submit, returning a promise
    if (e.agentInvoked) e.respondWith(sent.then(() => 'Quote request sent.'));
  });
</script>

Chromeのトライアルでは、「エージェントがtoolnameを呼び出すと、ブラウザはフォームにフォーカスを移し、入力欄を埋める。フォームはユーザーに見えたままである」。ブラウザは、コントロールの名前、<label>、required、<select>の選択肢からパラメータを組み立てます。フォームにtoolautosubmitがない限り、「タスクを完了するには、ユーザーが手動で送信をクリックしなければならない」ので、注文の確定やリードの送信を伴うフォームにはこれが望ましい動作です。SubmitEvent.agentInvokedは、エージェントがフォームに入力したことをハンドラーに知らせ、preventDefault()の後で呼ぶrespondWith()は、結果をエージェントに返します。toolactivatedとtoolcancelのイベントは、document.modelContextにaddEventListenerで登録してください。window.ontoolactivatedとwindow.ontoolcancelは、Chrome 156以降はサポートされません。

問題はその位置づけです。explainerの直近の変更、2026年10月8日の「Remove declarative API from the spec for now」という題の変更の後、宣言型に相当するものは「別途検討されているが……現時点では仕様の一部ではない」と書かれています。ChatGPTは非対応です。Chromeは今もトライアルの中でこれを文書化しており、GoogleのFarolino氏はMozillaのスレッドで「単にレガシーなウェブサイト、特にフォーム中心のサイトのために、宣言型の提案には価値があると考えている」と主張しました。これは、実験の中のChromeの実験と考えてください。試すのは構いませんが、唯一の経路にするのは賢明ではありません。

実際の訪問者に向けて有効にする

フラグ（chrome://flags/#enable-webmcp-testing）を使うと、自分のブラウザでテスト用にWebMCPが有効になります。訪問者には何の効果もありません。訪問者に向けては、ページにオリジントライアルのトークンが必要です。

1. ChromeのWebMCPトライアルのページでオリジンを登録します。オリジントライアルは「公開されており、すべての開発者が利用できる」もので、トークンは「そのオリジンのすべてのユーザーに対して機能を有効にする」ものです。
2. ツールを公開したいすべてのページで、<head>内の<meta http-equiv="origin-trial" content="...">か、Origin-Trial:レスポンスヘッダーとしてトークンを配信します。トークンはスクリプトから注入することもできます。1つのトークンは1つのオリジンを対象とし、1つのページに複数のトークンを載せることもできます。
3. 更新します。トライアルが延長されると、Chromeは登録者に「トライアルに登録した各オリジンの新しいトークンを提供する」ことを求め、「Chromeは無効なトークンや期限切れのトークンを無視する」。期限切れのトークンは、何も表示されずに失敗します。ツールが現れなくなるだけです。
4. Edgeでは、Edgeのトライアルのページで別途登録します。その条件では「可能な限り、機能検出とグレースフルデグラデーションを適用することに同意する」ことが求められます。

LighthouseのWebMCP監査にもトライアルの登録が必要なので、トークンなしで試したサイトでは、監査が失敗します。

安全に呼び出せるツールを書く

仕様のセキュリティの節は規範的ではなく、責任がどこにあるかを率直に述べています。エージェントが操作されるのを防ぐことは「主としてエージェント自身のセキュリティモデルの責任であり、この仕様が規範として強制できるものではない」。それでも、操作されたエージェントがどこまで被害を出せるかは、御社のツールが決めます。

• ヒントは嘘をつけるので、エージェントはそれを信用しません。 仕様はこう述べています。「悪意のあるサイトは、そうしたヒントを省略したり、偽ったりできる」。OpenAIはこう述べています。「ツールの名前や、データを読むだけだという主張は、そのツールが何をするかの証明にはならない」。そのブラウザでは、すべての呼び出しに安全性の審査がかかり、購入などの操作には引き続き確認が必要です。それでも、正直にアノテーションを付けてください。慎重なエージェントがいつユーザーに尋ねるかを判断するのに使うのは、これです。
• 影響を正確に説明してください。 仕様自身が挙げる悪い例は、「現在のショッピングカートを確定する」と説明されているのに「実際には購入を実行する」ツールです。「ユーザーは何も購入するつもりがなかった」。ツールがカードに課金するなら、説明にそう書き、consequentialHintをtrueにしてください。
• 毎回サーバー側で認可してください。 ツールはユーザーのセッションで動きます。仕様には「エージェントは、ブラウザからユーザーのIDと認証コンテキストを引き継げる」とあります。ツールの呼び出しはそのユーザーからのリクエストであり、同じチェックを受けます。explainerの助言は今も有効です。「コードでは厳密に、スキーマでは緩やかに検証する」。スキーマの検証が厳しすぎると、エージェントが止まってしまうことがあるからです。
• プロンプトインジェクションを想定してください。 仕様はこれを最初に挙げており、形は3つあります。ツールのメタデータに隠された指示、ツールの出力に隠された指示、そしてツールを標的にする攻撃です。他の人が書いたテキスト（レビュー、メッセージ、商品への質問）を含む出力はuntrustedContentHintの対象とし、エージェントが指示と受け取りかねない文章ではなく、データとして返すべきです。
• ページを意図してオプトアウトしてください。 Permissions-Policy: tools=()ヘッダーを付けると、そのドキュメントと、それが埋め込むすべてのものでAPIが使えなくなります。アカウント設定、決済ページ、管理画面は候補です。

Chromeのドキュメントについて1点注意があります。そのセキュリティのページには、ツールの実行中にユーザーに尋ねるためのrequestUserInteraction()メソッドがドラフトに含まれていると書かれています。2026年10月20日の仕様のドラフトには、そのようなメソッドはなく、explainerでもユーザーの確認は未解決の問題として残っています。これを前提に設計しないでください。

SafariとFirefoxのエンジニアが反対する点

Chromeだけを対象に作る場合でも、反対意見は読む価値があります。WebMCPが実際にどうおかしくなりうるかを説明しているからです。

2026年6月3日に投稿されたWebKitの見解は、使いにくいページはHTMLとARIAで直すべきだと主張しています。「そうすれば、ユーザーも、支援技術も、エージェントも、すべてが恩恵を受ける」。そして、ツールを使うと「脆さがDOMからツールの説明に移るだけだ」としています。エージェントを、特別に扱うべきでない支援技術と位置づけ、「WebMCPはその逆で、『エージェントが操作している』ことを観測可能な事実にしてしまう」と述べています。さらに、この提案には「重大な結果をもたらす操作に対する、同意と取り消しのモデルがない」と指摘しています。

Mozillaは8月に中立と結論づけました。WebMCPは「潜在的に価値のある抽象化をもたらす」が、「実際の力学に未解決の問題が多すぎて、全面的に支持できない領域を開く」。サイトが「ページ上のユーザーの体験と一致しないツール」を提供する可能性、たとえば「通常のユーザーには見えないプロンプトインジェクション」を仕込む可能性を警告しています。Mozillaの個々のエンジニアは、命令型の関数呼び出しのプリミティブに関心を示していますが、それはMozillaとしての支持ではありません。

Chrome自身は、他のエンジンがWebMCPを採用しないリスクはユーザーにとって低いと評価しています。その裏返しとして、今のところサイトがツールを追加しても、SafariやFirefoxでは何も得られません。

今日、すべてのエージェントに有効なこと

どのブラウザエージェントも、スクリーンショット、HTML、アクセシビリティツリーを読みます。エージェントに優しいサイトについてのGoogleのweb.devのガイダンスには、エージェントは「DOMとアクセシビリティツリーを使って、操作可能な要素のすっきりした構造化リストを取得し、それを視覚的なレンダリングと照合する」とあります。実践的なリストは短いものです。

• クリックできる<div>や<span>ではなく、本物の<button>と<a>の要素を使う。
• すべての<label>を、forで入力欄に結びつける。
• 操作可能な要素の上に透明なオーバーレイを置かない。操作可能な要素は8平方ピクセルより小さくしない。
• エージェントがクリックしようとしている間にずれない、安定したレイアウトにする。

その結論はこうです。「サイトを『エージェント対応』にするために私たちが提案することはすべて、人間にとってもサイトを良くする」。これは、WebKitがWebMCPの代わりに求めていることとほぼ同じ内容でもあります。チェックアウトがアクセシビリティ監査に通らないなら、ツールを1つ書く前にそちらを直してください。

Lighthouseには、バージョン13.2.0（2026年5月1日）からAgentic Browsingのカテゴリーがあり、Chromeではバージョン150から使え、Lighthouse 13.4.1（2026年7月20日）でPageSpeed Insights APIでも有効になりました。このカテゴリーは、機械にとって重要なアクセシビリティ監査のサブセット、レイアウトの安定性、登録されたWebMCPツールとツールのないフォーム、スキーマの有効性、llms.txtファイルの有無を調べます。Chromeはこれを「情報提供のみで、ベンチマークはない」としており、0から100までのスコアはありません。llms.txtについては、Google検索自身のガイダンスが、そのようなファイルは無視するとしています。追加しても「Google検索での表示や順位に害も益もない」。Lighthouseがこのファイルを調べても、それは変わりません。

今、WebMCPを追加すべきか

Liquidテーマを使うShopifyの場合： 作業は不要です。Shopifyのストアフロント、カート、チェックアウトのツールはすでに稼働しており、「インストールも設定も必要ない」とされています。ただしShopify自身の注意書きに「エージェントの対応は、現時点ではオリジントライアルを通じたChromiumベースのブラウザに限られる」とあります。ヘッドレスのストアフロントは、Hydrogenの開発者プレビューでのみ対象です。顧客のためにWebMCPを有効にしている他のコマースプラットフォーム、決済事業者、CDNは見つかっていません。

独自開発、ヘッドレス、レガシーのサイトの場合： 利用者次第です。

• 顧客やスタッフがChatGPTデスクトップアプリのブラウザを使っているなら、最上位のページの命令型ツールだけが彼らに届きます。最も多いタスク（注文状況、空き状況、見積もり）をめぐる読み取り専用のツールを2つか3つ、機能検出の下に、オリジントライアルのトークンとともに用意し、誰かが呼び出すかどうかを測定してください。
• Chromeで手軽に試したいなら、既存のフォームに宣言型の属性を付けるのは数時間の作業です。ただし、そこで止めないでください。ChatGPTはそれを認識せず、仕様にももう含まれていません。
• エージェントが御社を訪れている証拠がないなら、まずセマンティクス、ラベル、レイアウトを直してください。その作業はすべてのエージェントと、支援技術を使うすべての人の助けになり、APIが変わっても無駄になりません。

どの場合でも、通常のインターフェースは完全な状態に保ってください。OpenAIの助言はこうです。「WebMCPに対応していない人やブラウザのために、通常のインターフェースを維持する」。

今後変わりうること

• Intent to Ship。 Chromeのチームは、延長期間のうちに申請したいと考えています。延長が認められれば、その期間はChrome 162（2027年2月2日）で終わります。搭載されれば、Chromeではトークンが不要になります。
• APIの形。 継続API（ナビゲーション後に次のページで結果を受け取る仕組み）、ツール安定性API、サイズ上限が試作されています。直近のリリースでは、window.ontoolactivatedと文字列化された引数がすでに削除されました。
• 宣言型APIの行方。 仕様からは「当面」外れていますが、Chromeのトライアルにはまだ残っています。
• 呼び出し側。 Chrome内のGeminiの対応は発表されていますが、提供されていません。仕様の実装状況のページには、MetaのRay-Ban Displayグラスのウェブアプリ向けのWebMCPが近日公開として、BraveのLeoアシスタントでの実験的な対応が載っています。

今ツールを追加するなら、次の変更が1か所の編集で済むように、1つのモジュールにまとめ、機能検出の下に置いてください。

ご相談先

当社は、ウェブサイトとそのバックエンドのうちエージェントが触れる部分を構築しています。既存の注文、予約、アカウントのロジックを包むツール、エージェントの呼び出しを、そのユーザーからのほかのリクエストと同じように扱う認可、そしてツールを作る前にサイトを使える状態にするセマンティクスとアクセシビリティの修正です。当社のAIエージェント開発とMCPサーバー構築サービスは、WebMCPのツールだけでなく、名前は似ていても別のものであるバックエンドのMCPサーバーも対象としています。

御社のサイトでエージェントに今何が見えているのか、ツールを用意すると顧客にとって何かが変わるのかを知りたい場合は、office@c9group.devまでご連絡ください。