AI音声モデル26種を実測：最速・高精度・自然な声で首位が分かれる理由

Cekuraのチームが、26種類のテキスト読み上げ（TTS）モデルを比較検証した。同一の米国東部クラウドリージョンからAPIを呼び出し、共通の英語通話文104文を各モデルに3回ずつ読み上げさせ、一括入力・単語ごとの逐次入力・割り込み（インタラプト）などの条件下で挙動を計測している。チームの報告によると、ベンチマーク全体で発行されたリクエストは延べ30,564回に上るが、これは各種テストの組み合わせによるものであり、3万本以上の異なる文章を読ませたわけではない。

各モデルでは、あらかじめ用意されたアメリカ英語の固定プリセット女性話者（ボイス）を1つ選択している。本検証は特定のAPI仕様、音声、ネットワーク環境下での比較であり、中国語を含む他言語や音声クローン（ボイスクローニング）へそのまま当てはめることはできない。

同じモデル群であっても、評価基準を変えると首位は入れ替わる。

• 文単位入力の遅延：Inworld TTS-2 Flashが最初の可聴音出力時間の中央値46ミリ秒で首位に立つ。
• 単語ごとのストリーミング入力遅延：Gradiumの中央値が−64ミリ秒となり、文の最後の単語が入力し終わる前にすでに発声を開始する「負の遅延」を示した。
• 数字・専門用語の読み上げ精度：Inworld TTS-2が93.4%に達し、Inworld TTS-2 Flash（93.2%）、Fish Audio S2.1-Pro（92.0%）とともにトップ集団を形成した。
• 音声の自然度（推定スコア）：Fish Audio Drama 3が4.54点（5点満点）でトップとなった。

今回の比較では、すべての指標で単独首位を獲得したモデルは存在しなかった。発声開始の早さ、電話番号を正しく読み上げる正確さ、声の自然さ、そしてユーザーの割り込み時にそれまでの音声をどう処理するかは、それぞれ求められる能力が異なる。音声Agentの選定にあたっては、自社のプロダクトがどの課題を最も避けたいのかをまず見極める必要がある。

同じ文でも入力方式が変われば首位が入れ替わる理由

文章をツールに渡して音声に変換する場合、全文を一度に送信できる。しかしリアルタイムの音声対話では、返答を生成しながら話す場面が一般的だ。大規模言語モデル（LLM）が次々とテキストを生成するなかで、Agentは生成済みの断片から順次TTSへと渡し、音声合成と後続テキストの生成を重ねて進められる。

今回のテストでは、2種類のテキスト入力方式が個別に用いられている。

1. 文単位の一括入力モード（Non-streaming）：クライアントが完全な文を一度に送信し、送信した瞬間から最初の可聴音が出現するまでの時間を計測する。Inworld TTS-2 Flashの中央値は46ミリ秒、Gradiumは76ミリ秒、Inworld TTS-2は126ミリ秒となった。実際のプロダクトでも、句点を機械的に待つのではなく、まとまったフレーズ単位で送信する設計が可能だ。
2. 単語単位のストリーミング入力モード（Streaming）：クライアントが単語ごとに順次送信し、テキスト全体の送信が完了する前からTTSが発声を開始できるようにする。今回のベンチマークでは毎秒30単語のペースを模擬して入力し、最後の単語を送信した瞬間から最初の可聴音までの時間を計測している。結果はGradiumが−64ミリ秒、Inworld TTS-2 Flashが45ミリ秒、ElevenLabs v4 Turboが69ミリ秒となった。毎秒30単語という設定はテスト用の仕様であり、LLMの固定的な生成速度を表すものではない。

散布図に含まれなかった8つのモデル（GPT-4o mini TTS、Gemini 3.8 Flash、ElevenLabs v3、Qwen3-TTSなど）は、今回のテスト対象となったAPI仕様および設定において単語単位のテキスト入力を受け付けなかった。これらのモデルが出力音声をチャンク単位でストリーミング返却できたとしても、それは「テキストの受信が完了する前に合成を始める」こととは異なる。この差異はアプリケーション側のパイプライン設計に直接影響するが、あらゆるデプロイ形態においてこれらのモデルが低遅延を実現できないと断定できるわけではない。

中央値だけでは、突発的にどの程度待たされるかまでは把握できない。P90（90パーセンタイル）はテスト全体の約9割が収まる待機時間の上限を示すが、残り1割の遅いリクエストはそれ以上の時間を要する。文単位入力における初音計測では次のような差が見られた。

