LLM APIのリトライ・タイムアウト・冪等性設計｜本番運用で崩さない基本パターン

この記事でわかること

• LLM APIのエラーコード別リトライ可否と待ち時間の基本ルール
• タイムアウト、指数バックオフ、冪等性、サーキットブレーカーの設計要点
• ストリーミング応答が途中で切れたときのリカバリ判断
• 運用開始後に必ず見るべき指標と、採用しないほうがよい設計

結論サマリー

まず、LLM APIの応答種別ごとの基本対応を整理します。

Anthropic公式は「429ではretry-afterに従う」「529はレート制限ではなく容量制約」と明記しています。まずこの区別が運用の起点になります。

※本記事のAPI仕様への言及は2026年8月26日時点の各社公開情報を基にしています。LLM関連サービスの料金、エラー仕様、レート制限は変更される場合があります。導入前に公式情報で最新条件を確認してください。

LLM APIリトライ設計の基本用語を整理する

はじめに、本記事で扱う用語を最短で押さえます。

用語がそろえば、あとは「どのエラーで、どれを、どの順で使うか」だけです。

なぜLLM APIでリトライ設計が本番運用を左右するのか

LLM APIは通常のWeb APIよりリトライ設計の失敗コストが高いです。理由は3つあります。

1つ目は課金がトークン単位で発生することです。無邪気なリトライは1リクエストで数倍の費用を生みます。

2つ目は長時間の応答生成です。生成中断や途中リトライは、待ち時間もコストも二重になります。

3つ目はレート制限が厳しめに設計されている点です。429を無視して再送すると、アカウント単位でさらに長時間ブロックされる可能性があります。

判断軸：LLM APIのリトライ戦略はどう選ぶか

エラー種別と業務条件で決めます。単一のリトライ方針では守れません。

上の表は、LLMアプリのSLO（サービス品質目標）と月次コストに直結します。設計時に必ず1回は埋めておきます。

実装で確認すべき項目

コードに落とす順番を、優先度順に並べます。

タイムアウトを3層に分けて設計する

タイムアウトを単一値にしないでください。次の3層に分けます。

• 接続タイムアウト：サーバーへ接続開始できるまでの上限
• 読み取りタイムアウト：応答データが届く間隔の上限
• 全体タイムアウト：1リクエスト全体の上限

長文生成やRAG（社内文書などを検索してLLMに渡す方式）併用では、全体タイムアウトを長め、読み取りタイムアウトを短めに設定すると、詰まりの原因を切り分けやすくなります。

指数バックオフにジッターを必ず加える

固定間隔のリトライは、複数クライアントの再試行が同時に発生します。これは提供側にとって攻撃と同じ形になります。

• 初回待ちは1〜2秒程度から始める
• 毎回2倍程度に伸ばす
• 各回の待ち時間に±20〜50%の乱数を加える
• 最大待ち時間の上限を決める（例：60秒）

Anthropicは「Retry-After → レート制限リセットヘッダー → ジッター付き指数バックオフ」の順で判断することを推奨しています。

冪等性を書き込み系で必ず担保する

LLM API呼び出し自体は基本的に副作用がありません。しかし、応答をDBやSlackへ書き込む処理はリトライで重複します。

書き込み系の冪等性チェックポイント：

• リクエストごとに一意の冪等キー（UUIDなど）を発行する
• 冪等キーで既存の書き込み結果を検索してから書く
• 主要API（決済、注文、通知）は提供元の冪等キー仕様に従う
• OpenAI公式SDKは自動で冪等ヘッダーを付ける実装がある

冪等性が担保できないなら、そもそもリトライしない選択も正しい設計です。

ストリーミング応答の途中断は状態で判断する

ストリーミング応答の途中断は、単純にリトライしてよい場合と悪い場合があります。

• 出力を画面表示だけしている段階：リトライしてよい
• 出力を随時DBやツール実行に流している段階：巻き戻し設計が必要
• ツール呼び出し途中：ツールが冪等でない限りリトライ禁止

途中まで書き出したトークンをどう扱うかを、UI仕様とDB書き込みの両面で決めておく必要があります。

サーキットブレーカーで系全体を守る

上流のLLM APIが長時間不安定なとき、リトライを続けると自社側のスレッドが枯渇します。

• 直近N分のエラー率が閾値を超えたら、一定時間呼び出しを止める
• 停止中はキャッシュや代替モデルで縮退運用する
• 定期的にプローブリクエストで復旧を確認する
• 停止と復旧を運用アラートに流す

