AIゲートウェイのLiteLLM、認証情報の漏れを2件修正。v1.100.0は破壊的変更も2件

LiteLLM v1.100.0 は、AIゲートウェイのLiteLLMが2026年9月6日に公開した更新版で、認証情報が意図せず漏れる2つの経路を塞いだ点が実務上の要点です。

📖 この記事で分かること

• LiteLLM v1.100.0が9月6日に公開された事実
• 認証情報の漏えいを塞ぐ修正が2件入ったこと
• 更新前に確認すべき破壊的変更2件の中身
• 対応プロバイダとコスト計上まわりの拡張点

💡 知っておきたい用語

• AIゲートウェイ: 社内の各アプリと複数のAI事業者の間に立つ「中継所」。窓口を1つにまとめ、鍵の管理・利用量の記録・上限の設定をここで一括して行う仕組みです。
• virtual key: 本物のAPI鍵の代わりに、チームや用途ごとに発行する「合鍵」。誰がどれだけ使ったかを分けて数え、必要なときはその合鍵だけを止められます。

最終更新日: 2026年9月8日

▶ 公式ページ

• LiteLLM v1.100.0 リリースノート(GitHub)
• v1.99.0 → v1.100.0 の全差分(GitHub)

LiteLLM v1.100.0 で何が変わったのか

複数のAI事業者をまとめて扱うAIゲートウェイ「LiteLLM」の v1.100.0(2026年9月時点)が、2026年9月6日05:33 UTC(日本時間同日14:33)に公開されました。中でも実務に直結するのは、認証情報の扱いに関する2件の修正です。

この記事のポイント

• BerriAI が LiteLLM v1.100.0 を2026年9月6日に公開しました(2026年9月時点)。
• 呼び出し元の virtual key が漏れる経路と、リトライ記録に認証情報が写る経路の2件を修正。
• 破壊的変更が2件あり、prompt_token_calculator を使っている環境は更新前に確認が必要です。

リリースノートに並ぶ変更は400件超のPRリンクにわたり(重複記載を含む)、新規コントリビューターは14名。プロバイダ追加やUIの改善も含む大きめの更新ですが、更新を急ぐ理由になるのはセキュリティ側の修正です。

認証情報が漏れる経路を2つ塞いだ

今回、認証情報の取り扱いに関する修正が2件入りました。いずれも「本来外に出ないはずの鍵が、別の場所に写っていた」という性質のものです。

