Irodori-TTS とは｜絵文字で感情を操る日本語 TTS の仕組みと実測

音声合成の話題は英語圏のモデルが中心になりがちですが、日本語だけを狙い撃ちにしたモデルが個人の手から出てきて、しかも MIT ライセンスで配られています。それが Irodori-TTS です。

名前を聞いたことはあっても、「結局のところ何が新しいのか」「業務で使ってよいものなのか」までは追えていない方が多いと思います。この記事では、公開されているモデルカードやリポジトリの一次情報を追いながら、実際に GPU を借りて動かした実測値とあわせて整理します。

FIXIT

絵文字で感情を指定できる音声合成って聞いたけど、それって飛び道具なだけじゃないの？

Tsumiki

実際に聴くと、笑いも吐息も絵文字を置いた位置にそのまま乗ります。設定はしていません。

FIXIT

えっ、個人が作ったモデルなんだよね？仕事で使って大丈夫なの？

Tsumiki

コードも重みも MIT です。参考にした本家が非商用縛りなので、そこを外した作りが効いています。

FIXIT

じゃあ動かすのは大変？GPU がないと無理とか？

Tsumiki

手元では RTX 4090 を 1 時間借りて全部試しました。実費は 60 円くらいです。

Irodori-TTS を 3 行で

Irodori-TTS は、Aratako 氏 (Chihiro Arata 名義) が個人で開発している日本語特化のテキスト音声合成モデルです。学習・推論コードは GitHub に、学習済みの重みは Hugging Face に、どちらも MIT ライセンスで公開されています。

最新版の Irodori-TTS-v4.1-Small は 2026 年 8 月 11 日公開で、パラメータ数は約 7.7 億 (766,052,385) です。GitHub リポジトリは 2026 年 8 月 22 日時点で 1,203 スター、149 フォークを集めています。

このモデルの性格をひとことで言うと、「声そのものを設計させる」タイプの音声合成です。既製の話者ボイスは同梱されておらず、代わりに次の 4 系統の入力を組み合わせて、話者と話し方をその場で作り出します。

裏を返すと、何も指定しないと生成のたびに性別も年齢も変わります。手軽さを求めて触ると面食らう部分ですが、これは欠点というより設計思想の表れです。

仕組み——離散トークンをやめて連続潜在を生成する

Irodori-TTS のアーキテクチャは Rectified Flow Diffusion Transformer (RF-DiT) と呼ばれるものです。設計と学習方法は、Jordan Darefsky 氏の Echo-TTS をおおむね踏襲しています。

近年の音声合成には大きく 2 つの流れがあります。ひとつは音声をコーデックで離散トークンに変換し、言語モデルと同じ要領で次のトークンを予測していく方式です。もうひとつが、音声を連続値の潜在表現に落とし、拡散モデルやフローマッチングでその潜在表現そのものを生成する方式です。Irodori-TTS は後者にあたります。

Echo-TTS の作者は、前作にあたる Parakeet が離散トークン空間の自己回帰生成で一貫性を保てなかったと振り返り、連続潜在への移行を選んだと説明しています。Irodori-TTS はこの判断をそのまま引き継いでいます。

推論時の流れは次のようになります。

flowchart LR
  T[入力テキスト] --> E[共有エンコーダ<br/>ModernBERT-ja]
  C[キャプション] --> E
  R[参照音声] --> RE[参照潜在エンコーダ]
  E --> P[条件プロジェクタ]
  P --> D[Diffusion Transformer<br/>RF-DiT]
  RE --> D
  P --> DP[Duration Predictor]
  DP --> D
  D --> L[DACVAE 潜在系列]
  L --> V[コーデックでデコード<br/>48kHz 波形]
  V --> W[SilentCipher 透かし]

構成要素として押さえておきたいのは次の 3 つです。

ひとつ目は音声の表現方法です。Irodori-TTS は音声を Semantic-DACVAE-Japanese-32dim という 32 次元の連続潜在系列として扱い、48kHz の波形に復元します。このコーデックも同じ作者が Meta の DACVAE をベースに作ったもので、WavLM による意味蒸留を組み込んだうえで日本語音声で追加学習し、潜在次元を 128 から 32 まで圧縮しています。次元を落とすと下流の音声合成モデルの学習が軽くなる一方、UTMOSv2 で測った再構成品質は元の DACVAE を上回っています。

