Qwen3.8-LiveTranslate 登場：AI 通訳を人間のペースに乗せる 0.5 秒

Qwen3.8-LiveTranslateは2026年9月19日にリリースされ、その発表全体はひとつの引き算に集約される。平均ラグ——LAAL、話者の口から出た語が聞き手の耳に翻訳として届くまでの平均的なずれ——は、前世代の2.8秒から2.3秒に短縮される。プロの同時通訳者は、聞き取りから発話までの間隔（ear-to-voice span）がおよそ2～3秒で働く。要はそれだけだ。機械が速くなったからではなく、その遅延が、聞き手が機械をまったく意識しなくなる範囲に収まったからだ。発表時の数値では、前世代のFLEURS翻訳品質は83.0 xCOMET-XXLとされている。今回のモデルは85.7と主張されている。どちらの数値もベンダーによるもので、ベンダー自身の評価環境で算出されており、まだ独立した第三者による再現はされていない——これがこの記事における最も重要な注意点だ。

見出しを超えてこのリリースを読む価値があるのは、その仕組みにある。Qwen は、より高速な認識器やより軽量な合成器によって遅延を削ったのではない。両者の間の継ぎ目を消し去ったのだ。

実際に何が変わったか：継ぎ目が消えた

従来の同時通訳は、10年間同じやり方で組み上げられてきた3段階のパイプラインだ。自動音声認識がストリームを文字起こしし、機械翻訳がその文字起こしを変換し、音声合成が結果を読み上げる。各段階は独自のレイテンシ予算を持つ別個のモデルであり、各引き継ぎで何かが失われる——最初の段階では韻律、3番目の段階では話者アイデンティティ、そしてモジュールが確信を持つのに十分なトークンを待たなければならないあらゆる境界での、固定された数百ミリ秒である。

Qwen3.8-LiveTranslateは、そのカスケードを、ベンダーがインターリーブ・アーキテクチャと呼ぶものに置き換えている。これはハイブリッドMoEバックボーン上に構築され、協調する2つのモジュールに分かれている：

• Thinker — 映像、音声、原文テキスト、翻訳を時間順に交互配置した単一の因果的シーケンスへと編成し、3つのパスではなく1つのパスで理解と翻訳をエンドツーエンドで生成します。

• Talker — 翻訳されたテキストを元の音声とともに受け取り、元の話者の音色を保った音声を合成します。そのため、吹き替え後の声は話した本人だと分かるものになります。

アーキテクチャ上の主張はこうだ。音声認識、翻訳、音声合成がモジュール境界を越えてメッセージをやり取りするのではなく、単一の系列モデリングの枠組みを共有しているため、システムは発話ごとにモジュール間税を二度払わずに済む。これは0.5秒がどこから来たのかについてのもっともらしい説明であり、同時に、主張するのは安上がりで検証するのは高くつく、まさにその種の主張でもある。これはベンダーの説明として扱い、確立された結果として扱ってはならない。

真に新しい3つの機能

言語カバレッジは変わりませんでした。認識されるソース言語は60、音声出力に利用できるのは29——Qwen3.5-LiveTranslateと同じ数です。興味深い追加点はすべて、複数の人が話しているときに何が起きるかに関するものです。

• リアルタイム話者ダイアライゼーション — 各文は発話されると同時に話者に紐付けられ、声の音色の再現はターンの切り替わりを通じてより安定していると説明されている。Qwenは、自社の長いマルチスピーカーテストセットにおいて、話者ダイアライゼーション誤り率が9.7%であると自己報告しており、これはSeed LiveInterpret 2.0の30.6%に対するものである。両方の数値はQwenによるものである。

• 同じフレーム内の原文と翻訳 — モデルは元の文字起こしと翻訳テキストを1つのタイムライン上に出力するため、2回目の位置合わせ処理なしでバイリンガルのオンスクリーンキャプションのペアが可能になります。

• 長文脈の曖昧性解消 — 以前の文脈が引き継がれるため、名前、敬称、専門用語の一貫性が保たれます。これが実際上最も重要な点です。同時通訳の典型的な失敗は、誤った単語ではなく、同じ人物が1つの会議で3通りに訳されてしまうことです。

