--- title: "LiteLLMとは？複数LLMを1つのAPIで呼ぶProxyの構築手順とフォールバック・予算設定【2026年10月】" url: "https://www.issoh.co.jp/tech/details/18663/" published: 2026-10-21 updated: 2026-10-21 categories: ["AI"] publisher: "株式会社一創" --- # LiteLLMとは？複数LLMを1つのAPIで呼ぶProxyの構築手順とフォールバック・予算設定【2026年10月】 LiteLLMは、OpenAI・Anthropic・Amazon Bedrockなど各社のLLMを、OpenAI互換の1つの呼び出し形式にそろえるオープンソースのPythonライブラリ兼プロキシサーバーです。この記事では2026年10月時点の1.106系を前提に、Python SDKでモデルを切り替える最小コード、DockerでLiteLLM Proxyを立ててconfig.yamlにモデルを登録する手順、障害時のフォールバック、仮想キーによる部署別の予算とレート制限までを、コピーして動かせる形で示します。後半では2026年3月のPyPI侵害を踏まえた版の固定と、採用・見送りの条件も示します。 ## まとめ：LiteLLMはOpenAI互換の窓口で複数LLMの切替と費用管理を担うOSS LiteLLMの使い方は2つあります。アプリのコードに直接組み込むPython SDKと、社内の共通窓口として動かすProxy Server（AIゲートウェイ）です。1つのアプリから2社程度のモデルを呼ぶだけならSDKで足ります。複数のチームや複数のアプリがLLMを使い、APIキーの配布と費用の上限を一か所で握りたいならProxyを選びます。 Proxyで最初に設定する項目は4つです。model\_listへのモデル登録、障害時のfallbacks、PostgreSQLを前提にした仮想キー、キーごとのmax\_budgetとrpm\_limitです。2026年3月にPyPI上の2つの版へ認証情報を盗むコードが混入した前例があるため、版を固定して公式Dockerイメージを使います。SSOを6人以上で使う、監査ログが要る、という段階でEnterpriseかマネージド製品を検討します。 ## LiteLLMの定義とPython SDK・Proxy Serverの2つの使い方の違い ### OpenAI互換の形式で各社LLMを呼び分けるLiteLLMの基本構造と提供元 LiteLLMはBerriAI社が開発し、[GitHubのBerriAI/litellmリポジトリ](https://github.com/BerriAI/litellm)で公開されています。[PyPIの登録情報](https://pypi.org/project/litellm/)では、2026年10月21日時点の最新版は2026年10月20日公開の1.106.1、対応はPython 3.10以上3.15未満、ライセンス表記はMITです。 中心にある考え方は「呼び出し側は1つの形式で書き、違いはモデル文字列で吸収する」です。`openai/`や`anthropic/`のようなプロバイダ接頭辞をモデル名に付けると、LiteLLMが各社APIのリクエスト形式・認証・応答の違いを変換し、OpenAIのChat Completions形式で応答を返します。アプリ側のコードは、モデル文字列を差し替えるだけで別の会社のモデルへ移れます。 ### アプリに組み込むSDKと社内共通の窓口にするProxyを選ぶ判断基準 同じLiteLLMでも、SDKとProxyでは管理できる範囲が違います。判断の軸は「APIキーと費用を誰が握るか」です。 | 比較項目 | Python SDK | Proxy Server | | ---------- | ----------------- | -------------------- | | 動かし方 | アプリにimportして関数を呼ぶ | 独立したHTTPサーバーとして常駐 | | 呼び出せる言語 | Pythonのみ | OpenAI互換APIを呼べる全言語 | | APIキーの置き場所 | 各アプリの環境変数 | Proxyだけが保持し利用者には仮想キー | | 予算・レート制限 | アプリ側で自作 | キー・ユーザー・チーム単位で設定 | | 必要な基盤 | なし | コンテナ実行環境とPostgreSQL | PoCをSDKで始め、2つ目のチームが使い始めた段階でProxyへ移す流れが典型です。AIゲートウェイの考え方や、SaaS型・クラウド標準機能との比較は[AIゲートウェイとは？役割・LLMゲートウェイとの関係と導入判断](https://www.issoh.co.jp/column/details/13818/)で整理しています。本記事はその中のOSS型、LiteLLMを実際に動かす手順に絞ります。 ## Python SDKでcompletionを呼び出してプロバイダを切り替える最小コード ### uv add litellmで導入しOpenAIとClaudeを同じ関数で呼ぶコード例 [公式のSDK Quickstart](https://docs.litellm.ai/docs/learn/sdk%5Fquickstart)は、`uv add litellm`で導入し、`completion()`にモデル文字列とメッセージを渡す形を示しています。APIキーの読み取り元は、各社の既定の環境変数名（`OPENAI_API_KEY`、`ANTHROPIC_API_KEY`）です。次のコードは、同じメッセージを2社のモデルへ順に投げ、応答と1回あたりの料金を表示します。 ``` # 事前に: uv add litellm # 環境変数 OPENAI_API_KEY と ANTHROPIC_API_KEY を設定しておく from litellm import completion, completion_cost messages = [{"role": "user", "content": "LiteLLMを一文で説明してください。"}] # モデル名は2026年10月時点の公式docsの記載例。利用時はプロバイダのページで現行IDを確かめる for model in ["openai/gpt-6.1-sol", "anthropic/claude-sonnet-5"]: resp = completion(model=model, messages=messages, timeout=30) print(model, resp.choices[0].message.content) # 応答のトークン数と価格表からUSD換算した料金 print(f"cost: ${completion_cost(completion_response=resp):.6f}") ``` 応答はどちらもOpenAI形式の`choices[0].message.content`で取り出せます。Anthropicのモデル文字列の書き方は[LiteLLMのAnthropicプロバイダのページ](https://docs.litellm.ai/docs/providers/anthropic)に載っており、記載例は`anthropic/claude-sonnet-5`です。Claude側の単価やAPIキーの発行手順は[Anthropic API（Claude API）の料金とAPIキー取得方法](https://www.issoh.co.jp/tech/details/5893/)を参照してください。 ### completion\_costで1リクエストごとの料金をドル単位で取得する方法 料金計算の仕組みは[Token Usage and Costのページ](https://docs.litellm.ai/docs/completion/token%5Fusage)に書かれています。`completion_cost()`は応答のトークン数に、コミュニティで管理されている価格表`model_prices_and_context_window.json`の単価を掛けて返す仕組みで、金額の単位はUSDです。同じ値は`resp._hidden_params["response_cost"]`にも入ります。 この仕組みには注意点が2つあります。1つは、価格表に無いモデルや契約で単価が違うモデルは、`litellm.register_model()`で`input_cost_per_token`と`output_cost_per_token`を自分で登録しないと金額がずれることです。もう1つは、閉じたネットワークで`LITELLM_LOCAL_MODEL_COST_MAP="True"`を設定すると同梱の価格表を使うため、価格改定を反映するにはLiteLLM本体の更新が必要になることです。 ## DockerでLiteLLM Proxyを起動しconfig.yamlへモデル登録する手順 ### model\_listとos.environ記法でAPIキーを設定ファイルから分離する方法 Proxyの設定は1つのYAMLファイルにまとめます。[公式のConfig.yamlのページ](https://docs.litellm.ai/docs/proxy/configs)によると、主なセクションは`model_list`・`router_settings`・`litellm_settings`・`general_settings`の4つです。値に`os.environ/変数名`と書くと環境変数から読み込まれるため、APIキーをファイルに直書きせずに済みます。 ``` # config.yaml model_list: # 利用者が指定する名前（model_name）と、実際に呼ぶモデル（litellm_params.model）を分ける - model_name: chat-main litellm_params: model: openai/gpt-6.1-sol api_key: os.environ/OPENAI_API_KEY rpm: 300 # このデプロイへの1分あたりの上限リクエスト数 - model_name: chat-backup litellm_params: model: anthropic/claude-sonnet-5 api_key: os.environ/ANTHROPIC_API_KEY router_settings: routing_strategy: simple-shuffle fallbacks: [{"chat-main": ["chat-backup"]}] # chat-mainが失敗したらchat-backupへ litellm_settings: num_retries: 2 request_timeout: 30 allowed_fails: 3 cooldown_time: 30 general_settings: master_key: os.environ/LITELLM_MASTER_KEY # sk-で始まる値にする database_url: os.environ/DATABASE_URL # 仮想キーと支出記録の保存先（PostgreSQL） ``` ここで効くのは`model_name`の付け方です。利用者には`chat-main`のような用途名だけを見せ、裏のモデルを差し替えてもアプリ側の改修が要らない状態にします。同じ`model_name`で複数のデプロイを並べると負荷分散の対象になり、振り分け方は`routing_strategy`で`simple-shuffle`・`least-busy`・`usage-based-routing`・`latency-based-routing`から選択できる仕組みです。vLLMで自前ホストしたモデルも、`openai/`接頭辞と`api_base`を指定すれば同じ一覧に並べられます。vLLM側の構築は[vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違い](https://www.issoh.co.jp/tech/details/15786/)で扱っています。 ### docker runでポート4000に立ち上げcurlで疎通を確かめるまでの手順 [公式のProxy Quickstart](https://docs.litellm.ai/docs/proxy/docker%5Fquick%5Fstart)は、公式イメージに設定ファイルをマウントしてポート4000で起動する手順を示しています。次の例では本番を想定して`latest`ではなく版を明示したタグにしています。タグ名はGitHubのリリース一覧で実在を確かめてから指定してください。 ``` # 1. Proxyを起動する（タグは検証済みの版に固定する） docker run -d --name litellm \ -v "$(pwd)/config.yaml:/app/config.yaml" \ -e OPENAI_API_KEY="$OPENAI_API_KEY" \ -e ANTHROPIC_API_KEY="$ANTHROPIC_API_KEY" \ -e LITELLM_MASTER_KEY="sk-長いランダム文字列" \ -e DATABASE_URL="$DATABASE_URL" \ -p 4000:4000 \ docker.litellm.ai/berriai/litellm:<検証済みの版> \ --config /app/config.yaml # 2. OpenAI互換のエンドポイントへ用途名でリクエストする curl http://localhost:4000/v1/chat/completions \ -H "Authorization: Bearer $LITELLM_MASTER_KEY" \ -H "Content-Type: application/json" \ -d '{"model": "chat-main", "messages": [{"role": "user", "content": "疎通確認です"}]}' ``` 応答が返れば、既存のOpenAI SDKも`base_url`を`http://localhost:4000`に変えるだけで同じProxyを呼べます。管理画面は`/ui`です。 ## フォールバックとリトライ・クールダウンで障害時の切替先を設定する方法 ### context\_window\_fallbacksなど3種類で失敗別に切替先を指定 [公式のFallbacksのページ](https://docs.litellm.ai/docs/proxy/reliability)は、切替先を失敗の種類ごとに3つの設定で分けています。 - `fallbacks`：エラーやタイムアウトでリトライを使い切ったときの切替先 - `context_window_fallbacks`：入力がモデルのコンテキスト長を超えたときの切替先 - `content_policy_fallbacks`：プロバイダのコンテンツポリシーで拒否されたときの切替先 実務でまず入れるのは`fallbacks`だけで十分です。別の会社のモデルを切替先にしておくと、1社の障害やレート制限でサービス全体が止まる事態を避けられます。`context_window_fallbacks`を確実に効かせるには、`router_settings`で`enable_pre_call_checks: true`を指定し、送信前に長さを判定させる設定が必要です。なお、公式ページの例ではこれらのキーが`router_settings`と`litellm_settings`の両方に登場します。導入する版のページで置き場所を確かめてから書いてください。 ### num\_retriesとcooldown\_timeの決め方と本番前に切替を試す方法 切替の手前で効くのがリトライとクールダウンです。`num_retries`は同じ`model_name`内での再試行回数、`request_timeout`は1回の呼び出しの待ち時間（秒）です。`allowed_fails`を超えて失敗したデプロイは、`cooldown_time`秒のあいだ振り分け対象から外れます。公式例の値は`num_retries: 3`・`request_timeout: 10`・`allowed_fails: 3`・`cooldown_time: 30`です。 値は利用者の待ち時間から逆算します。`request_timeout: 30`で`num_retries: 2`なら、切替先に移るまでの待ち時間は、最悪で約90秒です。チャット画面のように利用者が待っている用途では、タイムアウトを短くしてリトライを減らすほうが体感はよくなります。 検証方法には落とし穴があります。`mock_testing_fallbacks`はSDKの`Router`を直接呼ぶ場合だけの機能で、Proxy v1.85.0以降はProxyへのリクエストから取り除かれて効きません。Proxyでは、検証環境で切替元のAPIキーをわざと無効な値にするなどして実際のエラーを起こし、通常のリクエストで切替を確かめます。 ## 仮想キーとPostgreSQLで部署別の予算上限とレート制限を設定する手順 ### master\_keyとDATABASE\_URLを揃えて仮想キーを発行するまでの手順 Proxyを共通窓口にする最大の理由が仮想キーです。各社の本物のAPIキーはProxyだけが持ち、利用者には`sk-`で始まる仮想キーを配ります。[公式のVirtual Keysのページ](https://docs.litellm.ai/docs/proxy/virtual%5Fkeys)によると、前提は2つです。`DATABASE_URL`でPostgreSQLを指定することと、`sk-`で始まる`master_key`を`general_settings`または環境変数`LITELLM_MASTER_KEY`で設定することです。 ``` # 部署用の仮想キーを発行する（予算は30日ごとに10米ドル、毎分100リクエスト・1万トークンまで） curl -X POST http://localhost:4000/key/generate \ -H "Authorization: Bearer $LITELLM_MASTER_KEY" \ -H "Content-Type: application/json" \ -d '{ "models": ["chat-main", "chat-backup"], "max_budget": 10, "budget_duration": "30d", "rpm_limit": 100, "tpm_limit": 10000, "metadata": {"department": "sales"} }' # 発行したキーの支出（USD）を確認する curl "http://localhost:4000/key/info?key=発行されたsk-キー" \ -H "Authorization: Bearer $LITELLM_MASTER_KEY" ``` `models`で呼べる用途名を絞れるので、高額なモデルを一部の部署だけに開放することもできます。支出は呼び出しのたびに`completion_cost()`でUSD換算されて加算され、キー単位は`/key/info`、ユーザー単位は`/user/info`、チーム単位は`/team/info`で確認できます。 ### max\_budgetとrpm\_limitで部署別の使い過ぎを止める設定値と注意点 [公式のBudgets, Rate Limitsのページ](https://docs.litellm.ai/docs/proxy/users)が定める挙動は次のとおりです。`max_budget`はUSDの上限で、超えたキーのリクエストは失敗します。`budget_duration`は`30s`・`30m`・`30h`・`30d`の形式でリセット周期を決め、指定しなければ予算はリセットされません。キーに`team_id`があるときは、キー所有者の個人予算ではなくチームの予算が適用されます。 レート制限は`rpm_limit`（毎分のリクエスト数）、`tpm_limit`（毎分のトークン数）、`max_parallel_requests`（同時実行数）の3種類です。`tpm_limit`が数える対象は`token_rate_limit_type`で入力・出力・合計から選べ、既定は合計です。 見落としやすいのは、予算の判定がPostgreSQLの支出記録に基づく点です。データベースを用意しない構成では`max_budget`を書いても上限として働きません。 ## 2026年3月のPyPI侵害事案から学ぶLiteLLM導入時の版の固定と確認項目 ### 1.82.7と1.82.8に混入した認証情報窃取コードの影響範囲と対処 [LiteLLM公式のセキュリティ告知](https://docs.litellm.ai/blog/security-update-march-2026)によると、PyPIで配布された`litellm==1.82.7`と`1.82.8`に不正なコードが混入しました。2026年3月24日10時39分（UTC）から、PyPIに隔離されるまで約40分間公開されていた版です。混入したコードは環境変数・SSH鍵・AWSやGoogle Cloud・Azureの認証情報・Kubernetesのトークン・データベースのパスワードを集め、公式ではないドメイン（models.litellm\[.\]cloud）へ送信するものでした。1.82.8は`litellm_init.pth`を追加しており、LiteLLMをimportしなくてもPythonの起動時に実行される作りでした。 公式Dockerイメージは依存関係を固定していたため影響を受けていません。修正版として新しいCI/CDで作られた1.83.0が公開されています。手元の環境は次のコマンドで確かめられます。 ``` # 導入済みの版を確認する（1.82.7・1.82.8なら認証情報をすべて入れ替える） pip show litellm | grep -i "^version" # site-packages に litellm_init.pth が残っていないか探す python -c "import site; print('\n'.join(site.getsitepackages()))" \ | xargs -I{} find {} -maxdepth 1 -name "litellm_init.pth" ``` 該当した場合はホスト上の認証情報をすべて入れ替え、CIやDockerビルドのログにも該当版の記録がないかを確かめます。 ### Dockerイメージの署名検証と版の固定で更新の速さに備える運用 LiteLLMは更新が速いOSSです。[GitHubのリリース一覧](https://github.com/BerriAI/litellm/releases)では、2026年10月20日の1日だけで1.106.1・1.105.2・1.104.4・1.103.6の4つが公開されており、複数の系列へ修正を戻す運用になっています。最新版へ自動で追従すると、毎週のように挙動が変わる前提で動くことになります。 本番では次の3点を運用ルールにします。 1. Dockerイメージのタグを版で固定し、`latest`を使わない 2. リリース一覧が案内するcosignの公開鍵でイメージの署名を確かめる（告知によれば対象はv1.83.0-nightly以降のイメージ） 3. 検証環境でフォールバックと予算の挙動を確認してから本番の版を上げる SDKとして入れる場合も`uv.lock`などで版とハッシュを固定します。各社のAPIキーを一手に握る部品なので、更新は人の確認つきの作業として扱います。 ## LiteLLMを採用する条件と見送る場面、Enterpriseとマネージドとの選び分け ### OSS版で足りる構成とEnterpriseライセンスが必要になる機能の境目 OSS版のProxyで、モデル登録・フォールバック・仮想キー・キー単位の予算とレート制限まではそろいます。ログの可視化も、[公式のLoggingのページ](https://docs.litellm.ai/docs/proxy/logging)にあるとおり`litellm_settings`の`success_callback`に`langfuse`を指定し、`LANGFUSE_PUBLIC_KEY`と`LANGFUSE_SECRET_KEY`を設定すればログを送信できる仕組みです。Langfuse側の画面や評価機能は[Langfuseとは？読み方・機能・使い方とLangSmithとの違い](https://www.issoh.co.jp/tech/details/6031/)で解説しています。 境目は統制の機能です。[公式のEnterpriseのページ](https://docs.litellm.ai/docs/enterprise)では、Admin UIのSSOは5ユーザーまで無料で、それを超えるとライセンスが必要です。監査ログ、ロールベースのアクセス制御、IPアドレスによる制限、キーのローテーション、シークレットマネージャー連携、タグ別やモデル別の予算もライセンスキーで有効になる機能として並んでいます。同ページは対象を「100ユーザー超、または本番のAIユースケースが10件超」のチームとしています。 利用者が数十人までで監査ログを求められていないなら、OSS版で始めてかまいません。全社の窓口として運用し、誰がいつキーを変えたかの記録が要るなら、OSS版のまま監査機能を自作するのは割に合いません。 ### LiteLLMを見送るべき4つの場面と代わりに選ぶ構成の判断基準 LiteLLMを入れないほうがよい場面もはっきりしています。 - 使うモデルが1社だけで、切替の予定もない：プロバイダ公式SDKを直接使うほうが新機能への追従が早い - AWSの中で完結し、Bedrockのモデルだけで足りる：[Amazon Bedrock Converse API](https://www.issoh.co.jp/tech/details/2391/)がモデル間の形式差を吸収し、IAMで権限を管理できる - コンテナとPostgreSQLを24時間運用する担当者がいない：Proxyが止まると全アプリのLLM呼び出しが止まるため、マネージド型のAIゲートウェイを選ぶ - 各社固有の機能（独自のツール形式や最新のベータ機能）を初日から使いたい：互換層を通すと対応が遅れる、または変換で情報が落ちる場合がある 反対に、2社以上のモデルを併用し、部署ごとの費用上限とAPIキーの一元管理が必要で、コンテナ基盤を自社で持てるなら、LiteLLMのProxyは有力な選択肢です。社内のLLM基盤をどこまで自前で持つか、既存の業務システムとどうつなぐかを含めて検討する場合は、[生成AI開発・AI受託開発](https://www.issoh.co.jp/service/ai/development/)で構成の設計から相談を受け付けています。 ## よくある質問 LiteLLMの導入を検討する段階でよく出る質問に答えます。 ### LiteLLMは無料で使えますか？ 本体はライセンス表記がMITのOSSで、SDKもProxyも費用なしで使えます。モデルの利用料は各プロバイダへ支払い、ProxyのサーバーとPostgreSQLの費用も別にかかります。有料になるのは、6人目以降のSSOや監査ログなど、ライセンスキーで有効になる機能を使う場合です。 ### LiteLLMとLangChainは何が違いますか？ 役割の層が違います。LiteLLMはモデル呼び出しの窓口をそろえ、切替・費用・レート制限を受け持ちます。LangChainはプロンプトの組み立て、RAG、エージェントの処理の流れを組むフレームワークです。両者は併用でき、LangChainからLiteLLM Proxyを呼ぶ構成も取れます。LangChainの全体像は[LangChainとは？LLMアプリ開発フレームワークの仕組み](https://www.issoh.co.jp/column/details/12967/)で解説しています。 ### Ollamaなどのローカルモデルもつなげますか？ つなげます。OpenAI互換のAPIを持つ推論サーバーであれば、config.yamlの`litellm_params`で`openai/`接頭辞と`api_base`を指定することで登録が可能です。クラウドのモデルとローカルモデルを同じ`model_name`の一覧に並べ、機密データはローカル、それ以外はクラウドと使い分ける構成も組めます。ローカル側の準備は[ローカルLLMとは？必要スペック・Ollamaでの構築手順](https://www.issoh.co.jp/column/details/12964/)が参考になります。 ### 予算を日本円で管理できますか？ LiteLLMの`max_budget`と支出記録はUSD建てです。円で管理したい場合は、社内レートで換算したUSD額を上限に設定し、`/key/info`などで取得したUSDの支出に同じレートを掛けて報告します。価格表に無いモデルや契約単価が違うモデルは`register_model()`で単価を登録しないと金額がずれるため、月に1度はプロバイダの請求額と照合してください。 ### LiteLLMの更新はどのくらいの頻度で追うべきですか？ 最新版を即日取り込む必要はありません。1日に複数の系列が公開されることもあるため、月に1度程度リリースノートでセキュリティ修正と使う機能の変更を確かめ、検証環境で挙動を見てから版を上げます。2026年3月のような緊急の告知が出たときだけは即日対応します。 ## 関連記事 - [AIゲートウェイとは？役割・LLMゲートウェイとの関係と導入判断を解説](https://www.issoh.co.jp/column/details/13818/)：LiteLLMを含むAIゲートウェイ全体の選び方。 - [Langfuseとは？読み方・機能・使い方とLangSmithとの違い](https://www.issoh.co.jp/tech/details/6031/)：Proxyから送ったログを可視化する先。 - [vLLMとは？PagedAttentionの仕組み・使い方](https://www.issoh.co.jp/tech/details/15786/)：自前ホストのモデルをLiteLLMの後ろに置く場合。 - [Vercel AI SDKの使い方｜Next.js実装とLangChain連携](https://www.issoh.co.jp/tech/details/9551/)：TypeScript側からLLMを呼ぶ場合の選択肢。 - [Anthropic API（Claude API）の料金とAPIキー取得方法](https://www.issoh.co.jp/tech/details/5893/)：切替先にClaudeを置くときの単価。 --- 出典: [LiteLLMとは？複数LLMを1つのAPIで呼ぶProxyの構築手順とフォールバック・予算設定【2026年10月】]()（株式会社一創）