322種の声、142言語、サーバーなし — ブラウザタブにそれだけの音声を収める方法
PrivateAIの音声合成ツールは322以上の声、142言語をすべてオンデバイスでカバーする。速度ではなく「声と言語のカバー範囲」こそがブラウザ型TTSの本当の難所である理由と、オープンソース勢・有料クラウドAPIとの比較。
見過ごしてしまいそうな数字
ブラウザ完結型AIツールの紹介記事は、たいてい同じ見出しに落ち着く。「何もアップロードされない」「サーバーを介さない」というものだ。PrivateAIにもその枠組みは当てはまるが、その音声合成(TTS)ツールにはもう一つ、見過ごされがちな数字がある。322以上の声、142言語を、ユーザー自身のGPU上だけで生成できるという点だ。別に用意された音声認識(STT)ツールも99言語をカバーする。これは「アップロード不要」を謳うためだけのブラウザデモの仕様ではない。むしろ規模感としては、従量課金制のクラウドAPIが提供する水準に近い——それをアカウント登録もサーバーも料金も無しで実現している。
難しいのは速度ではなく「カバー範囲」
オンデバイスAIについての報道の多くは速度に注目する。かつてはそれこそが障壁だったからだ。WebGPUがほとんどのブラウザに行き渡ったのはここ数年のことで、それ以前はクライアント側で実用的なモデルを動かそうとすれば、遅くぎこちないデモにしかならなかった。しかし速度とカバー範囲はまったく別の技術課題だ。単一言語・単一の声のモデルは、コンシューマー向けハードウェアではすでに解決済みの問題と言える。一方で142言語・数百種類の声をカバーするには、言語(または言語系統)ごとに個別のモデルを多数バンドルするか、あるいは一つのモデルにそれだけの音韻・韻律的な多様性を持たせつつ、ブラウザタブが現実的にダウンロード・保持できる範囲に収めるかのいずれかが必要になる。どちらの道も無償では手に入らない。ブラウザで動くローカルTTSプロジェクトの大半が、はるかに少ない言語数しか対応していない理由はここにある。
オープンソース勢が実際に提供しているもの
クライアント側で音声合成を動かす際によく引き合いに出される二つのエンジンを見ると、その差がよくわかる。Apache 2.0ライセンスで公開され、TTS Arenaのリーダーボードで首位に立った8,200万パラメータのモデルKokoroは、英語・日本語・中国語・スペイン語・フランス語・ヒンディー語・イタリア語・ポルトガル語・韓国語という9つの言語バリエーションにまたがる54種類の声を提供し、重みはブラウザストレージにキャッシュされ、合成はWebGPUまたはWebAssembly上で動作する。Home Assistantなどのプロジェクトでも採用されている定評あるローカルTTSエンジンPiperは、さらに幅広く、30以上の言語にわたる100以上の声をカバーしており、GPUを必要とせずWebAssembly上で動作する。どちらも実在の、活発にメンテナンスされているプロジェクトであり、それでも142言語には遠く及ばない。ここにPrivateAIの数字が注目に値する理由がある。それは単に「たまたまローカルで動くTTS」ではなく、ブラウザ完結という同じ制約の下で作られたオープンソースエンジンよりも、汎用のクラウド音声APIに近い言語カバー範囲を、ローカルTTSとして実現している点だ。
有料の代替手段にはいくら払うことになるか
この比較のもう一方の軸は、これだけのカバー範囲をクラウド側で提供しようとした場合に通常かかるコストだ。カバー範囲と品質でよくベンチマーク対象となる音声AIプラットフォームElevenLabsは、Flash/Turboモデルで1,000文字あたり0.05ドル、Multilingual v2/v3モデルで1,000文字あたり0.10ドルを課金しており、有料ティア全体での音声ライブラリはおよそ3,000種類にまで及ぶ。AzureのText-to-Speechサービスは、ニューラル音声を100万文字あたり16ドル、新しいHDティアでは100万文字あたり22ドルで提供しており、月間50万文字までの無料枠がある。クラウドAPIとしてはどちらも妥当な価格設定だが、いずれも従量課金であることに変わりはない。合成される文字数だけ、どこかでベンダー側に実際のGPU計算コストが発生するからだ。同等の言語数をユーザー自身のGPU上に持たせるツールは、その料金メーターを値引きするのではなく、構造そのものによって回避している。
ブラウザタブが実際に選んでいるトレードオフ
だからといって、オンデバイスTTSが単純に「クラウドより優れたアーキテクチャ」だというわけではない。特定の用途に適した、別の設計だということだ。音声合成、OCR、背景除去といった、範囲を絞り込んだツールがブラウザタブの中でうまく動く理由——そして自由度の高い推論モデルがそうはいかない理由——は、それらがコンシューマー向けGPUの実際のメモリと計算能力に収まる大きさだからだ。声と言語のカバー範囲を広げることは、まさにこの制約と正面からぶつかる。モデルを速くすることより、デバイスが処理しきれる範囲を超えずに142言語を流暢に扱えるようにすることの方がずっと難しい理由はここにある。
仕様上の数字にとどまらない意味
日本語の図面を読む製造業チーム、複数の市場をまたいで記録される会議メモ、異なる文字コードの時代に作られたレガシーシステム——他の5つのプロダクトが、必然的に複数言語をまたいで働く人々のためのツールを作っている会社にとって、サーバーもサブスクリプションもなしに142言語でテキストを読み上げるブラウザツールは、小さいながらも具体的な一例になっている。オンデバイス処理が、従量課金制のクラウドサービスに「近づく」だけでなく「並ぶ」ことができるという賭けの一例だ。
サーバーなし、アカウント登録なし、142言語から選べる音声合成がどんなものか試してみたい方は、PrivateAIを無料で試す、または[email protected]までご連絡を。
実績を見る
MinuteAIからAgentKitsまで — 私たちが提供した製品とプロジェクトをご覧ください。
ポートフォリオを見る関連記事
AgentKits Memoryのハイブリッド検索は「日本語」を二度解決しなければならない
BM25は意味を取りこぼし、ベクトル検索は正確なエラー文字列を取りこぼす。AgentKits Memoryは両方を融合させているが、日本語・中国語・韓国語のクエリではキーワード検索側にもう一段の判断が必要になる。
ガイドCOBOLモダナイゼーションツールの多くは「プログラム」で止まっている。実際に移行が壊れるのは、それを呼び出す「バッチジョブ」の側だ。
COBOL中心の依存関係マッピングツールは、JCLを「ジョブ名といくつかのDD文」程度の薄いラッパーとして扱いがちだ。しかし条件コード分岐、PROCのネスト、GDGの世代管理は、それ自体が独立した制御フローを持っており、依存関係グラフから日常的に抜け落ちている。Legacy Dragonが、後付けのメタデータとしてではなく、JCLを同じASTの中の第一級言語としてパースしている理由。
ガイドAgentKits Marketingには28個のスキルがある。だが一度に読み込むのは常に5個まで
Marketing Kitの`skills-registry.json`は28個のスキルを5カテゴリーに分類し、完全な依存関係グラフを持つ。社内の調査文書は、一度に読み込む量を制限する理由をはっきり名指ししている——「コンテキスト・ロット(context rot)」だ。実際に実装されたセレクターがどう動くのか、そしてなぜそれがきっかけとなった調査提案よりシンプルなのかを見る。