長文のSystem Prompt・Tool定義・RAGコンテキストを毎リクエスト送り直すコストに、いま多くのAIエージェント開発者が直面している。Anthropicが提供するPrompt Cachingは、cache_controlブレークポイントを付けるだけで「キャッシュ書き込み=入力単価の1.25倍」「キャッシュ読み出し=入力単価の0.1倍(90%引き)」という非対称な料金体系を作り出す機能で、設計次第でAIエージェントの推論コストを桁単位で削れる。一方、TTL(5分/1時間)・ブレークポイント数(最大4個)・キャッシュ無効化条件など、押さえないと「キャッシュしてるつもりで毎回書き込みコストを払う」失敗が起きやすい。
この記事は、Anthropic公式docsとAnthropic Blogだけを一次ソースに、Prompt CachingをAIエージェント設計に組み込むときの実装パターンとコスト試算を、フレームワークとして整理する。Pattern A4(データ・フレームワーク深掘り型)。
結論ファースト：Prompt Caching設計の5原則
- cache_controlは「最も書き換わらない順」に置く。Tool定義 → System → 会話履歴の順で4ブレークポイントを使い切る
- 5分TTLが基本。1時間TTLはbeta header必須でwrite単価2倍(1時間=入力単価×2.0、5分=×1.25)
- cache hit時の読み出しコストは入力単価の10%。長文context+ループ実行のエージェントほど効く
- キャッシュは「prefix完全一致」で効く。1文字でも変わるとそれ以降は全部cache miss扱い
- 最小トークン要件あり(Claude Opus/Sonnet=1,024 token / Haiku=2,048 token)。短いSystem Promptはキャッシュされない
以下、これらの根拠を公式docsで一個ずつ確かめながら、AIエージェント側の組み込み方を見ていく。
Prompt Cachingとは何か：Anthropic公式定義
Anthropicの公式ドキュメント「Prompt caching」では、Prompt Cachingを「APIコール間で頻繁に使われるコンテキストをキャッシュすることで、レイテンシとコストを削減する機能」と定義している。要点は3つ。
- キャッシュ対象は「
cache_controlブロックを明示的に付けた位置までのprefix」 - キャッシュはAnthropic側のサーバーに保持される(クライアント側のキャッシュではない)
- キャッシュヒット時、その範囲のトークンは「cache_read_input_tokens」として通常入力単価の10%で課金される
つまりPrompt Cachingは、開発者から見ると「cache_control: {"type": "ephemeral"}を付けるだけのフラグ」だが、その内部では「コンテンツのhashを取り、prefixが一致するキャッシュエントリがあれば再利用」というふるまいになる。だからこそ「prefixが完全一致しないとキャッシュは効かない」というルールが生まれる。
仕組み：cache_controlブレークポイントとprefix一致
4つのブレークポイントを「どこに置くか」
cache_controlは1リクエストにつき最大4個まで指定できる。各ブレークポイントは「ここまでのprefixをキャッシュ対象にする」という意味を持つ。AIエージェント設計では、書き換わる頻度の少ない順にブレークポイントを並べるのが基本だ。
{
"model": "claude-sonnet-4-5",
"max_tokens": 1024,
"tools": [
{
"name": "search_docs",
"description": "...",
"input_schema": {...},
"cache_control": {"type": "ephemeral"}
}
],
"system": [
{
"type": "text",
"text": "あなたはAIエージェントです... (長文のRole定義)"
},
{
"type": "text",
"text": "## 社内ナレッジベースn(20,000 token程度のRAG context)",
"cache_control": {"type": "ephemeral"}
}
],
"messages": [
{
"role": "user",
"content": [
{
"type": "text",
"text": "過去ログ要約: ...(履歴)",
"cache_control": {"type": "ephemeral"}
},
{
"type": "text",
"text": "今回の質問: 新しい入力"
}
]
}
]
}この例では3個のブレークポイントを置いた。Tool定義 → System内のRAGコンテキスト → 会話履歴の固定部分、までを全部キャッシュしている。最後の「今回の質問」だけは毎回変わるのでキャッシュ範囲の外。
prefix完全一致のシビアさ
キャッシュは「ブレークポイントまでのバイト列が完全一致した場合のみ」ヒットする。たとえばSystem Promptの先頭に"今は2026年5月27日です。"のような動的タイムスタンプを混ぜると、毎回prefixが変わって全部cache missになる。AIエージェントで「日時を入れたい」「ユーザーIDを混ぜたい」というニーズは多いが、これらはキャッシュ対象の外側に置くか、ブレークポイントより後ろの動的セクションに切り出す設計が必要だ。
最小トークン要件
公式docsには「キャッシュには最小サイズがある」と明記されている。具体的には次の通り。
| モデル | 最小キャッシュ可能トークン数 |
|---|---|
| Claude Opus 4 / Opus 4.1 | 1,024 token |
| Claude Sonnet 4 / Sonnet 4.5 / Sonnet 3.7 / Sonnet 3.5 | 1,024 token |
| Claude Haiku 4.5 / Haiku 3.5 / Haiku 3 | 2,048 token |
これ未満のブロックにcache_controlを付けても、リクエストは通るがキャッシュは作られない(API側で無視される)。「短いSystem Promptしか持っていない軽量エージェント」では、Prompt Cachingの恩恵はそもそも出ない。逆に、長大なTool定義+大型RAGを抱えるエージェントほど、効果が指数関数的に伸びる。
TTL：5分と1時間の使い分け
cache_controlにはtypeとttlの2フィールドがある。デフォルトは5分TTLで、Anthropic公式ドキュメントが「ephemeral」と呼んでいるのもこの5分キャッシュのことだ。
// 5分TTL (default)
{"type": "ephemeral"}
// 1時間TTL (extended, beta header必須)
{"type": "ephemeral", "ttl": "1h"}1時間TTLを使う場合、HTTPヘッダーにanthropic-beta: extended-cache-ttl-2025-04-11を追加する必要がある(2026年5月時点のbeta状態。GA移行されると不要になる可能性あり)。
料金の非対称性：書き込みコストはTTLで2倍違う
Anthropicの公式料金ページ「Pricing」と「Prompt caching」ドキュメントから、以下の料金構造が読み取れる。
| 操作 | 5分TTL | 1時間TTL |
|---|---|---|
| キャッシュ書き込み(cache_creation_input_tokens) | 基本入力単価 × 1.25 | 基本入力単価 × 2.0 |
| キャッシュ読み出し(cache_read_input_tokens) | 基本入力単価 × 0.1 | 基本入力単価 × 0.1 |
| キャッシュなし通常入力(input_tokens) | 基本入力単価 × 1.0 | 基本入力単価 × 1.0 |
つまり「1回書き込んで何回読み出すか」がROIを決める。5分TTLなら2回読めば元が取れる(1.25 – 1.0 = 0.25増分を、0.9引きで返却するから0.25 / 0.9 ≒ 0.28回相当でブレークイーブン)。1時間TTLなら約1.12回読めば元が取れる計算になる。
どちらを使うべきか：エージェント運用観点
AIエージェントの実運用を見ると、TTLは次のように使い分けるのが現実的だ。
- 5分TTL：チャット型エージェント、人間とのリアルタイム対話。連続するターン間は数十秒〜数分なので5分で十分。書き込みコストが抑えられるので「とりあえず全部キャッシュ」できる
- 1時間TTL：バッチ処理、cron実行、巨大Tool定義を持つ専門エージェント、人間のチームメンバーが断続的に使う社内アシスタント
1時間TTLは「書き込みコストが5分の1.6倍(=2.0/1.25)」高い代わりに、キャッシュ保持期間が12倍になる。エージェントの平均アクセス間隔が「数分以上空く」運用なら、1時間TTLの方がトータルで安くなる。
コスト試算：実数で見るPrompt Cachingの効果
Claude Sonnet 4.5の公式料金(2026年5月時点)を使って、AIエージェントの典型ワークロードで計算してみる。
- 入力単価: $3 / 1M tokens
- 出力単価: $15 / 1M tokens
- キャッシュ書き込み(5分): $3.75 / 1M tokens(=$3 × 1.25)
- キャッシュ読み出し: $0.30 / 1M tokens(=$3 × 0.1)
ケース1：Tool定義+System Prompt 30,000 tokenを100回再利用
カスタムAIエージェントを想定。Tool定義 25個 + 詳細System Prompt = 合計30,000 token。ユーザーとの会話で100回呼び出される。
| 項目 | キャッシュなし | 5分TTLキャッシュあり |
|---|---|---|
| 初回書き込み | 30,000 × $3 / 1M = $0.090 | 30,000 × $3.75 / 1M = $0.1125 |
| 2〜100回目(99回) | 30,000 × 99 × $3 / 1M = $8.910 | 30,000 × 99 × $0.30 / 1M = $0.891 |
| 合計 | $9.000 | $1.004 |
| 削減率 | – | 約88.8%削減 |
同じワークロードで5分TTLの再書き込み(=5分以上空いた場合)が10回入ったとしても、削減率は約80%は維持される計算だ。
ケース2：20,000 token RAGコンテキスト × 連続10ターン会話
カスタマーサポート用エージェント。社内マニュアル等を毎ターンSystem PromptにRAGとして注入。1回の会話で10ターン続く。
| 項目 | キャッシュなし | 5分TTLキャッシュあり |
|---|---|---|
| 1ターン目(書き込み) | 20,000 × $3 / 1M = $0.060 | 20,000 × $3.75 / 1M = $0.075 |
| 2〜10ターン目(9ターン) | 20,000 × 9 × $3 / 1M = $0.540 | 20,000 × 9 × $0.30 / 1M = $0.054 |
| 合計 | $0.600 | $0.129 |
| 削減率 | – | 約78.5%削減 |
ケース3：1時間TTLでバッチ処理(50,000 token context × 1日200回呼び出し)
ナレッジベース検索系のバッチエージェント。1日200回、間隔は10分〜30分。5分TTLだと毎回書き直しになるが、1時間TTLなら持続する。
| 項目 | 5分TTL(毎回再書き込み) | 1時間TTL |
|---|---|---|
| 書き込み回数 | 200回 | 約24回(1時間に1回) |
| 書き込みコスト | 50,000 × 200 × $3.75 / 1M = $37.5 | 50,000 × 24 × $6.00 / 1M = $7.2 |
| 読み出しコスト | 0(毎回ミスのため) | 50,000 × 176 × $0.30 / 1M = $2.64 |
| 合計 | $37.5 | $9.84 |
1時間TTLは書き込み単価が2倍だが、アクセス間隔の長いバッチでは結果的に大幅安になる。
AIエージェントへの組み込みパターン
具体的にどう設計に落とし込むかを、3つの典型エージェント類型で見ていく。
パターン1：チャット型エージェント(Sonnet/Opus + 長文System Prompt)
ChatGPT風UIを持つカスタマーサポート/社内Q&A型。Tool定義 + System Prompt + 直近の会話履歴を毎回送る。
- Tool定義の末尾に1個目のcache_control
- System Prompt(role定義 + RAG context)の末尾に2個目のcache_control
- 過去の会話履歴の末尾(=最新ユーザー入力の直前)に3個目のcache_control
- 4個目は予備(動的に変わる長文を持つ場合に使う)
このパターンなら、ユーザーがメッセージを送るたびにTool+System+履歴の全部がキャッシュヒットする(5分以内なら)。AIエージェントのコスト最適化原則でも触れたとおり、長期セッションほど効果が累積する。
パターン2：自律実行型エージェント(Agent loop + Tool calling)
Claude Agent SDKやLangGraphで作る自律エージェントは、1つのタスクで10〜50回のLLM呼び出しが入る。毎回のSystem PromptとTool定義は同じだから、Prompt Cachingの効果が極大化する。
Claude Agent SDKの場合、SDK内部で自動的にcache_controlが挿入されるパターンがdocsで言及されている(Agent SDK overview)。具体的な実装はClaude Agent SDK(Python)実装ガイドで詳しく扱った。
from anthropic import Anthropic
client = Anthropic()
# 自律ループの中で同じTool定義+System Promptが何度も再利用される
def agent_step(messages, tools, system):
return client.messages.create(
model="claude-sonnet-4-5",
max_tokens=2048,
system=[
{
"type": "text",
"text": system,
"cache_control": {"type": "ephemeral"}
}
],
tools=[
{**tool, "cache_control": {"type": "ephemeral"}}
if i == len(tools) - 1 else tool
for i, tool in enumerate(tools)
],
messages=messages
)Tool配列の最後だけにcache_controlを付けるとTool配列全体がキャッシュ対象になる(prefix一致のため)。これでブレークポイントを1個節約できる。
パターン3：Claude Code / Claude Codeベースの開発支援エージェント
Claude CodeはCLAUDE.md + プロジェクトコンテキスト + ツール定義を毎ターン送り直すワークロードを持つ。Claude Code内部ではPrompt Cachingが自動的に有効化されている(Anthropic公式の発表ブログ「Prompt caching with Claude」でも言及)。
つまり開発者がCLAUDE.mdに大量の指示を書いても、2回目以降のターンではキャッシュヒットで90%引きで読まれる。「長いCLAUDE.mdはコストが心配」という認識はPrompt Caching前提のClaude Codeでは古い。むしろ詳細なルールを書いた方が品質も上がりコストも増えない設計になっている。
キャッシュが無効化される条件
公式docsから整理すると、以下のケースでキャッシュは新規書き込み扱いになる。
- prefixの1文字でも変わる：System Promptの先頭にタイムスタンプを入れる等
- モデルバージョンを変える：Sonnet 4からSonnet 4.5に切り替えるとキャッシュは別物
- tool_choiceを変える：
auto→anyのような切り替え - 5分(または1時間)の有効期限を超える：最後のアクセスから時間経過
- cache_controlを付けたブロックの内容が変わる：当然ながらキャッシュは別物になる
逆に「temperature / top_p / max_tokens / messages末尾の新規入力」は変えてもキャッシュには影響しない。これらはcache_controlで指定したprefixより後ろにあるからだ。
並列リクエストのキャッシュ競合
同じprefixで複数リクエストを並列同時送信した場合、初回は全部キャッシュミス扱いになる可能性がある(まだキャッシュエントリが作られる前にリクエストが届くため)。バッチ起動時は1リクエスト目を投げてから少し待って残りを並列化する、というパターンが安定する。
レスポンスの読み方：cache_creation/cache_read_input_tokens
Prompt Cachingが効いているかは、Messages APIのレスポンスusageフィールドで確認できる。
{
"usage": {
"input_tokens": 150,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 28500,
"output_tokens": 410
}
}このレスポンスは「28,500 tokenがキャッシュヒット、150 tokenだけが通常入力、新規書き込みなし」を示している。期待通りキャッシュが効いていれば、ログを取ってモニタリングできる。逆にcache_creation_input_tokensが毎回大きい値を返すなら、prefixが微妙にズレてキャッシュが効いていない疑いがある。
モニタリングTIPS：cache hit率を運用指標にする
本番AIエージェントでは、以下の比率をDatadog/CloudWatch/Slack通知で監視する設計が現実的だ。
- cache hit ratio: cache_read_input_tokens / (cache_read_input_tokens + cache_creation_input_tokens + input_tokens)
- cache cost share: cache関連支払い / 全LLM支払い
- cache miss alert: cache_hit_ratio < 0.5が10分続いたら通知
cache hit ratio が想定より低い時の原因は、たいてい「動的トークンがprefixに混入」「会話履歴のserialization順が不安定」のどちらかだ。AIエージェントのプロンプト設計パターンで紹介した固定部分/動的部分の分離が、ここでも効いてくる。
対応モデルと2026年5月時点の最新状況
2026年5月27日時点で、Prompt Cachingに対応している主なモデルは以下の通り。
| モデル | 5分TTL | 1時間TTL(beta) |
|---|---|---|
| Claude Opus 4 / Opus 4.1 | ○ | ○ |
| Claude Sonnet 4.5 / Sonnet 4 / Sonnet 3.7 / Sonnet 3.5 | ○ | ○ |
| Claude Haiku 4.5 | ○ | ○ |
| Claude Haiku 3.5 / Haiku 3 | ○ | ○ |
| Claude Opus 3 (legacy) | ○(限定) | – |
新規モデルがリリースされる際は、Anthropic公式のModels overviewに対応リストが更新される。エージェントを設計するときは、運用するモデルがPrompt Caching対応かを最初に確認しておくのが安全だ。
Vertex AI / Amazon Bedrock経由の場合
GCPのVertex AIやAWS Bedrock経由でClaudeを使う場合、Prompt Cachingのサポート状況はプラットフォーム依存になる。最新の対応状況は各クラウドベンダーのdocsを確認するのが確実だが、AnthropicのMessages API直接コールのほうが機能反映が早いという一般的な傾向はある。
よくある失敗パターン
失敗1：System Promptの先頭に日時を入れる
「今日は{{date}}です」をSystem Promptの冒頭に入れると、毎日(またはミリ秒単位だと毎回)prefixが変わって全部cache missになる。日時を入れたい場合はcache_control境界より後ろに置く。
失敗2：会話履歴をJSON.stringify()でserializeしてオブジェクト順がブレる
会話履歴をJSONとして再生成する時、キーの順序が実行ごとに変わるとprefixが一致しない。Python標準のjson.dumps(obj, sort_keys=True)のようにキー順を固定する習慣をつける。
失敗3：ブレークポイントを4個全部使ってしまい、増設できない
「とりあえず4個全部付ける」は実は危険。途中で「中間のあるブロックだけ変わる」要件が出ると、4個では足りなくなる。最初は2〜3個に抑えて、運用しながら追加するのが現実的。
失敗4：短いSystem Promptにcache_controlを付けて「効いてるつもり」になる
1,024 token(Haikuは2,048 token)未満のブロックにcache_controlを付けてもキャッシュは作られない。レスポンスのusage.cache_creation_input_tokensがゼロのままなら、最小トークン要件を満たしていない可能性が高い。
失敗5：Tool定義を毎回動的生成して順番がブレる
Toolリストの順番が毎回違うとprefixが変わる。「ユーザーの権限で表示する/しない」を切り替えるなら、全Toolを定義した上でtool_choiceを使って制御するか、ユーザー権限ごとにcacheを分けて使う。
キャッシュ階層設計の応用：マルチテナント・マルチユーザー対応
BtoB SaaS型のAIエージェントを設計するとき、テナント(顧客企業)ごとに異なるRAGコンテキストや権限制御が必要になる。Prompt Cachingのprefix一致ルールをそのまま適用すると、テナント単位でキャッシュが分かれることになり、キャッシュ書き込みコストがテナント数に比例して増える。これをどう設計するかは、本番運用の重要な分岐点だ。
テナント共通部分とテナント固有部分の分離
具体的には、System Promptを「全テナント共通の役割定義」と「テナント固有のRAG・ルール」に分け、ブレークポイントを2段階に置く設計が有効になる。
system: [
{
"type": "text",
"text": "あなたは{{product_name}}のAIエージェントです... (全顧客共通)",
"cache_control": {"type": "ephemeral"} // ← ブレークポイント1: 全顧客で共有可能
},
{
"type": "text",
"text": "## 顧客{{tenant_id}}固有のナレッジn(テナント固有RAG)",
"cache_control": {"type": "ephemeral"} // ← ブレークポイント2: テナント単位
}
]こうしておくと、ブレークポイント1までは「全顧客の最初の問い合わせで書き込まれたキャッシュを、別の顧客の問い合わせでも共有できる」効果が出る(prefixが完全一致しているため)。これはAnthropicの公式docs「Prompt caching」セクションでも触れられている挙動で、自分のorganization内であれば、キャッシュは複数リクエストで共有される。
テナント別RAGはキャッシュ書き込みコストを計画する
テナント固有のRAGは、テナント数だけキャッシュ書き込みが発生する。たとえばRAG 20,000 token × テナント100社 = 200万tokenの書き込みが、5分TTLで使い切られると毎時繰り返される計算になる。これは「アクティブテナント数を絞る」「テナントRAGは1時間TTLにする」のどちらかで吸収するのが現実的だ。
Extended caching(1時間TTL)の本格運用ノウハウ
1時間TTLを本格運用するときに、書き込みコスト×2.0倍を吸収できるかは、アクセス回数と間隔次第になる。具体的なシミュレーションをいくつかのパターンで見てみる。
シナリオA: 1時間に5回アクセスされるエージェント
30,000 tokenのcontextを1時間TTLでキャッシュ。書き込みコストは 30,000 × $6.00 / 1M = $0.180。残り4回の読み出しコストは 30,000 × 4 × $0.30 / 1M = $0.036。合計$0.216。同じワークロードをキャッシュなしで動かすと 30,000 × 5 × $3 / 1M = $0.450。約52%削減。
シナリオB: 1時間に20回アクセスされるエージェント
書き込み$0.180 + 読み出し 30,000 × 19 × $0.30 / 1M = $0.171。合計$0.351。キャッシュなしなら 30,000 × 20 × $3 / 1M = $1.800。約80%削減。
シナリオC: 1時間に2回しかアクセスされないエージェント
書き込み$0.180 + 読み出し 30,000 × 1 × $0.30 / 1M = $0.009。合計$0.189。キャッシュなしなら 30,000 × 2 × $3 / 1M = $0.180。1時間TTLの方がわずかに高い。このパターンでは1時間TTLを使う意味がない(5分TTLで2回読めれば良い)。
つまり1時間TTLは「1時間あたり3回以上のアクセスが見込めるなら勝ち」というのが、おおまかな目安になる。アクセスパターンが予測できないエージェントでは、まず5分TTLで運用して、Datadog等で実アクセス頻度を確認してから切り替えるのが安全だ。
セキュリティとプライバシー：キャッシュ越しに他人のデータが見えることはあるか
Prompt Cachingで頻繁に問われる懸念が「自分のキャッシュが他社に見えてしまわないか」だ。Anthropic公式docsの「Prompt caching」セクションでは、以下の3点が明記されている。
- キャッシュはorganization単位で隔離される(自分のorgのキャッシュが他orgから見えることはない)
- キャッシュ内容はTTL満了で自動削除される
- cacheはモデルの学習データとしては使われない(通常のAPI呼び出しと同じデータ取り扱い)
つまり、同じorganizationの中で複数のチーム・複数のAIエージェントがPrompt Cachingを使う場合、キャッシュは内部で共有されうる(prefixが一致すれば)。これはコスト面ではメリットだが、組織内で機密情報を扱うエージェント同士はcache_controlを明示的に分けるか、API Keyを分離するなどの設計を検討した方が良い。
運用設計：本番AIエージェントのPrompt Caching設計テンプレート
ここまでの話をまとめると、本番運用するAIエージェントのPrompt Caching設計は次のテンプレートに落とせる。
- レイヤー分離：Tool定義 / System role / RAG context / 会話履歴 / 動的入力、の5層に明確に分ける
- cache_controlを上から3層に置く：Tool末尾、System末尾(またはRAG末尾)、会話履歴末尾
- 動的部分は最後に集める：日時・ユーザーID・今回の質問、すべて最後のmessageに
- TTLはユースケースで選ぶ：人間のリアルタイム対話は5分、バッチ/cron/間隔の空く運用は1時間
- cache hit ratioを監視：0.7以下に落ちたら設計を再確認
- モデル切替時は最初の数十分はキャッシュコスト増を許容：書き込み単価×1.25 or ×2が一気に出る
このテンプレートを守れば、AIエージェントの推論コストはほぼ確実に半分以下まで落とせる。長文contextを使うエージェントなら70-90%減も普通に出る。
まとめ：Prompt Cachingは「設計でコストが決まる」機能
Prompt Cachingは「フラグを付けるだけ」の単純な機能に見えて、実際には「prefix完全一致」「最小トークン要件」「TTL選択」「ブレークポイント4個の配置」が絡む設計問題になっている。AIエージェントを本番運用する以上、ここを最適化できれば月額の推論コストは桁単位で動く。
逆に、設計が雑だと「キャッシュしてるつもりで実は毎回書き込みコストを払っている」「prefixが微妙にズレてcache miss」「短すぎてキャッシュされていない」といった見えにくい損失が積み上がる。本記事のチェックリストと試算を、自社のエージェント設計レビューに使ってほしい。
関連: AIエージェント運用コストの最適化7原則｜Claude Agent SDK(Python)で自律エージェントを実装する｜AIエージェントのプロンプト設計パターン
FAQ
Q. Prompt Cachingに追加料金は発生しますか？
追加の月額料金は発生しません。キャッシュ書き込みは入力単価の1.25倍(1時間TTLは2.0倍)、読み出しは0.1倍として、通常のtoken課金体系の中で精算されます。
Q. cache_controlを付けたのに効きません。
(1)最小トークン数(Opus/Sonnet=1,024 / Haiku=2,048)を満たしているか、(2)prefixが完全一致しているか(日時・ランダム値の混入)、(3)モデルバージョン・tool_choiceを変えていないか、を順に確認してください。レスポンスのusage.cache_creation_input_tokensとcache_read_input_tokensで診断できます。
Q. 1時間TTLはいつ使うべきですか？
呼び出し間隔が「5分以上空くことが多い」運用のとき。バッチ処理、cron、間欠的な社内アシスタント、夜間のバックグラウンドエージェントなどです。リアルタイムチャットなら5分TTLで十分です。
Q. Claude Codeを使うとPrompt Cachingは自動で効きますか？
はい。Anthropic公式のClaude Code(およびAgent SDK)では、内部的にcache_controlが自動挿入される実装になっています。CLAUDE.mdに大量の指示を書いても、2ターン目以降はキャッシュヒットで90%引きの単価になります。
Q. キャッシュ内容はAnthropic側に永続保存されますか？
いいえ。5分(または1時間)のTTLで自動消滅します。Anthropic公式docsで明記されている通り、Prompt Cachingは短期キャッシュであり、長期保存・学習目的での利用はされません。データ取り扱いはAnthropicのCommercial Termsに準じます。
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。Prompt Cachingを含むコスト最適化、Claude Agent SDKを使った自律エージェント実装、本番運用のモニタリング設計まで、開発組織への伴走支援を提供しています。
本記事はAnthropic公式ドキュメント(docs.anthropic.com)、Anthropic Pricingページ、Anthropic Blogを一次ソースとして執筆しています。料金・仕様は2026年5月27日時点のものであり、最新情報はAnthropic公式サイトをご確認ください。
著者: 佐藤傑(さとう・すぐる)｜株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。著書『AIエージェント仕事術』。
