AI Gateway とは、OpenAI・Anthropic・Google など複数の LLM プロバイダーへの呼び出しを一本化し、認証・コスト管理・フェイルオーバー・監査ログを横串で実装するためのミドルウェア層である。本記事では、AI Gateway が解決する課題、主要製品（Cloudflare AI Gateway / LiteLLM / Portkey / Helicone）の選定軸、既存システムへの段階的な組込み手順を、複数 LLM 運用に踏み出した CTO・SRE 向けに整理する。当社では、タイ進出日系企業の AI 基盤を構築する際、Gateway の有無で運用負荷とコストの可視性が大きく変わることを実感している。

複数の LLM プロバイダーを使い分ける企業が増えるなかで、共通基盤として「AI Gateway」と呼ばれるレイヤーが定着しつつある。ここではまず、AI Gateway とは何か、なぜ必要とされるようになったのかを順に整理する。

AI Gateway とは、アプリケーションから LLM プロバイダーへの API リクエストを一度集約し、認証・ルーティング・ログ・ガードレールを共通化するミドルウェアである。アプリ側は Gateway の単一エンドポイントだけを呼び、Gateway が裏で OpenAI・Anthropic・Google・各社の OSS モデルなどへ振り分ける。

この発想自体は新しくない。マイクロサービスの世界ではすでに「API Gateway」が一般化しており、Kong や AWS API Gateway が認証・レートリミット・ログを請け負ってきた。AI Gateway はその LLM 版で、扱う対象が「外部 LLM への呼び出し」になっただけだ。

ただし LLM 特有の事情が 2 つある。1 つはトークン課金で、コスト管理の粒度が API 数ではなくトークン数になる。もう 1 つはモデルごとに性能・コスト・レイテンシが大きく異なるため、用途別にルーティングする要求が強い。この差分が AI Gateway を独自カテゴリにしている。

数年前までは「OpenAI 1 社で十分」という現場が大半だった。しかし複数モデルを併用するパターンが急速に広がっている。理由は 3 つある。

• 用途別の最適化: 要約・分類は小型モデル、複雑な推論はフラッグシップというように、タスクごとに最適なモデルが異なる。
• ベンダーロックインの回避: 1 社の停止・価格変更が業務を止めるリスクを下げたい。
• リージョン・データ主権: 顧客データの居住地に応じて、特定リージョンのモデル(Bedrock の東京/シンガポール等)を選びたい。

複数モデルを呼ぶ実装は、最初は「環境変数を分けて if 文で振り分ける」程度で済む。ところが、フェイルオーバー・コスト集計・ガードレールを後から足そうとすると、各アプリの中に同じコードが散らばっていく。Gateway は、その散らかりを 1 箇所に閉じ込めるための器だ。当社の経験では、3 つ以上のモデルを併用する段階で、Gateway 化のコストはほぼ確実に回収できる。

AI Gateway を構成する機能は概ね 3 つのレイヤーに分けられる。統一インターフェースとフェイルオーバー、コスト可視化とレートリミット、ガードレールと観測ログだ。ここからは、それぞれが現場のどの課題に効くのかを見ていく。

Gateway の最も基本的な役割は、プロバイダー間の API 差を吸収することだ。OpenAI 互換のリクエスト形式を入口に置き、内部で Anthropic・Google・Bedrock などへの呼び出しに変換する実装が主流である。アプリ側のコードは Gateway のエンドポイントだけを知っていればよく、モデル切替は Gateway 側の設定変更で完結する。

そのうえで重要なのがフェイルオーバーだ。本番運用で OpenAI が 5xx を返すケースは現実に発生する。Gateway がリトライ・別プロバイダーへの切替を担当することで、アプリ側のエラーハンドリングは「Gateway が最終的に失敗した場合のみ」をケアすればよくなる。

ルーティング戦略には、(a) プライマリ + フォールバック型、(b) コスト最小モデルからエスカレーション型、(c) AB テストのトラフィック分割型、などのバリエーションがある。設計時に「どのモデルがプライマリで、何が起きたらどう切り替わるのか」を決めておかないと、Gateway は単なる障害ポイントになる。

LLM 運用で意外に難しいのが「誰がどのアプリで、何トークン使ったか」を把握することだ。各プロバイダーのコンソールは月単位の合算しか見せず、社内のアプリ・部署ごとの内訳までは追えない。

AI Gateway は呼び出しを通す位置にいるので、リクエストごとに app_id や user_id などのタグを付け、トークン数・コストを集計できる。これにより、コスト超過を起こしているアプリの特定、課金部署への按分、無料利用ユーザーへのレートリミット設定が現実的になる。

実務的には、「ある特定の社内ツールが想定の 10 倍のトークンを使っていた」「営業デモ用に検証していた高コストモデルを本番に残してしまっていた」といった事故を防げる価値が大きい。レートリミットの粒度を「ユーザー単位 + IP 単位 + プラン単位」の組み合わせで設計できると、無料プランのユーザーによる予算枯渇も防ぎやすい。

