Gemini Live APIを本番で使うときの構成を考えた｜AI Studio PreviewとVertex AIで悩んだ話

僕はSpeech Linkというプロダクトの開発に携わっているのだが、このプロダクトでは音声会話の機能がある。この機能には生成AIを使っているのだが、ここにGoogle GeminiのLive APIを使うかどうかをずっと悩んでいた。レイテンシも体験価値も魅力的なんだけど、本番サービスに載せようとすると思いのほかいろんな制約が絡んでくるからだ。

レイテンシ・SLA・利用規約・モデル寿命の4つが絡み合う構図で、最終的にどう判断したかを記す。とはいえ、動きの早い世界なのであくまでも現時点の、だ。

なお、ちょうどこの記事の下書きを書いて公開するまでの間にUSでGoogle Cloudの年次カンファレンスであるGoogle Cloud Next 2026が開催されていて、そこでもいくつか関連するアップデートがあった。例えば、Vertex AIの生成AI・エージェント関連機能がGemini Enterprise Agent Platformに統合・再編されるなど。とはいえ、Live API自体の実装方針に直接影響する変更ではないので、本文では分かりやすさを優先してVertex AI表記のまま書いていく。Google Cloud側のドキュメントでは今後 Gemini Enterprise Agent Platform 表記へ移行していく可能性が高いのでそのときは読み替えてほしい。

刷新前の構成と動機

刷新前の会話練習機能は、こんな感じ。いわゆるText to speech（TTS）とSpeech to text（STT）を使ったパイプライン型の処理。

マイク → Web Speech APIでSTT → テキストとして送信 → LLM応答生成 → TTSで読み上げ

機能としては成立してるんだけど、体験面で正直イマイチ。

応答までのラグが大きい（STT・LLM・TTSを直列で走らせるので、ユーザーが話し終えてから音声が返るまで数秒かかる）
割り込めない（AIが喋ってる途中にこっちが話しかけても、処理が完了しないと次に進まない）
相槌や沈黙の間が不自然

一応、この機能を実装するにあたり国内外のTTSならびにSTTのサービスを比較評価していて、レイテンシと精度・価格のバランスでGeminiを使うことにはなっていた。もっと速度的に速ければいいんだけどなかなか限界あったのが実態。

で、これを解決するにはOpenAIであればRealtime APIだし、GoogleであればGeminiのLive APIなのだ。WebSocketで双方向に音声ストリームを流せて、モデルが発話中でもユーザーの割り込みを検知できる。試したら確かに体験は劇的に良くなる。

最初の実装: ブラウザ直結 + Ephemeral Token

最初に採用したのは、公式が「ブラウザ直結の推奨パターン」として紹介しているEphemeral Token方式。Ephemeral TokenというのはWebSockets を介してGemini APIにアクセスするための有効期間の短い認証トークンのこと。現状ではLive APIとのみ互換性がある。

[Browser]
   │  1. POST /api/conversation/live-token (NextAuthセッション認証)
   ▼
[Next.js Route Handler]
   │  Gemini APIキーで短命トークンを発行
   ▼
[Browser]
   │  2. WebSocket (ブラウザ ⇄ Gemini Live API直結)
   │     - AudioWorkletでマイク音声を16kHz PCM化
   │     - 受信した24kHz PCMを別のAudioWorkletで再生
   ▼
[Gemini Live API (AI Studio / Developer API)]

Ephemeral Tokenはデフォルトでは新規セッション開始期限は1分、接続上でメッセージを送れる期限は30分。uses: 1 でも session resumption を使う再接続では同じトークンを利用できる。

採用理由は単純で、構成としては一番シンプルなのとレイテンシ的にもいいから。音声会話の体験はミリ秒単位の遅延で印象が変わるのも事実だが、それ以上にGoogleの生成AIのモデル提供の住み分けがよくわかってなかったってのも正直ある。

調べているうちに見えてきた制約

