対話型音声AIアプリケーションの信頼性向上の取り組み

2025/07/11に開催された「SRE NEXT 2025」に、IVRyの森谷と渡部が登壇しました。

■リンク集
・IVRyコーポレートサイト：https://ivry.jp/company/
・IVRy採用ページ：https://ivry-jp.notion.site/
・IVRyイベント一覧：https://ivry.connpass.com/event/
・IVRy Tech Xアカウント：https://x.com/IVRy_tech

Transcript

1. confidential ~ Webアプリケーション以外でどうSREを実践するのか ~ 対話型⾳声AIアプリケーションの 信頼性向上の取り組み 2025/07/11 1
2. confidential LLMを組み込むと、最⾼のプロダクトが作れる！ 2
3. confidential LLMを組み込むと、最⾼のプロダクトが作れる！ 3
4. confidential LLM APIを利⽤した 対話アプリケーション運⽤の 取り組み 4
5. confidential 5 LLM APIのプロダクトへの組み込み LLM APIの監視・運用 Hiroyuki Moriya AI engineer / SRE ⾃⼰紹介
6. confidential 6 SRE NEXT 2025 Co-Chair 好きなWebSocketのCloseEventコード: 1005 Ryuichi Watanabe SRE ⾃⼰紹介
7. 7 1. IVRyについて 2. LLM API 3. WebSocket 4. まとめ アジェンダ
8. confidential IVRyについて 8
9. confidential 会社紹介 9 会社名 代表取締役 事業内容 住所 資本⾦等 設⽴年⽉ 株式会社IVRy（アイブリー） 奥⻄ 亮賀（Ryoga Okunishi） クラウド型AI電話SaaS（アイブリー）の運営 〒108-0073東京都港区三⽥三丁⽬5-19 住友不動産東京三⽥ガーデンタワー10F 46.1億円（準備⾦含む） 2019年3⽉
10. 10 電話⾃動応答サービス プロダクト
11. confidential 11 システムアーキテクチャ
12. confidential 12 システムアーキテクチャ
13. confidential 13 システムアーキテクチャ
14. confidential IVRyの技術スタック 14
15. confidential 電話は今でも最重要連絡⼿段 15
16. confidential 16 あらゆる業種‧企業規模のお客様に導⼊
17. confidential 対話型AIアプリケーションの難しさ LLM APIの プロダクト運用 Challenge #1 WebSocketの プロダクト運用 Challenge #2 17
18. confidential LLM API part 18
19. confidential ハルシネーションの 抑制 Challenge #1 LLM APIの安定運用 Challenge #2 LLM APIを本番運⽤する難しさ 19
20. confidential ハルシネーションの抑制 20
21. 21 LLMはハルシネーションする Problem
22. confidential 困難は分割せよ 22 Solution
23. confidential AI workflowによる実装 23 1つのタスクを複数のLLM componentで分割して処理する → validation‧error分析が⾏えるようになり、安定した結果を出⼒できる
24. confidential 確認を怠らない 24 Solution
25. confidential ⾃動 電話 e2e test 25
26. confidential 26
27. confidential 27
28. confidential 28
29. confidential 29 Merge code Deploy latest code Execute automated phone E2E tests Monitor on Datadog LLM Observability 電話 e2e testをコードマージ時に 実⾏させる
30. confidential 30 Datadog LLM Observability による監視
31. LLM APIの安定運⽤ 31
32. システム障害は多くの影響を引き起こす 32 Problem
33. confidential LLM APIは不安定である 33 LLM API Status in one day
34. confidential 完璧を求めない 34 Solution
35. confidential 35 Fast, stable, and cheap Slower, more $$$ Stability & performance > latest models 自分たちのユースケースに合っ たモデル選定をする。
36. confidential システム監視を怠らない 36 Solution
37. confidential 37 Datadog Inferred Servicesによる 外部通信の監視
38. confidential 38 Inferred serviceを通して、多くのmetricsを監視できる
39. confidential 最悪の事態に備える 39 Solution
40. confidential 40 複数のLLM APIを利用して、 fallbackシステムを実装する LLM fallback strategy
41. confidential 困難は分割せよ / 確認を怠らない 01 ハルシネーションの抑制 完璧を求めない / システム監視を怠らない 02 会話を自然な速度にするために 最悪の事態に備える 03 障害への対策 まとめ： LLMをプロダクト 運⽤するために 41
42. confidential WebSocketプロダクト運⽤ 42
43. confidential なぜ突然WebSocket？ 43
44. confidential 44 Simplified system architecture
45. confidential 45 Simplified system architecture
46. confidential WebSocketの特徴 46
47. confidential WebSocketの特徴 • RFC6445 で定義されている • 双⽅向通信‧全⼆重通信 ◦ クライアントとサーバーの両⽅が同時にデータを送受信可能 ◦ HTTPとは異なり、リクエスト‧レスポンスの概念がない • 接続を⼀度確⽴したあとは、明⽰的に切断されるまで維持される ◦ HTTPのように毎回接続を確⽴するオーバーヘッドがない • GitHub Actionsのログをリアルタイムでみれたり 47
48. confidential • ハンドシェイク (HTTPアップグレードリクエスト) • WebSocket接続の確⽴ • データフレームの送受信 • WebSocketの切断 WebSocketの通信フロー 48
49. confidential ハンドシェイクはHTTP通信によって⾏われる 49
50. confidential 50
51. confidential なぜWebSocketを使うのか 51
52. confidential なぜWebSocketなのか • 低遅延性 ◦ 発話から応答までの遅延がユーザー体験に影響する ◦ 数百ミリ秒の遅延でも会話のテンポが損なわれ、不⾃然に感じられる • 効率的なデータ転送 ◦ HTTP通信はやり取り毎に100byte以上のリクエストヘッダーがつく ◦ WebSocketの場合は数byte程度 52
53. confidential WebSocketを使ったアプリ運⽤の難しさ 安全なデプロイの難しさ 53
54. confidential 安全なデプロイ(課題) • デプロイのたびに⼀部の通話がエラーとなっていた • Graceful shutdownは設定されていた • なぜ？？ 54
55. confidential わかっていたことと調査 • エラーログが出ているわけでもなく原因は不明 • 終了処理中のメトリクスを⾒れるようにしたりトレースを⼊れることで落ちてい る箇所を特定する⽅針にしたが原因は不明だった 55
56. confidential 横断的分析 56 Solution
57. confidential ALB -> ECS構成におけるデプロイで何が起きるのかの把握不⾜ • アプリケーションの問題ではなかった • StopTimeoutは120秒が最⼤値 • 1通話の最⼤時間がその時間を⼤きく超えて正常に終了できていなかった • drainの時間を伸ばすことで通話の最⼤時間内に強制終了しないようにする 57
58. confidential ALB -> ECS構成におけるデプロイで何が起きるのかの把握不⾜ https://aws.amazon.com/jp/blogs/news/graceful-shutdowns-with-ecs/ 58
59. confidential ALB -> ELB構成におけるデプロイで何が起きるのかの把握不⾜ https://aws.amazon.com/jp/blogs/news/graceful-shutdowns-with-ecs/ 59
60. confidential WebSocketでもHTTPでも、調査アプローチは同じ • アプリケーションの運⽤で気を付けることに違いはある • プロトコルを理解するために使っているライブラリを読んだりする必要はある • トレース‧メトリクスの導⼊、o11yの改善やデバッグのノウハウを貯めるな ど、信頼性を⾼めるためにやることは⼤きく変わらない 60
61. confidential ⾳声対話システムのSLI/SLO 61
62. confidential ⾳声対話システムの「信頼性」が低いと？ • 「すみません、よく聞こえませんでした」を繰り返される • 話しかけて数秒経って返事がくる • 全く関係ない内容の返答が返ってきたり • 機能的には良くても、ユーザーはフラストレーションを抱える 62
63. confidential 信頼性に向き合う必要がある • 漠然と「もっと良くしよう」と考えるのではなく、何を、どれくらい良くするの かを明確にする • 信頼性を客観的に評価し、改善していくためにSLI/SLO • SREのノウハウ ◦ CUJを⾒つけ信頼性の指標となるものを決める ◦ 「ページの表⽰速度がX秒以内」「エラーコード5xxの発⽣率がY%未満」 63
64. confidential ⾳声対話システムでSLI/SLOを扱う難しさ • ユーザー体験が定量化しづらい ◦ ユーザーの体験は「ちゃんと会話できたか」という主観的なもの ◦ HTTPレスポンスのように明確な成功/失敗が定義しづらい • 会話失敗の原因が複雑 ◦ インフラ、LLMの応答ミス、⾳声認識の精度低下 • Webと異なりセッションベースでの設計が必要 ◦ Webのように1リクエスト=1トランザクションではない 64
65. confidential ユーザーに届けたいものを再考する 65 Solution
66. confidential Webアプリケーション共通のノウハウ • ユーザーの「⽬的達成」を最上位のSLOとする • 最も重要なのは、ユーザーがシステムを通して⾃⾝の⽬的を達成できること • ユーザー体験に紐づくSLI/SLOを「解釈層ごと」に切り出すことで計測可能性を ⾼める • 「⽬的達成」を阻害する要因を考えていく ◦ ⼤きく分けて⼆つの種類がある 66
67. confidential システムエラー‧対話のエラー、両⾯から考える システム的 Anomaly 対話的Anomaly 67
68. confidential なぜ分類するのか • ユーザー体験の複合的理解 ◦ ユーザー体験がシステム要因と対話要因のどちらに、どれだけ影響されてい るか理解できる ◦ ユーザーからの「使いにくい」というフィードバックが、実はシステムの応 答が遅いからなのか、それとも会話がうまく成⽴しないからなのかを、デー タに基づいて判断できるようになる 68
69. confidential システム的Anomaly • いわゆるインフラ層の失敗を指している ◦ アプリケーションの計算量による遅延、DBの性能が上限 ◦ LLM/⾳声合成の応答遅延/失敗数 • ⼀⽅で、「LLMが返してきた内容が意味不明だった」などの対話品質は、こ の層だけでは捉えられない 69
70. confidential 対話的Anomaly • ユーザーの主観的な体験に直結する対話の失敗 • 「話が通じなかった」「変な返事をされた」「⽂脈が⾶んだ」など • システム的には「成功」と⾒えるが、UXとしては失敗 • この値をトラッキングすることによってユーザーの「⽬的達成率」を追える 70
71. confidential まとめ 71
72. confidential まとめ • システム特性を理解し、可観測性を⾼め、安定性を担保 ◦ ユーザーの⽬的達成を最優先にした信頼性向上 ◦ 不安定なLLMに依存しながらも、ユーザー体験を守る設計と運⽤ ◦ システム的 Anomaly∕対話的 Anomaly を切り分け、SLI/SLO を設計 • 新しい技術スタックでも、SRE の基本は変わらない 72
73. confidential ブースやってます！ 73
74. confidential 採⽤してます！ 74
75. confidential ご清聴ありがとうございました 75