開発解説
LLM API障害時のfallbackはどう設計する？別モデルへ替える前に互換性を確認
目次
結論
429・5xx・timeoutを同じ失敗として扱わず、まずretry可否を判定します。別モデルへ落とす場合はツール/schema/context/data policyが互換な経路だけをfallback候補にします。
判断の順番は 必須条件→費用/性能の得失→運用条件 です。価格、plan、求人、hardware仕様など時間で変わる事実には 2026-09-13 の観測日を付け、未測定の速度・品質・時間・電力を公式仕様から推測して数値化しません。
判断表：障害種別ごとのretry/fallback状態遷移表
| 失敗 | 最初のaction | 同model retry | 別model/provider fallback | 失格条件 |
|---|---|---|---|---|
| 429 | Retry-After/backoff | 可（上限あり） | capacity policy次第 | 無限retry |
| timeout/5xx | idempotency確認 | 可（回数制限） | 可 | side effect重複の恐れ |
| context/size | prompt縮約/route変更 | 同条件retry不可 | 大context modelへ | 情報を黙って落とす |
| schema failure | validation errorを返す | corrective retry | schema互換modelのみ | required field欠落 |
| ツール incompatibility | capability check | 原則不可 | 同ツール contractを満たすmodel | ツールを無効化して成功扱い |
| policy/data boundary | route停止 | 不可 | 同じdata policyのproviderだけ | 未承認地域/providerへ送信 |
fallbackの成功条件は「文字が返った」ではなく、schema・ツール・policy・qualityの必須契約を維持したことです。
判断の前提
LLM APIはproviderを替えてもHTTP requestが同じになるわけではありません。message構造、ツール schema、structured output、rate limit、error semanticsを契約として扱います。
運用ではprovider公式のtoken/limitだけでなく、自分のrequest IDとlatency/error/quality評価を結びます。ただしprompt本文や個人情報を無条件にtelemetryへ載せません。
migration/fallbackは「返答が出たら成功」ではなく、schema validation・ツール実行・policy・評価セットまで同等に通ることをrelease条件にします。
このテーマで実際に見るポイント
429
backoff/retry-afterを尊重し、無限retryしない。
5xx/timeout
idempotencyを確認しretryと別provider切替を分ける。
schema
fallback modelがstructured output/ツール schemaを満たさなければ使わない。
policy
data residency/retentionが違うproviderへ勝手に送らない。
選ばない・進めない条件
schema/ツール/policy/rollbackが代表evalを通らないprovider/modelへ切り替えない。
これは「慎重に」という抽象論ではなく、比較表の必須条件を満たさない候補をランキングから外すための公開条件です。
一次情報
- OpenAI API — Compare models
- Anthropic — Rate limits
- Anthropic — Structured outputs
- Google AI — Gemini API rate limits
- Google AI — Function calling
まとめ
429・5xx・timeoutを同じ失敗として扱わず、まずretry可否を判定します。別モデルへ落とす場合はツール/schema/context/data policyが互換な経路だけをfallback候補にします。
変化が速い領域ほど固定ランキングより、同じinputで更新できる障害種別ごとのretry/fallback状態遷移表を正本にします。更新時は変化した項目だけを最新の情報源/実際の観測結果で差し替え、同じ判断基準で結論を再計算します。
まとめ
- 429・5xx・timeoutを同じ失敗として扱わず、まずretry可否を判定します。別モデルへ落とす場合はツール/schema/context/data policyが互換な経路だけをfallback候補にします。 変化が速い領域ほど固定ランキングより、同じinputで更新できる**障害種別ごとのretry/fallback状態遷移表**を正本にします。更新時は変化した項目だけを最新の情報源/実際の観測結果で差し替え、同じ判断基準で結論を再計算します。