音声AIの遅延はどこで発生する？STT・LLM・TTSのレイテンシを分解！

皆さんこんにちは。
感情豊かな音声合成技術を誰もがかんたんに活用できる未来を目指す、Aivis Projectです✨

音声AIを作ってみると、ほぼ確実にぶつかるのが「返事が遅い」という問題です。

厄介なのは、ユーザーが感じている待ち時間の中に、話し終わりの判定、音声認識、LLMの推論、外部ツールの実行、音声合成、通信、デコード、再生バッファといった複数の処理が隠れていることです。

そのため、TTSを高速なサービスに替えても、ボトルネックが別の場所にあれば大きな改善は得られません。
反対に、音声合成そのものは速くても、クライアント側のバッファリングによって再生開始が遅れることもあります。

この記事では、音声AIのレイテンシを工程ごとに分解し、何を、どの時刻で測り、どの順番で改善すべきかを、実装に落とし込める粒度で解説します📚

【結論】見るべきなのは「合計」だけではなく、最初の音までのクリティカルパス

音声エージェントを単純化すると、次の順番で動きます。

ユーザーの発話
  ↓
VAD・エンドポイント判定
  ↓
STT（音声認識）
  ↓
LLM・RAG・外部ツール
  ↓
TTS（音声合成）
  ↓
通信・デコード・再生バッファ
  ↓
最初の音が聞こえる

ただし、ストリーミング構成では、これらが完全な直列になるとは限りません。たとえば、ユーザーが話している間にSTTを進めたり、LLMが返答全文を作り終える前に、完成した一文だけをTTSへ渡したりできます。

したがって、改善対象は各工程の処理時間を単純に足した数字ではなく、ユーザーの発話終了から、最初の音が実際に鳴るまでのクリティカルパスです。

最初の音までの時間 ≒
   エンドポイント判定
 + STTの確定待ち
 + LLMが読み上げ可能な最初のまとまりを返すまで
 + TTSが最初の音声を返すまで
 + クライアントがデコード・再生を始めるまで

⚠️ 最も時間を使っている工程から直すのが基本です。
ただし、その工程を短縮すると別の工程が次のボトルネックになります。
改善するたびに計測し直してください。

【指標】「レイテンシ」をひとつの数字で扱わない

レイテンシを正しく議論するには、少なくとも次の指標を分けて記録します。

End-to-End Latency

ユーザーの発話が終わってから、返答音声が実際に鳴り始めるまでの時間です。ユーザー体験に最も近い指標ですが、この数字だけでは遅い工程を特定できません。

LLMのTTFTと「最初の読み上げ可能なまとまり」

TTFT（Time to First Token）は、LLMへリクエストしてから最初のトークンが届くまでの時間です。

ただし、最初の1文字が届いても、そのまま音声合成には渡せません。日本語では、助詞や文末表現が出るまで意味や読み方が安定しない場合があります。音声AIではTTFTに加えて、最初の文・節・意味のまとまりが完成するまでの時間を測る必要があります。

TTSのTTFA

TTFA（Time to First Audio）は、TTSへリクエストしてから最初の音声データを受け取るまでの時間です。

ここでも、次の3つは別物です。

・HTTPレスポンスヘッダーが届いた時刻
・最初の音声チャンクが届いた時刻
・デコード可能なデータがたまり、実際に再生が始まった時刻

最初のチャンクが届いても、プレイヤーが再生開始に必要な量をバッファする場合があります。TTFAが短いのに音が出ないなら、TTSより後段を疑ってください。

Total Generation Time

音声全体の生成と受信が完了するまでの時間です。ファイル生成では重要ですが、ストリーミング再生の体感速度とは分けて評価します。

RTF（Real-Time Factor）

RTFは、音声の長さに対して生成処理にどれだけ時間がかかったかを示します。

RTF = 音声の生成時間 ÷ 生成された音声の長さ

たとえば、10秒の音声を2秒で生成できればRTFは0.2です。RTFが1未満なら、計算上は再生速度より速く生成できています。

ただし、RTFが小さくても最初のチャンクが遅ければ、話し始めは遅く感じます。反対に、TTFAが短くても途中の生成が再生に追いつかなければ、音切れが発生します。開始時の速さと、再生を維持できる速さの両方が必要です。

【工程1】VADよりも「話し終わりの確定」に時間がかかる

VAD（Voice Activity Detection）は、入力音声から人の発話区間を検出します。しかし、VADが無音を検出した瞬間に返答を始められるわけではありません。

システムは、その無音が次のどちらなのかを判断する必要があります。

・文章の途中で考えているだけ
・本当に発話が終わった

