LiteLLMとは──100超のLLM APIを一本化するOSSゲートウェイと、2026年に露呈した「鍵束」のリスク¶

対象 / ポイント

対象: 複数のLLMプロバイダーを社内共通基盤として束ねたいプラットフォーム／インフラ担当者。

ポイント:

LiteLLMは100超のLLMをOpenAI形式で扱えるPython SDK兼AIゲートウェイだ
Proxyには仮想キー、予算、コスト追跡、フォールバック、MCP／A2A統制が入る
2026年の改ざん版とCVE連鎖により、導入には隔離・即時更新・全鍵ローテーションが欠かせない

2026年3月24日、正規のLiteLLM PyPIパッケージに悪性コードを入れた2バージョンが公開された。公開時間は約40分だったが、資格情報の収集、Kubernetesでの横展開、永続化を狙うコードが含まれていた⁶⁷。狙われたのはモデルではない。複数のモデルへ通じるゲートウェイだった。

この記事の問いは1つだ。100超のLLM APIを束ねる便利さと、すべての鍵が集まる危険を、どう両立させるのか。

LiteLLMが消すのは「プロバイダーごとの配線」¶

LiteLLMの役割は、アプリケーションとLLMプロバイダーの間に共通面を置くことだ。アプリケーションはOpenAI形式で送信し、LiteLLMがAzure、Anthropic、Bedrockなどの形式へ変換する。応答とエラーも共通形式へ寄せるため、プロバイダー追加のたびに接続コードを作り直す範囲を減らせる¹。

対象は/chat/completionsだけではない。 /responses、Anthropic形式の/messages、/embeddings、/batches、/a2aなどもカバーする¹。ただし、モデル固有のパラメーターや機能差まで消えるわけではない。統一されるのは共通の呼び出し面である。

利用形態は2つあり、選択基準は「どこで差分を吸収するか」にある。

	Python SDK	AIゲートウェイ（Proxy）
形態	アプリケーションへ組み込むライブラリー	独立したHTTPサーバー
主な利用者	LLMアプリケーションの開発者	プラットフォーム／インフラチーム
中心機能	リトライ、フォールバック、ルーティング	仮想キー、予算、監査、管理UI
適する範囲	1つのアプリケーション内	複数チーム・複数サービスの共通基盤

公開時点のGitHubスターは約5.4万、2026年3月の集計ではPyPI月間ダウンロードが約9,500万件だった¹³。本体はMITライセンスで、SSOなど一部の企業向け機能は商用ライセンスに分かれる²¹。

仕組みを理解する最短経路は、実際に2つの宛先を同じエンドポイントへ載せることだ。

最小構成はconfig.yamlと1つのコンテナ¶

最小構成では、モデルの別名と接続先をconfig.yamlへ書き、Proxyを起動する。次の例はAzure OpenAIとAnthropicを同じ窓口へ載せる⁴。

config.yaml

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: azure/my_azure_deployment
      api_base: os.environ/AZURE_API_BASE
      api_key: os.environ/AZURE_API_KEY
  - model_name: claude
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: os.environ/ANTHROPIC_API_KEY

docker run -d -p 4000:4000 \
  -e AZURE_API_BASE="https://<resource>.openai.azure.com/" \
  -e AZURE_API_KEY="..." -e ANTHROPIC_API_KEY="..." \
  -e LITELLM_MASTER_KEY="sk-change-me" \
  -v "$(pwd)/config.yaml:/app/config.yaml" \
  ghcr.io/berriai/litellm:v1.92.0 \
  --config /app/config.yaml

curl http://localhost:4000/chat/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer sk-change-me' \
  -d '{"model":"claude","messages":[{"role":"user","content":"こんにちは"}]}'

modelをgpt-4oへ変えれば、呼び出し方を変えずにAzure側へ流れる。例では公開時点の最新版v1.92.0へ固定した²。本番では承認したリリースをコンテナdigestまで固定し、署名をcosignで検証する¹。

この短い構成が提供するのは変換だけではない。組織導入で効くのは、その後段にある統制だ。

価値は変換より統制にある¶

Proxyを共通窓口にすると、アプリケーションごとに散っていた認証・予算・ログを1カ所へ寄せられる。公式ドキュメントとREADMEが示す本番機能は、次の5群に整理できる¹⁴。

仮想キーと上限: 生のプロバイダーキーを配らず、利用者・チーム単位で予算、RPM、TPMを設定する
コスト追跡: モデル単価を基に、支出をキー、チーム、組織別へ集計する
ルーティング: 同名モデルを複数デプロイへ束ね、リトライ、負荷分散、フォールバックを行う
ガードレールとログ: PII検知、外部可観測性基盤への連携、管理UIを共通化する
MCP／A2Aゲートウェイ: ツール呼び出しとエージェント間通信も同じ認証・監査面へ載せる

性能について、READMEは毎秒1,000リクエスト時のP95を8msと掲げる¹⁵。これはベンダー計測値であり、データベース、コールバック、ガードレールを有効にした自環境の値ではない。水平スケールと負荷試験を前提に読む数字だ。

Docker Compose、Helm、AWS／GCP向けTerraformモジュールも用意されている¹。デプロイ経路が太いほど導入は速い。だが、同じ速さで攻撃面も組織へ入る。

2026年に「鍵束」のリスクが露呈した¶

