社内で複数のLLM（大規模言語モデル）を使うプロダクトを保守しているエンジニアに向けた内容です。OpenAIのSDKを呼び出す処理があちこちに散らばっていないか、この機会に確認してみてください。
複数のチームがそれぞれclient.chat.completions.create(...)のようなコードを書き、プロバイダーごとに別々のクライアントインスタンスを持つ構成は珍しくありません。デモや個人検証の段階では問題になりませんが、本番運用に乗せた途端に弱点が露呈します。
何が起きるか
典型的な失敗パターンは、深夜にモデルプロバイダー側で障害が起きるケースです。OpenAIやAnthropicのAPIが5xxエラーやレート制限（429エラー）を返し始めると、それに依存する機能がそのまま止まります。
原因はアプリ側のバグではありません。障害発生時に「逃げ道」がないことが本質的な問題です。リトライ処理やフェイルオーバー（代替先への自動切り替え）の仕組みがコードに組み込まれていなければ、プロバイダーの障害がそのままサービス停止に直結します。
もう一つよくある事象がコストの見えない肥大化です。どのチームがどのモデルをどれだけ呼んでいるか追跡する仕組みがないと、月次の請求書を見て初めて異常な消費に気づく、という展開になりがちです。予算超過をリアルタイムで検知できる体制がないと、対応は常に後手に回ります。
なぜ起きるか
原因を分解すると、いくつかの段階に分かれます。
第一に、初期実装のスピード優先です。MVP（実用最小限のプロダクト）を作る段階では、特定のモデルへの直接呼び出しが最速の実装方法になります。この判断自体は間違っていません。問題は、本番運用に移行するタイミングでアーキテクチャを見直さないまま放置することです。
第二に、リトライロジックの重複と非統一です。あるチームは3回リトライ、別のチームは5回リトライ、さらに別のチームは指数バックオフ（再試行間隔を徐々に伸ばす方式）を実装している、といった具合にコードベース内でロジックがバラバラになります。障害対応の挙動が呼び出し箇所ごとに異なると、原因調査にかかる時間が跳ね上がります。
第三に、可観測性（オブザーバビリティ、システム内部の状態を外から把握できる度合い）の欠如です。レイテンシ、トークン使用量、エラー率がクエリ可能な形で記録されていなければ、障害発生時に「何が起きたか」を答えられません。
これらの問題を解決する層として登場したのが AI ゲートウェイと呼ばれるアーキテクチャです。アプリケーションと各モデルプロバイダーの間に単一のエンドポイントを置き、ルーティング・リトライ・フェイルオーバー・キャッシュ・ガバナンスを一手に引き受ける仕組みです。API Gateway（複数のAPIへのアクセスを一元管理する既存のパターン）のLLM版と考えると理解しやすいと思います。
自分のプロジェクトが該当するか確認する
該当するかどうかは、以下の観点で自分のコードベースを見てみてください。
# OpenAI互換クライアントの生成箇所を検索する例
grep -rn "chat.completions.create\|base_url" --include="*.py" .
grep -rn "chat.completions.create\|baseURL" --include="*.ts" .このコマンドで複数のディレクトリに似たようなクライアント初期化コードがヒットするなら、統合の余地があります。特にbase_url（呼び出し先エンドポイント）がハードコードされた箇所が3つ以上あれば、要注意です。
加えて、以下の5点をチェックリストとして使ってみてください。実務での「本番運用に耐えるAI呼び出し基盤」の条件です。
- フェイルオーバー: プライマリのモデルが429や5xxを返したとき、自動的に別のモデル・プロバイダーへ切り替わるか
- ロードバランシング: 複数のプロバイダーやAPIキーにトラフィックが分散され、単一のレート制限が全体を止めないか
- コストガバナンス: チーム単位・キー単位・モデル単位で予算とレート制限を設定・監視できるか
- 可観測性: レイテンシ・トークン使用量・エラー率を、別ツールを追加導入せずに確認できるか
- 低オーバーヘッド: ゲートウェイ自体がリクエストに目に見える遅延を追加していないか
この5条件をすべて満たせていないなら、フェイルオーバーとコストガバナンスから優先して手を入れる価値があります。障害時のサービス停止と請求書の異常、どちらも事後対応のコストが大きいためです。
対策の手順
実際の改善は、いきなり全面刷新する必要はありません。段階的に進める方が既存コードベースへの影響を抑えられます。
1. まずクライアント呼び出し箇所の棚卸しを行います。先述のgrepコマンドや、IDEの全文検索でOpenAI互換SDKの初期化箇所を洗い出します。
2. 次に、リトライ・フェイルオーバーのロジックを一箇所に集約します。自前実装する場合はサーキットブレーカー（連続失敗を検知して一時的に呼び出しを止める仕組み）とセットで設計すると堅牢になります。
3. 既存のオープンソースゲートウェイの導入を検討します。Go言語で実装されたBifrostのようなツールは、5,000リクエスト毎秒の負荷下で1リクエストあたり約11マイクロ秒のオーバーヘッドという計測結果が報告されています。Pythonベースの実装と比べてP99レイテンシ（全リクエストのうち遅い方から1%の応答時間）で大きな差が出るとされ、レイテンシに敏感なワークロードほど実装言語の選定が効いてきます。ミリ秒単位の遅延が積み重なるかマイクロ秒単位で収まるかは、高頻度リクエストのサービスでは無視できない差になります。
4. 導入後は、可観測性ダッシュボードでチームごと・モデルごとのコストとエラー率を可視化します。既存のGrafanaやDatadogといった監視基盤に統合できるかどうかも、選定時の判断材料になります。
5. 最後に、実際にプロバイダー障害を想定した負荷テストを行います。プライマリのAPIキーを意図的に無効化し、フェイルオーバーが正しく発火するかを確認する手順は、本番投入前に必ず実施しておきたいところです。
既存の大規模システムに後から組み込む場合、いきなり全トラフィックを切り替えるのはリスクが高い進め方です。まず影響範囲の小さい機能から段階的にゲートウェイ経由に切り替え、レイテンシとエラー率に異常がないことを確認しながら範囲を広げる進め方が安全です。
まとめ
複数のLLMプロバイダーを直接呼び出すコードが複数チームに散らばっている状態は、障害耐性とコスト管理の両方で弱点になります。
確認の第一歩は、コードベース内のクライアント初期化箇所をgrepで洗い出すことです。3箇所以上に似た実装が散在していれば、統合を検討するタイミングです。
次に、フェイルオーバー・ロードバランシング・コストガバナンス・可観測性・低オーバーヘッドの5条件でチェックリストを作り、現状のギャップを特定してください。
本番投入前には、プライマリのAPIキーを意図的に無効化してフェイルオーバーの挙動を確認するテストを忘れずに行ってください。それが、深夜のプロバイダー障害でサービスを止めないための最後の砦になります。