日本語の読み上げを組み込みたくて、TTS を探している。品質のいいものは値段が高く、安いものは読み間違いが多い。そこへ2026年7月20日、Alibaba の Qwen-Audio-3.0-TTS が出た。独立系の評価で首位、価格は競合の約3分の1。ただしダウンロードできる重みは無い。Qwen という名前から受ける印象と、実際に手に入るものが食い違っている。
目次
公開されたものの中身
Alibaba の Tongyi Lab がリリースしたのは、Alibaba Cloud Model Studio 経由でのみ使えるホスト型のモデルだ。2つのティアがある。
| ティア | 特徴 | 向いている用途 |
|---|---|---|
| Flash | 遅延およそ300ミリ秒。リアルタイム向け | 対話・読み上げの即時応答 |
| Plus高品質 | Artificial Analysis の音声アリーナで首位(Elo 約1,236) | 収録・配信など品質優先の用途 |
対応は16言語と中国語20方言で、日本語が含まれる。価格は100万文字あたり $27.59 とされ、ElevenLabs や MiniMax の3分の1程度という比較が出ている。7月21日に公開された Qwen-Image-3.0 も同じく API 限定で、重みの配布は無かった。2本続けて同じ形だったことが、単発の判断ではない可能性を示している。
「Qwen だからローカルで動く」が崩れた
Qwen は、これまでオープンウェイトを出し続けてきた系列だ。手元に落として動かす前提で選んでいた人にとって、今回の2本続けての API 限定は方針の変化に見える。
筆者はできる処理をローカル完結で組むのが好みで、文字起こしも背景除去もオフラインで動く形にしてきた。機密を含むデータを外に出さない構成にしておくと、後から用途が広がっても困らないからだ。その視点で見ると、今回のモデルは品質の話をする前に、選択肢の性質が違う。
例えるなら、これまで工具を売っていた店が、同じ看板で工事の請負を始めたようなものだ。仕上がりは良くても、工具は手元に残らない。次に同じ工事をしたければ、また頼むことになる。
重みが無いことで何が変わるか
音声合成を製品や記事に組み込むとき、筆者が見ている軸は3つある。コスト、データの外部送信、商用可否。重みの有無はこの3つ全部に効く。
| 軸 | ホスト型API(今回のモデル) | ローカル完結(VOICEVOX 等) |
|---|---|---|
| コスト | 使った文字数だけ。大量になると積み上がる | 初期の環境構築のみ。以後は電気代 |
| データの外部送信 | 読み上げる原稿が全部サーバへ渡る | 外へ出ない |
| 商用可否 | 提供元の規約に従う。改定されうる | ライセンス条文で確定できる |
| 撤退のしやすさ見落とし注意 | サービス終了・値上げに対処できない | 手元に残るので使い続けられる |
最後の行が、重みの有無でいちばん差が出るところになる。API 提供が止まれば、その音声で作った資産の続きが作れない。声を揃えて連載や動画シリーズを作っていた場合、途中から声が変わる。
個人開発者にとっては、この撤退リスクが値段より重いこともある。月に数千円の差より、2年後に同じ声を出せるかどうかのほうが効く場面がある。
止まったときに何が起きるか
具体的に想像しておくと判断しやすい。連載記事の読み上げ版を毎週出しているとする。50本を同じ声で作った時点で、API の提供が終わる。
選べる道は3つで、どれも代償がある。別のサービスで似た声を探す(完全には揃わない)、以降の回だけ声を変える(読者は気づく)、過去50本を新しい声で作り直す(費用と時間がかかる)。重みが手元にあれば、この状況自体が起きない。
この想定が大げさに感じるかどうかは、作るものの寿命による。1回きりのデモ音声なら考えなくていい。毎週積み上げる資産なら、最初に考えておく価値がある。
日本語で試すときに測る項目
リーダーボードの順位は英語圏の評価が中心になりやすい。日本語で使うなら、自分の原稿で測り直したい。筆者が確認する項目を挙げる。
固有名詞と専門用語の読み。技術記事の読み上げなら、製品名・英略語・バージョン番号が正しく読まれるか。「v2.1.216」「MCP」「WordPress」あたりは差が出やすい。
数字と単位。「1M トークン」「$27.59」「約300ミリ秒」のような表記が自然に読まれるか。ここは前後の文脈で読み方が変わるので、モデルの理解度が出る。
間の取り方。句読点での息継ぎ、箇条書きの区切り。長い原稿ほど、ここが疲れやすさに直結する。
# 同じ原稿を複数のTTSに投げて、聞き比べ用のファイルを揃える
# 原稿は自分の記事から抜く(読み上げの本番に近い文章で測る)
python tts_bench.py --text sample_ja.txt --out out/qwen_plus.wav --engine qwen-plus
python tts_bench.py --text sample_ja.txt --out out/qwen_flash.wav --engine qwen-flash
python tts_bench.py --text sample_ja.txt --out out/local.wav --engine voicevox
# 応答時間も一緒に記録する(体感はレイテンシで決まる場面が多い)
# 判断は耳で行う。数値スコアだけで決めない
数値のスコアだけで決めないのは、視覚出力の検証と同じ理由だ。指標が良くても、実際に聞いて不自然なら使えない。Whisper で文字起こしアプリを作った回でも、認識率の数字と実際の使い勝手が一致しない場面が何度もあった。
入力と出力を混同しない
音声まわりの話題は、認識(音声→文字)と合成(文字→音声)が同じ文脈で語られやすい。用途はまったく別で、選び方も違う。
認識のほうは、手元のマイクで録った音をローカルで処理できる。日本語向けモデルの比較で書いたとおり、日本語特化のモデルを選べば個人の機材でも実用になる。外に出さずに済む。
合成のほうは、品質の上限がまだホスト型のほうに寄っている。今回のモデルの順位は、その現状を示している。認識はローカル、合成は品質次第でAPIという組み合わせは、現実的な妥協点になりうる。
サイトに読み上げを足すかどうか
技術記事に音声版を付ける案は、以前から頭の片隅にある。移動中に聞ける形があれば読者の選択肢は増えるし、目が疲れているときに助かる場面もある。品質の高い TTS が安くなると、この検討が現実味を帯びる。
踏み切っていないのは、更新のたびに作り直しが発生するからだ。技術記事は公開後に直すことが多い。バージョン番号が変わった、手順が1つ増えた。テキストなら1行の修正で済むところが、音声だと該当箇所を作り直して差し替える作業になる。
50本の記事に音声を付けたとして、そのうち何本が半年後に修正されるか。筆者のサイトの更新頻度で考えると、無視できない数になる。音声版は、テキストを直すコストを静かに何倍かにする。
この見積もりが変わるとしたら、生成を自動化して更新のたびに丸ごと作り直す形にしたときだ。1記事の生成費用が十分に安ければ、差分を管理せず毎回作り直すほうが運用は楽になる。100万文字あたり $27.59 という価格は、その計算を検討する水準には入っている。
重みが無いことを、実際に探して確かめた
「重みが無い」は記事の土台なので、名前で調べて終わりにせず実際に探した。HuggingFace の API を叩いて検索している。
| 検索語 | 件数 | 中身 |
|---|---|---|
qwen audio 3 tts |
0件 | 該当なし |
Qwen-Audio-3 |
20件 | すべて Qwen2 / Qwen3-Omni の派生。3.0-TTS そのものは無い |
Qwen/Qwen-Audio |
2件 | 旧世代の Qwen-Audio と Qwen-Audio-Chat |
0件を根拠にする前に、検索が生きているかを確かめた。Qwen2-Audio で20件(Qwen/Qwen2-Audio-7B が実在)、kokoro tts で20件が返る。器具は動いていて、そのうえで 3.0-TTS だけが出てこない。
OpenRouter でも同じことをした。364モデルのうち qwen と audio または tts の両方に当たるものは0件。音声を出力できるモデルまで広げて数えると4件で、内訳は Google の Lyria 2件と OpenAI の gpt-audio 2件だった。Qwen の TTS はどちらの経路にも無い。
撤退できる側には何があるか
「撤退できるか」で選ぶという判断は、代わりに何を持っているかで意味が変わる。手元を数えた。
ローカルで動く TTS を1本持っている。自作の IrodoriTTS で、推論スクリプトと GUI、チェックポイントの変換まで込みで58ファイル。ホスト側の都合で止まることがない。
文字起こし側も同じで、faster-whisper を包んだ自作の MCP サーバがローカルで動く。実測では、温まった状態で4.6秒の音声を1.0秒で文字にした。
この2つがあると、ホスト型を採用するかどうかを「品質が上回るか」だけで判断できる。動かなくなったときに戻る先があるので、撤退のコストを見積もる作業が要らない。逆に戻る先を持っていない状態でホスト型に寄せると、判断の重さが変わる。
未検証: Qwen-Audio-3.0-TTS の音質は聴いていない。DashScope のキーを持っておらず、ホスト経由でも試していない。上で確かめたのは重みの不在と、手元の代替の有無だけになる。
筆者ならこう判断する
用途を2つに分けて考える。作り直しがきく用途なら API を使う。記事の下読み、下書きの確認、一時的なデモ音声。声が変わっても影響が小さい。
資産として積み上がる用途には、重みが手元にある選択肢を優先する。シリーズものの読み上げ、製品に組み込む音声、長期運用のアプリ。ここで API に寄せると、提供元の都合が自分の資産の寿命になる。
価格が3分の1という点は魅力的でも、それだけで本番に入れる判断はしない。過去に、外部APIの機能を確認不足のまま全経路へ組み込んで動かなくなった経験がある。以来、新しい外部サービスは単発で疎通を確かめてから、限定的な経路に入れるようにしている。代替に切り替えられる形を残しておけば、値上げにもサービス終了にも対処できる。
よくある疑問
いずれ重みが公開される可能性は。過去の Qwen 系にはオープンウェイトの実績がある。今回の2本が API 限定だった事実は残るので、公開を前提に設計するのは避けたい。
商用利用は可能か。Alibaba Cloud Model Studio の規約に従う形になる。規約本体を読んでから判断したい。生成した音声の権利まわりは、TTS では特に確認しておきたい箇所になる。
ローカルの日本語TTSで代替できるか。用途による。ナレーション品質を求めると差は残る。読み上げの内容が分かればいい用途なら、ローカルで足りる場面が多い。動作確認用の読み上げや、自分だけが聞く下読みは後者に入る。
まとめ
今回のモデルは、品質と価格では選ぶ理由がある。判断を分けるのはその音声が資産として積み上がるかどうかだ。作り直しがきく用途なら使えばいいし、長く同じ声を出し続ける必要があるなら、手元に残る選択肢を優先する。
試すなら、自分の記事から300字ほど抜いて読み上げさせるところから始めるといい。固有名詞の読み間違いが1つでもあれば、そこが運用の手間になる箇所として見えてくる。読み方の指定でごまかせる範囲か、原稿側を書き換える必要があるかも、その300字で見当がつく。
一次ソース: Alibaba’s Tongyi Lab Releases Qwen-Audio-3.0-TTS(MarkTechPost)