AI Gateway はリクエストとレスポンスの両方を通過させるため、ガードレールの差し込み口として理にかなった位置にある。代表的なガードレールは次の通りだ。

• PII マスキング: メールアドレス・電話番号・マイナンバー等を Gateway 側で検出し、プロバイダーに渡す前に置換する。
• プロンプトインジェクション検出: 攻撃ペイロードの兆候を検出してブロックする。
• 出力フィルタ: 機密情報・差別表現等が出力された場合に遮断・サニタイズする。

加えて、すべてのリクエスト/レスポンスをログとして残せるのも Gateway の価値だ。問題発生時のリプレイ、品質劣化の追跡、内部監査への提示など、後から「あの時の出力を見たい」というシーンは確実に発生する。アプリ側で個別にログを実装するより、Gateway 側で一元化したほうが取りこぼしが少ない。

ただし、ログには個人情報も含まれうるため、保持期間・アクセス制御・暗号化を最初に決めてから始める必要がある。

AI Gateway 領域の選択肢は、フルマネージド SaaS と OSS セルフホストの 2 系統に大別される。代表的な製品の特徴を順に整理する。

Cloudflare AI Gateway は、Cloudflare のエッジネットワーク上で動作するマネージド型 AI Gateway である。アプリは Cloudflare 提供のエンドポイントを呼ぶだけで、ログ・キャッシュ・レートリミット・コスト集計が組み込みで利用できる。

長所は導入が極めて軽いことだ。Cloudflare アカウントさえあれば設定画面から数分で経路を作成でき、Workers AI・OpenAI・Anthropic・Replicate・Hugging Face Inference など主要プロバイダーをそのまま中継できる。

一方、エッジで動く都合上、独自のガードレール処理を任意に差し込むのは制約がある。複雑なポリシーや独自プロバイダーへの対応が必要な場合は、後述の OSS と組み合わせるか、別の SaaS を検討するほうが現実的だ。本番運用前に最新の料金・対応プロバイダー一覧は公式ドキュメントで必ず確認すること。

LiteLLM は MIT ライセンスの OSS で、100 を超える LLM プロバイダーを単一の OpenAI 互換インターフェースに集約することを目的としたライブラリ/プロキシだ。Python ライブラリとしてアプリに直接組み込むことも、独立した Proxy サーバーとして起動することもできる。

セルフホストで運用する場合、Docker / Kubernetes 上で動かしてユーザー管理・チーム管理・予算上限・モデル別ルーティングを設定できる。コミュニティが活発で、新モデルへの対応速度も速い。

オンプレや特定 VPC に閉じた環境で Gateway を運用したい現場では、第一候補に挙がりやすい。一方で、SaaS と異なり監視・アップデート・スケーリングは自前で運用する必要があるため、SRE の体制が前提になる。本番採用前に、対応プロバイダー一覧とライセンス条件は公式リポジトリで確認することをすすめる。

Portkey はマネージド SaaS と OSS Proxy の両方を提供する AI Gateway 製品で、観測ログ・ガードレール・プロンプトテンプレート管理・キャッシュなどを統合的に提供する。SDK の差し替えだけで導入できる手軽さと、企業利用を意識した管理機能の充実が特徴だ。

Helicone は LLM 観測性に重点を置いた OSS / SaaS で、リクエストログ・ユーザー別の利用量・コスト集計・キャッシュ機能を備える。SDK を差し替える方式と、ベース URL を切り替えるだけのプロキシ方式が選べる。

両者は機能の重なりも多いが、Portkey はガードレールやエンタープライズ管理寄り、Helicone は観測ログとコスト分析寄りという色分けが見られる。複数プロバイダーをすでに使っている組織が、まず観測性から入りたい場合は Helicone、ガードレールも含めて統合的に管理したい場合は Portkey を選ぶ判断軸が立てやすい。

AI Gateway を提案すると、「結局リバースプロキシでしょう?」「導入すれば自動でコストが下がるんですよね?」という質問が高頻度で返ってくる。両方とも誤解で、現場の判断を歪める。順に整理する。

技術的に見れば AI Gateway はリバースプロキシの一種ではある。しかし「nginx を間に挟むのと何が違うのか」と言われると、答えは「LLM の文脈を理解する処理が組み込めるか」だ。

普通のリバースプロキシはバイト列を中継するだけで、トークン数を数えたり、プロンプトインジェクション兆候を検出したり、PII をマスクしたりはしない。AI Gateway は、LLM API の JSON 構造を理解し、リクエスト/レスポンスのテキストに対して LLM 特有の処理を適用できる点が本質的な違いだ。

そのため、SRE が「ロードバランサで足りる」と判断して既存の nginx/Envoy で代用しようとすると、コスト集計やガードレールが入らず、結局アプリ側に書き戻すことになる。AI Gateway は「LLM 用に特化したコントロールプレーン」だと捉えるほうが、後戻りが少ない。

「Gateway を入れればコストが下がる」という説明は、ベンダー側のセールス文脈ではよく聞く。実際にはそう単純ではない。

