考えている間、彼らはまるで耳が聞こえず目も見えないかのようだ。周りで何が起きているのか、それ以外のことは何も知覚できない。 -
ほとんどの音声エージェントがいまだに文字起こし（トランスクリプト）に基づいて判断を下していることに、私は驚きを隠せない。
すべての通話は、エージェントの「思考レイヤー」に届く前に、音声からテキストへ変換される。この変換には情報の欠落がつきものだ。残るのは言葉だけである。ためらい、「えーと」という言い淀み、語尾で下がるピッチ、背景音、誰かに話しかけるために少し体を向けた様子——そうしたものはすべて消えてしまう。
だからエージェントは推測するしかない。相手が考えをまとめきる前に遮ったり、話し終わった後に長く待ちすぎたり、丁寧な言葉の裏にある怒りを見逃したりする。
これこそが、今日の音声 AI における最大のギャップだと私は考えている。
本記事では現状に対する私の見解を示し、次の問いを探っていく。
- エージェントが通話を一度も「聞かずに」適切な判断を下せるのか？
- なぜ LLM のネットワークはこのギャップを埋められなかったのか？
- なぜ Speech-to-Speech モデルを使わないのか？
- 実際に「聴く」思考レイヤーとはどのようなものか？
市場の現在地はどこか？
https://x.com/jordan_dearsley/status/2085602471918064064
何年もの間、人々は音声がソフトウェアと対話する普遍的な手段になると予測してきた。2026 年になり、その予測は現実味を帯び始めている。@ElevenLabs や @DeepgramAI といった企業、そして 800 を超える音声 AI プロダクトのおかげで、AI は毎年数十億件のビジネス通話を処理している。
しかし、あらゆる技術波の初期段階と同じように、普及のスピードが品質を上回っている。本番環境のエージェントに「非常に満足している」企業は 約 5 社に 1 社 にすぎない。そのため大半のエージェントは、手頃で信頼できる領域にとどまっている。つまり、スクリプトに沿ったアウトバウンド通話や、予測可能なほどシンプルなインバウンド対応だ。
ほぼすべての音声エージェントはカスケード型で構成されている。まず Speech-to-Text（STT）、次に LLM、そして Text-to-Speech（TTS）という流れだ。エンジニアがこの設計を好むのは、タスクごとに最適なモデルを選び、中間ステップをすべて確認でき、エージェントの発話や行動を厳密に制御できるからである。
STT と TTS はレイテンシとコストの面で大きく進歩したものの、弱点となっているのが思考レイヤーだ。
文字起こしが捨ててしまうもの
思考レイヤーの役割はシンプルだ。会話の状態を把握し、次の適切な状態へと進めるアクション（話す、実行する、引き継ぐ、聞き続ける）を選ぶことである。
あなたのコードは、通話がワークフローのどのステップにあるかを常に把握している。しかし、電話の向こう側の人間に何が起きているかは分からない。それこそが、思考レイヤーがターンごとに読み取らなければならない部分だ。
- ユーザーは話し終えたのか、それとも一呼吸置いただけなのか？
- 何語で話しているのか？
- 好奇心から質問しているのか、それとも悪いサービスに怒っているのか？
- 背景音はテレビか、それとも遊んでいる子どもたちか？
- 私に話しかけているのか、それとも隣にいるパートナーに話しているのか？
- 求めているのは何か：返金、新規アカウント作成、状況確認？
「はい、どうぞ」という同じ文字起こしになる 2 つの音声クリップ。一方はエージェントに向かって話され、もう一方は部屋にいる別の人に向けられている。両者を区別できるのは音声だけだ。
上記の太字の項目は、何を 言ったかだけでなく、どのように 言ったかを教えてくれる。文字起こしは言葉を残すが、ピッチ、ペース、間、そして部屋の空気感を落としてしまう。
最初の質問を考えてみよう。沈黙が訪れる前に相手が話し終えようとしていることは、誰にでも分かる。ピッチが下がり、ペースが落ち、声が消えていくからだ。音声を聞くモデルは、まさにこうした手がかりを使うことを学習する（Ekstedt & Skantze, 2022）。しかし文字起こししか読めないモデルにはそれができない。韻律情報が書き留められることは決してないからだ（Rajaa, 2026）。
5 番目の質問も同様だ。Apple が検証した結果では、発話がアシスタントに向けられたものかどうかを判定する際、文字起こしに音声を加えることで、文字起こし単体と比較してエラーが最大 39% 減少した。
最善の判断は、音声とテキストを組み合わせて下される。残念ながら、今日のエージェントが受け取るのはテキストだけだ。
文字起こしのみ：74.8% のターンで早すぎる割り込みが発生。音声あり：7.8%。Uniphore、arXiv 2609.11066 より。
なぜ LLM のネットワークは壁にぶつかるのか
エンジニアたちは「思考レイヤー」を構築するために、欲張りな解決策を選んだ。最も手軽で、すぐに最大の成果が出る道へ走ったのだ。すなわち、その時点で最高峰のフロンティア LLM を採用し、どう振る舞うべきかを記した巨大なマニュアルを一つ渡すという方法である。これが 2023〜24 年のすべてだった。
ここにはいくつかの問題がある。
- 第一に、チームは LLM が予測不能で遅く、長くて高密度なプロンプトの中では指示を見落とすことに気づいた。
- 第二に、1 回の LLM 呼び出しでは発話を理解するのに不十分だということだ。
そこで次に論理的なステップとなったのが、より速く安価な LLM のネットワークだった。それぞれを異なるタスクに割り当て、上位にオーケストレーターを配置する構成である。デモは素晴らしかった。買い手は感銘を受け、収益が流れ始めた。
これが現在のフロンティアスタックだ。
しかし本番環境では、このアーキテクチャに 2 つの亀裂が見えた。
- どのコンポーネントも同じ文字起こしを読んでいる。 LLM を増やしても、文字起こしの段階で失われた間やトーンを取り戻すことはできない。
- 各コンポーネントが互いを待ってしまう。 呼び出しのたびに遅延が加算される。ターンの認識、行動の決定、タスクの実行で、応答時間の最大 80% が消費される。
カスケード型の音声エージェント：発信者の音声は STT へ送られ、複数の LLM 呼び出しを経て、TTS へ渡る。ピッチ、間、トーン、背景音、話しかけ先は STT の段階で失われる。
業界は思考レイヤーをタスク単位で分割した。本来は入力単位で分割すべきだった。 音声シグナルを必要とする判断はオーディオネイティブなモデルに任せ、LLM はテキストだけを扱うべきなのだ。
なぜ文字起こしを完全にスキップしないのか？
今年に入り、Speech-to-Speech（STS）モデルが本格的に頭角を現し始めた。魅力は明白だ。STT、LLM、TTS を単一モデルに圧縮することで、レイテンシの低下、会話理解の向上、エンジニアリング工数の削減を実現できる。
最大の弱点は、制御性と検証済みデータの不足だ。STS モデルが何を言うかを正確に固定することは難しく、ツール呼び出しやコード実行は、音声で思考するモデルにとって自然な動作ではない。
短期的に見れば、STS は実用化からまだ遠いと考えている。仮に開発が加速したとしても、まずは FAQ 回答のようなシンプルなユースケースに適したものになるだろう。ビルダーたちはカスケード型にとどまるはずだ。一部は惰性によるものであり、大部分はその制御性と柔軟性が必要だからだ。
だからこそ私は、カスケードスタックを制御しやすくし、コストとレイテンシの両面でデプロイ可能にするモデルを構築している。
聴くレイヤー
エージェントを制御しつつ無駄を省く方法があると私は信じている。それが 意思決定モデル だ。
GPT-Live を注意深く見ると、その中心に意思決定エンジンがあることが分かる。これは 1 秒間に何度も、話すか、聞き続けるか、間を置くか、割り込むか、ツールを呼ぶかを判断する。カスケード型にも、可視化・制御可能なコンポーネントとして同じエンジンが必要だ。
意思決定モデルは、現在の状態と限られた選択肢のセット（話すか待つか、エスカレーションするか続行するか、どの意図か）を受け取り、確率付きで 1 つの選択を返す。LLM よりも高速で、はるかに低コストだ。@typesafeai は、これがテキスト上でどれほどうまく機能するかを示して人々を驚かせた。
私が提案するのは次のような構成だ。
- 意思決定モデル が通話を聴き、限定された範囲の判断を下す。
- あなたのソフトウェア がワークフローの状態、権限、ツールを保持する。
- LLM は最も得意なこと、つまり「何をするか」が決まった後に返答文を作成することに専念する。
意思決定モデルは音声、これまでの会話、選択肢のセットを受け取り、各選択肢の確率を返す：refund_status 0.91、cancel_order 0.06、escalate 0.03（例）。
これを成立させるのが信頼度スコアだ。LLM に「どれくらい確信しているか」を尋ねると、たとえ間違っている場合でも、たいてい「非常に」と答える（Xiong et al., 2024）。一方、分類器のスコアは、示す数値がそのまま意味を持つように調整できる。分類器が「確信している」と言えば、実際にそうであることが多い（Guo et al., 2017）。
デザインパートナーとの初期実験では、エージェント内で LLM が担う処理の 30〜40% が、まさにこの種の作業——ルーティング、トリアージ、限定された選択肢からの選定——であることが分かった。
しかし、現在の意思決定モデルはテキストや画像を対象としている。TypeSafe AI の報告によれば、Jev を含むあらゆるモデルが、テキストに加えて別のモダリティを追加すると判断精度を落とし、Jev には音声サポートの公式ドキュメントが存在しない。
テキスト用の意思決定モデルに音声を後付けすることはできない。「聴く」モデルを構築するには、次の 3 つが必要だ。
- 各瞬間における正しい判断でラベル付けされた、実際の会話音声データ
- 音声とテキストを同時に使って判断を下すモデル
- アクセント、ノイズ、劣悪な電話回線においても信頼性を保つスコア
音声にふさわしい意思決定モデルとは、聴くことができるモデル、すなわちオーディオネイティブな意思決定レイヤーだ。
意思決定レイヤーが「聴ける」ようになると何が変わるか
オーディオネイティブな意思決定モデルによって、次のユースケースが可能になる。
- デバッグ可能なエージェント。 現在多くのチームが、挨拶、本人確認、返金処理、エスカレーションといった状態のグラフとしてエージェントを設計している。各ターンは 2 つの判断に帰着する。会話は実際にはどの状態にあり、次にどの状態へ移るべきか？どちらか一方でも間違えれば、通話全体が迷走する。
各ステップに意思決定モデルを置けば、すべての遷移が小さく説明可能な単位になる。何を聴き取り、どんな選択肢があり、何を選び、どれほど確信していたか。通話がうまくいかないとき、巨大なプロンプトをデバッグする必要はない。ずれた歯車を 1 つ見つけ、その部分を修正すればいい。
- 発信者が話し終わる前に用意される回答。 人は文を最後まで言う前に、自分が何を求めているかを明かしてしまう。「先週注文した件で電話したのですが……」という時点で、すでに注文検索の意図だ。テキスト優先のエージェントは、ユーザーが止まるのを待ち、最終的な文字起こしを待ち、どのツールを呼ぶか判断し、それからようやく呼び出す。各ステップが沈黙を積み重ねていく。
「先週の注文についてお電話しました」と話す発信者のタイムライン。テキスト優先のエージェントは終了を待ち、文字起こしし、判断し、get_order を呼ぶ。聴くルーターは文中で get_order を起動し、発信者が止まった瞬間に返答するため時間を節約できる。
聴く意思決定モデルは、通話に先回りするルーターとして機能する。文中で意図を認識し、ユーザーがまだ話している間に検索を実行するため、相手が止まった瞬間に注文の詳細が用意されている。
Meta と CMU の研究者たちは、その恩恵を実証した。ユーザーの発話と並行してツールのクエリを予測することで、ツールのレイテンシが 20% 短縮され、回答の精度も向上した。
- 瞬時に反応するように感じるパーソナルエージェント。 パーソナルエージェントは一日中、キッチンや車内、騒がしい街中でボイスメモを通じてコマンドを聴いている。その大半に必要な判断は 1 つだけだ。これはタスクか、リマインダーか、思いつきか、そもそも自分宛てではないのか？
すべての発話をフロンティア LLM に送るのは遅く、コストも高い。聴く小型モデルなら、その判断をわずかな時間で下し、本当に処理が必要なときだけ LLM を起動できる。最初の判断が大型モデルを待つことがないため、エージェントは瞬時に反応するように感じられる。
https://x.com/signulll/status/2077444321243013306
音声 AI の未来
音声は普遍的なインターフェースになるはずだった。しかし今日、会話が予測可能な場合にしかうまく機能しない。
だが、台本のない会話が無限の可能性を持つわけではない。どのターンでも、理にかなった行動は少数だ。話す、待つ、尋ねる、実行する、引き継ぐ。誰も台本に書けないのは、その順序である。会話を制御するために台本は要らない。実際に聴き取った内容から、一つひとつの判断を正確に下せばいいのだ。
私が賭けているのはこの転換だ。まず判断し、それからプロンプトを送る。聴くモデルが判断を下し、あなたのソフトウェアが状態を保持し、LLM が言葉を書く。すべての判断は可視化され、高速で、測定可能になる。これが実現すれば、音声は単純な通話のためのチャネルではなく、人がソフトウェアと対話する手段へと変わる。
私は @tazolabs でこの意思決定レイヤーを構築しており、今後数日で私たちのモデルについてさらに詳しく共有していく予定だ。
もしあなたが音声エージェントを開発しているなら、今どの判断でエージェントが苦戦しているかぜひ聞かせてほしい。そしてこのビジョンに共感してくれるなら、Tazo Labs で一緒に作ろう。
あなたの音声エージェントが最も頻繁に間違える判断は何だろうか？
