トークン破産、情報漏えい、LLM実行遅延――全部「AI Gateway」に任せよう　無料枠で学ぶAIエージェント開発、運用の新常識：クラウドサービスだけじゃない！　ローカルPCやサーバ、Kubernetesで生成AI（10）

気軽に試せるラップトップ環境で、チャットbotを提供するオールインワンの生成AI環境構築から始め、Kubernetesを活用した本格的なGPUクラスタの構築やモデルのファインチューニングまで解説する本連載。今回は、LLMアプリケーション開発や運用で避けて通れない課題を、AI Gatewayで解決するアプローチを解説します。

» 2026年01月22日 05時00分公開

[川村修平, 村田一平, 榎田皓太, 岡本隆史，Kong／NTTデータ／NTTデータグループ]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

※川村、村田はKong所属。榎田はNTTデータ所属。岡本はNTTデータグループ所属。

　Alphabetが発表した2025年第3四半期決算によると、「Gemini アプリ」の月間アクティブユーザー数が6億5000万人に到達（前四半期比3倍）するなど、生成AI（人工知能）の利用が急速に広がっていることが明らかとなっています。

　LLM（大規模言語モデル）を活用したAIエージェントも注目が集まっており、生産性を大きく向上させる技術として、企業における導入検討が盛んに進んでいます。

　しかし、生成AIを活用したアプリケーション（以下、LLMアプリケーション〈*〉）の開発、運用には特有の課題が存在し、それらを解決するためのアプローチも求められています。

　本連載第9回では、こうした課題を解決する「AI Gateway」の概要や、AI Gatewayを構築できるOSS（オープンソースソフトウェア）をはじめとする製品動向まで網羅的に解説しました。

　本稿は、そこから一歩踏み込んで、AI Gatewayの具体的な実装や挙動を深掘りしていきます。今回は、無償トライアルでAI Gatewayを試すことができる「Kong Konnect」を題材に、実装までの具体例とともに解説します。

*本稿では、生成AIの中でも特にLLMを活用したAIエージェントのようなアプリケーションをLLMアプリケーションと総称し、解説します。

LLMアプリケーションの特徴

　AIエージェントに代表されるLLMアプリケーションの特徴は大きく分けて3つあります。

アプリケーションの品質がLLMの品質に強く依存する

　ここでいう「品質」はさまざまな意味を含みますが、ここではサービス提供に支障がない（使えなくなってしまうことなどがない）ことと、出力がユーザーの満足度を満たしていることとして扱います。

　あるLLMプロバイダーのAPIを利用してサービスを提供する場合、プロバイダー側のAPIサービスがダウンすると影響を受け、アプリケーションのLLM関連機能は使えなくなってしまいます。

　アプリケーションの中に一部組み込まれている場合もあれば、コアの機能として据えている場合もあります。依存度はさまざまですが、コア機能として活用していればいるほど、LLMプロバイダーが提供するAPIのサービス品質に依存することになります。

LLM APIが利用できないとアプリケーションのLLM関連機能が利用できない

　「出力結果がユーザーの満足度を満たせるかどうか」という観点もLLMの品質に大きく依存します。ここでいう満足度とは、出力自体の妥当性や出力までにかかる時間を指します。

　最終的な出力は、その過程でさまざまなツールと連携されコンテキストが拡張されることもありますが、どのツールをどのような順番で実行すればよいか？　という判断はLLMの推論能力に依存しますし、自然言語の出力に関してもLLMの推論能力に依存します。出力までにかかる時間はLLMのトークンスループットに依存します。

ユーザーの満足度がLLMの品質に依存する

出力や処理効率を向上させるには、複数のコンポーネントを組み合わせる必要がある

　LLMは、膨大な学習データから作成された自然言語処理モデルであるため、学習データに含まれていないような内容について正しく出力できない可能性があります。

　学習データに含まれていないような新しい情報や、社内固有の情報をLLMに問い合わせても期待通りの回答が返ってこないといったケースです。皆さんも経験したことがあるでしょう。

　ユーザーにとって満足度が低下するような回答の発生確率を下げるために、知識を補完するための検索システムとひも付けたりすることが、LLMアプリケーション構築ではよくあります。

　また自律的にアクションするため、MCP（Model Context Protocol）などのプロトコルを通じたツール連携や、類似した入力ならキャッシュレイヤーから返却することで、処理効率を向上させる実装もあります。

　このように、LLMアプリケーションは単にLLMのAPIを使うだけではなく、裏側で複数のコンポーネントを組み合わせることで価値を提供しています。

LLMのアプリケーションはさまざまなコンポーネントと組み合わさって構成されている

通常のアプリケーションのセキュリティ対策に加えて、LLM固有のリスクを考慮する必要がある

　LLMを活用したアプリケーションは、通常のアプリケーションで知られるセキュリティ対策に加えてLLM固有の考慮事項が生じます。

　考慮事項は「入力面」と「出力面」で分けて考えられます。

　まず、入力面については個人情報などに相当する機密情報を渡さないようにするために、含まれていたらブロックしたり別の文字列で埋めたりする必要があります。それ以外にも、プロンプトに悪意のある表現を入力し、意図しない動作をさせるようなプロンプトインジェクションを防ぐような機構も必要です。

　出力面については、公序良俗に反する内容を出力してしまうとサービス自体の評判を下げてしまうことも考えられるため、未然に防ぐような工夫が必要です。

LLMの出力で考慮すべき事項

LLMアプリケーションの開発、運用における課題の整理

　こうした特徴を持つLLMアプリケーションを開発、運用する上では、以下のような課題と向き合う必要があります。

場合によっては、クライアントアプリケーションで複数のAPI Keyを管理する必要がある
アプリケーションとプロンプトのライフサイクルが一致しない
要件に応じて複数のLLM APIを動的に切り替える必要がある
LLMの入出力に機密情報や公序良俗に反することが含まれないようにする必要がある
複数のコンポーネントを活用するため、実装が複雑になる
制限なしに使用され、必要以上にコスト高になってしまうことを防ぐ必要がある
作成したアプリケーションの活用状況やボトルネックを監視する必要がある

場合によっては、クライアントアプリケーションで複数のAPI Keyを管理する必要がある

　特にアプリケーションのコア機能にLLMを活用する場合、LLMが利用できないことはクリティカルな障害に直結するため、失敗時に別のLLMプロバイダーのAPIを呼び出すような構成を検討する必要があります。

　タスクの難易度に応じて利用するLLMを使い分ける場合も、クライアントアプリケーション側で複数のAPI Keyを管理する必要があります。

