qwen-audio-3.0-tts-plus 開発者向けプロンプトレシピ

TTSプロンプトをコードと同じくらい厳密に扱うべき理由

多くのチームはテキスト読み上げを一度きりの操作として扱っています。誰かがデモ欄に一文を入力し、音声はそれなりに聞こえ、プロンプトはチャット履歴の中に消えていきます。三週間後、原稿の変更で再実行が必要になりますが、元の演じ方を再現できる人は誰もいません。声は揺れ、リズムは変わり、唯一の解決策はもう一度推測することです。

この失敗パターンはプロセスの問題であり、モデルの問題ではありません。TTSプロンプトは出力を形作る入力であり、設定ファイルやテンプレート文字列とまったく同じです。どこにも存在しなければ、レビューも差分比較もロールバックもできません。

すべてのプロンプトをレシピとして扱いましょう。名前とバージョン番号を持つ成果物であり、スクリプトと、それを正しく聞こえるようにする演技指示を対にしたものです。呼び出すコードの隣に置き、スクリプト本文が変わったとき、呼び出し元が変わったとき、あるいはモデルバージョンが足元で更新されたときに再テストします。

見返りは地味ですが価値があります。レシピにバージョン記録があれば、失敗した再生成は差分比較になります。関係者が「もっと温かみを」と求めることは、書き直しではなくブランチになります。そして新しいエンジニアのオンボーディングは、記憶ではなくフォルダを手渡すことになります。

作業原則を一つ：ある音声が公開できるほど良いなら、それを生成したレシピもコミットできるほど良い。

再利用可能な qwen-audio-3.0-tts-plus レシピの解剖

実用に耐えるレシピには四つの部分があります。これらをプロンプトファイル内の独立したフィールドとして扱い、一つの長い文字列にしないでください。そうすれば他の層に触れずに一つの層だけを編集できます。

1. 演技指示

朗読全体のスタイルを設定する短い指示ブロック：対象読者、テンポ感、フォーマル度、対象メディア（解説ナレーション、広告朗読、IVRプロンプト）。平易な言葉で書き、シリーズ内で安定させます。これが最も変化の少ない層です。

Delivery: calm product explainer, moderate tempo, warm but not
chatty, addressed to a developer audience. Avoid rising
trailing intonation on statements.

2. スクリプト本文

実際に朗読する言葉。それだけです。舞台指示を文中に埋め込んだり、音声に漏れ出る可能性のある挿入句を入れないでください。朗読されるべきでない語は、このフィールドに属しません。

3. セグメントマーカー

本文を個別に指示できるブロックに分割するための区切り——通常は各ブロックが一文か二文。セグメントはトーンやリズムの注釈を付加する場所なので、曖昧さがなく解析コストが低い必要があります。

[seg-01] First segment text here.
[seg-02] Second segment text here.

4. 出力の期待値

結果がどのように聞こえるべきか、そして実際に行った検証（長さの範囲、音節レベルの抜き取り検査、承認済み音声へのリンク）を記述した人間が読める説明。これにより、その場にいない人でもレシピをレビューできます。

各ユースケースは四つの部分すべてを一つのファイルに保存し、モデル名ではなくユースケース名で命名します。そうすれば基盤モデルを交換しても名前を強制的に変更する必要がありません。レシピはまず仕様書として、次にプロンプトとして読まれるべきです。

レシピ：ナレーションとボイスオーバーのリズム

TTSにおけるリズムは主に文章作成の問題です。エンジンは与えられたものを読むだけなので、長く途切れない文はしばしば慌ただしく、あるいは奇妙な強調で読まれます。解決策は、プロンプト言語に触れる前に、文の長さと改行を制御することです。

Delivery: documentary-style narration, unhurried, even energy,
clear sentence-final falling intonation.

[seg-01] Most audio pipelines fail at the same place.
[seg-02] Not at the model.
[seg-03] At the prompt that nobody saved.
[seg-04] A script change arrives, someone re-runs the generation,
and the voice comes back different, with no record of
what the old one looked like.

