APIを触っていると、ある日突然「429 Too Many Requests」などのエラーが出て困った経験はありませんか？
しかも調べてみると「スロットリング」「レートリミット」という似た言葉が出てきて、余計に混乱しがちです。
実はこの2つ、概念としては違いがあるものの、現場ではわりと雑に同じ意味で使われているケースもあります。特にクラウドサービスの設定画面では、「スロットリング」と書かれていても中身はレートリミットに近い動きをしていることが普通にあります。
この記事では、理解できるように噛み砕きつつ、
- スロットリングとレートリミットの一般的な違い
- 実装によって意味がズレる理由
- エラーになる場合・ならない場合の違い（トークンバケットなど）
をセットで整理していきます。
スロットリングとレートリミットは「似ているけどズレる」
最初に結論をざっくり言うと、スロットリングとレートリミットはこういう関係です。
- レートリミット：一定時間あたりの回数制限（ルールで決める）
- スロットリング：混雑や負荷に応じて流量を調整する（状況で調整する）
ただし、ここが重要なポイントです。
現場ではこの2つを厳密に区別せず、同じ意味で使っているサービスもかなり多いです。
つまり「理論上は違うけど、実装では混ざっている」ことがあるんですね。
なぜ混ざるのか（例：クラウドサービス）
たとえばAWSのAPI Gatewayには「スロットリング設定」という項目があります。
名前はスロットリングですが、実際の動きは「1秒あたり○リクエストまで」といったレートリミット的な挙動です。
こういうケースがあるので、
スロットリングとレートリミットの違いは一般的な概念の整理であり、サービスによって呼び方がズレることがある
という前提を持っておくと、かなり混乱しにくくなります。
それぞれの考え方をもう少し丁寧に
レートリミットとは（回数制限の仕組み）
レートリミットは、一定時間あたりのリクエスト数を制限する仕組みです。
例としてはこんな感じです。
- 1分間に60回まで
- 1秒あたり10回まで
- 1時間に1000回まで
これは「ルールで決めた上限を超えたら制限する」仕組みです。
システムが空いていようが混んでいようが、制限値を超えたら止める、というのが基本形です。
レートリミットがある理由
レートリミットが導入される理由はシンプルで、主に次のような目的があります。
- 過剰アクセス（意図しない連打）を防ぐ
- 悪意あるアクセス（DoS的な攻撃）を防ぐ
- 無料ユーザーと有料ユーザーで公平性を保つ
- API提供側のコスト増大を抑える
特に外部向けAPIでは、ほぼ必須の仕組みになっています。
スロットリングとは（状況に応じた流量調整）
スロットリングは、システムの状態を見ながら処理を制御する仕組みです。
イメージとしては「混んできたらブレーキを踏む」ようなものです。
例えば、次のような状況がトリガーになります。
- CPU使用率が高い
- DBの接続が限界に近い
- 同時処理が増えすぎてレスポンスが悪化している
このとき、リクエストを全部処理しようとするとシステムが耐えきれず落ちるので、あえて速度を落としたり、一部を拒否したりします。
つまりスロットリングは、サービス全体を落とさないための安全装置として働きます。
ただし「スロットリング」という言葉は実装で意味がズレる
ここが今回の重要ポイントです。
現場では「スロットリング」という言葉が、次の2パターンで使われることがあります。
- 負荷状況に応じて調整する（本来の意味）
- 1秒あたり○回までの制限をかける（実質レートリミット）
後者は「レートリミットじゃん」と思うのですが、UIやドキュメントではスロットリングと呼ばれていることがあります。
このため、実務では言葉だけで判断せず、
- どういう単位で制限しているのか
- リクエストが超過したときに何が起きるのか
を確認するのが大事です。
エラー動作のバリエーション：超えたら即エラーとは限らない
初心者が一番つまずきやすいのがここです。
「レートリミット＝超えたら即429エラー」と思われがちですが、最近は必ずしもそうではありません。
制限のかけ方（アルゴリズム）によって挙動が変わります。
パターン1：超過したら拒否する（即エラー）
これは一番分かりやすい挙動です。
- 上限を超えたリクエストは拒否する
- HTTP 429を返す
- 「Retry-After」ヘッダで待つ秒数を返すこともある
外部APIでよく見る典型パターンですね。
パターン2：待たせる（遅延応答する）
最近増えているのがこちらです。
上限を超えたら即エラーにするのではなく、処理の順番待ちをさせる方式です。
つまり、ユーザーから見ると「エラーではないけど遅い」状態になります。
これはシステム側でキューを持ち、リクエストを溜めて順番に処理するような設計でよく使われます。
パターン3：トークンバケット方式（バーストを許容する）
ここでよく出てくるのがトークンバケット方式です。
トークンバケット方式は、例えるなら「ポイント制の入場券」のような仕組みです。
- バケット（箱）にトークンが貯まる
- リクエストするたびにトークンを消費する
- トークンは一定速度で補充される
- トークンが残っていれば短時間に連続アクセス（バースト）できる
たとえば、
- 普段は1秒に10個トークンが増える
- 最大100個まで貯められる
という設定なら、普段アクセスしていなければトークンが貯まり、急に100回連続で叩いても耐えられる、という動きになります。
つまり「平均的には制限するけど、一時的な集中は許す」仕組みです。
この方式の場合、超過時に即エラーになるとは限らず、
- トークンが補充されるまで待たされる
- 少し遅延して返ってくる
といった挙動になることがあります。
パターン4：リーキーバケット方式（一定速度で流す）
リーキーバケット方式もよく使われます。
こちらはイメージとしては「穴の空いたバケツ」です。
- リクエストはバケツに溜まる
- バケツの穴から一定速度で流れていく（一定速度で処理される）
- バケツが溢れたら拒否される
つまり、急に大量アクセスが来ても処理速度を一定に保てるので、システムが安定しやすいのが特徴です。
この方式も、状況によっては「すぐエラーになる」より「待たされる」挙動になります。
実務でのポイント：現場で役立つ考え方
「用語の定義」より「挙動」を見た方が安全
実務で一番ありがちな落とし穴はこれです。
「このサービスはスロットリングって書いてあるから、負荷に応じて調整されるんだろう」
と思っていたら、実際には単純なレートリミットだった。
あるいは逆に、
「レートリミットだから超えたら即エラーだろう」
と思っていたら、裏で待たされてタイムアウトが増えるタイプだった。
なので実務では、用語の定義よりも次を確認するのが確実です。
- 制限の単位（秒あたり？分あたり？）
- 超過時のレスポンス（429？遅延？キュー？）
- バースト（短期集中）が許されるか
- リトライすれば回復するか
言葉に振り回されず「仕様と実測を見る」のが一番強いです。
クライアント側で意識すべき実装
APIを叩く側（クライアント側）では、次の実装がかなり重要です。
1. リトライは「一定間隔」ではなく「指数バックオフ」
例えば失敗したからといって、0.5秒おきに連打すると逆効果です。
制限をさらに悪化させます。
そこで使われるのが指数バックオフです。
- 1回目：1秒待つ
- 2回目：2秒待つ
- 3回目：4秒待つ
- 4回目：8秒待つ
というように、待ち時間を増やしていく方法です。
この方式はレートリミットでもスロットリングでも有効で、API提供側にも優しい動きになります。
2. バッチ処理は分割する
データ移行や一括処理をするとき、つい大量のAPIリクエストを一気に投げたくなりますが、これは制限に引っかかりやすいです。
- 1000件まとめて処理する
- ではなく、100件ずつに分ける
- さらに一定間隔を空ける
こうするだけで、安定性が一気に上がります。
3. キュー設計で「平準化」する
本格的なシステムでは、アクセスを平準化するためにキューを挟む設計もよく使われます。
- ユーザー操作 → 即API呼び出し
- ではなく、キューに積む
- ワーカーが一定速度で処理する
この設計にすると、急なアクセス増でもシステムが崩れにくくなります。
サーバー側での設計ポイント
API提供側、つまりサーバー側で考えるなら、次の観点が大切です。
- サービス全体を落としたくない（守りたい）
- でもユーザー体験はできるだけ壊したくない
このバランスを取るために、単純な拒否だけでなく、
- バースト許容（トークンバケット）
- キューイング（待たせる）
- 優先度制御（有料ユーザーを優先する）
などが使われます。
ここまでくると、もはや「レートリミットかスロットリングか」という言葉遊びより、設計の目的と仕組みが重要になります。
一問一答：現場でよくある疑問
- スロットリングとレートリミットは同義なの？
-
概念としては違いますが、サービスや現場によって同義で使われることも多いです。特にクラウドの設定項目では「スロットリング」と書かれていても、実際にはレートリミット的な制限のことがあります。
- レートリミットに引っかかったら必ず429になる？
-
必ずではありません。超過したら拒否する設計もありますが、トークンバケット方式やリーキーバケット方式では「待たされる」「遅延応答になる」ケースもあります。
- スロットリングはどんなときに発生しやすい？
-
アクセスが急増したとき、DBが重くなったとき、CPUが逼迫したときなど、システム負荷が高まったタイミングで発生しやすいです。エラーではなくレスポンス遅延として現れることもあります。
- 対策として一番重要なのは？
-
クライアント側なら「指数バックオフ付きのリトライ」を入れることが効果的です。また、バッチ処理は一気に投げず分割し、一定速度で流すようにするのが安全です。
まとめ
スロットリングとレートリミットは、どちらも「システムを守るための制限」ですが、一般的な概念としては違いがあります。
- レートリミット：一定時間あたりの回数を制限する（ルール型）
- スロットリング：負荷状況に応じて流量を調整する（状況対応型）
ただし実務では、この2つは厳密に区別されず、サービスによって呼び方が混ざっていることもあります。
そのため「言葉の定義」よりも「実際にどういう挙動をするのか」を確認するのが重要です。
また、レートリミット超過時の挙動は必ずしもエラー返却とは限りません。トークンバケット方式やリーキーバケット方式では、短期的な集中アクセスを許容したり、一定時間待たせたりする実装もあります。
APIを扱う上で大事なのは、制限を敵だと思わないことです。
むしろ、制限があるからこそサービスは安定して動き続けられます。
仕組みを理解しておけば、エラー対応も設計も一段ラクになるので、ぜひこの機会に「制限の正体」を押さえておきましょう。