　万が一、API Keyが流出した場合は、API Keyを適切にローテーションし、再起動などのオペレーションをする必要があります。複数のアプリケーションで共通のAPI Keyを利用している場合は、そのアプリケーション分、同様のオペレーションを実施する必要があり、運用負荷がとても高くなるという課題が生じます。

アプリケーションとプロンプトのライフサイクルが一致しない

　LLMアプリケーションのロジックそのものはプロンプトに大きく依存します。

　そのため、アプリケーションのコードを修正する必要はないものの、運用上、プロンプトだけを変更したいケースがあります。その際に、アプリケーションのコードの中にプロンプトが直接埋め込まれていると、プロンプトを差し替えるためにアプリケーションの再ビルド／デプロイが必要になってしまい、リリースまでに要する時間が長くなってしまうという課題が生じます。

要件に応じて複数のLLM APIを動的に切り替える必要がある

　先述したように、あるLLMプロバイダーが利用できなくなった場合に備えて、代替となるLLMプロバイダーを用意する必要があります。またコストや精度の観点で、タスクごとにLLMを使い分けるというケースもあり、クライアント側の実装が煩雑になるという課題もあります。

LLMの入出力に機密情報や公序良俗に反することが含まれないようにする必要がある

　外部にサービス公開している場合は特に、LLMの入出力には気を配る必要があります。個人情報に相当する機密情報を入力させないようにすること、出力に公序良俗に反する表現が含まれないようにすることです。LLMアプリケーションを実装する際には、これらのことを踏まえて実装に取り組む必要があります。

複数のコンポーネントを活用するため、実装が複雑になる

　前述した通り、LLMの知識は学習データ時点のスナップショットとなります。これを拡張するために知識データと組み合わせるRAG（Retrieval-Augmented Generation：検索拡張生成）や振る舞いを拡張するためのツールなどと連携する実装をする必要があり、実装が煩雑化する傾向にあります。

　LLMのAPIはその特性上、応答に時間がかかる傾向にあります。そのため、似たような入力であれば最も時間がかかるLLMのAPI呼び出しを省略し、キャッシュから返すような工夫も必要です。

　このようなことを考慮すると、クライアントアプリケーション側でそれらのコンポーネントと連携するための実装が必要となり、実装が複雑化するという課題があります。

制限なしに使用され、必要以上にコスト高になってしまうことを防ぐ必要がある

　LLMプロバイダーが提供しているAPIを利用する場合、その利用料金はトークン数に応じた従量課金となります。そのため、無制限に使わせてしまうとLLMのAPI利用量によっては当初予定していたランニングコストを大幅に超過してしまう可能性があります。

　従って、ユーザー体験を損なわない範囲で使い過ぎを防止するために、一定期間で利用可能なトークン数を制限するなどの工夫も必要です。

作成したアプリケーションの活用状況やボトルネックを監視する必要がある

　LLMアプリケーションは、構成が複雑化しやすいという特性上、最終的な出力に至るまでにどのようなステップだったか確認できると、ボトルネックの特定などで役に立ちます。

　構築したアプリケーションがどの程度利用されているのかを把握するためのトークン使用量など、メトリクス取得も重要な観点です。通常のアプリケーションでもいわゆるオブザーバビリティの領域は重要ですが、LLMアプリケーションについても同様に重要な観点と言えるでしょう。

AI Gatewayによるアプローチ

　ここまでLLMアプリケーションの開発、運用における課題を整理してきました。これらの課題と向き合う上で、2つのアプローチが存在します。

ライブラリを利用してクライアントアプリケーション側で実装し、課題と向き合う
AI Gatewayを利用し、Gatewayレイヤーに実装を寄せる

　それぞれのアプローチを簡単にまとめたものが以下の表になります。


	ライブラリを利用するアプローチ	AI Gatewayを用いるアプローチ
方法	アプリケーションの内部で制御する	アプリケーションの外部で制御する
長所	・導入が容易にできる・柔軟性やカスタマイズ性に優れる	・プログラミング言語に依存することなく導入ができる・複数環境に対して一元的な制御ができる・個別ライブラリについて学習する必要がなく、Gatewayの学習コストで完結する
短所	・特定の言語（多くは、PythonやTypeScript）に依存する・アプリケーションごとにライブラリを用いた実装が必要になる・各開発者がライブラリの使用方法などを理解する必要がある	・独立したコンポーネントの運用が必要になる・柔軟性やカスタマイズ性に欠ける
適した用途	・単一のアプリケーションに対して実装する・複雑なロジックの実装が必要な場合	・複数のアプリケーションに対して実装する・中央集権的にセキュリティ管理などが必要な場合

　分かりやすい対比形式でまとめていますが、上記のアプローチは排他的ではなく相互補完しながら利用することも可能です。

　AI Gatewayを利用するアプローチにおいて重要なのは、LLM APIやMCPなどの利用に伴う通信が、全てAI Gateway経由になるという点です。

LLMアプリケーションに関わる全ての通信はAIGatewayを通過する

　そのため、リクエスト／レスポンスヘッダやボディーの参照や変換で実現が可能なAPI Keyの挿入、プロンプトの補完、入出力のフィルタリングなどはAI Gateway側で一元的に機能提供が可能です。

　またAI Gateway側でLLMアプリケーションの通信を一元的に管理することで、トークンの使用量の監視やレート制限などを実装できます。AI Gateway側で各種コンポーネントとの連携が実装されている場合は、キャッシュサーバとの連携やRAGで利用する検索システムとの連携もAI Gatewayで実装できます。

Kong AI GatewayによるLLM課題へのアプローチ

　以降では、AI Gatewayの実装の一つである「Kong AI Gateway」を用いた具体的なアプローチ例を紹介します。本稿では、Kongが提供するSaaS環境である「Kong Konnect」の無償トライアルを利用して、実装のアプローチを解説します。

　以下は、典型的な課題とKong AI Gatewayでの解決策の対応表です。幾つかの代表的な課題に対して、Kong AI Gatewayでの解決策を実際の設定例を交えて紹介します。