これを再現可能にする三つのポイント：

• 短い冒頭セグメント。 序盤は各マーカーに一文だけ。エンジンに明確な境界を与え、あなたには予測可能なリズムを与えます。
• セグメント内の物理的な改行を自然な節の境界に置く。聴き手がポーズと認識する句読点を増やさずに、リズムのヒントとして機能します。
• 文末の下降調を演技指示に明示する。 上昇調で終わる陳述は不確かに聞こえ、長編ナレーションで最もよくある不満です。

耳のために書き、そして確認する。スクリプトを声に出して読み、息が続かない箇所が段落を分割すべき場所です。一文に複数の考えが含まれていれば、それは二文です。

レシピ：句読点とポーズの制御

句読点はすでに手元にあるリズム制御の手段です。意識的に使えば、追加の指示言語を一切加えずにポーズの長さと強調を導けます。ほとんどのエンジンが従うおおよその順序を、短いポーズから長いポーズへ示すと：

comma  <  dash  <  period  <  ellipsis

この順序は有用なデフォルトであり、保証ではありません——必ず聴いて確認してください。以下のレシピでは各マーカーに一つの役割だけを持たせます。

Delivery: instructional narration, steady tempo, deliberate
pauses at section changes.

[seg-01] Here is the part most people skip: the punctuation.
[seg-02] A comma is a breath. A dash — a short hold. A period
ends the thought.
[seg-03] And an ellipsis... is a real pause. Use it sparingly.
[seg-04] Three rules. Short sentences. One idea each.
Punctuate on purpose.

再現性を保つための実用的な制約：

• 一つの記号、一つの意味。 ダッシュが時には「保持」を意味し時には単なる装飾であるなら、レシピは再実行時に一貫して読まれません。
• 記号の重ね使いを避ける。 複数の感嘆符や、入れ子になった省略記号とダッシュは不安定なポーズを生みます。一つを選んでください。
• 句読点を付けすぎない。 三語ごとにカンマを置くと朗読が細切れになり、演じ方が機械的に聞こえます。
• 極端なケースをテストする。 完全に句読点を付けた段落と同じテキストの最小限の句読点版を比較する。その差がエンジンが句読点をどれだけ重視するかを教えてくれます。

句読点の変更は純粋なテキスト編集なので、差分比較が非常に簡単です。これにより最も反復コストの低いレシピ層になります。

レシピ：セグメントごとの感情とトーンのプロンプト

スクリプト全体に対する感情指示は脆弱です。「興奮して聞こえるように」という注記を五分の音声に適用すると、均一に大きな朗読になり、すべての移行が平坦になります。セグメントレベルのプロンプトはより良いツールです。感情を一つの連続した音声内で変化させ、ある行の結果がおかしいときにそのセグメントだけを再生成できます。

Delivery: multi-section product narration, same speaker
throughout, tone shifts at segment boundaries.

[seg-01 | tone: neutral, informative]
Here is what changed in this release.

[seg-02 | tone: neutral, informative]
The generation path is faster, and the retry logic is simpler.

[seg-03 | tone: warm, reassuring]
If something does fail, it now fails loudly and early,
not silently at the end of a long job.

[seg-04 | tone: upbeat, confident]
That is the whole update. Ship it.

セグメントプロンプトを使いやすく保つためのガイドライン：

• トーンを名付け、それを固定する。 「温かい」のような裸のラベルは曖昧です。ここでの意味を対にして示す——安心させる、より遅く、より柔らかい語尾——そうすれば将来の読み手が再現できます。
• 話者を一定に保つ。 すべてのセグメントは同じ人物のように読まれるべきです。ペルソナではなく感情を指示してください。
• トーンは境界で変え、文の途中では変えない。 セグメントの途中での切り替えは検証が難しく、不自然に見えがちです。
• プロジェクトごとに小さなトーン語彙に限定し、それを再利用する。十分に理解された五つのラベルは、発明された二十のラベルに勝ります。

