プロンプトキャッシング実践ガイド: エージェントアプリのコストとレイテンシーを同時に下げる

• はじめに
• なぜエージェントアプリで重要なのか
• OpenAI と Anthropic は何が違うのか
  • OpenAI
  • Anthropic
  • ざっくり比較
• 効くプロンプト構成パターン
  • パターン 1: 固定資産を前に置く
  • パターン 2: チーム内でテンプレートを標準化する
  • パターン 3: 変動しやすい文脈は後ろへ送る
  • パターン 4: Anthropic ではブレークポイントを資産境界として考える
• シンプルな実装例
  • OpenAI スタイルの例
  • Anthropic スタイルの例
• ROI が出やすいケース
• よくある失敗
  • 1. 変数データを前半に混ぜる
  • 2. 似ていれば十分だと思う
  • 3. 安定資産と実験資産を分けない
  • 4. Anthropic のブレークポイントを後ろに置きすぎる
  • 5. OpenAI で prompt_cache_key 戦略を持たない
• 移行チェックリスト
• まとめ
• References

はじめに

エージェントアプリでは、思っている以上に同じプロンプト構造が繰り返し使われる。システム指示、ツール説明、ポリシー文書、共通の few-shot 例、ワークフロー規則は多くのリクエストで変わらない。一方で、実際に変わるのは最後のユーザー依頼や一部の文脈だけ、というケースが多い。

そのため、プロンプトキャッシングは単なる小さな最適化ではない。エージェント製品では、設計そのものに効く改善になる。繰り返し使う接頭部分を毎回最初から処理しなくて済めば、同じ挙動を保ちながらレイテンシーとコストの両方を下げられるからだ。

この記事では、OpenAI と Anthropic の公式ドキュメントを根拠に、エージェントアプリでプロンプトキャッシングをどう考え、どう実装へ落とし込むかを実務目線で整理する。

なぜエージェントアプリで重要なのか

次の三つがそろうアプリでは、プロンプトキャッシングの効果が出やすい。

1. システム指示が長い
2. ツール説明やポリシーが繰り返し入る
3. 多くのリクエストが同じ接頭プロンプトを共有する

これはサポートエージェント、社内コパイロット、業務ワークフロー支援、文書中心の運用エージェントでよく見られる構成だ。

典型的なエージェントリクエストには、次のような要素が入る。

• 役割と行動ルール
• 安全性と承認ポリシー
• 利用可能なツールとその説明
• 共通の例
• 実際のユーザー依頼

高コストになりやすいトークンは、最後の一行よりも、その前にある繰り返しの設定部分に集まりやすい。そこを安定させられるなら、キャッシングは応答速度と単価の両方に効く。

OpenAI と Anthropic は何が違うのか

どちらも反復的な処理で時間とコストを下げるための仕組みだが、設計上の考え方には違いがある。

OpenAI

OpenAI の公式ドキュメントでは、プロンプトキャッシングは最近のモデル全般、つまり gpt-4o 以降で有効だと説明されている。さらに、キャッシュヒットは完全に一致する接頭部分でのみ成立する。つまり、固定の指示や例は前半に置き、変動する内容は後半に置く構成が重要になる。

OpenAI の文書には、次の実務ポイントも明記されている。

• 1024 トークン以上のプロンプトで自動キャッシングが有効になる
• prompt_cache_key はルーティングとキャッシュヒット率の改善に役立つ

OpenAI では、「共有接頭部をどれだけ厳密に安定させられるか」が一番大きな設計ポイントになる。

Anthropic

Anthropic の公式ドキュメントでは、プロンプトキャッシングは反復的なタスクにおいて処理時間とコストを削減すると説明されている。Anthropic には自動キャッシングに加えて、明示的なキャッシュブレークポイントの考え方がある。デフォルトのキャッシュ保持時間は 5 分で、追加コストを払うことで 1 時間キャッシュも使える。

また、キャッシュ範囲の説明も明確だ。Anthropic の文書では、キャッシュ対象は tools、system、messages の順に並ぶプロンプト接頭部であり、キャッシュブレークポイントまでを含むとされている。

ざっくり比較

効くプロンプト構成パターン

プロンプトキャッシングで重要なのは、文章の上手さだけではなく構造だ。目標は、再利用できる接頭部を長く、安定的に、多くのリクエストで共有できる形にすることだ。

パターン 1: 固定資産を前に置く

できるだけ前に寄せたい要素は次の通り。

• システム指示
• 共通ポリシー
• ツール説明
• 共通例
• 安定した出力ルール

後ろに寄せたい要素は次の通り。

• ユーザー依頼
• セッション固有の状態
• リクエストごとの変数
• 毎回変わる文書断片

[固定のシステム指示]
[共通ポリシー]
[ツール説明]
[共通例]
[変動するユーザー入力]

パターン 2: チーム内でテンプレートを標準化する

キャッシングで重要なのは、似ていることではなく、同じであることだ。チームごとにサポートエージェントの指示文を少しずつ書き換えていると、ヒット率はすぐに落ちる。

有効な運用例は次の通り。

• エージェント系統ごとにテンプレートを一つにする
• ツール順序を固定する
• 例の数を頻繁に変えない
• 共有プロンプトのバージョン運用を揃える

