LLMゲートウェイ（エルエルエムゲートウェイ）
複数のLLMプロバイダ（OpenAI、Anthropic、Google、ローカルLLM等）へのアクセスを統一APIで抽象化し、ルーティング・認証・レート制限・コスト管理・ロギング・キャッシュ等の横断的機能を提供するミドルウェア。APIゲートウェイのLLM特化版であり、LiteLLM、Portkey、Helicone等が代表的。
LLMゲートウェイとは
LLMゲートウェイは、アプリケーションと複数のLLMプロバイダの間に位置するミドルウェアで、APIゲートウェイのLLM特化版である。OpenAI、Anthropic、Google、Azure、AWS Bedrock、ローカルLLM（vLLM/Ollama等）といった異なるプロバイダのAPIを統一インターフェースで抽象化し、プロバイダ切替時のコード変更を不要にする。
2026年時点でLLMを利用するアプリケーションの多くが複数プロバイダを併用しており（コスト最適化、可用性向上、モデル特性による使い分け）、LLMゲートウェイはLLMインフラスタックの標準コンポーネントになりつつある。
LLMゲートウェイの主要機能
| 機能 | 説明 | メリット |
|---|---|---|
| 統一API | プロバイダ間のAPI差異を吸収 | コード変更なしでプロバイダ切替 |
| ロードバランシング | 複数プロバイダ/レプリカへの負荷分散 | 可用性・スループット向上 |
| フォールバック | プロバイダ障害時の自動切替 | ダウンタイム最小化 |
| レート制限 | プロバイダ別・ユーザー別のリクエスト制限 | API制限遵守・コスト制御 |
| コスト追跡 | トークン消費量・API費用のリアルタイム集計 | 予算管理・課金最適化 |
| キャッシュ | 同一リクエストの応答キャッシュ | レイテンシ削減・コスト削減 |
| ロギング | リクエスト/レスポンスの記録 | デバッグ・監査・品質改善 |
| ガードレール | 入出力の安全性チェック | 有害コンテンツ防止 |
主要ツール・サービス
| ツール | 種類 | 対応プロバイダ数 | 特徴 | 価格 |
|---|---|---|---|---|
| LiteLLM | OSS/セルフホスト | 100+ | 最も広いプロバイダカバレッジ | 無料（OSS）+有料Enterprise |
| Portkey | SaaS | 250+ | 高速キャッシュ、ガードレール統合 | フリーミアム |
| Helicone | SaaS/OSS | 主要プロバイダ | ロギング・分析特化 | フリーミアム |
| OpenRouter | SaaS | 50+ | マーケットプレイス型、最安値ルーティング | 従量課金 |
| Martian | SaaS | 主要プロバイダ | AI駆動のモデル選択最適化 | フリーミアム |
LiteLLM: 最も広く採用されているOSSのLLMゲートウェイ。100以上のプロバイダのAPIをOpenAI互換フォーマットに変換する。litellm.completion(model="claude-3-5-sonnet", messages=[...])のように統一APIで呼び出し、内部でAnthropic APIに変換・転送する。Redis/PostgreSQLベースのキャッシュ、Prometheus メトリクス出力、仮想キー管理を備える。
Portkey: エンタープライズ向けLLMゲートウェイSaaS。250以上のモデルに対応し、ゲートウェイの応答遅延が9.9msと極めて低い。セマンティックキャッシュ（類似リクエストのキャッシュヒット）、ガードレール統合、A/Bテスト機能を提供。
Helicone: LLMリクエストのロギング・分析に特化したゲートウェイ。1行のコード変更（ベースURLの書き換え）でOpenAI API呼び出しを全てログ記録できる。コスト分析、レイテンシ分布、エラー率などのダッシュボードを提供。OSS版（セルフホスト）と SaaS版がある。
アーキテクチャパターン
アプリケーション → [LLMゲートウェイ] → OpenAI API
→ Anthropic API
→ ローカルvLLM
→ AWS Bedrock
シングルゲートウェイ: 1つのLLMゲートウェイインスタンスが全てのLLMリクエストを仲介。小〜中規模アプリケーションに適している。
階層型ゲートウェイ: フロントエンドゲートウェイ（認証・レート制限）とバックエンドゲートウェイ（ルーティング・キャッシュ）の2層構成。大規模エンタープライズで採用。
セルフホスト vs SaaS
| 観点 | セルフホスト（LiteLLM等） | SaaS（Portkey等） |
|---|---|---|
| 初期コスト | 低い（インフラ費用のみ） | 低い（フリーミアム） |
| 運用負荷 | 高い（可用性管理が必要） | 低い |
| データプライバシー | 高い（データが外部に出ない） | 要確認（SOC2/GDPR対応） |
| カスタマイズ性 | 高い（ソースコード変更可） | 低い |
| レイテンシ | ネットワーク構成に依存 | 追加1〜10ms |
よくある質問
Q1: LLMゲートウェイを使うとレイテンシは増加しますか？
プロキシを経由するため理論上は追加レイテンシが発生するが、LiteLLMで1〜5ms、Portkeyで約10ms程度である。LLMの推論自体が500ms〜数秒かかるため、ゲートウェイの追加レイテンシは実用上無視できる。キャッシュヒット時は推論をスキップするため、全体としてはレイテンシが大幅に改善されるケースが多い。
Q2: LLMゲートウェイはセキュリティリスクになりませんか？
ゲートウェイが全てのLLMリクエスト/レスポンスを仲介するため、ゲートウェイ自体のセキュリティが重要になる。セルフホストの場合はTLS暗号化、認証（APIキー/JWT）、ネットワーク隔離を徹底する。SaaSの場合はSOC 2 Type II認証、GDPR対応、データ保持ポリシーを確認する。機密データを扱う場合はセルフホスト+VPC内デプロイが推奨。
Q3: 既存のOpenAI SDK呼び出しをLLMゲートウェイに移行するには？
LiteLLM/PortkeyはいずれもベースURLの変更だけで移行可能。OpenAI Python SDKの場合、openai.base_url = "http://litellm-gateway:4000"と1行変更するだけで全リクエストがゲートウェイ経由になる。既存のコード、プロンプト、パラメータは変更不要。