このエンドポイント判定には、一定時間の無音を待つ方式や、発話内容と韻律からターンの終了を推定する方式があります。

待ち時間を長くすると割り込みは減りますが、応答が鈍くなります。短くすると速く反応できますが、「ええと……」と考えている最中にAIが話し始める危険があります。

人間同士の質問応答を10言語で調べた研究では、話者交替の最頻値は質問終了後0〜200ミリ秒の範囲でした。ただし、これは人間同士の会話を観察した結果であり、そのまま音声AIの合格ラインになるわけではありません。電話受付、雑談、医療問診では、許容される待ち時間も割り込みのリスクも異なります。

VAD周辺で記録する時刻

・ユーザーが実際に話し終わった時刻
・VADが無音を検出した時刻
・システムが発話終了を確定した時刻

この差を分けると、認識や推論を始める前に待ちすぎていないかが見えるようになります。

プッシュトゥトーク方式なら、ボタンを離した時点を発話終了として扱えるため、VADの確定待ちを避けられます。自然なハンズフリー会話が必須でなければ、有効な選択肢です。

【工程2】STTは「最初の文字」と「確定結果」を分けて測る

STT（Speech-to-Text）は、音声をテキストへ変換する工程です。

ストリーミングSTTでは、ユーザーが話している最中から暫定結果を受け取れます。そのため、発話終了後に録音全体を送るバッチ方式より、後続処理を早く始めやすくなります。

ただし、暫定結果は後から修正されることがあります。たとえば、文末まで聞くことで固有名詞や同音異義語の認識結果が変わるケースです。

暫定結果をすぐLLMへ渡す場合の注意

暫定結果を使えば速く見えますが、認識内容が修正されたときに、すでに始めたLLMの処理を取り消す仕組みが必要です。訂正前の内容でツールを実行すると、予約日時や金額を誤る可能性があります。

したがって、実務では次のように処理を分けます。

・雑談や低リスクな案内 → 安定した暫定結果から先読みする
・予約、購入、本人確認 → 確定結果を待ち、重要項目は復唱する

速さだけでなく、誤認識によるやり直しまで含めて評価することが重要です。1回の応答を100ミリ秒縮めても、聞き間違いで会話が1往復増えれば、全体では大幅に遅くなります。

【工程3】LLMではTTFTより「最初の発話単位」を見る

LLMの遅延は、モデル推論だけで決まりません。

・入力コンテキストの長さ
・推論量やモデルの規模
・RAGで利用する検索処理
・データベースや業務APIへのアクセス
・直列に実行するツールの数
・返答の長さ

とくに外部ツールを複数回、順番に呼び出す構成では、ネットワーク往復が積み上がります。「LLMが遅い」と見えていても、実際には検索や業務APIが大半を占めていることがあります。

音声向けの返答を設計する

LLMの全文を待ってからTTSへ渡すと、返答が長いほど開始が遅れます。そこで、ストリーミング出力を次のように扱います。

LLMが最初の文を生成
  ├─ その文をTTSへ送る
  └─ 同時に次の文を生成し続ける

TTSが最初の文を音声化
  ├─ 受信できた部分から再生する
  └─ 次の文の音声を再生キューへ積む

ただし、1文字や数トークンごとにTTSへ送るのは逆効果です。リクエスト回数が増え、文章全体の韻律も作りにくくなります。

句点だけでなく、意味が完結する節や短い一文を単位にしてください。電話受付なら「承知しました。」を先に返し、その裏で検索を進める設計も有効です。ただし、処理が完了していないのに「予約できました」と断定するような先走りは避けます。

【工程4】Aivis Cloud APIのTTS遅延を正しく捉える

Aivis Cloud APIの音声合成には、次のエンドポイントを使用します。

POST https://api.aivis-project.com/v1/tts/synthesize

音声は、改行または対応するSSMLタグで区切られたセグメントごとに生成され、エンコードできたデータから順番にストリーミング配信されます。そのため、クライアント側で受信チャンクを順次デコーダーへ渡せば、音声全体の完成を待たずに再生できます。

⚠️ Aivis Cloud APIのリクエストボディに、ストリーミングを有効にするためのstreamパラメータはありません。APIレスポンス自体がストリーミングで返ります。Pythonのrequestsを使う場合のstream=Trueは、クライアント側でレスポンスを一括ダウンロードしないための指定です。

「最速0.3秒」の意味

現行のAPIドキュメントでは、GPUサーバーの混雑状況に応じたベストエフォート値として、次の生成性能を案内しています。

・2秒、15文字の音声を最速0.3秒以下で生成
・30秒、230文字の音声を最速0.7秒以下で生成

