OpenTalking とは？AI デジタルヒューマン対話を動かすためのオープンソースフレームワーク

OpenTalking は、datascale-ai が公開しているリアルタイムデジタルヒューマン対話のオーケストレーションフレームワークだ。解決しようとしているのは、「1枚の画像に口の動きを付ける」だけの単発問題ではない。デジタルヒューマン対話プロダクトでよく必要になる、フロントエンド操作、セッション状態、LLM 応答、TTS と音色選択、STT、字幕イベント、割り込み制御、WebRTC による音声・映像再生、そしてローカルまたはリモートの合成バックエンドをつなぐことが目的だ。

そのため OpenTalking は、特定のデジタルヒューマンモデルの起動スクリプトとして見るより、デジタルヒューマン制作ラインのためのエンジニアリング骨格として見るほうが近い。モデルは差し替えられる。音声サービスも差し替えられる。推論バックエンドはローカルでもリモートでもよい。フロントエンドは、キャラクター、音色、モデル接続状態、リアルタイム対話体験をひとつにまとめる。

何に向いているか

OpenTalking は主に3種類のニーズに向いている。

1つ目は、デジタルヒューマン対話プロダクトの素早い検証だ。プロジェクトには mock モードがあり、最初からモデル重みをダウンロードしたり、映像推論バックエンドを立てたりする必要がない。それでも API、LLM、TTS、STT、WebRTC、ブラウザ再生の一連の流れを確認できる。画面は静的なモックフレームだが、対話、字幕、ストリーミング TTS、伝送経路は先に検証できる。

2つ目は、コンシューマー向け GPU での単一マシンリアルタイムレンダリングだ。ローカルバックエンド経由で quicktalk、wav2lip、musetalk などのモデルを接続でき、3090 / 4090 クラスのマシンで実映像レンダリング、リップシンク、カスタムアバター検証を行う用途に向いている。

3つ目は、高品質またはプライベートデプロイだ。画質、複数 GPU、リモート GPU/NPU、production 隔離が必要な場合は、OmniRT 経由で flashtalk、flashhead などの高品質モデルを接続し、オーケストレーション層と推論層を分離して配置できる。

WebUI の価値

OpenTalking は、デジタルヒューマン対話の流れを管理する Web サービス画面を提供する。画面上でデジタル人物を選択または作成し、音色、LLM、TTS、STT、デジタルヒューマン駆動モデルを設定し、モデル接続状態を確認できる。同じページでリアルタイム対話、字幕、音声・映像再生も検証できる。

これはエンジニアリング上かなり重要だ。多くのデジタルヒューマン demo は「モデルが動くか」だけを見せる。しかしプロダクト化しようとすると、すぐ次のような問題にぶつかる。

キャラクター資産をどう管理するか；
音色と TTS provider をどう切り替えるか；
LLM、STT、TTS の key と base URL をどう設定するか；
モデルバックエンドはオンラインか；
初回フレーム遅延、割り込み、字幕、音声映像同期をどう観察するか；
一般ユーザーがブラウザでどうテストするか。エンジニアだけがログを見る形では足りない。

OpenTalking の WebUI は、こうした入口をまとめることで、モデル demo からプロダクトプロトタイプへ進むときの摩擦を減らす。

クイックスタートの流れ

初めて触る場合は、まず Mock モードで全体の流れを通すのがおすすめだ。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


export DIGITAL_HUMAN_HOME=/opt/digital_human
mkdir -p "$DIGITAL_HUMAN_HOME"

cd "$DIGITAL_HUMAN_HOME"
git clone https://github.com/datascale-ai/opentalking.git && cd opentalking

export UV_DEFAULT_INDEX=https://pypi.tuna.tsinghua.edu.cn/simple
uv sync --extra dev --python 3.11
source .venv/bin/activate
cp .env.example .env

環境要件は Python 3.10+（3.11 推奨）、Node.js 18+、FFmpeg。.env には少なくとも LLM / TTS 関連項目を設定する。edge TTS を使う場合、key は不要だ。

