Customer Account API レート制限強化の全解説

11月 02, 2026

CUSTOMER ACCOUNTS

Customer Account API
顧客単位レート制限完全解説

3,000 req/min per customer — 全アプリ共有で適用、リトライ実装を今すぐ確認

Customer Account APIを利用するすべてのアプリが対象。2026年10月7日以降、同一顧客・同一ストアへのリクエストは全アプリ合算で1分あたり3,000件を上限とする新しいレート制限が適用される。通常の購買行動では上限を下回るケースがほとんどだが、リトライロジックの実装確認を推奨する。

1変更内容のBefore / After 図解

2業務に活かせる具体ユースケース 3選

課題: マイページ機能を複数のサードパーティアプリ（ポイント・注文履歴・レビュー等）で実装しており、同一ページの読み込み時に各アプリが並行してCustomer Account APIを叩いている。
打ち手: 各アプリのリクエスト実装にHTTP 429検知とRetry-Afterに基づく待機処理を追加し、ページ描画のウォーターフォールを最適化してバースト回避の分散タイミングを設定する。
効果: 429エラーによるマイページ表示崩れや白画面を防止し、顧客体験を保護できる。
技術メモ: リミットは「全アプリ合算」のため、1アプリが消費した枠は他アプリにも影響する。アプリ数が多いほど注意が必要。

課題: バッチ処理的に顧客データを取得するバックエンドジョブが、特定顧客のセッション中に大量リクエストを集中させてしまうケースがある。
打ち手: バックエンドのバッチ処理はCustomer Account APIではなくAdmin APIを活用する設計に見直し、Customer Account APIはフロントエンドの顧客操作に限定する。
効果: 顧客の能動的なリクエストに制限枠を温存でき、UXへの影響ゼロを担保しやすくなる。
技術メモ: 元記事では「通常の購買トラフィックは上限をはるかに下回る」と明記。バッチ的ユースケースがある場合は設計を再点検すること。

課題: 新規開発中のカスタムアカウントページアプリで、リトライ処理が未実装のまま本番リリースを控えている。
打ち手: 本番前にHTTP 429レスポンスを検知するロジックを実装し、Retry-Afterヘッダーの秒数だけ待機したうえで再試行するコードをリリースチェックリストに追加する。
効果: 429発生時でも自動リカバリーが機能し、顧客には透過的にサービスが継続される。
技術メモ: Retry-Afterはレスポンスヘッダーに含まれる。待機秒数を固定値でハードコードせず、必ずヘッダー値を読み取って動的に設定すること。

3技術者向けポイント 5項目

📋 制限の仕様

上限: 3,000 req/分
単位: 顧客 × ストア
スコープ: 全インストール済みアプリ合算
既存のコストベース制限に追加される（代替ではない）

🚨 エラーレスポンス

HTTPステータス: 429 Too Many Requests
エラーコード: THROTTLED
待機ヘッダー: Retry-After（秒数）
他のGraphQLエラーと同様に errors フィールドで返る

🔄 推奨リトライ実装

HTTP 429を検知
Retry-Afterヘッダーの値を読む
指定秒数待機
同一リクエストを再送

📦 対象・非対象

✅ 対象: Customer Account API呼び出し全アプリ
✅ プラン問わず適用
⬜ Admin API: 対象外（別途制限あり）
⬜ Storefront API: 対象外

📅 移行・対応の優先度判断

状況	対応要否
通常の購買フロー内でAPIを呼ぶ	対応不要
429ハンドリングが未実装	要対応
複数アプリを同一ストアに導入済み	影響確認推奨
バースト的リクエストを送る設計	要設計見直し