LLMゲートウェイの仕組みとは？エンジニアリングチームのための実践ガイド

LLMゲートウェイは、アプリケーションと、それを経由して接続するモデルプロバイダーとの間に位置し、認証情報の管理と使用状況の追跡を一元的に行える場を提供します。

「今のところ、もうめちゃくちゃ（s**t show）だ」と、あるエンジニアは2026年9月にRedditのr/LLMDevsに投稿しています。

「Claude、OpenAI、AWS Bedrock、そのほか私たちが使っているあらゆる推論プロバイダーのキーを、全員がそれぞれ別々に持っている」

BigGoによるllm-proxy-tk（軽量なFastAPIゲートウェイ）の紹介記事は、この仕組みによってLLMが「企業の水道水」になるとたとえ、ゲートウェイを建物の元栓になぞらえています。

とはいえ、この配管にそこまで信頼を預ける前に、何を設置しようとしているのかを確認しておきましょう。

LLMゲートウェイとは？

LLMゲートウェイは、モデル呼び出しのためのリバースプロキシです。アプリケーションは、OpenAI、Anthropic、Googleなど利用しているLLMプロバイダーに直接ではなく、ゲートウェイにリクエストを送信します。ゲートウェイはそのリクエストを転送し、その過程で設定したルールを適用します。

LLMプロバイダーにはそれぞれ独自のAPIがあり、リクエストの形式も、認証方法も、エラーの返し方も異なります。レート制限や障害のパターンもそれぞれ別です。プロバイダーの前に共通のレイヤーがなければ、プロバイダーを呼び出すアプリケーションがそれぞれすべてを自前で処理することになり、しかもそのやり方は少しずつ異なってしまいます。

水道水のたとえが通用する範囲には限りがありますが、少なくともここまでは当てはまります。プロバイダーの配管工事は、ゲートウェイで一度行えば済むのです。それ以降は、アプリケーションごとに専用のメーター付き接続が割り当てられるため、誰が何を使っているかを把握でき、他の回線に影響を与えずに特定の回線だけを止めることもできます。

LLM、AI、MCP、APIゲートウェイの違いとは？

LLMゲートウェイの仕組み

アプリケーションからモデルへ、そしてまた戻ってくるまで、1件のリクエストの流れを追ってみましょう。

1. リクエストがゲートウェイに到着する：アプリケーションは、一見ごく普通のチャットリクエストを、多くの場合OpenAI互換の形式でゲートウェイのエンドポイントに送信します。アプリケーションから見れば、これがモデルにアクセスするために呼び出すアドレスです。
2. ゲートウェイが、誰がリクエストしているのか、何が許可されているのかを確認する：リクエストを転送する前に、ゲートウェイは認証情報を検証します。多くの場合、それはチームや製品に発行された仮想キーです。入力ガードレールを組み込んでいれば、プロンプトに機密データが含まれていないか、モデルへの指示を上書きしようとする試みがないかをスキャンすることもできます。
3. ゲートウェイが、すでに答えを持っていないか確認する：キャッシュが有効になっていれば、キャッシュの対象となる一致したリクエストには、プロバイダーを再度呼び出すことなく保存済みの応答で返答できます。セマンティックキャッシュを提供するゲートウェイもあり、これは完全に同一ではなくても十分に類似していると判断されるリクエストを探します。FAQのようなトラフィックに適している場合があります。
4. ゲートウェイがリクエストの送信先を選ぶ：リクエストでは、特定のモデルやエイリアスが指定されている場合があります。ゲートウェイは設定から該当するルートを検索します。バックアップルートを設定することもできます。プロバイダーAがタイムアウトした場合、ゲートウェイはプロバイダーBを試すことができます。
5. ゲートウェイが呼び出しを準備し、応答を返す：ゲートウェイは、リクエストを選択したプロバイダーの形式に変換し、プロバイダーへ送る呼び出しを認証します。応答を受け取るとすぐに、アプリケーションが必要とする形式に変換します。
6. ゲートウェイが処理内容を記録する：ロギングが有効になっている場合、ゲートウェイは誰が呼び出したか、どのモデルが処理したか、トークン数、レイテンシ、コストなどの詳細を記録します。冒頭で紹介したRedditのエンジニアに欠けていたのが、まさにこのログです。

