お問い合わせ
プロトコル・標準2026年10月26日

Commerce.comとCloudflare、BigCommerce加盟店でWebMCPを既定で有効に:約10万ドメインに広がる仕組みとEC事業者への示唆

BigCommerce加盟店のストアでWebMCPが既定で有効になりました。CloudflareがエッジでAIエージェント用のツールを配る仕組み、Shopify・Cafe24との違い、EC事業者が確認すべき点と未開示事項を解説します。

Commerce.comとCloudflare、BigCommerce加盟店でWebMCPを既定で有効に:約10万ドメインに広がる仕組みとEC事業者への示唆

この記事のポイント

  1. BigCommerceの親会社Commerce.comとCloudflareは2026年10月21日、対象となるBigCommerce加盟店でWebMCPを既定で有効にしたと発表しました。約10万ドメインで、ブラウザ内のAIエージェントが商品検索からカート作成、チェックアウトのリンク発行までを行えます
  2. Cloudflareはエッジでスクリプトを差し込み、Commerce.comのMCPサーバーのツールをそのままブラウザへ中継します。プラットフォームが店に代わって道具を一括で配る形は、ShopifyやCafe24とも共通します
  3. 決済は買い手が行い、加盟店は設定メニューで無効にできます。一方、WebMCPを呼べるエージェントはまだ限られ、計測や対象条件は未開示です。既定でオンの機能を自社でどう扱うかを先に決めておく必要があります

BigCommerceのストアが、ブラウザ型エージェントに道具を出し始めた

「150ドル以下で、自分のサイズの軽いジャケットを探して」。買い手がブラウザのエージェントにこう頼むと、エージェントはストアの実際の商品と価格を検索し、合う商品をカートに入れ、加盟店のサイトで支払うためのリンクを返します。Commerce.comがプレスリリースで示した利用例です。

2026年10月21日、BigCommerceの親会社であるCommerce.com(Nasdaq: CMRC)とCloudflareは、この機能を対象となるBigCommerce加盟店で既定で有効にしたと発表しました。同日のCloudflareのブログによると、Cloudflare上で動くCommerce.comの約10万ドメインが、WebMCPのツールを持つようになりました。加盟店がコードを書いたり、テーマを直したりする必要はありません。

WebMCPは、Webページが自分の機能を「ツール」としてブラウザに登録し、エージェントが名前と入力形式で呼び出せるようにする仕組みです。基本はShopifyのチェックアウト対応の記事で解説したため、本記事では新しい2点に絞ります。10万規模のストアへ一括で配った方法と、そこでCloudflareが担った役割です。

Cloudflareは「道具を作る側」ではなく「届ける側」に立った

今回の構成で最も重要なのは、ツールの中身を作っているのがCloudflareではない点です。

Cloudflareは2026年8月、WebMCPのエッジ実装をプレビューとして公開しました。管理画面でスイッチを入れると、CloudflareはHTMLを配信の途中で書き換える機能(HTMLRewriter)を使い、各ページに1行のスクリプトを差し込みます。スクリプト本体もエッジから同じドメインで配信されるため、加盟店のサーバーには何の変更も要りません。Commerce.comのストアに差し込まれるのは、次の1行です。

<script type="module"
    src="/.webmcp/bridge.js"
    data-packs="c2pa,mcp-server-client"
    data-mcp-url="/api/mcp"></script>

中心になるのは、Cloudflareが「mcp-server-client」と呼ぶツールパックです。ブリッジは起動時にCommerce.comのMCPサーバーへツールの一覧を問い合わせ、名前と説明、入力形式をそのままブラウザの document.modelContext に登録します。エージェントがツールを呼ぶと、ブリッジは買い手のセッションのまま、同じドメインの /api/mcp へ要求を送ります。

この設計の意味は2つあります。1つは、ツールの定義と処理を変えずに中継するため、中身はCommerce.comが握ったままになることです。もう1つは、処理が買い手のブラウザ内で、ストアのドメイン上で行われることです。エージェントは人間の買い手と同じ価格とカートを見ており、認証情報が第三者に渡ることもないとCloudflareは説明しています。

10万ドメインで「店ごとに止める」ための工夫

