LLMが変えたのは、音声対話の「考える」部分

車のナビに「自宅に帰る」と言えば通じるのに、「そろそろ帰ろうかな」では通じない。

少し前まで、音声操作にはこうした歯がゆさがありました。決められた言い方から外れると、こちらの意図をうまく拾ってくれなかったからです。

いまの音声AIは違います。「そろそろ帰ろうかな」でも、「いつものところに戻りたい」でも、前後の文脈から意図を推測できます。

この変化を大きく生んだのがLLMです。音声対話AIは、大まかに言えば「聞く → 考える → 話す → 会話の間を取る」という複数の処理でできています（全体像は 音声AIは、画面が使える場所では意外と出番がない に記載しています）。LLMによって大きく変わったのは、このうち「考える」部分です。

そして、そこで起きた変化は単なる性能向上ではありません。決められた言い方しか受けられない代わりに動きが読みやすかったシステムから、自由な言い方を理解できる代わりに想定外の答えも返すシステムへ変わった。この記事では、この交換で何が変わったのかを整理します。

以前の音声対話は、発話を「決められた用件」に振り分けていた

LLM以前の音声対話では、音声認識で発話を文字にしたあと、人があらかじめ用意した「意図」のどれに当てはまるかを判定する構成がよく使われていました。

• 「自宅に帰る」→ 経路案内
• 「音量を上げて」→ 音量操作
• 「エアコンをつけて」→ 空調操作

といった形です。こうしたコマンド型のシステムは、想定した範囲では安定して動きます。

一方で、利用者は設計者が想定した通りには話してくれません。「エアコンつけて」「冷房入れて」「ちょっと暑いな」。人間には似た意味に聞こえても、システム側では別々の言い方として扱われます。そのため、実際の発話を見ながら例文やルールを追加し、利用者の言い方を追いかける必要がありました。

不便ですが、利点もあります。あらかじめ用意していない処理を、勝手に作り出しにくいことです。想定した範囲が狭い代わりに、その中では動きを予測しやすい。業務システムでは、この性質が重要になることがあります。

LLMによって、言い方を事前に並べる必要が減った

LLMを使うと、この関係が変わります。

例えば「えっと、前に頼んだやつ、もう一回お願い」という発話には、明確なコマンド名が含まれていません。それでも、それまでの会話を参照すれば「直前に依頼したものをもう一度頼みたい」と解釈できます。すべての言い換えを事前に登録しなくても、文章の意味や会話の流れから意図を推測できるようになったわけです。

音声認識で文字にし、LLMで応答を作り、音声合成で声に戻す。この構成は、現在の音声対話システムで広く使われている基本形の一つです[1][3]。

LLMによって得られた最大の変化は、利用者がシステムの言い方に合わせなくてもよくなったことです。

ただし、自由になった分だけ動きは読みにくくなった

コマンド型では、システムが返せる答えや実行できる処理を、ある程度あらかじめ限定できます。LLMでは、その境界が曖昧になります。

代表的なのがハルシネーションです。LLMは、正しい情報がない場合でも、もっともらしい文章を生成することがあります。コマンド型なら「別の命令と誤認する」か「該当する命令がない」という失敗が中心でした。LLMではそこに「存在しない答えを、それらしく返す」という新しい失敗が加わります。範囲外の発言を止める仕組みは 自動応答のAIは、言ってはいけないことをどう避けているのか に記載しています。

つまりLLMによって、利用者側の自由度は上がりましたが、システム側の予測可能性は下がりました。業務用途では、この交換をそのまま受け入れられるとは限りません。予約の変更、契約、決済など、間違った処理の影響が大きい用途では、LLMが理解した内容をそのまま実行させず、ルールや確認処理を組み合わせる必要があります。

LLMになっても、音声対話そのものの難しさは残る

一方で、音声対話で起きる問題のすべてがLLMによって生まれたわけではありません。

例えば、返事の遅れです。一般的な構成では、音声を聞き取り、LLMが答えを作り、音声を生成する、という処理を順番に行います。それぞれが速くても、処理時間は積み重なります。人間どうしなら自然に入るはずのタイミングで返事が来なければ、利用者には「AIが黙っている」ように感じられます。これは、LLMが賢くなっただけでは解決しません。この綱引きは AIの声は自然になったのに、なぜ返事は遅いのか に記載しています。

もう一つ難しいのが、言い直しです。「明日の10時でお願いします。あ、やっぱり11時……いや、さっきの10時で」。人間なら自然に理解できます。しかしシステム側では、どの情報を残して、どの情報を取り消すのかを管理しなければなりません。こうした会話状態の扱いは、コマンド型でもLLM型でも残る問題です。

つまり、LLMによって「言葉の意味を理解する力」は大きく上がりましたが、音声で自然に会話するための問題が全部解けたわけではありません。

だから、全部をLLMに任せる必要はない

LLMが使えるからといって、すべての処理をLLMに置き換える必要はありません。

「残高を確認する」「予約をキャンセルする」「オペレーターにつなぐ」といった処理は、候補が明確です。こうした用件なら、従来型のルールやコマンド処理の方が制御しやすい場合があります。反対に、「先週頼んだやつ、もう一度送ってほしい」のように、自由な言い方や会話の文脈を解釈する必要がある場面ではLLMが強みを発揮します。

そのため実際の設計では、自由な発話の理解はLLMに任せ、実行する処理は限定する、という組み合わせが有効です。例えばLLMに「利用者が何をしたいのか」までを解釈させ、その先の予約変更や契約処理は決められたAPIだけを呼ばせる、といった構成です。判断をLLMに任せ、実行は決められた処理に限る。この組み合わせは、AIエージェントと呼ばれる仕組みにも使われます。LLMかコマンド型かを二者択一で考える必要はありません。

音声対話は、「自由」と「制御」の配分を設計する

音声対話AIにLLMが入ったことで、利用者は決められた言い方を覚える必要がなくなりました。一方で、システムがどう答えるかを完全に予測することは難しくなりました。

得たのは、言い方の自由。手放したのは、想定外の動きをしない堅さ。

だから音声対話AIを設計するときに決めるべきなのは、「LLMを使うかどうか」だけではありません。どこまでをLLMに考えさせ、どこから先をシステム側で制御するか。この境界を用件ごとに決めることが重要です。

なお、ここで説明したのは、音声認識・LLM・音声合成を分けて処理する構成についてです。近年は、音声を文字に変換せず直接扱うSpeech Language Modelや、相手の発話を聞きながら応答するFull-Duplex型の音声対話も研究されています[1][2]。「聞く・考える・話す」を別々の部品として扱う現在の構成自体も、今後変わっていく可能性があります。