概要
LiteLLM は、Y Combinator 出身の BerriAI が開発するオープンソースの LLM ゲートウェイです。形態は2つあります。OpenAI のリクエスト形式で任意のモデルを呼び出す Python SDK と、アプリとモデルプロバイダーの間に置くプロキシサーバー（「AI Gateway」）です。すべてのチームが OpenAI 互換の単一エンドポイントを呼び出し、プロキシが実際のプロバイダーキーを保持し、チームやエージェントごとに仮想キーを発行し、予算とレート制限を適用し、プロバイダー間でフォールバックし、呼び出しごとの費用を記録します。トップページでは 140+ のプロバイダーと約 1,900 のモデルをうたっていますが、ドキュメントはまだ 100+ と記載しています。コアは MIT ライセンスです。有料の Enterprise ライセンスを入れると、同じイメージ上でガバナンス機能が有効になります。
解決する運用上の課題はこうです。5つのチームが n8n のフロー、スクリプト、Claude Code の設定にキーを貼り付けて OpenAI、Anthropic、Bedrock を呼び出しており、財務は誰が何に使ったか把握できず、漏洩したキーを1つ失効させるにもすべてのツールを探し回る必要があります。
2026年のセキュリティ履歴
購入者が最初に知るべき点なので、機能より先に記載します。
2026年3月24日。 PyPI 上のバージョン 1.82.7 と 1.82.8 に認証情報窃取マルウェアが仕込まれ、約 40 分後に PyPI により隔離されました。LiteLLM は、CI 内でバージョン固定されていなかった Trivy スキャナーが静的な公開用認証情報を露出させたことが原因だとしています。公式のプロキシ Docker イメージは影響を受けませんでした。リリースは一時停止され、Mandiant が調査に入り、Trusted Publishing と cosign 署名を備えて再構築したパイプラインから 3月30日に v1.83.0 がリリースされました。
2026年10月21日。 バージョン 1.107.0 が再び侵害されました。今回は PyPI（約2時間）に加え、Docker Hub と GHCR 上のプロキシイメージも対象で、latest と main-stable タグも含まれます。ペイロードはクラウドの認証情報とプロキシのデータベースに保存されたすべてのプロバイダーキーを盗み、リモートコードローダーを設置しました。10月23日の根本原因レポートによると、5月に公開リポジトリへ漏れた管理者キーが失効されないまま残っており、攻撃者はそれを使って組織 owner の GitHub トークンを入手し、署名付きの正規リリースパイプラインを名前がほぼ同じフォークに向けました。Trusted Publishing と署名は設計どおりに動作しましたが、攻撃者が owner 権限を持っていたため防げませんでした。プライベートレジストリを使う Enterprise 顧客は影響を受けていません。 固定すべき安全なバージョンは 1.106.2 で、10月24日以降はローテーション済みの cosign キーで署名されたクリーンなリリースが出ています。
10月30日の続報では、期限付きの対策が示されています。ハードウェアに紐づく単一のリリース承認者と Splunk への監査ログ送信は完了済み、フィッシング耐性のある MFA とシークレットスキャンは 11月30日まで、不一致の成果物を自動で取り下げる外部検証ツールは 12月31日までです。プロジェクトは存続しておりリリースも続いています（1.108.4 が 11月9日に公開）が、これらは計画であって実績ではありません。
実際に購入するもの
オープンソース（無料）。 SDK とプロキシで、仮想キー、キーごとの予算と RPM/TPM 制限、費用トラッキング、Admin UI、ロードバランシングとフォールバック、ガードレールのフレームワーク、Presidio による PII マスキング、MCP ゲートウェイ、Langfuse、LangSmith、Arize Phoenix、OpenTelemetry へのロギングコールバックを利用できます。Admin UI の SSO は 5 ユーザーまで無料です。
Enterprise ライセンス。 同じイメージに設定する LITELLM_LICENSE キーと、プライベートなリリースレジストリへのアクセスです。5 ユーザーを超える SSO、SCIM、JWT 認証、保持期間付きの監査ログ、組織・チーム単位の RBAC、シークレットマネージャー連携（AWS、Azure、Google、HashiCorp Vault、CyberArk）、IP 許可リスト、キーのローテーション、タグ別・モデル別の予算、チーム単位のロギング制御、Lakera のプロンプトインジェクション検査などライセンス制のガードレール連携、サポート SLA（Sev 0 は 1 時間、セキュリティパッチは 72 時間）が加わります。
価格
2026-11-10 に litellm.ai と docs.litellm.ai で確認しました。オープンソースは $0 です。Enterprise の価格は公開されていません。 ドキュメントには価格は「デプロイ規模によって異なる」とあり、見積もりのみで、直接購入、請求書払い、AWS と Azure Marketplace 経由で販売され、30 日間のトライアルキーはセルフサービスで取得できます。LiteLLM 自身は、100+ ユーザーまたは 10+ の本番 AI ユースケースを持つチームを Enterprise の対象としています。第三者のガイドは 2024年のローンチ時の年間約 $30,000 という数字を今も引用していますが、見積もりではなく未検証の予算目安として扱ってください。
無料プランの本当のコストは人です。Postgres データベース、複数インスタンスでレート制限を効かせるための Redis、そしてアップグレードとインシデント対応を担うエンジニアが必要です。無料と呼ぶ前に、プラットフォームエンジニア1人分の一部を予算に入れてください。
最適な対象
すでにコンテナを運用しており、複数プロバイダーのモデルキーを1か所で発行・上限設定・失効させたいプラットフォームまたは RevOps のエンジニアリングチームで、データレジデンシーの理由からゲートウェイを自社 VPC 内に置きたい場合です。本番の依存先にしている企業にとっては、10月の侵害を免れたプライベートレジストリがあるため、今は Enterprise が妥当なプランです。
向いていないケース
インフラのオンコール担当がいないチームです。マネージド型ゲートウェイのほうが、失敗したアップグレード1回より安く済みます。単一プロバイダーの企業にも向きません。すべての呼び出しが Bedrock か Azure に向かうなら、ネイティブのクォータと IAM でほぼ足ります。また、オブザーバビリティ層でもありません。費用は記録しますが、トレースと評価は Langfuse か LangSmith の役割です。
代替製品との比較
- Amazon Bedrock または Microsoft Foundry — 呼び出しの 80%+ がすでに1つのクラウドを経由し、IAM をアクセス制御に使っているなら、そのクラウドのモデルプラットフォームを選んでください。
- OpenRouter — 最も急成長しているホスト型の選択肢で、現在は Stripe 傘下です。数百のモデルを1つの請求にまとめ、インフラを持たずに済ませたい場合で、リクエスト経路に第三者が入ることを許容できるなら選んでください。
- Portkey — ホスト型のコントロールプレーンを持つオープンソースのゲートウェイで、2026年5月に Palo Alto Networks が買収し Prisma AIRS に統合されました。セキュリティチームがすでに Palo Alto から購入しているなら選んでください。
- Kong AI Gateway または Cloudflare AI Gateway — そのベンダーがすでに API の前段にあり、モデルへのトラフィックも同じポリシーで管理したいなら選んでください。
- モデルではなくエージェントからツールへのトラフィックについては、Runlayer が MCP サーバーを統制します。LiteLLM の MCP ゲートウェイはより軽量です。
では、セルフホストの LiteLLM は今も安全でしょうか。問題はコードではなく、7 か月で2度破られたリリースチャネルでした。バージョンを固定し、署名を検証し、被害範囲を封じ込められるなら使い続けてください。そうでなければ、Enterprise に費用を払うか、マネージド型ゲートウェイへ移行してください。
注意点
- フローティングタグが10月のマルウェアを取り込みました。
latestやmain-stableをデプロイしていた環境は、数分で悪性イメージを受け取りました。対策：イメージダイジェストで正確なバージョンを固定し、ローテーション後のキーで cosign 署名を検証し、リリース後 48 時間待ってから本番に昇格させてください。 - プロキシのデータベースは全プロバイダーキーの金庫です。 10月のペイロードが盗んだのはまさにそれでした。対策：プロバイダーキーはプロキシの DB ではなくシークレットマネージャーに保管し（Enterprise 機能）、プロキシのホストには広範なクラウドロールを持たない最小権限の IAM を与え、アウトバウンド通信をプロバイダーのエンドポイントに限定してください。
- インシデント後のローテーションは大規模です。 復旧にはホストの IAM ロール、保存されたすべてのプロバイダーキー、マスターキー、すべての仮想キー、データベースのパスワードのローテーションが必要でした。対策：キーのローテーションをスクリプト化し、四半期に1回リハーサルして、インシデント対応を1週間ではなく1時間で終えられるようにしてください。
- 無料の SSO は 5 ユーザーまでです。 それを超えると Admin UI へのアクセスにライセンスが必要です。対策：Admin UI はプラットフォームチームに限定してほかのメンバーには仮想キーを配布するか、6 人目の管理者が必要になる前に Enterprise を予算化してください。