22言語を1モデルで聞き分ける──Saaras V4が音声認識をLLM側へ寄せた設計｜2026年9月28日版

2026年9月28日

音声波形が小さなニューラルネットを通り、複数の言語の文字列に分かれていく様子を表した概念図。

インドの Sarvam AI が公開した音声認識モデル Saaras V4 は、22のインド憲法指定言語と英語を1つのモデルで扱う。事前に「この音声はヒンディー語です」と指定しなくても、混ざった発話をそのまま投げれば通る。

面白いのは精度の数字より設計だ。従来の ASR が後処理スクリプトでやっていた整形・ローマ字化・翻訳を、3Bのハイブリッド状態空間モデルであるデコーダ側に押し込んでいる。音声認識が「専用モデル」から「音声を読めるLLM」に寄っていく、その具体例として読む価値がある。

公式ブログの掲載は2026年8月24日、ドキュメント上の一般提供は9月2日。技術メディアによる検証記事が出そろったのが9月25〜26日で、いま評価が固まりつつある段階にある。

この記事の要点

音声エンコーダ＋時間方向ダウンサンプリングのアダプタ＋3Bハイブリッド状態空間デコーダ、という3段構成
出力は5モード（逐語・整形・コードミックス・ローマ字・英訳）をモデル内部で切り替える
言語判定の誤り率は主要10言語で2.9%、22言語全体で5.22%（いずれもベンダー公表値）
提供はAPIのみ。ストリーミングの初回トークンまで150ms未満、バッチは最大2時間の音声

早見表：Saaras V4 の主要スペック

項目	内容
対応言語	インド憲法指定22言語＋英語（インド訛りを含む）
デコーダ	Sarvam-3B（3Bハイブリッド状態空間モデル、自社でフルスクラッチ学習）
出力モード	transcribe / verbatim / codemix / translit / translate
入力上限	REST 30秒、バッチ最大2時間、WebSocketで逐次
価格	音声1時間あたり₹30、話者分離ありで₹45
提供形態	API（Python 3.9+ / Node.js 18+ SDK）。セルフホスト手順はv3まで

何が変わったのか：後処理をモデルに畳み込む

インドの音声案件がしんどいのは、言語数だけではない。同じ1文の中でヒンディー語と英語が入り混じるのが日常で、話者は数字だけ英語で言い、単位はローカル語で言う。

従来型の構成だと、この整形が全部モデルの外側にあった。

逐語のテキストを ASR が吐く
数字・日付・句読点を正規化するルールを別に書く
ローマ字化したいならまた別のライブラリを通す
英訳が欲しければさらに翻訳APIへ

Saaras V4 は、この4段をプロンプトの引数1つに置き換えた。verbatim を指定すればフィラーまで含む発話そのまま、transcribe なら数字と日付が整形された形、codemix は英単語を英字のまま残した現地表記、translit はラテン文字、translate は英訳。

なぜデコーダが状態空間モデルなのか

構成は、音声エンコーダが波形を音響・音韻の埋め込みに変え、時間方向ダウンサンプリングのアダプタがそれを圧縮してデコーダの埋め込み空間に射影する、という流れだ。デコーダは Sarvam-3B。

Transformer の自己注意は系列長の2乗でコストが増える。音声は1分でもトークン列がかなり長くなるので、ここが素直に効く。状態空間系のデコーダは長い系列を線形寄りのコストで流せるため、アダプタによる圧縮と組み合わせて「数分の録音を1秒以内」という処理時間を成立させている（いずれも公表値）。

ストリーミングでは初回トークンまで150ms未満。人間の相槌が間に合う水準で、音声エージェントの応答設計に直接関わる数字だ。

キーターム・プロンプティング

固有名詞に弱いのは ASR 共通の弱点だ。Saaras V4 は、1リクエストに最大50語（各64文字まで）のキーワードを渡して認識を寄せられる。薬剤名、地名、商品コードのような閉じた語彙を持つ業務に効く仕組みで、ただし出力を保証するものではないとされている点は運用前に押さえておきたい。

ベンチマークはどこまで信じられるか

公表されている数字はいずれもベンダー計測だ。そのうえで、内容は具体的で検証しやすい形になっている。

英語：Hugging Face Open ASR Leaderboard 系のデータセット（AMI、GigaSpeech、LibriSpeech、SPGISpeech、VoxPopuli など）＋インド訛り音声の Svarah で、平均WERが最小と主張
インド諸語：Vistaar、Common Voice、FLEURS、Gramvaani、IndicTTS などで22言語すべてSOTAと主張
ノイズ環境：誤り率が Deepgram Nova-3 や OpenAI の GPT-4o 系の半分未満
文脈付き評価 IndicContextEval の L5 設定で、キーワード指定込みのWER 16.03%

注目したいのは言語判定（LID）の誤り率だ。主要10言語で2.9%が、22言語全体では5.22%に上がる。つまり話者の少ない言語ほど「何語か」の入口で外す。22言語対応という見出しの裏側にある現実的な勾配で、対応言語数の比較（Deepgramは11、ElevenLabsは14とされる）だけでは見えない部分になる。

ここがポイント: 「22言語対応」の価値は、言語ごとの精度表よりも、言語判定と出力整形をモデル内に取り込んだことでアプリ側のコードが減ることにある。

日本の開発現場から見た読みどころ

日本語は対象外なので、そのまま使う話にはならない。効くのは設計の借用と、比較軸の更新だ。

音声機能を実装する開発者

自前の正規化・翻訳パイプラインを、モデルの出力モードで置き換えられないか見直す価値がある
REST 30秒／バッチ2時間という入力上限は、会議録起こしと対話エージェントで設計が分かれる典型例
LiveKit Agents、Pipecat、Vercel AI SDK との接続が用意されており、音声エージェント側のフレームワーク選定にも影響する

多言語の業務を持つ企業

インド拠点のコールセンターや現場音声を扱うなら、言語指定なしで通ることが運用コストに直結する。一方で提供はAPIのみで、セルフホストのドキュメントは現時点でv3までしかカバーしていない。音声データを外に出せない業務では、そこが先に効く制約になる。

価格の見方

音声1時間あたり₹30、話者分離込みで₹45。為替次第だが日本円では1時間あたり数十円の水準で、長時間の録音を回す用途では既存の英語圏サービスと比較検討する対象になる。単価だけでなく、後処理を外部に持たなくていい分の実装工数も含めて見たほうが実態に近い。

継続ウォッチ

セルフホスト対応：v4のオンプレ提供が来るか。データ持ち出し制約のある案件はここで採否が決まる
第三者による再現：LIDの5.22%とノイズ耐性の比較値が、独立評価でどう出るか
状態空間デコーダの波及：音声認識のデコーダを非Transformer化する設計が他ベンダーに広がるか
キーターム機能の実測：50語の語彙バイアスが、実際の業務語彙でどれだけ効くか

今日のまとめ

Saaras V4 の本質は言語数ではなく、ASRの外側にあった整形処理をLLMデコーダの中に畳み込んだところにある。出力モードの切り替えがプロンプト引数になり、言語判定もモデル内で済む。

ただし公表値はすべてベンダー計測で、22言語全体のLID誤り率は主要10言語の約1.8倍。提供はAPI限定で、オンプレ手順はv3止まりだ。次に確認すべきは、v4のセルフホストが出るかと、独立評価でノイズ耐性の主張がどこまで残るか。この2点が、実務投入の判断を分ける。

参照リンク

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！