Labo › 検証ノート

音声合成

Irodori-TTS v4-Large の読み間違いを v4.1-Small と比べた — 時刻の読み上げ 36 本で誤りは 0。ただし短い文を 2 回読むことがあった（RTX 5060 Ti 16GB）

IVYXON 編集部 ・ 2026年10月2日

18/27短い文の余分な声v4.1-Small は 7〜8 本
0 / 36時刻の読み上げの誤り別の読みは 1 本
3.73 秒1 本の生成v4.1-Small（bf16）の 1.5 倍
CONTENTS目次（8）
  1. 使ったもの
  2. 判定の手順（前回と同じ）
  3. 結果 1: 読みの誤りは 0、別の読みも最も少なかった
  4. 結果 2: 短い文を 2 回読むことがあった
  5. 結果 3: 速さと VRAM
  6. 測っていないこと
  7. まとめ
  8. 出典

この記事の結論

  • 読みの誤りは 0 本で、別の読みも 1 本と、比べた 4 通りの中で最も少なかった。v4.1-Small が「はちふん」「よんじゅうよんふん」と読むことの多かった「8分」「44分」を、Large は 6 本とも「はっぷん」「よんじゅうよんぷん」と読んだ。ただし「午前7時」は 3 本とも、まず「ななじ」と読んだ（うち 2 本はすぐ「しちじ」と言い直した）。
  • 短い 1 文では、同じ文を 2 回読むなどの余分な声が 27 本中 18 本に入った（v4.1-Small は 7〜8 本）。1 人目の声では 9 文中 7 文を 2 回読んだ。読みの判定だけでは見落とすので、書き起こしの長さも検査する必要がある。
  • 1 本の生成は 3.73 秒で、同じ日に測った v4.1-Small（bf16）の 1.5 倍。1 秒の音声あたりでは 0.98 秒で、ほぼ実時間。VRAM は読み込みの途中で 13,146MiB（16GB の約 8 割）まで使い、生成中の山は 7,766MiB だった。

Irodori-TTS は、日本語の音声合成（TTS）のモデルです。2026年9月27日に、これまでの v4.1-Small（約 0.77B）の 4 倍ほどの大きさの v4-Large（約 3.29B）が公開されました。作者の評価では、文章で声を作り分ける Voice Design の点数は Small より高く、常用漢字の読みの正確さは Small よりわずかに低いとされています。

前回の記事（Irodori-TTS v4.1 の読み間違いを kana-whisper で自動検査する）では、v4.1-Small と、少ない段数で速く作る MF 版で時刻の読み上げを 36 本ずつ作り、読みを機械的に検査しました。今回は同じ 36 本を v4-Large で作り、同じ検査にかけました。数字は 2026年10月1日時点のものです。

使ったもの

項目内容
音声合成Irodori-TTS v4-Large（約 3.29B。重みのファイルは F32 で 13.2GB）。文章と声の指定を読み込む部分に、Google の T5Gemma 2 を使っている。比べる相手は前回と同じ v4.1-Small（約 0.77B・3.1GB）と v4.1-Small-MF
計算の精度Large と v4.1-Small を、どちらも bf16（16 ビットの浮動小数点）で動かした（--model-precision bf16。音声に戻す部分〔コーデック〕は既定の fp32 のまま）。前回の v4.1-Small と MF 版は fp32（32 ビット）
生成の設定段数は既定の 40（MF 版は 4）で、ほかの設定も既定のまま。音声の長さは指定せず、モデルの自動の見積もりに任せた（前回と同じ）
文と声前回と同じ 12 文×3 人の声＝36 本。声は参考の音声を使わず文章で指定し（落ち着いた二十代後半・明るく元気な二十代・しっとりとした大人）、乱数の種も前回と同じ
読みの検査sbintuitions/kana-whisper（音声をカタカナで書き起こすモデル）で書き起こし、前回と同じ規則で正解と突き合わせた
機材・ソフトGeForce RTX 5060 Ti 16GB・Windows 11。Python 3.10・PyTorch 2.10（CUDA 12.8）・transformers 5.12。Irodori-TTS のコードも前回と同じ版

