Coupang Open API：同じSeller IDを2つのシステムで使えるか？

いいえ。同じSeller IDまたはvendor codeに対して、Coupang Open APIの連携を2つ別々に登録することはできません。Coupangの公式キー管理ガイダンスでは、その対象アカウントで利用できるOpen APIキーは1つとされています。複数のプロバイダー、または外部プロバイダーと自社開発の連携を同時に登録することは認められていません。

現実的な構成は、Coupangとの直接接続を1つのコネクターに集約し、商品、注文、在庫、精算データをERP、倉庫プラットフォーム、会計システムなどの社内ツールへ振り分ける方法です。

ルールはSeller IDまたはvendor codeごとに適用されます

この制限はブランド単位ではなく、アカウント単位です。Seller IDやvendor codeを複数持つ場合は、それぞれについて連携方針を決めてください。あるアカウントで選んだコネクターが、別のアカウントも自動的にカバーするわけではありません。

この区別は、韓国でのローンチ時に重要です。ERP、倉庫プラットフォーム、会計システムは複数国で共通利用する場合がありますが、Coupangの認証は1つのセラーアカウントにひも付きます。数えるべきなのは、自社が所有するシステム数ではなく、そのSeller IDまたはvendor codeに対するCoupangへの直接登録数です。

ツールを選ぶ前に、簡単なアカウントマップを作成してください。

• 対象となる正確なSeller IDまたはvendor code
• Coupangとの直接接続を担う予定のコネクター
• キーを管理する担当者またはサービス
• データを必要とする社内システム
• 各書き戻しの判断を担うシステム

一次資料として、Coupang公式Open API開発者ドキュメントとWINGのキー管理フローを確認してください。実装前には最新の公式文言を確かめ、一般的な互換性の主張ではなく、プロバイダーのドキュメントで商品、注文、在庫、ステータス、精算の各フローへの実際の対応範囲を確認しましょう。

1つのCoupang連携で複数のシステムにデータを配信できます

「Coupangに直接接続する」ことと「Coupangのデータを受け取る」ことは同じではありません。前者はOpen APIキーを使ってCoupangに認証するシステムを指します。後者は、選択したコネクターからデータを受け取る下流システムを指します。この転送には、エクスポート、インターフェース、社内データパイプラインなどを使う場合があります。

実務上の構成は、次のようになります。

Coupangセラーアカウント → Coupangとの直接接続を担うコネクター1つ → ERP / 倉庫プラットフォーム / 会計システム

この構成でCoupangを直接呼び出すのはコネクターだけです。下流連携が機能するかは、コネクターが提供するインターフェースと実装に左右されます。必要なフローに対応していれば、識別子の正規化、レコードの配布、社内システムからの承認済み更新の受け付けも可能です。ERPと倉庫プラットフォームの両方が注文や在庫情報を必要としていても、それぞれが独自のCoupangキーを持つ必要はありません。

連携は、フローごとに評価してください。

商品・カタログ運用

セラーツールやカスタムサービスでは、商品・カタログ情報の作成、更新、管理が必要になる場合があります。ローンチ前に、Coupangと社内システムの間で移動させる必要があるレコードを洗い出してください。商品識別子、バリエーション、Seller SKU、出品コンテンツ、該当する場合は価格などの販売関連項目が含まれます。

どのシステムが何を管理するかを曖昧にしないでください。ERPとセラーツールの両方が同じ商品レコードを書き込める場合は、まず優先順位を決めます。そうしないと、競合する更新によって一方の変更が上書きされる可能性があります。各フィールドについて、どのシステムを管理元とするか、コネクターが変更を中継するだけなのか、それとも変換も行うのかを決めてください。

Coupangの処理では、更新の種類を分ける必要もあります。たとえば、Coupangで価格と在庫に別々のAPI呼び出しが必要な理由は、出品管理に必要なすべての商品操作が含まれると決めつけず、プロバイダーの実際の対応範囲を確認するための参考になります。

注文・ステータス処理

