Kong AI Gateway の使い方 — Docker で最小構成を動かす導入手順
Kong AI Gateway を検討するとき、最初の壁は「まず手元で動かすには何が必要か」です。本記事では、データベースなし（DB-less）の Kong Gateway を Docker で起動し、ai-proxy プラグイン経由で OpenAI 互換の入口を立てて、curl で応答を確認するまでの手順を示します。ローカル環境なら30分ほどで一巡できる内容です。
設定例は Kong Gateway 3.x 系の宣言的設定（declarative config）で書いています。プラグインのスキーマはバージョンで変わることがあるため、動かない場合は 公式ドキュメント（Plugin Hub: ai-proxy）で手元のバージョンの仕様を確認してください。
構成の全体像
今回作るのは次の構成です。アプリ（ここでは curl）は Kong の 8000 番ポートに OpenAI 形式のリクエストを送り、Kong の ai-proxy プラグインがプロバイダごとの認証ヘッダー付与とリクエスト変換を行って、LLM プロバイダに中継します。アプリ側は API キーを持ちません。
(キーを持たない)
認証付与・変換・中継
Anthropic ほか
前提条件
必要なものは3つです。(1) Docker が動く環境（Docker Desktop / OrbStack / Linux いずれも可）。(2) LLM プロバイダの API キー（この記事では OpenAI を例にします）。(3) Kong Gateway 3.6 以降。ai-proxy プラグインは 3.6 でオープンソース版に入ったため、それより古いイメージでは動きません。この記事では執筆時点の安定系である 3.9 系イメージを使います。
データベースは使いません。Kong には設定を PostgreSQL に持つモードと、YAML ファイル1枚で完結する DB-less モードがあり、検証には DB-less が向いています。設定ファイルがそのまま構成のドキュメントになり、Git で差分管理できるのも利点です。
手順1: 宣言的設定 kong.yml を書く
作業ディレクトリに kong.yml を作ります。service と route を1組定義し、その route に ai-proxy プラグインを付けます。
_format_version: "3.0"
services:
- name: openai-chat
url: https://api.openai.com
routes:
- name: openai-chat-route
paths:
- /openai/chat
plugins:
- name: ai-proxy
config:
route_type: llm/v1/chat
auth:
header_name: Authorization
header_value: Bearer sk-XXXX # 本番では直書きせず Vault 参照や環境変数に
model:
provider: openai
name: gpt-4o-mini
options:
max_tokens: 512
temperature: 0.7設定のポイントは3つあります。route_type: llm/v1/chat は「OpenAI の Chat Completions 形式で受けて中継する」という宣言です。auth.header_value に API キーを書くことで、Kong がプロバイダへのリクエストにキーを付けます。model.name をゲートウェイ側で固定しているため、クライアントがモデルを指定する必要はありません（部門ごとに使えるモデルを固定する、という統制がこの1行でできます）。
なお、検証を早く始めるためにキーを直書きしていますが、この YAML を Git に入れる段階で必ず外部化してください。Kong には環境変数や外部シークレットストアを参照する Vault 機能があり、{vault://env/openai-api-key} のような参照形式に置き換えられます。
手順2: Docker で起動する
docker run -d --name kong-ai \ -v "$(pwd)/kong.yml:/kong/declarative/kong.yml" \ -e KONG_DATABASE=off \ -e KONG_DECLARATIVE_CONFIG=/kong/declarative/kong.yml \ -e KONG_PROXY_LISTEN="0.0.0.0:8000" \ -e KONG_ADMIN_LISTEN="0.0.0.0:8001" \ -p 8000:8000 -p 8001:8001 \ kong:3.9
起動したら設定が読めているかを Admin API で確認します。curl -s localhost:8001/routes で routes が1件返れば読み込みは成功です。YAML の構文エラーがあるとコンテナが起動直後に落ちるので、その場合は docker logs kong-ai でエラー行を確認します。
手順3: curl で動作を確認する
curl -s http://localhost:8000/openai/chat \
-H "Content-Type: application/json" \
-d '{
"messages": [
{"role": "user", "content": "1行で自己紹介してください"}
]
}' OpenAI の Chat Completions と同じ形式のレスポンスが返れば成功です。アプリ側から見ると「モデル名も API キーも知らないのに LLM が使える」状態になっており、これが AI Gateway を入口に置く意味そのものです。プロバイダを切り替えたくなったら、アプリのコードではなく kong.yml を書き換えます。
手順4: 2つ目のプロバイダを追加する
services 配列にもう1組追加すると、パスごとにプロバイダを使い分けられます。Anthropic の例です。
- name: anthropic-chat
url: https://api.anthropic.com
routes:
- name: anthropic-chat-route
paths:
- /anthropic/chat
plugins:
- name: ai-proxy
config:
route_type: llm/v1/chat
auth:
header_name: x-api-key # Anthropic は Authorization ではなく x-api-key
header_value: sk-ant-XXXX
model:
provider: anthropic
name: claude-sonnet-4-5 # 利用可能なモデル名に置き換える
options:
anthropic_version: "2023-06-01"
max_tokens: 512これで /openai/chat と /anthropic/chat という2つの入口ができ、アプリは同じ OpenAI 形式のボディをどちらにも送れます。プロバイダごとの API 形式の差（認証ヘッダー、リクエスト構造）は ai-proxy が吸収します。DB-less モードの設定反映は、ファイル更新後にコンテナを再起動するか、Admin API の /config エンドポイントに新しい YAML を POST します。
つまずきやすい点
最小構成と本番の間にあるもの
ここまでの構成は「動く」までです。本番に置くときは、少なくとも次の4点を追加で設計することになります。(1) 呼び出し側の認証。今の入口は誰でも叩けるため、key-auth や OIDC で利用者を識別します。ここで付けた consumer 単位に、後述のコスト集計やレート制限が掛かります。(2) レート制限とコスト管理。トークン量ベースの制限や部門別の利用集計は AI 系プラグインの領域で、高度なものは有償版の機能に含まれます。(3) ログと可観測性。誰がどのモデルに何トークン使ったかの記録は、監査とコスト配賦の土台になります。(4) 設定の運用。DB-less の YAML を Git 管理し、CI から配布する形（いわゆる GitOps 運用）に乗せるか、コントロールプレーンを Konnect に任せるかの分岐です。
OSS の範囲でどこまで賄えるか、どこから有償版が必要かは、Kong のライセンスと料金の整理にまとめました。製品間の比較から入りたい場合は AI Gateway 比較（Kong / LiteLLM / Portkey）が前段になります。