The article maps to the already-present (untracked) file, but that file's footer uses a wrong source URL (`changelog.shopify.com/...`) instead of the given `shopify.dev` changelog URL. Per the task's output contract, I'll generate fresh, correct HTML. Here it is: 図解 : Shopify 商品バリエーション単位の公開制御(Publish Variants Independently)
Admin GraphQL API / Storefront GraphQL API ・ 2026-07

バリエーションを
商品から独立して公開/非公開にできる

API version 2026-07 から ProductVariant が Publishable になり、publication(チャネルまたはカタログ)単位でバリエーションごとに公開状態を制御できる。バリエーションを削除する・商品を複製する・ストアフロントのコードで隠す、といった回避策が不要に。

このページの構成
  1. そもそも何が変わるのか(30秒で理解)
  2. 仕組み図解 : 公開判定は「2段ゲート」
  3. 非破壊・加算的な3つの大前提
  4. Admin GraphQL API の変更点
  5. アプリ種別ごとの影響
  6. 技術者が押さえるべき5つのポイント
  7. 業務に活かせる3つのユースケース
  8. 提案で使える1行サマリ

1そもそも何が変わるのか

これまで「特定のバリエーション(サイズ・色など)だけ、このチャネルには出さない」を実現するには、バリエーションを削除する/商品を複製する/ストアフロントのコードで隠す といった回避策が必要だった。
2026-07 から ProductVariant 自体が Publishable になり、publication(チャネル/カタログ)単位でバリエーションごとに公開・非公開を切り替えられる。

従来 : バリエーション単位の公開制御が無い

「このバリエーションだけ隠す」には削除・商品複製・ストアフロント側で非表示にするなどの回避策しかなく、データが歪んだり保守が増えたりしていた。

新 : publication 単位で個別に制御

バリエーションを削除も複製もせず、チャネル/カタログごとに「どのバリエーションを見せるか」を細かく決められる(API version 2026-07)。

2仕組み図解 : 公開判定は「2段ゲート」

バリエーションが表示されるかは、① 商品レベルの公開を通過し、さらに② バリエーションレベルの公開を通過したものだけ。①が閉じていれば②に関係なく表示されない(商品レベルが優先)。

ゲート① 商品レベル 商品が active で チャネルに公開 = 大前提(優先) ゲート② バリエーション S … resourcePublicationsv2 = 公開 M … 公開 L … 非公開(unpublish) publication 単位で判定 そのチャネルでの表示 ✓ S を表示 ✓ M を表示 — L は出さない ①かつ②を満たす分だけ ※ ゲート①が閉じていれば、②の状態に関係なく一切表示されない
Publishable インターフェースとは : Product や Collection が以前から備えていた「publication 単位で公開状態を持つ」共通の型。今回 ProductVariant もこれに準拠し、resourcePublicationsv2 / publishedOnPublication でバリエーションの公開状態を読めるようになった。

3非破壊・加算的な3つの大前提

記事は明確に「non-breaking, additive change(破壊的でない加算的変更)」と述べている。既存実装を壊さないための前提が3つある。

前提 1

商品レベル公開が優先

商品レベルの公開挙動は変わらない。商品が active かつチャネルに公開 されていなければ、その配下のどのバリエーションもそのチャネルに表示されない。

前提 2

デフォルトは「公開」(オプトアウト)

バリエーションは既定で公開。商品レベルで公開している既存アプリは 無改修 でそのまま動く。

前提 3

非公開状態での作成が可能

バリエーションを非公開の状態で作成でき、購入者への 早期露出を防げる

4Admin GraphQL API の変更点

publish

1. publish/unpublish が変種 ID 対応

publishablePublishpublishableUnpublishProductVariant の ID を受け付けるようになった。

2. Publishable に準拠

ProductVariant が Product / Collection と同様に Publishable インターフェースに準拠。resourcePublicationsv2publishedOnPublication を含む。

3. Product feed webhook が発火

バリエーションがフィードのチャネルに公開/削除されると、product update として(variant added / deleted を伴って)product feed webhook が発火する。

soon

4. 専用 webhook は開発中

variant_publication/create・update・delete webhook は まだ開発中で、近日中(imminently)に提供予定。

