Geminiで音声対話AIを開発して分かった、PoCと商用サービスの大きな違い

GeminiのリアルタイムAPIを利用すると、ユーザーが話した内容に対して、AIがそのまま音声で応答するSpeech-to-Speechの機能を、比較的短期間で実装できます。

ブラウザからマイク音声を取得してGeminiへ送信し、返ってきた音声をブラウザで再生する。

実際、PoCとして「AIとリアルタイムに会話できる状態」を作るところまでは、それほど難しくありませんでした。

しかし、実際のユーザーが継続的に利用する商用サービスとして提供しようとすると、PoCでは見えなかった課題が次々に現れました。

• 複数人が同時に利用すると、音声が不安定になる
• 利用量に余裕があるように見えても、レート制限エラーが発生する
• 特定の端末だけ音声が遅れる
• 急に音声の再生速度が極端に遅くなる
• 最新モデルと安定した運用基盤を両立できない
• 障害が発生しても原因を十分に調査できない
• ブラウザや音声機器に依存する問題を再現できない

音声対話AIでは、「会話が成立すること」と「サービスとして安定して提供できること」の間に、大きな差があります。

本記事では、Geminiを使った音声対話AIの開発で直面した課題と、その対策から得られた教訓を紹介します。

特に、PoCを終えて商用開発へ進もうとしている新規事業担当者やPoC担当者にとって、事前に検討しておきたいポイントを整理します。

本記事は現時点での検証結果と開発経験に基づいています。利用できるモデル、API、認証方式などは変更される可能性があるため、導入時には最新の公式情報をご確認ください。

まずはユーザー体験とサービスの価値を検証した

今回開発したのは、ユーザーがAIとリアルタイムに音声対話できる機能です。

フロントエンドにはNext.jsを使用し、Vercel上でホスティングしていました。

PoC段階で重視していたのは、主に次のような点です。

• ユーザーがAIとの音声対話を自然に感じるか
• 音声による案内や支援が、実際の課題解決につながるか
• 周辺機能を含めたサービス全体に価値があるか
• 想定していた業務や利用シーンで使ってもらえるか
• どのような会話設計であればユーザーが迷わないか

つまり、PoCではアーキテクチャそのものよりも、ユーザー体験と事業仮説の検証を優先していました。

最初に採用したのは、ブラウザからGemini APIのLive APIへ直接接続する、比較的シンプルな構成です。

この構成であれば、自社のサーバーで音声データを中継する必要がなく、短期間で音声対話の体験を作れます。

また、Gemini APIでは、新しいLiveモデルやプレビュー段階のモデルを早く利用できる場合があります。

音声対話AIでは、モデルの違いが次のようなユーザー体験に直接影響します。

• 応答速度
• 会話の自然さ
• 音声品質
• ユーザーが話し始めた際の割り込み
• 文脈の維持
• 発話の間やテンポ

PoCの目的から考えると、最新モデルを使ってサービスの可能性を素早く確認できることは、大きなメリットでした。

一方で、商用利用を見据えた通信基盤、監視、同時接続、障害対応までを、PoCの段階で十分に検証できていたわけではありませんでした。

その結果、PoCでは問題なく見えた構成でも、本番利用に近い条件になると、さまざまな問題が顕在化しました。

PoCで「動く」ことと、本番で「使い続けられる」ことは違う

PoCでは、限られた人数と環境で機能を検証します。

社内メンバーが指定された端末やブラウザを使い、短時間のデモを行うのであれば、多少の接続切れや遅延が発生しても、再接続や再実行によって検証を継続できます。

一方、商用サービスでは状況が変わります。

ユーザーが利用する端末、ブラウザ、ネットワーク、マイク、スピーカーは統一できません。利用時間も数分とは限らず、複数人が同じ時間帯に継続して利用することもあります。

問題が発生した際には、単に再接続するだけではなく、原因を調査し、必要に応じて再発防止策を講じなければなりません。

