【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を使う場合、プロバイダーの障害は避けられません。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サーバーの立て方

チームで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)
