AI電話システムの裏側 — 応答レイテンシとの戦い

人間同士の電話では、相手が話し終えてから自分が話し始めるまでの間隔——ターンの 切り替え——は数百ミリ秒しかありません。会話分析の研究では、 言語を問わずおおむね0.2秒前後が典型とされます。私たちはこのテンポに慣れきっているため、 電話口で1〜2秒の沈黙があるだけで「あれ、聞こえてますか？」が始まり、 相手がAIだと分かっていても「反応が遅い」「話しづらい」という印象になります。

つまり電話AIの品質は、回答の賢さと同じくらい応答までの速さ（レイテンシ）で 決まります。この記事では、AI電話システムの内部で遅延がどこで生まれ、 どう削るのかを、実装者の視点から解説します。ボイスボットが「使えない」と言われる理由の ひとつである「沈黙による離脱」の、技術的な裏側にあたる話です。

遅延はどこで生まれるのか — 直列パイプラインの積み上げ

オーソドックスなAI電話システムは、3つの処理の直列パイプラインでできています。

1. 音声認識（STT） — 利用者の音声をテキストに変換する
2. 応答生成（LLM） — テキストから返答の内容を組み立てる
3. 音声合成（TTS） — 返答テキストを音声に変換して再生する

各段にはそれぞれ処理時間がかかり、多くの構成では各段がネットワーク越しのAPIのため往復の通信時間も段数ぶん積み上がります。仮に1段あたり数百ミリ秒でも、 3段を素朴に直列でつなげば合計は1秒を超えてきます。さらに見落とされがちなのが、 パイプラインに入る前の段階——「利用者が話し終えた」と判定するまでの待ち時間です。

発話終端検知のジレンマ — 待てば沈黙、急げば食い気味

システムは、無音が一定時間続いたことなどを手がかりに「発話が終わった」と判定します （エンドポインティングと呼ばれます）。ここに本質的なジレンマがあります。

• 判定を待ちすぎると、その待ち時間がまるごと応答遅延に足され、 沈黙が長くなる。
• 判定を急ぎすぎると、考えながら話す人の「えっと……」の間で 発話が終わったと誤判定し、相手の話の途中で応答をかぶせてしまう。

住所や電話番号を思い出しながら話す場面では間が長くなり、相づちの場面では間が短い—— つまり最適な待ち時間は会話の文脈によって変わります。固定の無音時間だけで判定する 素朴な実装が電話で使いものにならないのは、このためです。

遅延を削る3つのアプローチ

① 各段のストリーミング化

最も効くのは、各段が全文の完成を待たずに結果を次段へ流し始めることです。 音声認識は話している途中から暫定テキストを出し、応答生成は文章を最後まで組み立てる前に 冒頭から出力し、音声合成は最初のひとかたまりが合成できた時点で再生を始める。 全体の所要時間は変わらなくても、利用者が「最初の音」を聞くまでの時間を 大きく前倒しできます。体感品質を決めるのは合計処理時間ではなく、この最初の音までの 時間です。

② パイプラインの統合（speech-to-speech）

さらに進んで、音声認識・応答生成・音声合成を一つのモデルで扱い、音声から直接音声を 生成するspeech-to-speech型のアプローチも実用化が進んでいます。 段間のテキスト変換と通信往復が減るぶん遅延を短縮しやすく、声のトーンのような テキスト化で失われる情報を扱える可能性もあります。業界全体として、 直列パイプラインからこの方向への統合が進みつつあります。

③ UX側の緩和策 — つなぎ言葉と相づち

技術で削り切れない遅延は、会話設計でカバーします。人間のオペレーターも、即答できない ときは「お調べしますので少々お待ちください」と言ってから調べます。同じように、 処理に時間がかかる場面では「かしこまりました、確認いたしますね」といったつなぎ発話を先に返すことで、無音を「応対中の間」に変えられます。 当社の開発でも、遅延をミリ秒単位で削る改善と、沈黙を沈黙と感じさせない会話設計の 両輪で品質を作っており、後者の効果は数値以上に大きいというのが実感です。

割り込み（バージイン） — 話をさえぎられたAIはどう振る舞うか

レイテンシと並ぶもう一つの難所が、AIの発話中に利用者が話し始める割り込み（バージイン）への対応です。人間なら自然に口をつぐんで 聞き役に回りますが、システムには次の処理が必要になります。

• 検知 — 再生中の音声に重なった利用者の発話をリアルタイムに検出する
• 再生停止 — 話しかけの検出後、即座に自分の発話を止める（遅いと「話を聞かないAI」になる）
• 文脈復帰 — 自分がどこまで話せたか・相手が何に反応したかを踏まえて会話を続ける

厄介なのはエコーの問題です。電話ではAI自身の発話が回線や相手側の スピーカーを経由してマイク側に回り込むことがあり、これを「利用者の割り込み」と 誤検知すると、AIが自分の声に反応して黙り込む、という珍現象が起きます。 エコーキャンセルと割り込み判定のチューニングは、電話AI開発の定番の泥沼です。 逆に、雑音を割り込みと誤検知しないためのしきい値を上げすぎると、今度は本物の 割り込みを無視してしまう——ここにも終端検知と同型のジレンマがあります。

電話網という制約 — ブラウザのデモと本番の違い

最後に、電話ならではの制約です。ブラウザのマイクで試すデモは高音質・低遅延の 理想環境ですが、実際の電話は違います。

• 8kHz帯域 — 従来の電話網は約8kHzの狭帯域で、高い周波数成分が 落ちた音声が届きます。音声認識の精度は理想環境より確実に下がります。
• コーデックによる圧縮 — 電話網で使われる音声圧縮は、人間の聞き取りには 十分でも、機械の認識にはさらなるハンデになります。
• パケットロスとジッタ — 音声データの一部欠落や到着間隔の揺らぎが、 音の途切れ・詰まりとして認識と応答タイミングの両方を乱します。

「デモでは賢かったのに、電話にしたら聞き取りが悪くなった」という導入後のギャップは、 多くの場合この電話網の制約が原因です。裏を返せば、実際の電話回線でどれだけ 自然に会話できるかが、そのサービスの実力そのものだと言えます。

まとめ — 見極めは「デモを電話で試す」こと

応答レイテンシは、どこか一箇所のボトルネックではなく、終端検知・各処理段・ ネットワーク・割り込み処理・電話網の制約まで含めた設計全体の総和です。 だからこそ資料のスペックだけでは分からず、導入検討では実際に電話をかけて会話してみることが最良の見極めになります。 沈黙の長さ、話をさえぎったときの振る舞い、聞き取りの正確さ——この記事で挙げた 観点で試せば、サービスの作り込みの深さはおおよそ判断できます。 アーキテクチャの選び方はシナリオ型 vs LLM自律思考型、 費用面の検討はAI電話代行の料金相場と導入効果の試算ページをあわせてどうぞ。