AI Gateway比較｜LiteLLM・OpenRouter・Portkey・Cloudflare・Bifrostを一次ソースで検証

AI Gateway / LLMルーターとは何か

業務でLLMを使うチームの多くが、もはや単一のモデルでは回らなくなっています。要約はコストの安いモデル、コード生成は精度の高いモデル、長文処理は対応コンテキストの広いモデルというように、用途ごとに別プロバイダのAPIを叩く構成が当たり前になりました。プロバイダが増えれば、APIキーの管理場所もリクエスト形式もバラバラになり、どのチームがどのモデルに月いくら使ったのかも追いにくくなります。ここを一手に引き受けるのが、AI Gateway(LLMルーター、LLMプロキシなどとも呼ばれます)です。

AI Gatewayは、アプリケーションと複数のLLMプロバイダのあいだに立つ中継層です。アプリは一本の統一APIに対してリクエストを投げ、ゲートウェイがそれを適切なプロバイダへ振り分けます。OpenAI・Anthropic・Googleの各社APIに加え、自社でホストしたオープンモデルまでを、同じ呼び出し方で扱えるようにするのが基本的な役割です。あるモデルが落ちていれば別のモデルへ自動で切り替え、リクエストごとのトークン数とコストを記録し、チーム単位の予算やレート上限を当てる。こうした横断的な統制を、アプリ側のコードをほとんど変えずに差し込める点に価値があります。

「1モデルをローカルAPI化する」のとは別レイヤー

ここで線引きをしておきます。たとえばOllamaを社内サーバーに立て、ローカルで動くモデルをHTTP経由で社内から呼べるようにする構成があります。これは「特定の1モデルをAPIとして提供する」話であって、AI Gatewayが担う領域とは別の層です。ローカルAPI化はモデルを動かす場所と入口を用意するもので、横断的な振り分けや統制は守備範囲に含みません。

AI Gatewayは、その先に立ちます。ローカルで動くモデルも、クラウドのOpenAIやAnthropicも、まとめて一本の入口の裏側に並べ、「このリクエストをどのモデルへ流すか」「落ちたらどこへ逃がすか」「誰がいくら使ったか」を中継しながら統制します。実際、後述するゲートウェイの多くはOllamaを対応プロバイダの一つとして扱えるので（手元でローカルLLMをどのエンジンで動かすかは、姉妹サイトのローカルLLM推論エンジン比較が詳しい）、ローカルAPI化とゲートウェイは競合ではなく、重ねて使う関係になります。

アンサンブル/オーケストレーションとも別物

もう一つ混同されやすいのが、複数のAIを協調させるオーケストレーションです。同じ質問を複数モデルに投げて多数決を取る、役割を分担させて議論させるといった仕組みは、アプリケーション側のロジックの話です。AI Gatewayはそこには踏み込みません。本記事で扱うAI Gateway/LLMルーターの中核機能は、複数モデルの協調推論そのものではなく、リクエストの中継・認証・ルーティング・可観測性・統制です。複数モデルを束ねるという表現が共通するため紛らわしいのですが、束ねる目的が違います。なお近年は各製品がMCPやエージェント機能、ガードレールなどの周辺領域を広げており、その意味での境界は重なりつつあります。

ゲートウェイが担う役割

製品によって濃淡はありますが、AI Gatewayが受け持つ機能はおおむね次の領域に整理できます。比較に入る前に、何を期待できる層なのかを押さえておきます。

• 統一API: 各社で異なるリクエスト/レスポンス形式を、共通の形(多くはOpenAI互換のスキーマ)に揃えます。アプリはモデルを切り替えても呼び出しコードを書き直さずに済みます。
• フォールバックとリトライ: 指定したモデルがエラーや過負荷を返したとき、別のモデルやプロバイダへ自動で切り替えます。可用性を上げるための中核機能です。
• ルーティングとコスト最適化: リクエストの内容や負荷状況に応じて、安いモデルや空いているプロバイダへ振り分けます。複数のキーやデプロイ先にロードバランスする実装もあります。
• キャッシュ: 同じ(あるいは意味的に近い)リクエストへの応答を再利用し、推論コストとレイテンシを抑えます。
• 可観測性とコスト可視化: プロンプト・トークン数・エラー・レイテンシ・コストをログに残し、ダッシュボードで横断的に見られるようにします。チーム別・ユーザー別の内訳を出せる製品が多くなっています。
• キー/レート/予算の管理: 実プロバイダのキーをゲートウェイ側で保持し、アプリやチームには発行した仮想キー(バーチャルキー)を配ります。仮想キーごとにレート上限と予算を設定でき、上限を超えたら止める運用ができます。
• ガードレールとガバナンス: PIIのマスキング、入出力のフィルタリング、役割ベースのアクセス制御(RBAC)、監査ログなど。組織で安全に共用するための統制機能です。