課題	解決策	利用プラグイン
場合によっては、クライアントアプリケーションで複数のAPI Keyを管理する必要がある	AI Gatewayの通過時にAPI Keyを統一的に設定する	AI Proxy、AI Proxy Advanced
アプリケーションとプロンプトのライフサイクルが一致しない	AI Gatewayでプロンプトを管理し、通過時に設定する	AI Prompt Decorator、AI Prompt Template
要件に応じて複数のLLM APIを動的に切り替える必要がある	AI Gatewayのルーティング機能で動的に切り替える	AI Proxy Advanced
LLMの入出力に機密情報や公序良俗に反することが含まれないようにする必要がある	AI Gatewayを通過する入出力に対して統一的にフィルタリング処理をする	AI AWS Guardrails、AI Azure Content Safety、AI GCP Armor、AI PII Sanitizer、AI Prompt Guard、AI Semantic Prompt Guard、AI Semantic Response Guard
複数のコンポーネントを活用するため、実装が複雑になる	AI Gatewayが有している連携機能を利用する	AI RAG Injector、AI Semantic Cache、AI Prompt Compressor
制限なしに使用され、必要以上にコスト高になってしまうことを防ぐ必要がある	AI Gateway でレート制限を設定する	AI Rate Limiting Advanced
作成したアプリケーションの活用状況やボトルネックを監視する必要がある	AI Gatewayの監視機能を利用する	OpenTelemetry、Prometheus

Kong Konnectの無償トライアル登録

　まずは、無償トライアルの登録サイトへアクセスします。

サインアップ画面

　サインアップに必要な情報を選択、もしくは入力し、サインアップの手続きを進めます。

Organization Nameを決める

　ここでは、Organization Nameを決めます。Organization NameはKong Konnect上での組織名となります。後ほど変更できるので任意の名前を入力し、Nextをクリックします。簡単なアンケートに回答後、サインアップが完了すると、Kong Konnectのダッシュボードへ遷移します。

Kong Konnectのダッシュボード

複数のLLM APIを要件によって動的に切り替える

　先述したように、LLMを使いこなす上で、複数のLLMを要件によって動的に切り替えるケースが出てきます。例えば以下のようなケースが考えられます。

LLMによって回答がばらつくため、回答を比較したい
モデルの強みに合わせてLLMを選択したい
LLMプロバイダーがダウンした場合に備えて冗長化したい

　このようなユースケースはKongのAI Gatewayを使うと簡単に実現できます。設定方法は以下が用意されています。

Kong KonnectのWeb UI上のAI Gatewayのガイダンスから設定する
Kong KonnectのWeb UI上の通常の設定画面から設定する
Kong KonnectにAPIを発行して設定する
「decK」というCLIツールを使って設定する

　ここでは一番設定が簡単な、AI GatewayのガイダンスからOpenAIとCohereを使った冗長構成を設定してみます。

　Kong Konnectにログインし、左サイドバーに表示されるAI Gatewayを選択し、New AI Gateway > Start from scratchと選択します。

AI Gateway作成画面

　なお、「Start with demo」を選んだ場合はData Planeが自動でプロビジョニングされてパスなどの設定も自動で行われます。実用的ではありませんが、ちょっとした動作確認を試したい方はそちらを試してみてもいいかもしれません。

　Start from scratchを選択後、以下を設定します。その他はデフォルト（既定）のままとします。

General information
- AI Gateway name：任意の名前を設定します。ここではkong-demoとします
API Gateway
- Select gateway：AI Gatewayを展開するControl Plane（管理グループのようなもの）を選択します。Trial版であればserverless-defaultというControl Planeが最初に用意されているので、これを選択します
Route
- Path：Data Plane（プロキシノード）のどのパスにアクセスするとLLMプロバイダーに転送するかを設定します。ここでは/aiとします

　上記設定をAPI Gatewayの基本設定として保存します。ただ、LLMのプロバイダー設定などは行っていません。これについては設定保存後の次の画面で行います。

　保存後は以下の画面に遷移しますが、ここでは右下のConnect LLMを選択します。

Connect LLM選択画面

　LLMプロバイダーの選択画面が表示されます。ここではまずCohereを登録するために以下を設定します。

LLM Provider：Cohere
Enter a model：command-a-03-2025
API Key：（CohereのAPI Keyを入力）

　Cohereは無料プランでもAPI Keyが発行できるので、まだ持っていない場合は、こちらからサインアップしてAPI Keyを取得してください。

　なお、API KeyをクライアントからのAPIリクエストに含めて送信する場合、ここでの保存は不要です。セキュリティ要件などで保存が許可されていない場合は、入力せずに進めてください。

　保存すると次にプラグインの追加画面になりますが、このタイミングでは設定できるプラグインがかなり絞られているため、これはスキップしてTest your setupを選択します。以下のようにテストのためにcurlコマンドを使った確認方法が提示されます。

テストコマンド表示画面

　テスト内容はAIに対して「How does Kong AI Gateway work?」とKong Gatewayがどのように動作するかを尋ねる内容となっています。

　またアクセス先は「https://kong-05dced184busfugnm.kongcloud.dev/ai」のようなURLになっているはずです。

　ホスト名についてはトライアル版であれば動的に用意されたData Plane（プロキシノード）のホスト名が設定されており、先ほど指定したパス（/ai）が設定されています。

　curlコマンドをコピーして端末に貼り付けて実行すると、以下のようなAIからのレスポンスが取得できるはずです。

