ボイスボットでOpenAI Realtime APIを使うべきか？

OpenAIがRealtime APIを発表

OpenAIが発表したRealtime APIは、ChatGPTのAdvanced Voice Modeを自社プロダクトに組み込めるAPIで、以下のような特徴があります:

• 低遅延

• 自然な音声対話をサポート（ChatGPTのAdvanced Voice Modeと同様）

• 音声入力と出力を単一のAPI呼び出しで処理

• 会話の途中での割り込みにも対応

• 関数呼び出し機能をサポートし、音声アシスタントが具体的なアクションを実行可能

なんといっても強みは、複数のAIモデル（音声認識、LLM、音声合成）を組み合わせる必要がなく、単一のAPIコールで自然な会話体験を実現できる点です。これにより、よりスムーズな対話が可能になりました。

今までのボイスボットについて

今までのボイスボットの処理は以下のようなフローになっていました。

このように複数のAIモデルを経由することで回答するまでの待ち時間が発生してしまい、直列な実行だと最悪10秒程度の待ち時間が発生します。

ユーザは話し終わってから1秒以上の沈黙があるとストレスを感じ、顧客体験が悪化すると言われています。

そこで実装面で、以下のようなポイントで高速化の工夫を行っていました。

• Speech To Textのリアルタイム化

• LLMのキャッシュ化

• Text to Speechの高速化

• 対話システムの最適化

しかしとはいえ待ち時間は1-2秒程度は発生してしまうことが一般的です。

Realtime APIのメリット

1. 高速なレスポンス

Realtime APIの裏側で動いてるAIモデルは「音声を受け入れて、そのまま音声を出力する」いわゆるSpeech to Speechのモデルであるため、複数のAIモデルを経由することなく出力を生成できるため、とても高速にレスポンスを返すことができます。

OpenAIは300msでの応答が可能であると謳っており、今までのボイスボットと比べると圧倒的に高速化された形になります。

2. 実装が比較的に容易

複数のAIモデルを組み合わせないで良いぶん、実装面は比較的にシンプルになります。

今までの工夫をしたボイスボットの場合、それぞれのAIモデルを複数のプロセスやスレッドで並行的に起動し、複雑にやりとりをしながら実装をする必要がありました。

それに対して、Realtime APIを使う場合は(※RAGなどを考慮しなければ)、1つのプロセスで音声を受け付けて音声を返すシンプルな実装が可能です。

具体的にはRealtime APIに対してwebsocketでEventを送出しておくと、サーバからリアルタイムで音声やFunction Callingのレスポンスが返ってくるため、それらを処理するような実装になります。

websocketによる実装となるので、従来に比べるとシンプルになるものの依然として開発難易度が高いことは変わりません。

3. ボイスボットの進化の流れとして正当

今までのボイスボットの大きな課題の一つに、「一問一答感がある」というものがありました。要するに、質問をして、回答をしてもらうだけのもので、どうも「対話をしている感覚」がないというものです。

本当はAIにガイドしてもらって、いろいろ自分の中に眠っているものを掘り出してもらうような主体的な行動を期待しているのに、できることが一問一答だと期待値に合わないというものです。

これは、システムの構造としてREST APIであることが問題でした。要するに、「リクエストを投げるとレスポンスが帰ってくる」というシステム的な構造からどれだけAIが進化してもどうしても一問一答の構造は変わらないのです。

今回のRealtime APIではアーキテクチャとして、websocketを採用し、双方向的なコミュニケーションが可能となりました。ユーザ側はAPIに対して音声等のイベントをサーバに送り、サーバもユーザ側に音声やその他の情報を生成したタイミングで送り返します。このようなイベントベースのAPIでは、例えば「ユーザがずっと無言だったらAI側から話しかける」のような機能も追加可能です。こちらからリクエストを投げなくてもAIから投げかけるようなことが可能です。

現状では、Realtime API自体には「ユーザがずっと無言だったらAI側から話しかける」のような機能はないので、自社サーバ側で実装が必要ですが、ボイスボットの進化の流れとしてはこのイベントベースのwebsocket APIから変わることはないと思われます。

