【WebMCPとは？】
AIファーストなサイトを作るWeb新規格

AIは「読む」だけでなく「操作する」段階へ

生成AIのWeb活用は、記事や商品情報を要約する段階から

検索
予約
問い合わせ
購入候補の比較

といった実際の操作を代行する段階へ進んでいます。

しかし、これまでのブラウザエージェントは、画面上のボタンや入力欄を人間のように見つけ、クリックや文字入力を模倣する必要がありました。この方式は、画面の見た目やDOM構造が変わると壊れやすく、似た名前のボタンを誤って選ぶ可能性もあります。

この課題に対する新しい提案が、WebMCP（Web Model Context Protocol）です。

WebMCPは、Webサイトが「AIに何ができるか」を構造化されたツールとして宣言し、ブラウザ上のエージェントが機能をより正確に呼び出せるようにする提案中のWeb標準です。

WebMCPは「AI専用の別サイトを作る技術」ではなく、人間向けのWebサイトにAIが理解しやすい操作契約を追加するための仕組みです。

そこで本記事では、

WebMCPの基本概念
通常のMCPとの違い
Declarative APIとImperative APIの使い分け
AIファーストなサイトを設計するための実践的な考え方
セキュリティ上の注意点
段階的な導入方法

までをまとめます。

WebMCPとは何か
WebMCPが解決する問題
MCPとWebMCPは競合するのか
WebMCPの2つのAPI
1. 【Declarative API】HTMLフォームをAI対応にする
2. 【Imperative API】動的な機能をJavaScriptで公開する
AIファーストなサイトにする7つの設計原則
【セキュリティ】AIに公開する操作は最小権限で設計する
AIファーストなコンテンツ設計
段階的な導入ロードマップ
よくある誤解
WebMCPは「AIに読ませる」から「AIに使わせる」への一歩
関連記事

WebMCPとは何か

WebMCPは、Webページの機能をAIエージェントが呼び出せるツールとして公開するためのブラウザ向けAPIです。

ツールには、

名前
用途の説明
入力値のスキーマ
実行処理

などを定義します。エージェントは画面を推測して操作するのではなく、サイト側が提示した明確な能力一覧から適切な機能を選べるようになります。

仕様上、Webページはバックエンドで動くMCPサーバーというよりクライアント側スクリプトでツールを実装するMCP的な提供者として捉えられます。document.modelContextを通じてツールを登録し、ブラウザエージェントやページ内エージェントがツールを発見・実行する設計です。

例えば、

旅行サイトなら「東京から大阪への新幹線を検索する」
ECサイトなら「在庫のある商品を価格順に絞り込む」
サポートサイトなら「契約者情報をもとに問い合わせフォームを準備する」

といった機能をツールとして公開できます。

AIは「ボタンを押す」のではなく、「商品を価格順に絞り込む」という意味に基づいて処理を依頼できます。

WebMCPが解決する問題

従来のDOM操作型エージェントでは、

サイトの画面を読み
操作対象を推測し
1つずつクリックや入力

を繰り返します。操作の各段階に解釈が入り込むため、

フォームのラベル
ボタンの位置
表示順
ポップアップ

などの変化がエラー要因になります。

WebMCPでは、サイトが目的と入力形式を明示します。Chrome公式ドキュメントは、WebMCPの主要な価値として、

ツールの発見
JSON Schemaによる入力定義
ページ状態の共有

を挙げています。

エージェントは、

「何ができるか」
「何を渡せばよいか」
「いま実行できるか」

を判断しやすくなります。

観点	DOMを見て操作する方式	WebMCP方式
機能の発見	画面やDOMから推測する	サイトがツールとして宣言する
入力の理解	ラベルや文脈から推測する	JSON Schemaで型・選択肢を示す
UI変更への耐性	レイアウト変更の影響を受けやすい	アプリケーションロジックとの接続を維持しやすい
実行単位	クリックや入力の連続	意味のある機能単位
ユーザーとの関係	裏側で操作が進みやすい	既存画面を表示し、確認を挟みやすい
弱点	誤クリック、操作の脆弱性	対応ブラウザ・仕様の成熟度、ツール設計の難しさ

