Pipecatとは？LiveKit Agents・TEN Frameworkと比較する音声AIエージェントOSSの選び方

音声で対話するAIを作ろうとすると、候補のOSSが一気に増えて選べなくなります。Pipecat、LiveKit Agents、TEN Framework、OpenAvatarChat、MuseTalk——名前が並列に見えるのに、実際に触ると担当している範囲がまったく違う。整理の鍵は、「会話オーケストレーション層」「アバター描画層」「ドメインロジック層」の3層に分けることです。既存OSSはたいていどれか1層に特化しているので、丸ごと1本で済ませようとすると必ずどこかで詰みます。この記事では各層の代表的なOSSをGitHub APIで実測しながら整理し、表記がApache-2.0でも追加条件が付くというライセンスの実態まで確認します。エージェント全般の枠組みの選び方はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証を参照してください。

音声AIエージェントは3層に分けて選ぶ——1本のOSSで全部は賄えない

「AIと声で会話する」を実現するために必要な仕事を分解すると、性質のまったく違う3種類が出てきます。

この3つを1本のOSSで賄おうとすると何が起きるか。改善サイクルが止まります。 たとえばアバターの描画を会話ループに密結合させると、ターン終了検知のアルゴリズムを差し替えるだけで描画側の修正が必要になる。逆にアバターを差し替えたいだけなのに会話ループを触ることになる。

実際、この分離は業界側でも起きています。後述する OpenAvatarChat がバージョン0.6.0（2026-04-17）でフロントエンドとバックエンドを分離するアーキテクチャ刷新を行ったのは、同じ動機と読めます。

会話オーケストレーション層——Pipecat・LiveKit Agents・TEN Frameworkの違い

①の層が本体です。ここを間違えると後から取り返しがつきません。実測した3つの主要OSSを並べます。

3つとも最終pushが同じ日（2026-08-27）で、いずれも活発に開発されています。規模でも更新頻度でも決定的な差は付きません。 選定軸は別のところにあります。

Pipecat——transportを差し替えられるパイプライン抽象

Pipecatは、READMEの表現で「リアルタイム音声・マルチモーダル対話エージェントを構築するオープンソースのPythonフレームワーク」です。特徴はフレームプロセッサをつないでパイプラインを組むモデルで、音声・映像・AIサービス・transportを同じ抽象の上で扱います。

実務上効くのは transport非依存であることです。READMEに挙がっているtransportは Daily（WebRTC）、FastAPI WebSocket、LiveKit（WebRTC）、SmallWebRTCTransport、Vonage（WebRTC）、WebSocket Server、WhatsApp、Local。つまり同じエージェント実装のまま、ブラウザ越しの会話も電話回線もWhatsAppも通せる設計です。

ここで気づいてほしいのは、「PipecatかLiveKitか」という二者択一が実は成立しないことです。PipecatのtransportにLiveKitが含まれている以上、LiveKitのインフラの上でPipecatのパイプラインを動かす構成が普通に取れます。層が違うものを並べて比較していた、という整理になります。

v1.0.0のリリースは 2026-04-14 で、実測時点の最新は v1.8.1（2026-08-27）。約4か月半で1.0→1.8と、メジャー安定版到達後も速いペースで進んでいます。

LiveKit Agents——エージェントが「参加者」としてルームに入る

LiveKit Agentsの設計思想はREADMEの一文に集約されています——「realtime, programmable participants（リアルタイムでプログラマブルな参加者）」を作るためのフレームワーク。エージェントがWebRTCのルームに参加者として入るモデルです。

この設計が効くのは、会話が2者で閉じない場面です。候補者とAI、そこに人事担当者が同席する。画面共有をしながら話す。録画を残す。こうした要件は「参加者」モデルなら追加の参加者を増やすだけで済みますが、1対1の音声ストリームを前提に組んだ実装では後付けが重くなります。セッション状態・再接続・低遅延といった面倒もRTC層から降ってきます。

READMEに明記されている機能のうち実務で効くのは2つです。セマンティックなターン終了検知（transformerモデルでユーザーの発話が終わったかを判定し、割り込みを減らす）と、テレフォニー統合（LiveKitのSIPスタック経由で電話の発着信ができる）。

