IVRyのインフラアーキテクチャ図
riddle_tec
IVRyのメイン機能はAWS上で構築されており、音声通話部分、設定画面用API、バッチ処理に分かれています。極力マネージドサービスを利用し運用コストを削減しています。
フロントはCloudFrontを利用し、コンテナプラットフォームはECS Fargate、APIのアプリケーションはRuby on Railsで実装、データベースはAurora PostgreSQLを使用した構成です。
通話の量は社会的なイベントによってスパイクすることもあります。そのため、音声通話部分は設定系のAPIとは切り離し、可用性・拡張性の観点からDynamoDBを利用し、設定内容の参照や通話ログの保存を行っています。また、Blue/Greenデプロイによる切り替えを行い、ダウンタイムと機能のロールバックに関するリスクを軽減しています。音声通話の処理内でChatGPT(Azure OpenAI Service)へのリクエストを行うこともあります。
料金計算や、通話後の書き起こしなどは非同期ジョブで処理しています。
インフラ構成はIaC(Terraform)で管理し、CI/CDは主にGitHub Actionsを利用しています。
現在のアーキテクチャの課題と今後の改善予定
通話部分のUXをより向上させるべくobservabilityの向上、ボトルネックの発見/解消に取り組んでいきたいです。関連ログ/イベントなどを集約、モニタリングし、より信頼性の高いサービスを提供していきたいと考えています。また、チームの開発リソースを、価値を生み出し素早く届けるという本質に集中できる状態を維持、向上し続けたいです。
riddle_tec基礎知識
私たちは、IVR（電話自動応答）を起点として、AI対話システムを開発・運営しています。
へ〜電話のところは Twilio なのか。（経験がある）
なるほど、電話番号の発行からその応対時にどのようなフローで返信させるか？LLMをつかったナレッジベースの回答もできたりするのね。通話周りはTwilio によせていて IVR を提供してるってことなのかな。
気になったとこ
1. ここの矢印きになる (Twilio とどう通信してる？）
エンドユーザ(ユーザ A)からクライアント(お店 X)に対する電話問い合わせの電話を Twilio 経由で IVRy が受け取ります。
ユーザ A が電話で伝える「予約したい」といった音声を基に、どんな問い合わせなのかを解釈します。ここでは LLM や機械学習モデルを組み合わせた AI 対話システムを利用します。
解釈した「予約」という問い合わせ内容に対して、お店 X ではどんな対応をするべきかをクライアントナレッジ DB から取り出します。
「SMS でネット予約ができる URL を送付する」「お店の電話を実際に鳴らしてスタッフが対応する」「連携している予約台帳の API を呼び出し予約を行う」など、お店 X のユースケースに沿った自動応答をします。
通話履歴は IVRy の設定画面から閲覧ができます。録音された通話音声を聞いたり、文字起こしや要約を表示することもできます。
あー。なるほど。電話自体は IVRy でやりとりしてるのか。はーーん。
2. この辺何してるかわからない
自動化ルールの設定画面と電話システムが完全に分離されている。どちらかが落ちても、もう一方が動くようになっているんです。これがめちゃくちゃ賢い。設定画面はRDBで作られていて、設定が完了するとDynamoDBに転記される。電話のトラフィックが大量に発生するため、通話中にRDBへアクセスしない仕組みになっている。可用性の要件が全然違うからこそ、わざわざDBを分けているんですよね。
3. なにこれ
Sentry だ。
riddle_tecIVRy 給料高いな。法人電話ってもうかるのか
でもSREのリードよりバックエンドのリードの方が高いのは意外だな。
LLM周りの面倒見るから高いのかな。
riddle_tec2023年の話（Google Assistantの自然言語理解チーム（の中の一チーム）でテックリードをやってた方のジョイン）
実際、LLMでゼロからサービスを作って上手くいっているものは世界を見てもほとんど無いと思っていて、既存サービスに載せる方が「手堅い」かと思います。
その意味で「既に広く使われているサービスを既に持っている」というのは魅力的でした。
https://note.com/csstudyabroad/n/nfd25eaa0c5ab
riddle_tec- そもそもベースの事業が日本のどこの会社でも必要とされる電話対応の自動化であり、それを安く解決できるサービスということで売上が立ちやすい
- 業界問わないし、サービスセンター以外は既存で入ってないだろうからパイがおおきい
- かつての Freee に似てる感じ
- 結果、高単価でエンジニアが採用できる
- LLMとの相性がとても良い（これを最初から狙っていたかは変わらない
- 結果LLMを組み込んだサービス作りたい強い人が集まる
- 情報発信力がとても強い、外部発信を主導？もしくは組織的にサポートしている？
riddle_tecてかCTOいないじゃん（VPoE はいるけど2025から）
え、どうやって集めたんだろう。
初期のエンジニア二人かな？（代表も書いていたみたい）
週５フル開発は私だけでしたが、フロントエンドとバックエンドと電話サーバーの開発を合計4人のエンジニアで開発していました。当時は代表の奥西も微修正である場合は自らコードを書いていました。2022年ごろからコードは一切書いてません。(これも成長の証)
うーん、読み解けないなあ。
riddle_tec
採用チャネルはほぼほぼリファラル
一般的に採用力がない点と「背中を預ける」という観点から、CEO奥西の起業前の同僚や大学時代の知り合いからの採用がメインになっています
これか。繋がりがすごかったんだろうな。リクルートか。
riddle_tec多職種の人がいろんなことをいろんな媒体で発信してるのすごい強いな。