プロンプトキャッシュのワークフロー: LLMアプリ向けコストとROIガイド

プロンプトキャッシュは、繰り返し発生するLLMリクエストのコストとレイテンシを削減できますが、それはワークフローが安定したプレフィックス、十分な再利用、許容可能なキャッシュヒット動作を生み出す場合に限られます。機能をオンにすることは、投資収益率を証明することと同じではありません。

このガイドでは、エンジニアリングとFinOpsチーム向けに実践的なプロンプトキャッシュのワークフローを紹介します。対象トラフィックの特定、再利用しやすいようにプロンプトを整えること、キャッシュ指標の計測、純削減額の計算、そして品質や信頼性の低下を隠さずに展開する方法です。また、プロバイダーの使用量フィールドを使って、実施・修正・停止の判断につなげる7日間監査も含まれています。

プロンプトキャッシュのROI: まず結論

プロンプトキャッシュは、ワークフローがプロバイダーの保持期間内に、大きなバイト一致のプレフィックスを繰り返し送信する場合に、試す価値があることが多いです。モデルが割引されたキャッシュ済みトークンを提供しているというだけで、自動的に有益とは限りません。

本番のプロンプトを変更する前に、次の3段階のゲートを使ってください:

基本計算は次のとおりです:

net_savings = uncached_baseline_cost
            - observed_cached_workflow_cost
            - incremental_engineering_and_operations_cost

roi_percent = net_savings
            / incremental_engineering_and_operations_cost
            × 100

実装コストが複数のキャッシュIDで共有される場合は、プロジェクト全体のコストを1件に割り当てるのではなく、期待評価期間にわたって按分してください。

2026年のプロンプトキャッシュで何が変わったのか?

プロンプトキャッシュは、もはや一様な割引メカニズムではありません。現在のプロバイダー設計は十分に異なっており、一般的な「キャッシュ済みトークンは安い」という表計算だけでは誤った結論になることがあります。

たとえば、OpenAIの現在のGPT-5.6ドキュメントでは、自動プレフィックス一致、明示的なprompt_cache_keyおよびcache_controlの制御、さらにキャッシュ読み取りとキャッシュ書き込みの個別の使用量が説明されています。このモデルのキャッシュ書き込みにはプレミアムがかかる場合があるため、損益分岐点の計算には、割引された読み取りだけでなく、キャッシュを作成または延長するコストも含める必要があります。OpenAIはまた、対応リクエストの使用量フィールドで、キャッシュ済み、非キャッシュ、キャッシュ書き込みのトークン詳細を公開しています。

Anthropicは明示的なキャッシュ境界とTTLの選択を使用します。Geminiの明示的コンテキストキャッシュには保存料金が追加される場合があります。DeepSeekは、ヒット率とミス率を分けた自動コンテキストキャッシュを文書化しています。これらの設計はいずれも節約を生み出し得ますが、必要となるテレメトリと数式はそれぞれ異なります。

プロンプトキャッシュとは何か?

プロンプトキャッシュは、LLMプロバイダーが直近で処理したプロンプト内容に対する計算を再利用できるようにします。繰り返し入力される各トークンを通常料金で都度課金・処理する代わりに、プロバイダーは再利用可能な部分に対して、より低いキャッシュ済み入力レートまたは別のキャッシュ読み取り価格を適用できます。

再利用可能なコンテンツは、通常 安定したプロンプトプレフィックス です。一般的な例には次のようなものがあります:

• 長いシステムプロンプトとポリシーブロック。
• すべてのエージェントターンで共有されるツール定義。
• 繰り返し照会される大きなドキュメント、リポジトリマップ、または製品カタログ。
• 分類や抽出ジョブ全体で再利用される few-shot の例。
• いくつかの可能な次のアクションで共有される会話履歴。

