Liquid ストアフロントに、テーマとその上で動くコードの間の標準通信レイヤーが追加。テーマは イベントを発火し、アプリやエージェントは アクションを呼び出す。両方が全テーマで動き、セットで提供されるため実装は一度だけで済む。
アプリは各テーマの DOM やカスタムイベントを個別に解析。テーマが変わると壊れ、データ取得のたびに追加 API 呼び出しが必要だった。
events / actions は 全テーマで動く。実装は一度きり。イベント購読は素の JavaScript、ペイロードが直接届くので追い API 不要。
events は「コマース操作」を表す DOM イベント。テーマ開発者がテーマコード内で実装し、アプリ開発者は素の JavaScript で購読してペイロードを直接受け取る（追加の API 呼び出しは不要）。
shopify:product:view商品が閲覧されたときに発火。閲覧トラッキングやレコメンドの起点に。
shopify:cart:lines-updateカートの明細が更新されたときに発火。カート内容の同期や上乗せ提案に。
shopify:search:update検索が更新されたときに発火。検索ワード分析やサジェスト連携に。
actions は events と逆方向。すべての Liquid ストアフロントで利用可能で、アプリやエージェントが呼び出してテーマの挙動を起こす。
Shopify.actions.updateCartカートを更新する。アプリ側からカート内容を書き換えたいときに呼ぶ。
Shopify.actions.getCart現在のカート状態を取得する。表示や判定の入力として使う。
Shopify.actions.openCartカート（ドロワー等）を開く。追加後にカートを見せる導線などに。
| 方向 | 呼ぶ側 / 実装する側 | 性質 |
|---|---|---|
| events | テーマが 発火 ／ アプリが 購読 | コマース操作を表す DOM イベント。ペイロードが直接届く |
| actions | テーマが 挙動を提供/上書き ／ アプリが 呼び出し | 全 Liquid ストアフロントで利用可。成功時に対応 event も発火 |
同じ updateCart でも、テーマがオーバーライドしているかどうかで体験が変わる。ここが本機能の肝。
テーマが何もしていない状態では、action は Storefront API を叩いてページをリロードする。確実に動くが、画面はフルリロードされる。
テーマ開発者が action をオーバーライドすると、リロードをスキップして UI を直接更新できる。さらに成功時には対応する event を発火するので、購読側にも自然に伝わる。
events / actions は特定テーマ依存ではなく、Liquid ストアフロント全体で利用可能。テーマごとの作り込み・DOM 解析からの脱却が狙い。
events は DOM イベントなので、フレームワーク無しの plain JS で購読できる。ペイロードが直接届き、追い API 呼び出しが不要な点が実装・性能の両面で効く。
action は成功時に対応する event を emit する。つまり「アプリが起こした変更」も購読側に統一的に伝わり、状態同期のループが一貫する。
箱出しは Storefront API ＋ リロードで「とりあえず動く」。テーマがオーバーライドすればリロードなしの滑らかな UI に。アプリ側の呼び出しは不変。
記事は明示的に「apps and agents」が actions を呼ぶと書いている。AI エージェントが標準アクションでストアフロント挙動を起こせる前提の設計で、将来の自動化・対話型購買 UX を見据えている。詳細仕様はドキュメント参照。
shopify:product:view / shopify:cart:lines-update / shopify:search:update を素の JS で購読し、ペイロードをそのまま計測基盤へ送る。updateCart 相当の操作後にページをフルリロードしてしまい、体験が途切れて CVR を落としている。Shopify.actions.updateCart → openCart を呼ぶだけにし、テーマ側で action をオーバーライドしてリロードなしの UI 更新に。Shopify.actions.getCart / updateCart / openCart を呼ぶ。記事が言う「apps and agents」想定の正攻法。