MCPとWebMCPは競合するのか

WebMCPは通常のMCPを置き換えるものではありません。両者は似た思想を持ちながら、対象になる場所とライフサイクルが異なります。

通常のMCPは、

AIアプリケーション
外部のデータソース
サービス
業務システム

をつなぐためのプロトコルです。

MCPの公式仕様では、

ホスト
クライアント
サーバー

という構成を取り、

リソース
プロンプト
ツール

などを提供します。JSON-RPCを基盤とし、

デスクトップ
クラウド
モバイル

など、ブラウザ以外の環境も対象にできます。

WebMCPは、ユーザーが開いているWebページをブラウザエージェントが操作しやすくする仕組みです。

ログイン状態
Cookie
現在表示しているデータ
画面上の状態を利用できる

反面、ページを閉じたり移動したりするとツールも利用できなくなるというタブ単位の一時性があります。

項目	MCP	WebMCP
主な場所	バックエンド、外部サービス	開いているWebページとブラウザ
利用範囲	エージェントから広く利用可能	対応ブラウザ上のライブなサイト
ライフサイクル	サーバーやサービスとして継続	ページを開いている間だけ有効
得意なこと	データ取得、業務処理、バックグラウンド処理	現在の画面・セッションに即した操作
実装	MCP SDK、JSON-RPCなど	HTML属性またはJavaScript API
推奨関係	基盤となる業務ロジック	その場のUI・状態を扱う接続面

実務では、MCPをサービス層、WebMCPをブラウザ上の文脈層として併用する構成が有力です。
注文検索や在庫取得の中核処理はバックエンドに置き、ログイン済みユーザーが見ている注文画面のフィルタリングやフォーム準備はWebMCPで扱うといった分担です。

WebMCPの2つのAPI

WebMCPには、大きく分けてDeclarative APIとImperative APIがあります。

どちらを使うかは、

対象機能が標準HTMLフォームで表現できるか
アプリケーション状態や非同期処理を含む複雑なロジックを必要とするか

で判断します。

【Declarative API】HTMLフォームをAI対応にする

Declarative APIは、既存のHTMLフォームに属性を追加して、フォームをWebMCPツールとして公開する方法です。toolnameとtooldescriptionをフォームに付け、入力欄には通常のname、label、requiredなどを使います。必要に応じてtoolparamdescriptionで、AI向けの補足説明も追加できます。

HTML

<form
toolname=”search_articles”
tooldescription=”記事タイトル、本文、タグを対象にブログ記事を検索します。”
action=”/search”
method=”get”>
<label for=”query”>検索語</label>
<input id=”query” name=”query” type=”search” required>

<label for=”category”>カテゴリ</label>
<select id=”category” name=”category”
toolparamdescription=”検索対象のブログカテゴリです。”>
<option value=”all”>すべて</option>
<option value=”technology”>AI・テクノロジー</option>
<option value=”history”>歴史</option>
</select>

<button type=”submit”>検索</button>
</form>

この方式の利点は、人間用のフォームをそのままAI向けの操作面にできることです。フォームは画面に残り、エージェントが呼び出すと入力欄がフォーカスされ、値が設定されます。toolautosubmitを付ければ、エージェント呼び出し時に送信まで進められますが、検索や絞り込みなど比較的安全な処理から使い始めるのが適切です。

フォーム送信時には、AIエージェントによる呼び出しかどうかをSubmitEvent.agentInvokedで判定できます。preventDefault()とrespondWith()を使えば、検証結果や処理結果をエージェントに返すことも可能です。画面上では、:tool-form-activeや:tool-submit-activeによって、AIが操作している対象を視覚的に示せます。

【Imperative API】動的な機能をJavaScriptで公開する

