コンテンツにスキップ
ファウンダー価格 — 早期顧客向けに固定今すぐ始める →

LLMゲートウェイ：AIエージェントのためのルーティング、認証、コスト管理

LLMゲートウェイは、AIエージェントプロセスとアップストリームモデルプロバイダーエンドポイントの間に配置されたHTTPリバースプロキシであり、すべてのアウトバウンド推論トラフィックのデータプレーンとして機能します。転送前にワイヤー層でオペークなキーハンドルを解決し、スライディングウィンドウカウンターを使用してテナントごとのスロットルクォータを適用し、リクエストごとにOpenTelemetryの支出テレメトリを送信し、アップストリームのP99レイテンシが設定されたしきい値を超えるとサーキットブレーカーを開きます。エージェントアプリケーションコードの変更は不要です。3つ以上の同時推論コンシューマーを実行するフリートはこれを導入すべきです。

LLMゲートウェイは、AIエージェントプロセスとモデルプロバイダーエンドポイントの間のデータプレーンに位置するHTTPリバースプロキシであり、ワイヤー層でのオペークキー解決、スライディングウィンドウカウンターによるテナントごとのクォータ適用、リクエストごとのOpenTelemetry支出テレメトリ、およびサーキットブレーカーフェイルオーバーをアプリケーションコードに対して透明なインフラストラクチャプリミティブとして提供します。

マルチエージェント推論におけるデータプレーンの問題

専用の推論データプレーンなしには、各エージェントプロセスが独自のアップストリーム接続を管理します：環境状態からのキー解決、プロセスごとのクォータなし、リクエストごとのテレメトリなし、アップストリームエンドポイントが劣化しているかどうかの可視性なし。2つのエージェントでは管理可能ですが、20つになると4つの異なる障害モードが発生します。

環境イントロスペクションによるキー漏洩

環境内にプレーンテキストのプロバイダーキーを保持するエージェントプロセスは、たった1つの敵対的な命令でそれを漏洩させる可能性があります。攻撃面はプロセス環境そのもの：os.environ、Linuxホスト上の/proc/self/environ、プロセス状態をシリアライズする詳細なエラートレースバック、AuthorizationフィールドなどのアウトバウンドHTTPヘッダーをキャプチャするデバッグログ設定です。

エージェントに環境状態をエコーさせるプロンプトインジェクション攻撃は、プレーンテキストキーを保持するエージェントに対するドキュメント化された攻撃クラスです（OWASP LLM01:2025）。構造的な修正は入力検証の改善ではありません：エージェントプロセスからプレーンテキストキーを完全に削除することです。Authorizationヘッダーが書き込まれる前にワイヤー層でオペークハンドル（$CRED{openai}）を解決するLLMゲートウェイは、エージェントプロセスが漏洩させられる可能性のある素材を保持しないことを意味します。

OpenLegionのメッシュはこれをインフラストラクチャレベルで実装します：$CRED{}ハンドルはメッシュホスト境界で解決されます。エージェントコンテナは構造的に解決された値に到達できません。指示されていないからではなく、解決がそれらのアドレス空間の外で行われるからです。

共有キースロットリングによるクォータ枯渇

アップストリームモデルプロバイダーはAPIキーレベルでスロットリングします。20のエージェントプロセスが1つのキーを共有するフリートでは、予想レートの10倍のリクエストを発信する単一のプロセス（リトライストーム、暴走ループ、または無制限の推論呼び出しを引き起こすプロンプトインジェクションペイロードによる）が、他の19のキーをレート制限領域に追い込む可能性があります。

ゲートウェイはエージェント識別子をキーとするスライディングウィンドウカウンターを使用してテナントごとのクォータを適用します。エージェントのカウンターが設定された上限に達すると、ゲートウェイはゲートウェイレイヤーでHTTP 429で応答します：アップストリームリクエストはディスパッチされず、プロバイダークォータは消費されず、兄弟エージェントは影響を受けません。

エージェントごとのクォータは、OWASP LLM10:2025（無制限消費）の構造的な緩和策でもあります。敵対的な命令がエージェントに無制限の推論呼び出しを発信させるパターンです。

アップストリームの可視性の欠如

推論データプレーンなしには、リクエストごとのテレメトリは各エージェントプロセス内でのインストルメンテーションを必要とします。これは冗長であり一貫性がありません。ゲートウェイはワイヤー層でリクエストごとにOpenTelemetry OTLPログレコードを送信します：エージェント識別子、アップストリームエンドポイント、モデル名、入力トークン数、出力トークン数、キャッシュヒットトークン、HTTP応答ステータス、リクエスト時間。

リクエストごとの支出レコード（入力トークン × 1k入力あたりの価格 + 出力トークン × 1k出力あたりの価格）はエージェントごとの支出台帳に蓄積されます。この台帳は日次および月次の支出上限、および支出異常アラートをサポートします。

