LiteLLM v1.106.0：stdio MCPサーバーをデフォルトで無効化、Dockerを1コマンドで起動

1. 登録は残し、実行を止める

2026年10月18日に公開された今回のバージョンの主な変更は、stdio方式のデフォルト無効化だ。MCPサーバーはモデルが使う外部ツールを提供し、今回変更された方式はプロキシのあるコンピューターでコマンドを実行して接続するものだ。リモートサーバーに接続する方式とは異なる。

変更提案書は、大半のデプロイではリモートサーバーだけが必要だが、従来はローカル実行方式を無効にできなかったと説明する。今後はサーバーの登録情報が残っていても、プロセスは起動しない。リモートのHTTP・SSEサーバーはこの遮断の対象ではない。

2. 遮断の通知はリクエストによって異なる

無効なサーバーのツール一覧をREST APIで取得すると空の一覧が返り、ツールを直接呼び出すとアクセスを拒否するステータスコード403と案内メッセージが返る。同じ方式のサーバーの作成・変更は、リクエスト検証エラーの422で拒否される。ただし、既存サーバーをリモート接続方式に変更する場合は例外だ。

管理画面はサーバーカードに無効化バッジを付け、作成・変更画面では該当の転送方式をグレーアウトする。既存サーバーの詳細画面などには、再び有効にする方法を案内するバナーを表示する。

モデルのリクエストが遮断されたサーバーを指す場合、エラーではなくツールなしで成功することがある。そのため、リクエストの成否だけで接続を判断せず、ツールが提供されるかも確認する必要がある。この制限はプロキシに適用され、開発ツール群であるSDKのMCPクライアントには適用されない。

3. 再び有効にするにはプロセス環境を変える

引き続き使用するには、プロキシのプロセス環境にLITELLM_ENABLE_MCP_STDIO=trueを設定し、プロキシを再起動する。有効化の値はtrueのみで、大文字と小文字や前後の空白は区別しない。

プロキシの隣にある.envファイルもプロセス環境として認められる。一方、設定ファイルやデータベースに保存した値は無視され、警告が記録される。管理画面や設定更新APIで保存する方法も有効化の手段にはならない。ツール接続を再び許可する判断は、プロキシの実行環境を管理する側が下すべきだということだ。

4. デフォルト遮断の利点と運用コスト

この変更には、プロキシのコンピューターでローカルコマンドを実行する経路をデフォルトで閉じる利点がある。代償となるのは既存接続の継続性だ。従来の方式に依存するデプロイは管理者が対応するまでツールを失うため、更新作業に接続方式の点検と環境設定の変更を含める必要がある。

変更提案書には、無効化状態でワーカープロセス4個を使って実行した検証も掲載された。この条件で、画面設定の取得40回はすべて無効化を報告し、ツール呼び出し60回はすべて403となり、該当のツールサーバープロセスは起動しなかった。これはその検証条件での動作確認であり、処理速度の改善を示す数値ではない。

5. Dockerの起動手順とイメージの検証

リリースノートは、Dockerの1コマンド起動手順がゲートウェイ、Postgresデータベース、管理画面をまとめて立ち上げると説明する。Windows向けのPowerShell起動手順も追加された。ただし、提供された原文には実際の起動コマンドとデプロイ用ファイルの内容は示されていない。

ノートに掲載された次のコードは、起動コマンドではなくイメージ署名の確認例だ。LiteLLMはイメージにcosignで署名しており、変わらないコミットハッシュで公開鍵の場所を固定する検証方式を推奨する。

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
  ghcr.io/berriai/litellm:v1.106.0

今回のバージョンは、インストールを始める手順を減らしつつ、ローカルツールの実行許可は管理者が明示的に決定するように変更したリリースだ。