実際の展開では壁がありました。CloudflareのWebMCPは、もともとドメインのまとまり(ゾーン)単位でオンかオフを選ぶ設計でした。ところがCommerce.comは、Cloudflare for SaaSという仕組みで、数千の加盟店の独自ドメインを共有のゾーンに載せています。ゾーン単位のスイッチでは、全店を有効にできても、特定の店だけを外せません。

Cloudflareが選んだのは、新しい許可リストを作るのではなく、既存の設定ルール(Configuration Rules)と、独自ドメインごとのメタデータを組み合わせる方法でした。加盟店が管理画面で無効化のスイッチを入れると、そのドメインに webmcp_opt_out の印が付き、エッジのルールがそのストアだけWebMCPを外します。判定はページを返す前に行われるため、無効にしたストアには遅延の増加も、外部への問い合わせも、差し込まれるスクリプトもないとされています。

MCPサーバーが落ちている場合や、ブラウザがWebMCPに対応していない場合、スクリプトは何もせずに終了し、人間の買い物には影響しません。

エージェントに渡る道具は、カートとチェックアウトのリンクまで

Commerce.comでプロダクトマネジメント・ディレクターを務めるKristina Pototska氏は、エージェントが得る道具を「商品を探し、詳細を確かめ、カートを作り、チェックアウトのリンクを得る」ものだと説明しています。サーバー型のMCPとWebMCPは同じ買い物用ツール一式で、加盟店が別々に管理する必要はないとも述べています。

BigCommerceのMCPサーバーの文書によると、B2C向けのツールは、商品検索、商品詳細、関連商品、カートへの追加・変更・削除、チェックアウトURLの発行で構成されます。B2Bのストアでは、購買担当者の権限に応じて、買い物リストや見積もりのツールが加わります。

線が引かれているのは、決済の手前です。Cloudflareのブログは、購入を確定するときは買い手が自分でチェックアウトを押すと明記しており、支払い情報はエージェントの手を通りません。

買い手は加盟店のサイトにとどまり、加盟店は顧客との関係を保ちます。

この割り切りは、Shopifyと比べると違いがはっきりします。Shopifyは9月にWebMCPをチェックアウトまで広げ、買い手の許可を得たうえでエージェントが注文を確定できるようにしました。同じ週に全ストアでの採用を発表した韓国のCafe24も含めると、3社の線引きは次のとおりです。

項目BigCommerce(Commerce.com×Cloudflare)ShopifyCafe24
発表2026年10月21日2026年9月28日にチェックアウトへ拡大(ストアフロントは先行)2026年10月(同じ週)
対象対象となる加盟店で既定で有効(約10万ドメイン)Liquidのストアは設定不要。チェックアウトは対象となる加盟店Cafe24で作られたすべてのストア
エージェントができる範囲商品検索、商品詳細、カート操作、チェックアウトURLの発行商品検索、カート操作、チェックアウトの更新、買い手の許可後の注文確定商品検索から即時購入の注文フォームへの移動、注文履歴の確認まで11機能
最後の支払い買い手が自分でチェックアウトを押す買い手の許可を得てエージェントが確定。本人認証は買い手ログインと最終決済は利用者
配る仕組みCloudflareがエッジでスクリプトを差し込み、Commerce.comのMCPサーバーへ中継Shopifyが自社で実装Cafe24が自社で実装
加盟店による無効化新しい設定メニューで無効化できる公式文書で示されていない(9月時点)報道で言及なし
エージェントの身元確認発表で言及なしWeb Bot Authによる署名報道で言及なし

Digital Todayの報道によると、Cafe24は商品検索から即時購入の注文フォームへの移動、注文履歴の確認まで11の機能を用意しました。使える環境はChatGPTのデスクトップアプリの内蔵ブラウザで、Chromeでは拡張機能と開発者向けの設定が必要です。

3社に共通するのは、個々の店に実装を求めず、プラットフォームが一括で道具を配っている点です。違いは、エージェントにどこまで任せるかと、配る仕組みを自前で持つか外部に頼るかにあります。

「既定でオン」と「申請してオン」の差

見落としやすいのが、同じBigCommerceの中で、有効化の手順が2つに分かれていることです。