音声対話AIを商用化する際には、少なくとも次の要件を同時に考える必要があります。

PoCで検証していたのが「この体験に価値があるか」だったのに対し、商用化では「さまざまな環境で、安定して価値を届け続けられるか」が問われます。

ここに、PoCと本番開発の大きな違いがありました。

課題1：Gemini APIで同時利用時の挙動が不安定になった

Gemini APIへブラウザから直接接続する構成では、少人数による検証では比較的スムーズに会話できました。

しかし、複数人が同時に利用する条件で試すと、次のような問題が発生しました

確認できる利用量や想定していたレート制限上は、上限に達していないように見える条件でも発生しました。また、利用量に余裕があるように見えるにもかかわらず、レート制限やクォータ超過を示すエラーが返ってくるケースもありました。

実際にGoogle AI Developers Forumでも、複数セッション時の上限の考え方が分かりにくいという報告や、利用状況上は余裕があるように見えるにもかかわらず429エラーが発生したという投稿が確認できます。ただし、フォーラム上の投稿は開発者による報告であり、個々の事象の原因がGoogleから公式に確認されたことを意味するものではありません。

このような事象が難しいのは、次のどこに原因があるのかを判断しにくい点です。

• アプリケーション側の実装
• クライアントのネットワーク
• 同時セッション数
• プロジェクトやAPIキー単位の制限
• リージョンや一時的なサービス負荷
• モデル固有の挙動
• 明示されているクォータとは別の内部的な制御

エラーが返されたとしても、それが本当に設定上のレート制限なのか、一時的なリソース不足なのか、別の問題がレート制限として表現されているのかを、利用側から完全に判断することは困難でした。

課題2：モデルの切り替わりに近い時期に、旧モデルの応答が悪化した

検証中には、新しいモデルが公開される前後で、利用していた旧モデルのレスポンスが不安定に感じられる時期もありました。

私たちの環境では、新しいモデルである3.1系が公開される約1週間前から、それまで利用していた2.5系モデルで、次のような変化を観測しました。また、2.0から2.5の際にも同様な変化を観測しました。

• 応答開始までの時間が長くなる
• 音声が返らないケースが増える
• 音声が途中で途切れる
• セッションごとの品質差が大きくなる
• 複数人で利用した際の不安定さが増す

ただし、新モデルの公開準備と旧モデルの挙動悪化に因果関係があったかどうかは確認できていません。

あくまでも、私たちの検証環境で時期的に重なって観測された事象です。

Google AI Developers Forumでも、Live APIの遅延増加、Native Audioの途切れ、モデル更新前後や更新後に品質が変化したと感じる開発者からの報告があります。これらも個別の利用者による報告であり、同一の原因によるものと断定することはできません。

事業としてサービスを提供する場合、モデルの性能だけでなく、次の点も重要になります。

• 同じモデルを一定期間安定して使えるか
• モデル更新時に挙動がどう変わるか
• 問題発生時に以前のバージョンへ戻せるか
• 新旧モデルを並行して比較できるか
• モデル変更の影響を事前に検証できるか

音声対話AIでは、わずかな遅延や発話テンポの変化でも、ユーザー体験が大きく変わります。

そのため、モデル更新の影響を通常のテキスト生成以上に慎重に評価する必要がありました。

課題3：ブラウザからの直接接続では、障害の原因を調査しにくい

ブラウザからGemini APIへ直接接続する構成では、音声データが自社のバックエンドを通りません。

これはシステムをシンプルにできる一方で、障害調査の面では弱点になります。

例えば、次のような問題が発生したとします。

• 会話の途中で接続が切れた
• AIの返答が始まるまで時間がかかった
• 特定の時間帯だけ接続しにくい
• 複数人が使うと動作が不安定になった
• 特定のユーザーだけ音声が遅れた
• レート制限エラーが返された

ブラウザ側のログから、接続が切れたという事実や、受信したエラーは確認できます。