ふたつ目はテキストの理解です。v4 でテキストエンコーダが刷新され、ゼロから学習した独自のエンコーダから、SB Intuitions が公開する ModernBERT-ja-310m をファインチューニングしたものに置き換わりました。しかもこのエンコーダは、読み上げるテキストとキャプションの両方で共有されます。日本語の事前学習済み言語モデルを土台にしたことで、難しい漢字の読みが改善したとされています。

3 つ目が出力長の推定です。v3 から Duration Predictor が導入され、テキストと条件から出力の長さを自動で見積もるようになりました。v4.1 での変更はここだけで、本体を凍結した状態で Duration Predictor だけを分離して学習し直しています。出力長を過大に見積もることで起きていた生成崩れを減らすのが狙いです。

半年で 7 世代——どこから生まれたのか

Irodori-TTS を「突然出てきた個人開発モデル」と捉えると、実像を見誤ります。作者の Hugging Face アカウントには 134 のモデルと 68 のデータセットが並んでおり、Irodori-TTS はその積み重ねの上に立っています。

公開日を並べると流れが見えてきます。

半年で 7 世代という速度もさることながら、v1 から v2 にかけて音声コーデックそのものを自作品へ差し替えている点が目を引きます。ここは後述するライセンスの話にも直結します。

ライセンスが MIT である意味

日本語のローカル音声合成を業務で検討するとき、性能より先に引っかかるのがライセンスです。ここで Irodori-TTS の設計判断が効いてきます。

この種のモデルでは、音声を潜在表現に変換するコーデックのライセンスが全体を縛ります。設計の参照元である Echo-TTS は Fish Speech の S1-DAC というオートエンコーダを使っており、これが CC BY-NC-SA 4.0、つまり非商用限定です。コーデックが非商用であれば、それを通して音声を作るパイプライン全体が非商用に縛られると Echo-TTS の作者自身が述べています。

Irodori-TTS はこの部分だけ別の道を選びました。初代は Meta の DACVAE をそのまま 128 次元で使い、v2 以降は自作の Semantic-DACVAE-Japanese-32dim に切り替えています。土台は facebook/dacvae-watermarked で、そこに WavLM の意味蒸留と日本語音声での追加学習を重ねたうえで、MIT として公開されています。アーキテクチャの考え方は参照しつつ、ライセンス上の足かせになる部分は最初から踏まずに済ませたかたちです。

作者は GitHub の Issue で、商用利用について次のように回答しています。

As long as you comply with the model's license and Ethical Restrictions, there are no further restrictions. Please feel free to use it, including for commercial purposes.

ただし、ライセンスとは別に 4 つの倫理的制約がモデルカードに明記されています。

1. 声優・著名人・公人を含め、本人の明確な同意なく個人の声をクローンしないこと
2. 誤解を招くディープフェイクや虚偽情報を目的とした音声を生成しないこと
3. 参照音声を使わずに生成した声が偶然実在の人物に似る可能性があること
4. 誤用に対して開発者は責任を負わず、法令順守は利用者の責任であること

3 番目は見落とされがちです。参照音声を渡していないから安全、とは言い切れないという注意で、潜在空間のなかで確率的に似てしまう可能性があると作者自身が述べています。

生成音声にはソニーの SilentCipher による電子透かしが自動で埋め込まれます。これも作者の説明が明快で、生成後に後付けする方式なので技術的には外せるものの、なりすまし防止のために外す方法は案内しない、外すことを推奨もしない、という立場を取っています。禁止条項ではないと明言したうえで推奨しないと言い切る書き方は、実務で判断するうえでかなり参考になります。

実際に動かす——RTX 4090 を 1 時間借りて測る

ここからは手を動かした結果です。手元の Mac には NVIDIA の GPU がないため、RunPod で RTX 4090 (24GB) を時間借りして検証しました。実費は Pod の立て直しを含めて約 60 円です。

セットアップ

必要なものは Python 3.10 以上、Git、そして uv の 3 つです。

git clone https://github.com/Aratako/Irodori-TTS.git
cd Irodori-TTS
uv sync --extra cu128

末尾の --extra で PyTorch のバックエンドを選びます。NVIDIA の CUDA 12.8 なら cu128、AMD なら rocm、Intel なら xpu、CPU のみや macOS なら cpu です。

所要時間は回線に大きく左右されました。同じ手順を 2 つの環境で実行した結果は次のとおりです。

依存関係をすべて展開した .venv は 7.8GB になりました。ここにモデル本体のダウンロードが加わります。初回の推論では v4.1 本体 (3.06GB) に加えてコーデック、ModernBERT、SilentCipher が取得され、Hugging Face のキャッシュは量子化版も含めて 5.0GB まで膨らみました。ディスクは余裕をもって 30GB 以上見ておくと安心です。

