pocket-tts
CPU 上でローカル実行できるオープンソース TTS で、開発者やエッジアプリ開発チームがクラウド音声 API に頼らずテキストをオフライン音声へ変換するのに向いています。
ツール概要
判断としては、「ローカル/オフラインで動き、CPU で回せて、アプリに組み込みやすい音声合成」が欲しいなら pocket-tts はかなり有力です。一方で、完成済み商用基盤、公式モバイル SDK、実運用での高スループット実績を重視するなら、現時点の証拠だけでは断定できません。これは音声アシスタント全体でも ASR でもチャットモデルでもなく、より近いのは「軽量で配備しやすい音声出力エンジン」です。
実際の役割として、公式 GitHub と複数の投稿では、約 100M パラメータで CPU 動作する点、ストリーミング TTS、音声クローン、ローカル処理によるプライバシー用途が繰り返し強調されています。初回音声までの遅延、6言語、Android へのコミュニティ移植といった話もありますが、多くは転載やデモ紹介です。つまり注目度の証拠にはなりますが、安定品質の証明としては弱めです。能力判断に比較的使いやすいのは公式リポジトリと、ベンチマークで「最も遅いが最も面白い」とする比較コメントで、強みが絶対速度よりローカル性と柔軟性にあることを示しています。
コストと導入負荷について、証拠で比較的明確なのは「オープンソース」「MIT ライセンス」「CPU で動く」「クラウド API 依存を減らせる」という点です。ホスト型 SaaS ではないため公式料金表は確認できません。固定ハードウェア費用、正式なモバイル対応範囲、長期運用コストについても十分な裏取りはありません。したがって保守的には、費用は API 従量課金よりも、自前計算資源・統合工数・性能調整の負担として考えるべきです。音声モデル配備や音声パイプライン、端末最適化の経験がないチームには一定のハードルがあります。
向いているのは、オフライン音声アシスタント、プライバシー重視の読み上げ、エッジ Agent、組み込み読み上げ、ローカル AI 実験を作る開発者です。逆に、完成済み音声プラットフォームを買いたい人、強い SLA が必要な企業、箱から出してすぐ全音声体験を作りたいチームには今のところ不向きです。証拠の質としては、GitHub の伸びと X の拡散が中心で、ランキング系・紹介系の投稿が多く、深い実測や長期レビューはまだ少なめです。Zhihu には技術解説がありますが、二次整理的な色もあります。総じて「CPU ローカル TTS として面白い」という合意は強い一方、「最も使いやすい・最も安定・最も安い」まで言うには検証サンプルが足りません。