しかし、通信経路の途中に自社のサーバーがないため、原因を詳細に切り分けることが困難でした。

原因としては、さまざまな可能性があります。

• ユーザーのネットワーク
• ブラウザ内部の処理
• WebSocket接続
• API側からの切断
• モデルやサービス側の負荷
• リージョンや通信経路
• 同時利用数やクォータ
• 音声データの送信タイミング

PoCであれば、「もう一度試してください」で済む場合もあります。

しかし、実際の顧客が利用するサービスでは、原因を調査できないこと自体が事業上のリスクになります。

課題4：最新モデルと安定した運用基盤にトレードオフがあった

本番環境での認証、利用量管理、監視などを考えると、Vertex AIは有力な選択肢です。

Vertex AIを利用すると、Google CloudのIAMやクォータ管理と統合しやすくなり、バックエンドから安全にAPIを利用できます。

一方で、検証時点では、Gemini APIで利用できた新しいLiveモデルが、Vertex AIではまだ利用できないケースがありました。

最新モデルを優先すれば、音声品質や会話体験を向上させやすくなります。

一方、安定した運用やセキュリティを優先してVertex AIへ移行すると、PoCで使用していたモデルをそのまま利用できない可能性があります。

ここで重要なのは、モデルの性能だけを比較しても、商用サービスの構成は決められないという点です。

モデル品質、提供形態、認証、運用、ログ、障害対応まで含めて判断する必要があります。

課題5：Vertex AIへ移行すると、通信基盤も作り直す必要があった

Gemini APIでは、短時間のみ有効なEphemeral Tokenを利用し、ブラウザからLive APIへ直接接続できます。

これにより、長期間有効なAPIキーをブラウザに置くことなく、シンプルな通信経路を実現できます。

一方、Vertex AIでは、Google CloudのIAMやサービスアカウントを利用した認証が基本になります。

サービスアカウントの認証情報をブラウザに持たせることはできないため、自社のバックエンドを経由する構成が必要になります。

通常のチャット機能であれば、ブラウザからバックエンドへリクエストを送り、バックエンドがAIの応答を返す構成で対応できます。

しかし、音声対話では、音声をリアルタイムに双方向で送受信する必要があります。

そのため、一般的なWeb APIだけではなく、長時間の音声通信を維持するリアルタイムサーバーが必要になりました。

つまり、Gemini APIからVertex AIへの移行は、単に接続先を変更するだけではありませんでした。

Gemini API
+ Ephemeral Token
+ ブラウザから直接接続

という構成から、

Vertex AI
+ 自社バックエンド
+ リアルタイム通信基盤
+ セッション管理
+ ログと監視

という構成への変更が必要になりました。

課題6：Vercelとは別にリアルタイム通信サーバーが必要になった

フロントエンドはNext.jsで実装し、Vercelでホスティングしていました。

一般的なWebサイトやWebアプリケーションであれば、Next.jsとVercelの組み合わせは非常に扱いやすい構成です。

しかし、今回必要だったのは、ユーザーごとに長時間維持される双方向の音声通信です。

そのため、フロントエンドと同じ構成だけでは完結せず、WebSocket接続などを維持するサーバーを別途用意する必要がありました。

リアルタイムサーバーを構築する場合、考慮するのは単に音声を中継することだけではありません。

• 長時間接続の維持
• 切断時の再接続
• ユーザーごとのセッション管理
• 音声データのバッファリング
• 同時接続数に応じたスケーリング
• タイムアウト
• 利用量と課金の制御
• ログと監視
• 音声形式の変換

PoC時点では小さく見えた機能でも、本番化すると開発・運用範囲が大きく広がります。

対策：LiveKitを使って音声通信を管理する

リアルタイム音声通信をすべて自前で実装すると、開発だけでなく、その後の運用負荷も大きくなります。そこで、WebRTC基盤としてLiveKitを導入しました。

LiveKitを利用することで、次のような機能を管理しやすくなりました。