Mock モードを起動する。

1
2


cd "$DIGITAL_HUMAN_HOME/opentalking"
bash scripts/start_unified.sh --mock

デフォルトのフロントエンド URL は次の通り。

1

http://localhost:5173

ポートを変える場合は明示的に指定する。

1

bash scripts/start_unified.sh --mock --api-port 8210 --web-port 5280

この段階の目的は画面品質ではない。ブラウザ、API、LLM、TTS、STT、字幕イベント、WebRTC 伝送がつながることを確認することだ。全体の流れが通ってから、モデル重みのダウンロードや推論バックエンドのデプロイを決めればよい。

よく使う起動パラメータ

プロジェクトでは scripts/start_unified.sh を統一入口として使うことが推奨されている。よく使う引数は用途で見るとわかりやすい。

--mock：内蔵 Mock を使う。モデル重みや映像推論バックエンドは不要；
--backend <mock|local|omnirt|direct_ws>：推論バックエンドを指定する；
--model <name>：使用するモデルを指定する。例：quicktalk；
--omnirt <url>：OmniRT 推論サービスに接続する；
--api-port <port>：OpenTalking バックエンドのポートを指定する；
--web-port <port>：WebUI のポートを指定する；
--host <host>：WebUI の待ち受けアドレスを指定する；
--env <file>：env ファイルの場所を指定する。

たとえばローカル QuickTalk ルートは次の通り。

1

bash scripts/start_unified.sh --backend local --model quicktalk

リモート OmniRT ルートは次の通り。

1
2
3
4
5
6


bash scripts/start_unified.sh \
  --backend omnirt \
  --model flashtalk \
  --api-port 8210 \
  --web-port 5280 \
  --omnirt http://<gpu-server>:9000

4つのデプロイルートをどう選ぶか

OpenTalking の README はデプロイルートをかなり明確に分けている。実用上は、まず本物の映像レンダリングが必要かを考え、次に推論を Web サービスと同じマシンに置くかを考えるとよい。

単に全体の流れを検証したいだけなら mock を使う。GPU もモデル重みも不要で、初日にシステムを起動する用途に向いている。

コンシューマー向け GPU があり、単一マシンで本物のデジタルヒューマンのリアルタイムレンダリングをしたいなら、quicktalk から始めるとよい。プロジェクトが示す目安は 3090 / 4090 クラスのマシンで、カスタムアバターとリアルタイム映像効果の検証に向いている。

軽めのリップシンクとカスタムアバター検証だけでよい場合は、wav2lip を見るとよい。デプロイ負荷が比較的低く、軽量ルートとして使いやすい。

完全ローカルのプライベート音声チェーンにしたい場合は、sensevoice、local_cosyvoice、quicktalk を組み合わせ、STT と TTS もローカルモデルに切り替える。このルートは重いが、クラウド音声サービスに依存したくない場面に合う。

高品質映像、複数 GPU、production 隔離が必要な場合は、推論層をリモートに置き、OmniRT 経由で flashtalk または flashhead を接続する。この場合、OpenTalking はセッション、フロントエンド、サービス設定、推論 endpoint 呼び出しを担当するオーケストレーション層に近い。

モデル対応とリソース感

現在のモデルルートは、おおよそ次のように見られる。

mock：静的フレームのプレースホルダー。GPU 不要；
quicktalk：template video + audio。ローカル CUDA GPU、3090 / 4090 推奨；
wav2lip：参照画像または frames + audio。local または omnirt 向き；
musetalk：full frames + audio。VRAM 要求はより高い；
soulx-flashtalk-14b：portrait + audio。OmniRT 経由で複数 GPU / NPU にデプロイする用途向き；
soulx-flashhead-1.3b：portrait + audio。同じく高品質リモート推論寄り。

