本記事の目的

以前、GPT-Live-1 によるコールセンターでのAIの今後の変化を技術的な面から考えた記事を記載させていただきました。

音声AIの技術動向と、GPT-Live-1 に STORM Platform の RAG を接続したデモも紹介しました。

今回は、その音声対話がどのような仕組みで成り立っているのかを、従来の STT → LLM → TTS という構成と比較しながら整理してみます。実装コードの紹介は別の機会とし、構成と会話の進め方に焦点を当てます。

音声AIの要素技術

音声AIと話すとき、私たちは回答の正しさだけを評価しているわけではありません。

話し終わってから返事が来るまでの間、言い直したときの反応、回答中に話しかけたときの振る舞い。そうした要素も、会話のしやすさに関わります。

では、この違いはどこから生まれるのでしょうか。

STT → LLM → TTS から Speech-to-Speech へ

音声AIを構築する方法の一つが、次のようにサービスやモデルを組み合わせる構成です。

この構成では、LLM が受け取るのは、基本的には STT が出力したテキストです。LLM が生成した回答もテキストであり、それを TTS が読み上げます。

OpenAI の公式ドキュメントでは、こうした構成を Chained voice pipeline として紹介しています。途中のテキストを確認・加工でき、各段階のコンポーネントを個別に置き換えられる点が特徴です。Voice agents

例えば、既存のテキストチャットに音声入力と読み上げを追加したい場合には、役割を分けて考えやすい構成です。

テキストを受け渡すことの意味

ここで注目したいのが、処理の途中で何を受け渡しているかです。

例えば、

「あ、それでお願いします」

という発話でも、即答しているのか、少し迷いながら答えているのかによって、会話上の受け取り方は変わります。

STT の出力テキストだけを次の処理に渡す場合、声の調子や細かな間が、そのまま伝わるとは限りません。そうした情報も利用したければ、別の情報として抽出・付加するなどの設計が必要になります。

また、LLM が生成した回答をどのような声やリズムで話すかは、後段の TTS が担います。

つまり、この構成では「聞き取る」「考える」「話す」を、それぞれの処理の境界で接続しています。

音声を直接扱う Speech-to-Speech

これに対して、今回ご紹介する GPT-Live を使用した方式は Speech-to-Speech といえます。Speech-to-Speech は、モデルが音声を直接入力として受け取り、音声で応答する方式です。概念的には、次のように表せます。

音声を直接扱う方式は、以前の記事で取り上げた OpenAI Realtime API でも採用されています。ここまでが音声の入出力方式の話です。

Speech-to-Speech では、アプリケーション側で独立した STT・LLM・TTS を順につなぐ構成とは、音声対話を組み立てる単位が異なります。

なお、この図は入出力の関係を示す概念図です。モデル内部で一切テキストを扱わない、という意味ではありません。

違いは「処理が三つから一つになる」だけではない

比較すると、次のように整理できます。

観点	STT → LLM → TTS	Speech-to-Speech
基本構成	音声認識・回答生成・音声合成を接続	モデルが音声入力と音声出力を扱う
処理間の受け渡し	テキストが中心	音声を直接扱う
調整する単位	各段階を個別に調整できる	音声対話モデルと周辺処理を調整する
設計時の注目点	各処理の品質と、処理間の接続	音声対話の振る舞いと、外部処理との接続

待ち時間についても、単純に処理段階の数だけでは決まりません。

STT → LLM → TTS でも、ストリーミングを使って処理を部分的に重ねる設計は可能です。そのため、「従来構成では、すべての処理が完了するまで何も返せない」という理解は正確ではありません。

比較するときには、発話終了の判断、回答生成の開始、音声再生の開始を分けて考えると、どこで待ち時間が発生しているのかを整理しやすくなります。

Speech-to-Speech から、同時に聞いて話す対話へ

ここまでの話は、音声をどう入力し、どう出力するかという構成の違いです。

もう一つ考えたいのが、AIが話している間も、ユーザーの発話を扱えるかという点です。

GPT-Live-1 は、聞くことと話すことを同時に行う Full Duplex（全二重）の音声モデルです。会話を担当しながら、必要な推論やツール利用をバックエンドへ委任できます。

ここでは、二つの言葉を分けて考えると理解しやすくなります。

Speech-to-Speech：音声を入力し、音声で応答する方式
Full Duplex：聞くことと話すことを同時に行う性質

