1そもそも Amazon SP-API って何？

SP-API（エスピー・エーピーアイ）とは、Selling Partner API の略で、Amazonが提供するセラー（出品者）向けの公式APIです。受注データの取得、在庫・価格の更新、配送通知、レポート出力など、セラーセントラルで手動でやっている作業の大半を、プログラムから自動で行えるようになります。

ひとことで言えば、「Amazonのセラー業務を自動化するための公式の窓口」です。

ただし、SP-APIは前身のMWS（Amazon Marketplace Web Service）よりも複雑になりました。認証の仕組みが変わり、レート制限のルールが厳密になり、個人情報を取得するには追加のトークンが必要になっています。「MWSの感覚でSP-APIを叩くと必ず事故る」と言われる所以です。

本記事では、SP-APIを本番運用して初めて見える「レート制限」「トークン期限」「RDT（個人情報トークン）」という3つの大きな罠と、その回避設計を実務の視点から解説します。

2SP-API の基本構造 ― 認証・リージョン・エンドポイント

罠の話に入る前に、SP-APIの基本構造を押さえておきましょう。ここを理解していないと、後のエラーメッセージの意味がわかりません。

認証の仕組み ― LWAトークン

SP-APIの認証は LWA（Login with Amazon）と呼ばれるOAuth 2.0ベースの仕組みで行います。重要なのは「トークンが2種類ある」ことです。

トークン	有効期限	役割
アクセストークン	1時間	API呼び出しのたびにヘッダに付ける短期トークン
リフレッシュトークン	長期（実質無期限）	アクセストークンを再発行するための長期トークン
Restricted Data Token (RDT)	約1時間（短め）	購入者氏名・住所などの個人情報（PII）取得専用

実運用では、リフレッシュトークンを安全な場所に保管しておき、1時間ごとに新しいアクセストークンを取得するのが基本パターンです。アクセストークン毎回発行、を毎リクエストでやってしまうと、それ自体がレート制限に引っかかります。

リージョンとエンドポイント

SP-APIは世界を3つのリージョンに分けています。日本の楽天ではなくAmazonセラーの場合、Far East（FE）リージョンを使います。

「amazon.co.jp（日本）」でセラー登録しているなら FE、「amazon.com（米国）」なら NA、複数のマーケットプレイスに出品しているなら複数のエンドポイントに並行してアクセスすることになります。リージョンを間違えると「なぜか404」が返ってきます。

3最大の罠「レート制限」― 429エラーが起きる本当の理由

SP-APIで最もハマるのがこれです。「ドキュメント通りに書いたのに、本番でだけ 429 Too Many Requests が返ってくる」という現象は、ほぼ全員が一度は経験します。

トークンバケット方式の仕組み

SP-APIのレート制限は、「トークンバケット方式（Token Bucket Algorithm）」という仕組みで動いています。これを理解しないと、なぜ429が出るのかが永遠にわかりません。

各エンドポイントには「Rate（1秒あたりの補充速度）」と「Burst（バケツの最大容量）」の2つの数値が設定されています。Burstまでは一気に連打できますが、使い切ったらRateの速度でしか補充されません。

エンドポイントごとにレートが違う

ここが最大の落とし穴です。エンドポイントによってRateとBurstがまったく違います。「getOrdersが動くなら全部動くだろう」と思って他のAPIを叩くと、秒殺で429が返ってきます。

エンドポイント（代表例）	Rate (req/sec)	Burst	用途
getOrders	0.0167（約1分1回）	20	受注一覧の取得
getOrder	0.5	30	受注1件の詳細取得
getOrderItems	0.5	30	受注の商品明細取得
getCatalogItem	2.0	2	商品情報の取得
createFeed	0.0083（約2分1回）	15	一括更新フィード作成

※ 上記は公式ドキュメント記載の代表値。セラーのアカウント状況や時期により変動することがあります。最新値は必ず公式ドキュメントで確認してください。

