MOSS-TTSはCPUで使える？爆速のNano、沈黙のメインモデル

ざっくりまとめ

• Nano は“実用速度”、1.7B は高品質だが CPU では非現実的

• Windows でのセットアップ手順を、つまずきポイント込みで解説

• 1.7B を CPU で動かすとどうなるか、実測と体験を共有

1. はじめに：LLMが動くなら、次は「声」もローカルで

最近、Gemma 4やQwen 3.6といったLLMをローカル環境で動かす検証を続けてきました。手元のノートPCでも、そこそこの速度でテキストが返ってくるようになると、次に欲しくなるのは、やっぱり「声」なんですよね。

ChatGPTのように、生成されたテキストをその場で自然なイントネーションで読み上げてほしい。それもクラウドのAPIを使うのではなく、できれば自分のPC内だけで完結させたいな、と考えたのが今回のきっかけです。

ローカルの音声合成といえば「VOICEVOX」が定番ですが、最近はTransformerベースの新しいモデルも次々と登場しています。「最新のモデルなら、もっと表現力が高いんじゃないか？」という、ちょっとした好奇心が湧いてきたんですよね。

そこで今回は、プロジェクトは2024年末から注目され、今回のLocalモデルは2026年2月に登場したばかりの最新モデル「MOSS-TTS」を触ってみることにしました。

GPUを積んでいない、ごく普通のビジネス向けノートPCで、最新の音声合成はどこまで実用的に動くのか。実際にセットアップして試してみた結果を共有したいと思います。

2. 動作環境：メモリ32GB / GPUなし

今回の動作に使ったのは、最近のビジネス向けノートPCとしては少し足腰が強めなこちら。
　・プロセッサ: AMD Ryzen AI 5 PRO 340 (2.00 GHz)
　・メモリ: 32.0 GB
　・GPU: なし
　・OS: Windows 11

環境構築には「Miniconda」を使いました。 サクッと専用の仮想環境を作って、必要なライブラリを流し込む。この「自分だけの実験場」をパパッと用意できる身軽さが、ローカルAIを触る時の楽しさでもありますよね。

GPUがない普通のノートPCで、Transformerベースの最新TTSがどこまで動くのか。コストをかけない条件で、どこまで「実用」に近づけるかを探ってみます。

3. MOSS-TTS：軽量なNanoと、重量級のメインモデル動作環境：メモリ32GB / GPUなし

今回、「MOSS-TTS」を選んだのは、Transformerを中核に据えた最新のアーキテクチャに強く惹かれたからです。

これまでローカル環境での音声合成といえば「VOICEVOX」などが主流でしたが、2024年末以降、LLMと同じ仕組みであるTransformerを用いた音声生成モデルが、ものすごいスピードで進化してきました。

MOSS-TTSは、OpenMOSS Team によって2026年2月に公開されたばかりの新しいモデル。純粋なTransformer構成を採用しているのが最大の特徴で、従来方式よりも「発話の流れ」や「細かなニュアンス」をより自然に扱えるとのことで、「試してみようかな」と思いました。

モデルのラインナップは、次のように整理できます。

$$
\begin{array}{c|c|l} \rule{0pt}{2em} \text{モデル名} & \text{パラメータ数} & \text{特徴} \\[10pt] \hdashline \rule{0pt}{2em} \text{Nano} & \text{約0.1B（1億）} & \text{CPU動作を前提とした軽量版。機動力は抜群。} \\[10pt] \hdashline \rule{0pt}{2em} \text{Local / 1.7B} & \text{1.7B（17億）} & \text{Qwen3-1.7Bベースのバランス型。品質と動作性を両立。} \\[10pt] \hdashline \rule{0pt}{2em} \text{Delay / 8B} & \text{8B（80億）} & \text{大規模モデル。最高品質だが、動作にはGPUが必須。} \\[10pt] \hline \end{array}
$$

技術的な中身を少し覗くと、MOSS-TTSは「Causal Audio Tokenizer（CAT）」を用いた離散音声トークナイズを採用しています。

面白いのは、「時間方向を扱うGlobal Transformer」と、「音の細部を補完するLocal Transformer」という二段構えの構造で音声を生成する点です。 これは、LLMが次の単語を予測するように、「次に続く音」を自然に紡ぎ出そうという設計なんですね。難しい用語が並びますが、要するに「楽譜全体を眺める指揮者」と「一音一音を丁寧に奏でる演奏者」が二人三脚で声を作っているイメージです。

公開されている評価（Seed-TTS-evalなど）でも、話者の再現性（Speaker Similarity）や音質の高さが確認されています。コミュニティでも「オープンソースとしてはかなり高い水準にある」という声が多く、一部の非公開モデルにも引けを取らないのでは……という期待感があるモデルなんです。

4. 環境の構築：Nanoモデルのセットアップと評価

ここからは、実際にNanoモデルを動かすまでの手順をまとめていきます。 軽量版とはいえ、Windows環境で音声合成のライブラリを整えるのは、それなりに骨が折れる作業でした。特にテキスト処理を担う「pynini」というライブラリには、正直、何度も心を折られそうになりました（笑）。

