Speech-AI-Forge を採用する前に確認すべきこと

Speech-AI-Forge が埋めるのはモデル選定の隙間

TTS のモデルはここ数年で増え、ChatTTS、CosyVoice、FishSpeech、F5-TTS、GPT-SoVITS などがそれぞれ別のリポジトリで公開されている。それぞれ推論コードの書き方も、音色の指定方法も、依存パッケージの組み合わせも異なる。1 つのモデルを試すだけなら個別リポジトリを直接動かせば済むが、複数を比較しようとすると環境構築を何度もやり直すことになる。Speech-AI-Forge はこの比較作業を 1 つのプロジェクトに寄せたもので、README では「TTS 生成モデルを中心に開発されたプロジェクト」と説明されている。対象は、音声合成を組み込む前に複数モデルの出力を聴き比べたい開発者、そして WebUI で音色を探しながら API 経由の呼び出しも同時に検証したい人である。

webui.py と launch.py で入口が分かれる

起動スクリプトは 2 つに分かれている。python webui.py は Gradio ベースの WebUI を立ち上げ、音色の切り替え、スタイル制御、長文の自動分割、分割器の設定、速度や音調の調整、生成履歴の保存といった操作を画面から行う。もう一方の python launch.py は API サーバー専用で、README では「WebUI が不要、またはより高い API スループットが必要な場合」に使うとされている。起動後に http://localhost:7870/docs を開くと有効なエンドポイントを確認できる。つまり WebUI は試行錯誤の場、launch.py は組み込み先から叩く窓口という役割分担になっている。同じモデル群を共有しつつ、UI を挟むか挟まないかを選べる点がこの構成の要である。

対応モデルは表で管理され、更新履歴も追える

README の対応モデル表には、Index-TTS (v1/v1.5)、Qwen3-TTS、FishSpeech (1.4)、CosyVoice (v2/v3)、FireRedTTS、F5-TTS (v0.6/v1)、Spark-TTS、GPT-SoVITS、ChatTTS が並び、対応言語も en/zh 中心のものから ja/ko/yue まで含むものまで幅がある。加えて MiniMax Cloud TTS のようなクラウド TTS も対象に入っている。Breaking change logs を見ると、CosyVoice3 や Qwen3-TTS、Index-TTS-2 の対応が時系列で記録されており、モデル側の更新に追従する形で機能が足されていることが分かる。逆に言えば、追従の速さはモデルごとに差があり、表の「実装状況」列がそのまま現在の到達点を示している。

音色はファイルとして扱われ、Hub から取得する

音色の扱いは WebUI の機能として明示されている。内置音色として 27 個の ChatTTS 音色、7 個の CosyVoice 音色、1 つの参考音色が用意され、カスタム音色ファイルのアップロードにも対応する。参考音声とそのテキストを渡して推論する方式も選べる。ChatTTS 向けにはランダムシードで音色を引く「音色抽卡」と、複数シードを混ぜる「音色融合」というデバッグ用の道具が用意されている。作成した音色はファイルとして扱われ、Speech-AI-Forge-spks リポジトリから Hub 経由でダウンロードできる。音色がコードに埋め込まれず外部ファイルとして流通する設計なので、差し替えと配布が分離されている。

長文と複数話者は SSML 側で処理する

長い原稿をそのまま投げるのではなく、分割してから合成する流れが用意されている。WebUI には分割器の設定があり、分割終了符 (eos) と分割閾値を調整できる。SSML タブでは Podcast 機能で長文かつ多角色の音声を作り、字幕ファイルから SSML スクリプトを生成し、スクリプトエディタで編集してから合成に回せる。ChatTTS の refiner を使えば、README の表現では無限長テキストの処理に対応する。長文を一括で投入するのではなく、分割結果を人間が確認してから音声化する前提の作りである点は、読み上げ位置のズレを避けたい用途では利点になる。

ASR と後処理まで同じ画面に入っている

音声合成だけでなく、Whisper や SenseVoice を使った ASR も同じプロジェクトに含まれる。Whisper では文稿匹配 (force alignment) により認識精度を上げる使い方が示されている。生成後の音声に対しては、速度、音調、音量の調整と響度均衡、Enhancer モデルによる人声增强、後処理ツールでのクリップや調整が用意されている。読み上げ原稿を作る、合成する、聞き直して直す、という一連の作業を 1 つの UI で回せる構成になっており、外部ツールを繋ぐ手間を減らす方向に振っている。

配布形態は 3 つ、依存とモデルの入手は別問題

導入経路は Windows の整合包 (portable_v0.7)、Colab ノートブック、ローカル環境、Docker の 4 つが README に示されている。Docker は docker-compose.webui.yml と docker-compose.api.yml に分かれ、環境変数は .env.webui と .env.api で設定する。ローカルの場合は docs/dependencies.md の依存関係を先に整え、モデルダウンロードの手順に従って必要なモデルを取得する必要がある。ここが実運用で最初に詰まる箇所で、整合包や Colab はこの手順を肩代わりする代わりに、環境の自由度を下げる。どの経路を選んでも、使うモデルの重みは別途取得する前提だと考えておいたほうがよい。

AGPL-3.0 とモデルライセンスは別々に確認する

リポジトリのライセンスは AGPL-3.0 である。ネットワーク越しにサービスとして提供する形態では、AGPL の条件が改めて問題になる。加えて、対応モデル表に並ぶ各モデルはそれぞれ別のリポジトリで公開されており、それぞれのライセンスは Speech-AI-Forge のものとは独立している。つまりこのプロジェクトを導入する際には、プロジェクト本体の AGPL-3.0 と、実際に使うモデルのライセンスという 2 段階の確認が必要になる。ここは法務判断の領域なので、条件の解釈は自組織の法務に確認するとして、少なくとも「どのモデルをどの配布形態で使うか」を決めた上で照合する順序にしておきたい。

1 モデル固定の運用には重すぎる

このプロジェクトの価値は複数モデルを横並びで扱える点にある。逆に、ChatTTS だけを使うと決まっている場合、個別リポジトリを直接動かすほうが依存は少なく、更新の追従先も 1 つで済む。同様に、モデルの切り替えを許さない本番運用では、対応モデルの追加がそのまま検証対象の増加になる。モデルごとに推論の前提が異なるため、全モデルが同じ品質で動く保証はなく、README の表でも実装状況の欄がモデルごとに分かれている。もう 1 つの制約は、モデル重みの取得が利用者側の作業として残ることで、これがオフライン環境や閉域網では導入の障壁になる。比較検討の段階を終えたら、このプロジェクトを挟まずに済む構成も検討する価値がある。

編集部の結論

複数の TTS モデルを同じ API と WebUI で試し、音色や SSML の分割を比較したい開発者には向く。逆に、単一モデルを本番に固定して運用したい場合や、AGPL-3.0 の条件をクリアできない配布形態を取る場合は適さない。導入前に、docs/dependencies.md の依存関係とモデルダウンロード手順を確認し、対象モデルのライセンスが自社の利用条件と一致するかをモデルごとに照合すること。

公式情報源

1. Issues
2. lenML/Speech-AI-Forge on GitHub
3. License: AGPL-3.0
4. README
5. Releases