MOSS-TTS ファミリーを採用前に読む: 4系統のモデルと Apache-2.0 の境界
An open-source model family for long-form speech, dialogue synthesis, voice design, sound effects, and real-time streaming TTS
ひと目でわかる
- これは何？
- MOSS-TTS は長文ナレーション、多話者対話、効果音、リアルタイム配信を1つのリポジトリ群で扱う音声生成モデルファミリーである。用途ごとにモデルが分かれており、選定を誤ると不要な GPU を抱えることになる。
- 誰に向いている？
- 長文ナレーションや多言語の読み上げを自前で動かしたいチームは MOSS-TTS-v1.5 から試すのが妥当で、音声のデザインや効果音が目的なら MOSS-VoiceGenerator や MOSS-SoundEffect v2 を別モデルとして見る必要がある。CPU 4コアで足りるかどうかが要件なら MOSS-TTS-Nano が別リポジトリにあるので、そちらの README を先に読むべきだ。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 10 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
1つのリポジトリに4種類の音声タスクが同居している
MOSS-TTS は単一のモデルではなく、用途別に分かれたモデル群の総称である。README のタスク選択表は、CPU やブラウザでの音声合成とボイスクローンには MOSS-TTS-Nano、多言語の長文ナレーションとボイスクローンには MOSS-TTS-v1.5 と Local Transformer v1.5、多話者対話やポッドキャスト、吹き替えには MOSS-TTSD、リアルタイム配信には MOSS-TTS-Realtime、音声デザインや環境効果音には MOSS-VoiceGenerator と MOSS-SoundEffect v2 を挙げている。つまり「MOSS-TTS を入れる」という判断は成立せず、どの系統を入れるかまで決めて初めて作業量が見える。Nano と TTSD は別リポジトリとして切られており、このリポジトリの README はそれらへの入口として機能している。対象読者は、商用クラウドの TTS API を自前の推論基盤に置き換えたいと考えているエンジニアと、吹き替えや効果音の生成をパイプラインに組み込みたい制作側の技術者である。
MossTTSLocal 系とトークナイザの分離という構成
v1.5 系の骨格は Qwen3 系のバックボーンに音声トークナイザを組み合わせる形で、2026.6.18 のリリースでは MOSS-TTS-Local-Transformer-v1.5 がバックボーンを Qwen3-1.7B から Qwen3-4B へ拡大し、MOSS-Audio-Tokenizer-v2 を使って 48 kHz ステレオをネイティブに扱うと説明されている。ここで重要なのは、音声の入出力仕様がモデル本体ではなくトークナイザ側に属するという点だ。MOSS-Audio-Tokenizer-v2 は 48 kHz ステレオの入出力に対応し、専用リポジトリ MOSS-Audio-Tokenizer で配布されている。したがってサンプルレートを上げたいのか、多言語の安定性を上げたいのかで、差し替える対象が別になる。アーキテクチャ名も系統ごとに分かれており、SGLang-Omni の告知では MossTTSLocal が最初にサポートされた構成として挙げられ、vLLM-Omni 側の告知では MossTTSDelay、MossTTSRealtime、MossTTSNano の3つが対象として列挙されている。推論バックエンドを選ぶときは、自分の使いたい系統がそのバックエンドの対象アーキテクチャに入っているかを先に照合する必要がある。
長文とポーズ制御をどう扱うか
v1.5 の変更点として README が挙げているのは、言語タグを与えたときの多言語合成の強化、ボイスクローンの安定性向上、長い参照音声に対する短いテキストのクローン品質、句読点に追従する韻律、そして [pause X.Ys] による明示的なポーズ制御である。読み上げ原稿の途中に意図的な間を入れたい場合、SSML のような別レイヤを用意せずテキスト側にこの記法を埋め込む設計だと言える。長文ナレーションを分割せずに投入できる点は、章単位で API を叩いて継ぎ目を処理する実装を減らせる。ただし README はポーズ記法の構文以外、秒数の上限や入れ子の可否について何も述べていない。原稿生成側でこのタグを自動挿入する仕組みを作るなら、まず手元の原稿で期待どおりの間が得られるかを確認してから本番のテンプレートに組み込む順序が安全である。
配信バックエンドは SGLang-Omni と vLLM-Omni の2択
2026.6.18 の告知によれば、MOSS-TTS-Local-Transformer-v1.5 は SGLang-Omni で Day-0 サポートを受け、MossTTSLocal アーキテクチャに対応した最初の推論バックエンドになった。OpenAI 互換の /v1/audio/speech エンドポイント、ストリーミング、ボイスクローンが利用でき、cookbook として moss_tts_local と moss_tts の2つが案内されている。一方、2026.6.2 の告知では vLLM-Omni が MOSS-TTS シリーズ全体（MossTTSDelay、MossTTSRealtime、MossTTSNano）をサポートし、MOSS-TTS-v1.5、MOSS-TTS、MOSS-TTSD、MOSS-SoundEffect、MOSS-VoiceGenerator、MOSS-TTS-Realtime、MOSS-TTS-Nano が対象だとされている。既存の推論基盤がどちらかに寄っているなら、その側のレシピを読むのが最短になる。逆に、複数系統を1つのサービスにまとめたい場合は、vLLM-Omni 側の対象範囲のほうが広いと告知されている点を出発点にできる。なお、どちらの cookbook も外部リポジトリにあるため、この記事の範囲では実際の起動コマンドまでは確認できていない。
導入時に確認する重みとライセンスの2層
重みの配布元は Hugging Face のコレクションと ModelScope のコレクションの2系統が README に示されている。モデルごとに個別のリポジトリがあるため、取得先の URL は系統ごとに書き換わる。リポジトリ本体のライセンスは Apache-2.0 と表示されているが、これはコード側の条件であり、各チェックポイントのモデルカードが同じ条件を課しているかは README からは読み取れない。商用利用の可否を判断する立場なら、コードのライセンスと重みのライセンスを別々に確認する必要がある。ここは当サイトが法的助言を与えられる領域ではないので、条件の解釈は自組織の法務やコンプライアンス担当に委ねてほしい。実務上は、採用候補を絞った時点で対象モデルのカードを開き、再配布や出力物の扱いに関する記述を確認する作業が1回発生する。
CPU 4コアという選択肢と、それが使えない場面
MOSS-TTS-Nano は約 100M パラメータのモデルとして案内され、多言語のボイスクローン、48 kHz ステレオの入出力、ストリーミング出力を 4 CPU コアで動かせると README は述べている。GPU を確保せずに読み上げ機能を組み込みたい場合、これが現実的な出発点になる。ただし Nano は別リポジトリであり、このリポジトリの README には具体的な起動コマンドや設定キーが載っていない。CPU 前提の検証をするなら、まず MOSS-TTS-Nano 側の README を読む必要がある。もう1つの制約は用途の分離そのもので、読み上げと効果音を同じモデルで処理する構成は用意されていない。MOSS-SoundEffect v2 は DiT バックボーンに Flow Matching 目的関数を使い、48 kHz のバイリンガル効果音を最大30秒生成すると説明されており、系統として独立している。1つのエンドポイントで両方を返したい設計なら、モデルを2つ立ててルーティングする実装を自分で書くことになる。
対話合成を求めるなら MOSS-TTSD を見るべき理由
多話者対話、ポッドキャスト、吹き替えが目的の場合、README は MOSS-TTSD を出発点として指定し、別リポジトリへ誘導している。MOSS-TTS-v1.5 の説明には話者交代の扱いに関する記述がなく、長文ナレーションとボイスクローンが中心である。したがって、対話の掛け合いを1回の推論で生成したいという要件は、v1.5 では満たせない可能性が高い。技術レポートも MOSS-TTSD と MOSS-VoiceGenerator について別々に公開されていると告知されており、モデルごとに設計思想が異なることがうかがえる。代替として、クラウドの TTS API を話者ごとに呼び分けて自前で会話を組み立てる方法もあるが、その場合は発話の重なりや間の制御をすべてアプリケーション側で持つことになる。MOSS-TTSD を選ぶかどうかは、この制御をモデルに任せるかアプリケーションに残すかの判断とほぼ同義である。
mlx-audio と派生ツールの位置づけ
2026.5.6 の告知では MOSS-TTS と MOSS-Audio-Tokenizer が mlx-audio をサポートすることが示され、詳細は mlx-audio 側のリポジトリに委ねられている。Apple Silicon 上で動かしたい場合の入口はここになるが、対応の範囲や制限はこの README からは分からない。同種の外部連携として、OpenClaw の Skills へのリンクもバッジとして貼られている。こうした派生ツールは本体の更新に追随するとは限らないため、依存を決める前に最終更新を確認する価値がある。このリポジトリ自身の最終 push は 2026.9.6 と記録されているが、派生側の更新状況は別途見る必要がある。
編集部の結論
長文ナレーションや多言語の読み上げを自前で動かしたいチームは MOSS-TTS-v1.5 から試すのが妥当で、音声のデザインや効果音が目的なら MOSS-VoiceGenerator や MOSS-SoundEffect v2 を別モデルとして見る必要がある。CPU 4コアで足りるかどうかが要件なら MOSS-TTS-Nano が別リポジトリにあるので、そちらの README を先に読むべきだ。逆に、1つのチェックポイントで読み上げと効果音の両方を賄いたい場合、このファミリーは用途ごとにモデルが分かれているため候補にならない。導入前に確認すべきは、MOSS-Audio-Tokenizer-v2 を使う構成かどうかで出力が 48 kHz ステレオになる点と、配信に SGLang-Omni か vLLM-Omni のどちらの cookbook を使うかである。重みの取得元は Hugging Face と ModelScope の2系統があり、ライセンスはリポジトリ側が Apache-2.0 と表示されているが、重みごとの条件は各モデルカードで別途確認する必要がある。
コミュニティノート