Coupangの商品ID：1つのIDではすべてのバリエーションを管理できません

いいえ。ERP（enterprise resource planning）では、サイズや色ごとに異なる商品すべてに、1つのCoupang商品IDを恒久的なキーとして使うべきではありません。ブランドのSKU（stock-keeping unit）をERPの主キーにしてください。Coupangの5つのフィールド—sellerProductId、productId、vendorItemId、sellerProductItemId、externalVendorSku—を、出品行または対応するバリエーション行に保存します。

ブランドSKUを起点にする

ブランドSKUをERPの主コードにしてください。チームが商品の仕入れ、在庫数の確認、補充、報告にすでに使っているコードです。

CoupangのIDは、Coupang内の商品を示すものです。ブランドが自社のシステム全体で使うコードに取って代わるものではありません。コネクタは2つのシステムをつなぐものであり、変わり得るCoupangの商品グループIDだけに頼るべきではありません。

たとえば、ドリンクウェアブランドが、500 mlのマグカップを黒と白の2色で販売しているとします。黒は MUG-500-BLK、白は MUG-500-WHT です。

ブランドには在庫商品が2つあります。購入者には1つのCoupang出品の中に表示される場合でも、黒と白は在庫数を別々に数え、注文もそれぞれに照合する必要があります。

コネクタが出品に対して productId を1つしか保存しなければ、どのCoupangオプションが MUG-500-BLK に対応し、どれが MUG-500-WHT に対応するのか分かりません。在庫更新が誤った在庫単位に届く可能性があり、注文行が返ってきても、ブランドSKUと確実に照合できないことがあります。

より安全なモデルは、販売可能なバリエーションごとにERPの行を1つ用意することです。その行にオプション単位のCoupang値を保存し、出品単位の値は別に保存します。Coupangが表示上の商品グループを変更しても、コネクタはプラットフォーム側のフィールドだけを更新し、ブランド内部のSKUは変えずに済みます。

externalVendorSku には、CoupangのAPIがこのフィールドを受け付ける場合、ブランドSKUを入れられます。発注照会で、Coupangから出品者独自のコードを返してもらうのに役立ちます。それでも、コネクタからCoupangのIDを捨ててはいけません。ブランドコードとCoupangの値は、別の問題を解決します。

最初に確認すべき選定ポイントは、コネクタが各ブランドSKUをCoupangの正しい販売可能オプションに対応付けられるかどうかです。その対応関係を示せなければ、商品、在庫、注文の更新を安全に同じSKUへ結び付け続けることはできません。

Coupangの5つのフィールドの意味

これらのフィールド定義は、Coupang公式Open API開発者ドキュメントに基づいています。実際に使うAPI呼び出しごとに、そのリクエストとレスポンスを確認してください。出品を識別するフィールドが、そのままオプションの編集や注文照合に必要なフィールドになるとは限りません。

よくある間違いは2つです。1つ目は、Coupangが変更する可能性があるにもかかわらず、コネクタが productId を恒久的な値として扱うことです。2つ目は、vendorItemId と sellerProductItemId を同じフィールドの別名として扱うことです。

この2つは同じではありません。vendorItemId は最小単位の販売可能オプションを識別します。sellerProductItemId は商品照会から返され、オプションの値を変更するときに必要です。オプションを編集するコネクタは、両方の値を別々のフィールドに保存してください。

出品作成とIDマッピングも別の話です。Coupang Open APIでは商品カタログをアップロードできます。ただし、出品とそのオプションが存在するようになった後に返される値を、コネクタは保存する必要があります。「商品を作成できる」ことは、その後も商品を維持管理できる証明にはなりません。

productIdを恒久的なキーにしてはいけない理由

productId は便利ですが、長く使う唯一の参照先にはできません。Coupangによれば、商品が統合または分離されると、この値は変わる可能性があります。

統合によって、商品が1つの表示上の商品グループにまとめられることがあります。分離によって、1つの商品グループが複数の商品に分かれることもあります。いずれの場合も、古い productId だけを保存したERPは、現在のCoupang商品グループのどれが自社の出品に対応するのか分からなくなる可能性があります。

解決策は productId を無視することではありません。現在のCoupang値として保持し、プラットフォームが新しい値を返したら更新してください。次のリンクも保存してください。

• sellerProductId は登録商品全体のリンクに使います。
• vendorItemId は最小単位の販売可能な各オプションに使います。
• sellerProductItemId はオプションの値を編集するときに使います。
• externalVendorSku は出品者側の照会でブランド独自コードを照合するために使います。

ブランドSKUはERPの主キーのままです。Coupangの値は、そのSKUが現在マーケットプレイス上のどこにあるかをコネクタに伝えます。

vendorItemId は実務上のオプション単位のキーですが、それだけでは不十分です。出品全体の sellerProductId、オプション編集用の sellerProductItemId、出品者自身のコードを照合するための externalVendorSku の代わりにはなりません。APIではそれぞれに異なる役割があるため、コネクタにはこれらの値を関連付けて保存する必要があります。

実例：2つのマグカップバリエーションをERPで追跡する

ここでは、先ほどの2つのマグカップオプションを追ってみます。実際にCoupangから返される値は、プラットフォームの識別子です。以下では、コネクタが各フィールドを何として保存し、どう使うべきかを示します。

1. 出品行を作成します。 コネクタは登録商品に対する sellerProductId を1つ保存します。また、表示上の商品グループである現在の productId も保存します。これらは出品単位を示す値で、2つの色の在庫を別々に示す値ではありません。