TEN Framework——VAD・ターン検知を独立コンポーネントとして持つ

TEN Framework（開発元はAgora）は、リアルタイムマルチモーダル対話のためのフレームワークです。特徴はエコシステムを構成要素ごとに切り出していること。README上では TEN Framework 本体のほかに、TEN VAD（低遅延・軽量なストリーミング音声区間検出）と TEN Turn Detection（全二重の対話を可能にするターン検知）が独立したリポジトリとして並んでいます。

アバター連携の設計サンプルとしても読む価値があります。READMEの「Lip Sync Avatars」の項には、MotionSyncによるリップシンクを持つアニメキャラクター（Kei）に加えて、Trulience・HeyGen・Tavus といった実写系ベンダーに対応すると書かれています。①の層のフレームワークが②の層をどう抽象化しているかの実例です。

ただし、TEN Frameworkにはライセンス上の重い制約があります。次節で扱います。

ライセンスの実態は3者3様——PipecatのBSD-2とApache-2.0の追加条件

GitHubのライセンスバッジだけを見て選ぶと事故ります。3つの LICENSE ファイルを実際に読み比べると、制約の強さがまったく違いました。

TEN Frameworkの条件①は、用途によっては致命的です。 「エンドユーザーの端末上でホストしない」という条件は、後述する Duix-Mobile のような端末内デプロイの発想と真っ向から衝突します。会場に設置した端末の中だけで完結させたい、ネットワーク非依存で動かしたい——そうした要件がある場合、TEN Frameworkは検討対象から外れます。GitHubのライセンス欄が NOASSERTION と表示されるのはこの追加条件のためで、「ライセンス情報が無い」のではなく「標準ライセンスに当てはまらない」という意味です。

LiveKitのモデル分離も見落としやすい点です。 セマンティックなターン検知はLiveKit Agentsの売りの一つですが、そのモデルはApache-2.0ではありません。「LiveKit Agentsから離れられなくなる部品」として扱う必要があります。Pipecat側にも pipecat-ai/smart-turn という独自のターン検知モデルの系譜があり、この領域は各社が囲い込みにかかっている、と読むのが妥当です。

なお本記事はライセンス文書の記載内容を整理したものであり、法的な解釈や助言ではありません。商用導入にあたっては最終判断を法務担当者・専門家に確認してください。

アバター描画層——実写系と3Dキャラ系はまったく別物

②の層は、実写系と3Dキャラ系で技術も適性も分かれます。

OpenAvatarChat は、VAD・ASR・LLM・TTS・アバターアニメーションを1台のPCで完結させるモジュラー構成です。READMEの記載では、LiteAvatar / LAM / MuseTalk / FlashHead といったアバター実装を差し替えられ、「低遅延最適化により平均応答時間はわずか2.2秒」（公称）とされています。0.6.0ではアーキテクチャを刷新してフロントエンドとバックエンドを分離し、フロントエンドは別リポジトリ（OpenAvatarChat-WebUI）に切り出されました。あわせてすべてのデジタルヒューマンで手動割り込みと双工（双方向）割り込みモードに対応したことも記載されています。ライセンスはApache-2.0で、追加条件はありません。アーキテクチャの教科書として読む価値が最も高いのはこれです。

ただし注意点があります。0.5.1（2025-08-21）から0.6.0（2026-04-17）まで8か月の間隔が空いており、実測時点でも最新リリースは0.6.0のままです（最終pushは2026-07-31）。

MuseTalk は口の動きを音声に合わせるモデル単体で、会話ループもUIも持ちません。「V100で30fps以上」（公称）という数字が有名ですが、リポジトリの最終pushは2025-09-26、GitHub Releasesは1本もありません。 実測時点で約11か月更新が止まっており、★6,464という規模に反して新規採用の第一候補にはしにくい状態です。star数はメンテナンス状況を示しません。

Duix-Mobile は端末内デプロイを前提としたアバターSDKで、LLM/ASR/TTSは自前のものを差す設計です。ここで数値の読み方に注意が要ります。リポジトリの説明文は「<1.5 s latency」、README本文は「120ms以下（Snapdragon 8 Gen 2 で測定）」と、同じプロジェクト内で1桁違う数字が並んでいます。測定している区間が違う（アバター描画の応答か、発話までのエンドツーエンドか）と考えるのが自然です。本記事はこれを実機で検証していません。 比較検討では数字そのものより「何から何までの時間か」を各ドキュメントで確認してください。