特に注意すべきは getOrders。レートは 1分に1回しか補充されません。Burst 20を使い切ったら、1分待たないと次のリクエストが通らないのです。「セール日に受注が1000件入ったから、とりあえず全部getOrdersで取り直そう」は即死コースです。

4トークンの罠 ― 期限切れ・RDT・リボーク

レート制限を乗り越えても、次に待っているのがトークンの罠です。「動いていたはずのシステムが、ある朝突然全部止まっている」という現象の多くは、このトークン問題が原因です。

罠1：アクセストークンの期限切れ

アクセストークンの有効期限はわずか1時間。これを過ぎるとすべてのAPI呼び出しが 401 Unauthorized で失敗します。

よくある事故パターン：

• 夜間バッチで取得したアクセストークンを翌朝そのまま使って401エラー
• アクセストークンをDBに保存して使い回しているが、期限チェックがない
• リトライロジックがトークン再取得を含んでおらず、401で処理が止まる

対策は「トークンの有効期限を必ず保存し、期限が近づいたら先回りして再取得する」こと。アクセストークン発行時のレスポンスに expires_in（秒数）が含まれているので、それをもとに期限を記録しておきます。

罠2：Restricted Data Token (RDT) がないと個人情報が取れない

SP-APIでは、購入者氏名・配送先住所・電話番号などの個人情報（PII: Personally Identifiable Information）を取得するには、通常のアクセストークンに加えてRDT（Restricted Data Token）という専用トークンが必要です。

RDTを取得する手順：

1. createRestrictedDataToken APIを呼び、対象リソース（例: /orders/v0/orders/{orderId}）を指定
2. レスポンスで返されたRDTを、次の実リクエストのAuthorizationヘッダに使用
3. RDTは約1時間で失効するので、対象注文ごとに取り直し

罠3：セラーによるアプリ連携の無効化（リボーク）

SP-APIはセラーが「このアプリに自分のアカウントへのアクセスを許可する」仕組みで動いています。つまり、セラー側がセラーセントラルの管理画面でアプリ連携を無効化（revoke）すると、その瞬間にAPIがすべて401になります。

よくあるシナリオ：

• セラー（クライアント）が「使わなくなったアプリ」を整理していて、気付かず連携解除
• Amazonの定期的なセキュリティレビューで強制的にリボーク
• 連携を承認したAmazonアカウントのパスワードが変わった

システム側からは「同じリフレッシュトークンなのに、ある日を境に401」に見えます。エラーログだけ見ても原因がわからず、セラーに確認するまで詰むのが定番パターンです。

5EC実務で起きるSP-API事故パターン

ここまでの仕組みを踏まえて、EC実務の現場で実際に起きるSP-API事故を具体的に見ていきましょう。

事故1：セール日に受注取得が詰まる

プライムデー・ブラックフライデー・年末年始のような受注ピーク時。普段1日10件のセラーに1000件の注文が入ったとします。これをgetOrdersで全件取ろうとすると：

ここでパニックになって「並列で叩けばいいじゃないか」と複数プロセスから同時にgetOrdersを叩くと、Burstを一瞬で使い切ってますます遅くなります。正解は「ページング + NextToken」で1回のgetOrdersで複数件をまとめて取得することです。

事故2：大量出荷時のFeeds APIが詰まる

出荷通知（出荷ステータス・追跡番号）は Feeds API で一括送信します。createFeed のレートは 約2分に1回。1件ずつフィードを作って送ると、出荷100件に200分かかります。

正解は「出荷通知を1つのフィードにまとめて送る」こと。Feeds APIは1フィードで数千件を一括処理する前提で設計されています。1件1フィードはAPIの使い方を間違えています。

事故3：複数スクリプトが並列で動いていて一瞬でバースト切れ

「在庫同期バッチ」「受注取得バッチ」「価格更新バッチ」が別々のサーバー・別々のスクリプトで同時に走っているケース。レート制限はセラー単位で共有されるため、どこか1つがバーストを使い切ると他のバッチが全部429になります。

