電話とAIとPlatform Engineering【シリーズD資金調達】

IVRy で Principal Engineer として働いている成田 ( @mirakui ) です。趣味は自家製の天然酵母からパンを作ることと、あと最近は焚き火にハマっています。

入社からの1年10ヶ月の変化

早いもので、2024年2月に入社してから、次の2月で丸2年が経とうとしています。スタートアップの時間感覚というのはめまぐるしいもので、毎週のように新機能をリリースしてプロダクトは高速に進化していき、中小企業向けに加えてエンタープライズ企業にも使っていただけるようになり、IVRy の組織も倍以上に成長しました。僕は IVRy では16人目のエンジニアですが、今では40名以上のエンジニア組織になっていて、これまででは難しかったような規模の開発にもチャレンジできるようになってきました。

そしてありがたいことに、先日シリーズDの資金調達をおこない、事業を次のステージに進める準備が整いつつあります。

Platform Engineering の立ち上げ

僕が入社した頃はまだ創業期と地続きで、いわゆる Stream-aligned なプロダクトのエンジニアがほとんどでした。IVRy でプロダクトを伸ばしていくためには、プロダクトを作り運用するのに必要な基盤技術を磨き込むことが重要と考えました。そこで僕は SRE やデータ基盤のチームを立ち上げて採用を進めつつ、自分自身もエンジニアとしてコミットしてきました。

次のステップとして、プロダクトの発展に必要な基盤をどんどん作っていく、開発要素の強い Platform Engineering チームの必要性を感じ、最近積極的にこの領域の採用を始めました。

良い Platform Engineering には高い技術力や、事業の将来を見据えた視座が必要です。特にいまの IVRy のような、まだ基盤がまったく整っていない環境では、何をするにしてもゼロから作ることになります。自らの洞察力をもって開拓していく必要があるため、思い切って Platform Engineer の採用基準は他のロールよりも高く設定しました。

herp.careers E12. プラットフォームエンジニア（リードクラス）

株式会社IVRy

募集要項をみる

技術サイドから見た電話 x AI ドメインの面白さ

IVRy は電話の音声対話 AI をプロダクトの主軸に置いています。電話と AI という、僕のように Web の技術でやってきたエンジニアからすると未経験の領域が広がっています。僕が最近関わっているプロジェクトからいくつか、面白いと思っているエピソードをピックアップします。

「電話」は落ちないと思われている

Web やメールで解決しないものは電話をするしかない、という体験をしたことがある方は多いと思いますが、そのくらい電話は昔から信頼されている通信手段です。

ですが IVRy の音声対話システムや通話アプリはプログラムである以上、何らかの問題によってクラッシュする可能性があります。「自動音声と話していたら突然電話を切られた」という体験は一番避けたいことです。

どのようにすれば、非常に可用性の要求が高い電話というインフラと、LLM というまだ安定性に課題のあるシステムを組み合わせられるでしょうか？

一方で、「電話が混んでいて繋がりにくい」は電話の体験としては自然なことです。途中で切断するくらいなら最初から繋がない方がいいのです。これが Web の世界では壊れていてもレスポンスを返した方がいいので、個人的にはこの特性の違いは面白いなと思っています。

通話の内容はまだほとんど活かされていない

日本では、すべての事業者が電話番号を持っています。事業の大小を問わず、電話で話された内容の中にはビジネスにとって重要な情報が含まれています。しかし電話で話された内容を蓄積したり、それを活かしたりといったことはまだほとんど行われていません。

IVRy は電話の自動応答からスタートした事業であり、電話対応業務の課題解決に取り組んできました。ですが、実はこの事業の肝はデータの蓄積にあります。電話を IVRy で受けるほどにデータが蓄積し、もっと便利に使えるようになる。そうすると、「電話応対の手間を減らす」という、人手不足解消やコスト削減効果という価値から、IVRy を入れることでデータが活用できるようになり、お客様の事業をもっと伸ばすことができるという価値に進化できるはずです。

IVRy Data Hub は通話データをビジネス価値に変える、いままでに無かったプロダクトです。僕もエンジニアとして開発に関わっています。

