Prompt 結果の再利用をAI運用へ組み込む境界

Prompt CacheはLLM入力prefixの再処理を減らし、latencyとinput costを改善し得るoptimization layerです。ただし、cache hitは会話memory、正本、監査証跡、同一出力の保証ではありません。cache missやexpiryが発生しても業務が正しく動く設計を基準にしてください。

OpenAI、Anthropic、Google Gemini、Amazon Bedrockはいずれもprompt/context cachingを提供しますが、cache eligibility、prefix matching、breakpoint、minimum token、TTL、retention、usage accountingはprovider・model・APIごとに異なります。

OpenAIのcurrent GPT-5.6+ prompt cachingでは、full rendered prefixの一致がreuse条件となり、model、tool definitions/order、reasoning/output settings等の変更がreuseへ影響し得ます。Anthropicはtools、system、messagesの順でbreakpointまでのprefixをcache対象にします。Geminiはimplicit cachingとdeveloper-managed explicit cachingを区別します。Bedrockもmodel/APIごとにimplicit/explicit supportとTTLが異なります。

「cache enabled」と「cache hit」を分離してください。各requestでprovider/model/API/cache mode、prefixまたはapplication version、cache read/write tokens、total input、request timestamp、latencyを記録し、hit率と実コストを観測します。stable contentをprefix側へ置き、動的timestamp、user-specific content、頻繁に変わるtool/schema等はreuse境界を壊さない位置へ分離します。

TTLとdata-retention policyを同一視しないでください。Geminiではexplicit cached contentはuser-defined TTL/expire timeを持つ保存対象で、absolute zero-data footprintでは使用しないよう案内されています。一方、implicit in-memory cachingは別のstorage semanticsです。OpenAI等もmodel・organization policyによってretention条件が異なり得るため、exact account/APIで確認します。

prefix mutation、tool schema/order変更、model/API/version変更、reasoning/output設定変更、expiry、capacity/routing miss、region boundary、implicit-cache miss、低reuse、first-write/storage cost、agent tool-loop追加write、compaction/truncation、sensitive content retention、metrics欠落、cacheをdurable memoryと誤認することを想定します。

Cache read単価だけで採否を決めません。minimum cacheable length、cache write/storage cost、reuse回数、miss率、TTFT、rate-limit semanticsを含めて実測します。shared prefixが存在してもhitは保証されないため、usage telemetryを正とします。

本項は2026-10-05時点のprovider public documentationに基づくdesk researchです。対象organizationでのlive cache experiment、billing validation、ZDR/data-residency contract確認は未実施です。

Prompt Cacheは性能・コスト最適化層です。正本・memory・監査ログとして扱わず、cache hitを同一出力保証と解釈しません。provider/model/APIごとにcache semanticsをversioned configurationとして管理し、実際のhit/write/missをresponse usageから観測してください。

対象organizationのprovider/model/API構成、ZDR/data-residency契約、retention default、regional routing、実測hit/miss率、prefix変更頻度、tool-schema churn、契約単価、sensitive promptのexplicit cache可否は未確認です。

Prompt Cacheの存在やhitだけをdurability、reproducibility、privacy compliance、output determinismの証拠にしないでください。tenant固有保証が必要な場合はexact API/accountでruntime testとpolicy readbackを追加します。

旧EA-233候補のPrompt Cache研究を、登録済みEA-1010へ引き継ぎました。正規EA-233のEdge Workers記事とは別物です。元候補と元Evidence Packetは改変せず保持しています。

2026-10-16に各社の公開資料を再確認しました。prefix再利用と出力同一性、cache有効化と実際のhit、TTLとretentionを分離する原則は維持します。Google Generate Contentの資料にはexplicit cacheを利用できないモデルもあり、製品名だけで全モデル・全APIの対応を推定しません。モデル、API、region、組織契約ごとのAvailability Gateを先に確認します。

再確認は公開仕様の範囲です。実tenantでのhit率、請求、ZDR契約、削除完了、隔離の実証には進めていません。元のOPEN_UNKNOWNを解消済みと扱いません。

• OpenAI: https://developers.openai.com/api/docs/guides/prompt-caching
• Claude: https://platform.claude.com/docs/en/build-with-claude/prompt-caching
• Google Generate Content: https://ai.google.dev/gemini-api/docs/generate-content/caching
• Google ZDR: https://ai.google.dev/gemini-api/docs/zdr
• Amazon Bedrock: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html

元資料: Library libfile_e06afad45b38819199e56ece6654bf5e; ZIP libfile_e22819cdb91881919b58503cfcb5dcfd。元payload SHA-256: e4f20f3e81c966cb0d2d8ae51f203bfb4d52bc276c025ce3905613c57f8b5d26。