【ITニュース解説】Building sentence-level alignment for bilingual audio

「Bilingual Mix」というプロジェクトは、異なる2つの言語で話された同じ内容の音声ファイルを、交互に再生される1つのMP3ファイルに変換する技術を開発している。例えば、英語と中国語で同じ物語や授業、ポッドキャストが収録されている場合、それを「英語の文→中国語の文→次の英語の文→次の中国語の文」という形でつなぎ合わせることを目指している。

この技術が解決しようとしている問題は容易ではない。一般的な語学学習アプリは、まずテキストを翻訳し、それから音声を生成するという手順を踏むことが多い。しかし、実際に録音された音声ファイルを基にすると、さまざまな課題に直面する。例えば、同じ内容であっても、言語によって文の区切りが異なったり、話すスピードがバラバラだったりする。また、片方の音声にはイントロの音楽が入っていたり、余計なナレーションが含まれていたり、編集の仕方が違ったりすることもある。これらの課題を乗り越え、正確に文レベルで音声を同期させるための工夫が、このプロジェクトの核となる。

まず、最初の重要なステップは、音声ファイルを「文字起こし」することだ。しかし、ただテキストに変換するだけでは不十分で、いつからいつまでその言葉が話されたのかを示す「タイムスタンプ」が非常に重要になる。このプロジェクトでは、Groqというサービスが提供する「Whisper-large-v3-turbo」という高性能な音声認識モデルを利用している。このモデルに各音声ファイルを送信し、単語単位と短い音声区間（セグメント）単位の両方で、それぞれの開始時刻と終了時刻を正確に取得する。この詳細なタイムスタンプ情報があるからこそ、後の工程で無音部分を正確にカットしたり、修正された文の区切りが本当にその言葉を含んでいるかを検証したりすることが可能になる。つまり、最終的に必要なのは、2つの音声ファイルそれぞれについて、対応する文の開始・終了時刻を示す4つの数字（トラックAの開始・終了、トラックBの開始・終了）である。

次に、この文字起こしされた情報を使って、2つの言語の音声がどこで一致するかを特定する「アライメント」という作業を行う。初期のバージョンでは、音声認識で区切られた大きなセグメント全体を基に一致を探していたが、これには問題があった。片方の言語では1つの長い文になっている箇所が、もう一方の言語では2つの短い文に分かれているような場合、アライメントがうまく機能せず、一度間違ったペアリングがなされると、その後の全体がずれてしまうことが頻繁に発生した。そこで、現在のシステムでは、まず文字起こしされたテキストをさらに短い「音声単位」に分割する。これらの単位は、約6.5秒以内、1つの候補グループにつき3単位まで、グループ全体の長さは最大8秒といった厳密な制限の下でのみ結合される。また、「えーと」や「um」のような明示的なノイズと判断される発話は、アライメントの邪魔になるため除去される。このように短い単位で処理することで、各音声認識セグメントが常に完璧な文であると仮定することなく、より柔軟で正確なアライメントが可能になる。

アライメントの精度を高めるために、テキスト情報だけでなく、多言語対応のAIモデルと時間情報を組み合わせる工夫がされている。テキストだけでは、「そこ」という言葉が文中のどの「そこ」を指しているのかなど、意味が曖昧になることがある。また、異なる吹き替えでは、同じ場面でも使われる言葉が違うこともある。そこで、「Cloudflare Workers AI」が提供する「BGE-M3」という多言語対応のモデルを使って、候補となる音声区間の意味を数値データ（埋め込みベクトル）に変換し、その意味的な類似度を比較する。これに加えて、元のタイムスタンプと、それぞれのトラック内での相対的な進行度（全体の中でどのくらいの割合の位置にいるか）も考慮に入れる。単に最も近いタイムスタンプのものを採用するのではなく、両方のトラックが概ね22秒から45秒の範囲内で時間的に近い候補を選び出す。この「時間帯（タイムバンド）」の概念が、アライメントをより堅牢にしている。さらに、意味的な類似度にも最低限のしきい値を設けており、時間的なずれが大きくなるほど、この類似度判定はより厳しくなる。特に1、2語のような短い発話では、偶然意味が一致してしまう可能性が高いため、より厳格なチェックが行われる。複数の短い単位を結合して1つの候補とする場合も、その中の個々の単位すべてが一致をサポートしている必要がある。一部の強いフレーズだけで、その周辺の弱いフレーズまで巻き込んで一致とすることはしない。

