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

「OpenAIもAnthropicもGeminiも使いたいけど、APIの仕様がバラバラで管理しきれない」——複数のLLMを使い分ける開発者なら、一度はぶつかる壁です。LiteLLMはこの問題を根本から解決するオープンソースツールで、100以上のLLMプロバイダーをOpenAI互換の統一APIで呼び出せます。> この記事のポイント 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ゲートウェイ）が有力な選択肢。複数チームでのキー一元管理・予算上限・監査ログ・レート制限が必要な規模なら推奨。小規模やSDK直叩きで完結する用途では必須ではない
• OpenRouterとの最大の違いは「自分でインフラを持つか、SaaSに任せるか」。セキュリティ・カスタマイズ重視ならLiteLLM、手軽さ重視ならOpenRouter
• 個人開発者はSDK、チーム開発はProxy、エンタープライズはEnterprise版が最適解

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

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

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

① Python SDK（ライブラリ） 自分のPythonコードに from litellm import completion を組み込み、ライブラリとして利用する方法です。最小構成で素早く試せます。

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

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

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

Python SDKのインストール

pip install litellm

Python 3.8以上が必要です。なお、2026年3月にLiteLLMのPyPIパッケージで不正バージョン混入が報告された経緯があるため、導入前に公式リポジトリのリリースノートおよびセキュリティアドバイザリで最新の安全版を確認することを推奨します（2026年5月時点）。本番運用ではバージョンを明示的に固定（例: pip install litellm==<確認済みバージョン>）し、requirements.txt などのロックファイルとハッシュ検証（pip install --require-hashes）で再現性と完全性を担保してください。

APIキーの設定

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

# 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 import load_dotenv
load_dotenv()

from litellm import completion

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

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

```python
from litellm import completion

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

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

# ② Anthropic Claudeに切り替え（modelを変えるだけ）。具体的なモデル識別子はLiteLLM公式Provider一覧で最新のものを参照
response = completion(model="claude-3-5-sonnet-latest", 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 import completion

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
import asyncio
from litellm import acompletion

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

asyncio.run(main())

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

<img src="/images/articles/litellm-guide-2026-3.png" alt="LiteLLMの対応プロバイダー一覧" />

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

| プロバイダー | モデル名の例 | プレフィックス |
|-------------|-------------|--------------|
| <strong>OpenAI</strong> | `gpt-4o`, `gpt-4o-mini`, `o3-mini` | なし |
| <strong>Anthropic</strong> | `claude-3-5-sonnet-latest`, `claude-3-opus-latest` 等（[公式Provider一覧](https://docs.litellm.ai/docs/providers/anthropic)で最新識別子を要確認） | なし |
| <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 import completion

# フォールバックチェーンを定義（モデル識別子は公式Provider一覧で要確認）
fallback_models = ["gpt-4o", "claude-3-5-sonnet-latest", "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社の障害でサービスが止まるリスクを大幅に削減できます。

## コスト追跡と最適化

<img src="/images/articles/litellm-guide-2026-4.png" alt="LiteLLMのコスト追跡ダッシュボード" />

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: 動作確認

# ヘルスチェック
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ライセンス）なので、ソフトウェアそのものは無料です。ただし、運用形態によってコストが変わります。

注意すべきポイント：

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

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

OpenRouterとの比較

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

どちらを選ぶべきか

LiteLLMを選ぶべきケース：

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

OpenRouterを選ぶべきケース：

• サーバー管理をしたくない（インフラエンジニアがいない）
• 多数のモデルをすぐに試したい（300以上のモデルに即アクセス）
• 個人開発で手軽に始めたい
• 月額固定費を避けたい（従量課金のみ）

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

AI PICKSの独自評価

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

スコアはAI PICKSの独自基準で算出。詳細は評価基準についてをご覧ください。

編集部の検証メモ

検証の観点

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

公開情報からの比較整理

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

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

編集部の総合判断

• 個人開発・PoC段階: Python SDKのみで十分。pip install litellmで即起動でき、コストはAPI利用料のみ。
• チーム開発・本番運用: LiteLLM Proxyのセルフホストが有力。APIキーの一元管理・予算上限・フォールバックをYAMLで宣言的に書ける。
• インフラ運用工数を避けたい場合: 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）がサプライチェーン攻撃を受け、バックドアが仕込まれる事件が発生しました。現在は修正済みですが、必ず最新の安定版を使用し、公式のGitHubリリースとPyPIのバージョンが一致することを確認してください。Docker経由で公式イメージ（ghcr.io/berriai/litellm）を使うのが最も安全です。

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

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

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

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

関連記事

• 【2026年最新】OpenAI Responses API完全ガイド｜使い方・料金・Assistants API廃止前の移行手順
• 【2026年最新】Claid AI完全ガイド｜EC商品画像を自動で高品質化・料金・使い方・API活用術
• 【2026年最新】Claude API完全ガイド｜使い方・料金・Python実装を徹底解説