WIGTN CREW
WIGVO リアルタイム電話通訳
Webクライアントと任意の電話番号の間を2つのリアルタイム音声セッションでつなぎます。受ける側はアプリも通信キャリア連携も不要で、ただ電話に出るだけです。
ACL 2026 採択- 役割
- リレーサーバーとデプロイインフラ担当 · 論文共著者 (5人中1人)
- 期間
- 2026
- 使用技術
- FastAPIPython 3.12OpenAI Realtime APITwilio Media StreamsDockerCaddy
改善結果
555ms
発信者から受信者までの中央値遅延 (プロダクション実測)
0件
147通の通話中に発生したエコー起因の翻訳ループ
$0.28
通話1分あたりのコスト
01何であるか
一般の電話網の通話で二つの言語の間を双方向にリアルタイム通訳するオープンソースシステムです。Webクライアントと任意の電話番号の間を2つの同時音声セッションで接続し、伝送には通信APIのメディアストリームを使用します。受ける側はアプリをインストールする必要も、通信キャリアと連携する必要もありません。ACL 2026 System Demonstrations トラックに採択され、MITライセンスで公開されています。
02解くべき問題
電話網で双方向通訳を行うと、固有の障害が発生します。通訳された音声が相手のスピーカーから流れ、その音がマイクに再び入ってまた翻訳されるエコーループです。一度はまると、通話が終わるまで同じ言葉が繰り返されます。しかも電話網は帯域が狭く遅延に敏感なため、よく使われるエコー除去技法をそのまま適用するのは困難です。
03検討した代替案
エコーループを断ち切る方法がシステムのアイデンティティを決定しました。論文では3つの方向性を比較しました。
| 案 | 利点 | 課題 |
|---|---|---|
| 音響エコー除去(AEC) | 通話品質分野の標準技法で、実装が多い | 電話網は帯域が狭く遅延変動が大きいため参照信号の整列が難しく、漏れ出た通訳音声を十分に消せない |
| 単一セッションで双方向処理 | セッションコストが半分で、構成が単純 | いま聞こえている音声が相手の発話なのか直前に送り出した通訳なのか区別できず、自分の出力を再翻訳するループを防げない |
| 二重セッション + エコーゲーティング採用 | 方向ごとにセッションを分離して話す順番を判定し、自分の出力が戻ってくる経路自体を遮断 | 2つのセッションの状態とコストを管理する必要があり、リレーサーバーがリアルタイムのボトルネックになる |
04私が担当した部分
リレーサーバーとデプロイインフラを担当しました。リレーサーバーは2つの音声セッションと通信APIのメディアストリームの間でオーディオをやり取りし、エコーゲーティングを実際に執行する地点です。通話がリアルタイムで動いている間に停止や遅延があってはならないため、機能を追加することよりも、リソースとライフサイクルを正確に管理する仕事がほとんどでした。
- 同時通話の容量を1つのロックの下で管理し、予約と活性状態の合計が常に上限を超えないよう保証しました
- 予約、確定、終了へと続く通話ライフサイクルを整理し、準備中に失敗した通話がリソースを掴んだまま残らないようにしました
- オーディオルーティングやリングバッファ、音声活動検出、割り込み処理などのリアルタイム経路を構成しました
- セッションが切断されたときに復旧する経路と、ハルシネーション応答をフィルタリングする処理を入れました
- リクエストレート制限やテナント認証キーの発行など、サーバーの入口を整理しました
- 遅延とイベントループの停滞を追跡する観測レイヤーを付け、通話中のボトルネックを事後に確認できるようにしました
- Docker Compose と Caddy ベースのデプロイ構成を作り、証明書の自動更新とともに運用しました
05結果
論文の中核的貢献である二重セッションエコーゲーティングは、決定論的な無音注入とエネルギーベースの音声活動検出でどちらが話す順番かを判定し、自分の出力が戻ってくる経路を塞ぎます。プロダクション環境では発信者から受信者までの中央値遅延555ミリ秒、147通の通話中エコーループ0件、通話1分あたり0.28ドルを記録し、韓英通話155通で評価しました。対象言語はこのペアに限定されません。リレーサーバーには47個のテストファイルを置き、ユニット、コンポーネント、統合、負荷試験に分けて検証しています。