Amazon Creators API / PA-API の API Rates とは？ 1 TPS・8640 TPD・31日目以降・429/503 の見方を整理

Amazon の API Rates って、数字だけ見ると単純そうなんですけど、実際に使い始めると混乱しやすいです。

よくある疑問としては、次のようなものがあります。

最初の30日間はどこまで使えるのか
31日目以降は何を基準に上限が変わるのか
売上があるのに利用枠が増えないのはなぜか
429 TooManyRequests が出たときにどう対処すればいいのか
30日間成果がないと本当に API が使えなくなるのか

この話がややこしく感じる原因は、「利用枠の増減」と「APIアクセスを維持できるかどうか」が、実は別々の仕組みで動いているからなんですよね。

この2つを分けて考えると、Amazon の公式説明はかなり読みやすくなります。

この記事では、PA-API 5.0 の公式ドキュメント「API Rates」と「Error Messages」、それから Associates Central のヘルプページをもとに、API Rates の全体像を整理します。

先に結論だけまとめると
この記事の前提：Creators API と PA-API の関係
TPS と TPD はどう違うのか
GetItems() で10個の ASIN を送っても 1 transaction
最初の30日間に与えられる初期枠
31日目以降の利用枠はどう決まるか
shipped item revenue と qualified referring sales は別の概念
30日間の成果条件を満たさないとどうなるか
売上があるのに利用枠が増えない場合
Primary Account とは何か
429 TooManyRequests が返ってきたとき
429 と 503、どちらが throttling を意味するのか
エラーが出たときの確認手順
実装側でやっておきたいこと
よくある誤解
まとめ
参考情報

先に結論だけまとめると

Amazon APIの利用制限やレート制限、エラー確認をイメージしたフラットデザインの挿絵

細かい話に入る前に、全体の要点を並べておきます。

項目	要点
初期枠	認証情報を作ると、最初の30日間は 1 TPS / 8640 TPD の枠が使える
31日目以降	過去30日間の shipped item revenue をもとに利用上限が毎日見直される
TPD の増え方	shipped item revenue が 0.05ドル増えるごとに 1 TPD
TPS の増え方	PA-API 5.0 文書では 4320ドルごとに 1 TPS。Associates Central ヘルプでは 4600ドルごとに 1 request per second
アクセス維持	qualified referring sales や qualified sales の条件を満たせないと、APIアクセスに影響する
エラー	429 はレート超過だけでなくアクセス停止でも返る。別のヘルプでは throttling を 503 と案内しているページもある

TPS の増加条件については、公式ソース間で数字が食い違っています。

PA-API 5.0 の文書では 4320ドル、Associates Central のヘルプでは 4600ドルです。どちらが「正」かは判断しづらいので、この記事では両方の数字を併記しています。

この記事の前提：Creators API と PA-API の関係

本題に入る前に、Creators API と PA-API の関係だけ整理しておきます。

日本のアソシエイト・セントラルでは、Creators API は PA-API やデータフィードなどを含む、より広い枠組みとして案内されています。

一方で、1 TPS、8640 TPD、0.05ドルごとに TPD が1つ増える、4320ドルごとに TPS が1つ増える、といった具体的なレート条件は、PA-API 5.0 の「API Rates」というページに書かれています。

ただし、この PA-API 5.0 のドキュメント自体には、「このサイトは保守されておらず、古い情報を含む可能性がある」「PA-API は 2026年4月30日に廃止予定で、Creators API へ移行するように」という趣旨の注記があります。

なので、この記事では次の前提で整理します。

大きな枠組みとしては Creators API
具体的なレート条件の一次情報としては PA-API 5.0 文書
ただし PA-API 5.0 文書は古い情報を含む可能性がある
現行の Associates Central ヘルプと数字が違う部分は、両方を併記する

という前提で読んでもらえればと思います。

TPS と TPD はどう違うのか

まず基本的なところからです。API の利用制限には、TPS と TPD という2つの指標があります。

指標	正式名称	意味
TPS	Transactions per second	1秒あたりに送れるリクエストの上限
TPD	Transactions per day	1日あたりに送れるリクエストの合計上限

TPS は「瞬間的にどれだけ連打できるか」の制限です。
TPD は「1日トータルで何回まで使えるか」の制限です。

たとえば初期枠だと、1 TPS / 8640 TPD です。
つまり、1秒に1回までリクエストを送れて、1日の合計は8640回まで、ということになります。

ここで意外と見落としやすいのが、8640 TPD を24時間で割ると、平均10秒に1回程度しか使えないという点です。

理屈の上では、1 TPS のペースで24時間叩き続ければ 86400回になります。
でも、初期枠の TPD は 8640回です。

