モデルフォールバックルーティング（モデルフォールバックルーティング）
LLMプロバイダの障害・レート制限・タイムアウト発生時に、事前定義された優先順位に従って代替モデルへ自動切替するルーティング戦略。サービスの可用性を99.9%以上に維持するための基本的な耐障害設計。
モデルフォールバックルーティングとは
モデルフォールバックルーティング（Model Fallback Routing）とは、LLMへのリクエストが失敗した際に、事前に定義された代替モデル（フォールバック先）へ自動的にリクエストを再送信する耐障害性の仕組みである。「Plan B」を常に用意しておくことで、特定プロバイダの障害がサービス全体のダウンタイムに直結することを防ぐ。
フォールバックが必要な障害パターン
| 障害パターン | HTTP ステータス | 発生頻度 | 典型的な原因 |
|---|---|---|---|
| レート制限 | 429 Too Many Requests | 高い | リクエスト集中・TPM/RPM上限到達 |
| サーバーエラー | 500 Internal Server Error | 中程度 | プロバイダ側の障害・メンテナンス |
| タイムアウト | 408/504 | 中程度 | 長文生成・サーバー過負荷 |
| コンテンツフィルタ | 400 Bad Request | 低い | 安全性フィルタによる拒否 |
| 認証エラー | 401/403 | 稀 | APIキー失効・権限不足 |
| モデル非可用 | 404 | 稀 | モデルの廃止・リージョン制限 |
フォールバックチェーンの設計
フォールバックチェーンは「どのモデルが失敗したら、どのモデルに切り替えるか」を定義する優先順位リストである：
同等品質フォールバック（水平フォールバック）
同じ性能ティアのモデル間で切り替える。品質維持を最優先する場合に採用。
例: Claude Sonnet 4.6 → GPT-4o → Gemini 2.5 Pro
グレード降格フォールバック（垂直フォールバック）
障害時に下位ティアのモデルへ切り替える。可用性を最優先し、品質低下を許容する場合に採用。
例: Claude Opus 4 → Claude Sonnet 4.6 → Claude Haiku 4.5
ハイブリッドフォールバック
まず同等品質のモデルを試し、それも失敗したら下位ティアに降格する。品質と可用性のバランスを取る設計。
例: Claude Sonnet 4.6 → GPT-4o → Claude Haiku 4.5
リトライとフォールバックの使い分け
| 戦略 | 動作 | 適するケース |
|---|---|---|
| リトライ（再試行） | 同じモデルに再リクエスト | 一時的な429エラー、ネットワーク瞬断 |
| フォールバック（代替切替） | 別のモデルにリクエスト | 持続的な障害、500エラー、モデル非可用 |
| リトライ→フォールバック | まず再試行、失敗続きなら代替へ | 最も一般的な実装パターン |
実装では「3回リトライ後にフォールバック」が標準的な設定。リトライ間隔はExponential Backoff（1s→2s→4s）が推奨される。
主要プラットフォームでのフォールバック設定
LiteLLM
router_settings:
num_retries: 3
timeout: 30
fallbacks:
- claude-sonnet: [gpt-4o, gemini-pro]
- gpt-4o: [claude-sonnet, gemini-pro]
OpenAI SDK（Python）
from openai import OpenAI
client = OpenAI()
try:
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "Hello"}]
)
except Exception:
# フォールバック
response = anthropic_client.messages.create(
model="claude-sonnet-4-6",
messages=[{"role": "user", "content": "Hello"}]
)
Portkey AI Gateway
{
"strategy": {"mode": "fallback"},
"targets": [
{"virtual_key": "openai-key", "override_params": {"model": "gpt-4o"}},
{"virtual_key": "anthropic-key", "override_params": {"model": "claude-sonnet-4-6"}}
]
}
フォールバック時の注意事項
- プロンプト互換性: モデル間でシステムプロンプトやツール定義のフォーマットが異なる場合がある。LiteLLMは自動変換を提供するが、高度な機能（Vision、Tool Use）は互換性を事前確認する必要がある
- コスト管理: フォールバック先が高コストモデルの場合、障害時にコストが急増するリスクがある。コスト上限との連携が重要
- レスポンス一貫性: ユーザーとの対話途中でモデルが切り替わると、口調やコンテキスト理解が変わる場合がある
- 監視とアラート: フォールバックが頻発する場合はプライマリモデルの障害を示唆するため、フォールバック率の監視とアラート設定が必須
FAQ
Q1: フォールバックチェーンには何個のモデルを含めるべきですか？
A1: 2-3個が実用的です。1個では単一障害点が残り、4個以上は管理の複雑さとテスト負荷が増大します。異なるプロバイダ（Anthropic、OpenAI、Google）を混在させることで、特定プロバイダの全面障害にも対応できます。
Q2: フォールバック発生時にユーザーに通知すべきですか？
A2: 一般的にはユーザーへの通知は不要です。ユーザーにとっては「応答が返ってくること」が重要であり、内部のモデル切替は透過的に処理されるべきです。ただし、品質が明らかに低下するグレード降格フォールバック時は、「現在一部機能を制限して提供中」などの表示を検討してください。
Q3: すべてのフォールバック先も障害の場合はどうなりますか？
A3: 全フォールバック先が失敗した場合は、適切なエラーメッセージをユーザーに返す「グレースフルデグラデーション」を実装します。「現在AIアシスタントが一時的に利用できません。しばらくお待ちください」のような表示と、オペレーションチームへの即時アラートを組み合わせます。