プロンプトキャッシュ比較2026｜3大LLMのコスト最適化戦略

結論：プロンプトキャッシュはAIエージェントの「見えないコスト削減レバー」

2026年現在、AIエージェントの本番運用で最大の課題は「精度」ではなく「コストとレイテンシ」に移っている。長大なシステムプロンプト、複数ツール定義、数百ターンに及ぶ会話履歴——これらの接頭辞部分を毎回ゼロから処理すると、APIコール1回あたり数ドルが吹き飛ぶ。Claude CodeやCursor、Devinなどの実運用エージェントでは、1セッションで数万トークンのコンテキストを扱うことが日常的だ。この規模になると、プロンプト処理コストが無視できない運用費になる。実際、Claude Codeのヘビーユーザーからは「キャッシュなしでは月額のAPI費用が4桁ドルに達した」という声も聞かれる。

ここで効くのがプロンプトキャッシュだ。主要3プロバイダー（Claude・GPT・Gemini）はいずれもこの機能を提供しており、適切に設計すれば入力コストを50〜90%削減できる。本記事では、3社のキャッシュ機構を比較し、エージェント設計にどう組み込むべきかを実装コード付きで解説する。キャッシュ設計の善し悪しは、エージェント単体の性能差よりも大きなコスト差を生む。年間のAPI費用を数万ドル単位で左右する決断だ。本稿を読み終える頃には、あなたのエージェントのプロンプト構造を見直し、月額API費用を半減させる具体的なアクションプランが手に入る。

プロンプトキャッシュとは何か

LLMのAPI呼び出しでは、毎回プロンプト全体を送信する。その先頭部分（システムプロンプト、ツール定義、固定の指示書など）が前回と同じでも、モデルは毎回ゼロから計算する。プロンプトキャッシュは、この接頭辞部分の計算結果（KVキャッシュ）をサーバー側に保持し、2回目以降の同一接頭辞呼び出しでは再計算をスキップする仕組みだ。

初回リクエストには若干のキャッシュ書込コストが上乗せされるが、2回目以降の読取は通常の10〜50%の価格で済む。たとえばClaude Opus 4では、キャッシュ読取トークン単価が通常の約10分の1になる。エージェントのように同一システムプロンプトで何十回もAPIを叩くユースケースでは、劇的な効果を発揮する。2025年から2026年にかけて、このキャッシュ機能は「あると便利」から「ないと本番運用できない」レベルに必須度が上がっている。特にMCP（Model Context Protocol）やツール呼び出しを多用するエージェントでは、ツール定義だけで数千トークンに達するため、キャッシュがないとコストが指数関数的に膨らむ。

重要な制約として、キャッシュは完全一致が条件だ。接頭辞の1文字でも変わればキャッシュは無効化される。ツール定義の順序変更や、システムプロンプトへの動的差し込みもキャッシュ破壊の原因になる。さらに、モデルを切り替えるとキャッシュは完全に消滅する。これは同じプロバイダー内の別モデルでも同様で、たとえばClaude Opus→Sonnetへの切り替えでもキャッシュは引き継がれない。このため、マルチモデル構成のエージェントでは、キャッシュ戦略がモデル選択の重要な判断材料になる。

3社キャッシュ機構の比較表

項目	Claude（Anthropic）	GPT（OpenAI）	Gemini（Google）
機能名	Prompt Caching	Prompt Caching	Context Caching
制御方式	明示的（cache_control指定）	完全自動	明示的（CachedContent作成）
TTL（有効期限）	デフォルト5分（最大1時間）	数分〜1時間超	設定可能（1時間以上）
キャッシュ書込コスト	通常の1.25倍程度	なし（透過的）	通常料金
キャッシュ読取割引	最大90%オフ	50〜90%オフ	最大75%オフ
最大コンテキスト	200Kトークン	128K〜1Mトークン	1M〜2Mトークン
キャッシュ可能ブロック数	最大4ブロック	制限なし（自動判定）	1オブジェクト
適した用途	エージェント、ツール呼出、コード生成	会話システム、コーディングエージェント	大量固定ドキュメント、RAG

