【2026年最新】LiteLLM完全ガイド|100以上のLLMを統一APIで呼び出す方法・料金・使い方

「OpenAIもAnthropicもGeminiも使いたいけど、APIの仕様がバラバラで管理しきれない」——複数のLLMを使い分ける開発者なら、一度はぶつかる壁です。LiteLLMはこの問題を根本から解決するオープンソースツールで、100以上のLLMプロバイダーをOpenAI互換の統一APIで呼び出せます。> Key Takeaway: LiteLLMの使い方・料金・設定方法を徹底解説。OpenAI・Anthropic・Gemini・Cohere等100以上のLLMを同一コードで呼び出せるオープンソースライブラリ・プロキシサーバー。

この記事の要点

  • LiteLLMの2つの使い方(Python SDK vs プロキシサーバー)
  • pip installから最初のAPI呼び出しまでの手順
  • OpenAI・Anthropic・Geminiを同じコードで切り替えるPython実装例
  • フォールバック・ロードバランシングの設定方法
  • LiteLLM Proxyサーバーの立て方とYAML設定
  • 料金プランの比較(無料版 vs Enterprise)
  • OpenRouterとの違いと使い分け

30秒で結論

  • LiteLLMはOSS無料。自分でホストすればライセンス費用ゼロ
  • Python SDKなら pip install litellm → モデル名を変えるだけでプロバイダー切り替え
  • チーム運用にはLiteLLM Proxy(AIゲートウェイ)が必須。YAML設定でフォールバック・予算管理・レート制限を一元管理
  • OpenRouterとの最大の違いは「自分でインフラを持つか、SaaSに任せるか」。セキュリティ・カスタマイズ重視ならLiteLLM、手軽さ重視ならOpenRouter
  • 個人開発者はSDK、チーム開発はProxy、エンタープライズはEnterprise版が最適解

LiteLLMとは——2つの使い方を理解する

LiteLLMは、Berri AI社が開発するオープンソースのLLMゲートウェイです。GitHubスター数は37,000以上。MITライセンスで誰でも無料で使えます。

LiteLLMには2つの利用形態があります。

① Python SDK(ライブラリ) 自分のPythonコードに ` ② LiteLLM Proxy(AIゲートウェイサーバー) Docker等でプロキシサーバーを立てて、チーム全体のLLMリクエストを一元管理する方法です。仮想APIキーの発行、チーム別の予算管理、レート制限、フォールバック、ログ連携——本番環境に必要な機能が揃っています。

どちらもOpenAI互換のAPIフォーマットを採用しているため、既存のOpenAI SDKで書かれたコードをほぼそのまま流用できるのが最大の強みです。

インストール方法とAPIキー設定

Python SDKのインストール

pip install litellm

これだけです。Python 3.8以上が必要です。

### APIキーの設定

LiteLLM自体にAPIキーは不要ですが、呼び出す先のプロバイダーのAPIキーが必要です。環境変数で設定します。

```bash
# OpenAI
export OPENAI_API_KEY="sk-..."

# Anthropic
export ANTHROPIC_API_KEY="sk-ant-..."

# Google Gemini
export GEMINI_API_KEY="AIza..."

# AWS Bedrock
export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_REGION_NAME="us-east-1"

# Azure OpenAI
export AZURE_API_KEY="..."
export AZURE_API_BASE="https://your-resource.openai.azure.com"
export AZURE_API_VERSION="2024-10-21"

環境変数を設定したら、すぐにコードから呼び出せます。`.env` ファイルと `python-dotenv` を使うのも一般的です。

```python
# .envファイルを使う場合
from dotenv load_dotenv()

from litellm

## 基本的な使い方——同じコードで3社のLLMを呼び出す

LiteLLMの真価は「モデル名を変えるだけ」でプロバイダーを切り替えられる点にあります。以下のコードを見れば、そのシンプルさが伝わるはずです。

```python
from litellm
# 共通のメッセージ
messages = [{"role": "user", "content": "日本の首都はどこですか?"}]