ゲートウェイを本番環境に導入する前に知っておくべき4つのこと

前のセクションで説明したことがすべて可能なのは、ゲートウェイが、そこを経由するすべてのリクエストを把握できるからです。それがセールスポイントです。しかしそれは同時に、対策を講じておくべき攻撃対象領域とベンダー依存を説明するものでもあります。

ゲートウェイは今や、AIスタックで最も価値の高い存在になる

ゲートウェイはアクセスを一元化します。そのため、多くの認証情報が1つのサービスから手の届く場所に置かれることにもなります。LiteLLMのデプロイメントが保持または取得しうるものとしてMicrosoftのセキュリティチームが挙げているのは、プロバイダーのAPIキー、LiteLLM自体のマスターキー、仮想キーのレコード、データベース接続文字列、ルーティング設定、テナントポリシーです。

2026年10月、LiteLLMについてCheck Point Researchが2件の高リスクの脆弱性を公表しました：

• CVE-2026-35029では、読み取り専用ユーザーを含む認証済みユーザーが管理機能にアクセスし、インスタンスを乗っ取ることができました。
• CVE-2026-59823では、ユーザーがリクエストを自身の管理するサーバーにリダイレクトし、プロバイダーキーを盗み取ることができました。

どちらもバージョン1.83.9で修正されています。ゲートウェイを利用するアプリケーションが、その設定を変更できるようであってはなりません。

ガードレールには障害時のポリシーが必要

Pillar Securityが2026年10月4日に公開したレビューでは、LiteLLM、Kong、TrueFoundry、Portkey、Azure API Management、Apigeeなど主要ゲートウェイにおけるサードパーティ製ガードレールの統合状況がまとめられています（Pillarはガードレールを販売している企業なので、その推奨事項を読む際にはその点を念頭に置いてください）。

フックとは、リクエスト経路上のポイントのことで、一般的にはプロンプトがモデルに送られる前や応答が返ってきた後に置かれ、ゲートウェイはそこでコンテンツを外部のスキャナーに渡して判定を求めることができます。ブロッキング型のチェックでは、判定が出るまでトラフィックを先に進めずに待機します。Portkeyのドキュメントではこれらをbefore_request_hooksおよびafter_request_hooksと呼んでいます。TrueFoundryでは4つのフックが実行され、MCPツール呼び出しの前後のチェックが追加されています。

ここで、確認すべきことが2つあります：

• スキャナー自体に障害が発生したらどうなるか？リクエストをブロックすれば、未チェックのトラフィックは止められますが、アプリケーションが中断する可能性があります。通過させれば、アプリケーションはそのチェックなしで動作を続けられます。障害ログを見れば後からチェックが漏れていたことはわかり、それはそれで役に立ちますが、実際にチェックを実行したのと同じではありません。
• スキャナーを差し替えられるか？別のプロバイダーがサポートされていない場合、アプリケーションを更新するか、別のプロキシを使って接続する必要があるかもしれません。

TrueFoundryのMCPフックは、ゲートウェイの適用範囲をモデルリクエストからツール呼び出しにまで広げます。しかし、ゲートウェイが検査できるのは、そこを通過するトラフィックだけです。開発者のマシン上でコマンドを実行するコーディングエージェントは、その範囲外にあるかもしれません。

PerplexityのオープンソースツールNumbatは、そちら側を担います。Numbatはローカルフックを通じて対応エージェントに接続し、シェルコマンドやファイル書き込みといった予定されているアクションを、実行前に検査できます。ブロック機能はオプションで、デフォルトではオフになっています。ゲートウェイが把握できるのは、ゲートウェイを経由するモデルトラフィックです。Numbatはそれに加えて、エージェントがその応答を使って何を行うかを可視化します。

ゲートウェイの制御がどこまで及ぶのかを把握する必要がある

