Coupangの注文行：1行が1個とは限らない

いいえ、Coupangの注文行を1個として安全に扱うことはできません。Coupangの注文行は、倉庫が実物を1個減らすべきことを示すものではなく、顧客向けの販売オプションです。自動生成された数量オプションは、基準単位を複数個表すことがあります。ERPが在庫を減算したりフルフィルメント処理を登録したりする前に、オプションの種類と元の商品との関係を特定し、構造化された注文データから処理数量を算出する必要があります。

Coupangでは、なぜ「1行＝1個」の前提が崩れるのか

多くの欧米のERPマッピングは、次のような単純な連鎖を前提にしています。1つのカタログ商品が1つのSKUになり、1つの注文行が1個になり、そこから1回の在庫減算が行われる、という連鎖です。この連鎖が安全なのは、顧客向けのオプションと倉庫で扱う単位が同じ場合だけです。

Coupangの公式告知では、自動生成オプションは対象カテゴリ向けの、需要に応じた購入数量オプションと説明されています。したがって、出店者が新しい実物商品を作成していなくても、出品した商品に顧客向けの数量またはバンドルのオプションが付くことがあります。この機能はすべての商品に適用されるわけではないため、コネクターは全体に1つのルールを適用せず、商品ごとに状態を検出する必要があります。

分けて管理すべき識別子は3つあります。

• 元の商品またはアイテム： 商品カタログとの関係の起点となる、出店者が作成したプラットフォーム上の出品です。
• 生成オプション： Coupangが作成する、顧客向けの数量またはバンドルの選択肢です。
• 基準となる実物単位： 倉庫、3PL、またはフルフィルメント業務が実際にピッキング、出荷、計数する単位です。

生成オプションは販売上は別の選択肢でも、倉庫用の新しいSKUとは限りません。オプションが複数の基準単位を含む場合、その注文行を1個として扱うと在庫を過少に減算してしまい、不完全なフルフィルメント指示を送ることになります。一方、すべてのオプションをまったく新しいSKUとして扱うと、カタログレコードの重複、分断された販売履歴、不要な在庫識別子が生まれます。

実務上のテストは簡単です。商品タイトルを読まなくても、1つの顧客向けオプションが具体的な実物数量にどう変換されるかを、コネクターが説明できるか確認してください。説明できないなら、この注文フローの該当部分を自動化する準備はできていません。

マッピングの基準にすべきCoupangのフィールドはどれか

構造化されたProduct APIと注文シートのレスポンスデータを、マッピングの基準にしてください。Product APIと注文レスポンスのスキーマは、Coupang公式のOpen API開発者ドキュメントで確認してください。Coupang公式の自動生成オプションに関する告知も参照してください。

エンドポイントの文脈が重要です。出店者商品レスポンスは GET /v2/providers/seller_api/apis/api/v1/marketplace/seller-products/{sellerProductId} から返され、注文シートレスポンスは GET /v2/providers/openapi/apis/api/v4/vendors/{vendorId}/ordersheets から返されます。実装する前に、現在のパスとバージョンをCoupangのドキュメントで確認してください。

表中の役割名は概念上のものです。コード表記の値は、実装担当者が確認すべきレスポンスパスです。Coupangでは、生成オプションのマーカーがエンドポイントやAPIバージョンによって別のキーで提供される場合があります。そのため、generated_option_state のような正規化フィールドとともに、元のキーと値も保持してください。マーカーがない場合に、オプション名へ黙って置き換えてはいけません。

現在のスキーマで、生成オプションを示すフラグに別のリテラル名が使われている場合は、その名前をコネクターのバージョン管理されたマッピング設定に記録してください。重要なのは、正規化フィールドを generated_option_state と呼ぶかどうかではありません。元のレスポンスキー、値、エンドポイント、APIバージョンが監査可能な状態で残っているかどうかです。

重要なのは、オプション数量と処理数量を区別することです。レスポンスが1オプションあたりの基準単位数 B と注文数量 Q を示している場合、別途定義された倉庫ルールがない限り、基準単位の在庫移動は B × Q です。たとえば B = 3、Q = 2 なら、基準単位6個分の在庫移動（3 × 2）が発生します。一方、顧客向けオプションの数量は2のままです。