なので、1 TPS のペースで送り続けると、約2時間24分で1日分を使い切ってしまいます。

新規で使い始めるときは、秒間上限よりも、日次の総量のほうが先にボトルネックになりやすいわけです。

GetItems() で10個の ASIN を送っても 1 transaction

PA-API 5.0 の API Rates では、GetItems() のリクエストパラメータに10個の ASIN を入れて送っても、それは10 transaction ではなく 1 transaction としてカウントすると説明されています。

同じ 8640 TPD の枠でも、

1回のリクエストで商品を1つずつ取得する
1回のリクエストで10個まとめて取得する

この2つでは、1日に扱える商品数が最大10倍変わります。

TPD をどう節約するかを考えるなら、まずここを押さえておくと効率がだいぶ違います。

最初の30日間に与えられる初期枠

新しく PA-API の認証情報を作成すると、最初の30日間は初期枠として 1 TPS / 8640 TPD が割り当てられます。

期間	TPS	TPD	基準
認証情報作成から30日間	1	8640	初期枠

公式の説明には「This will help you begin your integration with the API, test it out, and start building links and referring products to your readers」とあるので、この初期枠はまさに実装と動作確認、最初のリンク構築のために用意されている期間ですね。売上がゼロの段階でも API を試せるということです。

ただ、この初期枠がずっと続く前提で設計するのは避けたほうがいいと思います。公式の文言で明記されているのは「最初の30日間は初期枠がある」ことと「その後は過去30日の shipped item revenue をもとに usage limit が調整される」ことの2点です。31日目以降も初期枠が最低保証として残るとは、少なくとも公式文書では読み取れません。

31日目以降の利用枠はどう決まるか

31日目以降は、過去30日間にどれだけ shipped item revenue（発送済み売上）を生んだかで、利用枠が自動的に調整されます。しかもこの調整は毎日行われます。

まず TPD の計算はシンプルです。PA-API 5.0 の文書には「shipped item revenue が 0.05ドル増えるごとに 1 TPD」と書かれています。1ドルあたり約20 TPD 増える計算ですね。

具体的にどれくらいの売上でどれくらいの TPD になるか、目安を出すとこうなります。

過去30日の shipped item revenue	TPD の目安
10ドル	200 TPD
100ドル	2000 TPD
432ドル	8640 TPD
1000ドル	20000 TPD

初期枠と同じ 8640 TPD を維持するには、過去30日間で432ドル分の発送済み売上が必要、ということです。

一方で TPS のほうはかなり上がりにくいです。PA-API 5.0 の文書には「4320ドルごとに 1 TPS」と書かれていますけど、Associates Central のヘルプには「4600ドルごとに 1 request per second」と書かれています。

ソース	TPS が1増えるのに必要な金額
PA-API 5.0 文書「API Rates」	4320ドルごとに 1 TPS
Associates Central ヘルプ「How to Increase Your Request Rate」	4600ドルごとに 1 request per second

どちらの数字を採用するかで微妙に変わってきますけど、いずれにしても TPS を上げるにはかなりの売上規模が必要です。なお、TPS の上限は 10 TPS と明記されています。

この数字の食い違いについては、PA-API 5.0 側が古い文書である可能性を考えると、Associates Central ヘルプの 4600ドルのほうが新しい数字かもしれません。ただ断定はできないので、両方の数字を把握しておくのが安全だと思います。

shipped item revenue と qualified referring sales は別の概念

shipped item revenueとqualified referring salesの違いを比較したフラットデザインの図

ここはかなり混同しやすいところです。

用語	日本語にすると	主に使われる場面
shipped item revenue	発送済み商品の売上額	利用枠、つまり TPS / TPD の計算
qualified referring sales	条件を満たした紹介売上	APIアクセス権の維持判定

shipped item revenue は、PA-API 経由のリンクから購入された商品が実際に発送されたときの売上額です。これが TPS や TPD の計算に使われます。

qualified referring sales は、一定の条件を満たした紹介売上のことで、こちらは「APIへのアクセスを維持できるかどうか」の判定に使われます。

つまり、「利用枠がどれくらい増えるか」と「そもそも API を使い続けられるかどうか」は、見ている指標が違うわけです。

30日間の成果条件を満たさないとどうなるか

PA-API 5.0 の API Rates には、30日連続で qualified referring sales が発生しなかった場合、そのアカウントは PA-API へのアクセスを失うと書かれています。

これは「利用枠が下がる」という話ではなく、「API 自体が使えなくなる」という話です。

