Soniox STT v6：60以上の言語の音声認識・翻訳・エコーキャンセリング

60以上の言語のコードスイッチングとフォーマットにおけるstt-rt-v6の変更点

単一言語のストリーミングエンジンではなくSonioxを選ぶ最大の理由は、一文の中での多言語コードスイッチングの処理能力にあります。技術メモを音声入力したり、中国語、英語、フランス語が混ざり合う会議や、前触れなくスペイン語と英語が切り替わる会議で話したりする際にも、stt-rt-v6は言語の切り替え操作や個別の音声ルーティングを必要とせず、その場で表記体系を切り替えます。安定した接続環境では、最初のトークンが表示されるまでのエンドツーエンドのストリーミング遅延は500ミリ秒から1秒の間に収まります。

v6では、発話された数値、通貨の金額、英数字の製品コードが、単語のつづりではなく、自然にタイピングする形式にずっと近い形でフォーマットされて返ってきます。ただし、v6では音声ディクテーションコマンドの扱いが変更されています。period、new line、scratch thatといったフォーマット指示を声に出して言った場合、モデルはそれらを句読点に変換したり直前の節を削除したりするのではなく、文字どおりの単語として文字起こしします。カスタムの音声ディクテーションツール内でstt-rt-v6を使用する場合、クライアントアプリケーション側でトークンストリームからこれらの文字どおりのコマンドフレーズを解析し、テキスト編集を自ら実行する必要があります。

また、60言語という上限がどこにあるのかを把握しておくことも重要です。Sonioxはヨーロッパ、アジア、中東の主要言語を単一のモデルでカバーしていますが、すべての地域の話し言葉を網羅しているわけではありません。ネパール語、シンハラ語、クメール語、ビルマ語、ラオス語、アムハラ語、アルメニア語、ジョージア語、モンゴル語、アイスランド語、アイルランド語、ジャワ語、ヨルバ語、ズールー語、ハウサ語、ソマリ語などの言語は、対応言語リストに含まれていません。話者がこれらの言語のいずれかを使用する場合、言語設定で選択したりSonioxから現地文字での文字起こしを取得したりすることはできないため、それらの特定のロケールには引き続きフォールバック用のプロバイダが必要になります。

ヘッドホンなしで動作するAgent Text InputとVoice Echo Cancellationの仕組み

ライブ音声エージェントやデスクトップのキャプション表示における運用上の最大の悩みは、音響エコーです。ヘッドホンを使わずにノートブックのスピーカーからAIアシスタントの音声やリモート会議の参加者の声を再生すると、マイクがそのスピーカー出力を拾い、音声認識ストリームにそのまま送り返してしまいます。結果として文字起こしエンジンはコンピュータ自身の声をユーザーが話したかのように文字起こししてしまい、誤った割り込みを引き起こして会話のキャッチボールを台無しにします。

Soniox STT v6は、リアルタイムモデル内のAgent Text InputとAgent Voice Echo Cancellationによってこの問題に対処します。OSレベルのハードウェア音響エコーキャンセリングだけに頼るのではなく、音声エージェントが話している正確なテキストをAgent Text Input経由でアクティブなstt-rt-v6セッションに入力します。文字起こしエンジンはスピーカーから出力されている音声のテキスト内容を把握できるため、Agent Voice Echo Cancellationはユーザーの声を聞き取り続けながら、マイクの入力ストリームから一致する発話を除去します。スピーカーのミュートを解除したまま文の途中でエージェントに割り込んでも、ストリームは実際に人間が話した内容だけを文字起こしします。

ここには、この機能をすぐに利用できるかどうかを左右する重要なアーキテクチャ上の境界線があります。

• 応答スクリプトが既知の音声エージェント： 対話型のAI音声エージェントを構築している場合、バックエンドはテキスト読み上げエンジンが音声を再生する前、または再生中にLLMのテキスト応答を生成します。正確な応答テキストがすでにメモリ上にあるため、それをAgent Text Inputに渡すだけでそのまま機能します。
• 音声ディクテーションおよび人間同士の双方向会議： スタンドアロンの音声ディクテーションアプリを構築している場合や、ZoomやTeamsでの双方向通話をスピーカーフォンで録音している場合、アプリ側には通話相手がこれから何を話すかという事前作成されたスクリプトがありません。通常のディクテーションでは、Agent Text Inputは何の効果もないためオフのままにしておくべきです。ヘッドホンなしのスピーカーフォン会議でSonioxのエコーキャンセリングを利用する唯一の方法は、二系統の回避策をとることです。つまり、一方のリアルタイムストリームを実行してリモート話者からのシステム音声を文字起こしし、同時にそのライブ文字起こし結果をAgent Text Inputとしてマイクストリームに入力することで、室内への音漏れを抑制します。

