LLM ProxyとAI Gateway：アーキテクチャ、制御、選択

LLMプロキシとAIゲートウェイは同じネットワーク上の位置に配置できますが、必ずしも同じ責務を担うわけではありません。プロキシの主な役割はモデルへのリクエストとレスポンスの転送です。AIゲートウェイは通常、それに加えてルーティングポリシー、フォールバック、使用量記録、コストの帰属、ワークロード単位のアクセスルールなど、モデルを認識した制御を提供します。

これらの名称は標準化されていません。モデルを認識するゲートウェイを「プロキシ」と呼ぶ製品もあれば、管理されたエンドポイントに近い機能を「ゲートウェイ」と呼ぶ製品もあります。選択するときは名称ではなく、必要な責務、実際に検証できる動作、そのレイヤーを使わない場合にアプリケーションチームが自ら構築・運用する必要がある機能を比較することが重要です。

製品名ではなく責務から考える

どちらのレイヤーも、一般にはアプリケーションと1つ以上のモデルプロバイダーの間に置かれます。

アプリケーションまたはCoding Agent
        ↓
LLMプロキシまたはAIゲートウェイ
        ↓
モデルプロバイダーと選択されたモデル

この図だけでは、中間レイヤーが実際に何を行うのかは分かりません。評価は責務のマトリクスから始めると明確になります。

責務	転送中心のLLMプロキシ	モデルを認識するAIゲートウェイ
TLS終端とHTTP転送	一般的	一般的
アップストリームURLとHeaderの処理	一般的	一般的
ストリーミングレスポンスの転送	対応することが多い	通常対応するが、正確なイベント契約は要検証
プロバイダー認証情報の分離	製品による	一般的だが、保存とアクセスの境界は要検証
OpenAI互換リクエストインターフェース	製品による	一般的だが、互換範囲はモデルと機能によって異なる
モデルやプロバイダーを認識したルーティング	限定的、またはアプリケーション側が担当	一般的
リトライと順序付きフォールバック	基本的なアップストリーム再試行まで	モデルや失敗種別を考慮することが多い
ワークロード単位のRate LimitやQuota	通常は外部で管理	一般的
Token、使用量、コストの記録	通常は外部で管理	一般的
リクエスト単位のレイテンシ診断	通常は外部で管理	一般的
ポリシーと監査制御	通常は外部で管理	製品による

ここでの「一般的」は、対応を保証する言葉ではありません。重要な項目ごとに、正確なリクエスト契約、失敗時の動作、生成される記録、運用者が設定できる制御を確認する必要があります。

LLMプロキシが通常担当する範囲

主な目的がアップストリームAPIの前に安定したエンドポイントを置くことであれば、転送中心のプロキシで十分な場合があります。TLS、アップストリームのホスト名、特定のHeader、リクエストサイズ制限、タイムアウト、基本ログを一元化できます。LLM向けのプロキシであれば、Server-Sent Eventsを理解し、ストリーミングレスポンスをバッファリングせずに転送できることもあります。

これは有用な基盤です。アプリケーションに制御されたネットワーク経路を提供し、一部のクライアント環境からプロバイダーの認証情報を分離できます。従来型の認証やネットワークポリシーを適用する場所にもなります。

一方、プロキシがリクエスト形式の変換、プロバイダーの選択、モデルTokenの集計、リクエストコストの計算を始めると、境界は曖昧になります。これらはモデルを認識した動作です。製品名に「プロキシ」が残っていても、AIゲートウェイとして評価すべき段階です。

次のような場合は、シンプルなプロキシから始める判断が合理的です。

• 1つのアプリケーションが1つのプロバイダーと少数の固定モデルだけを使う。
• リトライ、使用量集計、インシデント診断をアプリケーションがすでに担当している。
• プロバイダー固有機能を変換せずにそのまま通す必要がある。
• チームやワークロードごとのルーティングポリシーを必要としない。
• 運用する中間レイヤーをできるだけ小さくしたい。

AIゲートウェイが追加するもの

