音声AI対話OSS「speech-to-speech」が選ばれる理由と競合比較

音声AI対話OSSの実装を検討する際、Hugging Face が公開する speech-to-speech は「ローカル完結・OpenAI Realtime API 互換・Hub のモデルを自由に差し替え可能」という三点セットで注目を集めています。ただし同じ音声パイプライン領域には、Daily 社の Pipecat、LiveKit の Agents SDK といった有力な OSS がすでに存在します。技術選定を任されたエンジニアにとっては「どれを選べば良いのか」を短時間で判断する材料が必要です。

とくに困りやすいのは、各 OSS の設計思想の違いが公式ドキュメントの表面だけでは掴みづらい点です。speech-to-speech は Hugging Face エコシステム統合を軸にしていますが、Pipecat はマルチプロバイダ抽象、LiveKit Agents は WebRTC ネイティブと、それぞれ強みの領域が異なります。この差を理解しないまま採用してしまうと、あとから運用上の制約に気付いてスタックの入れ替えが発生します。

本記事では、speech-to-speech のアーキテクチャ・実行モード・LLM バックエンドの選択肢を公式ドキュメントベースで整理したうえで、Pipecat・LiveKit Agents との棲み分けを 3 軸で比較します。最後に「どういうときに speech-to-speech を採用すべきか」を判断チェックリストとしてまとめ、読者が自プロジェクトへの適合性を一次判断できる状態を目指します。

なお本記事は動作検証を行わず、GitHub 上の公式リポジトリと Hugging Face の公式ブログ記事の記述のみを根拠に整理しています。数値・仕様は本記事執筆時点のものです。

speech-to-speech とは

speech-to-speech は、Hugging Face が公式に公開しているローカル音声 AI エージェント構築用の OSS です。GitHub 上のリポジトリは huggingface/speech-to-speech で、ライセンスは Apache-2.0、記述言語は Python、記事執筆時点のスター数は 6,022、フォーク数は 841、直近のプッシュは 2026 年 7 月 9 日です。リポジトリはアーカイブされておらず、フォークでもなく、Hugging Face 本体組織直下でアクティブにメンテナンスされている一次リポジトリです。

リポジトリの一行説明は「Build local voice agents with open-source models」で、ローカル環境かつ OSS モデル中心で音声エージェントを組み立てるための土台を提供することを目的としています。

何を解決する OSS か

このプロジェクトが提供するのは、VAD → STT → LLM → TTS の 4 段パイプラインを OpenAI Realtime 互換の WebSocket API 経由で公開する仕組みです。Realtime API 互換であるため、OpenAI Python SDK の client.realtime.connect(...) などの既存クライアントをエンドポイントの差し替えだけで再利用できます。ホスト版 OpenAI Realtime からセルフホストへ移行するシナリオや、逆にセルフホスト前提でクライアント SDK 資産を活用したいシナリオに向いています。

技術ブログでの深掘り記事や実装レポートも複数存在しており、日本語圏でも note の紹介記事 や Zenn のスクラップ などで検証内容が共有されています。

基本情報と本記事の位置づけ

プロダクション実績としては、Hugging Face 自身が販売する OSS ロボット Reachy Mini の会話バックエンドとして採用されており、公式ブログの Reachy Mini goes fully local: on-device speech-to-speech conversation で完全ローカル構成の実装例が公開されています。「メンテナンスが健全か・実運用実績があるか」という採用判断の起点は、リポジトリ活動と Reachy Mini の稼働台数の両面から確認できます。

本記事では以降、この speech-to-speech の設計特徴を整理したうえで、同じ音声エージェント領域の主要 OSS である Pipecat と LiveKit Agents との違いを比較していきます。

アーキテクチャの特徴

speech-to-speech は、音声入力から音声応答までを 4 段のカスケード構成で処理します。README の「How it works」セクションに記載されているとおり、各段は独立したスレッドで動作し、段の間はキューで接続されるためストリーミング性能を確保できる設計です。

4 段パイプライン（VAD / STT / LLM / TTS）の役割

この 4 段構成自体は音声エージェントの一般的な設計です。特徴的なのは、各段が CLI フラグ（--stt、--llm_backend、--tts など）で個別に差し替え可能な点で、Hugging Face Hub 上の新しいモデルを短いフィードバックループで試せる作りになっています。

各段のバックエンド選択肢

各段で選択可能なバックエンドは README「Supported Components」に列挙されています。以下は主要な選択肢の抜粋です。

STT のデフォルトである Parakeet TDT はヨーロッパ 25 言語をカバーし、TTS のデフォルト Qwen3-TTS は自動言語判定に対応するため、多言語音声エージェントの初期構成としてもそのまま利用できるようになっています。

OpenAI Realtime API 互換の意味

speech-to-speech の対外インターフェースは、既定で ws://localhost:8765/v1/realtime に WebSocket サーバとして立ち上がり、OpenAI Realtime プロトコルのコアイベント群を実装します。README には、受信側で input_audio_buffer.append / session.update / conversation.item.create / response.create / response.cancel を扱い、送信側で音声開始・停止・ストリーミング書き起こし・音声デルタ・tool call・response.done などを返す旨が明記されています。

