Lazadaの色とサイズを取り違えない方法

Lazadaで色やサイズを追加したら、

購入者の選択肢とSKU、

実物が同じ組み合わせに

なっているか確認しましょう。

合計在庫が合うだけでは、

取り違えは防げません。

商品と選択肢を整理する

商品名は一つでも、

色とサイズが違えば、

購入者が選ぶ実物は変わります。

管理表では「ポーチ」

という商品群と、

「青・M」という販売単位を

分けると、どの数量を更新するかが

明確になります。

販売者側SKUは、

発送する組み合わせを識別するために

使います。

一方、棚番は保管する場所です。

同じSKUを別の棚へ移しただけなら、

商品自体を

別物にする必要はありません。

商品名、選択肢、SKU、

棚番を一つの欄に詰めると、

表示名を変えただけで在庫との

結び付きが切れることがあります。

Lazadaの公式資料には、

色などの販売属性はカテゴリごとに

異なることが示されています。

自社の管理表が色・サイズの

二軸でも、

対象カテゴリで同じ入力形式を

使えるかは別途確認します。

画面の都合に

合わせて無関係なカテゴリへ

移すのではなく、

商品に適切なカテゴリと

許可される属性で組み立てます。

複数店舗では、

同じSKU文字列だけで店舗を横断して

照合しないようにします。

「マーケット・ショップ・

商品・販売単位」の組み合わせを

残せば、

どの店舗の変更かを

追いやすくなります。

合計だけでは分からない例

架空のポーチで考えます。

黒Mが3個、黒Lが2個、青Mが4個、

青Lが0個。

社内で確認した販売可能数という仮定で、

合計は9個です。

黒Mと青Mの割り当てが

入れ替わっても、

合計9個は変わりません。

色とサイズを一行ずつに分けて、

SKUと実物を

確認する必要があります。

表示名と識別情報を分ける

「Blue」「青」は表示名です。

同じ色名を別の商品にも使えるため、

色名だけで注文と実物を

結び付けません。

Lazada公式資料は、

販売者側のSellerSkuと、

Lazadaで作成されるSkuIdを

区別しています。

対象マーケット、ショップ、

商品と一緒に、

確認できる識別情報を残します。

色追加時の取り違え

架空の店舗で、

黒Mと黒Lを販売しており、

新しく青Mと青Lを追加する場面を

考えます。

作業者が黒Mの行を複製して、

表示名だけを「青M」に

変えたとします。

見た目は青Mが増えていても、

実物の参照先や画像、

価格が黒Mのままなら、

登録作業は終わっていません。

数量だけを4個に直すと、

黒の実物を青として

引き当てる可能性が残ります。

最初に、追加する青Mの現物、

販売者側SKU、画像を決めます。

次に対象ショップと商品の管理情報を

記録し、

追加後に作成された識別情報との

対応を確認します。

最後に青Mを選んだ購入者表示と、

管理側の青Mの情報を照合します。

青Lの現物がない場合は、

「あとで入る予定」を現在の

販売可能数へ混ぜません。

取り扱わない組み合わせと、

一時的な欠品は、

社内表で区別します。

対象画面での有効・無効や欠品の

表示方法は、

その商品の現在の仕様で確認します。

この流れなら、

追加した二行だけでなく、

元からある黒Mと黒Lを

壊していないかも確認できます。

新しい選択肢が見えることと、

既存選択肢を

保ったまま正しく追加できたことを、

別々に評価できます。

作業前後の対応を残す

変更前の選択肢、SKU、価格、数量、

画像を保存します。

履歴や連携先との関係が

分からない場合は、

既存SKUを削除して作り直す操作を

保留します。

保存後は各選択肢を選び、画像、

説明、価格、

販売状態を購入者側の画面で

確認します。

対応SKUは管理画面や

取得できる出力情報で照合します。

実注文を作って試す必要はありません。

公開画面にSKUが出ない場合、

その画面だけでSKUまで

確認済みにはできません。

対象カテゴリやマーケットによる

違いも確認してください。

変更後は全対象を確認

一度に色名、価格、画像、

数量をすべて変えると、

何が原因でずれたのかを