プロバイダーの実装は異なります。OpenAI は、条件を満たすプロンプトプレフィックスに対する自動キャッシュを文書化しており、API 使用量でキャッシュ済みトークンの詳細を公開します。対応する新しいモデルでは、キャッシュ書き込みの詳細も公開される場合があります。Anthropic は、明示的なキャッシュブレークポイントと複数の有効期限オプションをサポートしています。Google Gemini は、保存料金付きの明示的なコンテキストキャッシュをサポートしています。一方、DeepSeek は、キャッシュヒットとキャッシュミスの入力レートを分けた、ディスクベースの自動コンテキストキャッシュを文書化しています。節約効果を予測に織り込む前に、必ずプロバイダーの公式ドキュメントで最新のモデル対応状況と料金を確認してください。

ROI の誤り: 割引ではなくワークフローを測定すること

キャッシュ済みトークンの割引は、純粋な節約額と同じではありません。ワークフローでは、キャッシュ書き込み料金、保存料金、追加リクエスト、運用の複雑さ、またはチームがプロンプト構造を攻めすぎて最適化した場合の品質低下も発生する可能性があります。

重要な単位を測定します:

プロンプトキャッシュの純 ROI = 回避できた非キャッシュ入力コスト - キャッシュ書き込み/保存コスト - 実装および運用コスト

本番での意思決定では、その結果を承認済みの成果に結びつけます:

承認済みタスクあたりのコスト = 総リクエストコスト / 検証済み成功タスク

これにより、トークン支出は減っても、再試行、却下された出力、または人手によるレビューが増えるという誤解を招く結果を防げます。また、キャッシュを単独の請求テクニックとして扱うのではなく、より広い AI API コスト最適化 プログラムにプロンプトキャッシュを整合させます。

6 ステップのプロンプトキャッシュワークフロー

1. 実際にプレフィックスが再利用されるワークロードを見つける

直感ではなく、リクエストトレースから始めます。ワークフローごとにトラフィックをグループ化し、1 回のリクエストから次のリクエストまでで、冒頭から何入力トークンが同一のまま残るかを見積もります。

有力な候補には、通常 4 つの特性があります:

1. 大きな繰り返し入力: 再利用可能なプレフィックスが、動的なサフィックスに対して十分な比重を持っている。
2. 頻繁な再利用: 複数のリクエストが、プロバイダーの実効キャッシュ有効期間内に同じプレフィックスを参照する。
3. 安定した順序: システム指示、ツール、例、参照資料が同じ順序で表示される。
4. 低いカーディナリティ: アプリケーションが、ユーザーごとに固有のプレフィックスを作成するのではなく、管理可能な数のプロンプトバリアントを再利用している。

潜在性が高い典型的なワークフローには、安定したツールスキーマを持つコーディングエージェント、共有のナレッジパッケージに基づくサポートアシスタント、ドキュメントの Q&A セッション、繰り返し例を使うバッチ抽出、マルチターンのリサーチエージェントなどがあります。

適さない候補には、単発の短いプロンプト、非常に個別化されたプレフィックス、呼び出しごとにツール定義が変わるリクエスト、キャッシュエントリをほとんど再利用しない低ボリュームのジョブなどがあります。

各ワークフローについてベースライン表を作成します:

2. 静的コンテンツを動的コンテンツの前に置く

プロンプトキャッシュは通常、プロンプトの先頭からの一致に依存します。先頭付近にわずかな違いがあるだけで、その後のすべてに対する再利用を妨げることがあります。

プロバイダーとSDKが許す場合は、次の順序で配置してください:

1. 安定したシステム指示
2. 安定したポリシーと安全性ルール
3. 安定したツール定義
4. 安定した参考資料または例
5. 半固定の会話コンテキスト
6. 動的なユーザー入力と実行時の値

タイムスタンプ、リクエストID、ユーザー固有のラベル、ランダムな順序のJSON、または頻繁に変わる機能フラグをプロンプトの先頭付近に置かないでください。ツールスキーマを正規化し、構造化コンテンツを決定論的にシリアライズします。

これは、無関係なデータを巨大なプレフィックスにまとめてよいという意味ではありません。テナント境界、認可ルール、データ保持要件は維持してください。より安いプロンプトが、プライバシーや分離の失敗に見合うことはありません。

