累計2500万着電を支える大規模 電話自動応答サービスのアーキテクチャ / Architecture of a Large-Scale Automated Phone Response Service Supporting 25 Million Cumulative Calls

1. confidencial 累計2500万着電を⽀える⼤規模 電話⾃動応答サービスのアーキテクチャ 2024/11/26 株式会社IVRy（アイブリー）
2. confidencial ⾃⼰紹介 ▪ 学⽣時代: 京都⼤学･⼤学院  ⾃然⾔語処理を学ぶ ▪ 2015年: 株式会社リクルートホールディングス  アプリ･Webのディレクター、データ分析等 ▪ 2019年: エクサウィザーズ  NLPエンジニア、チームリード、エンジニアリングマネージャー ▪ 2022年: IVRy  Point: 休⽇はボルダリングしかしていません 町⽥ 雄⼀郎 2 AIエンジニア / エンジニアリングマネージャー
3. confidencial オフィスに壁あります！ 3
4. confidencial 電話⾃動応答サービスIVRy 4 電話AI SaaS IVRy(アイブリー)は、 ⽉額3,000円からカスタム電話をカンタンに作成できるサービス。 全ての電話業務を誰でもすぐにAIを使って効率化できます
5. confidencial 電話は今でも最重要連絡⼿段 5
6. confidencial 電話を当たり前に取れない時代 6
7. confidencial 業態に合わせた⾃由な応答設定 7 ダイヤルプッシュとAIの対話をハイブリッドで設定し、 受けたい電話と⾃動化したい電話を分類。電話業務を効率化できる
8. confidencial 累計2500万着電に⾃動応答しています 8
9. confidencial 電話AI SaaSの難しさとは？ 9 confidencial
10. confidencial 本⽇のお話 「電話はつながって当たり前」であること 基本的に電話はつながるものでサービスレベルが⾮常に⾼い 累計2500万着電を処理し⽇本の電話業務の効率化を推進している IVRyのアーキテクチャについてお話します 10
11. confidencial 累計2500万着電を⽀える ⼤規模電話⾃動応答サービスのアーキテクチャ 電話業務を守る アーキテクチャ AI対話の アーキテクチャ 品質を保ちながらの 継続改善 1 2 3 confidencial 11
12. confidencial IVRyはエンドユーザー･クライアントの 間に⽴ちます 12 ※本⽇のスライド内ではお店に電話をかける⼈をエンドユーザー、 お店で電話を取る⼈をクライアントと呼んでいます
13. confidencial 電話⾃動応答のアーキテクチャ 13 IVRyは｢クライアント｣の代わりに電話をとり｢エンドユーザー｣に⾃動で応答するサービス システムは①エンドユーザー側と②クライアント側に分かれる エンドユーザー側 電話応答システム クライアント側 ルール設定システム
14. confidencial クライアント側 ルール設定システム 14 クライアントは設定画⾯を通じて⾃動応答ルールや会社情報を編集 また、⽂字起こしや要約がなされた着電履歴を確認できる
15. confidencial エンドユーザー側 電話応答システム 15 エンドユーザーからの着電にTwilioを通じて⾃動応答 プッシュや対話AIなど、クライアント側で設定されたルールに従って適切に返答
16. confidencial アーキテクチャで最も優先していること 「電話はつながって当たり前」を守ること 特にエンドユーザー側の⾃動応答が損なわれないような設計を 意識しています 16
17. confidencial 緊急時には⼤規模着電がある 17 引用:https://www2.nhk.or.jp/archives/movies/?id=D0009030854_00000  https://www3.nhk.or.jp/news/html/20210510/k10013021211000.html 2021年4⽉コロナワクチン接種時は⽇本中のクリニックの電話が鳴りました ⼤⼿通信会社が発着信制限をかけるほどの異常なトラフィック ワクチン予約電話で発着信制限 NTTと携帯大手 
 新型コロナウイルス　ワクチン接種始まる

