LiteLLM Proxy: 1つのAPIで100以上のLLMを利用（Dockerで15分セットアップ）

LiteLLM Proxy: 1つのAPIで100以上のLLMを利用（Dockerで15分セットアップ）

あなたのチームはSlackのDMでOpenAIのAPIキーを共有していませんか？先週火曜日に誰が400ドル使ったのか、誰も把握できていません。レート制限もなく、プロバイダーがダウンした際のフォールバックもなく、GPT-4oからClaudeへ切り替えるには12箇所のコードを変更する必要があります。見覚えがありますか？セルフホスト型のLLMゲートウェイを使えば、これらすべてを解決できます。そして、LiteLLMプロキシはその中で最も人気のあるオープンソースオプションであり、100以上のLLMプロバイダーへリクエストをルーティングする単一のOpenAI互換エンドポイントを提供します。

このガイドでは、完全なlitellmプロキシのセットアップを解説します。PostgreSQLを使用したDocker Compose、予算付きの仮想チームキー、コスト追跡、レート制限、そしてClaude CodeやCursorのようなAI IDEとの接続が含まれます。LLMゲートウェイツールを検討している場合、これはゼロから本番環境まで導く実践的なチュートリアルです。

始める前に重要な注意点：LiteLLMのSDK（Pythonライブラリ）とプロキシサーバーは別物です。SDKは、Pythonから複数のLLM APIを呼び出す個々の開発者向けです。一方、プロキシはチーム向けであり、アプリとLLMプロバイダーの間にサーバーとして配置されます。スクリプトを書くソロ開発者ならSDKで十分ですが、チームのキー、予算、アクセスを管理するならプロキシが必要です。ここでセットアップするのは、まさにそのプロキシです。

LiteLLM Proxyの概要

デプロイ方法の比較は以下の通りです：

ほとんどのチームにとって、PostgreSQLを使用したDocker Composeが最適な選択肢です。これからそれを構築していきますが、まずは60秒でプロキシを動かしてみましょう。

前提条件と環境セットアップ

開始前に、以下を用意してください：

• Docker および Docker Compose がインストールされていること（Docker Desktopには両方含まれています）
• 少なくとも1つのLLM APIキー（OpenAI、Anthropic、またはローカルのOllamaインスタンス）
• 基本的なターミナル/CLIの知識

Dockerが準備できていることを確認し、APIキーをエクスポートします：

# Check Docker is installed
docker --version
docker compose version

# Export your LLM API keys (add to your shell profile for persistence)
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."

# Optional: set a master key for your proxy (you'll need this later)
export LITELLM_MASTER_KEY="sk-master-your-secret-key"

これで完了です。特別なPythonバージョンやOS固有のツールは不要です。マシンでDockerが動けば、準備は整っています。

クイックスタート：60秒で最初のLiteLLMプロキシを起動

GPT-4oを使用したプロキシを起動するコマンドは1つだけです：

docker run -d \
  --name litellm-proxy \
  -p 4000:4000 \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  -e LITELLM_MASTER_KEY=$LITELLM_MASTER_KEY \
  ghcr.io/berriai/litellm:main-stable \
  --model openai/gpt-4o

curlでテストします：

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o",
    "messages": [{"role": "user", "content": "Say hello from LiteLLM"}]
  }'

またはPythonからテストします：

from openai import OpenAI

# Point the standard OpenAI SDK at your proxy
client = OpenAI(
    api_key="sk-master-your-secret-key",
    base_url="http://localhost:4000/v1"
)

response = client.chat.completions.create(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Say hello from LiteLLM"}]
)
print(response.choices[0].message.content)

何が起こったのでしょうか？あなたのコードは標準的なOpenAI SDK形式を使用してlocalhost:4000と通信しています。プロキシはリクエストを受け取り、実際のキーを使ってOpenAIのAPIに転送し、レスポンスを返します。アプリケーションコードが実際のAPIキーに触れることはありません。

これが核心概念です。 次に、本番環境用のセットアップを構築しましょう。

PostgreSQLを使用した本番環境向けDocker Composeセットアップ

単一のdocker runコマンドはテストには有効ですが、本番環境のチームには永続的なコスト追跡、仮想キー、適切なデータベースストレージが必要です。つまり、PostgreSQLを使用したDocker Composeが求められます。

