声質変換の遅延を減らす7つの方法と、その代償

「遅延を減らしたいのですが、どうすればいいですか」。手を入れられる場所は、大きく7つあります。ただし、どれから手をつけるかは、方法の一覧からは決められません。最初にやることは、自分の構成で遅延を測って内訳を出すことです。

この記事で扱うのは、話す内容はそのままに、声だけを別人のものに変えるリアルタイム声質変換（ボイスチェンジャー）です。マイクに声を入れてから変わった声が耳に届くまでの時間を遅延（レイテンシ）と呼びます。変換プログラム内部の遅延は、判断に必要な音がたまるのを待つ時間と、たまった音を計算する時間に分かれます。内訳のしくみは ボイスチェンジャーの遅延はどこで生まれるのか で説明しています。

7つの方法も、この分解に沿って3つの系統に分かれます。

系統	方法
待ち時間を減らす	1. ためる量を減らす／2. 先読みを減らす／3. 先読みを前提にしない構造にする
計算時間を減らす	4. 声を組み立てる部分を軽くする／5. プログラムを小さく作り直す／6. 機械を速くする
工程そのものを変える	7. 音声認識への依存を外し、足りない未来は予測で補う

どこから手をつけるかは、遅延の内訳で決まります。

• 待ち時間が支配的なら、効くのは「ためる量・先読み・構造」の側で、GPUではほとんど減らない
• 計算時間が支配的だと測って分かってから、部品の軽量化やハードウェアを検討する
• 小さな調整で目標に届かなければ、工程そのものを変える段階に入る

待ち時間を減らす: ためる量・先読み・構造

そもそも、プログラムはなぜ待っているのでしょうか。理由は2つあります。ひとつは、変換の判断のために、マイクの音をある程度まとめてから処理すること。もうひとつは、少し先の音まで聞いてから判断することです。この後者を先読み（look-ahead）と呼びます。同時通訳者が文の続きを少し聞いてから訳し始めるのと同じで、待つ対象が話の続きではなく音の続きになります。

待つ理由が2つなら、打ち手は3つです。まとめる量を減らす、先を見る量を減らす、先を見なくても動く構造にする。

1. ためる量を減らす

ためる量を減らすことは、待ち時間を直接減らします。ある研究では約0.16秒ためており、それが変換処理内の遅れ（約0.19秒）の大半を占めていました[1]。代償は音の品質です。少ない材料で判断することになるので、変換の精度が落ちます。ためる量をあとから変えられるように学習させ、1つのプログラムで「品質重視」と「速さ重視」を切り替えられるようにした研究もあります[1]。

2. 先読みを減らす

ある方式では0.05秒ほどを先読みに使っており[2]、減らせばそのぶん速くなります。引用した研究は、先読みの短い関連方式で「その人らしさ」（話者性）の評価が低いことに触れ、抑揚を目標の声に合わせるには先の情報が足りないのではないか、という仮説を示しています[2]。ただし、同じ方式のまま先読みの長さだけを変えて品質を測り比べた公開文献は確認できていません。どこまで削れるかは、品質を確かめながら決めることになります。

3. 先読みを前提にしない構造にする

2番をさらに進めて、過去と今の音だけで声を作る設計に変えれば、先を待つ必要そのものがなくなります。先読みをゼロにしきれず、わずかに残したまま設計された方式もあります。代償が出るとすれば、2番と同じく、その人らしさを含む品質の側です。

計算時間を減らす: 部品・モデル・機械

計算時間のほうが支配的なら、こちらの3つです。同じ系統でも、計算そのものを減らす（4番・5番）か、同じ計算を速く実行する（6番）かで分かれます。

4. 声を組み立てる部分を軽くする

分析した情報から実際に聞こえる音を作る部分を、ボコーダと呼びます。携帯電話でも動くよう設計された軽くて高品質な方式が公開されており、ここを取り替える代償は小さく済みます。ただし、効く場面は限られます。ある研究の構成では、ボコーダは計算時間の3割ほどを占める一方、遅れ全体ではわずか4%程度でした[1]。待ち時間が大部分を占める構成では、重そうに見える部分を速くしても体感はほとんど変わりません。

5. プログラムを小さく作り直す

モデル自体を軽くすれば、計算時間を縮められます。名古屋大学の研究グループは、計算をあえて間引いて軽くする手法（スパース化）などを組み合わせ、CPUのコア1つだけで動く低遅延の声質変換を実現しました[3]。この系統の出発点となった論文には、TARVO代表が著者として加わっています[4]。計算を粗くして軽くする量子化で、全体の遅延を約0.4秒から約0.32秒に縮めた例もあります[6]。代償は、作り直す手間そのものです。量子化が声の自然さやその人らしさに与える影響を定量した公開文献は確認できていません。

6. 機械を速くする

機械の入れ替えで縮められるのは、計算時間だけです。音がたまるのを待つ時間も、先読みの時間も、機械の速さとは無関係です。計算が一瞬で終わっても、0.16秒の待ち時間は残ります。この記事で挙げた研究の多くも、遅延の測定はCPUのコア1つという条件で行っています[1,2,3]。GPUなしのノートパソコンやスマートフォンでの動作を掲げた技術発表も出てきています。内訳を測らないままの買い替えは、最後に回します。

7. 小さな調整で届かなければ、工程そのものを変える

1〜6番は、いまの作りを保ったままの調整や交換です。それで目標に届かないときは、工程そのものを変える段階に入ります。

多くの方式は、「何と言っているか」をいったん認識する工程（音声認識）を途中に挟みます。この依存を外して全体をひとつながりで学習させ、足りない未来の情報は予測で補う——この組み合わせで待ち時間を大きく削った研究が公開されています[5]。同じ系統の前の方式が変換処理内で約0.19秒だったのに対し[1]、この方式は約0.05秒まで縮めながら、品質の評価は同程度と報告されています[5]。調整では届かない水準に、構造の変更で届くことがある、という例です。

予測が外れたときに品質がどう崩れるかを数値で評価した公開文献は確認できていません。この研究では、その人らしさの評価は予測に使う情報の量にあまり左右されなかった可能性も報告されています[5]。

どこから手をつけるかは、実測した内訳から決まる

順番は方法の番号ではなく、測定結果で決まります。

1. 自分の構成で遅延を測り、待ち時間と計算時間の内訳を出す
2. 待ち時間が支配的なら、1〜3番（ためる量・先読み・構造）から検討する
3. 計算時間が支配的なら、4〜6番（部品・モデル・機械）から検討する
4. 小さな調整で目標に届かなければ、7番（工程の変更）を検討する

プログラム側をどれだけ削っても、その外側で時間を食われます。入口と出口のオーディオバッファやOSの設定で乗るぶんは ボイスチェンジャーの遅延はどこで生まれるのか で説明しています。目標を決めて、既存の方法で届くかを測り、届かないならどこを作り替えるか。この見極めを含む技術調査を、TARVOでは受託で承っています。詳しくは AI受託開発 をご覧ください。