計算には、表示名を解析するのではなく、Coupangが返す構造化された値を使ってください。正規化されたERPの結果だけでなく、プラットフォームの生の識別子とレスポンス値も保存してください。そうすれば、生成オプションが追加、変更、無効化されたときに、後から検証できます。また、在庫移動を計上した理由を説明する証跡を、データ修正によって失うことも防げます。

この区別は、APIでカタログを作成する場合にも重要です。Coupang Open APIで商品カタログをアップロードできますか？ では、カタログデータをアップロードできても、マッピングと検証が不要になるわけではない理由を説明しています。レコードを取り込むことと、それが倉庫で何を意味するかを決めることは同じではありません。

架空の倉庫SKUではなく、関係を構築する

信頼できるデータモデルでは、生成オプションを元のアイテムに紐づく関係として扱います。プラットフォーム上のオプションをすべて、自動的に新しい内部SKUへ昇格させることはしません。

少なくとも、次のレコードまたはフィールドは分けて保持してください。

このモデルでは1対多の関係を扱えます。1つの基準SKUに、通常のプラットフォームアイテムと、1つ以上の顧客向け生成オプションを紐づけられます。オプションは売上レポート上では固有の価格や割引を持ちながら、実物の移動は基準SKUに戻せます。

重要な例外が1つあります。ブランドが実際にその数量オプションを、別個の梱包済み商品として製造・ラベル付け・保管し、ピッキングしている場合は、専用の倉庫SKUを割り当てることもできます。これは在庫ポリシーの判断です。Open APIはプラットフォーム上の関係を公開しますが、バンドルがあらかじめ梱包された在庫なのか、ピッキング指示なのか、仮想的な販売オファーなのかは決めません。

Coupangがオプションを変更したときに、マッピングが黙って変わらないようにしてください。現在の状態、有効なバンドルルール、過去の関係を、注文履歴の照合に使えるよう保持してください。新規または変更されたオプションでは、過去の注文のマッピングを見えない形で書き換えるのではなく、明示的なマッピング変更イベントを発生させるべきです。

在庫、フルフィルメント、精算の前にマッピングを適用する

在庫を減らした後にマッピングするのでは遅すぎます。下流システムが注文を実行可能なものとして扱う前に、その関係を解決しておく必要があります。

安全な手順は次のとおりです。

1. 元の注文データを保存します。 プラットフォームの注文、行、商品またはアイテムの参照、生成オプションを示すフラグ、数量フィールド、価格、割引を保持します。
2. 行を分類します。 通常の出店者商品なのか、自動生成された数量オプションなのかを判定します。
3. 関係を解決します。 元のアイテム、内部の基準SKU、適用するバンドルサイズのルールを特定します。
4. 処理数量を計算します。 バンドルルールを注文数量に適用します。レスポンスに出荷数量が含まれる場合は、それを独立した情報として保持します。
5. 冪等性を保って処理します。 マッピングが成功してから在庫を減算し、フルフィルメント作業を作成します。同じ注文を再試行しても、在庫が2回減算されないようにします。
6. 顧客向けオプションと基準SKUの両方の観点で記録します。 売上と割引は顧客向けオプション単位で保持し、実物数量と単位利益はブランドの会計方針に従って基準SKUに集約します。

この順序は、ブランド自身の倉庫だけでなく、フルフィルメントサービスにも重要です。プラットフォーム上では1つの販売行に見えても、フルフィルメント指示では複数の基準単位が必要になる場合があります。コネクターが行の数量だけを渡すと、倉庫には不完全な指示が届きます。逆に、オプションを別SKUと解釈したうえでさらに数量を掛け、過大な数量を渡すと、同じ注文で過剰出荷が発生する可能性があります。

精算でも同じ関係が必要です。注文レコードから、財務担当者が次の内容を追跡できるようにしてください。

• どのプラットフォーム行が売上を発生させたか
• どの元の商品と生成オプションが関係したか
• どの価格と割引が適用されたか
• どの基準SKUに実物単位の在庫移動を割り当てたか
• どの数量ルールがその移動を生んだか

これは、照合時に商品名からバンドル数量を再構築するより信頼性が高い方法です。この考え方は、Coupangの精算期間：Kontacticの照合方法における記録の紐付けの原則とも一致します。そこでは、プラットフォームの証跡と配賦レコードが精算レビューを通じて結び付いたままになります。

