プロンプトキャッシュを解説：GetVibeで節約効果を測定する

コーディングエージェントやマルチターンアシスタントは、同じシステムプロンプト、ツール定義、会話の先頭部分を繰り返し送信することがよくあります。キャッシュを利用すると、繰り返される入力トークンをより安価にできますが、モデル、エンドポイント、リクエスト形式が対応している場合に限られます。生成された出力は割引対象になりません。また、似たテキストを繰り返すだけでは、キャッシュキーが変わる場合に十分ではありません。このガイドでは、OpenAI形式の自動キャッシュと、Claudeの明示的なブレークポイント動作を分けて説明します。

請求額はどう変わりますか？

キャッシュ読み取りは、通常の入力料金ではなく、キャッシュ入力料金で課金されます。GetVibeのモデルカタログには、モデル料金とともにキャッシュ対応状況とキャッシュ料金が掲載されています。2026年10月3日に確認したカタログのスナップショットには、GPT-6 Lunaの$0.0055 入力 · $0.0274 出力 100万トークンあたりやClaude Sonnet 5.5の$0.168 入力 · $0.84 出力 100万トークンあたりなどが含まれています。これらの価格値は、最新のモデルページから表示されます。そこに記載されたキャッシュの詳細も確認してください。すべてのモデルで同じ倍率や書き込みポリシーが使われるとは限りません。

繰り返されるプレフィックスの簡単な見積もりは、繰り返される入力トークン数に通常の入力料金を掛けた場合と、繰り返される入力トークン数にキャッシュ読み取り料金を掛けた場合を比較します。その差が、入力に関して得られる可能性のある節約額です。モデルによってキャッシュ書き込み料金が発生する場合は、その分を差し引いてください。この見積もりを実測値に変えるには、実際のリクエスト使用量が必要です。

OpenAI互換モデル：プレフィックスを安定させる

対応するOpenAIファミリーのルートでは、キャッシュは自動的に行われます。通常のChat Completionsリクエストに追加するcache-controlフィールドはありません。繰り返される先頭部分は同一に保つ必要があります。システム指示、安定した例、ツール定義は、ユーザー固有の値より前に配置してください。タイムスタンプ、ランダムID、リクエストごとの機能フラグを先頭に置くことは避けてください。ツールの順序は決定的に保ってください。

同じプレフィックスの一致を期待する場合、エージェントセッションを継続するときに以前の会話ターンを書き換えないでください。新しいターンを追加します。モデルを切り替えると、別のモデルキャッシュが開始されます。リクエストが有効であっても、プレフィックスがモデルのキャッシュしきい値を下回っている場合や、キャッシュの有効期限が切れている場合は、キャッシュ済みトークンがないと報告されることがあります。

Claude：ブレークポイントとMessagesエンドポイント

Claudeのキャッシュでは、cache-controlブレークポイントを使用します。GetVibeの統合では、対応するClaudeリクエストにブレークポイントがない場合、ブレークポイントを挿入できます。自分でブレークポイントを管理する場合は、最新のキャッシュのドキュメントを確認し、安定したセクションにマーカーを配置してください。Claude CodeはAnthropic Messagesエンドポイントを使用します。Claude Code統合ガイドでは、ベースURLと認証情報について説明しています。

curl https://getvibeapi.com/v1/messages \
  -H "x-api-key: $GETVIBE_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-5.5",
    "max_tokens": 300,
    "system": [{"type":"text","text":"Stable instructions shared by every request."}],
    "messages": [{"role":"user","content":"A request-specific question."}]
  }'

この例では、安定したシステムセクションと、変化するユーザーメッセージを示しています。クライアントとモデルでサポートされる正確なブレークポイントフィールドについては、最新のドキュメントを使用してください。

キャッシュヒットを想定せずに検証する

同じ長いプレフィックスを2回送信し、短いサフィックスだけを変更します。レスポンスの使用量を確認してください。OpenAI形式のレスポンスでは、キャッシュ済み入力がprompt_tokens_details.cached_tokensに報告されます。Anthropic形式のレスポンスでは、キャッシュ読み取りとキャッシュ作成のフィールドが公開されます。アカウントの使用量ページにもキャッシュ情報が表示されることがあります。これらのカウントが0のままの場合は、プレフィックスの一致、キャッシュ可能な最小長、モデルの対応状況、選択したルートを変更していないかを確認してください。

