📚 参考書籍

※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。

####『ゼロから触ってわかった！AI Agent Observability入門― MLflow・Databricksで実践するAIエージェントの評価・監視・安全性・説明可能性』
本書は、AI Agentを「作って動かす」だけでなく、その品質をどう観測し、どう評価し、どう守り、どう説明可能にするかを体系的に学ぶための入門書です。
https://link.amazon/B04VaTlR3

####『ゼロから触ってわかった！AI Gateway入門 ― LiteLLMで学ぶ、LLM・AIエージェント・MCPを安全につなぐための基礎知識』
https://link.amazon/B07CHz9OB

⚡AI Gateway入門⚡ 統一エンドポイントとは？複数LLMの接続を共通化する仕組み

複数のLLMを利用する場合、プロバイダーごとにAPIの接続先、認証方法、モデル名、リクエスト形式が異なります。

アプリケーションがそれぞれの違いを直接扱うと、モデルを追加・変更するたびに実装やテストが必要になります。

そこで活用するのが、**AI Gatewayの統一エンドポイント（Unified Endpoint）**です。

1. なぜ統一エンドポイントが必要なのか？

AI Gatewayを利用しない場合、アプリケーションは各プロバイダーへ直接接続します。

アプリ → OpenAI / Anthropic / 社内LLM

この構成では、次の情報を個別に管理します。

• APIエンドポイント
• APIキーやアクセストークン
• モデル名
• リクエスト・レスポンス形式
• エラーコード
• StreamingやTool Callingの仕様

接続先が増えるほど、実装が複雑になります。

AI Gatewayを配置すると、構成は次のようになります。

アプリ → AI Gateway → 各LLMプロバイダー

アプリケーションは共通の接続先だけを利用し、プロバイダーごとの差異をGateway側で吸収します。

2. OpenAI互換APIによる接続の共通化

AI Gatewayでは、統一エンドポイントとしてOpenAI互換APIがよく利用されます。

これは、異なるLLMをOpenAI APIに近い形式で呼び出す仕組みです。

例えば、次のようなリクエストを送信します。

{
  "model": "general-model",
  "messages": [
    {
      "role": "user",
      "content": "この文章を要約してください"
    }
  ]
}

LiteLLM ProxyもOpenAI互換APIを提供しています。

2026年現在、LiteLLMは100以上のLLMプロバイダーに対応しています。

OpenAI SDKを利用する場合、接続先URLとAPIキーを変更してGatewayへ接続できます。

[
from openai import OpenAI

client = OpenAI(
base_url="http://localhost:4000",
api_key="sk-your-virtual-key"
)

response = client.chat.completions.create(
model="general-model",
messages=[
{"role": "user", "content": "こんにちは"}
]
)

print(response.choices[0].message.content)
]

※Gatewayの起動とモデル登録が必要です。

3. モデル抽象化とは？

モデル抽象化とは、実際のプロバイダー名やモデル名をアプリケーションから隠し、共通名で利用する考え方です。

例えば、

• general-model：一般的な文章生成
• low-cost-model：低コスト処理
• reasoning-model：高度な推論
• coding-model：コード生成

といった名前を定義します。

LiteLLMではmodel_nameを使って、共通名と実際のモデルを対応付けます。

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

これは設定例です。

実際のモデルを変更する場合も、Gateway側の対応付けを変更すれば、アプリケーションのモデル名を維持できます。

アプリケーションと実際のLLMを疎結合にすることが重要です。

4. 統一エンドポイントとルーティング

統一エンドポイントは、単純な通信中継だけではありません。

Gatewayでは、設定されたルールに基づいて接続先を選択できます。

例えば、

• モデルエイリアス
• 利用者や所属チーム
• 処理内容
• 予算やレート制限
• リージョン
• モデルの稼働状況

などを考慮した設計が可能です。

LiteLLMには、Load Balancing、Retry、Fallbackなどの機能があります。

ただし、機密度や地域に応じた振り分けは自動的に保証されるものではなく、明示的なルール設計が必要です。

5. 認証情報もGatewayで一元管理する

統一エンドポイントでは、アプリケーションに各プロバイダーのAPIキーを直接設定する必要を減らせます。

LiteLLMでは、Virtual Keyを利用できます。

• アプリケーションごとにキーを発行
• 利用可能なモデルを制限
• 予算・レート制限を設定
• 問題が発生したキーを失効
• プロバイダー側のキーを集中管理

なお、LiteLLMのVirtual Keyや予算管理にはPostgreSQLなどのデータベース構成が必要です。

接続先だけでなく、認証情報も共通化することが重要です。

6. OpenAI互換APIにも限界がある

OpenAI互換APIは、すべてのLLMの機能が完全に一致することを保証しません。

モデルによって次の違いがあります。

• Tool Calling
• Structured Outputs
• 画像・音声入力
• Streaming
• 最大コンテキスト長
• 指定可能なパラメーター
• 推論モデル固有の設定

あるモデルで成功したリクエストが、別のモデルでは失敗する場合もあります。

そのため、実務では次のように使い分けます。

• 共通処理は統一エンドポイントを利用
• モデル固有機能は個別設定を利用
• 非互換の処理は専用APIを検討
• モデル変更時は機能・品質を再検証

まとめると

AI Gatewayの統一エンドポイントは、複数LLMへの接続を共通化する仕組みです。

• OpenAI互換APIで呼び出し形式を統一する
• モデルエイリアスで接続先を抽象化する
• ルーティングで接続先を制御する
• Virtual Keyで認証情報を管理する
• モデル固有機能の違いには注意する

重要なのは、モデルの機能を完全に同一化するのではなく、接続方法を共通化して変更の影響を小さくすることです。