2026年初め、Uberは社内でAIコーディングツールの利用を奨励するために利用量を社内ランキングで競わせました。その結果、わずか4か月でAI関連の年間予算を使い切ってしまいました（TechCrunchが報じています）。

使われたのはどれも普段のエンジニアリング業務、プロンプトの検証や社内ツールの構築、エージェント型ワークフローの実行です。リクエストはトークン単位で課金され、上限もなければ誰が使ったかの内訳もないまま積み上がり、経理担当がその年の予算がすでに底をついていたことに気づいたのは4月でした。

Uberの一件が表沙汰になっただけで、同じような静かな予算超過は他社でも起きています。こうした予算超過がなぜ繰り返されるのか、その構造的な要因は本シリーズ第1回のエンタープライズAIが予算超過に陥る理由で詳しく掘り下げています。

多くの組織では、各アプリケーションが単一のフロンティアモデルを直接コードに埋め込み、タスクの難易度にかかわらずすべてのリクエストをそのモデルに送り、本番環境でモデルが何をしているのかを可視化する手段を持っていません。

大規模言語モデル（LLM、Large Language Model）用のGatewayは、この利用状況を統制するレイヤーです。アプリケーションとその呼び出し先であるモデルプロバイダーの間に立ち、どのモデルが各リクエストを処理するか、そのリクエストにいくらかかるか、そもそもその呼び出しが必要だったかを判断します。本記事ではLLM Gatewayを定義し、混同されがちなAPI GatewayやAI Gatewayとの違いを整理したうえで、AIスタックのどこに位置づけられるかを示します。

本記事は、CDataが9月中旬まで毎週火・木曜日に配信しているAI Gatewayに関するエグゼクティブ向け学習シリーズの第4回です。

シリーズ全体はこちら: AI Gatewayとは？企業のAI活用を成功させる全8回学習シリーズ

概要

定義: LLM Gatewayは、アプリケーションと1つ以上のモデルプロバイダーの間に立つインフラ層です。単一のAPIを公開しながら、マルチモデルのルーティング、コスト管理、セマンティックキャッシュ、可観測性、フェイルオーバーを一元化します。

位置づけ: LLM Gatewayが統制するのはモデルのトラフィックです。ツール呼び出しやデータアクセスまで統制する、より広義のAI Gatewayの内側に位置し、エージェントとツール間のやり取りを統制するMCP（Model Context Protocol）Gatewayとは並行して動きます。

なぜ今なのか: 企業のモデル利用コストは半年ごとに倍増しており、コスト・信頼性・ベンダーロックインという、Gatewayが吸収するはずの圧力を企業がまっさきに感じるのがこのモデル層です。

LLM Gatewayとは？

LLM Gatewayは、アプリケーションと1つ以上のモデルプロバイダーの間に立つインフラ層です。単一のAPIを公開しながら、マルチモデルのルーティング、コスト管理、セマンティックキャッシュ、可観測性、フェイルオーバーを一元化します。この単一インターフェースこそがLLM Gatewayの存在理由です。各チームがプロバイダーごとに別々のSDK・認証設定・請求アカウントを維持する代わりに、Gatewayと1度だけ連携すればよくなり、モデルの切り替えやフォールバックの追加はコードの変更ではなく設定変更で済むようになります。

まっとうなLLM Gatewayは4つの機能で定義されます。1つ目はルーティングとフェイルオーバーで、どのモデルが各リクエストを処理するか、プロバイダーの調子が悪いときにトラフィックをどこへ逃がすかを決めます。2つ目はコストの追跡と制御で、トークンごとの利用をチームやプロジェクトに割り当て、使いすぎる前に上限をかけます。3つ目は可観測性の提供で、呼び出しごとのルーティングの判断・レイテンシ・トークン使用量を記録します。4つ目はセキュリティガードレールの適用で、リクエストがプロバイダーに届く前にスクリーニングします。

より本質的なメリットは疎結合にあります。アプリケーションが特定プロバイダーのSDKではなく1つの安定したインターフェースとだけ会話するようになれば、モデルの選択は後から作り直すアーキテクチャ上の決定ではなく、実行時の判断に変わります。

LLM GatewayとAPI Gateway、何が違う？

「それってAPI Gatewayがすでにカバーしているのでは」と思うのも無理はありません。Application Programming Interface（API）Gatewayは成熟した実績のあるインフラで、認証・レート制限・バージョニング・REST サービスのライフサイクル管理を担い、同期的で料金が固定のHTTP呼び出しを前提に作られています。モデルのトラフィックは、その前提のいくつかを一度に崩します。課金は呼び出し単位ではなくトークン単位で発生し、レスポンスも単一のペイロードではなく段階的にストリーミングで返ります。脅威モデルには認証バイパスだけでなくプロンプトインジェクションが含まれ、キャッシュを効かせるにはURLの完全一致ではなくリクエストの意味的な近さが鍵になります。

