AI Gateway 比較 — Kong AI Gateway / LiteLLM / Portkey の選び方

複数のLLMを使い分けたい、コストとログを集約したい、プロンプト保護やガードレールを統一したい。こうした要件を担うソフトウェアを総称してAI Gateway（LLMゲートウェイ）と呼びます。2026年6月時点で日本のエンタープライズが評価対象に入れることが多い3製品（Kong AI Gateway／LiteLLM／Portkey）を、機能・運用・コストの3軸で並べます。

前提条件によって最適解が大きく変わる領域なので、本記事では結論を1つに絞らず、要件と製品の対応を整理する形で進めます。本文の数値や条件は2026年6月時点の公開情報（各社サイト・サードパーティのTCO分析）にもとづくもので、契約条件は個別に各社へ確認してください。

背景：AI Gatewayが必要になる場面

業務でLLMを使い始めると、最初は1つのモデルへの直接呼び出しで足ります。やがて、用途別に最適なモデルを使い分けたい、コストを部門別に見たい、プロンプトに機密が含まれていないかを統一ルールで検査したい、というニーズが出てきます。これを各アプリで実装するとバラバラになるため、入口に置く共通の仕組みが必要になります。これがAI Gatewayです。

2025年から2026年にかけて、Kong がLLM向けプラグインを拡充し、LiteLLM が企業導入を増やし、Portkey が観測性とガードレールで存在感を増しました。2026年4月30日にはPalo Alto Networksが Portkey の買収を発表しており、AI Gateway市場はゲートウェイ専業からセキュリティ企業による吸収統合のフェーズに入りつつあります。選定時はベンダーの将来も含めて見る局面です。

3製品の概観

3製品は同じカテゴリに分類されますが、出自が違います。Kong は API Gateway（Kong Gateway）の延長 としてAI Gatewayを提供しており、既存のAPI統制と同じ枠組みでLLMトラフィックを扱う設計です。LiteLLM は OpenAI互換proxy として始まり、対応プロバイダ数の多さと開発者親和性で広がりました。Portkey は 観測性とプロンプト管理 を主軸に据え、ダッシュボードまで含めた製品体験を提供します。

機能比較（網羅性）

各製品が標榜する機能を、同じ軸で並べます。◎は標準搭載かつ強み、○は対応あり、△は外部組合せが前提、を意味します。製品アップデートは頻繁にあるため、最終的には公式ドキュメントで確認してください。

この表からの読み筋を3つ挙げます。LLMの種類が多い場面では LiteLLM の対応プロバイダ数が他より広いこと。ガードレール・観測性が要件の中心にある場面では Portkey の標準搭載量が効くこと。既にKong Gatewayを運用しているならKong AI Gatewayが選定の中心に来ること。要件次第で順番が入れ替わります。

運用・SRE観点の比較

機能の表だけでは選べない要素として、運用負荷・障害時の挙動・スケール特性があります。AI Gatewayは業務の入口に立つので、ここが停止するとLLM利用が全停止します。3製品の運用上の特性を整理します。

Kong AI Gateway：Kong Gatewayの上に乗る構成で、デプロイ形態として OSS自社運用／Self-Hosted Enterprise／Konnect（SaaS） の3パターンがあります。SaaSのKonnectを選べば運用は最小化されますが、コントロールプレーンが他社管理になります。Self-Hosted は高度にカスタマイズ可能ですが、Kong運用のスキル（Lua/Go、Kubernetes、observability）が前提です。プラグインの順序依存・バージョン互換に注意が必要で、Enterpriseの一部機能はOSS版に無いため事前確認が必要です。

LiteLLM：軽量proxyとして始まったため、最小構成は Docker 1コンテナで動きます。本番運用では PostgreSQL（virtual keys・budgets の永続化）と Redis（cache・rate-limit）が事実上必須で、HA構成にすると依存コンポーネントが増えます。OSSの運用は自社で抱えることになるため、SRE体制が無いと on-call 負荷が高くなります。Enterprise契約でも自社ホスティングは続くため、運用人員のコストが見えにくい点に注意します。

Portkey：SaaSが基本線で、運用負担は最も低い構成を取れます。Apache 2.0でセルフホストも可能ですが、観測ダッシュボードや管理画面はSaaSが主体です。2026年4月のPalo Alto Networks買収発表により、製品ロードマップと価格体系が今後変動する可能性があります。買収完了は2026年7月までに予定されており、フィードリリースや既存契約の継続条件は買収後の発表を確認するのが安全です。