コネクターは、注文データを、それに基づいて処理を行うシステムへ取り込む必要があります。フルフィルメントモデル上必要であれば、ステータス変更をCoupangへ送り返す必要もあります。例外はオペレーションキューへ振り分けてください。

「注文を同期できる」という説明だけで判断せず、公開されるデータと操作を確認してください。注文・明細を社内レコードと照合する際に使う識別子、ステータス変更の通知方法、更新が遅延・拒否された場合の挙動を個別に確認します。カスタマーサービスやCRMで利用できる形式かも確認してください。CoupangのOpen APIが実際に提供する顧客データとはでは、業務用の注文データを完全な顧客プロファイルとして自動的に扱うべきでない理由を説明しています。

在庫関連の運用

在庫関連の処理は、フルフィルメントモデルによって決まります。コネクターによっては、販売可能数を読み取り、在庫移動を監視し、補充を調整し、承認済みの在庫更新を渡すこともできます。ただし、可能な操作はCoupangが注文をどのようにフルフィルメントするかによって異なります。

Rocket Growthは、とりわけ重要な例です。販売可能数量は、Coupangがフルフィルメントセンターで実際に受領した数量によって決まります。そのため、社内の在庫数をすべて単純にCoupangへプッシュできると想定する設計は危険です。提案している在庫フローがフルフィルメントモデルと一致するか確認する際は、Coupang Rocket Growthに在庫数をプッシュできない理由を参照してください。

会計向けの精算データ

精算データは、最初から連携要件に含めてください。会計部門は、Coupangの精算記録を注文、返品、社内の売上記録、銀行口座の入出金と照合する必要があるかもしれません。単に日次の売上合計を受け取ればよいわけではありません。

注文ステータス、収益認識、精算のタイミングは、概念上分けて扱ってください。Coupangが売上を収益として認識するタイミングでは、配送を基準とする売上認識と、後から発生する取り消しの違いを説明しています。この区別は、レコードのラベルと照合ルールに影響します。ローンチ前に、コネクターと会計システムの双方で、これらを定義してください。事業で異なる精算スケジュールを使用する場合は、Coupangの精算タイムライン：月次・週次・早期精算の違いも、受け渡し設計に関係します。

Buy：セラーツールを登録コネクターにする

Buyの選択肢では、Seller IDまたはvendor codeに対するCoupang接続の唯一の登録先として、1つのセラーツールまたは連携プロバイダーを選びます。ERP、倉庫プラットフォーム、会計システムは既存の構成に残せますが、Coupangへ個別に登録するのではなく、選択したコネクターを経由してデータを受け取るようにします。

プロバイダーに権限を付与する前に、次の順序で進めてください。

1. 必要なフローを定義します。 ローンチに必要な商品、カタログ、注文、ステータス、在庫、精算に関する操作を列挙します。それぞれを読み取り、書き込み、社内だけの受け渡しのどれに当たるか記します。
2. 対象アカウントを確認します。 どのSeller IDまたはvendor codeに接続するのか、その登録方式がCoupangの1キー方針に準拠しているかをプロバイダーに確認してもらいます。
3. 実際の対応範囲を確認します。 識別子を含め、フローごとに回答を求めます。実行できない操作も確認してください。商品出品機能だけでは、注文ステータス、在庫、精算照合まで対応している証拠にはなりません。
4. 下流インターフェースを検証します。 プロバイダーがERP、倉庫プラットフォーム、会計システムにデータを公開する方法を確認します。フィールドマッピングと更新方向を確認し、失敗または一部のみ成功した同期をプロバイダーがどのように報告・修正するかも確認してください。
5. 管理主体を決めます。 カタログの値、フルフィルメントステータス、在庫判断、会計照合をどのシステムが担うかを決めます。プロバイダーがCoupang接続を持っているという理由だけで、意図せず管理元にならないようにします。
6. 切り替え・撤退計画を文書化します。 新しいキーを誰が申請・受領できるか、マッピングをどうエクスポートするか、運用履歴を失わずに現行プロバイダーとの連携を切り替え、必要なら撤退する方法を決めます。

