Developer Changelog / ストアフロント

WebMCP 対応
ストアが「AI エージェント用の操作口」を自分から公開する

オンラインストアが WebMCP ツールを公開し、AI エージェントがカタログ検索・カート操作・チェックアウト遷移を、買い物客が見ているそのタブの中で直接実行できるようになった。Liquid ストアフロント全体と Hydrogen の Developer Preview で本日から稼働。インストールも設定も不要。

このページの構成
  1. そもそも何が変わるのか(30秒で理解)
  2. 仕組み図解 : 従来のエージェント vs WebMCP
  3. エージェントが呼べるツール一覧
  4. クリック模倣 vs WebMCP の比較
  5. 対応範囲と前提条件
  6. マーチャント側でやること(3ステップ)
  7. 技術者が押さえるべき5つのポイント
  8. 業務に活かせる3つのユースケース
  9. 提案で使える1行サマリ

1そもそも何が変わるのか

今まで AI エージェントは、ストアのページのコードを読んでクリックを模倣するしかなかった。
WebMCP 対応で、ストア側が 「これを呼んでください」というツールをブラウザに登録する 形に変わる。

従来 : コードを読んでクリック模倣

エージェントが各ページの DOM を解析し、人間の操作を真似る。記事いわく 遅く、エラーが起きやすい

WebMCP : ツールとして登録済み

ページがブラウザに対してツールを登録し、エージェントはそれを名前で呼ぶだけ。推測不要。

すでに稼働中:すべての Liquid ストアフロント、および Hydrogen の Developer Preview で本日から有効。インストールも設定も不要(原文 : "There's nothing to install or configure.")。

2仕組み図解 : 従来のエージェント vs WebMCP

BEFORE : ページを読んでクリックを模倣する エージェント HTML 取得 DOM を解析 ボタンの位置を推測 テーマごとに構造が違う クリックを模倣 画面遷移ごとに再解析 遅い / 壊れやすい slow and error-prone AFTER : ページがツールをブラウザに登録する エージェント ツール呼出 ブラウザ(WebMCP) search_catalog update_cart ページが登録したツール一覧 ストアフロント標準アクション アプリが使うのと同じ経路 買い物客のライブセッション上 テーマの挙動もそのまま カート更新でドロワーが開く テーマなら、agent 操作でも開く
WebMCP とは : ページがブラウザに対してツールを登録できるようにする提案中の Web 標準。Shopify は Google・Microsoft と並んで仕様策定に関わっている。
ポイントは「エージェントが勝手に画面を触る」のではなく、サイト側が呼んでいい操作を明示するという向きに変わること。

3エージェントが呼べるツール一覧

カタログ
4 ツール
カート
3 ツール
チェックアウト / 注文
2 ツール
ポリシー / FAQ
1 ツール

カタログ Catalog

search_catalogカタログを検索する
browse_storeストアを回遊する
get_product商品を取得する
show_variantバリエーションを表示する

カート Cart

get_cartカートの中身を取得する
update_cartカートを更新する
cancel_cartカートをキャンセルする

チェックアウト・注文 Checkout & orders

proceed_to_checkoutチェックアウトへ進む
manage_orders注文を管理する

その他コンテンツ Other content

search_shop_policies_and_faqsショップのポリシーと FAQ を検索する
各ツールの引数・戻り値のスキーマ、レート制限、エラー時の挙動はこの告知には記載なし。実装前に WebMCP ドキュメントで確認すること。

4クリック模倣 vs WebMCP の比較

項目従来(クリック模倣)WebMCP ツール
操作の発見方法 推測 各ページのコードを読む 明示 ページがツールを登録
速度・安定性 slow / error-prone(原文表記) 記事に定量値の記載なし(改善が目的と明記)
実行される場所 エージェント側の自動操作 買い物客のライブセッション上・見ているタブ内
カート操作の経路 UI をクリックして再現 アプリが使うのと同じ標準ストアフロントアクション
テーマの副作用 カート更新でドロワーが開くテーマならエージェント操作でも開く
マーチャントの作業 なし インストール・設定不要

5対応範囲と前提条件

Liquid ストアフロント

すべての Liquid ストアフロントで本日から有効。GA

Hydrogen

Developer Preview で有効。preview

ブラウザ側

エージェント対応は現時点で Chromium 系ブラウザのオリジントライアル経由に限定

WebMCP はまだ策定途上の標準。Shopify は Google・Microsoft とともに仕様に関与しているが、仕様変更のリスクは残る
オリジントライアルの終了時期、Hydrogen の GA 時期、対応国・対応プランの条件は記載なし

6マーチャント側でやること(3ステップ)

1

設定は不要

