Lazadaの色とサイズをSKUで照合する

※掲載画像はAI生成イメージです。

「青のMサイズ」を選んだ注文なのに、作業表では「黒のMサイズ」になっていた。Lazadaで選択肢を追加するときは、表示名と在庫数だけでなく、選択肢・SKU・実物の対応を確認する必要があります。

在庫の合計が合っていても、色やサイズの割り当てが入れ替わっている場合があります。追加・編集の前後に、一つの組み合わせを一行として照合しましょう。

商品と選択肢を整理する

商品名は一つでも、色とサイズが違えば、購入者が選ぶ実物は変わります。管理表では「ポーチ」という商品群と、「青・M」という販売単位を分けると、どの数量を更新するかが明確になります。

販売者側SKUは、発送する組み合わせを識別するために使います。一方、棚番は保管する場所です。同じSKUを別の棚へ移しただけなら、商品自体を別物にする必要はありません。商品名、選択肢、SKU、棚番を一つの欄に詰めると、表示名を変えただけで在庫との結び付きが切れることがあります。

Lazadaの公式資料には、色などの販売属性はカテゴリごとに異なることが示されています。自社の管理表が色・サイズの二軸でも、対象カテゴリで同じ入力形式を使えるかは別途確認します。画面の都合に合わせて無関係なカテゴリへ移すのではなく、商品に適切なカテゴリと許可される属性で組み立てます。

複数店舗では、同じSKU文字列だけで店舗を横断して照合しないようにします。「マーケット・ショップ・商品・販売単位」の組み合わせを残せば、どの店舗の変更かを追いやすくなります。

選択肢の名前を識別番号にしない

「Blue」「青」「ブルー」は、表記が違っても同じ色を指す場合があります。一方で、同じ「Blue」でも別の商品に使われます。色名だけを頼りに注文と在庫を結び付けると、商品を取り違えるおそれがあります。

Lazada Open Platformの公式資料では、販売属性の例として色やサイズが示され、SKUとの対応が説明されています。また、販売者側のSellerSkuと、Lazada側で作成されるSkuIdは別の識別情報です。

以下は編集部の管理方法です。商品・市場・ショップを明示し、販売者側のSKUと画面で確認できる商品・SKUの識別情報を対応表に残します。入力できる属性や選択肢は、実際のカテゴリとマーケットで確認します。

色とサイズを一行にする

次は架空のポーチの例です。数量は社内で確認した販売可能数という仮定で、Lazadaの画面値や自動計算式ではありません。

合計は9個ですが、この合計だけでは、黒Mの3個と青Mの4個が入れ替わった誤りを見つけられません。各行を、現物の管理番号・棚番・選択時の画像と照らし合わせます。

青Lの0個は、欠品を表す仮の社内記録です。0個の選択肢が購入者にどう表示されるかは、対象画面で確認します。すべての市場で同じ表示になるとは扱いません。

色追加時の取り違え

架空の店舗で、黒Mと黒Lを販売しており、新しく青Mと青Lを追加する場面を考えます。作業者が黒Mの行を複製して、表示名だけを「青M」に変えたとします。

見た目は青Mが増えていても、実物の参照先や画像、価格が黒Mのままなら、登録作業は終わっていません。数量だけを4個に直すと、黒の実物を青として引き当てる可能性が残ります。

最初に、追加する青Mの現物、販売者側SKU、画像を決めます。次に対象ショップと商品の管理情報を記録し、追加後に作成された識別情報との対応を確認します。最後に青Mを選んだ購入者表示と、管理側の青Mの情報を照合します。

青Lの現物がない場合は、「あとで入る予定」を現在の販売可能数へ混ぜません。取り扱わない組み合わせと、一時的な欠品は、社内表で区別します。対象画面での有効・無効や欠品の表示方法は、その商品の現在の仕様で確認します。

この流れなら、追加した二行だけでなく、元からある黒Mと黒Lを壊していないかも確認できます。新しい選択肢が見えることと、既存選択肢を保ったまま正しく追加できたことを、別々に評価できます。

対応表に必要な列を決める

色とサイズだけの表に、価格や在庫を後付けするより、最初から販売単位を一行として管理します。次は社内表の項目例です。Lazadaの入力画面を再現したものではありません。

空欄がある場合は、その欄が不要なのか、未確認なのかを分けます。とくに識別情報が未確認の行は、一括更新の対象に入れる前に解消します。

表の行番号や画面での並び順は、固定の識別情報として使いません。行を並べ替えても同じSKUを追えるようにするためです。手作業で照合する場合も、先頭の数行だけでなく、今回変更する全組み合わせを対象にします。

追加前に対応表を残す

作業前の選択肢とSKU、価格、数量、画像の対応を保存します。色名だけを変えるのか、新しいサイズを加えるのか、作業範囲も決めます。

過去注文や連携ツールが参照している番号を把握できないまま、既存のSKUを削除して作り直すことは避けましょう。対応が不明な場合は変更を保留し、履歴と連携先を確認します。

複数ショップを扱う場合は、同じ社内商品でもマーケットとショップを区別します。一店舗での照合結果を、他店舗の反映確認に流用しません。

変更後は全対象を確認

一度に色名、価格、画像、数量をすべて変えると、何が原因でずれたのかを追いにくくなります。作業前に「今回は青を追加」「今回は画像のみ訂正」のように、変更する項目と対象行を決めます。

