WebMCP：Chromeであなたのサイトを「agent‑ready」にする

Sommaire

なぜ「クリックする」エージェントは壊れやすく（そしてコストがかかる）のか

今日、多くのウェブエージェントは人間のふりをしています。
彼らはスクリーンショットを読み、正しいボタンがどこにあるかを推測してクリックし、待ち、また繰り返します。

それは動作します… しかしある日、ラベルやレイアウト、フローを変更すると、
不安定、遅延、トークン消費、そして診断が難しいバグが発生します。

WebMCPは単純な考えを再導入しようとします：もしあなたのサイトが既にある操作を実行できるなら、それをきちんと記述したほうが良い。

WebMCPとは？

WebMCPはあなたのウェブインターフェースの上に「機械が読み取れる」層を追加します。
ブラウザにエージェントが提示できる**ツール（tools）**を公開します。

Chromeは補完的な2つのAPIについて説明しています：

API déclarative : HTMLフォームをツールに変換する（低い労力で大きな利得）。
API impérative : JavaScriptでツールを宣言する（より強力で柔軟）。

WebMCP vs MCP (バックエンド)

従来の Model Context Protocol (MCP) はクライアント <---> サーバーを想定しています。

あなたはサービス（Node/Python）を通してツールを公開し、エージェントはリモートでそれを消費します（例えば REST API のように）。

一方、WebMCPはタブ内で実行されます。
UI とユーザーセッションに最も近い「クライアント側の MCP サーバー」のように見ることができます。

直接の結果：

既存のフロントコード（state、auth、UIロジック）を再利用できる、
人間の介在（human‑in‑the‑loop） を適切に行える、
ただし ブラウジングコンテキスト が必要（現時点では純粋なヘッドレスは不可）。

L’API impérative : `navigator.modelContext`

L’API impérative はあなたの UI がダイナミックな場合や、フォームを介さずに構造化された結果を返したいときに使います。

知っておくべき4つのメソッド

provideContext({ tools }) : ツールのセットをすべて置き換える（SPAで便利）。
registerTool(tool) : 他を触らずにツールを追加する。
unregisterTool(name) : ツールを削除する。
clearContext() : すべてをクリアする。

ツールとは具体的に何か？

ツールは JSON 定義 + execute 関数です。
決定的なポイントは、入力を契約化する inputSchema（JSON Schema）です。

変更を行わない場合は readOnlyHint というヒントでツールに注釈を付けることもできます。

例：製品検索を公開する（JSON を返す）

// Exemple minimal : un tool côté client.
// Objectif : éviter que l’agent scrolle, clique 12 filtres et parse du HTML.

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "search_products",
    description: "Recherche des produits dans le catalogue",
    annotations: { readOnlyHint: true },
    inputSchema: {
      type: "object",
      additionalProperties: false,
      properties: {
        query: { type: "string", description: "Texte libre" },
        category: { type: "string", description: "Catégorie (slug)" },
        minPrice: { type: "number", description: "Prix minimum" },
        maxPrice: { type: "number", description: "Prix maximum" }
      },
      required: ["query"]
    },

    // execute peut être async.
    // Le 2e param (client) sert notamment à demander une interaction utilisateur.
    execute: async ({ query, category, minPrice, maxPrice }, client) => {
      const params = new URLSearchParams({ query });
      if (category) params.set("category", category);
      if (minPrice != null) params.set("minPrice", String(minPrice));
      if (maxPrice != null) params.set("maxPrice", String(maxPrice));

      const res = await fetch(`/api/products/search?${params.toString()}`);
      if (!res.ok) {
        // Astuce : renvoyer une erreur explicite aide l’agent à se corriger.
        return { ok: false, error: `Search failed (${res.status})` };
      }

      const data = await res.json();
      return { ok: true, results: data.results };
    }
  });
}

「使えない」ツールを避けるデザインルール

動詞＋目的語で命名する：search_products、create_ticket、book_flight。
小さく作る：ツール＝明確な意図ひとつ。
構造化された返却を行う：安定した JSON、テキストの塊は避ける。
エラーを扱う：コード、メッセージ、欠落フィールドを返す。

L’API déclarative : `<form>` をツールに変換する

これは最も漸進的な移行です。
フォームは人間にとって100%使えるままで、WebMCP が利用可能ならエージェントからも呼び出せるようになります。

キー属性

toolname : ツールの識別子。
tooldescription : 自然言語での説明。
toolparamdescription : フィールド（パラメータ）の説明。
toolautosubmit : 手動クリックなしでの送信を許可する。

toolautosubmit が無い場合、Chrome はエージェント側の実行を一時停止し、ユーザーのアクションを待つことができます。
これはサプライズを避ける「許可優先」アプローチです。

例：予約フォーム

<form
  toolname="book_table"
  tooldescription="Réserver une table au restaurant"
  action="/reserve"
  method="post"
