Prompt Caching for Multi-Tenantとは？B2B SaaSの推論コストを削減する設計

Prompt Caching for Multi-Tenant とは、複数テナントが共有する LLM（大規模言語モデル）推論基盤において、テナントごとのシステムプロンプトやコンテキストウィンドウをキャッシュすることで、推論コストとレイテンシを削減する設計手法です。

B2B SaaS では、テナント数の増加とともに LLM への API 呼び出し回数が急増し、入力トークンのコストが収益を圧迫する課題が生じやすい傾向があります。プロンプトキャッシュを適切に設計すれば、キャッシュ読み取り時のコストを大幅に抑えられる一方、テナント間のデータ混入というリスクも伴います。

本記事では、エンジニアやアーキテクトを対象に、以下の内容を順を追って解説します。

プロンプトキャッシュとは、LLMへのリクエスト時に毎回送信される長いプロンプトの前半部分をサーバー側で保持しておき、次回以降の処理を省略する仕組みです。システムプロンプトや固定のコンテキストが繰り返し使われるB2B SaaSでは、この仕組みが推論コストに直結します。

ただし、マルチテナント環境ではそう単純ではありません。テナントごとに異なるシステムプロンプトや権限情報をキャッシュに乗せようとすると、「誰のキャッシュをどこに保持するか」という分離の問題が浮上します。コスト削減を優先してキャッシュを共有すれば情報漏洩のリスクが生まれ、テナントごとに完全分離すればキャッシュヒット率が下がって削減効果が薄れます。

ここでは、プロンプトキャッシュの基本的な動作原理から、B2B SaaS特有のコスト構造、そしてマルチテナント環境でキャッシュ設計が複雑になる理由を順に整理していきます。

プロンプトキャッシュは、LLM への API リクエストのうち「変化しない先頭部分（プレフィックス）」を推論サーバー側でメモリに保持し、次のリクエストで再利用する仕組みです。毎回同じシステムプロンプトや長大なコンテキストを再処理する代わりに、キャッシュ済みの Key-Value テンソルを読み出すため、入力トークンの処理コストを大幅に削減できます。

最初は「キャッシュはレスポンス全体を保存するものだ」と考えがちですが、実際はプロンプトの入力側のプレフィックスだけをキャッシュするのが正確な理解です。出力は毎回生成されるため、削減対象はあくまで入力トークンの処理コストに限られます。

仕組みを整理すると、以下の流れになります。

• 書き込み: 初回リクエスト時にプレフィックスが Key-Value テンソルとして保存される
• 読み取り: 同一プレフィックスを持つ後続リクエストでキャッシュが再利用される
• コスト差: Anthropic の Claude では、キャッシュ読み取りコストは通常入力価格の 0.1 倍、一方でキャッシュ書き込みは 1.25 倍（5 分 TTL の場合）となっている

キャッシュが有効になる最小トークン数はプロバイダーによって異なります。OpenAI は 1,024 トークン以上、AWS Bedrock の Claude Opus では 4,096 トークン以上が必要です。

TTL（有効期間）も重要な設計変数です。

B2B SaaSの推論コストは、ユーザー数ではなくテナント数 × リクエスト数 × トークン数の積で膨らむ点が特徴です。単一のエンドユーザー向けサービスと異なり、法人顧客ごとに固有のシステムプロンプトや業務ルールを毎回送信するため、入力トークン数が慢性的に大きくなります。

コスト構造を分解すると、3つの層が重なっています。まずテナントごとの業務ルール・制約・ペルソナ定義を束ねたシステムプロンプト層で、内容によっては数百〜数千トークンに達します。次に会話履歴やRAGで取得したドキュメント断片からなるコンテキスト層で、これもリクエストのたびに再送信されます。最後がユーザー入力層、つまりエンドユーザーが実際に打ち込むクエリで、相対的にトークン数は少ないです。

テナントが数十社規模であれば月次コストはまだ許容範囲に収まることが多いですが、数百〜数千社規模になると話が変わってきます。同じ構造のプロンプトをすべてのテナントに対してフルで送り続けるコストは、スケールするほど無視できなくなります。

特に深刻なのが**「共通部分の重複送信」**という問題です。多くのB2B SaaSでは、製品仕様・FAQ・コンプライアンスルールといったテナント間で共通するコンテンツをシステムプロンプトに組み込んでいます。テナントが変わっても内容はまったく同一なのに、毎リクエストで課金対象トークンとして計上され続けます。これはコスト構造上の盲点になりやすい箇所です。