3. キャッシュIDと無効化ポリシーを定義する

プロバイダーがキャッシュを自動管理する場合でも、アプリケーションにはプロンプトのバージョンを明示的に把握する方法が必要です。

実用的なキャッシュIDには、次の要素を含められます:

workflow + prompt_version + tool_schema_version + knowledge_version + model_family

このIDをテレメトリで追跡します。指示、ツール契約、または参照データが変更されたら、該当するバージョンを増やします。そうすることでコスト変動の説明がしやすくなり、チームが想定された無効化をプロバイダー障害と混同するのを防げます。

ワークロードの挙動とプロバイダーのサポートに基づいて再利用ウィンドウを設定します。短命な対話エージェントなら、数分の再利用で十分な場合があります。定期的なリサーチワークフローでは、保存コストが入力の再処理より低い限り、より長い明示的キャッシュが正当化されるかもしれません。

4. ヒット、ミス、書き込み、承認済みの結果を計測する

少なくとも、各試行について次のフィールドを記録してください:

• プロバイダー、モデル、ワークフロー。
• プロンプトバージョンとキャッシュID。
• 提供される場合は、総入力、キャッシュ/読み取り、キャッシュ書き込み、出力トークン数。
• キャッシュヒット、または推定されたヒット状態。
• 入力、キャッシュ、出力、および総推定コスト。
• レイテンシ、ステータス、リトライ回数、フォールバック経路。
• 検証済みの成功、または受理されたタスクの結果。

利用可能な場合は、プロバイダーが返す使用状況フィールドを請求の真実のソースとして使用します。プロバイダーが明確なキャッシュヒットフラグを返さない場合は、キャッシュ済みトークン数または請求記録から慎重に推定し、その指標を推定値としてラベル付けしてください。

プロンプトキャッシュのテレメトリは、リトライやモデルフォールバックと同じトレースに含めるべきです。そうしないと、リトライの連続が成功したキャッシュ最適化のように見えてしまうことがあります。AI observability implementation checklist では、試行ごとのコストとアプリケーションの成果を結び付ける方法を示しています。

5. Savings と損益分岐点の使用量を計算する

プロバイダーの課金構造に合ったモデルを使用します。

割引された読み取りレートを伴う自動キャッシュの場合:

gross_savings = cache_read_tokens × (uncached_input_rate - cached_input_rate)
net_savings = gross_savings - incremental_operating_cost

書き込みと保存料金が発生する明示的キャッシュの場合:

net_savings = avoided_uncached_cost
            - cache_write_cost
            - cache_storage_cost
            - incremental_operating_cost

キャッシュ書き込みと読み取りで異なるトークン料金を課すプロバイダーまたはモデルの場合は、再利用可能な1つのプレフィックスのライフサイクルを計算します:

uncached_scenario = prefix_tokens × total_uses × uncached_rate

cached_scenario = prefix_tokens × cache_writes × write_rate
                + prefix_tokens × cache_reads × read_rate
                + storage_cost

prefix_net_savings = uncached_scenario - cached_scenario

cache_writes = 1 と仮定しないでください。プレフィックスの変更、エントリの期限切れ、ルーティング変更、または明示的な更新によって、別の書き込みが発生することがあります。

1つのキャッシュされたプレフィックスについて、再利用の損益分岐点数を見積もることができます:

break_even_reuses =
  (cache_write_cost + storage_cost + implementation_cost_per_entry)
  / savings_per_cache_read

次の整数の再利用回数に切り上げます。そのうえで、ミス、無効化、トラフィック変動の余裕を加えます。

ROIの計算例

あるワークフローに以下があるとします:

• 月間40,000リクエスト。
• 1リクエストあたり18,000入力トークン。
• 12,000トークンの安定したプレフィックス。
• 実効キャッシュヒット率70%。
• キャッシュなしの入力レートは100万トークンあたり3ドル。
• キャッシュありの入力レートは100万トークンあたり0.30ドル。
• 償却後のエンジニアリングおよび監視コストが月350ドル。

