WebGPU と WASM：ブラウザー内 TTS 推論の性能と使い分け

最初に結論

もしあなたが“今すぐ速く試したい”なら WebGPU、もし“どの端末でも動いてほしい”なら WASM を選ぶのが基本です。実務では、この二択を対立させるのではなく、WebGPU をプレビューや反復に使い、WASM をフォールバックや配布の安定性に使うのがいちばん扱いやすいです。

つまり、WebGPU は速度優先、WASM は互換性優先。どちらも Kokoro TTS の実用ルートであり、正しい使い分けをすればどちらかを捨てる必要はありません。

1. WebGPU が向いている場面

WebGPU の強みは、ブラウザーが GPU を使える環境で低遅延な反復ができることです。短い文章を何度も修正しながら音を確認する作業、たとえば YouTube のナレーション、製品デモ、プロトタイプの読み上げなどでは非常に相性がいいです。

• 短い修正を何度も試したい。
• ブラウザーが最新で、GPU の利用が許可されている。
• 最初のプレビュー速度を重視したい。
• ローカル環境での対話的な作業を中心にしたい。

たとえば「この一文の区切りだけ少し変えたい」という作業は、WebGPU のほうが気持ちよく回ります。返答が速いほど、スクリプトの微調整は細かくできます。

2. WASM が向いている場面

WASM の魅力は、環境依存が少ないことです。企業端末、教育機関の管理端末、GPU 制約のある環境、あるいはブラウザーのポリシーが厳しい環境では、WASM のほうが安定して動くことがあります。

• WebGPU が使えない、または不安定。
• 管理下の PC で互換性を優先したい。
• パフォーマンスはそこそこでよく、確実に動くことが重要。
• 動画制作やバッチ生成で、安定した再現性を重視したい。

WASM は派手ではありませんが、仕事道具としては非常に頼れます。特に“誰が見ても同じ結果に近い”ことが重要な環境では有利です。

3. どちらを選ぶかの簡易表

4. 長尺を安定させる分割戦略

ブラウザー内 TTS で失敗しやすいのは、長い文章を一気に処理しようとすることです。長尺の文章はメモリの負荷も大きく、途中で失敗したときの手戻りも大きくなります。おすすめは、意味の切れ目ごとに分割して、1 セグメントを 8〜20 秒程度に抑えるやり方です。

分割の目安は、文法の区切りだけではなく、聞いたときに一息つけるかどうかです。ひとつの段落に詰め込みすぎると、WebGPU でも WASM でも後半の安定性が落ちます。

• 1 セグメントは短く、修正しやすくする。
• WAV で保存して、後で編集ソフトで結合する。
• 失敗したセグメントだけ再生成する。

5. 互換性の観点で見るときの注意点

WebGPU は新しい API なので、ブラウザーやドライバー、OS の組み合わせに影響されやすいです。特定の端末でだけ遅い、あるいは初回ロードが重い、ということは珍しくありません。一方で WASM は、比較的予測しやすい動作をしやすいです。

実務では、この違いがとても大きいです。たとえば社内の複数部署で同じ音声生成フローを共有するなら、まず WASM を基準にして、WebGPU は“使える人は速い”という追加の選択肢にするほうが説明しやすいです。

6. 実際の運用フロー

1. まず WebGPU で短いサンプルを生成し、声質と句読点を確認する。
2. 問題がなければ、長い原稿を意味単位で分割する。
3. 端末によって差が出る場合は、WASM で再実行できるようにする。
4. 生成した WAV を後工程に渡し、まとめて編集する。
5. 最後に、失敗した箇所だけを再生成する。

この手順の良いところは、速度と再現性の両方を取れることです。全部を WebGPU に寄せる必要も、全部を WASM に固定する必要もありません。

7. パフォーマンスを落としにくくするコツ

• タブを複数開いて同時実行しない。
• 一度に長い原稿を読み込まず、段落単位で送る。
• 長時間使ったらタブを再起動し、メモリをリセットする。
• 出力はまず WAV にして、後で圧縮する。

このあたりの工夫は地味ですが、実際にはかなり効きます。TTS の遅さはモデルだけでなく、使い方でかなり変わるからです。

8. ありがちな誤解

よくある誤解は「WebGPU があるなら WASM は不要」というものですが、実際には逆です。WASM があるからこそ、WebGPU の不調や互換性差を吸収できます。もうひとつの誤解は「WASM は遅いから使えない」というものですが、TTS の用途では“十分に速い”ことが多いです。

したがって、比較の軸は“速いか遅いか”だけではなく、“その環境で再現できるか”“失敗したときに戻せるか”まで含めて考えるべきです。

9. 参考ワークフロー

// WebGPU: 反復と試聴
原稿 → 短い分割 → WebGPU でプレビュー → 修正 → WAV 出力

// WASM: 安定配布
原稿 → 分割 → WASM で生成 → WAV を保存 → 編集ソフトで結合

10. どちらを選んでも守るべきこと

最後に大事なのは、エンジンの違いよりも、入力と出力の管理です。脚本が雑なら WebGPU でも WASM でも結果は雑になります。逆に、脚本を整え、セグメントを小さくし、出力をきちんと保管すれば、どちらの経路でもかなり安定した音声が作れます。

11. 環境別の実践メモ

• Windows の管理端末では、まず WASM を基準に考える。
• 最新の Chrome / Edge を使えるなら、WebGPU の反復速度を活かす。
• 長時間の生成では、途中でタブを再起動する前提を持つ。
• 同じ原稿を複数回試すなら、ファイル名とセグメント番号を固定する。

このメモは小さいですが、現場ではかなり効きます。ブラウザー TTS は“モデル性能”より“運用の癖”で差が出ることが多いからです。

12. 迷ったときの判断フロー

GPU が使える？ → はい → まず WebGPU で試す
                        → いいえ → WASM で進める

出力が長い？ → はい → セグメントを短くする
             → いいえ → 通常の分割で十分

判断フローを単純にしておくと、毎回の意思決定コストが下がります。迷う時間を減らすこと自体が、かなり大きな最適化です。

著者：Kokoro Web チーム • 最終更新 2025‑01‑15