AIゲートウェイは、モデルリクエストを単なるHTTPトラフィックとして扱いません。要求されたモデル、プロトコル、API Keyポリシー、グループの可用性、各種制限、過去の試行結果を使って、リクエストをどこへ送るか判断できます。その後、最終的な試行をToken使用量、タイミング、ステータス、コスト記録に関連付けられます。

機能の範囲は製品ごとに異なります。たとえば、Cloudflare AI Gatewayのドキュメントでは分析、ログ、キャッシュ、Rate Limit、リトライ、フォールバックをゲートウェイ機能として扱っています。KongのAI Gatewayメトリクスのドキュメントでは、モデル、Token、コスト、キャッシュ、レイテンシ、エラーのメトリクスを説明しています。これらは「ゲートウェイ」がAIを認識するコントロールプレーンを意味することが多い例ですが、普遍的な最低要件を定義するものではありません。

次の要件が複数重なる場合、AIゲートウェイの価値が高まります。

• 複数のアプリケーションやAgentに、個別に帰属できるAPI Keyが必要。
• 要求された同じモデルを複数の適格な経路から提供できる。
• アップストリームの処理やコストが発生する前に制限を適用したい。
• 認証、ルーティング、アップストリーム待機、最初の有効出力、生成時間を切り分けたい。
• モデル使用量と最終課金をリクエスト単位で説明する必要がある。
• プライマリ経路に明示的で順序付きのフォールバックが必要。
• 複数のモデルグループを1つの運用画面で確認したい。

ゲートウェイを導入しても、すべてのプロバイダーが交換可能になるわけではありません。モデル出力の検証、ツール実行の冪等性、アプリケーション内の秘密情報の保護、プロバイダー固有機能のテストも引き続き必要です。

ワークロード別の判断マトリクスを使う

製品カテゴリだけで選ぶよりも、次のようにワークロードから判断する方が実用的です。

ワークロード	主な要件	合理的な開始レイヤー	理由
1つのプロバイダーと1つのモデルを使う社内サービス	安定したネットワーク経路	直接APIまたは小規模プロキシ	ルーティングやコストポリシーが、価値以上の複雑さを増やす可能性がある。
同じモデルに複数の適格経路がある顧客向けアプリ	可用性と試行の証跡	AIゲートウェイ	経路選択、有界なフォールバック、試行単位の診断に共通の責任主体が必要。
エンジニアリングチーム全体のCoding Agent	Key、Quota、使用量の帰属、退職時の無効化	AIゲートウェイ	共有プロバイダーKeyと帰属できない支出が運用リスクになる。
新しいプロバイダー固有機能を使うアプリ	正確なWire Contract	まずネイティブエンドポイント、その後に検証済みのプロキシまたはゲートウェイ	正規化されたAPIでは固有フィールドが未対応または失われる可能性がある。
独自のキューとリトライ制御を持つバッチ処理	スループットとアプリ側の復旧	リトライを無効化または制限したプロキシ/ゲートウェイ	複数レイヤーのリトライが障害と重複処理を増幅する。
規制対象または機密データを扱う処理	データ経路、保持、アクセスの証跡	検証済みの制御に依存	「ゲートウェイ」という名称だけではセキュリティやコンプライアンス境界の証明にならない。

ワークロードの成熟に応じて判断が変わっても問題ありません。最初は1つのプロバイダーへ直接接続し、後からゲートウェイを導入する設計も合理的です。その場合は、モデルクライアントを明確な内部境界の後ろに置き、移行時の契約をテストできるようにします。

見落としやすいトレードオフ

追加される1ホップは実測する

プロキシやゲートウェイはネットワークと処理のレイヤーを追加します。そのコストを1つの平均レイテンシだけで判断することはできません。現実的な同時実行数で、アップストリームHeader、最初の有効出力、該当する場合は最初の可視テキスト、総時間、出力速度を分けて測定します。小さな固定オーバーヘッドが増えても、障害復旧や原因特定が速くなる可能性はありますが、それはワークロード固有の判断であり、普遍的な性能改善ではありません。

互換性は機能単位で確認する

