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

by 株式会社IVRy（社員登壇資料）

Slide 1

Slide 1 text

conﬁdential ~ Webアプリケーション以外でどうSREを実践するのか ~ 対話型⾳声AIアプリケーションの信頼性向上の取り組み 2025/07/11 1

Slide 2

Slide 2 text

conﬁdential LLMを組み込むと、最⾼のプロダクトが作れる！ 2

Slide 3

Slide 3 text

conﬁdential LLMを組み込むと、最⾼のプロダクトが作れる！ 3

Slide 4

Slide 4 text

conﬁdential LLM APIを利⽤した対話アプリケーション運⽤の取り組み 4

Slide 5

Slide 5 text

conﬁdential 5 LLM APIのプロダクトへの組み込み LLM APIの監視・運用 Hiroyuki Moriya AI engineer / SRE ⾃⼰紹介

Slide 6

Slide 6 text

conﬁdential 6 SRE NEXT 2025 Co-Chair 好きなWebSocketのCloseEventコード: 1005 Ryuichi Watanabe SRE ⾃⼰紹介

Slide 7

Slide 7 text

7 1. IVRyについて 2. LLM API 3. WebSocket 4. まとめアジェンダ

Slide 8

Slide 8 text

conﬁdential IVRyについて 8

Slide 9

Slide 9 text

conﬁdential 会社紹介 9 会社名代表取締役事業内容住所資本⾦等設⽴年⽉株式会社IVRy（アイブリー）奥⻄亮賀（Ryoga Okunishi）クラウド型AI電話SaaS（アイブリー）の運営〒108-0073東京都港区三⽥三丁⽬5-19 住友不動産東京三⽥ガーデンタワー10F 46.1億円（準備⾦含む） 2019年3⽉

Slide 10

Slide 10 text

10 電話⾃動応答サービスプロダクト

Slide 11

Slide 11 text

conﬁdential 11 システムアーキテクチャ

Slide 12

Slide 12 text

conﬁdential 12 システムアーキテクチャ

Slide 13

Slide 13 text

conﬁdential 13 システムアーキテクチャ

Slide 14

Slide 14 text

conﬁdential IVRyの技術スタック 14

Slide 15

Slide 15 text

conﬁdential 電話は今でも最重要連絡⼿段 15

Slide 16

Slide 16 text

conﬁdential 16 あらゆる業種‧企業規模のお客様に導⼊

Slide 17

Slide 17 text

conﬁdential 対話型AIアプリケーションの難しさ LLM APIのプロダクト運用 Challenge #1 WebSocketのプロダクト運用 Challenge #2 17

Slide 18

Slide 18 text

conﬁdential LLM API part 18

Slide 19

Slide 19 text

conﬁdential ハルシネーションの抑制 Challenge #1 LLM APIの安定運用 Challenge #2 LLM APIを本番運⽤する難しさ 19

Slide 20

Slide 20 text

conﬁdential ハルシネーションの抑制 20

Slide 21

Slide 21 text

21 LLMはハルシネーションする Problem

Slide 22

Slide 22 text

conﬁdential 困難は分割せよ 22 Solution

Slide 23

Slide 23 text

conﬁdential AI workﬂowによる実装 23 1つのタスクを複数のLLM componentで分割して処理する → validation‧error分析が⾏えるようになり、安定した結果を出⼒できる

Slide 24

Slide 24 text

conﬁdential 確認を怠らない 24 Solution

Slide 25

Slide 25 text

conﬁdential ⾃動電話 e2e test 25

Slide 26

Slide 26 text

conﬁdential 26

Slide 27

Slide 27 text

conﬁdential 27

Slide 28

Slide 28 text

conﬁdential 28

Slide 29

Slide 29 text

conﬁdential 29 Merge code Deploy latest code Execute automated phone E2E tests Monitor on Datadog LLM Observability 電話 e2e testをコードマージ時に実⾏させる

Slide 30

Slide 30 text

conﬁdential 30 Datadog LLM Observability による監視

Slide 31

Slide 31 text

LLM APIの安定運⽤ 31

Slide 32

Slide 32 text

システム障害は多くの影響を引き起こす 32 Problem

Slide 33

Slide 33 text

conﬁdential LLM APIは不安定である 33 LLM API Status in one day

Slide 34

Slide 34 text

conﬁdential 完璧を求めない 34 Solution

Slide 35

Slide 35 text

