エンタープライズ規模のAIエージェントは、LLM APIを数百〜数千コールで叩き続ける。1リクエストが429を返した瞬間、マルチエージェント構成では並列ワーカーが一斉に再試行を開始し、リトライストームがAPI予算を秒単位で消費する。LLMが返す失敗は「HTTPステータス」だけではない——コンテキストウィンドウ超過・コンテンツポリシー拒否・品質劣化は、ステータス200のまま静かにシステムを侵食する。サーキットブレーカーとフォールバックチェーンの設計なしに、エンタープライズエージェントの本番安定性は確保できない。
LLM APIの障害はなぜ通常のサービス障害と違うのか
LLM APIはレート制限・コンテキスト超過・非決定論的拒否で失敗し、ステータス200のまま質的に劣化するサイレント障害も存在する。
従来のWebサービスでは死活監視とHTTPステータスコードで障害を検知できた。LLM APIの障害パターンはこの前提を崩す。
量的失敗（検知しやすい）: 429レート制限、500/503サーバー障害。これは従来のサーキットブレーカーが対処できる失敗だ。
質的失敗（検知しにくい）: ステータス200を返しながら発生する障害がある。応答レイテンシが数秒→十数秒に悪化する、コンテキストウィンドウ上限に近づいてコヒーレンスが失われる、コンテンツポリシーの確率的拒否が増える——これらは通常の死活監視では見えない。質的劣化を検知するには、レイテンシP99やLLMジャッジによる出力品質スコアをメトリクスに組み込む必要がある。
カスケード増幅: サブエージェント・オーケストレーションの各ノードに再試行ロジックが存在する場合、各ノードが個別に3回リトライすれば5段階パイプラインでは最大3^5=243コールが1リクエストから発生しうる。この指数的増幅が「リトライストーム」の正体だ。サーキットブレーカーはカスケード増幅を上流で止める最初の防壁として機能する。
サーキットブレーカーの3状態と閾値設計
サーキットブレーカーはClosed/Open/Half-openの3状態で自律動作し、LLM API障害を遮断してサービスが回復するまで保護する設計パターンだ。
サーキットブレーカーは電気回路の遮断器をソフトウェアに適用したパターンで、3つの状態遷移で動作する。
Closed（通常状態）: すべてのリクエストをLLM APIに転送しながら失敗率をスライディングウィンドウで監視する。60秒間のウィンドウでエラーを集計し、失敗率が50%を超えた時点でOpenに遷移する。量的失敗（429、500系）に加え、レイテンシP99が設定閾値（例: 10秒）を超えるケースも失敗としてカウントすると、質的劣化にも反応できる。
Open（遮断状態）: すべてのリクエストをLLM APIに送らず即座に拒否する。フォールバックチェーンが起動するのはこのタイミングだ。この状態を60秒間維持することで、回復の妨げになるリトライストームを防ぎ、APIプロバイダーに回復の時間を与える。
Half-open（探索状態）: Open期間が経過した後に入る中間状態。テストリクエストを1件だけAPIに通し、成功すればClosedに戻り、失敗すればOpenに延長する。フリップフロップ（短時間でOpen/Closedを繰り返す現象）を防ぐため、Half-openで連続して成功した回数（例: 5回）を条件にする実装が安定する。
``
Closed → (失敗率 > 50% in 60秒窓) → Open
Open → (60秒経過) → Half-open
Half-open → (テスト成功) → Closed
Half-open → (テスト失敗) → Open
Resilience4j（Java）・Polly（C#）・PyBreaker（Python）などのライブラリはこの3状態機械を実装しており、LLMゲートウェイとのミドルウェア統合が可能だ。
フォールバックチェーンの構造——モデル・キャッシュ・503の順序
フォールバックチェーンはプライマリモデル→廉価モデル→セマンティックキャッシュ→503の順で宣言的に定義し、契約互換性を保証する。
サーキットブレーカーがOpenになった後、システムはどう応答するか。その答えがフォールバックチェーンだ。チェーンは「上位から試み、使えなければ下位に降りる」階段構造で設計する。
段階1: 廉価モデルへのルーティング: プライマリモデル（例: Claude Opus）が不可能な場合、廉価・低レイテンシのモデル（例: Claude Haiku）にルーティングする。重要なのはスキーマ互換性の保証だ。出力フォーマット（JSON Schemaや関数呼び出しの定義）を統一しないと、フォールバック先のレスポンスをダウンストリームが処理できない。フォールバック先ごとに事前に互換性テストを実施し、モデル切替が透過的に行える状態にしておく。
段階2: セマンティックキャッシュ: 過去の類似クエリの応答を返す。ベクトル類似度で「意味的に近いクエリ」を見つけ、コサイン類似度0.95以上の場合にキャッシュ応答を返す設計が一般的だ。完全一致キャッシュより命中率が高く、LLM API全停止時でも限定的な機能継続を可能にする。
段階3: 503または部分応答: チェーンのすべての選択肢が尽きたとき、ユーザーに明示的な「現在AIサービスを利用できない」メッセージを返す。サイレントな誤応答より透明な失敗が運用上は優る。ルートによっては「AIなしの手動処理フロー」にリダイレクトする設計もある。
各フォールバック段階はLLMゲートウェイ（詳細はLLMゲートウェイ設計を参照）のルーティングルールとして宣言的に定義し、アプリケーションコードを変更せずにフォールバック先を切り替えられる設計にする。
バルクヘッドパターンとリトライストームの防止設計
バルクヘッドはワークロード単位でAPIコンテキストを分離し、1ワークロードの暴走が全エージェントを巻き込まない設計を実現する。
バルクヘッドパターンは船舶の防水隔壁が語源だ。1区画が浸水しても他の区画が生き残る設計をソフトウェアに適用する。
トークンバケット分離: APIコンテキストを（テナント、ワークロード、モデル）の3軸で分離したバケットに割り当てる。バッチ処理ワークロードがバケットを使い果たしても、リアルタイム処理ワークロードのバケットは独立して確保される。1ワークロードの過消費が他ワークロードのAPIアクセスを奪わない構造だ。サブスクリプションプランに応じたバケットサイズ設計は、マルチテナントエージェント基盤（詳細はマルチテナントエージェント分離設計を参照）と組み合わせると効果的だ。
マルチエージェントでのリトライ無効化: LangGraphや各社エージェントSDKを使ったマルチエージェント構成では、ノードごとのデフォルトリトライを無効化することが推奨される。個別ノードのリトライはオーケストレーターレベルで集中管理し、ファンアウト並列ワーカーのリトライが掛け算で増幅しないよう設計する。具体的にはwith_retry()の削除またはmax_attempts=1の明示設定が起点となる。
コストベロシティブレーカー: 支出速度が計画値の一定倍（デフォルト10倍）を超えた場合に発動する特殊なブレーカーだ。予算爆発を時間的に制限し、オペレーターがアラートを受け取り介入できる時間を確保する。アラートにはトレースID・発火したID・検出パターン・コスト速度を含め、原因特定を即時に行える設計にする。
エンタープライズ向けのサーキットブレーカー設計・LLMゲートウェイ統合・フォールバックチェーンの実装支援はKuu株式会社のRDEサービスで提供している。
参考
- Retries, Fallbacks, and Circuit Breakers in LLM Apps — Maxim
- Rate Limiting AI Agents: Preventing LLM API Exhaustion with a 3-Layer Gateway — TrueFoundry
- AI Agent Circuit Breakers: The Reliability Pattern Production Teams Are Missing — DEV Community
まとめ
LLM APIの障害はHTTPエラーに止まらず、ステータス200で起きる質的劣化・リトライストームという独自の課題を持つ。サーキットブレーカーはClosed/Open/Half-openの3状態機械でAPIへのアクセスを自律遮断し、フォールバックチェーンはプライマリモデル→廉価モデル→セマンティックキャッシュ→503の順でサービス継続を維持する。バルクヘッドパターンでワークロードを隔離し、コストベロシティブレーカーで予算爆発を防ぐ多層防御が、エンタープライズ品質の耐障害性設計の骨格だ。
大規模エージェント基盤の設計・実装支援を検討している場合は、Kuu株式会社のRDEサービスにご相談ください。