これらをアプリごとに自前で実装すると重複も漏れも出ます。横断の中継層に寄せておけば、新しいプロバイダの追加もポリシーの変更も一箇所で済む、というのが導入の動機になります。

主要製品の比較

ここから、実在し現行で使える代表的な選択肢を取り上げます。提供形態(OSSかSaaSか)、自己ホスト可否、料金、対応プロバイダの広さ、認証・ガバナンス、向くチームの観点で並べます。料金・対応数はいずれも2026年6月時点で各社公式ドキュメントを確認した値で、変動するため導入時に再確認してください。

表の「対応プロバイダ/モデル数」はいずれも各社の公称値です。BifrostやPortkeyのように、公式ページ・GitHub・docsの間で数値の表記が揺れる製品もあります（例: Bifrostは公式GitHubで23+ providers、docs/製品ページでは20+ providersや8+ providers/1,000+ modelsといった別表現が混在します）。プロバイダの追加・廃止で日々動くため、絶対数の大小だけで優劣を判断するより、自分たちが使いたいプロバイダが確実に入っているかを、最新のモデルカタログ・provider matrix・pricingページで確認するほうが実務的です。

OSS系(LiteLLM / Bifrost)の位置づけ

LiteLLMは、OpenAI互換の統一APIで100以上のLLMを呼べるプロキシをOSSとして提供します。Dockerで自社インフラに立てられ、仮想キーによるアクセス制御、プロジェクト/ユーザー単位のコスト管理、レート上限、各種可観測性ツール(Langfuse・Helicone等)への連携を備えます。SSO/SAML・監査ログ・複数チーム管理といった組織機能はEnterpriseに分かれており、料金は問い合わせ制です。コードベースで挙動を細かく制御したい、データやキーを外部のSaaSに預けたくない、という要件に合いやすい選択です。

Bifrostは比較的新しいOSSゲートウェイ(Apache 2.0)で、23以上のプロバイダ経由で1,000以上のモデルをOpenAI互換APIで束ねます。自動フェイルオーバー、複数キー間のロードバランス、セマンティックキャッシュ、仮想キー、予算/レート管理を備え、NPXやDocker、Kubernetesで自己ホストできます。開発元のMaximはクラスタ構成や高度なガバナンスを含むEnterprise版を提供しています。高い処理性能を打ち出している点が特徴で、スループットや中継オーバーヘッドを重視する自己ホスト構成の候補になります。なお性能の数値は提供元のベンチマークに基づく主張であり、自分たちのワークロードでの実測とは切り分けて捉えるのが無難です。

SaaS系(OpenRouter / Portkey / Cloudflare)の位置づけ

OpenRouterは、自前運用なしで400以上のモデル・70以上のプロバイダにアクセスできるマネージドの統一APIです。推論料金そのものにはマークアップを乗せず、プロバイダ価格をそのまま通す方式で、収益はクレジット購入時の手数料(5.5%、最低0.80ドル)などから取ります。自前のプロバイダキーを使うBYOKでは、月100万リクエストまで手数料が無料で、それ以降はプロバイダ原価に対して5%が乗ります。公式には自己ホスト版は案内されていません。とにかく多くのモデルを最小の手間で試したい、運用負荷をかけたくないチームに向きます。

Portkeyは、AI Gatewayに可観測性・ガードレール・ガバナンス・プロンプト管理を束ねた製品です。1,600以上のモデルを統一APIで扱える公称ですが、公式リポジトリ内には250+という表記も残っているため、導入時は最新のモデルカタログで確認するのが確実です。無料枠は月1万ログ、Productionプランが月49ドル(10万ログ、追加10万ごとに9ドル)、Enterpriseは問い合わせ制です。RBAC・予算/レート上限・PIIマスキング等のガードレールを持ち、SSOやSOC2/HIPAAといった統制はEnterprise階層に入ります。ゲートウェイ部分はOSSとして公開されており、コントロールプレーンはSaaS・ゲートウェイは自社ネットワーク内というハイブリッド運用も取れます。可観測性とガバナンスを重視しつつ運用は任せたい組織に合います。

Cloudflare AI Gatewayは、アプリと各プロバイダのあいだに立つ制御プレーンで、キャッシュ・レート制限・フォールバック・ガードレール・コスト可視化を備えます。OpenAI・Anthropic・Googleなどの外部プロバイダとWorkers AIのモデルを、Cloudflareのモデルカタログ経由で同一APIから扱えます。コア機能は無料で、Unified Billing（統一請求）を使う場合はクレジット購入に5%が乗ります。LogpushやGuardrailsなど一部機能は別課金です。既にCloudflareを使っていて、エッジでのキャッシュや分析を一緒に効かせたいチームにとっては導入の摩擦が小さい選択になります。

どう選ぶか