「テナントAのシステムプロンプトをキャッシュしたら、テナントBのリクエストにそのキャッシュが当たってしまうのでは？」——マルチテナント環境でプロンプトキャッシュを検討し始めると、多くのエンジニアが最初にこの不安に直面します。

この懸念は単なる杞憂ではありません。マルチテナント環境でキャッシュが難しい主な理由は以下の 3 点に集約されます。

• テナント間のデータ分離要件: 各テナントのシステムプロンプトには、業務ルール・料金体系・機密ポリシーなど固有の情報が含まれます。キャッシュキーの設計を誤ると、別テナントのリクエストが同じキャッシュを参照してしまうリスクがあります
• プロンプト構造の多様性: テナントごとにシステムプロンプトの長さや構成が異なるため、共通プレフィックスが短くなりやすく、キャッシュヒット率が下がります。プロンプトキャッシュは 1,024 トークン以上の共通部分がなければ効果が薄い点も設計の難しさを増します
• TTL とテナントライフサイクルの不一致: テナントが契約変更やプラン更新を行った際、キャッシュの有効期限（TTL）が残っていると古い設定が使われ続ける恐れがあります。Anthropic の Claude では標準 TTL が 5 分、オプションで 1 時間まで延長できますが、テナント設定の変更頻度と TTL のバランスを取る仕組みが別途必要です

さらに、テナント数が増えるほどキャッシュエントリーも増加し、管理コストが線形以上に膨らむ傾向があります。

結論: 設計に入る前に、利用する LLM プロバイダーのキャッシュ仕様・テナント分離モデル・システムプロンプトの構造の 3 点を確認することが、コスト削減効果を最大化する前提条件となります。

各要素の選択ミスは後工程での大幅な手戻りにつながるため、順を追って整理します。

キャッシュ設計を始める前に、利用するプロバイダーが「どの条件でキャッシュが有効になるか」を正確に把握しておく必要があります。最初は「どのモデルでも同じように使える」と考えがちですが、実際にはプロバイダーごとにキャッシュの最小トークン数・TTL・APIの呼び出し方が大きく異なります。

主要プロバイダーの仕様を以下に整理します。

• OpenAI: 1,024 トークン以上のプロンプトでキャッシュが有効。キャッシュヒット数はレスポンスの usage.prompt_tokens_details.cached_tokens で確認できます。In-memory キャッシュは非アクティビティで 5〜10 分程度で失効し、最大 1 時間保持。Extended では最大 24 時間保持が可能です。同一プレフィックスの prompt_cache_key は 15 リクエスト/分未満に抑えることが推奨されています。
• Anthropic（Claude）: デフォルトの TTL は 5 分。1 時間オプションは追加費用が発生し、キャッシュ書き込みコストは基本入力価格の 1.25 倍（5 分）または 2 倍（1 時間）、読み取りは 0.1 倍となります。
• AWS Bedrock（Claude Sonnet）: 最小キャッシュトークン数は 1,024 トークン、デフォルト TTL は 5 分。Claude Opus の場合は最小 4,096 トークンが必要で、最大 4 つのキャッシュ区切りを設定できます。

テナント分離モデルの選択は、キャッシュ設計の土台となるため、アーキテクチャ決定の最初期に行う必要があります。主要な3モデルの特徴を整理します。

サイロ型（Silo） テナントごとに専用のLLMエンドポイントやキャッシュ領域を割り当てるモデルです。データ混入リスクが最も低く、コンプライアンス要件が厳しい金融・医療系 SaaS に向いています。ただしキャッシュの再利用範囲がテナント内に限定されるため、テナント数が増えるほどインフラコストが線形に増大する傾向があります。

プール型（Pool） 複数テナントが共通のキャッシュ領域とシステムプロンプト（System Prompt）を共有するモデルです。共有プレフィックスのキャッシュヒット率が高くなり、推論コストを大幅に削減できます。一方で、キャッシュキーの設計が不十分だとテナント間のデータ混入リスクが生じるため、後述するキャッシュキー設計が特に重要になります。

ハイブリッド型 共有部分（製品共通のシステムプロンプト）はプール型で管理し、テナント固有のコンテキストはサイロ型で分離する折衷モデルです。コスト効率とセキュリティを両立しやすく、多くの B2B SaaS に適しています。

