自宅で動かしている音声AIアシスタントは、対話とコード開発でモデルを分けた話を書いた同じやつだ。今度は読み上げ(TTS)側を触った。

きっかけはiOSネイティブアプリでSTT(音声認識)をブラウザのWeb Speech APIからiOS標準のオンデバイス認識に変えたこと。ネットワーク往復が消えて、聞き取りの確定が速くなった。そうなると今度は、TTSの遅さが相対的に目立つようになった。実測すると、非キャッシュ時で470〜570ms、短い一文でこれだけかかっていた。

それまで使っていたのはedge-tts。Microsoft Edgeの読み上げ機能を流用した非公式ルートで、無料だがSLAはない。ja-JP-KeitaNeural、レートは+20%で運用していた。

まず検討したのがAzure Speech(公式)とAmazon Polly、そしてElevenLabsの3つ。Azureはedge-ttsと同じ声質・同じレイヤーなので、公式契約になるだけで速度向上はほぼ見込めない。Pollyは当時「安定しているが最速ではない」という位置づけで見送った。ElevenLabsはFlash v2.5というモデルが推論レイテンシ約75msをうたっていて、速度優先ならここ一択に見えた。

7/7、ElevenLabsに乗り換えた。edge-ttsをフォールバックに残し、3回連続失敗で60秒間ElevenLabsへの試行を止めるサーキットブレーカーを挟んだ。発音辞書とキャッシュ機構はそのまま流用できたので、変更はTTSエンジン呼び出し部分に閉じた。フロントエンドとiOSアプリ側は無改修。

最初に選んだ声(Adam、英語ネイティブの男声)は、多言語モデル経由で日本語を読ませると発音と強調が文脈とズレる違和感があった。翌日、日本語ネイティブの声(Asahi)に切り替えた。

実測では、ElevenLabsは文字数が伸びてもレイテンシがほぼ横ばいだった。18字で304ms、57字で323ms、90字で349ms。一方edge-ttsは文字数に比例して伸び、30字で約500ms、長文だと700msを超える。短い相槌はほぼ互角、1文以上になるとElevenLabsが優位という結果だった。

ここでedge-tts時代に付けていた+20%のレート感が、ElevenLabsには引き継がれていないことに気づいた。ElevenLabsのAPIには話速パラメータ(voice_settings)があるので、環境変数ELEVENLABS_SPEED(既定1.1、許容範囲0.7〜1.2)を追加してこれを埋めた。

そしてもう1日経った7/8、3つ目の選択肢だったAmazon Pollyを改めて測り直した。結果は18字で112ms、63字で213ms、99字で312ms。短文〜中文でElevenLabsもedge-ttsも上回っていた。

Pollyは声をTakumi(Neural)、リージョンは東京、話速は1.2倍にした。このマシンは既にAWS認証(SSM Hybridのcredential_process)が設定済みなので、新規のアカウント登録も契約も不要だった。初年度は実質無料。boto3の呼び出しは同期APIなので、asyncio.to_threadでオフロードしてある。

主系をPollyに切り替え、環境変数TTS_PROVIDERで3つのプロバイダを選べるようにした。edge-ttsは常時フォールバックとして残し、プロバイダごとに独立したサーキットブレーカーを持たせ、キャッシュキーにもプロバイダ・声・話速を織り込んだ。ElevenLabsとedge-ttsの実装はコードごと残してあるので、環境変数を書き換えるだけでいつでも戻せる。

2日で3段階乗り換えたことになる。速度だけを見るなら、最初からPollyを測っていればElevenLabsは経由しなくてよかったかもしれない。ただ最初の見立て(「Pollyは安定重視、最速はElevenLabs」)は検討時点では妥当な判断で、実測して初めて逆転が分かった。数字は都度測るしかない。

いまは主系がPolly、副系がedge-tts、ElevenLabsは設定を残したまま待機中。