Customer Account API に 「顧客ごと・毎分 3000 回」の上限

図解 ： Customer Account API に顧客単位のリクエスト上限（毎分 3000 回） Customer Account API / レート制限 Customer Account API に 「顧客ごと・毎分 3000 回」の上限 ストア上の顧客 1 人あたり毎分 3000 リクエストまで。全アプリで共有される上限で、既存のコストベース制限に追加して適用される。通常の購入者トラフィックなら対応不要、ただしリトライ処理は要確認。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： 2 つの制限の関係 上限を超えたときのレスポンス 変更前 vs 変更後の比較 影響範囲 やるべきこと ： リトライ処理の 3 ステップ 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか Customer Account API に 「顧客 1 人 × ストア 1 つ あたり、毎分 3000 リクエスト」 の上限が新設された。 この上限は そのストアに入っている全アプリで共有 され、既存のコストベースのレート制限に 追加で かかる。 毎分 3000 回 顧客ごと・ストアごとのリクエスト数上限。 全アプリで共有 どのアプリが投げたかに関係なく、同じ顧客・同じストアなら同じ枠を消費。 多くは対応不要 通常の購入者トラフィックはこの上限を大きく下回る想定。 2 仕組み図解 ： 2 つの制限の関係 ポイントは「共有枠」 ： 自分のアプリのリクエストが少なくても、同じ顧客に対して他のアプリも Customer Account API を呼んでいれば同じ 3000 回/分の枠を消費する。 3 上限を超えたときのレスポンス HTTP 429 Too Many Requests THROTTLED エラー エラーコードとして返る Retry-After ヘッダ 待つべき時間を通知 詳細は Customer Account API のレート制限ドキュメントを参照、と記事内で案内されている。レスポンス本文の具体的な JSON 形式は本記事に記載なし。 4 変更前 vs 変更後の比較 項目 変更前 変更後 コストベースのレート制限 あり あり 継続 顧客単位のリクエスト上限 なし 新設 毎分 3000 回 / ストア カウントの単位 — 顧客 × ストア（全アプリ合算） 超過時の挙動 — HTTP 429 ＋ THROTTLED ＋ Retry-After 開始日 / 移行期間 記載なし（記事は「now enforces」＝既に適用中という表現） 5 影響範囲 対象 ： Customer Account API を呼ぶ全アプリ どのストアでも、Customer Account API を呼んでいるアプリはすべて対象。 実害 ： ほとんどのケースで無し 通常の購入者のトラフィックは上限を十分に下回るため、多くの場合アクション不要。 現在の消費量を確認する手段（残り枠を示すヘッダ・ダッシュボード等）は本記事に記載なし。 6 やるべきこと ： リトライ処理の 3 ステップ Customer Account API を使うアプリは、リトライロジックが以下を満たしているか確認する。 1 HTTP 429 を検知する レスポンスのステータスコードで 429 を判定。 2 Retry-After を読む レスポンスヘッダから待機時間を取得。 3 待ってから再試行 Retry-After の時間だけ待ち、同じリクエストを再送。 この 3 点を満たしていれば、まれに上限に当たっても自動回復できる。 それ以外のコード変更は記事上は求められていない。 7 技術者が押さえるべき5つのポイント 1. 制限は 2 層になった 既存のコストベース制限は残ったまま、顧客単位のリクエスト数上限が上乗せ。どちらにも引っかかりうる前提で設計する。 2. 枠は他アプリと共有 自アプリだけの呼び出し量では予測しきれない。同じストアの他アプリの消費次第で 429 が返る可能性がある。 3. キーは「顧客 × ストア」 アプリ単位や IP 単位ではなく、ストア上の顧客ごとにカウントされる。1 顧客に対する一括処理・ポーリングが要注意パターン。 4. 429 は「待てば回復」の合図 THROTTLED は恒久エラーではない。即時リトライの連打ではなく Retry-After に従うことが求められている。 5. 記事に書かれていないこと 開始日・猶予期間、残り枠の確認方法、上限の引き上げ申請可否、Retry-After の値の範囲は 記載なし 。必要なら Customer Account API のレート制限ドキュメントで確認する。 8 業務に活かせる3つのユースケース USE CASE 1 既存アプリ・カスタム実装の 429 対応棚卸し 課題 Customer Account API を使った会員ページ拡張やカスタムアプリを抱えているが、リトライ処理が 429 / Retry-After に対応しているか不明。 打ち手 該当コードを洗い出し、「429 検知 → Retry-After 読み取り → 待機後に再試行」の 3 点を満たすかチェック。 効果 まれに上限へ当たった場合でも、エラー表示ではなく自動回復で済むようになる。 技術メモ HTTP クライアントの共通層に 1 か所実装すれば全呼び出しに効く。 USE CASE 2 複数アプリ併用ストアでの「API 呼び出し量」レビュー 課題 会員向け機能を複数アプリで構成しており、同じ顧客に対して各アプリが Customer Account API を呼んでいる。 打ち手 顧客アカウントページ表示時に、どのアプリが何回 API を呼ぶかを把握し、重複取得やポーリングを見直す。 効果 共有枠の無駄遣いを減らし、上限到達リスクとページ表示の遅延要因を同時に下げる。 技術メモ 枠は全アプリ共有のため、自社アプリだけ最適化しても他アプリ次第で 429 は起こりうる。リトライ実装は前提として必須。 USE CASE 3 アプリ開発・受託案件の設計レビュー項目に追加 課題 新規開発で Customer Account API を使う際、レート制限の考慮がレビュー観点から漏れがち。 打ち手 設計レビューのチェックリストに「顧客単位 3000 回/分・全アプリ共有」「429 時は Retry-After に従う」を明記。 効果 リリース後のスロットリング起因の不具合を予防し、顧客への説明根拠にもなる。 技術メモ コストベース制限も併存するため、両方の制限を前提としたテスト観点にしておく。 9 提案で使える1行サマリ 「Customer Account API に 顧客ごと毎分 3000 回・全アプリ共有 の上限が追加。 通常利用なら影響なし、 429 を検知して Retry-After だけ待って再試行 できていれば OK。」 source ： shopify.dev / changelog / per-customer-request-limit-for-the-customer-account-api 原文公開日 2026-10-07