これはAivis Cloud APIへ音声合成リクエストを送ってから、音声AI全体が返答を始めるまでの保証値ではありません。VAD、STT、LLM、ネットワーク、クライアントのデコードや再生開始は別に加わります。また、混雑状況やモデル、入力テキスト、出力形式などによって変動します。

分割は細かすぎても、長すぎてもいけない

一行に長い文章をすべて入れると、その行の音声生成を待つ必要があるため、ストリーミングの効果が弱くなります。一方、短い語句ごとに細分化すると、推論のオーバーヘッドが増え、感情表現や声のつながりが不自然になりやすくなります。

Aivis Cloud APIでは、通常は1〜3文程度をひとつの目安としつつ、意味的につながる文章は段落や文脈の区切りまで一行にまとめることをおすすめしています。なお、一行が200文字を超える場合は、200文字境界の前後50文字以内にある文末記号などを探して自動分割します。

低遅延化では、単に短く切るのではなく、最初に読ませる一文は短く、その後は自然さを保てるまとまりにするのがポイントです。

先頭の無音を調整する

leading_silence_secondsは、生成音声の先頭に付ける無音時間です。既定値は0.1秒で、0.0〜60.0秒の範囲で指定できます。

ストリーミング再生で反応を早く感じさせたい場合は、0.0を指定すると先頭の無音を削除できます。

{
  "model_uuid": "YOUR_MODEL_UUID",
  "text": "お待たせしました。確認結果をご案内します。",
  "output_format": "mp3",
  "leading_silence_seconds": 0.0
}

これは推論自体を高速化する設定ではありません。音声データの先頭にある無音を減らし、最初の発声を早める設定です。

【工程5】通信・デコード・再生バッファにも遅延がある

TTSから最初のチャンクが返った時点では、まだユーザーの耳に音は届いていません。

その後に、次の処理があります。

・ネットワーク経由で音声チャンクを受信する
・コーデックをデコードする
・再生開始に必要な量をバッファへためる
・ブラウザやOSのオーディオ出力を開始する

バッファを小さくすると再生開始は早まりますが、通信の揺らぎによって音切れしやすくなります。大きくすると安定しますが、再生開始が遅れます。

見るべきなのはバッファのバイト数だけではありません。圧縮形式やビットレートによって、同じバイト数に含まれる再生時間が変わるため、「何ミリ秒ぶんの音声を先読みできているか」で管理するほうが実態に合います。

出力形式は再生環境から選ぶ

Aivis Cloud APIは、WAV・FLAC・MP3・AAC・Opusに対応しています。

・MP3：ブラウザやOSとの互換性が高く、ブラウザでのリアルタイム再生の基本候補
・Opus：圧縮効率と低遅延性を重視する場合の候補。ただしApple製品では対応OSの確認が必要
・AAC：iOS対応を含め、圧縮効率とストリーミングを両立したい場合の候補
・FLAC：無劣化を保ちながら、WAVより転送量を抑えたい場合の候補
・WAV：無圧縮で高品質だがファイルサイズが大きく、Aivis Cloud APIのストリーミングWAVはRIFFヘッダーのデータサイズが未設定になるため、厳密な一部のプレイヤーでは扱えない場合がある

ブラウザで迷った場合は、まずMP3で実装し、必要に応じてOpusやAACを実機検証してください。コーデック単体の理論値ではなく、対象ブラウザ・端末で再生が始まるまでを測ることが重要です。

【測定】1回のリクエストではなく、イベント時刻を記録する

最低限、1ターンごとに次の時刻を同じトレースIDへ記録します。

speech_end_actual       ユーザーが実際に話し終わった
endpoint_committed      システムが発話終了を確定した
stt_first_partial       STTの最初の暫定結果が届いた
stt_final               STTの確定結果が届いた
llm_request_started     LLMへリクエストした
llm_first_token         LLMの最初のトークンが届いた
llm_first_speakable     最初の読み上げ可能な文・節が完成した
tts_request_started     TTSへリクエストした
tts_headers_received    TTSのレスポンスヘッダーが届いた
tts_first_chunk         最初の音声チャンクが届いた
playback_started        クライアントで実際に再生が始まった
playback_finished       返答音声の再生が終わった

この粒度なら、「VADの待ちすぎ」「STTの確定待ち」「LLMの初動」「文分割の待ち」「TTSの初回音声」「プレイヤーのバッファ」を切り分けられます。

Aivis Cloud APIの最初のチャンクを測る

次の例は、リクエスト開始、レスポンスヘッダー受信、最初の音声チャンク受信、全データ受信完了を分けて計測します。

import os
from time import perf_counter

import requests

