声を、声のまま
70言語へ届ける。
これまでリアルタイム音声翻訳は、認識・翻訳・合成の3段を自前で組む大仕事でした。Gemini Live API は、その全部をエンドポイント1つに畳み込む——話者のトーンを保ったまま、声から声へ。仕組みと使いどころを図解で解きほぐします。
3段パイプラインという
「重さ」
半年前まで、リアルタイム音声翻訳を自社アプリに組み込もうとすると、音声認識 → テキスト翻訳 → 音声合成という3段のパイプラインを自前で組む必要がありました。それぞれ別のサービスやモデルをつなぎ、入出力のフォーマットを合わせ、エラー時の挙動まで面倒を見る——構築だけでもかなりの労力です。
さらに厄介だったのが遅延です。各段の処理に1〜3秒かかり、積み重なると会話のテンポに追いつかない。相手が話し終えてから訳が返るまでの「間」が、対話の自然さを削いでいました。加えて、いったんテキストに落とす設計では、話者の声色や感情がそこで失われてしまいます。
| 3段パイプライン（従来） | Gemini Live API |
|---|---|
| 認識・翻訳・合成を別々に接続 | エンドポイント1つで完結 |
| 各段 1〜3 秒の遅延が積算 | ストリーミングで連続生成 |
| テキスト経由で声色が消える | トーン・速度・ピッチを保持 |
| 対応言語は組み合わせ次第 | 70 以上の言語に対応 |
テキストに落とさず、
声を声のまま渡しきる。
声から声へ、直接
テキストを経由する“中継地点”をなくし、入力音声のストリームから訳した音声のストリームを直接立ち上げます。
声をそのまま受ける
マイクから入ってくる音声ストリームを、テキストに書き起こす前にモデルへ流し込みます。話している途中から処理が始まるので、話し終えるまで待つ必要がありません。
声のまま訳す
1つのモデルが内部で意味をとらえ、訳した内容を音声として連続的に出力します。途中でテキストへ落とさないため、話者のトーン・スピード・ピッチを保ったまま別言語の声が立ち上がります。
1つのAPIで呼ぶ
開発者が触るのはエンドポイント1つ。3つのサービスを継ぎ合わせる配線も、各段の遅延管理も不要になり、組み込みの実装コストが大きく下がります。
開発者に、そのまま
開かれた
Google が「Gemini 3.5 Live Translate」を Gemini Live API として開発者公開。フロンティアモデル群に「同時翻訳」という新しいユースケースが加わりました。
公開と同時に、Google Meet と Google Translate にも組み込みでリリースされました。つまり Google 自身が自社プロダクトで実地に使っている技術が、そのまま API として開発者の手元に降りてきた、ということです。
従来は「リアルタイム音声翻訳」を実現すること自体が研究プロジェクト級の難度でした。それが、設計の重心を1本のエンドポイントに移すだけで届く。音声 × 多言語を扱うプロダクトの参入障壁が、はっきりと下がった瞬間です。
誰に、どう効くか
音声と多言語が同時に必要なプロダクトに、これまでなかった「直接使える部品」が手に入ります。
国際会議 SaaS
参加者が母語で話し、相手の母語で聞ける。テキスト字幕に頼らず、声のテンポを保った同時通訳をアプリ内で完結できます。
語学学習アプリ
お手本の発話を任意の言語へ即時変換し、ピッチや速度のニュアンスごと学習者に届けられます。発音やトーンの教材化にも向きます。
サポート自動化
多言語のカスタマーサポートを、オペレーターの声色を保ったまま展開。問い合わせ対応の言語カバレッジを広げやすくなります。
導入前に、ここを
確かめる
魅力的な選択肢である一方、過信は禁物です。最大の論点は品質の見極め。「話者の声を保ったまま訳す」というクオリティは、言語ペアや音声環境、専門用語の多さで変わり得ます。カタログ値ではなく、自分のユースケースで実際に試すまでは未知数だと考えるべきです。
既存の3段パイプラインを置き換えられれば、レイテンシと実装コストの両方を改善できるはずです。だからこそ、本番導入の前に自分の言語ペア・想定シーンでの精度検証を一度はさむ。そこをくぐり抜けたとき、これは確かな一手になります。