複数のLLM（大規模言語モデル）API を一本化するプロキシとして、LiteLLM（OpenAI・Anthropic・Gemini など各社のAPIを共通のインターフェースで呼び出せるオープンソースのゲートウェイ）の採用を検討している組織は増えています。
2025年10月30日にリリースされたv1.109.0-dev.2では、機能追加よりも「配布物の安全性をどう検証するか」という運用面の変更が目立ちます。社内のLLM基盤にLiteLLMを組み込む予定がある方、すでに運用していてアップデート方針を決めかねている方の判断材料として整理します。
何が変わったのか
今回のリリースで明示されたのは、配布されるDockerイメージの署名検証手順です。
LiteLLMのDockerイメージはすべてcosign（Sigstoreプロジェクトが提供するソフトウェア署名ツール）で署名されています。cosignは、コンテナイメージが「公開された鍵を持つ発行者によって作られたものか」「配布後に改ざんされていないか」を検証できる仕組みです。
具体的には、公開鍵のURLとイメージタグを指定してコマンドを実行すると、署名の正当性が確認できます。公式リリースノートには2通りの方法が示されています。
# コミットハッシュを固定して検証する方法（推奨）
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/e82a3c646908ba0a6ee0beddc4310d7a6cac4065/cosign.pub \
ghcr.io/berriai/litellm:v1.109.0-dev.2# リリースタグを使う簡易な方法
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/v1.109.0-dev.2/cosign.pub \
ghcr.io/berriai/litellm:v1.109.0-dev.2前者はコミットハッシュ（Gitの変更履歴を一意に識別する不変の文字列）を直接指定するため、鍵の出所が改変されるリスクがありません。後者はタグ名で参照するため読みやすい一方、タグの保護設定（force pushや上書きを禁止する設定）に依存します。公式ドキュメントもコミットハッシュ方式を推奨しています。
なぜこの変更がガバナンス上重要か
LLMゲートウェイのようなミドルウェアは、社内のあらゆるAI呼び出しが経由する単一障害点になりがちです。
ここにサプライチェーン攻撃（ソフトウェアの配布経路や依存関係に不正なコードを混入させる攻撃手法）が成立すると、通過するプロンプトやAPIキーが広範囲に漏えいするリスクがあります。2021年のCodecovインシデントや2020年のSolarWindsの事例以降、イメージの出所検証はセキュリティ監査の標準項目になりつつあります。
cosignによる署名検証は、この種のリスクを技術的に低減する手段のひとつです。ただし運用上は「検証コマンドを誰が・いつ・どの環境で実行するか」を決めておかないと形骸化します。
CI/CDパイプラインのイメージpullステップに検証を組み込むか、少なくとも本番デプロイ前のチェックリストに追加するかは、導入前に決めておくべき運用設計です。
関連技術との比較で見る位置づけ
コンテナイメージの署名検証にはいくつかの選択肢があります。整理すると判断がしやすくなります。
| 方式 | 特徴 | 向いている組織 |
|---|---|---|
| cosign（公開鍵固定） | 鍵をリポジトリ内で管理・配布。導入コストが低い | 中小規模チーム、まず検証を始めたい組織 |
| Sigstore keyless署名 | OIDC認証と一時証明書を使い鍵管理を不要化 | すでにOIDC基盤がある組織 |
| Notary/Docker Content Trust | Docker公式の署名機構。レジストリ側対応が必要 | Docker Hub中心の運用 |
LiteLLMが採用しているのは最初の「公開鍵を固定するcosign」方式です。鍵の管理主体がBerriAI（LiteLLM開発元）に委ねられる点は留意が必要です。
自社でSigstoreのkeyless署名基盤をすでに運用している場合は、ベンダー側の鍵管理方針（ローテーション頻度、鍵漏えい時の対応手順）も合わせて確認しておくと安心です。
導入・運用担当者が今日確認できること
既存でLiteLLMを運用している場合、まず自社のバージョンを確認します。
# 稼働中のコンテナのイメージタグを確認
docker inspect --format='{{.Config.Image}}' <container_id>バージョンが確認できたら、次の3点をチェックリストとして見直すことをおすすめします。
- 現在使用しているイメージタグが、署名検証付きでpullされる運用になっているか
- イメージの取得元がghcr.io/berriai/litellmの公式レジストリであり、独自ミラーやキャッシュ経由でないか
- デプロイパイプライン（GitHub Actions・ArgoCD等）にcosign verifyのステップを追加する余地があるか
これはLiteLLMに限った話ではありません。LLMゲートウェイやAPIプロキシ全般を選定する際、ベンダーが署名検証の仕組みを提供しているかどうかは、技術選定のチェック項目に加えておく価値があります。
同じリリースでは、Databricks・Tavily・Anthropic・Cohere向けの価格設定やレスポンス形式の修正も複数件含まれています。これらは個別のプロバイダ連携を使っているチームにとって、アップグレード判断に関わる実務的な変更点です。
アップグレード前にはGitHubのリリースノート本文にある「What's Changed」一覧を確認し、自社が利用しているプロバイダ（Databricks・Tavily・Anthropic・Cohereなど)に関連する修正が含まれていないか照合することをおすすめします。
まとめ
今回のリリースで押さえておきたいのは次の3点です。
- Dockerイメージの署名検証(cosign)が明文化され、サプライチェーンリスクへの対策が可視化された
- 検証にはコミットハッシュ固定方式とタグ指定方式があり、前者がより安全性が高い
- 既存運用では、イメージの取得元・バージョン・パイプラインへの検証組み込み状況を点検する価値がある
LLMゲートウェイのようにAPIキーとプロンプトが集約するコンポーネントは、機能面だけでなく配布の安全性も選定基準に含めておくと、後々の監査対応が楽になります。まずは手元の環境でdocker inspectによるバージョン確認とcosign verifyの実行から始めてみてください。