# プロンプトキャッシュでコーディングエージェントのコストが実際に下がるのはいつですか？ > 多くのリクエストが十分に大きくバイト単位で安定したプレフィックスを再利用し、プロバイダーのキャッシュ読み取りによる節約が複雑さとミスのコストを上回る場合、プロンプトキャッシュはコーディングエージェントのコストを下げます。すべての反復指示が割引されると仮定せず、実際の使用記録からキャッシュ済み入力を測定してください。 プロンプトキャッシュが有効なのは、エージェントが同じ大きな先頭部分を繰り返し送る場合であり、人間から見てプロンプトが似ているだけの場合ではありません。先頭近くのタイムスタンプ、並び替えられたツール一覧、変化するワークスペース要約、生成されたリクエストIDは、それ以降の再利用を壊す可能性があります。 プロンプトを再設計する前に、実際のリクエストの使用量メタデータを確認します。対象となる入力トークン数、キャッシュ読み取りとして報告された数、プレフィックスの変更頻度、選択モデルとプロトコルがキャッシュ効果を提供するかを把握してください。 ## 非キャッシュ時の基準をモデル化する キャッシュは出力トークンやツール実行を減らさないため、入力コストから始めます。 ```text uncached_input_cost = requests * input_tokens_per_request * input_rate ``` 料金単位は通常100万トークン当たりで統一します。記憶している割引率を使わず、対象モデルの最新料金ページと使用量フィールドを参照してください。 | 要素 | リクエスト間で安定しているか | 想定配置 | |---|---|---| | システムポリシー | 通常は安定 | 先頭 | | ツールスキーマ | 通常は安定 | 前方 | | リポジトリ規約 | 多くの場合安定 | 前方 | | タスクチェックポイント | 場合による | 中間 | | ユーザーリクエスト | ほぼ変化 | 後方 | | ライブツール出力 | 不安定 | 最後 | ## 記号を使って損益分岐を計算する `P` を安定プレフィックスのトークン数、`R` を総リクエスト数、`W` をキャッシュ書き込み単価、`H` をキャッシュ読み取り単価、`U` を通常の非キャッシュ入力単価とします。 ```text uncached = R * P * U cached = P * W + (R - 1) * P * H savings = uncached - cached ``` これは初回以降がすべてヒットする理想例です。測定ヒット率を `h` とする場合、後続リクエスト項を `H` と `U` の加重平均に置き換えます。プレフィックス外のトークンは両側に通常単価で加えます。 ミスと開発負担を含めても節約が正の場合だけ、経済的な価値があります。 ## 安定した内容を先頭に置く 安定から可変の順に構成します。 * システム指示と安全指示。 * 決定的な順序のツール定義。 * リポジトリ規約と永続的な参照文。 * 簡潔なタスクチェックポイント。 * 現在のユーザーリクエスト。 * 最新のツール出力。 スキーマは決定的にシリアライズします。プレフィックス内のランダムな順序、空白の書き換え、タイムスタンプ、リクエスト固有コメントを避けます。安定バンドルには意図的にバージョンを付け、実際の変更によるミスを説明可能にしてください。 ## 大きさだけでなく有用性を保つ 肥大したプレフィックスはキャッシュ読み取り数を増やしても、総トークンとモデルの注意散漫を増やします。古いツール、重複ポリシー、現在のタスクに無関係な参照ファイルを削除してください。 ヒット率だけでなく、成功したコーディング成果当たりのコストを測ります。短い非キャッシュプロンプトが少ないターンで解決するなら、キャッシュされた冗長なプロンプトより優れています。 ## リクエストと成果を計測する モデル、プロトコル、プレフィックス版、総入力トークン、利用可能ならキャッシュ済み入力トークン、出力トークン、レイテンシー、ツール呼び出し数、再試行、タスク結果を記録します。取得できないフィールドはゼロではなく「利用不可」とします。 | 指標 | 重要な理由 | |---|---| | キャッシュ済みトークン比率 | 実際に再利用されたことを確認 | | ミス理由 | 意図しないプレフィックス変動を特定 | | タスク当たりリクエスト数 | 節約を消すループを発見 | | 採用変更当たりコスト | トークンと有用な作業を接続 | | 再試行率 | キャッシュ外の信頼性コストを発見 | 合成プロンプトを100回繰り返すより、代表的なタスクを1週間測定する方が有用です。 ## ルーティングとセッション境界に注意する キャッシュ挙動はモデル、プロバイダー、地域、保持期間、ルーティングに依存します。ゲートウェイやフォールバックにより、同じ温まったプレフィックスを持たない経路へ移ることがあります。キャッシュ性能は選択経路で観測した特性として扱います。 Atlas Cloudは1つのAPIで複数のLLM形式を提供しますが、公開プロトコルガイドは普遍的なキャッシュ割引を約束していません。コストを主張する前に現在のモデルとコンソールを確認します。互換形式の選択には[LLMプロトコル](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs)、最新モデル情報には[モデルカタログ](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs)を使ってください。 ## 見せかけの節約を避ける 入力項目が安くても、追加ターン、失敗したツール呼び出し、繰り返すコンテキスト再構築が隠れている場合があります。キャッシュ読み取りとアプリケーション層の保存・検索も区別してください。解決する問題が異なります。 キャッシュされる可能性があるからといって秘密情報を含めてはいけません。プロバイダーのデータ制御と自社の保持要件に従います。キャッシュ設計はアクセス制御の代わりではありません。 ## 実用的な採用ゲートを使う 次の条件を満たす場合に導入します。 * 安定プレフィックスに意味があり、頻繁に再利用される。 * 実際の使用量がキャッシュ読み取りを報告する。 * 観測したミス率を含めても節約できる。 * プレフィックスのバージョン管理が単純で決定的である。 * タスク品質とターン数が悪化しない。 満たさない場合は、まずプロンプトを短くし、関連ファイルだけを取得し、エージェントループを短縮します。 ## 結論 プロンプトキャッシュがコストを下げるのは、大きく有用でバイト単位に安定したプレフィックスが、安いキャッシュ入力を報告する経路で十分に再利用される場合です。安定内容を先頭に置き、現在単価で損益分岐を計算し、実際のタスクを計測して、採用変更当たりのコストを確認してください。プロンプトが不必要に大きい、またはターン数が増えるなら、高いヒット率でも成功ではありません。 ## FAQ ### プロンプトキャッシュに最も適した内容は？ 安定したシステム指示、ツールスキーマ、リポジトリ規約、ほとんど変わらない参照資料は、ライブログや最新のユーザーメッセージより適しています。 ### 可変内容を安定プレフィックスの後に置くのはなぜですか？ プレフィックスキャッシュは通常、完全に一致する先頭部分に依存します。タイムスタンプ、リクエストID、変化するコンテキストを前方へ置くと、その後の安定内容までミスになります。 ### プロンプトキャッシュは常にレイテンシーを下げますか？ いいえ。効果はプロバイダー実装、キャッシュ状態、ルーティング、モデル、リクエストサイズ、負荷に左右されます。レイテンシーとコストは別々に測定してください。 ### 損益分岐点はどう計算しますか？ 想定再利用回数における非キャッシュ入力コストと、キャッシュ書き込み・読み取りコストを比較し、開発コストとミス率も加えます。 ### ツール定義はキャッシュできますか？ プロバイダーと選択プロトコルがキャッシュ対象に含める場合、反復プレフィックスの一部になり得ます。推測せず使用量メタデータで確認してください。 ### コーディング会話全体をキャッシュすべきですか？ 通常は不要です。会話は毎ターン変化します。安定した指示とスキーマを先頭に置き、その後に簡潔なチェックポイントと現在のリクエストを追加してください。