ライブ翻訳の制限事項と話者ダイアライゼーションにおけるコンテキストの落とし穴

Soniox STT v6では、文字起こしと同じストリーミングWebSocket接続内でリアルタイム翻訳を実行できるため、別のAPIを接続することなく低遅延の字幕を表示したい場合に便利です。実際のワークフローでこれをテストしてデプロイしてみると、翻訳と話者ダイアライゼーションにおいて二つの動作制限が浮かび上がります。

第一に、Sonioxクライアントでone_way翻訳を設定する場合、target_languageフィールドは単一の言語文字列しか受け付けません。一つの英語ストリームからスペイン語、フランス語、日本語のライブキャプションを配信しようとして配列や複数のターゲット言語を渡すと、APIは余分な言語を黙って破棄し、最初の言語のみを出力します。ライブウェビナーやイベント向けに複数の翻訳言語を同時に出力するには、ターゲット言語ごとに個別のWebSocketセッションを開く必要があります。さらに、stt-rt-v6はソース音声の文字起こしにおいては（特に専門用語やホットワードをcontextパラメータに入力した場合に）高い精度を発揮するものの、スラングやライブ配信のテンポの速い掛け合いを処理する際、内蔵の翻訳機能は専用の大規模言語モデルと比べて明らかに硬い表現になります。300ミリ秒の短縮よりも翻訳の自然さが重要な場合、私はstt-rt-v6を文字起こし専用として使用し、確定した文を前後の会話コンテキストとともに外部のLLMへパイプしています。

第二に、誰が話しているかをラベル付けするために話者ダイアライゼーション（enable_speaker_diarization: true）をオンにする場合、context.textペイロードの文字数に注意する必要があります。Sonioxのドキュメントでは最大8,000トークンのコンテキストが許可されていますが、3,000文字程度のcontext.text文字列を渡すと、話者ダイアライゼーションがエラーコードも出さずに黙って機能しなくなり、返されるすべてのトークンが"1"や"2"ではなくspeaker: nullになります。各コンテキストブロックを400文字前後（専門用語と参加者名を合わせて合計800文字程度）に収めることで、話者ラベルを維持したままホットワードによる精度向上の恩恵を受けられます。また、二人が話している際の単語のタイムスタンプは正確に調整されるものの、話者間にポーズなしの素早い割り込みの応酬があると、両者の声が単一の途切れない文ブロックに結合されてしまうことがある点にも留意してください。

250msの遅延削減とWebSocketの401エラーの修正

リアルタイムアプリケーションにstt-rt-v6を組み込む際、トラブルの多くはモデルの精度ではなくWebSocketのセッション管理から生じます。三つの接続設定を調整することで、接続の切断を防ぎ、毎回のターンから目に見えるラグを削ることができます。

LiveKitのようなフレームワークでローカルの音声区間検出（VAD）を実行して話者が話し終えたタイミングを検知する場合、単に音声ストリームをフラッシュするだけでは、Sonioxのサーバー側エンドポイント処理が文の終了を判定するのを待つことになります。実際には、その自動エンドポイント判定を待つと、最後に発話された単語から664〜1,058ミリ秒かかります。VADが無音を検知した瞬間にWebSocket経由でJSON制御メッセージ{"type": "finalize"}を明示的に送信すれば、確定した文字起こし結果が440〜475ミリ秒で届くようになり、応答ごとに約250ミリ秒を短縮できます。

