対話型音声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

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