Forkast Newsは、異なる方向からゲートウェイへと向かう3つの系統を挙げています：

• LLM特化型ゲートウェイ：LiteLLMやPortkeyは、プロバイダー間の変換、リクエストのルーティング、トークンの追跡といった、モデル呼び出しの処理から出発しました。現在はツール呼び出し向けの制御を追加しつつあります。
• API管理プラットフォーム：Kong、GoogleのApigee、Azure API Managementは、認証、権限、トラフィック管理から出発し、その後モデルやAI固有のルールへの対応を追加しました。
• エージェントネイティブなインフラストラクチャ：たとえばagentgatewayは、MCPやA2Aを含め、エージェントがモデル、ツール、他のエージェントと通信することを前提に構築されています。

選び分けのポイントは、何をルーティングするかです：

• モデル呼び出しだけか？それなら、LLMファーストのゲートウェイから始めるのがよいでしょう。
• すでにAPIルールが数多く整備された企業内でのモデル呼び出しか？それなら、既存のプラットフォームから始めましょう。
• エージェントがツールを呼び出し、そのツールがモデルを呼び出すのか？それなら、そうした接続もカバーされているかを確認しましょう。

共通の単一障害点が生まれる

たとえば、サポート用チャットボットはOpenAIを、リサーチツールはAnthropicを使っていて、どちらも同じゲートウェイを経由して接続しているとします。そのゲートウェイが停止すると、OpenAIとAnthropicが正常に稼働していても、両方のツールがモデルにアクセスできなくなります。

これは実際に起きたことです。2025年6月12日の障害発生時、CloudflareのAI Gatewayのエラー率は最大97%に達しました。このゲートウェイは設定の保存にCloudflareのストレージサービスであるWorkers KVを利用しており、そのサービスに障害が発生していたのです。

ゲートウェイを自社で運用する場合は、1つが停止しても引き継げるよう、別のインスタンスも稼働させておきましょう。ゲートウェイを他社がホストしている場合は、障害時にどのように稼働を維持するのか、復旧中にリクエストがどう扱われるのかを確認しましょう。

LLMゲートウェイで注目すべき主な機能

ゲートウェイには全員の認証情報へのアクセスを委ねることになるのですから、その見返りとして何をしてくれるのかについては厳しく求めるべきです。

• 複数のプロバイダーの前に1つのAPI：コードは1つの形式（多くの場合OpenAI互換）でやり取りし、ゲートウェイが変換を担います。LLMプロバイダー側も歩み寄っています。たとえば、PerplexityのAgent APIはOpenAIのResponses APIインターフェースをサポートしているため、チームは既存のOpenAIクライアントライブラリを再利用できます。
• ルールを付与した仮想キー：チームや製品ごとに専用のキーが発行され、使用できるモデル、リクエスト数の上限、支出を管理するルールが適用されます。
• ルーティングとフォールバック：ゲートウェイは、コスト、速度、特定のプロバイダーなど、設定で重視した条件に基づいてリクエストをモデルに送ります。呼び出しが失敗した場合は、別のモデルを試すことができます。PerplexityのAgent APIでは、異なるプロバイダーのモデルを含め、最大5つのモデルを優先順に指定できます。
• キャッシュ：保存済みの応答を使えば、プロバイダーへの再度の呼び出しを省けます。同一のリクエストを照合するゲートウェイもあれば、意味が類似したリクエストまで照合できるものもあります。キャッシュされた応答をユーザーやチームごとに分離できるか、パーソナライズされた回答や時間に左右される回答についてキャッシュをオフにできるかを確認しましょう。
• ストリーミングと一貫したエラー処理：応答は生成されると同時に届き、プロバイダーのエラーはアプリケーションが処理できる形式に変換されます。AIガードレールを追加した場合にどうなるかを確認しましょう。
• ロギングとコストの配分：ゲートウェイは、誰が呼び出したか、どのモデルが処理したか、使用したトークン数、所要時間、推定コストを記録します。ログにプロンプトと応答が含まれるか、どのくらいの期間保持されるかを確認しましょう。
• ガードレールフック：リクエスト経路上で、ゲートウェイがコンテンツを外部のスキャナーに送って判定を求められるポイントです。一般的には、モデルへのリクエストの前や応答の後に置かれます。スキャナーに障害が発生した際にリクエストが停止するのか続行されるのか、また別のスキャナーを接続できるかを確認しましょう。
• アクセスを制限できる管理インターフェース：ゲートウェイは、プロバイダーの認証情報へのアクセスと、全員が使用するルールを管理します。管理者アクセスをアプリケーションのトラフィックとは別に制限できるか、読み取り専用ユーザーが設定を変更できないようになっているかを確認しましょう。元栓には鍵が必要です。

