TTSで略語・商品名・特殊な単語を正しく発音させる方法

綴りと普通の読み方が一致しなくなると、TTSは急に難しくなります。acronym、会社名、developer tool、product version、username、外国人名、造語brandなどは、画面では明らかでも音声モデルには複数の解釈があり得ます。

最も安定した制作方法は、2つの目的を分けることです。表示上は正式で正確な名前を保ち、音声生成用には意図した発音を得るためのspeech textを用意する。

この分離をすると、原稿全体を謎のphonetic hackや不自然な記号で汚さずに済みます。

最初に「単語として読むか、文字として読むか」を決める

acronymには、普通の単語として読まれるものがあります。

一方で、通常は文字ごとに読むものもあります。

よく知られた略語ならモデルが正しく推測することがありますが、珍しい略語は読みが不安定です。

単語だけを単独で試すのではなく、普通の文で確認します。

もし誤読されるなら、より明示的なspeech formも比較します。

空白が効くこともありますが、modelやlanguageによって挙動は違います。単純なspacingで安定しないなら、その言語でのletter nameを明示する書き方を試します。

重要なのは、大規模な置換をする前に短文で検証することです。

display textとspeech textを分離する

例えば正式なproduct nameがIndexTTS2だとします。

web page、subtitle、screenshotではそのofficial spellingを保ちつつ、ナレーションでは正しく読ませるための別のrenderingを使えます。

TTSに読ませやすくするためだけに、正式な商品名をサイト全体で書き換えるべきではありません。

制作上は次の2層を持つと管理しやすくなります。

• display text: 正式な綴り、brand名、code名
• speech text: 意図した発音を出すために確認済みの表記

articleをvideo scriptにも使う場合、product tour、podcast、字幕付きtutorialでは特に有効です。

画面は正確なspellを担当し、音声は自然な理解を担当できます。

letters + numbersの名前は必ず文脈で試す

GPT-5、iPhone 17、HTTP/2、IndexTTS 2.5には複数の判断が含まれます。

• 文字を1つずつ読むのか
• 数字をどう読むのか
• hyphen、slash、decimal pointに意味があるのか
• product nameとversionの間でどこに間を置くのか

compactな表示形が常に同じ音になるとは限りません。

必要なら英語のspeech textでは、例えば次のような形を試せます。

ただし、英語のletter-by-letter renderingを日本語や他の言語へそのままコピーしないでください。letter nameも自然なbrand pronunciationもlocaleごとに違います。

brandには綴りから予想できない公式発音がある場合がある

造語brandは、見た目から推測した読みと公式pronunciationが違うことがあります。

公式ガイドがあるならそれを優先します。ない場合も、大量制作を始める前に内部標準を決めます。

例えばproject noteに次のように残せます。

production scriptやstyle guideへ記録し、次のeditorの記憶に頼らないようにします。

random punctuation hackを避ける

発音を直すためにperiod、hyphen、slash、apostropheを増やしていく方法は、1回だけ成功することがあります。

しかしpunctuationは発音だけでなくpauseやrhythmも変えます。

たとえば文字の間にperiodを入れると、文中で不自然に強い間が入る可能性があります。

workaroundを使うなら、最低でも次を確認します。

• sentence beginning
• sentence middle
• numberの前後
• commaやperiodの隣

1行だけで成功するsolutionはfragileです。より明示的なspeech renderingで解決できるなら、その方が保守しやすいです。

難しいcompoundは聞き取りやすい単位に分ける

technical termには、既知の部分を組み合わせた新しい名前が多くあります。

modelがcompound全体を読めなくても、componentを分けると正しく読めることがあります。複雑なphonetic spellingを作る前に、spaceや説明的な言い方を試します。

対象になりやすいのは：

• internal tool name
• model alias
• repository name
• domain name
• command name

tutorialで正確なspellが必要なら、まず自然に名前を読み、その後screenで正確なtokenを表示する、あるいは必要なときだけspell outする方法があります。

domainは聞き手向けの表現にする

indextts.onlineは画面なら直感的ですが、.を含む文字列は読み上げでぎこちなくなることがあります。