AITuberKit は3Dキャラ系（VRM / Live2D）で、日本語音声合成の選択肢の広さが強みです。ただしv2.0.0以降は商用利用に別途ライセンス購入が必要な独自ライセンスで、他の3つとは前提が異なります。詳細はAITuberKitとは？MITではない商用ライセンス料金と開発停止・再開の実測、対応LLM15種を解説にまとめました。

GPU設計の落とし穴として押さえておきたいのは、「人物を新たに生成するのか、既にある人物の映像を動かすだけか」で必要なGPUが激変するという点です。リップシンクだけならH100級は不要で、MuseTalkが公称の基準に置いているのも1世代前のV100です。逆に人物そのものを生成する構成にすると要求が跳ね上がります。ここは選定の早い段階で決めておくべき分岐点です。

ドメインロジック層——DeepInterviewとflo-interviewerの実態

③の層は、業務要件そのものなので汎用OSSが育ちにくい領域です。参考実装として名前が挙がる2つを実測しました。

まず率直に書くと、どちらも「実績あるプロダクト」として推せる規模ではありません。 DeepInterviewは★26、flo-interviewerは★4で最終pushから約11か月経過しています。参考にするなら「設計の読み物」としてであって、そのまま業務に載せる想定では見ないほうがよいです。

そのうえでDeepInterviewは設計の参考としては有用です。ただし用途を取り違えないこと——リポジトリ説明文にある通り、これは候補者が自分で模擬面接を練習するツール（CVと求人票をアップロードし、声に出して練習し、弱点を採点・コーチングしてもらう）であって、採用側が候補者を評価するための業務システムではありません。

構成はLiveKit＋LangGraph＋Next.jsで、READMEに書かれている要素は次の通りです。

・カスケード型の STT→LLM→TTS ループをLiveKit上で回し、バージイン・セマンティックなターン終了検知・適応的な追加質問に対応
・LangGraphのパイプラインがCVと求人票を読み、対象企業を調べ、ギャップを差分化。Question Plannerが質問計画・難易度カーブ・評価基準・追加質問を事前計算する
・各段が環境変数1つで差し替え可能（STT_PROVIDER / TTS_PROVIDER / LLM_PROVIDER）。キー未設定時はオフラインのモックアダプタに落ちる

v0.3.0（2026-08-02）で完全ローカル経路が入りました。LLM_PROVIDER=ollama / STT_PROVIDER=whisper / TTS_PROVIDER=kokoro を設定すればモデル用のAPIキーは一切不要になります。ただしREADME自身が2つの正直な但し書きを置いています——LiveKitは依然としてリアルタイムtransportとして必要（完全オフラインにするなら livekit-server --dev を併用する）、そしてローカルモデルでのターンレイテンシはベンチマークを取っていない、音声は当面英語のみ。README冒頭でも自らを「early open build」と位置づけています。

質問の分岐や深掘りを状態遷移として設計する部分は、LangGraph入門｜とは？状態遷移でマルチエージェントを作る基本とLangChainとの違い・比較で扱っているような枠組みがそのまま使えます。DeepInterviewがLangGraphを採用しているのも同じ発想です。

採用・評価に使うなら、記録のスキーマを先に切る

面接や評価に関わるシステムを日本国内で運用する場合、参照すべき条文の一つが職業安定法 第五条の五（求職者等の個人情報の取扱い）です。e-Gov法令検索で取得した条文（昭和二十二年法律第百四十一号、2026年4月1日施行の版）には、次のように書かれています。

第1項：公共職業安定所、特定地方公共団体、職業紹介事業者及び求人者（中略）は、それぞれ、その業務に関し、求職者（中略）の個人情報（中略）を収集し、保管し、又は使用するに当たつては、その業務の目的の達成に必要な範囲内で、厚生労働省令で定めるところにより、当該目的を明らかにして求職者等の個人情報を収集し、並びに当該収集の目的の範囲内でこれを保管し、及び使用しなければならない。ただし、本人の同意がある場合その他正当な事由がある場合は、この限りでない。