API_KEY = os.environ["AIVIS_API_KEY"]
MODEL_UUID = os.environ["AIVIS_MODEL_UUID"]

started_at = perf_counter()

with requests.post(
    "https://api.aivis-project.com/v1/tts/synthesize",
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    },
    json={
        "model_uuid": MODEL_UUID,
        "text": "お待たせしました。確認結果をご案内します。",
        "output_format": "mp3",
        "leading_silence_seconds": 0.0,
    },
    stream=True,
    timeout=(5, 60),
) as response:
    headers_at = perf_counter()
    response.raise_for_status()

    first_chunk_at = None
    total_bytes = 0

    for chunk in response.iter_content(chunk_size=16 * 1024):
        if not chunk:
            continue
        if first_chunk_at is None:
            first_chunk_at = perf_counter()
        total_bytes += len(chunk)

    completed_at = perf_counter()

print(f"レスポンスヘッダーまで: {headers_at - started_at:.3f} 秒")
print(f"最初のチャンクまで:     {first_chunk_at - started_at:.3f} 秒")
print(f"全データ受信まで:       {completed_at - started_at:.3f} 秒")
print(f"受信サイズ:             {total_bytes:,} bytes")

time.time()ではなくperf_counter()を使うのは、処理時間の計測に適した単調増加時計だからです。

⚠️ このコードで測れるのは最初の音声チャンクを受信するまでです。実際の再生開始を測るには、ブラウザならplayingイベントなど、利用する再生ライブラリが通知する時刻も別に記録してください。

平均だけで判断しない

本番環境では、平均値だけでなく次の分位点を確認します。

・p50：半数のリクエストがこの時間以内に収まる
・p95：95%のリクエストがこの時間以内に収まる
・p99：99%のリクエストがこの時間以内に収まる

平均やp50が速くても、p95・p99が大きいと、一部のユーザーは繰り返し遅さを感じます。コールドスタート、回線品質、長い会話履歴、外部ツールの遅延などを、遅いトレースから調べてください。

【診断】症状から遅い場所を絞り込む

話し終わってから処理開始までが遅い

VADまたはエンドポイント判定が待ちすぎています。speech_end_actualとendpoint_committedの差を確認します。

LLMの最初のトークンは速いのに、TTS開始が遅い

文分割器が長い区切りを待っている可能性があります。llm_first_tokenとllm_first_speakableの差を確認し、短くても意味が完結する最初の発話単位を設計します。

TTSの最初のチャンクは速いのに、音が出ない

デコードまたは再生バッファが原因です。tts_first_chunkとplayback_startedの差を、ブラウザ・OS・出力形式ごとに比較します。

会話の途中から遅くなる

会話履歴が長くなり、LLMの入力処理が増えている可能性があります。コンテキスト長、キャッシュ利用状況、検索結果の量を確認します。

最初の1回だけ遅い

モデル、接続、コンテナ、TLSセッションなどの初期化が疑われます。初回と2回目以降を別集計し、必要なら起動後のウォームアップや接続再利用を検討します。

再生中に音が途切れる

TTFAではなく、生成速度・通信・バッファの問題です。RTF、受信間隔、バッファ残量、アンダーラン回数を確認します。

【改善手順】効果の大きい順ではなく、計測結果の大きい順に直す

環境によってボトルネックは変わるため、「必ずLLMから」「必ずTTSから」とは決められません。次の手順で進めます。

1. End-to-End Latencyを定義する

開始点を「ユーザーが実際に話し終わった時刻」、終了点を「音声チャンク受信」ではなく実際の再生開始にそろえます。

2. 各境界へタイムスタンプを入れる

VAD、STT、LLM、ツール、TTS、プレイヤーを同じトレースIDで追えるようにします。サービスごとのログ時刻がずれている場合は、時計同期にも注意してください。

3. p95のクリティカルパスを確認する

平均的な1件ではなく、遅い5%のトレースを見ます。外部ツールだけが遅いのか、全工程が少しずつ遅いのかを判別します。

4. ひとつ変更し、再計測する

モデル変更、プロンプト短縮、文分割、コーデック変更を一度に行うと、何が効いたか分かりません。変更前後を同じ条件で比較します。

5. 品質指標と一緒に評価する

VADを短くしたら割り込み率、STTを先読みしたら訂正率、文を短くしたら音声の自然さ、バッファを減らしたらアンダーラン率も確認します。

速くなった代わりに会話が壊れた状態は、改善ではありません。

【本番運用】低遅延だけでは足りない

割り込み時は、生成と再生の両方を止める

ユーザーがAIの発話中に話し始めた場合、LLMやTTSの生成を止めるだけでは不十分です。クライアントの再生キューに残っている音声も破棄しないと、AIが話し続けます。