README にはコンシューマー GPU の参考値もある。quicktalk を RTX 3090 で template video + audio 入力として使う場合、出力は 720x900 / 25fps、VRAM 使用量は約 3.8 GiB、生成スループットは約 35 fps とされている。この数値はデプロイ前の大まかな目安になるが、実際の体験は初回フレーム構築、キャッシュ、解像度、音声モデル、マシン環境にも左右される。

設定で注意すること

OpenTalking は設定項目が多い。特に LLM、STT、TTS は単一の fallback key を共有しない。同じ DashScope key を使う場合でも、対応する環境変数へそれぞれ書く必要がある。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


OPENTALKING_LLM_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
OPENTALKING_LLM_API_KEY=sk-your-key
OPENTALKING_LLM_MODEL=qwen-flash

OPENTALKING_STT_DEFAULT_PROVIDER=dashscope
OPENTALKING_STT_DASHSCOPE_MODEL=paraformer-realtime-v2
OPENTALKING_STT_DASHSCOPE_API_KEY=sk-your-key

OPENTALKING_TTS_DASHSCOPE_API_KEY=sk-your-key
OPENTALKING_TTS_DEFAULT_PROVIDER=edge
OPENTALKING_TTS_EDGE_VOICE=zh-CN-XiaoxiaoNeural

この設定方式は少し煩雑に見えるが、境界が明確になる。LLM、音声認識、音声合成、音色クローンをそれぞれ別 provider に差し替えられ、すべての機能をひとつのサービスに固定しなくてよい。

エンジニアリング構造

OpenTalking のコード構造にも、その位置づけが表れている。中核のオーケストレーション層は opentalking/ にあり、プロトコル、provider、モデルアダプタ、avatar、voice、media、pipeline、runtime を含む。apps/ には FastAPI サービス、統一起動モード、React フロントエンド、CLI がある。configs/ には YAML 設定、docker/ と docker-compose.yml はコンテナデプロイ、scripts/ は統一起動と quickstart、docs/ はモデル、デプロイ、設定ドキュメントを補う。

この構造は、プロジェクトが単一モデルリポジトリではないことを示している。フロントエンド、バックエンド、モデル推論、音声、資産、ランタイムというデジタルヒューマン製品チェーンの各境界を分けようとしている。

誰が注目すべきか

OpenTalking は次のような人に向いている。

リアルタイムデジタルヒューマン対話プロダクトのプロトタイプを作りたい；
LLM、TTS、STT、WebRTC、デジタルヒューマンモデルをひとつの流れにつなぎたい；
まず Mock でシステムを検証し、その後に本物のモデルへ段階的に差し替えたい；
コンシューマー GPU があり、QuickTalk / Wav2Lip / MuseTalk をローカルで動かしたい；
プライベートデプロイやリモート複数 GPU 推論が必要で、推論と Web オーケストレーションを分けたい；
WebUI でデジタル人物、音色、モデル、対話検証を管理したい。

一方、「ワンクリックでデジタルヒューマン動画を生成したい」だけのユーザーにはあまり向かない。OpenTalking はよりエンジニアリングフレームワーク寄りで、うまく使うにはモデル重み、音声サービス、推論バックエンド、ポート、環境変数、ブラウザのリアルタイム伝送を理解する必要がある。

OpenTalking と LongCat-Video の選び方

最近のオープンソースのデジタルヒューマンプロジェクトでは、OpenTalking と LongCat-Video-Avatar-1.5 のどちらも注目に値する。ただし、この2つは同じ種類のプロジェクトではない。

ひと言で言うと、OpenTalking は「デジタルヒューマン対話システムのエンジニアリングフレームワーク」に近く、リアルタイム対話、業務編成、サービス連携が中心だ。LongCat-Video、特に LongCat-Video-Avatar ブランチは、「デジタルヒューマン動画生成の基盤モデル」に近く、長尺動画、画質、リップシンク、人物の動きが中心になる。

AI カスタマーサポート、バーチャル配信、AI コンパニオン、リアルタイム Q&A を作るなら、まず OpenTalking を見るとよい。高品質なデジタルヒューマン動画、音声駆動キャラクターアニメーション、長尺動画の継続生成、プリレンダーコンテンツを作るなら、LongCat-Video-Avatar を優先して見るとよい。

