複数のLLM（大規模言語モデル）プロバイダーを1つのAPIで切り替えて使うためのプロキシ、LiteLLMを本番導入している組織、あるいは導入を検討している情報システム部門に向けた内容です。2025年10月公開のv1.106.0-rc.1で、Dockerイメージの署名検証手順が整理されました。地味な変更に見えますが、サプライチェーン攻撃対策とベンダー管理の観点では見逃せない話です。
LiteLLMは、OpenAI・Anthropic・Google Geminiなど100以上のLLM APIを、統一フォーマットで呼び出せるようにするオープンソースのプロキシ層です。社内に複数チームが別々のLLMベンダーと契約していると、API仕様の違いがコスト管理や監査の妨げになります。LiteLLMを間に挟むことで、呼び出し方法を揃えつつ、利用量やコストを一元的に可視化できます。
今回の変更点は何か
v1.106.0-rc.1では、配布されているDockerイメージがcosign（Sigstoreプロジェクトが提供する署名ツール）で署名されていることが明示されました。すべてのリリースは、特定のコミット（0112e53）で導入された鍵で署名されています。
署名検証とは、ダウンロードしたソフトウェアが「本当に開発元が作ったもの」であり「配布経路で改ざんされていないもの」かを確認する仕組みです。LiteLLMのように外部APIキーを扱うミドルウェアが改ざんされると、APIキーの漏えいやリクエスト内容の窃取につながりかねません。
検証方法を段階的に見る
公式には2通りの検証コマンドが示されています。まずコミットハッシュを固定する方法です。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.106.0-rc.1コミットハッシュはGitの仕組み上、一度確定すると書き換えられません。公開鍵の取得元を最も確実に固定できる方法です。
もう1つはリリースタグを使う方法です。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/v1.106.0-rc.1/cosign.pub \
ghcr.io/berriai/litellm:v1.106.0-rc.1タグはリポジトリ側の保護設定（タグプロテクション）に依存するため、コミットハッシュ方式よりはやや信頼の前提が増えます。読みやすさを取るか、堅牢性を最優先するかの判断になります。
検証に成功すると「The cosign claims were validated」「The signatures were verified against the specified public key」という出力が返ります。これが確認できれば、イメージが公式の鍵で署名された正規のものだと判断できます。
なぜベンダー管理の観点で重要か
オープンソースのミドルウェアを本番環境に組み込む際、情報システム部門が最も気にするのはサプライチェーンリスクです。GitHub上のコンテナレジストリやDocker Hubに公開されたイメージは、理屈の上では誰でも偽物を紛れ込ませる余地があります。
署名検証の仕組みは、npmのパッケージ署名やSLSA（Supply chain Levels for Software Artifacts、ソフトウェア供給網の安全性レベルを定義する枠組み）といった、近年広がっているソフトウェア供給網セキュリティの考え方と同じ系統にあります。日本国内でも経済産業省やIPAがソフトウェアサプライチェーンリスクへの注意喚起を続けており、OSS導入時の検証プロセスを社内規程に組み込む動きが見られます。LiteLLMの署名検証は、そうした規程に具体的な根拠を与える材料になります。
商用のAPIゲートウェイ製品（Kong、Apigeeなど）を使う場合は、ベンダーが提供するSLA（サービス品質保証）やサポート契約の中で改ざん対策が担保されます。LiteLLMのようなOSSを選ぶ場合は、こうした検証作業を自社の運用フローに組み込む必要がある点が、意思決定上の違いです。コストは抑えられても、運用の手間とセキュリティ検証の責任は自社に戻ってきます。
今回のリリースはrc（release candidate、正式版の前段階として検証を目的に配布されるバージョン）扱いです。rcは機能面の変更が多く含まれる一方、本番導入の判断材料としては、まず安定版での同様の署名体制を確認するのが無難です。
今日確認できること
自社でLiteLLMを使っている、あるいは導入を検討しているなら、次の点を確認しておくと判断がしやすくなります。
- 現在使っているイメージのバージョンタグを
docker inspectやデプロイ設定ファイルで確認する - GitHub Releasesページで該当バージョンに署名検証コマンドが記載されているか確認する
- CI/CDパイプラインのイメージpull工程に
cosign verifyを組み込めるか、インフラ担当と相談する - 社内のOSS利用ガイドラインに「コンテナイメージの署名検証」という項目があるか見直す
- rc版と安定版（正式リリース）のどちらを本番で使っているか、バージョニング方針を確認する
特にCI/CDパイプラインへの組み込みは、一度仕組み化すれば以降のアップデートのたびに手動確認する手間が省けます。GitHub ActionsやCircleCIのデプロイステップに検証コマンドを1行足すだけで、継続的な検証体制が作れます。
まとめ
LiteLLMのDocker署名検証は、機能追加ではなく信頼性を担保する仕組みの明文化です。複数LLMベンダーを横断管理する基盤だからこそ、基盤自体の改ざんリスクは高くつきます。
判断基準としては、コミットハッシュ固定方式を基本線にしつつ、タグ保護設定の運用状況も合わせて確認するのが現実的です。まずは自社のデプロイ設定に記載されているバージョンタグを洗い出し、該当リリースのページで署名検証コマンドが提供されているかを確かめるところから始めてみてください。