LiteLLMの代替（2026）— ホスト型ゲートウェイ、BYOキーのコントロールプレーン、乗り換えない方がよい場合

LiteLLMは、自分で運用するオープンソースのOpenAI互換プロキシです。自分のプロバイダーアカウントの前段に置き、複数のアカウントに対してコードへ1つのエンドポイントと1種類のキー形式を提供します（公式ドキュメント）。チームが代替を探す理由は、互いに関係のない2つに分かれます。運用:セルフホスト型プロキシは、パッチ適用、スケール、障害対応が必要なサービスを1つ増やします。サプライチェーン:2026年3月24日、攻撃者がバックドアを仕込んだLiteLLMのリリース2つをPyPIに公開し、「ビルド内のパッケージ」がもたらす攻撃面を、それまでコストとして見積もっていなかった多くのチームに突き付けました。このまとめでは、各動機に実際に答えるツールを対応付けています。LiteLLMを使い続ける理由も含めており、その理由は、この検索に出てくる7本のベンダーによるリスト形式の記事が示唆するよりも強固です。

冒頭で立場の偏りを明示しておきます。Kunavoは私たちの製品であり、最初に掲載しています。以下に挙げる他のすべてのツールについても、真摯に推奨しています。確認済みの詳細は比較ページに掲載し、評価していない2つについては、それぞれの公式サイトに記載された範囲でのみ説明しています。

候補一覧

ほとんどの判断を左右する区別

LiteLLMは2つの役割を同時に担いますが、ほとんどの代替製品はそのうち1つだけを担います。LiteLLMはプロキシ（複数プロバイダーに対する1つのエンドポイント）であり、BYOキーのツール（プロバイダーアカウントは自分で保有）でもあります。ホスト型推論ゲートウェイであるKunavoやOpenRouterは、その両方を置き換えます。プロキシを運用する必要も、プロバイダーアカウントを保有する必要もありません。ゲートウェイが上流の認証情報を保持し、利用量に応じて請求するためです。ホスト型コントロールプレーンであるPortkeyやTrueFoundryは、最初の役割だけを置き換えます。プロキシの運用はやめますが、アカウントは保持します。どちらの半分を置き換えるのかが分かれば、この一覧の大半は整理できます。このパターンについてはLLMゲートウェイガイドで詳しく説明しています。

実際に人々を検索へ向かわせたもの

この検索の最上位の結果はリスト形式の記事ではなく、サプライチェーン攻撃に関するRedditのスレッドです。LiteLLM自身によるセキュリティ更新情報によると、経緯は次のとおりです。2026年3月24日、攻撃者は配布用のwheelに悪意のあるコードを埋め込み、litellm==1.82.7とlitellm==1.82.8をPyPIに公開しました。これらは10:39 UTCから約40分間公開されており、その後PyPIによって隔離されました。侵害の原因は、LiteLLMのCI/CDセキュリティスキャンワークフローで使用されていたTrivy依存関係にあると特定されました。攻撃者は公式のリリースワークフローを迂回し、PyPIに直接アップロードしました。SecurityWeekによると、2,500を超える組織が影響を受けました。

LiteLLMの対策は公表されており、内容も大規模です。侵害されたパッケージの撤去、メンテナー認証情報のローテーション、フォレンジック調査のためのMandiant起用、分離されたビルド環境、強化されたリリースゲート、cosign署名済みDockerイメージを備えた再構築済みCI/CDパイプラインによるv1.83.0のリリースが行われました。1.83.0以降を使用しており、40分間のウィンドウ中に汚染されたバージョンを実行していなかったなら、このインシデントはあなたにとって解決済みです。

この検索へ人々を向かわせ続ける理由は、LiteLLM固有の問題ではなく構造的なものです。セルフホスト型プロキシはビルド内のパッケージであり、そのためCI/CDとクラスターが攻撃の影響範囲に含まれます。この一文はよく考える価値があります。MLflow AI Gatewayを含む、このページ上のすべてのセルフホスト型代替製品にも同じことが当てはまります。そして、ホスト型エンドポイントが取り除く唯一のものでもあります。HTTPS URLを呼び出すため、汚染されるパッケージはなく、ゲートウェイの実行環境が自社ネットワーク内に入ることもありません。

率直に言うべきもう一方の側面:ホスト型ゲートウェイはより安全なのではなく、露出の仕方が異なります。APIキーとプロンプトテキストは他社のインフラを経由し、自社でパッチを適用するリスクの代わりに、その会社の侵害リスクを引き受けます。プロンプトテキストを自社インフラの外に出せないなら、セルフホストが正しい答えであり、このページの残りは選ぶべきでないトレードオフについて述べています。

1. Kunavo — プロキシなし、プロバイダーアカウントなし

Kunavoはホスト型推論ゲートウェイです。OpenAI互換のbase URLが1つ、sk-kn-キーが1つ、従量課金残高が1つあり、上流プロバイダーの認証情報はあなたではなく私たちが保持します。LiteLLMとは役割分担が異なります。プロキシを運用せず、Anthropic、Google、OpenAIそれぞれのアカウントを個別に管理する必要もありません。