{"object":"chat.completion","usage":{"completion_tokens":732,"total_tokens":739,"prompt_tokens":7},"model":"command-a-03-2025","id":"da391887-0484-453c-af49-80151fe046e8","choices":[{"message":{"content":"Kong AI Gateway is an extension of the Kong API Gateway that integrates artificial intelligence (AI) and machine learning (ML) capabilities to enhance API management,
：（省略）

　またKonnectの画面の方ではLLMプロバイダーとのやりとりで発生したトークン数やレイテンシなどの情報も確認できるでしょう。

Analyticsの画面

　ここまででいったんLLMプロバイダーであるCohereを使った設定が完了しました。続いて、別のLLMプロバイダーとしてOpenAIを追加して冗長化してみます。

　作成したAI Gatewayの画面に戻り、左サイドバーにあるLoad balancingを選択します。

Load balancing選択画面

　ここでは先ほど設定したパスにアクセスした際に転送するLLMプロバイダーの一覧が表示されます。現時点では先ほど追加したCohereのみが表示されているはずです。

　ここでConnect LLMを選択します。LLMの追加画面が表示されるので、今度はOpenAIを追加するため、以下のように設定します。

General information
- LLM Provider：OpenAI
- Route type：llm/v1/chat
- Specific model
  - Enter a model：gpt-4o-mini
Authentication
- Authentication from gateway to LLM
- Provided by the AI gateway
  - API Key：（OpenAIのAPI Keyを入力）

　OpenAIのAPI KeyはOpenAI Platformから取得できます。費用がかかるため注意してください。

　設定して保存すると、LLMプロバイダーの一覧にOpenAIが追加されているはずです。

Load balancing設定後

　なお、画面の右上を確認すると分散アルゴリズムが選択できるようになっています。

　デフォルトではラウンドロビンが選択されているため、それぞれのLLMプロバイダーに順番にリクエストが分散されます。この状態で先ほどと同じcurlコマンドを何度か実行してみます。

　実行すると以下のようにChatGPTとCohereのそれぞれに分散してアクセスすることが分かります。

{
  "id": "chatcmpl-CYkkNOYArCBFffntGI2PjMVKX4CfC",
  "object": "chat.completion",
  "created": 1762398883,
  "model": "gpt-4o-mini-2024-07-18",
  "choices": [
：（省略）

OpenAIへのアクセス結果

{"object":"chat.completion","usage":{"completion_tokens":868,"total_tokens":875,"prompt_tokens":7},"model":"command-a-03-2025",
：（省略）

Cohereへのアクセス結果

今回検証した際、Load balancing設定後にCohereのみ必ずタイムアウトする事象がありました。もし同様の現象に遭遇した場合はCohereを一度削除して再作成してみてください。

　以上により、LLMの冗長化が実装できました。以下のケースについても同様の手順でAI Gateway設定を目的別に作成することで対応可能です。

LLMによって回答がばらつくため、回答を比較したい
モデルの強みに合わせてLLMを選択したい

　作成したAI Gatewayへのパスについては、curlコマンドで確認しましたが、AIエージェント経由でも呼び出せるため、LLMアプリケーションで課題となる柔軟なLLM呼び出しをAI Gatewayを用いることで容易に実現できるようになります。

　なお、後ほどの検証をスムーズに行うため、動作が確認できたらCohereを削除し、OpenAIのみの状態に戻しておいてください。また、以降の動作確認でも同じエンドポイントに対してcurlコマンドを実行するため、以下のようにData Planeのホスト名を環境変数に設定しておきます。

export PROXY_HOST="kong-05dced184busfugnm.kongcloud.dev"

トークン数によるレート制限

　こちらも先述したように、AIエージェントの活用によりLLMプロバイダーへの問い合わせが増加すると、LLMアプリケーションを提供する事業者からすれば「AIへのAPIを使い過ぎて想定外の金額が請求されないか」という不安が出てきます。

　特に、エージェントループと呼ばれるエージェント内でのアクションと思考の繰り返しの実装を誤ると、意図せず大量のトークンを消費してしまうリスクがあります。

　ここではこれをAI Rate Limiting Advanced Pluginを用いて抑止してみます。

　この設定は、AI Gatewayの設定画面からは設定できず、AI Gatewayによって作成された Serviceにプラグインを追加することで設定します。

　左サイドバーのAPI Gatewayを選択後、右ペインのserverless-defaultを選択すると、API Gatewayの設定画面に遷移します。

API Gatewayの設定画面

　左サイドバーからGateway Servicesを選択し、Gateway Servicesの一覧の中にAI Gatewayで自動生成されたService（AIManagerModelService\_...）があるので選択します。

　詳細画面に遷移したら、PluginsタブにあるNew pluginを選択します。

プラグイン追加画面

　プラグインの選択画面で「ai rate」と入力すると「AI Rate Limiting Advanced」というプラグインが表示されるはずです。プラグインの設定項目は多岐にわたり、必須項目もありますが、ほとんどはデフォルト値のままで動作するので、ここでは以下の項目のみ設定します。

Llm Providers：
- Limit：トークンの上限数を指定。ここでは、500とします
- Name：プロバイダー名を指定。ここでは、openaiとします
- Window Size：上限数をカウントする期間を秒数で指定。ここでは、30とします

プラグインの設定値

　なお、指定できるトークン種別としては、入力トークン（prompt_tokens）、出力トークン（completion_tokens）、合計トークン（total_tokens）に加えてコスト（cost）の4種類があります。ここでは特に指定せず、デフォルトの合計トークン（total_tokens）のままとしています。

　設定後、画面下部にあるSaveを選択して保存します。以上で設定は終了です。

　次に動作確認をしてみます。

　LLMプロバイダーに対してトークン量を指定してプロンプトを送信し、500トークンを超えた場合にエラーになることを確認します。最初にトークン量の少ない問い合わせを実行し、30秒以内にトークン量の多い問い合わせを2回実行します。

curl -i -X POST ${PROXY_HOST}/ai \
-H 'Content-Type: application/json' \
-d '{
  "messages": [
    {
      "role": "user",
      "content": "今日の日付を教えて"
    }
  ]
}'

トークン量の少ない問い合わせ

curl -i -X POST ${PROXY_HOST}/ai \
-H 'Content-Type: application/json' \
-d '{
  "messages": [
    {
      "role": "user",
      "content": "Kong Gatewayで人気のプラグインを3つ挙げ、それぞれ詳細を説明して"
    }
  ]
}'

トークン量の多い問い合わせ

　なお、curlコマンドのオプションに-iを追加することでレスポンスヘッダを確認できます。AI Rate Limiting Advancedプラグインが有効化されている場合、トークンの残量などがヘッダから確認できるので、これも後ほど確認します。

　1回目に実行したトークン量の少ない問い合わせの結果は以下となりました。

{
  "id": "chatcmpl-CcoWCy4HxyMGq9egOICKaZakDmZtO",
  "object": "chat.completion",
  "created": 1763366692,
  "model": "gpt-4o-mini-2024-07-18",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "今日の日付は2023年10月2日です。",
        "refusal": null,
        "annotations": []
      },
      "logprobs": null,
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 13,
    "completion_tokens": 13,
    "total_tokens": 26,
　：（省略）

　OpenAIのレスポンスのtotal_tokensから合計のトークン量が26であることが分かります。レスポンスヘッダを見てみると以下のヘッダがあることが分かります。

x-ai-ratelimit-limit-30-openai: 500
x-ai-ratelimit-remaining-30-openai: 500

　x-ai-ratelimit-limit-30-openaiは30秒当たりの上限が500であることを示しており、x-ai-ratelimit-remaining-30-openaiは残量が500であることを示しています。このプラグインはレスポンスを受け取った後にトークン使用量をカウントするため、レスポンスヘッダにはトークン数は計上されておらず、残トークン数は500のままとなっています。

　2回目に実行したトークン量の多い問い合わせの結果は以下となりました。

  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Kong Gatewayは
        ・・・（省略）・・・
  "usage": {
    "prompt_tokens": 30,
    "completion_tokens": 539,
    "total_tokens": 569,
    :（省略）

　OpenAIのレスポンスからはトークン量が569であることが分かります。レスポンスヘッダを見てみると、以下のヘッダがあることが分かります。

x-ai-ratelimit-limit-30-openai: 500
x-ai-ratelimit-remaining-30-openai: 474

　トークンの残量が474となっており、先ほどの26トークンを引いた値が残量となっています。569トークンを消費することで、残量がゼロとなり次の問い合わせは失敗するはずです。

　3回目に実行したトークン量の多い問い合わせの結果は以下となりました。

HTTP/1.1 429 Too Many Requests
：（省略）
{"message":"AI token rate limit exceeded for provider(s): openai"}

　レスポンスコードが429となっており、AI Rate Limiting Advanced Pluginによってトークン上限を超えたためにリクエストが拒否されたことが分かります。

　またレスポンスヘッダは以下となっています。

x-ai-ratelimit-limit-30-openai: 500
x-ai-ratelimit-remaining-30-openai: 0
x-ai-ratelimit-retry-after: 17
x-ai-ratelimit-reset: 17
x-ai-ratelimit-reset-30-openai: 17
x-ai-ratelimit-retry-after-30-openai: 17

　x-ai-ratelimit-remaining-30-openaiからも残量が0であることが分かります。またx-ai-ratelimit-retry-afterやx-ai-ratelimit-resetなどのヘッダからは、あと17秒でリセットされることが分かります。

　以上により、AI Rate Limiting Advanced Pluginを用いることでLLMプロバイダーへのトークン消費量を制限できることが確認できました。

LLM固有のセキュリティ要件への対応

　先述した通り、LLMアプリケーションには、通常のアプリケーションのセキュリティ対策に加えて、LLM固有のリスクを考慮する必要があります。

　Kong AI Gatewayでは、LLM固有のセキュリティ要件に対応するための以下のような機能をプラグインとして提供しています。


プラグイン	概要
AI AWS Guardrails	「AWS Bedrock Guardrails」を利用した入出力の保護
AI Azure Content Safety	「Azure AI Content Safety」を利用した入出力の保護
AI GCP Armor	「Google Cloud Model Armor」を利用した入出力の保護
AI PII Sanitizer	Kong提供のPII Service（Docker Container）を利用したPII（氏名や電話番号などの個人識別情報）の入出力保護
AI Prompt Guard	正規表現を利用した入力プロンプトの保護
AI Semantic Prompt Guard	埋め込みを利用した入力プロンプトの保護
AI Semantic Response Guard	埋め込みを利用した出力の保護

　今回は、この中でも一例としてAI Semantic Prompt Guardを利用した入力プロンプトの保護について紹介します。作成したAI Gatewayの画面に戻り、左サイドバーのGuardrailsを選択します。

Kong Konnect: Guardrails

　ここでは、AI Gatewayに対して設定されているGuardrailsの一覧が表示されます。Add Guardrailを選択後、Guardrailsの追加画面にて、入力プロンプトを保護するためのAI Semantic Prompt Guardを追加します。

General information
- Start from scratchを選択します
Guardrail
- Semanticを選択します
- Allow：Kong Gatewayに関する質問
VectorDB
- Choose Vector Database Driver：redis
- VectorDB Dimensions：1536
- Caching Similarity Threshold：1
- Choose VectorDB Distance Metric：cosine
- Configure Redis Vector
  - Host：（Redisのホスト名を入力）
  - Port：6379
Embeddings
- LLM Provider：OpenAI
- Model Name：text-embedding-3-small
- API Key：（OpenAIのAPI Keyを入力）

AI Semantic Prompt Guard の設定

　ここで、Allowに設定した「Kong Gatewayに関する質問」というコンテンツと類似した内容でテストしてみます。

curl https://${PROXY_HOST}/ai -H 'Content-Type: application/json' -d '{
  "messages": [
    {
      "role": "user",
      "content": "How does Kong AI Gateway work?"
    }
  ]
}'

　実行結果は以下のようになりました（※LLMによる出力例であり、実際のKong AI Gatewayの機能とは異なります）。

{
  "id": "07743973-c918-4d2b-a147-24feef6b6e75",
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "Kong AI Gateway is an extension of the Kong API Gateway that integrates artificial intelligence (AI) and machine learning (ML) capabilities to enhance API management, security, and performance. It leverages AI to automate and optimize various aspects of API traffic, including routing, security, analytics, and personalization. Here’s how Kong AI Gateway works:\n\n### 1. **AI-Powered Traffic Management**\n   - **Intelligent Routing**: Kong AI Gateway uses machine learning models to analyze traffic patterns and make real-time routing decisions. It can dynamically route requests based on factors like latency, load, or user behavior, ensuring optimal performance.\n   - **Load Balancing**: AI algorithms optimize load balancing by predicting traffic spikes and distributing requests across available resources efficiently.\n\n### 2. **Enhanced Security**\n   - **Anomaly Detection**: The gateway employs AI to detect unusual patterns or behaviors in API traffic, such as DDoS attacks, API abuse, or unauthorized access attempts. It can automatically block or flag suspicious activity.\n   - **Bot Detection**: AI models identify and mitigate bot traffic, distinguishing between legitimate users and malicious bots.\n   - **Adaptive Authentication**: AI can adjust authentication requirements based on risk levels, such as requiring multi-factor authentication (MFA) for high-risk requests.\n\n### 3. **Real-Time Analytics and Insights**\n   - **Predictive Analytics**: Kong AI Gateway analyzes historical and real-time data to provide insights into API usage, performance bottlenecks, and potential issues.\n   - **Automated Reporting**: AI-driven reporting tools generate actionable insights, helping developers and operations teams optimize APIs and troubleshoot problems.\n\n### 4. **Personalization and User Experience**\n   - **Context-Aware Responses**: AI can tailor API responses based on user context, such as location, device type, or past behavior, improving the user experience.\n   - **Dynamic Content Delivery**: The gateway can use AI to optimize content delivery, ensuring faster and more relevant responses to end-users.\n\n### 5. **Automation and Self-Healing**\n   - **Auto-Scaling**: AI predicts traffic patterns and automatically scales resources up or down to meet demand, reducing costs and improving efficiency.\n   - **Self-Healing**: The gateway can detect and resolve issues like failed services or degraded performance without human intervention, ensuring high availability.\n\n### 6. **Integration with AI/ML Models**\n   - **Custom AI Plugins**: Kong AI Gateway allows users to integrate custom AI/ML models via plugins, enabling organizations to apply their own machine learning algorithms to API traffic.\n   - **Pre-Built AI Capabilities**: It comes with pre-built AI features for common use cases, such as rate limiting, threat detection, and traffic optimization.\n\n### 7. **Scalability and Flexibility**\n   - **Cloud-Native Architecture**: Kong AI Gateway is designed to work seamlessly in cloud-native environments, supporting microservices and containerized applications.\n   - **Hybrid and Multi-Cloud Support**: It can be deployed across hybrid and multi-cloud environments, providing consistent AI-driven capabilities regardless of the infrastructure.\n\n### 8. **Developer-Friendly**\n   - **Easy Configuration**: Kong’s declarative configuration model makes it simple to set up and manage AI-powered features.\n   - **Extensible Ecosystem**: The gateway supports a wide range of plugins and integrations, allowing developers to extend its functionality as needed.\n\n### Use Cases\n- **E-commerce**: Personalizing API responses for users, detecting fraudulent transactions, and optimizing checkout processes.\n- **Finance**: Enhancing security with real-time fraud detection and adaptive authentication.\n- **Healthcare**: Ensuring secure and efficient API communication for patient data while complying with regulations.\n\nBy combining Kong’s robust API gateway capabilities with AI-driven intelligence, Kong AI Gateway enables organizations to manage APIs more effectively, improve security, and deliver better user experiences."
      },
      "index": 0,
      "finish_reason": "stop"
    }
  ],
  "model": "command-a-03-2025",
  "object": "chat.completion",
  "usage": { "completion_tokens": 797, "total_tokens": 804, "prompt_tokens": 7 }
}

　また、Allowに設定した内容と類似しない内容でテストします。

curl -X POST https://${PROXY_HOST}/ai -H 'Content-Type: application/json' -d '{
  "messages": [
    {
      "role": "user",
      "content": "What is the highest mountain in Japan?"
    }
  ]
}'

{ "error": { "message": "bad request" } }

実行結果

　このように、AI Semantic Prompt Guardプラグインを利用することで、許可／拒否設定されたコンテンツに基づいて入力プロンプトを保護することができます。高度なコンテンツモデレーション（暴力的、差別的な表現など）を行いたい場合は、AI AWS Guardrails、AI Azure Content Safety、AI GCP Armorといったプラグインを利用できます。

　以降の工程のために、Guardrailの一覧画面に戻り、先ほど作成したGuardrailの名前をクリックしてGuardrailの設定を削除しておきます。

RAGやキャッシュによるユーザー体験の向上

　先述したように、RAGやキャッシュを利用しようと思った場合、通常はクライアントアプリケーション側でそれらのコンポーネントと連携するための実装が必要です。RAG向けのプラグインを使って回答精度の向上を図り、次にセマンティックキャッシュのためのプラグインを使って処理効率の向上を図る方法を解説します。

RAGによる回答精度の向上

　RAGとはデータベースなどの外部ソースから情報を取得し、LLMの回答精度を向上させる仕組みであり、社内のデータ活用などさまざまなシーンで利用されています。RAGを利用するにはベクトルデータベースへのデータ登録や、LLMへの問い合わせ時にRAGを利用するための実装が必要で、ハードルが高くなります。

　Kong AI Gatewayではベクトルデータベースとして「pgvector」（PostgreSQLのベクトル検索機能拡張）と「Redis」をサポートしています。今回はRedisを利用して検証していきます。

　なお、RedisはData Planeと接続できるのであればDockerやKubernetes、クラウドのマネージドサービスなど、どのような形態でも利用可能です。

　AI GatewayのサイドバーからRAGを選択後、Configure RAGを選択します。

RAG選択画面

　設定画面に遷移したら以下のように設定します（設定しない項目はデフォルト値を利用します）。

Vector DB：
- Vector Database Driver：redis
- VectorDB Dimensions：1536
- VectorDB Distance Metric：cosine
- Redis Vector：
  - Host：（Redisのホスト名を入力）
  - Port：6379
- Embeddings：
  - LLM Provider：OpenAI
  - Model Name：text-embedding-3-large
- Authentication：
  - API Key：（OpenAIのAPI Keyを入力）

　これでRAGが利用可能となりました。このプラグインがあることで、RAG利用時のフロー内のコンテキストデータの取得や挿入が自動化されます。

　続いてRAGを利用するためにデータベースにデータを登録します。今回はサンプルデータとして架空の漬物である「ゴリラ漬け」についての説明を記載したファイル（example.txt）を用意します。

ゴリラ漬けとは、神川県の郷土料理で、主にゴリラ（ニシキゴイ）を使った漬物の一種です。ゴリラは淡水魚であり、その肉質は白身で淡泊ですが、独特の風味があります。ゴリラ漬けは、ゴリラの身を薄く切り、塩や酢、砂糖などで味付けし、数日間漬け込むことで作られます。この料理は、ご飯のお供やお酒のつまみとして楽しまれています。また、地域によっては独自の調味料や漬け方が存在し、多様なバリエーションが楽しめる料理でもあります。

　このデータですが、無償トライアルでは登録方法に工夫が必要です（製品版の場合、こちらを参考にして登録できます）。今回は、別の方法でデータを登録します。

　以下のスクリプトをchunk_injector.pyという名前で保存します。

　なお、10行目の変数providerから16行目のcontent_fileまでは適宜書き換えてください。また利用時には以下に注意してください。

検証用のスクリプトのため、トークンをそのまま記載していますが、実際の運用では環境変数など安全に管理してください
OpenAIのAPIに接続するため、インターネット接続できる環境で実行する必要があります
OpenAIのAPIを利用するため費用が発生します

from langchain_text_splitters import RecursiveCharacterTextSplitter
import requests
from openai import OpenAI
import redis
import json
import time
import uuid
import numpy as np
provider = "openai"
model = "text-embedding-3-small"  #必要に応じて変更してください
namespace = "kong_rag_injector"   #必要に応じて変更してください
ai_token = "sk-proj-ni2l9..."     #自身のトークンに変更してください
redis_host = "myredis.info"       #自身の環境にあわせて変更してください
redis_port = 6379                 #必要に応じて変更してください
content_file = "/tmp/example.txt" #自身の環境にあわせて変更してください
headers = {
    "x-provider": provider,
    "x-model": model
}
client = OpenAI(
    api_key = ai_token,
    default_headers=headers
)
def setup_redis_simple():
    """Setup Redis connection for simple key-value storage."""
    r = redis.Redis(
        host=redis_host,
        port=redis_port,
        db=0,
        decode_responses=True,
        socket_connect_timeout=5,
        socket_timeout=5
    )
    try:
        r.ping()
        print("Successfully connected to Redis")
    except redis.ConnectionError as e:
        print(f"Failed to connect to Redis: {e}")
        return None
    except Exception as e:
        print(f"Error setting up Redis: {e}")
        return None
    return r
def load_content_file():
    """Load the content file from as a string."""
    try:
        with open(content_file, "r", encoding="utf-8") as file:
            content = file.read()
        return content
    except FileNotFoundError:
        print("Error: %s not found" % content_file)
        return None
    except Exception as e:
        print(f"Error reading file: {e}")
        return None
content = [load_content_file()]
print("Length of %s: %d" % (content_file, len(content[0])))
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=100)
docs = text_splitter.create_documents(content)
print("Injecting %d chunks..." % len(docs))
r = setup_redis_simple()
for index, doc in enumerate(docs):
    response = client.embeddings.create(
        input=doc.page_content,
        model=model
    )
    chunk_id = f"{namespace}:{uuid.uuid4()}"
    chunk = {
        "payload": doc.page_content,
        "vector": response.data[0].embedding
    }
    try:
        r.json().set(chunk_id, "$", chunk)
        print(f"Injected chunk {chunk_id} into Redis as JSON for vector search")
    except AttributeError:
        print("Redis JSON module not available. Falling back to simple storage.")
        r.set(chunk_id, json.dumps(chunk))
        print(f"Injected chunk {chunk_id} into Redis as string")

