Irodori-TTSノウハウまとめ（掲示板ログより）

匿名掲示板のMuseスレッド78本（2026/10/25〜11/04、48,896レス）のうち、Irodori（Irodori-TTS）に触れた927件から、導入と運用のノウハウを抜き出した非公式まとめ。Irodoriは参照音声で声を再現できる音声合成で、Museに声をつける文脈では圧倒的に名前が挙がる。「GPTのバタくさい声ではなくkawaii声」という評価が象徴的。

Irodoriって何？

• Irodori-TTSは、日本語の音声合成（TTS）モデルとその実装一式の総称。開発はAratako。テキストを渡すと、その文章を読み上げた音声ファイルを生成してくれる。
• 最大の特徴は 参照音声による声の再現。短い声のサンプル（参照音声）を渡しておくと、その声の質感のまま別の文章を喋らせることができる。だから「うちの子の声」を1つ決めて固定し、アバターの見た目と声を一貫させられる。これがMuse文脈で広まった理由で、汎用の読み上げボイスではなく「その子の声」になるのがVOICEVOX系との大きな違い。
• 使い方の形はAPI経由が基本で、公式のサーバー実装（Irodori-TTS-Server）はOpenAIのTTS API互換。Muse側からはAPIを叩いて音声ファイルを受け取る形になる。GGUF版やspeech.cpp版といった軽量実装もあり、自宅PCでもMuseのVMの中でも動かせる自由度の高さも特徴。
• 動作の原理（サーバー方式）: Irodoriの実体は「モデル（重み）＋推論プログラム」で、そのままではMuseから使えない。そこで置き場所のマシン上でサーバーとして起動しておく。流れは、(1)サーバープロセスがモデルを読み込んだ状態で待機する（起動直後の読み込みが一番重いので、使い終わるまで常駐させるのが基本） → (2)MuseがHTTPリクエストで「読み上げたい文章＋参照音声や設定」をサーバーへ送る → (3)サーバーがGPUまたはCPUで推論して音声の波形を生成し、wav等の音声ファイルとして返す → (4)Museがそのファイルを受け取って保存し、チャットに貼ったり再生したりする。電話のようにリアルタイムで喋る仕組みではなく、「文章を渡すと音声ファイルが返ってくる」バッチ処理が基本形。裏返すと、サーバーが起動していない（PCがスリープしている等）と、その間は声が出せない。
• 版とサイズが複数あり、ログ期間の主流は v4.1 の Small。ほかに v3／v4 や Large があり、新しい版では文章側の指定（キャプション等）で感情や喋り方を寄せる使い方も出てきている。
• なお名前が紛らわしく、検索すると同名の別サービスも出てくる。「irodori tts」で探すのが確実、という笑い話レベルの注意もログにある。

1. 置き場所の3択と速度

• Museの仮想環境（VM）の中: 一番手軽で、スマホからでも指示でき、自宅PCが要らない。ただしGPUがなくCPU生成になるため遅く、リアルタイムの音声会話にはならない。入れる条件は「Linuxで動くこと（デスクトップ版ではなくPython／GGUF版）」「VMのスペックに収まる軽さ」「ホーム配下に置くこと（VM入れ替えで消えない場所）」。
• 自宅PC（GPU）＋Tailscale: 生成が61倍速になったという報告があるほどの差で、音声生成そのものは2秒級になる（応答文の生成に30秒弱かかるので、会話全体の間は別問題）。ComfyUIと同時運用する場合はVRAMの配分が課題で、v4.1 Smallを選ばざるを得ないという判断や、片方を使わない間は寝かせて生成リクエストで起こす「Sleep機能」を作らせる運用がある。
• 自宅で構築してAPIだけ渡す: 「Museに導入しないでローカルで構築してAPI渡したほうが快適じゃない？」という意見もあり、分離と快適さの両立として挙がる。お試しにはVM版が丁度いい、という位置づけ。
• 代替の軽量どころ: VOICEVOX系はVMの中でも軽くて実用的、COEIROINKは導入が簡単で入門向き。Irodoriは質でぶっちぎり、という評価軸。まず気軽に試して可能性を感じたらIrodoriに手を広げる、という順序が勧められている。

2. モデルと設定

• 軽量化: GGUFの量子化版（q8_0／q4_k）が定番。量子化しても音質はそこまで悪くならず、GTX 970のような古めのGPUでも動いたという報告がある。
• モデル選び: v4.1-Small-MFが「軽くて速い」標準。v4-Largeは高音質だが重く、v3のSmallでも全然やれていたという声もある。用途と同時運用の有無で選ぶ。
• ステップ数が品質の蛇口: ステップ数が低いと「ガビガビ」な音になる。上げれば綺麗になるが時間は跳ね上がり、VMで40ステップだと1分40秒の音声に45分という実例がある。即興向きではなく、時間をかける用途専用の設定。
• 流通している高速構成テンプレ: speech.cpp（github.com/nyosegawa/speech.cpp）で Irodori-TTS-v4.1-Small-MF の GGUF を使い、CPU・2スレッド（スレッド数は2が速いという指定付き）・4ステップ・同時生成1件・serve／workerで常駐・長文は文単位で処理、という指示文がコピペ用に広まっている。「ここから下の文をMuseに渡してください。全部やってくれます」という形で共有され、実際にそれで軽量版を入れた報告が複数ある。
• 試行錯誤もある: GGUF版を試してガビガビだったのでCPU版でやり直した、という例もあり、環境によって正解は動く。