conﬁdential 35 Fast, stable, and cheap Slower, more $$$ Stability & performance > latest models 自分たちのユースケースに合ったモデル選定をする。

Slide 36

Slide 36 text

conﬁdential システム監視を怠らない 36 Solution

Slide 37

Slide 37 text

conﬁdential 37 Datadog Inferred Servicesによる外部通信の監視

Slide 38

Slide 38 text

conﬁdential 38 Inferred serviceを通して、多くのmetricsを監視できる

Slide 39

Slide 39 text

conﬁdential 最悪の事態に備える 39 Solution

Slide 40

Slide 40 text

conﬁdential 40 複数のLLM APIを利用して、 fallbackシステムを実装する LLM fallback strategy

Slide 41

Slide 41 text

conﬁdential 困難は分割せよ / 確認を怠らない 01 ハルシネーションの抑制完璧を求めない / システム監視を怠らない 02 会話を自然な速度にするために最悪の事態に備える 03 障害への対策まとめ： LLMをプロダクト運⽤するために 41

Slide 42

Slide 42 text

conﬁdential WebSocketプロダクト運⽤ 42

Slide 43

Slide 43 text

conﬁdential なぜ突然WebSocket？ 43

Slide 44

Slide 44 text

conﬁdential 44 Simpliﬁed system architecture

Slide 45

Slide 45 text

conﬁdential 45 Simpliﬁed system architecture

Slide 46

Slide 46 text

conﬁdential WebSocketの特徴 46

Slide 47

Slide 47 text

conﬁdential WebSocketの特徴 ● RFC6445 で定義されている ● 双⽅向通信‧全⼆重通信 ○ クライアントとサーバーの両⽅が同時にデータを送受信可能 ○ HTTPとは異なり、リクエスト‧レスポンスの概念がない ● 接続を⼀度確⽴したあとは、明⽰的に切断されるまで維持される ○ HTTPのように毎回接続を確⽴するオーバーヘッドがない ● GitHub Actionsのログをリアルタイムでみれたり 47

Slide 48

Slide 48 text

conﬁdential ● ハンドシェイク (HTTPアップグレードリクエスト) ● WebSocket接続の確⽴ ● データフレームの送受信 ● WebSocketの切断 WebSocketの通信フロー 48

Slide 49

Slide 49 text

conﬁdential ハンドシェイクはHTTP通信によって⾏われる 49

Slide 50

Slide 50 text

conﬁdential 50

Slide 51

Slide 51 text

conﬁdential なぜWebSocketを使うのか 51

Slide 52

Slide 52 text

conﬁdential なぜWebSocketなのか ● 低遅延性 ○ 発話から応答までの遅延がユーザー体験に影響する ○ 数百ミリ秒の遅延でも会話のテンポが損なわれ、不⾃然に感じられる ● 効率的なデータ転送 ○ HTTP通信はやり取り毎に100byte以上のリクエストヘッダーがつく ○ WebSocketの場合は数byte程度 52

Slide 53

Slide 53 text

conﬁdential WebSocketを使ったアプリ運⽤の難しさ安全なデプロイの難しさ 53

Slide 54

Slide 54 text

conﬁdential 安全なデプロイ(課題) ● デプロイのたびに⼀部の通話がエラーとなっていた ● Graceful shutdownは設定されていた ● なぜ？？ 54

Slide 55

Slide 55 text

conﬁdential わかっていたことと調査 ● エラーログが出ているわけでもなく原因は不明 ● 終了処理中のメトリクスを⾒れるようにしたりトレースを⼊れることで落ちている箇所を特定する⽅針にしたが原因は不明だった 55

Slide 56

Slide 56 text

conﬁdential 横断的分析 56 Solution

Slide 57

Slide 57 text

conﬁdential ALB -> ECS構成におけるデプロイで何が起きるのかの把握不⾜ ● アプリケーションの問題ではなかった ● StopTimeoutは120秒が最⼤値 ● 1通話の最⼤時間がその時間を⼤きく超えて正常に終了できていなかった ● drainの時間を伸ばすことで通話の最⼤時間内に強制終了しないようにする 57

Slide 58

Slide 58 text

conﬁdential ALB -> ECS構成におけるデプロイで何が起きるのかの把握不⾜ https://aws.amazon.com/jp/blogs/news/graceful-shutdowns-with-ecs/ 58

Slide 59

Slide 59 text

conﬁdential ALB -> ELB構成におけるデプロイで何が起きるのかの把握不⾜ https://aws.amazon.com/jp/blogs/news/graceful-shutdowns-with-ecs/ 59