Large を fp32 のまま動かすと、重みだけで約 12,540MiB を使います。生成中の作業の分と画面表示の分を足すと、16GB の GPU では余裕がほとんどありません。Windows の NVIDIA のドライバは、VRAM が足りなくなるとメインメモリで代わりをして動き続けるので、止まらずに遅くなり、速さの比較が狂います。そこで Large は bf16 で動かし、比べる相手の v4.1-Small も同じ日に bf16 で作り直しました。作者の評価は fp32 で行われているので、bf16 にしたことで読みが変わった可能性は残ります。

判定の手順（前回と同じ）

書き起こしと正解の両方の長音をそろえてから、「正」「別の読み」「誤」の 3 つに分けます（コードは前回の記事に載せています）。「8分」を「はちふん」、「44分」を「よんじゅうよんふん」と読んだものは、辞書によって分かれる読みとして「別の読み」に数えます。前回の書き起こしをこの手順で判定し直し、前回と同じ数（v4.1-Small は正 30・別の読み 6・誤 0、MF 版は 29・4・3）になることを確かめてから、今回の分を判定しました。

結果 1: 読みの誤りは 0、別の読みも最も少なかった

版正別の読み誤
v4-Large（bf16）3510
v4.1-Small（bf16）3150
v4.1-Small（fp32・前回）3060
v4.1-Small-MF（fp32・前回）2943

各 36 本。kana-whisper の書き起こしによる判定で、人の耳では確かめていない。前回の 2 つは 2026年9月29日、今回の 2 つは 2026年10月1日に作った。

差が出たのは、次の 3 か所です。

読みv4-Largev4.1-Small
（bf16）		v4.1-Small
（fp32・前回）		MF 版
（前回）
「8分」を「はちふん」0332
「44分」を「よんじゅうよんふん」0221
「午前7時」を、まず「ななじ」3111

3 人の声の 3 本のうち、その読みをした本数。MF 版の「8分」の残り 1 本は「はちぷん」と読んだ（誤）。「朝の7時です。」の文は、MF 版の 1 本（「ひちじ」）を除いて、どの版も「しちじ」と読んだ。

  • Large は「8分」「44分」を、6 本とも「はっぷん」「よんじゅうよんぷん」と読みました。v4.1-Small の別の読みは、ほとんどがこの 2 つを「ふん」と読んだものです
  • 一方で「午前7時」は、Large の 3 本とも最初に「ななじ」と読みました。うち 2 本は「ゴゼンナナジデス、ゴゼンシチジデス」と続けて言い直していて、前回と同じ規則（正解の読みが書き起こしのどこかにあれば正）では「正」に数えています
  • 2 通り続けて読んだ本を最初の読みで数え直すと、Large は正 33・別の読み 3、v4.1-Small（bf16）は正 30・別の読み 6 です。この数え方でも、Large のほうが別の読みは少なくなります

作者の評価では、Large の読みの正確さは Small よりわずかに低い（常用漢字の読みのベンチマークの正答率で 92.80% 対 93.42%）とされています。今回は時刻の 12 文だけなので、この結果から、一般に Large のほうが読みが正確だとは言えません。

結果 2: 短い文を 2 回読むことがあった

前回の記事では、書き起こしに文の前後の声や言い直しが混じる本を数えました。同じ数え方（1 文だけの 9 文×3 人＝27 本のうち、読みの誤りを除いて、書き起こしが「時刻＋です」より長い本）で比べると、Large は 27 本中 18 本でした。

版余分な声
（27 本中）		1 人目2 人目3 人目
v4-Large（bf16）18828
v4.1-Small（bf16）7403
v4.1-Small（fp32・前回）8404
v4.1-Small-MF（fp32・前回）7403

声は 1 人目が「落ち着いた二十代後半」、2 人目が「明るく元気な二十代」、3 人目が「しっとりとした大人」。各 9 本。

Large の書き起こしの例です。

読ませた文声書き起こし
午前4時です。1 人目ゴゼンヨジデスゴゼンヨジデス
1時1分です。1 人目イチジイップンデス、イチジイップンデス
午前7時です。1 人目ゴゼンナナジデス、ゴゼンシチジデス
6時6分です。3 人目ロクジロップンデス、ツーヨー
10時10分です。3 人目ヨニジュージジュップンデス
  • 1 人目の声では、9 文中 7 文で同じ文を 2 回読んでいました（1 回目と 2 回目で読みを変えた「午前7時」を含む）
  • 3 人目の声では、2 本で文を読み直し、ほかは文の後ろに意味のない声が付いたり、前に余分な音が入ったりしました。はきはき話す 2 人目の声は 2 本だけでした
  • 後ろに文が続く長めの 3 文（9 本）では、Large も v4.1-Small も、余分な声は 1 本ずつでした