Gateway そのものは、コストを「下げる」のではなく「見える化する」装置だ。コストが下がるかどうかは、見える化したあとに、(a) 用途別の安いモデルへのルーティング、(b) プロンプトキャッシュ・セマンティックキャッシュの有効化、(c) 不要な高頻度呼び出しの抑制、を実装するかどうかで決まる。

導入直後は、むしろ Gateway の運用費用ぶんコストが増える可能性すらある。だからこそ「Gateway 導入 = コスト削減 KPI」と最初に握ってしまうのは危険で、「コスト可視化 → 最適化 → 結果としての削減」という順序で関係者と握っておくのが現実的だ。

AI Gateway はビッグバン導入よりも、段階的な置き換えが向く。当社が複数案件で取った進め方を 2 つのフェーズに分けて紹介する。

最初のフェーズは「既存の LLM 呼び出しを Gateway 経由に通すだけ」に絞る。新機能は足さない。

具体的には、以下を進める。

1. Gateway 製品を 1 つ選び、ステージング環境で OpenAI 互換エンドポイントとして立ち上げる。
2. 既存アプリの API ベース URL を Gateway のエンドポイントに差し替える(コード変更はベース URL 1 行程度で済むことが多い)。
3. ステージングで主要シナリオを回し、レイテンシ増加が許容範囲か確認する。
4. カナリアリリースで本番の一部トラフィックを通し、レスポンス不一致やエラー率を監視する。

このフェーズで重要なのは「機能を増やさない」という規律だ。ガードレール・コスト按分・キャッシュなどを同時に有効化すると、問題が起きたとき原因の切り分けが難しくなる。まずは「同じ振る舞いのまま Gateway を間に挟んだ」という状態を作る。

Phase 1 が安定したら、Gateway が本来持つ価値を段階的に解放する。

優先順位は次の通りだ。

• 観測ログ: アプリ ID・ユーザー ID をリクエストヘッダーに付け、Gateway 側で集計する。問題発生時のリプレイ用にリクエスト/レスポンスの保存も有効にする(保持期間とアクセス制御を必ず先に決める)。
• コスト按分: アプリ ID 別のトークン使用量・コストをダッシュボード化する。財務・経営側の合意が必要なら、レポート形式も最初に決める。
• ガードレール: PII マスキング、プロンプトインジェクション検出など、リスクの大きいものから順に有効化する。
• ルーティング最適化: 用途別の小型モデル振り分け、フェイルオーバー、キャッシュ。コスト最適化の核心はここに含まれる。

すべてを一度に入れず、四半期ごとに 1〜2 機能のペースで足すのが現実的だ。組織の運用負荷とリターンの両方が見えてくる。

Q1: AI Gateway は自前で作るべきか、製品を採用すべきか?

採用が現実的だ。LLM プロバイダーは月単位で API・モデル・料金体系が変わるため、自前 Gateway の保守コストはアプリ機能の開発と同程度以上に膨らみやすい。差別化に直結しない領域に SRE のリソースを割きにくい組織ほど、既存製品を採用する判断が合理的だ。

Q2: API Gateway を既に使っているが、追加で AI Gateway が必要か?

必要になるケースが多い。既存の API Gateway は LLM の JSON 構造やトークン課金を理解しないので、コスト按分・PII マスキング・プロンプトインジェクション対策などは別途実装することになる。前段を既存 API Gateway、後段を AI Gateway とし、責務を分けるのが扱いやすい。

Q3: マイクロサービス単位で別々の Gateway を持ってもよいか?

推奨しない。コスト按分・ガードレール・観測ログを一元化する目的が薄れるためだ。組織単位・テナント単位など、ガバナンスの単位で 1 つに揃えるのが現実的である。

Q4: Gateway 自体の障害が単一障害点にならないか?

単一障害点にはなり得る。マネージド SaaS を選ぶ場合は SLA とリージョン構成を、OSS をセルフホストする場合は冗長化・ヘルスチェック・フェイルバック手順を必ず設計しておく必要がある。

AI Gateway 導入の要点を整理する。

• AI Gateway は複数 LLM プロバイダーへの呼び出しを集約し、認証・コスト管理・フェイルオーバー・ガードレールを共通化するミドルウェアだ。
• 3 つ以上のモデルを併用する段階で、Gateway 化のコストはほぼ確実に回収できる。
• 主要製品は Cloudflare AI Gateway(マネージド)、LiteLLM(OSS)、Portkey / Helicone(SaaS+OSS)があり、運用体制とガバナンス要件で選び分ける。
• 導入時は「Gateway を間に挟むだけ」→「観測ログ・コスト按分・ガードレール・ルーティングの段階追加」の順で進めるとリスクが低い。
• コスト削減は Gateway 単体で発生する効果ではなく、可視化した後の最適化次第である。

複数 LLM 運用に踏み出した段階で、Gateway を「あとで足す」ではなく「先に足す」発想で設計に組み込むと、後年の運用負荷とガバナンスコストが大きく下がる。当社が支援する現場でも、Gateway の有無は AI 基盤の成熟スピードを直接左右している。