Live APIに限らず、TTSやSTTのモデルについても開発と並行して本番運用を見据えた調査を進めていくと、Previewモデル前提のアーキテクチャには複数のリスクがあることが分かってきた。どうしても性能がPreviewモデルのほうが良かったりするのでそれを選びがちだったのはある。一方でPreviewモデル特有の制約もあった。TTSとかだとシンプルに遅いってのもある。

1. Vertex AIのGAモデルではEphemeral Tokenが使えない

現時点で、Vertex AI / Gemini Enterprise Agent Platform 側で Live API の GA として明示されているモデルは gemini-live-2.5-flash-native-audioのみ。ただ、少なくとも公式SDKやissue上は、Vertex AIでEphemeral Tokenを発行する手段がない（googleapis/js-genai#766）。

つまり現状では、Vertex AIのGA LiveモデルをブラウザからEphemeral Tokenで直接接続する構成は取れない。ブラウザ直結を維持する限り、AI StudioのPreviewモデルしか選べないことになる。というわけでそうしたんだがいくつか制約がある。

プラットフォーム	モデル	ステータス	Ephemeral Token
Vertex AI / Gemini Enterprise Agent Platform	`gemini-live-2.5-flash-native-audio`	GA / 2026-12-13 廃止予定	未対応
Gemini Developer API / AI Studio	`gemini-3.1-flash-live-preview`	Preview	対応
Gemini Developer API / AI Studio	`gemini-2.5-flash-native-audio-preview-12-2025`	Preview（shutdown date 未公表）	対応

※モデル名やステータスはわりと頻繁に変わるので、最新情報は公式ドキュメントで確認してほしい。

2. AI Studio側のPreviewはTerms上、本番利用が明確にNG

さらに言うなら、Gemini API Preview Termsには次の記述がある。

Services identified as "Preview" may not be used in production.

つまりAI Studio / Gemini Developer API側のPreviewサービスは、Preview Terms上、本番では利用すべきではないと明記されている。社内ツールや実験的プロダクトなら許容範囲かもしれないけど、というわけでエンドユーザー向けに継続提供する本番サービスでは避けるべき、と判断しました。

なお、Google Cloud / Vertex AI側のPre-GA Offerings Termsはまた契約体系が違うはずなので、AI Studio側とVertex側のPreviewを同じ枠で語らない方がよさそう。ややこしいのはVertex AIにもPublic Previewのモデルが存在することだ。このあたりマジで複雑で難しい。未だに理解しきれない。

3. PreviewにはSLAがない

Preview / Pre-GA は原則 SLA 対象外。GA については Google Cloud 側の Online Inference SLA の対象になり得るが、対象メソッド・除外条件などは個別に確認したほうが良さそう。少なくともPreviewは障害やレイテンシ劣化が起きても補償対象外なので、自社サービスのユーザーに稼働率を保証しているのならば重要なポイントになる。

4. レート制限が制限的

Gemini APIのレート制限は累計課金額によるTier制（Free / Tier 1〜3）で自動昇格するのが基本だが、Previewモデルはこの昇格の恩恵を受けにくいケースも報告されている。実際に自分もそれっぽい挙動を体験している。

Live APIは1セッションで数十秒〜数分の双方向ストリーミングが継続するのでわりと重量級のAPIと言える。なので同時接続が少なくても、モデル・Tier・セッション時間・音声量・実際のquota設定次第では結構すぐに制限される可能性がある。少なくとも通常のテキスト生成と同じ感覚で見積もらない方がよさそうだし、自分がテストでやってたときも引っかかったことがある。

5. モデル寿命が短い

Previewモデルは数か月〜1年程度で後継や廃止予定が出ることが多いので、GAモデルよりも移行頻度を高めに見積もっておく必要がありそう。実例として、検討期間中だけでもこんなモデル遷移が起きた。

gemini-2.5-flash-native-audio-preview-12-2025: shutdown dateは未公表だけど、後継候補として gemini-3.1-flash-live-preview が示されている
gemini-3.1-flash-live-preview: 後発でリリース（現採用）