不可視のアップストリーム劣化

プロバイダーエンドポイントは劣化します。キャパシティイベント中のGPT-4oのP99テールレイテンシは12秒に達する可能性があります（OpenLegionインフラストラクチャベンチマーク、2026年6月）。データプレーンにサーキットブレーカーなしには、フリート内のすべてのエージェントがすべてのリクエストでこの劣化を吸収します。

サーキットブレーカーを持つゲートウェイはエンドポイントごとのエラーレートとP99レイテンシを追跡します。設定可能な障害しきい値が超過されると（5回連続の5xx応答、または30秒ウィンドウでP99が8秒を超えるなど）、サーキットが開きます：後続のリクエストはプライマリがタイムアウトを待たずに設定されたフォールバックエンドポイントに即座に転送されます。

OpenLegionの2026年6月のベンチマークは、GPT-4oプライマリ → Claude 3.5 Sonnetフォールバックトポロジーを測定しました：エージェントコードへの変更なしにP99が12秒から3.1秒（3.9倍）に低下しました。

ゲートウェイアーキテクチャ：データプレーンとコントロールプレーン

データプレーン：リクエストごとの適用

すべての推論リクエストはデータプレーンを順番に通過します：

  1. TLS終端：エージェントプロセスはTLSでゲートウェイに接続します。mTLSデプロイメントでは、エージェントも証明書を提示します。mTLSはエージェントとゲートウェイ間のリクエストごとの認証トークンの必要性を排除します。

  2. ワークロードID解決：ゲートウェイは接続するワークロードをテナントIDにマッピングします。mTLSデプロイメントでは、クライアント証明書に埋め込まれたSPIFFE SVIDがワークロードIDを伝えます。

  3. オペークハンドル解決：ゲートウェイはアウトバウンドAuthorizationヘッダーを$CRED{}ハンドルパターンで検査します。一致するハンドルはゲートウェイのバッキングシークレットストアに対して解決されます。

  4. クォータチェック：ゲートウェイはテナントのスライディングウィンドウカウンターをインクリメントし、設定された上限と比較します。カウンターが上限を超えると、ゲートウェイはRetry-Afterヘッダーと共に429を返します。アップストリーム接続は開かれません。

  5. サーキットブレーカーチェック：ゲートウェイはターゲットエンドポイントのサーキット状態を評価します。サーキットが開いていると、リクエストはプライマリを試みることなく即座にフォールバックにリダイレクトされます。

  6. アップストリームディスパッチ：ゲートウェイは独自の接続プールからアップストリームエンドポイントへの接続を開き、応答をストリームバックします。

  7. テレメトリ送信：応答完了時に、ゲートウェイはテレメトリパイプラインにOTLPログレコードを書き込みます。

ウォームパス（キャッシュ内解決済みハンドル、メモリ内クォータカウンター、クローズドサーキット）での総オーバーヘッド：0.7〜2.1ms。コールドパス（アウトバウンドシークレットストアルックアップが必要なキャッシュミス）：2.6〜6.6ms。500ms〜30秒のプロバイダー推論レイテンシでは、ウォームパスのオーバーヘッドは総ラウンドトリップ時間の0.5%未満です。

コントロールプレーン：設定とポリシー

コントロールプレーンはデータプレーンの動作を規制します。主要な責任：

テナントIDとクォータ設定、エンドポイントトポロジー、ハンドル権限スコープ：どのテナントIDがどのハンドルを解決できるか。openai:readスコープのテナントは$CRED{openai}を解決できますが、$CRED{anthropic}は解決できません。これにより、テナント間の横移動が防止されます。

監査ポリシー：OTLPログレコードにどのフィールドが表示されるか。

コントロールプレーンAPIはエージェント側ネットワークからアクセスできてはなりません。GHSA-53mr-6c8q-9789（LiteLLM、CVE-2026-35029、v1.83.0でパッチ済み）は、コントロールプレーンの設定書き込みパスが十分な認可なしにネットワーク到達可能な場合に何が起こるかを示しました。

デプロイメントトポロジー

集中型イングレス

単一のゲートウェイクラスターがエージェントフリートからのすべてのアウトバウンド推論トラフィックを処理します。運用のシンプルさが優先される約50エージェントまでのフリートに適しています。

サイドカーパターン

各エージェントコンテナはループバックインターフェイス上でゲートウェイプロセスを実行します。障害ドメインは1つのエージェントコンテナです。エージェントごとの障害分離が優先される大規模フリート（50+エージェント）に適しています。

メッシュネイティブプロキシ

OpenLegionでは、推論プロキシはメッシュサービスです。メッシュネイティブモデルはワークロードIDをネイティブに処理します：各エージェントコンテナはスポーン時にメッシュ発行のIDを受け取ります。

OpenLegionの見解

