言語処理の代わりに数値読みモジュールを内臓したAquesTalk

当社の音声合成ミドルウェアAquesTalkは、言語処理部を持たない規則音声合成エンジンです。
メールやWebページの内容を読み上げるような用途には適しませんが、その代わりにタグで指定した数値を正確に読み上げる数値読みモジュールを内臓していますので、動的に数値を変えるなどのニーズにもマッチします。
なぜ、AquesTalkがこのような体系になっているか、その理由を説明いたします。

言語処理にはらむ問題

言語処理が内蔵されている音声合成エンジンは、アプリ開発からみると一見便利そうですが、実際にこれでシステムを構築してみると、いくつかの問題が顕在化します。

1. 辞書にない単語は読めない
2. 読みやアクセントの間違い
3. 言語辞書のデータサイズ

辞書にない未知語
通常、言語辞書は数１０万語の単語が登録されていますが、特に人名や地名などの固有名詞は辞書に含まれていないために読み間違うことが多々あります。
言語辞書に単語を登録する機能もありますが、読み間違いが発生する都度、アプリケーション側で辞書に単語を追加する必要があります。もちろん、この方法は開発段階で発声内容が確定されていないときには対応できません。

形態素解析の誤り
言語辞書に単語が含まれていても読み間違いやアクセントの間違いが起こる場合があります。
日本語は英語のように単語同士がスペースで分けられていませんので、形態素解析などの手法を用いて単語に分割します。ここで次の文を考えてみます。

畜産物価格安定法

上の文は、次のどちらにも分割することができます。

畜産/物価/格安/定法

畜産物/価格/安定/法

上は、ちょっとイジワルな例でしたが、単語の分割の違いにより、読み間違いが生じる結果があることがおわかりいただけたかと思います。

アクセント変化
さらに、日本語は単語の連結により読みやアクセントが変化します。
たとえば、「株式」と「会社」が結合すると、「会社」の先頭音韻の「か」が「が」に、「会社」のアクセントが平板から頭高アクセントに変化します。通常、言語処理はこれに対応するための処理が含まれていますが、残念ながら完全ではありません。そのため言語辞書に正しいアクセントが記述してあっても、文として生成したときに所望のアクセントが得られない場合があります。

結局、
これらの事由により、せっかく言語処理部を内蔵していながらも、アプリケーション側で読みやアクセントを直接指定するといった開発事例が数多く見受けられます。

また、言語辞書のデータサイズに関しては、２０万単語の言語辞書で２Mバイト程度のメモリが必要となります。音声合成を利用する環境によっても異なりますが、組み込み向け用途を考えると無視できないサイズです。

以上から、AquesTalkでは言語処理をはずし、その代わりに数値読みモジュールを組み込みました。
この数値読みモジュールは、棒読み、桁読み、助数詞をタグで指定するものです。文字表記から読み方を推定するといったTTSで使われる方式と異なり、あいまいさを無くすことで正確な読みとアクセントの音声合成を実現しています。

1 / 2 / 3