• Inworld TTS-2 Flash：中央値 約46ミリ秒、P90 約73ミリ秒
• Smallest Lightning v3.1 Pro：中央値 約357ミリ秒、P90 約679ミリ秒

後者のP90は中央値の約2倍に達している。モデル選定時には、通常時のレスポンスだけでなく、処理が遅延したリクエストがどこまで引き延ばされるかを見極めることが重要となる。なお、P90自体も最大待機時間を示すものではない。

「−64ミリ秒」の正体：負の遅延はタイムトラベルか、それともフライングか？

「負の遅延」は計測の基準点（ゼロ点）の取り方によるものであり、モデルがまだ届いていないテキストを予知しているわけではない。

ストリーミング遅延計測における基準ゼロ点は、クライアントが文の「最後の単語」をTTSのAPIへプッシュした瞬間である。

例えば10単語からなる文を想定すると分かりやすい。最後の単語を送信した時刻を0とする。それまでに受信した手前のテキストですでに発声が始まっており、最初の可聴音がゼロ点より64ミリ秒早く現れた場合、−64ミリ秒として記録される。これは計測ロジックの説明例であり、ランキングの−64ミリ秒は複数回テストの中央値にすぎない。すべての文で一律にこれだけ前倒しされるわけではなく、モデルが何単語目を受け取った時点で推論処理を開始したかもここには現れない。

接続の準備や対話システム全体の所要時間も、これらの数値が持つ意味を左右する。

• 接続確立後に計測開始、ネットワーク往復は計測に含まれる：ハンドシェイク、認証、コンテキストの準備時間は除外されているが、クライアントがテキストを送信してから音声が返り、可聴音が出現するまでの往復時間は含まれている。したがって、ネットワーク環境が異なれば体感値も変わり得る。
• TTSの初音時間は対話プロセス全体の一部にすぎない：完全な音声対話には、発話終了の判定、音声認識、返答テキストの生成、プレイヤーによる再生出力といった工程が介在し、これらも並行して進む場合がある。46ミリ秒という値は、すでに接続が確立された条件下でテキスト全文を送信してから最初の可聴音が出るまでの区間を測ったものであり、ユーザーが話し終えてからAIが返答し始めるまでの総所要時間と同一視することはできない。

音声パケットの到着＝発声ではない：冒頭の無音という罠

音声インタラクションにおいて、APIから最初のデータパケットが返ってきた（TTFB: Time to First Byte）としても、人間の耳に音が聞こえているとは限らない。

返却された音声の冒頭には、可聴音の検出閾値を下回る低音量の区間が含まれている場合がある。最初のデータパケットの到着だけを記録すると、システム上は「応答済み」と表示されても、ユーザーの耳にはまだ声が届いていないこともある。

今回の検証では、最初の可聴音出現時間（TTFA: Time to First Audible Audio）を比較指標に採用している。まず音声チャンクの到達を記録し、その上で実際に声が始まるまでの微弱な音量区間を加算する。検出にあたっては、直流（DC）成分を除去した10ミリ秒の音声ウィンドウを1ミリ秒刻みでスライドさせ、二乗平均平方根（RMS）振幅がフルスケールの1%を初めて超えた位置を特定している。これは統一基準による機械的な検出ルールであり、個々のユーザーの聴力を測定したものではない。

文単位の入力テストにおいて検出された冒頭無音時間の中央値は以下のとおりだ。

• Deepgram Aura-2：223ミリ秒
• Cartesia Sonic 3.5およびSonic 3.6：それぞれ132ミリ秒、142ミリ秒
• Smallest Lightning v3.1 Pro：141ミリ秒

これらの数値は、音声データを受信することと最初の発話を聞き取ることは別個の事象であることを示している。文単位テストの無音時間の中央値をそのまま単語単位ストリーミングテストに当てはめて、同一録音の一連のフェーズであるかのように扱うことはできない。

自動精度スコアは何を測定しているのか？

音声アシスタントが電話番号を読み上げる際、流暢に聞こえるだけでは不十分で、数字そのものが正しくなければならない。住所を読む際にも、同じ略称が文脈によって異なる発音になることがある。

テストでは通話文内の難関フレーズに対して許容される読み方をあらかじめ定義し、以下の4つに分類している。

1. 数字と略記：例 7 a.m.、20%、36°F、approx.
2. コードと住所：例 クーポンコード SAVE20、メールアドレス help@north-clinic.org、フリーダイヤル 1-800-555-0199
3. 文脈に応じた略語の展開：例 St. Mary's on Main St.（前者のSt.はSaint、後者のSt.はStreet）、Dr. OkaforにおけるDr.（Doctorと展開すべきもの）
4. 難解な医療・医薬品用語：例 レボチロキシン levothyroxine、消化器病学 gastroenterology