選定の出発点は、データとキーを自社インフラの内側に置きたいかどうかです。社内ネットワークから外へ出さない統制が要件なら、LiteLLMやBifrost、あるいはPortkeyのHost it Yourselfのように自己ホストできるOSS系が候補になります（自社内でのモデル提供はOpen WebUIでのチーム共有のような構成と組み合わせられます）。逆に、ゲートウェイの運用そのものを抱えたくない、メンテナンスやスケールを誰かに任せたいなら、OpenRouterやCloudflare、PortkeyのマネージドといったSaaS系が現実的です。ここでSaaSを選ぶ場合、リクエストとプロンプトは外部サービスを経由します。「データが外部に出ない」と言えるのは自己ホスト構成かつ呼び出し先も自社内のモデルに限った話で、クラウドモデルを呼ぶ時点でプロンプトはプロバイダへ送られます。この前提は構成次第で変わるので、SaaSなら通過するという認識を持っておくほうが安全です。

次に効いてくるのが、何を一番見たいかです。チーム別・ユーザー別のコストやトークン消費を細かく可視化し、ガードレールやRBACで統制したいなら、可観測性とガバナンスを前面に出すPortkeyが厚めです。とにかく多様なモデルを試して比較したい段階なら、対応モデルの広いOpenRouterが手数を減らします（使うツールの絞り込み方はAIコーディングツールの選び方と同様、顔ぶれから逆算するのが近道です）。すでにCloudflareでWebやエッジを運用しているなら、同じ基盤に乗せられるCloudflare AI Gatewayが運用面で素直です。自社のコードで挙動を作り込みたい、あるいは将来Enterpriseで組織統制まで一気通貫にしたいなら、OSSのLiteLLMやBifrostから入って必要に応じて有償階層へ広げる道があります。

料金の見え方にも注意が要ります。OpenRouterやCloudflareのように推論原価へのマークアップを取らず、クレジット購入時や統一請求に数%を乗せる方式は、使用量に応じてその数%が積み上がります（モデル単体をクラウドで使うか自前かの損得は、クラウドで使うべきかの比較のように料金とデータ取り扱いで判断します）。一方でPortkeyのような月額サブスクは、記録ログ/リクエスト枠と超過課金で効いてきます。OSS本体が無料でも、自己ホストにかかるインフラ費・運用工数は別途発生します。表面的な「無料」「マークアップなし」という言葉だけで比べず、自分たちの月間リクエスト規模を当てはめて総額を見積もるのが実態に合います。料金体系は各社とも改定があるので、契約前に公式ページで現行値を確認してください。

セキュリティと運用上の注意

AI Gatewayは便利な一方で、構造的に重い役割を背負います。全LLMトラフィックの集約点であり、各プロバイダの実APIキーを保持し、社内の複数チームが共用する。つまり、ここが破られると配下のキーとトラフィック全体が一度に危険にさらされる単一障害点になりえます。可用性の話だけでなく、認証・秘密管理・脆弱性対応のすべてが、この一点に集中する性質を持っています。中継層を一箇所に寄せる利便と、その一箇所が攻撃面になるリスクは表裏です。

これは抽象論ではなく、実際の事例があります。LiteLLMでは2026年4月3日に複数の脆弱性が公開されました。代表的なものがCVE-2026-35030で、JWT認証(enable_jwt_auth: true)を有効にした構成において、OIDCのuserinfoキャッシュがトークンの先頭20文字だけをキーにしていたため、同じ署名アルゴリズムで作られたトークンの先頭が一致するとキャッシュが衝突し、未認証の攻撃者が正規ユーザーの権限を引き継げる、という認証バイパスでした。NVDのCVEレコードでは、GitHub（CNA）のCVSS v4.0ベーススコアとして9.4（Critical）が表示されています。ただしNIST/NVD自身の評価欄はN/Aです。同時に、認証済みユーザーが設定更新エンドポイント経由で権限昇格できる高深刻度の問題(CVE-2026-35029)や、パスワードハッシュの扱いに関する問題も公開されました。いずれもバージョン1.83.0で修正されています。CVE-2026-35030はJWT認証を明示的に有効にした場合のみ影響し、初期設定では無効である点も、自分の構成と照らして確認すべき情報です。

さらに、同年3月24日にはサプライチェーン経由の事案も報じられました。PyPI上のLiteLLMパッケージ(1.82.7および1.82.8)に、公開のCI/CD経路を迂回して悪意あるコードが混入したというもので、PyPIによって約40分後に隔離されたと報告されています。混入したコードは資格情報の収集や横展開を試みる内容だったとされ、ゲートウェイがインフラの中枢に近いほど被害が広がりやすいことを示しました。なお修正版は、汚染された経路を避けて新しいCI/CDパイプラインで再構築したv1.83.0として、クリーンに再リリースされています。