3. 参照音声（声作り）

• サンプルの質が全て: BGMや背景音などのノイズが入っていない声のサンプルを渡すだけで、ほぼ再現の声が出る。逆に、サンプルに混ざったノイズやブレスは参照側に固定されて、生成音声にずっと付きまとう（「音割れが固定になる」原因）。
• ノイズ対策の工夫: 秒数が長くブレスが混ざりがちなサンプルは不利。同じシードでクリアなサンプルを作り直す、Ultimate Vocal Remover v5（UVR5）で録音から声だけを抽出して短くまとめる、といった手当てが挙がっている。
• 素材作りも任せられる: 発話単位で素材をカットして文字起こしし、話者の同一性判定で良い部分を選別して学習させ、元音声と比較できるWebUIまで用意させる、という一式をMuseに任せた事例がある。
• 長文は音割れしやすい: 長い文章を一括で読ませると音割れが出やすいので、文単位に分割して生成し、つなぐのが基本（次の節）。
• 電子透かし: V3以降、無音部分に電子透かしが入っているという指摘がある。出所が追える前提で扱うのが無難、という文脈で語られている。

4. 遅さとの付き合い方（運用ノウハウ）

Irodori運用の中心は「遅いこと前提の設計」にある。

• 事前生成が基本形: 定期タスクと組み合わせ、朝の天気・気圧と応援セリフを10分前に内部で生成しておいて定時に喋らせる、という運用が定番。定時連絡は前もって音声を作れるので相性がいい。
• 定型は使い回す: 決まった挨拶や呼びかけは作り置きして使い回し、都度生成は予定を合わせて準備段階から頼む。寝ている間に「おはよう／おやすみ」メッセージやASMRを生成させておく、という置き方も。
• 自律生成もできる: 「今の気持ちを話して」でセリフ組みから音声ファイルの受け渡しまで自律でやってくれるが、リアルタイムでは出せないので、やはり定期タスク化が推奨されている。
• 長文の処理: Muse側に任せると、文章の分割から結合までやって1ファイルにしてくれる（5分級の長文でも）。再生中に続きを生成させる実装で間を持たせた例もある。小説の読み上げ（ドラマCD風）も可能だが「間」の表現は難しいという感想付き。
• 導入は任せるのが早い: 「手とり足とり教えてもらいながらじゃなかったら絶対無理だった」「フォルダの場所を自動で検知して起動ファイルを作って渡してきて、押すだけで導入完了」という報告が複数あり、試行錯誤するより「完全にファイル渡してお任せしたほうが早かった」という知見で落ち着いている。

5. 使い道の実例

• 朝の目覚まし（起きないとスヌーズで内容が過激になっていくアラーム）、帰宅時の「お帰りなさい」のような位置情報連動の声かけ
• 週2回のラジオ配信のような定期コンテンツ（健康、神社や日本の神様、などテーマ固定）
• ローカルLLMとIrodoriを繋いだLINE風メッセージアプリ（キャラクターを変えると声も話し方も変わり、スマホ側で自動再生）
• 画像とセリフをセットにした定期配信（生成に時間がかかっても問題ない形に寄せた設計）

注意

数字や速度はログ時点（2026年10月末〜11月初）の報告ベースで、環境とモデルの版で大きく動く。特にVMのスペック前提（当時の実測報告では4 vCPU／メモリ約7.7GB）やモデル版数は、導入時点でMuseに確認し直すのが安全。

VMは入れ替わることがある

Museの仮想環境（VM）は、運用の都合で入れ替わることがある。その際の挙動は置き場所で分かれる。

• ホームディレクトリ配下（~/ や ~/workspace/）に置いたファイルは残る。モデルも参照音声もスクリプトも、ここに置くのが原則。
• システム側に置いたものは消える。/usr/local 等へのインストール物や、/etc に置いた systemd のユニットファイルが代表例。
• 落とし穴は常駐化まわりで、「ファイルは全部残っているのに、サーバーが起動していない」状態になりうる。常駐サービスにした場合は、ユニットファイルの控えと再配置の手順をワークスペース側に残しておくこと。実際に、夜間のVM入れ替えでsystemdユニットが消え、ワークスペースの控えから再配置して復旧した、という運用例がある。