Prompt Caching(プロンプトキャッシング)とは?
Prompt Cachingとは、LLM APIに毎回送信するシステムプロンプトや参照ドキュメントをAPIサーバー側に一時保存し、次回以降の呼び出しでキャッシュ済みトークンを再利用することでコストと遅延を削減する機能です。たとえば1万トークンの法律文書を顧客対応チャットで毎回送信していたケースでは、Prompt Cachingの導入によりトークン読み込みコストを最大90%削減できます(キャッシュヒット率100%の場合)。
※ 倍率・コスト試算の数値は Anthropic Pricing(取得 2026-05)および Tufe Company SOT lib/claude-model-data.ts を一次参照。
なぜ重要なのか
LLMを業務に組み込む際、最大のコスト要因の一つが「長いシステムプロンプトの反復送信」です。RAGシステムで大量の参照文書を毎回コンテキストに含める場合、1回のAPIコールで数万トークンを消費することも珍しくありません。
Prompt Cachingが重要な理由は主に3点あります。コスト削減(キャッシュヒット時のトークン読み込み料金が通常の10分の1)、レスポンス高速化(キャッシュ済み部分の処理をスキップすることで初回以降の応答遅延を短縮)、スケーラビリティの向上(同じ文書を参照する多数のユーザーが並行利用する場面でコストが線形増加せず抑制される)です。
顧客対応チャットボット・社内ナレッジ検索・コード生成アシスタントなど、同一コンテキストを繰り返し参照する用途で特に高い効果を発揮します。
仕組みとコスト構造
キャッシュの種類と料金倍率
Claudeでは cache_control パラメータで2種類のキャッシュ有効期間を指定できます。
| キャッシュ種別 | 有効期間 | 書き込み料金(base比) | 読み込み料金(base比) |
|---|---|---|---|
| 5分キャッシュ | 5分 | 1.25倍 | 0.1倍(90%削減) |
| 1時間キャッシュ | 1時間 | 2倍 | 0.1倍(90%削減) |
※ 出典: Anthropic Pricing(取得 2026-05)
元が取れる条件
- 5分キャッシュ: 書き込み1.25倍 + 読み込み0.1倍のため、1回のキャッシュヒットで書き込みコストを回収できます
- 1時間キャッシュ: 書き込み2倍のため、2回のヒットで元が取れます
※ 出典: Anthropic Pricing(取得 2026-05)
コスト試算例
システムプロンプト 10,000トークンを100回呼び出す場合(Claude Haiku 4.5、入力 $1/MTok):
キャッシュなし(通常)
- 10,000トークン × 100回 = 1,000,000トークン消費
5分キャッシュあり(ヒット率100%前提、※ Tufe Company 内部試算 / 2026-05時点)
- 書き込み: 10,000 × 1.25 = 12,500トークン相当
- 読み込み: 10,000 × 0.1 × 99回 = 99,000トークン相当
- 合計: 111,500トークン相当(約89%削減)
※ Tufe Company 内部試算 / 2026-05時点。実際のコスト削減率はキャッシュヒット率・モデル・プロンプト構造により異なります。
実装サンプル(cache_control)
{
"model": "claude-haiku-4-5",
"system": [
{
"type": "text",
"text": "あなたは〇〇社のカスタマーサポートです。以下の製品マニュアルを参照してください...",
"cache_control": { "type": "ephemeral" }
}
],
"messages": [
{ "role": "user", "content": "返品手続きを教えてください" }
]
}
"type": "ephemeral" がデフォルト(5分)、1時間キャッシュは "type": "ephemeral_1h" を指定します。
実務での活用例
Tufe Companyが支援する中小企業・士業での主な活用シーンは以下の3パターンです。
税理士・法律事務所の相談チャットボット: 業務規程・法令条文・顧客FAQを1万〜5万トークンのシステムプロンプトとしてキャッシュ。毎日数十件の問い合わせを処理しても、キャッシュ分のトークンコストはほぼゼロに抑えられます(※ Tufe Company 提供価格目安 / 2026-05時点、Anthropic Pricing 準拠)。
ECサイトの商品検索アシスタント: 数千件の商品カタログをベクトル検索で絞り込んだ後、上位10件のテキストをコンテキストに含めるRAG構成でキャッシュを活用。商品説明テキストが変わらない限り、キャッシュが有効に機能します。
社内ドキュメント要約・Q&A: 社内規程や議事録をn8n・Difyのワークフローに組み込み、同じドキュメントへの複数ユーザーからのアクセスをキャッシュで処理。n8n自動化ガイドやDifyワークフローガイドで紹介している構成と組み合わせると効果的です。
よくある誤解・注意点
誤解1: キャッシュヒット率が常に100%だと思っている(参考: Anthropic Prompt Caching docs 取得 2026-05) キャッシュは「プロンプトのどこまでが同一か」を前方一致で判定します。毎回プロンプト冒頭のユーザー名や日時を動的に挿入している場合、キャッシュが効かないことがあります。キャッシュ対象のテキストはプロンプトの先頭付近に配置し、変動する部分は末尾にまとめる設計が必要です。
誤解2: 1時間キャッシュは常にお得(参考: Anthropic Pricing — 5min/1h Cache Writes 取得 2026-05) 書き込みコストが2倍になるため、同じドキュメントへのアクセスが1時間以内に2回以上発生しないシナリオでは逆に割高になります。呼び出し頻度を事前に測定し、5分 vs 1時間を使い分けてください。
誤解3: すべてのLLMプロバイダーで同じ仕様
OpenAIのPrompt Cachingは自動適用でユーザーによる cache_control 指定が不要な一方、Claudeは明示的に指定が必要です。プロバイダーごとに仕様・料金倍率・最小キャッシュ可能トークン数が異なります。
よくある質問
Q. Prompt Cachingを使うと応答速度も上がりますか?
キャッシュヒット時は、サーバーがキャッシュ済みトークンの再処理をスキップするため、初回コール以降のTTFT(Time to First Token)が短縮される傾向があります。ただし短縮幅はプロンプト長やモデルによって異なり、数十ミリ秒〜数秒程度のケースが報告されています。コスト削減を主目的とし、速度改善はあくまで副次的効果として捉えると判断がブレません。
Q. キャッシュ対象のプロンプトに最小サイズはありますか?
Claudeでは最低約1,024トークン以上のブロックにしかキャッシュが適用されません(モデルバージョンにより異なる場合があります)。短いシステムプロンプトへの適用は効果が薄いため、社内マニュアル・FAQ文書・長い指示書など、まとまった分量のコンテキストに対して使用するのが基本です。
Q. n8nやDifyなどのノーコードツールからでも使えますか?
n8nのAnthropicノードやDifyのClaude連携では、2026年時点でAPIパラメータをカスタム指定できる構成が増えています(※ Tufe Company 内部実測 / N=自社運用 / 2026-05時点)。ただしGUIから cache_control を直接設定できるかはバージョン依存のため、HTTPリクエストノードでAPIを直接呼び出す方法が確実です。Difyワークフロー活用ガイドも参考にしてください。
関連用語
Tufe Companyのサービス
LLM APIの活用コスト最適化・Prompt Caching設計・n8n/Difyを使ったAI自動化ワークフロー構築は、Tufe CompanyのAI自動化支援サービスで対応しています。詳しくは n8n・Difyワークフロー構築サービス をご覧ください。
実装支援が必要な方は 無料相談 をご利用ください。