クーパンのロケットグロースに在庫数を送信できない理由

Coupangのロケットグロース（로켓그로스）では、在庫数を送信することができません。販売可能な数量は、Coupangがフルフィルメントセンターで実際に入庫・受領した数量から算出されます。入庫受領時点での数量がそのまま販売可能数になります。フィールドに入力することも、API呼び出しで書き込むこともできません。この仕組みは出品者出荷（セラーフルフィルメント）の真逆であり、AmazonやShopifyから引き継いだ在庫同期を、気づかないままに崩してしまいます。

この違いが重要なのは、多くの海外チームが次の2つのどちらかを前提にしているからです。すなわち、編集できる数量フィールドがあるはずだ、あるいはどのマーケットプレイスのAPIでも在庫を調整できるはずだ、という思い込みです。ロケットグロースでは、そのどちらも当てはまりません。もし連携がこの前提の上に構築されていると、エラーも出ないまま静かに失敗します。書き込みは反映されず、出品者側にエラーは表示されず、最初に気づく症状は「原因不明の在庫切れ」というわけです。

基本ルール：受領数がそのまま在庫数になる

ロケットグロースの商品では、販売可能な数量は、Coupangのフルフィルメントセンターに物理的に入庫され受領された商品を反映します。Coupang自身の開発者向けドキュメントにも明記されています。ロケットグロース商品では入庫数量が商品数量として反映され、通常の商品数量変更の機能は適用されません。

つまり、ロケットグロースの出品では「数量を500に設定する」といった操作は存在しません。Coupangは荷受け場に到着した数量をカウントし、その数がそのまま販売可能数になります。数量に影響を与えられるのは、値を編集することによってではなく、商品を出荷して入庫させることによってのみです。

所有権や在庫の動きがこのような形で機能するのも、同じ理由からです。Coupangの棚にある商品は、売れるまでは依然として出品者のものですが、出品を動かしているカウントは、出品者が管理する数字ではなく、Coupangの受領記録です。「自社が所有するもの」と「Coupangがカウントするもの」の境界線については、クーパンのロケットグロースに何を送るべきか — そして誰が所有するのかで別途取り上げています。

出品者出荷の出品とどう違うのか

出品者出荷（マーケットプレイス）の出品では、在庫は自社が保有し、何個が販売可能かをCoupangに伝える責任も自社にあります。この場合、商品数量は自分で調整できます。数字は自分が所有・管理する値であり、自社の倉庫の在庫が減るのに合わせて更新していきます。

ロケットグロースはこれを逆転させます。Coupangが商品を保管し出荷するため、カウントを所有するのもCoupangだからです。ツール連携への影響は具体的です。ロケットグロース商品は、出品者出荷の出品を参照・変更するのと同じOpen APIのパスからは、照会も調整もできません。マーケットプレイスの出品者が商品数量を変更できるエンドポイントは、ロケットグロースのSKUにはそもそも該当する仕組みではないのです。

これは特定の形で連携を狂わせます。多くの在庫同期の実装では、「Coupang上の数量を更新する」という操作を、すべての出品に共通する1つの処理として扱っています。しかし、そうではありません。CoupangのAPIでは、マーケットプレイス商品であっても価格と在庫はすでに別々の処理として扱われており、この分離についてはCoupangで価格と在庫に別々のAPI呼び出しが必要な理由で解説しました。そしてロケットグロースでは、在庫の書き込みそのものが完全になくなります。同期ロジックを一度だけ書いて、それをすべての出品に向けている場合、ロケットグロースのSKUはリクエストのパスを受け付けはするものの、期待どおりには動作しません。

• 出品者出荷： 販売可能な数量は自分で設定・調整します。数字は自分が管理するものです。
• ロケットグロース： 販売可能な数量はCoupangの入庫受領から算出されます。数量設定の呼び出しは存在しません。
• 共通の落とし穴： すべての出品向けに書かれた1つの同期処理は、ロケットグロースの出品を静かに誤って扱ってしまいます。

プログラムでまだ制御できること

