TTSで数字・日付・金額・単位を自然に読ませる書き方

数字は画面では非常に効率的ですが、音声では複数の読み方を持ちます。人間は1/5、2026、$14.99、3–30 sを見てcontextから意味を補えますが、TTS modelはどのspoken formを使うか決めなければなりません。

productionでは、すべてのnumeric notationをmodel任せにしない方が安全です。まず「listenerに何と聞かせたいか」を決め、重要な表現をshort sentenceでtestし、必要な箇所だけ明示的なspeech textへ変えます。

formattingより先にspoken formを決める

最初に、human narratorならこの行をどんな単語で読むべきか考えます。

例えば：

“fourteen dollars and ninety-nine cents”と聞かせたいのか、“fourteen ninety-nine”でもよいのかは、$14.99という表示だけでは決まりません。

exact wordingが重要なら、speech scriptで直接書きます。

広告、tutorial、financial explanation、product pricingなど、数字の誤読がtrustを下げる場面では特に有効です。

yearは普通のcardinal numberと同じとは限らない

英語の2026は“twenty twenty-six”と読まれることがありますが、contextやlanguageによって別のreadingになる場合があります。

重要なyearは単独の数字ではなく、完全なsentenceでtestします。

意図と違う場合のみspoken formを明示します。ただし、すべてのyearを無条件にwordsへ変換しないでください。numeric notationのまま正しく読まれるケースも多く、過剰な展開はsource scriptのmaintenanceを難しくします。

consistencyが必要な箇所だけ明示するのが実用的です。

dateはlocale ambiguityをなくす

08/09/2026は人間にとっても地域によってAugust 9とSeptember 8の両方に解釈できます。

speech scriptでは、対象言語の普通のdate formを使って意図を直接表します。英語なら：

または：

localized scriptではtarget languageの慣習へ直し、生成結果を聞きます。

interface languageを変えただけでnumeric dateが自動的に一意になるとは考えないでください。legal、billing、release、event dateではcompactnessよりclarityが優先です。

currency symbolにはcontextが必要

$は複数のcurrencyを表す可能性があり、音声になった後listenerは元のsymbolを見られない場合があります。

通貨が重要なら、例えば意図がUS dollarsであることをspeech textに明示します。

$14.99のようなproduct priceは、compactなnumeric inputと明示的なspoken formを比較し、target audienceにとって自然で正しい方を使います。

multilingual contentではEnglish formattingをそのままコピーしないでください。number grouping、decimal separator、currencyの語順はlocaleごとに変わります。

percentageは周囲の数字と一緒に確認する

25%だけなら問題なく読まれることが多いですが、percentage、decimal、rangeが同じsentenceに複数入ると聞き取りが難しくなります。

例えば：

全部の数字が必要なら、2文に分けてそれぞれの役割を明確にする方がlistenerに優しい場合があります。

narrationでは「technicalに正しい」だけでなく、「1回聞いて理解できる」こともqualityです。

長いdecimalは必要なprecisionを先に考える

3.14は単純ですが、0.037582のような長いdecimalは冗長になり、digit-by-digit readingになる場合もあります。

listenerがfull precisionを必要としないなら、contentの要件が許す範囲でroundすることを検討できます。

一方、scientific、financial、medicalなどexact precisionが必要な内容では、音を滑らかにするために値を変えてはいけません。正確な値を保ち、必要ならspoken sequenceを明示し、人によるreviewを入れます。

rangeはdashに依存しない方が安定する

3–30 secondsは正しく読まれることもありますが、dash typeやmodelによって挙動が変わる場合があります。

重要なinstructionなら：

のように読みを直接書くと安定します。

date range、price range、quantity rangeでも同じ考え方が使えます。目的はcompact typographyではなくlistenerの理解です。

unitとsymbolはaudienceに合わせる

5 km、10 GB、44.1 kHz、250 msはnumberとabbreviationの組み合わせです。

technical audienceなら略語のままが自然なこともあります。general audienceならfull wordの方が理解しやすいことがあります。

例えばtutorialで：

とした方が10 MBより自然な場合があります。

ただし、modelがすでにabbreviationを自然に処理するなら無理に展開する必要はありません。target audienceと実際のoutputで判断します。

ordinalは特別に確認する

1st、2nd、3rd、21stはdate、ranking、instructionに現れます。

complete lineでtestし、21stが不安定なら“twenty-first”と書きます。

dateはtarget languageの自然なdate expressionを使い、number+suffixを人工的に組み立てない方が安全です。

versionも同じで、screenを見ていないlistenerにはv2より“the second version”の方が明確な場合があります。

large numberはlistener向けに編集する

1,250,000をmodelが正しく読めても、周囲に別の数値が多いとlistenerには重くなります。

必要に応じて：

のような分かりやすいframeを使えます。

exact valueが必要なら：

のように明示します。

判断基準はaudienceが何を覚える必要があるかです。voice scriptはspreadsheetではありません。

acronym + numberはambiguityが重なる

API v2.5 supports 5 languagesにはacronym、version number、countが同時に存在します。

tokenを別々に見るだけでなく、sentence全体をtestします。

必要なら：

のように書けます。

API自体を展開するかどうかはaudienceとproject pronunciation ruleに合わせます。重要なのは、曖昧なtokenを個別に診断することです。

multilingual scriptはlanguageごとにnumeric formatをreviewする

Englishで機能するnumber formatが、Spanish、Japanese、Chinese、Arabicで自然とは限りません。

multilingual generation前に：

1. 周辺語だけでなくnumber format自体をlocalizeする
2. decimal / thousands separatorを確認する
3. dateをunambiguousにする
4. 必要なcurrency名を言う
5. unitとabbreviationをtarget languageでtestする
6. number単体ではなくcomplete sentenceを聞く

cross-language voice cloningはlanguage-aware editingを不要にはしません。

小さなnumeric regression setを作る

price、date、version、percentage、measurementが繰り返し出るprojectでは、短い固定testを保存します。

例えば：

model、language、主要format ruleを変更したときに再生成します。

これは完全なquality proofではなく、既知の数字表現が変化したときのfast warningです。

数字が悪いときは1変数testをする

失敗した行でreference、pace、punctuation、modelを同時に変えないでください。

まずtextだけ比較します。

A:

B:

その他の条件は固定します。Bで改善したなら、問題はvoice referenceではなくtext normalizationです。

最終checklist

final generation前に、次をscanします。

• 2通りに解釈できるnumeric date
• currency名のないsymbol
• 不要に長いdecimalやprecision
• dashに依存するrange
• modelが読みにくいcompact unit
• ordinal / version number
• 耳で理解しにくいlarge number
• character-by-characterで読むべきidentifier
• 他localeからコピーされたseparator

目的は最も短い表記ではなく、予測可能で理解しやすいspeechです。

重要なnumberほどlistenerのために書いてください。scriptで数語増やすだけで、final audioの混乱や不自然さを大きく減らせます。