これらの指定難関箇所の自動通過率は、Inworld TTS-2が93.4%、Inworld TTS-2 Flashが93.2%、Fish Audio S2.1-Proが92.0%、Fish Audio Drama 3が91.3%となった。これは一文全体を完全に誤りなく読めた割合ではなく、通話全体の成功率でもない。

このスコアがどのように算出されたかを知ることで、適切な活用法が見えてくる。

• 文字起こしを経てから難所を照合：合成された音声はDeepgram Nova-3とOpenAI Whisperの2つのASRシステムに送られ、文字起こし結果の中に許容された読みが含まれているかを判定する。番号やコード類はアルファベットや数字も照合される。音声認識側が聞き間違える可能性もあるため、これらはあくまで推定値である。
• 2つのASRで評価が割れることも：公開ページによると、同一モデルに対する正答率の推定値がASR間で最大10ポイント乖離するケースもあった。
• 上位の僅差は同率とみなす：ベンチマークでは、2ポイント以内の上位の差は同率として扱うことを推奨している。例えば93.4%と93.2%の差をもって、前者が明確に優れた体験を提供していると断定することはできない。
• 発声の早さと発音の正確さは別物：Gradiumはストリーミング遅延が最も短いものの、難所の通過率は79.5%にとどまる。一方、Inworld Flashは45ミリ秒で93.2%を記録している。これは2つの能力を個別に比較すべきであることを示しており、「早く発声しようとしたから読み間違えた」と証明するものではない。

発音の問題のなかには、文字起こしされたテキスト自体からは判定できないものもある。例えば「read」の現在形と過去形は発音が異なるが、文字起こし結果はいずれも「read」となる。元のコーパスでは、こうした項目を「音声の聴取が必要な項目」として個別に扱い、ここでの自動正答率の計算からは除外している。そのため、「文脈項目100%」という結果であっても、すべての同形異音語やアクセントが正しく発音されていると解釈することはできない。

また総合スコアは設問タイプごとの得手不得手を覆い隠してしまう。文字起こしで判定可能な項目のうち、Gradiumの文脈に応じた読みの正答率は約67%にとどまる一方、医療用語は約99%に達した。逆にInworld TTS-2は文脈項目が約100%だったのに対し、コードや住所は約86%だった。これらもまた文字起こしエンジンによるカテゴリ別推定値である。認証コードの読み上げが多いアシスタントであればコードや番号の正答率を重点的に検証すべきであり、医療用語のスコアが高いからといってすべての難所に対応できると思い込むのは禁物だ。

割り込みと再生途切れ：音色にとどまらないエンジニアリング体験

ユーザーが「ちょっと待って」と口を挟んだとき、どれほど魅力的な声であっても、それまでの話をそのまま喋り続けられれば対話の妨げになる。割り込み（インタラプト）の処理には、サーバー側の合成タスクの停止とクライアント側の再生制御の双方が絡む。

1. 割り込み機構のプロトコル上の実態

今回の「Stopping（停止）」指標が測定しているのは、キャンセルリクエストを送信した後に、再生可能な音声がなおどれだけ届いたかという「音声の長さ（再生時間）」である。キャンセル要求から最後のパケットが届くまでの経過時間（実時間）を測定したものではない。

• キャンセルAPIが利用可能なモデルの結果：Grok TTSとSonioxのキャンセル後余剰音声時間の中央値は0ミリ秒、Deepgram Aura-2は40ミリ秒、Cartesia Sonic 3.6は764ミリ秒だった。ここでの「0」は中央値であり、毎回必ず余計な音声が発生しないことを意味するわけではなく、通話環境全体が一瞬で無音になることを示すものでもない。
• n/aの背景にある仕様の違い：Gradium、Inworld、およびテスト対象のElevenLabs v3などは利用可能なキャンセルメッセージを持たない。一方、テスト対象のElevenLabs Flash v2.5、v4 Turbo、v4のクローズ制御は、送信済みテキストの音声をすべて出力し終えてからコンテキストを閉じる仕様となっている。いずれも「n/a」を「ゼロ」と同一視することはできず、完成したプロダクトでユーザーが割り込みできないことを意味するわけでもない。
• プレイヤー側での旧音声の即時破棄が不可欠：Agentはローカル再生を即座に停止し、不要になった音声を破棄した上で、APIの機能に応じて旧ストリームのキャンセル、クローズ、または破棄を行わなければならない。そうしなければ、バックエンドが送信を停止しても、バッファに残った音声が鳴り続ける可能性がある。

