スマレジのデータをAIから触れるようにしたい、という相談が増えました。作る側の選択肢は、これまで MCP サーバー1つでした。そこに WebMCP というブラウザ側の仕組みが加わり、Chrome 149 からオリジントライアルが始まっています。
どちらも、AIに道具を渡すための仕組みです。ただ、道具の置き場所が違います。置き場所が違うと、できることも、作る手間も、動かなくなる条件も変わります。MCPサーバーを1本作って公開した立場から、その違いを書きます。
WebMCP は、ページが自分で道具を差し出す
WebMCP は、ウェブページが「このページではこれができます」とAIエージェントに宣言するための仕様です。Chrome のドキュメントでは「AI エージェント用の構造化ツールを構築して公開するのに役立つ、提案中のウェブ標準」と説明されています。
いまのAIエージェントは、画面を読んでボタンを推測して押しています。押す前にページの構造を当てなければならず、当て損なうと違うものを押します。WebMCP は、その推測をやめさせる仕組みです。ページ側が道具の名前・説明・受け取る値を先に渡しておくと、エージェントはそれを呼ぶだけで済みます。
書き方は2つあります。ひとつは JavaScript で登録する命令型です。
await document.modelContext.registerTool({
name: 'toggle_layer',
description: 'Control pizza layers',
inputSchema: {
type: 'object',
properties: {
layer: { type: 'string', enum: ['sauce-layer', 'cheese-layer'] },
action: { type: 'string', enum: ['add', 'remove', 'toggle'] }
},
required: ['layer']
},
execute: async ({ layer, action }) => {
return `Performed ${action} on layer: ${layer}`;
}
});name・description・inputSchema・execute の4つで1つの道具になります。MCPサーバーのツール定義とほぼ同じ形なので、MCPを書いたことがあれば読めます。
もうひとつは、既存のフォームに属性を足すだけの宣言型です。
<form toolname="createSupportRequest"
tooldescription="Submits a request for customer support.">
</form>toolname と tooldescription を付けると、そのフォームがそのまま道具になります。入力欄ごとに toolparamdescription で説明を足せます。すでに動いているフォームに属性を2つ足すだけで済むのが、この書き方の強みです。
なお navigator.modelContext という古い名前が Chrome 150 で非推奨になりました。いま書くなら document.modelContext です。
違いは、道具をどこに置くか
Chrome のドキュメントには、MCP と WebMCP を並べた比較があります。要点はこうです。
- 動く場所: MCPは「パソコン、モバイル、クラウド、ウェブ」で使える。WebMCPは「ウェブサイトでのみ」使える
- 寿命: MCPは「永続的（サーバーとデーモン）」。WebMCPは「エフェメラル（タブバインド）」で、ページが開いているあいだだけ存在する
- UIとの関係: MCPは「ヘッドレスと外部」。WebMCPは「ブラウザ統合型で DOM を認識」し、表示中の画面をそのまま操作する
- 向く仕事: MCPは「バックグラウンドで API アクションを実行」。WebMCPは「コンテキストに応じたブラウザ内でのやり取り」
この4つのうち、作れるものを分けるのは寿命です。WebMCP の道具は、タブを閉じると消えます。 ドキュメントにも「ユーザーがサイトから移動したり、タブを閉じたりすると、エージェントはサイトにアクセスしたり、アクションを実行したりできなくなります」と書かれています。
つまり「毎朝7時に売上をまとめて通知する」のような、人が見ていない時間に動く仕事は WebMCP では作れません。逆に「いま開いているこの画面で、この操作をやってほしい」は WebMCP の領分です。
Chrome のドキュメントも、この2つは競合ではなく併用するものだと説明しています。コアのロジックとデータ取得は MCP、画面の操作は WebMCP、という組み合わせが想定されています。
いまどこまで動くのか
Chrome 149 からオリジントライアルに参加できます。 ローカルで試すだけなら chrome://flags/#enable-webmcp-testing で有効にできます。Cloudflare は2026年8月6日の記事で「Chrome 146 で実験的に搭載」と書いているので、フラグで触れるようになったのが146、オリジントライアルが149、という並びです。仕様自体は「現在、活発な議論が行われており、今後変更される可能性」があると明記されています。
制約もいくつか決まっています。
- オリジン分離されたドキュメントでのみ使える。
document.domainを有効にしていると WebMCP の API は無効になります - Permissions Policy の `tools` で制限される。 既定は
selfで、クロスオリジンの iframe で使わせるならallow="tools"が要ります - ブラウザが必須。 ヘッドレスでは動きません
Cloudflare はこの仕様に乗る形で、デベロッパープレビューを出しています。既存のサイトにコードを足さず、エッジで `bridge.js` を注入して WebMCP 対応にするという作りです。注入には HTMLRewriter を使っています。プレビューには「Content Credentials」と「Site MCP Server」の2つのツールパックが含まれ、WebMCP に対応したリモートブラウザとして BrowserRun も出ています。
このやり方で目を引くのは認証の扱いです。ツールの実行は訪問者のブラウザの中で完結し、外部サーバーへの往復がありません。訪問者がすでに持っているセッションをそのまま使うので、エージェントのために別のトークンを発行する必要がなくなります。
スマレジ連携では、どちらを作るか
ここからは、スマレジ連携アプリを8本作った立場での判断です。
スマレジの業務をAIに任せるなら、いまは MCP サーバーです。 理由は3つあります。
ひとつめは寿命です。店長が知りたいのは「今朝の売上」「今月の達成見込み」「しばらく来ていないお客さん」で、どれもブラウザを開いていない時間に集計しておくものです。タブを閉じると消える道具では受けられません。
ふたつめは、スマレジのデータがブラウザの画面にないことです。WebMCP が得意なのは「表示中のページを操作する」ことですが、スマレジの管理画面は自分のサイトではないので、そこに toolname を足せません。データはプラットフォームAPIから取るしかなく、それはサーバー側の仕事です。
みっつめは認証です。スマレジのAPIは OAuth とアプリアクセストークンで、トークンはサーバーの中だけに置く設計になります。ブラウザ側には置けません。
逆に、WebMCP が向くのは自社サイト側です。 会員登録フォーム、予約フォーム、問い合わせフォーム。すでに動いているフォームに toolname と tooldescription を2つ足すだけで、AIエージェントが正しい欄に正しい値を入れられるようになります。フォームを作り直す必要はありません。
私が作ったMCPサーバーでは、渡す道具を15個で打ち止めにしました。道具が増えるほどAIは選び間違えるので、足すなら何かを捨てる、という規則にしています。WebMCP でも同じことが起きるはずです。ページ上のあらゆる操作を道具にすると、エージェントは選べなくなります。宣言型APIはフォームに属性を足すだけで済むぶん、足しすぎる事故が起きやすい書き方でもあります。
いま決めるなら、こうです。
- サーバー側で完結する業務 — 集計・通知・発注の見込み・休眠客の抽出。MCPサーバーで作る
- 自社サイトの画面操作 — フォーム入力・絞り込み・予約。WebMCP を足す
- 両方が要る場合 — Chrome のドキュメントが書いているとおり、併用する。ロジックはMCP、画面はWebMCP
WebMCP はまだ提案段階の仕様で、変わる可能性が明記されています。本番の業務をここに載せるのは早いというのが現時点の判断です。ただし宣言型APIは既存のフォームに属性を足すだけなので、外すのも簡単です。試す価値のある場所から順に、というのが現実的な入り方だと思います。