選択の判断軸は次のとおりです。テナントごとにデータ主権やコンプライアンス要件が異なる場合はサイロ型またはハイブリッド型、テナント間の要件が均質でコスト最適化を優先する場合はプール型が適しています。

「システムプロンプトをどこまで共通化し、どこからテナント固有にすべきか」——この線引きに迷う現場は多いです。コンテキストウィンドウとシステムプロンプトの設計方針は、キャッシュ効率に直結するため、実装前に整理しておく必要があります。

設計の基本原則は「不変部分を先頭に固める」ことです。LLM（大規模言語モデル）のプロンプトキャッシュは、プロンプトの先頭から一致するプレフィックスをキャッシュします。変化しない共通コンテキストを先頭に配置し、テナント固有の情報を後方に置くことで、キャッシュヒット率が大幅に向上します。

システムプロンプトは以下の 3 層に分けて設計するのが効果的です。

• 共通層（全テナント共有）: 製品の基本動作ルール、応答フォーマット、禁止事項など。変更頻度が低く、最も長い部分をここに集約する
• プラン層（プランや業種で共有）: エンタープライズ向け機能説明や業種別ガイドラインなど、同一プランのテナントが共有できるコンテキスト
• テナント固有層: テナント名、カスタム設定、個別ポリシーなど。最も短くなるよう設計する

Anthropic の Claude では、キャッシュ最小サイズが 1,024 トークンです。共通層がこの閾値を超えるよう設計すると、キャッシュ書き込みが有効になります。AWS Bedrock の Claude Opus では最小 4,096 トークンが必要なため、プロバイダーごとに共通層の分量を調整してください。

結論: キャッシュキーの設計ミスはテナント間のデータ混入に直結するため、命名規則と分離構造を事前に確定することが不可欠です。

テナントごとのキャッシュキー設計では、共有プレフィックスとテナント固有サフィックスをどう組み合わせるか、TTL をどう管理するかが核心になります。

キャッシュキー設計で最初に陥りがちな失敗は、「ユーザーIDやセッションIDをそのままキーに使えばよい」という発想です。しかし実際には、テナントIDを最上位の名前空間として必ず先頭に置くほうが、分離の確実性とキャッシュ効率の両方が高まります。

なぜ先頭でなければならないのでしょうか。LLMプロバイダーのプロンプトキャッシュは、プロンプト文字列の先頭からの一致（プレフィックスマッチ）でヒットを判定するため、キャッシュキーの構造はプロンプトの並び順と対応させる必要があります。この原則に従うと、推奨するキー構造は次のようになります。

先頭の tenant_id にはテナントを一意に識別するUUIDなどを置きます。ここを起点にすることで、異なるテナントのキャッシュが混在する余地がそもそもなくなります。続く model_id は同一テナントが複数モデルを使う場合の衝突防止、prompt_version はシステムプロンプト変更時に古いキャッシュを自動的に無効化するためのもの、context_hash はユーザー固有のコンテキストをSHA-256などでハッシュ化した値です。

なお、テナントIDにはアプリケーション側で管理する識別子をそのまま流用できますが、外部に露出しない内部UUIDを使うとセキュリティリスクを抑えられます。

プロンプトを「共有プレフィックス」と「テナント固有サフィックス」に分離する構造は、マルチテナント環境でキャッシュ効率を最大化するための基本パターンです。

分離の基本構造

プロンプト全体を次の 3 層に分けて組み立てます。

• 共有プレフィックス層: 全テナント共通のシステムプロンプト（製品説明、安全ポリシー、出力フォーマット指示など）
• テナント固有層: テナントごとの設定（会社名、業種、カスタムルールなど）
• ユーザーリクエスト層: 各リクエストのユーザー入力

キャッシュの対象は主に「共有プレフィックス層」です。ここが全リクエストで共通するため、キャッシュヒット率が最も高くなります。

条件による設計の分岐

テナント間でシステムプロンプトの共通部分が大きい場合は共有プレフィックスを長く取るほどキャッシュ効率が上がりますが、テナントごとにポリシーや言語設定が大きく異なる場合はテナント固有層を前段に置いてテナント別にキャッシュを分割する設計が適切です。

実装例（概念）

[共有プレフィックス: 2,000 トークン]
あなたはSaaSプラットフォームのAIアシスタントです。
出力は日本語で.

「キャッシュのTTLはどれくらいに設定すればいいのか」——実装の現場でまず迷うのがこの問いです。

TTL の設定は、コスト削減効果とデータ鮮度のトレードオフで決まります。主要プロバイダーの仕様を踏まえて整理すると、以下のとおりです。