月間キャッシュ済みトークン:

40,000 × 12,000 × 70% = 336,000,000 cached input tokens

総節約額:

336 million × ($3.00 - $0.30) / 1 million = $907.20

月間の純節約額:

$907.20 - $350 = $557.20

このワークフローが32,000件の承認済みタスクを生み出す場合、キャッシュによる節約は承認済みタスク1件あたり約$0.017になります。規模が大きければ意味のある数字ですが、単に「キャッシュ済み入力の90%割引」と言うよりも結果はかなり控えめです。

上記のレートは説明用の例であり、現時点のプロバイダーの見積もりではありません。契約済みまたは公開されているレートに置き換え、該当する場合はキャッシュ書き込み、保存、地域別価格、サービス階層、ゲートウェイ料金も含めてください。

コピー可能なプロンプトキャッシュROIワークシート

ワークシートはワークフローとプロンプトバージョンのレベルで作成します。アカウント全体で集計したヒット率では、利益を生むキャッシュ1つと、多くの無駄なキャッシュを隠してしまう可能性があります。

次の式を使用します:

eligible_prefix_tokens = R × P
observed_cached_tokens = H × P

baseline_prefix_cost = eligible_prefix_tokens × U

observed_prefix_cost = (H × P × C)
                     + (W × P × CW)
                     + S

net_savings = baseline_prefix_cost - observed_prefix_cost - O

net_savings_per_accepted_task = net_savings / A

ドル/トークン、またはドル/100万トークンのように、一貫したレート単位を使用してください。プレフィックスの一部のみがキャッシュ済みとして報告される場合は、H × P をプロバイダーが報告したキャッシュ済みトークン総数に置き換えます。

1回のキャッシュ書き込みに対する損益分岐点の簡易計算

初回の書き込みが1回 בלבדで、個別の保存料がなく、その後の使用がすべてヒットである場合:

break_even_reads = (write_rate - uncached_rate)
                 / (uncached_rate - read_rate)

切り上げて次の整数回の読み取りにします。書き込みレートが通常の非キャッシュレートと同じであれば、最初に成功した再利用の時点で粗利益ベースの節約が発生します。書き込みにプレミアムがある場合は、追加の読み取りが必要です。実運用での損益分岐点は、ミス、無効化、保存、エンジニアリングコストを加味するとさらに高くなります。

6. 管理された実験で展開する

キャッシュは、測定可能な対照群を持つエンジニアリング変更として実行します。

1. 再利用率の高いワークフローを1つ選びます。
2. 評価セットと受け入れ基準を固定します。
3. 非キャッシュ時のコスト、レイテンシ、品質のベースラインを設定します。
4. 安定したプレフィックスのみを再構成します。
5. 本番トラフィックの一部をキャッシュ経路に流します。
6. ヒット率、承認済みタスクあたりのコスト、P95レイテンシ、エラー、フォールバックを比較します。
7. 運用コストを差し引いても節約が正である場合にのみ拡大します。

対照群と処理群は同等のトラフィックで実行します。可能な限り、モデル、サービスティア、最大出力、サンプリング設定、ツールセット、フォールバックポリシーは固定してください。そうしないと、モデルやルーティングの変更がキャッシュの効果と誤認される可能性があります。

広範囲に展開する前に、3つの意図的な無効化テストを実施します:

1. プロンプトのバージョンを変更し、古いキャッシュが新しいワークフローに誤って紐づけられていないことを確認します。
2. ツールスキーマを変更または並べ替え、結果として発生するミスがテレメトリで可視化されることを確認します。
3. 承認済みのフォールバック経路をトリガーし、キャッシュの喪失と増分コストがフォールバック試行に帰属していることを確認します。

リトライとフォールバックのポリシーは、キャッシュロジックとは分けて管理してください。失敗したリクエストは、安全に再試行できる場合もあれば、部分的なストリーミング後に再実行するのは危険な場合もあり、同等のモデルで処理した方がよい場合もあります。すべてのキャッシュミスやタイムアウトを同じ失敗として扱うのではなく、定義済みのモデルフォールバック戦略を使用してください。

