【ClickHouseMeetup】LibreChat × ClickHouse プロンプトキャッシュ機能の効果とその仕組み

ClickHouse Meetup Tokyo -Librechat Night‐ 2026/03/09（https://connpass.com/event/383869/）

Transcript

1. Hisashi Hibino/日比野 恒 ログスペクト株式会社 LibreChat × ClickHouse プロンプトキャッシュ機能の効果とその仕組み
2. 日比野 恒 - Hisashi Hibino ログスペクト株式会社 Security Architect CISSP, CCSP, CySA+, CISA, PMP, 情報処理安全確保支援士（000999） [書籍] ➢ Elastic Stack 実践ガイド [Logstash/Beats 編]（インプレス刊） ➢ AWS 継続的セキュリティ実践ガイド （翔泳社刊） [略歴] ⚫ 2018 年まで 10 年間 フューチャーアーキテクト株式会社に在籍 ⚫ 2019 年より株式会社リクルートのセキュリティ組織に所属 ログ基盤やクラウドセキュリティに関するプロジェクトを推進 ⚫ 2024 年にログスペクト株式会社を設立し、LogEater を開発・展開中 自己紹介
3. LogEater とは データアナリストの採用を前提にしません 少子高齢化が進むと人の採用自体が難しくなります。知識のある 人を業務にアサインできないことを前提に「ログの民主化」を実 現するためのツールになります。 ログ基盤の運用コストを削減します LogEater はクラウドサービスのため、ログ基盤の運用は不要で す。また超高圧縮データストアを採用しているため、ログ保管に かかるコストを極限まで削減します。 クエリ言語の学習は不要です もうクエリを書けなくても大丈夫です。 日本語でやりたいことを伝えるだけで必要な情報を提供してくれ ます。ログの解析結果をチャットやグラフで回答してくれます。 LibreChat × ClickHouse を使ったログ解析 AI エージェントサービスです 1 2 3 LogEater 公式サイト: https://logeater.ai/
4. 本日の内容 3 2 プロンプトキャッシュとは 1 技術的な動作検証の実施 その結果含め、総括
5. プロンプトキャッシュとは • アテンション状態をキャッシュすることで、プロンプトによって LLM が消費するトークン数を節約できる仕組みです input Prompt Cache LLM output キャッシュヒットした 内容を output に送る ヒットせず キャッシュ検索 output の内容を キャッシュに登録 【 プロンプトキャッシュとは】 LLM が文章を理解するとき、「どの単語がどの 単語と関係しているのか」を計算する仕組みであ るアテンション状態を異なる複数のプロンプト間 で再利用できるようにキャッシュする仕組み 【 input 中身】 1. system（システムプロンプト） 2. messages: user（ユーザープロンプト） 3. tools（ツール定義） 【 output 中身】 1. messages: assistant（アシスタントプロンプト）
6. プロンプトキャッシュで期待できる効果 • LLM はチャット内の過去のやり取りを記憶できないため、リクエストするたびに過去の履歴を追加して問い合わせします 出展: Anthropic 社 コンテキストウィンドウ（https://platform.claude.com/docs/ja/build-with-claude/context-windows） プロンプトキャッシュの キャッシュにヒットする領域 # フィールド キャッシュ効果 1 system ほぼ 100% ヒット（固定値のため） 2 messages 過去の履歴部分はヒット 3 tools ほぼ 100% ヒット（固定値のため） 【input の詳細】
7. プロンプトキャッシュの設定方法 • LibreChat の v0.8.1-rc2 以降のバージョンでは、 Bedrock プロンプトキャッシュがデフォルトで有効になっています 参考: LibreChat v0.8.1-rc2（https://github.com/danny-avila/LibreChat/releases/tag/v0.8.1-rc2）
8. 動作検証の内容 • Bedrock のプロンプトキャッシュ機能の制約を考慮し、以下のシナリオで動作検証を実施しました 参考: AWS Bedrock プロンプトキャッシュ（https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html） User A User B Me EC2 Docker LibreChat v0.8.3-rc1 AWS Bedrock Prompt Cache LLM Claude Sonnet 4.6 ClickHouse Cloud CloudWarch Logs OpenSearch Elastic Cloud AWS @Tokyo BigQuery MCP 「こんにちは！（20:10）」 「CloudTrail のログ解析がしたい（20:11）」 「こんにちは！（20:13）」 「CloudTrail のログ解析がしたい（20:14）」 Bedrock のキャッシュ保持期間は 5 分間（標準）のため 5 分以内に LibreChat の異なるユーザーで同じプロンプトを実施 同一アカウント/同一 リージョンでキャッ シュが共有されます キャッシュチェックポ イントあたりの最小 トークン数は 4,096 になります キャッシュ対象の フィールドは system, messages, tools に なります
9. LibreChat 設定内容 • 以下、LibreChat で設定している AWS Bedrock Claude Sonnet 4.6 に関する設定の抜粋になります endpoints: bedrock: titleModel: "jp.anthropic.claude-sonnet-4-6" inferenceProfiles: "jp.anthropic.claude-sonnet-4-6": "${BEDROCK_INFERENCE_PROFILE_ARN}" streamRate: 35 availableRegions: - "ap-northeast-1" agents: recursionLimit: 50 maxRecursionLimit: 100 disableBuilder: false # Bedrock Settings BEDROCK_AWS_DEFAULT_REGION=ap-northeast-1 BEDROCK_AWS_MODELS=jp.anthropic.claude-sonnet-4-6 BEDROCK_INFERENCE_PROFILE_ARN=arn:aws:bedrock:ap-northeast-1:{AWS ACCPUNT}:application-inference-profile/{INFERENCE_PROFILE_ID} .env の抜粋 librechat.yaml の抜粋 参考: LibreChat AWS Bedrock（https://www.librechat.ai/docs/configuration/pre_configured_ai/bedrock）
10. システムプロンプトと MCP Server の設定 • 本動作検証環境におけるシステムプロンプト（指示文）および MCP Server の設定は以下の通りです
11. 実施結果 # 時刻 User system/tools input output messages messages 1 20:10:02 A 2 20:10:05 A 3 20:11:03 A ◦ （詳細省略） - ◦ （詳細省略） 4 20:11:35 A 5 20:11:37 A 6 20:13:02 B ◦ （詳細省略） - ◦ （詳細省略） 7 20:13:05 B 8 20:14:06 B - ◦ （詳細省略） こんにちは！ Provide a concise, 5-word-or-less title for the conversation, using title case conventions. Only return the title itself. No1 の input と output + CloudTrail のログ解析がしたい こんにちは！ \n\n何かお手伝いできることはあります か？\nAWS環境のログ解析、Google Cloudの監査ログ 解析、セッションマネージャーの操作ログ解析など、お気 軽にご相談ください！ 日本語の挨拶 CloudTrail のログ解析ですね！AWS 環境のログ解析な ので、**ClickHouse** と **CloudWatch** を確認して みます。まず両方のデータソースを同時に調べてみますね。 （toolUse あり） No4 の input と output + （ClickHouse と CloudWatch のス キーマ情報） - こんにちは！ 次に、ClickHouse の `default` データベースにあるテー ブルを確認してみます。 ClickHouse の `default` データベースに **`aws_cloudtrail`** テーブルが見つかりました！ （以下、量が多いため、省略） こんにちは！ \n\n何かお手伝いできることはあります か？AWS環境のログ解析、Google Cloudの監査ログ解 析、セッションマネージャーの操作ログ解析など、お気軽 にご相談ください！ Provide a concise, 5-word-or-less title for the conversation, using title case conventions. Only return the title itself. No6 の input と output + CloudTrail のログ解析がしたい Japanese Greeting Exchange CloudTrail のログ解析ですね！\n\nAWS環境のログ解 析については、**ClickHouse** と **CloudWatch** を 確認します。（以下、量が多いため、省略） input TokenCount output TokenCount cacheRead Input TokenCount cacheWrite Input TokenCount 20,622 110 129 12 10 222 - - 0 0 0 20,704 1,567 88 16,915 736 20,622 109 20,704 141 20,845 0 - - 128 7 10 339 0 0 0 20,703
12. 結果の考察 # 時刻 User system/tools input output messages messages 1 20:10:02 A 2 20:10:05 A 3 20:11:03 A ◦ （詳細省略） - ◦ （詳細省略） 4 20:11:35 A 5 20:11:37 A 6 20:13:02 B ◦ （詳細省略） - ◦ （詳細省略） 7 20:13:05 B 8 20:14:06 B - ◦ （詳細省略） こんにちは！ Provide a concise, 5-word-or-less title for the conversation, using title case conventions. Only return the title itself. No1 の input と output + CloudTrail のログ解析がしたい こんにちは！ \n\n何かお手伝いできることはあります か？\nAWS環境のログ解析、Google Cloudの監査ログ 解析、セッションマネージャーの操作ログ解析など、お気 軽にご相談ください！ 日本語の挨拶 CloudTrail のログ解析ですね！AWS 環境のログ解析な ので、**ClickHouse** と **CloudWatch** を確認して みます。まず両方のデータソースを同時に調べてみますね。 （toolUse あり） No4 の input と output + （ClickHouse と CloudWatch のス キーマ情報） - こんにちは！ 次に、ClickHouse の `default` データベースにあるテー ブルを確認してみます。 ClickHouse の `default` データベースに **`aws_cloudtrail`** テーブルが見つかりました！ （以下、量が多いため、省略） こんにちは！ \n\n何かお手伝いできることはあります か？AWS環境のログ解析、Google Cloudの監査ログ解 析、セッションマネージャーの操作ログ解析など、お気軽 にご相談ください！ Provide a concise, 5-word-or-less title for the conversation, using title case conventions. Only return the title itself. No6 の input と output + CloudTrail のログ解析がしたい Japanese Greeting Exchange CloudTrail のログ解析ですね！\n\nAWS環境のログ解 析については、**ClickHouse** と **CloudWatch** を 確認します。（以下、量が多いため、省略） input TokenCount output TokenCount cacheRead Input TokenCount cacheWrite Input TokenCount 20,622 110 129 12 10 222 - - 0 0 0 20,704 1,567 88 16,915 736 20,622 109 20,704 141 20,845 0 - - 128 7 10 339 0 0 0 20,703 初回のプロンプトがキャッシュ乗っていない （cachePoint を設定していないと思われる） output messages の内容が User A と一文字（改行 コード）が異なるためキャッシュに乗らなかった チャットのタイトルを自動生成するため LibreChat が別リクエストを発行している ここで初回のやり取りがキャッシュに乗っている system と tools のトークン消費が大きい No4 のツール利用結果を踏まえて、追加でツールを利 用したため、別のリクエストになったと推察される
13. 本日のまとめ ✓ 設定内容にもよるが、システムプロンプトとツール定義で消費するトークン数が多くを占めていた ✓ そのトークン消費が毎リクエストに乗ってくるため、それをプロンプトキャッシュで節約できる効果は大きい ✓ LLM は過去のチャット履歴を記憶できないため、やり取りの回数が増えるほどキャッシュの効果が発揮される ✓ 異なるユーザーで同じプロンプトを実行しても生成 AI の回答が一文字ズレるだけキャッシュには乗らない ✓ 同一 AWS アカウント/同一リージョンでも、意外と異なるプロンプトでキャッシュに乗せるのは難しい ✓ ユーザーが LibreChat で投げたリクエストが生成 AI に対するリクエストと一致するとは限らない ✓ チャットタイトルを自動生成するためのリクエストが走っていた ✓ MCP で得た結果を用いて段階的に MCP を使う場合に生成 AI に対するリクエストは別になっていた 過去のチャット履歴を記憶できない LLM の仕組みにおいて システムプロンプトとツール定義で消費されるトークン量を大幅に節約できるため 80 % 近いトークンコストが抑制できるという説は正しそう
14. ご清聴ありがとうございました