Eventsサブスクリプションのクエリ複雑度上限が100ポイントに変更
250ポイントから100ポイントへ削減。既存サブスクリプションの見直しが必要です。
ShopifyはEventsサブスクリプションのクエリ複雑度上限を250ポイントから100ポイントへ引き下げます。Classic Webhooksには影響しません。上限を超えるサブスクリプションクエリを持つアプリは、2026年9月22日以降に対応が求められます。
1変更内容の図解：Before / After
2業務に活かせるユースケース
- 課題
- 商品の全バリアントを一括取得するクエリが250pt付近で動いており、100ptに引き下げ後にエラーになる
- 打ち手
- バリアント価格変更トリガーでは
$variantIdを使って変更された1バリアントの price / SKU / 親ProductID だけを取得するクエリに書き換える - 効果
- クエリポイントを大幅に削減しつつ、変更のあったバリアントを確実に捕捉できる。250件以降のバリアントもカバー可能
- 技術メモ
- バリアント価格トリガーは
$variantId変数を提供するが、商品タイトルトリガーは提供しない。変数の有無でサブスクリプションを分けること
- 課題
- 在庫・価格・メタフィールドを1つのEventsサブスクリプションにまとめており、複雑度が高い
- 打ち手
- 「在庫変更」「価格変更」「メタフィールド更新」の3つのサブスクリプションに分割し、各クエリを担当する変更データのみに絞る
- 効果
- 1サブスクリプションあたりの複雑度が下がり100pt以内に収まる。ハンドラーのロジックも単純化され保守性が向上する
- 技術メモ
- 同一トピックに対して複数のサブスクリプションを設定可能。各サブスクリプションに独自のトリガーとクエリを設定できる
- 課題
- ERP連携アプリが注文データの多くのフィールドを一括取得するクエリを使っており、移行後に動作が止まる可能性がある
- 打ち手
- ハンドラーが実際に使っているフィールドを洗い出し、不要なフィールドや
connectionsのfirst/last件数を削減してクエリを再設計する - 効果
- 必要なデータだけを取得することでポイントを削減し、ペイロードサイズの削減・処理速度の向上も副次的に得られる
- 技術メモ
- Eventsサブスクリプションのクエリ実行はアプリのAPIレートリミットにカウントされない点は変更後も同様
3技術者が押さえるべきポイント
| 項目 | 内容 |
|---|---|
| 対象 | Eventsサブスクリプションのみ。Classic Webhooksは対象外 |
| 複雑度の計算方法 | 選択フィールド・返却データ型・connections の first/last 件数に基づいてShopifyが算出（GraphQL query cost計算に準拠） |
| 上限の適用単位 | サブスクリプションクエリ1件ごとに適用。複数サブスクリプションの合計ではない |
| APIレートリミットへの影響 | Eventsサブスクリプションのクエリ実行はアプリのAPIレートリミットにカウントされない（変更後も同様） |
| 100ptを超えるユースケース | 元記事によると、コミュニティフォーラムへのフィードバックを推奨。現時点で例外対応の仕組みは記載なし |
| 移行の手順 | ①既存サブスクリプションの複雑度を確認 → ②100pt超のクエリを特定 → ③役割・トリガー別に分割 → ④利用可能な変数とクエリをマッチング |
📋 チェックリスト：移行前に確認すること
- 現在のEventsサブスクリプションのクエリ複雑度を計測する
-
connectionsでfirst: 250などを使っているクエリがないか確認する - ハンドラーが実際に使用しているフィールドのみに絞り込む
- トリガーごとに利用できる変数（例:
$variantId）を確認し、必要に応じてサブスクリプションを分割する - 分割後も必要なフィールドとリレーションデータがカバーされているか検証する
Eventsサブスクリプションのクエリ複雑度上限が250→100ポイントに引き下げられるため、既存クエリを役割別・トリガー別に分割し、取得フィールドを必要最小限に絞ることで対応できます。
Source: https://shopify.dev/changelog/events-subscription-query-complexity-limit-is-changing-to-100-points | 公開日: 2026年9月22日
Share:
Polaris 2.0 RC：新管理画面デザインへの対応ガイド