Skip to Content
Docs05. 運用LLM ゲートウェイの設計
中級llm-gatewayroutingplatform更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

LLM ゲートウェイの設計

この記事の目的

複数モデル・複数プロバイダー・複数チームの LLM 利用を一元化するゲートウェイ層を設計できるようになります。ゲートウェイが解く問題(キー管理・モデル抽象化・コスト集計・監査・レート制御)を理解し、構成の類型(自作 / OSS / マネージド)を選び、ルーティング・フォールバック・マルチテナント複数のテナント(顧客・部門)が同一の Agent 基盤を共有する構成です。データ・設定・容量・費用を分けて設計し、認証キーを分けた場合も上流の共有上限と容量の隔離を別に確認します。制御の実装点を押さえ、落とし穴(単一障害点化・モデル固有機能の喪失)を避けられる状態を目指します。フォールバック・分離の原則は各正本に譲り、本記事は「それらを 1 つの部品に集約する」設計論です。

対象読者

  • 社内で複数チーム・複数プロバイダーの LLM 利用が広がり、統制・コスト把握に困っているプラットフォーム/運用担当
  • モデルの切り替え・フォールバック・使用量集計をアプリごとに実装していて、共通化したいテックリード

前提知識

本文

概要: ゲートウェイは「共通の交差点」

LLM ゲートウェイ(LLM gateway)は、アプリと LLM プロバイダーの間に置く共通の中継層です。各アプリが個別にプロバイダーを直接叩く代わりに、ゲートウェイを経由させることで、キー管理・モデル抽象化・コスト集計・統制を1 か所に集約します。本記事はこの集約の設計を扱い、フォールバック・分離・リトライの原則は デプロイとスケーリング / マルチテナント設計とテナント分離 / エラーハンドリングとリトライ設計 が正本です。

ゲートウェイが解く問題

ゲートウェイの価値は、各アプリで重複していた面倒を 1 か所に集めることです。

  • キー管理の一元化: プロバイダーの API キーをゲートウェイが保持し、各アプリには仮想キーを配る。キーの漏えい範囲を絞り、失効・ローテーションを一元化できます
  • モデル抽象化: 各アプリは統一 API(多くは OpenAI 互換形式)で呼び、裏側でどのプロバイダー/モデルを使うかをゲートウェイが決める。アプリ改修なしにモデルを差し替えられます
  • 使用量・コストの集計: チーム・アプリ・モデル別のトークン消費とコストを一元集計(コスト管理)。「誰がいくら使ったか」が見えます
  • 監査ログ: 誰が何を呼んだかを記録。統制・トレーサビリティの土台になります
  • レート制御・予算: チーム・キー単位のレート制限と予算上限を課し、暴走・超過を防ぎます

構成の類型

ゲートウェイの実現方法は 3 類型で、規模と統制要件で選びます(代表例は元の調査時点、Kong 2.0 の境界は 2026-09-10 に再確認)。

類型内容向く場面代表例(2026-07 時点)
薄い自作プロキシ最小限の中継を自作ごく小規模・要件が単純自前実装
OSS ゲートウェイOSS を自社ホスト統制・データ管理を自社に置きたいLiteLLM・Portkey Gateway 等(OSS コアと商用機能は分ける)
マネージドSaaS のゲートウェイ運用を任せたいCloudflare AI Gateway・各 OSS のマネージド版等

ルーティング設計

ゲートウェイの中核機能が、用途に応じてモデルを振り分けるルーティングです。

  • 用途別の振り分け: 簡単なタスクは小型・安価なモデル、難しいタスクは上位モデル、という振り分けを一元的に実装します(モデル選定ガイドのティア混在の実装点。小型活用は 小型言語モデル(SLM)の活用戦略)
  • 抽象化の粒度: どこまで抽象化するかを決めます。抽象化しすぎると後述の「モデル固有機能の喪失」が起き、しすぎないとアプリごとの分岐が増えます
  • 自ホストモデルも束ねる: セルフホストした OpenAI 互換エンドポイント(セルフホスト推論の実務)も、API プロバイダーと同じルーティングに載せられます。「借りる」と「自ホスト」を 1 つの入口に統一できます

フォールバック・リトライ・サーキットブレーカの実装点

信頼性機能は原則が別記事にあり、ゲートウェイはその実装を集約する場所です。

  • フォールバック: あるプロバイダー/モデルが失敗・過負荷のとき、別へ切り替える(原則は デプロイとスケーリング)。ゲートウェイに集約すると、全アプリが自動でフォールバックの恩恵を受けます
  • リトライ・サーキットブレーカ: 一時失敗のリトライと、繰り返し失敗する先を一時遮断するサーキットブレーカ(原則は エラーハンドリングとリトライ設計)。これもゲートウェイ層で共通化できます
  • アプリから消える利点: これらをアプリ個別に書かず、ゲートウェイに寄せることで、アプリはビジネスロジックに集中できます

マルチテナント制御との統合

複数チーム・複数テナントが使うゲートウェイは、分離とクォータを統合します。

  • テナント別のクォータ: チーム・テナント単位のレート制限・予算上限を課します(マルチテナント設計とテナント分離のクォータの実装点)。1 テナントの暴走が他に波及しないようにします
  • 仮想キーで境界を引く: テナント/アプリごとの仮想キーに権限・上限を紐づけ、分離の境界を明確にします
  • 集計の単位: コスト・使用量をテナント単位で集計し、課金・配賦の根拠にします

落とし穴

ゲートウェイは便利な一方、集約ゆえのリスクを抱えます。

製品の世代と OSS の境界

Kong AI Gateway 2.0 は 2026-09-01 GA で、独立した runtime・control plane・Admin API・version を持ちます。従来の Kong Gateway 3.x に AI プラグインを追加する構成と分けて評価します。Kong core の Apache-2.0 を製品全体の許諾とみなせません。旧プラグインの廃止を意味する変更でもありません。AI Proxy 無印の Free / OSS 利用範囲は未確定のまま、契約・機能 tier を確認します。

実務での注意点

アンチパターン

チェックリスト

  • ゲートウェイに集約する機能(キー管理・抽象化・集計・監査・レート制御)を決めた
  • 構成類型(自作 / OSS / マネージド)を規模・統制・データ要件で選んだ
  • OSS を使う場合、OSS コアと有償エンタープライズ機能の境界を確認した
  • 用途別ルーティングを設計し、自ホストモデルも同じ入口に束ねた
  • フォールバック・リトライ・サーキットブレーカをゲートウェイ層に集約した
  • テナント別のクォータ・予算・仮想キーで分離と集計を設計した
  • ゲートウェイを冗長化し、単一障害点にしない設計にした
  • 抽象化でモデル固有機能を失わない経路を残した

関連トピック

参考資料

TODO・未確認事項

本文の未確認事項を参照してください。

GPU・AI ハードウェアの基礎セマンティックキャッシュと応答再利用