AIゲートウェイは、接続するプロバイダーの資格情報とLLMトラフィックへ到達できる。その侵害は、通常のWebアプリケーション1台より広い影響を持つ。 2026年の主な事象を時系列で並べると、攻撃対象になった理由が見える。

時期	事象	確認できた影響と修正
3月24日	PyPIの`1.82.7`／`1.82.8`を改ざん	Trivy侵害を経てPyPI公開トークンが漏れたとみられる。約40分で隔離。公式Proxyイメージは非該当⁶⁷
3月30日〜4月	外部監査と`1.83.0`	既定で無効のJWT認証を明示的に有効化した環境のバイパスなどを修正し、バグバウンティを開始⁸
4月20日〜5月8日	CVE-2026-42208	未認証SQLインジェクション。`1.83.7`で修正。公開DB掲載から36時間7分後に攻撃試行を観測し、KEV入り⁹¹⁰¹¹
4月21日〜6月8日	CVE-2026-42271	MCPテスト経由の認証済みコマンド実行。`1.83.7`で修正。Starletteの欠陥と連鎖する未認証RCEも実証され、KEV入り¹²¹³¹⁴¹⁵
5月28日	CVE-2026-49468	Hostヘッダーを使う別の認証回避。`1.84.0`未満が影響し、`1.84.0`で修正¹⁶

ここから引ける教訓は3つある。

被害単位は全資格情報: 侵害時はパッチだけで終えず、仮想キー、マスターキー、プロバイダーキーを棚卸しする
更新猶予は時間単位: CVE-2026-42208では攻撃試行が36時間7分後に現れた。翌営業日の判断では遅い
周辺機能が入口になる: キー検証、MCPテスト、Hostヘッダー処理など、管理・補助経路が本流を迂回した

開発元は、外部監査、バグバウンティ、CI/CDの分離、cosign署名を導入した⁶⁸。対応の速さは評価できる。一方、1.83.7で1件を直しても、後から1.84.0未満を対象とする別の欠陥が開示された。

つまり、固定すべきなのは「安全とされた古い版」ではない。Advisoryを追い、検証済みの新しい版へ動ける手順である。

導入するなら5つの前提を置く¶

LiteLLMは、複数プロバイダーを自社の統制下で束ねたい組織には依然として有力だ。ただし、採用条件は機能表ではなく、次の運用を平時から回せることにある。

版と成果物を固定する: latestを避け、影響範囲を確認したタグとdigestを固定し、cosign署名も検証する
直公開しない: 閉域または相互認証付きリバースプロキシの背後へ置き、Hostヘッダーを正規化する
管理面を分離する: 管理UI、キー発行、MCPテストなどを利用経路から分け、管理者だけに到達を許す
鍵の権限と寿命を絞る: プロバイダー側でも予算・権限を最小化し、一括ローテーション手順を演習する
時間単位の更新手順を持つ: GitHub Security AdvisoriesとCISA KEVを監視し、同日中に検証・展開できるようにする

ここで-stableの意味を取り違えないことが重要だ。公式READMEでは12時間の負荷試験を通したタグとして推奨されるが、これは脆弱性がないことを保証しない¹。公開時点の最新版は1.92.0であり、採用時にはそれ以降のAdvisoryも改めて確認する必要がある²。

では、運用責任まで含めてLiteLLMを選ぶべき場面はどこか。

導入判断──統制を内に持つか、運用責任を外へ出すか¶

LiteLLMが向くのは、データ、ログ、鍵、ルーティング方針を自社の境界内で持つ必要がある場合だ。閉域・オンプレミス、チーム別の予算按分、独自のMCP統制、複数クラウドの切り替えが中心なら、その自由度が効く。

判断軸	LiteLLMを自前運用	マネージド型ゲートウェイ
データとログ	自社境界内へ置きやすい	ベンダーの保存・処理条件を確認する
カスタマイズ	ルーティングや認証を深く変えられる	提供範囲内で設定する
更新と障害対応	自社が即時対応する	サービス提供者へ委ねる部分が増える
資格情報の責任	自社の設計・保管・ローテーション	責任分界を契約と構成で確認する

反対に、単一プロバイダーだけを使い、専任の基盤・セキュリティ運用を置けないなら、OpenRouterやCloudflare AI Gatewayなどの管理型も比較対象になる。既存のKong GatewayをAI向けに拡張する方法や、Envoy AI Gatewayも選択肢に入る¹⁸。分かれ目は機能数ではなく、鍵束を誰が守り、何時間で更新できるかだ。

まとめ¶

LiteLLMは100超のLLMを共通形式で扱うPython SDK兼AIゲートウェイで、仮想キー、予算、ルーティング、MCP／A2A統制まで集約する
2026年の改ざん版、SQLインジェクション、MCP経由のコマンド実行、Hostヘッダー認証回避は、ゲートウェイが高価値な資格情報面であることを示した
採用の成否は、隔離、最小権限、成果物検証、時間単位の更新、全鍵ローテーションを実行できるかで決まる

新しい選定基準は、対応プロバイダー数ではない。プロバイダーを1つ増やすたび、障害時に切り替えられる価値と、侵害時に回す鍵が1つ増える。 便利さの拡大率と被害半径の拡大率を、同じ設計会議で扱うことがAIゲートウェイ運用の出発点になる¹⁷。