aillmopsreliability
LLMのレート制限とリトライ設計チェックリスト｜AIアプリを落とさない運用（2026）
|
5 min read
LLMの429や一時障害は前提。タイムアウト、バックオフ、冪等性、フォールバック、コスト制御を最小のチェックリストに落とし込み、信頼性と請求事故を両方防ぐ。
目次
LLMのレート制限（429）と一時障害を、安全にリトライするには？（信頼性とコストの両立）
結論（Conclusion）
LLMプロバイダの429や一時障害は“普通に起きる”。 AIアプリ側に必要なのは場当たりではなく、再現できる運用ポリシー。
- タイムアウト
- バックオフ付きリトライ
- 冪等性（idempotency）と重複排除
- フォールバック/劣化モード
- コストのガードレール
上手くやると「遅いけど動く」。 下手にやると無限リトライ、二重実行、請求事故になる。
背景（Explanation）
LLM呼び出しの失敗はパターン化される。
- 429（rate limit）
- 5xx（プロバイダ側不調）
- タイムアウト
- ストリーミング切断
難しいのは「リトライするか」ではなく、次の事故を避けること。
- リトライ嵐（自分のリトライが障害を増幅）
- 二重実行（メール二重送信、CRM二重書き込み）
- エージェントの隠れループ（ツール側リトライ×LLM側リトライ）
- コスト暴騰（高額モデルを何度も叩く）
結局、
- 計算のリトライ（安全）
- 副作用の実行（冪等性が必要）
を分けるのが本質。
実務手順（Practical Guide）
手順1：LLM操作を分類する（5分）
各LLM呼び出しをラベル付け。
- safe to retry（純粋なテキスト生成）
- risky to retry（ツール呼び出し、DB/CRM書き込みを伴う）
ルール：
- 副作用は冪等性が保証できない限りリトライしない
手順2：タイムアウトを意図して決める（5分）
定義するもの：
- connect timeout
- total request timeout
- streaming timeout
加えて：
- max tokens
- max output size
タイムアウトがないと、キューがそのまま障害になる。
手順3：バックオフを正しく入れる（10分）
- 指数バックオフ + jitter
- 試行回数に上限
初期の目安：
- 最大試行：3
- base delay：250ms
- max delay：4s
429はできれば：
- Retry-After を尊重
- 即リトライよりキューイング
手順4：副作用を冪等にする（10分）
「何かを実行する」ステップには idempotency key を付ける。
例：
- メール送信
- チケット作成
- CRM書き込み
- 決済
最小パターン：
- request_id を idempotency key にする
- 短期のdedupeレコードを保存
dedupeできないなら、安全なリトライはできない。
手順5：フォールバック/劣化モードを用意する（5分）
- リトライ時は軽いモデルに切り替え
- よくある問い合わせはキャッシュ
- read-only（ツールOFF）
- draft mode（自動送信/自動実行しない）
目的は“予測できる挙動”。完璧な出力ではない。
手順6：コストのガードレール（5分）
リクエスト単位でログ：
- tokens_in, tokens_out
- attempts
- attemptごとのmodel
ガード例：
- 高額モデルのリトライ回数を絞る
- トークン上限
- アカウント単位のレート制限
落とし穴（Pitfalls）
- 冪等性なしでツールをリトライする
- jitterなしで同時リトライが同期する
- 絶対に成功しない4xxをリトライする
- エージェントが同じツール呼び出しを再発行する
- すべてのリトライで高額モデルを使う
チェックリスト（Checklist）
- [ ] LLM呼び出しを safe-to-retry と side-effect に分類した
- [ ] タイムアウト（connect/total/streaming）を明示した
- [ ] max tokens / output上限がある
- [ ] リトライは指数バックオフ + jitter
- [ ] 試行回数の上限がある
- [ ] 429はRetry-Afterを尊重できる
- [ ] 副作用にはidempotency keyがある
- [ ] request_idで重複排除できる
- [ ] フォールバックモデルがある
- [ ] ツールOFFの劣化モードがある
- [ ] リクエスト単位でコスト（tokens/attempts/model）をログしている
- [ ] アカウント単位の制限で悪用を抑える
FAQ
1) すべてのエラーでリトライすべき？
NO。429/5xx/タイムアウトなど一時エラーだけ。成功しない4xxはリトライしない。
2) 一番多いミスは？
冪等性なしの副作用リトライ。二重実行が起きる。
3) リトライ嵐を防ぐには？
jitter、試行上限、429はキューイングで抑える。
内部リンク（Internal links）
免責
一般的な運用ガイドです。