パターン 3: 変動しやすい文脈は後ろへ送る

検索結果、ユーザープロフィール、最新イベントログはリクエストごとに変わりやすい。これらが前半に入ると、再利用できる接頭部が短くなる。まず共有ルールを置き、その後に変動文脈を付けるほうが良い。

パターン 4: Anthropic ではブレークポイントを資産境界として考える

Anthropic では、一緒に再利用したいプロンプト資産のまとまりを先に考えると設計しやすい。長いポリシー、共通ワークフロー文書、大きなツール説明などは、ブレークポイント設計の自然な候補になる。

シンプルな実装例

OpenAI スタイルの例

{
  "model": "gpt-4o",
  "prompt_cache_key": "support-agent-v1",
  "messages": [
    {
      "role": "system",
      "content": "You are the support operations agent. Follow the policy, use the available tools carefully, and produce a concise action summary."
    },
    {
      "role": "system",
      "content": "Policy: verify account scope, avoid irreversible actions without approval, and log the final decision."
    },
    {
      "role": "system",
      "content": "Tool guide: ticket_lookup, refund_policy_check, escalation_create."
    },
    {
      "role": "user",
      "content": "Customer asks whether order 48291 can be refunded after partial shipment."
    }
  ]
}

最初の三つのブロックが再利用可能な接頭部になる。この共有部分が完全に同じまま維持されるほど、キャッシュの恩恵を受けやすい。

Anthropic スタイルの例

{
  "model": "claude-sonnet",
  "system": [
    {
      "type": "text",
      "text": "You are the finance operations agent. Apply policy strictly and explain risk before action."
    },
    {
      "type": "text",
      "text": "Shared policy and workflow documentation goes here.",
      "cache_control": {
        "type": "ephemeral"
      }
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "Review this reimbursement request and tell me whether it should be approved."
    }
  ]
}

この例では、共有ポリシー文書のブロックが再利用境界として機能する。ユーザー依頼だけを変えながら、同じ前半部分を再利用しやすい。

ROI が出やすいケース

プロンプトキャッシングの効果はどこでも同じではない。次のようなケースでは特に有効だ。

• 長い指示を持つエージェント
• ツール説明が多いワークフロー
• 同じ運用プロンプトを何度も使う社内コパイロット
• 多くのリクエストが共通セットアップを共有する B2B 製品
• 同じ背景文脈を繰り返し参照する文書中心の運用

一方で、効果が弱くなりやすいのは次のケースだ。

• プロンプトが先頭から大きく変わる
• そもそも短いリクエストが多い
• 実験のたびに共有接頭部を書き換える
• 個別化データが安定指示より前に来る

簡単に言えば、共有接頭部が長く、安定していて、何度も繰り返されるほど、投資対効果は良くなる。

よくある失敗

1. 変数データを前半に混ぜる

チケット番号、ユーザー名、最新ログが共有指示より先に来ると、接頭部の再利用性が下がる。

2. 似ていれば十分だと思う

キャッシングは完全一致の接頭部に依存する。少しの文言変更、ツール順序変更、例の変更でもヒット率は落ちうる。

3. 安定資産と実験資産を分けない

システムプロンプト全体を毎回実験で変えると、キャッシュしやすい構造が壊れやすい。ポリシーやツール説明は固定し、実験箇所だけ切り分けるほうが良い。

4. Anthropic のブレークポイントを後ろに置きすぎる

変動しやすい文脈の後ろにブレークポイントを置くと、キャッシュできる価値の高い部分が小さくなる。

5. OpenAI で prompt_cache_key 戦略を持たない

OpenAI の文書にある通り、prompt_cache_key はルーティングとキャッシュヒット率の改善に役立ちうる。エージェント系統やバージョン単位で一貫して設計すると運用しやすい。

移行チェックリスト

既存のエージェントワークフローをキャッシング前提へ寄せるときは、次の順番が実務的だ。

1. 現在のプロンプトを安定資産と変動資産に分ける。
2. 共有指示、ツール、例を接頭部へ移す。
3. ユーザー固有情報とリクエスト固有文脈を後ろへ送る。
4. エージェント種別ごとに標準テンプレートを決める。
5. OpenAI では、1024 トークン以上の繰り返し接頭部が実際に存在するか確認する。
6. OpenAI では、prompt_cache_key の基準をチーム、エージェント、バージョン単位で決める。
7. Anthropic では、どこまでを再利用資産にするか、どこにブレークポイントを置くか決める。
8. 標準の 5 分で十分か、1 時間オプションが必要か判断する。
9. 導入後は、キャッシュ挙動、レイテンシー、リクエスト単価を一緒に見る。
10. 可能なら、実験系の変更は安定した接頭部と分離する。

まとめ

プロンプトキャッシングは、単なる課金の最適化機能ではない。エージェントアプリにおいては、プロンプト設計の規律そのものになる。OpenAI では完全一致する共有接頭部と順序の安定化が重要であり、Anthropic では再利用したい資産とブレークポイントの設計が重要になる。

長い指示、共通ポリシー、共有ツール説明を多く使うエージェント製品なら、最初に見直すべきなのは新しいモデルではなく、プロンプトの並べ方かもしれない。

References

• OpenAI Prompt Caching
• Anthropic Prompt Caching