>
  <label for="date">Date</label>
  <input
    id="date"
    name="date"
    type="date"
    required
    toolparamdescription="Date de réservation"
  />

  <label for="time">Heure</label>
  <input
    id="time"
    name="time"
    type="time"
    required
    toolparamdescription="Heure (format local)"
  />

  <label for="guests">Convives</label>
  <input
    id="guests"
    name="guests"
    type="number"
    min="1"
    max="12"
    required
    aria-description="Entre 1 et 12"
  />

  <button type="submit">Réserver</button>
</form>

アクセシビリティ：WebMCPは良い慣行を評価する

Chrome はパラメータの説明を次の優先順で構築します：

toolparamdescription があればそれを優先、
なければ label のテキスト、
それもなければ aria-description。

要するに：フォームがきちんと作られていれば（labelの関連付け、ARIAの活用）、既に作業の80%は完了しています。
同時にスクリーンリーダーの体験（WCAG 2.2 など）も改善されます。

信頼を与えるUIシグナル

WebMCPは視覚的に有用なシグナルも導入します：

toolactivation と toolcancel イベント（window上でdispatch）。
CSSの疑似クラス :tool-form-active と :tool-submit-active。

これによりエージェントがページを「操作している」間、明確な状態表示が可能になります。
ユーザーは何が起きているかを目で確認でき、不透明な魔法に翻弄されません。

window.addEventListener("toolactivation", (e) => {
  console.log("Tool started:", e.toolName);
});

window.addEventListener("toolcancel", (e) => {
  console.log("Tool cancelled:", e.toolName);
});

/* Petit feedback visuel pendant l’interaction agent */
form:tool-form-active { outline: 2px solid currentColor; }
button:tool-submit-active { opacity: 0.7; }

セキュリティ、同意、そして「人間の介在」（本質的な議題）

エージェントを語る際のリスクは、ウェブが「あなたの背後で」操作を行うようになることです。
WebMCPはむしろ逆のロジックを推進します：ブラウザが仲裁する。

命令的APIでは、execute の間にユーザーの介入を要求できます。
宣言的APIでは、toolautosubmit が無いことで人間の操作が強制されます。

私のアドバイス：単純な枠組みから始めてください。

読み取り専用のツール：検索、フィルタ、データの読み取り。
書き込みツール：明示的な確認の背後に置く。

現在の制限（記事で想定すべき点）

WebMCPはまだ初期段階です。
その制約は次の通りです。

タブが必須：ツールはトップレベルのブラウジングコンテキスト内に存在します。
発見性（Discoverability）：サイト毎のネイティブなツール「カタログ」はない。
急速な進化：Community Group のドラフトなので変化が激しい。

方向性は明確で、APIは安定化するでしょう。
しかし現状ではプロトタイピングの段階であり、既存の情報システムを全面的に作り替えるフェーズではありません。

今日（2026年2月時点）テストする方法

1) 早期プレビューへアクセス

WebMCPは Chrome Early Preview Program (EPP) の枠組みで提供されています。
目的はプロトタイプを作り、フィードバックを与え、迅速に反復することです。

2) Chrome Canary + フラグを使う

WebMCPに関するツール群は Chrome 146+ と以下のフラグを必要とします：

chrome://flags → WebMCP for testing

3) “Model Context Tool Inspector” でツールを検査する

拡張機能によりページで公開されているツールを一覧化し、実行できます。
スキーマ、ネーミング、ペイロードを検証するのに最適です。

採用戦略（シンプルで現実的）

現場の開発者として説明したいなら、次の3ステップがおすすめです。

ステップ1 — まずフォームから始める

頻度の高いフォーム3つを探してください：

検索、
お問い合わせ／サポート、
チェックアウト／予約、
高度なフィルタ。

toolname と tooldescription を追加し、ラベルや説明の質を高めてください。

ステップ2 — ROIが高い1〜2個の命令的ツールを追加

典型的な例：

JSONをきれいに返す search_products、
技術情報を事前入力する create_support_ticket。

目標は：20回のUI操作を1回の呼び出しに置き換えること。

ステップ3 — セーフガードを追加する

読み取りなら readOnlyHint を付ける。
書き込みなら確認（human‑in‑the‑loop）を要求する。
ログと可観測性：エージェントが何をしたか再現できるようにする。

FAQ

「これはアクセシビリティの代わりになるのか？」

いいえ。
ただし一部の経路（会話型UIなど）では助けになる場合があります。特にサイトのアクセシビリティツリーが貧弱な場合に有効です。
最良の組み合わせは：堅牢なアクセシビリティ + 明確なツール です。

「WebMCP をすべてに追加する必要があるか？」

いいえ。
まずは重要で繰り返し使われるフローから始めてください。
エージェントトラフィックが実際の話題になれば、範囲を広げれば良いです。

「すべてのブラウザで動くのか？」

現時点ではそうではありません。
しかし Google と Microsoft は標準化の側面で共同作業を進めています。
小さな領域での早期導入は価値があります。

結論

WebMCP は「ただの追加のAI関連機能」ではありません。
人間向けのウェブを壊さずに、エージェントにとってもっと扱いやすくする試みです。

既に良いフォームと整理されたUIがあるなら、有利なスタート地点にいます。
さらに踏み込むなら、命令的APIは堅牢でバージョン管理可能、テスト可能なアクションを公開できます。

参考リンク

読み込み中...