【ITニュース解説】My TTS kept stressing Russian words wrong. The bug was one line that deleted the answer.

このニュースは、言語学習サイトで使われている音声合成（TTS: Text-to-Speech）技術が抱えていた、ロシア語のアクセントに関する課題とその解決プロセスについて詳細に解説している。

発端は、サイト運営者が提供するロシア語学習コンテンツの音声において、ネイティブの教師から「アクセントが頻繁に間違っている」という指摘を受けたことだった。ロシア語では、単語のどの音節にアクセントが置かれるかによって単語の意味が大きく変わることがある。例えば、「за́мок」（城）と「замо́к」（鍵）は、アクセントの位置が異なるだけで全く別の意味を持つ。そのため、音声合成でアクセントを正確に再現することは、言語学習において非常に重要な要素となる。

サイト運営者は、学習者向けにテキストにアクセント記号（U+0301）を付与していた。これは通常、アクセントのある母音の後に挿入される記号だ。しかし、音声合成エンジンにテキストを送る直前に行われる「テキストのクリーンアップ」機能が、この大切なアクセント記号を含む全ての結合文字を削除してしまっていたことが判明した。さらに、日常のロシア語の印刷物では、アクセントがある場合に「ё」と表記されるべき単語が、アクセントがない「е」として書かれていることが多かった。音声合成モデルはこれらの情報を受け取ることができなかったため、全ての単語のアクセントを毎回自分で推測するしかなく、結果として多くの間違いが生じていたのだ。

この問題に対処するため、サイト運営者はいくつかの改善策を試みた。まず、クリーンアップ機能がアクセント記号を削除しないように修正し、失われていた「ё」も本来の形に戻した。さらに、音声合成モデルに対して、これらの記号が何を示しているのかを指示として与えた。この改善の前後で、25個のテスト項目を用いた検証が行われた。結果は明確だった。改善前の出荷されていた音声では21個中14個が正解だったのに対し、アクセント記号と「ё」を復元し、モデルに指示を与えた後の音声では21個中18個が正解に改善したのだ。特に、「ё」を含む単語のアクセントは、改善前は頻繁に間違っていたが、改善後は4回中4回全て正しく発音されるようになった。一方で、文脈によって意味が変わる同形異義語（例: до́маとдома́）のような単語は、アクセント記号を付けても正答率は約50%で推移し、これらはより高度な文脈理解が必要な課題として残された。また、Microsoft Azureのニューラル音声エンジンも試されたが、こちらはアクセント記号の有無でほとんど結果が変わらず、記号をうまく活用できていないことが示唆された。

次に、サイトの39,465件のテキスト全てに正確なアクセント情報を付与する作業が行われた。アクセントの取得源には優先順位が設けられた。まず、運営者自身が手動で修正した情報が最優先された。次に、サイトが既に学習者向けに提供している用語集のデータが利用された。そして、オープンソースのアクセントモデル「RuAccent」が使われた。これらの情報源が互いに矛盾する場合や、RuAccentモデルがアクセントを特定できない場合は、大規模言語モデル（LLM）がレビュアーとして活用された。LLMは、単語が使われている文脈全体を読み、最適なアクセントを判断した。約12,000トークン（単語や記号の単位）がLLMによるレビューを通過し、その過程でRuAccentの提案のうち約8%が誤っていることが発見された。これらの誤りの多くは、単語の格変化（例: окна́ / オクナー vs オ́кна / オークナ）に関するものだった。

音声生成の品質を保証するための仕組みも導入された。音声合成モデルは、同じ入力テキストに対しても異なる音声を生成することがあるため、生成された各オーディオクリップには品質チェックが実施された。まず、全てのクリップに対して長さが適切であるかのチェックが行われた。さらに、単一の単語からなるクリップについては、音声認識器を使ってアクセントが正しいかを詳細に検証した。このチェックは、まず母音の品質を基準とし、同点の場合は発音の持続時間で判断された。もしクリップがこのチェックに失敗した場合、最大で3回まで再生成が試みられた。それでもアクセントが修正されない「頑固な」単語については、最終手段として、アクセントのない「о」の文字を「а」に書き換えて音声モデルに送るという工夫が凝らされた。これは「アカーニエ」と呼ばれるロシア語の実際の音韻変化を模倣したもので、具体的には「за́мок」（城）のような単語のアクセント問題を解決するのに役立った。

このプロジェクトでは、いくつかの技術的な落とし穴にも遭遇した。その一つが、オーディオファイルの長さ検出に関する問題だった。ffprobeというツールを使って、パイプ（プログラム間でデータを直接受け渡す仕組み）から読み込んだMP3ファイルの長さを測定しようとした際、「N/A」（該当なし）という結果が返されてしまい、全てのクリップが長さチェックに不合格となってしまう事態が発生した。この問題は、オーディオを一度デコード（圧縮されたデータを元に戻すこと）してから長さを測定することで解決された。また、このようなバッチ処理を行う前に、必ず一つのクリップでテストを行うことの重要性も再認識された。

最終的な結果として、約36,000個のオーディオクリップが再録音された。これにかかったAPI利用料は約35ドルと、労力に比して非常に低コストだった。改善の結果、チェックセットにおける「ё」のアクセント間違いは約40%から約2%にまで劇的に減少し、その他のアクセント間違いも13%から1%未満へと大幅に改善された。生成されたクリップの82%は最初の試みで品質チェックをパスするようになり、効率も大きく向上した。しかし、142の単一単語のクリップは3回の再生成後も品質チェックをクリアできず、これらは最終的に人間の耳による確認が必要となった。このことは、機械だけではまだ、わずか3秒程度の短い単語クリップの正確性を完全に保証することが難しいという現状を示している。

この一連の取り組みは、ユーザーの具体的な問題を解決するために、バグの特定、既存技術の限界の理解、複数のデータソースやAI技術の組み合わせ、そして地道な品質保証のプロセスがいかに重要であるかを教えてくれる好例だ。