Amazon Bedrockは、Claude 4.6向けのプロンプトキャッシュ機能を提供開始しました。この機能により、生成AIアプリケーションのレスポンス遅延を短縮し、推論コストを削減できます。この機能は、プロンプトの静的な部分を最大5分間保持することで、後続の呼び出しにおいて、そのテキストのコストのかかる再処理をスキップします。

キャッシュがリクエストチェーンにどのように組み込まれるか

Claude 4.6へのリクエストが届くと、2つのレイヤーが連携して動作します。

  • モデルレベル – Claude 4.6は、GPUメモリ内にキーバリュー（KV）キャッシュを保持します。モデルが最初に命令ブロックを解析すると、その結果としての内部表現が保存されます。同じブロックを再利用する後続の呼び出しでは、モデルは再計算する代わりにその表現を呼び出すことができます。

  • Bedrockレベル – Bedrockは、静的なプロンプトセグメントのフィンガープリントを計算します。新しいリクエストが一致するフィンガープリントを持っている場合、Bedrockはそれを、すでにキャッシュされた状態を保持しているGPUに直接ルーティングし、「ウォームアップ」ステージをバイパスします。

毎回新しく始めるのではなく、セーブデータをロードするようなものだと考えてください。

キャッシュを維持するためのルール

  1. 最小トークン数 – Claude Sonnet 4.6では、キャッシュされるセグメントに少なくとも1,024トークンが必要です。Claude Opus 4.6の場合は4,096トークンが必要です。これより小さい場合は無視されます。

  2. 5分間の有効期限 – キャッシュは5分間アクティビティがないと期限切れになります。ヒットするたびにタイマーがリセットされるため、継続的な呼び出しが行われていれば、キャッシュを無期限に維持できます。

  3. プロンプトの順序 – Bedrockはプロンプトを逐次的に読み取ります。静的な命令が最初に現れ、その後に cachePoint マーカーがあり、その後にすべてのユーザー生成メッセージが続く必要があります。マーカーより前の文字を1文字でも変更すると、フィンガープリントが壊れ、コールドリード（新規読み込み）が強制されます。

機能の実装方法

Bedrock Converse APIがエントリーポイントとなります。以下は、必要な構造を示す最小限のPythonスニペットです。

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
MODEL_ID = "anthropic.claude-sonnet-4-6"

# Must be >1,024 tokens for Sonnet
BASE_SYSTEM_PROMPT = "Your long instructions here..."

system_configuration = [
    {"text": BASE_SYSTEM_PROMPT},
    {"cachePoint": {"type": "default"}}
]

conversation_history = []

def run_chat_turn(user_input):
    global conversation_history
    conversation_history.append(
        {"role": "user", "content": [{"text": user_input}]}
    )

    response = bedrock.converse(
        modelId=MODEL_ID,
        system=system_configuration,
        messages=conversation_history,
        inferenceConfig={"maxTokens": 500, "temperature": 0.4}
    )

    assistant_message = response["output"]["message"]
    conversation_history.append(assistant_message)

    metrics = response["usage"]
    print(f"Read from cache: {metrics.get('cacheReadInputTokens', 0)}")

cachePoint は、不変のセグメントがどこで終わるかを Bedrock に伝えます。最初の呼び出しの後、cacheReadInputTokens メトリクスがゼロ以外の値を示していれば、キャッシュがヒットしたことが確認できます。

開発者が注目すべき理由

静的な命令と動的なユーザー入力を分離することで、作業負荷をコストの高いGPUサイクルから軽量なルーティングステップへと移行できます。チャットボット、検索拡張生成（RAG）パイプライン、または同じシステムプロンプトを繰り返すあらゆるサービスにおいて、その結果としてレスポンスが高速化し、課金対象となるトークン数が減少します。スループットの高いシナリオでは、計算時間のわずかな削減であっても、顕著なコスト削減につながる可能性があります。

制限事項とトレードオフ

この機能は、プロンプトセグメントが最小トークン数を満たし、かつ変更されない場合にのみ効果を発揮します。システム命令を頻繁に変更するアプリケーションや、短いプロンプトに依存するアプリケーションでは、メリットはほとんどありません。また、5分間のウィンドウがあるため、長いアイドル時間があるバースト的なトラフィックでは、繰り返しコールドリードが発生し、レイテンシの利点が損なわれる可能性があります。最後に、キャッシュはGPUメモリ内に存在します。複数のモデルが同じハードウェアを共有している場合、競合がパフォーマンスに影響を与える可能性がありますが、Bedrockはその詳細を公開していません。

次に注目すべき点

  • メトリクスのダッシュボード – キャッシュが意図した通りに使用されているかを確認するために、cacheReadInputTokens と全体のレイテンシを監視してください。
  • プロンプトエンジニアリング – リクエストを肥大化させることなく、サイズしきい値を満たすプロンプトを設計することは、開発者にとって新しい規律となります。
  • 将来の拡張 – Bedrockがキャッシュ期間を延長したり、トークン制限を緩和したりすれば、長期にわたる会話の経済性がさらに変化する可能性があります。

まとめ: プロンプトキャッシュは、十分に大きく不変のプロンプトを固定し、呼び出しを短い時間枠内に収めることができれば、Claude 4.6のユーザーに対してレスポンス時間とコストの両方を削減するための具体的な手段を提供します。同じシステム命令を繰り返すあらゆるGenAIサービスにとって、この機能は早期にテストする価値があります。