TTSの句読点とポーズの書き方ガイド

TTS scriptでは、句読点もgeneration inputの一部です。modelはpunctuationから、どこで1つのthoughtが終わり、次が始まり、phraseをどうgroupingするかを推測します。

ただし、punctuationをhidden timing languageのように扱うのは危険です。commaが一定msのpauseを保証するわけではなく、同じsentenceでもmodelによってprosodyが変わります。

より安定したworkflowは、まずspoken text自体を明確にし、それでもdeliveryが悪いときだけ最小のformat changeをtestすることです。

まず普通の文章として正しく書く

careful human editorと同じようにpunctuationを使います。

periodはcomplete thoughtを閉じ、commaは自然なphrase groupを示し、question markはquestionを明確にし、colonは説明やlistを導入します。

例えば：

このようなnormal structureから始める方が、pauseを強制するためにcomma、ellipsis、特殊symbolを重ねるより原因を診断しやすくなります。

human readerが構造を理解しにくいscriptでは、bad outputがmodel由来かtext由来かも分かりません。

periodは最も明確なboundaryになりやすい

long sentenceがrushして聞こえる理由の1つは、modelが1つのprosodic contourを最後まで維持しようとすることです。

2つのclauseが独立できるなら、分けることを検討します。

例えば：

より明確にすると：

後者はmodelに明確なboundaryを与え、1か所だけ問題が起きたときに小さいunitだけ再生成できます。

commaはpause buttonではなくgrammar groupingに使う

commaが最も安定するのは、実際のgrammarと一致するときです。

自然な例：

不自然なhack：

後者はsentence structureとpunctuationが衝突し、不自然なphrase breakを作る可能性があります。

commaより強いbreakが必要なら、まず2 sentencesへ分けるべきか考えます。

line breakはproduction organizationを第一目的にする

1 spoken sentence per lineはvoiceover制作で非常に便利です。

この形式はreview、subtitle alignment、chunk regenerationを簡単にします。

ただし、すべてのmodelがline breakに同じacoustic pauseを付けるとは限りません。line breakは最初にproduction organization tool、次にacoustic hintと考える方が安全です。

colonは「setup → explanation」に向く

colonは、最初のphraseが次の内容を予告するときに有効です。

tutorialやproduct walkthroughでは、listenerが次に何を聞くか準備できます。

ただし1 paragraphにcolonを何度も入れるより、periodで分けた方が明確な場合もあります。

dashは意味があるときに使い、挙動をtestする

em dashはcontrastやasideを表せます。

speech systemによってdashへの反応は大きく違います。明確なpauseを作るものもあれば、ほとんど変化しないものもあります。

本当にcontrastを表すなら保持して構いません。timing目的だけならcomma、period、em dashをcontrolled comparisonします。

ellipsisを万能pauseとして使わない

ellipsisは本当のhesitationやtrailing speechには有効です。

しかし普通のnarrationで繰り返すと、必要以上にslowまたはtheatricalになることがあります。

ellipsisはmeaningを表すときに使い、sentence designの代わりにはしません。

listはvisual scanningではなくlistening用に書き直す

visual listはreaderが全体を一度に見られますが、audio listenerは時間順にしか情報を受け取れません。

例えば：

を、意味のchunkへ分けます。

information量を減らさず、listenerが順番に処理しやすくしています。

punctuationを疑う前にnumber・acronym・nameを確認する

sentenceがawkwardな理由がpauseとは限りません。

2026、3–30 seconds、API、domain、product versionなど自体が誤読されているなら、commaを追加しても直りません。

まずproblem tokenをshort sentenceでtestし、必要なら意図したspoken formを明示します。

例えば“three to thirty seconds”と聞かせたいなら、3–30の周囲にsymbolを足すよりそのwordsを書く方が安定する場合があります。

sentence lengthは強力なpacing control

複数idea、number、parenthetical clause、long listを1文に詰めると、modelが一度に推測するstructureが増えます。

editingでは：

1. 各sentenceのmain ideaを特定する
2. unrelated ideaを分ける
3. secondary detailを次のsentenceへ移す
4. まず再生成する
5. それでも必要ならpunctuationを追加testする

この順序がhuman readabilityとsynthetic speechの両方を改善します。

controlled pause testを作る

1 sentenceが悪いとき、script全体を書き直す前にtiny test setを作ります。

A:

B:

C:

model、reference voice、language、emotion、paceは固定します。

そして具体的に聞きます。

• pauseはshortすぎるかlongすぎるか
• second clauseが強くrestartしすぎないか
• boundary後にspeaker energyが落ちないか
• あるvariantだけartifactが出ないか

こうすると「なんとなくBが良い」を再利用可能なproduction decisionへ変えられます。

一度に1 variableだけ変える

punctuation、emotion、pace、reference、modelを同時に変えると、改善理由を特定できません。

有効なA/Bでは1 factorだけを変えます。IndexTTS OnlineのVoice Labでmodel比較をするときも、modelを固定してscript formattingを比較するときも同じ原則です。

pause production checklist

final voiceover前に次の順で確認します。

1. 各sentenceが単独でも理解できる
2. ideaを詰めすぎたsentenceをsplitした
3. normalなperiod、comma、question mark、colonを使った
4. listをlistening用に再構成した
5. number、acronym、nameのpronunciation問題を先に除外した
6. dashとellipsisはreal meaningがあるときだけ使った
7. まだ悪いとき、punctuation changeを1つだけA/Bした
8. long-formではaffected chunkだけregenerateした

重要な原則はシンプルです。punctuationはstructureをclarifyするためのもので、hidden control codeではありません。

clean scriptはmodelが曖昧な判断をする回数を減らし、controlled testingはrandom symbolを足し続けるよりはるかに有用なproduction ruleを残します。