バリエーションが 複数バーコードに対応（最大20本）

図解 ： Shopify バリエーションが複数バーコードに対応（最大20本） Products / 新機能 バリエーションが 複数バーコードに対応（最大20本） 1 バリエーション ＝ バーコード 1 本だった制約が撤廃。箱の UPC、棚札の自社 EAN、マーケットプレイスの ASIN を、全部そのバリエーションに持たせられる。どれで検索してもヒットする。 このページの構成 そもそも何が変わるのか（30秒で理解） 図解 ： 1 本しか持てなかった世界と、20 本持てる世界 できるようになったこと（6つ） バーコードの種類とフォーマット検証 従来 vs これから 比較 変わらないこと ： 「1 本目」ルール 操作の入口（4 パターン） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか これまで、1 つの商品バリエーションが持てるバーコードは 1 本だけ だった。 同じ商品に「メーカーの UPC」「自社プライベートラベルの EAN」「マーケットプレイスの ASIN」が 同時に存在しても、 どれか 1 本を選んで、残りはスプレッドシート管理 するしかなかった。 今回、 1 バリエーションあたり最大 20 本 のバーコードを持てるようになり、 そのどれで引いても同じ商品が特定できる 。 課題 ： 現物には複数のコードが付いている 箱にはメーカーの UPC。棚札には自社の EAN。マーケットプレイス出品には ASIN。現実の 1 商品は複数の識別子を持っている。 従来の逃げ道 ： スプレッドシート Shopify に入れられない残りのコードは外部の表で管理。二重管理・検索不能・属人化の温床になっていた。 解決 ： 最大20本を商品側に持たせる バリエーション詳細に直接 20 本まで登録。 そのどれでも商品を識別できる ので、外部表を畳める。 2 図解 ： 1 本しか持てなかった世界と、20 本持てる世界 ポイントは 「入力は多対1」だが「出力は依然として 1 本」 だということ。 登録・スキャン・検索は 20 本すべてが対象になる一方で、 販売チャネルが読むのは 1 本目のバーコード のまま。だから既存の連携が壊れない。 3 できるようになったこと（6つ） 1. 詳細画面で追加 / スキャン / 削除 バリエーション詳細ページ上で直接、バーコードの追加・スキャン・削除ができる。 2. スマホの Shopify アプリからも PC の管理画面だけでなく、スマートフォンの Shopify アプリからも同じ操作ができる。現場でそのままスキャン。 3. 種類の指定とフォーマット検証 UPC / EAN / ISBN / GTIN / ASIN の種類を選ぶと、その規格の書式に照らして検証される。桁の打ち間違いが入力時点で弾かれる。 4. 一括編集ツールで複数バリエーションを一気に bulk editor（一括編集）で、多数のバリエーションのバーコードをまとめて更新できる。 5. 商品 CSV でインポート / エクスポート 商品 CSV の Variant Barcodes 列で、20 本のセットをまとめて出し入れできる。 6. どのバーコードでも商品が見つかる 1 本目に限らず、 バリエーションが持つどのバーコードからでも 商品を検索できる。 4 バーコードの種類とフォーマット検証 各バーコードには「種類」を指定する。指定した規格の書式に沿っているかをその場で検証してくれるので、 タイプミスがデータに残らない 。 UPC 規格に沿った書式検証あり EAN 規格に沿った書式検証あり ISBN 書籍向け。書式検証あり GTIN 国際標準。書式検証あり ASIN マーケットプレイス向け。書式検証あり Custom 規格に従わない社内コード用 入力時バリデーションがある のが実務的に大きい。従来のフリーテキスト運用では、桁落ち・全角混入・チェックデジット誤りが後工程（ラベル印刷・チャネル連携）まで気づかれなかった。 Custom は検証されない前提 なので、規格に沿うものは必ず正しい種類を選ぶ運用ルールにしておくとよい。 5 従来 vs これから 比較 項目 従来 これから 1 バリエーションの保持数 1 本 最大 20 本 種類（タイプ）の指定 無し UPC / EAN / ISBN / GTIN / ASIN / Custom 入力チェック 実質フリー入力 規格書式で検証 （Custom を除く） 検索 登録した 1 本でのみヒット どのバーコードでもヒット 一括更新 一括編集ツール（1 本分） 一括編集ツールで複数バリエーションをまとめて CSV 従来のバーコード列 Variant Barcodes 列でセット全体を入出力 販売チャネルが読む値 その 1 本 1 本目 （従来と同じ挙動） 移行作業 — 不要 既存バーコードはそのまま 6 変わらないこと ： 「1 本目」ルール 既存のバーコードはすでに入っているので、 マイグレーション作業は不要 。 そして 「単一のバーコードが期待される場所」では、これまで通り 1 本目が使われる 。 ラベル、販売チャネルのフィード、アプリは 今日と全く同じように動き続ける 。 裏を返すと「並び順」が実質の設定項目になる。 チャネルに出したいコードは必ず 1 本目に置くこと。CSV 一括投入や一括編集で順序が入れ替わると、ラベルやフィードに載る値が変わる可能性がある。 投入後は 1 本目を目視確認する運用 を入れておきたい。 7 操作の入口（4 パターン） 1 バリエーション詳細ページ 1 件ずつ、追加・スキャン・削除。種類の指定もここ。 2 スマホの Shopify アプリ 現場・倉庫でそのままカメラでスキャンして登録。 3 一括編集ツール 多数のバリエーションのバーコードをまとめて更新。 4 商品 CSV Variant Barcodes 列でセット全体をインポート／エクスポート。 8 技術者が押さえるべき5つのポイント 1. データモデルは「1 対多 ＋ 代表値」 バリエーションは複数バーコードを保持できるが、 単一バーコードが期待される箇所では 1 本目が使われる 。既存の「1 バリエーション 1 バーコード」を前提にした処理は壊れないが、 順序が意味を持つ配列 になった点は設計上の変化。 2. バリデーションはプラットフォーム側に移った UPC / EAN / ISBN / GTIN / ASIN は規格書式で検証される。 アプリ側やミドルウェアで自前実装していたチェックデジット検証は役割が縮小 する。ただし Custom は検証対象外 なので、社内コードの整合性は引き続き自分たちの責任。 3. CSV の列が増える ＝ 既存パイプラインは要確認 Variant Barcodes 列でセット全体を入出力する。商品 CSV をパースしている ETL・在庫連携バッチ・PIM 連携は、 列構成の変化に耐えるか確認が必要 。列位置決め打ちのスクリプトは事故りやすい。 4. 検索の一致対象が広がった 「1 本目だけ」ではなく バリエーションが持つ任意のバーコードで商品が引ける 。逆に言えば、 1 件のスキャンに対する候補が広がる ということでもある。同じコードを複数バリエーションに登録した場合の挙動は記事に 記載なし なので、重複登録の運用ルールは自分たちで決めておくのが安全。 5. API / Webhook 仕様、対応プラン、20 本超過時の挙動は「記載なし」 今回のアナウンスは 管理画面・モバイルアプリ・一括編集・CSV・検索 という運用面の説明に限られている。Admin GraphQL / REST でのフィールド表現、Webhook のペイロード、対応プラン・対応国、上限 20 本に達したときの挙動については この記事に記載がない 。自動連携を組む前に、 開発ストアで実データを取得して確認すること 。 9 業務に活かせる3つのユースケース USE CASE 1 「バーコード対応表スプレッドシート」を廃止して、識別子を Shopify に一本化 課題 Shopify に入れられるバーコードが 1 本だけだったため、メーカー UPC・自社 EAN・マーケットプレイス ASIN の対応関係を Excel／スプレッドシートで並行管理。担当者しか更新できず、Shopify 側の商品と乖離していく。 打ち手 対応表を Variant Barcodes 列を含む商品 CSV に整形して一括インポート → 各コードに正しい種類（UPC / EAN / ASIN / Custom）を付与 → 元のスプレッドシートを参照専用にして段階的に廃止。 効果 二重管理の解消。商品マスタが唯一の正になり、どのコードで問い合わせが来ても管理画面の検索だけで特定できる。 技術メモ 投入時に チャネルに出したいコードを 1 本目に置く こと（1 本目がラベル・フィード・アプリに流れる）。規格に沿うコードは Custom ではなく正しい種類を選ぶと、インポート時点で書式エラーを検出できる。 USE CASE 2 店舗・倉庫の「箱のコードでは引けない」問題を現場スキャンで潰す 課題 棚札には自社ラベルの EAN、入荷した箱にはメーカーの UPC。Shopify に登録したのは片方だけなので、もう片方をスキャンしても商品が見つからず、目視で探す時間が発生している。 打ち手 スマホの Shopify アプリでバリエーション詳細を開き、 現場でその場で両方のコードをスキャンして追加 。入荷ロットでメーカー側コードが変わる商品も、都度その場で足していける（最大 20 本）。 効果 どちらのコードをスキャンしても同じ商品にヒットする。棚卸し・検品・店頭問い合わせでの探索時間と誤認をまとめて削減。 技術メモ 検索は 1 本目に限らずバリエーションが持つ 任意のバーコード が対象。ただしラベル印刷に載るのは 1 本目なので、 棚札用のコードを 1 本目に固定 する運用ルールを最初に決めておく。 USE CASE 3 マルチチャネル出品の識別子を整備し、フィード事故を入力時点で止める 課題 マーケットプレイスやショッピングフィードごとに求められる識別子（GTIN / UPC / EAN / ASIN）が違うのに、Shopify 側は 1 本しか持てず、残りはアプリ設定や外部表に散っていた。桁の打ち間違いは、フィード連携がエラーを返して初めて発覚していた。 打ち手 チャネルごとに必要な識別子をバリエーションに全部登録し、それぞれ正しい種類を指定。 チャネルへ出す代表コードを 1 本目に固定 。整備は一括編集ツールで対象バリエーションをまとめて処理する。 効果 フォーマット検証により打ち間違いが 入力時点で 弾かれ、フィード拒否・出品エラーの手戻りが減る。チャネル追加時も「どのコードだったか」を探す作業が消える。 技術メモ 販売チャネルが読むのは 1 本目のみ という仕様が前提。チャネル別に別々のコードを出し分けられるかどうかは記事に 記載なし のため、複数チャネルで異なる識別子を要求される場合は事前検証が必須。API での扱いも 記載なし 。 10 提案で使える1行サマリ 「1 バリエーション ＝ 1 バーコードの制約が外れ、 最大 20 本を種類付き・書式検証つきで登録でき、そのどれでも商品が引ける ようになった。 既存データは移行不要、チャネルが読むのは従来通り 1 本目 なので今の連携は無改修のまま。 まずやるべきは、外部スプレッドシートに逃していた識別子を CSV で商品マスタへ戻すこと。」 source ： changelog.shopify.com / multiple-barcodes-in-variants published 2026-09-08