Coupang Open APIのキーはコネクタで更新できる？発行・再発行はWINGで行います

Coupang Open APIコネクタは、自らが使用するセラーアカウントの認証情報を発行・再発行できません。Coupangでは、これらの操作をセラー向け管理画面であるWINGで行います。コネクタは認証が完了すれば、商品カタログ、注文、在庫、精算に関する処理を自動化できますが、認証情報のローテーションと復旧は、WINGを操作できる担当者が管理する必要があります。

これが、実務上の「自社開発か、外部サービスを利用するか」の境界です。コネクタは反復的なデータ処理を減らせますが、セラーアカウントの管理責任を担うわけではありません。調達担当がこの2つを同じものとして扱うと、今は動いても認証情報に対応が必要になった際の担当者が定まっていない連携を承認することになります。

APIが自動化するのはECデータであり、セラーアカウントの管理主体になることではありません

Coupang連携を評価する際は、データプレーンとコントロールプレーンを分けて考えると有用です。データプレーンとは、既存の認証情報を使い、接続を通じて実行される処理です。コントロールプレーンとは、接続を成立させ、利用可能な状態に保つアカウント管理の権限と責任です。

商品同期が成功しても、そのリクエストで認証情報が機能したことしか証明しません。連携が代替の認証情報を作成できること、有効期限の状態を確認できること、WINGでアカウントレベルの操作が必要になった場合に対応できることまでは証明しません。これらは別の能力であり、技術評価では分けて記載する必要があります。

データプレーンのジョブと認証情報の管理責任は分けてください。カタログ登録、価格・在庫の呼び出し、共有セラーIDの設計については、それぞれ個別の運用課題として扱います。詳しくは、Coupang Open APIで商品カタログをアップロードできる？、Coupangで価格と在庫に別々のAPI呼び出しが必要な理由、Coupang Open API：2つのシステムで1つのセラーIDを共有できる？をご覧ください。

欧米ブランドが韓国で現地展開を始める場合、この分離はベンダー選定の際に特に役立ちます。業務ワークフローと認証情報ワークフローを分けた図を求め、誰がWINGを使い、誰がアラートを受け取り、誰が置き換え後の認証情報をデプロイするのかを確認してください。

提案書に最初の図しかない場合、接続をどのように運用するかは、まだ説明されていません。

キーの発行・再発行はWING内で行います

Coupangの公式Open API開発者ドキュメントは、APIの認証とリクエスト動作を確認するための一次情報として適切です。アカウント側の操作については、WINGのセラー向け管理画面と、最新のヘルプまたはFAQを確認してください。重要な境界は一貫しています。APIが利用するのはセラーアカウントの認証情報であり、文書化された発行・再発行の操作はOpen APIの呼び出しではなくWINGで行います。

稼働中のコネクタは、既存のAPIセッションを使ってCoupangに新しいキーを要求することはできません。問題を検知して失敗を報告し、設計次第では、担当者による保存済みシークレットの更新を支援できます。そうしたシグナルをWINGの操作権限に変えることはできません。必要なWINGアクセス権を持つ担当者またはチームを、連携の運用設計に含める必要があります。

Coupangの現在の公式FAQでは、再発行の操作は有効期限前の最後の14日間に限って利用可能になると説明されています。これは、アカウントの担当者を決める期限ではなく、計画上の制約として扱ってください。その期間に入る前にアラートを設定し、WINGを操作する担当者とバックアップ担当者を確認し、再発行が可能になる前にデプロイ経路の準備を整えておきます。

WINGの正確なラベルや画面レイアウトは変わる可能性があるため、Coupang公式Open API開発者ドキュメントとWINGのセラー向け管理画面で現在の手順を確認してください。運用上の結論はボタン名に左右されません。コネクタがアカウント管理の責任者に取って代われないことが重要です。

管理責任を記録する際は、最低限、次の項目を含めてください。

• セラーアカウントと、WINGで操作を担当する人。
• 主担当者が対応できない場合に行動できるバックアップ担当者。
• 認証情報を使用するシステムと環境。
• アラートの送信先と、アラートを確認する責任者。
• 置き換え後の認証情報をデプロイできる人と、重要なワークフローを検証する人。

担当者を明記することと、共有パスワードを使うことは別です。目的は明確な責任分担とアクセス制御であり、チームチャットやスプレッドシートに認証情報をコピーすることではありません。担当者はWINGの操作を実行できなければならず、連携チームは秘密情報を不必要に公開せずに、その結果をデプロイできなければなりません。

