Prompt Caching

プロンプトキャッシングの仕組み：「キャッシュプレフィックス」とは何で、なぜコストを大幅に削減できるのか？

Claude APIの課金方式はトークン単位です——各APIコールの入力トークン数が入力コストを決定します。

多くのアプリケーションでは、各APIコールの「前半部分」（System Prompt、背景ドキュメント、役割設定）は全く同じで、「後半部分」（ユーザーの質問）のみが毎回異なります。プロンプトキャッシングなしでは、内容が全く同じであっても毎回APIコールで完全なSystem Promptを再計算します。

プロンプトキャッシングの原理：最初のAPIコール時にAnthropicのサーバーがSystem Promptの「中間計算状態」（KVキャッシュ）を計算して保存；後続の呼び出しはこのキャッシュを読み取るだけで再計算不要。キャッシュ読み取りコストは元の計算コストの10%です。

キャッシュTTLは5分で、ヒットするたびにリセットされます。

APIでプロンプトキャッシングを正しく実装するには？よくある実装ミスは？

正しい実装方法：

response = client.messages.create(
    model="claude-sonnet-4-5",
    system=[
        {
            "type": "text",
            "text": "固定のSystem Promptコンテンツ（1,024トークンを超える必要がある）",
            "cache_control": {"type": "ephemeral"}  # これでキャッシングを有効化
        }
    ],
    messages=[{"role": "user", "content": user_question}]
)

よくある実装ミス：

ミス1：System Promptが短すぎる（1,024トークン未満）——Anthropicの最小キャッシュ要件は1,024トークンです。

ミス2：毎回変更されるコンテンツにキャッシュマーカーを追加——コンテンツが全く同じ場合にのみキャッシュがヒットします。

ミス3：キャッシュが実際にヒットしているか確認しない——レスポンスのusageフィールドのcache_read_input_tokensを確認します。

プロンプトキャッシングに最適なアプリケーションシナリオは？期待されるコスト削減の計算方法は？

プロンプトキャッシングに最適なシナリオ：

マルチターン会話アプリケーション——各ラウンドのSystem Promptは同じで、ユーザーメッセージとアシスタントの返答のみが累積します。

ナレッジベースQ&A（RAG）——System Promptに長いナレッジベースドキュメントを配置し、異なるユーザーの質問が同じドキュメントをコンテキストとして使用します。

バッチ処理——同じ分析指示で大量のドキュメントを処理します。

コスト削減の推定式：

期待される月次節約 = (System Promptトークン × 呼び出し回数 × キャッシュヒット率 × 0.9 × 入力レート)

プロンプトキャッシングと他のコスト最適化戦略（モデルダウングレード、出力長制御）を組み合わせて最も効果的に使用するには？

組み合わせ1：プロンプトキャッシング + 階層型ルーティング

Haikuを分類ルーティングに使用し、複雑さに基づいてSonnetまたはOpusを選択します。各モデルでプロンプトキャッシングを個別に有効化します。この組み合わせは通常コストを60〜75%削減します。

組み合わせ2：プロンプトキャッシング + 会話履歴管理

長い会話では、履歴を合理的な範囲内に制御しながらSystem Promptのキャッシングを有効化します。

組み合わせ3：プロンプトキャッシング + Batch API

AnthropicのBatch APIはリアルタイムAPIの50%のコストで一度に多くのリクエストを送信できます。プロンプトキャッシングと組み合わせると、バッチ処理のコスト削減は80〜90%に達することができます。