数量の書き込みが使えないからといって、ロケットグロースがブラックボックスというわけではありません。Coupangの開発者向けドキュメントによれば、ロケットグロース商品で使えるレバーは、数量ではなく、商業的・運用的なものです。実際には、以下のことは引き続き可能です。

• 販売価格の変更。
• 割引基準価格の変更。
• 出品の販売の一時停止と再開。
• 注文の読み取りと問い合わせの読み取り。

このリストの性質に注目してください。残されているものはすべて、価格に関する意思決定か、在庫可否の切り替えか、読み取りのいずれかです。唯一欠けているのが、在庫数を書き込む機能です。なぜなら、在庫数は自分が書き込むものではないからです。これはローンチ前に理解しておくことが重要です。ロケットグロースの自動化ロードマップは、価格・プロモーション・在庫可否・注文/問い合わせの読み取りを軸に構築すべきであり、補充はAPIのフィールド経由ではなく物流を通じて行われることを前提にすべきです。

在庫切れの防止は物流の問題になる

ここで、人員配置や計画の立て方を実際に変える発想の転換をお伝えします。数量フィールドを補充できない以上、ロケットグロースにおける在庫切れの防止は、在庫フィールドの更新の問題ではなく、物流サイクルの問題になります。数字をより速く編集することで在庫切れを防ぐのではなく、適切な量を十分に早く入庫させることで防ぐのです。

つまり、計画のインプットが変わります。在庫スライダーを見ながら調整するのではなく、販売消化のスピードと出荷リードタイムに対して需要を予測し、そこから逆算して発注トリガーを設定します。そのトリガーには、全工程を織り込む必要があります。すなわち、生産またはピッキング、韓国への輸送、通関とフルフィルメントセンターへの入庫、そしてCoupangの受領確認です。チームが忘れがちなのが、この受領のステップです。輸送中の商品や荷受け場で待機中の商品は、まだ販売可能ではありません。まだカウントされていないからです。

ここで実効的なリードタイムは、倉庫の上流にあります。それは出荷サイクルと受領にかかる時間の合計です。だからこそ私たちは、荷受け場のスループットそのものではなく、ロケットグロースの入庫最低数量と実際のリードタイムを、補充を左右する数字として扱っています。日々の運用リズムも役立ちます。販売消化と入庫状況を確認する短い定例レビューがあれば、まだ出荷が間に合ううちに迫り来る在庫切れを捉えられます。これが、韓国アカウントの昼のチェックインがSOP（標準作業手順）に組み込まれる価値を持つ理由の一つです。

よくある質問

Coupang Open APIを使ってロケットグロース商品の数量を設定できますか？ いいえ。Coupangの開発者向けドキュメントには、ロケットグロース商品では入庫数量が商品数量として反映され、商品数量変更の機能は適用されないと記載されています。数量はフルフィルメントセンターでの物理的な受領から算出されます。

なぜロケットグロースのSKUで在庫同期が静かに失敗するのですか？ ロケットグロース商品は、出品者出荷の出品と同じOpen APIのエンドポイントからは調整できないためです。マーケットプレイス商品向けに作られた同期処理は、ロケットグロースの数量を動かせないパスに向けられており、出品者側に意味のあるエラーは表示されません。

ロケットグロースの出品で、まだ自動化できることは何ですか？ Coupangのドキュメントによれば、価格の変更、割引基準価格の変更、販売の一時停止と再開、そして注文と問い合わせの読み取りが可能です。制御できるのは商業的・運用的な部分であり、数量ではありません。

在庫を送信できないのに、どうやって在庫切れを防げばいいですか？ 販売消化のスピードと出荷リードタイムに対して需要を予測し、入庫から受領までの期間を含めた発注トリガーを設定します。商品はCoupangが受領・受け入れをして初めて販売可能になります。したがって、どのくらいの頻度でどのくらいの量を入庫させるかというサイクルこそが、在庫可否を守るものになります。

どこで確認できますか？ Coupangの公式開発者向けドキュメントが、ロケットグロース商品がOpen API上でどのように動作するか（どの書き込み操作がフルフィルメント商品に該当し、どれが該当しないかを含む）についての権威ある情報源です。