Realtime APIのデメリット

では、今までのボイスボットの実装に比べてデメリットも紹介していきます。

1. 価格が高い

弊社で開発中のボイスボット系プロダクトの試算ですと、今までのボイスボットが1分会話すると4.67円になるのに対して、Realtime APIでの実装では87円程度になりました(システムプロンプトの長さやラリー数によって計測)。

ひとえに、Realtime APIが現状コストが高いことが原因になります。Textの生成に比べて10-20倍程度のコスト差になっています。

スピーディに会話ができてしまうが故にトークン数を消費しやすいことと、音声認識や合成音声部分にはコストがかからないもの、それらのコストは生成AIに比べるとわずかであるため、全体としては20倍程度のコスト差になってくる形になります。

将来的にコストが下がってくることが予想されるものの、現状ではなかなか大規模には活用しづらい価格感になっています。

2. 声のカスタマイズ性は低い

Realtime APIを使う場合は、声はプリセットの音声から選ぶ形になります。

今までのボイスボットであれば合成音声部分は他のAIを活用できるため、事前に学習した声を利用することができ、カスタマイズ性が非常に高いですが、Realtime APIではそれができません。

技術的にはOpenAIがボイスクローニング技術を持っているとリリースしておりますが、犯罪利用を防ぐため一般には公開されておりません。

こちらも将来的には技術が公開される可能はあります。

3. RAGにすると遅くなる？

MicrosoftがVoiceRAGという形で、Realtime APIを使ったRAGのボイスボットのアーキテクチャを提案しています。

方法としては、OpenAI Realtime APIで検索のためのFunction Callingを生成し、それを元に検索を行い、検索結果から回答をするというものになります。

しかし、この方法の場合、ユーザの発話を全て聞いてからFunction Callingを生成し、検索結果を待って回答を生成する流れとなるため回答が遅い可能性があります。

日本ビジネスシステムズ社にて日本語でデモをしたケースが動画で挙げられていましたが、実際に回答までに数秒のラグが生じております。

%3Ciframe%20width%3D%221280%22%20height%3D%22720%22%20src%3D%22https%3A%2F%2Fwww.youtube.com%2Fembed%2FSvXl1A7Kz-A%22%20frameborder%3D%220%22%20allow%3D%22accelerometer%3B%20autoplay%3B%20encrypted-media%3B%20gyroscope%3B%20picture-in-picture%22%20allowfullscreen%3E%3C%2Fiframe%3E

今までのボイスボットであれば、ユーザの発話中に文字化をしてそれを元に検索をかけることができるため、ユーザの発話が終了する前に検索を完了することができます。Realtime APIだけを使う場合はそのようなカスタマイズが少し困難という課題があります。

まとめ

項目	従来のボイスボット	Realtime API
処理フロー	複数のAIモデルをくみ合わせる Speech To Text → LLM → Text to Speech	Speech to Speech (単一モデル)
応答時間	最悪10秒程度 工夫をすると1-2秒	300ms
実装の複雑さ	複雑	比較的シンプル
アーキテクチャ	REST API (一問一答)	WebSocket (双方向コミュニケーション)
コスト (1分の会話)	約4.67円	約87円
声のカスタマイズ	高い（他のAIを活用可能）	低い（プリセットのみ）
RAGへの対応	ユーザーの発話中に検索可能	検索に時間がかかり、応答が遅くなる可能性あり

現状のプロダクトに落とす観点ではまだ従来のボイスボットに優位性がありそうですが、ボイスボットの未来としてはRealtime APIのようなSpeech to Speechモデルが採用されることが増えていくと思われます。

LangCore Voicebotでは従来型ボイスボットとRealtime APIを同一のインターフェイスで実装しており、設定で切り替えが可能になっています。またtwilioを使ったIP電話連携も可能で、ボイスボットのPoCや開発をすぐに実現できます。

実際にデモを見たい方や、ボイスボットについての開発のご相談について「1時間の無料相談」を承っております！まずはお気軽にお問い合わせください。→こちらで無料相談を予約する