私が最終的に安定して動かすことができた手順を共有します。初心者の方でも、この通りに進めれば「とりあえず動く」状態まで持っていけるはずです。

1. 仮想環境の作成と有効化
まずは、他のプロジェクトと干渉しないよう、Minicondaで専用の環境を作ります。今回は Python 3.11 を選択しました。執筆時点での最新は 3.13 ですが、AI関連のライブラリ（特に pynini や onnxruntime）は、最新バージョンへの対応が遅れることがよくあります。現時点で最もライブラリの互換性が高く、トラブルが少ない「安定の選択肢」として 3.11 を選んでいます。

# 新しい環境を作成
> conda create -n moss-tts python=3.11 -y

# 環境を有効化
> conda activate moss-tts

2. コードの入手と「pynini」の攻略
リポジトリをクローンした後、最大の難所である pynini をインストールします。ここは通常の pip ではなく、conda-forge を利用するのが確実です。

# コードを入手
> git clone https://github.com/OpenMOSS/MOSS-TTS-Nano
> cd MOSS-TTS-Nano

# pynini を conda-forge からインストール（ここが重要です）
> conda install -c conda-forge pynini=2.1.6 --force-reinstall -y

3. 依存ライブラリのインストール
次に、必要なライブラリをまとめて入れていきます。一部、依存関係を無視してインストールしたり、エラーが出てもそのまま進めて良い箇所があります。

# WeTextProcessing を依存関係を無視してインストール
> pip install WeTextProcessing>=1.0.4.1 --no-deps

# CPU版のTorchを優先してインストール
> pip install torch==2.7.0 torchaudio==2.7.0 --index-url https://download.pytorch.org/whl/cpu

# その他の必須ライブラリ
> pip install numpy>=1.24 sentencepiece>=0.1.99 transformers==4.57.1 soundfile onnxruntime>=1.20.0

# 以下のコマンドは環境によってエラーが出ることがありますが、無視して大丈夫です
> pip install importlib_resources

# テキスト処理に必要な辞書系を補完
> pip install jieba pypinyin

4. 常駐型のGUI（Gradio）で動かす
環境構築が完了したので、動かしていきます。

# GUI用のライブラリをインストール
> pip install gradio

# サーバーを起動
> python app_onnx.py

ブラウザで http://localhost:18083/ にアクセスして動かします。

一度サーバーを立ち上げてしまえば、モデルがメモリに載った「スタンバイ状態」になるため、生成ボタンを押してから音声が出るまでは わずか1〜2秒程度。まさに「一瞬」という感覚で、ローカルLLMの回答をリアルタイムに読み上げさせるような用途にも、これなら十分に応えてくれそうですが、品質は、う～ん、まぁ。

5. 環境の構築：1.7Bモデルのセットアップと評価

Nano版で手応えを掴んだので、次はいよいよ高品質な「Local（1.7B）版」に挑戦しました。 パラメータ数が増えるだけかな、と軽く思っていたのですが、ライブラリのバージョン不整合でかなり苦労してしまいました。なので、ここから少し難易度が上がります。

環境構築：Nano版とは別の「箱」を用意する
Nano版の環境を汚さないよう、新しく moss-tts-full という環境を作って進めます。

# 新しい環境を作成 (Python 3.11)
> conda create -n moss-tts-full python=3.11 -y
> conda activate moss-tts-full

# MOSS-TTS の標準コードを入手
> git clone https://github.com/OpenMOSS/MOSS-TTS
> cd MOSS-TTS

ここでも pynini 周りの設定が必要ですが、Nano版での成功体験をそのまま流用します。

# pynini と WeTextProcessing のインストール
> conda install -c conda-forge pynini=2.1.6 -y
> pip install WeTextProcessing>=1.0.4.1 --no-deps

# CPU版のTorchと追加ライブラリ
> pip install torch==2.7.0 torchaudio==2.7.0 --index-url https://download.pytorch.org/whl/cpu
> pip install "huggingface_hub>=1.5.0,<2.0" "transformers>=5.0.0"
> pip install -U gradio accelerate safetensors numpy>=1.24 sentencepiece>=0.1.99 soundfile

重みのダウンロード：承認が必要な「壁」
1.7Bモデルの重みを入手するには、Hugging Faceで公式のアカウント承認が必要でした。OpenMOSS-Team/MOSS-TTS-GGUF にアクセスし、「Agree and access repository」をクリックして承認を得てから、以下のコマンドでダウンロードします。

# 重みのダウンロード
> huggingface-cli download OpenMOSS-Team/MOSS-TTS-Local-Transformer --local-dir ./models/moss_tts_local

執念の「ソースコード手術」
今回、一番時間がかかったのがここです。起動時に Gradio や Transformers の内部でエラーが多発したため、直接ソースコードを書き換える「手術」をいくつか行いました。私の試行錯誤の跡を覗いてみてください。

手術1：processing_moss_tts.py の修正
Hugging Faceからダウンロードしたキャッシュ内にあるファイルが、最新の Transformers の仕様と食い違っていました。

• ファイルの場所: C:\Users\name\.cache\huggingface\modules\transformers_modules\moss_tts_local\processing_moss_tts.py