主要プロバイダーのデフォルト TTL

• Anthropic（Claude）: デフォルト 5 分、オプションで 1 時間（追加費用あり）
• AWS Bedrock（Claude Sonnet）: デフォルト 5 分
• AWS Bedrock（Claude Opus）: 5 分または 1 時間を選択可能
• OpenAI: 非アクティブで 5〜10 分程度で失効、最大 1 時間（Extended は最大 24 時間）

TTL 選択の判断軸

TTL は「システムプロンプトの更新頻度」と「リクエスト密度」の 2 軸で決めるのが実践的です。

• 更新頻度が低く、リクエストが集中する時間帯がある場合 → 1 時間 TTL でキャッシュ書き込みコストを回収しやすい
• テナントごとにシステムプロンプトが頻繁に変わる場合 → 5 分 TTL で鮮度を保ちつつ、短期バースト時のコスト削減を狙う

Anthropic の価格体系では、1 時間キャッシュの書き込みコストは基本入力価格の 2 倍、読み取りは 0.1 倍です。1 回の書き込みコストを回収するには、TTL 内に同一キャッシュを複数回ヒットさせる必要があります。

結論: 設計方針が固まったら、テンプレート化・キャッシュレイヤー構築・計測の3ステップで実装を進める。

システムプロンプトのテンプレート化から始め、キャッシュレイヤーの導入、ヒット率の計測へと順に構築します。各ステップの詳細は以下の H3 で解説します。

最初は「テナントごとに完全に異なるシステムプロンプトを用意すれば良い」と考えがちですが、実際には共通部分と差分を明確に分離したテンプレート構造のほうが、キャッシュヒット率と保守性の両面で効果的です。

テンプレート化の基本方針は、プロンプトを「共有プレフィックス層」と「テナント固有層」の2段構成に分けることです。

共有プレフィックス層（キャッシュ対象）

• AIの役割定義・出力フォーマット指示・禁止事項などの不変ルール
• 全テナントで共通する業務ロジックやガイドライン
• OpenAI の場合は 1,024 トークン以上、Anthropic（Claude）の場合も同様に最低 1,024 トークン以上が必要なため、共通部分をこの閾値以上に設計する

テナント固有層（キャッシュ非対象）

• テナント名・契約プラン・有効機能フラグなどの動的パラメータ
• テナント独自のトーン指定やブランドガイドライン

実装時は Jinja2 などのテンプレートエンジンを活用し、共有プレフィックスを静的文字列として管理するのが一般的なアプローチです。テナント固有のパラメータは {{ tenant_name }} のようなプレースホルダーで後置し、レンダリング後もプレフィックス部分のバイト列が変化しないよう設計します。

注意点として、共有プレフィックスの末尾に改行や空白が混入すると、プロバイダー側でキャッシュキーが別物と判定される場合があります。

テンプレート化したシステムプロンプトをそのまま API に渡すだけでは、キャッシュの恩恵を安定して受けられません。キャッシュレイヤーを別途設けて「プロンプトハッシュ」で一元管理することが、マルチテナント環境での安定運用に欠かせません。

キャッシュレイヤーの基本構成

アプリケーション層と LLM API の間に薄いキャッシュプロキシを挟む構成が一般的です。処理フローは以下のとおりです。

1. テナント ID とシステムプロンプトのバージョン番号を結合し、SHA-256 などでハッシュ値を生成する
2. ハッシュ値をキーとして Redis 等のインメモリストアにキャッシュエントリを登録する
3. 同一ハッシュのリクエストが来た場合はキャッシュから返し、LLM API への呼び出しをスキップする

プロンプトハッシュ管理の判断軸

リクエスト量が多いテナントの場合はハッシュをインメモリ（Redis）で管理してレイテンシを最小化し、リクエスト頻度が低いテナントの場合はコスト優先でデータベース側にハッシュを永続化する設計が適しています。

LLM プロバイダー側の連携

Anthropic のキャッシュ読み取りコストは基本入力価格の 0.1 倍であるため、ハッシュが一致してプロバイダー側のキャッシュもヒットすると二重のコスト削減が得られます。キャッシュ書き込みコストは 5 分 TTL で 1.

「キャッシュを導入したはいいが、本当にヒットしているのか確認できていない」という状況は、現場でよく起きます。計測なしでは最適化の余地が見えないため、AIオブザーバビリティの設定は実装と同時に進めることが重要です。

