LLM ゲートウェイとは?
すべてのアプリ、エージェント、IDE が呼ぶ単一のエンドポイント — そしてモデル通信をルーティングし、計測し、保護し、監査する一か所。
LLM ゲートウェイ · AI ゲートウェイ / LLM プロキシ / LLM ルーター
この言葉は緩く使われています。同じ層を AI ゲートウェイ、LLM プロキシ、LLM ルーターと呼ぶベンダーもあります。本ページでは正確に定義し、混同されがちなものと切り分け、導入すべきでない場面も明示します。
LLM ゲートウェイとは?
LLM ゲートウェイは、アプリケーションとモデルプロバイダの間に位置するサービスです。アプリは 1 つのエンドポイントを呼び、ゲートウェイが各リクエストを設定済みのモデルへ転送し、プロトコルを変換し、プロバイダの鍵を保持し、利用量を記録します。あなたの通信で学習せず、プロンプトを書き換えず、モデルを置き換えもしません。
- •モデルではなくインフラです — モデルはあなたが選んだプロバイダのままです。
- •1 つのエンドポイントで、チャットアプリ、コーディングエージェント、バッチ処理、リアルタイム音声、MCP ツール呼び出しを扱えます。
- •有用な線引き:リクエスト経路はゲートウェイが、プロンプトはアプリが持ちます。
LLM ゲートウェイは実際に何をするのか?
4 つの仕事です。各リクエストを適切なモデルへルーティングする、プロトコルを正規化してどのクライアントからもどのプロバイダにも接続できるようにする、鍵とアクセス制御を集約する、すべての呼び出しをコストと監査のために記録する。キャッシュ、予算、コンテンツ検査はこの 4 つの上に載ります。
- •ルーティングとフォールバック:エージェントの役割ごとにモデルを選び、5xx やタイムアウト時は別プロバイダで再試行し、上流の鍵をプールします。
- •プロトコル変換:4 系統のチャットプロトコルを双方向に変換するので、クライアントは既存の SDK を使い続けられます。
- •ガバナンス:鍵グループ、リクエストヘッダーによる入場制御、テナント別クォータ、SSO と SCIM、リクエスト単位の監査ログ。
- •可観測性:鍵・チーム・モデル別に分単位のトークンとコスト時系列。
なぜ企業はモデルの前にゲートウェイを置くのか?
モデル利用が 1 チームの問題ではなくなるからです。複数のチーム、ベンダー、エージェントがモデルを呼び始めると、論点は調達の論点になります。誰がどのモデルを使えるか、部門ごとの費用はいくらか、データは外部に出たか、プロバイダ変更にどれだけの工数がかかるか。ゲートウェイはこれらをコード変更ではなく設定で答えます。
- •コスト配賦:呼び出しごとに鍵とタグが付くので、チーム別に費用を分けられます。
- •データ経路:ゲートウェイはあなたのネットワーク内で動作し、リクエストは設定した宛先にのみ送られます。
- •継続性:プロバイダ障害やモデル変更はルーティング層で処理され、各アプリを改修しません。
- •調達:セルフホスト + BYOK により、鍵と通信は自社のプロバイダ契約の下に留まります。
どういうときに LLM ゲートウェイが必要か?
次のうち 2 つ以上が当てはまるときです。モデルプロバイダが 2 社以上、利用チームが 2 つ以上、コンプライアンスやデータ所在地の要件がある、あるいは請求書を誰も説明できないほど支出が大きい。その線より下では、プロバイダ API を直接呼ぶほうが簡単で安く済みます。ゲートウェイは運用対象が 1 つ増えるということです。
- •能力・コスト・冗長性のために 2 社以上を使っている。
- •チーム別・顧客別のコストレポートが繰り返し求められる。
- •データを特定のネットワーク・リージョン・テナント外に出せない。
- •複数のエージェントと IDE が今 1〜2 個の API キーを共有している。
ゲートウェイが誤った選択になるのはどんなとき?
チームが 1 つ、プロバイダが 1 社、アプリが 1 つだけのときです。ゲートウェイはホップ、デプロイ、オンコール対応面を増やします。月次のモデル費用が予測でき、コンプライアンス要件も単純なら、プロバイダ API を直接呼び、2 社目・2 チーム目・最初の監査依頼が来た時点で再検討してください。
- •1 社のプロバイダ上のプロトタイプや単一の社内ツールには不要です。
- •プロンプト管理やモデル評価は別の製品で、ゲートウェイでは代替できません。
- •どんなゲートウェイもプロバイダ契約を読む手間をなくしません。
ゲートウェイは中継サービスやプロバイダ SDK の直接利用とどう違う?
中継サービスはあなたの代わりにプロバイダへ通信を転送し、しばしば鍵を預かり手数料を上乗せします。自分で運用するゲートウェイは鍵と通信を自社ネットワークに留め、ルーティング・計測・ポリシーを加えます。プロバイダ SDK の直接利用はこの間接層を省けますが、再試行やプロトコル、計測のロジックが各アプリに散らばります。
- •プロトタイプなら中継サービスでも構いません。代償はプロンプトと鍵が自社ネットワークの外に出ることです。
- •SDK のみは 2 社目のプロバイダが現れるまで最も安価です。その時点で全アプリに同じ接着コードが必要になります。
- •3 つのうち「誰がいくら使ったか」を答えられるのはゲートウェイだけです。
| 観点 | セルフホスト型ゲートウェイ | 中継 / アグリゲーター | プロバイダ SDK のみ |
|---|---|---|---|
| 動作場所 | 自社 VPC またはオンプレミス | ベンダーのクラウド | 各アプリ内 |
| 鍵の保持者 | 自社のシークレットストア。実行時はゲートウェイのメモリ | 中継ベンダー | 各アプリ |
| モデルの範囲 | 設定した任意のプロバイダ | ベンダーのカタログ | SDK ごとに 1 社 |
| ルーティングとフォールバック | 役割別・鍵別・プロバイダ跨ぎ | ベンダーのカタログ内に限定 | 自社で実装 |
| コストレポート | 鍵・グループ・モデル別、自社の台帳から | ベンダーのダッシュボード | 自作した範囲 |
| 監査範囲 | 自社が保有するリクエスト単位のログ | ベンダーのログ | 各アプリに分散 |
ゲートウェイはセルフホストと SaaS のどちらにすべき?
鍵、プロンプト、ログを自社ネットワークの外に出せない、あるいは調達がこれ以上サブプロセッサを認めない場合はセルフホストです。プラットフォームチームがなく運用をゼロにしたい場合は SaaS が有利です。判断を分けるのは流行ではなく、あなたの通信を誰が読めるかという一点です。
- •セルフホストのコストはコンテナ、アップグレード、運用手順書です。SaaS のコストはサブスクリプションとサブプロセッサ審査です。
- •ハイブリッドもあります。セルフホストのデータプレーンとベンダーのコントロールプレーンで、プロンプトは内側に残ってもメタデータは外に出ます。
- •求めるべきはデータフロー図であり、マーケティングページではありません。
| 観点 | セルフホスト | SaaS |
|---|---|---|
| データ経路 | 自社ネットワーク内に留まる | ベンダーを経由する |
| 鍵の保管 | BYOK、ゲートウェイのメモリのみ | ベンダー管理または転送 |
| 運用コスト | コンテナとアップグレードを自社で | ベンダーが運用 |
| 初回利用まで | Compose ファイル 1 つ | サインアップ |
| コンプライアンス面 | 自社の DPA とサブプロセッサ | ベンダーの DPA とサブプロセッサ |
| 障害ドメイン | 自社インフラ | ベンダーのステータスページ |
どう選べばよいか?
5 つの観点で候補を採点します。どこで動くか、請求の基準は何か、どのプロトコルと SDK をネイティブに話すか、鍵とテナントをどこまで細かく統制できるか、来年もそのベンダーが製品を保有しているか。最後に、どの表にも出ない 1 点を確認します。1 か月前のコストレポートを今日再現できるか。
- •デプロイ:セルフホスト、SaaS、ハイブリッド。コントロールプレーンが自社へ通信しないかも確認します。
- •課金の基準:インスタンス単位、シート単位、トークン単位、支出の割合。
- •プロトコル:OpenAI、Anthropic、Gemini、DashScope の双方向変換と、ストリーミング・ツール呼び出しの等価性。
- •ガバナンス:鍵グループ、ヘッダー ACL、予算、SSO と SCIM、監査エクスポート。
- •再現性:同じ入力から数か月後も同じ数値が出るか。