専用の variant_publication/* webhook の正確な提供時期や、Storefront GraphQL API 側の具体的な読み取り仕様は記載なし。現時点で確実なイベント源は product feed webhook と、Admin API での resourcePublicationsv2 読み取り。

5アプリ種別ごとの影響

アプリの種類必要な対応ポイント
product feed を使うチャネルアプリ 改修不要 フィードが商品にバリエーションを追加/削除し、増分同期 webhook が発火する。
feed を使わず Admin API で公開状態を読むチャネル/疑似チャネル 対応推奨 ProductVariant.resourcePublicationsv2 で各バリエーションの公開状態を読む実装を追加すべき。
商品公開後にバリエーションを作るアプリ 要確認 新バリエーションは親商品の全 publication で公開がデフォルト。非公開で作るなら productSet / productVariantBulkCreatevariant.published: false を使う。
商品を公開するアプリ 改修不要 従来通り商品に publishablePublish を呼べばよい。バリエーション非公開がワークフローに関わるなら対応を検討。
多くのアプリは 無改修で動く。能動的な対応が要るのは「feed を使わず Admin API で公開状態を読むチャネル/疑似チャネル」と「非公開でバリエーションを作りたいアプリ」の2類型。

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

商品 変種

1. 公開は「商品 → バリエーション」の2段

商品レベル公開が常に優先。商品が active+チャネル公開でないと、バリエーションをいくら公開しても表示されない。デバッグ時はまず商品レベルを疑う。

v2

2. 読み取りは resourcePublicationsv2

Product / Collection と同じ Publishable の作法で、ProductVariant.resourcePublicationsv2 から各 publication の公開状態を取得する。既存の Publishable 実装を流用しやすい。

3. デフォルト公開(オプトアウト)

何もしなければバリエーションは公開。「非公開で作る」は明示が必要 = variant.published: falseproductSet / productVariantBulkCreate で指定する。

4. 当面のイベント源は feed webhook

専用の variant_publication/* webhook は開発中。リアルタイムに変化を検知したいなら、まずは product feed の product update(variant added/deleted)に乗る設計が現実的。

2026-07

5. API version 2026-07 が前提/Storefront 側仕様は記載なし

本機能は API version 2026-07 で利用可能。タグには Storefront GraphQL API も含まれるが、本文で説明されているのは Admin API の変更のみで、Storefront 側の具体的な読み取り方法は記載なし。ストアフロント表示の検証は別途必要。

7業務に活かせる3つのユースケース

A B
USE CASE 1

チャネル/市場ごとに「出すバリエーション」を出し分け

課題
同一商品でも、特定カラー・特定サイズを「卸チャネルだけ」「特定マーケットのカタログだけ」に出したい。従来は商品複製や削除で対応し、在庫・SKU 管理が二重化していた。
打ち手
商品は1つのまま、出したくないバリエーションを対象 publication で publishableUnpublish。チャネル/カタログ単位に公開状態を持たせる。
効果
商品の重複が消え、在庫・価格・分析が1商品に集約。チャネル別の見せ方を運用だけで切り替えられる。
技術メモ
表示確認は対象チャネルで「商品レベルが active+公開」かを先に満たすこと。公開状態の読み取りは resourcePublicationsv2
公開予約
USE CASE 2

新商品・新バリエーションのローンチを本番データ上で準備

課題
新サイズ・新色を事前に登録しておきたいが、登録した瞬間に購入者へ露出してしまうのを避けたい。
打ち手
productSet / productVariantBulkCreatevariant.published: false で非公開のまま作成 → ローンチ時に publishablePublish で一斉公開。
効果
商品データ・画像・在庫を本番に仕込んでおける。露出タイミングを完全に制御でき、フライング販売を防止。
技術メモ
非公開作成は明示指定が必須(既定は公開)。公開切替の検知は当面 product feed webhook 経由で。専用 webhook は開発中。
USE CASE 3

自社チャネル/疑似チャネルアプリのバリエーション公開同期に対応

課題
product feed を使わず Admin API で公開状態を読む自社チャネル/疑似チャネルアプリは、商品単位でしか公開を見ておらず、バリエーション単位の非公開を取りこぼす。
打ち手
ProductVariant.resourcePublicationsv2 を読んで、バリエーションごとの公開状態を同期処理に組み込む。
効果
非公開のバリエーションを誤って外部に露出させない。Shopify 側の公開モデルとアプリ側の表示が一致する。
技術メモ
Publishable インターフェース準拠なので、Product / Collection 向けの既存読み取りロジックを ProductVariant に展開しやすい。

8提案で使える1行サマリ

ProductVariant が Publishable に。API version 2026-07 から publication(チャネル/カタログ)単位でバリエーションごとに公開・非公開を制御できる。
非破壊・加算的で既存アプリは無改修、デフォルトは公開(オプトアウト)。
『商品レベル公開が常に優先』という大前提だけ押さえれば、商品の複製や削除なしでチャネル別の見せ分けが運用で完結する。」