計測の起点となるのは、API レスポンスの usage.prompt_tokens_details.cached_tokens フィールドです。このフィールドからキャッシュヒット数を取得し、以下の指標を継続的に記録します。

• キャッシュヒット率: cached_tokens ÷ total_prompt_tokens で算出
• テナント別ヒット率: テナント ID ごとに集計し、ヒット率の低いテナントを特定
• TTL 切れ件数: キャッシュ書き込みとヒットの時間差を記録し、5 分・1 時間のどちらの TTL が適切かを判断する材料にする

これらのメトリクスは、Datadog や Grafana などのオブザーバビリティプラットフォームに送信し、ダッシュボードで可視化するのが一般的なアプローチです。AIエージェント導入後の効果測定方法｜KPI設計から継続改善までで解説しているように、KPI を事前に定義しておくことで、改善サイクルを回しやすくなります。

アラートの設定も欠かせません。推奨する閾値の例を以下に示します。

キャッシュを活用するほど、テナント間の情報漏洩リスクも高まります。これは設計の後付けで対処できる問題ではなく、キャッシュ構造を決める段階で織り込んでおかなければなりません。プロンプトリーキングの具体的なリスクと、プライバシー・バイ・アイソレーションをキャッシュ設計に適用する方法を以降で整理します。

キャッシュを「コスト削減の仕組み」としてだけ捉えていると、テナント間の情報漏洩という深刻なリスクを見落としやすいです。実際は、キャッシュ設計の誤りがプロンプトリーキング（システムプロンプト漏洩）の温床になるケースが報告されています。

プライバシー・バイ・アイソレーション（Privacy by Isolation）をキャッシュ設計に組み込む際は、「何を隔離するか」を最初に明確に定義することが出発点になります。

具体的には、以下の三層で分離を設計します。

• キャッシュストレージ層: テナント ID をキャッシュキーの名前空間として必ず付与し、Redis や Memcached のキーが他テナントと衝突しない構造にする
• プロンプト構造層: 全テナント共通のシステムプロンプト（共有プレフィックス）と、テナント固有のコンテキスト（サフィックス）を物理的に分離して管理する
• API 呼び出し層: キャッシュヒット判定の前に、リクエスト元のテナント ID と取得しようとするキャッシュキーの名前空間が一致するかを必ず検証する

テナント分離モデルによって実装方針は変わります。サイロ型（テナントごとに独立したインフラ）の場合はキャッシュストレージ自体を分離できるため管理がシンプルになりますが、プール型（共有インフラ）の場合はアプリケーション層でのキー名前空間管理と、取得前の所有権チェックが不可欠です。

また、キャッシュに書き込む内容そのものにも注意が必要です。テナント固有の個人情報や機密データをキャッシュ対象のプロンプトに含めることは避け、キャッシュに乗せるのは「テナント設定・ロール定義・共通ナレッジ」などの静的・準静的なコンテキストに限定するのが原則です。

結論: 設計・実装段階で見落とされやすい失敗パターンを事前に把握することが、安定したキャッシュ運用の前提となります。

キャッシュキーの衝突とキャッシュ無効化タイミングのズレは、マルチテナント環境で特に発生しやすい問題です。それぞれの原因と回避策を整理します。

キャッシュキーの衝突は、まるで異なる住人の郵便物が同じポストに届くようなものです。テナント A のシステムプロンプトがテナント B のリクエストに返却されれば、機密情報の漏洩に直結します。

この問題が起きる典型的な原因は、キャッシュキーの設計が不十分な場合です。たとえば、プロンプトの内容だけをハッシュ化してキーとした場合、異なるテナントが偶然同一のシステムプロンプト文字列を使っていると、同じキーが生成されます。結果として、先にキャッシュを書き込んだテナントのコンテキストが別テナントに返却される可能性があります。

衝突パターンは大きく三つあります。一つ目は、プロンプトの内容だけをキー化するケースで、テナント ID をキーに含めていないため同一文字列で衝突します。これは {tenant_id}:{prompt_hash} の形式にキーを統一することで防げます。二つ目は、グローバルなキャッシュ名前空間をテナント間で共用するケースです。Redis などを使う場合、キャッシュストア自体を分離していないと名前空間レベルで混入が起きるため、テナントごとにキープレフィックスまたは DB 番号を分ける必要があります。三つ目は、テンプレート変数の展開前にハッシュを計算してしまうケースで、共通テンプレートをそのままキーにすると、展開後の内容が異なるにもかかわらず同一キーが生成されます。ハッシュは必ず変数展開後のプロンプト文字列に対して計算してください。