ライセンスとコスト構造

価格は公開されているもののみ列挙します。Enterpriseは個別交渉が多く、年契約のエスカレーター（5〜10%/年）や、リクエスト数による従量加算など、見積もり段階で確認すべき条項があります。

3製品ともOSS版は無料ですが、自社運用するならインフラと人件費が別途必要になります。サードパーティのTCO分析では、LiteLLMの自社運用はライセンス費用が見えない代わりに運用人件費が乗るため、長期で見るとSaaS型と総コストが逆転する条件があると報告されています。Kongは契約に年5〜10%の自動上昇条項が含まれることが多く、3年契約で2割増しになる試算もあります。Portkeyは2026年7月までに買収が完了する見通しで、買収後の価格改定はまだ未公表です。

前提条件×推奨マトリクス

機能と運用とコストの全てを満たす製品は存在しません。前提条件によって有利不利が変わるため、要件を一段具体化したうえで対応する候補を絞り込みます。

このマトリクスの使い方は単純です。自社の前提を1つに固定するのではなく、複数の行を選んで重ね合わせるのが現実的です。たとえば「既にKong Gatewayあり」かつ「ガードレール必須」なら、Kong AI Gatewayをベースに、必要なガードレール機能を別途プラグインで足すかPortkeyを部分併用するか、という設計議論になります。「とにかく多種類のLLM」かつ「自社運用」なら LiteLLM の自社ホスティングが第一候補に挙がります。

選定時の落とし穴

3製品を実評価した範囲で、判断を誤りやすいポイントを共有します。

1. 「OSSだから無料」と読まないこと。OSS版は確かにライセンス費用が0ですが、本番運用には Redis や PostgreSQL のHA構成、監視、CVE対応、バージョン追従の作業が継続して発生します。SRE体制がない組織では、SaaS版のほうが総コストが安いケースが多くあります。

2. ベンチマーク数値だけで判断しないこと。レイテンシのベンチは構成・キャッシュ有無・モデル種別で大きく変わります。各社が公開する数値は最適条件下のもので、実装後に同じ数字が出るとは限りません。重要な指標はゲートウェイのレイテンシ単独ではなく、「LLM呼び出し全体のp95」です。

3. Enterprise契約の上昇条項を見落とさないこと。年5〜10%の自動上昇条項は珍しくありません。3年で20%、5年で50%近く上がる可能性があります。契約書の Renewal terms と Price escalation 条項を必ず確認します。

4. ベンダーの将来性を要件に入れること。AI Gateway市場は買収・統合が進行中で、Portkey の Palo Alto Networks 入りもその一例です。買収自体は悪い話ではありませんが、ロードマップ・価格・サポート体制が変わる可能性があるため、選定時は EOLや製品終了時の出口戦略 も含めて評価します。

5. 「試験導入で動いた」と「本番で運用できる」は別問題。短期間の検証では、HA構成・障害復旧・バージョン更新・運用ルックブックの整備など、本番運用に必要な作業が見えません。試験導入時に運用ランブックを作る前提で時間を確保することを勧めます。

「うちならどう選定するか」の進め方

私たちは選定支援を行う場合、以下の順番で詰めます。技術的な比較表だけでなく、組織の前提と将来計画を先に固めるのが特徴です。

(1) 既存のAPI/インフラ基盤の確認。Kong Gatewayが既にあるか、Kubernetes・AWS・GCPのどれで運用しているか、SRE体制があるか。これによってSaaS型を選ぶか自社運用を選ぶかが大筋決まります。

(2) LLM利用の現状把握。今のプロバイダ数、月間リクエスト数、トークン消費の分布、機密データの取扱いルール。これでルーティング・コスト管理・ガードレールの優先度が決まります。

(3) 1年後・3年後のLLM利用予測。エージェント／MCPサーバの導入予定、社内アプリへの組み込み計画。スケール特性とロードマップ親和性で候補が変わります。

(4) 試験導入の設計。「動くか」ではなく「本番で運用できるか」を確かめます。HA構成、障害シナリオ、運用ランブック、バージョン更新手順の試作までを含めて評価します。

(5) 契約条件の確認。Renewal terms、Price escalation、サポートSLA、データ取扱い・監査ログの保管場所、Enterpriseの最低契約期間。技術と独立して詰めます。

この順番を逆にすると、製品ロックインや想定外のコスト増に陥りやすくなります。要件と前提を一度整理する作業を、製品選定の前段に必ず置きます。