さて、ここに IVRy 創業以来のすべての通話内容が音声ファイルとして保存されています。これをそのまま自由に活用して新規事業を立ち上げて良いでしょうか。もちろんだめです。通話内容は通信の秘密として、電気通信事業法で保護されているためです。

どのようにしたら、セキュリティやプライバシーを保護しつつ、LLM を通してお客様に情報を届けられるでしょうか？
安心と便利を妥協無く両立させるのは、エンジニアとしての腕の見せ所です。

通話後処理 x AI の世界

通話データの活用は、データパイプラインや LLM Ops の観点でも技術的な興味が尽きません。膨大な量の通話の書き起こしテキストがあったとして、そこから何らかの情報を抽出するには、書き起こしを生データのまま扱うのではなく、不要データの除去やマスキング、要約、ラベリング、エンベディングなど様々な処理を通話一件ずつに対しておこなうことで精度を高めることができるでしょう。また、そのようなジョブネットワークが、大量の同時着信があっても破綻無く実行でき、各ジョブの状態を観測できるようなジョブ実行基盤も必要になってきます。パイプラインの速度は体験に大きく影響するので、将来的には通話中にストリーム処理していくようなアーキテクチャも考えられます。

白状すると、ここに書いてあるようなデータパイプラインの完成度にはまだ全然到達していません。エンジニアなら分かってもらえると思いますが、どれ一つをとっても難易度が高いものの組み合わせなので、採用から頑張っているというのが今です。

技術の積み上げには時間がかかる

エンジニア組織が40名を超えて、まあまあの開発規模になりましたが、だからこそ Platform Engineering が未成熟であることがプロダクト開発のネックになりつつあると感じています。基盤というのはちゃんとしたものを作るのには時間がかかるので、ほとんどのエンジニアが入社1-2年以内という今の状況ではまだ積み上げが全然足りていません。

前述のような、ドメイン固有の難しい領域ならまだしも、他の会社には当然あるような道具すらまだ揃えられていないものがいくつもあります。Platform Engineer としてこれは本当に悔しい。解き方が自明なものはさっさと最速で駆け抜けて、本当に難しくて事業にクリティカルな技術課題を倒しに行きたい。

システムの複雑化を力に変えていけるか

ところで、IVRy に入社したときにプロダクトやコードを見て思ったのは、めちゃくちゃシンプルだなということです。コード量も RDB のテーブル数も、多くのお客様に使っていただいているプロダクトとしてはかなり少ないと感じました。

シンプルであるということは開発に好影響があり、実際に驚異的なペースでリリースが進んできています。

ただ、どんなプロダクトでも開発が進むとシステムは必ず複雑になっていきます。今ではそろそろシステム全体を把握するのが難しい規模になってきました。

うまく準備された複雑性と、その場しのぎで複雑に作ってしまったものとでは大きく将来性が異なります。僕自身が Platform Engineering で成し遂げたいのは、システムが大きく複雑になっても、それが負担になるのではなく、事業の力として推進力に変えられるような設計をし続けるということです。複雑性の壁を何段階も突破した向こうに、世界で戦えるプロダクトになれるチャンスがあるからです。

おわりに

僕の入社エントリーには次のようなくだりがあります。

入社時から期待していたこのデータと事業のサイクルは、入社時点にはまだほとんどが構想にとどまっていましたが、今では現実のものになりつつあります。

そして通話データを活用する事業がついに動き出したことで、個人的には IVRy についに Platform Engineering の時代が来たなと感じています。基盤をよくすればするほどプロダクトが良くなり、事業を伸ばせるという構造があるからです。

われわれのような人間 (基盤にロマンを感じるタイプ) にとっては、基盤をいくらやりこんでもよいという最高のフェーズですので、腕に覚えのある方、力を持て余している方、最近コード書いてないけどそろそろエンジニアに戻りたい CTO / VPoE の方、ぜひ一緒に面白い技術課題を倒しましょう。

herp.careers E12. プラットフォームエンジニア（リードクラス）

株式会社IVRy

募集要項をみる