Irodori-TTS は、音声の長さを指定しないと、文と声の指定から長さを自動で見積もります。Large が作った 1 人目の短い文の音声は、どれも 3.7〜3.9 秒で、v4.1-Small（1.9〜2.9 秒）より長めでした。読み終えても時間が余り、その時間を同じ文の読み直しで埋めた、とみられます（確かめていません）。逆に、長めの 3 文の音声は Large のほうが短めでした（3.7〜5.2 秒。v4.1-Small は 3.8〜6.2 秒）。

2026年10月2日に、2 回読んだと書き起こされた本のうち 2 本（1 人目の声の「午前4時です。」と「1時1分です。」）を人が聞き、同じ文を 2 回読んでいることを確かめました。残りの本は聞いていませんが、2 回読んだと書き起こされた本は音声も長く、1 回目と 2 回目で読みが違う本もあるので、同じように音に入っているとみられます。Irodori-TTS には、長さを秒数で指定する --seconds と、見積もりを伸び縮みさせる --duration-scale（1 より小さいと短くなる）があり、短い文で長さを詰めれば防げる可能性がありますが、今回は試していません。

結果 3: 速さと VRAM

版1 本の生成1 秒の音声
あたり		音声の
長さ		VRAM の山
読み込み中・生成中
v4-Large（bf16）3.73 秒0.98 秒3.7 秒13,146・7,766
v4.1-Small（bf16）2.47 秒0.80 秒2.8 秒3,079・2,940
v4.1-Small（fp32・前回）1.64 秒0.60 秒2.8 秒—
v4.1-Small-MF（fp32・前回）0.53 秒0.19 秒2.8 秒—

各 35 本の中央値（モデルの読み込みを含む最初の 1 本を除く）。VRAM は PyTorch が確保した量の最大（MiB）で、読み込み中は最初の 1 本まで、生成中はその後の 35 本。前回は 2 つの版を同時に読み込んで、最大 8,110MiB だった。今回の 2 つは 2026年10月1日に、同じ GPU で続けて測った。

  • Large の 1 本の生成は 3.73 秒で、同じ日に測った v4.1-Small（bf16）の 1.5 倍でした。1 秒の音声あたりでは 0.98 秒と、ほぼ実時間で作れています
  • ただし Large の音声は、読み直しのぶん長くなりがちなので（中央値 3.7 秒。v4.1-Small は 2.8 秒）、1 秒あたりの数字は実際より良く見えます。1 本あたりで比べるほうが、使ったときの感覚に近いはずです
  • モデルの読み込みを含む最初の 1 本は、Large が 56 秒、v4.1-Small が 15 秒でした（重みは取り込み済み）

bf16 では、初めて作る長さのときに約 1 秒多くかかった

今回の bf16 の 2 つは、1 本ごとの時間が約 1 秒の幅で、2 つの群にはっきり分かれました。分かれ目は音声の長さで、それまでに作ったことのない長さの音声を作るときだけ遅く、同じ長さの 2 本目からは速くなっていました。前回の fp32 の 2 つには、この差はありませんでした。

版初めて作る長さ前に作った長さ
v4-Large（bf16）3.82 秒（21 本）2.83 秒（14 本）
v4.1-Small（bf16）2.54 秒（29 本）1.43 秒（6 本）
v4.1-Small（fp32・前回）1.65 秒（30 本）1.58 秒（5 本）
v4.1-Small-MF（fp32・前回）0.53 秒（30 本）0.53 秒（5 本）

1 本の生成の中央値（最初の 1 本を除く）。長さは、保存した音声の秒数（0.04 秒刻み）で分けた。bf16 の 2 つは群が重ならなかった（Large は 3.64〜4.06 秒と 2.64〜3.01 秒、v4.1-Small は 2.24〜2.80 秒と 1.32〜1.60 秒）。

GPU の計算の準備を、新しい長さのたびにやり直しているとみられますが、原因は確かめていません。この 36 本は長さがほとんど毎回違ったので、上の表の中央値には、この約 1 秒が入っています。bf16 の v4.1-Small が上の表で fp32 より遅く見えるのは、主にこのためです。前に作った長さどうしで比べると、bf16 の v4.1-Small（1.43 秒）は fp32（1.58 秒）より少し速く、Large（2.83 秒）は v4.1-Small の約 2 倍でした。