2. 再生バッファの枯渇（Playout stall / Underrun）

プレイヤーは一定量の音声を先読みバッファに蓄積してから、受信と並行して再生を行うことができる。これは給水しながら排水する貯水タンクに似ており、すでに十分な蓄えがあれば、一時的に供給が揺らいでも出口の水流が途切れるとは限らない。

しかし後続の音声が滞り、バッファが底をつくと、音声が途切れてしまう。したがって、最初の声が素早く出ることと、一文全体が途切れずに滑らかに再生され続けることは、別個の要求仕様である。

今回の文単位再生テストにおいて、ElevenLabs v4では測定文の約7%で音声供給がリアルタイム再生に追いつかず、v4 Turboでも約5%で発生した。これらの割合はテスト文章群全体に対するものであり、長文のみを対象とした結果ではない。

3. リクエストが正常に完了するかどうか

再生中の途切れに加えて、テストの規程に沿ってリクエストが正常終了したかどうかも確認する必要がある。公開スナップショットにおいて、GPT-4o mini TTSの関連合成記録936件中、52件がタイムアウトで終了していた。これは今回のAPI仕様と待機ルールに基づく記録であり、そのまま本番環境における長期的な障害率と見なすことはできない。

テストでは、APIキー、残高、クォータ、レートリミットによるアカウント起因の拒否は別途整理されており、サーバー側のタイムアウトと混同してはならない。またマルチステップテストで不合格となった場合でも、APIリクエスト自体のエラーとは限らない。例えばキャンセルの条件を満たせなかったケースを、単なるサービスタイムアウトとしてカウントすることはできない。

自然度の推定スコアと実際の試聴に向けたアドバイス

自然度の評価にはオープンソースモデル「UTMOS」が採用されており、文単位で生成された録音に対して人による聴取評価の平均スコア（1〜5点）を予測している。これは人間がどれほど自然に感じるかを機械的に推定したものであり、今回のランキングは人間の被験者による聴取評価で作成されたものではない。

Fish Audio Drama 3の予測スコアは4.54、Inworld TTS-2は4.52、Gradiumは4.51となった。上位3モデルの数値は僅差であり、0.02点の差をもってユーザーがどちらかを明確に好むと裏付けることはできない。

日常的な挨拶フレーズでイントネーションやポーズ（間の取り方）を比べ、続いて2つの「read」を含む文章を聴いて、異なる読み分けが再現されているか確認してみよう。プレイヤーには共通の入力原文と日本語訳を表示しているため、発音の違いはご自身の耳で直接確かめてほしい。

その他のボイスや評価用文章は、公式の同一文試聴ページで聴き比べることができる。

実装に向けたモデル選定の判断材料

今回のベンチマークは候補を絞り込むための手がかりとして活用し、その上で自社プロダクトの実文を用いて検証するのが適切だ。

1. 対話のテンポに追従できるかをまず確認する：GradiumとInworld TTS-2 Flashが低遅延の有力候補となる。同時に難関箇所の正答率も併せて確認し、発声の早さが自社の要件を満たす発音精度と両立しているかを確かめたい。
2. 番号・住所・専門用語を読み上げる頻度が高い場合：Inworld TTS-2（93.4%）、Flash（93.2%）、Fish Audio S2.1-Pro（92.0%）、Drama 3（91.3%）を候補としてテストを進めるとよい。実際の番号や固有名詞を実務の文脈に組み込んで聴取し、必要に応じて人手で照合する。なお、これらの英語での自動評価スコアは、中国語を含む他言語での信頼性を直接保証するものではない。
3. 音声合成のコストを比較する：今回のベンチマークにおける100万文字あたりの参考標準価格は、Soniox TTS RT v2が14.81ドル、Inworld FlashとGrok TTSが15ドルとなっている（Drama 3は価格未提供）。これらはランキングに記載されたベンダー公表価格または換算基準であり、音声認識、LLM、電話回線などを含んだ通話全体のコストではない。また単価の安さがそのまま高並行時の安定性を保証するわけではない。

絞り込んだ少数の候補に対しては、ターゲットとする言語と実際のネットワーク環境下で再測定を実施する。最初の一言が出るまでにどれだけ待たされるか、読み上げられた数字は合っているか、割り込み時に以前の音声がしっかり止まるか、ひとまとまりの発話が途切れず最後まで再生されるか、リクエストが正常に完了するか。ベンチマークのスコアが製品の実体験と結びつくのは、まさにこれらの確認を経てこそである。