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

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（チャネルまたはカタログ）単位でバリエーションごとに公開状態を制御できる。バリエーションを削除する・商品を複製する・ストアフロントのコードで隠す、といった回避策が不要に。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： 公開判定は「2段ゲート」 非破壊・加算的な3つの大前提 Admin GraphQL API の変更点 アプリ種別ごとの影響 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか これまで「特定のバリエーション（サイズ・色など）だけ、このチャネルには出さない」を実現するには、 バリエーションを削除する／商品を複製する／ストアフロントのコードで隠す といった回避策が必要だった。 2026-07 から ProductVariant 自体が Publishable になり、publication（チャネル／カタログ）単位でバリエーションごとに公開・非公開を切り替えられる。 従来 ： バリエーション単位の公開制御が無い 「このバリエーションだけ隠す」には削除・商品複製・ストアフロント側で非表示にするなどの回避策しかなく、データが歪んだり保守が増えたりしていた。 新 ： publication 単位で個別に制御 バリエーションを削除も複製もせず、チャネル／カタログごとに「どのバリエーションを見せるか」を細かく決められる（API version 2026-07）。 2 仕組み図解 ： 公開判定は「2段ゲート」 バリエーションが表示されるかは、 ① 商品レベルの公開 を通過し、さらに ② バリエーションレベルの公開 を通過したものだけ。①が閉じていれば②に関係なく表示されない（商品レベルが優先）。 Publishable インターフェース とは ： Product や Collection が以前から備えていた「publication 単位で公開状態を持つ」共通の型。今回 ProductVariant もこれに準拠し、 resourcePublicationsv2 / publishedOnPublication でバリエーションの公開状態を読めるようになった。 3 非破壊・加算的な3つの大前提 記事は明確に「non-breaking, additive change（破壊的でない加算的変更）」と述べている。既存実装を壊さないための前提が3つある。 前提 1 商品レベル公開が優先 商品レベルの公開挙動は変わらない。商品が active かつチャネルに公開 されていなければ、その配下のどのバリエーションもそのチャネルに表示されない。 前提 2 デフォルトは「公開」（オプトアウト） バリエーションは既定で公開。商品レベルで公開している既存アプリは 無改修 でそのまま動く。 前提 3 非公開状態での作成が可能 バリエーションを非公開の状態で作成でき、購入者への 早期露出を防げる 。 4 Admin GraphQL API の変更点 1. publish/unpublish が変種 ID 対応 publishablePublish と publishableUnpublish が ProductVariant の ID を受け付けるようになった。 2. Publishable に準拠 ProductVariant が Product / Collection と同様に Publishable インターフェースに準拠。 resourcePublicationsv2 と publishedOnPublication を含む。 3. Product feed webhook が発火 バリエーションがフィードのチャネルに公開／削除されると、 product update として（variant added / deleted を伴って）product feed webhook が発火する。 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 / productVariantBulkCreate の variant.published: false を使う。 商品を公開するアプリ 改修不要 従来通り商品に publishablePublish を呼べばよい。バリエーション非公開がワークフローに関わるなら対応を検討。 多くのアプリは 無改修で動く 。能動的な対応が要るのは「feed を使わず Admin API で公開状態を読むチャネル／疑似チャネル」と「非公開でバリエーションを作りたいアプリ」の2類型。 6 技術者が押さえるべき5つのポイント 1. 公開は「商品 → バリエーション」の2段 商品レベル公開が常に優先。商品が active＋チャネル公開でないと、バリエーションをいくら公開しても表示されない。デバッグ時はまず商品レベルを疑う。 2. 読み取りは resourcePublicationsv2 Product / Collection と同じ Publishable の作法で、 ProductVariant.resourcePublicationsv2 から各 publication の公開状態を取得する。既存の Publishable 実装を流用しやすい。 3. デフォルト公開（オプトアウト） 何もしなければバリエーションは公開。「非公開で作る」は明示が必要 ＝ variant.published: false を productSet / productVariantBulkCreate で指定する。 4. 当面のイベント源は feed webhook 専用の variant_publication/* webhook は開発中。リアルタイムに変化を検知したいなら、まずは product feed の product update（variant added/deleted）に乗る設計が現実的。 5. API version 2026-07 が前提／Storefront 側仕様は記載なし 本機能は API version 2026-07 で利用可能。タグには Storefront GraphQL API も含まれるが、本文で説明されているのは Admin API の変更のみで、 Storefront 側の具体的な読み取り方法は記載なし 。ストアフロント表示の検証は別途必要。 7 業務に活かせる3つのユースケース USE CASE 1 チャネル／市場ごとに「出すバリエーション」を出し分け 課題 同一商品でも、特定カラー・特定サイズを「卸チャネルだけ」「特定マーケットのカタログだけ」に出したい。従来は商品複製や削除で対応し、在庫・SKU 管理が二重化していた。 打ち手 商品は1つのまま、出したくないバリエーションを対象 publication で publishableUnpublish 。チャネル／カタログ単位に公開状態を持たせる。 効果 商品の重複が消え、在庫・価格・分析が1商品に集約。チャネル別の見せ方を運用だけで切り替えられる。 技術メモ 表示確認は対象チャネルで「商品レベルが active＋公開」かを先に満たすこと。公開状態の読み取りは resourcePublicationsv2 。 USE CASE 2 新商品・新バリエーションのローンチを本番データ上で準備 課題 新サイズ・新色を事前に登録しておきたいが、登録した瞬間に購入者へ露出してしまうのを避けたい。 打ち手 productSet / productVariantBulkCreate の variant.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（チャネル／カタログ）単位でバリエーションごとに公開・非公開を制御できる。 非破壊・加算的で既存アプリは無改修、デフォルトは公開（オプトアウト）。 『商品レベル公開が常に優先』という大前提だけ押さえれば、商品の複製や削除なしでチャネル別の見せ分けが運用で完結する。」 source ： shopify.dev/changelog/publish-and-unpublish-product-variants-independently-from-product 公開日 2026-05-07 ／ generated 2026-05-23