リアルタイム文字起こしの「固有名詞が化ける」問題に、ElevenLabsが手を打った

会議やライブ配信をその場で文字起こしさせると、必ずと言っていいほど固有名詞が化ける。自社プロダクト名、専門用語、人名——文脈を知らないモデルにとっては、音が似た別の単語に化けやすい一番の難所だ。事後に一括変換で直せる録音と違い、リアルタイムだと画面にそのまま流れてしまう。

ElevenLabsが、この地味だが効く痛点に手を入れてきた。文字起こしモデルScribeのリアルタイムWebSocketに、「Realtime keyterms」と「verbatim mode」の2つが加わった。

派手な新モデル発表ではない。だが、実務でリアルタイム文字起こしを使っている人ほど「それ、待ってた」と感じる類のアップデートである。

keyterms — 単語を先に教えておける

Realtime keytermsは、認識してほしい特定の用語をあらかじめモデルに渡し、そこへバイアスをかける仕組みだ。要は「この配信ではこの単語が出るぞ」と先に耳打ちしておく。

効果が出るのは、一般的な辞書に載っていない語だ。社内の略称、新しいSaaS名、業界用語、あるいは日本語なら独特の技術用語。こうした「モデルが初見の単語」ほど、事前登録の有無で結果が変わる。リアルタイムでは後から直せないぶん、入り口で精度を底上げできる意味は大きい。

正直に言えば、この発想自体は新しくない。録音済み音声のAPIでは以前からキーワード指定が使えたし、競合も似た機能を持つ。新しいのは、それを低遅延のリアルタイムストリームに載せた点だ。ストリーミング中に語彙のヒントを効かせるのは、バッチ処理より実装上のハードルが高い。そこを製品化してきた、という話である。

verbatim mode — 「えー」「あの」を消すかどうか選べる

もうひとつのverbatim modeは方向が逆で、フィラー語（filler words）の扱いを制御する。「えー」「あの」「まあ」といった言い淀みを、そのまま書き起こすか、除去してクリーンにするかを選べる。

用途で最適解が分かれるのがポイントだ。議事録や字幕なら、フィラーは邪魔なので消したい。一方、発話分析や医療・法務のように「言ったことをそのまま残す」正確性が命の場面では、勝手に消されると困る。verbatim（逐語）という名前どおり、この切り替えを明示的に持たせたのは理にかなっている。

あわせて、マイク設定エラーの通知や、セットアップ失敗時のマイクリソース解放といった、リアルタイムクライアントの信頼性改善も入った。地味だが、実運用でセッションが固まる事故を減らす種類の修正で、こういう積み重ねが安定稼働を支える。

この2つが揃うと何が変わるか

機能単体では小粒だが、組み合わせると効いてくる。

たとえばライブ配信の字幕。keytermsで番組固有の名詞を守りつつ、verbatimでフィラーを削れば、その場で「読める字幕」に近づく。人手の校正を挟む余地が少ないリアルタイムほど、入り口の精度とノイズ除去は直接品質に跳ね返る。

カスタマーサポートの通話も相性がいい。製品名やプラン名をkeytermsに入れておけば、会話ログの検索性が上がる。さらに文字起こしをそのままLLMに渡して要約・タグ付けまで自動化する流れを考えると、入力テキストがきれいなほど後段の精度も上がる。「文字起こしの質は、その先のAI処理すべての土台」という当たり前が、ここでも効く。

理想を言えば、keytermsを固定リストではなく、会話の流れから動的に候補を足していけるようになれば化ける。話に出た新語をその場で語彙に取り込めれば、初見の固有名詞にも強くなる。現時点でそこまでやるとは書かれていないが、リアルタイムに語彙を効かせる土台ができた以上、次の一手として十分あり得る方向だ。

評価

過大評価は禁物だ。これはエンドユーザー向けの派手な機能ではなく、Scribeを組み込んで自前の文字起こし体験を作る開発者向けの、WebSocket APIの改善である。多くの人は、この機能を使ったアプリ経由で恩恵を受けることになる。

それでも、リアルタイム文字起こしの「固有名詞が化ける」「フィラーが邪魔」という二大不満に、正面から手を入れた点は素直に評価したい。音声AIの競争が新モデルの精度勝負に偏りがちな中で、実務の使い勝手を詰めるこの手の更新は、地味でも効く。

対応状況や実装の詳細はElevenLabs公式のドキュメントで確認できる。文字起こしAPIの選び方全般は、主要サービスを比較した記事もあわせてどうぞ。