AI エージェントのキャッシュヒット率が崩れる理由：GPT、Claude、監査可能なゲートウェイ
第三者エージェントのキャッシュ失敗、GPT と Claude の prompt caching、再現可能な測定、Modelflare の公開補償境界を一次資料で解説します。
AI エージェントのキャッシュは、設定画面のチェックボックスではありません。プロトコル、ルーティング、会計で構成される契約です。本稿では、上流モデルが prompt caching に対応していても第三者エージェントのキャッシュヒット率が極端に低くなり得る理由、GPT と Claude の再利用と計測の違い、監査可能なゲートウェイが保証すべき条件を説明します。
結論を一文で
本番でキャッシュ経済性に依存するエージェントを、ネイティブな使用量を返さず、安定したプレフィックスを保持せず、モデルとルートの親和性を維持せず、TTL と分母を示さず、永続的な台帳と照合できない第三者エージェント／ゲートウェイの背後に置かないでください。「キャッシュ対応」は機能の主張であり、適格トラフィックの実測ヒット率が運用上の事実です。
これは、すべての第三者エージェントが失敗するという意味ではありません。固定コーパス、固定モデル、明確な観測期間、リクエスト単位の使用量証拠がなければ、公開資料からベンダー全体の割合を証明できません。より限定した結論は、不透明な変換層が複数の独立した切断点を作り、有効なプロバイダーキャッシュをほぼ毎回コールドな経路に変えてしまうことです。キャッシュ依存の本番トラフィックでは、証拠を提示できないこと自体が採用しない理由になります。
パーセンテージの前に分母を定義する
プロバイダーは通常、三つの異なるバケットを返します。R はキャッシュから読み出した token、W は書き込んだ token、U は再利用されずに処理された入力 token です。キャッシュ対象となるプレフィックスの比較可能なヒット率は次のとおりです。
eligible_hit_rate = R / (R + W)
モデルへ送った全入力に対する再利用率は次のとおりです。
input_reuse_share = R / (R + W + U)
この二つは別の問いに答えます。全入力を分母にするダッシュボードは、短く適格でないリクエストが多いと低く見えます。適格トラフィックだけを分母にするダッシュボードは、動的なサフィックスが費用の大部分を占めている事実を隠せます。両方の値、適格性ルール、観測期間を示してください。
証拠はエージェント画面の緑色バッジではなく、プロバイダーのフィールドです。
| シグナル | OpenAI フィールド | Claude フィールド | 証明できること |
|---|---|---|---|
| 再利用されたプレフィックス | input_tokens_details.cached_tokens |
cache_read_input_tokens |
一致したエントリから提供された token |
| 新しいキャッシュエントリ | input_tokens_details.cache_write_tokens |
cache_creation_input_tokens |
エントリ作成・延長に使った token |
| 再利用されない入力 | input_tokens - input_tokens_details.cached_tokens - input_tokens_details.cache_write_tokens（慎重に導出） |
breakpoint 後の input_tokens |
キャッシュプレフィックス外の入力。意味は異なる |
| 相関情報 | request ID、モデル、ルート | request ID、モデル、ルート | 使用量を生成したプロバイダー試行 |
合成例であり、Modelflare の本番テレメトリではありません。R=720,000、W=80,000、U=200,000 なら、適格ヒット率は 720,000 / 800,000 = 90% ですが、全入力の再利用率は 720,000 / 1,000,000 = 72% です。一つの数値だけを公開すると分母が隠れます。
input_tokens_details.cache_write_tokens=0 は「キャッシュなし」の証明ではありません。読み取りリクエストは新しいエントリを作らないからです。第三者レスポンスに使用量フィールドがない場合もゼロではなく、監査不能として記録すべき観測性の失敗です。
モデルが対応していてもエージェント経路がヒットを失う理由
原因はアプリケーションとプロバイダーの間にあることが多く、主な切断点は次のとおりです。
- 動的なバイトが早すぎる。 timestamp、request ID、ユーザー、実験フラグ、変化する現在日付が、再利用する指示より前のプレフィックスを変えます。
- ツールが再シリアライズされる。 ツール schema の追加・削除・並べ替え・非決定的なシリアライズは完全一致するプレフィックスを変えます。JSON キーの順序だけでも miss になります。
- フォールバックがキャッシュの識別子を変える。 モデル alias、リージョン、組織、資格情報をまたぐ負荷分散は一つの共有エントリを使いません。
- アダプターがネイティブ制御を落とす。
cache_control、prompt_cache_key、保持設定、使用量詳細を削ると、機能が見えない best effort になります。 - プロンプトが閾値未満。 短いターンは有効なリクエストでもキャッシュ対象外になり得ます。
- TTL を越える。 Claude の五分エントリやモデル依存の OpenAI 保持期間は、人間の確認待ちの間に期限切れになります。
- 並列ウォームアップの競合。 最初のレスポンスがエントリを利用可能にする前に、並列リクエストが到着します。
- 履歴が書き換えられる。 要約、圧縮、切り詰め、別のシリアライズは末尾への追加ではなくプレフィックスを変えます。
これらの失敗に悪意は必要ありません。エージェントのリクエストを自由なテキストとして扱い、プロバイダーのキャッシュ契約を保持しないゲートウェイから予測可能に発生します。実務上の警告は明確です。どの breakpoint が失敗したかを示せないエージェントでは、キャッシュ依存トラフィックの価格と障害を正しく扱えません。
GPT と Claude は似た考え方でも意味は同じではない
どちらも完全一致する再利用プレフィックスを要求しますが、制御面と使用量の意味は異なります。下表は 2026-08-25 に確認した公式ガイドに基づきます。モデル名、最小長、保持期間は変わり得ます。
| 項目 | OpenAI prompt caching | Claude prompt caching |
|---|---|---|
| 再利用単位 | 指示、ツール、履歴、マルチモーダル部分を含む、レンダー済みコンテキスト全体のプレフィックス | cache_control breakpoint までの順序付きプレフィックス：tools、system、messages |
| 最小長 | 現行ガイドは GPT-5.6+ で可視 1,024 token、旧モデルは通常 2,048 | モデル別に約 512–4,096 token。短い入力はキャッシュされない |
| 制御 | 暗黙キャッシュ。対応モデルでは明示 breakpoint と安定した prompt_cache_key |
トップレベル自動キャッシュまたはブロック breakpoint。最大四つ、20 ブロック lookback |
| 保持 | GPT-5.6+ は 30 分 TTL。旧モデルはプロバイダー定義の代表的な保持モード | デフォルト五分、利用ごとに更新。一時間 TTL は書き込み価格が高い |
| 価格形状 | 現行 GPT-5.6+ ガイドでは書き込み 1.25 倍、読み取り 0.1 倍 | 五分書き込み 1.25 倍、一時間書き込み 2 倍、読み取り 0.1 倍 |
| 使用量の証拠 | input_tokens_details.cached_tokens と、該当時の input_tokens_details.cache_write_tokens |
cache_read_input_tokens、cache_creation_input_tokens、breakpoint 後の input_tokens |
| よくある無効化 | モデル・ツール・設定の変更、マシン overflow、breakpoint 前の変更 | モデル・system・ツール・メッセージの変更、前メッセージ不在、並列ウォームアップ miss |
OpenAI はキャッシュエントリが個々のマシンにあると説明しています。prompt_cache_key はグループ化とルーティングを助けますが、マシンを固定せず、ヒットを保証しません。Claude は完全一致、workspace 単位の分離、tools_changed や messages_changed などの診断を文書化しています。違いを隠すゲートウェイは、プロバイダー資料を一つの率に変換して保証することはできません。
価格倍率を見ると影響が分かります。引用した OpenAI モデルでは、書き込み一回の後に読み取り一回を行うキャッシュ部分は、非キャッシュ入力の約 1.25 + 0.10 = 1.35× です。十回完全再利用なら 1.25 + 9×0.10 = 2.15× で、10× ではありません。これは公式の説明用計算であり、Modelflare の請求額や全モデルの保証ではありません。
アダプターのコストは測定できる
スクリーンショットではなく故障マトリクスを使います。プロンプト、モデル、資格情報、速度を固定し、一度に一つだけ変え、ネイティブな usage オブジェクトを保存してください。
| 制御した変更 | 期待されるシグナル | 不透明なエージェントが隠せるもの | リリース判断 |
|---|---|---|---|
| ユーザーターンだけ追加 | 最初の W の後に R が上昇 |
履歴の書き換えや新ルート | プレフィックス保持 |
| system prompt に timestamp を追加 | R がゼロ、または新しい W |
変化したバイト | 動的プレフィックスは破壊要因 |
| ツール属性を一つ並べ替え | tools_changed または新しい書き込み |
シリアライザーの挙動 | schema は決定的にする |
| alias やマシンへ分散 | R が低く変動 |
選択ルートとキャッシュキー | 親和性がない |
| 文書化 TTL を超えて待機 | 期限後に新しい書き込み | 期限時刻と保持モード | 人間の待ち時間を別測定 |
| 同じ最初のリクエストを二つ並列送信 | 片方または両方が書き込む可能性 | ウォームアップ競合と順序 | コールド burst は容量を示さない |
request ID、ストリームモード、最初のイベント時刻、正確なモデル、選択ルート、キャッシュフィールド、UTC 時刻を保存します。プロンプト、鍵、顧客コンテンツはマスクします。ゲートウェイが正規化された入力合計しか返さない場合は、試験を監査不能と記録し、不足した次元を作り上げたゼロにしないでください。
再現可能な監査レコード
次は小さな合成フォーマットです。外側はプロバイダーに依存せず、usage 内にはネイティブフィールドを残します。ベンチマーク結果ではありません。
{"request_id":"demo-001","timestamp":"2026-08-25T02:00:00Z","model":"MODEL_ID","route":"route-a","stream":true,"usage":{"input_tokens":1000000,"input_tokens_details":{"cached_tokens":0,"cache_write_tokens":1000000}}}
{"request_id":"demo-002","timestamp":"2026-08-25T02:00:03Z","model":"MODEL_ID","route":"route-a","stream":true,"usage":{"input_tokens":1000000,"input_tokens_details":{"cached_tokens":720000,"cache_write_tokens":80000}}}
最低五段階を実行します。直列ウォームアップ、追加だけの会話、動的 system 変更、ツール順序変更、TTL 間隔後の再生です。各プロバイダーのネイティブな読み取り／書き込みフィールドを保持し、フェーズ、ルート、モデル、UTC 日ごとに R/(R+W) と R/(R+W+U) を比較します。混ぜた一つの数字だけでは本番採用を決められません。
Modelflare が保証すること、しないこと
Modelflare の公開ステータスページは現在 OpenAI Cache Hit Rate Guarantee を説明しています。OpenAI のキャッシュ要件を満たし有効なキャッシュを形成する適格リクエストについて、日次率を UTC の暦日で計算します。適用ティアを下回った場合は差分を補償し、Dashboard → Token Usage Analysis に表示します。公開されているティアは現在 65%、75%、85% です。
境界は意図的なものです。
- 保証対象は適格で有効な OpenAI キャッシュトラフィックであり、短い入力や常に変化して条件を満たさないリクエストではありません。
- 変化するモデル、ツール schema、ルート、TTL を自動的に再利用可能なプレフィックスにはしません。
- UTC の暦日単位で計算し、文書化されたアカウント画面へクレジットします。各リクエストのヒットを約束するものではありません。
- ネイティブ使用量と適格性計算は必要です。分母が明示されるからこそ補償を検証できます。
これが監査可能なサービス約束と第三者エージェントのスローガンの違いです。前者は対象母集団、期間、閾値、クレジット先を明示します。
価格の優位性と運営の正当性は別の証拠
公開価格ページには、適用キャンペーン／グループの 初回チャージ 0.015 プロモーション比率と、公開された最低額・条件も表示されています。これは価格特典であり、キャッシュ保証とは別です。購入前にライブページでモデル範囲と精算規則を確認してください。
公開の信頼・法務資料は Havenbyte LLC を運営主体として示し、米国を拠点とする運営と説明しています。また支払い、請求書、返金、不正対策の処理に Stripe を記載しています。これは責任と資金管理の手掛かりであり、特定州の登録や認証を主張するものではありません。
本番エージェントへの推奨
次のチェックリストを通過する第三者エージェントだけを選びます。
- プロバイダーのネイティブなキャッシュ制御を転送し、ネイティブな読み取り／書き込みを返す。
- 安定した指示・ツールプレフィックスのバイト列を同一に保ち、動的状態を後ろへ追加する。
- モデル、ルート、組織／地域境界、TTL モード、request ID を公開する。
- 直列と並列のウォームアップを平均せず別々に記録する。
- 適格トラフィック、分母、UTC 期間、閾値、補償を文書で定義する。
- 鍵や顧客内容を漏らさず、リクエスト単位の証拠をエクスポートできる。
一つでも「いいえ」なら、再利用の経済性に依存する workload にその経路を使わないでください。まずプロバイダー直結で比較し、または Modelflare のような監査可能なゲートウェイを同じコーパスで検証します。関連項目は 信頼できる AI API ルーティング、AI API コスト追跡、価格、信頼センター です。
ソースと確認日
次の一次資料を 2026-08-25 に確認しました。プロバイダーの契約と Modelflare の現在の公開方針を示しますが、名前のない第三者エージェントの普遍的なヒット率を証明するものではありません。
- OpenAI Prompt Caching ガイド
- OpenAI API 料金
- Anthropic Prompt Caching ガイド
- Anthropic キャッシュ診断
- Modelflare ステータスとキャッシュ保証
- Modelflare 料金と現在の条件
- Modelflare の信頼性と運営主体
FAQ：第三者の低いヒット率は必ず詐欺ですか？
いいえ。短いプロンプト、変化するプレフィックス、分散ルート、TTL 切れ、欠落フィールドが原因かもしれません。制御試験で原因を特定するまでは「再現不能」または「監査不能」と記録します。
FAQ：Claude と GPT を一つの数字で比較できますか？
分母を正規化し、双方のネイティブフィールドを残した場合だけです。同じコーパスとフェーズを比べ、混合ダッシュボードの合計を比べないでください。
FAQ：補償があれば安定したプレフィックスは不要ですか？
いいえ。補償は適格な OpenAI キャッシュトラフィックの金銭的下振れを抑えますが、不適格なリクエストを再利用可能にはせず、プレフィックスを書き換えるエージェントも修復しません。