2. 販売可能なバリエーションごとにオプション行を1つ作成します。 黒の行には MUG-500-BLK をブランドSKUとして保存し、そのバリエーション固有の vendorItemId も保存します。白の行には MUG-500-WHT と、別の vendorItemId を保存します。色が1つの出品に入っている場合、両方の行が同じ sellerProductId を参照します。

3. 編集用の参照値を保存します。 作成後の商品照会では、各オプションについて sellerProductItemId が返されます。コネクタはこの値を対応するオプション行に保存します。Coupangが後からオプション変更を受け付ける場合、その編集には sellerProductItemId を使います。推測した vendorItemId を代わりに使わないでください。

4. 正しいオプションの在庫を更新します。 ERPで黒いマグの在庫を減らす場合、コネクタは MUG-500-BLK を見つけ、保存してある vendorItemId をたどって黒のオプションを更新します。出品単位の productId だけを送り、Coupang側に変更対象の色を推測させてはいけません。

5. 注文行を照合します。 発注照会で externalVendorSku が返れば、コネクタは MUG-500-BLK をブランドの黒いマグのSKU行に照合できます。ERPは共有出品の合計からではなく、正しいSKUの在庫を差し引けます。

6. 商品グループの変更に対応します。 Coupangが商品を統合・分離して別の productId を返した場合、コネクタは現在の商品グループIDを更新します。ブランドSKUを維持し、Coupangが変更しないとしている sellerProductId と vendorItemId のリンクも保持します。

IDの照合だけでは、注文処理全体を解決できません。Coupangの注文行には、実物商品が複数個含まれることがあります。コネクタは、注文行を正しいSKUと数量にマッピングする必要があります。ID設計が先ですが、IDが見つかった後も数量のマッピングは重要です。詳しくは、Coupangの注文行は常に1個とは限りませんを参照してください。

コネクタ導入時の確認ポイント

「CoupangのIDに対応しています」だけを完全な回答として受け入れないでください。コネクタのベンダーに、保存するフィールドと各操作で使う値を示してもらってください。

1. 5つの値をすべて保存しますか？ 一般的な「Coupang商品ID」フィールドだけでなく、sellerProductId、productId、vendorItemId、sellerProductItemId、externalVendorSku が確認できるはずです。

2. 販売可能なSKUごとにオプションリンクを1つ保持しますか？ 2色または2サイズの出品を見せてもらってください。各バリエーションに固有の vendorItemId とブランドSKUがあるはずです。

3. 統合または分離の後はどうなりますか？ ブランドSKUと、変更されないオプションリンクを保持しながら、現在の productId をどう更新するのか説明できる必要があります。「productId を主キーにしています」は警戒すべき回答です。

4. 作成後にオプションの値を編集できますか？ できる場合は、sellerProductItemId をどこに保存し、どの照会で取得するのかを確認してください。vendorItemId だけに言及するベンダーは、オプション編集について答えていません。

5. 発注行をどのように照合しますか？ 発注照会で externalVendorSku が返る場合にそれを読み取り、その値をERPのブランドSKUにマッピングするか確認してください。

6. 各更新で使ったIDを確認できますか？ 商品作成、在庫更新、オプション編集、注文照合では、異なるフィールドが必要になる場合があります。コネクタは、各操作でどのフィールドを使うのかをチームに示せる必要があります。

IDを保存しても、適切なAPI呼び出しを選ぶ必要はなくなりません。各操作でコネクタがどのCoupangフィールドを送るのかを確認してください。出品を作成できるかだけを確認してはいけません。価格と在庫ではCoupang APIの呼び出しが分かれているため、Coupangでは価格と在庫のAPI呼び出しが分かれていますも参照してください。

productId だけを保存するコネクタでは、商品と注文を確実に更新できません。vendorItemId だけでバリエーション在庫には対応できる可能性がありますが、それだけでは出品、オプション編集、出品者コードの照合をカバーできません。

Coupangの商品IDに関するよくある質問

sellerProductId をすべてのバリエーションに使えますか？

いいえ。sellerProductId は登録商品を識別し、関連するオプションをまとめます。サイズ、色、その他の最小の販売可能オプションごとに、別の vendorItemId を保存してください。

productId は役に立ちませんか？

いいえ。現在表示されている商品グループとして保持し、特定のAPI呼び出しで必要なら渡してください。Coupangは統合・分離の際に変更する可能性があるため、恒久的なERPキーにはしないでください。

vendorItemId だけでコネクタを構成できますか？

いいえ。実務上のオプション単位の値ではありますが、完全なマッピングには、出品単位の sellerProductId、編集単位の sellerProductItemId、そしてブランドSKUまたは externalVendorSku も必要です。

externalVendorSku でCoupangのIDを置き換えられますか？

いいえ。出品者独自の商品コードであり、発注照会の結果をERPと照合するのに役立ちます。CoupangのIDは、出品者のSKUをCoupangの出品オブジェクトやオプションオブジェクトに結び付けるために引き続き必要です。

Coupangが商品を統合または分離した場合、どうすればよいですか？

コネクタは現在の productId を更新し、ブランドSKU、sellerProductId、vendorItemId のリンクを保持してください。Coupang上の表示グループは変わっても、ERPのSKUは変えないでください。

5つの値をすべて保存すれば、同期は保証されますか？

いいえ。5つの値によって、コネクタに必要なリンクが揃います。それでも、正しいAPI呼び出しを送り、各レスポンスを正しいSKUと数量に照合する必要があります。各操作で必要なフィールドを確認するため、Coupang公式の開発者ドキュメントを使ってください。