Claude Prompt Caching：精密制御の決定版

Anthropicのアプローチは開発者に最大の制御権を与える。キャッシュしたいブロックに cache_control: {type: "ephemeral"} を明示的に付与し、複数ブロックに分割して指定できる。公式ドキュメント（Anthropic Prompt Caching）に詳細な仕様が記載されている。

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-20250514",
    max_tokens=4096,
    system=[
        {
            "type": "text",
            "text": "あなたはAIエージェントの設計コンサルタントです。",
            "cache_control": {"type": "ephemeral"}  # ここをキャッシュ
        },
        {
            "type": "text",
            "text": "現在の日付: 2026年6月23日"  # ここはキャッシュしない（動的）
        }
    ],
    messages=[{"role": "user", "content": "最適なコンテキスト戦略は？"}]
)

# レスポンスからキャッシュ利用状況を確認
print(f"キャッシュ読取: {response.usage.cache_read_input_tokens}")
print(f"キャッシュ書込: {response.usage.cache_creation_input_tokens}")

ポイント: システムプロンプトの静的部分だけをキャッシュし、動的な日付やユーザー情報はキャッシュ対象外にする。これにより、接頭辞の安定性を保ちつつ柔軟な動的注入が可能になる。

弱点: デフォルトTTLが5分と短い。連続リクエスト間隔が5分を超えるとキャッシュが消える。長時間のエージェントセッションでは、この点がボトルネックになりやすい。もっとも、5分以内に連続リクエストが発生する対話型エージェントでは、この短いTTLでも実用上の支障は少ない。実際にClaude Codeでは、連続的なコード編集セッションにおいて98%以上のキャッシュヒット率を達成した事例が報告されている。

GPT Prompt Caching：自動化の利便性

OpenAIは開発者が何もしなくても自動でキャッシュが効く「透過型」設計を採用している。1,024トークン以上の接頭辞が一致すれば自動キャッシュが発動し、TTLもClaudeより長め（状況により最大24時間）でヒット率が高い。公式のPrompt Cachingガイドで利用状況の確認方法が解説されている。実運用では、OpenAI Cookbookのキャッシュ活用例も参考になる。

特筆すべきは、Anthropicのエンジニアが公開しているプロンプトキャッシュ設計パターンだ。実際のClaude Codeで達成された98%のキャッシュヒット率や、$193K相当のコスト削減事例が報告されている。これらの一次情報は、抽象的なベストプラクティスではなく、実測値に基づく貴重なデータである。

from openai import OpenAI

client = OpenAI()

# キャッシュ用の特別な設定は不要。同じsystemプロンプトを繰り返し送るだけ
for query in queries:
    response = client.chat.completions.create(
        model="gpt-5",
        messages=[
            {"role": "system", "content": system_prompt},  # 自動キャッシュ
            {"role": "user", "content": query}
        ]
    )
    # usageからキャッシュヒットを確認可能
    print(response.usage.prompt_tokens_details.cached_tokens)

ポイント: 「コードを書かずにキャッシュが効く」のは強力なメリットだ。特に長期間稼働するコーディングエージェント（Codexなど）では、開発者がキャッシュ設計を意識しなくても恩恵を受けられる。

弱点: 制御が効かないため、キャッシュしたくない部分までキャッシュされる可能性がある。また、キャッシュヒット率のチューニングがブラックボックスになりがちで、意図しないキャッシュ破壊の原因特定が難しい。

Gemini Context Caching：巨大コンテキストの取り回し

Googleの方式は、キャッシュしたいコンテンツを事前に独立したオブジェクトとして登録する設計だ。ClaudeやGPTが「リクエストの一部としてキャッシュ指定」するのに対し、Geminiは「まずキャッシュを作り、それを使う」という2段階のワークフローになる。詳細はGemini Context Cachingガイドを参照。

import google.generativeai as genai

# Step 1: キャッシュを作成
cache = genai.caching.CachedContent.create(
    model="models/gemini-2.5-pro",
    display_name="agent system prompt v1",
    system_instruction="あなたはAIエージェント開発の専門家です...",
    contents=[large_document],  # 巨大なドキュメントもキャッシュ可能
    ttl="3600s"  # 1時間
)