コストの見え方の差がいちばんわかりやすい例です。API Gatewayが教えてくれるのは、あるエンドポイントに何件のリクエストが来たかまでです。LLM Gatewayなら、各リクエストが何トークン消費したか、モデル別にいくらかかったか、どのチームがそのコストを発生させたか、そしてセマンティックキャッシュがヒットしていればその呼び出し自体を避けられたかまでわかります。

これはAPI Gatewayの設計上の欠陥ではなく、そもそも想定していた役割が違うというだけの話です。両者は補完関係にあり、サービス・マイクロサービス層にはAPI Gateway、モデルアクセス層にはLLM Gatewayを使うのが基本です。本番環境でAIを運用する企業の多くは両方を併用しています。エージェントとツール間のトラフィックについては、本シリーズのMCP Gatewayを取り上げた回で並行するケースを扱いました。

LLM GatewayとAI Gateway、線引きはどこ？

「LLM Gateway」と「AI Gateway」という用語は、ベンダーやアナリストによって使われ方が一定していません。名称だけでは、目の前にあるのがどちらなのか判断できません。モデルルーティングのミドルウェアという意味で両者を同じものとして使うベンダーもいれば、「AI Gateway」をエージェント型のツール呼び出しやMCPアクセスまで統制するより広い制御プレーンの呼び名として使い分けるベンダーもいます。

もっともすっきり整理する方法はスコープで区別することです。LLM Gatewayはモデル側のインフラで、アプリケーションとプロバイダーの間のトラフィックをルーティングし、コストを最適化し、モデル呼び出し層での可観測性を提供します。より広い意味でのAI Gatewayは、それを内側に含んだうえで、Model Context Protocol（MCP）を通じたツール呼び出しの統制を追加したものです。

この違いは実務にそのまま直結します。チャットボットや要約ツール、コーディング支援のように、アプリケーションがモデルのAPIを直接呼び出しているチームにとっては、LLM Gatewayが主たる統制層として適切です。一方、業務データや社内ツールに手を伸ばすエージェントを展開しているチームにとっては、LLM Gatewayは必要条件ではあっても十分条件ではありません。データアクセスを統制する層が別途必要になるからです。この「モデルルーティングは一方、統制されたデータアクセスはもう一方」という切り分けが、それぞれの構成要素がスタックのどこに収まるかという次の問いにつながります。

もう1つ紛らわしい呼び名が「LLM Proxy」です。こちらはGatewayよりもさらに狭いスコープを指すことが多く、単一のエンドポイントで複数プロバイダーのAPI差分を吸収し、リクエストをそのまま転送するだけの軽量な中継層を指すのが一般的です。コスト管理・可観測性・フェイルオーバーまで一元化するLLM Gatewayに対し、LLM Proxyはルーティング自体を担いません。「窓口を1つにする」ことに機能を絞った、いわば簡易版と捉えると整理しやすくなります。小規模なプロトタイプならProxyで足りても、本番運用でコストと信頼性を管理したいならGatewayの機能セットが必要になるでしょう。

実装の選択肢も押さえておくと判断しやすくなります。代表的なものとしては、OSSで自前構築するLiteLLM、既存のAPI管理基盤の延長で使えるKong AI Gateway、エッジ側で手早く導入できるCloudflare AI Gatewayなどが挙げられます。自前で組むか、マネージドのサービスに寄せるか、という選択になります。この選択は、社内にどれだけ運用リソースを割けるかで決まる部分が大きいと思います。

モデルルーティングはどう動く？

モデルルーティングは、LLM Gatewayによるコスト削減の大半を支える仕組みです。すべてのリクエストを同じフロンティアモデルに送る代わりに、Gatewayは届いたリクエストを1件ずつ確認し、複雑さ・コスト・レイテンシ・ポリシーに基づいて最も適したモデルへ振り分けます。多段階の推論が必要なクエリはフロンティアモデルへ、単純な検索や分類はより小さく安価なモデルへ回ります。ここで生まれる削減効果は、多くのチームが過小評価している事実、つまり本番トラフィックのかなりの割合はそもそもフロンティアモデルを必要としていなかった、という事実に由来します。