7日間のプロンプトキャッシュROI監査

短期間の本番監査は、宣伝されているキャッシュ割引に基づく予測よりも信頼性があります。目的は、キャッシュが一般に機能することを証明することではありません。特定のワークフロー、プロンプトバージョン、モデルルート、保持ポリシーが、再現可能な価値を生み出すかどうかを判断することです。

1日につき1つの監査行を作成し、テスト期間中は非キャッシュのコントロールを継続して実行してください。平日と週末でトラフィックが異なる場合は、両方のパターンが現れるまでテストを延長します。混雑した処理日と静かな過去のベースラインを比較しないでください。

アカウント全体の平均ではなく、マッチしたコホートを使う

ワークフローIDとテナントIDのハッシュのような安定したルールを使って、比較可能なリクエストをコントロール群と処理群に割り当てます。これにより、顧客構成、プロンプト長、タスク難易度が結果を説明してしまう可能性を減らせます。失敗やリトライをコスト集計から除外しないでください。それらも本番経済の一部です。

少なくとも、監査は以下でセグメントしてください:

• ワークフローとプロンプトのバージョン。
• モデルとプロバイダーのルート。
• キャッシュ保持モードまたはTTL。
• プロンプトが実質的に異なる場合のテナントクラス。
• 成功、再試行、フォールバック、拒否出力の結果。

アカウント全体のキャッシュヒット率は監視には有用ですが、投資判断には弱い指標です。1つの大容量ワークフローが、継続的に書き込まれほとんど読み出されない何十ものキャッシュIDを隠してしまうことがあります。

信頼度とばらつきのチェックを追加する

1日だけのプラスの節約額をロールアウトのシグナルとして扱わないでください。日次の純節約額を算出し、合計だけでなく範囲も確認します。

daily_net_savings = daily_uncached_baseline_cost
                  - daily_observed_cached_cost
                  - daily_operating_cost

quality_adjusted_savings = daily_net_savings
                         / daily_accepted_tasks

主要な要約値として、日次の品質調整後節約額の中央値を使用し、そのうえで最悪日と、プラスを維持した日の割合を報告します。平均節約額は大きいものの、負の日が繰り返し発生するワークフローは、トラフィックの形状、期限切れのタイミング、またはフォールバック動作に敏感である可能性があります。

トラフィックが少ない場合は、監査を始める前に最小観測件数を定義してください。実用的なルールとしては、各コホートに通常の再試行、ミス、そして少なくとも1回の保持期限切れサイクルを含めるのに十分な受理済みタスクが集まるまで待つことです。正確な件数はワークフローのばらつきに依存するため、すべてのアプリケーションに統計的に有効な普遍的サンプルサイズとして提示するのは避けてください。

Go、修正、停止のルーブリック

開始前に損切りルールを設定してください。例としては、拒否出力の許容できない増加、エラー率の悪化、P95レイテンシーの大幅な増加、予期しないテナント間のキャッシュIDの混在、またはチームの予算許容値を超える日次支出の増加が挙げられます。損切り閾値は、一般的なブログのベンチマークではなく、製品既存のサービス目標とリスク方針から定めるべきです。

保持すべき監査記録

最終判断は、分断されたスプレッドシートではなく、プロンプトとルーティング設定の横に保存してください。有用な監査記録には、オーナー、実験日、プロンプトハッシュ、ツールスキーマハッシュ、モデルルート、使用レート、未加工の使用フィールドマッピング、受理済みタスク定義、除外条件、純節約額、ガードレール結果、判断、次回レビュー日が含まれます。

この記録は、価格設定、モデルバージョン、保持動作、またはフォールバックルートが変わったときに特に重要になります。書き込み、読み出し、保存、または受理済み結果に実質的に影響する前提が変わった場合は、判断を再度見直してください。

プロンプトキャッシュのKPIダッシュボード

次の指標をワークフロー別およびプロンプト版別に追跡してください。