LLMゲートウェイの機能セット（mTLS、スライディングウィンドウクォータ適用、OTLP支出テレメトリ、サーキットブレーカーフェイルオーバー）はマルチエージェントフリートのオプションインフラストラクチャではありません。これは最小限実行可能なデータプレーンです。

OpenLegionの2026年6月のインフラストラクチャテストからの3つの測定値がその重要性を数値化します：

フェイルオーバーなしのP99テールレイテンシ：プロバイダーキャパシティイベント中のGPT-4oのみのデプロイメントで12秒。サーキットブレーカーフォールバックとしてClaude 3.5 Sonnetを使用した場合：3.1秒。3.9倍の改善はエージェントアプリケーションコードへの変更を一切必要としませんでした。

キー漏洩攻撃面：すべてのエージェントが環境内にプレーンテキストキーを保持する20エージェントフリートでは、プロンプトインジェクション（OWASP LLM01:2025）によって侵害された単一のエージェントがすべての他のエージェントのアップストリーム接続のキーを漏洩させることができます。オペークハンドル解決を持つゲートウェイ仲介フリートでは、同じ侵害されたエージェントは漏洩させることができる素材を保持しません。

OWASP LLMカバレッジ：ゲートウェイでのテナントごとのクォータ適用はLLM10:2025（無制限消費）に対処します。ハンドルスコープ適用はLLM06:2025（過剰エージェンシー）に対処します。

AIエージェントの認証情報管理パターンを評価しているチームにとって、ゲートウェイのオペークハンドル解決は、そこで説明されているvaultプロキシパターンのデプロイメントレベルの実装です。

LLMゲートウェイ比較

機能セルフホスト (LiteLLM)OpenAI ネイティブOpenLegion メッシュプロキシ
キー解決モデルPostgresバックのキーストアマネージドサービスオペークハンドル → ワイヤー層でのvault
mTLS ワークロードID非対応非対応エージェントコンテナごとのSPIFFE SVID
クォータ適用設定ベース、キーごと組織ごとの制限スライディングウィンドウカウンター、テナントごと
サーキットブレーカーフェイルオーバープラグインベース利用不可ネイティブ、ハーフオープンプローブ付き
OTLP支出テレメトリ部分的エクスポートなしリクエストごと、全フィールド
コントロールプレーン分離手動；デフォルトで公開マネージドプライベートメッシュサブネットのみ
CVE履歴 (2024–2026)GHSA-53mr-6c8q-9789 + その他公開なしなし

フリートに適したゲートウェイの選択

mTLS vs ベアラートークン認証

mTLS（mutual TLS）は、HTTPペイロードが交換される前に、TLSハンドシェイク層でクライアント（エージェント）とサーバー（ゲートウェイ）の両方を認証します。クライアント証明書にはSPIFFE SVID（暗号学的に検証可能なワークロードID）が含まれています。ヘッダーにベアラートークンは送信されず、トークンを発行、配布、ローテーションする必要もありません。

本番のマルチエージェントフリートでは、SPIFFE発行のSVIDを持つmTLSが正しい認証モデルです。トークン管理面を完全に排除します。

スライディングウィンドウ vs 固定ウィンドウクォータカウンター

固定ウィンドウカウンターは時計の境界でリセットされます。エージェントは、1つのウィンドウの最後の数秒と次のウィンドウの最初の数秒に最大速度でリクエストすることで、名目レートの2倍をバーストできます。スライディングウィンドウカウンターは、利用できる時計境界のない連続時間間隔にわたる継続的なカウントを維持します。推論ワークロードには、スライディングウィンドウ適用が正しいモデルです。

テレメトリ粒度要件

リクエストごとのOTLPレコードは、有用なフリートの可観測性のための最低限です。ゲートウェイがすべてのレコードでこれらのフィールドを提供するかどうかを評価します：agent_id、model_id、input_tokens、output_tokens、cache_tokens、upstream_latency_ms、upstream_status。テレメトリを集約するゲートウェイは、エージェントごとの支出異常検出や正確なサーキットブレーカーキャリブレーションをサポートできません。

始める

mTLSワークロードID、スライディングウィンドウクォータ適用、リクエストごとのOTLP支出テレメトリでマルチエージェント推論フリートをデプロイ。

OpenLegionで始めるドキュメントを読むLiteLLMとOpenLegionを比較

よくある質問

LLMゲートウェイとは何ですか？

LLMゲートウェイは、AIエージェントプロセスとアップストリームモデルプロバイダーエンドポイントの間のデータプレーンに位置するHTTPリバースプロキシです。ワイヤー層でオペークなキーハンドルを解決し（エージェントプロセスはプレーンテキストキーを保持しない）、ディスパッチ前にテナントごとのスライディングウィンドウクォータ制限を適用し、リクエストごとにOpenTelemetry支出テレメトリを送信し、アップストリームエンドポイントが設定されたしきい値を超えるとサーキットブレーカーを開きます。これらの機能はエージェントアプリケーションコードの変更を必要としないインフラストラクチャプリミティブとして動作します。