記録上の会話履歴も、実際にユーザーが聞いた範囲と一致させる必要があります。未再生の文章まで「発話済み」として履歴へ残すと、次の応答が不自然になります。

ストリーミング途中の再試行は重複に注意する

音声の途中で接続が切れたとき、同じ文を最初から再試行すると、聞き手には同じ内容が二重に再生されます。

文や節ごとにセグメントIDと順序番号を持たせ、どこまで再生済みかを管理してください。受信済みではなく、再生済みの位置を基準にするのがポイントです。

バックプレッシャーを設計する

LLMが文章を作る速度、TTSが音声を生成する速度、プレイヤーが再生する速度は一致しません。

生成が再生より速い場合は、音声キューが増え続けます。割り込まれたときの破棄量も大きくなります。反対に生成が遅い場合は、バッファが尽きて音切れします。

キューへ上限を設け、一定量を超えたらLLMやTTSへの投入を待たせる仕組みを用意してください。

レイテンシとエラー率を同じ画面で見る

タイムアウトを短くすると見かけ上のレイテンシは改善しても、失敗率が上がることがあります。本番では次を一緒に監視します。

・End-to-End Latencyのp50・p95・p99
・工程ごとのレイテンシ
・音声のアンダーラン回数
・割り込みから停止までの時間
・STTの訂正率や再質問率
・HTTPエラー、タイムアウト、再試行率

最終的な目的はベンチマークの数字ではなく、ユーザーが待たされず、聞き返さず、途中で切れない会話を作ることです。

よくある質問（FAQ）

Q. 目標レイテンシは何秒に設定すればよいですか？

一律の正解はありません。雑談、問い合わせ、本人確認など用途によって、速さと割り込み防止、正確さの優先順位が変わります。まず現在値を測り、実際の利用者による会話テストで許容範囲を決めてください。

Q. LLMの出力は何文字ごとにTTSへ渡せばよいですか？

固定文字数だけで切る方法はおすすめしません。句点、節、意味の完結、固有名詞の途中ではないことを見て分割します。最初の発話だけ短くし、以降は自然な韻律を保てるまとまりにする設計が扱いやすいです。

Q. 開発環境では速いのに、本番だけ再生開始が遅くなります。

中継するAPIサーバー、リバースプロキシ、CDNなどがレスポンスをバッファし、一定量がたまるまでクライアントへ転送していない可能性があります。各区間の最初のチャンク到着時刻を記録し、どの境界で止まっているか確認してください。

Q. ブラウザからAivis Cloud APIを直接呼び出せますか？

音声合成APIは、ブラウザ上のJavaScriptから直接利用できるようクロスオリジンアクセスを許可しています。中継サーバーを省けば遅延を減らせますが、ブラウザへAPIキーを持たせる設計には漏洩リスクがあります。公開範囲や利用者を踏まえて判断してください。

Q. レイテンシ計測に生成音声を保存する必要はありますか？

時間計測だけなら必須ではありません。ただし、文分割やバッファ調整による音切れ、重複、韻律の変化を検証する場合は、テスト環境で音声とトレースIDを対応づけて保存すると原因を追いやすくなります。保存期間やアクセス権限は、扱うデータの方針に合わせて設計してください。

Q. Speech-to-Speechなら遅延の計測は不要ですか？

必要です。Speech-to-SpeechではSTT・LLM・TTSの境界が外から見えにくくなりますが、発話終了、最初の音声、再生開始、割り込み停止などのEnd-to-End指標は測れます。内部工程が見えない分、ユーザー視点のイベント計測がより重要です。

まとめ

遅延の改善は、速そうな部品へ交換することではありません。

ユーザーが待っている区間を観測し、最も長い区間を短くし、もう一度測る。この繰り返しです。

Aivis Cloud APIをTTSとして組み込む場合も、最初の音声チャンクだけで評価を終えず、実際の再生開始までを含めて確認してください。
音声AI全体をひとつのパイプラインとして捉えることで、体感速度と安定性を両立しやすくなります✨

以上で、この記事はおしまいです。
Aivis ProjectやAivis Cloud APIに関してご不明点やご相談がある場合には、お問い合わせフォームよりお気軽にご連絡ください。

🔗 関連リンク

・Aivis Cloud APIドキュメント: https://api.aivis-project.com/v1/docs
・Aivis Cloud API: https://aivis-project.com/cloud-api/
・リアルタイム音声合成デモ: https://api.aivis-project.com/v1/demo/realtime-streaming
・AivisHub（音声合成モデル共有）: https://hub.aivis-project.com