ShopifyバンドルSKUを3PLで「1ケース」として出荷・課金させる｜受注明細の分割・lineItemGroup・テスト注文照合台帳
ON THIS PAGE▼
Shopify Bundlesで「12本入りケース」「ギフトセット」などを販売すると、販売画面上では1商品でも、在庫・出荷の処理では構成SKUごとの情報が中心になります。ここで重要なのは、バンドルSKUを作成したことと、3PLが1ケースとしてピック・梱包・課金できることは別の要件だという点です。
Shopifyの公式ヘルプでは、バンドルは注文内で入れ子の明細として扱われる一方、分割フルフィルメント、返品、交換など構成品を個別に処理する画面では、構成品が個別明細として表示されると案内されています。また、Shopify Bundlesでは注文処理上、バンドルSKUではなく構成品のSKUが表示される制約があります。仕様の確認時点は**本記事で参照するShopify公式ドキュメントの掲載内容（公開前にリンク先の現行仕様を要再確認）**です。Shopify Bundlesの考慮事項 と Shopify Bundlesのヘルプ を前提に、物流の判断を組み立てます。
最初に分けるべき4つの単位
ケース販売の連携設計では、次の4つを同じ「SKU」として扱わないことが出発点です。
| 単位 | 例 | 主に判断すること |
|---|---|---|
| 親バンドルSKU | CASE-12 | ストアで何ケースを販売したか |
| 構成SKU | DRINK-001 × 12 | 在庫を何本引き当てるか |
| フルフィルメントオーダー | ロケーションA分、ロケーションB分 | どこから何を出荷するか |
| 3PLの作業・課金単位 | ケースピック、単品ピック、キッティング | 誰がどう作業し、何を請求するか |
たとえば、ストアでは CASE-12 × 1 と売れていても、3PLに渡る出荷指示が DRINK-001 × 12 だけなら、WMSは単品12個のピック指示として解釈する可能性があります。逆に、構成SKUが12本で届いても、親バンドル情報を参照し、かつそのセットが倉庫内でケース在庫として保管されていれば、ケースピックへ変換できる設計もあり得ます。
つまり、確認すべき問いは「Shopify Bundlesに対応していますか」だけでは足りません。以下まで具体化します。
- 親バンドルSKUと構成SKUの対応を、3PL/WMSが受け取れるか
- その対応を受け取った後、WMSの作業指示でケースとして判定できるか
- ケース在庫が物理的に存在しない場合、構成品を集める作業をキッティングとして扱うか
- 分割出荷時にも、親バンドル数量と構成品数量を追跡できるか
- ピッキング、資材、キッティング、分割出荷、返品の各料金を、どの単位で計上するか
契約書や見積書に「バンドル対応」とだけ書かれている場合は、ケースピックの可否を判断できません。「CASE-12を1ケースとして、出荷指示・作業実績・請求明細のそれぞれにどう記録するか」をサンプルデータで確認します。
Shopify側で起きる受注明細の展開と分割を理解する
Shopify Bundlesでは、構成SKUの在庫を基準に販売可能数が決まります。この性質は在庫同期には有用ですが、物流データでは親商品の見え方が変わることがあります。
Shopify公式ヘルプは、バンドルの構成品が、分割フルフィルメントや返品・交換などの個別処理画面では個別明細として表示されると説明しています。したがって、3PL連携がフルフィルメント対象の明細だけを取得する方式なら、親バンドルSKUがそのまま届くことを前提にしてはいけません。
さらに、注文後の配送グループはフルフィルメントオーダーとして表現されます。Shopifyのsplit cartsに関する開発者ガイドでは、注文、注文の明細、配送、フルフィルメントオーダー、フルフィルメント明細を合わせて取得・照合する実装が案内されています。About split carts in checkout の仕様を踏まえると、同じ購入者注文でも、出荷元や配送グループに応じて出荷指示が複数に分かれる前提でテストすべきです。
特に、次の状態は別々に確認します。
- 構成SKUの全量が同じロケーションにある
- 構成SKUの一部が別ロケーションにある
- ケース商品と単品商品が同じカートに入る
- バンドル数量が複数になる
- 構成品の一部が欠品し、出荷保留または分割出荷になる
「通常注文で1ケースと表示された」だけでは、ロケーション変更や欠品時の出荷・請求まで確認したことにはなりません。
lineItemGroupで親バンドルを再構成できるかを確認する
ShopifyのGraphQL Admin APIには、バンドル購入時の構成品LineItemから親バンドルを参照するlineItemGroupがあります。公式のLineItemGroupリファレンス では、親のタイトル、商品ID、バリエーションID、SKU、親バンドル数量を取得できると示されています。
これは、構成SKUの明細しか受け取れない連携でも、連携アプリまたは中間処理が親子関係を再構成できる可能性を意味します。ただし、lineItemGroupが存在することは、利用中の3PLコネクタやWMSが自動で利用することを意味しません。確認対象はAPIの可否ではなく、自社の実際のデータ経路で、その項目を取り出して運用できるかです。
3PLまたは連携ベンダーには、以下をそのまま質問すると認識差を減らせます。
- 注文取得はREST API、GraphQL API、CSV、受注管理システムのどれですか。
- 構成品明細に紐づく
lineItemGroupまたは親バンドルSKUを取得・保存できますか。 - 親SKU、親数量、構成SKU、構成数量を、出荷指示と作業実績の両方で保持できますか。
- 同一の親バンドルに属する構成品を、出荷時に1ケースとしてグルーピングできますか。
- フルフィルメントオーダーが複数に分かれた場合、親バンドルとの対応をどの画面・帳票で確認できますか。
- APIバージョン変更時やコネクタ更新時に、どの項目が保証対象ですか。
LineItemGroupの参照先はunstable版のGraphQL Admin APIリファレンスです。導入判断では、利用するAPIバージョン、連携アプリの対応バージョン、項目の保存有無をベンダーに確認してください。仕様名だけで実装済みと判断しないことが重要です。
「1ケース」として出荷・課金する3つの運用パターン
ケース販売を扱う方法は一つではありません。物理在庫とWMS機能に合わせ、作業実態に合うパターンを選びます。
パターン1：完成済みケースをケースSKUで保管・出荷する
倉庫にCASE-12という完成済みケース在庫を保管し、WMSでも1ケースとして在庫・ピックする方法です。ケースピックの定義が明確で、梱包のばらつきを抑えやすい一方、Shopify Bundlesの構成SKU在庫と倉庫側のケース在庫をどう同期・補充するかが別途必要になります。
構成SKU在庫をShopify Bundlesで直接引き当てる運用とは、在庫の持ち方が一致しない場合があります。ケースを開梱して単品出荷する商品なら、ケース在庫と単品在庫の変換ルール、棚卸し、破損時の調整責任を先に決めます。
パターン2：構成品をまとめてピックし、WMSでケース作業に変換する
構成品は単品在庫として保管し、親子情報を使ってWMSが「この12本はCASE-12の1セット」と判定する方法です。ケース完成品を前もって持たない点は利点ですが、実態は12本の集品・検品・梱包を伴う可能性があります。
この場合、「1ケース課金」と呼んでいても、料金表上はケースピックではなく、単品ピック＋セット組みまたはキッティングになることがあります。作業名称ではなく、請求明細の計算式を確認します。
パターン3：親子情報を渡せないため、構成SKUの単品出荷として扱う
既存コネクタが構成SKUしか渡せず、改修の優先度も低い場合の選択肢です。実装変更を避けられる反面、販売上の「1ケース」と物流上の「単品12ピック」が異なることを、原価計算と顧客向け梱包基準で受け入れる必要があります。
このパターンを選ぶなら、ケース商品だけが単品商品の12倍のピック数として計上されるのか、注文単位の上限料金があるのか、資材費や同梱物の扱いがどうなるのかを見積もりで明文化します。安価に見える連携でも、販売数量が増えた時点で作業費が変わる可能性があります。
3PLとの仕様確認シート：課金表と例外を同じ表で見る
3PLへの質問を技術項目と料金項目に分けると、片方だけ確認して判断を誤りやすくなります。以下のシートを、連携担当と物流担当が共同で埋めます。
| 確認項目 | 確認する内容 | 判定・記録欄 |
|---|---|---|
| 親子識別 | 親SKU、構成SKU、親数量、構成数量の受信可否 | 受信項目名、保存先 |
| グルーピング | 同じ親バンドルの構成品を同一作業単位にできるか | 条件、不可時の処理 |
| 在庫引当 | 構成品が別ロケーションの場合の出荷指示 | 分割・保留・移動のルール |
| ピッキング | ケース、単品、セット組みのどれとして指示されるか | WMS画面または帳票 |
| 梱包 | 外箱、緩衝材、同梱物、ラベルの指定方法 | SKU別マスタの有無 |
| 課金 | ピック、キッティング、梱包、分割出荷、保管の料金単位 | 見積書の行番号・適用条件 |
| 返品 | 未開封ケース、構成品欠品、破損時の受入単位 | 在庫戻し・廃棄のルール |
| 障害時 | 親子情報が欠落した注文の保留・手作業手順 | 連絡先、締切時刻 |
料金は、単価だけでなく適用条件を確認します。たとえば「ケースピック料金」が完成済みケースにだけ適用されるのか、構成品を集めて梱包したケースにも適用されるのかで結果が異なります。3PLの料金・契約条件は個別見積もりに依存するため、本記事では金額の一般化はしません。見積取得日、料金表の版、対象SKU、想定出荷パターンを台帳に残してください。
公開前に行うテスト注文照合台帳
テストは、Shopify管理画面で注文を見て終わりにせず、3PLの受信データ、WMS作業指示、出荷実績、請求予定データまで同じ注文番号でつなげます。少なくとも次の列を持つ台帳を作成します。
| 列 | 記載例 |
|---|---|
| テストID | BND-01 |
| Shopify注文番号 | 実テスト注文番号 |
| 購入内容 | CASE-12 × 1 |
| 期待する構成 | DRINK-001 × 12 |
| 在庫ロケーション | Aのみ／A・B混在 |
| 期待する出荷形態 | 1ケース／分割出荷／保留 |
| 3PL受信明細 | 親SKU・構成SKU・数量の実測値 |
| WMS作業単位 | ケースピック／単品ピック／キッティング |
| 出荷実績 | 追跡番号、梱包数、出荷拠点 |
| 請求予定 | 請求項目、数量、適用条件 |
| 判定 | 一致／要修正 |
| 修正担当・再試験日 | 担当者、日付 |
推奨する最小テストは、次の6件です。
- バンドル1個、構成品が同一ロケーションにそろう注文
- バンドル2個の注文
- バンドルと単品SKUを混在させた注文
- 構成品を別ロケーションに置いた注文
- 構成品の一部を欠品させた注文
- 出荷後に返品を想定し、ケース完品・構成品不足・破損の扱いを確認する注文
ロケーション、在庫配置、3PLコネクタ、WMSマスタのいずれかを変更したときも、同じ台帳で再試験します。変更前に通っていたケースピックが、設定変更後も維持されるとは限りません。
導入可否は「親SKUが見えるか」ではなく請求まで一致するかで決める
判断の基準は、親バンドルSKUを画面で表示できることではありません。テスト注文について、販売数量、構成品数量、出荷拠点、梱包数、作業単位、請求予定が、合意したルールどおりにつながることです。
親子情報を取得できても、WMSがケース作業へ変換できなければ、物流上は単品ピックのままです。また、ケースへ変換できても、構成品が別ロケーションにあると分割出荷が発生し、1ケースとして完結しないことがあります。これらは機能の優劣ではなく、在庫配置、物理保管、連携方式、契約上の作業定義の組み合わせで決まります。
移行・改修を検討する際は、連携アプリの変更だけでなく、WMSマスタ整備、ケース在庫の保管方法、料金表の再協議、既存注文への影響、返品フローの教育まで含めて比較します。まずは照合台帳で現状の差異を可視化し、その差異を「許容する」「WMS設定で直す」「連携を改修する」のどれで解消するかを決めると、過剰な移行を避けやすくなります。
参考情報
この課題、もっと詳しく相談したい方へ
記事では答えきれない個別の状況にもお応えします。