chunk_injector.py

　上記のスクリプトを実行するための環境を構築します。macOSの場合は以下のようになります。

python3 -m venv venv
source venv/bin/activate
pip install langchain-text-splitters langchain openai redis numpy requests

　スクリプトを実行します。

python chunk_injector.py

　実行するとおおよそ以下のような出力が得られ、Redis内にデータが格納されます。

/private/tmp/venv/lib/python3.14/site-packages/langchain_core/_api/deprecation.py:26: UserWarning: Core Pydantic V1 functionality isn't compatible with Python 3.14 or greater.
  from pydantic.v1.fields import FieldInfo as FieldInfoV1
Length of /tmp/example.txt: 206
Injecting 1 chunks...
Successfully connected to Redis
Injected chunk kong_rag_injector:b3980596-75ca-4aed-b0e7-5b21f4cd6a93 into Redis as JSON for vector search

　動作を確認する前に、RAGを利用するように設定を変更しておきます。AI GatewayのサイドバーからPrompt managementを選択し、Add decoratorを選択します。

　そこで以下のような設定を追加します。

General information：Start from scratch
Decorator：
- Position：append
- Role：system
- Content：ユーザーメッセージでは、質問の前に渡された情報のみを使用します。質問にデータが提供されていない場合は、「内部データは利用できません」と応答します