高いヒット率でも削減効果が弱いことは、繰り返されるプレフィックスが小さい場合に起こりえます。低いヒット率でも大きなプレフィックスがあるなら、プロンプトの断片化を修正できれば価値ある機会を示している可能性があります。指標はまとめて読み取ってください。

一般的なプロンプトキャッシュの失敗モード

先頭に動的値がある

タイムスタンプ、ID、ユーザーごとのメタデータが先頭付近にあると、キャッシュが断片化します。可能な限り、安定したプレフィックスの後ろに移動してください。

リクエスト間でツールスキーマが変わる

エージェントはツール定義を動的に再構築したり、並び替えたりしがちです。順序を正規化し、不要なツールを削除し、スキーマを意図的にバージョン管理してください。

キャッシュエントリは書き込まれるが、ほとんど再利用されない

トラフィックが少ない場合やTTLが長すぎる場合、明示的なキャッシュ作成は節約額よりコストの方が大きくなることがあります。保持期間を延長する前に、キャッシュIDごとの再利用を測定してください。

チームがトークン最適化だけを行い、出力を無視する

出力トークン、リトライ、人手レビューが総コストの大部分を占めることがあります。リクエスト全体と受理された結果の測定を継続してください。

プロバイダーの挙動が他環境でもそのまま使えると仮定している

自動プレフィックスキャッシュ、明示的なブレークポイント、保存料金、最小プロンプト長、対象モデル、使用状況フィールドはプロバイダーごとに異なります。プロバイダーアダプターを構築し、ビジネス指標はプロバイダー非依存に保ってください。

フォールバックがキャッシュ局所性を破壊する

プロバイダーやモデルファミリーを切り替えると、キャッシュは移植できないため再利用が失われることがあります。これはフォールバックを無効にすべきという意味ではありません。信頼性とコストに共通のポリシーが必要だという意味です。必要時にはフェイルオーバーし、その後ミスと増分コストを正しく帰属させてください。

プロバイダー実装チェックリスト

すべての実装を1つのブール値 cache_hit フィールドに押し込むのではなく、プロバイダーアダプターを使用してください:

モデルでプロンプトキャッシュを有効にする前に、次を確認してください:

• キャッシュは自動、明示的、またはその両方ですか?
• どのモデルとAPIエンドポイントが対応していますか?
• 適用される最小プロンプト長はどれですか?
• 一致するプレフィックスはどのように定義されますか?
• どのTTLまたは保持オプションがありますか?
• キャッシュの書き込み、読み取り、保存は別々に課金されますか?
• キャッシュ済みトークンやキャッシュ作成を公開する応答フィールドはどれですか?
• サービスティア、リージョン、データレジデンシー、またはゼロ保持設定で挙動は変わりますか?
• キャッシュはプロジェクト、アカウント、組織、または別の境界ごとに分離されますか?
• リクエストが別のモデルやプロバイダーにフォールバックした場合、どうなりますか?

最新の実装詳細については、公式のOpenAI prompt caching guide、Anthropic prompt caching documentation、Google Gemini context caching guide、およびDeepSeek context caching guideを使用してください。料金とモデルの利用可否は変更される可能性があるため、重要なコストレビューのたびにこれらの情報源を再確認してください。

既存のOpenAIキャッシュダッシュボード向け2026年移行チェック

ダッシュボードがGPT-5.6対応より前のものである場合、キャッシュされていないプレフィックストークンをすべて通常の入力コストにまとめていないことを確認してください。対応するGPT-5.6リクエストでは、キャッシュ書き込みの使用量を別途確認し、保持モードを記録し、明示的なキャッシュ書き込みと自動キャッシュ読み取りを区別してください。cached_tokensのみを追跡するダッシュボードは、キャッシュ作成のレートが高い場合に節約額を過大評価する可能性があります。

AIゲートウェイが適する位置づけ