状態管理、複数のAPI呼び出し、複雑な日付選択、画面遷移を伴う処理には、Imperative APIが向いています。document.modelContext.registerTool()にツール定義を渡し、execute関数に処理を実装します。

Plain Text

const tool = {
name: “filter_articles”,
title: “記事を絞り込む”,
description:
“指定されたカテゴリと公開期間で、現在のブログ記事一覧を絞り込みます。”,
inputSchema: {
type: “object”,
properties: {
category: {
type: “string”,
enum: [“all”, “technology”, “history”, “society”],
description: “記事カテゴリ。意味が明確な文字列を指定します。”
},
period: {
type: “string”,
enum: [“all”, “7_days”, “30_days”, “1_year”],
description: “公開時期の範囲。”
}
},
required: [“category”]
},
annotations: {
readOnlyHint: false,
untrustedContentHint: false
},
execute: async ({ category, period = “all” }) => {
const result = await filterArticleList({ category, period });
updateArticleList(result);
return JSON.stringify({
status: “ok”,
count: result.length,
message: “記事一覧を更新しました。”
});
}
};

if (“modelContext” in document) {
await document.modelContext.registerTool(tool);
}

ツールは、1つの関数に1つの目的を持たせます。「問い合わせ画面へ移動するツール」と「問い合わせ内容を送信するツール」を分けるように、開始と実行を混同しない設計が重要です。ツールが現在の画面状態で不要になった場合は登録解除し、利用可能な機能だけを提示します。ツールの発見や変更は、getTools()やtoolchangeイベントで扱えます。

AIファーストなサイトにする7つの設計原則

WebMCPを導入するだけで、サイトが自動的にAIファーストになるわけではありません。AIファーストとは、AIに迎合して人間向けUIを捨てることではなく、人間が見て理解でき、AIも意味を読み取って安全に操作できる二重設計です。

【Part.1】ページではなく「ユーザーの目的」を設計する

「どの画面にAIを付けるか」ではなく、「ユーザーは何を完了したいのか」です。例えば、ECサイトの目的は、商品詳細ページを開くことではなく、「予算とサイズに合う在庫商品を比較し、購入候補を決めること」です。

その目的を、

検索
比較
カート投入
配送条件の確認
購入確定

という適切な粒度のツールに分解します。

1つのツールに検索から決済までを詰め込むと、

権限
確認
失敗時の復旧

が複雑になり、エージェントも選択を誤りやすくなります。

【Part.2】ツール名と説明は広告文ではなくAPI契約として書く

ツール名には、実際に起きる動作を表す動詞を使います。

start-event-creation-processよりcreate-eventの方が、即時作成を意味する名前として明確です。ただし、フォームを開くだけならopen-event-formのように、開始と実行を区別します。

説明文では「使うな」という否定的な条件を大量に書くより、「何を、いつ実行するツールか」を肯定形で具体的に示します。例えば、「天気には使わない」ではなく、「指定した日時と場所でカレンダーイベントを作成する」と書きます。

【Part.3】AIに余計な計算や変換をさせない

モデルに、時刻の差分計算、内部IDへの変換、複雑な文字列加工を任せるほど、誤りが増えます。入力は可能な範囲で人間の自然な表現を受け付け、サーバーまたはツール実装側で正規化します。

例えば、配送方法はshipping_id: 1ではなく、shipping: “Express”のように意味が分かる値を採用します。入力Schemaではstring、number、enumなどの型を具体的に定義し、実行関数では必ず再検証します。

【Part.4】機能を小さく分けて重複ツールを作らない

ツールが多すぎると、エージェントのコンテキストを消費し、ツールの選択に迷います。Chrome公式のベストプラクティスでも、単体目的のツール、重複しない命名、必要な状態でのみ登録することが推奨されています。

サイト全体を同時にAI対応にするのではなく、

検索
絞り込み
FAQ検索
問い合わせフォームの下書き