また、双方向に音声を送受信できる通信方式を使うことと、モデルが同時に聞きながら話すことも、区別する必要があります。

GPT-Live-1 では、ユーザーの発話、AIの音声、バックエンドの処理が時間的に重なりながら進みます。会話を、きれいに交互に並んだ発話だけで捉えないことがポイントです。

会話の場面で考える ― 言い直し・割り込み・沈黙

仕組みの違いを、具体的な会話の場面に置き換えてみます。以下は、比較のための会話例です。

話している途中で言い直す

ユーザー：「配送先を自宅に……あ、今回は会社に変更したいです」

この場合、最初に出てきた「自宅」だけで処理を進めると、意図と違う結果になります。

STT → LLM → TTS の構成では、途中の認識結果をいつ確定し、どの時点で LLM や業務処理に渡すかが設計の論点になります。

GPT-Live-1 を使う場合も、言い直しを受けて、バックエンドに渡す依頼や進行中の処理をどう更新するかは重要です。会話が自然につながることと、業務処理が正しく更新されることは、それぞれ確認する必要があります。

AIの回答中に質問を変える

AI：「手続きには、まず契約者番号と……」
ユーザー：「すみません、番号が分からない場合はどうすればいいですか？」

ここでは、AIの音声を止めることに加え、追加された質問に応じて回答の内容を変える必要があります。

GPT-Live-1 では、割り込み時に話を譲る振る舞いを指示できます。ただし、指示すれば必ずその瞬間に停止するというものではなく、実際の声や会話条件で確認する必要があります。

少し考えながら話す

ユーザー：「契約したのは……ええと……去年の春だったと思います」

発話の途中にある沈黙は、話し終わりとは限りません。

早く応答しようとすると、まだ考えているユーザーの話を遮ってしまうことがあります。一方、待ちすぎれば、反応がないように感じられます。

音声AIを評価するときには、回答開始までの時間に加えて、こうした場面で待ち方が適切かも見ていきたいところです。

RAGと接続すると、会話設計はどう変わるか

コールセンターの問い合わせでは、会話を続けることに加えて、FAQやマニュアルなどの情報を参照する必要があります。

前回ご紹介したデモでは、その情報源として STORM Platform の RAG を接続しました。

GPT-Live-1 では、音声でのやり取りと、バックエンドで行う業務処理を分けて考えられます。既存のエージェントや処理フローをバックエンドとして利用する構成も可能です。

今回のような構成を概念的に表すと、次のようになります。

このとき考えるのは、「何を検索するか」だけではありません。

ユーザーが説明している途中で検索に十分な情報がそろったら、検索を始めるのか。その後に条件が追加されたら、検索し直すのか。検索結果を待つ間には、何を伝えるのか。

例えば、「確認します」と応対することと、検索結果に基づいて回答することでは、必要な情報が異なります。検索が終わっていない段階で、確認できたかのように話さない設計も必要です。

前回のデモで触れた「先回りして検索する」という動きも、こうした会話と検索のタイミングに関わる部分です。

検索自体の速度に加えて、検索処理を会話のどこに組み込むかが、利用者の感じる待ち時間に関わってきます。

実際の会話で確かめる

今回は、STT → LLM → TTS と Speech-to-Speech の構成の違い、そして GPT-Live-1 の Full Duplex による対話について整理しました。

ただ、言い直したときの反応や、話しかけるタイミングが重なったときの会話の続き方は、文章や構成図だけでは伝えきれない部分があります。

今回ご紹介した GPT-Live-1 を使用した音声対話デモは、2026年11月12日（木）・13日（金）開催の「コールセンター/CRM デモ＆コンファレンス 2026 in 東京」　にて、ログイット株式会社様のブース内で、STORM Platform とともに展示する予定です。CCCRM 2026

会場では、実際にデモと会話していただけます。

途中で質問を変えたり、少し考えながら話したりしながら、音声AIとの会話の感触を確かめていただければと思います。

STORM Revelation（仮）

展示予定のデモ画面もご紹介します。以下は、会話画面と会話要約の画面例です。

会話画面

会話画面では、実際の双方向の音声をテキストで確認し、RAGの検索タイミング・内容も確認できます。

会話要約

Full Duplex による対話とは別の観点ですが、コールセンターでの活用では、会話履歴を振り返れることも重要です。プロンプトやRAGの改善、顧客満足度の分析に役立てられるよう、会話内容を参照しやすい形で整理しています。