Docker Composeファイル

# docker-compose.yml
version: "3.9"

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-stable
    container_name: litellm-proxy
    ports:
      - "4000:4000"         # Proxy API port
    volumes:
      - ./config.yaml:/app/config.yaml   # Mount your config file
    environment:
      - LITELLM_MASTER_KEY=${LITELLM_MASTER_KEY}
      - OPENAI_API_KEY=${OPENAI_API_KEY}
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      - DATABASE_URL=postgresql://litellm:litellm_password@postgres:5432/litellm
      - LITELLM_SALT_KEY=${LITELLM_SALT_KEY:-sk-salt-random-string}
    command: --config /app/config.yaml --detailed_debug
    depends_on:
      postgres:
        condition: service_healthy
    restart: unless-stopped

  postgres:
    image: postgres:16-alpine
    container_name: litellm-db
    environment:
      POSTGRES_DB: litellm
      POSTGRES_USER: litellm
      POSTGRES_PASSWORD: litellm_password
    volumes:
      - litellm_pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U litellm"]
      interval: 5s
      timeout: 5s
      retries: 5
    restart: unless-stopped

volumes:
  litellm_pgdata:

LITELLM_SALT_KEYはデータベース内の仮想キーデータを暗号化します。LiteLLM本番環境ベストプラクティスのドキュメントでは、チームでのデプロイ時にこれを設定することを推奨しています。

スタックの起動

# Create a .env file with your keys (don't commit this to git)
echo "LITELLM_MASTER_KEY=sk-master-your-secret" > .env
echo "OPENAI_API_KEY=sk-..." >> .env
echo "ANTHROPIC_API_KEY=sk-ant-..." >> .env
echo "LITELLM_SALT_KEY=sk-salt-$(openssl rand -hex 16)" >> .env

# Start everything
docker compose up -d

# Check logs
docker compose logs -f litellm

動作確認

# Health check
curl http://localhost:4000/health

# Test a request
curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "ping"}]}'

成功レスポンスが表示されれば、本番環境スタックは稼働しています。PostgreSQLは、コンテナの再起動をまたいで、すべてのコストデータ、仮想キー、使用量メトリクスを永続的に保存します。

結論：Docker Compose + PostgreSQLが推奨される本番環境セットアップです。 約10分の作業で、永続ストレージ、コスト追跡、仮想キーを実現できます。後で自動スケーリングが必要になった場合は、DockerデプロイドキュメントでKubernetesやHelmについて確認できます。

config.yaml walkthrough：実際のマルチプロバイダー設定

多くのチュートリアルでは1つのモデルのみを含むconfig.yamlを示していますが、ここでは3つのプロバイダー、フォールバック、ロードバランシングを備えた実際のチーム設定を紹介します。

設定ファイル

# config.yaml -- Real multi-provider setup
model_list:
  # Primary: OpenAI GPT-4o
  - model_name: gpt-4o          # The name YOUR code uses
    litellm_params:
      model: openai/gpt-4o      # The actual provider/model
      api_key: os.environ/OPENAI_API_KEY

  # Secondary: Anthropic Claude
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: os.environ/ANTHROPIC_API_KEY

  # Local: Ollama for development / cost-free testing
  - model_name: local-llama
    litellm_params:
      model: ollama/llama3.1
      api_base: http://host.docker.internal:11434

  # Fallback: route "gpt-4o" to Claude if OpenAI is down
  - model_name: gpt-4o
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  routing_strategy: least-busy    # Load balance across same-name models
  num_retries: 3
  retry_after: 5                  # Seconds between retries
  fallbacks: [{"gpt-4o": ["claude-sonnet"]}]

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

モデルエイリアスとルーティング

設定内でgpt-4oが2回登場していることに注目してください。1回はOpenAIを指し、もう1回はAnthropicを指しています。コードがgpt-4oをリクエストすると、LiteLLMはまずOpenAIを試みます。失敗した場合、fallbacks設定により自動的にClaudeへルーティングされます。アプリケーションコードは一切変更する必要がありません。

vLLMやSGLangなどの本番推論バックエンドを使用している場合は、同じように追加でき、api_baseを推論サーバーに設定するだけです。

