Amazon Web Services ブログ
Amazon Bedrock でプロンプトキャッシュを効果的に活用する方法
本記事は 2025 年 4 月 7 日に AWS Machine Learning Blog で公開された Effectively use prompt caching on Amazon Bedrock を翻訳したものです。翻訳はソリューションアーキテクトの川戸渉が担当しました。
Amazon Bedrock において、プロンプトキャッシュの一般提供が開始されました。Anthropic の Claude 3.5 Haiku と Claude 3.7 Sonnet に加え、 Nova Micro、 Nova Lite、 Nova Pro モデルで利用可能です。複数の API 呼び出しにおいて頻繁に使用されるプロンプトをキャッシュすることで、応答時間を最大 85% 短縮し、コストを最大 90% 削減します。
プロンプトキャッシュを使用すると、特定の連続したプロンプト部分 ( プロンプトプレフィックスと呼ばれます ) をキャッシュ対象として指定できます。指定されたプロンプトプレフィックスを含むリクエストが送信されると、モデルは入力を処理し、そのプレフィックスに関連する内部状態をキャッシュします。その後、同じプロンプトプレフィックスを含むリクエストがあると、モデルはキャッシュから読み取り、入力トークンの処理に必要な計算ステップをスキップします。これにより、最初のトークンが生成されるまでの時間 (time to first token, TTFT) が短縮され、ハードウェアがより効率的に利用されます。そのため、ユーザーはより安い価格でサービスを利用できます。
この記事では、Amazon Bedrock のプロンプトキャッシュに関する総合的な説明と、レイテンシー改善とコスト削減を実現するための効果的な活用方法を解説します。
プロンプトキャッシュの仕組み
大規模言語モデル (large language model, LLM) の処理は、主に 2 つの段階で構成されています。入力トークン処理と出力トークン生成です。 Amazon Bedrock のプロンプトキャッシュは、この入力トークン処理の段階を最適化します。
まず、プロンプトの関連部分にキャッシュチェックポイントを指定します。チェックポイントより前のプロンプト全体がキャッシュされるプロンプトプレフィックスになります。キャッシュチェックポイントで指定されたものと同じプロンプトプレフィックスを含むリクエストを送信すると、LLM はそのプレフィックスがキャッシュに既に保存されているかどうかを確認します。一致するプレフィックスが見つかった場合、LLM はキャッシュから読み取り、最後にキャッシュされたプレフィックスから入力処理を再開できます。これにより、プロンプトプレフィックスを再計算するために必要だった時間とコストを節約できます。
なお、モデルによってプロンプトキャッシュの対応状況が異なりますので、注意ください。対応しているモデル、サポートされているモデル、キャッシュチェックポイントあたりの最小トークン数とリクエストあたりの最大キャッシュチェックポイント数の詳細については、関連ドキュメントを確認してください。
キャッシュヒットは、プレフィックスが完全に一致した場合にのみ発生します。プロンプトキャッシュのメリットを最大限に活用するには、指示や例などの静的コンテンツをプロンプトの先頭に配置することをお勧めします。ユーザー固有の情報などの動的コンテンツは、プロンプトの末尾に配置してください。この原則は画像やツールにも適用され、キャッシングを有効にするためにはリクエスト間で同一である必要があります。
次の図は、キャッシュヒットの仕組みを説明しています。 A、B、C、D はプロンプトの異なる部分を表しています。 A、B、C がプロンプトプレフィックスとして指定されています。後続のリクエストに同じ A、B、C のプロンプトプレフィックスが含まれている場合、キャッシュヒットが発生します。
プロンプトキャッシュを使うべき場面
Amazon Bedrock のプロンプトキャッシュは、複数の API 呼び出しで頻繁に再利用される長いコンテキストプロンプトを扱うワークロードに適しています。この機能を使うと、レスポンスのレイテンシーを最大 85% 短縮し、推論コストを最大 90% 削減できるため、繰り返し使用される長い入力コンテキストを持つアプリケーションに特に適しています。プロンプトキャッシュがユースケースに有益かどうかを判断するには、キャッシュするトークン数、再利用の頻度、リクエスト間の時間を見積もる必要があります。
プロンプトキャッシュに適したユースケースを以下に示します:
- ドキュメントを使ったチャット – 最初のリクエストでドキュメントを入力コンテキストとしてキャッシュすることで、各ユーザークエリの処理が効率化されます。これにより、ベクトルデータベースのような複雑なソリューションを使わなくても、よりシンプルなアーキテクチャが実現できます。
- コーディングアシスタント – プロンプトで長いコードファイルを再利用することで、ほぼリアルタイムのインラインコード提案が可能になります。これにより、コードファイルを何度も再処理する時間を大幅に削減できます。
- エージェントワークフロー – より長いシステムプロンプトを使用してエージェントの動作を洗練させても、エンドユーザーの体験を損なうことがありません。システムプロンプトや複雑なツール定義をキャッシュすることで、エージェントフローの各ステップの処理時間を短縮できます。
- Few-shot 学習 – カスタマーサービスや技術的なトラブルシューティングなど、多数の高品質な例と複雑な指示を含める場合、プロンプトキャッシュが役立ちます。
プロンプトキャッシュの使用方法
プロンプトキャッシュを使用する際は、プロンプトの構成要素を「繰り返し使用される静的な部分」と「動的な部分」の 2 つのグループに分類することが重要です。プロンプトテンプレートは、次の図に示す構造に従う必要があります。
1 つのリクエスト内に複数のキャッシュチェックポイントを作成できます。ただし、モデルごとに制限があります。次の図に示すように、静的な部分、キャッシュチェックポイント、動的な部分という同じ構造に従う必要があります。
ユースケース例
プロンプトにドキュメントを含める「ドキュメントを使ったチャット」のユースケースは、プロンプトキャッシュに非常に適しています。この例では、プロンプトの静的な部分はレスポンスフォーマットに関する指示とドキュメント本文で構成されています。動的な部分はユーザーのクエリであり、これはリクエストごとに変わります。
このシナリオでは、プロンプトの静的な部分をプロンプトプレフィックスとして指定し、プロンプトキャッシュを有効にします。以下のコードスニペットは、 Invoke Model API を使用してこのアプローチを実装する方法を示しています。次の図に示すように、リクエスト内に 2 つのキャッシュチェックポイントを作成しています。1 つは指示用、もう 1 つはドキュメント本文用です。
以下のプロンプトを使用します:
上記のコードスニペットに対するレスポンスには、キャッシュの読み取りと書き込みに関するメトリクスを示す usage セクションがあります。以下は、最初のモデル呼び出しからのレスポンスの例です:
cache_creation_input_tokens
の値が 37,209 であることから、キャッシュチェックポイントが正常に作成され、 37,209 トークンがキャッシュされたことがわかります。この状態を次の図に示します。
次回のリクエストでは、別の質問をすることができます:
プロンプトの動的な部分は変更されましたが、静的な部分とプロンプトプレフィックスは同じままです。このため、続くモデル呼び出しではキャッシュが活用されることが期待できます。以下のコードをご覧ください:
37,209 トークンはキャッシュから読み込まれたドキュメントと指示内容に対応し、ユーザークエリ部分は 10 トークンとなっています。この状態を次の図に示します。
別のブログ記事にドキュメントを変更してみましょう。ただし、指示内容は同じままにします。今回のリクエストの構造は指示部分がドキュメント本文よりも前に配置されているため、指示部分のプロンプトプレフィックスについてはキャッシュヒットが期待できます。以下のコードをご覧ください:
レスポンスを確認すると、指示部分は 1,038 トークンをキャッシュから読み取っており、新しいドキュメント本文については 37,888 トークンをキャッシュに書き込んでいるのがわかります。この状態を、次の図に示します。
コスト削減効果
キャッシュヒットが発生すると、Amazon Bedrock はコンピューティングの節約分をキャッシュされたコンテキストのトークンごとの割引としてお客様に還元します。潜在的なコスト削減効果を計算するには、まず Amazon Bedrock のレスポンスにあるキャッシュ書き込み / 読み取りメトリクスを使用して、プロンプトキャッシュの使用パターンを把握する必要があります。その後、1,000 入力トークンあたりの価格 (キャッシュ書き込み) と 1,000 入力トークンあたりの価格 (キャッシュ読み取り) を使って潜在的なコスト削減効果を計算できます。詳しい価格情報については、 Amazon Bedrock の料金 をご覧ください。
レイテンシーベンチマーク
プロンプトキャッシュは、繰り返し使用されるプロンプトの TTFT パフォーマンスを向上させるために最適化されています。この機能は、チャットプレイグラウンドのような複数回のやり取りを伴う会話型アプリケーションに非常に適しています。また、大きなドキュメントを繰り返し参照する必要があるユースケースにも役立ちます。
ただし、2,000 トークンにも及ぶ長大なシステムプロンプトの後に、頻繁に内容が変わる長いテキストが続くようなワークロードでは、プロンプトキャッシュの効果があまり発揮されない場合があります。このような状況では、キャッシュによるメリットが限定的になってしまいます。
プロンプトキャッシュの使用方法とベンチマーク方法については、GitHub リポジトリにノートブックを公開しています。ベンチマーク結果は、入力トークン数、キャッシュされたトークン数、出力トークン数など、ユースケースによって異なります。
Amazon Bedrock クロスリージョン推論
プロンプトキャッシュは、クロスリージョン推論 (CRIS) と組み合わせて使用できます。クロスリージョン推論は、推論リクエストを処理するために地理的に最適な AWS リージョンを自動的に選択し、リソースとモデルの可用性を最大化します。需要が高い時期には、これらの最適化によりキャッシュ書き込みが増加する可能性があります。
メトリクスとオブザーバビリティ
プロンプトキャッシュのオブザーバビリティは、Amazon Bedrock を使用するアプリケーションのコスト削減とレイテンシー改善に不可欠です。主要なパフォーマンスメトリクスをモニタリングすることで、開発者は長いプロンプトの TTFT を最大 85% 削減し、コストを最大 90% カットするといった大幅な効率改善を達成できます。これらのメトリクスは、開発者がキャッシュパフォーマンスを正確に評価し、キャッシュ管理に関する戦略的な決定を行うために重要です。
Amazon Bedrock でのモニタリング
Amazon Bedrock は API レスポンスの usage
セクションでキャッシュパフォーマンスデータを提供しています。これにより開発者は、キャッシュヒット率、トークン消費量(読み取りと書き込みの両方)、レイテンシー改善などの重要なメトリクスを追跡できます。これらの情報を活用することで、チームはキャッシング戦略を効果的に管理し、アプリケーションの応答性を高め、運用コストを削減できます。
Amazon CloudWatch でのモニタリング
Amazon CloudWatch は AWS サービスの健全性とパフォーマンスをモニタリングするための強力なプラットフォームです。 Amazon Bedrock モデル専用の新しい自動ダッシュボードも含まれています。これらのダッシュボードは主要なメトリクスに素早くアクセスし、モデルのパフォーマンスをより深く理解できるようになっています。
カスタムオブザーバビリティダッシュボードを作成するには、以下の手順を実行します:
- CloudWatch コンソールで新しいダッシュボードを作成します。詳しい手順については、Improve visibility into Amazon Bedrock usage and performance with Amazon CloudWatch を参照ください。
- データソースタイプ欄の CloudWatch を選択し、初期のウィジェットのタイプとして 円 を選択します ( これは後で調整可能です ) 。
- メトリクスの時間範囲 ( 1 時間、 3 時間、 1 日など ) をモニタリングニーズに合わせて更新します
- AWS 名前空間で Bedrock を選択します
- 検索ボックスに「 cache 」と入力してキャッシュ関連のメトリクスをフィルタリングします
- モデルについては、 anthropic.claude-3-7-sonnet-20250219-v1:0 を見つけ、 CacheWriteInputTokenCount と CacheReadInputTokenCount の両方を選択します
- 「ウィジェットの作成」を選択し、その後「保存」を選んでダッシュボードを保存します
以下は、このウィジェットを作成するためのサンプル JSON 設定です:
キャッシュヒット率の把握
キャッシュヒット率を分析するには、 CacheReadInputTokens
と CacheWriteInputTokens
の両方のメトリクスを確認する必要があります。一定期間にわたってこれらのメトリクスを集計することで、キャッシング戦略の効率についての洞察を得ることができます。 Amazon Bedrock 料金ページに掲載されているモデル固有の 1,000 入力トークンあたりの価格(キャッシュ書き込み)と 1,000 入力トークンあたりの価格(キャッシュ読み取り)を使用すれば、特定のユースケースの潜在的なコスト削減を見積もることができます。
まとめ
この記事では、 Amazon Bedrock のプロンプトキャッシュについて、その仕組み、使用べき場面、効果的な活用方法を紹介しました。あなたのユースケースがこの機能の恩恵を受けるかどうかを慎重に評価することが重要です。プロンプトの構造を工夫すること、静的コンテンツと動的コンテンツの違いを理解すること、そして特定のニーズに合った適切なキャッシング戦略を選択することが重要です。CloudWatch メトリクスを使用してキャッシュパフォーマンスをモニタリングし、この記事で説明した実装パターンに従うことで、高いパフォーマンスを維持しながら、より効率的でコスト効果の高い AI アプリケーションを構築できます。
Amazon Bedrock のプロンプトキャッシュの使い方の詳細については、 Prompt caching for faster model inference を参照ください。
著者について
Sharon Li は、マサチューセッツ州ボストンを拠点とする Amazon Web Services (AWS) の AI/ML スペシャリストソリューションアーキテクトです。最先端技術の活用に情熱を持ち、 AWS クラウドプラットフォームで革新的な生成 AI ソリューションの開発と導入に取り組んでいます。
Shreyas Subramanian は、プリンシパルデータサイエンティストとして、生成 AI とディープラーニングを活用して AWS サービスを使用したビジネス課題の解決を支援しています。大規模最適化と機械学習のバックグラウンドを持ち、最適化タスクの加速に機械学習と強化学習を使用しています。
Satveer Khurpa は、 Amazon Web Services のシニア WW スペシャリストソリューションアーキテクトであり、 Amazon Bedrock セキュリティを専門としています。クラウドベースのアーキテクチャに関する専門知識を活かし、さまざまな業界のクライアント向けに革新的な生成 AI ソリューションを開発しています。生成 AI 技術とセキュリティ原則への深い理解により、堅牢なセキュリティ体制を維持しながら、新たなビジネス機会を開拓し、実質的な価値を推進するスケーラブルで安全かつ責任あるアプリケーションの設計を行っています。
Kosta Belz は、 AWS Generative AI Innovation Center のシニア応用科学者として、お客様が主要なビジネス課題を解決するための生成 AI ソリューションの設計と構築を支援しています。