など、失敗しても回復しやすい読み取り・準備系の機能から始めるとよいでしょう。

【Part.5】状態を「返す」だけでなく画面にも反映する

ツールがバックエンド処理を完了しても、画面が古いままだとAIは次の判断を誤る可能性があります。処理後には、

一覧
件数
選択状態
エラーメッセージ

を更新し、エージェントにも簡潔な結果を返します。

出力は、成功・失敗、変更件数、次に取れる行動を含む小さな構造にします。人間向けの長いHTMLをそのまま返すよりも、status、count、nextActionのように次の判断に必要な情報を優先します。

【Part.6】失敗をモデルが自己修正できる形にする

入力エラーは、Bad Requestと返すのではなく、「categoryにはtechnology、history、societyのいずれかを指定してください」のように、修正方法が分かるメッセージにします。レート制限や一時障害には、再試行可能か手動操作へ切り替えるべきかを明示します。

ただし、スキーマだけに厳格な検証を任せてはいけません。スキーマはエージェントへのヒントであり、セキュリティ境界ではありません。

認証
認可
値の範囲
所有者確認
業務ルール

は、必ずサーバー側と実行コード側で検証します。

【Part.7】人間の確認と可視性を残す

送信
予約確定
購入
削除
公開

など、取り消しにくい操作は、AIに完全自動化させるのではなく、確認画面を挟みます。

ユーザーには、

対象
金額
宛先
変更内容
実行ボタン

を明確に表示します。

WebMCPの利点は、AIが既存の画面上で動作できる点です。操作対象がどこかを視覚的に示し、AIが入力した内容をユーザーが確認できる設計にすることで、透明性と信頼を高められます。

【セキュリティ】AIに公開する操作は最小権限で設計する

AIエージェントは、Webページ上の文章やユーザー生成コンテンツを指示とデータの区別なく処理することがあります。そのため、悪意ある文章がエージェントを誘導する間接プロンプトインジェクションへの警戒が必要です。Chrome公式のセキュリティガイダンスでは、最先端のモデルであってもプロンプトインジェクションを完全には保証できないと説明しています。

実装では、読み取り専用ツールにはreadOnlyHintを付け、ユーザー投稿や外部取得データを返す場合はuntrustedContentHintを検討します。ツールの説明や返却文に、

秘密情報
システム指示
認証トークン

を含めてはいけません。

他オリジンのiframeからツールを利用する場合は、Permissions Policyのtoolsと明示的に許可した安全なオリジンの設定が必要です。信頼していないサイトへ読み取りツールを公開するだけでも、個人情報が漏れる可能性があります。書き込みツールやユーザーデータを扱うツールは、許可先をさらに限定します。

操作	推奨する保護
記事検索・商品絞り込み	読み取り専用、公開データのみ、レート制限
問い合わせ下書き	ログイン確認、入力内容の画面表示、送信前確認
コメント投稿	CSRF対策、スパム対策、投稿前確認、監査ログ
注文・予約確定	金額・対象・日時の再確認、ユーザー明示承認、冪等性キー
削除・公開・権限変更	強い再認証、明確な確認、取り消しまたは復旧手段

ツール出力の長さにも注意します。

Chromeのガイダンスは、

ツール説明を500文字
パラメータ説明を150文字
ツール名とパラメータ名を30文字
個別のツール出力を1500文字

以内に抑えることを推奨しています。絶対的な仕様ではありませんが、コンテキストの節約と誤解防止に有効な実務目安です。

AIファーストなコンテンツ設計

WebMCPは操作のための仕組みですが、AIが適切に判断するにはコンテンツの構造化も必要です。見出しを階層的に整理し、リンク文を「こちら」ではなく遷移先の内容にし、フォームには明確なラベルを付けます。これはアクセシビリティの改善にもつながります。

記事や商品情報では、

タイトル
要約
公開日
更新日
カテゴリ
価格
在庫
対象読者