最初の一組で、入力先と表示の関係を確かめます。そこで問題がなければ残りを進めますが、最初の一組が正しかったことを、全行の照合の代わりにはしません。

作業中は、手動編集と在庫連携が同じ商品を同時に書き換えないかも確認します。連携を一時的に止める必要がある場合は、受注の取り込みや他商品の更新まで止まらないか、担当者と範囲を決めます。再開時には現在の注文と在庫を取り直し、停止前の古い数量をそのまま送らないようにします。

社内の完了報告には「対象ショップ／対象商品／追加・変更した組み合わせ／変更項目／管理側の照合結果／購入者表示の確認／残る不明点」を記入します。保存ボタンを押したという作業記録と、内容が正しいという確認記録を区別できます。

連携ツールを使う場合は、どの識別情報をキーに送信するかも確認します。自社SKUを変えた後に古い対応表が使われると、画面を修正しても次の同期で誤りが戻る可能性があります。

購入時の選択肢を確認

保存後は、購入者側の各選択肢を確認します。選んだ色・サイズに対して、画像、商品説明、表示価格、販売状態が適切かを見ます。

さらに対象商品の登録情報や取得できる出力データで、対応するSKUが意図どおりかを照合します。公開画面にSKUが表示されない場合は、公開画面だけでSKUまで確認できたとは記録しません。注文の確認をするときは、既存注文の明細など、実際に取得できる情報の範囲で確認します。

テストのために実注文を発生させる必要はありません。取り違えが判明した場合は、対象選択肢の販売停止を含む対応を判断し、既存注文と連携先への影響を確認します。

異常の原因を切り分ける

原因を一つに決めて全商品を直す前に、異常が出る一組を特定します。たとえば画像だけが誤っているのか、SKUと実物の対応も逆なのかで、修正の範囲は変わります。

既存注文に影響がある場合は、購入時の選択肢と注文に記録された商品情報を確認します。現在の商品名を変更したからといって、過去注文が何を示していたかまで自動で分かるわけではありません。

対応を戻すときも、作業前の数量を丸ごと再入力しないようにします。作業後に新しい注文や返品があれば、数量は変わっています。表示や対応関係の訂正と、現在庫の更新を分けて扱いましょう。

選択肢追加の運用負担

色2種類×サイズ2種類なら4通りですが、色3種類×サイズ4種類なら組み合わせは12通りです。全部を実際に販売するかどうかとは別に、確認する組み合わせが増えることを把握します。

架空の見積もりで、一組の初回照合を2分と置くと、4組なら8分、12組なら24分です。さらに共通の作業準備や撮影、登録後の確認時間がかかります。これはLazadaの処理時間ではなく、自社で担当と工数を考えるための例です。

組み合わせを増やせば必ず売れるわけではありません。実際の需要、仕入れ単位、欠品対応、画像の準備状況を見て、管理できる選択肢から始めます。色を増やす前に、既存選択肢でどの組み合わせが売れ、どこで問い合わせが発生しているかを確認すると、追加の優先順位を決めやすくなります。

修正後も一行ずつ照合する

• 対象マーケット・ショップ・商品を特定できる。
• 色とサイズの組み合わせを重複なく記録した。
• 各行のSKUと現物・画像が対応している。
• 価格・数量・販売状態を対象画面で確認した。
• 連携先や既存注文への影響を確認した。

記録欄は「対象商品／選択肢／販売者側SKU／Lazada側識別情報／変更前後／実表示／確認者・日時」から始められます。合計数量と、各組み合わせの正しさを両方確認しましょう。

よくある疑問

「欠品の選択肢は消してよいですか」。販売表示の調整と、履歴や連携情報の削除は別に考えます。一時欠品なら、再入荷時に同じ販売単位として扱うかを決め、対象画面で利用できる表示・販売状態の変更を確認します。削除して作り直すことを既定の方法にしません。

「同じ写真を複数サイズで使えますか」。外観が同じでも、写真から寸法を読み違えないかを確認します。サイズ比較の画像が必要なら、測定方法と寸法の定義をそろえます。色や柄が違う場合は、実物と異なる画像にならないようにします。

「SKUの末尾をMからLへ変えれば十分ですか」。文字列の見た目だけでは判断できません。現物、登録された識別情報、既存注文、連携先の対応を確認します。社内表だけ直しても、公開ページや同期設定が同じように更新されるとは限りません。

「注文テストは必要ですか」。まず実注文を作らず確認できる管理情報と購入者表示を照合します。そこで不明な部分は不明として残し、追加の確認方法を担当者やサポートへ相談します。未確認の機能を確認済みと記録しないことが大切です。

参考資料

情報確認日・公式情報確認日：2026-11-01。

Lazada Open Platform 販売属性とSKUの説明、SellerSkuとSkuIdの説明を参照。確認範囲は取得できた公式資料の項目説明です。対応表、架空例、点検手順は編集部の運用例です。

関連記事と相談の準備

関連記事：商品表の並べ替えで行ずれを防ぐも確認できます。

確認項目の整理には物販・EC運用チェックリストを利用できます。判断が止まる箇所は、顧客情報や認証情報を除いた整理メモを用意し、物販AI Labの相談窓口へお知らせください。

コメントを残す コメントをキャンセル

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

コメント ※

名前 ※

メール ※

サイト

次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。

上に表示された文字を入力してください。