• リアルタイム音声通信
• ユーザーごとのセッション管理
• 接続状態の監視
• Agentプロセスとの連携

自前でWebSocketサーバーを構築する場合と比較すると、音声通信に必要な機能を一から実装せずに済みます。また、通信を自社側で管理することで、セッション単位のログも取得できるようになりました。

例えば、次のような情報です。

• 接続開始と終了の時刻
• 切断理由
• 再接続回数
• 音声データの送受信量
• AIの応答開始までの時間
• APIエラー
• 利用モデルと設定
• セッションの状態変化

これにより、API側の問題なのか、通信基盤の問題なのか、クライアント側の問題なのかを、以前より切り分けやすくなりました。

LiveKitを導入しても、ブラウザや端末固有の問題は残った

LiveKitとVertex AIを組み合わせたことで、サーバー側の通信と運用は安定させやすくなりました。しかし、それでもすべての問題が解消したわけではありません。

実際の利用環境では、次のような問題が残りました。

• 特定の端末だけ音声再生が遅れる
• 特定のブラウザだけ音声が途切れる
• 長時間利用すると音声品質が変化する
• Bluetooth機器の接続状態によって挙動が変わる
• マイクやスピーカーの切り替え時に問題が発生する
• 特定のユーザー環境でしか問題を再現できない
• 音声の再生速度が突然、極端に遅くなる

特に判断が難しかったのが、会話の途中から音声が急にスローモーションのようになり、体感では通常の10分の1程度の速度で再生される事象です。サーバーから音声データ自体は返ってきていても、クライアント側では正常な速度で再生されません。

このような事象が発生した場合、原因として次のような可能性が考えられます。

• 音声のサンプリングレートの扱い
• ブラウザ内の音声バッファ
• AudioContextの状態
• 端末の負荷
• メモリ不足
• 音声トラックの再接続
• OSやブラウザによる省電力制御
• 音声デコードや再生処理の一時的な異常

しかし、Webアプリケーションから取得できる情報には限界があります。サーバー側のログを増やしても、ブラウザや端末内部の状態をすべて取得できるわけではありません。

例えば、次のような情報は十分に観測できない場合があります。

• OS側の音声デバイスの詳細な状態
• 他のアプリケーションによる音声デバイスの利用
• ブラウザ内部の音声処理
• 端末全体のCPUやメモリ使用状況
• OSによるバックグラウンド制御

この経験から、音声対話AIでは、サーバー側の安定性とユーザー端末側の安定性を分けて考える必要があると分かりました。LiveKitはリアルタイム通信基盤の課題を減らしてくれますが、ユーザーの端末上で発生する音声再生の問題まで、すべて解決してくれるわけではありません。

現時点では、ネイティブアプリとVertex AIの組み合わせが有力

今回の検証を通じて、継続的に利用される本番プロダクトでは、現時点では次の構成が有力だと考えています。

つまり、ネイティブアプリとVertex AIを組み合わせる構成です。

もちろん、すべてのサービスにこの構成が必要というわけではありません。

短時間のデモ、利用者が限定された社内ツール、インストール不要で気軽に試してもらうサービスでは、ブラウザベースの構成が適している場合もあります。

一方、次のようなサービスでは、ネイティブアプリを検討する価値が高いと考えます。

• ユーザーが長時間音声対話を行う
• 音声の遅延や途切れが業務に影響する
• マイクやスピーカーを安定して制御したい
• 端末や音声機器の状態を詳しく取得したい
• 障害発生時に詳細な原因調査が必要
• 現場業務や接客、教育などで継続利用する
• ユーザー環境をある程度統一できる

ネイティブアプリであれば、ブラウザよりも端末やOSの機能へアクセスしやすくなります。マイクやスピーカーの状態、アプリのメモリ使用状況、バックグラウンド動作などを把握・制御しやすくなり、障害調査の選択肢も増えます。