• 修正内容: 25行目付近の MODALITY_TO_BASE_CLASS_MAPPING を AUTO_TO_BASE_CLASS_MAPPING に書き換えます。

手術2：clis/moss_tts_app.py の大規模改修
GradioのUI周りでも、スライダーの最小・最大値のチェックが厳格化されたことによるエラーが出ました。

これに対応するため、clis/moss_tts_app.py にはかなりの修正を加えています。具体的には、最新のキャッシュ管理（DynamicCache）が NoneType エラーを吐かないようにするための互換パッチを組み込んだり、UIのスライダー設定を強制的に上書きしたりといった対応です。

また、スライダー以外でも2026年現在の Transformers ライブラリの仕様と、モデルが想定している内部ロジックが衝突し、実行時にエラーを吐いて止まってしまう状態でした。これを解決するために、モデルの「深層」にまでパッチを当てる必要があったのです。

今回、私が自作した 「2026年互換性修正パッチ」 で対応した主な内容は以下の通りです。

• キャッシュ管理の再構築（DynamicCacheの修正） 最新のライブラリが期待する「Modular Cache」の挙動に合わせて、最小限のキャッシュ更新メソッドを持つ SimpleLayerCache クラスを定義し、強引に差し替えました。これにより、実行時に多発していた NoneType エラーを物理的に回避しています。

• モデル構成の同期（apply_deep_patch） モデルが自分の「層の数」や「隠れ層の設定」を正しく認識できていなかったため、設定ファイル（config）を直接書き換え、24層のレイヤー構造を強制的に同期させました。

• レイヤー番号の教え込みと位置エラー対策 各レイヤーに対して「お前は○番目の層だよ」というインデックスを改めて付与し直したり、推論時に位置情報を見失って落ちる cache_position エラーを防ぐためのダミー処理を組み込んだりしています。

正直、ここまでの作業は「ちょっとTTSを試してみたい」という方にはかなりハードルが高いはず。 そこで、私が実際に動かした 「修正済みの moss_tts_app.py」 を、記事の最後にファイルとして添付しておくことにしました。興味がある方や、同じエラーで立ち止まってしまった方は、ぜひ参考にしてみてください。

いざ起動：1.7BモデルがノートPCに問いかけるもの

執念の修正を終え、いよいよGUIを立ち上げます。1.7BモデルをCPUで動かすため、デバイス指定を忘れずに行います。

# GUI（Gradio）の起動コマンド
> python clis/moss_tts_app.py --model_path ./models/moss_tts_local --device cpu

サーバーが立ち上がったら、ブラウザ（Chromeなど）から以下のURLにアクセスします。

• URL: http://localhost:7860/

画面が表示され、テキストボックスに「こんにちは、テストです」と入力して、生成ボタンを押しました。

わずか一行の挨拶を音声に変えるのに、画面に表示されたのは「2000秒」を超える数字。しかも、これはあくまで「経過時間」です。 実際にはノートPCのファンがかつてないほどの轟音を上げ始め、筐体も熱を帯びてきたため、これ以上の負荷は危険と判断して途中で処理を停止しました。つまり、最後まで完遂させていれば、この数字はさらに膨れ上がっていたはずです。

「動く」という事実を確認できたのは大きな収穫でしたが、同時に、専用GPUを持たない一般的なノートPCにとって、1.7BクラスのTransformerモデルをCPUのみで運用するのは、現時点では「非現実的」であるという厳しい現実を突きつけられたので、そっと、ブラウザを閉じました。

期待が大きかった分、ファンが唸るだけの静かな沈黙（フリーズ）を前に、私はただ、ぬくもりを持ったノートPCを優しく撫でてあげることしかできませんでした。

6. おわりに：今のPCスペックで「声」を扱うための現実解

今回、最新のTransformerモデルを「普通のノートPC」で動かしてみた結果は、非常に明快なものでした。

一瞬で言葉を紡ぎ出す「Nano」の軽快さと、終わらなかった「1.7B」の重厚さ。同じシリーズでも、パラメータ数の違いがこれほどまでに実行速度の差として現れるのは、ローカル環境ならではの洗礼と言えるかもしれません。

もし、このスペックのPCで「リアルタイム性」を重視するなら、今回の検証範囲ではNanoモデルが有力な選択肢になります。ただ、音声合成の世界は広く、他にも「VOICEVOX」のような定番から、さらに軽量で高品質な新しいモデルが次々と登場しています。

「MOSS-TTSのNano一択」と決めるのではなく、用途に合わせて他のモデルも試しながら、自分のPCに最適な「声」の落としどころを探していくのが良さそうです。

なので、別のTTSも試してみました。

今回の私の試行錯誤が、皆さんの環境構築のヒントになれば幸いです。

修正済み moss_tts_app.py
記事の中で触れた、ライブラリの不整合を解消するために作った修正済み moss_tts_app.py を添付します。エラーが出て動かない方は、このファイルを clis フォルダ内のものと差し替えて試してみてください。動かす際の助けになればと思います。(セキュリティに不安がある方は、オリジナルファイルとのdiffを確認してから使って頂けたらと思います)