なぜLLMゲートウェイが必要なのか

AIアプリケーションを開発していると、すぐに壁にぶつかります。モデルごとにエンドポイントが異なり、認証方式もバラバラで、特定のモデルが遅くなればコードを修正しなければなりません。OpenAI SDKで開発していたのに、急にClaudeへ切り替える必要が出たら？クライアントコードを全部書き換えることになります。

そこで登場するのが LLMゲートウェイ（LLM Gateway） 、別名 AIゲートウェイパターン です。クライアントは単一の安定したエンドポイントへリクエストを送り、ゲートウェイが内部的に適切なモデルへルーティングする構成です。LiteLLMやPortkeyなどのオープンソースプロキシを自前で運用する方法もありますが、サーバーレスのイングレスレイヤーで処理できれば運用負荷は大きく下がります。

Google Cloud API Gatewayはこの点に着目し、モデルルーティング（Model Routing） 機能をPublic Previewで公開しました。OpenAI互換リクエストを受け取り、Gemini、Claude、OpenAI OSS-GPTなどのバックエンドへ動的にルーティングします。本記事では、OpenAPIスペックの記述からcurlでのテストまで、一通り追える形で整理します。

根拠資料: Google Developers Blog - A unified API for AI model routing

Cloud API gateway architecture diagram routing LLM traffic to multiple AI models Coding Session Visual

核心：OpenAPIスペックにルーターを定義する

API Gatewayのモデルルーティングは、OpenAPI 3.xスペック内に x-google-api-management 拡張ブロックとして定義します。バックエンド（モデルごとの実アドレス）とルーター（どのリクエストをどこへ送るか）を分離して宣言する構造です。

1) バックエンドの定義

まず各モデルの実エンドポイントを backends に列挙します。pathTranslation: CONSTANT_ADDRESS を指定すると固定アドレスへリクエストを送れます。

openapi: 3.0.4
info:
  title: OpenAPI 3.x spec using Model Routing
  version: 1.0.0
x-google-api-management:
  backends:
    gemini-35-flashlite:
      address: >-
        https://aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/global/publishers/google/models/gemini-3.5-flash-lite:generateContent
      deadline: 60.0
      pathTranslation: CONSTANT_ADDRESS
    anthropic-claude-opus-47:
      address: >-
        https://aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/global/publishers/anthropic/models/claude-opus-4-7:rawPredict
      deadline: 60.0
      pathTranslation: CONSTANT_ADDRESS
    openai-gpt-oss-120b:
      address: >-
        https://aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/global/endpoints/openapi/chat/completions
      deadline: 60.0
      pathTranslation: CONSTANT_ADDRESS

2) ルーターの定義

ルーターは デフォルトモデル（defaultModel） と ルール（rules） で構成されます。リクエストbodyの model フィールド値を見て、どのバックエンドへ送るかを決定します。

  ai:
    models:
      routing:
        routers:
          # ルーター1: デフォルトはGemini、model=claude-opus-4-7 ならClaudeへ
          gemini-claude-router:
            defaultModel:
              backend: gemini-35-flashlite
              targetModel: google/gemini-3.5-flash-lite
            rules:
              - model: "claude-opus-4-7"
                backend: anthropic-claude-opus-47
                targetModel: anthropic/claude-opus-4-7
          # ルーター2: デフォルトはOpenAI GPT、model=gemini-3.5-flash-lite ならGeminiへ
          openai-gemini-router:
            defaultModel:
              backend: openai-gpt-oss-120b
              targetModel: openai/gpt-oss-120b-maas
            rules:
              - model: "gemini-3.5-flash-lite"
                backend: gemini-35-flashlite
                targetModel: google/gemini-3.5-flash-lite

3) パスにルーターを紐付ける

各pathのPOSTオペレーションに x-google-model-router 拡張でルーターを指定します。クライアントから見ると、単なるOpenAI形式の /v1/chat/... エンドポイントに見えます。

servers:
  - url: "https://my-gateway.example.com"
paths:
  /v1/chat/gemini-claude:
    post:
      summary: "デフォルトGemini、Claudeオプション"
      operationId: "chatGeminiClaude"
      x-google-model-router: gemini-claude-router
      responses:
        '200':
          description: "OK"
  /v1/chat/openai-gemini:
    post:
      summary: "デフォルトOpenAI、Geminiオプション"
      operationId: "chatOpenAIGemini"
      x-google-model-router: openai-gemini-router
      responses:
        '200':
          description: "OK"

