レート制限（429）に強いAPI連携を作る方法（リトライ/バックオフ設計）

429（Too Many Requests）とは？「APIが落ちた」ではなく「使いすぎ」のサイン

外部サービスとAPI連携をしていると、突然レスポンスにHTTP 429（Too Many Requests）が返ってきて処理が止まることがあります。これは「サーバが故障した」よりも、「一定時間内の呼び出し回数が上限を超えた」という意味合いが強いエラーです。たとえば、会計ソフト・CRM・EC・地図・SMS配信・生成AIなど、多くのSaaSは利用者全員の快適性を守るために「レート制限（Rate Limit）」を設けています。

現場では「昨日まで動いていたのに、今日は止まった」「月末の一括処理だけ失敗する」といった形で表面化しがちです。特に、情シスや業務部門主導でツールを増やした結果、バッチ処理・RPA・BI・iPaaSが同じAPIを同時に叩いてしまい、合計の呼び出し数が閾値を超えるケースがよくあります。

429が怖いのは、単に一時的な失敗にとどまらず、再実行で二重登録や二重請求などの事故につながる点です。さらに、レート制限に乱暴にぶつかり続けると、短時間のブロックや、最悪の場合はアカウント制限など運用上のトラブルへ波及します。

この記事では、専門知識が深くなくても判断できるように、レート制限に強いAPI連携を作るための基本設計（リトライ、バックオフ、キュー、冪等性、監視）を業務シーンに落として解説します。開発チームに依頼する場合の「要件の伝え方」にも使える内容にします。

なぜレート制限が起きるのか：よくある業務シーンと落とし穴

レート制限（429）が発生する背景は「呼び出し数の増加」だけではありません。多くのAPIは「1分あたりのリクエスト数」「同時接続数」「ユーザーごとの上限」「トークン（利用枠）」「特定エンドポイントの上限」など複数の制限を組み合わせています。つまり、ある画面の検索APIだけが厳しい、夜間バッチだけが危ない、といった偏りも起こります。

業務で典型的なのは次のパターンです。

• 月末・週次の一括同期：取引データや顧客データをまとめて取り込み、短時間に大量アクセスする
• 社内ツールの増殖：RPA、iPaaS、BI、スクリプトが同じAPIを別々に呼び、合算で上限超え
• リトライの暴走：失敗時に「すぐ再試行」を無限に繰り返し、さらに429を増やす
• ページネーションの過剰：一覧取得を1件ずつ繰り返すなど、設計上ムダが多い
• 並列処理のやりすぎ：処理時間短縮のために同時実行数を増やし、同時接続制限に抵触

ここで重要なのは、429は「異常」ではなく「仕様どおり」に返ってくることが多い点です。だからこそ、設計で先回りして「ぶつからない」「ぶつかっても壊れない」連携にしておく必要があります。具体的には、リトライ（再試行）とバックオフ（待ち時間の伸長）を中心に、キューイング、優先度制御、重複防止、監視までをセットで考えます。

レート制限に強い設計の全体像：リトライ/バックオフだけでは足りない

429対策というと「リトライすればいい」と思われがちですが、リトライは万能薬ではありません。誤ったリトライは、かえってアクセスを増やし、復旧を遅らせます。強いAPI連携の基本は、次の4点を揃えることです。

• 正しいリトライ：失敗の種類に応じて再試行する/しないを分ける
• バックオフ＋ジッター：待ち時間を伸ばし、さらに乱数で「同時再開」を避ける
• スロットリング（自前の流量制御）：アプリ側で「上限以内」に抑える
• 冪等性（同じ処理を繰り返しても結果が壊れない）：再試行しても二重登録にならない

これに加えて、実務では「キュー（順番待ち）」が効きます。たとえば、注文作成や請求書発行のように“必ず処理したい”ものは、即時に外部APIへ投げるのではなく、いったんキューに入れて順番に送ると安定します。キューがあると、ピーク（瞬間風速）を平準化できるため、レート制限に当たりにくくなります。

また、API提供側が返すヘッダー（例：残り回数、リセット時間、Retry-After）を見られる場合は、それを優先して従うのが鉄則です。仕様に沿うほど安定し、運用コストも下がります。つまり、設計のポイントは「根性で叩かない」「相手の合図に従う」「失敗しても壊れない」の3つに集約できます。

実装の要点：リトライ/バックオフ（指数＋ジッター）と「再試行すべき/すべきでない」判断

まず整理したいのは、「失敗したら何でも再試行」ではないことです。たとえば認証エラー（401/403）をリトライしても治りませんし、入力が不正（400）なら同じデータで再試行するほど無駄です。一方、429や一時的なサーバ都合（多くは5xx）は、時間を置けば成功する可能性が高い典型です。

一般的な判断の目安は次の通りです（APIごとの仕様が最優先です）。

• リトライ推奨：429、502、503、504、ネットワークタイムアウトなど
• 原則リトライ不要：400、401、403、404（仕様次第）、422など

リトライの設計で特に重要なのがバックオフです。最もよく使われるのは「指数バックオフ（Exponential Backoff）」で、1回目は1秒、2回目は2秒、3回目は4秒…のように待ち時間を増やします。さらに「ジッター（Jitter）」という乱数を混ぜて、複数の処理が同時に再開して再び429を誘発する“群れ”を防ぎます。