また、バックエンドではVertex AIを利用することで、認証、利用量管理、監視などをGoogle Cloud上で統合しやすくなります。

そのため、安定性や運用管理を重視する本番サービスでは、現時点では「ネイティブアプリ＋Vertex AI」が有力な選択肢だと考えています。

ただし、これはあらゆるプロダクトに共通する唯一の正解ではありません。モデルの提供状況や各サービスの仕様は変化が速いため、実際の採用時には次の項目を改めて評価する必要があります。

• 利用できるモデル
• 会話と音声の品質
• 対象リージョン
• クォータと同時接続数
• インフラ費用
• 想定する利用端末
• 一回あたりの利用時間
• 必要な障害調査の範囲

重要なのは、最新のモデルを採用することではなく、サービスに必要な品質から逆算して構成を選ぶことです。

新規事業やPoC担当者が、商用開発前に確認すべきこと

音声対話AIのプロジェクトでは、PoCで会話が成立すると、そのまま商用化できるように感じられます。

しかし、実際にはPoCの次の段階で、アーキテクチャやクライアント方式を大きく見直すことがあります。

商用開発を始める前に、少なくとも次の点を確認することが重要です。

1. PoCで何を検証し、何を検証していないかを明確にする

PoCでユーザー体験やサービスの価値を確認できたとしても、次の項目まで検証できているとは限りません。

• 複数人による同時利用
• 長時間の連続利用
• 低速または不安定なネットワーク
• 複数のブラウザとOS
• メモリやCPUに余裕がない端末
• API障害時の復旧
• モデル更新時の影響

PoCの結果を評価するときは、「成功したか」だけでなく、「どの条件まで確認できたか」を整理する必要があります。

2. ユーザー体験の検証と、技術的な安定性の検証を分ける

ユーザーが音声対話を便利だと感じるかを確認する検証と、本番環境で安定して動作するかを確認する検証は、目的が異なります。

前者では、会話設計やサービス価値が中心になります。後者では、同時接続、通信、端末差、ログ、復旧などが中心になります。

一つのPoCですべてを確認しようとせず、検証の段階を分ける方が、結果を判断しやすくなります。

3. 想定する利用環境を具体化する

「Webで使える音声AI」という要件だけでは不十分です。

• PCかスマートフォンか、タブレットか
• Chromeだけか、Safariも対象か
• 一回の会話時間は何分か
• 同時に何人が利用するか
• 通信環境が悪い場所でも利用するか
• 利用者の端末を指定できるか

これらによって、適切な構成は変わります。

4. モデル品質だけで構成を決めない

音声対話AIでは、モデル品質は非常に重要です。一方で、商用サービスでは次の項目も同じように重要です。

• 認証
• 同時接続
• クォータ
• 通信経路
• ログ
• 監視
• 障害復旧
• モデル更新への対応
• クライアント端末の制御

PoCで最も自然に会話できたモデルが、そのまま本番サービスに最適とは限りません。

5. PoC後の作り直しも計画に含める

PoC用の構成を、そのまま本番に利用できるとは限りません。

PoCは事業仮説やユーザー体験を素早く検証するためのものと割り切り、本番化する際に、次の要素を見直す可能性があります。

• 利用するAPI
• モデル
• 認証方式
• 通信基盤
• クライアント方式
• ログと監視
• インフラ構成

PoCと商用開発を完全に同じ構成にすることよりも、「何を残し、何を作り直す可能性があるか」を事前に認識しておくことが重要です。

今回得られた教訓

1. PoCの成功は、商用化の成功を意味しない

少人数、短時間、限定された端末で動作することと、多数のユーザーが継続利用できることは別の問題です。特に今回のPoCでは、ユーザー体験やサービス価値の検証を優先していたため、本番運用を想定したアーキテクチャの検討が十分ではありませんでした。

PoCの結果を商用化の判断に利用する際には、検証できていない範囲を明確にする必要があります。

2. 同時利用の検証は早い段階で行う