エンジニアリング詳細は Realtime Engine の実装 README にまとめられており、OpenAI Python SDK の client.realtime.connect(...) からそのまま接続できる互換性を保つことを設計目標として掲げています。これはつまり、OpenAI Realtime に依存する既存のクライアント SDK・サンプル資産を、エンドポイント URL の差し替えのみでセルフホスト側に振り向けられることを意味します。ロックインを避けつつクライアント側の実装コストを抑えたいプロジェクトでは、大きな採用理由になり得ます。

実行モードと LLM バックエンドの選択肢

speech-to-speech は、単一のトランスポート方式に固定されているわけではありません。README の「Run Modes」および「LLM Backends」セクションに、複数の実行モードと LLM 接続先が整理されています。自社インフラ・クライアント形態に応じて選び分けられる点は、採用判断の重要な材料になります。

実行モード 4 種の使い分け

realtime モードは既存の Realtime SDK 資産を活かしたい場合の第一選択、local はデバイス内完結のプロトタイプ、websocket / socket は独自プロトコルで最小構成のクライアントを組みたい場合に選ばれる、というのが README の説明から読み取れる位置づけです。

LLM バックエンドの選択肢

LLM の接続先は、OpenAI 互換 API を軸に幅広く選べます。README「LLM Backends」に列挙されている主な選択肢は以下のとおりです。

vLLM の Responses ストリーミングが不安定な場合は --llm_backend chat-completions で /v1/chat/completions に切り替える運用が README で紹介されています。この切り替えオプションが用意されていること自体、実運用で発生し得る不整合を吸収する設計配慮の一つとして参考になります。

README の「Quickstart」に記載されているとおり、既定構成での起動は 3 行で完結する形になっています。以下は README からの抜粋です。

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

出典: huggingface/speech-to-speech README

これで ws://localhost:8765/v1/realtime に Parakeet TDT（STT）+ OpenAI Responses API （LLM）+ Qwen3-TTS（TTS）の Realtime 互換サーバが立ち上がる、という前提が README に示されています。完全ローカル構成については、Hugging Face 公式ブログの Reachy Mini goes fully local に llama.cpp と Gemma 系モデルを組み合わせた構成例が示されています。

多言語対応

多言語対応は README「Multi-Language Support」に整理されています。STT 側では Parakeet TDT がヨーロッパ 25 言語、Whisper 系は幅広い多言語をカバーし、TTS 側では Qwen3-TTS が --qwen3_tts_language auto で自動言語判定に対応します。--language <code> で単一言語に固定するか、--language auto で発話ごとに検出するかを選べる設計になっており、多言語運用が前提のプロジェクトでも初期構成で対応可能です。

類似 OSS との違い（Pipecat・LiveKit Agents）

音声エージェント OSS の代表格として、speech-to-speech と並んでよく検討対象になるのが Pipecat と LiveKit Agents です。設計思想・トランスポート・対象ユースケースの 3 軸で見ると、それぞれのポジションが明確に分かれます。

3 プロジェクトのポジションマップ

speech-to-speech は「Hub モデルで固めたセルフホスト音声エージェントを OpenAI Realtime 互換 API で公開する」ことに軸足があり、他の 2 プロジェクトとは狙う領域が異なります。

Pipecat との違い（プロバイダ抽象 vs Hub 最適化）

pipecat-ai/pipecat は、Daily 社が開発する Python 製の音声・マルチモーダル AI パイプラインフレームワークです。共通点は Python エコシステム上で STT/LLM/TTS を可換に組み合わせる点ですが、抽象化の主眼が異なります。

• Pipecat は Deepgram・ElevenLabs・Play.ht などの商用サービスを含む数十のプロバイダ統合を持ち、「多層プロバイダ抽象化」を強みとしています。
• speech-to-speech は Hugging Face Hub のモデル（Parakeet / Qwen3-TTS / HF Inference Providers 経由の OSS LLM）に最適化しており、Hub 上の新モデルを短時間で試せる Hub ネイティブ志向です。
• Pipecat は独自のパイプライン抽象を対外 API として提供する一方、speech-to-speech は OpenAI Realtime プロトコルを対外 API として公開する API 互換志向です。

判断軸としては、複数の商用プロバイダを組み替えながら運用したい場合は Pipecat、Hugging Face エコシステム中心で OSS モデル最適化を進めたい場合は speech-to-speech が向く、という整理になります。

LiveKit Agents との違い（WebRTC ネイティブ vs WebSocket 特化）

livekit/agents は、LiveKit の WebRTC メディアサーバ上に構築する音声エージェント SDK です。共通点は OSS で Realtime 志向・STT/LLM/TTS を組み合わせられる点ですが、トランスポート層の位置づけが根本的に異なります。