追いにくくなります。

作業前に「今回は青を追加」「今回は

画像のみ訂正」のように、

変更する項目と対象行を決めます。

最初の一組で、

入力先と表示の関係を確かめます。

そこで問題がなければ残りを

進めますが、

最初の一組が正しかったことを、

全行の照合の代わりにはしません。

作業中は、

手動編集と在庫連携が同じ商品を

同時に書き換えないかも確認します。

連携を一時的に

止める必要がある場合は、

受注の取り込みや他商品の更新まで

止まらないか、

担当者と範囲を決めます。

再開時には現在の注文と在庫を

取り直し、

停止前の古い数量を

そのまま送らないようにします。

社内の完了報告には

「対象ショップ／対象商品／

追加・変更した組み合わせ／

変更項目／管理側の照合結果／

購入者表示の確認／残る不明点」を

記入します。

保存ボタンを

押したという作業記録と、

内容が正しいという確認記録を

区別できます。

連携ツールを使う場合は、

どの識別情報をキーに送信するかも

確認します。

自社SKUを変えた後に古い対応表が

使われると、

画面を修正しても次の同期で誤りが

戻る可能性があります。

確認欄は五つで始める

対象ショップと商品。

色・サイズの組み合わせ。

販売者側SKUとLazada側の識別情報。

現物・画像・価格・数量との対応。

確認結果、確認者、日時。

誤りがあれば、

対象選択肢の販売停止を含めて対応を

判断し、既存注文や連携先への影響を

確認します。

異常の原因を切り分ける

見つかった異常：

青を選ぶと黒の画像になる／最初の

確認先：

選択肢と画像の割り当て／その

後の確認：実物とSKUも同じ誤りか

見つかった異常：

管理表と価格が違う／最初の確認先：

店舗・通貨・対象選択肢／その

後の確認：通常価格と販促条件の違い

見つかった異常：

追加後に数量が戻る／最初の確認先：

最終更新日時と連携元／その

後の確認：同時更新や古い対応表

見つかった異常：

一部の選択肢が見えない／最初の

確認先：現在の登録・販売状態／その

後の確認：

属性・カテゴリ・欠品等の表示条件

原因を一つに決めて全商品を

直す前に、

異常が出る一組を特定します。

たとえば画像だけが誤っているのか、

SKUと実物の対応も逆なのかで、

修正の範囲は変わります。

既存注文に影響がある場合は、

購入時の選択肢と注文に

記録された商品情報を確認します。

現在の商品名を

変更したからといって、

過去注文が何を示していたかまで

自動で分かるわけではありません。

対応を戻すときも、

作業前の数量を丸ごと

再入力しないようにします。

作業後に新しい注文や返品があれば、

数量は変わっています。

表示や対応関係の訂正と、

現在庫の更新を分けて扱いましょう。

よくある疑問

「欠品の選択肢は

消してよいですか」。

販売表示の調整と、

履歴や連携情報の削除は別に

考えます。

一時欠品なら、

再入荷時に同じ販売単位として

扱うかを決め、対象画面で

利用できる表示・販売状態の変更を

確認します。

削除して作り直すことを既定の

方法にしません。

「同じ写真を複数サイズで

使えますか」。

外観が同じでも、

写真から寸法を読み違えないかを

確認します。

サイズ比較の画像が必要なら、

測定方法と寸法の定義をそろえます。

色や柄が違う場合は、

実物と異なる画像にならないようにします。

「SKUの末尾をMからLへ

変えれば十分ですか」。

文字列の見た目だけでは

判断できません。

現物、登録された識別情報、

既存注文、

連携先の対応を確認します。

社内表だけ直しても、

公開ページや同期設定が同じように

更新されるとは限りません。

「注文テストは必要ですか」。

まず実注文を

作らず確認できる管理情報と

購入者表示を照合します。

そこで不明な部分は不明として残し、

追加の確認方法を担当者やサポートへ

相談します。

未確認の機能を確認済みと

記録しないことが大切です。

参考資料

参照資料：

Lazada Open Platformの

販売属性・SKU項目説明。

情報確認日：2026年10月30日。

架空例と照合手順は編集部の

提案です。