リアルタイム音声は、AI 搭載アプリケーションとの根本的に異なる対話手段を提供します。ユーザーは文字入力やメニュー操作の代わりに自然に話し、リアルタイムの間合いと感情的な文脈を伴う応答を受け取れます。
優れたリアルタイム音声体験を構築する鍵は、ライブ対話の調整です。ここから本当のプロダクト開発が始まります。リアルタイム体験は即時的で生き生きとしています。それを持続できるアプリケーションの構築には、独自のエンジニアリング課題があります。
モデルはシステムの一部にすぎません。本番アプリケーションには、音声ネイティブなインフラ、会話の流れと高度な推論の明確な分離、進行中のセッションを管理するイベント駆動型制御が必要です。
残る難しさの多くは、ガードレールと評価にあります。安全性チェックはライブ音声に追従する必要があります。また、タイミング、口調、会話の流れといった一時的な会話特性は、従来の評価手法では評価が困難です。
現在の音声対応 AI アプリケーションの多くは、今も同じ仕組みです。音声を入力してテキストに変換し、モデルが考え、合成音声が回答を読み上げます。この仕組みでも機能します。しかし、その対話は会話ではなく、まさにパイプラインのように感じられます。
リアルタイム音声は、それを変えます。ユーザーは自然に話し、間合い、口調、感情的な文脈を伴う応答を受け取れます。音声認識などを連結したパイプラインよりも高速で滑らかであり、システムを操作するというより、人と話す感覚に近づきます。
これにより、パイプライン型アーキテクチャでは対応が難しいプロダクト接点が生まれることを、私たちは確認してきました。リアルタイム音声エージェントなら、長く制約の多い IVR メニューや部門間転送が必要だった顧客対応を処理できます。コーチング、オンボーディング、さまざまなメディアでのアクセシビリティ支援などにも活用できます。音声会話がテキストベースのインターフェースより有利な場面なら、リアルタイム音声を構築する価値があります。
音声対応アプリケーションの多くは、「連結型アプローチ」と呼ばれる方式を採用しています。音声認識、言語処理、音声合成をそれぞれ別のモデルで行うパイプラインです。こうしたシステムは十分に機能し、幅広い可能性をもたらしますが、音声が存在するのは処理の両端だけです。分離された各工程によって固定的な構造と遅延が生まれ、実際の会話より不自然な対話になります。
リアルタイム音声は異なるアプローチを採ります。聞く、考える、話すために別々のモデルを使うのではなく、単一のモデルが 3 つすべてをネイティブに処理し、音声と文字起こしを同時に理解・生成します。入出力が連続して行われるため、ライブ会話らしい自然なリズムを保ちながら、自然なタイミングと感情を込めた応答が可能になります。その結果、タイミング、口調、割り込み処理がプロダクトの中核になります。
リアルタイム体験は即時性があるからこそ魅力的ですが、互いの順番を待たないからこそ実現が困難です。これを支えるには、高速かつ正確な音声生成だけでは足りません。難しいのは、それ以外のすべてです。モデルはライブセッション内で動作します。その周囲にある状態、安全性、オーケストレーション、制御も、会話と並行して同じ速度で動作しなければなりません。
連結型音声アプリケーションでは、ターン制の会話によって明確なやり取りの構造が生まれます。ユーザーが話し、システムが応答して、次の工程が始まります。リアルタイム音声には、その構造がありません。双方が同時に話すこともあれば、どちらも話さず沈黙が続くこともあります。ユーザーが応答の途中で割り込んだり、システムが話し終わる前に追加質問をしたりすることもあります。割り込みは例外事象ではなく、主要な対話パターンになります。
このパターンがあるからこそ、リアルタイムアプリケーションは本質的に調整の問題となり、モデルを取り巻くシステムがモデル自体と同じくらい重要になります。
この種のシステムを大規模に運用するには、ライブ対話に特化した設計が必要です。本番稼働するシステムに共通して見られる要素は、次の 3 つです。
リアルタイム音声セッションでは、音声ストリーミング、発話交替、割り込み、接続ライフサイクル、エージェント実行を処理する必要があります。アプリケーションの導入先によっては、電話機能への対応も必要です。これらは体験の土台であり、アプリケーションを拡張するうえでも中心的な要素です。
第一の要件は、音声ネイティブなセッション層です。リアルタイム通信（RTC）フレームワークは、参加者の管理、音声のストリーミング、電話環境でのエージェント実行を担う基盤をアプリケーションに提供します。私たちの経験では、特に Livekit が役立ちました。低遅延の WebRTC スタックに、高品質なノイズキャンセリングとジッター低減機能が標準搭載されています。複雑さが増すことを考えると、この層を自作する価値はほとんどありません。
リアルタイム音声のマルチエージェントアーキテクチャは、本質的に関心事を分離するためのものです。
リアルタイム音声モデルは会話音声のストリーミングに非常に優れていますが、高度な推論向けには最適化されていません。ツール呼び出し、情報検索、構造化された意思決定などのタスクは、別のモデルに実行させるほうが効果的です。
有効なパターンの一つが、応答役・思考役アーキテクチャです。
応答役は、リアルタイム音声エージェントです。聞く、話す、割り込みに対処する、会話の流れを保つといった、ライブ対話の維持を担います。その設計では、応答性、明瞭さ、感情の一貫性を優先します。
思考役は、推論能力を備えたモデルで動く別のエージェントです。会話経路の外で動作し、ツールの使用、情報検索、計画などのタスクを処理します。応答役は必要に応じて思考役を呼び出し、その結果を会話に反映できます。
思考役が推論を直接処理する場合もあります。また、専門化した複数のエージェントを統括するオーケストレーターとして機能する場合もあります。重要なのは、推論タスクにより適したモデルがこの作業を担うことです。
利点は明快です。応答役は高速で会話に集中した状態を保ち、より多くの時間、文脈、構造を要する作業は思考役が処理します。
将来のフロンティアモデルの進歩によって、このアプローチは不要になるかもしれません。しかし現時点では、このパターンが単一エージェント方式を一貫して上回ることを確認しています。
リアルタイム音声システムでは、イベントの連続的なストリームが自然に発生します。
ユーザーは話し始め、間を置き、割り込みます。文字起こしは段階的に更新されます。応答が生成され、ストリーミングされます。外部から処理結果が届きます。セッション内の状況も変化します。これらはすべて、現在の会話状態を形づくった主要イベントとして取得、ストリーミング、保存できます。これらがなければ、きめ細かく的を絞った介入ができなくなります。
イベント駆動型アプローチなら、これを明確な形で管理できます。システムはイベントの発生時にそれを取得し、セッション状態を更新して、適切な後続処理を開始します。
軽量なハンドラーによってリアルタイム経路の応答性を保つ一方、ステートマシンの更新、メトリクスの記録、機密情報の削除、データベースの更新、セッション終了などの複雑な処理は、非同期のバックグラウンドタスクとして実行します。
機能が追加されるにつれ、こうしたバックグラウンドタスクは急速に増える可能性があります。小さなプロダクト変更でも、新たなイベントフローや依存関係が生じることがあります。システムの進化に伴って理解しやすさと信頼性を保つには、こうした並行処理に対応する適切に構成されたアーキテクチャが重要です。
このイベント駆動型アプローチは、会話そのものを形づくるという重要なプロダクト課題にも対応します。リアルタイム音声システムは、応答を生成するだけではありません。会話のペースを整え、沈黙や割り込みを処理し、セッションをいつ、どのように終えるかを判断します。こうした動作はプロダクト体験の一部であり、明示的に設計することで改善できます。
ターン数、経過時間、ユーザーの行動に応じてセッション状態が変化すると、システムは応答役に的を絞った指示を与えられます。セッション上限が近づいたら、会話をまとめられるようユーザーを支援するようエージェントに促したり、対話が滞ったら補足説明を加えたりできます。こうした介入は軽量ですが、意図のある一貫した体験を生み出します。
適切に設計されたシステムは、誰が話しているか、会話がどう進んでいるか、どの条件が満たされたかなど、セッション状態を明確に把握し続けます。イベントストリームによって継続的に更新されるこの状態により、適切なタイミングで適切な指示を出せます。
ユーザー向け AI にガードレールは欠かせません。安全性、コンプライアンス、不正利用、信頼性を管理するためです。ターン制のシステムなら、ユーザーが話し終えた後や応答を返す前など、ガードレールを実行する明確なタイミングがあります。
リアルタイム音声では、こうした都合のよいチェックポイントの大半がなくなります。ユーザー入力は途切れることなく届きます。音声出力もすでにストリーミング中かもしれません。完成した文字起こしは、音声より遅れることがよくあります。メッセージが完成するまでシステムがチェックを待てば、会話はリアルタイムに感じられなくなります。
生き生きとした対話を保つには、会話と並行してガードレールを機能させる必要があります。一つの方法は、音声をバッファーへストリーミングしながら、利用可能になった文字起こしの断片を非同期で評価することです。これにより、対話を妨げることなく、ほぼリアルタイムで安全性チェックを実行できます。
ガードレールが作動した場合、システムは会話の方向転換、動作の調整、必要に応じたセッション終了など、文脈に沿って対応できます。これにより、ユーザー体験を損なわずにガードレールをリアルタイムで機能させられます。
リアルタイム会話システムの評価で最も難しいのは、タイミング、割り込み、流れ、口調といった重要な品質を、文字起こしだけのテストでは捉えられないことです。
標準的な評価パイプラインでは、現実的なシナリオをシステムに入力し、出力を観察して採点します。テキストベースまたは音声処理を連結したシステムなら簡単です。テキストを送り、返されたテキストを確認します。リアルタイムシステムへの入力はライブ音声です。最も重要な会話の性質は、発話の重なりをエージェントがどう処理するか、どれほど速く応答するか、割り込みからどう立て直すかなど、時間軸上に存在します。
エージェントと直接話す手動テストなら、こうした性質を捉えられますが、規模を拡大できません。文字起こしに基づく自動化は拡張できますが、優れたリアルタイム体験と劣った体験を分ける要素が失われます。
一つの方法だけでは不十分です。現実的な答えは、次の手法を組み合わせることです。
エージェント間評価：特定のユーザーペルソナを演じるよう指示された別のリアルタイムエージェントが、テスト対象のシステムと会話します。さらに別の LLM が判定役となり、対話を採点します。これにより、タイミングや割り込み処理を含む音声経路全体を大規模にテストできます。
非機能メトリクス：最初の音声が出るまでの時間と文字起こしの感情分析を、会話品質の定量的な代替指標として利用します。
人手による定性レビュー：自動メトリクスが見逃す問題、特に口調や自然さに関する問題を見つけるうえで、今も欠かせません。
すべてを網羅できる単一の方法はありません。リアルタイムエージェントを本番環境へ導入するには、この 3 つを重ね合わせる必要があります。それでも、リアルタイム音声の評価ツールはテキストベースの AI に比べて未成熟です。
リアルタイム音声は、プロダクトのあり方を変えます。ユーザー体験を形づくるのは、言葉だけではありません。タイミング、割り込み、沈黙、立て直しも同じくらい重要です。
つまり、モデルはシステムの一部にすぎません。本番環境のリアルタイム音声には、音声ネイティブなセッション層、発話と推論の明確な分離、ライブセッションを取り巻くイベント駆動型制御が必要です。ガードレールは依然として遅延のボトルネックですが、工夫次第でリアルタイム体験の多くを維持できます。
この構成で今なお最も弱いのは評価です。タイミング、口調、割り込み処理、会話の流れなど、リアルタイム音声を心地よく感じさせる品質をテストする手法は、まだ確立されていません。それが確立されるまでは、この技術を使うチームが自動テスト、エージェント間テスト、人手によるレビューを組み合わせる必要があります。