Buyの選択肢が機能するのは、プロバイダーが運用フロー全体をカバーしているか、不足する部分を補う信頼できるインターフェースを提供している場合に限ります。カタログ変更には対応していても、精算レコードを会計システムに公開できないセラーツールでは、デモでは問題なく見えてもローンチ要件を満たせない可能性があります。

Build：1つの社内サービスをコネクターにする

Buildでは、そのSeller IDまたはvendor codeについてCoupangを呼び出す唯一のコンポーネントとして、社内サービスを1つ選びます。ERP、倉庫プラットフォーム、カスタムスクリプトは、Coupangではなくそのサービスと通信します。

このサービスが明確に管理すべきなのは、認証情報だけではありません。

• 認証情報の管理： キーを安全に保管し、アクセスを制御し、差し替えまたは失効の手順を定めます。
• 識別子のマッピング： Coupangの商品、アイテム、注文、ステータスの識別子を、社内SKU、倉庫レコード、会計レコードに対応付けます。
• データルーティング： Coupangを直接呼び出さなくても済むように、必要なレコードをERP、倉庫プラットフォーム、会計システム、オペレーションキューへ送ります。
• 監視： 認証失敗、更新漏れ、拒否された変更、重複レコード、ステータスの不一致を検知します。
• 照合： コネクターのレコードを、関連するCoupangデータと社内元帳とで比較し、見逃された同期失敗が原因不明の在庫差異や精算差異にならないようにします。
• 変更管理： 連携の変更を追跡し、プラットフォームまたは運用モデルが変わったときは、Coupangの最新の開発者向けガイダンスを確認します。

コネクターの役割と、正本となるシステム（system of record）の役割を分けてください。会計システムを照合の基準、倉庫プラットフォームを実在庫の管理元、ERPを商品マスターの管理元とする場合があります。カスタムコネクターは、こうした判断を変換してルーティングする役割です。すべての業務レコードを自ら管理する必要はありません。

Buildが有力なのは、自社のデータモデルや業務フローが汎用セラーツールに合わず、連携を保守できるチームがある場合です。また、マッピング、監視、復旧手順、将来の置き換え作業を自社チームが担うという、長期的な運用責任も生じます。どちらを選んでも、1つの連携というルールは変わりません。

なぜ一見便利なハイブリッド登録はサポートされないのか

よくある提案は、通常業務をセラーツールに任せ、足りない機能をカスタムコネクターで補う方法です。しかし、この分割でも同じSeller IDまたはvendor codeに対して複数の直接登録が生まれます。ERPが精算を担当し、セラーツールが商品と注文を担当する場合も同じです。

実務上は、選択したコネクターが必要なインターフェースを公開していることを条件に、カスタムロジックをその背後に置く設計が可能です。セラーツールをコネクターにする場合は、サポートされているエクスポートやインターフェースを使い、ミドルウェア、ERP、倉庫プラットフォーム、会計システムへデータを渡します。カスタムサービスをコネクターにする場合は、それをセラーツールのCoupangへの直接接続の役割を意図的に置き換えるものとし、両方の登録を並行して運用しないでください。

これは設計判断であり、ローンチ後まで先送りするための回避策ではありません。先にセラーツールを選び、後になってカスタムコードをその背後に置けないと判明すると、最悪のタイミングでキーの差し替え、データ移行、運用切り替えを迫られる可能性があります。

キーの再発行は本番切り替えとして扱ってください

Coupang Open APIキーの再発行は、単なるパスワード更新ではありません。Coupangの公式キー管理ガイダンスでは、キーを再発行すると古いキーは直ちに無効になるとされています。そのため、新しいキーを発行した瞬間に、既存のコネクターは認証できなくなります。この変更は、本番切り替えとして計画してください。

計画的に切り替える手順には、次の項目を含めてください。