統一されたAIゲートウェイは、プロバイダーのキャッシュを移植可能にするものではありません。各プロバイダーが依然として独自のキャッシュの意味付けと課金を管理します。ただしゲートウェイは、モデルIDの正規化、対象ワークロードのルーティング、プロバイダー固有の使用量の記録、承認済みタスクあたりのコスト比較、フォールバックや予算ポリシーの適用を行う単一の場所をチームに提供できます。

Flatkeyは、1つのOpenAI互換エンドポイントと、複数のモデルファミリーへのアクセスのための統一残高を提供します。これにより、すべての統合を作り直すことなく、キャッシュありとキャッシュなしのワークフローをベンチマークしやすくなります。ルートをキャッシュ有効とみなす前に、選択したモデルの現在のキャッシュ対応状況とプロバイダーの挙動を確認してください。

既存のクライアントを先に統合する場合は、OpenAI互換APIゲートウェイ移行チェックリストを使用し、Flatkeyの現在のモデルアクセスと価格を確認してください。

よくある質問

プロンプトキャッシュでどれくらい節約できますか？

節約額は、再利用可能なプレフィックス、ヒット率、プロバイダーの料金、書き込みまたは保存料金、実装コストによって異なります。すべての入力トークンに見出しの割引を適用するのではなく、実際に観測されたキャッシュ済みトークンに基づいて純節約額を計算してください。

損益分岐点に達するには、どれくらいのキャッシュヒットが必要ですか？

それは、書き込みプレミアム、読み取り割引、保存料、運用コストによって異なります。書き込みが通常のキャッシュ未使用レートで課金され、保存料がない場合、最初の成功した読み取りで総トークン節約が発生します。プレミアムな書き込みや有料保持には、より多くの再利用が必要です。選択したモデルについて、正確な料金と実際のキャッシュ書き込み回数から損益分岐点を計算してください。

どのキャッシュヒット率が良いですか？

万能の目標はありません。有用なヒット率とは、純節約がプラスになり、承認済みタスクあたりのコストを改善または維持できるものです。大きなプレフィックスは低いヒット率でも正当化できる一方、小さなプレフィックスでは非常に高い再利用が必要になる場合があります。

プロンプトキャッシュはレイテンシを改善しますか？

キャッシュヒット時の入力処理レイテンシを短縮できる場合がありますが、その効果はプロバイダー、モデル、プロンプトサイズ、ネットワーク経路、ワークロードによって異なります。固定された改善を想定するのではなく、P50 と P95 のレイテンシを追跡してください。

会話全体をキャッシュすべきですか？

通常は、すべてを無条件にキャッシュするのではなく、安定したプレフィックスを最大化すべきです。会話のターンは増え、変化します。安定した指示、ツール、参照コンテンツを前方に置き、その後に変化する履歴とユーザー入力を追加してください。

キャッシュ済みプロンプトはプロバイダー間で共有できますか？

いいえ。プロバイダー側のプロンプトキャッシュはプロバイダー固有です。ルーティングによってプロバイダーやモデルが変わる場合、プロバイダーが明示的に互換再利用を文書化していない限り、そのリクエストはキャッシュミスである可能性が高いものとして扱ってください。

プロンプトキャッシュは機密データに対して安全ですか？

ご利用アカウントとモデルについて、プロバイダーのデータ処理、キャッシュ分離、保持、データ所在、およびゼロ保持の条件を確認してください。コスト最適化を、セキュリティ、プライバシー、またはテナント分離要件の回避に使わないでください。

1つの繰り返しプレフィックスから始める

最適なプロンプトキャッシュのワークフローは意図的に狭く設定します。つまり、コストの高い再利用頻度の高いワークロードを1つ選び、安定したコンテンツを先頭に移し、バージョン管理し、ヒット、ミス、レイテンシ、品質、コストを測定し、そのうえで純ROIを計算します。

結果が承認済みタスクあたりのコストを改善するなら、次のワークフローへとパターンを拡張します。改善しない場合でも、テレメトリによって、問題がプロンプトの断片化、ボリューム不足、保持期間の短さ、プロバイダー価格、あるいはそもそもキャッシュ候補として適していなかったワークロードのどれなのかが分かります。