一人で利用したときに安定していても、複数人が同時に接続すると挙動が変わる場合があります。公表されているクォータだけを確認するのではなく、実際の想定利用人数で負荷をかけ、音声品質や接続状態を確認することが重要です。

3. 最新モデルと本番安定性は別々に評価する

最新モデルが優れた会話体験を提供できても、本番環境で安定して利用できるとは限りません。認証、クォータ、提供の継続性、監視、障害調査、更新時の影響まで含めて判断する必要があります。

4. APIの変更は、システム全体の変更につながる

Gemini APIからVertex AIへの移行は、接続先を変えるだけではない場合があります。認証方式、通信経路、バックエンド、セッション管理、ログの設計まで変更が必要になる可能性があります。

5. LiveKitを入れても、端末側の問題は残る

LiveKitなどのWebRTC基盤を利用すると、リアルタイム通信やセッション管理の問題を減らせます。一方、ブラウザ、OS、音声デバイス、端末負荷などに起因する問題まですべて解決できるわけではありません。

音声が極端に遅くなるような端末固有の事象まで考えると、クライアント側の観測と制御が重要になります。

6. 本番向けには、現時点でネイティブアプリ＋Vertex AIが有力

端末制御、障害調査、認証、運用管理を総合的に考えると、長時間・継続利用される音声対話サービスでは、ネイティブアプリとVertex AIの組み合わせが有力です。

ただし、利用の手軽さや導入速度を優先する場合には、Webアプリケーションが適するケースもあります。Webかネイティブかを最初から固定するのではなく、サービスで求める安定性、利用時間、利用環境から判断することが重要です。

実際に、ネイティブアプリで音声対話AIを扱っているプロジェクトは安定稼働をしています。

まとめ

Geminiを利用したSpeech-to-SpeechのPoCは、比較的短期間で構築できます。一方、商用サービスにするためには、モデル以外にも多くの要素を設計する必要があります。

今回のPoCでは、ユーザー体験や周辺機能を含めたサービスの価値を検証することを優先していました。その目的に対して、ブラウザからGemini APIへ直接接続する構成は有効でした。

しかし、商用化を進める中で、同時利用時の不安定さ、レート制限に見えるエラー、モデルの挙動変化、ブラウザや端末固有の音声問題などが顕在化しました。通信基盤をLiveKitとVertex AIへ移行することで、サーバー側の管理性と観測性は改善しました。

一方で、音声が突然極端に遅くなるなど、ブラウザや端末側に起因すると考えられる問題は残りました。

今回の経験から得られた最も大きな教訓は、次の点です。

音声対話AIでは、「どのAIモデルを使うか」だけでなく、「どの端末で、どの通信経路を通し、どこまで観測・制御するか」を一体として設計する必要がある。

PoCでは、事業仮説やユーザー体験を素早く検証することが重要です。

一方、商用化では、異なる端末やネットワークでも安定して動き、問題発生時に原因を調査できることが重要になります。

そのため、PoCを始める段階から次の点を意識しておく必要があります。

• PoCでは何を検証するのか
• 商用化までに追加で何を検証するのか
• 想定する同時利用人数は何人か
• 一回の利用時間はどの程度か
• どの程度の遅延や切断まで許容できるか
• 障害発生時にどこまで原因を調査する必要があるか
• Webとネイティブのどちらが利用環境に適しているか
• PoCと本番でアーキテクチャが変わる可能性を織り込んでいるか

安定性、運用管理、端末制御までを重視する本番プロダクトでは、現時点ではネイティブアプリとVertex AIの組み合わせが有力だと考えています。

ただし、それはあらゆる音声AIサービスに当てはまる唯一の正解ではありません。

音声対話AIでは、PoCを動かすことと、サービスとして提供し続けることの間に大きな差があります。

その差を早い段階で認識し、ユーザー体験の検証と商用アーキテクチャの検証を段階的に進めることが、手戻りを減らすうえで重要です。