良いTTS脚本の書き方：句読点、数字、略語、自然な話し言葉

TTSの品質はvoice modelだけで決まりません。script自体が、どこで考えが始まり終わるか、数字をどう読むべきか、どのabbreviationが曖昧か、人間ならどこでpauseするかをmodelへ伝えます。

良いTTS scriptは、articleをそのままgeneratorへ貼り付けたものではありません。contentを「聞くため」に編集したspoken-language editionです。

1回聞いただけで理解しやすいように書く

読者はpauseし、前へ戻り、headingやlayoutを見て構造を理解できます。listenerは通常、時間の流れに沿って1回聞くだけです。

そのため、spoken writingでは構造を早めに示します。

direct sentence、clear transition、1文1つのmain ideaを優先します。nested clauseや条件が多い文はgeneration前に分割します。

目的は内容を単純化することではなく、visual supportがなくても理解できるようにすることです。

生成前に声に出して読む

これは最も速く、費用のかからないquality checkです。

音読して：

• つまずく；
• 息が足りない；
• 無意識に別の言葉へ言い換える；
• abbreviationの読み方に迷う；
• punctuationがない場所で自然に止まる；

なら、scriptはまだTTS向けに改善できます。

音読すると、画面では気づきにくいawkward rhythm、repeat word、hidden ambiguity、不自然なpunctuationが見つかります。

punctuationはdelivery structureとして使う

punctuationは精密なprosody control languageではありませんが、重要な構造を与えます。

periodはcomplete thoughtの強いboundary、commaは自然なphrase grouping、colonは説明やlistの導入、question markはquestion intentを示します。

演出を強制するためだけにcomma、ellipsis、dashを無作為に増やさないでください。scriptはまずhuman editorが読んでも文法的に明快である必要があります。

もっと強いbreakが必要なら、記号を増やす前に2文へ分けるべきか検討します。

数字は「聞かせたい形」にする

数字はscreen上ではcompactですが、speechでは複数のreadingを持つことがあります。

2026/08/23のようなdateはlocaleで解釈が変わり、3.5やcurrency symbolもcontextによって読み方が変わります。

重要なnarrationでは、modelに全てを推測させず、target languageで意図したspoken formへ書き換えます。

画面ではcompact notationを保ち、speech scriptだけ明示的にすることもできます。display textとspoken textは別のmedia layerです。

abbreviationのspoken formを決める

acronymにはletter-by-letter、word pronunciation、full phraseへの展開などがあります。

projectが必要とするreadingをmodelが必ず推測できるとは限りません。

critical termはshort natural sentenceでtestし、speech-friendly renderingを決めたらproject全体で統一します。

company name、technical product、medical term、internal acronym、model/version nameでは特に重要です。

URLとemailを意図的に扱う

画面にURLがあるからといって、voiceoverで全部読み上げる必要はありません。

listenerがexact addressを覚える必要があるのか、それとも「websiteをご覧ください」で十分なのかを判断します。

多くのvideoやproduct walkthroughでは、visual channelが正確なURLを示し、audio channelはactionとmeaningを伝える方が自然です。

email addressも同様です。character-by-character readingは聞きにくいため、screenで表示してvoiceでは簡単なCTAだけ言う方がよい場合があります。

visible stringを自動的に全てnarrationへ入れないでください。

visual listをspoken structureへ変える

bullet listは読者なら一目でscanできますが、listenerはitemを順番に受け取ります。

long listをそのまま読むとmonotoneになり、構造も覚えにくくなります。

必要に応じて「まず」「次に」「最後に」などのtransitionを加え、related itemをgroup化します。

exact itemを覚えてほしい場合は、audioでlogicを説明し、screenでcomplete listを見せる方法もあります。

名前は早めにtestし、決めた形を再利用する

proper nounをfinal batchまで放置しないでください。

名前やbrandをordinary sentenceに入れてtestすると、isolated wordより実際のproductionに近い結果を確認できます。

international nameでは、source-language pronunciationかlocalized pronunciationかもprojectとして決めます。

毎回modelに判断させるより、approved renderingを作り、全clipで統一する方がconsistentです。

parenthetical writingを減らす

articleやreportではparentheses、footnote、citationが視覚的に処理できますが、speechでは突然のinterruptになります。

重要な補足はnormal sentenceへ変え、listenerに不要なら削除します。

referenceやcitationも「spoken experienceに本当に必要か」を判断します。pageには残しても、voiceでは読まないという選択ができます。

長尺でも小さくcoherentなsectionで生成する

final contentが長いことと、1回のgenerationを巨大にすることは別です。

paragraph-sized sectionはnatural rhythmに必要なcontextを保ちつつ、correctionを局所化できます。

arbitrary character countではなくmeaning boundaryで分け、complete sentenceを途中で切らないでください。

visual headingをspoken transitionへ変える

visual documentはheading、font size、spacingでtopic changeを示します。audioにはそのsilent layoutがありません。

例えばSecurityというheadingだけではlistenerにtopic changeが伝わらないため、

のようなorientation sentenceが必要な場合があります。

chapter changeやsummaryも同じ考え方です。

toneをproject全体で統一する

marketing copy、technical documentation、support textをつなぐと、formality、sentence length、terminologyが急に変わることがあります。

生成前に1つのspeaking styleへeditします：

• formality level；
• typical sentence length；
• preferred terminology；
• second-person usage；
• transition pattern。

model settingを変えなくても、script styleの統一だけでvoice consistencyが改善することがあります。

pronunciation testをwriting processへ入れる

同じwordが繰り返し失敗するなら、outputを毎回直すのではなくscript conventionを直します。

short test sentenceを作り、clearer written formを比較し、成功したものをpronunciation guideへ記録します。

product nameが全chapterで間違ってから気づくのではなく、writing段階で解決します。

生成後はapproved scriptと照合する

audioを「良い声か」だけで聞かず、approved textと一致しているか確認します。

• omission；
• duplicated word；
• unexpected pause；
• number/acronymの誤解；
• readingによるmeaning change；

を探します。

同じ問題が複数sectionで起きるなら、individual outputを直し続けるのではなく、source script ruleを修正します。

Speech-first編集チェックリスト

generation前に確認します：

1. すべての文が音読しやすい；
2. punctuationが自然なstructureを示す；
3. important numberにambiguityがない；
4. acronymのspoken formが決まっている；
5. nameとbrandをtest済み；
6. URL/email/visual-only textを意図的に処理している；
7. 必要なheadingにspoken transitionがある；
8. long paragraphをmeaning boundaryで分割している；
9. toneとterminologyがproject全体でconsistent；
10. pronunciation ruleがdocumented and reusedされている。

良いTTS modelでも、受け取ったstructure以上のものは使えません。listenerのためにwritingを設計すると、regenerationが減り、pronunciation reviewが容易になり、完成音声も「documentを読み上げたもの」ではなく「最初からaudioとして設計されたもの」に近づきます。