Amazon Q in Connectのレイテンシー最適化を、ドキュメントのAIプロンプト最適化手法から読み解いてみた

はじめに

Amazon Q in Connectを利用するうえで、レスポンスのレイテンシーは重要な要素です。

ここで言うレスポンスのレイテンシーとは、モデルがプロンプトを処理して出力を生成するまでにかかる時間のことです。レイテンシーは、モデルのサイズ、プロンプトの複雑さ、モデルを支える基盤インフラストラクチャーなど、様々な要因の影響を受けます。

特にコンタクトセンター環境では、顧客の待機時間に直結するため、数秒の差が顧客体験に大きな影響を与えます。エージェントがAIからの推奨事項を待っている間、顧客は不安になり、満足度が低下する可能性があります。

今回はAWSドキュメントに記載されているAmazon Q in ConnectのAIプロンプトの最適化手法を解説します

なお、AWSドキュメントを確認すると、Amazon Q in ConnectのプロンプトキャッシュはAmazon Bedrockの機能をベースにしていることが分かります。コア技術、最適化原則、モデル要件はすべて共通しているため、本記事で紹介する手法はAmazon Bedrockでの生成AIアプリケーション開発にも活用できます。

Amazon Q in Connect ナレッジベース構成の概要

Amazon Q in Connectは、Amazon Bedrock上に構築されたサービスです。

Amazon Bedrock を利用: 自動不正検出 AWS を実装します。Amazon Q in Connect は Amazon Bedrock を基盤に構築されているため、ユーザーは Amazon Bedrock に実装されている制御を最大限に活用して、安全性、セキュリティを強制し、人工知能 (AI) の責任ある使用ができます。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/amazon-q-connect.html

ナレッジベースの仕組みは、RAG（Retrieval-Augmented Generation）構成に基づいています。
この仕組みでは、まずコンテンツを「チャンク」と呼ばれる単位に分割し、それらをベクトル埋め込みに変換してベクトルストアに保存します。クエリ実行時には、関連性の高いチャンクを検索・取得し、それらの情報を基に回答を生成します。

これはAmazon Bedrock ナレッジベースと同様のアーキテクチャです。

https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/kb-chunking.html

https://docs.aws.amazon.com/ja_jp/connect/latest/APIReference/API_amazon-q-connect_ChunkingConfiguration.html

Bedrock ナレッジベースと比較して、Q in Connectのナレッジベースでは、使用されるエンベディングモデルやベクトルストアの詳細はAWS側で管理されており、技術的な中身は公開されていません。

また、料金体系も大きく異なります。Bedrockナレッジベースでは、Bedrockのモデルの入力/出力トークン数による料金やベクトルストアのランニングコストが別途発生しますが、Q in Connectでは専用の料金体系として一括で課金されます。

AWSドキュメントのガイドライン

Amazon Q in ConnectのAWSドキュメントでは、AIプロンプトの最適化について段階的に説明されています。

https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/create-ai-prompts.html#supported-variables-yaml

AI プロンプトのパフォーマンス最適化

AI プロンプトのパフォーマンスを最適化するには、次のガイドラインに従ってください。

• プロンプトの変数の前に静的コンテンツを配置します。
• レイテンシーを最適化するには、少なくとも 1,000 個のトークンを含むプロンプトプレフィックスを使用します。
• レイテンシーのパフォーマンスを向上させるために、プレフィックスに静的コンテンツを追加します。
• 複数の変数を使用する場合は、少なくとも 1,000 個のトークンを持つ個別のプレフィックスを作成して、各変数を最適化します。

プロンプトキャッシュを使用したプロンプトレイテンシーの最適化

プロンプトキャッシュは、すべてのお客様に対してデフォルトで有効になっています。ただし、パフォーマンスを最大化するには、次のガイドラインに従ってください。

• プロンプトの変数の前にプロンプトの静的な部分を配置します。キャッシュは、各リクエスト間で変更されないプロンプトの一部でのみ機能します。
• プロンプトの各静的部分がトークン要件を満たしていることを確認し、プロンプトキャッシュを有効にします。
• 複数の変数を使用する場合、キャッシュは各変数で区切られ、要件を満たすプロンプトの静的部分を持つ変数のみがキャッシュの恩恵を受けます。

これらのガイドラインを詳しく解析してみましょう。

ガイドライン1：プロンプトの変数の前に静的コンテンツを配置

# ✅ キャッシュ最適化された構造
prompt: |
  You are an expert customer service AI assistant with comprehensive 
  training in technical support, customer psychology, and solution 
  optimization...

  [大量の静的な指示内容が続く... 1,000トークン以上]

  Customer Question: {{$.query}}
  Knowledge Base Results: {{$.contentExcerpt}}

# ❌ キャッシュ効果が得られない構造
prompt: |
  Customer Question: {{$.query}}

  You are a customer service assistant...
  [静的な指示内容が続く...]

理由：
Amazon Bedrock のドキュメントには以下のように記載されています。

これらのプロンプトプレフィックスはリクエスト間で静的である必要があります。後続のリクエストでプロンプトプレフィックスを変更すると、キャッシュミスが発生します。
https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/prompt-caching.html#prompt-caching-models

また、AWSブログでは以下のように説明されています。

キャッシュヒットは、プレフィックスが完全に一致した場合にのみ発生します。プロンプトキャッシュのメリットを最大限に活用するには、指示や例などの静的コンテンツをプロンプトの先頭に配置することをお勧めします。ユーザー固有の情報などの動的コンテンツは、プロンプトの末尾に配置してください。
https://aws.amazon.com/jp/blogs/news/effectively-use-prompt-caching-on-amazon-bedrock/