# ① OpenAI GPT-4oを呼び出す
response = completion(model="gpt-4o", messages=messages)
print(response.choices[0].message.content)

# ② Anthropic Claude 4 Sonnetに切り替え(modelを変えるだけ)
response = completion(model="claude-4-sonnet-20260514", messages=messages)
print(response.choices[0].message.content)

# ③ Google Gemini 2.5 Flashに切り替え
response = completion(model="gemini/gemini-2.5-flash", messages=messages)
print(response.choices[0].message.content)

<strong>たった3行のモデル名の違い</strong>で、3社のまったく異なるAPIを同じ形式で呼び出せています。レスポンスの形式もOpenAI互換に統一されるため、後続の処理コードを書き換える必要がありません。

### ストリーミング対応

```python
from litellm
response = completion(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Pythonの魅力を3つ教えてください"}],
    stream=True
)

for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")

### 非同期呼び出し(async)

```python
litellm
async def main():
    response = await acompletion(
        model="claude-4-sonnet-20260514",
        messages=[{"role": "user", "content": "非同期処理のメリットは?"}]
    )
    print(response.choices[0].message.content)

asyncio.run(main())

## サポートプロバイダー一覧と対応モデル名

LiteLLMは100以上のプロバイダーに対応しています。主要なものを一覧にまとめます。

| プロバイダー | モデル名の例 | プレフィックス |
|-------------|-------------|--------------|
| <strong>OpenAI</strong> | `gpt-4o`, `gpt-4o-mini`, `o3-mini` | なし |
| <strong>Anthropic</strong> | `claude-4-sonnet-20260514`, `claude-4-opus-20260514` | なし |
| <strong>Google Gemini</strong> | `gemini/gemini-2.5-pro`, `gemini/gemini-2.5-flash` | `gemini/` |
| <strong>AWS Bedrock</strong> | `bedrock/anthropic.claude-v2` | `bedrock/` |
| <strong>Azure OpenAI</strong> | `azure/gpt-4o` | `azure/` |
| <strong>Google Vertex AI</strong> | `vertex_ai/gemini-2.5-pro` | `vertex_ai/` |
| <strong>Mistral</strong> | `mistral/mistral-large-latest` | `mistral/` |
| <strong>Cohere</strong> | `command-r-plus` | なし |
| <strong>Groq</strong> | `groq/llama-3.3-70b-versatile` | `groq/` |
| <strong>Together AI</strong> | `together_ai/meta-llama/Llama-3.3-70B` | `together_ai/` |
| <strong>Ollama(ローカル)</strong> | `ollama/llama3.3` | `ollama/` |
| <strong>Replicate</strong> | `replicate/meta/llama-3.3-70b` | `replicate/` |
| <strong>Databricks</strong> | `databricks/dbrx-instruct` | `databricks/` |
| <strong>Cloudflare Workers AI</strong> | `cloudflare/...` | `cloudflare/` |