ただし、完全に締め出されるわけではありません。公式の説明によると、Site Stripe などの他のリンクツールは引き続き使えますし、紹介売上として認められる購入があって、その商品が発送されれば、2日以内にアクセスが復活するとされています。

また、PA-API 5.0 の Error Messages ページには AssociateEligibilityException という例外も記載されていて、「過去30日間に10件の qualified sales がないとアクセスできない」という条件も読み取れます。これは API Rates ページの「30日間売上ゼロで停止」とはニュアンスが少し違っていて、単に「ゼロでなければOK」ではなく「10件以上」という基準が存在する可能性があります。

全体の設計としては、最初は初期枠で試せる、継続利用には成果が必要、成果が長期間途切れるとアクセスが止まる、条件を満たす売上が戻れば復活する、というサイクルになっています。

売上があるのに利用枠が増えない場合

実務で結構ハマりやすいのがこのパターンです。

「売上は出ているはずなのに、API の利用枠が増えない」というケースですね。

PA-API 5.0 の API Rates では、成果を正しく帰属させるための条件として、次の点を挙げています。

PA-API が返したリンクをそのまま使うこと
URL のパラメータを勝手に編集しないこと
Associate アカウントと PA-API のアカウントが同じ Amazon アカウントで作られていること
Primary Account の認証情報でリクエストしていること
すべてのリクエストに Partner tag を含めていること

さらに、Partner tag を入れ忘れた場合は、あとから売上クレジットを遡って適用することはできないとされています。

Associates Central のヘルプでも、request rate の計算に使われるのは「PA-API が返した URL 経由の shipped revenue だけ」だと説明されています。

なので、売上はあるのに枠が増えないときは、まず次を確認したほうが原因が見つかりやすいです。

リンクを独自に加工していないか
Partner tag を全リクエストに渡しているか
Associate アカウントと API アカウントが同じ Amazon アカウントにひも付いているか
Primary Account の認証情報で運用しているか

売上金額そのものより、売上の帰属が崩れているケースを疑ったほうが早いこともあります。

Primary Account とは何か

Primary Account というのは、Associates アカウントを作成したときに使った元の Amazon アカウントのことです。メールアドレスとパスワードのセットで、要するにそのアソシエイトアカウントの「親」にあたる本体アカウントですね。API Rates の文書でもこの定義が明記されています。

PA-API のリクエストは、この Primary Account の認証情報で行う必要があります。別のアカウントの認証情報を使っていると、売上が正しく帰属されない可能性があるわけです。

なお、PA-API のアクセスが有効かどうかは、Associates Central の Tools から Product Advertising API のページに行けば確認できます。コードを書いてリクエストを投げなくても、管理画面からステータスを見られるということです。

429 TooManyRequests が返ってきたとき

429 が返ってきたら、まず最初に疑うのはレート超過です。

TPS を超えた、あるいはその日の TPD を使い切った、というパターンですね。

ただ、PA-API 5.0 の API Rates には、usage limit を超えるリクエストを送った場合、またはアクセスが revoked されている場合に 429 TooManyRequests が返ると書かれています。

Error Messages のページでも、TooManyRequestsException の HTTP ステータスコードは 429 だと案内されています。

つまり 429 は、リクエストの送りすぎだけでなく、

短時間に送りすぎている
その日の総量を使い切っている
そもそもアクセス権自体が停止されている

こうした場合にも返ってくる可能性があるわけです。

「429 が出たから、ちょっと待てば直るだろう」と安易に考えると、実はアクセス権が停止されていた、ということもあり得ます。

429 と 503、どちらが throttling を意味するのか

ここは、公式文書同士で言っていることが微妙に違うところです。

PA-API 5.0 の API Rates と Error Messages では、リクエストの throttling や usage limit の超過は 429 に紐づいています。
TooManyRequestsException のメッセージにも、request throttling によってリクエストが拒否された、という内容が書かれています。

一方で、Associates Central の「I Received an Error with My Product Advertising API Request」というヘルプページでは、503 error はリクエストを速く送りすぎて throttle されていることを意味し、1 request per second まで落とすようにと案内しています。

なので、throttling の際に必ず 429 が返る、あるいは必ず 503 が返る、とは言い切れない状態です。

実務的には、次の順番で見ていくのが手堅いと思います。

返ってきたステータスコードを見る
レスポンス本文を見る
直近の送信頻度を見る
その日の使用量を見る
Associates Central で PA-API のアクセスが有効かどうかを確認する

ステータスコードだけで原因を決めつけないほうが安全です。

エラーが出たときの確認手順

429 や 503 が返ってきてうまく動かないとき、闇雲にコードをいじるより、順番に切り分けたほうが結局は早いです。

