Shopify 2026-07 新コレクションモデル完全解説

8月 08, 2026

API CHANGE

Shopify 2026-07
新コレクションモデル完全解説

ruleSet から sources へ — マルチソース・除外条件・バリアントメンバーシップが一気に解禁

Shopify GraphQL Admin API バージョン 2026-07 より、コレクションの内部モデルが刷新されます。従来の単一 ruleSet に代わり、複数のソースを持つ マルチソースモデルが導入。包含・除外条件の強型化、アプリをまたいで再利用できるシェアラブルソース、Shopify Functions でのバリアント単位メンバーシップ判定が一度に解禁されます。既存の ruleSet はクエリ可能なまま非推奨となるため、段階的な移行が可能です。

OVERVIEW

01何が変わったのか — Before / After

ARCHITECTURE

02新モデルの構造 — sources の全体像

USE CASES

03業務に活かせる具体ユースケース

課題: 「セール対象タグが付いている商品のうち、在庫切れバリアントだけ除外したコレクション」を従来の ruleSet では表現できなかった。
打ち手: CollectionConditionsSource の exclusionConditions に在庫切れバリアント条件を設定し、target: VARIANTS で動作させる。inclusionConditions にタグ条件を追加。
効果: バリアント単位で除外制御が完結するため、商品ページに表示しつつコレクションには出さないという細粒度の在庫管理が実現できる。
技術メモ: 2026-07 以降の API が必須。Shopify Functions の ProductVariant.inAnyCollection / inCollections と組み合わせてディスカウント関数内でも判定可能。

課題: 複数のブランドストアを運営するショップで、「期間限定セール」「会員限定」などの共通ロジックを全ブランドのコレクションに同期反映したかったが、毎回個別設定が必要だった。
打ち手: シェアラブルソース (shareable: true) として共通条件ロジックをアプリ側で一元管理し、CollectionShareableSourceInput { sourceId } を各コレクションの sourcesToCreate に渡してリンクする。
効果: ロジック変更時は collectionConditionsSourceUpdate 1回で全コレクションに即時反映。管理コストが大幅に削減できる。
技術メモ: シェアラブルソースを削除すると全リンクコレクションから自動デタッチされる。更新・削除できるのはオーナーアプリのみ。同一ロジックを複数コレクションで使わない場合は通常の collection mutation を使う。

課題: Shopify Functions 内のディスカウントロジックで「商品がコレクションに属しているか」を判定する際、バリアント単位の判定ができず、商品全体の判定しか取れなかった。
打ち手: Functions の ProductVariant 型に追加された inAnyCollection(ids: [ID!]!): Boolean! と inCollections(ids: [ID!]!): [CollectionMembership!]! を使い、バリアント単位で所属判定を実行する。
効果: 「特定サイズのみ割引」「限定カラーのみセール価格」といったバリアント粒度のプロモーションロジックを Functions 内で完結させられる。
技術メモ: 既存の Product.inAnyCollection / Product.inCollections は引き続き商品レベルの判定を返す。バリアント判定が不要な場合は既存フィールドで対応可。2026-07 API 対応の Functions ランタイムが必要（公式ドキュメントで確認を）。

DEV NOTES

04技術者が押さえるべき5つのポイント

#	ポイント	詳細	影響度
1	後方互換性	2026-07 では非推奨の `ruleSet`・`collectionCreate(input:)`・`collectionUpdate(input:)` は引き続きクエリ可能。段階的移行が可能。ただし 2026-07 以前のAPIバージョンでは新モデル利用コレクションがクエリから除外される。	要注意
2	優先順位の衝突	`collectionCreate`/`collectionUpdate` に `input` と `collection` の両方を渡した場合、`collection` 引数が優先される。移行期間中の二重渡しミスに注意。	破壊的
3	増分更新	`CollectionUpdateInput` の `sourcesToCreate` / `sourcesToUpdate` / `sourcesToDelete` でソースを個別に操作可能。コレクション定義全体の置き換えは不要。	便利
4	条件の型安全性	各条件は具体型を持つ強型システム。例: タグルール → `CollectionSourceInclusionConditionProductTag`。旧 `ruleSet` の各ルールに対応する inclusion condition 型が存在する。	設計
5	メタフィールド条件	`collectionConditionMetafieldDefinitions` クエリで、呼び出しアプリのアクス権限にスコープされたメタフィールド定義を取得し、inclusion condition として使用可能。	新機能