AIエージェントをエンタープライズシステムに組み込むプラクティス 【サーキットブレーカ＋モデルフォールバック】 💡 LLMプロバイダは落ちる。それを前提に設計していますか？サーキットブレーカとフォールバックで、単一障害点を構造的に排除しましょう。 🔥 解決する課題 - LLMプロバイダの障害・メンテナンスでエージェントが完全停止する - 障害中のプロバイダへのリトライが蓄積し、システム全体の負荷を悪化させる - 単一プロバイダへの依存が全エージェントの可用性リスクになる 🏗️ 提案パターン プライマリモデルのエラー率やレイテンシが閾値を超えたら、セカンダリモデル（別プロバイダや別リージョン）へ自動切替します。セカンダリも不可なら、キャッシュ応答や「現在対応できません」メッセージで縮退応答を返します。サーキットブレーカ（Open/Half-Open/Closed）で障害時のリクエスト洪水を防止し、復旧後はHalf-Open状態で段階的にプライマリへ戻します。この仕組みはAIゲートウェイに組み込み、個別アプリでの重複実装を避けるのが鉄則です。 ✅ 選定条件 - 向き：全本番環境（LLMの可用性変動は前提として備えるべき） - 不向き：特になし（本番運用であれば原則適用） ⚠️ 落とし穴 - タイムアウトを長くしすぎるとユーザー離脱やリソース枯渇を招く - 副作用を伴う操作のリトライは冪等キーなしでは重複実行の危険がある - フォールバックモデルの品質差を事前にevalで検証しておかないと、切替後の品質劣化に気づかない 🛠️ 実装方針 1. マルチプロバイダ抽象レイヤ（LiteLLM / Portkey）を導入し、プライマリ・セカンダリモデルの切替をアプリコードから分離します 2. サーキットブレーカ（resilience4j / Polly）をAIゲートウェイに組み込み、エラー率・レイテンシ閾値（P99の2〜3倍を起点）で Open/Half-Open/Closed を自動遷移させます 3. フォールバック先モデルの品質をevalデータセットで事前検証し、許容範囲を確認してから登録します 4. 副作用を伴う操作には冪等キーを付与し、リトライ時の重複実行を防止します 5. ヘルスチェックエンドポイントを設け、復旧検知後にHalf-Open状態で段階的にプライマリへトラフィックを戻します #AIエージェント# #エンタープライズアーキテクチャ#