プロバイダー簡易リファレンス

routing_strategy: least-busy設定は、同じmodel_nameを持つモデル間でリクエストを分散します。もし2つのOpenAIキー（異なる組織で異なるレート制限がある場合など）を持っているなら、それらを両方gpt-4oの下にリストすれば、LiteLLMが負荷を分散します。

仮想キー：予算とレート制限付きのチーム別APIキー

ここからLiteLLMは「単なるプロキシ」からチーム管理ツールへと進化します。仮想キーを使用すると、チームメンバーやサービスごとに、支出制限とレートキャップを備えた独自のAPIキーを発行でき、それらはすべて単一のプロバイダーAPIキーセットを通じてルーティングされます。

予算付きチームキーの作成

# Create a virtual key with a $50/month budget
curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "frontend-team",
    "max_budget": 50.0,
    "budget_duration": "1mo",
    "models": ["gpt-4o", "claude-sonnet"],
    "metadata": {"purpose": "frontend AI features"}
  }'

レスポンスにはsk-team-abc123...のような新しいキーが含まれます。これをフロントエンドチームに渡してください。彼らはこれをOpenAIキーと全く同じように使用できますが、月間50ドルまでに制限され、指定したモデルへのみアクセス可能です。

レート制限の設定

# Create a key with rate limits: 100 requests/minute, 50K tokens/minute
curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "backend-team",
    "max_budget": 200.0,
    "budget_duration": "1mo",
    "rpm_limit": 100,
    "tpm_limit": 50000,
    "models": ["gpt-4o", "claude-sonnet", "local-llama"]
  }'

仮想キードキュメントにはすべてのパラメータが記載されています。さらにきめ細かい制御のために、ユーザーごとの予算とレート制限を設定することもできます。

キーの使用状況モニタリング

import requests

# Check a key's current spend and limits
response = requests.get(
    "http://localhost:4000/key/info",
    headers={"Authorization": f"Bearer {MASTER_KEY}"},
    params={"key": "sk-team-abc123..."}
)
info = response.json()
print(f"Spent: ${info['spend']:.2f} / ${info['max_budget']:.2f}")
print(f"RPM used: {info['rpm_limit_used']} / {info['rpm_limit']}")

侵害されたキーを取り消す必要がある場合？APIコール1回で済みます：

curl -X POST http://localhost:4000/key/delete \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"keys": ["sk-team-abc123..."]}'

結論：仮想キーこそが、LiteLLMを個人用プロキシではなくチームツールにする要素です。 これらがなければ、コードとLLMの間にホップを1つ追加するだけです。これらがあれば、アクセス制御、予算執行、使用帰属が可能になり、CFOのパニックを防ぐことができます。

コスト追跡とLiteLLMダッシュボード

PostgreSQLが接続されると、LiteLLMはすべてのリクエストのコストを自動的に追跡します。何も設定する必要はありません。サポートされているすべてのモデルのトークン単価を認識しています。

ダッシュボード

http://localhost:4000/uiで組み込みUIにアクセスします（マスターキーでログイン）。表示される内容：

• すべてのチームとキーにわたる総支出
• モデル別内訳。どのモデルが予算を圧迫しているか
• チーム別支出。誰が何を使っているか
• 時間経過に伴うリクエストボリューム

LLM APIコスト削減に真剣に取り組むチームにとって、ダッシュボードだけでプロキシを実行する価値があります。さらに深い分析のために、LiteLLMをLangfuseやHeliconeなどの外部AI観測プラットフォームに接続することもできます。

プロバイダー別コスト比較

主要モデルの100万トークンあたりのコストは以下の通りです（2026年4月現在）：

ダッシュボードでチーム別にこれらの数字を見ると、「このユースケースにはより安価なモデルを使うべきか？」という議論が非常に具体的になります。

結論：コスト追跡だけでも、月間100ドル以上LLM APIに費やすチームにとってプロキシを導入する正当な理由になります。 測定できないものは最適化できません。

AI IDEとの接続：Claude Code、Cursor、Continue

ほとんどのLiteLLMガイドが完全に省略している点：AIコーディングツールもプロキシに向けることができます。1つのプロキシですべてのIDEツールを統一し、請求も一元化します。