価格:カタログの大半はプロバイダーの公式料金未満で掲載されています。Claude Sonnet 4.6は1Mトークンあたり$2.10 / $10.50で、Anthropicの$3.00 / $15.00と比較できます。LiteLLMは何も再販しないためマークアップがありません。支払う金額は自分のプロバイダー契約に基づくため、比較対象はゼロではなく、私たちの料金と直接契約の料金です。対応範囲:同じキーと残高でチャット、画像、動画、音楽モデルを利用できます。対応しないこと:自分のプロバイダーキーのルーティングです。これはLiteLLMが保持するBYOキー側の役割であり、私たちは置き換えません。詳細: KunavoとLiteLLMの比較。

2. OpenRouter — 最も長いモデル一覧

もう1つのホスト型推論ゲートウェイであり、単価よりカタログの広さを重視する場合に選ぶ製品です。大規模なプロバイダー群の数百モデルを1つのウォレットで利用でき、無料枠と、KunavoにはないBYOキーのルーティングも提供します。アカウントを保持するのをやめるためにLiteLLMから移行するなら、現実的な選択肢はOpenRouterとKunavoの2つです。KunavoとOpenRouterの比較では両者を並べて比較し、OpenRouterまとめではこの分野の他の選択肢を扱っています。

3. Portkey — キーは保持し、運用を手放す

すでに保有しているプロバイダーアカウントの上に構築するホスト型コントロールプレーンです。自分でプロキシを運用せずに、ルーティング、フォールバック、ガードレール、可観測性を利用できます。LiteLLMをルーティングと予算機能のために選び、手放したいのが運用だけなら、最も近い代替製品です。詳細: KunavoとPortkeyの比較。

4. Helicone — 理由が可観測性だけだった場合

LiteLLMのデプロイの多くは、誰かがリクエストログとチーム別のコスト帰属を必要とし、それを得る手段としてプロキシを使っているものです。これに当てはまるなら、既存のプロバイダー呼び出しの上に可観測性レイヤーを置く方が、ゲートウェイよりはるかに小規模な運用で済みます。詳細: KunavoとHeliconeの比較。

5. TrueFoundry — 調達部門がベンダーを必要とする場合

この検索で2位に位置し、独自のLiteLLM比較記事を掲載しています。レイテンシーオーバーヘッド、デプロイの柔軟性、SLA、ガバナンス、監査対応の管理機能を訴求するエンタープライズAIゲートウェイとして販売されています（製品ページ）。私たちは評価していないため、ここでは推奨ではなく参照先として紹介します。オープンソースプロキシにはサポート契約がないことが障害なら、これがその問題を解決するカテゴリーです。ただし、比較記事を自社が執筆したことを踏まえて読む価値があります。

6. MLflow AI Gateway — 同等製品へのオープンソース移行

3位に位置し、このページでLiteLLM自体に最も近い製品です。オープンソースのセルフホスト型ゲートウェイであり、自分のプロバイダーキーの前段に置き、MLflowプロジェクトの一部として保守されています。率直に言うと、セルフホスト型プロキシから別のセルフホスト型プロキシへ移行しても、デプロイモデルは変わらず、したがって上記の攻撃面も残ります。それが正しい選択である場合もあります。嫌だったのがモデルではなくプロジェクトなら、これが望む移行です。

7. Cloudflare AI Gateway — エッジでのキャッシュと制限

すでに保有しているプロバイダーアカウントの前段に置く薄いプロキシです。推論の再販は行わず、レスポンスキャッシュ、レート制限、リトライ、分析を提供します。KunavoやOpenRouterを含め、推論ソースを置き換えるのではなく、任意の推論ソースと組み合わせて利用できます。詳細: KunavoとCloudflare AI Gatewayの比較。

LiteLLMを選び続けるべき場合

• プロンプトテキストを自社インフラの外に出せない。規制対象データ、エアギャップ環境、またはホスト型ゲートウェイでは満たせないポリシーがある場合です。答えはセルフホストであり、残る問題はどのセルフホスト型プロキシを選ぶかだけです。
• プロバイダー契約を締結済みである。Anthropic、OpenAI、Googleとのコミット済み利用額やエンタープライズ料金は、再販業者が提示するどの料金よりも価値があります。BYOキーのツールなら、それらを使い続けられます。
• キーごとの予算とチームルーティングを使っている。これらの機能があるからこそLiteLLMを導入しているチームは多く存在します。base URLの差し替えだけで移行が完了すると考える前に、移行先がそれらをカバーしていることを確認してください。
• 読んで修正できるソースが欲しい。自分で管理できるオープンソースプロキシは実質的な特性です。2026年3月のインシデントによって失われたものではありません。これはプロキシ自体の欠陥ではなく、すでに対処済みのリリースパイプライン侵害でした。

切り替えは2行です

ここで推論を再販するすべての代替製品はOpenAIワイヤープロトコルに対応しているため、LiteLLMプロキシからの移行はbase_urlとキーの差し替えです。リクエストとレスポンスの形式は変わりません。

# Before: your own LiteLLM proxy, your own provider keys,
# your own container to patch.
client = OpenAI(
    api_key=os.environ["LITELLM_MASTER_KEY"],
    base_url="http://litellm.internal:4000",
)

# After: a hosted endpoint. No package in your build, no proxy to run.
client = OpenAI(
    api_key=os.environ["KUNAVO_API_KEY"],
    base_url="https://api.kunavo.com/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)

2行では済まない部分は、LiteLLMがルーティング以外に行っていたことです。キーごとの予算、チームへの分配、カスタムコールバックなどです。まずそれらを洗い出してください。ワイヤーレベルの詳細はOpenAI互換APIガイドにあり、ゲートウェイに任せるべき処理では移行先に確認すべき機能群を扱っています。

よくある質問