生成そのものは 1 行です。

uv run --no-sync python infer.py \
  --hf-checkpoint Aratako/Irodori-TTS-v4.1-Small \
  --text "本日はお越しいただき、誠にありがとうございます。" \
  --no-ref \
  --output-wav outputs/sample.wav

ブラウザから触りたい場合は Gradio の Web UI が用意されています。

uv run --no-sync python gradio_app.py --server-name 0.0.0.0 --server-port 7860

生成レイテンシと VRAM の実測

テキスト 40 字、出力音声 7.80 秒の条件で測った結果です。wall はプロセスの起動から終了までの実時間、gen は infer.py が出力するモデルロード後の純粋な生成時間です。

既定設定での RTF (生成時間 ÷ 音声長) は 0.137、つまり実時間の約 7 倍速で音声が出てきます。ステップ数を 16 に落とすと 0.084、実験的な Sway Sampling で 6 ステップまで削ると 0.058 まで下がりました。

読み取れることが 2 つあります。

ひとつは、VRAM が 5.5GB 前後で収まる点です。24GB の GPU は必要なく、8GB クラスでも動く水準に見えます。int8 の重み量子化を使えば 3.3GB まで下がるため、より小さい GPU も射程に入ります。ただし量子化版は wall が伸びており、これは初回のダウンロードとロードの分です。生成時間そのものは fp32 とほとんど変わりませんでした。速度目的ではなく、VRAM を切り詰めるための選択肢と考えるのが妥当です。

もうひとつは、wall と gen の差です。生成が 1 秒で終わっているのに、プロセス全体では 17 秒前後かかっています。差の 16 秒はモデルのロードです。コマンドを都度叩く使い方では待ち時間の 9 割以上がロードということになります。

何に時間がかかっているのか

infer.py は処理段階ごとの内訳を出力します。参照なし・40 ステップの場合は次のとおりです。

7 割強を占めるのが sample_rf、つまり Rectified Flow のサンプリングです。ステップ数を削ると速くなるのはこの部分だからで、逆に言えばここ以外を削っても効果は薄いことがわかります。

参照音声を渡すと prepare_reference が 0.2 ミリ秒から 445.3 ミリ秒に跳ね上がり、合計は 1.492 秒になりました。同じ声を繰り返し使うなら、参照音声を毎回エンコードするのではなく、事前に潜在表現へ変換して渡すか、話者埋め込みを学習しておくほうが効率的です。Irodori-TTS には Speaker Inversion という仕組みがあり、本体を凍結したまま話者の埋め込みだけを学習して、小さなファイルとして使い回せます。

電子透かしの付与に 74.5 ミリ秒かかっている点も、内訳を見て初めて気づける部分でした。生成時間の約 7% が透かしに使われている計算になります。

30 秒の壁

入力の長さを変えて出力の長さを測ると、明確な上限が見えました。

約 210 字を入れたときの出力はちょうど 30.00 秒で、後半が失われていました。学習時の最大長が 25 fps 換算で 750 フレーム、つまり 30 秒に設定されているためです。1 回の生成は 150 字前後までに抑え、それ以上は分割する前提で設計します。

つまずいたところ

最初に借りた Community Cloud の個体では、nvidia-smi は正常に GPU を表示するのに torch.cuda.is_available() が False を返し、CUDA の初期化に失敗しました。Pod を再起動しても直らず、Secure Cloud で立て直したところ問題なく動きました。時間貸しの GPU では個体差を引くことがあります。最初に torch.cuda.is_available() を確認してから本番の作業に入ると、無駄な待ち時間を防げます。

なお、CUDA が使えないまま CPU にフォールバックした状態でも生成自体は完走しました。ただし短文でモデルのダウンロード込み 176 秒です。これは 152 vCPU のサーバー CPU での値なので、ノート PC ではさらに時間がかかると見ておくべきでしょう。

声をどう作るか

参照音声は「短いクリップを複数」

v4-Small は参照音声を合計 120 秒まで受け付けます。ただしここには注意点があり、学習時に「同じ話者の短い発話をランダムに連結したデータ」で訓練されているため、1 本の長い録音を渡す形式は評価されていないと明記されています。推奨は同じ話者のクリーンな短いクリップを複数渡す方法です。

参照の長さと話者類似度の関係は、作者が JVS の 100 話者で測った結果が公開されています。