Claude Code

# Set Claude Code to use your LiteLLM proxy
export ANTHROPIC_BASE_URL=http://localhost:4000/v1
export ANTHROPIC_API_KEY=sk-team-your-virtual-key

これだけです。Claude Codeはリクエストをプロキシに送信し、プロキシはAnthropic（または設定で指定された場所）にルーティングしながら、仮想キーの下でコストを追跡します。

Cursor

Cursorの設定で、カスタムOpenAI互換エンドポイントを追加します：

{
  "openai.apiBaseUrl": "http://localhost:4000/v1",
  "openai.apiKey": "sk-team-your-virtual-key"
}

Continue (VS Code)

Continueのconfig.jsonで：

{
  "models": [
    {
      "title": "GPT-4o via LiteLLM",
      "provider": "openai",
      "model": "gpt-4o",
      "apiBase": "http://localhost:4000/v1",
      "apiKey": "sk-team-your-virtual-key"
    }
  ]
}

なぜ手間をかけるのか？これで、すべての開発者のIDE使用量がプロキシを経由するからです。AIコーディングアシスタントの個人別コスト追跡、コーディングセッション中に誤って500ドルを使い果たさないためのレート制限、より良いオプションが見つかった場合にモデルを切り替えるための単一の場所が得られます。

よくある問題のトラブルシューティング

「Config file not found」

通常、Dockerのボリュームマウントパスが間違っていることを意味します。config.yamlがマウント元のディレクトリにあることを確認してください：

# Check the file exists where you think it does
ls -la ./config.yaml

# The volume mount in docker-compose.yml should match
# volumes:
#   - ./config.yaml:/app/config.yaml

PostgreSQLへの「Connection refused」

Dockerネットワーキングは誰もが一度は引っかかります。LiteLLMがPostgresに到達できない場合は、以下を確認してください：

• DATABASE_URL内のサービス名がDocker Composeのサービス名（localhostではなくpostgres）と一致している
• condition: service_healthy付きのdepends_onが設定されている（LiteLLMがPostgresの準備ができるのを待つため）
• 両方のサービスが同じDockerネットワーク上にある（Composeではデフォルトでそうなります）

「Invalid API key format」

最も一般的な混乱：LITELLM_MASTER_KEYは管理操作（仮想キーの作成、ダッシュボードへのアクセス）用です。アプリケーションが使用するのは仮想キー（sk-team-...）です。混同しないようにしてください。

「Model not found」

リクエスト内のmodelフィールドは、config.yaml内のmodel_nameと一致する必要があります。設定でgpt-4oを定義しているのに、コードでopenai/gpt-4oをリクエストすると一致しません。正確なスペルを確認してください。

プロキシは起動するがリクエストがハングする

通常、ファイアウォールまたはポートバインディングの問題です。ポート4000が公開されており、ブロックされていないことを確認してください：

# Check if the port is listening
docker port litellm-proxy
# Should show: 4000/tcp -> 0.0.0.0:4000

セキュリティ：バージョン1.82.7および1.82.8を避ける

2026年3月、サプライチェーンインシデントがLiteLLMバージョン1.82.7および1.82.8に影響を与えました。侵害されたバージョンは削除され、クリーンなリリースが1.83.0で出荷されました。Dockerイメージは常に特定のバージョンにピン留めし、アップグレード前に公式セキュリティアップデートを確認してください。1.82.7または1.82.8を使用している場合は、直ちに更新してください。

どのLiteLLMセットアップ方法を選ぶべきか？

初めてこのガイドを読む場合は、Docker Compose + PostgreSQLから始めてください。後でKubernetesに移行することもできますが、config.yamlは同じままです。

FAQ

LiteLLMプロキシとは何か、どのように動作するのか？

LiteLLMプロキシは、アプリケーションとOpenAIやAnthropicなどのLLMプロバイダーの間に配置されるオープンソースのAIゲートウェイサーバーです。単一のOpenAI互換エンドポイントを公開するため、コードは1つのURLと通信するだけで、プロキシが背後でルーティング、キー管理、コスト追跡、フォールバックを処理します。