VRAM: 読み込みの途中で 16GB の約 8 割を使う

Large は、読み込みの途中で VRAM を 13,146MiB まで使いました。Irodori-TTS は、F32 の重みをいったんそのまま GPU に載せてから bf16 に変えるためです（Irodori-TTS のコードで確認）。bf16 に変えた後、生成中の山は 7,766MiB でした。

ただし PyTorch は、一度確保したメモリをすぐには手放しません。生成の間も、プロセスとしては最大 13,748MiB を抱えたままでした。16GB の GPU で、Large と別のモデル（たとえば LLM）を同時に載せるのは難しい量です。v4.1-Small（bf16）は、読み込み中 3,079MiB・生成中 2,940MiB（抱えたままの量は最大 5,070MiB）でした。

使い分けの目安（時刻の読み上げ 36 本から）

  • 読みの正確さを優先し、1 本ずつ検査して作り直せるなら Large。短い文では読み直しが入りやすいので、読みだけでなく書き起こしの長さも検査する
  • 短い文をたくさん作る、VRAM を他のモデルと分け合うなら v4.1-Small。今回の時刻の文では、読みの誤りは Large と同じく 0 で、余分な声は Large の半分以下だった
  • 速さが何より大事なら MF 版（1 本 0.53 秒）。誤りが出るので、検査と作り直しを前提にする

Large のライセンスは Small と違う

v4.1-Small と MF 版は MIT ライセンスですが、v4-Large は文章の読み込みに Google の T5Gemma 2 を使っているため、Gemma の利用規約（Gemma Terms of Use）と、その禁止用途の方針（Prohibited Use Policy）に従います。作者はさらに、本人の同意なく声をまねることと、人をだます目的の合成音声を作ることを禁じています。

規約では、生成した出力（音声）について Google は権利を主張せず、使い方の責任は使う側にあるとされています。モデルそのものを配ったり、API などで機能を他の人に提供したりするのは規約上の「配布」にあたり、利用制限を受け手との約束に含める、規約の写しを渡す、などの条件が付きます。ここに書いたのは要点で、法的な確認ではありません。使う前に原文を確かめてください。

測っていないこと

  • 音の自然さや声の好み。今回の検査は、読みと書き起こしの長さだけを見ている
  • kana-whisper の判定が、人の耳の判定とどれだけ一致するか（読み直しを人が聞いて確かめたのは 2 本だけ）
  • 時刻以外の文（人名・専門用語・文脈で読みが変わる漢字など）と、もっと多い本数。読みの差は数本なので、偶然の範囲かもしれない
  • Large の fp32（作者の評価の条件）と、量子化版（int8 で約 3.6GB などが公開されている）
  • 参考の音声を使った声のまね（クローン）。作者は、短い参考の音声 1 本だと、声の似かたがかなり落ちると書いている
  • --seconds・--duration-scale で長さを詰めれば、読み直しが防げるか
  • bf16 で、初めて作る長さのときに約 1 秒多くかかる原因

まとめ

  • Irodori-TTS v4-Large は、時刻の読み上げ 36 本で読みの誤り 0・別の読み 1（v4.1-Small は誤り 0・別の読み 5〜6、MF 版は誤り 3）。「8分」「44分」は 6 本とも「〜ぷん」と読んだ
  • ただし短い 1 文では、27 本中 18 本に、同じ文を 2 回読むなどの余分な声が入った（v4.1-Small は 7〜8 本）。読みの判定に加えて、書き起こしの長さも検査する
  • 1 本の生成は 3.73 秒で、v4.1-Small（bf16）の 1.5 倍。1 秒の音声あたりでは 0.98 秒
  • 16GB の GPU では bf16 で動かした。読み込みの途中で VRAM を 13,146MiB まで使う（2026年10月1日時点）

出典

← 検証ノートの一覧へ

この記事は、手元の機材で行った測定をもとにした一般的な技術情報の提供を目的としており、特定の製品・ソフトウェアの購入や利用を推奨・勧誘するものではありません。数値は 2026年10月1日時点の測定（v4.1-Small と MF 版の fp32 は 2026年9月29日）で、モデルの版・設定・機材・読ませる文によって変わることがあります。ライセンスの記述は要点の紹介で、法的な助言ではありません。