Gemini 3.1 Flash Live移行で変わる音声AI実装｜2026年7月25日版
Googleは2026年7月21日、リアルタイム音声対話向けモデル「Gemini 3.1 Flash Live Preview」をGemini APIの更新情報に追加しました。
重要なのは、旧モデルからの移行がモデル名の置き換えだけでは終わらない点です。受信イベントの処理、テキスト入力の送信方法、映像を含むターンの扱い、関数呼び出しの設計まで見直す必要があります。
今日押さえておきたい要点は次の4つです。
- 低遅延の音声対話に加え、テキスト・画像・音声・動画を入力できる
- 1回のサーバーイベントに音声と文字起こしなど複数の要素が入る場合がある
send_client_contentは初期履歴の投入に用途が限定される- 関数呼び出しは同期実行のみで、処理完了まで会話が止まる
音声AIの中核が「文字変換」から双方向ストリームへ
Gemini 3.1 Flash Live Previewは、音声を受け取り、音声を直接返す低遅延モデルです。入力にはテキスト、画像、音声、動画を利用でき、出力はテキストと音声に対応します。
従来型の音声アプリでは、音声認識、LLMへの問い合わせ、音声合成を別々に組み合わせる構成が一般的でした。Live APIでは、WebSocket上の継続的なセッションで入力と応答をやり取りします。これにより、電話受付、対話型サポート、音声操作アプリなどを一つの会話セッションとして設計できます。
モデルの主な仕様は次の通りです。
- モデルID：
gemini-3.1-flash-live-preview - 入力：テキスト、画像、音声、動画
- 出力：テキスト、音声
- 入力上限：131,072トークン
- 出力上限：65,536トークン
- 対応機能：Live API、同期式の関数呼び出し、Google検索によるグラウンディング、Thinking
- 非対応：非同期の関数呼び出し、コード実行、ファイル検索、構造化出力、URLコンテキスト
モデル自体はPreviewです。本番採用では、仕様変更を前提にモデルIDやイベント形式を設定から切り替えられる構成が安全です。
移行時にコード修正が必要な4項目
Googleの移行ガイドでは、Gemini 2.5 Flash Liveから3.1へ移る際の具体的な差分が示されています。
1. 受信イベントの全パートを処理する
1つのBidiGenerateContentServerContentイベントに、音声チャンクと文字起こしなど、複数のパートが同時に含まれる場合があります。
先頭のパートだけを読む実装では、一部の音声やテキストを取りこぼしかねません。受信側ではpartsを最後まで走査し、種類ごとに処理を振り分ける必要があります。
2. 会話中のテキストはリアルタイム入力で送る
send_client_contentは、セッション開始時に過去の会話履歴を与える用途に限定されました。会話開始後にテキストを追加する場合は、send_realtime_inputを使います。
つまり、次の2つをコード上でも分離します。
- 初期履歴：
send_client_content - 会話中の追加入力：
send_realtime_input
旧モデル向けの送信処理をそのまま流用すると、会話途中のテキスト更新が想定通りに反映されない可能性があります。
3. 動画フレームの送信量を見直す
3.1では、ターンの既定値がTURN_INCLUDES_AUDIO_ACTIVITY_AND_ALL_VIDEOになりました。検出された音声活動だけでなく、その間に送信された動画フレームもモデルのターンに含まれます。
カメラ映像を常時送る実装では、不要なフレームまで処理対象となり、料金や通信量が増える可能性があります。映像が必要な場面を絞り、音声活動中だけ送信するなどの制御が重要です。
4. 外部ツールの待ち時間を会話設計に含める
関数呼び出しには対応していますが、3.1では同期式のみです。モデルが関数を要求すると、アプリが処理結果を返すまで応答を再開しません。
在庫照会や予約登録のような処理に時間がかかる場合、利用者には沈黙として伝わります。ツール側の高速化に加え、「確認しています」といった待機案内をアプリ側で出す設計が必要です。
ここがポイント: Gemini 3.1 Flash Liveへの移行では、モデル名よりもストリームイベントとターン管理の変更が重要です。音が返れば完了ではなく、取りこぼし、待ち時間、映像送信量まで確認する必要があります。
実運用で先に確認したい制約
Live APIは状態を持つWebSocket APIです。接続後の最初のメッセージでモデル、生成設定、システム指示、利用するツールを設定し、そのセッション内で双方向通信を続けます。
セッション時間
公式ガイドでは、通常のセッション時間に次の上限があります。
- 音声のみ：15分
- 音声と動画：2分
長時間の窓口対応や会議用途では、セッション再開やコンテキスト圧縮を含む管理方式が必要です。接続が切れた際に、どこまで会話を復元するかも事前に決めておくべきです。
クライアント認証
ブラウザやスマートフォンからGeminiへ直接接続する構成では、固定APIキーを配布してはいけません。Googleは、短期間だけ有効なエフェメラルトークンの使用を案内しています。
実装では次の流れになります。
- 利用者が自社バックエンドで認証する
- バックエンドが短寿命のトークンを発行する
- クライアントがそのトークンでLive APIへ接続する
- 期限切れや切断時に新しいセッションを開始する
トークンを短寿命にしても、発行元の認証が弱ければ安全にはなりません。発行回数の制限や利用者とのひも付け、監査ログも必要です。
料金は音声の入出力を分けて試算する
有料枠では、音声入力が100万トークン当たり3ドル、または1分当たり0.005ドル、音声出力が100万トークン当たり12ドル、または1分当たり0.018ドルと案内されています。画像・動画入力にも別料金が設定されています。
音声アプリの試算では、会話時間だけでなく次の項目を分けて測ると実態をつかみやすくなります。
- 利用者が話している時間
- AIが音声を返している時間
- カメラ画像や動画フレームの送信量
- Thinkingで発生する出力トークン
- Google検索を利用した回数
無料枠と有料枠では、送信データが製品改善に使われるかどうかの扱いも異なります。業務データや個人情報を扱う場合は、料金だけでなくデータ利用条件を確認してください。
日本の開発者・企業が見るべきポイント
今回の更新は、音声AIを試作から業務利用へ進めるチームに直接影響します。
開発者
モデルIDの更新に加え、複数パートを含む受信イベント、リアルタイム入力、同期式ツール呼び出しをテストする必要があります。特に、旧SDK向けに書いたイベント処理の流用には注意が必要です。
企業利用者
コールセンターや受付で使う場合、応答精度だけでは評価できません。通信切断からの復帰、ツール待機中の案内、会話ログの保存範囲、トークン発行の安全性を運用試験に含めるべきです。
プロダクト担当者
音声と動画を常時送信する設計は、通信量と料金を押し上げます。「いつカメラを使うのか」「どの操作で外部ツールを呼ぶのか」を画面や会話フローに落とし込むことが、コスト管理にもつながります。
継続ウォッチ
今後は次の点を確認していく必要があります。
- Previewから正式版へ移る際のモデルIDと互換性
- 非同期関数呼び出しへの対応時期
- セッション時間と再開機能の変更
- 対応地域、データ所在、企業向け提供条件
- 実環境の回線切り替えや長時間通話における安定性
まず着手すべきなのは、モデル名の差し替えではありません。受信した全パートを処理できるか、外部ツール待機中に会話がどう見えるか、不要な動画を送っていないかを確認する移行テストです。