さらに、429で提供側がRetry-Afterを返す場合は、それに従います。指数バックオフよりも優先です。これがあるのに無視すると、再試行が早すぎて失敗を重ねる原因になります。

最後に「いつ諦めるか」も重要です。無限リトライは、システムを“終わらない処理”で詰まらせます。業務影響を減らすには、最大リトライ回数に達したら「失敗としてキューに戻して後で再実行」「担当者に通知して手動確認」「処理を保留し次のデータへ進む」など、業務に合わせた逃がし方を決めます。“諦め方”も設計の一部です。

安定運用の鍵：スロットリング、キュー、優先度、そして「冪等性」で二重計上を防ぐ

リトライ/バックオフは「当たってしまった後の回復策」です。そもそも当たりにくくするには、アプリ側で流量を絞るスロットリング（レート制御）が効きます。たとえば「1秒に5件まで」「同時実行は2つまで」といった上限をアプリ側に設け、上限を超えた分は待たせます。これだけで429が激減することがあります。

次に、キュー（ジョブキュー）を入れると、処理を“ためて順番に流す”ことができます。業務で例えるなら、レジが混んだときに行列を作ってさばくイメージです。行列がないと、店内がパンクします。API連携も同じで、ピークを平準化する仕組みがあると、月末や朝一の集中にも耐えやすくなります。

さらに実務では優先度が重要です。たとえば「顧客が今まさに画面で実行している処理（リアルタイム）」と「夜間の一括同期（バッチ）」を同列に扱うと、バッチが枠を使い切ってリアルタイムが止まる、という事故が起こります。キューに優先度を持たせ、“今必要な処理が先に通る”ようにすると、ユーザー体験が安定します。

そして最重要の守りが冪等性（べきとうせい）です。これは「同じリクエストを複数回送っても結果が1回分に収まる」性質のこと。非エンジニア向けに言うなら、通信が不安定で同じボタンを2回押してしまっても、請求書が2枚発行されない仕組みです。冪等性を作る方法は複数あります。

• 冪等キー（Idempotency Key）：同じキーなら同じ結果を返す（APIが対応している場合）
• 外部IDの固定：自社側の注文IDなどを外部にも保存し、重複作成を防ぐ
• Upsert（更新/作成の統合）：「なければ作る、あれば更新」で二重作成を避ける
• 結果の記録（送信ログ）：成功済みを保存し、再送時はスキップ

429対策は、単にエラーを減らすだけでなく、二重登録・二重請求のリスクを下げる意味でも投資価値があります。特に予算がある企業ほど、後工程（監査、返金、顧客対応）のコストが膨らみやすいため、早めに“壊れない連携”を作っておくと結果的に安くつきます。

導入手順：仕様確認→設計→テスト→監視まで（情シス/発注側のチェックリスト）

ここからは、開発を内製する場合も、ベンダーに依頼する場合も使える手順に落とします。ポイントは「429が起きたときの挙動」を、実装前に言語化して合意しておくことです。

仕様確認（最初にここを押さえる）

• レート制限の単位：秒/分/日、ユーザー単位かIP単位か
• 上限の種類：回数、同時接続、トークン制など
• 429時の情報：Retry-Afterヘッダーの有無、リセット時刻の通知有無
• 推奨されるリトライ方式：公式ドキュメントの推奨値

これが曖昧だと、運用開始後に「想定より厳しかった」が起きます。SaaSによってはプランで上限が変わるため、契約プランと上限の整合も重要です。

設計（“待たせ方”と“諦め方”を決める）

• リトライ対象コードと、最大リトライ回数
• バックオフ方式（指数＋ジッター）と待ち時間の上限
• スロットリング（例：毎秒N件、同時M件）
• キューの有無、優先度、デッドレター（失敗の退避先）
• 冪等性の担保方法（冪等キー、外部ID、ログなど）

ここで発注側（情シス/業務側）が確認したいのは、「失敗したらどうなるか」が一枚の図で説明できるかどうかです。ブラックボックスのまま進めると、障害対応時に判断が遅れます。

テスト（“月末相当”を再現する）

テストでは、通常時の疎なアクセスだけでなく、月末・移行・一括同期のようなピークを再現します。たとえば“1000件を一気に送る”“同時に3ツールが動く”を想定し、429が出たときにバックオフが効いて最終的に収束するか、処理が詰まらないかを確認します。可能ならステージング環境で制限を意図的に厳しくして試すと、設計の弱点が見つかります。

監視と運用（気づける仕組みを作る）

最後に、429は“起きない”より“起きても気づける”が大切です。監視の指標としては、429の件数、リトライ回数、キュー滞留数、処理の遅延時間（何分遅れているか）を最低限追います。特にキュー滞留が増え続けるのは危険信号で、放置すると翌営業日に未処理が雪だるま式に残ります。「止まった」ではなく「遅れている」を検知できると、業務への影響を事前に抑えられます。

まとめ

レート制限（429）は、外部APIを使う以上「いつかは起きる」前提で設計しておくべき事象です。場当たり的に再実行するのではなく、リトライ対象の見極め、指数バックオフ＋ジッター、スロットリング、キュー、冪等性、監視をセットで整えることで、月末の集中やツール増加にも耐えられるAPI連携になります。

情シス・業務側の立場では、「429時に何回まで・何秒待って・最終的にどう扱うか」「二重登録をどう防ぐか」「遅延をどう検知するか」を要件として明文化するのが成功の近道です。これができると、開発会社との認識違いが減り、運用コストも下がります。