1. 現在の接続を棚卸しします。 Seller IDまたはvendor code、現在のプロバイダー、キーの管理者、データフロー、スケジュール、マッピング、連携に依存している社内システムを記録します。
2. 新しい権限・責任分担を定義します。 どのコネクターがCoupangを呼び出し、どのシステムが商品、注文、在庫、精算に関する各判断を担うかを決めます。認証情報を変更する前に、責任範囲を明確にします。
3. 新しいマッピングとインターフェースを準備します。 下流への受け渡しを先に構築または設定します。機密情報ではない設定を保持し、新しいコネクターが既存の商品、注文、在庫レコード、精算期間をどう識別するかを文書化します。
4. 直近で正常に同期できた時点を記録します。 未処理の注文、ステータス変更、在庫レコード、未精算データを照合します。これを引き継ぎ中の取りこぼしを検出する基準にします。
5. キーの切り替えを調整します。 プロバイダーが関わる場合は、誰が新しいキーを受け取り、どのように安全に入力し、いつ有効化するかを事前に合意します。自社でキーを再発行すれば、プロバイダー側も自動的に更新されるとは考えないでください。
6. 再発行・有効化・監視を行います。 公式手順を通じて新しいキーを発行し、選択したコネクターを有効にします。認証エラー、重複または欠落したレコード、拒否されたステータス変更、在庫差異、精算の不一致を監視します。新しい接続で本番データの処理が始まった後、再度照合します。

Coupangの公式キー管理ガイダンスは、現在の連携を終了する計画を立てる際にも重要です。期限切れのキーは再発行でき、期限前のキーはWINGから削除できます。どちらのライフサイクル操作も、同じセラーアカウントで別々に登録した2つの連携を運用するための、サポートされた方法にはなりません。選択した接続を管理するための制御機能です。

よくある質問

ERPとCoupangのセラーツールで、同じSeller IDを使えますか？

両方で関連データを受け取ることはできますが、同じSeller IDまたはvendor codeに対する別々の直接Coupang Open API連携として登録すべきではありません。Coupangとの直接接続を担うコネクターを1つ選び、社内でデータを振り分けてください。

1キーのルールは、Coupangのデータを使える社内システムが1つだけという意味ですか？

いいえ。ルールが制限するのはCoupangへの直接接続です。コネクターは、サポートされたエクスポート、インターフェース、ミドルウェアを通じて、複数の社内システムへデータを配布できます。

セラーツールを導入した後にカスタムコードを追加できますか？

はい。カスタムロジックが選択したCoupangコネクターの背後で動き、そのコネクターが提供するインターフェースを使う場合は可能です。同じセラーアカウントに対してカスタムコードを別途登録することが、サポートされないハイブリッド構成です。

現在のキーが期限切れになると、どうなりますか？

Coupangの公式ガイダンスでは、期限切れのキーは再発行できます。プロバイダーがキーを使っている場合は、社内だけの変更と考えず、そのプロバイダーと再発行・有効化を調整してください。

プロバイダーを交換するときは、どうすればよいですか？

本番環境の切り替えとして扱ってください。キーを再発行すると古いキーが直ちに無効になるため、所有権を切り替える前に、認証情報の引き渡し、テスト済みのマッピング、照合の基準、ライブ監視を用意する必要があります。

選定前に、次を確認してください：

1. 各Seller IDまたはvendor codeについて、キーを管理するのは誰で、安全に差し替えられるのは誰ですか？
2. どのSeller IDまたはvendor codeを接続するのか、すでにその対象に登録されている他のツールはありますか？
3. 商品・カタログデータ、注文ステータス、在庫判断、精算照合について、どのシステムを管理元としますか？
4. どのフローが読み取り専用で、どのフローに書き戻しが必要ですか。また、コネクターは各フローをERP、倉庫プラットフォーム、会計システムにどのように公開しますか？
5. 更新漏れ、拒否されたリクエスト、重複レコード、認証失敗、照合差異をチームはどのように検知しますか？
6. コネクターを切り替える場合の移行計画はありますか。マッピングのエクスポート、キーの切り替えに関する調整、過去データの保持、切り替え責任者を決めていますか？

これらの回答が文書化されていないなら、コネクターの選定は終わっていません。キーは単なる認証情報ではありません。Coupangへの運用経路をどのコネクターが担うかを決めるものです。