Google ColabをAPIサーバー化してS2S音声対話を動かしてみた

「音声対話AI（Speech-to-Speech: S2S）を試したいけど、検証のためだけにGPUサーバーをわざわざ契約するのは大げさすぎる」

そう考えている方は多いのではないでしょうか。検証段階なら、GPUは必要なときにだけ借りたい。そこで思い浮かぶのがGoogle Colabですが、Colabはそもそも「外部からアクセスできるサーバー」ではありません。

Colabはノートブックのセルを実行するだけの環境で、そこにWebSocketで接続してリアルタイムに音声をやり取りする、という使い方は想定されていません。「できるとしても、どうせ不安定で使い物にならないだろう」と、最初は思っていました。

しかし実際にやってみたら、思ったより普通に動きました！

今回は、Google Colabと無料アカウントの範囲で構築したS2S音声対話の検証環境と、会話のテンポを良くするためのレイテンシ改善の取り組みについて、「こんな仕組みでやってみたら、いい感じになった！」という知見をご紹介します。

1. Colabに、ngrokで穴を開ける

やったことはシンプルです。
Colabのセルでサーバープロセスを起動し、トンネリングサービス「ngrok」で一時的な公開URLを発行して、手元のPCからそのURLに接続します。

これだけで外部からアクセス可能な一時的なURLが払い出されるのですが、実際に検証を繰り返していると、「毎回 ngrok の URL を確認して、手元のクライアントスクリプトの引数を書き換える」のが少し面倒になってきます。

そこで、セル実行時の出力ログに「手元のPC（ローカル環境）側でそのままコピー＆ペーストして実行できるコマンド」を生成して表示するような仕掛け（親切設計）を仕込んでおきました。

セル実行後には次のようなログが表示されます。

🚀 S2S v2 Server (WebSocket) Ready!
URL: https://xxxx-xx-xx-xxx-xx.ngrok-free.app
📋 Client Command (Run this locally):
uv run client_s2s.py --url wss://xxxx-xx-xx-xxx-xx.ngrok-free.app

この出力されたコマンドをそのままコピーして手元のターミナルに貼り付け、uv runを叩くだけで、即座にAIと会話ができる状態になります。
毎回URLを手入力で書き換える手間が省けて、無料のColabと無料のngrokアカウントだけでも非常にスムーズに動作確認が行えます！

システム構成にすると、こうなります。

[手元のPC（クライアント）]                 [Google Colab（T4 GPUサーバー）]
     マイク入力                                 faster-whisper (STT)
       │                                           │
       ▼ VAD (Silero) で発話区間を検出              │
  WebSocketで音声を送信  ──────ngrok───────► Gemini 2.5 Flash-Lite (LLM, streaming)
       ▲                                           │
       │ 音声を受信して再生                         ▼
     スピーカー出力                            VOICEVOX Engine (TTS)

役割はGPU側とPC側で完全に分かれています。
音声認識（STT）と音声合成（TTS）という重い処理はColabのT4 GPUに任せ、手元のPCはマイクとスピーカーの世話だけをします。

2. サーバー側のセットアップとモデル選定の話

Colab側の環境構築は、Pythonのセルを実行して必要なライブラリのインストールや各種AIモデルのロードを進めていきます。

初回だけ数分のセットアップ時間がかかりますが、起動してしまえばあとは何度話しかけても同じセッションを使い回せます。接続が切れたり壊れたりしたら、セルをもう一度実行するだけのお手軽仕様です。また、音声合成用の「VOICEVOX Engine (GPU版)」もColab上でバックグラウンドプロセスとして起動させておきます。

ここで、音声認識（STT）のモデル選びにはちょっとした一悶着がありました。
最初はmediumクラスの軽いモデルで十分だろうと考えていました。「日本語の文字起こしだし、そこまでの精度は要らないだろう」と。

これが甘い見立てでした。
mediumも、軽量版のdistil-whisper-large-v3も、実際に日本語で試すと聞き取りが崩れる場面が多く、実用に届きませんでした。
結局、精度は最上位のlarge-v3一択で決着。その代わり、処理速度はモデルを小さくして稼ぐのではなく、モデルサイズはそのままにint8系（int8_float16）へ「量子化」することで確保しました。

「モデルを小さくして速くする」のではなく、「精度が出る一番大きいモデルを、量子化で速くする」。この組み合わせに落ち着くまでに、いくつかのモデルを実際に喋って比べる時間が必要でした。

対話生成（LLM）のほうは、方針で迷うことはありませんでした。
GPUで自前のLLMを動かすとColabのGPU負荷が跳ね上がって動作が遅くなってしまいます。そこで、LLMはAPI経由で爆速で動く「Gemini 2.5 Flash-Lite」を採用しました。JSON出力や機能呼び出し（Function Calling）も安定しています。ここでGPUを使わないと決めたことで、Colab側の負荷は音声認識と音声合成の2つだけに絞ることに成功しました。

