# LLMゲートウェイ設計——ルーティング・レート制限・配賦を一元管理

> 複数チームのLLM利用をゲートウェイ1点で統制する設計を解説。モデルルーティング・チーム別レート制限・コスト配賦の設計パターンとLiteLLM・Kong AIの実装例を示します。

- Canonical: https://kuucorp.com/blog/llm-gateway-routing-rate-limiting/
- Date: 2026-05-31
- Last modified: 2026-05-31
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
複数のチームがそれぞれ直接LLM APIを呼び出している状態を放置すると、月末の請求書が届くまでコストが見えない、1チームのバーストが全組織の上限を食い潰す、モデルを変更するたびに各チームのコードを修正する——という問題が連鎖します。LLMゲートウェイはこの問題を単一アーキテクチャレイヤーで解消するための答えです。

## LLMゲートウェイとは何か

> LLMゲートウェイはアプリとAIプロバイダーの間に置くミドルウェアで、ルーティング・認証・レート制限・計測を一点で担います。

LLMゲートウェイ（AI Gateway）は、アプリケーションとAIモデルプロバイダー（Anthropic・OpenAI・Google等）の間に配置するプロキシミドルウェアです。アプリケーションはゲートウェイの単一エンドポイント（多くはOpenAI互換API）にリクエストを送り、ゲートウェイ側でプロバイダー選択・認証・ポリシー適用・計測を透過的に処理します。

この設計の利点は3点あります。第一に、アプリケーションコードをプロバイダーから切り離せるため、モデルをClaude Sonnetからgemini-2.0-flashに切り替えてもアプリの変更は不要です。第二に、全トラフィックがゲートウェイを通過するため、コスト・レイテンシ・エラー率を組織全体で一元計測できます。第三に、レート制限・予算上限・アクセス制御を中央集権的に管理でき、各チームが個別設定する分散ガバナンスを解消できます。

2026年時点の代表実装は**LiteLLM Proxy**（OSS、100以上のLLMプロバイダーに対応）と**Kong AI Gateway**（APIゲートウェイ基盤にAI機能を統合したエンタープライズ製品）です。Kong AI GatewayはLiteLLMと比較してレイテンシが86%低く、既存のAPIゲートウェイ基盤と統合したい大規模組織に向いています。

## モデルルーティング設計

> ルーティングはコスト優先・フォールバック・セマンティックキャッシュの3パターンで構成し、変更はゲートウェイ設定のみで完結します。

モデルルーティングは「どのリクエストをどのモデル／プロバイダーに送るか」をゲートウェイ層で決定する仕組みです。アプリケーション側はゲートウェイに送るだけでよく、ルーティングロジックはゲートウェイの設定に集約されます。

**コスト優先ルーティング**では、タスクの複雑度に応じてモデルを振り分けます。構造化データ抽出や定型分類のような単純タスクにはClaude Haiku、長文推論や複雑なツール連携にはClaude Sonnetを割り当てるルールをゲートウェイ設定で定義します。入力トークン単価はモデルによって10倍以上の差が存在するため、適切な振り分けは月間コスト削減の直接的な手段になります。

**フォールバックルーティング**はプロバイダー障害やレート制限超過時の自動切り替えです。Claude APIがエラーを返した場合にGeminiへ自動フォールバックする設定をゲートウェイに持たせておくと、アプリケーション側でリトライロジックを実装する必要がなくなります。プロバイダーの可用性変動をアプリに伝播させないことで、SLAの安定性が向上します。

**セマンティックキャッシュ**は、プロンプトの意味的類似度でキャッシュヒットを判定する手法です。完全一致ではなく意味的近さでキャッシュを引くため、LLMコールを削減しながら応答品質を維持できます。同一業務プロセスを繰り返す社内ツール（週次レポート生成・定型問い合わせ対応等）で特に効果を発揮します。

## チーム別レート制限とトークン予算の実装

> チーム別制限はTPM・RPM・USD予算の3次元で設定し、LiteLLMは `/team/new` エンドポイント1コールでチーム全体に適用できます。

エンタープライズ環境でのレート制限は「プロバイダーのAPIキー単位」ではなく「チーム・プロジェクト・環境単位」で管理する必要があります。プロバイダー側のAPIキー単位制限だけでは、あるチームのトラフィックバーストが他チームのSLAに影響する問題を防げません。

LiteLLM Proxyのチーム別制限は以下のAPI呼び出しで設定します。

```bash
curl -X POST http://localhost:4000/team/new \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "platform-eng",
    "tpm_limit": 500000,
    "rpm_limit": 1000,
    "max_budget": 500.0,
    "budget_duration": "30d",
    "model_tpm_limit": {
      "claude-sonnet-4-6": 300000,
      "claude-haiku-4-5-20251001": 200000
    }
  }'
```

