日本語ローカルTTSを12個試して Irodori TTS に出会うまで

前回は、棒立ちの3Dアバターに「まず頭脳から」とチャットを実装したところまで書きました。テキストを打つと、秘書が返事を返してくれる。それはそれで動く。でも、決定的に足りないものがありました。

無言なんですよね。

第1章で叫んだとおり、私が欲しかったのは「しゃべってほしい！！」でした。テキストが画面に出るだけでは、まだ「いる」感じがしない。というわけで、声を与えることにしました。これが、想像の3倍くらい沼でした。

まず、TTSは沼だった

ローカルで動く日本語TTSを、片っ端から試しました。数えたら12モデル。

評価軸は2つ。RTF（リアルタイムファクタ） と 日本語の品質 です。RTF は「実時間の何倍速で合成できるか」で、1.0x なら喋る長さと同じだけ合成に時間がかかる、つまり会話には遅すぎる。5x、10x と大きいほど速い。会話アシスタントは応答が遅いと一気に冷めるので、ここは死活問題でした。

結果がこれです。計測は手元の AMD AI Max 395+ 96GB。…NVIDIA じゃないので動かすだけで本当に苦労したんですが、その話は長くなるので別の記事に回します。

#	モデル	RTF	日本語	判定
1	Qwen3-TTS 1.7B	0.45x	A	品質最高だが遅い
2	Kokoro-82M	14.5x	C	速度1位、JP韻律課題
3	Piper	45.9x	F	日本語壊滅
4	MeloTTS	0.92x	C	RT未満で論外
5	F5-TTS	0.11x	F	Qwenより遅い+日本語壊滅
6	Spark-TTS	失敗	C-	長文で破綻
7	Chatterbox	0.54x	要確認	RT未満
8	KokoClone	0.84x	F	二重劣化で論外
9	PocketTTS	3.8x	F	英語のみ、JP対応待ち
10	Style-Bert-VITS2	5.1x	JP特化	速度2位
11	Qwen3-TTS 0.6B	0.34x	A	1.7Bよりむしろ遅い
12	vLLM-Omni+Qwen3	0.20x	A	CPU比2倍遅い

眺めて分かったのは、身も蓋もない法則でした。

• 品質トップの Qwen3-TTS（日本語A）は、軒並み RT 未満。0.45x。会話には遅すぎる。
• 速度トップの Kokoro(14.5x) や Piper(45.9x) は、日本語が壊滅。英語圏で評判のモデルほど、日本語を読ませると別物になる。
• F5-TTS に至っては「遅い うえに 壊滅」という、どこを褒めていいか分からない仕上がり。

速いやつは日本語がダメ、日本語がいいやつは遅い。きれいなトレードオフの壁です。唯一それなりに両立していたのが Style-Bert-VITS2（日本語特化・5.1x）でした。

…が、これも採用しませんでした。私が欲しかったものが、もう1つあったからです。

欲しかったのは、3つ

整理すると、要件はこうでした。

1. 声のクローンができる（自分の秘書に、特定の声をあてたい）
2. 手元のコンシューマGPUで動く（4090必須では困る）
3. 会話に耐える応答速度

この「声のクローン」が効きました。表で最有力だった Style-Bert-VITS2 を蹴ってでも、理想の声を自分で作りたかった。

そんなときに出会ったのが Irodori TTS でした。

Irodori TTS との出会い

結論から言うと、理想のTTSでした。声のクローンができて、コンシューマGPUで動いて、速い。3拍子そろっている。作者の方には感謝しかありません。

ここで私は腹をくくって RTX 3090(24GB) を買いました。AMD での苦労もあって、もう NVIDIA でいいや、と。

3090 での実測がこれです。

• 1文の合成：0.4〜0.7秒で 3〜5秒の音声
• 実時間倍率：約5〜10x faster-than-realtime（bf16、CUDA グラフは無効でこの速度）
• VRAM：Irodori 単体は常駐で約 3.7〜6GB

数字だけ見ると「3090いらないのでは？ 3060 12GB でも Irodori 単体なら乗るぞ」と思いますよね。私もそう思っていました。落とし穴は 同居 です。