18. confidencial 電話⾃動応答のシステム特性 18 エンドユーザー/クライアント側ともに DB負荷が⾼まる クライアント側のアクセスが増えることで通話履歴画⾯へのアクセスが増加。 ルール更新アクセスも増えるのでDBへの読み込み･書き込みが増加
19. confidencial DBを共有せず同期させる エンドユーザー側とクライアント側のDBを完全に分離させ同期させる コロナ当時はまだサービスの規模が⼩さくクライアント側のDB負荷は想定以上 クライアント設定画⾯の操作に遅延が発⽣してしまったが、⾃動応答には影響なし 19 分離･同期
20. confidencial エンドユーザー側は読み込み重視 アプリケーションはALB+ECS Fargateの構成｡⾃動応答ルールはDynamoDBを採⽤。 オートスケーリングで通話量急増に⾃動対応し､運⽤管理の⼿間を削減しつつ⾼可⽤性を担保。 ⾼負荷時でも⼀貫した低レイテンシーで通話品質への影響を最⼩限に抑制できる 20
21. confidencial クライアント側は整合性重視 アカウント関連の複数の情報を保存するため、データの整合性を重視してRDSを採⽤ 21
22. confidencial 分離･同期の構造: 設定画⾯ → ⾃動応答 RDS → DynamoDB(⾃動応答ルールなど)はアプリケーションでトランザクション処理 RDSとDynamoDBの状態が異なることを阻⽌ 22
23. confidencial 分離･同期の構造: ⾃動応答 → 設定画⾯ Dynamo → RDS(通話履歴など)はDynamoDB Streamsを利⽤し、変更を都度検知 23
24. confidencial その他: ⾮同期ジョブにできるものは切り分ける 24 着電通知･終話後の書き起こし･要約など、電話後に発⽣する処理がある ⾮同期にできるものはジョブに切り出し
25. confidencial その他: ログのローテート アプリケーションログは分析のためBigQueryへ格納 TROCCOの利⽤でスキーマ変更に柔軟かつ⾼頻度なログ連携が可能 25
26. confidencial 累計2500万着電を⽀える ⼤規模電話⾃動応答サービスのアーキテクチャ 電話業務を守る アーキテクチャ AI対話の アーキテクチャ 品質を保ちながらの 継続改善 1 2 3 confidencial 26
27. confidencial LLMを利⽤したAI対話 27
28. confidencial LLMを利⽤したAI対話 28 Websocketを利⽤しエンドユーザーとLLMがリアルタイムにやり取りしている
29. confidencial リアルタイムLLM対話システムの難しさ つながって当たり前 + 間違った情報を発話すると取り返しがつかない 29
30. confidencial LLMを利⽤したよくある対話システム 30 タスクの詳細や制約をすべて LLMへ指示することで とりあえずそれらしく動くのでは？ 予約したいです 承知しました。明⽇...
31. confidencial 31 LLMとハルシネーション 承知しました。明⽇お待ちしております ありがとうございます。貸し切りをご⽤意します ⾃然だがビジネス上問題のある返答 予約時間が分からずトラブルになる可能性 お店の都合を考えずに勝⼿に判断してしまう 対話⽤途では特にハルシネーション(真実ではない内容がなめらかに⽣成されてしまう)に注意 しかしLLMにすべて任せるとハルシネーションは避けられない 時間は決まってないんだけど、明⽇30名で予約とって
32. confidencial Compound AI System 32 すべてをLLMへの単⼀指⽰でやらせず、複数のAIコンポーネントに分離 情報に不⾜がないかの判定やレスポンス内容の バリデーション‧エラー分析がしやすくなり全体の結果が安定 予約したいです 承知しました。 何⽇のご予約をご希 望ですか？  モジュールごとに 精度‧出⼒管理 統合‧制御
33. confidencial LLMは「つながって当たり前」ではない 33 ある⽇のOpenAI Status 各社どんどんアップデートしているものの、実は結構落ちたりしてる。 特にリアルタイム性が求められる電話アプリケーションでは致命的
34. confidencial LLM戦国時代 34 ⽇を追う毎に各LLMの性能は向上中 難易度の低いタスクであればどれを選んでも精度に⼤きな差はない
35. confidencial LLM Fallback 35 複数のLLMを利⽤することを前提にFallback機構を構築 APIのStatus, Ratelimitやデータ制約(地理制約)をもとに振り分け
36. confidencial 複数LLMを切り替えるときの注意点 36 評価データを作り定期的にテスト LLMによって出⼒結果に違いがないか？ ある⽇を境に急にできなくなることも 単純なタスクに思えても各LLMで出⼒が安定しないことがある 評価データに対して⼗分な精度が出ているかは要確認 モデルが勝⼿にアップデートされて急に出⼒が変わることもあり､定期モニタリングが必要 ⼤⼈2名こども2名でお願いします 4名様ですね 2名様ですね
37. confidencial DataDog LLM Observabilityで監視 37 レイテンシーやtoken数などのリアルタイム監視を強化 通常のリソース同様にチェックをすることで異常にすぐ気づける体制
38. confidencial リアルタイムでも安定してLLMを使うために 38 LLMはまだ「つながって当たり前」ではない！ アプリケーション‧インフラの両⾯で安⼼して使えるアーキテクチャを考える必要あり Compound AI Systemの利⽤ Fallbackの構築 監視の充実
39. confidencial 累計2500万着電を⽀える ⼤規模電話⾃動応答サービスのアーキテクチャ 電話業務を守る アーキテクチャ AI対話の アーキテクチャ 品質を保ちながらの 継続改善 1 2 3 confidencial 39
40. confidencial つながって当たり前≠守りの運⽤ 40 「つながって当たり前」のためにリリースを絞っているわけではない むしろリリース頻度を増やし、多いときで週12回もリリースしている
41. confidencial ⾃動架電テスト 41 "scenarios": [ { "title": "Test Case 1", "push_actions": [ { "send_digit": "2" } ], "speech_actions": [ { "say": "アイブリーの町⽥です。" }, { "say": "⽥中さん" }, { "say": "ゼロ、ハチ、ゼロ、イチ、ニ、サンです" }, { "say": "通話のテストをしています" } ], "expect": [ { "action": "notification", "notification_text": "以下の内容で\... }, { "action": "complete" } ] }, テスト対話シナリオ XXXです 080... お名前は？ 電話番号は？ 実際に電話をかけてのQAが⼀番⼤事 だが時間がかかる ⾃動応答テスト⽤の⾃動応答システム を作り、⾃動で架電してのテストを 毎回実施  confidencial
42. confidencial まとめ 「電話はつながってあたりまえ」 電話の最も⼤事なところを守りながら 最先端のAIを組み込み、⾼速改善を繰り返す IVRyのアーキテクチャを紹介しました 42
43. confidencial