`tpm_limit`（tokens per minute上限）・`rpm_limit`（requests per minute上限）・`max_budget`（USD予算上限）・`budget_duration`（予算リセット期間）の4パラメータがチーム別制限の基本セットです。`model_tpm_limit` でモデルごとに個別上限を設定でき、Sonnetへの意図しない過剰振り向けを防げます。チームメンバーはこの設定を自動継承し、個別キーはチームの上限を超えられません。

制限の階層は「個別キー→チーム→プロジェクト→グローバル」の4段階で解決されます。個別キーに上限を設定しない場合はチーム設定が適用され、チームに設定がなければグローバル設定が適用される継承モデルです。この階層により、組織全体のグローバル制限を守りながら、チームごとの柔軟な制限設計が両立します。

Kong AI Gatewayでは、サブスクリプション・エンタイトルメント・レートカードをカタログに定義し、消費時点でのリアルタイム強制適用が可能です。[AIエージェントの可観測性設計](/blog/agent-observability-tracing-instrumentation/)と組み合わせることで、どのチームのどのエージェントがどのモデルをどれだけ消費しているかをスパンレベルで追跡できます。

## コスト配賦（ショーバック／チャージバック）の設計

> ショーバックはコスト可視化のみ、チャージバックは費用を消費チームに実際に帰属させ、Kong の4段階フレームワークで段階的に移行できます。

LLMゲートウェイが全トラフィックを通過させる設計であれば、コスト配賦の技術的基盤は自然に整います。課題は「どの粒度で・どう組織に帰属させるか」の運用設計です。

**ショーバック（Showback）**は可視化のみで、チームの予算に直接影響を与えません。「platform-engチームは今月のLLMトークン消費が前月比40%増」という情報を提供しますが、コストは中央のIT予算が負担します。ショーバックだけでも消費の偏りや過剰APIコールを発見でき、チームの設計判断に影響を与え始めます。

**チャージバック（Chargeback）**は消費コストを実際に各チームの予算に転嫁します。Kong Konnect Metering and Billing（OpenMeter基盤）はプロバイダーとモデルバージョンごとのトークン単価を自動更新し、消費データをビジネスユニット単位の請求に変換します。84%の企業がAIコストによるグロスマージン圧迫を報告している現状では、チャージバック導入によりチームが「コストを意識した設計判断」をするようになります。

JWTクレーム（`user_id`・`team`・`app`・`env`）でトークン消費を分解すると、アプリ・ユーザー・環境ごとの詳細なコスト内訳が得られ、財務部門とプラットフォームチームの双方が利用できる統合レポートを構成できます。

段階的移行の4ステップは次のとおりです。

1. **基本ショーバック** — リクエスト量を可視化。既存ツールへの変更は不要で最短で導入可能
2. **高度ショーバック** — トークン数・モデル別コスト・トレンド分析まで拡張
3. **強制適用付きショーバック** — リアルタイムのエンタイトルメント制限を追加。予算超過をゲートウェイが遮断
4. **完全チャージバック** — 使用量をチーム予算に転嫁。AIコストが設計の第一級入力になる

LLMゲートウェイの設計・構築・運用基盤の整備は、[Kuu株式会社のReinvention Deployed Engineeringサービス](https://kuucorp.com/services/rde/)で一貫して支援しています。複数チームのLLM利用統制・コスト配賦モデルの設計・ゲートウェイのセキュリティ強化まで対応します。

## 参考

- [LLM Cost Management: AI Showback and Chargeback — Kong Inc.](https://konghq.com/blog/enterprise/llm-cost-management-ai-showback-and-chargeback)
- [Budgets, Rate Limits — LiteLLM Docs](https://docs.litellm.ai/docs/proxy/users)
- [Kong AI Gateway vs LiteLLM — Kong Inc.](https://konghq.com/blog/enterprise/kong-ai-gateway-vs-litellm)
- [Rate limiting for LLM applications — Portkey](https://portkey.ai/blog/rate-limiting-for-llm-applications/)

## まとめ

LLMゲートウェイは複数チームのLLM利用を統制するアーキテクチャの要です。ルーティング・レート制限・コスト配賦の3機能を一点に集約することで、モデル切り替えコスト・予算の不可視性・チームSLAの相互干渉という典型的なエンタープライズ課題を解消できます。

まずショーバック（コスト可視化）から始め、組織のAIコスト意識が醸成された段階でチャージバックへ移行する段階的アプローチが、導入摩擦を最小化しながら[エージェントガバナンス](/glossary/agent-governance/)を強化する現実的な道筋です。

LLMゲートウェイ基盤の設計・構築については[Kuu株式会社のRDEサービス](https://kuucorp.com/services/rde/)までご相談ください。