サーバー型のStorefront MCPは、文書によると、ストアのオーナーが管理画面でスイッチを入れ、利用規約に同意して初めて使えます。誰がいつ同意したかも記録されます。これに対して今回のWebMCPは、対象となる加盟店では最初から有効で、止めたい店が自分で無効にする方式です。プレスリリースによると、無効化は新しい設定メニューで行い、そこではCommerce.comのAI関連の接続をまとめて管理できます。

ただし、WebMCPのツールはサーバー型のMCPから中継されます。サーバー型を有効にしていない店でどう扱われるのか、「対象となる加盟店」の条件は何かは、発表では示されていません。

留保:道具を並べても、呼ぶ側はまだ少ない

推進側の説明だけで判断すべきではない点もあります。

まず、WebMCPそのものが固まっていません。W3CのWeb Machine Learningコミュニティグループの仕様の草案は、2026年10月20日付の版でも、W3C標準ではなく標準化トラックにも乗っていないと明記しています。Chromeの開発者向け文書が案内するのは、Chrome 149からのオリジントライアル(本番サイトで期間限定に試せる制度)と開発用のフラグです。Cloudflare自身も、WebMCPを初期プレビュー段階の実験的な標準案と位置づけています。

つまり、10万ドメインに道具が並んでも、それを呼べるエージェントを使う買い手はまだ少数です。Chromeの文書は、エージェントがサイトを訪れるまでツールの有無を知る方法がないことも制約に挙げています。Cloudflareが次の課題に「ツールを見つけやすくすること」を挙げたのは、この弱点への対応です。

次に、安全性の論点です。仕様の草案は、エージェントが買い手のログイン状態を引き継ぐことを前提にしており、ツールに付ける「読み取り専用」などの印も、悪意あるサイトなら偽れると認めています。加盟店の側には逆の問題もあります。Shopifyはチェックアウトのツールを使うエージェントにWeb Bot Authによる署名を求めていますが、今回の発表にはエージェントの身元をどう確かめるかへの言及がありません。自動化された大量のカート作成にどう備えるかは見えていません。

最後に、効果の数字が出ていません。エージェント経由の訪問やカート作成、購入がどれだけ発生したかは公表されていません。

EC事業者が確認すべきこと

BigCommerceの加盟店は、まず新しい設定メニューを確認すべきです。何もしなければ、自社のストアはすでにエージェントから使える状態にあると考えておく必要があります。止めるかどうかは、自社の商品で検索結果やカートの中身が正しく出るかを見てから判断できます。Chromeの開発用フラグを有効にすれば、開発者ツールで登録されたツールを確かめられます。

計測も早めに考えておきたい点です。エージェントが作ったカートを区別できないまま件数が増えると、カート放棄率やコンバージョン率の読み方が変わります。

BigCommerce以外の事業者にとっても参考になります。Cloudflareのエッジ実装は、Cloudflareを使うサイトなら管理画面の「Agent Readiness」から有効にできるプレビューです。自社でMCPサーバーを持っていれば、それをブラウザ側の道具として出す経路が、ほぼコードなしで手に入ります。逆に言えば、中身となるMCPサーバーがなければ、配る道具がありません。どの機能をエージェントに開くかの設計が先に来ます。

開示されていないこと

発表、Cloudflareのブログ、BigCommerceの開発者向け文書を突き合わせても、次の点は示されていません。

  • 「対象となる加盟店」の条件(プラン、国・地域、ストアの種類):未開示
  • サーバー型のStorefront MCPを有効にしていない店での扱い:未開示
  • エージェントの身元確認やボット対策との関係:未開示
  • エージェント経由のカートや注文を区別して計測できるか:未開示
  • 追加料金の有無:未開示
  • エージェント経由の利用実績:未開示(公表は約10万ドメインという規模のみ)

まとめ

Cloudflareは今回、自らツールを作るのではなく、プラットフォームのMCPサーバーを10万規模のストアへ届ける配送網になりました。Shopify、Cafe24と合わせて、EC基盤が店に代わってエージェント用の道具を配る流れは、2026年秋にはっきりしました。

残る問いは呼ぶ側です。主要なエージェントがWebMCPを日常的に使い始めるか。そしてプラットフォームが、エージェント経由の買い物を加盟店にどう見せ、どう止められるようにするか。道具が先に並んだ今、問われるのは店の使いこなしです。