LLM Gatewayが解決すること
アプリケーションから各LLMへ直接接続する代わりに、共通の窓口を置きます。モデル変更時にアプリ側の修正を減らし、リクエスト単位のログや費用を同じ形式で扱えるようになります。
Gateway自体がAIモデルになるのではなく、既存モデルへの接続と運用をまとめる層です。
- モデルごとに異なるAPI接続の共通化
- タイムアウトや429発生時のリトライ・フォールバック
- チーム・顧客・機能ごとの利用量集計
- 予算上限、レート制限、監査ログの一元管理
代表的な選択肢の違い
同じGatewayという呼び方でも、提供範囲は異なります。自社のAPIキーを束ねるのか、モデル調達まで一本化するのか、既存通信に制御を追加するのかを先に決めます。
| 選択肢 | 主な役割 | 向くケース | 主な注意点 |
|---|---|---|---|
| LiteLLM | OSSのSDK/Proxy | 自社管理で認証・予算・ルーティングを細かく制御 | Proxyの可用性と更新を自社で担う |
| OpenRouter | 多数モデルへの統合API | モデル接続とプロバイダー選択を短期間でまとめたい | 調達経路・ログ・固有機能への依存を確認 |
| Cloudflare AI Gateway | 既存AI API通信の可視化・制御 | 既存構成に分析・キャッシュ・レート制限を追加 | 必要機能とプラン、ログ保存条件を確認 |
コスト削減は『単価』だけでは決まらない
安いモデルへの切り替えだけを見ると、品質低下や再実行の増加を見落とします。成功率、レイテンシ、入力・出力トークン、キャッシュヒット率を合わせて計測し、完了タスク1件あたりの原価で比較するのが実務的です。
導入前に確認したい5項目
既存SDKとの互換性、ストリーミング対応、ログに残るデータ、障害時の挙動、セルフホスト可否を確認します。特に顧客データを扱う場合は、プロンプトやレスポンスがどこに保存されるかを先に整理してください。
- OpenAI互換APIとして置き換えられるか
- リージョン・保存期間・マスキング設定
- プロバイダー障害時の切替条件
- タグ付けの粒度と請求データの出力
- Gateway自体の従量料金と運用工数
PoCで測るべき指標
本番トラフィックの一部だけをGateway経由にし、直結時と比較します。平均値だけでなく、p95レイテンシ、429率、フォールバック後の成功率、1完了タスクあたりの費用を記録します。障害時にGatewayを迂回できる設計も、導入判断に含めるべきです。
向いているチーム
複数モデルを本番利用している、月次請求の内訳を説明できない、顧客別原価を取りたい、障害時に手作業でモデルを切り替えている。このいずれかに当てはまる場合は、Gatewayを検証する価値があります。
1回のリクエストが通る流れ
アプリからGatewayへ送られたリクエストは、認証、利用可能モデルの確認、予算・レート制限、接続先の選択を経てプロバイダーへ転送されます。応答後はトークン数、料金、処理時間、エラー、選択された接続先をログへ記録します。
この各段階で失敗条件が増えるため、Gateway導入は接続先URLを変えるだけの作業ではありません。タイムアウトをGatewayとプロバイダーのどちらで判定するか、再試行による二重処理をどう防ぐか、ストリーミング途中の切断をどう扱うかまで決めます。
- 認証:アプリや顧客ごとの仮想キーを検証
- 制御:利用モデル、予算、RPM・TPMを確認
- 選択:優先度、価格、地域、稼働状況から接続先を決定
- 実行:プロバイダーへ転送し、応答またはエラーを受信
- 記録:トークン、料金、遅延、再試行、最終結果を保存
完了タスク原価の計算方法
Gateway導入後のコストは、API請求額だけでなく、再試行と失敗を含めて計算します。たとえば1,000件の処理でAPI料金が1万円でも、100件が失敗し、再実行に2,000円かかった場合、完了900件に対する原価は単純な1件10円ではありません。
比較には『(モデル料金+Gateway料金+再試行料金+運用費)÷正常完了件数』を使います。品質評価に人手確認が必要なら、その作業時間も別項目で記録します。単価の安いモデルへ振り分けても、修正率が上がれば全体原価は悪化します。
Gateway自体を単一障害点にしない
複数モデルへ切り替えられる構成でも、入口のGatewayが停止すれば全モデルへ接続できなくなります。本番ではGatewayの冗長化、設定変更の承認、設定ファイルのバックアップ、直結経路への緊急切替を検討します。
フォールバックも無条件に行うと危険です。タイムアウトのたびに高価なモデルへ切り替わると費用が急増し、ツール呼び出し途中の再実行では二重処理が起きます。読み取り処理と書き込み処理で再試行方針を分け、最大回数と費用上限を設定します。
ロックインを減らす設計
OpenAI互換APIは移行を容易にしますが、すべての固有機能が共通化できるわけではありません。モデル固有の推論設定、キャッシュ、ツール呼び出し、画像・音声機能をアプリ全体へ直接書き込むと、Gateway変更時の修正範囲が広がります。
共通処理と固有処理をコード上で分け、元のプロバイダー応答、Gatewayが付加したメタデータ、社内の評価データを持ち出せる状態にします。月1回程度は直結経路でも疎通確認し、緊急切替が机上の設計にならないようにします。
参考資料
料金・仕様は変更される可能性があります。導入時は各社の最新情報をご確認ください。