モデルのキャッシュしきい値を超えるのに十分な大きさのサンプルを使用してください。1文だけのシステムプロンプトでは、目に見える違いが生じない場合があります。キャッシュの有効期間やリクエストのスケジューリングによってプレフィックスがまだウォームな状態かどうかが変わるため、複数回の繰り返し呼び出しを比較してください。

実用的な節約効果のテスト

再利用可能なプレフィックスが十分に大きい、実際のプロンプトを1つ選びます。
通常の入力使用量と、現在のモデルページに記載された料金を記録します。
ユーザーのサフィックスだけを変更して繰り返します。
レスポンスにキャッシュ済み入力が報告されることを確認します。
繰り返したリクエストの台帳上のコストを比較します。

出力の支出によって入力の変化が見えにくくならないよう、実験中は出力長を同程度に保ってください。キャッシュ倍率だけを根拠に節約を主張しないでください。キャッシュヒット数と請求対象の使用量を確認してください。

よくあるキャッシュミス

安定した指示より前にタイムスタンプやリクエストIDがある。
リクエストごとにツール定義が異なる順序でシリアライズされている。
アプリケーションが空白を変更したり、履歴を異なる方法で切り詰めたりしている。
ターンの途中でモデルが変わっている。
プレフィックスが短すぎる、またはキャッシュウィンドウが経過している。

キャッシュが機能すると、長いエージェント会話をより経済的にできますが、不要なリポジトリコンテキストまで送信する理由にはなりません。プロンプトを焦点の絞られたものに保ち、タスク全体のコストを評価してください。エンドポイントの詳細については、キャッシュ実装ガイドと、モデルの最新の料金ページをお読みください。

再利用できる場所にブレークポイントを配置する

Messages形式のプロンプトでは、安定した指示と参照資料をsystemブロックに保持し、変化する質問をuserメッセージに配置してください。キャッシュブレークポイントは、リクエスト固有のタイムスタンプの後ではなく、安定した部分の末尾に置きます。コンテキストに複数の大きなドキュメントが含まれる場合は、呼び出し間で再利用される部分にブレークポイントを配置し、モデルがサポートするブレークポイント数を確認してください。

履歴を自分自身で要約するエージェントには注意してください。各ターンで以前の会話を書き換えると、全体の会話が人間には似ているように見えても、プレフィックスが変わり、キャッシュヒットが失われることがあります。ミスをデバッグするときはシリアライズされたリクエスト本文を比較してください。ただし、ログに機密情報を残さないようにしてください。

キャッシュ書き込みと最小長を考慮する

キャッシュが適用される前に、一定の最小プレフィックス長を必要とするモデルがあります。また、最初の書き込みは、その後の読み取りとは異なる料金で課金される場合があります。そのため、短いプロンプトでは節約が表示されないことがあります。現在のモデルのキャッシュ読み取り料金、書き込み料金、キャッシュ可能なトークンしきい値を確認してください。そのうえで、最初のリクエストと後続のリクエストを別々に比較し、説明のない1つの数値に平均化しないでください。

キャッシュの利用可能性は時間によって変わります。アイドル期間の後にプレフィックスの有効期限が切れることがあり、キャッシュはアプリケーションデータ用の永続ストアではありません。正しい回答に必要な会話状態を保持するために、キャッシュに依存しないでください。必要なコンテキストは引き続き送信してください。

キャッシュによる節約とプロンプト最適化を分けて考える

重複したコンテキストを減らすことと、繰り返されるコンテキストをキャッシュすることは、別々の改善です。まず、関係のない指示、古い例、コピーされたログを削除します。その後、残った安定した内容をキャッシュします。これにより、キャッシュミス時でもプロンプトを小さく保て、使用しないコンテキストに対して繰り返し料金を支払うことを避けられます。

プロンプトの変更を評価するときは、タスクの例を固定してください。プレフィックスを短くするとコストを削減できる一方で、モデルに必要な情報まで削除する可能性があります。最適化によって正確性が気付かないうちに失われないよう、キャッシュ済みおよびキャッシュされていない使用量とともに、出力品質も測定してください。