Prompt Decoratorの設定画面

　これにより、ユーザーメッセージの前にシステムメッセージが追加され、RAGで取得した情報のみを利用するようになります。設定後、以下のコマンドでAIに問い合わせを行います。

curl -X POST https://${PROXY_HOST}/ai \
-H 'Content-Type: application/json' \
-d '{
  "messages": [
    {
      "role": "user",
      "content": "ゴリラ漬けとはどういうものですか?"
    }
  ]
}'

　問い合わせ結果として以下の返答が返ってきました。

 "content": "ゴリラ漬けは、神川県の郷土料理で、ニシキゴイ（通称ゴリラ）を使った漬物の一種です。ゴリラは淡水魚で、その肉質は白身で淡泊ですが特有の風味があります。ゴリラ漬けは、魚の身を薄く切り、塩や酢、砂糖などで味付けし、数日間漬け込むことで作られます。この料理は、ご飯のお供やお酒のつまみとして楽しまれており、地域によって異なる調味料や漬け方が存在するため、多様なバリエーションがあります。",

　なお、念のためデータベースに登録していない質問も試してみます。

curl -X POST https://${PROXY_HOST}/ai \
-H 'Content-Type: application/json' \
-d '{
  "messages": [
    {
      "role": "user",
      "content": "ゴリラの塩辛とはどういうものですか?"
    }
  ]
}'