モデルプロバイダーが1つだけの場合でもLLMゲートウェイは必要ですか？

単一プロバイダーのフリートでも3つのゲートウェイ機能から恩恵を受けます：オペークハンドル解決、テナントごとのクォータ適用、リクエストごとのOTLP支出テレメトリ。ウォームパスのオーバーヘッドは0.7〜2.1ms（プロバイダー推論レイテンシ500ms〜30秒に対して無視できる）です。

LLMゲートウェイのサーキットブレーカーフェイルオーバーはどのように機能しますか？

ゲートウェイはローリング観測ウィンドウ内でエンドポイントごとのエラーレートとP99レイテンシを追跡します。設定可能な障害しきい値が超過されると（5回連続の5xx応答、または30秒ウィンドウでP99が8秒を超えるなど）、サーキットが開きます：後続のすべてのリクエストは設定されたフォールバックエンドポイントに即座に転送されます。クールダウン期間後、ゲートウェイはプライマリにハーフオープンプローブをディスパッチします。成功したプローブはサーキットを閉じ、失敗したプローブはクールダウンタイマーを再起動します。OpenLegionの2026年6月のベンチマークは、GPT-4o → Claude 3.5 Sonnetトポロジーでのこれがp99を12秒から3.1秒に削減することを測定しました。

mTLSとは何ですか？なぜLLMゲートウェイに重要なのですか？

mTLS（mutual TLS）は、HTTPペイロードが交換される前に、TLSハンドシェイク層で接続するエージェントプロセスとゲートウェイの両方を認証します。エージェントはSPIFFE SVID（暗号学的に検証可能なワークロードID）を持つクライアント証明書を提示します。HTTPヘッダーにベアラートークンは送信されず、トークンを発行、配布、ローテーションする必要もありません。SVIDから導出されたワークロードIDがハンドルスコープ適用を駆動します：ゲートウェイは接続するワークロードがSPIFFE IDのスコープ内にあるオペークハンドルのみを解決することを許可し、エージェントコンテナが侵害された場合でもテナント間の横移動を防ぎます。

スライディングウィンドウと固定ウィンドウのクォータ適用の違いは何ですか？

固定ウィンドウカウンターは時計の境界でリセットされます。エージェントは1つのウィンドウの最後の数秒と次のウィンドウの最初の数秒に最大速度でリクエストすることで名目レートの2倍をバーストできます（60リクエスト/分が20秒で120リクエストになる）。スライディングウィンドウカウンターは、利用できる時計境界のない連続時間間隔にわたる継続的なカウントを維持します。バーストがアップストリームプロバイダーのスロットリングを引き起こす可能性がある推論ワークロードには、スライディングウィンドウ適用が正しいモデルです。

リクエストごとのOTLPテレメトリと集約支出レポートの違いは何ですか？

リクエストごとのOpenTelemetry OTLPレコードは、すべての推論呼び出しで個別のフィールドをキャプチャします：エージェントID、モデルバリアント、入力トークン、出力トークン、キャッシュヒットトークン、アップストリームレイテンシ、HTTPステータス。これらのレコードはエージェントごとの支出台帳に蓄積され、日次および月次の予算上限（エージェントが上限に達するとゲートウェイがブロック）、支出異常検出（エージェントのリクエストあたりコストがローリングベースラインのN倍の場合にフラグ）、クロスモデルコストベンチマークをサポートします。集約支出レポートはシグナルがリクエストごとの分散にあるため異常検出をサポートできません。

ゲートウェイのコントロールプレーンはエージェント側ネットワークに何を公開すべきでないですか？

コントロールプレーンはクォータ設定、エンドポイントトポロジー、ハンドル権限スコープ、監査ポリシーを管理します。外部アクセスパスのないプライベートサブネットにデプロイされるべきです。GHSA-53mr-6c8q-9789（LiteLLM、CVE-2026-35029、v1.83.0でパッチ済み）は、管理APIでの不十分な認可を文書化しました。エージェント側ネットワークはゲートウェイのデータプレーンポートのみに到達できるべきです。

フリートのサーキットブレーカーしきい値をどのようにキャリブレートすればよいですか？

2〜4週間の本番トラフィックにわたってプロバイダーエンドポイントごとのP50、P95、P99レイテンシヒストグラムを収集します。サーキットブレーカーオープンしきい値は、プロバイダーの通常のSLAに比べて明確に劣化したP99値に設定するべきです（通常は中央値P99の2〜3倍）。ハーフオープンプローブ前のクールダウン期間はプロバイダーの典型的な回復時間を超えるべきです（30〜60秒が合理的なベースライン）。