候補となるペアが洗い出されたら、次に、それらのペアの中から最適な「経路（パス）」を選択する作業が行われる。これは「動的計画法（ダイナミックプログラミング）」という技術を使って、両方の文字起こしを順方向に進むような経路を選ぶ。これは「モノトニックなパス」と呼ばれ、一度一致したペアを選んだら、次に選ぶペアは必ず時間的にその先にあるものでなければならないというルールに従う。これにより、意味的に似ているからといって時間的に逆戻りしたり、全く関係ない遠い場所に飛んでいったりするような、致命的な誤りを防ぐことができる。また、この選択プロセスでは「曖昧さ」もチェックされる。例えば、同じ音声単位に対して、ほぼ同等の二つの候補が存在する場合、そのペアはリスクが高いと判断され、最終的な結果から除外されることがある。これは、繰り返されるセリフやリフレイン、一般的な挨拶などで、複数の場所で同じようなフレーズが出てくる場合に特に重要となる。

ユーザーに対しては、システムの「品質シグナル」が提示される。このシステムは、翻訳の正確さを保証するものではなく、あくまで音声のアライメント（同期）の正確さを示す「保守的なスコア」を表示する。このスコアは、意味的な類似度の平均と、両方のトラックでカバーできた時間の割合のうち、低い方を取る。例えば、片方の言語で大きなセクションが欠落した場合、残りのペアがどれほど完璧に見えても、全体のスコアは大きく下がるように設計されている。これは、完璧ではない部分を正直にユーザーに伝えるための工夫だ。最終的な音声が生成される前に、ユーザーはレビュー画面で各元のクリップを聞き、提案されたテキストを確認し、間違っていると判断したペアを手動でチェックを外して除外できる。自動アライメントはあくまで「下書き」であり、すべての意味的な一致が正しいことを約束するものではない、というスタンスが明確にされている。

ユーザーがペアを確認し、最終的な内容に納得したら、いよいよ音声ファイルの生成（レンダリング）が行われる。このレンダリング作業は、サーバー側ではなく、ユーザーのウェブブラウザ（クライアント側）で行われる点が特徴的だ。ブラウザは「Web Audio API」を使って、元の2つの音声ファイルをデコードする。そして、ユーザーが確認した開始・終了時刻に基づいて、PCM WAV形式の短い音声クリップを生成する。これらのクリップは、約12ペアずつまとめてバッチ処理され、ブラウザ上で動作する「ffmpeg.wasm」という動画・音声変換ツールを使って192 kbpsのMP3形式にエンコードされる。最後に、すべてのバッチが同じエンコーダー設定で処理されているため、ストリームコピーという効率的な方法で結合され、1つのMP3ファイルが完成する。このように、処理負荷の高い音声処理をブラウザ側で行うことで、生成された音声ファイルをサーバーに再度アップロードする必要がなくなり、サーバーの負担を軽減し、ユーザーは迅速に最終的なファイルを受け取れるというメリットがある。サーバーは文字起こしと意味的なアライメントという主要な処理を担当し、クライアントは最終的なカットと結合を担当するという役割分担がされているのだ。

このプロジェクトの今後の改善点としては、音声の重なり（例えば、複数の人が同時に話している状況）や、ボイスオーバー（元の音声の上に別の音声が被せてある状況）の処理をより良くすること、そして現在の保守的なスコアではなく、統計的により正確な確信度モデルを開発することの二点が挙げられている。語学学習ツールという特定の目的に特化しているため、カバー範囲にギャップがあっても、間違った文を自信満々にペアリングしてしまうよりも、短くても正確な結果を提供する方がユーザーにとって有用であるという判断がされている。

最後に、このプロジェクトから得られた重要な教訓がいくつかある。音声認識のタイムスタンプを利用する際は、絶対的な時間と相対的な進行度の両方を考慮し、音声の一致経路は常に順方向（モノトニック）に進むようにすること。そして、レンダリング前にシステムの不確実性をユーザーに伝えること。これらの工夫が、多くの予期せぬエラーを防ぐ上で非常に効果的だった。