秘書を動かすには、Irodori(TTS) だけでなく、頭脳の LLM(vLLM) と、後で足す耳の STT(kotoba-whisper) が同じGPUに乗ります。最初、欲を出して Qwen3-30B と同居させようとして、3回 OOM しました。30B は 24GB に同居できない。14B-AWQ(9.4GB) まで落として、ようやくコンパニオン全体＋vLLM で約 20GB に収まりました。24GB でギリギリ。3060 では足りない、が答えです。

声が、定まらない（シードの罠と声ガチャ）

声のクローンで最初にハマったのがこれです。

Irodori は参照音声なし(no_ref)＋シード指定でも声を作れます。なので最初は seed=777 で固定すればいつも同じ声になる、と思っていました。

ところが、同じ seed=777 なのに、テキストを変えると声が変わる。

調べると、no_ref ＋自動 duration の組み合わせだと、ノイズの形がテキストに依存してしまう。だから入力文ごとに微妙に別人になる。これでは「うちの子の声」が定まりません。

解決は地味な力技でした。参照音声(ref_wav) で固定する。シードをランダムに変えながら 100個くらい音声を生成して片っ端から保存 し、その中から「これだ」という1つを選んで Ref に採用しました。ファイル名は cool_seed_7777.wav。完全に声ガチャです。当たりを引くまで回しました。

ちなみに、後で作る「お休みモード」用には 別の Ref を用意しています。こっちは ささやき声 にしたかったんですが、これがなかなか出ずに苦労しました（Irodori v3 だと、真の囁きまでは届かない）。この話は、お休みモードの回でちゃんと書きます。

英語が、壊滅した

声が固まって喜んでいたら、次の壁が来ました。

英語がまったく読めない。

「GitHub」も「API」も、見るも無残な発音になる。日本語特化の宿命です。これは 読み方辞書 を自作して解決しました。固有名詞や英単語を「ギットハブ」のように登録しておくと、合成前に置換する仕組みです。

ただ、辞書は手動登録なので想定外の語に弱い。そこでもう一段、「誤読しそうな日本語を LLM に投げて、先回りでひらがなに直す」フィルタ も用意しました。合成の前にテキストを一度モデルに通して、難読語をかな書きに整える。ただしこれはチャットだと ひと手間ぶんレスポンスが遅くなる ので、リアルタイム性が要る会話では切っています。一方、日記の読み上げ のように多少待ってもいい場面では効果てきめんでした。

（ちなみに、このフィルタを噛ませる前から Irodori は読みがかなり賢くて、「今日は一月一日日曜日」を "いちがつ ついたち にちようび" とちゃんと読み分けてくる。同じ「日」が3回出てきて全部読みが違うやつです。これが普通に読めるTTS、地味にすごすぎる。）

もう1つ、長文を渡すとやたら早口になり、しかも参照音声を無視し始める 問題もありました。これは、テキストを 崩壊しない長さに切って順番に渡す ことで回避しています。長い返事は、裏で文を分割して合成しているわけです。

最終的に、合成は Python 側の HTTP サーバ（FastAPI で :7880、起動時に --voice-ref で Ref を指定）に切り出し、Next.js から /api/tts 経由で叩いて、ブラウザの Web Audio で再生する。チャットの返事と同期して喋る、という形に落ち着きました。

その後 ― 読み方辞書を、12万語に育てた

ここからは、最近やった話です。

手動の読み方辞書と LLM フィルタで当座はしのげていたのですが、根本的な弱点が残っていました。手で登録した語しか直せない。 知らない英単語が来たら、また誤読する。いたちごっこです。

そこで、力技に出ました。英単語の読みを、まとめて生成して辞書に流し込む。

使ったのは e2k（English-to-Katakana）。CMUDict（英語の発音辞書）の見出し語を、片っ端からカタカナ読みに変換しました。生成して登録できた語、124,922件。手動でぽちぽち登録していた数十語が、一気に12万語になりました。

ところが、ここで新しい壁にぶつかります。素朴な実装だと、辞書が大きいほど遅くなる。