Docker ComposeでLiteLLMプロキシをセットアップするには？

LiteLLMプロキシイメージとPostgreSQLデータベースを含むdocker-compose.ymlを作成し、config.yamlをマウントし、APIキーを環境変数として設定して、docker compose up -dを実行します。上記の本番環境Docker Composeセクションには、コピー＆ペースト可能な完全なファイルがあります。

LiteLLMでチームAPIキーを管理するには？

仮想キーを使用します。マスターキーを使用して/key/generateエンドポイントにアクセスし、チーム別またはユーザー別のキーを作成します。各仮想キーには、独自の月間予算、レート制限（RPMおよびTPM）、モデルアクセス制限を設定できます。仮想キーセクションで完全なワークフローを説明しています。

LLM APIにコスト追跡とレート制限を追加するには？

PostgreSQLをプロキシに接続し（DATABASE_URL経由）、コスト追跡は自動的に行われます。レート制限については、仮想キーを生成する際にrpm_limitとtpm_limitを設定します。/uiの組み込みダッシュボードには、チーム別およびモデル別の支出が表示されます。

LiteLLMプロキシは本番環境で使用しても安全か？

はい、ただし注意点があります：2026年3月のサプライチェーンインシデントの影響を受けたバージョン1.82.7および1.82.8は避けてください。バージョン1.83.0以降を使用してください。Dockerイメージのバージョンをピン留めし、暗号化のためにLITELLM_SALT_KEYを設定し、公式の本番環境ベストプラクティスに従ってください。

LiteLLM SDKとLiteLLMプロキシの違いは？

SDKは、コードから複数のLLM APIを呼び出すためのPythonライブラリです。プロキシは、チーム全体が接続するスタンドアロンサーバーです。スクリプトを書くソロ開発者ならSDKを使用してください。チーム全体で共有アクセス制御、コスト追跡、レート制限が必要な場合はプロキシを使用してください。

LiteLLMプロキシをOllamaやローカルモデルで使用できるか？

もちろん可能です。config.yamlにmodel: ollama/llama3.1およびapi_base: http://host.docker.internal:11434（またはOllamaホスト）のエントリを追加します。チームは同じプロキシエンドポイントを通じてローカルモデルにアクセスでき、開発やコストのかからないテストに最適です。

LiteLLMプロキシのコストは？

LiteLLMプロキシは無料でオープンソース（MITライセンス）です。独自のインフラストラクチャでセルフホストします。唯一のコストはサーバー（ほとんどのチームには小さなVPSで十分）と、すでに支払っているLLM APIコストです。BerriAIは、セルフホストしたくない場合のために管理クラウドバージョンも提供しています。

LiteLLMはどのプロバイダーをサポートしているか？

100以上を含み、OpenAI、Anthropic、Azure OpenAI、AWS Bedrock、Google Vertex AI、Ollama、Hugging Face、Cohere、Replicateなどが含まれます。完全なリストはLiteLLM GitHubリポジトリにあります。

LiteLLMプロキシを安全に更新するには？

Dockerイメージタグで常に特定のバージョンをピン留めしてください（例：ghcr.io/berriai/litellm:v1.83.2-stable）。アップグレード前に、変更ログで破壊的変更を確認してください。本番環境では決してlatestを使用しないでください。また、新しいバージョンがセキュリティ advisory リストにないことを常に確認してください。2026年3月のインシデントは、信頼されたパッケージでも侵害される可能性があることを証明しました。

最終結論と次のステップ

チームがLLM APIにお金を費やしていて、まだプロキシを持っていないなら、今日からDocker Compose + Postgresを始めましょう。セットアップには15分かかり、終了時にはコストの可視性とアクセス制御が手に入ります。

稼働したら、コンテンツフィルタリングと安全性チェックのためにLLMパイプラインにガードレールを追加することを検討してください。プロキシは基盤であり、その他すべてはその上に構築されます。

ソース

• LiteLLM Proxy クイックスタート, 公式ドキュメント
• LiteLLM Docker デプロイガイド
• LiteLLM 仮想キードキュメント
• LiteLLM 本番環境ベストプラクティス
• LiteLLM セキュリティアップデート, 2026年3月
• BerriAI/litellm, GitHub リポジトリ