Hugging Face speech-to-speechを完全ローカルにする条件──OSS音声エージェントの4段構成¶

対象 / 採用判断

対象: ローカルまたは自社管理の音声エージェント基盤を比較しているAIアプリケーション開発者

採用が合う	別案が合う
音声認識、LLM、音声合成を個別に交換したい	抑揚や発話の重なりを音声ネイティブな単一モデルで保ちたい
Realtime API対応クライアントを再利用したい	OpenAI Realtimeの全イベントとの一致が必須である
音声データと推論先を自分で管理したい	日本語の本番品質を設定変更なしで得たい

Hugging Faceのhuggingface/speech-to-speechは、Apache-2.0の音声エージェント基盤である。 2026年7月17日にPyPI版0.2.11が公開され、開発段階はAlphaだ。¹²

名前だけを見ると音声から音声へ直接変換する単一モデルに見える。実体は違う。 VAD、STT、LLM、TTSを直列につなぎ、各段を交換できるカスケード型パイプラインである。

この記事の問いは、何をローカルにでき、どの条件ならこのOSSを選ぶべきかだ。

VAD、STT、LLM、TTSの4段構成と、LLMをクラウドまたはローカルへ切り替える境界

4段の交換可能性がこのOSSの本体である¶

speech-to-speechは、音声入力を4つの処理へ渡す。各処理は別スレッドで動き、キューで次の段へ結果を送る。¹

段	既定の役割	交換で変えられるもの
VAD	Silero VAD v5で発話の開始と終了を検出	無音判定、割り込み感度
STT	Parakeet TDTで音声をテキスト化	対応言語、認識精度、計算量
LLM	OpenAI互換APIで応答とツール呼び出しを生成	知能、遅延、データの送信先
TTS	Qwen3-TTSでテキストを音声化	声質、言語、生成速度

ここでの「speech-to-speech」はモデル名ではなく、部品をつなぐランタイムの名前だ。一体型の音声モデルと違い、STTが作ったテキストをLLMへ渡すため、声の抑揚や間の情報を知能層が直接読む設計ではない。

代わりに、英語認識だけを高速化する、LLMだけを社内サーバーへ置く、TTSだけを日本語向けへ替える、といった局所的な改善ができる。 品質の上限を1モデルに預けず、ボトルネックになった段だけを交換する設計だ。

標準起動ではLLMだけがクラウドへ出る¶

最短のQuickstartは完全ローカルではない。既定ではSTTとTTSがローカルで動く一方、LLMバックエンドはOpenAI Responses APIを使い、 APIキーを要求する。現行設定の既定モデルはgpt-5.4-miniである。¹³

pip install speech-to-speech
export OPENAI_API_KEY=...
speech-to-speech

この構成では生音声の認識と音声合成は手元に残るが、文字起こしされた発話はLLM提供先へ送られる。「音声ファイルが外へ出ない」と「会話内容が外へ出ない」は同じではない。

全段をローカルにするには、LLMをllama.cppやvLLMで起動し、responses_api_base_urlをそのサーバーへ向ける。公式の現行例はGemma 4をllama.cppで提供し、空のAPIキーで接続する。¹⁵

speech-to-speech \
  --model_name "ggml-org/gemma-4-E4B-it-GGUF" \
  --responses_api_base_url "http://127.0.0.1:8080/v1" \
  --responses_api_api_key ""

リポジトリのライセンスがApache-2.0でも、組み合わせるモデル、音声、推論サーバーの利用条件まで一括で同じになるわけではない。本番では4段それぞれのライセンスとデータ送信先を確認する必要がある。

Realtime API互換がクライアントと推論基盤を分離する¶

このOSSのもう一つの価値は、/v1/realtimeのWebSocketを公開する点にある。クライアントは音声チャンクやsession.updateを送り、サーバーは文字起こし、音声差分、ツール呼び出し、完了イベントを返す。⁴

そのため、OpenAI Realtime対応のクライアント側を大きく変えず、背後だけをセルフホストへ差し替えられる。 Hugging FaceのReachy Miniも、接続先URLをローカルのspeech-to-speechへ変える構成を採る。⁵

ただし、READMEが主張するのは「互換API」であり、公式実装もコアイベント群を列挙している。 OpenAI側の全イベントや将来の仕様まで自動的に一致する保証ではない。必要なイベント、音声形式、ツール結果の返し方をクライアント単位で試すべきだ。

低遅延はストリーミングと割り込み制御で作られる¶

カスケード型では、4段の待ち時間が足し合わされる。特に公式READMEはLLMを最も計算量と遅延が大きい段と説明する。¹

speech-to-speechは、LLMのテキストとTTSの音声をストリーミングし、全回答の完成を待たずに再生を始める。ユーザーが途中で話すとVADが発話開始を通知し、共有のCancelScopeが古いLLM/TTS出力を無効化してキューを掃除する。⁴

これは単なる4コマンドの接着ではない。音声対話で難しいのはモデルを呼ぶことより、古い応答を止め、新しい発話へ会話状態を正しく渡すことだからだ。

一方、リポジトリは利用環境ごとのエンドツーエンド遅延を保証していない。 SmartScopeは今回、ソースと設定を静的に確認し、モデルのダウンロード、実音声、遅延ベンチマークは実施していない。採用時は発話終了から最初の音声が出るまでを自分のハードウェアで測る必要がある。

日本語ではSTTをWhisper系へ替える¶

既定のParakeet TDT 0.6B v3は25の欧州言語向けで、日本語を含まない。⁶ 日本語入力では、リポジトリが選択肢として持つWhisper系へSTTを替えるのが出発点になる。

Whisper large-v3は多言語チェックポイントで、Hugging Faceのモデルカードは99言語を掲げる。⁷ 一方、既定TTSのQwen3-TTSは日本語を含む10言語をサポートする。⁸

speech-to-speech \
  --stt whisper \
  --stt_model_name openai/whisper-large-v3 \
  --language ja \
  --qwen3_tts_language ja

これで「日本語対応済み」と判断するのは早い。固有名詞、方言、雑音、発話のかぶり、TTSの読み方は用途ごとに差が出る。音声認識の誤りがLLMへ渡り、その返答をTTSが読み上げるため、各段の小さな誤差が会話全体へ連鎖する。

採用基準は「完全ローカル」より交換境界に置く¶

SmartScopeの評価では、このOSSが合うのは「音声AIをローカルで動かしたい人」全般ではない。 STT、LLM、TTSのどこを自分で選び、どこまで運用責任を持つかを決められるチームに合う。

音声の抑揚を直接扱うことが最優先なら、音声ネイティブなエンドツーエンドモデルを先に比較する。日本語のゼロ設定品質や大規模同時接続を求めるなら、Alpha段階のOSSへ運用を足す費用と、マネージド音声APIの費用を並べる。

逆に、既存Realtimeクライアントを残しながら、音声認識だけ、LLMだけ、音声合成だけを交換したいなら設計が噛み合う。完全ローカルは製品属性ではなく、4段すべての実行先を自分で選んだ結果である。