# Step 2: キャッシュを使ってモデルを呼び出す
model = genai.GenerativeModel.from_cached_content(cached_content=cache)
response = model.generate_content("このドキュメントの要点を教えて")

# 使用後はキャッシュを削除
cache.delete()

ポイント: 2Mトークンという巨大コンテキストと組み合わせることで、書籍全文やコードベース全体をキャッシュに乗せられる。RAGパイプラインの「参照ドキュメント」部分を丸ごとキャッシュするユースケースと相性が良い。

弱点: キャッシュ作成が別ステップになるため、動的に変化するプロンプトには不向き。またChatGPT/Claudeに比べて開発者コミュニティでの議論が少なく、情報収集やトラブルシューティングにやや手間取る。とはいえ、静的ドキュメントの処理効率では他の追随を許さない。たとえば研究論文50本（約150万トークン）をコンテキストキャッシュに乗せ、その上で横断的な質問応答を行うようなユースケースでは、Gemini以外の選択肢は実質的に存在しない。Google Cloudのエコシステム（Vertex AI、BigQuery、Cloud Storage）との統合も強みで、エンタープライズ環境ではキャッシュ＋既存データパイプラインの相乗効果が期待できる。

エージェント設計に組み込む5つのキャッシュ最適化パターン

Anthropicのエンジニアや実務者が確立した、実戦的な設計パターンを紹介する。どのプロバイダーでも応用可能だ。

1. 静的ファーストのプロンプト構造

プロンプトを「静的→動的」の順に並べる。システムプロンプト、ツール定義、固定ドキュメントを先頭に置き、会話履歴や最新のツール出力は末尾へ。接頭辞の一致確率を最大化する鉄則だ。

# 良い並び順（キャッシュが効く）
prompt_parts = [
    SYSTEM_PROMPT,      # 静的・キャッシュ可能
    TOOL_DEFINITIONS,   # 静的・キャッシュ可能
    PROJECT_CONTEXT,    # 静的・キャッシュ可能
    RECENT_MESSAGES,    # 動的・キャッシュ対象外
    CURRENT_QUERY       # 動的・キャッシュ対象外
]

2. システムプロンプトの不変性

動的な情報（状態更新、学習内容、リフレクション結果）をシステムプロンプトに直接書き込まない。代わりに、タグ付きのユーザーメッセージとして末尾に追加する。これにより接頭辞が変化せず、キャッシュが維持される。

3. ツール定義の安定化

ツール定義はキャッシュ済み接頭辞に含まれる。ツールの追加・削除・並び替えはキャッシュを破壊する。アルファベット順の固定や、全ツールの常時ロード（必要なときだけ呼び出す設計）で安定させる。モード切替はツールセットの差し替えではなく、EnterPlanMode のようなメタツールで実装する。

4. サブエージェントによるコンテキスト分離

異なるモデルや異なるタスクには別のサブエージェントを割り当てる。モデル切替はキャッシュを完全に破壊するため、Orchestrator→Workerのハンドオフパターンで分離する。高価なモデルでもキャッシュが効いていれば、安価なモデルをキャッシュなしで使うより安上がりになるケースがある。

5. キャッシュヒット率を本番指標に

レイテンシやエラー率と同じレベルで、キャッシュ読取トークン率をダッシュボードに載せる。キャッシュヒット率の急落は「ツール定義の順序が変わった」「システムプロンプトに動的注入が入った」などの回帰バグを即座に検知するシグナルになる。30%→85%の改善はチューニングだけで実現可能だ。実運用では、キャッシュ書込トークン数と読取トークン数の比率を時系列グラフ化し、週次でトレンドをレビューするチームが増えている。特に料金体系が複雑なマルチモデル構成では、プロバイダー別・モデル別のキャッシュ効率を個別に追跡する必要がある。

補完戦略：キャッシュだけでは足りない部分