4) デプロイ後にcurlでテスト

ゲートウェイをデプロイした後は、クライアントコードをほぼ変えずにそのまま呼び出せます。ゲートウェイがpayloadをバックエンドのネイティブスキーマへトランスコードし、Agent Platformの認証トークンを自動で付与します。

curl -X POST "https://my-gateway.example.com/v1/chat/gemini-claude" \
  -H "content-type: application/json" \
  -H "x-api-key: $API_KEY" \
  -d '{
    "model": "claude-opus-4-7",
    "messages": [
      {"role": "user", "content": "Introduce yourself in 5 words"}
    ]
  }'

model フィールドに claude-opus-4-7 を入れるとルーターのルールに従ってClaudeバックエンドへ、それ以外や省略時はデフォルトのGeminiへ送られます。ここがポイントです。クライアントは依然としてOpenAIスキーマでリクエストしていますが、裏側ではClaudeが応答しているわけです。

Serverless API Gateway endpoint processing OpenAI-compatible chat completion requests Dev Environment Setup

注意点と実務上の落とし穴

機能自体は魅力的ですが、導入前に必ず確認すべき点があります。

1) 単一ルーターは単一ホストのみサポート

公式ドキュメントに明記された重要な制約です。1つのルーターが参照するすべてのバックエンドは同じホストを共有する必要があります。 例えば aiplatform.googleapis.com 一つにまとまっている必要があり、別ホスト（外部のOpenAI APIなど）へのクロスルーティングはできません。Vertex AI経由でClaudeとGPT-OSSを利用する構成だからこそ成立する設計です。

2) 認証分離のメリットを活かす

実務上の最大の利点は クライアント認証とバックエンドLLM認証の分離 です。アプリケーションはゲートウェイに対してのみ認証すればよく、バックエンドの資格情報はゲートウェイが管理します。モデルプロバイダーを変更したりキーをローテーションしても、アプリコードには触れる必要がありません。運用面で大きな差になります。

3) Agent Gatewayとの役割分担

Google CloudのAIゲートウェイは3層に分かれています。

  • Apigee: 本格的なAPI管理が必要な場合
  • Agent Gateway: エージェントのegressに対するセキュリティガバナンスが必要な場合
  • API Gateway（モデルルーティング）: 軽量に始め、ルールベースルーティング・レート制限・トークン追跡のみで足りる場合

実務ではAgent Gatewayでセキュリティガバナンスをかけ、その背後でAPI Gatewayが動的ルーティングを担う組み合わせが自然です。最初からApigeeまで行く必要はありません。

4) Public Previewである点

まだPublic Preview段階です。SLAや機能変更の可能性を考慮し、本番クリティカルパスへ直接投入するよりはパイロットで検証することを推奨します。特にルーティングルールが複雑になるほどデバッグ難易度が上がるため、ログとトークン追跡は最初から有効化しておくとよいです。

エージェントのセキュリティガバナンスをより深く知りたい場合は、NVIDIAが公開したゼロトラストランタイムの解説も併せて読むと全体像が掴めます。

AI chatbot terminal sending request through unified LLM gateway to Gemini and Claude IT Technology Image

まとめ：いつ使うべきか、次に何を見るべきか

Google Cloud API Gatewayのモデルルーティングは、「複数のLLMを1つのOpenAI互換エンドポイントにまとめたい」 という要件にぴったりのサーバーレスソリューションです。オープンソースプロキシを自前運用する負担なく、OpenAPIスペックにルーターを宣言するだけで済みます。

実務適用チェックリスト

  1. バックエンドのモデルがすべて 同じホスト（aiplatform.googleapis.com） にあるか確認
  2. クライアントはゲートウェイにのみ認証する設計にする
  3. ルーティングルールは最小限から始め、必要に応じて拡張
  4. トークン追跡とレート制限を最初から有効化し、コストの可視性を確保

次の学習ステップ

  • Agent Gatewayのドキュメント を読み、エージェントegressガバナンスのパターンを習得
  • Apigeeとの違い を比較し、組織規模に合った選択基準を策定
  • OpenAI互換スキーマと各バックエンドのネイティブスキーマの差異（特にtool calling、streaming）を確認

エージェントコマースの標準に関心があれば、UCP（Universal Commerce Protocol）完全ガイドも併せて読むと、AIエージェントが実際にトランザクションを処理する流れまで繋げて理解できます。

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。