音声合成(TTS)を組み込んだアプリを作ると、ほぼ必ずぶつかるのが読み間違いです。「1日」を「いちにち」と読んでほしいのに「ついたち」と読む。「3本」を「さんほん」と読む。社名や商品名を、文によって違う読み方で読む。
音声の自然さは年々上がっていますが、読みの正しさは別の問題です。しかもLLM(ChatGPTなど)の返答を読み上げるアプリでは、何を読ませるかを事前にすべて確認することができません。
この記事では、音声合成が日本語を読み間違える仕組みを分解したうえで、アプリの側でできる直し方と、直した読みを壊さないためのテストを、音声機能つきアプリの開発現場からまとめます。
📌 この記事の3行まとめ
① 読み間違いは「テキストの正規化」「読みの推定」「アクセント」の3か所で起きる。どこで起きたかで直し方が変わる
② 直し方は入力を整える・辞書に登録する・その場で指定する・合成前のデータを直すの4層。分かっている読みは外から渡す
③ 直した読みは自動テストで守る。エンジンや辞書を更新するたびに、決めた文例の読みを機械的に照合する
読み間違いは3か所で起きる
音声合成エンジンの中では、文字がいきなり声になるわけではありません。おおまかに次の順で処理されます。
| 段階 | やっていること | 間違いの例 |
|---|---|---|
| ① テキストの正規化 | 数字・記号・英字を「読める形」に直す | 「3/4」を日付と分数のどちらで読むか、「10〜20」の「〜」、「AI」「v2.0」 |
| ② 読みの推定(G2P) | 漢字かな交じりの文を、読み(音素)に変換する | 「辛い」(からい/つらい)、「人気」(にんき/ひとけ)、人名・地名 |
| ③ アクセントと区切り | 高低アクセント、アクセント句、間(ポーズ)を決める | 単語単体では正しいのに、文の中でつながると高低がおかしい |
| ④ 音声の生成 | ①〜③の結果から音声の波形を作る | 声質や抑揚の自然さ(この記事では扱いません) |
G2Pは「Grapheme to Phoneme(文字から音素へ)」の略です。日本語では、同じ漢字に複数の読みがある、数字と助数詞の組み合わせで音が変わる(1本=いっぽん、3本=さんぼん、1分=いっぷん)、単語がつながると高低アクセントが変わる、という3つの性質が重なるため、ここが特に難しくなります。
大事なのは、どの段階で間違えたかによって、直す場所が違うことです。人名の読みが違うのは②、数字の読みが違うのは①か②、読みは合っているのに不自然なのは③です。原因を切り分けずに場当たり的に直すと、別の文で新しい読み間違いを生みます。
間違えやすい日本語の早見表
| 種類 | 例 | 起きる理由 |
|---|---|---|
| 数字と日付 | 1日(ついたち/いちにち)、3/4、10:30 | 同じ表記が、文脈によって別の読みになる |
| 助数詞 | 1本・3本・6本、1分・3分、1階・3階 | 数字によって音が変わる(促音化・連濁) |
| 同じ表記で読みが違う語 | 辛い、人気、市場、生物、明日、上手 | 文脈を理解しないと読みが決まらない |
| 固有名詞 | 人名・地名・社名・商品名 | 辞書に無い、または読みが複数ある |
| 英字・略語 | AI、iOS、SaaS、Wi-Fi、v2.0 | 単語として読むか、1文字ずつ読むか |
| 記号 | 〜、→、%、#、URL、絵文字 | 読むのか、黙るのか、何と読むのか |
| アクセント | 複合語、助詞が付いたとき | 単語の高低が、文の中で変化する |
研究ではどう解いているか:自動推定と「外からの指定」の両立
この問題は研究でも盛んに扱われています。松尾研究所のテックブログ(2026年10月9日公開)の「音声合成に日本語を正しく読んでもらう話(後編)」では、辞書・Transformer・BERTを組み合わせた日本語G2Pの構成が紹介されています。要点は次の3つです。
- 形態素解析で辞書を引くべき語(固有名詞や数詞など)を見つけ、辞書から得た読みを「読みタグ」で囲んで保持したまま、残りの部分だけを機械学習のモデルで読みに変換する
- 単語をつないだあとのアクセントの変化(アクセント結合)は、別のモデル(BERT)で推定する
- 数詞・助数詞を含む100表現での評価では、読みとアクセントを表す記号列の誤り率(文字誤り率、CER)が、広く使われているOpen JTalkの16.24%に対して、この構成では1.42%だった。複合語のアクセント結合でも、単語を単純につなげた場合の15.21%から、BERTによる推定で6.04%に下がった
アプリ開発者にとって示唆的なのは、記事が目標として「自動で自然に読んでくれること」と「必要なときに『ここは、こう読んで』と伝えられること」の両立を掲げている点です。自動推定がどれだけ賢くなっても、社名や業界用語のように文脈だけでは決まらない読みは残ります。だからこそ、アプリの側に「分かっている読みを外から渡す口」を用意しておくことが大切です。
ここから先は、いま実際に使われている音声合成エンジンで、その「口」をどう使うかの話です。
アプリ側でできる4つの直し方
| 層 | 何をするか | 向いている場面 | 注意点 |
|---|---|---|---|
| ① 入力を整える | 合成する前のテキストを、読み間違えにくい形にする | 記号・Markdown・URL・日付や金額の書式 | 直しすぎると、別の誤読やアクセントの崩れを生む |
| ② 辞書に登録する | 単語の読みとアクセントをエンジンに教える | 社名・商品名・人名・業界用語 | 登録した語が、別の語の一部に誤って当たることがある |
| ③ その場で指定する | SSMLなどで、その文だけ読みを指定する | 日付・電話番号・一度きりの言い回し | 使えるタグは、エンジンや声の種類によって違う |
| ④ 合成前のデータを直す | 読みやアクセントの中間データを直接編集する | 研修動画やナレーションなどの作り置き | 手作業が増える。その場で喋る用途には向かない |
① 入力を整える:読み上げ用のテキストを作る
まず効果が大きいのは、画面に表示するテキストと、読み上げるテキストを分けることです。
LLMの返答には、Markdownの記号(** や #)、箇条書きの記号、URL、絵文字、コードなどが混ざります。これをそのまま音声合成に渡すと、記号を読み上げたり、不自然な間が入ったりします。合成の直前に、次のような前処理を入れます。
- Markdownの記号、URL、絵文字、コードを取り除く(URLは「リンクを画面に表示しました」などの言葉に置き換える)
- 「〜」「→」「%」など、意味のある記号は、読み方のある言葉に置き換える
- 括弧の中身を読むか読まないかを、ルールとして決めておく
- 日付・時刻・金額・電話番号は、文脈がはっきりする書式にそろえる(「10/22」より「10月22日」)
LLMを使っているなら、システムプロンプトで読み上げ向けの書き方を指示するのも効きます。「記号や箇条書きを使わない」「日付は〇月〇日の形で書く」「英字の略語は、初めて出るときに読みを添える」といったルールです。
ただし、数字をすべてひらがなに開くことはおすすめしません。「さんぼん」と書けば読みは確定しますが、エンジンが単語の切れ目やアクセントを判断しにくくなり、かえって不自然になることがあります。数字の扱いは、使うエンジンで実際に聞き比べて決めてください。
② 辞書に登録する:分かっている読みを教える
社名・商品名・人名・業界用語のように、読みが決まっている言葉は、エンジンの辞書に登録するのが正攻法です。
VOICEVOXの場合、エディターの「読み方&アクセント辞書」で、単語・読み(カタカナ)・アクセントの位置・品詞・優先度を登録できます。VOICEVOX ENGINEをサーバーやアプリに組み込んでいる場合は、同じ登録をAPI(/user_dict_word に、単語・カタカナの読み・アクセント核の位置を渡す)から行えます。なお、辞書に無い英単語は、VOICEVOXでは既定で自然なカタカナ読みに変換されます。
クラウドの音声合成サービスも、多くが辞書(レキシコン)やSSMLによる読みの指定に対応しています。
| エンジン | 辞書・読みの登録 | 文ごとの読みの指定 |
|---|---|---|
| VOICEVOX | ユーザー辞書(単語・カタカナの読み・アクセント核の位置・品詞・優先度) | 音声クエリの編集、AquesTalk風記法による読みとアクセントの指定 |
| Amazon Polly | レキシコン(PLS形式。日本語に対応) | SSMLの <phoneme>(x-amazon-yomigana でひらがな・カタカナ・ローマ字の読み、x-amazon-pron-kana で高低アクセントまで)、<sub> |
| Google Cloud Text-to-Speech | カスタム発音(読みがな。Chirp 3: HDなど対応する声のみ) | SSMLの <phoneme alphabet="yomigana">(^ と ! で高低アクセント)、<sub> |
| Azure AI Speech | カスタムレキシコン | SSMLの <phoneme>(日本語はカタカナによる表記またはIPA)、<sub> |
(2026年10月時点の各社の公式ドキュメントに基づく概要です。同じサービスでも、声の種類やエンジンの世代によって使えるタグが違うため、採用前に確認してください。)
辞書登録で気をつけたいのは、登録した語が、別の語の一部に当たってしまうことです。短い語や一般的な語を登録すると、意図しない場所で読みが変わります。登録したら、その語を含む別の文例でも読みを確認します(後で説明する自動テストが、ここで効きます)。
③ その場で指定する:SSML
文ごとに読みを指定したいときは、SSML(音声合成マークアップ言語)を使います。多くのクラウドTTSが対応しているW3Cの標準規格で、次のようなタグがよく使われます。
<sub alias="よみかた">表記</sub>:表記を別の読みに置き換える。もっとも互換性が高い<say-as interpret-as="date">:日付・時刻・電話番号・数字の読み方を指定する<phoneme>:読みがなや発音記号で、発音を直接指定する(日本語で使える書き方はエンジンごとに違う)<break time="300ms"/>:間(ポーズ)を入れる
たとえば社名を確実に読ませるなら、次のように書けます。
<speak>
<sub alias="コードアンドデザイン">Code and DESIGN</sub>のアプリです。
</speak>
読みだけでなく、高低アクセントまで指定できるエンジンもあります。たとえばGoogle Cloud Text-to-Speechでは、読みがなの中で ^ がアクセント句の始まり、! が音の下がる位置を表し、同じ「はし」を次のように読み分けられます。
<phoneme alphabet="yomigana" ph="^は!し">箸</phoneme>
<phoneme alphabet="yomigana" ph="^はし!">橋</phoneme>
SSMLは強力ですが、エンジンや声の種類によって効くタグが違う点に注意が必要です。同じサービスでも、新しい世代の声では一部のタグが使えないことがあります。採用する声を決めたら、使うタグが効くかを最初に確かめてください。
④ 合成前のデータを直す:VOICEVOXの音声クエリ
VOICEVOXは、文章をいきなり音声にするのではなく、まず音声クエリという中間データを作り、それを音声に変換する2段構成です。音声クエリには、アクセント句ごとの読み(モーラ)、アクセントの位置、音の高さ、間などが入っています。
この中間データを編集してから合成すれば、辞書に登録するほどではない一度きりの読みや、細かいアクセントまで直せます。エディターでアクセントや抑揚を手で調整する操作は、まさにこの中間データの編集です。
また、VOICEVOX ENGINEは、読みをカタカナと記号で書く「AquesTalk風記法」からアクセント句を作ることもできます(/accent_phrases で is_kana=true を指定)。記法の主なルールは次のとおりです。
- 読みはすべてカタカナで書き、アクセント句ごとに、音が下がる位置を
'で1つ示す - アクセント句は
/か、で区切る(、で区切ったときだけ間が入る) - カナの前に
_を置くと、そのカナを無声化する - アクセント句の末尾に全角の
?を置くと、疑問の抑揚になる
研修動画の台本やアプリの定型案内など、読みを完全に固定したい作り置きの音声に向いています。
直した読みを、自動テストで守る
読みの修正は、一度直したら終わりではありません。エンジンの更新、辞書への語の追加、声(モデル)の変更で、以前は正しかった読みが変わることがあります。毎回すべてを人が聞き直すのは現実的ではないので、読みの自動テストを用意します。
- 文例集を作る:社名・商品名・価格・日付・電話番号・住所・助数詞・英字の略語・業界用語など、そのアプリで読ませる表現を50〜200文ほど集める
- 正しい読みを記録する:各文の正しい読み(とアクセント)を、人が確認して書いておく
- エンジンが出す読みと照合する:VOICEVOXなら、音声クエリ(
/audio_queryの結果)に、エンジンが判断した読みとアクセントがAquesTalk風記法の文字列(kana)で含まれます。音声を作らなくても、「読みとアクセントが期待どおりか」を文字列として比べられます - 更新のたびに実行する:辞書の追加、エンジンや声の更新、前処理の変更のたびに自動で回し、読みが変わった文だけを人が聞いて確認する
読みを文字列で取り出せないクラウドTTSでは、合成した音声を音声認識(文字起こし)にかけて元の文と比べる方法もあります。ただし音声認識の側も間違えるため、大きな崩れを見つけるための網と割り切り、重要な文は人の耳で確認するのが現実的です。
💡 テストは「間違えると実害が出る読み」から
金額、日時、数量、薬の量、住所など、読み間違えると実害が出る表現から文例に入れていきます。読み間違いをゼロにすることより、「間違えてはいけない読みを、確実に間違えない」ことを優先します。
LLMの返答を読み上げるときの考え方
AIキャラクターや音声アシスタントのように、LLMが生成した文章をその場で読み上げるアプリでは、事前に全文を確認できません。そこで、次のように線を引きます。
- よく出る固有名詞は辞書に登録しておく(自社名、商品名、キャラクター名、地名など)
- システムプロンプトで読み上げ向けの書き方を指示し、記号や曖昧な表記を減らす
- 合成の直前に前処理をかけ、記号・URL・絵文字を取り除く
- 金額・日時など重要な情報は画面にも表示し、音声だけに頼らない
- それでも残るまれな読み間違いは許容範囲として扱い、ユーザーから報告を受けたら辞書に足していく
当社のAIキャラクターアプリお喋りずんだもんでは、ChatGPTが作った返答の語尾を、形態素解析(NMeCab+IPADIC)で「ずんだもんらしい口調」に変換したうえで、アプリに組み込んだVOICEVOXで一文ずつ音声にしています。LLMの出力と音声合成のあいだに、自前のテキスト処理の段を1つ持っていることがポイントで、読みの前処理や辞書による補正も、この段に足していけます。設計の詳細は「ChatGPTに“全部”は任せない」で解説しています。
まとめ
- 読み間違いは、正規化・読みの推定・アクセントのどこで起きたかを切り分けてから直す
- 直し方は、入力を整える → 辞書に登録する → その場で指定する → 中間データを直すの順に検討する
- 直した読みは、文例集と自動テストで守る。エンジンや辞書を更新するたびに回す
- LLMの返答を読み上げるアプリでは、重要な情報を画面にも出すことと、報告を受けて辞書を育てる運用をセットにする
音声合成エンジンそのものの選び方(クラウドTTS・VOICEVOX・端末内の合成の違い、料金の見積もり方、商用利用の条件、待たせない設計)は、音声合成AIをアプリに組み込むときの選び方で解説しています。
当社は、音声合成を組み込んだアプリを、企画から実装・App Store / Google Playへの申請まで開発しています。キャラクターの音声会話、案内や回答の読み上げ、台本からのナレーション生成など、「読みの正しさ」が品質を左右する機能のご相談は、お問い合わせからどうぞ。AI機能の開発全般についてはAIアプリ開発のページにまとめています。



