大手メディア企業がAmazon Bedrockを使ったコンテンツ生成パイプラインを本番運用しています。一部のAPIリクエストで通常の3〜4倍のレイテンシが断続的に発生しており、ユーザー体験に悪影響を与えています。エンジニアチームが根本原因を特定するために最初に実施すべきアクションはどれですか？
断続的な高レイテンシのトラブルシューティングでは、まず観測データを収集して根本原因を特定することが必要です。Amazon Bedrock Model Invocation Loggingを有効化すると、各リクエストの推論レイテンシ・入力/出力トークン数・モデルID・タイムスタンプなどがCloudWatch LogsまたはS3に記録されます。CloudWatch Logs Insightsでこれらのフィールドをクエリすることで、遅延が高いリクエストの共通属性（大きな入力トークン数・特定モデル・ピーク時間帯のスロットリングなど）を特定し、適切な対策（Provisioned Throughput・チャンク分割・負荷分散など）を根拠を持って選択できます。 選択肢BのInvokeModelWithResponseStreamへの変更は体感レイテンシを改善しますが、実際の総推論時間は変わらず、根本原因の特定につながりません。 選択肢CのProvisioned Throughputへの移行はスロットリングが原因の場合に有効ですが、診断前に高コストのリソース変更を実施するのは時期尚早で、原因が別にある場合は効果がありません。 選択肢DのAPI Gatewayキャッシュはまったく同一のリクエストにしか機能せず、コンテンツ生成のような多様なリクエストパターンでは命中率が極めて低くなり、根本原因の解明にも貢献しません。