「OpenAI互換」がBase URL、認証Header、Chat Completionsリクエストをカバーしていても、Responsesイベント、Structured Outputs、ツール呼び出し、使用量フィールド、エラー形式まで同一とは限りません。アプリケーションが使う機能を1つずつテストしてください。OpenAI互換APIガイドは移行の基本を、Responses APIとChat Completionsはエンドポイント名だけで互換性を判断できない理由を説明しています。

集約されたレイヤーは障害ドメインにもなる

Key、ルーティング、制限、ログを1つのレイヤーへ集約すると責務は明確になりますが、そのレイヤー自体が重要になります。設定のバージョン管理とロールバック、コントロールプレーンが利用できない場合の動作、運用変更中に進行中のリクエストを完了できるかを確認します。

コスト記録には明確な真実の情報源が必要

公開価格からコストを推定するゲートウェイもあれば、設定価格、グループ倍率、記録された課金式を使うものもあります。価格がいつ選択されるか、リクエストに対して固定されるか、キャッシュTokenやツール料金がどう表現されるか、最終課金を使用量まで追跡できるかを確認してください。AI APIのコスト追跡では、混同すべきでないコストの各レイヤーを説明しています。

移行時の退出コストも評価する

正規化されたリクエストインターフェースを採用する前に、アプリケーションコードがゲートウェイ固有Header、モデルエイリアス、ルート名、ログAPIのどれに依存するかを確認します。有用なゲートウェイは現在の経路を運用しやすくする一方で、基礎となるプロトコルへ戻る道を残します。

3つの実例

1プロバイダーの社内アシスタント

ある社内アシスタントが、1つの固定モデルに対して中程度の非ストリーミングリクエストを送信するとします。アプリケーションは独自のジョブIDを記録し、サーバー側で1つのプロバイダーKeyを保持しています。この場合は従来型のプロキシで十分かもしれません。複数プロバイダーのルーティングや別のコスト制御プレーンを追加しても、現在の課題は解決しません。

それでも将来ゲートウェイを導入できる余地は残します。モデルクライアントを1つの内部インターフェースに隠し、プロバイダーのリクエストIDを保存し、ブラウザやデスクトップクライアントにプロバイダーKeyを公開しない設計が有効です。

複数経路を持つ本番アプリケーション

顧客向けアプリケーションで、1つのアップストリームアカウントが飽和しても要求されたモデルを利用可能にしたいとします。また、どの経路が処理し、どの試行でコストが発生したかを確認する必要があります。フォールバック、課金、診断が同じリクエストIDに基づく必要があるため、これはゲートウェイが適した状況です。

フォールバックは要求された契約を維持すべきです。別モデルへの切り替えは品質、レイテンシ、ツール動作、価格を変える可能性があるため、見えない復旧策ではなく明示的な製品ポリシーにします。信頼できるAI APIルーティングでは、順序付きグループとリクエスト単位の証跡の関係を説明しています。

エンジニアリングチームのCoding Agent

Coding Agentは多数の開発者端末から、長くツール呼び出しの多いセッションを作成できます。1つの共有プロバイダーKeyでは、Quota、帰属、ローテーション、退職時の無効化が困難です。ゲートウェイはワークロード別Keyを発行し、アクセスを制限し、使用量をチームやプロジェクトへ関連付け、障害を確認する場所を一元化できます。

ただし、ゲートウェイはツール操作が安全か、生成されたパッチが正しいかまでは判断できません。リポジトリ権限、サンドボックス、ツール承認、コード検証はモデルルーティング層の外側に残ります。

Modelflareの位置付け

Modelflareは、単なる透過的なHTTP Relayではなく、AIを認識するアクセスおよびルーティングレイヤーを提供することを目的としています。通常のAPI Keyではプライマリのモデルグループと順序付きフォールバックグループを指定できます。Smart API Keyでは設定された戦略に従って適格なグループを評価できます。どちらも要求されたモデルへの適格経路を探す仕組みであり、別のモデルへ暗黙に置き換えるべきではありません。

グループRPMは、実際に選択されたグループに対して、課金およびアップストリームリクエストの前に適用されます。グループが上限に達していれば、次の適格グループを検討できます。残りの経路がなければ、リクエストは429を返します。これにより、ルーティング容量の判断と、すでにアップストリームへ送られた処理を分離できます。