また、クライアントの認証方法と接続先のリージョンホスト名も確認する必要があります。これまで、SonioxのWebSocket接続（wss://stt-rt.soniox.com/transcribe-websocket）では、ソケットを開いた後の最初のJSON設定フレーム内でapi_keyを受け付けていました。2027年1月15日以降、この最初のJSONメッセージ内でのみAPIキーを渡す接続は401 unauthenticatedで拒否されます。WebSocketを開く際には、HTTPハンドシェイクヘッダーでAuthorization: Bearer <YOUR_API_KEY>を渡す必要があります。認証をハンドシェイクヘッダーに移行することで、LiteLLMのような統合APIゲートウェイ経由でのトラフィックルーティングも容易になります。従来はキーが最初のペイロードフレーム内に埋もれていたため、GPTリアルタイムラッパー経由でマッピングしない限り、生のSoniox WebSocketストリームをプロキシできませんでした。

最後に、有効なはずのAPIキーが突然401エラーを返す場合は、プロジェクトのリージョンを確認してください。Sonioxはキーのスコープをリージョン別のデータセンターに限定しているため、アプリにデフォルトの米国ホスト（stt-rt.soniox.comまたはapi.soniox.com）がハードコードされていると、EUプロジェクトのキーは常に401を返します。エンドポイントはプロジェクトのリージョンに合わせる必要があり、欧州連合はstt-rt.eu.soniox.comおよびapi.eu.soniox.com、日本はstt-rt.jp.soniox.com、インドはstt-rt.in.soniox.comを使用します。また、欧州のクライアントを.euホストへ直接ルーティングすることで、WebSocket接続の確立時間が約0.55秒から0.30秒に短縮されます。

Soniox STT v6とWhisper、Parakeet、Nemotron 3.5 Transcribeの比較

Soniox STT v6と他の現行モデルのどれを選ぶかは、クラウドベースの多言語コードスイッチング、ローカルオフライン環境でのプライバシー、あるいは複数話者の激しい発話重複への対応のどれを必要としているかによって決まります。

複数言語にわたる音声ディクテーションをテストしてみると、純粋な英語のバッチファイルに対しては（Groqの高速なHTTP API上で実行する場合でも、MacWhisper内でローカル実行する場合でも）依然としてWhisperが高い水準を示しており、macOSでのオフライン利用にはApple Speechが便利です。しかし、一息のなかに中国語、英語、フランス語を混ぜて話すと、どちらもつまずいてしまい、英語のコード用語を当て字に音訳してしまうか、文の残りの部分で誤った言語に固定されてしまいます。英語のみでディクテーションを行い、分単位のAPI料金を支払わずにローカルで即座の応答を得たい場合は、160MBのParakeetストリーミングモデルをHex 3.0のローカル音声ディクテーション内で実行すれば、手元のマシン上で100msのGPUストリーミングが得られます。そして、複数話者が入り乱れる医療や法務の録音データを自前のハードウェア上で話者ラベル付きで文字起こしすることが最優先であれば、NVIDIA Nemotron 3.5 Transcribeなら40言語と重複する音声をローカルで処理できます（ただし30B-A4BのMoEモデルをホストできるVRAMが必要です）。

Soniox STT v6が優位に立つのは、話者が次に60以上の言語のどれを使うか予測できない場合や、ユーザーにAirPodsの装着を強いることなく自身のスピーカーフォン出力を打ち消す必要がある音声エージェントを構築する場合です。

もちろん、Soniox STT v6は開発者向けのAPIであり、キャプションウィンドウを備えたデスクトップアプリケーションではありません。WebSocketのコードを書いたりリージョン別のAPIキーを管理したりすることなく、多言語のZoom通話や大学の講義、ライブ配信の最中にライブキャプションや二言語翻訳を読みたいだけなら、私はVocenaを使用しています。追加の参加者として通話に割り込むクラウド会議ボットや単一言語のディクテーションユーティリティとは異なり、Vocenaはコンピュータ上で直接動作し、システム音声とマイクの両方を同時にキャプチャして、リアルタイムのキャプションと翻訳を画面上に表示します。OtterのMacデスクトップアプリと同様のボット不要なデスクトップカテゴリに位置づけられますが、多言語のライブ翻訳と二言語同時表示を軸に設計されています。Vocenaは、複数言語が混在する音声を日常的に扱うリモートワーカー、学生、国際チームに最適です。基本的なライブキャプション表示と毎日の短いセッションをカバーする無料プランが用意されており、無制限の連続リアルタイム翻訳、長時間の会議録音、および文字起こし全文のエクスポートには有料サブスクリプションが必要です。