LLMゲートウェイの構築に使えるツール

機能の一覧は、市場全体で重複しています。社内でのモデルアクセスに関するあるRedditのスレッドで、投稿者はこう問いかけていました。専任のエンジニアを必要としないゲートウェイはどれか？

私たちの考えでは、それこそが的を射た問いです。そしてその答えは、作業のどこまでを自分たちで担うつもりかによって、4つあります。

自分で作る

最小限のゲートウェイが担う仕事は限られています。リクエストを受け付け、呼び出し元のキーを確認し、プロバイダーの認証情報を付加し、呼び出しを転送し、結果をログに記録することです。しかし、さまざまなプロバイダーの形式に対応するには手間がかかります。全体を稼働させ続けることも同様です。

すでにEnvoyを運用しているなら、その外部処理フィルターを使って、リクエストと応答を検査・変更するサービスを接続できます。ただし、そのサービスは自分で構築し、運用する必要があります。

ゲートウェイでコストを削減できるかを議論したr/LLMDevsのスレッドで、u/QuanTradinは、すべての呼び出しでトークン数とキャッシュヒットのフラグをログに記録したことで、同一のプロンプトに正規料金を支払っていた2つのジョブを見つけられたと述べています。

「……それを修正したことには、どんなルーティングレイヤーよりも大きな価値があった」

これはあくまで報告された体験談ですが、出発点としては良いものです。ルーティングのための凝った仕組みを構築する前に、まず何にお金を払っているのかを把握しましょう。

オープンソースのゲートウェイをセルフホストする

ここではLiteLLMが一般的な選択肢です。OpenAI互換で、幅広いプロバイダーをサポートし、大規模なコミュニティがあります。Bifrostは、リクエストあたりのオーバーヘッドを低く抑えるよう設計された代替手段です。オブザーバビリティを最優先するなら、Heliconeも検討する価値があります。

LiteLLMも、ほかの製品と同様に、チームによっては限界があります。自前で構築する以外の選択肢を議論したr/aiagentsのスレッドで、u/Own_Bar_920は、LiteLLMはルーティングについては問題なく処理できたものの、チームをまたいだプロンプトのバージョン管理や、モデル切り替え時の継続的な評価では物足りず、別のツールを導入することになったと述べています。

これらは基本的なゲートウェイのルーティングを超えた機能であり、そこが重要な点です。ルーティングが主な目的であれば、LiteLLMは彼らにとって十分に機能していたのです。

すぐに使える機能一覧が手に入り（一部の機能はエディションによって異なります）、ゲートウェイを自社ネットワーク内に置いておけます。その一方で、パッチ適用の責任も自分たちが負うことになります。これは先ほどのCheck Pointによる公表で具体的に示されたとおりです。ゲートウェイの可用性も同様に自分たちの責任であり、これは単一障害点のセクションで示したとおりです。

ただし、それを担当する人員の予算は確保しておきましょう。社内アクセス用のゲートウェイに関するr/LLMDevsのスレッドで挙がっていた懸念の1つが、メンテナンスでした。u/Informal-Writer9685は「メンテナンスに専任のエンジニアを必要としない」ものを求めており、報告されているLiteLLMのアップグレード時の不安定さが、自分たちの規模でも現実的な問題なのか、それとも本番環境に限った懸念なのかを尋ねていました。

マネージドゲートウェイを使う