使用量ログは、完了したリクエストをステータス、Token使用量、コスト、タイミングメタデータに関連付けます。タイミングフィールドは、認証、グループ選択、アップストリームHeader、最初のアップストリームイベント、最初の有効出力、最初の可視テキスト、アップストリーム完了、Handler総時間を区別します。このタイミング記録にPrompt、レスポンス本文、完全なAPI Key、元のリクエストBodyを含める必要はありません。

重要な互換性境界もあります。GPT、Codex、OpenAIトラフィックが完全な適応対象です。それ以外のOpenAI互換モデルファミリーは、追加動作が個別に検証されていない限り、元のChat Completionsのパススルーとして扱う必要があります。共通のBase URLは、すべてのモデルが同じResponses、ツール、Structured Outputs契約を提供するという約束ではありません。

現在公開されているモデルとグループはモデルと料金で確認できます。クライアント別の設定方法はModelflare Docsを参照してください。

本番導入前の評価チェックリスト

どちらのレイヤーを選ぶ場合でも、アプリケーションに必要な動作を実際にテストします。

• **プロトコル：**利用しているリクエストとレスポンスの正確な形式を維持できるか。
• **ストリーミング：**イベントをバッファリング、欠落、ツール引数の順序変更なしで転送できるか。
• **モデル識別：**経路が変わっても、要求モデルを暗黙に変更しないか。
• **フォールバック：**どの失敗が対象か、何回試行するか、いつリトライを停止するか。
• **制限：**Rate LimitとQuotaがアップストリーム処理および課金の前に適用されるか。
• **使用量：**該当する入力、出力、キャッシュ、推論、ツール使用量を正しく表現できるか。
• **コスト：**記録された課金が、そのリクエストで使われた価格と経路に結び付くか。
• **診断：**ゲートウェイ時間、アップストリーム待機、最初の出力、生成速度を切り分けられるか。
• **秘密情報：**プロバイダー認証情報、リクエスト本文、レスポンス本文を誰が読めるか。
• **変更管理：**ルーティングやポリシー変更をレビューし、ロールバックできるか。
• **退出経路：**アプリケーションを書き直さずにプロバイダーのネイティブエンドポイントへ戻せるか。

このチェックリストは、同じモデル、Promptの種類、出力長、ストリーミングモード、ツール、リージョン、現実的な同時実行数で実施します。「Hello World」が成功しても、到達性を証明するだけで、本番互換性までは証明しません。

よくある質問

OpenAI互換プロキシはすべてAIゲートウェイですか？

いいえ。OpenAI互換はリクエストインターフェースの一部を説明する言葉で、ゲートウェイは運用上の責務を示します。OpenAI形式のエンドポイントを提供しても、ルーティング、コスト、制限、診断を担当しないプロキシはあります。

AIゲートウェイを使えばプロバイダーKeyは不要ですか？

必ずしも不要にはなりません。プロバイダー認証情報を保持するゲートウェイ、BYOKを使うゲートウェイ、独自の請求関係を提供するゲートウェイがあります。認証情報がどこに保存され、誰が利用・エクスポートできるかを確認してください。

AIゲートウェイでリクエストは速くなりますか？

自動的に速くなるわけではありません。1ホップは増えますが、経路の可用性や診断性が向上する可能性があります。一般的な性能宣伝ではなく、自分のワークロードでリクエスト全体のタイムラインを測定してください。

フォールバックでは別モデルを選ぶべきですか？

アプリケーションがそのトレードオフを明示的に受け入れた場合に限ります。安全な既定動作は、要求されたモデルとプロトコルを満たす別の適格経路を探すことです。モデルをまたぐ置換には、品質、互換性、レイテンシ、価格について個別のポリシーが必要です。

実用上の違いは次のように整理できます。主に制御された転送経路が必要ならプロキシを選びます。モデルを認識するルーティング、ワークロードポリシー、使用量、コスト、リクエストの証跡を1つの責任主体が持つ必要があるならAIゲートウェイを選びます。ただし、製品名だけを根拠にせず、それぞれの責務を個別に検証してください。