リアルタイム翻訳APIを選ぶとき、翻訳精度だけでは実運用の良し悪しは決まらない。
会議なら発話から訳が返るまでの待ち時間、動画なら音声だけでなく画面情報を使えるか、接客なら同時接続数やレート制限が問題になる。
さらに音声入力と音声出力で課金単価が異なるサービスでは、同じ10分の利用でも構成によって費用が変わる。
Alibaba Cloudが提供するQwen3.8-LiveTranslate-Flash-Realtimeは、音声と画像を入力し、翻訳テキストまたは音声をリアルタイムで返すモデルだ。
60言語を理解し、29言語で音声出力に対応する。日本語も公式の対応言語に含まれている。
導入前に押さえたいのは、これはダウンロードしてGPUで動かすローカルモデルではなく、Model StudioからWebSocket APIで利用するサービスだという点だ。
必要スペックより、リージョン、通信、トークン課金、レート制限、データ取り扱いの確認が重要になる。
Qwen3.8-LiveTranslate-Flash-Realtimeは、多言語のリアルタイム音声・映像翻訳を目的としたモデルである。
入力はAudioとImage、出力はTextとAudio。
一般的なチャットモデルのようなFunction Calling、Web Search、Batch Inference、Fine-tuningには対応しないと公式モデル情報に明記されている。
コンテキストウィンドウは53,248トークン、最大入力49,152、最大出力4,096。
会話の直前だけを見るのではなく、長い文脈を使って固有名詞や専門用語を解釈しやすくする設計も特徴だ。
Qwen3.8世代ではリアルタイム話者分離、原文と訳文の同期表示、長文脈を使った曖昧性解消が打ち出された。
複数人会議で「誰が何を言ったか」を保ったまま翻訳したい用途では、単純な音声認識→翻訳→読み上げの直列処理とは異なる価値がある。
公式ドキュメントでは、中国語、英語、フランス語、ドイツ語、ロシア語、日本語、韓国語、スペイン語、ポルトガル語、アラビア語などを含む60言語の翻訳に対応する。
ここで注意したいのが、60言語すべてで音声出力できるわけではない点だ。
29言語は音声とテキストの両方を出力でき、残る31言語はテキスト出力が中心となる。
したがって「日本語を理解できるか」「日本語へ文字で訳せるか」「日本語音声として読み上げられるか」を分けて確認する必要がある。
日本語は音声出力対象として公式リストに含まれている。
映像翻訳では画像入力も利用できる。
口の動き、ジェスチャー、画面内テキストなどを補助情報として扱う設計で、騒音や曖昧な単語がある場面で翻訳精度を補う狙いがある。
国際向けSingaporeリージョンの公式モデル情報では、音声入力が100万トークン7.5ドル、画像入力0.55ドル、テキスト出力20ドル、音声出力30ドル。
これは原価として掲載されている価格で、期間限定プロモーションは含まない。
音声入力と音声出力の両方を使う双方向通訳は、字幕だけを返す構成より費用が増える。
逆に動画翻訳でも、訳文字幕だけが必要なら音声出力を使わない構成にできる。
モデル名だけで「1分いくら」と決めるのではなく、どのモダリティを入出力するかを先に決めるべきだ。
ここで固定の「1時間○ドル」を置くのは適切ではない。
Alibaba Cloudの料金はトークン単位で、実際のトークン量は発話密度、無音区間、画像入力の頻度、出力形式などで変わるからだ。
見積もりは、音声入力トークン×7.5ドル/100万、画像入力×0.55ドル/100万、テキスト出力×20ドル/100万、音声出力×30ドル/100万を足す。
会議なら「音声→字幕のみ」と「音声→翻訳音声」の2パターンを分けて試算すると予算を立てやすい。
動画では画像入力をどの頻度で送るかも効いてくる。
すべてのフレームを同じ扱いで送る設計ではなく、視覚情報が翻訳に必要な場面だけを使う構成を検討した方が、コストと帯域を抑えやすい。
リアルタイム版はWebSocket Realtime APIを使う。
モデルIDは qwen3.8-livetranslate-flash-realtime。
session.output_modalitiesで出力形式を設定
翻訳テキストはresponse.text.delta
音声側の転記はresponse.audio_transcript.delta
などのイベントとしてストリーミングされる。
実装では「接続したら音声を送り続ければ終わり」ではない。
認証、セッション設定、音声チャンク送信、イベント受信、切断時の再接続、タイムアウト、UI側の字幕更新を分けて設計する必要がある。
また、旧世代のqwen3.5-livetranslate-flash-realtimeとはパラメータやイベントが異なると公式ドキュメントが注意している。
既存コードでモデルIDだけを置き換えるのではなく、3.8向けイベント仕様を確認した方がよい。
Alibaba CloudはQwen3.8-LiveTranslateについて、平均遅延指標LAALを2.8秒から2.3秒へ短縮したと説明している。
別の公式ドキュメントでも「as low as 2.3 seconds」と表現されているため、2.3秒をすべての通信で保証される固定値として扱うべきではない。
利用者が体感する遅延には、モデル処理だけでなく端末からリージョンまでのネットワーク、音声チャンク、発話区切り、出力音声生成、クライアント側再生バッファが加わる。
日本からSingaporeリージョンへ接続する場合も、実環境で測る必要がある。
会議では速度だけでなく話者分離も重要だ。
Qwen3.8ではリアルタイムspeaker diarizationが追加され、発話者の帰属を維持する設計が強化されている。
字幕UIでは原文と訳文を同時表示できるため、訳を確認しながら会話を追う用途にも向く。
国際リージョンの公式モデル情報では、RPMは10、TPMは100,000。
PoCで1接続を試すだけなら目立たなくても、多数の会議室や接客端末から同時利用する場合は設計上の制約になる。
本番導入では、1セッション当たりの送信量、同時接続数、再接続時のリクエスト増加を測り、上限に近づく条件を先に把握したい。
イベント会場やコールセンターのように利用が同じ時間帯へ集中するサービスでは特に重要だ。
リージョン選択は料金だけで決めない。
国際利用ならSingaporeの提供条件、データの送信先、企業のデータ保持要件、ネットワーク遅延をまとめて確認する必要がある。
比較で最初に分けたいのは製品の役割だ。
Qwen3.8-LiveTranslateは翻訳に特化したRealtime APIで、Function CallingやWeb Searchを持たない。
一方、Gemini Live系はリアルタイム会話やツール利用を含む汎用的なライブAIとして使われるケースがある。
そのため、対応言語数やトークン単価だけを横並びにすると判断を誤りやすい。
リアルタイム通訳専用なら、話者分離、二言語表示、映像による翻訳補助を重視できる。
会話の途中で検索や業務ツールを呼びたいなら、汎用Live API側の機能構成も確認すべきだ。
Gemini側はモデルやプレビュー/正式版によって料金・音声機能が変わるため、公開時点のGoogle公式価格表とLive APIドキュメントで再確認する。
比較表へ固定値を載せる場合は、同じ日付・同じ入出力条件で揃える必要がある。
社内会議なら、日本語と外国語の音声出力、話者分離、字幕表示、会議データの扱いが中心になる。
まず少人数の会議で固有名詞と専門用語の再現率、発話被り、遅延を測るとよい。
動画翻訳では、視覚情報を使う価値が高い。
画面内の文字や口の動きが翻訳に寄与する場面がある一方、音声だけで十分なら画像入力を減らして構成を簡素化できる。
接客用途では同時接続と障害時の挙動が重要になる。
RPM/TPM、再接続、無音処理、聞き返し、個人情報の送信ルールまで含めてPoCを行い、翻訳精度だけで本番可否を決めない方がよい。
Qwen3.8-LiveTranslate-Flash-Realtimeは、日本語を含む多言語のリアルタイム翻訳をWebSocket APIへ組み込みたい開発者にとって、仕様を比較しやすいモデルだ。
60言語理解、29言語の音声出力、話者分離、映像入力、長文脈といった機能が1つの翻訳APIにまとまっている。
ただし、導入判断では「2.3秒」「60言語」といった数字だけでなく、必要な出力形式ごとのトークン料金、RPM/TPM、ネットワーク遅延、データの扱いを見る必要がある。
まず実際の会議や動画を使ってトークン量と体感遅延を測り、そのデータから月額費用と運用可能な同時利用数を算出するのが確実だ。
.png){kind=logo}
