音声AIエージェントの応答速度を測る指標として、業界で最も注目されているのはTime to First Token（TTFT）である。しかし、この指標だけを見て推論APIを選ぶと、ユーザーが感じる「遅さ」を見誤る危険がある。TTFTは生成が開始された瞬間を示すに過ぎず、テキスト読み上げ（TTS）モデルは文節単位でしか音声を出力できない。その間には、エージェントが「会話している」と感じられるか、ユーザーが遮ってしまうかを分ける大きな差が存在する。本稿では、LLM、音声認識（STT）、TTS、そして音声対音声モデルまで、音声AIスタックの全レイヤーを横断したベンチマークデータを解説する。
TTFTが音声では不十分な理由
音声エージェントは、内部に言語モデルを搭載したレイテンシー予算である。各処理段階で消費されるミリ秒は、ユーザーが直接耳にする。TTFTは推論リクエストを送信してから最初のトークンが返ってくるまでの間隔を指す。IBMの定義でも、システムがアイドル状態から可視的にアクティブになる瞬間とされている。
チャット用途であればTTFTはほぼ全てを説明する。しかし音声では、それは総和の中の一要素に過ぎない。理由は機械的なものだ。TTSモデルは単語の途中から合成できない。完全な文節や文が揃って初めて音声を生成できる。この結果として重要な指標が、Time-to-First-Sentence（TTFS）である。LiveKitはGemma 4の導入記事で、TTFSこそユーザーが実際に体感する指標だと主張している。
つまりエンジニアリング上のツマミは二つある。TTFTは生成開始タイミングを制御し、トークン／秒は最初の文が完了する速度を制御する。一方だけを最適化しても、システムは高速に感じられない。
レイテンシーバジェットの全体像
LiveKitの音声エージェント概要によると、1ターンのレイテンシーはSTTが約100〜200ミリ秒、LLMがストリーミングで300〜500ミリ秒、TTSが100〜200ミリ秒、ネットワークがWebRTCで50〜150ミリ秒。実用的なエンドツーエンド目標は700ミリ秒〜1.2秒としている。
Pipecatの共同創設者であるKwindla Hultman Kramer氏は、800ミリ秒の中央値を音声対音声レイテンシーの目標に据えるよう助言しており、概念実証レベルでは1,500ミリ秒まで許容できるとしている。彼の概算では、この予算を輸送・メディア処理、STT＋発話終了検出、LLM推論、TTSの4つにそれぞれ約200ミリ秒ずつ割り振る。
Dailyの調査が示す人間の応答時間は約500ミリ秒。800ミリ秒を超える間は不自然に感じられ始める。Dailyの2026年2月のベンチマークは、この要件をLLMに直接翻訳している。自然な会話には音声対音声で1,500ミリ秒未満が必要であり、テキストモードのLLMを書き起こし→LLM→音声のパイプラインで使う場合、LLMのTTFT予算は約700ミリ秒と算出される。この700ミリ秒が、全てのプロバイダーを評価する基準となる。
ベンチマーク読み解きの5つのポイント
TTFTの数値を正しく解釈するには、以下の手法上の注意が必要だ。
1. ワークロードの形状が支配的：Artificial Analysisは2026年3月にデフォルトのワークロードを変更し、現在は1,000トークンではなく1万トークンの入力プロンプトを報告している。長いプロンプトはTTFTと出力速度の両方を押し上げる。LiveKitは、実際のエージェントがポリシー、ペルソナ、エスカレーションルール、検索結果、ツールスキーマを先頭に詰め込むため、この設定の方が現実に近いと主張している。
2. サーバー位置が数値に含まれる：Artificial AnalysisはGoogle Cloudのus-central1-aゾーンからテストしており、TTFTにはネットワークレイテンシーが含まれる。
3. 推論トークンも計測対象：推論モデルの場合、最初の推論トークンがTTFTの対象であり、回答トークンとは別に扱われる。
4. 受信側で計測する：Dailyは、モデルプロバイダーが自社の推論スタック内部のTTFTを公表するケースを指摘する。Dailyはリクエスト送信からAPIから最初の有効なトークンが届くまでを計測している。
5. 実行結果は再現可能とは限らない：TTFTはベンチマーク実行ごとに大きく変動し、プロバイダーはモデル名を変えずに推論スタックや重みを変更することがある。
LLM層：最速0.23秒の実力
以下の数値は、2026年8月30日時点のArtificial Analysis APIプロバイダーリーダーボードから取得した。ワークロードは1万入力トークン、単一プロンプト、72時間の中央値である。
最も低いTTFTを記録したプロバイダー
Basetenがgpt-oss-120b（high）で0.23秒という最速値を記録した。出力速度は266トークン／秒。同じBasetenのlow設定で0.24秒、DeepInfraのNemotron 3 Ultraが0.28秒、CohereのNorth Mini Codeが0.32秒、Command A+が0.40秒と続く。ModularのGemma 4 31B（NVFP4）は0.44秒、FireworksのNemotron 3.5 Lightningは0.46秒で出力速度501トークン／秒と高速だ。
スループットの罠
シリコンベンダーは音声エージェントとは異なる指標を最適化している。Cerebrasのgpt-oss-120b（high）はTTFT 0.49秒で出力速度1,697トークン／秒。Celeris-1は0.62秒で1,612トークン／秒。一方、InceptionのMercury 2はTTFTが3.07秒と、自然な会話に必要なLLM予算の4倍に達する。CerebrasやGroqはTTFTも出力速度も高いため、TTFSの観点では強力な選択肢となる。
フロンティアモデルとプロプライエタリエンドポイント
Amazon Bedrock上のGPT-5.6 Luna（非推論）は0.59秒、OpenAIの同じモデルは0.74秒。GoogleのGemini 3.7 Flash（low、AI Studio）は0.84秒、AnthropicのClaude 4.5 Haiku（非推論）は0.84秒。OpenAIのGPT-5.6 Sol（非推論）は1.06秒と、ホスティング環境とルーティングが重みと同等に重要であることを示している。
ベンダー実測値の特異点
LiveKitは自社の推論プロダクトでGemma 4 31BのTTFTが192ミリ秒と報告している。Gemini 2.5 Flashの911ミリ秒、GPT-5.5の966ミリ秒、GPT-4.1の1,006ミリ秒、OpenRouter経由の同じGemma 4 31Bの1,876ミリ秒を大きく下回る。LiveKitはこの仕組みについて透明性を確保しており、SGLangと投機的デコードを組み合わせ、GPUを意図的に過小パックすることでキューイング遅延を抑えている。ウォームリクエストでは約100ミリ秒でトークンを返し始めるとしている。トレードオフはコストで、100万出力トークンあたり1.20ドルだ。
同じ投稿では、会話全体のTTFSも報告されている。Gemma 4 31B on LiveKitが354ミリ秒、Gemini 2.5 Flashが1,034ミリ秒、GPT-4.1が1,088ミリ秒、Gemini 3.0 Flashが1,267ミリ秒、GPT-5.5が1,404ミリ秒。能力面では、Artificial AnalysisのIFBenchでGemma 4 31Bは75.6%、GPT-5.5は75.9%、GPT-4.1は43%、Gemini 2.5 Flashは39%と拮抗している。
STT層：発話終了検出が真の課題
音声におけるSTTのレイテンシーは、文字起こし速度ではなく、ユーザーが話し終えた瞬間からパイプラインがそれを認識するまでの時間で定義される。
各ベンダーの公称値は以下の通り。Deepgram Fluxはデフォルト設定で約260ミリ秒のend-of-turn検出、Nova-3はサブ300ミリ秒、AssemblyAI Universal-Streamingは約300ミリ秒、Cartesia Ink-2は100ミリ秒、Speechmatics Voice SDKは発話終了から最終結果まで0.451±0.022秒。
Deepgram Fluxは最もアーキテクチャ上興味深い。end-of-turn検出を認識モデルに統合しており、従来のSTT＋VAD構成と比較してエージェント応答レイテンシーを200〜600ミリ秒削減できるとしている。特にEagerEndOfTurnイベントは、LLMを早期に開始することを可能にし、予測が的中した場合にLLM TTFTをクリティカルパスから完全に外せる。
AssemblyAI Universal-Streamingは、部分書き起こしと最終結果のモデルを逆転させ、不変のトランスクリプトを出力する。同社は2025年の自社計測で、単語出力中央値が307ミリ秒（Deepgram Nova-3は516ミリ秒）だったと報告。音声エージェントには、フォーマットが後から届きLLMの動作をほとんど変えないため、未フォーマットのトランスクリプトを推奨している。
精度に関する主張はベンダー間で競合しており、実際の運用前に自社検証が必須である。LiveKitは部分書き起こしでLLMを開始する「先制生成」も文書化しているが、最終トランスクリプト後に再生成が必要になった場合、トークンを消費して効率が悪化するリスクがある。
TTS層：ベンダー公称値の落とし穴
ここが、ベンダーの公称値とユーザー体験が最も乖離する領域だ。
ElevenLabsはFlash v2.5のモデル推論時間を約75ミリ秒としている。ただし同社のドキュメントは、これがモデル推論時間のみであることを明確にしている。ネットワークラウンドトリップは地域に応じて通常20〜200ミリ秒、さらにほとんどのオーディオプレイヤーは再生前にバッファリングを行い、500ミリ秒のバッファが一般的である。v3はリアルタイム向けではなく、Agents PlatformではFlash v2.5、Flash v2、Multilingual v2を推奨している。
CartesiaはSonic-3.6とInk-2で、TTSがサブ90ミリ秒、トランスクリプトレイテンシーが100ミリ秒としている。ただしこれもベンダー表明のモデルレイテンシーであり、エンドツーエンドのラウンドトリップではない。Sonicはトランスフォーマーではなくステートスペースモデルを採用し、系列長に対して2次ではなく線形にスケールする点が特長だ。
品質面では、Artificial AnalysisのProvider Voice arena（ブラインドリスナーElo、2026年8月30日取得）で、Cartesia Sonic 3.6が1,288、SpeechifyAI Simba 3.2が1,243、Alibaba Qwen-Audio-3.0-TTS-Plusが1,243、ElevenLabs Flash v2.5が1,083と、低レイテンシー層の品質コストが明確に表れている。
音声対音声モデルの現実
音声対音声モデルはSTT、LLM、TTSを1パスに圧縮する。ラウンドトリップが減ればレイテンシーも下がるはずだが、LiveKitが注意している通り、すべてのケースで高速になるとは限らず、適切にチューニングされたパイプラインと十分競合できる。
Artificial Analysisの音声対音声リーダーボード（2026年8月30日取得）によると、TTFA（Time to First Audio）はDeepslate Opalが0.44秒で最速。Gemini 2.5 Flash Native Audio Dialogが0.63秒、Grok Voice Think Fast 2.0 Highが0.70秒（音声推論97%、タスク成功率94.7%）、OpenAI GPT-Realtime-1.5が0.81秒。OpenAIのGPT-Realtime-2.1は0.97秒で、タスク成功率89.4%。Grok Voice Think Fast 2.0 Highは0.70秒と高速でありながら高い精度を両立しており、このボード上で最もバランスの取れたモデルと評価できる。
推論努力のペナルティは同一モデルファミリー内で明確だ。Gemini 3.1 Flash LiveはMinimal設定で0.96秒、High設定で2.99秒。OpenAI GPT-Realtime-2.1はMinimalで0.97秒、Highで1.21秒、タスク成功率を2.1ポイント向上させる。OpenAIは2026年7月初旬にgpt-realtime-2.1とgpt-realtime-2.1-miniをリリースし、改善されたキャッシュによりRealtime音声モデルのp95レイテンシーを最低25%削減したと発表している。テールレイテンシーこそ電話エージェントが壊れたように感じる原因であり、中央値の改善よりも実用的な価値が高い。
能力差は依然として存在
Dailyのベンチマークは、なぜ多くのプロダクションエージェントがカスケードパイプラインを使い続けるかを定量化している。aiwf_medium_contextテストでGPT Realtimeは86.7%、GPT-4.1は94.9%だった。Ultravox 0.7は、Dailyの評価では複数ターンの長い会話で初めて良好なパフォーマンスを示した音声対音声モデルであり、オープンウェイトで利用できる。
Artificial Analysisはベンダー標準のカスケードシステム4つもベンチマークしており、Deepgram Voice Agent（Nova-3 + GPT-4o Mini + Aura-2）、ElevenLabs Agents（Scribe v2 Realtime + Gemini 2.5 Flash + Eleven Flash v2）、Cartesia Line（Ink + Gemini 2.5 Flash + Sonic）、Inworld Realtime（Inworld STT 1 + Gemini 2.5 Flash + Inworld TTS 1.5 Mini）の4つのうち3つがGemini 2.5 Flashを採用している点は示唆的だ。
実用的なレイテンシー予算
本稿の検証データから導き出した計画値として、2つのモデルケースを示す。
アグレッシブなカスケードパイプライン（米国ホスティング、コロケーション）：Transport/Mediaが50〜150ミリ秒、STT＋end-of-turn（Fluxデフォルト）が約260ミリ秒、LLM first chunk（サブ0.5秒層）が230〜500ミリ秒、文完了（250トークン／秒以上）が約100ミリ秒、TTS初回音声＋ネットワークが150〜300ミリ秒。合計は約790ミリ秒〜1.3秒となり、800ミリ秒目標にほぼ一致する。
音声対音声、単一モデル：Transport/Mediaが50〜150ミリ秒、モデルTTFA（最小推論層）が700ミリ秒〜1.0秒。合計は約750ミリ秒〜1.15秒でカスケードと同等だが、Dailyのベンチマークが示す通りツール呼び出しや指示追従において測定可能な能力差が存在する。
実装における7つの実践的アドバイス
- アーキテクチャが制約する指標を選ぶ：TTSモデルが下流にあるならTTFTではなくTTFSを最適化する。TTFTとトークン／秒を組み合わせて評価すべきである。
- モデル最適化より先にコロケーション：LiveKitはエージェントとモデルのコロケーションをモデル選択以上に重要と評価している。SIPを使う場合はトランクも地理的に近くに配置する。
- 推論努力を明示的に制限する：これは上のテーブルで最も大きな単一レバーであり、ほとんどのモダンなエンドポイントで設定が可能である。
- ツール呼び出しに予算を確保する：Kwindla氏は、ツール呼び出しを含むターンはLLMレイテンシーをほぼ2倍にすると指摘する。max_tool_stepsを制限し、外部API呼び出しを統合し、ユーザーへのフィードバックとして思考音を再生することを推奨している。
- チューニングより先に計装する：LiveKit Agents SDKはe2e_latency、LLM TTFT、TTS初回バイトまでの時間をターンごとに公開する。Pipecatもenable_metricsとオブザーバーで同等の機能を提供する。ログを外部保存し、回帰を監視する。
- p50だけでなくp95を計測する：OpenAIが2026年7月に改善したのはテールレイテンシーであり、音声エージェントが壊れるのはそこだからである。
- インフラの落とし穴に注意する：LiveKitは、AWSのt3やt4gのようなバースト可能インスタンスでセルフホストすると、CPU使用率が低く見えても深刻なレイテンシーや発話検出タイムアウトが発生する可能性を指摘している。
主要な発見
- 1万トークンワークロードで独立計測された最速の最初のチャンクはBasetenのgpt-oss-120b（0.23秒）、Artificial Analysis調べ。
- スループットとTTFTは異なる指標：Cerebrasは1,697トークン／秒だがTTFTは0.49秒、Inception Mercury 2は770トークン／秒でTTFT 3.07秒。
- ElevenLabsの75ミリ秒やCartesiaのサブ90ミリ秒といったベンダーのレイテンシー主張はモデル推論時間のみであり、ネットワークを除外している。
- 推論努力は最大のTTFTレバー：Gemini 3.1 Flash LiveはMinimalとHighで0.96秒から2.99秒に変動する。
- TTFT単独ではエージェントの体感速度を予測できない。音声合成には完全な文節が必要なため、Time-to-First-Sentenceこそが真の指標である。