中核の位置づけが違う

OpenTalking は、産業向けのオープンソースリアルタイムデジタルヒューマン対話フレームワークとして位置づけられている。関心は、デジタルヒューマン製品をどう動かすかにある。フロントエンド UI、LLM 応答、TTS 音声合成、STT 音声認識、WebRTC 配信、字幕イベント、割り込み制御、キャラクター資産、デジタルヒューマン駆動モデルをどう接続するか、という問題だ。

そのため OpenTalking 自体は、底層の動画生成モデルではない。Wav2Lip、MuseTalk、QuickTalk、FlashTalk などのモデルを接続できるスケジューラ兼オーケストレーション層に近い。推論はローカルでもリモートでもよい。

LongCat-Video は、美団 LongCat チームが公開したマルチモーダル動画生成基盤モデルだ。LongCat-Video-Avatar-1.5 は音声駆動デジタルヒューマン動画生成によりフォーカスし、テキストから動画、画像から動画、音声駆動キャラクターアニメーション、単一人物および複数人物の音声入力に対応する。

つまり OpenTalking が解くのは「製品チェーンをどう編成するか」であり、LongCat-Video-Avatar が解くのは「動画と人物の動きをどう自然に生成するか」だ。

リップシンクと画質

OpenTalking のリップシンクと画質は、主にどのモデルを接続するかに依存する。

Wav2Lip を接続する場合、軽量で成熟しており、リップシンクのルートが明確という利点がある。一方、画質や自然さはモデル能力に制約される。MuseTalk や QuickTalk を接続すれば、コンシューマー GPU 上でより完整なデジタルヒューマン検証ができる。FlashTalk を接続すれば画質はさらに上がるが、デプロイと GPU 要件も高くなる。

LongCat-Video-Avatar-1.5 は、モデルそのものが中心だ。音声駆動、口元の自然さ、同一人物性、長尺動画の安定性、人物の動きに重点を置く。プロジェクト資料では、音声エンコーダとして Whisper-Large-v3 を導入していること、単一人物・複数人物の音声駆動動画生成に注目していることが示されている。

したがって「画質」で単純比較するのは注意が必要だ。OpenTalking 自体は画質モデルではなく、上限は外部モデルに依存する。LongCat-Video-Avatar の強みは、底層の生成モデルそのものにある。

リアルタイム対話と長尺動画生成

OpenTalking はもともとリアルタイム対話寄りだ。WebUI を提供し、WebRTC の音声・映像再生に対応し、LLM、TTS、STT、デジタルヒューマン駆動モデルをリアルタイム対話チェーンとして接続する。この設計は低遅延の場面に向いている。

AI カスタマーサポート；
バーチャルキャスター；
デジタルヒューマンのライブ対話；
AI コンパニオン；
企業内デジタルヒューマンアシスタント；
話しながら再生する必要があるリアルタイムデモ。

LongCat-Video-Avatar は、動画コンテンツ制作とプリレンダー寄りだ。長尺動画の継続生成、キャラクターの同一性、安定したリップシンク、身体の動き、高品質な画面に重点を置く。より向いているのは次のような用途だ。

口播動画生成；
デジタルヒューマンの短編・長編動画；
音声駆動キャラクターアニメーション；
複数人物のインタラクション動画生成；
先に生成してから公開するコンテンツ制作フロー。

簡単に言えば、OpenTalking は「オンライン対話システム」に近く、LongCat-Video-Avatar は「動画生成モデル」に近い。

ハードウェアとデプロイのハードル

OpenTalking はデプロイの柔軟性が高い。まず mock モードで全体の流れを通し、モデル重みのダウンロードや動画推論バックエンドのデプロイを後回しにできる。API、LLM、TTS、STT、WebRTC が通ったら、GPU と用途に応じて quicktalk、wav2lip、またはリモート OmniRT 推論サービスを接続すればよい。