Cloudflare AI Gateway、Vercel AI Gateway、OpenRouter、Portkeyのホスト型ゲートウェイは、サービスの運用を代行してくれます。互換性のあるアプリケーションであれば、URLの変更とAPIキーの用意だけで、最初のリクエストを通せる場合もあります。

ここでのトレードオフは、すべてのプロンプトがプロバイダーに届く前にサードパーティを経由するようになることです。つまり、コンプライアンス書類に記載すべきデータ処理者が1つ増えることになり、ゲートウェイ自体の障害はベンダー側のインシデントとなるため、自分たちで修正することはできません。

たとえば、2026年2月17日と19日には、キャッシュの依存関係の障害を受けてOpenRouterでそれぞれ38分間と35分間の障害が発生しました。一部の顧客には「User not found」エラーが返され、まったく問題のないAPIキーのデバッグに時間を費やすことになりました。障害の原因はゲートウェイのインフラストラクチャにあったのです。

ただし、OpenRouterは詳細なポストモーテムを公開し、キャッシュの障害によってデータベースに過剰な負荷がかからないよう保護策を追加しており、その点は評価に値します。OpenRouterのようなマネージドゲートウェイはアクセスを簡素化できますが、u/QuanTradinがr/LLMDevsで指摘しているように、請求をまとめても支出が自動的に減るわけではありません。

既存のAPIゲートウェイを拡張する

すでにKong、Apigee、Azure API Managementをサービスの前段に置いているなら、いずれにもAI固有の機能があります。Kong AI Gateway、ApigeeのAIゲートウェイポリシー、Azure API ManagementのAIゲートウェイです。既存の認証、ネットワークルール、運用手順を土台にしながら、プラグインやポリシーを通じてモデルの制御を追加できます。

大企業では、これが組織内の抵抗が最も少ない道になる可能性があります。ただし、AI機能はスタンドアロンのゲートウェイと比べるとまだ歴史が浅いものです。トークンベースのレート制限とストリーミングについては、使用予定のプラグインやポリシーをすべて組み合わせた状態でテストしておきましょう。

ですから、ぜひマスターバルブ、つまり万能のゲートウェイを導入してください。とはいえ、冒頭で紹介したエンジニアの言い分にも一理あります。企業のモデルへのアクセスが、たまたま引き出しに正しいキーをしまっている誰かに左右されるべきではありません。

ゲートウェイはそれらのキーを一元管理することでこの問題を解決しますが、その分、引き出しを開けっ放しにしておくリスクはむしろ高まります。それが誰の引き出しなのかを把握しておく必要があります。

LLMゲートウェイに関するよくある質問

LLMゲートウェイは無料ですか？

LLMゲートウェイというカテゴリ全体についてであれば、無料版を提供しているものもあります。

LLMゲートウェイには、無料のオープンソースソフトウェアから月額約50ドルからの有料プランまであり、エンタープライズ導入向けにはカスタム料金も用意されています。また、代わりに一定の割合を手数料として課すものもあります。たとえば、OpenRouterのStandardプランでは、クレジット購入額に5.5%が上乗せされます。

最適なLLMゲートウェイはどれですか？

どこまでの作業を自分たちで担うつもりかによって決まります。

• セルフホストして設定を自分で管理したい場合は、BifrostやHeliconeを検討してみてください。
• サービスの運用を外部に任せたいチームには、OpenRouterやVercel AI Gatewayのようなマネージド型の選択肢が適しています。
• すでにKongやAzure API Managementを利用している場合は、まずそれらのAI機能を確認してください。

候補を絞り込んだら、プロバイダーに障害が発生した場合の挙動も含めて、自社の実際のリクエストでテストしてください。

AWSにはLLMゲートウェイがありますか？

はい。Amazon Bedrock AgentCore Gatewayは、AWSが「推論ターゲット（inference targets）」と呼ぶ仕組みを通じてモデル呼び出しをサポートしています。これにより、アプリケーションは単一のエンドポイントからAmazon Bedrock、OpenAI、Anthropicなどのプロバイダーにアクセスでき、プロバイダーの認証情報とルーティングはゲートウェイが処理します。