対策は「同じセラーへのAPIコールは1つのキューに集約し、並列数を制御する」こと。インフラ的には Redis のレートリミッタや、SQS などのキューを挟むのが定石です。

事故4：MWSのまま運用していて2024年8月に一斉停止

旧MWSは2024年7月末で完全廃止されました。移行を後回しにしていた事業者は、2024年8月以降にAPI連携がすべて停止。「動いているから放置」の古いシステムは、今でも時限爆弾のリスクがあります。外注開発で納品されたまま中身を触っていないシステムは、一度MWS混入がないか監査しておくのが無難です。

6安全にSP-APIを使うための設計ポイント

ここまで読むと「SP-APIは怖い」と感じるかもしれませんが、設計のポイントさえ押さえれば安定運用は可能です。経験則から、最低限実装すべき5つのポイントを挙げます。

ポイント1：指数バックオフでリトライする

429が返ってきたら、待ち時間を倍々に伸ばしながら再試行するのが定石です。1秒→2秒→4秒→8秒→16秒というように。即座にリトライすると、429を429で追い打ちして永遠にループします。

ポイント2：アクセストークンをキャッシュする

アクセストークンは1時間有効。毎リクエストで取り直すのは無駄どころか、トークン発行自体のレート制限に引っかかる原因になります。取得したアクセストークンは有効期限とセットでキャッシュし、期限の5〜10分前になったら先回りして更新しましょう。

ポイント3：レート制限を「自分で守る」

429が返ってきてから対処するのではなく、そもそも呼び出し側で「1分に1回以上getOrdersを呼ばない」ように制御します。Redis のレートリミッタ、Semaphore、トークンバケット実装のライブラリ（Pythonの ratelimit、Node.jsの bottleneck など）を挟むのが定石です。

ポイント4：Sandbox環境で先にテスト

SP-APIにはSandbox環境が用意されています。固定のテストデータが返ってくるので、本番アカウントに影響を与えず認証・レート制限・エラーハンドリングの実装を試せます。いきなり本番で試すのは事故のもとです。

ポイント5：エラー監視とアラート

401（トークン期限切れ・リボーク）や 429（レート制限超過）、503（サーバー側の一時的障害）は、発生頻度と種類別に監視・アラートを仕込むこと。「朝起きたら受注が取れていなかった」を無くすには、異常時にすぐ気付ける仕組みが不可欠です。

7自力対応の限界と、プロに任せるという選択肢

SP-APIはAmazonセラーにとって「避けて通れない」APIです。受注取得・在庫連動・出荷通知など、モール運営の基幹業務が全部この上で動きます。しかし、ここまで見てきた通り、安定運用に必要な設計パターンは多岐にわたります。

• トークンバケット方式のレート制限を理解し、エンドポイントごとに適切な呼び出し設計をする
• LWAトークン・RDT・リボークを想定したエラーハンドリングを実装する
• 指数バックオフ・キャッシュ・キュー制御を組み合わせる
• Sandbox環境で十分にテストし、本番投入後も監視する

これらを「自社の片手間」で実装・維持するのは、現実的にはかなり重い負荷です。さらに厄介なのは、SP-APIはAmazon側の仕様変更が頻繁にあること。レート制限値の変更、新エンドポイントの追加、古いエンドポイントの廃止予告など、動いているシステムでも定期的なメンテナンスが必要です。

もし「SP-API連携がなぜか不安定」「セール日に受注取得が詰まる」「MWSのまま残っているシステムがある」といった課題を抱えているなら、API設計の見直しから仕組み化まで、外部の手を借りるのが最も確実な解決策です。

EC現場の実務を知っていて、かつAmazon SP-APIの仕様まで踏み込める人は多くありません。11年のEC実務経験に基づいて、セラーセントラルの運用と技術実装を橋渡しできる――それが、mixt-incがSP-API周りのご相談でお役に立てる部分です。受注取得の遅延、出荷通知の詰まり、在庫同期のズレなど、「動くけど不安定」な連携を根本から設計し直したい方は、ぜひお気軽にご相談ください。