話者分離こそが、ここで真に差別化につながる要素だ。Googleの競合するリアルタイム音声対音声モデルであるGemini 3.5 Live Translateは、ターンテイキングに問題があることが報告されている——話者が実際に話し終えた時点を把握するのに苦労することがある。Qwenは逆の特性を機能としてうたっている。どちらの企業も、それに決着をつける直接比較を公開していない。

ベンチマークの主張を誠実に読み解く

Qwenは2つのセットでテストされており、これらは測定する内容が異なるため、分けて扱う価値がある。

• FLEURS、70言語方向 — 公開され広く利用されている多言語音声ベンチマーク。Qwenは、翻訳品質、平均ラグ、音声認識精度、音声合成品質において、その前身モデルと、同社が現行の主流リアルタイム通訳システムと呼ぶものの両方を上回ると主張している。85.7対83.0のxCOMET-XXL比較はここにある。

• Omnilingua-MSpeaker、14言語方向 — Qwen自身のマルチスピーカー長尺音声評価セット。同社は、忠実性、流暢さ、簡潔さの向上に加え、話者分離エラー率の低減を主張している。ベンダーが自ら構築したベンチマークは無価値ではないが、証拠でもない。それは、評価対象のモデルを作った人々によって設計されたものだからだ。

正直にまとめると、FLEURSは実在して公開されているので、85.7という数字は少なくとも原理上は検証可能だ。Omnilingua-MSpeakerはそうではないため、話者分離での勝利は、誰かが再実行するまでは主張にとどまる。執筆時点で第三者がQwen3.8-LiveTranslateの数値を公表しておらず、このモデルはまだ登場から数時間しか経っていない。

APIのコスト、そしてあなたを悩ませる一つの数字

Qwen3.8-LiveTranslateは非公開ウェイトでAPI専用です。モデルID qwen3.8-livetranslate-flash-realtimeのWebSocket Realtime API経由で動作し、通常のHTTPエンドポイントではありません。料金は100万トークン単位で、音声トークンは密度が高いため、音声トークンとは何かを思い出すまでは、表向きの料金レートはテキストモデルと並べると驚くほど高く見えます：

• シンガポールリージョン — 音声入力 $7.50、画像入力 $0.55、テキスト出力 $20.00、音声出力 $30.00（100万トークンあたり）

• 北京リージョン — 100万トークンあたり、音声入力 ¥40、画像入力 ¥3.3、テキスト出力 ¥100、音声出力 ¥160。現在の為替レートでは、およそ $5.65 / $0.47 / $14.13 / $22.61 に相当します。

• コンテキスト — 合計53,248トークンで、最大入力49,152と最大出力4,096に分割されます。

• レート制限 — 1分あたり10リクエスト、1分あたり100,000トークンで、両リージョンとも同一です。

そのレート制限こそが、強調すべき数字だ。1分あたり10リクエストは、会議室がいくつかある程度なら十分に寛大だが、コンタクトセンターの導入や、数千の同時ストリームを伴うライブ配信にはまったく足りない。Qwenは、インターフェースの価格を前世代とほぼ横ばいに保っている——北京の料金は変わらず、シンガポールはわずかに安い——しかし、アーキテクチャ上スケールに対応できるモデルが、プレビュー版のようにプロビジョニングされている。本番トラフィックを計画するなら誰でも、10 RPMの上限を、トークン単価ではなく、拘束力のある制約として読むべきだ。

それを呼び出すのは、チャットモデルを呼び出すのとは違う

Realtime APIはイベント駆動型であり、これは補完エンドポイントとは異なるメンタルモデルです。ソケットを開き、受信します：session.created。次に送るのはsession.update イベントで、音声が流れる前にセッションを構成します。

• target_languageは必須であり、最初のオーディオチャンクより前に設定する必要があります。暗黙のデフォルトターゲットは存在しません。

• source_language は省略可能で、デフォルトでは自動検出になります。