注文がCoupang Rocket Growthなどのフルフィルメントワークフローに流れる場合も、同じ区別が下流まで続きます。Coupang Rocket GrowthのSKUが利用できないままになる理由は、プラットフォームの在庫状態を、注文行や社内の補充予定から推測するのではなく、プラットフォームが認識する在庫と照合すべきことを示す参考になります。

本番在庫を任せる前にコネクターをテストする

本番展開の前に、出店者アカウントまたは管理されたテスト環境の実際のレスポンス形状を使ってマッピングをテストしてください。通常の注文を取り込めるだけでは不十分です。オプションの状態が変化したときにも、コネクターが関係を保持できるかを確認してください。

自社開発のコネクターが妥当なのは、ERPと連携層が、1対多の商品マッピング、変更されるバンドルサイズ、重複を安全に処理する更新、監視、未マッピングケースのレビューパスをサポートしている場合だけです。中核の前提が「1つのプラットフォーム商品から1つの内部SKUと1つの整数数量」という汎用コネクターは危険です。

ベンダーには注文画面だけでなく、正規化されたレコードを提示してもらってください。確認すべき証拠は、元の商品、生成オプション、基準SKU、バンドルルール、計上された数量の間に保存された関係です。ベンダーがこれらの値を公開できないなら、取り込みに成功していても、安全でない在庫判断が隠れている可能性があります。

生成オプションを制御し、API接続を守る

自動生成オプションを望まないブランドは、Product APIの制御機能を使って、商品登録後に特定の生成オプションまたはすべての生成オプションを無効化できます。これによりカタログ方針を簡素化できる場合がありますが、検出の代わりにはなりません。プロセスでは、Coupangがオプションを追加、変更、無効化したときに、状態を再確認してアラートを出す必要があります。

再同期プロセスでは、CoupangのAPIの動作も考慮する必要があります。Coupangは、商品関連の呼び出しが過剰になるとHTTP 429レスポンスが返され、ブロックにつながる可能性があると警告しています。そのため、オプションの検出と再同期には、スロットリング、バックオフ付きのリトライ、最後に確認した状態の保持、アラートを使うべきです。無制限に繰り返し呼び出すのではなく、レート制限を考慮した運用が必要です。

運用監視では、次の4つに答えられるようにしてください。

• 商品の生成オプション状態は変化したか
• 生成オプションを示すフラグがあるのに、マッピングが存在しない注文が届いたか
• 計算された実物数量と、在庫またはフルフィルメントに計上された数量が異なっていないか
• リトライ、レート制限のレスポンス、部分的な更新によって、注文が不明な状態に残っていないか

こうしたチェックがあれば、カタログ機能に伴う連携課題を管理できるようになります。これがなければ、コネクターは安定しているように見えても、誤った在庫データや利益データを少しずつ蓄積している可能性があります。

Coupangの数量オプションに関するよくある質問

自動生成された数量オプションは、すべて新しいSKUですか？
いいえ。顧客向けのプラットフォームオプションです。ブランドの保管・ピッキング方針で、別個の梱包済み商品として扱う場合に限り、別の倉庫SKUを割り当ててください。

コネクターはオプション名から数量をマッピングできますか？
いいえ、そうすべきではありません。生成オプションを示すフラグ、関連アイテム参照、1オプションあたりの基準単位数、注文数量または出荷数量、プラットフォーム識別子を使ってください。表示名はレビュー担当者の参考にはなりますが、在庫計算の根拠にはしないでください。

Coupangはすべての商品にこのようなオプションを作成しますか？
いいえ。この機能は対象カテゴリ向けに提供されており、商品ごとに検出する必要があります。コネクターは、アカウント全体で一律の状態だと想定してはいけません。

生成オプションを無効化すれば、連携リスクはなくなりますか？
適用した商品については数量の変動要因をなくせますが、コネクターは引き続き状態を確認し、既存の注文や古いレスポンスを正しく処理する必要があります。

Open APIが会計上の扱いを決めるのですか？
いいえ。Open APIは商品と注文の関係を公開し、制御機能を提供します。オプションを基準SKU、梱包済みSKU、フルフィルメント数量、レポート上の扱いのどれにマッピングするかは、ブランドが定義します。

汎用コネクターで十分なのはどのような場合ですか？
1対多のマッピング、変更されるバンドルルール、重複を安全に処理する更新、監視、未マッピングケースの人によるレビューを保持できる場合に限ります。1つのプラットフォーム行を1つの内部単位と想定している場合は、十分に検証されていないものとして扱ってください。