この点は具体的な数字でも裏付けられています。LMSYSがICLR 2025で発表したオープンなフレームワークRouteLLMは、公開されている選好データでルーターを学習させたところ、最良のルーターはMT Benchのベンチマークで GPT-4性能の95%を維持しながら、高価なモデルへ回すリクエストをわずか14〜26%に抑えました。これはランダムに割り振る場合と比べて、およそ75〜85%のコスト削減にあたります。具体的な数値はベンチマークやモデルの組み合わせによって変わるため、この数字そのものを目標にするのではなく、この手法が効くことの裏付けとして受け止めてください。

セマンティックキャッシュはこの効果をさらに底上げします。新しいプロンプトが直近のものと意味の上で十分に近ければ、Gatewayは保存済みの回答を返してモデル呼び出し自体を省略します。すべてのリクエストをプロバイダーに届く前に必ず経由するGatewayだからこそ、この仕組みを実装するのに適した場所になるのです。

可観測性やフォールバックはどう機能する？

LLM Gatewayが本番環境で存在価値を発揮する理由の半分はコスト管理ですが、残り半分は運用面の信頼性であり、その出発点が可観測性です。Gatewayを通るすべてのリクエストは、ルーティングの判断・レイテンシ・トークン数・コストとともに記録されます。そのおかげで、「今モデルは何をしているのか」という問いは、調査案件ではなく1回のクエリで済む話に変わります。これは多くのチームが最初の本番障害のあとに慌てて後付けする診断レイヤーです。最初から組み込んでおくことこそが、その障害を不意打ちにしないための備えになります。

信頼性のパターンとしてもっとも重要なのがフェイルオーバーです。複数のプロバイダーを設定したGatewayなら、メインのモデルが使えなくなったり、レイテンシの閾値を超えたりしたときに、自動的にセカンダリのモデルへ切り替えられます。これにより、単一プロバイダーの障害が機能停止につながりかねなかった事態を、ユーザーが気づかないうちに処理されるルーティングイベントへと変えられるわけです。

自社でGPU（Graphics Processing Unit）インフラを持つ企業では、これに近いパターンもよく見られます。通常のリクエストはオンプレミスのモデルに回し、ローカルの処理能力が足りなくなったときだけ、クラウドプロバイダーへフォールバックする運用です。

これらすべての上に乗るのが予算の制御です。すべてのトークンが1か所を通るからこそ、Gatewayは支出が閾値に近づいた時点でアラートを出せます。チームやプロジェクトごとに消費量の上限をかけ、暴走したワークフローからのリクエストをブロックすることもできます。読めなかったコストが、管理可能なコストに変わるということです。

LLM Gatewayが効くのはどんな場面？

LLM Gatewayが投資に見合うのは、モデル呼び出しが「試しに動かしてみる」段階を越えて、業務の一部として回り始めたときです。実務では、おおむね次の4つのパターンで採用されています。

• 社内AIプラットフォーム：複数の部門がそれぞれにモデルを呼んでいる状態を共通の入口へ集約し、権限とコストを部門別に配分したい場合です。

• マルチプロバイダーのSaaS：自社プロダクトにAI機能を組み込んでいて、特定プロバイダーの障害や価格改定に事業を左右されたくない場合です。

• 規制業界での利用：金融や医療のように、どのプロンプトがどのモデルに渡ったのかを監査ログとして残す必要がある場合です。

• エージェント基盤：エージェントが業務データや社内ツールを呼び出す構成で、モデル層とデータ層の両方に統制を効かせたい場合です。CData Connect AIと組み合わせれば、モデル呼び出しの記録とデータアクセスの記録を突き合わせられます。

LLM GatewayはAIスタックのどこに位置する？

本番環境のAIを3つの層に分けて考えると理解しやすくなります。AI機能が動くのがアプリケーション層、モデルが動きLLM Gatewayが統制するのがモデル層、そして自社の業務データが存在し、統制・保護・監査可能な状態にあるべきなのがデータ層です。

多くのチームは最初の2層には慎重に頭を使いますが、3つ目の層は作り込みが手薄になりがちで、停滞しているAI導入プロジェクトの多くはこのデータ層に原因をたどることができます。データ層をどう設計するかという論点はMCPの設計パターンを整理した記事でも取り上げているので、あわせて参考にしてください。

この分け方でスタックを組んだ実例もあります。ノーコードのAIプラットフォームを提供するTheNoah.aiでは、顧客ごとに個別の連携を作り込む方式が拡大の足かせになっていました。MCPベースの共通インターフェースでSAPやOracle、Microsoft ERPへのアクセスを標準化したところ、データ連携にかかる期間を80%以上（数人月から1週間未満へ）短縮し、2週間で本番稼働にこぎつけています。モデル側をどれだけ工夫しても縮まらなかったのは、結局データ側の作り込みだったということです。

