【Shopify最新ニュース2026・開発者向け】GraphQL Admin API 2026-10で「>」の日時フィルタが1秒丸ごと除外に

2026年10月22日

開発者向けの変更です。
注文などのデータを、アプリや外部のシステムで Shopify から取り込んでいる店にも関わる話です。

2026-10 から、端数の無い「>」の日時フィルタは指定した1秒を丸ごと除きます

変わったのは、GraphQL Admin API のバージョン 2026-10 から。検索の構文で日時に「>」を使ったときの結果です。
秒の端数を付けずに指定すると、その1秒が丸ごと除かれます。

掲載は2026年10月19日、Shopify の developer changelog です。
フラグは「Update」。

出典: Shopify developer changelog「Exclusive > timestamp filters exclude the full second」2026年10月19日
https://shopify.dev/changelog/posts/exclusive-timestamp-filters

As of API version 2026-10, an exclusive lower bound (>) on a timestamp filter in the GraphQL Admin API search syntax excludes the full second.
（API バージョン 2026-10 から、GraphQL Admin API の検索構文で、日時のフィルタに付けた排他的な下限「>」は、その1秒を丸ごと除きます）

公式の例は created_at:>'2026-09-15T12:00:02Z'。12:00:02.500 に作られた注文を、もう返しません。

これまでは、同じ1秒のうち、その秒ちょうどより後の記録が「>」にも「<=」にも当たっていました

背景にあるのは、API が返す日時と、内部で持っている日時の細かさの違いです。

The GraphQL Admin API returns timestamps such as createdAt to the second, but internally some resources store them with fractional seconds.
（GraphQL Admin API は createdAt などの日時を秒単位で返しますが、内部では秒の端数まで持っているリソースがあります）

2026-10 より前は、>'…T12:00:02Z' を 12:00:02.000000 と比べていました。
その1秒のうち .000000 より後の記録は「>」に当たり、返る createdAt は 12:00:02Z のまま。
同じ記録が <='…T12:00:02Z' にも当たっていました。

2026-10 からは、「>T」と「<=T」が重なりません

2026-10 からは、端数の無い「>」の値は、その1秒の終わり＝12:00:02.999999 の後から始まります。

A record matches >T only when the timestamp that the API returns for it is later than T, so >T and <=T no longer overlap.
（ある記録が >T に当たるのは、API がその記録について返す日時が T より後のときだけです。そのため >T と <=T はもう重なりません）

「>=」「<」「<=」と、日付だけの値・端数付きの値は変わりません

公式は、変わらないものも挙げています。どのバージョンでも同じです。

>=・<・<=
日付だけの値。例 created_at:>2026-09-15
秒の端数を付けた値。例 created_at:>'2026-09-15T12:00:02.250Z'

公式が挙げる中で変わるのは、端数を付けない日時に「>」を使ったときだけです。

2026-10 に上げたあと、前回の同期の日時を端数なしの「>」で渡すアプリは、取りこぼすおそれがあります

公式が影響を受けるとするのは、次のアプリです。

Apps that send a > bound without fractional seconds on a timestamp filter in the query argument of a GraphQL Admin API connection, for example created_at on the orders query.
（GraphQL Admin API の connection の query 引数で、日時のフィルタに秒の端数なしの「>」を送るアプリ。例えば orders クエリの created_at）

公式が確かめるよう求めているのは、前に受け取った日時を「>」の下限に使う問い合わせです。
例えば、最後に見た記録より新しいものを取る使い方です。

2026-07 以前のアプリは、いま変える必要はありません

Apps on 2026-07 or earlier don’t need to change anything.
（2026-07 以前のバージョンを使うアプリは、何も変える必要がありません）

「>」のフィルタを確かめるのは、アプリを 2026-10 に上げる前です。

同じ1秒に後から作られた記録を落とせないなら、「>=」にして id で重複を除きます

公式の示す手順は2つです。

前の応答で受け取った日時を「>」の下限に使っている問い合わせを探す
同じ1秒に後から作られた記録を落とせないなら、その日時で「>=」を使い、id で重複を除く

公式のコード例は、次の形です。

query OrdersSinceLastSync { orders(first: 50, sortKey: CREATED_AT, query: "created_at:>='2026-09-15T12:00:02Z'") { nodes { id createdAt } } }

🔴 公式に書かれていないこと

次の点は、一次ソースにありません。

秒の端数まで持っているリソースがどれかは書かれていません。「some resources」とだけあります。例として挙がるのは orders クエリの created_at です
updated_at など、created_at 以外の日時のフィールドも同じかは、個別には書かれていません。書かれているのは「a timestamp filter」という言い方です
2026-10 より前に、実際に取りこぼしや二重取りが起きた件数は書かれていません
REST Admin API や Storefront API で同じことが起きるかは書かれていません。Affected APIs は GraphQL Admin API です
Webhook や一括操作＝bulk operations の検索も対象かは書かれていません
2026-07 のサポートがいつ終わるかは、この1本には書かれていません
🔴 本記事は API を呼んで確かめていません。記載が無いことをもって「変わる」とも「変わらない」とも書きません

開発者と店がやること

開発者は、アプリが使っている GraphQL Admin API のバージョンを確かめる
開発者は、2026-10 に上げる前に、query 引数で端数なしの日時に「>」を使っている箇所を探す
開発者は、同じ1秒に後から作られた記録を落とせないなら、前回の同期の日時を「>」で渡している箇所を「>=」に替え、id で重複を除く
店は、注文の取り込みを外部のアプリや制作会社に任せているなら、この変更への対応を聞いておく

🔵 上の手順はキクシル編集部の整理で、公式の記載ではありません。4 は店向けに足した整理で、一次ソースは店に何かを求めていません。

出典

Shopify developer changelog「Exclusive > timestamp filters exclude the full second」2026年10月19日
https://shopify.dev/changelog/posts/exclusive-timestamp-filters

上記の Shopify 公式の情報だけを一次情報として使っています。
次の事項は「未確認」として扱い、推測で補っていません。