LLM を使ったアプリは、外部のAPIに依存し、使った分だけ課金され、ときどき混雑や障害で応答が返らない——この3つを前提に作る必要があります。デモは動いても、本番で同時アクセスが増えたり提供元が一時的に落ちたりすると簡単に崩れます。この章では「上限に当たる前に自分で制御する（レート制限）」「落ちても切り替えて止めない（フェイルオーバー）」「無駄な課金を防ぐ（コストの守り）」という、守りの設計を具体的に整理します。
Why It Breaks
そもそも、なぜ守りが要るのか。LLM の API には提供元が決めた上限があり、これを超えると 429 Too Many Requests というエラーが返ってきます。上限は主に2つの指標で測られます——RPM（1分あたりのリクエスト数）とTPM（1分あたりのトークン数＝入力＋出力の合計）。多くのプロバイダはこの上限を「累計支払額に応じたティア（段階）」で引き上げる方式を採っており、たとえば2026年時点で OpenAI は最上位ティアで非常に大きな上限を出す一方、登録直後の低いティアでは桁違いに小さい上限から始まります。Anthropic も RPM・入力TPM・出力TPM を別々に制限しており、生成量が多い用途では「出力トークン/分」が先に効いてくる、といった具合です。
FIG.1 上限を超えたリクエストは弾かれて 429 で返る——だから「当たる前に」自分で制御する
01レート制限：上限に当たる前に自分で制御する
守りの第一歩は、提供元の上限に当たる前に、自分のアプリ側で流量をコントロールすることです。上限に当たってから慌てるのではなく、当たらないように整える発想です。実務でよく使う手は次の通りです。
- キューイング：リクエストを一度待ち行列に入れ、1分あたりの送信数を上限内に収まるよう間引いて送る。突発的なアクセス集中（スパイク）を平準化できます。
- バックオフ（指数的後退）：429 が返ったら即リトライせず、待ち時間を 1秒 → 2秒 → 4秒…と倍々に伸ばして再送する。全クライアントが同時に再送して再び詰まるのを避けるため、待ち時間に少しランダムなブレ（ジッター）を足すのが定石です。
- ユーザー単位のクォータ：1人（または1組織）あたりの利用量に上限を設ける。これは「濫用・暴走を防ぐ」ためで、後述のコスト暴走対策にも直結します。
