LiteLLM（複数のLLM APIを統一インターフェースで呼び出せるオープンソースのプロキシ/SDK）をプロダクションで使っているチームに向けた内容です。リリースタグの命名規則と、RC（Release Candidate、正式リリース前の検証版）を本番運用に紛れ込ませてしまう運用上のリスクを整理します。
2025年11月に公開されたv1.107.0-rc.3は、一見すると通常のバージョンアップのように見えます。ところが実際には「1.108.0が現行の安定版である一方、まだ1.107系のRCを使っているユーザー向けに個別の修正を当てたパッチ」という、やや特殊な位置づけのリリースです。この構造を理解せずにアップグレード作業を進めると、スプリント内で思わぬ手戻りが発生します。
何が起きるか
チームの依存関係管理が機械的な「最新タグ追従」になっている場合、v1.107.0-rc.3のようなプレリリースタグを本番環境に取り込んでしまう事故が起こります。
GitHubのリリースページではPre-releaseのラベルが付いていますが、CI/CDのパイプラインがタグ名のパターンマッチだけで判定していると、このラベルを見落とします。
結果として、検証が不十分なRC版を本番で動かし続け、後から「なぜ1.108系ではなく1.107系のRCが動いているのか」を調査する手戻り工数が発生します。これはスプリントの見積もりに含まれていない「隠れた技術的負債の精算作業」です。
なぜ起きるか：原因を分解する
原因は大きく3段階に分けて考えると整理しやすくなります。
1段階目は、バージョニングの意味が開発チーム内で共有されていないことです。LiteLLMのリリースは1.107.0rc1からrc2、rc3を経て1.107.0に進むのが通常ですが、今回のケースでは1.108.0が先に安定版として出た後に、1.107系のRCだけ追加の修正版（rc3）が出ています。これは「まだ1.107系RCを使っているユーザーのための救済パッチ」であり、最新を追えば安全というわけではありません。
2段階目は、サプライチェーンセキュリティに関する運用知識の不足です。今回のリリースノートには過去のセキュリティインシデント（10月21日に発生したインシデント、Issue番号47826）を受けて、Dockerイメージの署名に使うcosignキー（コンテナイメージの改ざん検知に使う鍵）を新しいものに差し替えた旨が明記されています。鍵のローテーションが行われたタイミングを把握していないと、古い鍵で検証スクリプトを書いたまま放置し、検証自体が形骸化するリスクがあります。
3段階目は、見積もり文化の問題です。「ライブラリのパッチアップデートは0.5ポイント」のような画一的な見積もりルールを運用していると、RCかどうか、セキュリティ修正を含むかどうかの事前確認コストが見積もりから漏れます。これが積み重なると、依存関係更新というタスク自体がチームの中で軽視される技術的負債予備軍になります。
自分のプロジェクトが該当するか確認する
まず、現在使っているLiteLLMのバージョンを確認します。
pip show litellm | grep Version出力に「rc」や「b」（beta）といった文字列が含まれていれば、プレリリース版を本番で使っている状態です。
Dockerで運用している場合は、docker-compose.ymlやKubernetesのマニフェストファイルでイメージタグを確認します。
grep -r "ghcr.io/berriai/litellm" ./k8s ./docker-compose.ymlタグが「latest」や「main」のような固定されない指定になっていないか、「-rc.」を含むタグが紛れ込んでいないかをここで確認します。
さらに、依存関係の自動更新ツール（DependabotやRenovateなど）を使っている場合は、プレリリースタグを除外する設定になっているかを見直します。Renovateであれば「ignoreUnstable」、npm系のエコシステムであれば「prerelease」フィールドの扱いが該当します。LiteLLMはPythonパッケージなのでpipの依存関係管理ツール（Poetry、pip-tools等）の設定ファイルで、バージョン指定が曖昧な範囲指定になっていないかもあわせて確認してください。
対策の手順
対策はチームの運用ルールに落とし込むところまでが本番です。以下の4ステップで進めます。
- バージョン固定の徹底：requirements.txtやPoetryのpyproject.tomlで、RCを含まない安定版のみを明示的に固定する
- タグ命名規則のドキュメント化：「-rc.N」が付くタグは検証環境専用である旨をチームのWikiやREADMEに明記する
- 署名検証のCI組み込み：cosign verifyコマンドをデプロイパイプラインに組み込み、鍵のローテーションが起きた際に検知できるようにする
- 見積もりテンプレートの見直し：依存関係更新タスクのストーリーポイントに「バージョン種別の確認」「セキュリティ修正の有無確認」を見積もり項目として明文化する
cosignによる署名検証は、以下のようなコマンドで実行できます。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/e82a3c646908ba0a6ee0beddc4310d7a6cac4065/cosign.pub \
ghcr.io/berriai/litellm:v1.107.0-rc.3このコマンドはCIのデプロイ前フックに組み込んでおくと、万一古い鍵や改ざんされたイメージを引いてしまった場合に自動で失敗させられます。スクラムで運用しているチームであれば、これをスプリントの「Definition of Done」（完了の定義）の一項目に加えておくと、個人の注意力に依存しない仕組みになります。
まとめ
RC版のタグが本番運用に紛れ込む事故は、技術的な見落としというよりも、バージョニングの意味共有と見積もりプロセスの不備から生まれます。
今回のケースでは「1.108.0が安定版なのに1.107系のRCパッチが後から出る」という一見逆行したリリース順が起きており、これは機械的な最新追従では判断できません。
まずは手元でpip show litellmを実行してバージョン文字列を確認し、「rc」が含まれていないかをチェックするところから始めてみてください。
あわせて、依存関係更新タスクの見積もりテンプレートに「バージョン種別確認」の項目を追加し、チームの振り返り（レトロスペクティブ）で一度議題に挙げてみることをおすすめします。