Claude Codeのプロンプトキャッシュの仕組みを徹底解説：セッション再開時のコスト高騰の正体
AI開発環境「Claude Code」におけるプロンプトキャッシュの仕組みと、セッション再開時のコスト構造について詳細な分析がなされました。本記事は、ユーザーが「なぜか再開の1ターン目だけコストが高い」と感じる現象の技術的な根拠を明らかにしています。
**【何が起きているか（What/Why）】**
Claude Codeは、モデルが会話の履歴を記憶していないため、毎ターン、会話の全履歴をAPIに送り直す必要があります。通常、この全履歴を再処理すると高額な課金が発生しますが、プロンプトキャッシュ機能が、前回と同じ部分（プリフィックス）をキャッシュから読み込むことでコストを大幅に削減しています。しかし、このキャッシュには「寿命（TTL: Time To Live）」が存在します。長時間放置したり、レスポンス生成に時間がかかりすぎたりしてキャッシュが失効すると、次のリクエストでは全履歴を書き直す（再構築する）必要が生じ、これがコストの急激な上昇を引き起こします。
**【コスト構造と単価の差（How）】**
コストは、キャッシュが生きている状態（Cache Read）と、キャッシュが切れた直後の書き込み（Write）で単価が大きく異なります。特にFable 5.1モデルの場合、キャッシュが生きている状態ではBase Inputの0.025倍という極めて低い単価で処理されますが、キャッシュが切れた直後の書き込み（1時間Write）ではBase Inputの2倍となり、その差は最大80倍にも及びます。この80倍という数字は、書き込み単価が高いというより、キャッシュが効いている状態が極端に安いため、相対的に高く見えるものです。
**【実用的な注意点（When/How）】**
キャッシュの寿命は、認証方法によって異なります。サブスクリプション利用ではメイン会話に1時間、APIキーやAmazon Bedrockなどでは5分が標準的なTTLです。特にAPIキー運用で「短いやり取りは問題ないが、長い作業の後は毎回キャッシュが切れている」と感じる場合、このTTLの制限が原因である可能性が高いです。また、セッションを継続的に使用する場合、放置するよりは早めに作業に戻るか、`/clear`コマンドで意図的にキャッシュを消去する方が効率的です。作業の区切りで`/compact`コマンドを使用し、履歴を圧縮しておくことも、再構築コストを抑える有効な手段です。
本記事は、ユーザーがAI開発のコスト構造を深く理解し、より効率的かつ経済的にClaude Codeを利用するための重要な知見を提供しています。
背景
大規模言語モデル（LLM）を用いた開発環境では、会話の履歴（コンテキスト）を維持することが不可欠です。しかし、履歴が長くなるほどAPIへの送信データ量が増え、コストが膨大になります。プロンプトキャッシュは、この履歴の重複送信を防ぎ、コスト効率を劇的に改善する仕組みですが、そのキャッシュの寿命（TTL）と再構築時のコスト構造が、ユーザーが直面する「コストの急増」の主な原因となっています。
重要用語解説
- プロンプトキャッシュ: LLMの会話履歴の特定部分（プリフィックス）を一時的に保存する仕組み。再利用することで、毎回全履歴を送信する手間とコストを削減する。
- TTL (Time To Live): キャッシュデータが保持できる時間制限のこと。この時間が経過すると、データは失効し、次のリクエストではキャッシュが使えなくなる。
- Base Input: プロンプトキャッシュを使用せず、会話の全履歴を最初からAPIに送信した場合の、最も基本的な入力コスト（単価）のこと。
今後の影響
本知識を得ることで、ユーザーは単に「遅い」「高い」という感覚的な問題ではなく、コスト構造に基づいた具体的なワークフロー改善が可能になります。特に、長時間セッションを維持する際は、TTLを意識した作業の区切り方や、`/compact`などの前処理を組み込むことで、API利用の経済性を大幅に向上させることが期待されます。