• LiveKit Agents は WebRTC ルーム / トラック / トランスポートを標準装備し、マルチ参加者・ビデオ・スクリーンシェア・SIP まで一貫して扱えます。
• speech-to-speech はメディアサーバを持たず、WebSocket レベルでの API 互換のみを提供します。トランスポート層の構築は利用者側の責務です。
• LiveKit はクラウド運用（LiveKit Cloud）とセルフホストの両方が公式に想定されています。

判断軸としては、WebRTC マルチ参加者・電話統合（SIP）まで含めた包括的な会議・通話基盤が必要な場合は LiveKit Agents、単一クライアントとの低レイテンシ音声対話を Realtime API 互換で提供できれば十分な場合は speech-to-speech、という棲み分けになります。

採用判断の軸（どういうときに選ぶか）

ここまで整理した設計特徴・実行モード・類似 OSS との差分を踏まえて、speech-to-speech を採用すべきケース・避けた方が良いケースをチェックリスト形式でまとめます。

採用に向くケース

• Hugging Face Hub 上のモデル（Parakeet / Qwen3-TTS / HF Inference Providers の OSS LLM 等）を中心に音声エージェントを組みたい
• OpenAI Realtime API 向けに書かれた既存クライアント SDK・サンプルの資産を、エンドポイントの差し替えだけで再利用したい
• 単一クライアント↔サーバの低レイテンシ音声対話が主要件で、WebRTC マルチ参加者は必須ではありません
• Python 中心のスタックで、CLI フラグによる段別バックエンド差し替えの柔軟性を重視します
• 完全ローカル運用（llama.cpp + OSS TTS/STT）に踏み込む余地を残しておきたい

採用が向かないケース

• WebRTC マルチ参加者・ビデオ・スクリーンシェア・SIP を一体運用する要件があります（LiveKit Agents 側の適合が高い）
• Deepgram・ElevenLabs 等の商用プロバイダを含む多層プロバイダ抽象と、プロバイダ切替の運用機能を重視します（Pipecat 側の適合が高い）
• 非 Python スタック中心で、Python プロセスを主要 API として運用する前提を避けたい

プロダクション運用時の注意

README や関連ドキュメントで示されている運用上の留意点も、採用判断の前に押さえておくと良い項目です。

• パイプライン本体は Apache-2.0 ですが、実際に組み合わせる個別モデル（Qwen3-TTS / Parakeet / Silero VAD 等）はそれぞれ別ライセンスに従います。商用利用時は各モデルカードのライセンスを個別に確認する必要があります。
• README の「Multi-Language Support」に付随する記載として、DeepFilterNet は numpy<2 を要求する一方、Pocket TTS は numpy>=2 を要求するため両者は同一環境に共存できません。組み合わせは事前に確認が必要です。
• STT・TTS モデルのウェイトによっては GPU バックエンドと CUDA バージョンに依存関係があるため、実行環境に応じた wheel の選定が必要になります。
• archive/ 配下の MeloTTS など、CLI から接続されない非推奨コンポーネントもリポジトリに残っている旨が README に記載されているため、実装時は最新の README を参照するのが安全です。

Hugging Face Endpoints へのデプロイ手順は公式ブログの Deploying Speech-to-Speech on Hugging Face にまとまっているため、本番運用に向けた次のステップとしてはこの記事が起点になります。

まとめ

speech-to-speech は、Hugging Face が公式に公開している音声AI対話OSSで、Apache-2.0 ライセンス・約 6,000 スター・Reachy Mini でのプロダクション採用実績を持つアクティブなプロジェクトです。設計の要点は次の三点に集約できます。

• VAD → STT → LLM → TTS の 4 段を CLI フラグで差し替え可能な、Hub モデル最適化のモジュラーパイプライン
• OpenAI Realtime プロトコル互換の WebSocket API を対外インターフェースとする API 互換志向
• OpenAI・HF Inference Providers・OpenRouter・vLLM・llama.cpp と幅広い LLM バックエンドをカバーし、クラウドから完全ローカルまでシームレスに移行できる構成

音声エージェントOSS比較の観点では、Pipecat が「多層プロバイダ抽象」、LiveKit Agents が「WebRTC・マルチ参加者ネイティブ」というポジションを取っており、speech-to-speech は「Hub モデル中心＋Realtime API 互換」のニッチで差別化しています。判断の一次的な軸は「WebRTC マルチ参加者が必須か」「多層プロバイダ切替が主要件か」「Hub モデル中心の運用に踏み込むか」の三点で、この軸に沿って選び分けると迷いが減ります。

読了後の次のアクションとしては、まず huggingface/speech-to-speech の README と Realtime Engine の実装 README を再度確認し、想定するトランスポート・LLM 接続先・モデル選択が README の記載範囲でカバーできるかを照合するのが効率的です。そのうえでプロダクション運用を見据える場合は、Hugging Face 公式の Deploying Speech-to-Speech on Hugging Face と Reachy Mini goes fully local が具体的な構成例として参考になります。