AI英会話アプリ「スピーク」は、音声を中心に据えたAIで、語学学習の未来をつくろうとしています。AIとの会話、没入感のあるロールプレイ、インタラクティブなレッスンを通じて、数百万人の学習者が実際に声に出して練習できる場を提供しています。
こうした体験を支えているのが、ユーザーの声を聞き取り、理解し、応答を考え、音声で返す音声エージェント基盤です。自然な会話に感じられるほど低いレイテンシーで、この一連の処理を動かしています。本記事では、この基盤を構築する中で直面した技術的な課題と、そこで下した設計上の判断をご紹介します。
スピークが音声エージェントをつくる理由
スピークの学習メソッド「スピーク・メソッド」は、Learn（学ぶ）→ Practice（練習する）→ Apply（実践する）のサイクルで成り立っています。音声エージェントは、この3つすべての段階で重要な役割を担っています。
Learn・Practice：チューターレッスン
LearnとPracticeでは、AIチューターと一緒に、体系立てられたレッスンを進めます。チューターは概念を説明し、フレーズの例を示してから、学習者に発話を促します。学習者が話しかけている相手は、実際に何を話したかに応じて応答する音声エージェントです。
フレーズを正しく言えたら、音声エージェントは次へ進みます。文法を間違えたら、その理由を説明してもう一度促します。「『of the day』って、もう一度どう言うんだっけ？」と聞かれれば答え、自然に練習へ戻れるようにします。話題が大きくそれたときも、やさしく軌道修正します。
こうして、台本どおりに進むレッスンではなく、マンツーマンで教わっているような体験が生まれます。そのため音声エージェントには、発音の誤り、不完全な回答、語彙の間違い、学習者の母語での質問、周囲の雑音まで、幅広い状況に対応する力が必要です。
Apply：没入型ロールプレイ
Applyでは、学んだことを自由度の高い会話の中で試します。カフェで注文する、ホテルにチェックインする、同僚と話すといった現実的な場面に入り、さまざまな役を演じる音声エージェントと自由に会話します。学習者は会話を自然に進めながら、設定された目標の達成を目指します。
チューターレッスンと違い、ロールプレイに唯一の正解はありません。同じ目標にたどり着く方法はいくつもあります。音声エージェントは、学習者が何を言っても自然に応じながら、会話が目的から外れないよう導く必要があります。
どちらの体験にも、すばやく自然に応答する音声エージェントが欠かせません。機械的な声や長い待ち時間があると、会話への没入感は途切れてしまいます。しかもスピークのユーザーはネイティブスピーカーではなく、語学を学んでいる人です。そのため、多くの音声AIシステムでは想定されていない課題にも向き合う必要があります。
音声エージェント基盤の全体像
スピークの学習者は世界中にいるため、音声処理の各段階で生じるネットワーク遅延が積み重なります。ある地域では快適でも、別の地域では反応が遅い音声エージェントでは十分とは言えません。ここからは、それぞれの構成要素がどう連携しているかを見ていきます。
音声の伝送：LiveKitを使ったWebRTC
iOS・Androidのモバイルアプリは、ユーザーの声を収録し、エージェントの応答音声を再生します。アプリとバックエンドの接続には、リアルタイム音声のために設計されたWebRTCを使っています。WebRTCはパケットロスに強く、エコーキャンセレーションやノイズ抑制も標準で備えています。
WebRTCレイヤーにはLiveKit Cloudを採用しています。シグナリング、NATトラバーサル、メディアルーティングをLiveKit Cloudが担うため、これらのインフラを自前で運用する必要がありません。
音声エージェントサーバー
音声エージェントサーバーでは、後述するカスケード方式またはSpeech-to-Speech方式の音声処理パイプラインに加え、機能ごとのアプリケーションロジックも動かしています。たとえば、学習者が何を言ったかの判断、学習目標の評価、ヒントや訂正の生成、次へ進むタイミングの判断などです。
エージェントは、LiveKit Agentsフレームワーク上に構築されています。このフレームワークは、音声処理、ターンテイキング、各プロバイダーとの連携に必要な高水準の機能を提供します。私たちは低レイヤーのメディア処理ではなく、学習体験そのものに集中できます。
音声エージェントは、音声認識（ASR）、大規模言語モデル（LLM）、音声合成（TTS）、Speech-to-Speech推論のために外部プロバイダーへリクエストを送ります。同時に、レッスンコンテンツ、会話履歴、分析データを取得するため、スピーク独自のバックエンドサービスにも接続します。
グローバル展開
システム全体は、複数のリージョンに展開したスピークのKubernetesクラスター上で稼働しています。モバイルアプリは最寄りのLiveKit Cloudエッジノードに接続し、そこから最も近いスピークのクラスターへトラフィックがルーティングされます。
各リージョンの音声エージェントサーバーは、同じ地域にあるプロバイダーのエンドポイントへ接続します。音声の収録からエージェントの応答まで、パイプライン全体で地理的な近さを活かせる設計です。その結果、どこにいる学習者にも、安定して反応の速い体験を届けられます。
カスケード方式とSpeech-to-Speech：機能に合ったパイプラインを選ぶ
音声エージェント基盤をつくり始めたとき、私たちは重要な設計上の選択に迫られました。カスケード方式のパイプライン（ASR → LLM → TTS）を使うべきか、それともネイティブなSpeech-to-Speechモデルを使うべきか、という選択です。
答えは、機能に応じて両方を使うことでした。どちらにも明確な強みがあります。
カスケード方式は、パイプラインを細かく制御できます。個々のコンポーネントを入れ替えたり、処理の間に別のステップを加えたり、発話前にエージェントの応答を書き換えたりできます。テキストベースのLLMは指示に従う精度が高く、コストも大幅に抑えられます。
Speech-to-Speech方式は、声のトーン、韻律、発音など、単語以外の音声特性を保てます。ASR → LLM → TTSという処理の連鎖がないため、レイテンシーも低くなります。一方で、指示に従う精度は比較的低く、コストも高いというトレードオフがあります。ただし、指示追従性は急速に改善しています。
重要なのは、機能によっては文字起こしの過程で失われる音声信号の情報が必要になることです。学習者が単語を誤って発音しても、文字起こしだけを見ると正しく見えることがあります。ASRモデルは有効な単語を出力するよう学習されている一方、実際の音声には、どのように発音したかという情報が残っているためです。
私たちの判断基準はシンプルです。文字起こしだけでは捉えられない音声特性を理解する必要があるならSpeech-to-Speechを使い、それ以外はカスケード方式を使う。実際には、次のように使い分けています。
- カスケード方式： 没入型ロールプレイや自由形式の会話など、どのように言ったかより何を言ったかが重要な場面
- Speech-to-Speech方式： 発音フィードバック、話し方をリアルタイムで指導するチューターレッスン、声のトーンやアクセントが重要な機能
新機能の解決策を検討するときは、まず各方式が要件をどこまで満たせるか、どこに弱点があるかを見ます。そのうえで両方の方式でプロトタイプをつくり、精度と速度を比べ、エンドツーエンドの総コストを試算します。このハイブリッドな設計があるからこそ、技術環境の変化に合わせて改善を柔軟に取り込めます。
TTSプロバイダーの選定：すべてに適した1社はない
カスケード方式を使う機能を検証する中で分かったのは、あらゆるユースケースに適した単一のTTSプロバイダーは存在しない、ということでした。言語ペアごとに幅広く評価した結果、プロバイダーごとに次の点で大きな差がありました。
- 言語品質： アジア言語に強く欧米言語を苦手とするプロバイダーもあれば、その逆もあります。アクセントの品質、自然な韻律、言語固有の音を正しく発音できるかにも差があります。
- コードスイッチング： 語学学習では、ひとつの発話の中でL1（学習者の母語）とL2（学習対象の言語）を混ぜることがよくあります。たとえば、英語でスペイン語のフレーズを説明する場面です。こうした切り替えを自然に扱えるプロバイダーもあれば、切り替わりが不自然になったり、文中の別言語をまったく違う発音にしてしまったりするプロバイダーもあります。
- レイテンシー： 音声エージェントでは、TTSのTime to First Byte（最初の音声データが届くまでの時間）が非常に重要です。低レイテンシー向けに最適化されておらず、音声ストリーミングの開始まで1秒以上かかるプロバイダーがある一方、リアルタイム用途向けに設計され、ほぼすぐにストリーミングを始められるプロバイダーもあります。音声品質が優れていても、レイテンシーが大きければインタラクティブな会話には使えないことがあります。
- カスタム音声： 没入感のある体験には、一貫したキャラクターボイスをつくれることも重要です。音声クローニングやカスタマイズへの対応には、プロバイダーごとに大きな差があります。
私たちは言語ペアとユースケースごとにTTSプロバイダーを評価し、同じ機能でも複数のプロバイダーを使い分けることがあります。運用は複雑になりますが、それを正当化できるだけの品質差があります。
検討すべき要素が多く、音声品質の評価には主観も入りやすいため、分析だけで最適なプロバイダーを選ぶのは難しいものです。実際に実験することで学びが早まり、事前には見えなかったトレードオフが分かり、学習者が本当に好むものを基準に判断できるようになりました。
180円で1か月、または7日間無料。自分に合う方法で始められます。
スピークを試してみる
語学学習者のための音声エージェント設計
多くの音声AI企業が直面しない、語学学習ならではの課題があります。語学学習者の「間」は、ネイティブスピーカーの「間」とは違うということです。
一般的なASRやターン検出システムは、ユーザーが300〜500ミリ秒ほど黙ると、発話が終わったと判断します。しかし語学学習者は、使いたい単語を探したり、頭の中で動詞を活用したり、続けて話す自信を整えたりするため、話している途中で何度も間を取ります。この前提は、語学学習の場面ではうまく機能しません。
その結果、2つの問題が生じます。
- 文字起こし精度の低下： システムが一つひとつの間を発話の区切りだと判断すると、ひとつの文が複数の断片に分かれます。音声認識モデルは、完全な発話に比べて、こうした断片を正確に認識しにくくなります。
- 早すぎる割り込み： 一般的な音声区間検出（VAD）の設定を使うと、学習者がまだ話し終えていないのにAIが応答を始めてしまい、ストレスの大きい体験になります。
この課題への対応は、機能によって異なります。
- 手動ターン検出： ユーザーがボタンをタップして自分のターンを終える機能では、録音された音声全体をひとつの発話として扱い、録音全体に対してひとつの文字起こしを生成します。複数の文が含まれていても分割しないため、最も高い文字起こし精度が得られます。
- 自動ターン検出： ハンズフリーの体験が必要な機能では、沈黙時間だけに頼らず、会話の文脈を理解するセマンティックなターン検出モデルを使います。語学学習者に適したターン検出モデルの構築は、今も未解決の課題であり、現在も改善を重ねています。
オブザーバビリティ：本当に見るべき指標を測る
オブザーバビリティは、音声エージェントの品質を継続的に改善するための基盤です。音声エージェントでは、一般的なインフラ指標を見るだけでは足りません。まず見るべきは、学習者が実際に感じるエンドツーエンドのエージェント応答レイテンシーです。学習者が話し終えてから、エージェントの声が聞こえ始めるまでの時間を指します。私たちはこの指標を中心に最適化しています。ただし、どこを改善すべきかを知るには、パイプラインの各段階でレイテンシーがどう積み上がるかを理解する必要があります。
学習者が話し終えた瞬間から計測が始まります。最初に必要なのは完全な文字起こしです。そこで、ユーザーのターン終了から最終文字起こしを受け取るまでの時間を示す、ASRのTime to Final Transcriptを追跡しています。また、送信済みの音声に対してライブ文字起こしがどれだけ遅れているかを示すストリーミングレイテンシーも監視しています。これはリアルタイム文字起こしをどれだけ早く表示できるかに影響し、学習者がシステムに自分の発話が正しく伝わったかを確認する助けになります。次にLLMが応答を生成します。Time to First Tokenは、モデルがどれだけ早く生成を始めたかを示し、TTSがいつ処理を始められるかを左右します。最後にTTSがテキストを音声へ変換します。ここでのTime to First Byteによって、学習者がエージェントの声を聞き始めるタイミングが決まります。音声が実際の再生速度より速く生成されているかも追跡しています。途切れや音飛びのない滑らかなストリーミングに欠かせないためです。
スピークでは言語ペアごとに複数のプロバイダーを使っているため、これらの指標をプロバイダー別、言語別、リージョン別に追跡しています。この粒度が重要です。ベンチマークでは良い結果のプロバイダーでも、ルーティングの影響で特定のリージョンに想定外の遅延が生じたり、負荷が高いときに性能が落ちたりすることがあるからです。P50だけを見るのも十分ではありません。外部プロバイダーの成功率やレイテンシーは分布の末尾で大きく変動するため、P95やP99の監視と最適化も同じくらい必要です。ここまで可視化できていなければ、問題の診断や解決はずっと難しくなります。
信頼性の面では、社内サービスと外部プロバイダーの両方で、エラー率、タイムアウト率、可用性を追跡しています。あるリージョンでプロバイダーのレイテンシーが急増したり、エラー率がしきい値を超えたりした場合は、その言語ペア向けのバックアッププロバイダーへ自動的にトラフィックを切り替えます。想定どおりに動いていないときはアラートが届くため、学習者が問題に気づく前に調査を始められます。
今後の展望
スピークのリアルタイム音声基盤は、これからさらに高度な音声体験を実現していくための土台です。現在は、次の取り組みを進めています。
- ターン検出の改善： 語学学習者が考えるために間を取っているだけなのか、本当に話し終えたのかを理解する、セマンティックな発話終了検出の精度を高めます。
- Speech-to-Speechの活用範囲の拡大： モデルの指示追従性が上がり、コストが下がるにつれて、より豊かなフィードバックを提供できるSpeech-to-Speechへ移行する機能を増やしていく予定です。
- 音声ベースの評価： 評価フレームワークを音声の入力と出力に対応させ、音声エージェントの品質をより体系的に測定・改善できるようにします。
振り返り
この基盤をつくる中で、特に強く感じたことがあります。
デモではなく、実際のユーザーのためにつくる
一般的なVADのしきい値、ASRのデフォルト設定、単一プロバイダーによるTTS構成は、いずれも理想的な環境で話すネイティブスピーカーを前提に設計されています。特定の領域に向けた音声エージェントをつくるとき、最初に問うべきなのは「どのプロバイダーを使うべきか」ではありません。「私たちのユーザーは、これらのツールが想定する標準的なユーザーと、どこが違うのか」です。
アーキテクチャの柔軟性を保つ
音声AIを取り巻く環境は、非常に速いスピードで変化しています。新しいモデル、プロバイダー、機能が次々に登場します。ひとつの方式に固定することは、特定の時点の技術に賭けることでもあります。
新しいSpeech-to-Speechモデルの指示追従性が大きく向上すれば、機能を段階的に移行できます。必要な言語への対応に優れた新しいTTSプロバイダーが登場すれば、それを組み込めます。シンプルさを優先してすべてを標準化するのではなく、機能ごとに適したパイプラインを選ぶことで、学習者が期待する品質を保ちながら、改善をすばやく取り入れられます。
レイテンシーはインフラだけでなく、デザインの問題でもある
私たちはパイプラインの最適化に多くの時間を費やしました。それが重要であることに変わりはありません。しかし、とりわけ大きな改善のいくつかは、インタラクションデザインから生まれました。
手動ターン検出は、単なる技術的な代替策ではありません。学習者自身に会話の主導権を渡し、考えている途中で割り込まれる不安をなくします。配慮の行き届いたUXで体感レイテンシーを改善することは、実際のレイテンシーを短縮することと同じくらい重要になり得ます。
語学学習者のための音声エージェントをつくることは、一般的な音声AIアプリケーションにはない課題に向き合うことでもあります。低レイテンシーの音声システム、複数プロバイダーのオーケストレーション、領域固有の学習メソッドが交わるこの領域こそ、私たちがスピークで取り組みたい挑戦です。
180円で1か月、または7日間無料。自分に合う方法で始められます。
スピークを始める
