店のページが、エージェントに「道具」を差し出す：WebMCP と Commerce.com

エージェントがウェブで買い物をする時、これまではページの画面を読み、ボタンを探して押していました。Cloudflare と Commerce.com が 10 月 21 日に発表した仕組みは、これを変えます。「ボタンを探す代わりに、エージェントは必要な道具を直接呼ぶ（Instead of hunting for buttons, the agent calls the exact tool it needs directly.）」。

WebMCP とは

WebMCP は、Google が進める実験的なブラウザーの標準です。ウェブのページが、エージェント向けの道具（例えば、商品を探す search_products）を、決まった形で差し出せます。いまは早期のプレビューで、Chrome の実験的なフラグ、Origin Trials、一部のエージェントのブラウザーで試せます。

MCP（Model Context Protocol）は、AI に道具を渡すための共通の決まりです。WebMCP は、それをページの中に持ち込む形です。

Commerce.com の導入

• Cloudflare の上にある、約 10 万のドメインのストアで、WebMCP を有効にした。
• Cloudflare のエッジ（利用者に近い所で動くサーバー）が、橋渡しのスクリプトをページに差し込む（8 月からベータ）。道具は document.modelContext に出る。
• 裏側では、/api/mcp に MCP のサーバーを置く。
• 店ごとに、設定（Configuration Rule）で外せる。うまく動かない時も、ページはふだんどおり表示される（fail open）。

買い物の流れ

エージェントは、買い物客がいま開いているセッションの中で、search_products や add_to_cart を呼びます。支払いは、買い物客が自分で済ませます。Cloudflare は「買い物客は店のサイトにとどまり、店は客との関係を保つ（The human shopper stays on the merchant’s site, and the merchant keeps the relationship.）」と書いています。

作り手にとっての意味

エージェントのための入口は、2 つの道に分かれつつあります。1 つは、エージェントがすべてを代わりに済ませ、店は裏方になる道。もう 1 つは、店の画面とセッションの中でエージェントが動き、決める所は人に残す道。WebMCP は後者です。

EC に限らず、サービスを作る側は「自分の画面がエージェントに使われる」前提を持つ時期に来ています。人のためのボタンと、エージェントのための道具を、同じ設計から出す。支払いや契約のような戻せない操作は、人に残す。この線引きが、エージェンティックなサービスの信頼の土台になります。