Standard storefront events and actions テーマとアプリの「共通言語」が標準化された
原題: Standard storefront events and actions
図解 : Standard storefront events and actions(テーマとアプリの標準通信レイヤー) Themes / Developer Changelog Standard storefront events and actions テーマとアプリの「共通言語」が標準化された Liquid ストアフロントに、テーマとその上で動くコードの間の標準通信レイヤーが追加。テーマは イベントを発火 し、アプリやエージェントは アクションを呼び出す 。両方が全テーマで動き、セットで提供されるため実装は一度だけで済む。 このページの構成 そもそも何が変わるのか(30秒で理解) 仕組み図解 : events と actions の双方向 events(テーマ → アプリ)の中身 actions(アプリ → テーマ)の中身 actions のデフォルト挙動 vs テーマ側オーバーライド 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか これまでアプリ開発者は、テーマごとにバラバラな DOM 構造やイベントを読み解いて連携していた。 今回、Liquid ストアフロントに テーマとコードの「標準通信レイヤー」 が入り、 events(テーマが発火) と actions(アプリ/エージェントが呼ぶ) という 2 方向の共通インターフェースで会話できるようになった。 従来 : テーマごとに作り込み アプリは各テーマの DOM やカスタムイベントを個別に解析。テーマが変わると壊れ、データ取得のたびに追加 API 呼び出しが必要だった。 これから : 標準インターフェース events / actions は 全テーマで動く 。実装は一度きり。イベント購読は素の JavaScript、ペイロードが直接届くので追い API 不要。 2 仕組み図解 : events と actions の双方向 ポイントは 「両方が全テーマで動き、セットで出荷される」 こと。テーマ開発者は events を実装し、actions をオーバーライドする。アプリ開発者は events を購読し、actions を呼ぶ。役割は逆だが 実装は一度きり で済む設計になっている。 3 events(テーマ → アプリ)の中身 events は「コマース操作」を表す DOM イベント。テーマ開発者がテーマコード内で実装し、アプリ開発者は素の JavaScript で購読してペイロードを直接受け取る(追加の API 呼び出しは不要)。 shopify:product:view 商品が閲覧されたときに発火。閲覧トラッキングやレコメンドの起点に。 shopify:cart:lines-update カートの明細が更新されたときに発火。カート内容の同期や上乗せ提案に。 shopify:search:update 検索が更新されたときに発火。検索ワード分析やサジェスト連携に。 上記は記事で例示された 3 種。記事には「 and others (他にもある)」と明記されており、これら以外のイベントも存在する。 網羅リストはドキュメントを参照 のこと。 4 actions(アプリ → テーマ)の中身 actions は events と逆方向。 すべての Liquid ストアフロントで利用可能 で、アプリやエージェントが呼び出してテーマの挙動を起こす。 Shopify.actions.updateCart カートを更新する。アプリ側からカート内容を書き換えたいときに呼ぶ。 Shopify.actions.getCart 現在のカート状態を取得する。表示や判定の入力として使う。 Shopify.actions.openCart カート(ドロワー等)を開く。追加後にカートを見せる導線などに。 方向 呼ぶ側 / 実装する側 性質 events テーマが 発火 / アプリが 購読 コマース操作を表す DOM イベント。ペイロードが直接届く actions テーマが 挙動を提供/上書き / アプリが 呼び出し 全 Liquid ストアフロントで利用可。成功時に対応 event も発火 5 actions のデフォルト挙動 vs テーマ側オーバーライド 同じ updateCart でも、テーマがオーバーライドしているかどうかで体験が変わる。ここが本機能の肝。 デフォルト(標準箱出し) Storefront API + ページ再読込 テーマが何もしていない状態では、action は Storefront API を叩いてページをリロード する。確実に動くが、画面はフルリロードされる。 オーバーライド(テーマ実装) 再読込なしで UI を直接更新 テーマ開発者が action をオーバーライドすると、 リロードをスキップして UI を直接更新 できる。さらに成功時には対応する event を発火するので、購読側にも自然に伝わる。 アプリ側のコードは どちらの場合でも同じ呼び出し でよい。「リロードあり」か「リロードなし」かはテーマの実装次第で、アプリはその差を意識せず使える。これが「実装は一度だけ」の意味。 6 技術者が押さえるべき5つのポイント 1. 全テーマで動く共通レイヤー events / actions は特定テーマ依存ではなく、Liquid ストアフロント全体で利用可能。テーマごとの作り込み・DOM 解析からの脱却が狙い。 2. 購読は素の JavaScript events は DOM イベントなので、フレームワーク無しの plain JS で購読できる。 ペイロードが直接届き、追い API 呼び出しが不要 な点が実装・性能の両面で効く。 3. action 成功 → event 発火で往復が閉じる action は成功時に対応する event を emit する。つまり「アプリが起こした変更」も購読側に統一的に伝わり、 状態同期のループが一貫 する。 4. デフォルトとオーバーライドの二段構え 箱出しは Storefront API + リロードで「とりあえず動く」。テーマがオーバーライドすればリロードなしの滑らかな UI に。 アプリ側の呼び出しは不変 。 5. エージェント(AI)も第一級の呼び出し主体 記事は明示的に「apps and agents 」が actions を呼ぶと書いている。AI エージェントが標準アクションでストアフロント挙動を起こせる前提の設計で、将来の自動化・対話型購買 UX を見据えている。詳細仕様は ドキュメント参照 。 7 業務に活かせる3つのユースケース USE CASE 1 計測・トラッキングアプリの「テーマ非依存化」 課題 商品閲覧・カート更新・検索の計測タグを、ストアごと・テーマごとに DOM を読んで実装し直しており、テーマ変更のたびに壊れる。 打ち手 shopify:product:view / shopify:cart:lines-update / shopify:search:update を素の JS で購読し、ペイロードをそのまま計測基盤へ送る。 効果 テーマ差異に依存しない計測。実装は一度きりで保守コストが下がり、追い API 呼び出しが消えてページ負荷も軽くなる。 技術メモ 例示 3 種以外のイベント網羅は要ドキュメント確認。ペイロードのスキーマも合わせて検証する。 USE CASE 2 「アップセル / バンドル」アプリのリロードレス化 課題 カート追加系アプリが updateCart 相当の操作後にページをフルリロードしてしまい、体験が途切れて CVR を落としている。 打ち手 アプリは標準 Shopify.actions.updateCart → openCart を呼ぶだけにし、テーマ側で action をオーバーライドしてリロードなしの UI 更新に。 効果 滑らかなカート追加体験。アプリ側コードは不変のまま、テーマ対応の有無で自動的に最適な挙動になる。 技術メモ action 成功時に対応 event が発火するので、他の購読アプリ(計測等)とも整合が取れる。テーマ未対応ストアでもデフォルト挙動で安全に動く。 USE CASE 3 AI エージェント / チャットによる「対話で買える」導線 課題 チャットや AI アシスタントから「これカートに入れて」を実現したいが、ストアごとのカート操作 API を個別に叩く実装が重い。 打ち手 エージェントから標準 Shopify.actions.getCart / updateCart / openCart を呼ぶ。記事が言う「apps and agents」想定の正攻法。 効果 全 Liquid ストアフロントで動く対話型購買 UX を、テーマ個別対応なしで横展開できる。 技術メモ actions / events の正確なシグネチャ・対応範囲・認証要件は記事に詳細記載なし。実装前に 必ずドキュメントで確認 すること。 8 提案で使える1行サマリ 「テーマとアプリ/エージェントの会話を標準化する共通レイヤー。 テーマは events を発火・アプリは素の JS で購読(追い API 不要)、アプリは actions を呼び・テーマがオーバーライドすればリロードなし。 全テーマで動き、実装は一度きり。テーマ非依存の計測・アップセル・AI 購買導線をまとめて軽くできる。」 source : shopify.dev / changelog / standard-storefront-events-and-actions generated 2026-06-22