Leadde Logo

APIレート制限の理解

APIレート制限とは何か、なぜ実装されるのか、よくあるリトライの誤り、そして指数バックオフのような効果的なパターンについて、簡潔に解説します。
L作成者 Leadde 更新日 2026年8月22日

レート制限がリクエストの実行をどう左右するか

レート制限は、クライアントが一定期間内に送信できるリクエスト数に上限を設け、超過すると429エラーを返します。これは、特定のクライアントによる共有リソースの独占を防ぐためです。したがって、正しい対応は、すぐに再送するのではなく、処理速度を落とすことです。

しかし、多くの初期統合では、すぐにリトライしてしまいます。これは一時的な拒否を永続的な問題に変えてしまう行為です。クライアントは制限に達し、リトライすることで測定期間を延長し、結果として本来必要な時間よりもはるかに長くスロットリングされます。その間、開発者はAPIが信頼できないと判断しがちです。なお、お客様独自の制限設定(ティアごとのしきい値、バースト許容量、より厳しい上限を持つエンドポイントなど)は、時間の経過とともに古くなる動画ではなく、バージョン管理されたドキュメントに記載すべき情報であるため、本コンテンツでは意図的に除外しています。

このテンプレートでは、1つのリクエストを8つのシーンで追跡します。具体的には、制限が存在する理由、測定期間とそのカウント方法、429応答の内容、バックオフと遅延を増やす理由(2シーン)、ジッターとサンダリングハード、レート制限ヘッダーの読み方、そして制限にほとんど達しない設計方法について解説します。

2分でわかるバックオフの解説方法

開発者向けの教育コンテンツは、視聴者がすでに参照しているドキュメントとの競合に直面します。リファレンスページの焼き直しでは20秒と持たず閉じられてしまうでしょう。このモジュールは、ドキュメントでは伝えにくい「失敗パターン」に焦点を当て、パラメータではなく、その本質を伝えます。

解決策の前に「リトライストーム」を視覚化

解決策の前に「リトライストーム」を視覚化

すでに制限を超過しているにもかかわらず、200ミリ秒ごとにリトライを繰り返すクライアントの状況は、問題の核心を1つのシーンで明確に示します。これにより、バックオフは単なる推奨ではなく、明白な解決策として提示されるでしょう。

倍増のロジックを明確に

1秒、2秒、4秒、8秒。この具体的な進行を示すことは、指数バックオフの定義を説明するよりも迅速かつ効果的であり、開発者が実際に実装する内容そのものです。

ジッターの重要性を強調

ランダム化がなければ、スロットリングされたすべてのクライアントが同時にリトライし、復旧の試みが新たな障害を引き起こします。これは多くの統合で見落とされがちな点であり、このモジュールが存在する重要な理由です。

数値ではなくヘッダーに注目

制限値は変化しますが、それを報告するヘッダーは変わりません。クライアントに、伝えられた情報を読み取るよう教えることは、次の四半期には誤りとなるしきい値をハードコーディングするよりもはるかに効果的です。

既存のAPIドキュメントからコンテンツを生成

APIドキュメント、パートナー向け統合ガイド、または前回のオンボーディングで発生したサポートチケットをアップロードしてください。最大200MBまで、PDF、DOC、DOCX、PPTX、TXT形式に対応しています。生成されたシーンは編集可能で、元のドキュメントは一切変更されません。

自社APIへの最適化

画面に自社独自のヘッダー名を表示

画面に自社独自のヘッダー名を表示

ヘッダーの命名規則はプラットフォームごとに異なります。一般的な例を見せられても、開発者は結局自社のものを探しに行く手間が発生します。実際のヘッダー名をシーンに表示することで、この手間を省き、よりスムーズな理解を促します。

度重なる違反後の結果を明示

度重なる違反後の結果を明示

プラットフォームによっては、スロットリング、キーの停止、あるいは担当者への通知など、対応が異なります。結果を明確に伝えることで、パートナーがガイダンスをどれだけ真剣に受け止めるかが大きく変わるでしょう。

正確な読み取りが必要な用語のキャプションを調整

正確な読み取りが必要な用語のキャプションを調整

ステータスコード、ヘッダー名、パラメータ値は聞き間違いやすく、正確な読み取りが不可欠です。9種類の字幕スタイルから選択し、開発者シリーズ全体で統一することで、コード用語が小さな画面でも判読性を保つようにしましょう。

APIレート制限 FAQ

レート制限は、通常数秒から1分といった短い期間の処理速度を管理し、待機することで回復可能です。一方、クォータは請求期間全体の総量を管理するため、待っても回復しません。これらを混同すると、クライアントは増量を要求すべき状況でバックオフしてしまう可能性があります。

もし提供されていれば、`retry-after` の値を読み取り、少なくともその期間待機してください。その後、失敗が続くたびに遅延時間を長くしてリトライします。すぐに、または固定された短い間隔でリトライすると、スロットリングが解消されるどころか、かえって延長されてしまいます。

エンドポイント名は問題ありません。むしろモジュールをより有用なものにします。しかし、キーやトークン(期限切れのものも含む)は使用しないでください。トレーニングビデオは作成されたパートナー以外にも流通する可能性があり、資格情報よりもはるかに長く残存するためです。

ほとんどの実装では、失敗したリクエストも期間内のカウント対象となるためです。リトライするたびにクライアントは上限をさらに超えてしまい、待機を避けようとする試みが、かえって解消に必要な待機時間を長くしてしまいます。

本番環境で問題になる前に、自らスロットリングを

すでに公開しているAPIドキュメントを本ツールで処理し、次のパートナー統合が始まる前にシーンを調整しましょう。

avatar

このテンプレートから始めて、共有可能な動画を完成させましょう。

オンボーディングガイドやヘルプセンターページを追加すれば、数分で編集可能な下書きが生成されます。