正確なaddressを聞かせる必要があるなら、例えば：

のようなspeech formを使えます。

画面にURLが表示されているなら、音声をもっと簡単にしても問題ありません。

長いURL、tracking parameter、authentication linkは本当に必要な場合だけ読みます。聞き取りにくいうえ、sensitive informationを露出する危険もあります。

filenameとcode tokenは特別扱いする

voice_01.wav、page.tsx、/api/generationsのようなcode-like stringは、普通の文章として設計されていません。

まず、listenerが正確なtokenを耳で知る必要があるか判断します。

必要なら、理解できる単位に分けて読みます。必要でないなら、screenでsyntaxを見せ、voiceoverでは意味だけ説明する方が自然です。

例えば画面でvoice_01.wavを見せつつ、音声では：

と説明できます。

instructional mediaでは、正確なsyntaxはvisual、意味はspeechという役割分担が有効です。

外国語の人名は元言語を知る人にreviewしてもらう

multilingual generationが全体として流暢でも、personal name、place name、borrowed wordを誤読することがあります。

Japanese、Spanish、Arabic、Chinese、Englishのlanguage optionを選んだだけで、すべてのforeign proper nounが正しくなるわけではありません。

重要なnameは次の順で確認します。

1. origin languageを特定する
2. target localeで使うべきpronunciationを決める
3. short natural sentenceで試す
4. 必要ならnative spellingやtransliterationを比較する
5. high-visibility outputは知識のあるspeakerがreviewする

これはmodel settingではなくcontent-qualityの工程です。

abbreviationはcontextで意味が変わる

short formには複数の意味がある場合があります。Dr.はdoctorとして読むことがありますが、technical abbreviationはletter readingが適切かもしれません。

contextでmodelが判断できる場合もありますが、誤読すると困る箇所ではambiguityに頼りません。

例えば安定してDoctor Chenと読ませたいなら、speech textでDoctor Chenと書く方が確実な場合があります。

ms、GB、kHzのようなunitも、audienceが略称を期待するかfull formを期待するか決めます。

project pronunciation sheetを作る

繰り返し使うcontentでは、小さな発音表を維持します。

special softwareは不要です。repositoryのMarkdown fileでも十分です。

価値はconsistencyにあります。次のscriptを別の人が作っても、同じnameの発音が変わらなくなります。

pronunciation regression sentenceを保存する

複数の難語が安定したら、1つの短いtest sentenceへまとめます。

modelやtarget languageを変えたとき、まずこのsentenceを生成します。

project全体の正しさを保証するtestではありませんが、既知のtermが急に変わったときのearly warningになります。

一度に1つだけ変える

product nameの発音が悪いからといって、reference voice、emotion、pace、textを全部同時に変えないでください。

まずtext variantだけを比較します。

A:

B:

他の条件は固定し、nameだけを聞きます。Bが改善したなら、そのspeech renderingをpronunciation sheetへ保存します。

どちらも駄目なら別のwordingを試します。controlled iterationの方がrandom tuningより速く原因を特定できます。

pronunciation workaroundで事実を変えない

technical value、version、legal name、currencyをmodelが誤読しても、「別の値の方が読みやすい」という理由で事実を変更してはいけません。

変えるのはspeech rendering、sentence structure、visual supportです。factual accuracyは保持します。

legal、financial、safetyなどhigh-stakesなcontentでは人によるreviewが必要です。

最終workflow

final scriptを生成する前に：

1. acronym、product name、version、URL、code token、foreign nameをhighlightする
2. それぞれのtarget pronunciationを決める
3. 難しいtermをnatural short sentenceでtestする
4. 成功したspeech renderingをpronunciation sheetへ記録する
5. exact display spellingとspeech-optimized textを分離する
6. foreign nameやborrowed wordを知識のあるspeakerがreviewする
7. modelまたはlanguage変更時に小さなregression testを再生成する

特殊な単語はsynthetic speechを諦める理由ではありません。pronunciationを明示的なproduction stepとして扱う理由です。

難しい語彙を一度documentしておけば、その後のscriptは速く、一貫して、reviewしやすくなります。