これらはLiteLLM固有の欠陥として一製品を責める話ではなく、集約点であるゲートウェイ一般に当てはまる教訓として読むのが適切です。事案の透明な開示と速やかな修正版提供という対応自体は、運用者にとって追える形になっていました。ここから導けるのは、製品選定とは別に運用側で押さえるべき守りです。バージョンを追従し脆弱性情報を監視すること、依存パッケージのバージョンを固定し導入元の真正性(署名・ハッシュ等)を確認すること、実APIキーやJWT設定などの秘密を最小権限で管理し不要な認証機能はオフにしておくこと、RBACで誰が何を変更できるかを絞ること。集約点であるがゆえに、これらの基本がそのまま全体の安全性を左右します。

最小の使い方イメージ

具体像として、LiteLLMの統一API呼び出しのごく短い例を示します。プロキシを立てておけば、アプリ側はOpenAI互換のクライアントから一本の入口に対して投げるだけで済み、裏でどのプロバイダのどのモデルを使うかはゲートウェイ側の設定で切り替えられます。以下は公開APIの一般的な使い方の最小形で、エンドポイントやキーは各自の環境のものに置き換えてください。

from openai import OpenAI

# ゲートウェイ(LiteLLM Proxy)の統一エンドポイントに向ける
client = OpenAI(
    base_url="http://localhost:4000",   # 自分のゲートウェイのアドレスに置き換える
    api_key="YOUR_GATEWAY_VIRTUAL_KEY", # ゲートウェイが発行した仮想キー
)

resp = client.chat.completions.create(
    model="gpt-4o-mini",  # ゲートウェイ側でプロバイダにマッピングされたモデル名
    messages=[
        {"role": "user", "content": "二分探索を3行で説明してください。"},
    ],
)

print(resp.choices[0].message.content)

ここで指定しているmodel名は、ゲートウェイ側の設定で実プロバイダのモデルに紐づけておく前提です。別プロバイダのモデルに切り替えたいときも、アプリのコードを変えずに設定とモデル名の差し替えで対応できる、というのが統一APIの利点です。フォールバックやレート上限、コスト記録も、この入口を通る限り一律に効きます。ローカルのRAG構成（OllamaでローカルRAGを構築する場合など）から呼ぶときも、同じ統一エンドポイントを向ければゲートウェイの恩恵をそのまま受けられます。

よくある質問

AI GatewayとAPIゲートウェイ(KongやNGINX等)は同じものですか

目的が異なります。従来のAPIゲートウェイはHTTP API一般の認証・ルーティング・レート制限を担う汎用基盤です。AI GatewayはそれをLLM向けに特化させたもので、トークン単位のコスト計算、プロバイダ間のフォールバック、プロンプト/レスポンスのキャッシュやガードレールなど、LLM固有の関心事を扱います。近年は従来型APIゲートウェイ側がLLM向け機能を取り込む動きもあり、境界は重なりつつあります。

SaaSのゲートウェイを使うと、プロンプトはどこを通りますか

SaaS型では、リクエストはそのサービスを経由してから各プロバイダへ送られます。プロンプトやレスポンスがゲートウェイ事業者のログに記録される範囲は製品の設定とプランによります。機微なデータを扱う場合は、ログ保持期間・保存場所・マスキング設定を確認し、要件次第では自己ホスト可能なOSS構成を検討してください。

OSSのゲートウェイは完全に無料で運用できますか

本体のライセンス費はかからなくても、自己ホストするサーバーやコンテナの費用、監視・アップデート・脆弱性対応といった運用工数は発生します。SSOや監査ログなどの組織機能は有償のEnterprise階層に分かれている製品が多く、料金は問い合わせ制のことが一般的です。総コストはこれらを含めて見積もるのが実態に合います。

参考資料

• LiteLLM 公式ドキュメント — OSSプロキシの統一API・対応プロバイダ・Enterprise機能の一次情報。
• OpenRouter Documentation / FAQ — 対応モデル数・マークアップなしの料金方式・BYOK手数料の一次情報。
• Portkey Pricing — 無料枠・Productionプラン(月49ドル)・Enterprise・自己ホストの公式料金。
• Cloudflare AI Gateway Docs — モデルカタログ・Unified Billing・Logpush/Guardrails課金の公式ドキュメント。
• Bifrost（maximhq/bifrost, GitHub） — Apache 2.0・対応プロバイダ・自己ホスト手順・性能主張の一次リポジトリ。
• LiteLLM Security Update（2026年4月） — CVE-2026-35030等の脆弱性開示と修正版(v1.83.0)の公式アナウンス。
• NVD / GitHub Advisory: CVE-2026-35030（GHSA-jjhc-v7c2-5hh6） — 影響範囲・修正版と、CVSS v4.0=9.4 Critical（GitHub/CNA評価。NIST/NVD欄はN/A）の脆弱性レコード。