もともとの辞書置換は、全エントリをループして1件ずつテキストを走査する O(N×M) の作りでした。数十語なら1msで終わる。でも12万語を毎ターン回すと、500字のテキストで約2秒かかる試算です。Yuiが喋るたびに2秒待たされる。これは即・UX破綻です。声の即応性は、この秘書の生命線なので。

解決は、内部のアルゴリズムを Aho-Corasick（エイホ・コラシック）に差し替えること。複数のパターンを1回のテキストスキャンで同時にマッチングする古典的アルゴリズムで、計算量が辞書サイズにほぼ依存しない O(M+出現数) になります。しかも leftmost-longest モードを使えば「Apple Music」を「Apple」より優先してくれるので、固有名詞の取りこぼしもない。

差し替えた結果がこれです（実測、約12.5万件の辞書をコンテナ内で計測）。

項目	実測
置換処理（500字）	0.095 ms
置換処理（10,000字）	0.287 ms
trie 構築（12.5万件、60秒に1回だけ）	301 ms
メモリ（trie 本体）	約 140 MB

目標にしていた「12万件で50ms以下」に対して、約500倍の余裕。素朴ループなら2秒かかっていたはずの処理が、0.1ms未満になりました。体感は完全にゼロです。

地味に効いているのが、出所の優先順位です。手で登録した語（user）は、一括生成した語（cmudict）に必ず勝つようにしてあります。たとえば「Claude」。私は「クロード」と手で登録しているので、12万語の中に機械生成の別読みが紛れていても、こちらが優先される。実際に「Claude と schedule と coffee」と喋らせると、ちゃんと「クロード と スケジュール と コーヒー」と読みます（user の Claude が勝ち、cmudict 側の schedule / coffee はそのまま正しく読まれる）。

そして何より良かったのは、もう手で登録しなくても、たいていの英語が自然に読めるようになったこと。「GitHub」も「API」も、わざわざ辞書に足さなくても、それっぽく読んでくれる。あの「英語、壊滅」だった結衣が、いつの間にか英語混じりの文章を、普通に喋るようになっていました。

そして、結衣は喋った

声が乗った瞬間のことは、よく覚えています。

うちの秘書には 結衣（ゆい） という名前をつけています（設定で変えられるので、これはデフォルトの一例ですが）。

この「結衣」という名前、実は個人的な由来があります。昔、ゆいちゃっと という CGI のチャットがありました。Windows95 とジオシティーズの時代、個人サイトに設置して、みんなで文字でわいわい喋る、あの頃の定番です。私はこれをよく使っていて、「画面の向こうの誰かと、文字で会話する」という体験に、当時けっこうハマっていました。今となっては配布元も辿れず、どんな見た目だったかすら記憶が曖昧なのですが、「ゆいちゃっと」という名前と、あの楽しさだけははっきり残っています。

だから、自分の秘書に名前をつけようとしたとき、自然と頭に浮かんできたのが「ゆい」でした。漢字をあてて、結衣。文字で会話していたあの頃の延長線上に、いまの結衣がいる気がしています。

その結衣が、棒立ちのまま、自分の声で初めて喋った。たったそれだけのことなのに、テキストの時とは別物でした。「いる」感じが、一段濃くなった。

声って、こんなに効くのか、と。

おわりに

これで、結衣に声が宿りました。でも、よく見ると顔は無表情のまま。声で喋っているのに、表情ひとつ動かない。次はそこに手を入れていきます（第1章で撤退した、あの Blender 沼にもう一度…）。

それと、いつかやりたいのが逆方向、こちらから話しかける ほうです。タイピングじゃなく、声で。結衣に耳を持たせる、つまり STT。スタックにはすでに kotoba-whisper が乗っているので土台はあるんですが、ちゃんと会話入力として配線するのは、もう少し先になりそうです。

声が出るようになった結衣で、最初に作り込んだ機能が「お休みモード」でした。あの ささやき声 が活きる回になります。

参考

• Irodori TTS
• Style-Bert-VITS2
• kotoba-whisper
• vLLM
• e2k ― English → Katakana 変換（CMUDict 見出し語の一括カタカナ化に使用）
• @monyone/aho-corasick ― 12万語の辞書置換を高速化した Aho-Corasick 実装