などを明示します。重要な事実は本文中にも自然言語で書き、構造化データだけに依存しないようにします。AI向けに特別な隠しテキストを大量に置くのではなく、人間にも有用な情報をAIが解釈しやすい意味構造で提供するのが基本です。

ブログであれば、

「記事を検索する」
「関連記事を探す」
「要点を抽出する」
「問い合わせフォームを開く」

といった機能を候補にできます。ただし、読者の個人情報や限定コンテンツをAIに返す場合は、ログイン状態とアクセス権を必ずサーバー側で検証します。

段階的な導入ロードマップ

WebMCPは、2026年8月時点で提案・Origin Trial段階です。
Chrome公式は、Chrome 149からOrigin Trialに参加を案内しており、ローカル開発では専用フラグを有効にできます。仕様や実装は変更される可能性があるため、現時点では本番の中核機能をWebMCPだけに依存しないことが重要です。

段階	実施内容	成功指標
棚卸し	ユーザーが頻繁に行う操作と失敗しやすい操作を整理する	対象ユースケースが3〜5個に絞れている
低リスク試作	検索、絞り込み、FAQ、下書きなどをDeclarative APIで公開する	ツール発見率、正しい入力率
動的処理	状態管理、非同期処理、複合操作をImperative APIで実装する	完了率、再試行率、平均ステップ数
安全性検証	認証、認可、CSRF、レート制限、確認フローを検証する	不正実行ゼロ、誤操作の復旧時間
段階公開	feature detectionと従来UIを残して対象ユーザーへ展開する	人間・AI双方のコンバージョンと問い合わせ数

対応ブラウザでない場合に通常のフォームやボタンが使えるように機能検出を入れます。

Plain Text

const webMcpSupported =
“modelContext” in document &&
typeof document.modelContext.registerTool === “function”;

if (webMcpSupported) {
// WebMCPツールを登録する
} else {
// 従来のUIと通常のフォーム送信を利用する
}

検証では、決められた入力だけでなく、

曖昧な依頼
欠落値
異常に長い文字列
権限のない対象
途中での画面遷移
通信失敗

を試します。

Chrome公式は、通常のユニットテストだけでなく、

予想外の自然言語入力を含む評価
ベースラインと理想結果の定義
必要に応じたLLM-as-a-judgeの利用

を紹介しています。

よくある誤解

WebMCPで全AIからサイトを操作できる

WebMCPは、対応するブラウザエージェントが開いているページのツールを利用するための仕組みです。ページを直接訪れる必要があり、ツールはタブに紐づく一時的な存在です。どのAIサービスからでも常時アクセスできる公開APIとは異なります。

WebMCPはMCPサーバー

WebMCPは、MCPと同じプロトコルをJavaScriptで再現するものではありません。ブラウザ向けに設計されたMCPに着想を得たWeb APIです。データ連携やバックグラウンド処理には、通常のAPIやMCPサーバーの方が適しています。

JSON Schemaを書けば安全になる

スキーマは入力理解を助けますが、認証・認可・業務ルールを代替しません。AIが直接呼び出せる関数は通常の公開APIと同じかそれ以上に厳格なサーバー側検証が必要です。

AI用に人間向けUIを隠せばよい

WebMCPの強みは、既存の人間向けUIとエージェント操作を結び付けられる点です。操作中の対象や入力結果をユーザーが確認できるようにし、AI専用の不可視な処理だけに寄せない方が、信頼とアクセシビリティの両方を保ちやすくなります。

WebMCPは「AIに読ませる」から「AIに使わせる」への一歩

WebMCPは、Webサイトの機能をAIエージェントが理解し、意味のある単位で呼び出せるようにする提案中のブラウザ標準です。Declarative APIなら既存フォームを比較的容易にAI対応でき、Imperative APIなら動的なUIや複雑なアプリケーションロジックをツールとして公開できます。

AIファーストなサイトを作る上で重要なのは、AI向けの文章を追加することだけではありません。ユーザーの目的に沿って機能を分解し、