　試してみた結果、以下のように弾かれました。

"content": "内部データは利用できません。",

　これによりRAG Injectorプラグインが正常に動作していることが確認できました。なお、今回取り上げませんでしたが、AI Prompt Compressorというプラグインを利用することで、取得したチャンクをLLMに送信する前に圧縮することも可能です。これによりトークンやコストの削減、回答速度の向上、データ保護も期待できます。

セマンティックキャッシュによる回答速度の向上

　AI向けのキャッシュであるセマンティックキャッシュの設定方法を解説します。

　セマンティックキャッシュはクエリの完全一致だけでなく、意味やコンテキストの関連性も含めてキャッシュのHit/Miss判定をするため、データ取得を効率化できます。クエリの根底にある意図と、異なるクエリ間の意味的な類似性に基づいてリクエストを保存し、同様のリクエストが発生した際にキャッシュされた回答を再利用します。

　これにより、冗長な処理が削減され、応答時間が短縮され、ユーザーの意図に関連性のある回答が提供されるため、最終的にはシステム全体のパフォーマンスとユーザーエクスペリエンスの向上が期待できます。

　AI GatewayのサイドバーにあるSemantic cachingを開き、Configure semantic cachingを選択します。

Semantic cachingの選択画面

　設定画面に遷移したら以下のように設定します（設定しない項目はデフォルト値を利用します）。

Vector DB：
- Vector Database Driver：redis
- VectorDB Dimensions：1536
- Caching Similarity Threshold：0.3
- VectorDB Distance Metric：cosine
- Redis Vector：
  - Host：（Redisのホスト名を入力）
  - Port：6379
- Embeddings：
  - LLM Provider：OpenAI
  - Model Name：text-embedding-3-large
- Authentication：
  - API Key：（OpenAIのAPI Keyを入力）

　Caching Similarity Thresholdで類似度を設定しています。またエンベディング（ベクトル化）には、OpenAIを利用しています。上記設定後、以下のコマンドを実行します。

curl -X POST https://${PROXY_HOST}/ai \
  -i -H 'Content-Type: application/json' \
  -d '{
    "messages": [
      {
        "role": "user",
        "content": "パスタの茹で時間は何分が最適ですか？"
      }
    ]
  }'