セグメントが独立しているので、却下された一行はトラック全体を再生成するのではなく、一つのセグメントを再実行するだけで済みます。これによりA/Bテストも安価になります。seg-03のプロンプトを変え、残りはそのままにできます。

出力をテストし、レシピをロックする

聴く前のレシピは単なる仮説です。ループは短く、フォルダと命名規則以外にツールは要りません。

ループ

1. 下書き。 レシピファイルを書くか編集する。一度に一つだけ変える——一つのプロンプト、一つの句読点パターン、一つのセグメント分割。
2. 生成。 編集したセグメントだけでなく、スクリプト全体の音声を生成する。リズムは文脈依存であり、一つのセグメントの変化が隣接セグメントの読み方を変えます。
3. 比較。 同じスピーカーまたはヘッドホンで、新しい出力を前回承認した版と連続して聴く。リズム、強調、トーンの移行を別々に判断する。これらは独立して失敗します。

新しい版が勝ったら、昇格させる。そうでなければファイルを元に戻し、失敗の理由をコミットメッセージに残す。

記録すべきもの

• 送信時とまったく同じ完全なレシピファイル。
• レンダリングされた音声を、対応する名前で隣に保存。
• 各比較の一行結論：何を変え、何が改善し、何が悪化したか。

ロック

レシピが承認されたら、タグを付ける——v1、v1.1、またはプロジェクトですでに使っている慣習に応じて日付ベースのタグ。それ以降、タグ付けされたレシピが公開された成果物となり、さらなる編集はそこから分岐します。モデルバージョンが足元で変わったら、まずタグ付けされたレシピから再生成し、記憶ではなく既知の参照と差分を測れるようにします。

ロックを機能させる二つのルール：ロックされたレシピをその場で編集しないこと、そして生成レシピがリポジトリにない音声を公開しないこと。

よくあるレシピの間違いとその修正方法

これらはチームがレシピのバージョン管理を始めた後に最もよく現れる失敗パターンです。それぞれにテキストレベルの修正方法があります。

過剰なプロンプト

演技指示、トーンラベル、強調マーカー、括弧付きの指示を一つのセグメントに積み重ねる。結果は不安定な朗読であり、誰も保守できないレシピです。

修正： レシピごとに演技指示は一つ、セグメントごとにトーンプロンプトは一つ、残りは句読点に任せる。あるセグメントに三つの指示が必要なら、それはおそらく二つのセグメントです。

句読点の不統一

ある箇所ではダッシュや省略記号を装飾的に使い、別の箇所では意味を持たせる。同じ記号がスクリプト全体で異なるポーズを生みます。

修正： 各記号にちょうど一つの役割を割り当て、生成前にファイル内の違反を監査する。... と — を検索するのに数秒しかかかりません。

再現不可能なスクリプト

コピー＆ペーストしたテキストにスマート引用符、余分な空白、または人間のレビュアー向けのつもりの括弧内容が朗読されてしまう。

修正： スクリプト本文には言うつもりのないものを一切含めず、エディタで引用符と間隔を正規化し、貼り付けるたびにファイルの差分を比較する。

スクリプト全体の感情

一つの「興奮」または「真剣」の指示が数分間の音声を覆う。

修正： トーンプロンプトをセグメントに移し、話者を一定に保ち、耳で検証できる境界で感情を変化させる。

未テストの編集

テキストが問題なさそうに見えるからと、プロンプトを変えて聴かずにそのまま公開する。

修正： 昇格する前に生成して比較する。紙の上で正しく読めるプロンプトでも、リズムや強調がずれることがあります。

迷ったら、指示を追加するのではなく削る。句読点がきれいで、セグメント境界が正直な短いレシピのほうが、すべてを制御しようとする長いレシピより再現しやすい。レシピを構築し、出力を聴き、効果のあるものをロックする。