• output_modalitiesは、["text"]を文字起こしのみの場合、または["text","audio"]を翻訳音声の場合に選択します。

• input_audio_buffer.appendは base64 エンコードされた PCM チャンクを上り方向に運び、response.text.deltaとresponse.audio.deltaが下り方向に返ってきて、response.doneがターンの終了を示します。

実用的な注意点が2つあります。1つ目は、ブラウザは WebSocket ハンドシェイクで Authorization ヘッダーを設定できないため、接続はサーバー側で確立し、音声を独自のソケット経由でクライアントへ中継する必要があります。これはフロントエンドに直接組み込めるものではありません。2つ目に、Qwen はパラメーターとイベントのセットが前世代の LiveTranslate とは異なると明示的に警告しているため、Qwen3.5-LiveTranslate 向けに書かれたコードは、参照先を差し替えるだけではなく再確認が必要です。エンジニアリング工数を投じる前に遅延を実際に聞いてみたい場合は、omni.qwen.ai/live-translate で無料トライアル用エンドポイントが稼働しています。

意図的に行わないこと

Qwenは一連の機能を利用不可として挙げており、そのリストは明確だ。関数呼び出しなし。構造化出力なし。ウェブ検索なし。プレフィックス継続、コンテキストキャッシュ、バッチ推論なし。ファインチューニングなし。

これは専門特化型であり、通訳者の帽子をかぶった汎用モデルではありません。あなたのエージェントループを回すこともなければ、会議を要約するモデルでもありません。それに合わせて設計してください。通訳者は文字起こしと翻訳音声ストリームを生成し、その下流にあるものすべて — アクションアイテム抽出器、用語集エンフォーサー、CRM書き戻し — は別のテキストモデルの仕事です。

その役割分担こそ、ルーターが真価を発揮する場面です。Qwen3.8-LiveTranslate自体は、ベンダー自身のAPIといくつかのサードパーティプラットフォームを通じて利用可能であり、本日時点でOrcaRouterのカタログにはありません。そうでないふりをするつもりはありません。OrcaRouterが扱っているのは、それを取り巻くスタックです — Alibaba自身のフラッグシップであるQwen3.8-Maxを含みます。これは2.4兆パラメータのスパースなMixture-of-Expertsモデルで、100万トークンのコンテキストを持ち、入力100万トークンあたり$2.00、出力100万トークンあたり$6.00で、プロバイダーの定価で請求され、マークアップは一切上乗せされません。翻訳モデルとその出力を消費するモデルを1つのエンドポイントと1つのキーの背後に置くことで、要約モデルを差し替えるときに文字起こしパイプラインが2つ目の契約を必要とせず、自動フェイルオーバーは単一のプロバイダーが不安定になったときにシステムの下流側を生かし続けます。これは、毎分10リクエストという状況では、発見するのではなく計画しておく価値のあるシナリオです。

次に見るもの

このリリースを、よく論じられた主張から確定した事実へと変えるものが2つある。1つ目は独立したレイテンシ測定だ。LAALは明確に定義された指標であり、試用エンドポイントとストップウォッチの仕掛けさえあれば、誰でもQwenが作成したものではない数値を導き出せる。2つ目はQwen自身が公表したロードマップ——レイテンシの下限へさらに近づくこと、セッションをまたぐ長期記憶、そしてロングテール言語と地域方言のカバレッジだ。彼らに責任を問うべきなのはこのロングテールの項目である。なぜなら、60のソース言語というのは立派な数ではあるが、世界の話者の大半を静かに排除しており、北京語と英語で動くデモと、ヨルバ語やケチュア語で動くデモとの間の隔たりこそが、リアルタイム通訳製品が歴史的につまずいてきた地点だからだ。

今のところ妥当な見方はこうだ。Qwen3.8-LiveTranslateは、看板となる数値を自らの前身モデルではなく人間の通訳者と比較して打ち出した初の同時通訳モデルである——そしてその枠組みは、それが取って代わるものよりもはるかに合格の難しいテストだ。まだ合格してはいない。ただ手を挙げただけである。