変化のないカート操作では carts/update Webhook が来なくなった

図解 ： 変化のないカート更新で carts/update Webhook が発火しなくなった Developer Changelog / Webhooks 変化のないカート操作では carts/update Webhook が来なくなった 同じ値を再送しただけのような「カートの中身が変わらない」操作では carts/update が送られなくなった。Webhook は「リクエストごと」ではなく「変更ごと」に 1 回になり、重複通知がなくなる。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： リクエストと Webhook の関係 Before / After 比較 記事に書いてあること／書いていないこと 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか 以前は カート操作のたびに必ず carts/update が送られていた。 今後は カートの中身やプロパティが実際に変わったときだけ 送られる。 以前 ： 1 リクエスト = 1 Webhook カートがすでに持っている値と同じ値を再送しただけでも carts/update が発生。結果として重複通知が届いていた。 今後 ： 1 変更 = 1 Webhook カートが変化しない操作では送信されない。アプリはカートへの変更 1 回ごとに 1 通の carts/update を受け取る。 2 仕組み図解 ： リクエストと Webhook の関係 図の数量・プロパティの例はわかりやすくするためのもの。記事に書かれている具体例は「 カートがすでに持っている値と同じ値を再送する 」操作だけ。送信条件は「カートの 中身（contents）またはプロパティ（properties）が変わったとき 」。 3 Before / After 比較 項目 以前 今後 送信のきっかけ 毎リクエスト カート操作のたびに必ず送信 変更時のみ 中身・プロパティが変わったとき 同じ値の再送 carts/update が送られる 送られない 重複通知 あり 解消 アプリが受け取る単位 リクエスト 1 回につき 1 通 カートの変更 1 回につき 1 通 4 記事に書いてあること／書いていないこと 記載あり 書いてあること ・カートが変わらない操作では carts/update が送信されない ・変更があれば毎回送信される ・以前は全カート操作で送信されていた ・重複通知がなくなり、変更ごとに 1 通になる ・関連ドキュメント ： Cart webhooks / Ajax Cart API 記載なし 書いていないこと ・対象の API バージョン ： 記載なし ・オプトイン／オプトアウトの有無 ： 記載なし ・適用開始の日時（公開日は 2026-10-12）： 記載なし ・ carts/create など他のトピックへの影響 ： 記載なし ・ペイロード形式の変更 ： 記載なし 「何をもって変更とみなすか」の細かい判定基準も記事にはない。境界ケース（並び順だけ違う、など）に依存する処理がある場合は、開発ストアで実際の挙動を確認すること。 5 技術者が押さえるべき5つのポイント 1. Webhook は「差分」を表すようになった carts/update が届けば、カートに何かしらの変更があったと考えてよい。「受信 = 実際の変更」という前提が成り立つ。 2. 受信件数は減る可能性がある 重複分がなくなるので、受信数をそのまま「カート活動量」として扱っていると数値が変わる。比較するときは変更前後で分けて見る。 3. 「送信 = 操作あり」とは使えなくなる 操作の生存確認やハートビートとして carts/update を使っていた場合、変化のない操作は届かない。操作の有無そのものを追うなら別の手段が必要。 4. 重複排除ロジックは残してよい 記事が言っているのは「変化のない操作では送らない」ことだけ。配信リトライによる重複について記載はないので、冪等な処理は今後も残す。 5. ストアフロントの Ajax Cart API 呼び出しも関係する 関連ドキュメントに Ajax Cart API が挙げられている。テーマやアプリブロックが同じ値で何度もカート API を呼んでいても、Webhook の受け手側には変更分しか届かない。ただし 不要な呼び出し自体がなくなるわけではない ので、フロント側の無駄なリクエストは引き続き見直す価値がある。 6 業務に活かせる3つのユースケース USE CASE 1 Webhook を受けるアプリのコスト・負荷の見直し 課題 carts/update を受けるたびに外部 API 呼び出しや DB 書き込みをしているため、重複通知の分まで処理が走っていた。 打ち手 変更後の受信件数と処理時間を計測し、変更前の数値と比べる。キューやワーカーの設定が過大になっていないか見直す。 効果 重複通知の処理がなくなる分、無駄な処理が減る。どれだけ減るかはストアの操作パターンによる。 技術メモ 自前の「前回と同じ内容ならスキップ」処理は不要になる可能性があるが、記事に書かれていないケースもあるので、外す前に実際の挙動で確かめる。 USE CASE 2 カート行動を集計しているダッシュボード・レポートの補正 課題 carts/update の件数を「カート更新回数」として KPI 化していると、この変更の前後で数値が下がって見える。 打ち手 レポートに変更日（2026-10-12 の公開）の注記を入れる。指標を「リクエスト数」ではなく「変更回数」として定義し直す。 効果 仕様変更による数値の落ち込みを、ビジネス上の悪化と取り違えずに済む。 技術メモ 正確な適用日時は記事に記載なし。受信ログで件数が下がった時点を確認して区切りを決める。 USE CASE 3 「受信 = 操作あり」を前提にしたロジックの点検 課題 carts/update の受信を「顧客がまだカートを触っている」というシグナルとして使っている処理（タイマー延長など）があると、同じ値の再送では届かなくなる。 打ち手 Webhook ハンドラを棚卸しし、「受信回数」や「受信時刻」に依存する処理を洗い出す。カートの中身の変化を前提にした処理に書き直す。 効果 変更後に起きうる想定外の挙動を、本番障害になる前に見つけられる。 技術メモ 開発ストアで、同じ値でカートを更新したときに Webhook が来ないことを確認するテストケースを足しておく。 7 提案で使える1行サマリ 「 carts/update は “リクエストごと” から “変更ごと” の通知になった。 重複通知がなくなり、受信は実際の変更 1 回につき 1 通。 受信件数を指標にしているアプリやレポートは、変更日を区切りに見直しを。」 source ： shopify.dev/changelog/unchanged-carts-no-longer-trigger-carts-update-webhooks 公開日 2026-10-12（Shopify Developer Changelog）