LLM Gatewayはこのギャップを埋めません。もともとそのために作られたものではないからです。LLM Gatewayはトラフィックを効率よくモデルへ振り分けますが、回答の背後にあるデータへモデルがどうアクセス権を得るのか、そのデータがCRMにあるのかERPにあるのかHRシステムにあるのか、あるいは別のシステムオブレコードにあるのかまでは判断しません。それはデータ層の問題です。業務データにアクセスするエージェントをどう安全に本番投入するかは、Production-readyなエージェント設計のリファレンスアーキテクチャで具体的に解説しています。

CDataでは、このスタックを完成させるデータアクセスプラットフォームとしてConnect AIを提供しています。CData Connect AIは、単一のMCP準拠インターフェースを通じて、AIアプリケーションやエージェントに数百の業務データソースへの統制された、リアルタイムのアクセスを提供します。そのため、モデルに届くデータは、モデルに渡る前の時点ですでに権限フィルタ済み・スキーマ最適化済み・監査ログ記録済みになっています。

LLM Gatewayがどのモデルがクエリを処理するかを管理するのに対し、Connect AIはそのモデルが読み書きしてよいデータを管理します。両者を組み合わせることで、本番の企業向けAIを支える完全な制御プレーンができあがります。モデル層を統制するLLM Gateway、データ層を統制するデータアクセスプラットフォーム、そしてその上に乗るアプリケーション群、という構成です。

導入前に知っておきたい注意点

ここまでの利点と引き換えに、受け入れることになるコストもあります。事前に把握しておきたい点は3つです。第一に、すべてのモデル呼び出しが1か所を通る設計は、そのGateway自体が単一障害点（SPOF）になり得るということでもあります。冗長化やヘルスチェックの設計は最初から必要になるでしょう。第二に、ルーティングの判断を挟む分だけレイテンシは増えます。対話型のユースケースでは、この数十ミリ秒が体感に響くこともあります。第三に、ルーティングのポリシーや予算の閾値は放っておいても最適にはなりません。継続的に見直す担当をどこに置くかを、導入前に決めておいたほうが安全です。

自社にLLM Gatewayは必要？導入判断の目安

導入すべきかどうかは、次の3点で判断できます。

• 複数のモデルプロバイダーを併用しているか：単一プロバイダーの単一モデルで完結しているなら、ルーティングの価値はまだ出にくいと思います。

• モデルAPIのコストが無視できない規模になっているか：目安としては月あたり数十万円を超えたあたりから、ルーティングとキャッシュによる削減幅が導入・運用の手間を上回りやすくなります。

• 本番の可観測性とフェイルオーバーが要件になっているか：モデルが落ちたときに何が起きるかを説明できる必要があるなら、それはGatewayの仕事です。

3つとも当てはまらない、社内の検証用プロトタイプの段階であれば、導入はまだ早いかもしれません。まずはモデル呼び出しのログを取り、どのリクエストがどれだけコストを使っているかを把握するところから始めるほうが、投資の判断もしやすくなるでしょう。

CData Connect AIで業務データへ安全にアクセス

LLM Gatewayが企業にもたらすのは、モデルのトラフィックをルーティングし、計測し、可視化し続けるための1つの場所です。より難しいもう半分の問題、つまりそれぞれの回答の背後にあるリアルタイムのデータへモデルが統制されたかたちでアクセスできるようにすることは、CData Connect AIが担う役割です。Connect AIは、SalesforceやSAPからSnowflake、ServiceNowまで、数百の業務データソースへの統制された、リアルタイムのアクセスを、単一のMCP準拠インターフェースを通じて提供します。

モデルのトラフィックはLLM Gatewayが、データアクセスはConnect AIが担います。無料トライアルを開始すれば数分で最初のデータソースを接続でき、モデルルーティングの隣にデータアクセス層をどう組み込むかはドキュメントで確認できます。

よくある質問

モデルの先、データ層もConnect AIで固める

この記事で見てきたように、LLM Gatewayが管理してくれるのはモデル呼び出しのコストとルーティングまでです。そこから先、モデルが実際に読み書きする業務データの権限管理・スキーマ設計・監査ログの整備は、また別の仕事として残ります。CData Connect AIなら、SalesforceやSnowflakeをはじめ数百の業務データソースを、権限フィルタ済み・監査ログ付きのMCPサーバーとしてノーコードで公開でき、SDKの実装やセキュリティ設定を自分たちで組み上げる手間を省けます。

認証やコンプライアンス、モニタリングまで含めた企業導入に耐える設計になっているため、LLM Gatewayでモデル層を固めたチームが、次にデータ層を固める先としてそのまま選べます。

Connect AIの14日間無料トライアルを今すぐ開始して、最初の業務データソースを数分で接続してみてください。