認証情報のローテーションは、運用上の切り替えとして行います

再発行は、WINGに置き換え後の認証情報が表示された時点で完了ではありません。すべての利用先を更新し、依存するワークフローをテストし、監視が正常であることを確認してください。この変更は切り替えとして扱います。

1. すべての利用先を洗い出します。 本番コネクタ、スケジュール実行ジョブ、ERPや倉庫との接続、スクリプト、ステージング環境、その他セラーアカウントの認証情報を使う可能性があるサービスを一覧にしてください。古い連携が一覧から漏れると、切り替え後も失敗し続けたり、どのシステムが稼働中なのか分からなくなったりします。
2. WINGの担当者とデプロイ担当者を決めます。 WINGで認証情報を再発行できる人と、連携設定を変更できる人は異なる場合があります。有効期限前の最後の14日間に入る前に、両方の役割を割り当て、それぞれのバックアップも文書化してください。
3. 切り替えの時間帯を決めます。 確認が必要なカタログ、注文、在庫、精算ジョブを特定してください。短時間停止できるジョブ、安全にテストできるジョブ、変更中に監視する担当者を決めます。避けられる場合は、関係のないプラットフォーム変更や倉庫変更と同じ時間帯に切り替えを行わないでください。
4. WINGで操作を完了します。 アカウントが再発行可能な状態になったら、責任者がCoupangの現行WING手順に従って発行または再発行を行います。連携チームは、APIエンドポイントにリクエストを送ることを代替策として扱わないでください。
5. 置き換え後の認証情報を安全に保管・配布します。 新しい値は承認済みのシークレット管理経路に格納し、ソースコード、チケット、暗号化されていないメモには置かないでください。各利用先は通常のデプロイ手順で更新します。以前の認証情報が引き続き使える、またはすべてのサービスが同じ設定を読み込むとは限りません。
6. 重要なワークフローをテストします。 コネクタが実際に実行する操作について、認証後の動作を確認してください。たとえば、カタログ処理、注文取得、在庫更新、精算データなどです。接続に依存するジョブが4つあるなら、1つのエンドポイントに到達するだけのヘルスチェックでは不十分です。
7. 監視を確認して変更を完了します。 失敗でアラートが発生すること、そのアラートが指名した担当者に届くこと、ログが秘密情報を露出せずに影響を受けた利用先と外向きの通信経路を特定できることを確認してください。完了日、更新したシステム、テスト結果、使用した復旧手順を記録します。

この手順は、第三者がコネクタを運用する場合にも有効です。ブランド側は運用者に対し、利用先一覧、ローテーション手順書、ワークフローテストの証跡、WINGでの対応が必要な場合の引き継ぎ手順を求めるべきです。

よくある失敗は部分的な切り替えです。メインコネクタは更新したのに、精算ジョブや小さな在庫スクリプトが古い値を使い続けます。その結果、実際には認証情報のデプロイが不完全なのに、断続的なCoupangの問題に見えてしまいます。利用先一覧があれば、連携全体を一つのブラックボックスとして扱うことを防げます。

403は有効期限の判定ではなく、診断の問題です

HTTP 403が返ったからといって、Coupang APIキーが期限切れになったことを自動的に意味するわけではありません。Coupangの公式ガイダンスでは、サーバーIPのブロックや、異常または繰り返しのエラートラフィックに伴う一時的な制限も原因として示されています。原因ごとに必要な対応は異なるため、やみくもにキーを再発行したり、同じリクエストを繰り返し再試行したりすると、インシデントが長引く可能性があります。

次の手順に沿って切り分けてください。

1. 事象を記録します。 時刻、影響を受けた利用先、エンドポイント、リクエスト種別、レスポンス、実際のアウトバウンドIPを記録してください。インシデント記録に秘密情報を残さないでください。実際にリクエストを送っているサービスは、チームメンバーが想定しているサーバーとは限らないため、アウトバウンドIPが重要です。
2. 繰り返しのトラフィックを減らします。 連携のインシデント手順に従い、失敗しているジョブを一時停止するか、バックオフさせてください。異常なエラーが繰り返されると一時的な制限につながる可能性があり、トラフィックを増やしてもキーが有効だとは証明できません。
3. アカウント側の状態を確認します。 WING担当者に認証情報の状態と有効期限情報を確認してもらいます。再発行が必要で、アカウントが文書で案内された再発行可能期間に入っている場合は、APIで解決しようとせず、WING手順に従ってください。
4. ネットワーク経路を確認します。 コネクタがどのパブリックIPを使っているか、またそのIPが変更されたか、予期せず共有されているか、Coupangのガイダンスでブロック対象として示されているかを確認してください。認証情報を置き換えても、ブロックされた外向きの通信経路は直りません。
5. 失敗の範囲を切り分けます。 影響を受けた利用先とワークフローを比較してください。あるサービスだけが失敗し別のサービスが成功している場合、セラーアカウント全体が利用不能だと判断する前に、そのサービスのシークレットとネットワーク設定を調査してください。
6. 原因を確認してから、手順を踏んで復旧します。 原因を確認したうえで、認証情報またはネットワーク設定を更新し、重要なワークフローのテストを実行して、監視を継続してください。何を変更したか記録せずに、キー、IP、再試行ポリシーを同時に変更しないでください。