対応モデルの完全なリストは [LiteLLM公式ドキュメント](https://docs.litellm.ai/docs/providers) で確認できます。新しいモデルが出るたびに迅速に対応されるのもOSSコミュニティの強みです。

## フォールバック設定——障害に強いLLM運用

![障害時にLLM接続先を順次切り替える経路図](/article-images/litellm-guide-2026-1.png)

本番環境でLLMを使う場合、プロバイダーの障害は避けられません。LiteLLMのフォールバック機能を使えば、<strong>「[GPT-4o](/tool/chatgpt)が落ちたら[Claude](/tool/claude)、それもダメならGemini」</strong>という自動切り替えを数行で実装できます。

```python
from litellm
# フォールバックチェーンを定義
fallback_models = ["gpt-4o", "claude-4-sonnet-20260514", "gemini/gemini-2.5-pro"]

messages = [{"role": "user", "content": "量子コンピューティングを小学生に説明して"}]

response = completion(
    model="gpt-4o",
    messages=messages,
    fallbacks=fallback_models,  # 失敗時に順番に試行
    num_retries=2               # 各モデルで最大2回リトライ
)
print(response.choices[0].message.content)

### ロードバランシング(複数モデルに分散)

```python
from litellm
# ルーター設定:同じ「gpt-4o」への複数デプロイメントを分散
router = Router(
    model_list=[
        {
            "model_name": "gpt-4o",
            "litellm_params": {
                "model": "azure/gpt-4o-eastus",
                "api_base": "https://eastus.openai.azure.com",
                "api_key": "..."
            }
        },
        {
            "model_name": "gpt-4o",
            "litellm_params": {
                "model": "azure/gpt-4o-westus",
                "api_base": "https://westus.openai.azure.com",
                "api_key": "..."
            }
        },
        {
            "model_name": "gpt-4o",
            "litellm_params": {
                "model": "gpt-4o",  # OpenAI本家
                "api_key": "sk-..."
            }
        }
    ],
    routing_strategy="least-busy",  # 最も空いているデプロイメントに振る
    num_retries=3,
    fallbacks=[{"gpt-4o": ["claude-4-sonnet-20260514"]}]
)

response = router.completion(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello"}]
)

この設定なら、Azure East US・Azure West US・OpenAI本家の3つのエンドポイントにリクエストを分散しつつ、全部ダメならClaudeにフォールバックします。プロバイダー1社の障害でサービスが止まるリスクを大幅に削減できます。

## コスト追跡と最適化

LLMのAPI費用は放置すると簡単に膨れ上がります。LiteLLMには<strong>モデルごと・チームごと・APIキーごとのコスト追跡</strong>が組み込まれています。

### SDK でコストを取得する

```python
from litellm
response = completion(
    model="gpt-4o",
    messages=[{"role": "user", "content": "短く自己紹介して"}]
)

# レスポンスからコスト情報を取得
print(f"入力トークン: {response.usage.prompt_tokens}")
print(f"出力トークン: {response.usage.completion_tokens}")
print(f"コスト: ${response._hidden_params.get('response_cost', 'N/A')}")

### Proxyでチーム別予算を設定

```yaml
# config.yaml(LiteLLM Proxy設定ファイル)
general_settings:
  master_key: sk-litellm-master-key

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: gpt-4o
      api_key: os.environ/OPENAI_API_KEY

# チーム別の予算上限
litellm_settings:
  max_budget: 1000          # 全体の月次予算上限(ドル)
  budget_duration: "monthly"

```bash
# APIでチーム別予算を設定
curl -X POST "http://localhost:4000/team/new" \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{
    "team_alias": "engineering",
    "max_budget": 500,
    "budget_duration": "monthly"
  }'

チームAが月$500、チームBが月$200——という粒度で予算を管理できます。上限に達したらリクエストが自動的にブロックされるため、「気づいたら$10,000の請求が来ていた」という事故を防げます。

## LiteLLM Proxyサーバーの立て方

![LiteLLM Proxyを中心にしたチーム運用インフラ](/article-images/litellm-guide-2026-2.png)

チームでLLMを運用するなら、LiteLLM Proxyは事実上の必須インフラです。Docker一発で立てられます。

### Step 1: 設定ファイル(config.yaml)を作成

```yaml
model_list:
  # OpenAI
  - model_name: gpt-4o
    litellm_params:
      model: gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  # Anthropic
  - model_name: claude-4-sonnet
    litellm_params:
      model: claude-4-sonnet-20260514
      api_key: os.environ/ANTHROPIC_API_KEY

  # Google Gemini
  - model_name: gemini-2.5-flash
    litellm_params:
      model: gemini/gemini-2.5-flash
      api_key: os.environ/GEMINI_API_KEY

  # フォールバック用のバックアップモデル
  - model_name: fallback-model
    litellm_params:
      model: gemini/gemini-2.5-flash
      api_key: os.environ/GEMINI_API_KEY

litellm_settings:
  # フォールバック設定
  fallbacks:
    - gpt-4o: ["claude-4-sonnet", "fallback-model"]
    - claude-4-sonnet: ["gpt-4o", "fallback-model"]

  # コスト追跡を有効化
  success_callback: ["langfuse"]  # Langfuseにログ送信

general_settings:
  master_key: sk-your-master-key
  database_url: os.environ/DATABASE_URL  # PostgreSQL

### Step 2: Dockerで起動

```bash
docker run -d \
  --name litellm-proxy \
  -p 4000:4000 \
  -v $(pwd)/config.yaml:/app/config.yaml \
  -e OPENAI_API_KEY="sk-..." \
  -e ANTHROPIC_API_KEY="sk-ant-..." \
  -e GEMINI_API_KEY="AIza..." \
  -e DATABASE_URL="postgresql://user:pass@host:5432/litellm" \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml

### Step 3: 動作確認

```bash
# ヘルスチェック
curl http://localhost:4000/health

# OpenAI互換のAPIとして呼び出し
curl -X POST http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-your-master-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

プロキシが立ち上がれば、チームメンバーは `http://localhost:4000` をOpenAI APIのベースURLとして設定するだけで、すべてのモデルにアクセスできます。個々のプロバイダーのAPIキーを配布する必要がなくなるのは、セキュリティ面でも大きなメリットです。

### 仮想APIキーの発行

```bash
# チームメンバー用のAPIキーを発行
curl -X POST "http://localhost:4000/key/generate" \
  -H "Authorization: Bearer sk-your-master-key" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "engineering",
    "max_budget": 100,
    "duration": "30d",
    "models": ["gpt-4o", "claude-4-sonnet"]
  }'

仮想キーごとに「使えるモデル」「予算上限」「有効期限」を細かく制御できます。

## 料金プラン

LiteLLMはオープンソース(MITライセンス)なので、ソフトウェアそのものは無料です。ただし、運用形態によってコストが変わります。

| プラン | ライセンス費用 | 含まれる機能 | 想定ユーザー |
|--------|-------------|-------------|-------------|
| <strong>OSS(無料)</strong> | $0 | 統一API、フォールバック、ロードバランシング、基本ログ、仮想キー管理 | 個人開発者、小規模チーム |
| <strong>Enterprise Basic</strong> | $250/月〜 | OSS全機能+Prometheusメトリクス、LLMガードレール、JWT認証、SSO(6人以上)、監査ログ | 中規模チーム |
| <strong>Enterprise Premium</strong> | $30,000/年〜 | Enterprise Basic全機能+優先サポート、カスタム開発、SLA保証、専任アカウント管理 | 大規模組織 |

<strong>注意すべきポイント:</strong>

- <strong>SSO(シングルサインオン)は5人まで無料</strong>。6人以上のチームでSSOを使うにはEnterprise Basicが必要
- <strong>ソフトウェアは無料でもインフラ費用は別</strong>。PostgreSQL + Redisのマネージドサービスで月$100〜$400が目安
- 本番運用のTCO(総所有コスト)は、OSS版でも月$500〜$1,500程度が現実的なライン
- LLM APIの呼び出し費用はLiteLLMの料金に含まれない(各プロバイダーに直接支払い)

結論として、個人〜小規模チームなら<strong>OSS版で十分</strong>。チームが10人を超えてガバナンスが必要になったらEnterprise Basicを検討する、というステップが合理的です。

## OpenRouterとの比較

LiteLLMと並んでよく名前が挙がるのが[OpenRouter](https://openrouter.ai/)です。どちらも「複数のLLMを統一APIで呼び出す」という目的は同じですが、思想がまったく違います。

| 比較項目 | LiteLLM | OpenRouter |
|---------|---------|------------|
| <strong>形態</strong> | セルフホスト型(OSS) | フルマネージドSaaS |
| <strong>料金</strong> | ソフトウェア無料+インフラ自前 | API呼び出し単価にマージン上乗せ |
| <strong>APIキー管理</strong> | 自分で各プロバイダーのキーを取得 | OpenRouter 1アカウントで全モデル利用 |
| <strong>セットアップ</strong> | Docker + 設定ファイル(30分〜) | アカウント登録のみ(5分) |
| <strong>カスタマイズ</strong> | YAML設定で自由自在 | 限定的 |
| <strong>データの経路</strong> | 自分のサーバー経由(完全制御) | OpenRouterのサーバー経由 |
| <strong>フォールバック</strong> | 自分で細かく設定可能 | 自動ルーティングあり |
| <strong>チーム管理</strong> | 仮想キー・予算管理・レート制限 | 基本的にキー単位の管理 |
| <strong>対応モデル数</strong> | 100+ | 300+(サードパーティモデル含む) |
| <strong>運用負荷</strong> | 高い(サーバー管理が必要) | ほぼゼロ |

### どちらを選ぶべきか

<strong>LiteLLMを選ぶべきケース:</strong>
- 社内のセキュリティポリシーで外部SaaSにリクエストを経由させられない
- チーム別の予算管理・レート制限を細かく制御したい
- 自社のインフラチームがDockerやKubernetesを運用できる
- 既にAWS Bedrock / Azure OpenAI等のクラウドアカウントを持っている

<strong>OpenRouterを選ぶべきケース:</strong>
- サーバー管理をしたくない(インフラエンジニアがいない)
- 多数のモデルをすぐに試したい(300以上のモデルに即アクセス)
- 個人開発で手軽に始めたい
- 月額固定費を避けたい(従量課金のみ)

要するに、<strong>エンジニアリングリソースがあってセキュリティ重視ならLiteLLM、手軽さ重視ならOpenRouter</strong>。両者は排他的ではなく、開発段階ではOpenRouterで素早くプロトタイプし、本番ではLiteLLM Proxyに移行する——という使い方も現実的です。

## AI PICKSの独自評価

AI PICKSでは、500以上のAIツールを独自の評価基準でスコアリングしています。外部レビュー・SNSバズ・トレンド指数・サイト人気度・プロダクト品質の5軸で総合評価しています。

| ツール名 | 総合スコア | 料金タイプ |
|---|---|---|
| ChatGPT | 95pt | フリーミアム |
| Claude | 93pt | フリーミアム |

*スコアはAI PICKSの独自基準で算出。詳細は[評価基準について](/about/editorial-policy)をご覧ください。*

## 編集部の検証メモ

### 検証の観点

LiteLLMを評価するにあたり、公開情報をもとに以下3つの軸で整理した。①<strong>統合API設計の使いやすさ</strong>(モデル切り替えのコスト)、②<strong>運用機能の充実度</strong>(フォールバック・予算管理・監視)、③<strong>セルフホスト vs SaaSのトレードオフ</strong>。同じ「マルチLLMゲートウェイ」というカテゴリでも、想定ユースケースで最適解が分かれるためだ。

### 公開情報からの比較整理

公式ドキュメントと主要競合の仕様を整理すると、以下のように違いが見える。

| 観点 | LiteLLM (OSS) | LiteLLM Enterprise | OpenRouter |
|------|--------------|-------------------|------------|
| ホスティング | セルフホスト | セルフホスト+商用サポート | SaaS(フルマネージド) |
| 料金 | 無料(MIT) | 要問い合わせ | 従量課金(モデルごと) |
| 対応プロバイダー | 100以上 | 100以上 | 主要100以上 |
| 予算・レート制限 | YAML設定で実装 | エンタープライズ機能込み | ダッシュボード |
| データの所在 | 自社インフラ内 | 自社インフラ内 | OpenRouter経由 |
| 日本語対応 | UIは英語、モデル側で対応 | 同左 | UIは英語、モデル側で対応 |
| 商用利用 | MITで自由 | 契約に準ずる | 利用規約に準ずる |

最新の料金・機能は公式サイトを参照されたい。

### 編集部の総合判断

- <strong>個人開発・PoC段階</strong>: Python SDKのみで十分。`pip install litellm`で即起動でき、コストはAPI利用料のみ。
- <strong>チーム開発・本番運用</strong>: LiteLLM Proxyのセルフホストが有力。APIキーの一元管理・予算上限・フォールバックをYAMLで宣言的に書ける。
- <strong>インフラ運用工数を避けたい場合</strong>: OpenRouterのほうが立ち上がりは早い。セキュリティ要件で社外にトークンを通せない組織はLiteLLM一択になる。

## よくある質問

### Q. LiteLLMは本当に無料で使えますか?

LiteLLM自体はMITライセンスのオープンソースで、ライセンス費用は完全に無料です。ただし、LLM APIの呼び出し費用(OpenAIやAnthropicへの支払い)と、プロキシサーバーのインフラ費用は別途かかります。個人でPython SDKとして使うだけならインフラ費用もゼロで、純粋にLLM APIの従量課金のみです。

### Q. LiteLLMとLangChainの違いは何ですか?

目的がまったく違います。LiteLLMは「LLM APIの統一インターフェース」であり、モデルの呼び出し・フォールバック・コスト管理に特化しています。LangChainは「LLMを使ったアプリケーションのフレームワーク」で、チェーン・エージェント・RAGなどの高レベルな抽象化を提供します。実際、LangChainの内部でLiteLLMをモデルプロバイダーとして使うことも可能で、両者は補完関係にあります。

### Q. 本番環境でLiteLLM Proxyを使うにはどんなインフラが必要ですか?

最低限必要なのは、Docker実行環境・PostgreSQL(ログ・キー管理用)・Redis(レート制限・キャッシュ用)の3つです。AWS RDS + ElastiCacheを使う場合、データベースだけで月$100〜$400程度が目安。高可用性を求めるなら、Kubernetes上で複数レプリカを走らせる構成が推奨されます。

### Q. LiteLLMのセキュリティは大丈夫ですか?

2026年3月にPyPI上のLiteLLMパッケージ(v1.82.7)がサプライチェーン攻撃を受け、バックドアが仕込まれる事件が発生しました。現在は修正済みですが、<strong>必ず最新の安定版を使用し、公式のGitHubリリースとPyPIのバージョンが一致することを確認してください</strong>。Docker経由で公式イメージ(`ghcr.io/berriai/litellm`)を使うのが最も安全です。

### Q. LiteLLMでEmbeddingやImage生成も統一できますか?

はい。`litellm.embedding()` でOpenAI・Cohere・Bedrock等のEmbedding APIを統一呼び出しできます。画像生成は `litellm.image_generation()` で[DALL-E](/tool/dalle)・Stability AI等に対応。テキスト生成だけでなく、Embedding・画像生成・音声認識(Whisper互換)まで統一APIでカバーしています。

### Q. 既存のOpenAI SDKのコードをLiteLLMに移行するのは大変ですか?

ほぼゼロコストで移行できます。LiteLLM ProxyはOpenAI互換のエンドポイントを提供するため、既存コードの `base_url` を `http://your-litellm-proxy:4000/v1` に変えるだけです。SDK側のコードは一切変更不要。これはOpenAI SDKだけでなく、[ChatGPT](/tool/chatgpt) APIを前提に作られたあらゆるツール(LangChain、LlamaIndex、[CrewAI](/tool/crewai)等)でも同じです。

## 関連記事

- [【2026年最新】OpenAI Responses API完全ガイド|使い方・料金・Assistants API廃止前の移行手順](/mag/openai-responses-api-guide-2026)
- [【2026年最新】Claid AI完全ガイド|EC商品画像を自動で高品質化・料金・使い方・API活用術](/mag/claid-ai-guide-2026)
- [【2026年最新】Claude API完全ガイド|使い方・料金・Python実装を徹底解説](/mag/claude-api-guide-2026)