インストールも設定項目もない。Liquid ストアフロントなら既に稼働している。

2

テーマの挙動を確認

カート更新時にドロワー等を開くテーマは、エージェント操作でも同じ挙動が発火する。

3

ドキュメントを読む

詳細は WebMCP ドキュメント。自前エージェントを作るなら「Build commerce agents」。

7技術者が押さえるべき5つのポイント

1. 実行はサーバ間 API ではなく「タブの中」

エージェントの操作は買い物客のライブセッション上で起きる。Storefront API を裏で叩く外部連携とは前提が違い、ログイン状態・カート・セッションをそのまま共有する。

2. カート操作は「アプリと同じ標準アクション」

独自の裏口ではなく、既存アプリが使うのと同じストアフロントアクションを呼ぶ。既存のカート系フックやイベント設計がそのまま効く

3. テーマの副作用がエージェントにも発火する

カート更新でドロワーを開くテーマなら、エージェント操作でもドロワーが開く。モーダル・ポップアップ系のカスタマイズは、エージェント経由の連続操作を想定した回帰確認が要る

TRIAL

4. 標準もサポートも「途上」

WebMCP は提案段階の標準で、エージェント対応は Chromium 系のオリジントライアル限定。本番の主要導線としてではなく、追加チャネルとして設計するのが安全。

5. ツール名は「機能の公開契約」として読む

公開されているのは search_catalog / browse_store / get_product / show_variant / get_cart / update_cart / cancel_cart / proceed_to_checkout / manage_orders / search_shop_policies_and_faqs の 10 個。 「チェックアウトへ進む」までがツール範囲で、決済完了までエージェントがやり切るかどうかは記載なし。ポリシー・FAQ が検索対象に入っているため、返品規定や配送条件のページ整備がそのままエージェントの回答品質に効く

8業務に活かせる3つのユースケース

USE CASE 1

「AI エージェント経由の来訪」に耐えるストアかを棚卸しする

課題
Liquid ストアフロントでは設定不要でツールが公開済み。つまりマーチャントが何もしなくても、エージェントが操作しに来る前提が既に成立している。カスタムテーマの挙動が想定外に発火する恐れがある。
打ち手
Chromium 系ブラウザ+オリジントライアルの検証環境で、カタログ検索 → バリエーション表示 → カート更新 → チェックアウト遷移まで一気通貫でエージェントに操作させ、テーマの挙動を目視確認する。
効果
「カート更新でドロワーが開く」等のテーマ副作用が連続操作を阻害しないかを、事故る前に潰せる。
技術メモ
カート系は既存アプリと同じ標準ストアフロントアクションを通るため、既存のカートイベント監視をそのまま観測点に使える。
FAQ 返品 未整備
USE CASE 2

ポリシー・FAQ を「エージェントが読む前提」で書き直す

課題
search_shop_policies_and_faqs が公開ツールに含まれる = 返品・配送・保証の記述が、エージェントの回答品質にそのまま直結する。曖昧な FAQ は曖昧な回答になる。
打ち手
返品期限・送料条件・配送日数など、購入判断に効く条件を1 問 1 答で明示的に書く形へポリシー / FAQ ページを再構成する。
効果
エージェント経由の購入検討で「条件が分からず離脱」を減らせる。人間の閲覧者にとっても読みやすくなる。
技術メモ
ツールが返す内容の粒度・対象ページの範囲は告知に記載なし。実際に何が拾われるかは検証環境で叩いて確認すること。
search_catalog update_cart proceed_to_checkout
USE CASE 3

自社エージェント / 接客ボットを WebMCP ツールの上に載せ替える

課題
自前のショッピングエージェントを DOM 解析+クリック模倣で作っていると、テーマ変更のたびに壊れ、保守コストが積み上がる。
打ち手
公開された 10 ツール(カタログ 4 / カート 3 / チェックアウト・注文 2 / ポリシー 1)を呼ぶ実装へ寄せる。実装ガイドは「Build commerce agents」。
効果
テーマ構造への依存を切り離せる。操作が買い物客のライブセッション上で完結するため、セッション同期のための独自実装も減らせる。
技術メモ
動作環境は Chromium 系+オリジントライアル限定。非対応ブラウザ向けのフォールバック経路は必須。標準は策定途上のため、ツール呼び出し層は薄いアダプタで包んで仕様変更に備える。

9提案で使える1行サマリ

「ストアが AI エージェント向けの操作口(WebMCP ツール 10 個)を自分から公開するようになった。
Liquid ストアフロントは設定不要で稼働済み・Hydrogen は Developer Preview・エージェント側は Chromium のオリジントライアル限定。
今やるべきは導入作業ではなく、テーマの副作用確認とポリシー / FAQ の整備。」