Bedrockのレスポンス表示高速化を試してみた

▼概要
Amazon Bedrockのストリーム処理可能なAPIを使い、WebSocketとLambda関数URLでレスポンス表示を早くできないか試してみたという内容です。

▼AkarengaLT vol.38(2025-10-19)
- イベントリンク：https://engineercafe.connpass.com/event/370316/
youtube：https://www.youtube.com/live/DKhM_FJxZwU?si=QSPLfN37hkLauqef

Transcript

1. Bedrockのレスポンス表示高速化を試してみた - ユーザの待機時間を改善する - Akalenga LT 10/19 Y. Nakamura
2. プロフィール 2 Y. Nakamura - Web Engineer - GitHub ：enumura1
3. アジェンダ 3 1. 2パターンのレスポンス速度比較 2. なぜ「高速化」なのか？ 3. 実装内容 4. 代替案 5. 結果の比較 6. まとめ
4. アジェンダ 4 1. 2パターンのレスポンス速度比較 2. なぜ「高速化」なのか？ 3. 実装内容 4. 代替案 5. 結果の比較 6. まとめ
5. 2パターンの実際に比べてみた 5 左：ストリーム処理 ver 右：全てのレスポンス生成を待つ ver ※1: Lambdaはウォームスタート状態で検証 動画
6. アジェンダ 6 1. 2パターンのレスポンス速度比較 2. なぜ「高速化」なのか？ 3. 実装内容 4. 代替案 5. 結果の比較 6. まとめ
7. なぜ「高速化」なのか？ 7 • LLMからのレスポンス結果をまとめて返す構成（※1） ◦ Client → REST API → Lambda → Bedrock • 課題点 ◦ レスポンスが全文生成完了まで待ち時間が長い ▪ UXが低下・・😢 ※1: スライド1の動画だと右の方
8. なぜ「高速化」なのか？ 8 ▼全てのレスポンスを待つ ver
9. なぜ「高速化」なのか？ 9 • LLMからのレスポンス結果をまとめて返す構成（※1） ◦ Client → REST API → Lambda → Bedrock • 課題点 ◦ レスポンスが全文生成完了まで待ち時間が長い ▪ UX体験が低下・・😢 • 改善策 ◦ ストリーム処理で Bedrockのレスポンスをより早く表示する ※1: スライド5の動画だと左の方
10. アジェンダ 10 1. 2パターンのレスポンス速度比較 2. なぜ「高速化」なのか？ 3. 実装内容 4. 代替案 5. 結果の比較 6. まとめ
11. 実装内容 11 ▼今回作った構成 参考： Serverless generative AI architectural patterns – Part 1
12. 実装内容 12 ▼Bedrockで使用したモデル 参考： Supported Regions and models for inference profiles • Claude 4.5 sonnet • 日本国内に閉じた形でのクロス リージョン推論 ◦ 東京 or 大阪
13. 実装内容 ▼websocketを使ったストリーム処理 ver
14. 1. Bedrockのストリーム処理 2. websocketのフレームでレスポンスを返却 実装内容 14 ▼工夫した点
15. 1. Bedrockのストリーム処理 2. websocketのフレームでレスポンスを返却 実装内容 15 ▼工夫した点
16. 実装内容 16 1. Bedrockのストリーム処理 ストリーミング応答 API
17. • invoke_model_with_response_stream ◦ Amazon Bedrock のストリーミング応答API • 2つのAPIの違い ◦ invoke_model: 生成完了後に一括レスポンス ◦ invoke_model_with_response_stream: 生成中に逐次レスポンス 実装内容 17 1. Bedrockのストリーム処理
18. 実装内容 18 ▼例: invoke_model ▼例: invoke_model_with_response_stream 呼び出し方 レスポンス
19. 実装内容 19 2. websocketのフレームでレスポンスを返却 Bedrockから受け取った各チャンクを、 WebSocketの各フレームで返却
20. • クライアントとサーバが双方向に通信できる仕組み • メリット： ◦ 接続が確立すれば ▪ リアルタイム性の高い通信 ▪ サーバ側から任意のタイミングで情報送信 • デメリット： ◦ 接続管理が複雑 そもそもwebsocketって何？ 実装内容
21. 実装内容 ブラウザ画面 devtools > websocket input output
22. 実装内容 22 ただ websocket って実装コスト高そう・・
23. 実装内容 23 ただ websocket って実装コスト高そう・・ LLMのレスポンスを早く画面上に表示したいから websocketを使うのってちょっと微妙 本来、チャットアプリ・オンラインゲームで使われるもの
24. 実装内容 24 ただ websocket って実装コスト高そう・・ 他に実装方法はないの・・？ LLMのレスポンスを早く画面上に表示したいから websocketを使うのってちょっと微妙 本来、チャットアプリ・オンラインゲームで使われるもの
25. アジェンダ 25 1. 2パターンのレスポンス速度比較 2. なぜ「高速化」なのか？ 3. 実装内容 4. 代替案 5. 結果の比較 6. まとめ
26. 代替の構成 26 ▼代替の実装案 • Lambda a. 関数URL化 b. レスポンスストリーミングを有効化
27. 代替の構成 27 • before: API Gatewayを介したリクエスト • after: 直接Lambda関数にリクエスト HTTP POST ▼構成
28. 代替の構成 28 ▼代替の実装案 • Lambda a. 関数URL化 b. レスポンスストリーミングを有効化
29. 代替の構成 29 コンソール > Lambda > 関数を選択 ⇒ エンドポイント： https://<function-id>.lambda-url.<region>.on.aws/ ① ② ③
30. 代替の構成 30 ▼考慮しないといけない事 1. WAFとの直接統合ができない a. 代替案：CloudFront の活用 i. WAF ⇒ CloudFront OAC⇒ 関数URL化したLambda 2. 認証方法が IAM認証のみ
31. 代替の構成 31 • Lambda a. 関数URL化 b. レスポンスストリーミングを有効化 ▼代替の実装案
32. 代替の構成 32 ▼レスポンスストリーミングを有効化 • 関数URL化したLambdaで設定できる機能の1つ • データを一度に返すのではなく、chunked transfer encoding により、 HTTP クライアントに生データをストリームで返す機能 • Node.js しか現状サポートしてない（2025/10/13 時点） 参考：AWS Lambda レスポンスストリーミングの紹介
33. 代替の構成 33 チェック
34. 代替の構成 34 ▼例: responseStream処理 Bedrockのストリーム処理を streamifyResponse() でラップ 参考：AWS Lambda レスポンスストリーミングの紹介 クライアントに逐次レスポンスを返却
35. 代替の構成 35 • WebSocket : ◦ HTTP リクエスト → WebSocketにアップグレード → メッセージの双方向通信 → 切断処理 → 終了 • 関数URL化したLambda（ストリーミング ver）: ◦ HTTP リクエスト → メッセージchunk分割して逐次送信 → 終了 ▼処理フローの違い
36. 代替の構成 36 結局どっちが早いの？
37. アジェンダ 37 1. 2パターンのレスポンス速度比較 2. なぜ「高速化」なのか？ 3. 実装内容 4. 代替案 5. 結果の比較 6. まとめ
38. 結果の比較 38 左：WebSocket ver 右：関数URL化したLambda ver 動画
39. 結果の比較（最初の 1文字が画面に表示されるまでの時間） 39 No websocket（s） 関数URL化Lambda（s） REST API構成（s） 1 2.26 2.26 6.18 2 2.15 1.97 6.16 3 2.09 2.13 7.15 4 2.08 2.13 11.61 5 1.87 2.03 5.93 6 1.68 1.65 6.53 7 2.25 2.03 7.33 8 2.03 1.88 6.25 9 1.81 2.01 6.40 10 2.11 1.73 5.81 10回の平均 約 2.03 (s) 約 1.98 (s) 約 6.94 (s)
40. 結果の比較 40 さらに早くするには？
41. 結果の比較 41 • モデルを claude 4.5 haiku に変える • Bedrockのプロビションスループットの購入してモデル実行枠を確保 • Lambdaのメモリを10GB（MAX）まで上げる • Bedrockのプロンプトキャッシュの使用 ▼さらにレイテンシを改善するには？（可能性として）
42. アジェンダ 42 1. 2パターンのレスポンス速度比較 2. なぜ「高速化」なのか？ 3. 実装内容 4. 代替案 5. 結果の比較 6. まとめ
43. まとめ • Bedrockのレスポンス待機時間を改善 ◦ ストリーミング応答できるAPI 使える ◦ WebSocket or 関数URL化したLambda ▪ 分割されたレスポンスを逐次返却できる ▪ REST API構成より待機時間が改善 ▪ レスポンスが長いほどストリーム処理の効果が顕著 • WebSocket or 関数URL化したLambda ◦ トレードオフがあるので、選ぶ場合はそれぞれ要件を考慮
44. Appendix Appendix
45. Appendix: Lambdaの設定値 • メモリ：128MB • タイムアウト：60秒 • ランタイム： ◦ 関数URL化ver：Node.js 20.x ◦ それ以外：python3.12 • アーキテクチャ：arm64 ▼検証に使用した Lambdaの設定値
46. Appendix : 検証環境 46 ▼環境周り • ブラウザ： chrome ◦ version: 141.0.7390.76 ◦ シークレットモード • Lambdaはウォームスタート状態 • メモリ：128mb • プロンプト： ◦ 旅行で東京に行った際のおすすめ観光地を 200文字くらいで教えてください
47. Appendix: 選択可能なプロファイル ▼Bedrockで選択可能な sonnet4.5のプロファイル 上記は2025/10/11時点のもの
48. Appendix: WebSocket通信フロー図
49. Appendix: 実装内容 49 画像は Serverless generative AI architectural patterns – Part 1 > Pattern 2: Asynchronous request response > WebSocket APIs より引用 ▼参考
50. Appendix: 代替の構成 50 画像は Serverless generative AI architectural patterns – Part 1 > Pattern 3: Asynchronous streaming response > Fig 10 より引用 ▼参考
51. Appendix: コンポーネントのメモ化 • やったこと： コンポーネントのmemo化 • 目的： コンポーネントの不要な再レンダリングを抑える
52. Appendix: コンポーネントのメモ化 • 実装状況： ① websocketならフレーム、関数URL化したLambdaならチャンク分割されたレス ポンスが返ってくる ② 分割されたレスポンスが返ってくるごとにuseStateで状態変数を更新 • 課題： ◦ 何もしなかったら画面全体が何度も再レンダリングされてしまう
53. Appendix: コンポーネントのメモ化 • 対応策： ◦ memoで固定のコンポーネントをラップ • before： ◦ 分割されたレスポンスが返ってくるたびに画面全体が再レンダリング • after： ◦ レスポンスを表示する部分だけ再レンダリングされる
54. 54 ▼devtools > レンダリング > 再ペイントを有効化して確認 Appendix: コンポーネントのメモ化
55. • リポジトリ： ◦ https://github.com/enumura1/llm-stream-backend-demo • zennfes2025フリーテーマ記事： ◦ BedrockでWebSocketとLambda関数URLを使ったスト リーミング実装 Appendix: その他のリンク