社内の十数個の機能が、3つのモデルプロバイダーを呼び出しているとします。チームごとに独自の API キーを持ち、先月どのチームがいくら使ったかは誰にも分からず、主要プロバイダーが1時間にわたって 429 エラーを返したときは、各アプリがそれぞれ違う壊れ方をしました。あるアプリはモデルを切り替えて、JSON 出力が壊れました。
LLMゲートウェイは、AIゲートウェイや LLM プロキシとも呼ばれ、すべてのモデル呼び出しを1つのサービスに通します。そのサービスがキー、ルーティング、メーターを管理します。この記事ではリクエストの経路を段階ごとにたどり、そのあとルーティング、キャッシュ、トークン制限、メトリクス、セキュリティ、採用できるゲートウェイを取り上げます。
モデルプロバイダーの前にゲートウェイを置く理由
プロバイダーの制限や請求書は、組織図には沿っていません。OpenAI はレート制限を組織とプロジェクト単位で設定し、ユーザー単位では設定しません。Anthropic は組織単位で、任意でワークスペース単位の制限もあります。顧客向けチャットと同じプロジェクトで夜間バッチジョブを動かすと、チャットの毎分トークン数を使い切ることがあります。ゲートウェイを置くと、キー、ルーティング、チーム別の制限、コストの帰属を1か所にまとめられます。
ゲートウェイはAPI ゲートウェイの代わりにはなりません。API ゲートウェイはリクエスト数を数えます。LLMゲートウェイはトークンとドルを数え、ストリーミング応答を理解し、プロバイダーの 429 を別のモデルを試す理由として扱います。
リクエストの経路を段階ごとにたどる
軽いチェックを先に実行します。リクエストが許可され、まだ回答されていない場合にだけ、プロバイダーに到達します。
- 認証する。 仮想キーをアプリ、チーム、許可されたモデルに対応づけます。対応づけられなければ 401 を返します。
- 制限を確認する。 Redis にあるチームのトークンカウンターと予算を比較します。上限を超えていれば、
Retry-After付きで 429 を返します。 - ポリシーを適用する。 モデルの許可リストと
max_tokensの上限を適用し、メールアドレスなどの個人データをマスクします。 - キャッシュを確認する。 ヒットすれば、プロバイダーを呼ばずに保存済みの回答を返します。
- ルーティングする。 モデルと、順序付きのフォールバックチェーンを選びます。
- アダプターを呼ぶ。 リクエストをプロバイダーの API 形式に変換し、プロバイダーのキーを付け、最初のトークンのタイムアウトを開始します。
- リトライまたはフォールバックする。 対象は 429、5xx、Anthropic の過負荷エラー 529、タイムアウトで、最初のトークンがアプリに届く前に限ります。200 でストリームが始まったあとでもプロバイダーがエラーを送ることがあり、回答の途中でモデルを切り替えると2つの返信がつなぎ合わされてしまいます。
- ストリームして計測する。 server-sent events をそのまま通し、使用量イベントを非同期で書き込みます。OpenAI の Chat Completions API は、
stream_options.include_usageを指定した場合にだけ、最後のチャンクで使用量を送ります。ストリームが途中で切れると使用量は失われるため、クライアントが切断したあとも読み続けてください。
手順 1 から 4 はメモリまたは Redis のルックアップにとどめ、ログ記録と評価はリクエスト経路の外に置きます。
ルーティング戦略
| 戦略 | 選び方 | 注意点 |
|---|---|---|
| コスト | eval に合格する最も安いモデル | 機能ごとに eval が必要 |
| レイテンシ | 直近の最初のトークンまでの時間が最短 | 平滑化しないとノイズが多い |
| 機能 | コンテキスト長、ビジョン、ツール利用 | フォールバック先が対応していない場合がある |
| データ分類 | フラグ付きデータは承認済みモデルにだけ送る | 分類を誤ると漏えいする |
| フォールバックチェーン | エラーとタイムアウト時に次のモデルへ | モデルごとに回答が異なる |
| A/B 分割 | 90/10、会話ごとに固定 | エラー率ではなく eval で判断する |
最も安全なフォールバックは、同じモデルを別のホストで使うことです。たとえば Anthropic API と Amazon Bedrock の Claude モデルがこれに当たります。別のモデルファミリーには独自の eval が必要です。ツール呼び出しと JSON 出力が最初に壊れるためで、どのフォールバックにも余裕のあるクォータが必要です。
リトライは1つのレイヤーだけで行ってください。OpenAI Python SDK はデフォルトで2回リトライし、LiteLLM のドキュメントは、リトライを重ねると1件のリクエストが (1 + N)² 回の上流呼び出しになると警告しています。失敗しているデプロイメントを叩き続けず休ませましょう。LiteLLM はデフォルトで 429 のあと 5 秒間そうします。サーキットブレーカーパターンはこれを一般化したものです。
キャッシュ:完全一致、セマンティック、プロバイダー側
| 完全一致 | セマンティック | プロバイダーのプロンプトキャッシュ | |
|---|---|---|---|
| 実行場所 | ゲートウェイ(通常は Redis) | ゲートウェイとベクトルインデックス | プロバイダー |
| キー | リクエスト全体のハッシュ | 埋め込みの類似度 | 同一のプロンプト先頭部分 |
| 節約できるもの | 呼び出し全体 | 呼び出し全体 | 入力コストとレイテンシの一部 |
| リスク | チャットではヒット率が低い | 似た質問に誤った回答を返す | 先頭の変更で無効になる |
完全一致キャッシュは安全ですが、対象が狭くなります。Cloudflare AI Gateway は、プロバイダー、エンドポイント、モデル、認証ヘッダー、リクエスト本文全体をハッシュするため、少しでも変われば新しいエントリになります。キャッシュキーにはテナントを含めてください。含めないと、ある顧客の回答が別の顧客に届くことがあります。セマンティックキャッシュは言い換えにも一致しますが、「注文をキャンセルしたい」と「サブスクリプションを解約したい」のように近い位置に入ってしまうことがあります。そのため、惜しい外れが無害な場面にだけ使ってください。
プロバイダー側のキャッシュが最も節約になることが多いです。Anthropic は cache_control を付けたプレフィックスを 5 分間キャッシュし、ヒットのたびに延長します。ほとんどのモデルで、キャッシュ読み取りの料金は基本入力価格の 0.1 倍です。OpenAI は対応モデルでデフォルトでキャッシュを行い、キャッシュされた入力は最大 95% 安くなります(執筆時点、2026 年 11 月)。システムプロンプトはバイト単位で同一に保ち、先頭にタイムスタンプを入れないでください。マスキングは決定的に行い、会話は1つのデプロイメントに固定してください。プロバイダーのアカウントごとに独自のキャッシュがあるためです。
入力トークン 100 万あたり $3 と仮定すると、6,000 トークンのシステムプロンプトと 500 トークンの質問のコストは $0.0195 です。プレフィックスをキャッシュから読むと、6,000 × $0.30/M + 500 × $3/M = $0.0033 で、ヒットあたり約 83% 安くなります。無効化についてはキャッシュ戦略の記事で扱っています。
トークンのレート制限とチーム予算
毎分リクエスト数は、LLM のトラフィックの制限としては向いていません。1件のリクエストが 50 トークンのこともあれば 200,000 トークンのこともあるからです。チームごとに毎分トークン数を制限し、max_tokens に上限を設け、ドル建ての月間予算を設定してください。リクエストのサイズは完了するまで分からないため、次のいずれかの方法を選びます。
- 先に確保し、あとで調整する。 推定入力と
max_tokensを先に数え、あとで補正します。OpenAI は、max_tokensと文字数ベースの推定のうち大きいほうを自社の制限に対して数えます。 - 進行中に数える。 Anthropic は出力トークンを生成されるたびに数え、ほとんどのモデルで、キャッシュ読み取りは毎分入力トークン数に含まれません。
- あとで数える。 単純ですが、バーストで超過します。Cloudflare は、同時リクエストが支出上限を一時的に超えることがあると述べています。
カウンターは Redis に置き、すべてのゲートウェイインスタンスで共有します。アルゴリズムと Redis 障害についてはレートリミッターのシステム設計で扱っています。使用量はバージョン管理された価格表で換算し、予算の 80% でアラートを出し、100% でハードストップにするか安いモデルに切り替えるかを決めてください。
何を計測するか
プロバイダーとモデルごとの最初のトークンまでの時間、チームごとの入力、出力、キャッシュトークン、チームと機能ごとのコスト、種類別のエラー、フォールバック率とキャッシュヒット率を追跡します。OpenTelemetry の生成 AI セマンティック規約には gen_ai.usage.input_tokens などの属性がありますが、まだ開発中のため、出力するバージョンを固定してください。シグナルの流れ先はオブザーバビリティのアーキテクチャ図で確認できます。
セキュリティ:ゲートウェイが解決しないこと
ゲートウェイはすべてのプロバイダーキーを保持し、すべてのプロンプトを見ます。そのため、管理者は少人数にし、設定変更は監査し、ログにはすべての呼び出しのメタデータを残す一方で、プロンプトはサンプリングし、マスキングし、短期間だけ保持してください。
OWASP Top 10 for LLM applications が無制限の消費と呼ぶものには効果があります。制限と予算により、ループするエージェントや漏えいしたキーによる請求の膨張を止められます。プロンプトインジェクションは解決しません。OWASP は、完全な防止策があるかどうかは不明だとしており、取得した文書に隠された指示は、ゲートウェイからはデータに見えます。防御策は、最小権限のツール、承認、厳格な出力処理です。AI エージェントのアーキテクチャ図がその例です。
自作か採用か
| ゲートウェイ | 概要 | ライセンスとホスティング |
|---|---|---|
| LiteLLM | 100 以上のプロバイダーに対応する Python プロキシ:仮想キー、予算、フォールバック | MIT と商用エンタープライズ層、セルフホスト |
| Agent Router | 旧 Envoy AI Gateway、Envoy Gateway ベース | Apache 2.0、セルフホスト |
| Portkey AI Gateway | リトライ、フォールバック、負荷分散、ガードレール | MIT、セマンティックキャッシュはホスト版またはエンタープライズのみ |
| Kong AI Gateway | Kong Gateway 向けの AI ポリシー | Konnect またはセルフホスト、セマンティックキャッシュとトークン制限にはエンタープライズライセンスが必要 |
| Cloudflare AI Gateway | キャッシュ、レート制限、フォールバック、ログ | マネージド |
| Azure API Management | トークン制限、セマンティックキャッシュ、トークンメトリクス | マネージド |
Envoy AI Gateway は 2026 年 9 月に、Agent Router として Agentic AI Foundation に参加しました。自作するのは、データ分類によるルーティングのように自社固有の部分だけにしてください。費用がかかるのは、プロバイダーアダプターを最新に保つことです。マネージドゲートウェイは、すべてのプロンプトの経路に第三者を置くことになります。セルフホストなら、Redis、Postgres、アップグレードが自分たちの仕事になります。
LLMゲートウェイの構成図
ダイアグラムの内容
- LLM gateway
- Support chat
- Doc summarizer
- 1 Auth
- 2 Policy
- 3 Cache
- 4 Router
- 5 Adapters
- Postgres: keys, budgets
- Redis: counters, cache
- Self-hosted model
- OpenAI API
- Anthropic API
- Usage and cost log
- virtual key A
- virtual key B
- miss
- sensitive data
- primary
- fallback on 429/5xx
- key → team, limits
- token counters
- lookup by hash
- usage events (async)
図の読み方は次のとおりです。
- 2つのアプリが、プロバイダーキーを持たず、それぞれの仮想キーで、OpenAI 形式の1つのエンドポイントを呼び出します。
- 5つの段階が順に実行され、各段階の上に、その段階が何を判断するかのメモがあります。リクエストは Auth(401、429)またはキャッシュヒットで止まることがあります。
- 3つの宛先は、主系の OpenAI、429 または 5xx 時に破線でつながるフォールバックの Anthropic、機密データ用のセルフホスト vLLM モデルです。
- 段階の下には、キーと予算の Postgres、カウンターとキャッシュ回答の Redis、非同期で書き込まれる使用量ログがあります。
- Markdown ブロックには、1つのチームの設定例が載っています。
LLMゲートウェイの図をわかりやすく描くには
- 1つの箱ではなく、段階を描く。 ゲートウェイを1つの長方形にすると、マスキングがキャッシュの前に行われるのかが見えなくなります。
- 条件はエッジに書く。「fallback on 429/5xx」、「sensitive data」、「miss」などです。
- データがネットワークの外に出る箇所を示す。 外部プロバイダーとセルフホストモデルが違って見えるようにします。
- 非同期の経路は破線にする。 計測やログ記録などです。
- モデルカタログは載せない。 それは設定に属します。
Archboard で作る
- Google または GitHub でサインインし、ダイアグラムを作成します。
- 基本パックから、LLM gateway という名前のフレームを追加します。
- その中に、C4 Model パックから5つのコンポーネントノードを横一列に追加します。1 Auth、2 Policy、3 Cache、4 Router、5 Adapters で、それぞれの上に基本のテキストメモを置きます。
- その下に、データパックから Postgres と Redis、使用量とコストのログ用にデータウェアハウスを追加します。
- フレームの左に、アプリ用として C4 Model パックから2つのコンテナノードを追加します。右には、OpenAI API と Anthropic API 用に2つの外部システムノード、セルフホストモデル用に ML パックからエンドポイントを追加します。
- ラベル付きのエッジを描き、フォールバックと使用量イベントは破線にします。
- 設定例を入れた Markdown ブロックを基本パックから追加します。
経路を Mermaid のフローチャートで管理している場合は、Mermaid コンバーターで編集可能な最初の下書きに変換できます。この例で使うダイアグラムノードは 15 個で、Free プランの範囲に収まります。
よくある質問
LLMゲートウェイとは何ですか? すべてのモデル呼び出しが通るサービスです。プロバイダーキーを保持し、モデル間のルーティングとフォールバックを行い、キャッシュし、トークン制限と予算を適用し、チームごとの使用量を記録します。
AIゲートウェイと API ゲートウェイの違いは何ですか? API ゲートウェイは HTTP リクエストを制限します。AIゲートウェイはトークン、ストリーミング、プロバイダーのエラーも理解するため、トークン単位の制限、コストの帰属、別モデルへのフォールバックができます。
セマンティックキャッシュとプロンプトキャッシュの違いは何ですか? セマンティックキャッシュは自社のゲートウェイで動作し、似た質問に対して保存済みの回答を返します。プロンプトキャッシュはプロバイダー側で動作し、処理済みのプロンプト先頭部分を再利用します。回答はモデルが新たに書きます。
LLM のリクエストをトークン単位でレート制限するには? Redis にチームごとのトークンバケットを置き、各呼び出しの前に推定入力と max_tokens を確保し、あとで補正し、上限に達したら Retry-After 付きで 429 を返します。
LLMゲートウェイでプロンプトインジェクションを防げますか? 防げません。明らかな攻撃はフィルタリングでき、予算で被害を抑えられますが、文書に注入された指示はデータに見えます。アプリケーション側で、最小権限のツールと承認によって防御してください。