つまりPreview側は移行作業がそれなりの頻度で走る前提で体制を作る必要がある。プロンプト・パラメータ・音声品質はモデル差で変わってくるので、都度の回帰テストも避けられないだろう。

GAモデルも安泰とは言い切れない。Live APIのGAモデル gemini-live-2.5-flash-native-audio は、公式モデルページ上ではリリース日2025-12-12 / 廃止予定日2026-12-13と掲載されている。GAであっても約1年でのライフサイクルなので、年単位の移行計画は前提に置いておく方が無難そう。

選択肢の比較

ここまでを踏まえて、取りうる選択肢はこうなる。

選択肢	ToS上の本番可	SLA	レイテンシ	実装コスト
AI Studio Preview直結（現状）	✗	なし	◎	既存
Vertex AI GA + WebRTCパートナー（Daily / Twilio / LiveKit / Voximplant）	◯	あり	◯	中
Vertex AI GA + 自社WebSocketプロキシ	◯	あり	△ (+50〜150ms)	大
Firebase AI Logic経由	△ / 要確認	なし	△	中
Vertex AI直結（Ephemeral対応待ち）	◯	あり	◎	小

WebRTCパートナー経由は、Google Cloud Next 2026の前後で公式ドキュメントにも明記されるようになった選択肢。Daily / Twilio / LiveKit / Voximplant あたりが既にWebRTC越しでGemini Live APIを叩けるようになっていて、自前でWebSocketプロキシを立てなくてもGAモデルが使えるのがメリットではある。代わりにベンダーロックインや、Gemini以外に課金が発生するのでそれを許容できるかがある。

Firebase AI LogicはVertex AIへの公式プロキシで魅力的なんだけど、Live API部分は現状Previewで、SLAや非推奨ポリシーの対象外、後方互換性のない変更があり得ると公式に明記されているので、今回の本番要件は満たしにくい。GA化されれば第一候補になるかも？

というわけで現時点で本番要件を満たしやすい現実解は、WebRTCパートナー経由か、自社WebSocketプロキシ方式のどちらかになる。バックエンドをWebSocketプロキシとして立てる場合はざっくりこんな感じか。

[Browser]
   │  WebSocket (JWT / NextAuthセッション認証)
   ▼
[NestJS WebSocket Gateway (ECS Fargate)]
   │  Service AccountでVertex AI認証
   │  1ユーザー = 1 WSの上限制御・監査ログ・課金メトリクス
   ▼
[Vertex AI Live API (gemini-live-2.5-flash-native-audio: GA)]

メリットとしては、ToS / SLAの課題が解消される、APIキー漏洩リスクなし（Service Accountはバックエンドのみ）、レート制限・監査・課金管理をバックエンドで一元化できる、あたり。

トレードオフとしては、プロキシを挟むことでレイテンシ増、ECS Fargate常時稼働分のインフラコスト増、ALBの idle_timeout 調整やオートスケール設計などの手間、といったところ。

今回の判断: 現状維持で進めて、トリガー駆動で移行する

ユーザー数がそこまで多くない現在のフェーズで自社プロキシ方式に即移行するのはさすがに大変。なので、ひとまずはPreview直結を継続しつつ、近い将来にVertex GAに切り替えていくという段階プランにしました。Vertex AIがEphemeral Tokenに対応してくれればすべて解決するのだが。

まとめ

Gemini Live APIは体験価値が高い一方で、本番運用の観点ではいろいろと現実的な制約があった。ブラウザ直結 × GAモデルという理想の組み合わせはVertex AIのEphemeral Token対応待ちで、それまでは「レイテンシ最優先でPreviewを使う」か「バックエンドプロキシを自前で実装してGAを使う」、「パートナーのプロキシサービス経由でGAを使う」かの3択になる。

ひとまずPreviewでしのぎつつ、自前実装するかサービス使うかは実装難度とコスト見合いで考えた上で近い将来どちらかに移行することにした。

Sweet Escape