Gemini 2.0 Pro × Live API でリアルタイム多モーダル開発2026

この記事でわかること

  • Gemini 2.0 Pro と Live API を組み合わせたリアルタイム多モーダル開発の基本構成
  • 音声・映像・画面共有を同時に流す双方向ストリームの実装ポイント
  • 中級者がレイテンシ・コスト・運用安定性を両立させる現実的なチューニング指針

結論

2026年Q2時点で Gemini 2.0 Pro と Live API は、双方向の音声・映像入力に対してテキスト/音声で応答する「リアルタイム多モーダルエージェント」を一気に実装可能なプリミティブとして揃っています。中級開発者がやるべきは「Live API は WebSocket で常時接続」「Pro は推論精度の必要な単発タスクに切り出す」というハイブリッド構成で、レイテンシ要件とコストのバランスを取ること。すべてを Live API に寄せると料金が跳ね、すべてを Pro に寄せるとレイテンシが破綻します。

本題

Gemini 2.0 Pro と Live API の関係整理

混乱しやすいので執筆時点の整理から。

  • Gemini 2.0 Pro: 単発の高精度推論向け。入出力ともにテキスト・画像・音声・動画を扱える多モーダルモデル
  • Live API: 双方向ストリーム特化のランタイム。音声/映像を流し込んで音声/テキストで応答を受ける WebSocket ベースの API
  • Flash 系: レイテンシ重視の軽量モデル。Live API のバックエンドとしても選択可能

中級者がまず押さえるのは「Live API は単一モデルではなく、ストリーミング向けに最適化されたインターフェースである」こと。バックエンドモデルは指定パラメータで切り替える設計です。

双方向ストリームの最小構成

TypeScript のスニペットレベルでの最小例（執筆時点の Google AI SDK ベース）。

import { GoogleGenAI, Modality } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY! });

const session = await ai.live.connect({
  model: "gemini-2.0-flash-exp",
  config: {
    responseModalities: [Modality.AUDIO],
    systemInstruction: "あなたは日本語で簡潔に応答するアシスタントです。",
  },
  callbacks: {
    onmessage: (msg) => {
      // msg.serverContent.modelTurn に音声チャンクが流れてくる
    },
  },
});

// マイクから取得した PCM をそのまま送る
session.sendRealtimeInput({ audio: { data: pcmBase64, mimeType: "audio/pcm;rate=16000" } });

ポイントは responseModalities を AUDIO にしていること。テキスト応答も欲しければ [TEXT, AUDIO] を指定します。中級者が陥りがちなのは「テキストだけで動作確認して音声を後付けにする」パターンで、後から音声を足すとフォーマット周りでハマるので最初から音声前提で組むのが安全です。

音声・映像・画面共有を同時に流す

Live API は1セッションに対して複数の入力ストリームを混在できます。代表的なパターンは次の3つ。

  1. 音声のみ: 通話アシスタント / 音声対話 UI
  2. 音声＋カメラ映像: ビジョン付き対話、現実物体について話す
  3. 音声＋画面共有: 画面の内容に対する質問、教育系/サポート系

中級者向けの実装ポイント:

  • 映像はフルフレーム送る必要なし。1〜2 fps に間引いて帯域とコストを抑える
  • 画面共有は解像度を 1280x720 程度まで落とすとコスト/精度のバランスが良い
  • 音声は 16kHz PCM が標準、48kHz は不要

これだけで月額コストが体感1/3〜1/2になることがあります。

Pro と Flash の使い分け

レイテンシと精度のトレードオフを両立させるベタなパターン:

  • 常時の対話レイヤ: Live API + Flash 系で低レイテンシ応答
  • 重い解析（要約・複雑推論）: 別スレッドで Gemini 2.0 Pro を非同期呼び出し
  • 検索/RAG: ツール呼び出しで Pro を1回だけ叩いて結果を Live セッションに差し込む

「ユーザーが話しているうちは Flash で相づち、長い質問が終わったら Pro に投げ直す」のような階層化が中級者の現実解です。

観測性とエラー処理

本番運用で詰まる箇所:

  • WebSocket の再接続: ネットワーク瞬断で切れるので、セッションIDの再開ロジックが必須
  • 音声欠損: クライアント送信が途切れると応答品質が落ちるため、無音区間の埋め込みを実装
  • 料金制御: Live セッション時間で課金されるため、無人検知でセッションを閉じる仕組みを必ず入れる

中級者が見落としがちなのは料金制御で、ユーザーが画面を閉じてもセッションが残り続けると延々と課金されます。アクティビティタイムアウト（例: 60秒無音で自動切断）を必ず仕込んでください。

よくある質問（FAQ）

Q1: Live API はどのくらいのレイテンシで応答しますか？

A1: 執筆時点の体感では、Flash 系バックエンドで音声入力から音声応答開始まで500ms〜1秒前後です。ネットワーク条件と地理的なリージョンに大きく依存するため、本番投入前に対象ユーザー地域からの実測を必ず行ってください。

Q2: Gemini 2.0 Pro と GPT-4o Realtime はどう違いますか？

A2: 双方向音声対話という機能としては似ていますが、Gemini 2.0 Pro は映像・画面共有との同時入力に強く、Google エコシステム（Google Drive / Workspace）との接続性に優位があります。一方 GPT-4o Realtime はツール呼び出しの安定度や英語圏での生態系の厚みで強みがあります。用途で選ぶのが現実的です。

Q3: ローカル開発時にコストを抑える方法はありますか？

A3: 開発初期は Flash 系のみで動作確認し、Pro は本番向けプロファイルに分離するのが定石です。加えて Live セッションは数分単位で自動切断するスクリプトを開発時に挟んでおくと、無駄な課金を抑えられます。

まとめ

Gemini 2.0 Pro と Live API は、リアルタイム多モーダルエージェントを比較的少ないコードで構築できる強力な組み合わせです。中級開発者は「常時接続は Flash + Live API」「重い解析は Pro 単発」のハイブリッド構成と、映像のフレームレート/解像度の調整、料金制御のためのセッションタイムアウトの3点を押さえることで、実用品質と運用コストを両立できます。執筆時点では SDK・モデル名のリビジョンが頻繁に更新される領域なので、四半期に1回は公式リファレンスを見直す運用にしておくのが安全です。