1つ目は、認証情報を持たない Vertex passthrough 経路で、呼び出し元の virtual key が漏れていた問題の修正です(PR #38114)。passthrough は、ゲートウェイが中身に手を加えず事業者側へそのまま流す経路を指します。この経路で合鍵が意図せず外へ出ていたことになります。

2つ目は、リトライ時の記録に、転送された認証情報がコピーされていた問題の修正です(PR #38133)。失敗して再試行したときの経緯を残す仕組みに認証情報が混ざると、ログ基盤を見られる範囲すべてが鍵の露出範囲になります。

このほか、RAG【ラグ】の取り込み経路である /v1/rag/ingest に、ベクトルストアのアップロードに関するセキュリティ制御が適用されました(PR #38135)。社内文書を投入する入口が、これまで別扱いになっていた制御下に入った形です。ログ側では、伏せ字処理済みのツール呼び出し引数を解析しないようになりました(PR #38169)。

配布物の検証手段も明示されています。Docker イメージは cosign で署名されており、リリースノートはタグ指定よりも、コミットハッシュ 0112e53 で署名鍵をピン留めする検証を推奨しています。

破壊的変更は2件。更新前に確認する

v1.100.0 には破壊的変更が2件含まれます。数としては少ないものの、片方は影響範囲が読みにくいものです。

• prompt_token_calculator の削除(PR #38132)。この関数を直接呼んでいるコードがあれば、更新後に動かなくなります。
• Cerebras 向けに get_supported_openai_params へ max_retries と extra_headers を追加(PR #36601)。

自社のコードや社内ツールが LiteLLM をライブラリとして読み込んでいる場合、prompt_token_calculator の利用有無を先に検索しておくのが安全です。プロキシとして立てているだけの構成であれば影響は限定的ですが、トークン数を自前で見積もる処理を書いている環境では確認が要ります。

対応範囲とコスト計上の拡張

プロバイダ対応も広がりました。Vertex AI Interactions API のネイティブ対応が入り(PR #38229)、検索プロバイダとして Grounding with Bing Search が追加されています(PR #38119)。Azure AI Foundry は全ルートで Entra ID / OAuth 認証に対応しました(PR #35415)。

生成系では、Runway の生成エンドポイント全体がルーティング対象になり、動画のコスト計上が修正されました(PR #38115)。画像・動画ルートを OpenAI SDK の通信形式に合わせる修正も入っています(PR #38104)。Together AI は既定のエンドポイントが api.together.xyz から api.together.ai へ変わり(PR #38233)、サーバーレスモデルがコストマップに追加されました(PR #38230)。

課金・予算まわりでは、Google Interactions API リクエストのコストと利用額の記録(PR #33310)、Databricks でキャッシュ済みトークンをキャッシュ単価で計上し不足していた Claude の料金を補う修正(PR #37975)、Azure Model Router で実際に選ばれたモデルを利用ログに残す修正(PR #37770)が入りました。Terraform 側では litellm_team に soft_budget、tags、soft_budget_alerting_emails が追加されています(PR #37918)。

運用面では、Redis Cluster を redis-py の実装に寄せて接続単位で復旧するようにした修正(PR #38171)、イベントループが切り替わったときに処理待ちのログを捨てず引き継ぐ修正(PR #38144)、想定内の4xx応答の失敗ログでワーカーのCPUを埋め尽くさない修正(PR #38102)などが並びます。UIにはダークモード対応と、失敗リクエストのエラーコード別の掘り下げ表示が入りました。

編集部の見方

編集部は、このリリースを「新機能を取りに行く更新」ではなく、認証情報の露出を止めるための更新として扱うべきだと考えます。

• 根拠1: 修正された2件(PR #38114、PR #38133)は、いずれも設定ミスではなくゲートウェイ側の挙動として鍵が別の場所へ写る性質のもので、利用側の運用では回避できません。
• 根拠2: LiteLLM はチームや用途ごとに合鍵を配って利用量を分ける前提で使われるため、virtual key の露出はそのまま権限分離の前提が崩れることを意味します。
• 根拠3: 破壊的変更は2件のみで、うち影響が読みにくいのは prompt_token_calculator の削除だけです。確認コストが小さく、更新を先送りする理由になりにくい構成です。

この見方が変わる条件は、自社の構成が LiteLLM をライブラリとして深く組み込んでいる場合です。その場合は削除された関数の影響調査が先に来るため、検証環境での確認を挟んでから本番へ入れる順序になります。なお今回の2件について、実際に情報が外部へ渡った事例が報告されているかどうかは、リリースノートからは分かりません。

よくある質問

Q: どのような環境が今回の修正の影響を受けますか

A: リリースノートの記述からは、認証情報を持たない Vertex passthrough 経路を使っている環境と、リトライの記録を保存している環境が該当します。具体的な条件の細部までは公開情報からは分かりません。

Q: 更新前に何を確認すればよいですか

A: prompt_token_calculator を直接呼び出しているコードの有無です。この関数は v1.100.0 で削除されました。Cerebras を使っている場合は get_supported_openai_params の戻り値の変化も確認対象になります。

Q: 配布されている Docker イメージが正規のものか確かめられますか

A: cosign による署名検証が用意されています。リリースノートでは、タグを指定する方法よりも、コミットハッシュ 0112e53 で署名鍵をピン留めして検証する方法が推奨されています。

まとめ

LiteLLM v1.100.0 は2026年9月6日に公開され、呼び出し元の virtual key が漏れる経路と、リトライ記録に認証情報が写る経路の2件を修正しました。RAG 取り込み経路へのセキュリティ制御適用、プロバイダ対応の拡張、コスト計上の修正も含まれます。破壊的変更は prompt_token_calculator の削除など2件で、ライブラリとして組み込んでいる環境は更新前に利用箇所の確認が必要です。

【用語解説】

• passthrough: ゲートウェイが要求の中身を変換せず、AI事業者のAPI【エーピーアイ】へそのまま流す経路のこと。
• cosign: コンテナイメージなどの配布物に電子署名を付け、受け取り側が正規のものか検証するための仕組み。
• ベクトルストア: 文書を検索しやすい数値表現に変換して貯めておく保管庫。RAG で参照先として使われます。

引用元:

• [1] LiteLLM v1.100.0 リリースノート(GitHub)
• [2] v1.99.0 → v1.100.0 の全差分(GitHub)
• [3] PR #38114: stop leaking the caller’s virtual key on credential-less Vertex passthrough(GitHub)
• [4] PR #38135: enforce vector-store upload security controls on /v1/rag/ingest(GitHub)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。