はじめに
「LLMアプリケーションのベストアーキテクチャを探る──トークンの過剰利用や複雑な構成、入出力の制御をどう解決するか」 の続編です。本記事では、前半に整理した内容を踏まえ、Kong Gateway（OSS）を用いたハンズオンを交えつつ、実際のアプローチを紹介します。対象の読者層としては以下を想定していますが、該当しない場合でもLLMアプリケーション開発の一端を理解していただけるよう説明していきたいと思います。
- LLMアプリケーションの開発、運用に興味を持っている方
- LLMアプリケーションの開発、運用に現在携わっている方
- CCoE[1]など中央集権的なチームに所属している方
[1] Cloud Center of Excellenceの略で、組織全体で最適なクラウド導入を支援、管理、調整する役割
LLMアプリケーションにおけるAPI Gatewayの活用
前回の記事では、中央集権的なレイヤーを用いるアプローチの有用性について説明しました。以降では、具体的なユースケースをいくつか取り上げて説明します。
API Key、推論パラメータ、プロンプトの中央管理
通常、LLMアプリケーションを実装する際は以下のようにAPI Keyや推論パラメータをクライアント側に設定します。例では、OpenAIのSDKを利用していますがどのライブラリを利用しても大枠は同様の実装になるかと思います。
from openai import OpenAI client = OpenAI( api_key="sk-...", ) stream = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "あなたは優秀なアシスタントです"}, {"role": "user", "content": "日本で一番高い山はなんですか？"} ], max_tokens=max_tokens, temperature=temperature, stream=True, )
api_keyはアプリケーションや環境に紐づくものとなるため、仮にAPI Keyをローテーションする場合（流出してしまった場合など）は再発行、および再設定が必要になります。これは、api_keyを環境変数（OPENAI_API_KEY）から読み取るような形式であっても当てはまります。
また、推論パラメータ（max_token, temperatureなど）やプロンプトについても、対応はapi_keyと同様です。新しい設定を読み込むためには、アプリケーションを再起動する必要があります。
一方で、API Gatewayにはほとんどの場合でリクエスト・ヘッダーやボディーの変換機能が備わっており、このレイヤーでAPI Keyや共通的に設定したい推論パラメータ、プロンプトを設定することで、アプリケーションの再起動なしにAPI Keyのローテーションやパラメータを変更することが可能です。
統一的なセキュリティ対策
プロキシしているLLM APIに関連する通信はすべてAPI Gatewayを通過するため、このレイヤーでセキュリティ対策を講じることで統一的な制御が可能です。LLMアプリケーションでは先に述べた通り、通常のセキュリティ観点に加えてプロンプト・インジェクションの対策や機微情報の入力制限、LLMの出力制限などが必要となります。これらもリクエストやレスポンスボディの中身を確認することで実現できます。
キャッシュの活用
トークン使用量削減のため、もしくは似たような問い合わせに対する応答時間削減のために、LLMアプリケーションではキャッシュがよく活用されます。
通常のAPIレスポンスのキャッシュと考え方は近しいですが、異なる点としては緩くキャッシュ・ヒットさせる点です。つまり、厳密に同じリクエスト（＝問い合わせ）でなくても意味的に近しいのであれば、キャッシュ・ヒットさせるということです。
これを実現するために、アプリケーションで入力に対する埋め込みを作成し、それを基にキャッシュ・ヒットの判定を行います。APIレスポンスのキャッシュは、API Gatewayが担う典型的なタスクであり、埋め込みの作成やそれを基にしたキャッシュ・ヒットの判定ロジックさえ備わっていれば、API Gatewayでトークン使用量や応答時間削減の課題を解決することができます。
オブザーバビリティ
同様にプロキシしているLLM APIに関する通信はすべてAPI Gatewayを通過するため、このレイヤーでテレメトリー・シグナル（特にメトリクス）を収集すると効率が良いです。API Gatewayのレイヤーで一元的に収集するべきメトリクスとしては、遅延やトークン数が挙げられます。