サーキットブレーカーは「上流の障害を自系の障害にしない」ための仕組みです。

観測指標を最初から埋め込む

観測なしのリトライは、後で必ず事故になります。最初から次の指標を出します。

〖注意喚起〗リスクと限界

リトライ設計は「入れれば安心」ではありません。逆に事故を増やす典型パターンがあります。

• Retry-Afterを無視した即時再送は、アカウント単位で長時間の追加ブロックを招く可能性があります
• 冪等性なしの書き込み系リトライは、決済重複、通知連投、DB二重登録の原因になります
• タイムアウトが長すぎると、ユーザーが待ち続け、スレッドが詰まって全リクエストが遅延します
• タイムアウトが短すぎると、完了直前で切断され、コストだけ発生します
• 最大リトライ回数を決めないと、上流障害時に指数関数的な呼び出し爆発を起こします

注意
エラー種別、レート制限、Retry-Afterの返却条件は各社ドキュメントで異なります。必ず提供元の最新公式仕様を確認してから実装してください。

Blackfordの見解：LLMリトライ設計は業務・データ・運用責任の3点で設計する

LLM APIのリトライ設計は、単なるHTTPリトライ設計ではありません。生成AI固有の課金、体感待ち、ストリーミング、モデル切替を業務要件に接続する必要があります。

Blackford Technologiesでは、次の観点で個別設計しています。

• 業務課題：どの処理を失敗させてよくないか、どれは縮退で許容するか
• 扱うデータ：機密度と冪等性の担保方法
• 評価指標：エラー率、リトライ率、コスト、応答時間の目標値
• コスト上限：月次のトークン上限とリトライ由来コストの許容範囲
• セキュリティ要件：外部送信可否、監査ログ、代替モデル選択条件
• 運用責任者：アラート受信、サーキットブレーカー解除、コスト超過対応
• 既存クラウドとの接続：VPC内推論、閉域構成、代替LLM経路の設計

社内データを扱うRAGや業務AIアプリでは、DataRoidやDataRoid Cloudのようなデータ基盤側で、リトライ・キャッシュ・冪等性を運用しやすい形に設計します。個別のLLMアプリ実装や本番リトライ設計の相談はAI開発・実装サービスから進められます。

よくある質問

LLM APIで429が返ったら、何秒待てばよいですか？

まずRetry-Afterヘッダーの値に従うのが基本です。Retry-Afterがない場合は、指数バックオフとジッターで待ちます。早めの再送はサーバー側で追加ブロックの対象になる可能性があるため避けます。

リトライは何回までにすべきですか？

一般的には最大3〜5回、合計待ち時間で60秒程度が目安です。ユーザーが待つ画面上のリクエストは短めに、バッチ処理は長めに設定します。停止条件を決めない設計は事故の原因になります。

ストリーミング応答が途中で切れたときはリトライしてよいですか？

出力をDBに書き込む処理やツール実行に流している場合は、単純リトライは危険です。書き込みの巻き戻しか冪等性設計が必要です。純粋に画面表示だけなら、続きから再生成するプロンプト再送で対応できます。

冪等性キーはLLM APIでも必要ですか？

LLM生成そのものより、生成結果を書き込むDB、決済、通知APIで必須です。OpenAI公式SDKなど一部はSDKレベルで冪等ヘッダーを自動付与しますが、業務側の書き込み処理は自前の冪等キーが必要です。

タイムアウトはどのくらいに設定すればよいですか？

一律ではなく、接続・読み取り・全体の3層で分けます。長文生成やRAG併用では全体タイムアウトを長め（60〜120秒）、読み取りタイムアウトを短め（10〜30秒）に設定します。ユーザーが待つ画面では別途、UI側で早期フィードバックを設計します。

まとめ：エラー種別、待ち時間、冪等性、観測を最初から一式そろえる

LLM APIのリトライ設計は、エラー種別に応じた対応表、指数バックオフとジッター、冪等性、サーキットブレーカー、観測指標を一式そろえて初めて機能します。

一部だけの実装は、二重課金、応答詰まり、上流障害の波及を招きます。既存のLLMアプリでも、まず本記事の判断表と実装チェックリストを埋めるところから見直しできます。

社内AI導入や本番運用で、リトライ設計を含む安全な実装に迷う場合は、業務要件と運用体制を整理したうえで専門家に相談してください。

＼LLM本番運用の設計を相談できます／
Blackfordに相談する