3. 「間」を縮める：文単位のバッファリングと並行音声合成の仕組み

構成が動き出してから、最初に引っかかったのは会話の「間（遅延）」でした。
LLMの返答テキストをすべて生成し終えてから音声合成にかけると、返答が長いほど無音の時間が伸びてしまいます。
人間相手なら、これは会話が成立していないレベルの長さです。

そこで、Geminiのストリーミング応答を文の区切り（句点や改行）でバッファリングし、1文が確定した時点ですぐVOICEVOXに投げる形に変えました。

さらに、VOICEVOXでの音声合成処理をバックグラウンドのスレッドプールで並行して走らせる「非同期TTSマネージャー」の仕組みを実装しました。

これにより、**「LLMが後半の文章を生成している間に、先行して確定した最初の文の音声合成が裏で走り、出来上がった音声から即座にクライアントへストリーミング送信される」**という並行処理を実現しました。

効果はログを見るまでもなく、耳で分かるくらいはっきりテンポが良くなりました！

4. VOICEVOXのダウンロードを工夫してエラーを防ぐ

VOICEVOX EngineのGPU版は、GitHub上で5つの分割ファイルとして配布されています。
最初はシンプルに1番から5番まで順にダウンロードする処理を書いていたのですが、Colabのネットワークが不安定なタイミングに当たると、分割ファイルの一部だけが欠けたまま解凍が走り、エラーで止まってしまう問題が起きました。

しかも欠けているのが途中のファイルだったりすると、原因の切り分けに余計な時間がかかってしまいます。

そこで、5つのファイルを並列でダウンロードし、エラー時には自動リトライを行い、さらにダウンロード完了後に「途中の番号が抜けていないか」の整合性を自動でチェックする仕組みを組み込みました。

Colabのセルを何十回も再実行しながら検証を進めていたので、こういう「たまに失敗する外部ダウンロード」への耐性を早めに入れておいたのは大正解でした。

5. 手元のPCは、マイクとスピーカーだけで動く

クライアント側は、Pythonのパッケージ管理ツール uv の機能を利用し、事前準備なしで1コマンドで起動できるようにしました。

クライアントがやっていることは主に3つです。

1. Silero VAD というライブラリを使って、ユーザーが「話し始めた瞬間」と「話し終わった瞬間（無音）」を高精度に検出
2. 音声データをWebSocketでColabサーバーに送信
3. サーバーから順次送られてくる音声バイナリを受信して順番に再生

VADパラメータの「現場調整」

この発話区間検出（VAD）のしきい値や、何秒無音が続いたら発話終了とするかといった数値は、机上の設計だけで決められるものではありませんでした。

早口で相槌を挟む人が多い用途なら無音判定時間を短くしたく、考えながらゆっくり話す用途なら長めに取りたくなります。

実際に何十回も自分で喋って、AIに会話を割り込まれたり、逆に待たされすぎたりする感覚を確かめながら、今回は無音継続時間「350ミリ秒」という最適な落とし所に着地させました。やはり自分で喋ってみて調整するのが一番です。

6. 結局、何が体感速度を決めていたのか

ここまで組み合わせて動かしてみると、会話のテンポを左右していたのは、LLMの生成速度ではありませんでした。
本当に効いていたのは「発話が終わってから、最初の音が返ってくるまで」の区間（初動レイテンシ）です。

この「発話終了から音声受信までの時間」をログで計測しながら、テキストをどこで区切って音声合成に流すか、音声合成エンジンを何並列で動かすかを調整していきました。

これこそが検証（PoC）の実質的な作業のほとんどでした。
カタログスペックを眺めているだけでは、この区間がどこまで縮むのかは分かりません。

7. まとめ

• Colabはノートブックですが、ngrokでAPIサーバー化すれば、GPUサーバーを契約せずにS2Sの検証環境が丸ごと作れます。
• 音声認識は精度優先でlarge-v3を選び、速度は量子化で稼ぎます。
• LLMの返答をストリーミングで受け、文単位で音声合成に回すと会話の「間」がグッと縮みます。
• VADのしきい値は利用シーンによって変わるため、実際に喋りながら調整する必要があります。

無料のColabと無料のngrokで、ここまで動くとは思っていませんでした。
次に試したいのは、この構成のままどこまで同時接続数を増やせるかですが、それはまた別の機会にご紹介します。

当社では、こうしたPoC構築から、商用版の開発までを行なっています。
「まず検証したい」という段階から、お気軽にご相談ください。