目的は、コネクタにCoupang側のあらゆる判断を診断させることではありません。最初の403をきっかけに、記録されない再試行や認証情報変更が連続して起きるのを防ぐことです。優れたコネクタは証拠を見えるようにし、アカウントレベルの対応をWINGで実行できる担当者へ振り分けます。

認証情報の管理責任を「自社開発か外部サービスか」の判断軸にする

重要なのは、コネクタに自動更新ボタンがあるかではありません。選んだ運用モデルが、Open APIでは実行できない作業までカバーしているかどうかです。自社開発なら、その作業を社内で担います。ソフトウェアベンダーや運用代行会社が支援する場合でも、責任者と代替担当者を明確にする必要があります。

「キーは自動で処理されます」と言われた場合は、その意味を正確に確認してください。その表現は、次のような複数の意味を持ちます。

• システムが有効期限までの日数をカウントする。
• システムがWINGで操作するよう人にアラートを送る。
• 人がWINGの操作を実行した後、システムが保存済みシークレットを更新する。
• システムが失敗したリクエストを再試行する。
• システムが再発行まで自動で行う。

これらは同じではありません。Open APIには、コネクタがセラーアカウントの認証情報を発行・再発行する経路はありません。実用的な提案書なら、どの手順がWINGに残るのか、誰が担当するのか、置き換え後の情報を本番にどう反映するのかを明示するはずです。

調達では、承認する前にローテーションと403復旧の手順書を見せてもらってください。ベンダーに秘密情報を渡してもらったり、内部のセキュリティ設計を公開してもらったりする必要はありません。次の4つの質問に答えられるだけの情報が必要です。誰が対応するのか。何が変わるのか。どのようにテストするのか。最初の復旧試行が失敗したらどうなるのか。

これが本当の自社開発と外部利用の境界です。コネクタを購入すれば、チームが保守するコード量は減らせます。しかし、セラー向け管理画面への依存はなくなりません。その依存を「運用負荷の少ない連携」という言葉の裏に隠すべきでもありません。

Coupang APIキーの更新に関するよくある質問

コネクタはAPIエンドポイント経由で新しいCoupang Open APIキーをリクエストできますか？

いいえ。コネクタは現在のセラーアカウント認証情報を使って業務データの呼び出しを自動化できますが、文書化された発行・再発行はWINGで行われます。

コネクタで有効期限を監視できますか？

設計と利用可能なデータがその機能をサポートしていれば、アラートをスケジュールしたり、失敗した呼び出しを検知・通知したりできます。監視は有用ですが、アカウント側の操作に必要なWINGアクセス権が付与されるわけではありません。

担当者はいつ再発行の準備を始めるべきですか？

準備は有効期限前の最後の14日間より前に始めてください。Coupangの現在の公式FAQでは、再発行の操作が利用可能になるのはその14日間だけと説明されています。その14日間に入ってから担当者の決定、デプロイ、テストを始めるべきではありません。

HTTP 403が返れば、キーの期限切れだと証明できますか？

いいえ。認証情報の状態に加えて、実際のアウトバウンドIPとリクエストの動作を確認してください。Coupangの公式ガイダンスでは、ブロックされたサーバーIPや、異常または繰り返しのエラートラフィックによる一時的な制限も示されています。

欧米ブランドはコネクタ要件に何を含めるべきですか？

WINGの主担当者とバックアップ、期限アラート、安全なシークレットのデプロイ、安定したアウトバウンドIPの管理、制御された再試行を伴う403監視、ワークフローテスト、復旧手順書を必須にしてください。ベンダーがWINGで誰が対応するのかを説明できない場合、その連携はまだ十分に運用設計されていません。