　実行オプションとして-iを付与したため、レスポンスヘッダも確認できます。実行した結果は以下のようになりました。

：（省略）
x-cache-status: Miss
x-kong-upstream-latency: 7568
x-kong-proxy-latency: 4764
：（省略）
        "content": "パスタの最適な茹で時間は、パスタの種類や太さによって異なりますが、一般的には以下のような基準があります。\n\n- **スパゲッティ**: 8～12分\n- **ペンネ**: 10～12分\n- **フェットチーネ**: 7～10分\n- **ラザニア**: 25～30分（乾燥パスタの場合）\n- **生パスタ**: 2～4分\n\nパスタのパッケージには通常、推奨される茹で時間が記載されているので、それを参考にするのが良いでしょう。また、アルデンテの状態（少し硬め）で食べたい場合は、表示された時間よりも1～2分短めに茹でるのがおすすめです。茹でている間に味見をして、自分の好みに合わせて調整してください。",
：（省略）

　レスポンスヘッダのx-cache-statusがMissとなっているため、キャッシュを見に行っていることが分かります。また、x-kong-upstream-latencyとx-kong-proxy-latencyはそれぞれKongからLLMプロバイダーへのレイテンシ、Kongのプロキシ内でのレイテンシを意味しており、全体では約12秒かかっていることが分かります。

　次に、問い合わせ内容を以下に変更して実行します。

"content": "パスタの茹で頃はどれくらいの時間が最適ですか？"

　質問の内容は同じですが、表現が微妙に異なる内容となっています。コマンドを再度実行した結果、以下の結果となりました。

：（省略）
x-cache-status: Hit
x-kong-response-latency: 6026
：（省略）
"content":"パスタの最適な茹で時間は、パスタの種類や太さによって異なりますが、一般的には以下のような基準があります。\n\n- **スパゲッティ**: 8～12分\n- **ペンネ**: 10～12分\n- **フェットチーネ**: 7～10分\n- **ラザニア**: 25～30分（乾燥パスタの場合）\n- **生パスタ**: 2～4分\n\nパスタのパッケージには通常、推奨される茹で時間が記載されているので、それを参考にするのが良いでしょう。また、アルデンテの状態（少し硬め）で食べたい場合は、表示された時間よりも1～2分短めに茹でるのがおすすめです。茹でている間に味見をして、自分の好みに合わせて調整してください。"
：（省略）

　x-cache-statusがHitとなっているため、キャッシュを見に行って使えるキャッシュがあったことが確認できます。また、レイテンシも約6秒となっており、キャッシュを利用することでレイテンシが半分以下に削減されていることが分かります。

　レスポンスについては通常、AIに対する問い合わせは同じ内容であっても微妙に異なる回答が返ってくることがありますが、今回は全く同じ回答が返ってきているため、キャッシュが利用されていることが分かります。

　以上より、Semantic cachingプラグインが正常に動作していることを確認できました。

LLMアプリケーションの監視

　こちらも先述したように、LLMアプリケーションの監視は重要な観点です。Kong AI Gatewayでは、LLMアプリケーションの監視のため、以下のような機能を提供しています。

Analytics：AI Gatewayに対して送信されたリクエストのトークン使用量やレイテンシなどのメトリクスが確認可能な機能
Debugger：AI Gatewayに対して送信されたリクエストがKong Gatewayの内部やUpstream（LLM API）の呼び出しまでどのように処理されたかのトレース情報が確認可能な機能

　まずは、Analytics機能について確認します。Kong Konnectのダッシュボードに戻り、左サイドバーからAnalyticsを開き、Dashboardを選択します。

Kong Konnect - Analytics/Dashboard

　Create from templateボタンをクリックします。テンプレート一覧が表示されるので、AI Gateway dashboardテンプレートを選択し、Use templateボタンを選択します。

AI Gateway dashboardの作成

　AI gateway dashboardが作成され、AI Gatewayに対して送信されたリクエストのトークン使用量やレイテンシなどのメトリクスが確認可能となります。

ダッシュボードの画面

　続いて、Debugger機能について確認します。Kong Konnectのダッシュボードに戻り、左サイドバーからAPI GatewayのGatewaysを選択し、作成済みのserverless-defaultを選択します。

Gateway Managerの画面

　Debuggerタブを開き、New Sessionを選択します。特に追加項目を入力せずに、Start Sessionを選択してください。ここで、Debuggerのセッションが有効なData Planeに対して、AI Gateway経由でリクエストを送信します。

curl https://${PROXY_HOST}/ai -H 'Content-Type: application/json' -d '{
  "messages": [
    {
      "role": "user",
      "content": "How does Kong AI Gateway work?"
    }
  ]
}'

　リクエストが処理されると、Debuggerの画面にリクエストのトレース情報が表示されます。ここでは、AI Gatewayに対して送信されたリクエストがKong Gatewayの内部やUpstream（LLM API）の呼び出しまでどのように処理されたかを確認できます。

　全体の実行時間のうち、Upstreamの呼び出しに多くの時間を要していることが確認できます。

Konnect Debuggerを用いたトレース情報の確認

　本記事では簡易的なLLMアプリケーションの監視方法を解説しましたが、PrometheusやGrafana Tempoなど外部ツールにデータを長期保存すれば、より高度な分析も可能です。

終わりに

　本稿では、LLMアプリケーションの特徴や開発、運用における課題を整理した上で、AI Gatewayを用いたアプローチを解説し、実装のイメージとしてKong AI Gatewayを取り上げました。

　LLMアプリケーションは、その品質がLLMの性能に強く依存し、複数のコンポーネントとの連携が必要であり、さらにLLM固有のセキュリティリスクへの対応が求められるという特徴があります。API Keyの管理、プロンプトのライフサイクル管理、複数LLMの切り替え、セキュリティ対策、コスト管理、監視といった多様な課題が発生します。

　AI Gatewayは、これらの課題に対する効果的なアプローチの一つです。ライブラリを用いたアプローチと比較して、プログラミング言語に依存せず、複数のアプリケーションに対して一元的な制御が可能という利点があります。

　LLMを活用したアプリケーション開発は今後ますます加速することが予想されます。AI Gatewayのようなアプローチを活用することで、開発チームはビジネスロジックの実装に集中し、インフラストラクチャレイヤーで横断的な課題に対処可能になります。

　読者の皆さまのLLMアプリケーションを開発、運用する際の一助となれば幸いです。