キャッシュの無効化は「更新があれば即座にパージすれば良い」と考えがちですが、無効化のタイミングを誤ると新規書き込みコストが急増するという逆効果が起きやすいです。

Anthropicの価格体系では、5分キャッシュの書き込みは基本入力価格の1.25倍、1時間キャッシュは2倍になります。プロンプトが頻繁に変わるとキャッシュが再生成され、読み取り（0.1倍）の恩恵を受ける前にTTLが切れるサイクルが続きます。デフォルトTTLが5分のプロバイダーでは、5分以内に同一テナントのリクエストが集中しなければキャッシュヒットはほぼゼロになります。さらに、管理画面の設定変更のたびに全テナントのキャッシュを一括無効化すると、ヒット率が一時的に急落してコストが跳ね上がります。

こうした問題への現実的な回避策が遅延無効化（Lazy Invalidation）です。プロンプト変更をバージョン管理しておき、即時パージはせず次回リクエスト時に新バージョンへ切り替える方式をとることで、書き込みコストの連鎖的な増大を抑えられます。

Q1. Prompt Caching はすべての LLM プロバイダーで利用できますか？

主要プロバイダーでは対応が進んでいますが、モデルや契約プランによって条件が異なります。OpenAI はキャッシュ有効化に 1,024 トークン以上が必要で、in-memory キャッシュは 5〜10 分程度で失効します。Anthropic（Claude）はデフォルト TTL が 5 分で、1 時間オプションも選択できます。AWS Bedrock では Claude Opus 4.5 が最小 4,096 トークンを要件とするなど、モデルごとに閾値が異なります。導入前に各プロバイダーの公式ドキュメントで対応モデルと最小トークン要件を確認することをお勧めします。

Q2. マルチテナント環境でキャッシュを使うと、テナント間でデータが混入するリスクはありますか？

キャッシュキーの設計を誤ると、異なるテナントのコンテキストが同一キャッシュエントリに紐づくリスクがあります。対策として、キャッシュキーにテナント ID を必ず含め、テナント固有のシステムプロンプトを共有プレフィックスと明確に分離する設計が有効です。プライバシー・バイ・アイソレーションの考え方を適用し、テナントをまたいだキャッシュ参照が構造的に発生しない設計にすることが重要です。キャッシュヒット率の計測とあわせて、テナント境界の監査ログも定期的に確認することをお勧めします。

Q3. キャッシュの TTL はどのように設定すればコスト効率が高まりますか？

TTL の最適値はリクエスト頻度とシステムプロンプトの更新頻度によって変わります。Anthropic の価格体系では、キャッシュ書き込みコストは基本入力価格の 1.25 倍（5 分 TTL）または 2 倍（1 時間 TTL）ですが、キャッシュ読み取りは 0.1 倍まで下がります。リクエストが頻繁に来るテナントには 1 時間 TTL が有利で、低頻度テナントには 5 分 TTL がコスト的に適切なケースが多いです。TTL 選択はキャッシュヒット率の実測値をもとに定期的に見直すことが効果的です。

Q4. システムプロンプトを頻繁に更新するテナントがいる場合、キャッシュはどう扱うべきですか？

システムプロンプトが変更されると、対応するキャッシュエントリは無効化が必要です。プロンプトのハッシュ値をキャッシュキーの一部として組み込む設計にすると、プロンプト変更時に自動的に別のキャッシュエントリが生成され、古いエントリへの参照を防げます。更新頻度が高いテナントはキャッシュヒット率が下がる傾向があるため、AIオブザーバビリティのダッシュボードでテナントごとのヒット率を監視し、TTL 設定やキャッシュ戦略を個別に調整することをお勧めします。

Q5. Prompt Caching の効果を定量的に評価するにはどうすればよいですか？

OpenAI の場合、API レスポンスの usage.prompt_tokens_details.cached_tokens フィールドでキャッシュヒットしたトークン数を確認できます。このデータを蓄積することで、テナントごとのキャッシュヒット率と削減トークン数を算出できます。評価指標としては「キャッシュヒット率」「削減トークン数」「レイテンシ改善幅」の 3 つを組み合わせるのが実践的です。AIエージェント導入後の効果測定方法｜KPI設計から継続改善までも参考に、定期的な計測サイクルを設けることで継続的なコスト最適化につなげられます。