複数LLMを1つのAPIで扱う：PythonでLLMゲートウェイを試す
はじめに
OpenAI、Anthropic、Googleなど、複数のLLMをアプリケーションから利用するケースが増えています。
しかし、プロバイダーごとにAPIの仕様、認証方法、エラー処理、料金体系が異なるため、モデルを追加するほど実装と運用が複雑になります。
この記事では、LLMゲートウェイを使って複数モデルへのアクセスを共通化する考え方と、PythonからOpenAI互換APIを呼び出す基本的な方法を紹介します。
LLMゲートウェイとは
LLMゲートウェイは、アプリケーションとAIモデルプロバイダーの間に配置する共通のAPIレイヤーです。
主に次の処理を一元化できます。
- モデルとプロバイダーのルーティング
- 障害発生時のフォールバック
- APIキーの管理
- レート制限
- 利用予算の制御
- 入出力のガードレール
- トークン数、コスト、レイテンシーの記録
アプリケーション側は1つのインターフェースを利用しながら、用途に応じて異なるモデルを選択できます。
PythonからAPIを呼び出す
最初にAPIキーを環境変数へ設定します。
export NROUTER_API_KEY="your-api-key"
Windows PowerShellの場合は次のように設定します。
$env:NROUTER_API_KEY="your-api-key"
続いて、requestsをインストールします。
pip install requests
以下は、OpenAI互換エンドポイントへリクエストを送信する例です。
import os
import requests
api_key = os.environ["NROUTER_API_KEY"]
url = "https://api.nrouter.ai/v1/chat/completions"
payload = {
"model": "deepseek-v4-pro",
"messages": [
{
"role": "user",
"content": "LLMのセマンティックキャッシュについて説明してください。"
}
]
}
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json"
}
response = requests.post(
url,
json=payload,
headers=headers,
timeout=60
)
response.raise_for_status()
data = response.json()
print(data["choices"][0]["message"]["content"])
APIキーをソースコードへ直接書かず、環境変数やシークレット管理サービスを使用することが重要です。
エラー処理を追加する
本番環境では、タイムアウト、レート制限、認証エラーなどを区別して処理します。
import os
import requests
def call_llm(prompt: str) -> str:
response = requests.post(
"https://api.nrouter.ai/v1/chat/completions",
headers={
"Authorization": f"Bearer {os.environ['NROUTER_API_KEY']}",
"Content-Type": "application/json"
},
json={
"model": "deepseek-v4-pro",
"messages": [
{"role": "user", "content": prompt}
]
},
timeout=60
)
if response.status_code == 429:
raise RuntimeError("レート制限に達しました")
if response.status_code in {500, 502, 503, 504}:
raise RuntimeError("モデルプロバイダーで一時的な障害が発生しました")
response.raise_for_status()
result = response.json()
return result["choices"][0]["message"]["content"]
print(call_llm("Pythonのasyncioを簡単に説明してください。"))
すべてのエラーを無条件で再試行すると、遅延とコストが増える可能性があります。再試行するエラー、最大試行回数、フォールバック先を事前に定義しておきましょう。
ルーティングポリシーを設計する
「最も優れたモデルへ自動的に送る」だけでは、運用可能なルールとはいえません。
モデルの選択基準を明確にする必要があります。
例えば、次のようなルールを設定できます。
- 分類処理には低コストのモデルを使用する
- 複雑な推論には高性能モデルを使用する
- 応答時間を優先する処理では低レイテンシーのモデルを選択する
- 規制対象データは承認済みのプロバイダーだけへ送信する
- タイムアウトやレート制限が発生した場合だけフォールバックする
- チームの予算上限に達した場合はリクエストを停止する
重要なのは、モデルが選ばれた理由をログから説明できることです。
記録しておきたい情報
本番環境では、リクエストごとに次の情報を記録するとトラブルシューティングが容易になります。
- 使用したモデルとプロバイダー
- ルーティングの理由
- 応答時間
- 入力・出力トークン数
- 推定コスト
- キャッシュの使用状況
- フォールバック回数
- 最終ステータス
プロンプトに個人情報や機密情報が含まれる可能性がある場合は、内容をそのままログへ保存しない設計も必要です。
まとめ
複数のLLMを利用すると、単純なAPI連携はルーティング、障害対応、セキュリティ、予算管理を含むインフラ課題へ変わります。
LLMゲートウェイを導入すると、アプリケーション側のインターフェースを維持しながら、モデル選択や運用ポリシーを一元管理できます。
今回のコード例では、OpenAI互換APIを提供するマルチモデルLLMゲートウェイのnRouter.aiを使用しました。実際に導入する際は、対応モデルだけでなく、フォールバック、ガードレール、監視、予算制御、データ処理方針も確認してください。
Qiitaタグ
Python 生成AI LLM API AI