LASSIC Media らしくメディア
レートリミット/APIスロットリング設計を外注
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- レートリミット：急増するトラフィックや不正利用からAPIを守り、利用者間で処理能力を公平に配分する仕組みです
- トークンバケット：トークンバケット・リーキーバケット・固定ウィンドウ・スライディングウィンドウでは、バーストの許容度や実装コストが異なります
- 分散環境：Redis等の共有カウンタで整合性を保つ必要があり、設計・実装・運用の各段階で外部パートナーの知見が役立ちます
※ 本記事は2026年8月時点の公式情報（省庁・公的機関・ベンダー公式ドキュメント）に基づきます。
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
目次
レートリミットとスロットリングがAPI保護に必要な理由
レートリミット（Rate Limiting）とは、一定時間内にクライアントが送信できるリクエスト数を制限し、超過分を拒否または遅延させる仕組みを指します。スロットリング（Throttling）はほぼ同義で使われますが、超過リクエストを拒否するのではなく速度を落として処理する制御を指す場合もあります。
APIを公開すると、想定を超えたトラフィックが発生する場面が生じます。キャンペーンなどによるアクセス集中、特定クライアントによる連続呼び出し、認証情報の不正利用によるスクレイピングやブルートフォース攻撃が代表的です。MDN Web Docsは、429ステータスコードの説明において、この種の制御を「レート制限」と呼んでいます*1。制限にはサーバー全体での制限とリソース単位での制限があると整理されています*1。
急増トラフィックと不正利用からシステムを守る
レートリミットの一次的な目的は、想定を超えるリクエストがバックエンドやデータベースを圧迫し、正常なユーザーへの応答が遅延・停止する事態を避けることです。1台のクライアントが短時間に大量のリクエストを送るケースでは、後続のリクエストを制限しないと、他の利用者にも影響が及びます。
不正利用の防止も重要な役割です。ログイン試行の連続実行によるパスワード推測、スクレイピングによる大量データ取得は、いずれも通常より高頻度のリクエストパターンを示します。レートリミットは、こうした挙動を検知して制限する最初の防御線になります。ただし、レートリミット単体で不正アクセスを防ぎきれるわけではありません。認証強化やWAF（Web Application Firewall、不正な攻撃を検知・遮断する仕組み）などと組み合わせる多重防御が前提になります。
公平なリソース配分とコスト保護の観点
複数の顧客・利用者が同じAPIを共有するマルチテナント構成では、特定の利用者が処理能力を占有すると、他の利用者の体験が損なわれます。利用者単位でリクエスト数の上限を設けることは、限られた計算資源を公平に配分する手段になります。
従量課金のクラウドインフラでは、リクエスト数の増加がそのままコスト増につながります。想定外のトラフィックやボットによる過剰アクセスを制限することは、システムの安定性だけでなく、インフラコストの予測可能性を保つ意味も持ちます。
トークンバケット・リーキーバケット・ウィンドウ方式の違い
レートリミットの実装には複数のアルゴリズムがあり、それぞれバーストの許容度・実装の複雑さ・メモリ使用量が異なります。代表的な4方式の特徴を整理します。
トークンバケット方式 — バーストを許容する柔軟な制御
トークンバケット方式は、一定の容量を持つ「バケツ」に一定速度でトークンを補充し、リクエストごとにトークンを1つ消費する仕組みです。バケツにトークンが残っていれば、短時間に複数のリクエストが到着してもまとめて処理できます。バーストトラフィックにある程度対応できる点が特徴です。
トークンが枯渇すると、補充されるまで新規リクエストは拒否されます。平均レートを一定に保ちながら、瞬間的な集中にも柔軟に対応したい場合に選ばれる方式です。
リーキーバケット方式 — 出力レートを一定に保つ制御
リーキーバケット方式は、リクエストを一度キューに溜め、一定速度で処理する仕組みです。「穴の空いたバケツ」に水を注ぐイメージで、注ぐ速度（リクエストの到着）が変動しても、漏れる速度（処理される速度）は一定に保たれます。
バックエンド側の処理能力を一定に保ちたい場合に適した方式です。ただしキューが満杯になった時点で以降のリクエストを破棄する必要があり、バーストへの対応力はトークンバケット方式より低くなります。
固定ウィンドウ方式 — 実装が単純だが境界に偏りが出る
固定ウィンドウ方式は、時刻を一定間隔（例えば1分ごと）で区切り、各ウィンドウ内のリクエスト数をカウントする方式です。実装が単純でカウンタの管理も容易ですが、ウィンドウの境界をまたぐ瞬間に、実質的に許容量の2倍近いリクエストが短時間に集中する可能性があります。
スライディングウィンドウ方式 — 境界の偏りを緩和する制御
スライディングウィンドウ方式は、直近の一定時間を常に移動する形で計測し、固定ウィンドウの境界問題を緩和します。前後のウィンドウの重み付け平均を使う近似的な実装や、リクエストごとのタイムスタンプを保持する厳密な実装があり、後者は計算量とメモリ使用量が増える傾向があります。
| 方式 | バーストへの対応 | 実装の複雑さ | 向いている場面 |
|---|---|---|---|
| トークンバケット | 許容しやすい。 残トークン分は即時処理できる |
中程度。 補充速度と容量の調整が必要 |
平常時は低頻度だが、 瞬間的な集中が起きるAPI |
| リーキーバケット | 抑制的。 処理速度を一定に保つ |
中程度。 キュー管理が必要 |
バックエンドの処理能力を 一定に保ちたいAPI |
| 固定ウィンドウ | 境界付近で偏りが生じやすい | 低い。 カウンタのみで実装できる |
まず簡易に制限を導入したい場合 |
| スライディングウィンドウ | 偏りを緩和できる | 高い。 厳密な実装は計算量が増える |
境界の偏りを避けたい 高精度な制御が必要な場合 |
429応答とRetry-Afterヘッダで返す設計
リクエストを制限する際、クライアントに何を返すかは設計上の重要な論点です。標準化されたステータスコードとヘッダを使うことで、クライアント側の再試行処理を予測可能にできます。
HTTP 429 Too Many Requestsの意味
HTTP 429 Too Many Requestsは、クライアントエラーを示すステータスコードです。一定時間内に多すぎるリクエストを送信した場合に返されます。RFC 6585（2012年公表）で定義され、レート制限の実装を目的としています*2。MDN Web Docsも、429はサーバー全体またはリソース単位でのレート制限に用いられると説明しています*1。制限の基準はIPアドレスのほか、認証済みリクエストであればユーザー単位にもなり得ます*1。
Retry-Afterヘッダで再試行のタイミングを伝える
429応答には、Retry-Afterヘッダを付与することが推奨されます。RFC 6585では、429のレスポンスに状況の説明と、再試行までの待機時間を示すRetry-Afterヘッダを含めるべきだとしています*2。Retry-Afterは429以外にも使われます。503 Service Unavailableやリダイレクトのレスポンスでの使用例が、MDN Web Docsに示されています*3。値の指定方法は2通りです。秒数（例：120）か、HTTP日付形式（例：Wed, 21 Oct 2015 07:28:00 GMT）のいずれかを使います*3。
Retry-Afterを付けない設計では、クライアントがそれぞれ任意の間隔で再試行を繰り返し、結果的にサーバーへの負荷が続いてしまう可能性があります。待機時間を明示することは、クライアント側の実装を単純にし、無駄な再試行を減らすことにつながります。
RateLimit系ヘッダで現在の利用状況を通知する
429を返す前の段階で、クライアントに現在の利用状況を伝える手段もあります。RateLimit-Limit・RateLimit-Remaining・RateLimit-Resetといったヘッダを使う設計が広く使われています。これらはIETFのhttpapi作業部会が「RateLimit field for HTTP」として標準化を進めているドラフト仕様に整理されています*4。2026年時点では正式なRFCではなくインターネットドラフトの段階です*4。ドラフトの目的は、レート制限のポリシーと現在のクォータ（割り当て量）をヘッダ名・意味の両面で相互運用可能な形に標準化することです*4。
正式なRFCではない点を踏まえ、外部に公開するAPIでは事前の検討が必要です。ドラフトのヘッダ名をそのまま採用するか、自社で定めた別のヘッダ名にするかを決めておきます。将来的に仕様が変更される可能性があるため、契約書やAPI仕様書には採用したバージョンを明記しておくことが望まれます。
APIゲートウェイ・アプリ層・分散環境のどこで制御するか
レートリミットをどの層で実施するかによって、実装の難易度と得られる効果が変わります。単一の層に頼るのではなく、複数の層を組み合わせる設計が一般的です。
APIゲートウェイ・ロードバランサ層での制御
APIゲートウェイやリバースプロキシの層でレートリミットを行うと、リクエストがアプリケーションサーバーに到達する前に制限できます。不正なトラフィックによるアプリケーションサーバーへの負荷を未然に防げる点が利点です。多くのマネージド型APIゲートウェイサービスには、使用量プランやスロットリングの設定機能が標準で用意されています。
アプリケーション層での制御
アプリケーションのコード内でレートリミットを実装すると、ユーザーIDやAPIキーなど、業務ロジックに即した単位での制御がしやすくなります。特定のエンドポイントだけ制限を強めたり、契約プランごとに上限を変えたりする柔軟な制御は、アプリケーション層の実装が向いています。
分散環境での共有カウンタ — Redis等の活用
サーバーを複数台に水平分割している環境では、各インスタンスがローカルにカウンタを持つだけでは、全体のリクエスト数を正しく把握できません。あるインスタンスでは制限に達していなくても、他のインスタンスと合算すると閾値を超えているケースが起こり得ます。
この課題への一般的な対応は、Redisなどのインメモリデータストアを共有カウンタとして使い、全インスタンスが同じカウント値を参照・更新する構成です。共有ストアへのアクセスが増えるため、カウンタの更新処理自体がボトルネックにならないよう、有効期限の設定やアトミックな加算処理の設計が必要になります。分散環境でのレートリミットは、単一サーバー構成よりも設計・実装の難易度が上がる領域です。
閾値設計とユーザー単位・IP単位の使い分け
レートリミットを導入する際、閾値（上限値）をどう決め、何を制限の単位にするかは、業務要件を踏まえた個別の判断が必要です。ここを誤ると、正当な利用者の体験を損ねたり、逆に不正利用を防ぎきれなかったりします。
閾値設計を誤ると起きる影響
閾値を厳しく設定しすぎると、通常の利用パターンでも制限にかかり、正当な利用者が429エラーに遭遇する頻度が増えます。特に、フロントエンドが複数のAPIを連続で呼び出す設計になっている場合、想定より早く上限に達するおそれがあります。逆に閾値が緩すぎると、不正利用や過剰なトラフィックを防ぐ効果が薄れ、レートリミットを導入した本来の目的を果たせません。閾値は、平常時のアクセスパターンを計測したうえで、余裕を持たせつつ調整する反復的な作業になります。
ユーザー単位・IPアドレス単位・APIキー単位
制限の単位には、IPアドレス単位、認証済みユーザー単位、APIキー単位などがあります。IPアドレス単位はシンプルですが、同一のNAT環境（複数端末が1つのグローバルIPを共有する環境）にいる複数の利用者が同じ制限を共有してしまう問題があります。認証済みAPIでは、ユーザーIDやAPIキー単位で制限する方が、実際の利用実態に即した公平な制御になります。
バースト許容と多重防御の考え方
短時間の一時的なアクセス集中（バースト）をどこまで許容するかも、方式選定に直結する論点です。トークンバケット方式であれば、バケツの容量を調整することでバースト許容度を制御できます。加えて、レートリミットは単独の防御策ではなく、WAF・認証強化・異常検知といった他の対策と組み合わせる多重防御の一部として位置づけることが望まれます*1。
レートリミット設計・実装を外注する範囲と発注準備
レートリミットの設計・実装をこの記事の内容だけで内製化するには、アルゴリズムの選定・分散環境での整合性担保・閾値のチューニングという複数分野の知識が必要です。1名の担当者がAPI設計とインフラの両方を短期間で習熟するのは負荷が大きく、外部パートナーの活用を検討する企業も少なくありません。
内製する場合に必要なスキルと工数
内製でレートリミットを設計・実装する場合、API設計の知識に加え、Redis等のインメモリデータストアの運用知識、分散システムでの整合性に関する理解が必要です。既存システムへの組み込みでは、既存のAPIゲートウェイやミドルウェアの設定変更も伴います。要件整理から実装・負荷試験までを通しで行うには、設計担当と実装担当を含む体制と、複数週にわたる検証期間を見込む必要があります。
外注できる範囲の整理
外部パートナーに委託できる範囲は多岐にわたります。要件定義（どのエンドポイントに・どの単位で・どの閾値を適用するか）、アルゴリズムの選定と設計、APIゲートウェイまたはアプリケーション層への実装が対象です。加えて、負荷試験による閾値の妥当性検証、本番運用後のモニタリング・チューニングも委託できます。既存システムに後付けで導入する場合は、現行アーキテクチャの調査と影響範囲の洗い出しも委託範囲に含められます。
発注前に準備しておきたい情報
発注をスムーズに進めるには、事前の情報整理が望まれます。現在のAPIのエンドポイント一覧、想定される利用者数とアクセスパターンをまとめておきます。既存のインフラ構成（単一サーバーか分散環境か）、過去に発生した過負荷やアクセス集中の事例があれば、それらも整理します。これらの情報が揃っていると、パートナー側が閾値設計やアルゴリズム選定の初期提案を具体的に行いやすくなります。
まとめ：レートリミット設計 3つの判断軸
本稿では、APIのレートリミット・スロットリング設計について、必要性からアルゴリズムの選び方、応答設計、実施する層、外注の進め方までを整理しました。要点を3つに集約すると次の通りです。第一に、レートリミットは急増トラフィックや不正利用からシステムを守り、リソースを公平に配分するための仕組みです。第二に、トークンバケット・リーキーバケット・固定ウィンドウ・スライディングウィンドウにはそれぞれ異なる特性があります。バースト許容度と実装コストのバランスで選定します。第三に、429とRetry-Afterによる標準化された応答設計、分散環境での共有カウンタ設計は専門性が高い領域です。外部パートナーへの相談によってリスクを抑えながら導入を進められます。
よくある質問
レートリミットとスロットリングは同じ意味ですか。
同じ文脈で使われることが多いですが、厳密には異なります。レートリミットは超過リクエストを拒否する制御全般を指し、スロットリングは超過分を拒否せず処理速度を落として受け付ける制御を指す場合があります。実際の実装では両者が組み合わされることも多く、文脈に応じた確認が必要です。
429エラーが返ってきた場合、クライアント側はどう対応すべきですか。
Retry-Afterヘッダが付いていれば、その秒数または日時まで待ってから再試行するのが基本です*3。ヘッダが無い場合は、一定時間ごとに再試行間隔を広げていく方式（指数バックオフ）を使うことで、サーバーへの負荷集中を避けられます。
小規模なAPIでも分散環境向けの共有カウンタは必要ですか。
サーバーが1台のみの構成であれば、アプリケーション内のメモリでカウンタを保持する簡易な実装でも機能します。将来的にサーバーを複数台に拡張する予定がある場合は、早い段階でRedis等の共有カウンタを前提にした設計にしておくと、後からの作り直しを避けられます。
レートリミットの閾値はどのくらいの頻度で見直すべきですか。
導入直後は想定と実際のアクセスパターンにずれが生じやすいため、短い間隔でのモニタリングが望まれます。429の発生率や利用者からの問い合わせを確認しながら調整し、その後はトラフィックの傾向や利用者数の変化に合わせて定期的な見直しを継続します。
外注する場合、既存のAPIゲートウェイの契約は変更が必要ですか。
既存のAPIゲートウェイにスロットリング機能が備わっていれば、設定変更のみで対応できる場合があります。機能が不足している場合や個別の制御が必要な場合は、アプリケーション層への追加実装が必要になることがあり、事前の現行構成調査で判断します。
出典
- *1 出典：MDN Web Docs「429 Too Many Requests」（Mozilla、参照2026年）https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429（2026年8月確認）
- *2 出典：IETF RFC 6585「Additional HTTP Status Codes」（2012年）https://www.rfc-editor.org/rfc/rfc6585（2026年8月確認）
- *3 出典：MDN Web Docs「Retry-After」（Mozilla、参照2026年）https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Retry-After（2026年8月確認）
- *4 出典：IETF httpapi Working Group「RateLimit header fields for HTTP（draft-ietf-httpapi-ratelimit-headers）」（Internet-Draft、2026年時点で標準化作業中）https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/（2026年8月確認）
