Gemini API、音声生成のストリーミング対応を追加

Google Gemini の 2026年6月17日の Gemini API 変更履歴 では、音声生成でストリーミング応答が使えるようになったことが案内されました。対象は gemini-3.1-flash-tts-プレビュー で、通常の Gemini API では streamGenerateContent、Interactions API では ストリーム: true を使う形です。

要点

• Gemini API の TTS で、生成された音声を一括完了後ではなく途中のチャンクとして受け取れるようになりました
• 対象モデルは gemini-3.1-flash-tts-プレビュー で、Google の TTS ガイドでは Gemini 3.1 以降の TTS モデルがストリーミング対象と説明されています
• 音声アシスタント、読み上げ、会話 UI では、聞き始めるまでの体感待ち時間を下げられる可能性があります
• 実装側では、音声チャンクの再生、接続断、キャンセル、再試行、ログの扱いを同期生成とは分けて確認したいところです

今回の更新で変わること

今回の更新は、Gemini API の音声生成を「生成が完了した音声ファイルを受け取る処理」だけでなく、「生成されている音声を順次受け取り、再生や保存に回す処理」として扱えるようにするものです。公式 変更履歴 は短いですが、変更点は明確です。gemini-3.1-flash-tts-プレビュー に対して、通常の Gemini API では streamGenerateContent、Interactions API では ストリーム: true によるストリーミングがサポートされました。

TTS ガイドでは、Gemini API の TTS は、Live API のような即興的な音声対話とは別の位置づけとして説明されています。Live API はインタラクティブな会話やマルチモーダル入出力に向く一方、Gemini API の TTS は、渡したテキストを音声として読み上げ、声の種類、話し方、アクセント、ペース、トーンを制御する用途に寄っています。今回ストリーミング対象になったのは、この TTS 側です。つまり、リアルタイム会話 API そのものの新機能というより、テキストから音声を作る既存の TTS ワークフローを、待ち時間の短い形で扱いやすくする更新と見るのが自然です。

これまで同期的な generateContent で音声を生成していた実装では、レスポンス全体を受け取ってからファイル化したり再生したりする設計になりがちです。ストリーミングを使う場合は、返ってきた音声チャンクを順に処理できます。公式サンプルでも、Python では generate_content_stream、JavaScript では generateContentStream を使い、返ってくるチャンクから音声データを取り出して処理する流れが示されています。REST でも streamGenerateContent エンドポイントを使う形です。

読者にとって重要なのは、これが単なる API 名の追加ではなく、音声体験の設計に影響する点です。長めの読み上げ、学習コンテンツ、社内向け音声ガイド、問い合わせ応答の読み上げなどでは、ユーザーが最初の音声を聞くまでの待ち時間が体験を左右します。一方で、ストリーミングでは途中まで再生された音声をどう止めるか、接続が切れたときにどこから再生成するか、失敗時にユーザーへどう見せるかも設計対象になります。

また、Google の TTS ガイドは、この TTS 機能がプレビューであること、TTS モデルはテキスト入力を受け取り音声を出力すること、単一話者と複数話者の音声生成に対応することも示しています。したがって、すぐに本番の音声基盤へ置き換えるというより、まずは既存の同期生成フローと並べて、遅延、音声品質、チャンク処理、費用、監視のしやすさを検証する更新です。

実務で確認したいポイント

• gemini-3.1-flash-tts-プレビュー を使う前提で、現在の TTS 実装が同期生成かストリーミング生成かを切り替えられるかを確認したいです
• 返ってくる音声チャンクを、ブラウザ、モバイルアプリ、サーバー側処理のどこで再生・保存・破棄するかを決めておきたいです
• 途中停止、ユーザーによるキャンセル、接続断、再試行時に、二重再生や途中からの不自然な再開が起きないかを見ておきたいです
• ログや監視では、生成開始、最初の音声チャンク到着、完了、失敗を分けて見られるかが確認点です
• プレビュー機能として、利用制限、料金、品質評価、本番投入の判断基準を別途確認できているかが重要です

今回の更新が関係する人

Gemini API で読み上げ、音声ガイド、ナレーション、学習コンテンツ、問い合わせ応答の音声化を作っている開発チームに関係します。特に、長い音声を作る用途や、ユーザーが待ち時間に敏感な画面では、ストリーミング対応によって体感速度を改善できるかを検証する価値があります。

プロダクト担当やデザイナーにとっては、音声が「いつ鳴り始めるか」「途中で止められるか」「ユーザーが次の操作をしたときに古い音声が残らないか」が確認点になります。運用担当や SRE にとっては、ストリーム途中の失敗、タイムアウト、再試行、コストの見え方が確認点です。

結局、今回の更新をどう読むべきか

今回の更新は、Gemini API の TTS を、完了後にまとめて音声を受け取る用途から、生成途中の音声を使う用途へ広げる変更です。音声アプリを作るチームにとっては便利な一歩ですが、ストリーミングは体感速度を改善する一方で、途中停止や失敗時の扱いも表に出します。まずは既存の同期生成と比較し、どの画面やワークフローならストリーミング化の効果が大きいかを小さく試すのがよさそうです。