これは実装面で扱いやすい。段階的に検証できるからだ。

まず対話チェーンが動くことを確認する；
次に軽量なデジタルヒューマンモデルを接続する；
最後に高品質な推論バックエンドへ切り替える。

LongCat-Video-Avatar は重量級の基盤モデル路線だ。モデル規模、推論チェーン、VRAM 要件はより高い。通常は複数 GPU 環境、または xFormers、FlashAttention、CacheDiT、蒸留推論、INT8 量子化などを組み合わせて推論負荷を下げる使い方に向いている。

デジタルヒューマンの業務フローを素早く検証したいだけなら、OpenTalking のほうが始めやすい。最終的な動画品質と長尺動画の安定性を重視するなら、LongCat-Video-Avatar に計算資源を投じる価値が高い。

比較表

比較項目	OpenTalking	LongCat-Video-Avatar
プロジェクトの本質	リアルタイムデジタルヒューマン対話チェーンのオーケストレーションフレームワーク	音声駆動デジタルヒューマン動画生成の基盤モデル
重点能力	LLM、TTS、STT、WebRTC、WebUI、モデルバックエンド連携	T2V、I2V、Audio-to-Video、長尺動画継続
リアルタイム対話	強い。WebRTC とストリーミング対話に向く	弱い。オフライン生成とプリレンダー寄り
リップシンク	接続する `Wav2Lip`、`MuseTalk`、`QuickTalk`、`FlashTalk` などに依存	モデル自体が口型、音声駆動、人物動作を重点最適化
画質	外部モデルと推論バックエンドに依存	高品質動画生成寄り
長尺動画能力	主な売りではない	長尺動画の安定性と同一性を重視
デプロイ方式	`mock` からローカル GPU、リモート OmniRT まで段階的	モデル重み、複数 GPU、推論最適化への依存が大きい
向く場面	リアルタイム客服、ライブ対話、AI コンパニオン、デジタルヒューマン助手	デジタルヒューマン口播、長尺動画制作、音声駆動キャラクターアニメーション
導入ハードル	低くも高くもでき、段階検証しやすい	比較的高く、VRAM と推論環境を要求する

どう選ぶか

目的が「デジタルヒューマンがユーザーとリアルタイムに話せるようにする」ことなら、OpenTalking を選ぶ。製品チェーンに関心があり、LLM、音声、字幕、WebRTC、デジタルヒューマンモデルを接続した対話システムを作るのに向いている。

目的が「より高品質で安定したデジタルヒューマン動画を生成する」ことなら、LongCat-Video-Avatar を見る。底層の生成品質に重点があり、動画コンテンツ制作と音声駆動アニメーションに向いている。

完全なデジタルヒューマン製品を作る場合、両者は必ずしも排他的ではない。OpenTalking を対話と業務編成の層として使い、LongCat-Video-Avatar のようなモデルを高品質動画生成やプリレンダー機能の一部として使うこともできる。ただし、重いモデルをリアルタイムチェーンへ直接入れる場合、遅延と計算コストが主な問題になる。

まとめ

OpenTalking の価値は、リアルタイムデジタルヒューマン対話を、段階的に差し替え、段階的にデプロイできるエンジニアリングチェーンへ分解している点にある。mock から始めて API、LLM、TTS、STT、WebRTC だけを検証できる。ローカル quicktalk に切り替えて本物の映像レンダリングもできる。さらに高品質または production 向けには、OmniRT 経由で推論をリモート GPU / NPU に置ける。

デジタルヒューマンアプリ、ライブ配信インタラクション、バーチャルキャスター、コンパニオン製品、企業内プライベート検証に取り組んでいるなら、OpenTalking は調べる価値がある。敷居は低くないが、demo からデプロイ可能なシステムへ進む途中で崩れやすいエンジニアリング層を扱っている。

参考：datascale-ai/opentalking GitHub リポジトリ、OpenTalking ドキュメントサイト