エンドツーエンド音声モデルは ASR–LLM–TTS のカスケードを殺していない
ここ数年、音声エージェントを作る標準的なやり方は箱を三つ直列に並べることだった。ASR が音声をテキストにし、LLM が何を言うか決め、TTS がそれを音声に戻す。そこへ音声ネイティブなモデルが現れた。音声を入れて音声が出る、ネットワークは一つ。以来、語り口は「カスケードはレガシー」になった。デモは実際よくできている。モデルは笑い、口ごもり、文の途中で口調を変え、こちらの割り込みを受け入れる。
だが、カスケードを置き換える理由として挙げられるものの大半はレイテンシの話であり、その大半はレイテンシがどこにあるかを取り違えている。一方で本当に成立する理由ははっきり語られることが少なく、置き換えのコストはたいてい過小評価されている。ここは分けて考える価値がある。
レイテンシの勘定は、ほとんどが「発話終了の判定」
カスケードに対する直感的な反論はこうだ。三つのモデルを直列に並べたら、一つより遅いに決まっている。ASR と LLM と TTS を足せば数字が出る。
しかし、まともに作られたカスケードで時間が実際どこに消えているかを見ると、その足し算は問題ではない。ストリーミング ASR は音声が届いてから 200〜300 ミリ秒で安定した書き起こしを出す。LLM は部分書き起こしで走り出せるので、ユーザーがまだ話している時間とプレフィルが重なる。TTS がストリーミングなら最初のパケットは 100 ミリ秒を大きく下回って返る。三段は積み上がるのではなく、パイプライン化される。
支配項はまったく別のところにある。ユーザーが話し終えたと判定することだ。従来の音声パイプラインはこれを無音検出でやる。N ミリ秒静かならターン終了とみなす。N を小さくすれば、考えるために間を置いた人を毎回さえぎる。N を大きくすれば、すべてのやりとりがその遅延を背負う。多くのチームは 0.5 秒前後に落ち着き、このパラメータひとつが体感応答時間に占める割合は、たいてい三つのモデルの合計より大きい。
ここが音声ネイティブモデルが本当に改善している点で、その理由は正確に述べる価値がある。人間の会話におけるターンの受け渡しは無音では合図されない。イントネーション、統語的な完結、節末での音高の下降で合図される。生の音声を見ているモデルはそれらの手がかりを使い、人間が返すのと同じ地点で返せる。短い発話の直後にすばやく返すことも、文の途中の間を辛抱強く待つことも含めて。
ただし注意してほしい。これはターン検出の性質であって、エンドツーエンド生成の性質ではない。音響特徴と部分書き起こしを受け取って「ターンが終わった」を予測する意味的エンドポインティングのモデルを別途作り、カスケードに差し込むことができる。すでにそうしているチームは複数ある。残りのアーキテクチャに手を触れずに、会話としての手触りの大部分が戻ってくる。不満がレイテンシなら、これが安いほうの直し方であり、三段まるごと置き換えるよりずっと小さな変更だ。
本当に成立する理由：テキストは損失のあるボトルネック
こちらが持ちこたえる主張だ。カスケードでは、ユーザーが伝えるものすべてがいったんテキストに潰されて生き残らなければならず、システムが伝えるものすべてがテキストから再構成されなければならない。このボトルネックを二度通って落ちていくのが、**「どう言われたか」**に関する情報のすべてである。
テキストは、ユーザーが苛立って聞こえたことも、ためらっていたことも、半分冗談だったことも、自信なく語尾を濁したことも運ばない。話し手が子どもであることも、部屋にもう一人いることも、車の中にいることも運ばない。戻り方向も同じだ。TTS は「その言葉がどう受け取られるかを知らないまま LLM が書いた一文」の感情を推測するはめになる。皮肉は平坦になる。お悔やみと確認が同じ読み方になる。
かなり大きな一群の製品にとって、この損失はどうでもいい。注文状況を確認しているだけの人に対して、感情の色合いが正しい振る舞いを変えることはない。だが別の一群にとっては、それが製品そのものだ。伴走、語学練習、コーチング──システムの仕事が「要求に応える」ことではなく「人に応える」ことであるすべて。そこではカスケードは少し劣るのではない。構造的にその仕事ができず、三つの箱をいくら作り込んでも埋まらない。
だから正直な分割線はここにある。レイテンシではない。あなたの製品の価値は「何が言われたか」に宿るのか、「どう言われたか」に宿るのか。
手放すことになるもの
カスケードの置き換えはデモが示唆するより高くつく。しかもコストの大半は聴感ではなく運用の側にある。
テキストは監査できる唯一の媒体である。 カスケードは「ユーザーが何を言い、システムが何を言ったか」の書き起こしを自然に産む。保存でき、検索でき、個人情報を伏せられ、コンプライアンス検査をかけられ、抜き取りで品質を見られ、アナリストに渡せる。エンドツーエンドの中間状態は音声トークンの列だ。後から音声を書き起こせば似たものは得られるが、それは事後の再構成であって、モデルが実際に条件付けていたものではない。
段ごとの差し替えができなくなる。 カスケードでは各箱が独立した調達判断だ。ある言語だけ良い ASR に移り、TTS はそのままにし、来四半期に強い LLM が出たら LLM を替える──この分野では「来四半期に強いのが出る」はほぼ「常に」と同義である。エンドツーエンドは三つの能力を同時に一社に束ねることを意味し、上げるなら全部、上げないなら全部だ。
推論能力の差は実在する。 現時点で、音声ネイティブモデルは指示追従・ツール利用・多段推論において最前線のテキストモデルにはっきり後れを取っている。エージェントが関数を確実に呼び、長い規程文書に従い、ドメインの事実を外さない必要があるなら、カスケードは利用可能な最良のテキストモデルを中心に据えさせてくれる。この差は縮むだろうが、まだ閉じていない。
文言そのものの制御。 規制のある製品では、ある文を一字一句そのまま言う必要があり、ある文は決して言ってはならない。テキストの段こそがそれを担保する場所で、発話される前にその文字列を検査できる。音声トークンには等価な検査点がない。
デバッグのしやすさ。 カスケードが変な振る舞いをしたとき、どの箱のせいか切り分けられる。書き起こしが間違っていたのか、書き起こしは正しくて返答が間違っていたのか、両方正しくて響きだけが妙だったのか。このトリアージは数分で終わる。エンドツーエンドでは音声が入って音声が出るだけで、まずい応答を検分するための中間証拠が存在しない。
割り込みは、どちらにせよ転送層の問題
ひとつ別立てで書いておきたい。両アーキテクチャがまったく同じ形で間違えるからだ。割り込みはモデルを替えても解決しない。
ユーザーがエージェントにかぶせて話し始めたら、即座に再生を止め、クライアント側にすでにバッファされている音声を捨てなければならない。ここまでは誰でもやる。厄介なのはその後モデルが何を起きたと信じているかだ。三文の回答を生成し、ユーザーが四語目で割り込んだとすると、モデルの文脈は「三文言った」と主張し、ユーザーが聞いたのは四語である。以後のすべてのターンが共有状態についての偽の前提の上に建ち、会話は静かに同期を失う。エージェントはユーザーが聞いてもいないことを参照しはじめる。
直し方は、モデル自身の履歴を実際に再生された分まで切り詰めることだ。つまりクライアントは割り込み時点の再生位置を報告しなければならず、セッション状態は直前のターンを書き換えられなければならない。これはカスケードでも面倒だし、エンドツーエンドでも面倒だ。そして「デモは良いのに、しばらく使うと何かおかしい」という感覚の、最も一般的な単一の原因でもある。
選び方
製品がトランザクショナルなら──サポート、予約、注文、データ照会、ツールと業務ルールを伴うもの全般──カスケードで作る。ターンの受け渡しは無音タイマーではなく意味的エンドポインティングのモデルに任せ、両端をストリーミングにする。それだけで即応と感じられる応答時間が得られ、さらに監査可能性と段ごとの自由が手元に残る。どちらも後から買い戻すと高くつくものだ。
製品がリレーショナルなら──眼目がユーザーに「聞いてもらえた」と感じさせることなら──カスケードのテキストのボトルネックは工学で越えられない天井であり、運用コストを払ってでもエンドツーエンドが正しいアーキテクチャになる。
その中間にいるなら、有用なハイブリッドは「半分のモデル」ではない。音響のサイドチャネルを持つカスケードだ。入力音声に軽量な分類器を走らせ、感情・エネルギー・話者特性を取り出し、構造化された文脈として LLM に渡し、TTS 段への話し方の指示を LLM に選ばせる。パラ言語のループのかなりの部分を取り戻しながら、テキストは目に見える真ん中の位置に残る。今日の本番システムの大半が座るべきなのはここで、デモが示唆するより相当に地味な結論である。