確認する順番としては、次の流れがわかりやすいです。

1秒あたりの送信頻度が TPS を超えていないか
その日の TPD を使い切っていないか
Partner tag をすべてのリクエストに含めているか
API が返したリンクの URL を勝手に書き換えていないか
Associate アカウントと API アカウントが同じ Amazon アカウントにひも付いているか
Primary Account の認証情報を使っているか
PA-API へのアクセス自体が有効か

アクセスが有効かどうかは、Associates Central の Tools から Product Advertising API のページで確認できます。

リンクの確認については、生成したリンクや設置したリンクの URL を見て Store ID や Tracking ID を確認できます。

ただし、クリック後にリダイレクトされた最終 URL に tracking ID が見えなくても、それだけで未計測とは限らないとも説明されています。

なので、リンクが正しくタグ付けされているかどうかは、「生成した URL や設置したコードの段階」で確認するのがわかりやすいです。

実装側でやっておきたいこと

ここからは公式ドキュメントの内容そのものではなく、上限の仕組みから考えて、実務上やっておいたほうがいい対策です。

まとめ取得を活用する

GetItems() は、最大10個の ASIN をまとめて送っても 1 transaction です。

1件ずつリクエストするのと、まとめて送るのでは、TPD の消費効率が最大10倍違います。

複数商品を取得する場面では、なるべくまとめて送るようにしたほうがいいです。

キャッシュを入れる

同じ商品の情報を短時間に何度も取得すると、TPD を無駄に消費します。

商品情報がリアルタイムで秒単位に変わるわけではないので、ある程度の時間はキャッシュしておくだけで TPD の節約になります。

これは公式に「キャッシュしろ」と書いてあるわけではないです。
ただ、上限設計を考えれば自然な対応かなと思います。

なお、画像などのプロダクト広告コンテンツの保存には別途ルールがあるため、キャッシュする場合は Amazon の利用ポリシーも確認しておいたほうが安心です。

アプリ側でレート制御を組み込む

秒間の送信上限、1日の総量カウント、エラー時の再試行間隔、バックオフの仕組み。
少なくともこのあたりは、アプリケーション側で制御できるようにしておいたほうがいいです。

Associates Central のエラーに関するヘルプでも、リクエストを速く送りすぎたら 1 request per second まで落とすように案内されています。

送信頻度の管理は、実装側でかなり重要になります。

ログを残す

429 や 503 が出たとき、あるいは売上が正しく帰属しているか調べたいとき、ログがないと手がかりがありません。

最低限、次のような情報は保存しておくと、あとの調査がかなり楽になります。

リクエスト時刻
エンドポイント
Partner tag
ステータスコード
レスポンス本文
request ID

これは公式にログの保存を求めているわけではありません。
ただ、実務上はかなり助かるはずです。

よくある誤解

「1 TPS なら1日86400回使える」

使えません。

1 TPS で24時間叩き続ければ、計算上は 86400回です。
でも、初期枠の TPD は 8640回です。

つまり、日次の上限のほうが先に来ます。

「売上があれば自動的に枠が増える」

売上が PA-API 経由のリンクに正しくひも付いていなければ、枠の計算には反映されません。

リンクの加工、Partner tag の入れ忘れ、アカウントのひも付き不整合あたりが典型的な原因です。

しかも、Partner tag を入れ忘れた場合は、遡って適用できないとされています。

「429 はちょっと待てば直る」

そうとは限りません。

429 は単なる一時的な送りすぎだけでなく、アクセス権自体が停止されている場合にも返ります。

待っても直らないときは、Associates Central でアクセス状態を確認したほうがいいです。

「利用枠の話とアクセス維持の話は同じ」

別の話です。

利用枠、つまり TPS / TPD は主に shipped item revenue で計算されます。
一方、API アクセスを維持できるかどうかは qualified referring sales や qualified sales の条件が関わります。

見ている指標が違います。

まとめ

Amazon の PA-API の API Rates は、単なる技術的なスロットリングとはちょっと違います。
正しくひも付いた成果に応じて利用枠が広がり、条件を満たす紹介売上がなければアクセス自体にも影響する、という運用上の仕組みです。

最初の30日間は 1 TPS / 8640 TPD の初期枠で試せます。
ただし31日目以降は、過去30日間の shipped item revenue に応じて利用枠が見直されます。
さらに、qualified referring sales や qualified sales の条件を満たせない状態が続くと、API access を失う可能性があります。

つまり、最初は試せるけれど、その後は「API経由の売上が正しく帰属しているか」と「条件を満たす紹介売上が継続しているか」が重要になる、ということです。

参考までに。それでは！