第2項：公共職業安定所等は、求職者等の個人情報を適正に管理するために必要な措置を講じなければならない。

条文の名宛人に「求人者」——つまり採用する企業自身が含まれている点、そして義務が「①目的を明らかにして収集する ②収集目的の範囲内で保管・使用する ③適正管理の措置を講じる」という形で書かれている点が、システム設計に直接効きます。

技術的に読み替えると、何を目的に収集したのかと、その目的に紐づく記録を後から示せる形にしておく必要があるということです。会話エンジンを選んだあとにこれを後付けするのは難しいので、トランスクリプト・評価根拠・収集目的を紐づけて永続化する前提でスキーマを先に切っておくのが安全です。層で言えば③のドメインロジック層の仕事であって、Pipecat も LiveKit Agents もここは提供しません。

現実的な組み合わせと、着手前に確認すること

3層の整理を踏まえた現実解はシンプルです。

①の層（LiveKit Agents または Pipecat）を軸に据え、②のアバターは差し替え可能なプラグインとして扱う。③のドメインロジックは LangGraph 等で外に出す。

理由は、品質を決めるのがアバターの見た目ではなく、割り込み・沈黙の扱い・ターン終了検知・トランスクリプトと評価の紐付けだからです。アバターを会話ループに密結合させると、この一番効く部分の改善サイクルが止まります。OpenAvatarChatが0.6.0でフロントとバックを分離したのも、同じ問題に対する回答と読めます。

判断フローを言葉にすると次の順です。

1. 端末内で完結させる必要があるか。 あるならTEN Frameworkは選べません（ライセンスの追加条件）。この制約は技術的な向き不向きではなく契約の問題なので、最初に潰しておきます。

2. 会話が2者で閉じるか。 候補者＋AI＋人事担当のような3者以上、あるいは映像・画面共有が絡むならLiveKit Agentsの参加者モデルが素直です。

3. transportを後から変える可能性があるか。 ブラウザから始めて後で電話やWhatsAppに広げるなら、Pipecatのtransport非依存が効きます。

4. ライセンスの素直さを重視するか。 BSD-2で追加条件のないPipecatが最も制約が軽く、次点がApache-2.0のLiveKit Agents（ただしターン検知モデルは別ライセンス）です。

着手前に確認しておくこと

・公称値の測定区間を確認する。 「120ms」「2.2秒」「30fps」はいずれも各リポジトリの公称値で、測っている区間の定義が揃っていません。自分の要件に照らして意味のある数字かを、各ドキュメントで確認してから比較する
・star数を現役の指標にしない。 MuseTalkは★6,464でありながら約11か月更新なし・リリース0本。最終pushとリリース履歴を個別に見る
・GitHubのライセンスバッジで判断しない。 NOASSERTION は「情報が無い」ではなく「標準ライセンスに当てはまらない」。LICENSE ファイルの現物を読む
・GPU要件を早く決める。 人物を生成するのか既存映像を動かすだけかで必要なリソースが激変する
・記録のスキーマを先に切る。 トランスクリプトと評価根拠の紐付けは後付けが難しい。会話エンジンを選ぶ前に、何を残すかを決めておく

参照ソース

・pipecat-ai/pipecat — GitHubリポジトリ（README・Releases・ライセンス。★数/最終push/リリース日は2026-08-28にGitHub REST APIで取得）
・livekit/agents — GitHubリポジトリ（README・LICENSE）／MODEL_LICENSE の原文
・TEN-framework/ten-framework — GitHubリポジトリ／LICENSE の原文（追加条件1〜5）
・HumanAIGC-Engineering/OpenAvatarChat・TMElyralab/MuseTalk・duixcom/Duix-Mobile（アバター層の★数・最終push・公称性能値の出典）
・ngoanpv/DeepInterview（README・Releases。v0.3.0のローカル経路構成と但し書きの出典）
・職業安定法（昭和二十二年法律第百四十一号）— e-Gov法令検索（第五条の五の条文。2026年4月1日施行の版をe-Gov法令APIで取得）