短いクリップ 1 本だけなら v3 のほうが良いという結果になっています。長い参照に対応するため学習方法を変えた副作用だと作者は説明しており、改善が一様ではないことを自分から明示している点は信頼できます。実務上の要点は、30 秒集めた時点で改善のほとんどが得られるということです。120 秒まで集める労力に見合う差は小さいので、まずは 30 秒を目標にするとよいでしょう。

キャプションは日本語の文章で書く

キャプションは声質・感情・話し方を日本語の文章で指定する機能です。モデルカードのサンプルでは、次のような書き方がされています。

落ち着いた大人の男性。フォーマルな場で、深く響く声で丁寧かつ歓迎の意を込めて話している。
若く元気な女性の声。カフェの店員のように、明るくハキハキとした少し高めのトーンで話している。
深く傷つき、今にも泣き出しそうな様子。声が震えており、悲痛なトーンで弱々しく話す。

年齢層・性別・場面・トーン・距離感を短い文で重ねる書き方です。参照音声と併用する場合は、声の同一性は参照音声に任せ、キャプションでは感情や状況だけを指定するのがコツだとされています。両方で声質を指定すると条件が衝突し、音質が不安定になったり片方が無視されたりすると明記されています。

キャプションの追従性については、作者が Coco-Nut の公開音声記述 2,890 件を使い、生成音声を LLM に 1〜5 で採点させた結果を公開しています。v3 VoiceDesign の平均 4.2096 に対し v4-Small が 4.2339 と、わずかな改善にとどまりました。この評価について作者自身が「単一の自動判定を使った軽量な内部比較であり、研究水準のベンチマークとして扱うものではない」と断っています。

絵文字は 45 種類

絵文字による制御は、対応する 45 種類がドキュメントに一覧化されています。一部を挙げると次のようなものです。

同じ絵文字を繰り返すと効果を強められます。この機能は Respair 氏の着想を取り入れたものだと謝辞に記されています。

実際に「あははっ🤭、それ本当に言ってるの？…😮‍💨まぁ、君らしいけどね。」という一文を生成して聴いてみると、含み笑いと吐息が絵文字を置いた位置にそのまま乗っていました。テキストに絵文字を 2 つ足しただけで、抑揚の設定もパラメータの調整もしていません。この手軽さで感情が乗るのは、実際に耳で確かめると驚きがあります。

数字にも表れていて、同じ長さの通常テキストが 7.80 秒だったのに対し、絵文字入りは 9.00 秒になりました。非言語の発声が挿入されるぶん、出力が長くなります。30 秒の上限を考えるときは、絵文字の追加分も見込んでおく必要があります。

ただしモデルカードの注意書きどおり、効きは文脈に左右されます。今回うまくいったのは 1 つのシードでの 1 例にすぎません。狙った表現を確実に出したい場面では、シードを変えて数本作り、良いものを選ぶ工程を見込んでおくのが安全です。

業務システムへの組み込み方

コマンドを都度叩く使い方では、1 回あたり 16 秒のモデルロードが乗ります。業務で使うならサーバーを常駐させる構成が現実的です。

作者は Irodori-TTS-Server という OpenAI Text-to-Speech API 互換のサーバーを別リポジトリで公開しています。既存のコードで OpenAI の音声合成を呼んでいるなら、接続先を差し替えるだけで移行できます。

from openai import OpenAI
 
client = OpenAI(base_url="http://localhost:8088/v1", api_key="not-used")
 
with client.audio.speech.with_streaming_response.create(
    model="irodori-tts",
    voice="sample",
    input="こんにちは。これは Irodori-TTS の API テストです。",
    response_format="wav",
) as response:
    response.stream_to_file("speech.wav")

キャプションのような Irodori 固有の指定は、リクエストに irodori キーを足して渡します。

{
  "model": "irodori-tts",
  "input": "本日はお越しいただき、ありがとうございます。",
  "voice": "none",
  "response_format": "wav",
  "irodori": {
    "caption": "落ち着いた低めの女性の声。丁寧で穏やかな話し方。"
  }
}

長文は既定で自動的にチャンク分割され、順番に合成してから 1 本の音声に連結されます。分割は「一定の文字数に達したうえで句読点か改行に当たった位置」で行われ、しきい値はリクエストごとに調整できます。30 秒の制約をアプリケーション側で意識しなくて済むのは大きな利点です。