キャッシュが効くのは接頭辞だけだ。会話履歴やツール出力が増え続けるエージェントでは、以下の戦略と組み合わせる必要がある。これらはキャッシュと排他的ではなく、相補的に機能する。実際の本番エージェントでは、キャッシュ＋予算管理＋メモリの3層すべてを実装するのが標準になりつつある。

• コンテキスト予算管理：システムプロンプト15〜20%、RAG検索結果トップ5件、直近履歴、圧縮済み長期記憶——のようにウィンドウを明示的に区分し、各領域のトークン上限を設定する。具体的な実装では、トークンカウンターで各領域の消費量を監視し、上限超過時には古い会話ターンの要約やRAG結果の再ランキングで調整する。Anthropicの推奨では、システム指示は全体の15〜20%に抑え、残りを作業領域に割り当てるのが効果的とされている。
• 階層的メモリ：短期（直近履歴）→中期（セッション要約）→長期（ベクトルDB＋ナレッジグラフ）の3層構造で、必要な情報だけをウィンドウに載せる
• セマンティックキャッシュ：完全一致ではなく埋め込みベクトルの類似度でキャッシュ判定。ただしPIIやリアルタイムデータは除外ゾーンを設定する
• 定期的な圧縮：LLM自体に履歴の要約を依頼し、古い会話ターンを圧縮してトークン消費を抑制する

実践：コスト削減効果のシミュレーション

具体的な数字でキャッシュの効果を見てみよう。以下の条件でエージェントを運用すると仮定する：システムプロンプト5,000トークン、ツール定義10,000トークン（合計15,000トークンのキャッシュ可能接頭辞）、1セッションあたり50回のAPIコール。

キャッシュなしの場合：毎回15,000トークンをゼロから処理。Claude Opus 4（$15/M入力トークン）では、1コールあたり$0.225、50コールで$11.25が接頭辞処理だけで消費される。

キャッシュありの場合：初回のみ$0.281（書込コスト1.25倍）、残り49回はキャッシュ読取$0.0225/回（90%オフ）。合計は$0.281 + $1.103 = $1.384。つまり接頭辞処理コストが約88%削減される。

さらに、1日100セッション×月20日稼働の本番環境なら、キャッシュなしで月$22,500かかっていた接頭辞処理が、キャッシュ導入で約$2,768まで圧縮できる計算になる。差額の約$19,700は他の改善投資に回せる規模だ。

ここで注意すべきは、これは接頭辞部分だけの試算であり、会話履歴やツール出力といった動的部分のトークン消費は別途発生する点だ。それでも、システムプロンプトとツール定義がコストの相当部分を占めるエージェントでは、キャッシュ最適化のROIは極めて高い。

どのプロバイダーを選ぶべきか

エージェントの特性とチームの優先順位で判断しよう。

• 精密な制御と高品質な推論が必要なら Claude（明示的cache_control + Opusの推論力）
• 開発の手間を最小化したいなら GPT（完全自動キャッシュ + 長いTTL）
• 巨大な静的コンテキストを扱うなら Gemini（2Mトークン + Context Caching）
• 高度な最適化を目指すなら、キャッシュヒット率とTTLを監視しながらのマルチプロバイダールーティング

キャッシュ導入の実践手順：今日から始める3ステップ

理論だけでなく、実際に手を動かすための最小限の導入手順をまとめる。既存のエージェントコードベースに、今すぐ適用できる内容だ。

Step 1：現状のプロンプト構造を可視化する

まず、エージェントがAPIに送信しているプロンプト全体をログに出力し、どの部分が静的でどの部分が動的かを仕分ける。システムプロンプト、ツール定義、ファイルコンテキスト、会話履歴、直近のツール出力——それぞれのトークン数を計測し、接頭辞としてキャッシュ可能な割合を算出する。多くの場合、全体の30〜60%がキャッシュ可能であることに気づくだろう。

Step 2：静的ファースト構造にリファクタリングする

動的な要素をすべてプロンプト末尾に移動する。特に「現在時刻」「セッションID」「ユーザー名」などのランタイム情報はシステムプロンプトから排除し、ユーザーメッセージとして注入する。ツール定義はアルファベット順に固定し、実行時に動的変更しない。

