コードスイッチング音声、ASRのWERどれくらい悪化する?

鈴木 蓮
鈴木 蓮 20代・ ソフトウェアエンジニア
Hugging FaceにServiceNow AIが上げてたベンチマーク記事を読んで、けっこうハマった。
テーマはコードスイッチング——つまり「Zoom会議のパスワードをreset してほしいんですけど」みたいに、一文の中で言語を切り替えて話すやつのASR精度検証だ。
世界人口の過半数がバイリンガルという前提で、enterprise の voice agent がそれをどれだけ拾えるか、独自データセットまで作って計測してる。

benchmark の設計がえぐい



データセットは Spanish-English が 259 件、French-English が 298 件、Canadian French-English が 188 件、German-English が 173 件の計 918 件くらい。
GPT-5 でコードスイッチングテキストを生成して、ElevenLabs Multilingual V2 で音声合成、さらに母語話者の言語学者がレビューして不自然なやつを除外してる。
このパイプラインの丁寧さ、普通に参考になる。
合成音声だけど review ステップを人間が踏んでるのが評価の信頼性を上げてる。

評価指標は WER (Word Error Rate)、SWER (Semantic Word Error Rate)、AER (Answer Error Rate) の3本立て。
WER は完全一致の精度、SWER は意味が保たれてるかどうか、AER は downstream task として答えが合ってるかどうか。
Voice agent の末端での誤りが、ticket routing とか FAQ 回答まで伝播するから3軸で測るという設計思想は筋が通ってる。

トップ3として出てきたのが ElevenLabs Scribe V2、Gemini 3 Flash、AssemblyAI Universal 3-Pro だった。
Gemini 3 Flash がここで名前を出してくるのはちょっと意外で、正直 Whisper 系が堅いと思ってたから認識が更新された。

自分のコードのどこを直すか



いま個人開発で日英混在ユーザーが使う可能性のある音声入力 UI を組んでる。
具体的には、ユーザーが話した内容を transcript して LLM に渡すフローで、ASR は Whisper large-v3 を使ってた。

# 今の構成
ffmpeg -i input.webm -ar 16000 -ac 1 -f wav - \
  | whisper-cli --model large-v3 --language auto

これで日本語と英語が混じる発話をテストしたとき、English の tech term が化けることが何度かあった。
「push notification の設定を変えたい」が「プッシュ application の設定を変えたい」みたいな転写ミスで、LLM への入力が汚れる。
WER 単体で見るとそこまで悪くないけど、AER 相当のところで地味に痛い間違い方をしてた。

今回のベンチマーク記事を読んで、まず ElevenLabs Scribe V2 の API を試したくなった。
AssemblyAI は以前 v2 を触ったことがあって、日本語サポートが微妙だった記憶があるから Universal 3-Pro で変わってるかも確認したい。

# 乗り換え候補の整理メモ
asr_candidates:
  - name: ElevenLabs Scribe V2
    cost_per_min: 要確認
    multilingual: true
    ja_support: 未確認
  - name: AssemblyAI Universal-3-Pro
    cost_per_min: 0.006 USD
    multilingual: true
    ja_support: 要テスト
  - name: Whisper large-v3 (self-hosted)
    cost_per_min: 0 (GPU代のみ)
    multilingual: true
    ja_support: ok

コスト面が一番気になるのはここで、self-hosted Whisper のランニングコストと外部 API の per-minute 料金を比較する必要がある。
個人開発レベルのトラフィックなら API の方が安く済むケースもあるし、Scribe V2 の料金表を週末に掘ってみる予定。

WER だけ見てると詰む



記事で地味に刺さったのが SWER と AER を別で計測してる理由の説明だった。
コードスイッチングの transcript って、WER 上は軽微な差でも、downstream の LLM が違う動作をすることがある。
「password reset」が「パスワード reset」になるのは WER 的に 1 word のエラーだけど、ticket の routing タグが変わるなら実害は大きい。
自分もこれまで WER だけで ASR を評価してたので、eval の設計を見直すことになった。

彼女に「何そんな真剣に読んでるの」って言われて「voice agent がコードスイッチングをどう処理するか」と答えたら「何語?」ってなったけど、まあそういうもんだ。

ベンチマークデータセットと評価ハーネスの AU-Harness も公開してるので、手元の音声で回すとこまでやってみたい。
日本語-英語ペアはカバーされてないけど、データ生成パイプラインの設計は流用できそうだから、自前でデータ作るときの参考にする。

無料相談受付中

AI開発・DX推進についてお気軽にご相談ください。オンライン30分から。

無料相談を申し込む