キャッシュはプロンプトの先頭から始まる完全一致を前提としています。先頭に変数があると、その値がリクエストごとに変わるため、先頭からの完全一致が崩れます。その結果、後続に静的コンテンツがあっても、全体がキャッシュミスとなり、キャッシュ効果が得られません。

ガイドライン2：少なくとも1,000個のトークンを含むプロンプトプレフィックス

この数字は、Amazon Bedrockのモデル別最小キャッシュ要件に基づいています。AWSドキュメントの「サポートされているモデル、リージョン、制限」では以下のように定義されています。

モデルによって最小トークン数が異なるため、使用するモデルに応じた適切なプロンプト設計が必要です。

# Claude 3.5 Haiku使用時の対応例
prompt: |
  # 基本指示（約800トークン）
  You are an expert customer service AI assistant...

  # 追加の詳細指示（1,200トークン以上）
  Detailed Guidelines for Customer Interaction:

  1. Communication Excellence Standards:
     - Always maintain a professional, empathetic tone
     - Use clear, jargon-free language appropriate to customer's expertise level
     - Acknowledge customer emotions and concerns before providing solutions
     - Provide step-by-step instructions when applicable
     - Confirm understanding before proceeding to next steps

  2. Technical Support Methodology:
     - Gather comprehensive information about the issue
     - Analyze root causes using systematic troubleshooting approach
     - Provide multiple solution options when available
     - Include preventive measures and best practices
     - Document resolution steps for future reference

  [さらに詳細な指示が続き、合計2,048トークンを超える...]

  # 動的変数
  {{$.transcript}}
  {{$.contentExcerpt}}
  {{$.query}}

ガイドライン3：複数の変数で個別プレフィックスを作成

AWSドキュメントでは以下のように説明されています。

複数の変数を使用する場合、キャッシュは各変数で区切られ、要件を満たすプロンプトの静的部分を持つ変数のみがキャッシュの恩恵を受けます。

推奨パターン：すべての変数を最後にまとめて配置

prompt: |
  # 大きな統合プレフィックス（3,000-5,000トークン）
  You are an expert customer service AI assistant...
  [すべての指示を統合した詳細なガイドライン]

  # 変数をまとめて配置
  Customer Profile: {{$.customerData}}
  Conversation History: {{$.transcript}}
  Current Question: {{$.query}}

すべての静的コンテンツを先頭にまとめ、変数を最後に配置する方法が最も効果的です。

この方法を推奨する理由は以下のとおりです。

• キャッシュ効率の最大化: 大きな単一キャッシュブロックは、複数の小さなブロックよりも効率的です
• 管理性の向上: すべての静的指示が1箇所にまとまっているため、プロンプトの更新や保守が簡単になります
• AWSベストプラクティス: 実際にAWSのデフォルトプロンプトもこの構造を採用しており、実証済みの設計パターンです

デフォルトAIプロンプトに見る最適化の実例

実際に、AWSが提供するデフォルトのAIプロンプトを見ると、最適化原則が適用されていました。

SELF_SERVICE_PRE_PROCESSINGプロンプトの構造

# 大量の静的コンテンツ（数千トークン）
system: [長い指示]
tools: [詳細なツール定義] 
messages: [豊富な例とルール]

# 変数は最後に配置
<conversation>
{{$.transcript}}
</conversation>

https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/default-ai-system.html

変数の活用

AWSドキュメントでは、Q in ConnectのAIプロンプトで使用できる変数について以下のように説明されています。

AI プロンプトに変数を追加する

変数は、AI プロンプトの動的入力のプレースホルダーです。変数の値は、指示が LLM に送信されるとコンテンツに置き換えられます。

これらの変数を効果的に活用することで、動的なコンテキストに応じた柔軟なAI応答を実現できます。特に{{$.transcript}}は会話履歴を、{{$.contentExcerpt}}はナレッジベースの情報を参照できるため、より正確で文脈に沿った回答生成が可能になります。

AIプロンプトのモデル選択

これまで解説したプロンプト最適化手法を実装する際は、適切なモデル選択が重要です。特に、プロンプトキャッシュとクロスリージョン推論の両方に対応したモデルを選択することで、最大のパフォーマンス向上を実現できます。

東京リージョン（ap-northeast-1）対応モデル一覧

東京リージョンのAIプロンプトで対応されているモデルは以下のとおりです。

クロスリージョン推論は、推論リクエストを複数のAWSリージョンに自動的に分散し、利用可能なリソースを最適化してスループットを向上させる機能です。単一リージョンよりも高いパフォーマンスを実現し、予期しないトラフィックバーストもシームレスに処理できるため、レイテンシーの改善にも寄与します。

よって、利用推奨モデル（東京リージョン）は以下のとおりです。

• 高性能 + キャッシュ最適化: apac.anthropic.claude-sonnet-4-20250514-v1:0 または apac.amazon.nova-pro-v1:0（最大20,000トークンキャッシュ）
• 軽量 + キャッシュ最適化: apac.amazon.nova-lite-v1:0 または apac.amazon.nova-micro-v1:0

最後に

Amazon Q in ConnectのAIプロンプト最適化は、単なるパフォーマンスチューニングではなく、顧客体験の向上に直結する重要な技術です。

これらの手法を適切に実装することで、レスポンス時間の大幅な改善とコスト最適化を同時に実現できます。

AWSドキュメントの分析から、プロンプト最適化において最も重要なのは以下の2点です。

1. AIプロンプトの変数は最後にまとめて配置
2. クロスリージョンとプロンプトキャッシュに対応しているモデルを選択

この2点を実践することで、レスポンスのレイテンシー短縮を実現できます。デフォルトAIプロンプトもこのパターンを採用しており、実証済みの設計手法です。

参考

https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/prompt-caching.html#prompt-caching-models

https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/cross-region-inference.html