Step 3：キャッシュメトリクスを計測し、PDCAを回す

APIレスポンスのusageフィールドから cache_read_input_tokens / cache_creation_input_tokens を抽出し、時系列でダッシュボード化する。キャッシュヒット率が80%を下回ったらプロンプト構造を再点検し、90%以上を維持できたら他の最適化（メモリ圧縮、サブエージェント分離）に進む。最初の1週間でベースラインを確立し、2週間目から改善サイクルに入るのが理想的なペースだ。

よくある失敗パターンと回避策

キャッシュを導入したチームがハマりがちな罠を3つ紹介する。

失敗1：システムプロンプトへの動的文字列埋め込み

「現在時刻」や「ユーザー名」をf-stringでシステムプロンプトに埋め込むと、リクエストごとに接頭辞が変化しキャッシュが全滅する。典型的なコードは次のようなパターンだ：system_prompt = f"現在時刻は{datetime.now()}です。あなたは{username}さんのAIアシスタントです。"。この1行で、システムプロンプト全体のキャッシュが無効化される。回避策は明快で、動的情報はすべてユーザーメッセージ側に配置する。たとえばmessages配列の最初に「現在時刻: 2026-06-23T10:00:00」「ユーザー: 佐藤」といったコンテキストメッセージを追加すれば、システムプロンプトの不変性を保ったまま必要な情報を渡せる。

失敗2：ツール定義の実行時生成

「必要なツールだけ動的に組み立てる」設計は、ツール定義の順序や内容がリクエストごとに変動し、キャッシュヒット率がゼロになる。たとえば「検索が必要なときだけSearchToolを追加」「計算が必要なときだけCalculatorToolを追加」という実装は、リクエスト間でツールセットが異なるためキャッシュが一切効かない。代わりに全ツールを常時定義し、実際の使用判断はモデルに任せる。100個のツールを定義していても、モデルは必要なものだけを選んで呼び出すので、キャッシュを犠牲にする価値はない。

失敗3：キャッシュ有効期限の無視

Claudeの5分TTLを認識せず、6分間隔でエージェントを呼び出すと毎回キャッシュミスになる。解決策：TTL監視付きのリクエストスケジューラを実装するか、GPTのような長TTLプロバイダーに切り替える。具体的には、APIレスポンスのタイムスタンプを記録し、前回リクエストからの経過時間がTTLの80%を超えたらキャッシュウォームアップ用のダミーリクエストを送信するパターンが有効だ。Claudeの場合は5分TTLなので4分ごとに軽量なping的リクエストを送り、キャッシュをホットに保つ。

2026年の展望：キャッシュ戦略の次に来るもの

プロンプトキャッシュは2024〜2025年にかけて急速に普及したが、2026年後半にはさらに進化したコンテキスト管理手法が登場しつつある。モデル自体が自律的にコンテキストを刈り込み、不要な情報を外部化する「セルフマネジメント」機能や、勾配降下法的にウィンドウ内容を最適化する研究が進行中だ。また、バッチAPIとキャッシュの統合により、非リアルタイムのエージェントタスクでは99%以上のキャッシュヒット率を達成する事例も報告されている。

短期的には、プロンプトキャッシュ＋コンテキスト予算管理＋階層的メモリの3本柱がエージェント最適化の標準スタックとして定着するだろう。長期的には、これらの最適化が自動化され、開発者が明示的に設計しなくても効率的なコンテキスト利用が実現される未来が見えている。それまでの間は、本記事で紹介したパターンを武器に、手動でのチューニングが競争優位の源泉になる。

関連記事・次に読む

• AIエージェント評価ベンチマーク完全ガイド2026
• AIエージェント本番デバッグ完全ガイド2026
• モデル消失時代のAIエージェント設計

※本記事で引用しているAPI料金は2026年6月時点のものです。最新の料金は各プロバイダーの公式サイトでご確認ください。キャッシュの挙動や制限はモデルのバージョンアップに伴い変更される可能性があります。