Slide 60

Slide 60 text

conﬁdential WebSocketでもHTTPでも、調査アプローチは同じ ● アプリケーションの運⽤で気を付けることに違いはある ● プロトコルを理解するために使っているライブラリを読んだりする必要はある ● トレース‧メトリクスの導⼊、o11yの改善やデバッグのノウハウを貯めるなど、信頼性を⾼めるためにやることは⼤きく変わらない 60

Slide 61

Slide 61 text

conﬁdential ⾳声対話システムのSLI/SLO 61

Slide 62

Slide 62 text

conﬁdential ⾳声対話システムの「信頼性」が低いと？ ● 「すみません、よく聞こえませんでした」を繰り返される ● 話しかけて数秒経って返事がくる ● 全く関係ない内容の返答が返ってきたり ● 機能的には良くても、ユーザーはフラストレーションを抱える 62

Slide 63

Slide 63 text

conﬁdential 信頼性に向き合う必要がある ● 漠然と「もっと良くしよう」と考えるのではなく、何を、どれくらい良くするのかを明確にする ● 信頼性を客観的に評価し、改善していくためにSLI/SLO ● SREのノウハウ ○ CUJを⾒つけ信頼性の指標となるものを決める ○ 「ページの表⽰速度がX秒以内」「エラーコード5xxの発⽣率がY%未満」 63

Slide 64

Slide 64 text

conﬁdential ⾳声対話システムでSLI/SLOを扱う難しさ ● ユーザー体験が定量化しづらい ○ ユーザーの体験は「ちゃんと会話できたか」という主観的なもの ○ HTTPレスポンスのように明確な成功/失敗が定義しづらい ● 会話失敗の原因が複雑 ○ インフラ、LLMの応答ミス、⾳声認識の精度低下 ● Webと異なりセッションベースでの設計が必要 ○ Webのように1リクエスト=1トランザクションではない 64

Slide 65

Slide 65 text

conﬁdential ユーザーに届けたいものを再考する 65 Solution

Slide 66

Slide 66 text

conﬁdential Webアプリケーション共通のノウハウ ● ユーザーの「⽬的達成」を最上位のSLOとする ● 最も重要なのは、ユーザーがシステムを通して⾃⾝の⽬的を達成できること ● ユーザー体験に紐づくSLI/SLOを「解釈層ごと」に切り出すことで計測可能性を⾼める ● 「⽬的達成」を阻害する要因を考えていく ○ ⼤きく分けて⼆つの種類がある 66

Slide 67

Slide 67 text

conﬁdential システムエラー‧対話のエラー、両⾯から考えるシステム的 Anomaly 対話的Anomaly 67

Slide 68

Slide 68 text

conﬁdential なぜ分類するのか ● ユーザー体験の複合的理解 ○ ユーザー体験がシステム要因と対話要因のどちらに、どれだけ影響されているか理解できる ○ ユーザーからの「使いにくい」というフィードバックが、実はシステムの応答が遅いからなのか、それとも会話がうまく成⽴しないからなのかを、データに基づいて判断できるようになる 68

Slide 69

Slide 69 text

conﬁdential システム的Anomaly ● いわゆるインフラ層の失敗を指している ○ アプリケーションの計算量による遅延、DBの性能が上限 ○ LLM/⾳声合成の応答遅延/失敗数 ● ⼀⽅で、「LLMが返してきた内容が意味不明だった」などの対話品質は、この層だけでは捉えられない 69

Slide 70

Slide 70 text

conﬁdential 対話的Anomaly ● ユーザーの主観的な体験に直結する対話の失敗 ● 「話が通じなかった」「変な返事をされた」「⽂脈が⾶んだ」など ● システム的には「成功」と⾒えるが、UXとしては失敗 ● この値をトラッキングすることによってユーザーの「⽬的達成率」を追える 70

Slide 71

Slide 71 text

conﬁdential まとめ 71

Slide 72

Slide 72 text

conﬁdential まとめ ● システム特性を理解し、可観測性を⾼め、安定性を担保 ○ ユーザーの⽬的達成を最優先にした信頼性向上 ○ 不安定なLLMに依存しながらも、ユーザー体験を守る設計と運⽤ ○ システム的 Anomaly∕対話的 Anomaly を切り分け、SLI/SLO を設計 ● 新しい技術スタックでも、SRE の基本は変わらない 72