出力形式は wav / mp3 / flac / opus / aac / pcm に対応し、リクエストごとの LoRA アダプタ切り替えやベアラートークン認証も備えています。既定では同時に走る合成は 1 件で、それ以上は待ち行列に入ります。同時アクセスが見込まれるなら、この上限とタイムアウトの設定を先に詰めておくべきです。

このほか、コミュニティ側でも WebGPU でブラウザ内推論を試みるもの、ComfyUI のノード、int4 量子化で 1GB 前後の VRAM を狙うもの、Google Colab 用のノートブックなど、派生プロジェクトが複数生まれています。用途に近いものが既にあるかを一度探してみる価値はあります。

ベンチマークをどう読むか

作者は評価結果もモデルカードで公開しています。読み方に注意が要る部分があるので、あわせて整理します。

日本語の読みの正確さは、SB Intuitions が公開する Joyo Kanji Yomi Benchmark と JSUT BASIC5000 で測られています。学習データにはどちらも含まれていないと明記されています。

常用漢字の読みでは、約 36 万時間の音声で学習された Sarashina2.2-TTS を上回る数字が出ています。一方で JSUT の文レベルでは負けており、得意不得意がはっきり分かれています。

ただしこの表は横並びの優劣として読むべきものではありません。作者自身が注記しているとおり、論文値のモデルは非公開の固定参照音声とその書き起こしを使っているのに対し、Irodori は参照音声もキャプションも使わずに生成した結果です。アーキテクチャも推論設定も違います。

もうひとつ押さえておきたいのが、大規模な主観評価を実施していないという点です。自然さ・プロンプト追従・話者類似度のいずれについても人手の MOS 評価は行っておらず、自動評価のスコアが人間の知覚をそのまま代表するわけではないと作者が明記しています。数字だけで採否を決めず、自社の用途のテキストで実際に生成して耳で確かめる工程は省けません。

使いどころと、向かないところ

一次情報と実測を踏まえると、判断の分かれ目は次のように整理できます。

対応言語が日本語のみである点は、そのまま適用範囲の線引きになります。英語の文を入れるとカタカナ読みになったり不明瞭な発音になったりするため、多言語が必要な用途では別の選択肢が必要です。

FIXIT

結局、仕事で使うなら何から手をつければいいの？

Tsumiki

まず公式のデモ Space を触るのが早いです。環境構築なしで質感がわかります。

FIXIT

それで良さそうなら、次は？

Tsumiki

使いたい声の参照音声を 30 秒集めます。ここが揃わないと比較になりません。

FIXIT

GPU を買うのは、その後でいいってこと？

Tsumiki

はい。時間貸しで先に自社の原稿を通してから決めると、判断を間違えにくいです。

まとめ

Irodori-TTS は、絵文字で感情を指定できるという分かりやすい特徴の裏に、地に足のついた設計判断が積み重なっているモデルでした。

一次情報と実測から見えたことを整理すると、次のようになります。

テキスト・参照音声・キャプション・絵文字という 4 系統の入力を単一のモデルで扱えるようになったのが v4 の到達点です。参照元の Echo-TTS が非商用のコーデックに縛られているのに対し、コーデックを自作して置き換えることで MIT を通しています。RTX 4090 では 7.8 秒の音声が 1.07 秒で生成でき、VRAM は 5.5GB、int8 量子化なら 3.3GB まで落ちます。一方で 1 回の生成は 30 秒が上限で、プロセス起動ごとに 16 秒のモデルロードが乗るため、業務利用では API サーバーを常駐させ、長文はチャンク分割する構成が前提になります。

弱点を作者自身がモデルカードに書き出している点も、採否を判断する側からするとありがたい姿勢です。短い参照 1 本では v3 に劣ること、絵文字の効きが一貫しないこと、人手による主観評価を行っていないこと。こうした情報が揃っているからこそ、自社の用途に照らして冷静に判断できます。

FIXIT では、こうした新しいツールやモデルを実際に動かしたうえで、プロダクト開発のどこに組み込めるかを検証しています。音声を扱うプロダクトの設計や、ローカルモデルの業務導入でお困りのことがあれば、お問い合わせからご相談ください。

参考リンク

• Aratako/Irodori-TTS (GitHub)
• Aratako/Irodori-TTS-v4.1-Small (Hugging Face)
• Aratako/Irodori-TTS-Server (GitHub)
• Irodori-TTS-v4.1-Small Demo (Hugging Face Spaces)
• Echo-TTS の解説記事 (Jordan Darefsky)
• Aratako/Semantic-DACVAE-Japanese-32dim (Hugging Face)