本記事は「Kong Advent Calendar 2025」の18日目のエントリとして、Kongのドキュメントサイトの機能であるAsk AIについて解説する。
Kong GatewayやInsomniaなどKong製品を日本で使う上での障壁として、ドキュメントが少なかったり英語版しかなかったりすることがある。
加えて、最近ドキュメントサイトのデザインが変更されて（人によっては）ドキュメントが探しにくい状況となっている。
ただ、これを解決する素晴らしい機能が（結構前だけど）いつのまにかドキュメントサイトに実装された。
最近KongのドキュメントサイトにAsk AIというボタンが出ているのにお気づきだろうか。
今回はこれを紹介する。
Ask AIとは
Ask AIとは名前の通りAIが回答してくれる機能で、裏側の技術としては開発者モードで見る限りkapa.ai（ドキュメントを学習し、利用者の質問に回答するAIプラットフォーム）が使われている模様。
クリックすると以下のようなテキストフォームが表示される。
ここで質問すると、ドキュメントサイト内の情報を元に様々な質問に回答してくれる。日本語での問い合わせもOK。
例えば「Kong Gatewayとは？」と質問した時の回答は以下となった。
欲しい情報を日本語でくれるのも然ることながら、下の「Answer based on the following sources:」のところには情報ソースも表示してくれる。
ハルシネーションの対策もされているようで、例えば「Kong Gatewayの3.13の情報を教えて。」とまだリリースされていないバージョンに聞いてみると以下のような回答が得られる。
※ 執筆は12/15に行っており、公開された時にはもしかしたら3.13が出てるかも。
知識ソースには、Kong Gateway 3.13 に関する情報がまだ掲載されていません。
現在参照できる最新付近のバージョンは 3.12.0.x や 3.4.3.13 などで、3.13 系のリリースノートや変更点は見つかりませんでした。[[Gateway changelog](https://developer.konghq.com/gateway/changelog/)]
そのため、
- 3.13 の有無（リリース済みかどうか）
- 3.13 固有の新機能・変更点・バグ修正
については、提供された知識ソースだけではお答えできません。
最新情報を確認するには、公式の Kong Gateway Changelog ページを直接参照するのが確実です。[[Gateway changelog](https://developer.konghq.com/gateway/changelog/)]
なのでそれなりに信頼できるAIとして活用できそうだ。
どういったことが回答できそうか、いくつか試してみる。
Q. Kong Gateway 3.12のリリースノートのサマリをください。
回答は以下となった。
Kong Gateway 3.12 系のリリースノートから読み取れる主なポイントを、ソースにある範囲でまとめます。1. コア機能・PDK の強化
PDK 機能追加
kong.request.get_id()でリクエスト ID を取得可能に。kong.response.get_raw_body()/kong.response.set_raw_body()を:response()ハンドラから利用可能に。[PDK feature 3.12.0.0]コアのバグ修正（3.12.0.0 / 3.12.0.1 / 3.12.0.2）
- CP 上の stream/proxy リスナーが誤ってルーターにアクセスする問題を修正（CP では無効化）。
- Postgres 接続失敗時のログ改善、Vault 連携時のエラー詳細ログ追加。
- keyring の「key not found」が過剰に warning になる問題を修正。
- Kafka/Confluent Consume のオフセット処理や ListOffset レスポンス v0 のパース不具合を修正。
- ワークスペースのカスケード削除時に一部エンティティが削除されない問題を修正。
- Postgres 古いバージョン向けの期限切れ行削除のパフォーマンス改善。[Core bugfix 3.12.0.0; Core bugfix 3.12.0.1; Core perf 3.12.0.2]
OIDC グループの区切り文字設定
admin_gui_auth_confにauthenticated_groups_delimiterを追加し、JWT のグループ値を分割するデリミタ（,,;,|）を指定可能に。[Core feature 3.12.0.2]2. Kong Manager
新機能・UI 改善
- Upstream でフェイルオーバーターゲットを UI から設定可能に。
- Service Protection プラグインの UI を刷新。
- JWT Signer プラグインの新パラメータに対応。
- Key Auth / Key Auth Encrypted プラグインで TTL を設定可能に。[KM feature 3.12.0.0]
既知の問題
- Kafka / Confluent 系プラグインのスキーマレジストリ設定で、
authentication.mode = noneが保存されない場合がある（回避策なし、未修正）。[Breaking changes 3.12]3. AI / LLM 関連プラグイン
AI Semantic Cache
- 名前空間の保存方法を変更（テーブル名ではなく専用カラム）し、キャッシュ無効化問題を解消。ただし既存キャッシュは無効化されるため、長い TTL を使っている場合はウォームアップが必要。[Breaking changes 3.12]
- pgvector 利用時の DELETE API のステータスコード不整合や 500 エラーを修正。
- SSE 終端文字列や非 OpenAI プロバイダのストリーミング対応を修正。
- Cohere / HuggingFace との互換性、TTFT メトリクス、コスト削減メトリクス計算の不具合を修正。[AI semantic cache changelog; Gateway 3.12.0.1 plugin fixes]
その他 AI プラグイン
- AI Proxy / AI Proxy Advanced / LLM ドライバで、Gemini・Bedrock・HuggingFace など各種プロバイダとの互換性やトークンカウント、エラー処理を多数修正。[Gateway 3.12.0.1; Gateway 3.12.0.2]
4. 認証・セキュリティ系プラグイン
JWT Signer
notbefore,issuer,subject,audienceなどの追加クレーム検証をサポート。- 必須クレーム / 任意クレームの存在・検証を制御するオプションを追加。
- アクセストークン / チャネルトークンの署名・再署名を個別に ON/OFF できる
access_token_signing/channel_token_signingを追加。[JWT Signer 3.12.0.0]OAuth2 Introspection
- 高メモリ使用の原因となっていた「ネガティブなイントロスペクション結果のキャッシュ」を修正。
- 認証失敗時にエラーログへメッセージが出ない問題を修正。[OAuth2 introspection 3.12.0.0]
ACL
- インクリメンタル同期時にキャッシュが無効化されず、古いデータが返ることがある問題を修正。[ACL 3.12.0.1]
5. トラフィック制御・OAS 関連
OAS Validation
- OpenAPI 3.0/3.1 の
discriminator,oneOf/anyOf/allOf/notなど高度なスキーマ機能をサポート。multipart/form-dataのバリデーションをサポート。- Content-Type ヘッダが無いレスポンスや、クエリパラメータのシリアライズ・explode=false、
$を含むパス、discriminator と組み合わせたネスト参照など、多数の不具合を修正。[OAS Validation changelog]Mocking
include_base_path/custom_base_pathなど、パス評価の柔軟性を向上。- 空配列がオブジェクトとして返ってしまう問題、再帰スキーマの検証、非 ASCII パスパラメータなどを修正。[Mocking changelog]
6. AWS / Kafka / モニタリング関連
AWS Lambda プラグイン
- AWS API Gateway 互換ペイロード v2 をサポート（
awsgateway_compatible_payload_versionで制御）。- Proxy integration 時の
Content-LengthやmultiValueHeaders、resource/versionフィールドなど、互換ペイロード周りの不具合を多数修正。[AWS Lambda changelog]Kafka / Confluent Consume
latestオフセットの挙動を正しくするenforce_latest_offset_resetフラグを追加（デフォルト false で後方互換）。- レコード未取得時のオフセットコミットバグを修正。[Gateway 3.12.0.1]
AppDynamics プラグイン
- バックエンドへのレスポンス時間計測を修正し、Upstream を含む全リクエスト時間を正しく計測。[AppDynamics 3.12.0.0]
7. 3.12 系の主なブレイキングチェンジ
Kafka Consume プラグイン
- Service スコープでの適用が廃止。Service に付けても動作せず、Upstream があれば通常プロキシ、無ければプロキシもプラグインも動作しない。[Breaking changes 3.12]
Konnect 内部プラグイン
konnect-application-authの優先度変更
- プラグイン優先度が 950 → 960 に変更され、ACL プラグインとの実行順を調整。
- これに依存するカスタムプラグインが 950–960 の間にある場合は、優先度や Dynamic Plugin Ordering の見直しが必要。[Breaking changes 3.12]
AI Semantic 系プラグインのキャッシュ無効化
- 前述の通り、名前空間の保存方法変更により既存キャッシュが無効化される。[Breaking changes 3.12]
上記は、提供された 3.12 系の changelog / breaking changes に基づくサマリです。特定のプラグインや機能（例: AI Gateway, Kafka, 認証系など）に絞った詳細が必要であれば、その範囲を指定してもらえれば、該当部分だけもう少し詳しく整理できます。
バージョンアップがあった時キャッチアップするのは大変だが、そういう時にはAsk AIに聞くと時間をかけずにキャッチアップできそうだ。
Q. Kong GatewayのAnalytics機能でメトリクスを保存する日数は何日ですか？
回答は以下となった。
提供された知識ソースの範囲では、「Kong Gateway の Analytics 機能でメトリクスを何日間保存するか」を一意に示す値は製品別・プラン別で異なっており、単一の日数としては明示されていません。確認できる情報は次のとおりです：
Konnect（Advanced Analytics アドオンあり）の場合
- Advanced Analytics のデータ保持期間は 最大 14 か月 とされています。[Advanced analytics]
- 同じく価格表でも、Advanced Analytics の「Data retention」は 14 months と記載されています。[Pricing analytics]
Konnect の「標準（Out-of-the-box）Analytics」の場合
- Konnect の標準 Analytics は、サービスのヘルスを「直近 7 日間」で表示するものとされています。[Advanced analytics]
Konnect Dev Portal のアプリケーション Analytics（Advanced Analytics 前提）
- 開発者向けアプリケーションダッシュボードでは、メトリクスを 最大 90 日間 の期間で表示できると記載されています（Advanced Analytics が必要）。[Dev portal analytics]
Kong Manager（オンプレ Vitals）の長期保存について
- Kong Manager の Vitals では 12 時間より古いデータを UI からは見られず、長期保存はサポートされていないため、長期保存が必要な場合は Datadog や Prometheus など外部ツールの利用が推奨されています。[Vitals retention]
このように、「何日保存されるか」は以下で変わります：
- Konnect 標準 Analytics: 7 日間のヘルス表示
- Konnect Advanced Analytics: 最大 14 か月
- Dev Portal アプリケーション Analytics（Advanced Analytics 前提）: 最大 90 日間の期間で閲覧
- オンプレ Kong Manager Vitals: 12 時間より長い期間の閲覧は不可（長期保存は外部ツール推奨）
どの環境（Konnect / オンプレ）・どの機能（標準 Analytics / Advanced Analytics / Dev Portal / Vitals）について知りたいかを教えていただければ、その範囲でより絞ってお答えできます。
情報源がKong Developerではなくkonghq.comからも引っ張ってきていたため、幅広い範囲を情報源として教えてくれることが分かる。
ただ、回答にVitals（旧Dev Portal、今は原則的に利用不可）の情報も混じっていたので、この辺は読み手で気をつけるポイントになりそう。
Q. ECSでKong GatewayのDPを動かす時の注意点を教えてください。。
回答は以下となった。
提供された知識ソースには「ECS 上で **Kong Gateway の Data Plane (DP)** を動かす場合の専用ガイド」はなく、ECS 固有のベストプラクティスは明示されていません。以下は、ソースにある「DP の一般的な動作・ハイブリッド構成・ECS でよく起きる問題」から読み取れる範囲での注意点です。
1. ハイブリッド構成と DP の基本動作
Kong Gateway の DP は、Control Plane (CP) から設定を受け取ってプロキシ処理のみを行うノードです。Konnect でも自前ハイブリッドでも、DP は CP へ mTLS で接続し、設定を受信してローカルにキャッシュします。[CP–DP communication]
- DP は CP から受け取った設定をメモリにロードしつつ、
dbless.lmdbとしてローカルにキャッシュします。[CP–DP communication]- CP との通信が切れても、最後に受け取った設定でプロキシ処理を継続できます。[CP–DP communication]
ECS 上で DP を動かす場合も、この前提（CP との mTLS 通信・ローカルキャッシュ）は同じです。
2. DP の起動順序と設定キャッシュ
DP の起動時は、以下の順序で設定を読み込みます。[CP–DP communication]
kong_prefix（デフォルト/usr/local/kong）配下のdbless.lmdbがあればそれを使用- それが無く
declarative_configが設定されていれば、そのファイルを使用- どちらも無ければ空設定で起動（全リクエスト 404）
- いずれの場合も CP から最新設定を取得し、成功すれば
dbless.lmdbに保存ECS タスクのライフサイクルが短い場合でも、CP から設定を取得できるネットワーク経路と証明書設定を確実に行うことが重要です。
3. ハイブリッドモードでの DP 設定
自前ハイブリッド構成で ECS 上に DP を置く場合、DP 側は
role = data_planeとし、DB を持たず CP に接続する設定にします。[Deploy DP]# CP のアドレスを環境変数などで渡す例 export CONTROL_PLANE_IP="1.2.3.4" # kong.conf（DP 側）の例 echo " role = data_plane database = off cluster_control_plane = $CONTROL_PLANE_IP:8005 cluster_telemetry_endpoint = $CONTROL_PLANE_IP:8006 lua_ssl_trusted_certificate = /etc/kong/certs/tls.crt cluster_cert = /etc/kong/certs/tls.crt cluster_cert_key = /etc/kong/certs/tls.key " | sudo tee /etc/kong/kong.conf
- CP と同一の証明書 (
tls.crt/tls.key) を DP に配置する必要があります（ピン留め証明書認証）。[Deploy DP]
4. ECS 固有の注意点：Graceful Shutdown
ECS で Kong（Gateway イメージ）を動かす際に、タスク停止時にグレースフルシャットダウンが効かず、処理中リクエストが失敗するという既知の問題があります。[Graceful shutdown on ECS]
- ECS は Docker の
STOPSIGNALを尊重せず、コンテナ内の PID 1 に直接SIGTERMを送ります。- Kong のマスタープロセスが PID 1 の場合、
SIGTERMを受けて即時終了し、ワーカーがリクエスト処理を完了する前に落ちてしまいます。対策として、PID 1 を Kong 以外のプロセス（例:
dumb-init）に置き換え、SIGTERMをSIGQUITに変換して Kong に渡す構成が推奨されています。[Graceful shutdown on ECS]Dockerfile 例（抜粋）:
FROM kong/kong-gateway:latest-ubuntu USER root # dumb-init を追加 ADD https://github.com/Yelp/dumb-init/releases/download/v1.2.5/dumb-init_1.2.5_x86_64 /usr/local/bin/dumb-init RUN chmod +x /usr/local/bin/dumb-init USER kong # ENTRYPOINT を dumb-init 経由にする ENTRYPOINT ["/usr/local/bin/dumb-init", "--rewrite", "15:3", "--"] CMD ["/tini-wrapper.sh"]
tini-wrapper.sh例（抜粋）:#!/usr/bin/env bash set -Eeo pipefail graceful_shutdown() { echo "SIGTERM received, sending SIGQUIT to Kong..." local kong_pid=$(pgrep -f "/usr/local/openresty/nginx/sbin/nginx") kill -SIGQUIT "$kong_pid" } trap 'graceful_shutdown' SIGTERM exec /entrypoint.sh kong docker-startこの構成により、ECS からの
SIGTERM→dumb-init→tini-wrapper.sh→ Kong マスタープロセスへのSIGQUITという流れになり、ワーカーが処理中リクエストを完了してから終了できるようになります。[Graceful shutdown on ECS]
5. まとめ
知識ソースから読み取れる、ECS 上で Kong Gateway DP を動かす際の主な注意点は次の通りです。
- DP は CP からの設定配布とローカルキャッシュ（
dbless.lmdb）に依存するため、CP への mTLS 通信と証明書配置を正しく行う。[CP–DP communication; Deploy DP]- ハイブリッドモードでは
role = data_plane/database = offとし、cluster_control_planeなどを正しく設定する。[Deploy DP]- ECS では
STOPSIGNALが効かないため、そのままだとグレースフルシャットダウンが動作せず、dumb-initなどで PID 1 をラップしてSIGTERM→SIGQUIT変換を行う構成にする。[Graceful shutdown on ECS]それ以外の「ECS 固有の DP 設計・スケーリング・ネットワーク構成」などについては、提供されたソースには情報がありません。もし Konnect の Dedicated Cloud Gateways や Serverless Gateways との比較・使い分けなどを知りたい場合は、その観点を教えてください。
Graceful Shutdownの問題をナレッジベースから引っ張ってくる点がよく出来ている。
ただ、1-3の回答はノイズに近く、多くの人にとっては不要な情報な気がするので、この辺も読み手の知識がある程度あった方が良さそう。
まとめ
Ask AIはKongのドキュメントをベースとして回答してくれるため、Kongに関する質問に関してはかなり精度が高く取得できる。
また、ハルシネーション対策のようなものがあるようで、ソースがない情報については回答しない点でもかなり信頼できそうだ。
ただ、ナレッジベースなど一部古い情報をAIが引っ張れるようになっていて、回答に古い情報が含まれる可能性がある点、また不必要な情報を返すことがある点は利用する際に注意した方が良さそうだ。
参考意見としてはかなり強力だが、確実な情報が必要な場合はサポートへの問い合わせなども組み合わせて確認するとよいと思う。