# MuseTalk 完全ガイド：リアルタイム・リップシンク（潜在空間インペインティング）を公式準拠で本番運用する

> Tencent系のリアルタイム・リップシンクモデル MuseTalk を公式（GitHub・arXiv 2410.10122・HuggingFace）に忠実に解説。拡散を使わない単一ステップ潜在空間インペインティングの仕組み、256×256/30fps+の理由、fal.ai等のAPIとセルフホストの両手順、bbox_shiftなどのチューニング、アバター事前生成による本番リアルタイム運用までを具体コードで示します。

- 公開日: 2026-06-25
- 著者: 友田 陽大
- タグ: MuseTalk, リップシンク, リアルタイム, AI動画, デジタルヒューマン, Python, GPU, 生成AI
- URL: https://tomodahinata.com/blog/musetalk-realtime-lip-sync-production-guide

## 要点

- MuseTalkは『拡散しない』リップシンク。ft-mse-vaeの潜在空間で顔の下半分をインペイントし、Whisper音声特徴をU-Netのcross-attentionで融合、単一ステップ生成でV100で30fps+のリアルタイムを実現する
- 公式最新は1.5（2025/03/28公開）。perceptual+GAN+sync lossと二段階学習・時空間サンプリングで画質と同期を両立。論文ではHDTFでFID 6.43（Wav2Lip 11.21より良好）
- 真価は realtime_inference の『アバター事前生成＆再利用』。一度アバターを焼けば以降は音声ごとに即時生成でき、対話型デジタルヒューマン・ライブ配信に向く
- 試すだけならfal.ai/Replicate等のAPI、作り込むならセルフホスト（コードはMIT・商用可）。チューニングはbbox_shift・extra_margin・parsing_modeで制御する
- 弱点は256×256解像度・単一フレーム由来のジッタ・口髭/唇色などの同一性劣化。超解像(GFPGAN)・顔検出ゲート・同期スコアゲートで本番品質に引き上げる

---

## この記事のゴール

MuseTalk は、**音声から口の動きを生成する（リップシンク）モデル**です。リポジトリの正式名称がその思想を言い切っています——「**MuseTalk: Real-Time High Quality Lip Synchronization with Latent Space Inpainting**（潜在空間インペインティングによる、リアルタイム・高品質リップシンク）」。キーワードは2つ、**リアルタイム**と**インペインティング**です。

本稿は、その**公式ドキュメント（[GitHub](https://github.com/TMElyralab/MuseTalk) / [論文 arXiv:2410.10122](https://arxiv.org/abs/2410.10122) / [HuggingFace](https://huggingface.co/TMElyralab/MuseTalk)）の内容に厳密に基づきつつ**、公式 README には書かれていない「**どの場面で・どう使い・どこで詰まるか**」までを、実際に動くコードで埋めるものです。読み終えたときに、次の3つができる状態を目指します。

1. MuseTalk が**何をするモデルで、なぜ「拡散しないのに」高品質かつ高速なのか**を、人に説明できる。
2. **API（自前GPU不要）** と **セルフホスト** のどちらを選ぶべきか判断し、**今日中に手を動かせる**。
3. MuseTalk 最大の武器である **「アバターの事前生成＆再利用」によるリアルタイム運用**を、冪等性・回復性・可観測性まで含めて設計できる。

> **筆者について（信頼性の開示）**：私は、動画をアップロードするだけで「音声分離 → 文字起こし → 翻訳 → 多言語吹き替え → 口元同期」まで全自動化する**AI動画ローカライズ基盤を単独で設計・実装し、本番運用**しています。その第5段（リップシンク）の実装は **Wav2Lip 系 → MuseTalk → [LatentSync](/blog/latentsync-lip-sync-diffusion-model-production-guide)** と進化してきました。MuseTalk は「**速度とスループット、そしてアバター再利用が効く場面**」で今も現役です。本稿の「落とし穴」と「回復性設計」は、デモ用の知識ではなく、その実運用で踏み抜いた地雷の記録です。パイプライン全体の設計は[別記事](/blog/production-ai-video-localization-lipsync-gpu-pipeline)に、案件の概要は本稿末尾の[実績リンク](/case-studies/ai-video-localization-lipsync)にまとめています。

---

## 30秒のまとめ（結論を先に）

| 観点 | 結論 |
| --- | --- |
| **何のモデルか** | 話す人物の動画 + 任意の音声 →「**その音声を喋っているように口元を作り替えた動画**」を生成。顔領域 **256×256** を扱う |
| **何がすごいか** | **拡散モデルではない**。VAEの潜在空間で顔下半分を**単一ステップでインペイント**するため、**V100で30fps+のリアルタイム**が出る |
| **品質の根拠** | 論文（[arXiv:2410.10122](https://arxiv.org/abs/2410.10122)）でHDTFの **FID 6.43**（Wav2Lip 11.21・DI-Net 7.27 より良好）、CSIM 0.8225 |
| **最新版** | **MuseTalk 1.5**（2025/06基準で最新、**2025/03/28公開**）。perceptual + GAN + sync loss と二段階学習で同期と画質を両立 |
| **真の使いどころ** | `realtime_inference` の**アバター事前生成＆再利用**。一度アバターを焼けば、**音声ごとに即時生成**できる |
| **試すだけ** | **fal.ai / Replicate 等のサードパーティAPI**：自前GPU不要。`source_video_url` と `audio_url` を渡すだけ |
| **作り込む** | **セルフホスト**：Python 3.10 / PyTorch 2.0.1 / CUDA 11.7。**コードはMIT**で商用可 |
| **主要ノブ** | `bbox_shift`（口の開き）／`extra_margin`・`parsing_mode`・`*_cheek_width`（顔の合成境界）／`use_float16`（速度） |
| **向く用途** | 対話型デジタルヒューマン・AIアバター接客・ライブ寄り配信・**大量ドラフトの高速生成** |
| **向かない用途** | 4K級の高精細納品（256×256が上限）、口髭/唇色の厳密な同一性が要る素材、横顔・遮蔽の多い素材 |

「**まず自分の素材で動かしたい**」なら、この後すぐの [API章](#使い方a試すだけなら-apifalai--replicate自前gpu不要) に飛んでください。数分で結果が出ます。「**LatentSyncと何が違うの？**」が先に知りたい方は [使い分け章](#latentsync-との使い分け拡散-vs-単一ステップ) へ。

---

## MuseTalk は何をするモデルなのか

入力は2つ、**話している人物の動画（またはアバター映像）**と**喋らせたい音声**です。出力は1つ、**口元だけがその音声に同期するよう作り替えられた動画**です。顔の向き・表情・背景・カメラワークは元動画のまま、**顔の下半分（口元）だけ**が新しい音声に合わせて再生成されます。

MuseTalk の設計が「リアルタイム」に振り切れているため、効くのは**速度・対話性・量**が要件になる場面です。

- **対話型デジタルヒューマン / AIアバター接客**：LLMが生成した返答を TTS で音声化し、**その場で口を合わせて喋らせる**。受付・案内・カスタマーサポートのアバターに。後述の[アバター再利用](#リアルタイムの真価アバター事前生成--再利用realtime_inference)が肝。
- **ライブ寄りのバーチャルアンカー / 配信**：一度撮ったアンカー映像を**アバターとして焼き込み**、原稿音声を当てて低遅延で喋らせる。日替わりニュースや実況に。
- **パーソナライズ動画の大量生成**：1本のテンプレ映像をアバター化し、宛名・商品名を含む音声を流し込んで「○○様、こんにちは」を**一人ひとり別動画**に。事前生成済みアバターなら**音声を差し替えるだけ**で量産できる。
- **動画ローカライズのドラフト高速化**：吹替の**全カットをまず MuseTalk で速く・安く**当て、採用カットだけ高精細モデル（[LatentSync](/blog/latentsync-lip-sync-diffusion-model-production-guide)）や超解像で本生成する**二段構え**。

逆に、**4K級の精細さが要る最終納品**（256×256が物理上限）、**口髭や唇の色を厳密に保持**したいタレント映像、**横顔が長く続く・口元が手やマイクで隠れる・複数の顔が同時に映る**素材は苦手です。理由は次章の仕組みを読むと腑に落ちます。

---

## 仕組み：なぜ「拡散しない」のに高品質で速いのか（論文準拠でやさしく）

ここは公式論文（[arXiv:2410.10122](https://arxiv.org/abs/2410.10122)）と README の核心を、**正確さを保ったまま噛み砕く**章です。実装だけ知りたい人は[API章](#使い方a試すだけなら-apifalai--replicate自前gpu不要)へ飛んで構いません。ただし「なぜ落とし穴がああいう形で出るのか」「なぜこんなに速いのか」はここを理解していると一発で分かります。

### 出発点：これは「インペインティング（穴埋め）」であって拡散ではない

多くの最新リップシンク（[LatentSync](/blog/latentsync-lip-sync-diffusion-model-production-guide) など）は**拡散モデル**で、ノイズ除去を20〜50回繰り返して1フレームを作ります。品質は高いが**反復するぶん遅い**。

MuseTalk は発想が違います。README は明言します——**「UNet は stable-diffusion-v1-4 由来だが、これは拡散モデルではない（NOT a diffusion model）」**。やっていることは**潜在空間でのインペインティング（穴埋め）**です。

1. **顔の下半分をマスクで隠した画像**と、**同一人物の参照画像**を、VAE（`sd-vae-ft-mse`、凍結）で**潜在空間にエンコード**し、チャンネル方向に連結する。
2. 音声は **Whisper（tiny、凍結）** で特徴（80チャンネルの対数メルスペクトログラム由来の埋め込み）に変換する。
3. **マルチスケールの U-Net** が、視覚特徴と音声特徴を**複数の解像度で cross-attention により融合**する。
4. **拡散の反復を回さず、潜在表現から最終結果を一発でデコード**する（単一ステップ）。

「隠した口元を、音声をヒントに**1回で塗り直す**」——これが MuseTalk の本質です。反復がないからこそ、**256×256 で 30fps+（NVIDIA Tesla V100）**という**リアルタイム性能**が出ます。これがすべての出発点です。

### なぜ口がちゃんと合うのか：選択的サンプリング（SIS）

「穴埋め」を素朴にやると、モデルは楽をして**参照画像の口の形をそのままコピー**しがちで、音声を無視します。論文はこれを**選択的情報サンプリング（Selective Information Sampling, SIS）**で抑えます。学習時、参照フレームを選ぶ際に——

- **顎（chin）のランドマークのユークリッド距離**で、ターゲットと**頭の向きが近いフレーム**を選ぶ（ポーズを揃える）。
- そのうえで**内唇（inner-lip）のランドマーク**で、**口の動きが最も異なる**フレームを選ぶ（冗長な口形を排除する）。

この交差を取ることで「**ポーズは似ているが口形は違う**」参照だけが残り、モデルは**口の動きの精度に集中**できます。論文の ablation では、ポーズを揃えたサンプリングは **FID 4.39**、ランダム参照は **FID 23.95** と大差がつき、SIS が画質と同期の両立点を与えたと報告されています。

### v1.5 で何が変わったか：3つの損失と二段階学習

初代（v1.0）に対し、最新の **MuseTalk 1.5（2025/03/28公開）**は学習を強化しました。README より——

- **perceptual loss（知覚損失）＋ GAN loss ＋ sync loss** を統合し、全体性能を底上げ。
- **二段階学習（two-stage training）**と**時空間データサンプリング（spatio-temporal data sampling）**で、**画質**と**リップ同期精度**のバランスを取る。
- 学習は2段階：**Stage 1 は単一フレーム**、**Stage 2 は複数フレーム（既定16フレーム）の時間学習**。

> 📌 **学習は通常不要**：上記は学習の話で、**推論だけなら学習済みの重みを使うだけ**です（学習には 8×H20 級のGPUが要ります）。本稿は推論＝使う側に集中します。

### 数字で見る品質（論文の定量結果）

「速いのは分かった、で品質は？」に論文が答えています（**HDTF データセット**、抜粋）。

| モデル | FID↓（低いほど高画質） | CSIM↑（同一性） | LSE-C↑（同期） |
| --- | --- | --- | --- |
| Wav2Lip | 11.21 | 0.8184 | **7.46** |
| VideoRetalking | 10.93 | 0.7989 | 7.7 |
| DI-Net | 7.27 | 0.8154 | 6.17 |
| **MuseTalk** | **6.43** | **0.8225** | 6.53 |

MuseTalk は**画質（FID）でDI-Net比 11.55% 改善**、MEAD-Neutral では **FID 13.42（44.34% 改善）**を報告。一方で **LSE-C（同期スコア）は Wav2Lip(7.46) の方が高い**——ここが重要で、**「絵の自然さは MuseTalk、口の追従の強さは GAN系」**という棲み分けが数字に出ています。ユーザースタディ（5点満点）は視覚品質 3.62 / 同一性 3.55 / リップ同期 3.41。

### この設計が「落とし穴の形」を決めている

仕組みを押さえると、後述のトラブルが**必然**だと分かります。

- **256×256 が上限** → 顔が大きいアップでは精細さが足りない。論文も**超解像（GFPGAN等）併用**を推奨。
- **単一フレーム生成** → フレーム間の連続性が弱く、**ジッタ（小刻みな揺れ）**が出ることがある。論文も明記。
- **顔の下半分の合成** → 口髭・唇の色・唇形など**細部の同一性が崩れやすい**。論文も明記。
- **顔のマスク／位置合わせが前提** → 横顔・遮蔽・複数顔に弱い。

つまりパラメータ（`bbox_shift`・`extra_margin`・`parsing_mode`・`*_cheek_width`）は「気分」で回すものではなく、**この設計の延長線上で「合成境界をどう馴染ませるか」を制御するノブ**なのです。

---

## LatentSync との使い分け（拡散 vs 単一ステップ）

私は実運用で両方を使っています。**どちらが上、ではなく要件で選ぶ**のが正解です。

| 観点 | **MuseTalk** | **[LatentSync](/blog/latentsync-lip-sync-diffusion-model-production-guide)** |
| --- | --- | --- |
| 方式 | 潜在空間インペインティング（**単一ステップ**） | 音声条件付き**潜在拡散**（20〜50ステップ） |
| 速度 | **30fps+ でリアルタイム**（V100） | 1本に秒〜分（反復するため） |
| 解像度 | 256×256 | 256（1.5）／**512×512（1.6）** |
| リアルタイム | **◎（アバター再利用で即時）** | △（バッチ向き） |
| 最高画質 | ○（要超解像でアップに対応） | **◎（拡散の自然さ＋512）** |
| ライセンス | **コードMIT** | Apache-2.0 |
| 向く場面 | **対話・配信・大量ドラフト** | **高品質な吹替・主役アップ** |

実務の意思決定はこうです。

- **対話型アバター・ライブ・低遅延・大量処理**が要件 → **MuseTalk**。
- **吹替の最終品質・顔が大きいアップ**が要件 → **LatentSync 1.6**。
- **量と質を両立**したい → **MuseTalk でドラフト高速生成 → 採用カットだけ LatentSync で本生成**、の二段構え。これが私の基盤の実運用パターンです（[パイプライン記事](/blog/production-ai-video-localization-lipsync-gpu-pipeline)）。

---

## 使い方A：試すだけなら API（fal.ai / Replicate、自前GPU不要）

「品質が自分の素材で通用するか、まず確かめたい」段階では、**GPUを用意せず API で叩く**のが最短です。ただし**重要な注意**：MuseTalk の**一次配布は GitHub と HuggingFace（＝セルフホスト）**で、API ホスティングは **fal.ai や Replicate（`douwantech/musetalk` 等）のサードパーティ**が提供しています。LatentSync の Replicate のような「準公式」ではない点を理解して使ってください。

| ホスト | 入力 | 参考価格（要確認・変動） | 備考 |
| --- | --- | --- | --- |
| **fal.ai**（`fal-ai/musetalk`） | `source_video_url` / `audio_url` | 1回 約 $0.04 | per-inference 課金・最小構成 |
| **Replicate**（`douwantech/musetalk`） | `video` / `audio` 等 | 1回 約 $0.19・L40S・〜4分 | コミュニティ版 |

> 📌 **正確性のための注記**：価格・入力フィールド・デフォルトは**各サービスの最新ページで必ず確認**してください。サードパーティ版は公式リポジトリの更新やラッパー実装に依存し、本稿執筆時点と差異が出ます。本稿のコードは**構造**を示すもので、値は確認のうえ調整してください。

### TypeScript（プロトタイプ：同期実行）

fal.ai の公式クライアントが最小です。入力は**動画URLと音声URLの2つだけ**。

```ts
// scripts/musetalk-quickstart.ts
import { fal } from "@fal-ai/client";

fal.config({ credentials: process.env.FAL_KEY });

const result = await fal.subscribe("fal-ai/musetalk", {
  input: {
    // 公式デモ素材。自分のCDN/署名付きURLに差し替える
    source_video_url:
      "https://raw.githubusercontent.com/TMElyralab/MuseTalk/main/data/video/sun.mp4",
    audio_url:
      "https://raw.githubusercontent.com/TMElyralab/MuseTalk/main/data/audio/sun.wav",
  },
  logs: true,
  onQueueUpdate: (u) => {
    if (u.status === "IN_PROGRESS") u.logs.forEach((l) => console.log(l.message));
  },
});

console.log("generated video url:", result.data.video.url);
```

`subscribe()` は**完了までブロック**します。CLIや検証には便利ですが、Webアプリのリクエストハンドラで使うと**長時間のリクエスト**が立ち、タイムアウトと二重実行の温床になります。**本番は次の非同期方式**にします。

### TypeScript（本番：非同期 + 冪等性 + Webhook + 型安全）

本番品質の要件は4つ——**①ブロックしない（非同期/キュー）**、**②同じ入力で二重課金しない（冪等性）**、**③外部入力を境界で検証する（型安全・セキュリティ）**、**④Webhookを署名検証する**。Next.js の Route Handler（Node ランタイム）で実装します。

```ts
// app/api/lipsync/route.ts
import { NextResponse } from "next/server";
import { createHash } from "node:crypto";
import { fal } from "@fal-ai/client";
import { z } from "zod";

fal.config({ credentials: process.env.FAL_KEY });

// ① 外部入力は境界で必ず検証する（CLAUDE.md準拠：信頼境界はサーバー側）
const RequestSchema = z.object({
  videoUrl: z.string().url(),
  audioUrl: z.string().url(),
});
type LipSyncInput = z.infer<typeof RequestSchema>;

// ② 入力内容から決定的なキーを作る。同じ素材なら同じジョブ＝二重課金しない
function jobKey(input: LipSyncInput): string {
  return createHash("sha256").update(JSON.stringify(input)).digest("hex");
}

export async function POST(req: Request) {
  const parsed = RequestSchema.safeParse(await req.json());
  if (!parsed.success) {
    // 422: 何が不正かを返す（PIIは含めない）
    return NextResponse.json({ error: parsed.error.flatten() }, { status: 422 });
  }
  const input = parsed.data;
  const key = jobKey(input);

  // 冪等性：既存ジョブがあれば作り直さず返す（連打・リトライで二重生成しない）
  const existing = await jobStore.get(key);
  if (existing) {
    return NextResponse.json({ requestId: existing.requestId, status: existing.status, cached: true });
  }

  // ③ キューに投入。完了はWebhookで受ける（リクエストはすぐ返る）
  const { request_id } = await fal.queue.submit("fal-ai/musetalk", {
    input: { source_video_url: input.videoUrl, audio_url: input.audioUrl },
    webhookUrl: `${process.env.PUBLIC_BASE_URL}/api/lipsync/webhook`,
  });

  await jobStore.put(key, { requestId: request_id, status: "IN_QUEUE" });
  return NextResponse.json({ requestId: request_id, status: "IN_QUEUE", cached: false });
}
```

```ts
// app/api/lipsync/webhook/route.ts
import { NextResponse } from "next/server";
import { verifyFalSignature } from "@/lib/fal-webhook"; // 署名検証（各サービスの手順に従う）

export async function POST(req: Request) {
  const raw = await req.text();
  // ④ セキュリティ：Webhookは必ず署名検証する。検証なしの本文を信頼しない。
  if (!(await verifyFalSignature(req.headers, raw))) {
    return NextResponse.json({ error: "invalid signature" }, { status: 401 });
  }
  const event = JSON.parse(raw) as {
    request_id: string;
    status: "OK" | "ERROR";
    payload?: { video?: { url: string } };
  };

  if (event.status === "OK" && event.payload?.video?.url) {
    await jobStore.markDone(event.request_id, event.payload.video.url);
  } else {
    await jobStore.markFailed(event.request_id);
  }
  return NextResponse.json({ ok: true });
}
```

ポイントは、`jobStore`（Vercel KV / Upstash Redis などで十分）に **`sha256(入力)` をキーに**ジョブを記録していること。これだけで「送信ボタン連打でも1回しか走らない」「同じ動画×音声を再依頼してもキャッシュが返る」という**冪等性とコスト効率**が同時に手に入ります。LatentSync 版と**まったく同じ設計**が使える——これが「モデルではなく境界を設計する」ことの強みです。

### Python / curl

サーバーがPythonでも同形に書けます（fal.ai 公式クライアント）。

```python
# pip install fal-client
import fal_client

result = fal_client.subscribe(
    "fal-ai/musetalk",
    arguments={
        "source_video_url": "https://example.com/avatar.mp4",
        "audio_url": "https://example.com/dub_ja.wav",
    },
)
print(result["video"]["url"])  # 生成された動画のURL
```

---

## 使い方B：セルフホスト（公式手順に忠実）

リアルタイム・データプライバシー・1本あたり単価の最小化・**アバター再利用**が要件なら、**自前GPUでのセルフホスト**です。ここは公式 README の手順に**そのまま従う**のが正解で、勝手なバージョン変更は依存破壊（特に mmlab 系）の元になります。

### 1. 環境構築（公式準拠）

公式は **Python 3.10 / PyTorch 2.0.1 / CUDA 11.7** を推奨します。

```bash
# conda環境（Python 3.10）
conda create -n MuseTalk python==3.10
conda activate MuseTalk

# PyTorch 2.0.1（CUDA 11.7 ビルド）
pip install torch==2.0.1 torchvision==0.15.2 torchaudio==2.0.2 --index-url https://download.pytorch.org/whl/cu117

# 依存一式
pip install -r requirements.txt

# 顔・ポーズ系（mmlab）。バージョンを“勝手に上げない”ことが安定の鍵
pip install --no-cache-dir -U openmim
mim install "mmengine"
mim install "mmcv==2.0.1"
mim install "mmdet==3.1.0"
mim install "mmpose==1.1.0"
```

> 🔧 **最大のハマりどころは mmlab の依存地獄**：`mmcv==2.0.1` / `mmdet==3.1.0` / `mmpose==1.1.0` は**この組み合わせで噛み合う**ように作られています。新しい mmcv を入れると `mmdet` がインポートで落ちます。**`mim` 経由で指定バージョンを入れる**こと。ffmpeg は別途必要で、Linux は `conda install -c conda-forge ffmpeg`、Windows は配布バイナリを `--ffmpeg_path` で渡します。

### 2. 重みの取得（`download_weights.sh`）

公式の `download_weights.sh`（Windows は `download_weights.bat`）が、必要な重みを HuggingFace 等から取得し、次のツリーを作ります。

```text
./models/
├── musetalk/                 # v1.0
│   ├── musetalk.json
│   └── pytorch_model.bin
├── musetalkV15/              # v1.5（最新・既定）
│   ├── musetalk.json
│   └── unet.pth
├── sd-vae/                   # ft-mse-vae（凍結エンコーダ）
│   ├── config.json
│   └── diffusion_pytorch_model.bin
├── whisper/                  # 音声特徴（tiny）
│   ├── config.json
│   ├── pytorch_model.bin
│   └── preprocessor_config.json
├── dwpose/                   # 顔・体ポーズ
│   └── dw-ll_ucoco_384.pth
├── face-parse-bisent/        # 顔パース（合成境界の馴染ませ）
│   ├── 79999_iter.pth
│   └── resnet18-5c106cde.pth
└── syncnet/                  # 同期評価（LatentSync由来）
    └── latentsync_syncnet.pt
```

各依存（Whisper・sd-vae・dwpose 等）は**それぞれのライセンスに従う**必要があります。MuseTalk 本体のコードは MIT ですが、**依存とテストデータは別物**——商用前に一次情報で確認してください（[ライセンス章](#よくある質問faq)で詳述）。

### 3. 推論（公式 `inference.sh`）

GUIで試すなら `python app.py --use_float16`（Gradio）。バッチ・自動化は CLI です。公式の `inference.sh` は **v1.5 を既定**にしており、本質は次の通りです。

```bash
# Linux：v1.5・通常推論 ／ リアルタイム推論
sh inference.sh v1.5 normal
sh inference.sh v1.5 realtime

# 直叩き（Windows例。Linuxはパス区切りを/に）
python -m scripts.inference \
  --inference_config configs/inference/test.yaml \
  --result_dir results/test \
  --unet_model_path models/musetalkV15/unet.pth \
  --unet_config models/musetalkV15/musetalk.json \
  --version v15
```

入力は**コマンド引数ではなく YAML**で渡します（ここが LatentSync と違う点）。`configs/inference/test.yaml` は素直です。

```yaml
# configs/inference/test.yaml
task_0:
  video_path: "data/video/sun.mp4"   # 動画／画像／画像ディレクトリ
  audio_path: "data/audio/sun.wav"   # 当てる音声
  bbox_shift: 0                      # 口の開き調整（後述）。v1.5は0でよいことが多い
```

`scripts.inference` が受け取る**主要引数**（argparse の既定値どおり）：

| 引数 | 型 | 既定 | 役割 |
| --- | --- | --- | --- |
| `--version` | str | `v15` | `v15`（1.5）/ `v1`（1.0）の切り替え |
| `--inference_config` | str | `configs/inference/test_img.yaml` | タスクを書いたYAML |
| `--unet_model_path` | str | `./models/musetalkV15/unet.pth` | U-Net重み |
| `--unet_config` | str | `./models/musetalk/config.json` | U-Net設定 |
| `--vae_type` | str | `sd-vae` | VAE種別 |
| `--whisper_dir` | str | `./models/whisper` | 音声特徴モデル |
| `--bbox_shift` | int | `0` | 口の開き（マスク領域の上下シフト） |
| `--extra_margin` | int | `10` | 顔下端の余白（あご周りの合成境界） |
| `--parsing_mode` | str | `jaw` | 顔パースの馴染ませ方（`jaw` 推奨） |
| `--left_cheek_width` | int | `90` | 左頬の合成幅 |
| `--right_cheek_width` | int | `90` | 右頬の合成幅 |
| `--audio_padding_length_left` | int | `2` | 音声特徴の左パディング（時間文脈） |
| `--audio_padding_length_right` | int | `2` | 音声特徴の右パディング |
| `--batch_size` | int | `8` | バッチサイズ（VRAMと速度） |
| `--fps` | int | `25` | 出力fps |
| `--use_float16` | flag | off | fp16で高速化・省VRAM |
| `--result_dir` | str | `./results` | 出力先 |

> 💡 **`use_float16` の効き**：fp16 は速度とVRAMに直結します。参考値として、公式は **RTX 3050 Ti で8秒の動画を約5分（fp16）**としています。逆に **V100 では 30fps+ のリアルタイム**。GPUの世代差が体感を大きく分けるので、まず `--use_float16` を付けて測るのが定石です。

---

## リアルタイムの真価：アバター事前生成 & 再利用（realtime_inference）

ここが MuseTalk を選ぶ**最大の理由**であり、API のワンショットでは見えない部分です。

通常推論は毎回「動画を読み込み → 顔検出 → 潜在エンコード → 生成」を全部やります。`realtime_inference` は、この**重い前処理（顔検出・潜在エンコード等）を「アバター」として一度だけ焼き込み、以降は音声を差し替えるだけで即時生成**します。設定は `configs/inference/realtime.yaml`。

```yaml
# configs/inference/realtime.yaml
avator_1:                         # ← リポジトリの綴りは "avator"（typo）。そのまま使う
  preparation: True               # 新規アバターは True で1回だけ前処理
  bbox_shift: 5
  video_path: "data/video/yongen.mp4"
  audio_clips:                    # このアバターに当てる音声群
    audio_0: "data/audio/yongen.wav"
    audio_1: "data/audio/eng.wav"
```

```bash
# v1.5・リアルタイム。fpsを固定して実行
sh inference.sh v1.5 realtime
# or
python -m scripts.realtime_inference \
  --inference_config configs/inference/realtime.yaml \
  --result_dir results/realtime \
  --unet_model_path models/musetalkV15/unet.pth \
  --unet_config models/musetalkV15/musetalk.json \
  --version v15 --fps 25
```

運用のキモは README の一文です——**「新しいアバターを処理するときだけ `preparation: True`。前処理が終われば、同じアバターで追加の動画を作るときは `preparation: False` にする」**。

これを業務に翻訳するとこうなります。

- **接客アバター**：開店前に `preparation: True` でアバターを1体焼く（数十秒〜）。営業中は `preparation: False` のまま、**来客の質問に対する返答音声を当てるだけ**で喋らせる。前処理を毎回やらないから低遅延。
- **日替わりアンカー**：アンカー映像は固定＝**1回焼けば使い回せる**。毎日の原稿は音声だけ差し替え。
- **大量パーソナライズ**：テンプレ映像を1回アバター化 → **1万通りの音声を流し込んで1万本**を最小コストで生成。

> ⚠️ **「リアルタイム」の正確な意味**：30fps+ は**生成スループット**の話で、ASR→LLM→TTS を含む対話全体の遅延ではありません。体感の即応性は、**アバターを事前焼き込みしておくこと**と、**TTSの先頭チャンクが出た時点で生成を始める**ストリーミング設計で決まります。下の[応用章](#応用リアルタイムデジタルヒューマン基盤の組み方)で全体を組みます。

---

## パラメータ実践チューニング：用途別プリセット

MuseTalk のノブは「拡散の反復回数」ではなく、**「合成した口元を、元の顔にどう自然に馴染ませるか」**が中心です。仕組み章の「顔の下半分を合成する」設計を思い出すと意味が通ります。

| 用途 | `bbox_shift` | `extra_margin` | `parsing_mode` | `*_cheek_width` | `use_float16` | 狙い |
| --- | --- | --- | --- | --- | --- | --- |
| **まず動かす**（v1.5標準） | 0 | 10 | jaw | 90 / 90 | ✅ | 既定で十分。ここから差分調整 |
| **口の開きが弱い** | +5〜+10 | 10 | jaw | 90 | ✅ | 口元マスクを下げ、開口を増やす |
| **口が開きすぎ・違和感** | −3〜−7 | 10 | jaw | 90 | ✅ | マスクを上げ、開口を抑える |
| **あご周りに境界線** | 0 | 15〜20 | jaw | 90 | ✅ | 下端余白を広げ縫い目を隠す |
| **頬の合成が浮く** | 0 | 10 | jaw | 100〜110 | ✅ | 頬幅を広げて馴染ませる |
| **最終アップ品質** | 微調整 | 微調整 | jaw | 微調整 | ❌（fp32） | わずかな精度差を拾う＋超解像へ |

各ノブを実務語で言い換えると——

- **`bbox_shift`（口の開き）**：マスク領域を上下にずらして**口の開閉量を調整**する唯一のノブ。**正で開く、負で閉じる**。README 推奨の手順は「**まず既定で1回流すと、調整可能な値域がスクリプトに表示される。その範囲内で再実行**」。v1.5 は口元処理が改善され**0 のままで良いことが多い**が、早口や歌で開きが足りないときに使う。
- **`extra_margin`（下端余白）/ `*_cheek_width`（頬幅）/ `parsing_mode`（顔パース）**：すべて**合成の継ぎ目を消す**ためのノブ。あごや頬に**境界線・色ムラ**が出たら、ここを動かす。`jaw` が標準。
- **`audio_padding_length_left/right`（音声文脈）**：口の動きが参照する**前後の音声長**。既定2で十分だが、無音→発話の立ち上がりが不自然なときに触る。論文の ablation でも、音声セグメント長は同期に効く（最適は中庸）ことが示されている。
- **`batch_size` / `use_float16`**：**速度とVRAM**のノブ。ドラフトは `--use_float16` + 大きめバッチ、最終アップは fp32 + 超解像、が定石。

> **コスト直結の原則**：MuseTalk は**そもそも速い**ので、LatentSync のような「ステップ数＝お金」の効き方はしません。代わりに効くのは **①アバター再利用で前処理を払い戻す ②fp16で throughput を上げる ③無音区間を生成に通さない（VAD）**。私の基盤ではこの3点で GPU 時間を大きく削っています（[パイプライン記事](/blog/production-ai-video-localization-lipsync-gpu-pipeline)）。

---

## 本番で必ず詰まる落とし穴と回復性設計

デモ（10秒・正面・きれいな音声）では起きず、**現実の素材（数十分・横顔・無音・複数話者・低解像度）で一斉に噴出**する問題です。仕組み章で見たとおり、これらは**MuseTalkの設計の必然**として現れます。

### ① 顔検出・顔パースの失敗（最頻出）

MuseTalk は内部で顔を検出・パース（dwpose / face-parse）してから口元を合成します。**横顔・うつむき・手やマイクでの遮蔽・極端なサイズ**で検出が外れると、口元が崩壊するか処理が落ちます。

**対策**：投入前に**顔の有無と正面性を自前で前検査**し、検出できないカットは**リップシンクを通さず素通し（パススルー）**にする。全カットを無理に同期させない判断が品質を守ります。

```python
# 投入前ガード：正面に近い単一の顔があるカットだけをMuseTalkへ回す
import mediapipe as mp

_detector = mp.solutions.face_detection.FaceDetection(
    model_selection=1, min_detection_confidence=0.6
)

def is_lipsyncable(frame_rgb) -> bool:
    """顔が1つ・十分な信頼度で検出できるカットのみTrue。Falseなら原画パススルー。"""
    result = _detector.process(frame_rgb)
    faces = result.detections or []
    return len(faces) == 1  # 複数顔・無顔は同期対象外にして破綻を防ぐ
```

### ② 256×256 が上限という解像度の壁

MuseTalk の顔領域は **256×256**。顔が大きく映るアップでは、口元だけ解像感が落ちて見えます。論文も**超解像（GFPGAN等）併用**を明記しています。

**対策**：生成後に**口元領域へ超解像を1段かける**。全フレームにかけると重いので、**顔が大きいカットだけ**に適用するのが費用対効果が高い。

```python
# 生成後の口元だけを超解像で底上げ（顔が大きいカットに限定）
def enhance_if_closeup(frame_bgr, face_box, *, upscaler) -> "ndarray":
    x, y, w, h = face_box
    # 画面に占める顔の割合がしきい値超のときだけGFPGAN等を適用
    if (w * h) / (frame_bgr.shape[0] * frame_bgr.shape[1]) < 0.18:
        return frame_bgr  # 小さい顔は素通し（コスト削減）
    return upscaler.enhance(frame_bgr)  # 例：GFPGAN
```

### ③ 単一フレーム由来のジッタ

論文も認める弱点で、フレームを1枚ずつ作るため**口元が小刻みに揺れる**ことがあります。

**対策**：v1.5（時間学習込み）を使うのが第一。残るジッタは、口元領域に**時間方向の軽い平滑化（指数移動平均など）**を後処理でかけると目立たなくなります。かけ過ぎると逆に追従が鈍るので、**口の開閉が速い区間は弱める**のがコツ。

### ④ fps / 解像度 / 音声フォーマットの不一致

入力の **fps がバラバラ**だったり、音声が想定外コーデックだと、口と音が**全体的にズレる**か処理が失敗します。

**対策**：投入前に **ffmpeg で正規化**を1段挟む。fpsを固定し、音声を 16kHz/mono/wav に揃えるだけで、再現性と安定性が跳ね上がります。

```bash
# 投入前の正規化：fps固定・音声をwav 16kHz monoに統一
ffmpeg -y -i input.mp4 -r 25 -c:v libx264 -pix_fmt yuv420p norm_video.mp4
ffmpeg -y -i dub.m4a -ar 16000 -ac 1 dub.wav
```

### ⑤ 長尺・大量処理でのスループット詰まり

MuseTalk は速いですが、**数百本×長尺**を素朴に直列実行すると詰まります。OOM は LatentSync ほど起きにくい（拡散ではないため）ものの、**前処理の重複**と**無音区間の無駄打ち**が効いてきます。

**対策**：**①アバター再利用で前処理を払い戻す ②VADで無音区間をスキップ（口を動かす必要がない）③冪等キャッシュで再生成ゼロ**。これらは「速いモデルをさらに安くする」ための定石です。

```python
# OOMを正常系として扱う：失敗したらバッチを縮めて再試行（回復性）
def lipsync_batch(frames, *, batch_size: int = 8):
    try:
        return run_musetalk(frames, batch_size=batch_size)
    except torch.cuda.OutOfMemoryError:
        torch.cuda.empty_cache()
        if batch_size <= 1:
            raise  # これ以上割れない＝本物の異常。握りつぶさない
        return lipsync_batch(frames, batch_size=batch_size // 2)  # 半分にして再挑戦
```

### ⑥ 品質を「目視」でしか確認していない

本番で最も危険なのは、**品質ゲートが人間の目視だけ**であること。大量バッチでは破綻カットが必ずすり抜けます。

**対策**：MuseTalk のモデルツリーには **`syncnet`（`latentsync_syncnet.pt`）** が含まれます。これで**同期度を機械採点**し、しきい値を下回ったカットだけ人手レビュー or 再生成に回す。SyncNet 信頼度を**定量ゲート**にすることで、レビュー工数を激減できます。

---

## 本番運用の設計原則（可観測性・冪等性・回復性・コスト）

落とし穴の対策を、運用品質の言葉でまとめ直します。これが「動く」と「本番で落ちない」の差です。

- **冪等性**：`sha256(動画/アバターID + 音声 + 主要パラメータ)` を**ジョブキー**にし、結果をキャッシュ。再送・連打・リトライで二重生成しない。API でも自前GPUでも同じ設計。
- **回復性**：顔検出失敗・OOM・GPUプリエンプションを**例外ではなく正常系**として扱う。「バッチを縮めて再試行」「同期不能カットは原画パススルー」で、1カットの失敗が全体を巻き込まないようにする。
- **可観測性**：カットごとに **どの版で・bbox_shift いくつ・extra_margin いくつ・SyncNet信頼度いくつ**を構造化ログに残す。「なぜこのカットだけ口元が浮いたか」を後から追える状態にする。PII（顔・音声内容）はログに出さない。
- **コスト効率**：MuseTalk の場合は **①アバター再利用 ②fp16 ③VADで無音スキップ ④冪等キャッシュ**。サードパーティAPIなら 1回数¢が**そのまま積算**されるので、無駄打ち削減が直接効く。
- **損益分岐**：**少量・検証ならAPI**（環境構築ゼロ）。**定常的に大量・低遅延・データを外に出せない**ならセルフホスト。まずAPIで品質と需要を確かめ、量が増えたらセルフホストへ——が王道です。

---

## 応用：リアルタイム・デジタルヒューマン基盤の組み方

MuseTalk 単体は「音声→口」だけです。**実際に案件で価値を生むのは、これを対話スタックに組み込んだとき**です。最小構成はこうなります。

```text
[ユーザー音声/テキスト]
      │  ① ASR（Whisper）          → /blog/openai-whisper-production-guide-selfhost-vs-api
      ▼
[テキスト]
      │  ② LLM（Claude等）で返答生成 → /blog/claude-api-ai-sdk-v6-production-ai-features
      ▼
[返答テキスト]
      │  ③ TTS で音声合成（ストリーミング）
      ▼
[返答音声チャンク]
      │  ④ MuseTalk（事前焼き込みアバターに即時リップシンク）
      ▼
[喋るアバター映像] → 配信/再生
```

設計の肝は3つです。

1. **アバターは事前に焼く**（`preparation: True` を1回）。対話のたびに前処理しない。
2. **TTSとMuseTalkをストリーミングで繋ぐ**。TTSの先頭チャンクが出たら生成を始め、全文合成を待たない。体感遅延はここで決まる。
3. **境界をすべて型で守る**。LLM出力もTTS入力も**Zodで検証**し、想定外を生成に流さない（私の[音声AIエージェント記事](/blog/production-voice-ai-sales-agent-bedrock-pgvector)と同じ規律）。

返答生成〜リップシンク投入の**オーケストレーション部**を型安全に書くと、骨子はこうなります。

```ts
// lib/avatar-pipeline.ts — 対話1ターンを「型で固めた」最小オーケストレータ
import { z } from "zod";

// 各段の入出力を境界で検証する（壊れた出力を次段に流さない）
const Reply = z.object({ text: z.string().min(1).max(2000) });
const TtsChunk = z.object({ audioUrl: z.string().url(), seq: z.number().int() });

interface AvatarRuntime {
  /** 事前焼き込み済みアバター。preparationは起動時に一度だけ実行済み。 */
  readonly avatarId: string;
  /** 音声チャンクを当て、口を合わせたフレーム列を返す（再利用ゆえ低遅延）。 */
  speak(input: { avatarId: string; audioUrl: string }): Promise<{ videoUrl: string }>;
}

export async function handleTurn(
  userText: string,
  deps: {
    llm: (q: string) => Promise<unknown>;
    tts: (text: string) => AsyncIterable<unknown>; // ストリーミングTTS
    avatar: AvatarRuntime;
  },
): Promise<{ videoUrl: string }[]> {
  // ② LLM：出力は信用せず必ず検証
  const reply = Reply.parse(await deps.llm(userText));

  const clips: { videoUrl: string }[] = [];
  // ③→④：TTSチャンクが届くたびに、事前焼き込みアバターへ即リップシンク
  for await (const raw of deps.tts(reply.text)) {
    const chunk = TtsChunk.parse(raw);
    const out = await deps.avatar.speak({
      avatarId: deps.avatar.avatarId, // 再利用：前処理を払い戻す
      audioUrl: chunk.audioUrl,
    });
    clips.push(out); // 先頭から順に配信すれば、全文合成を待たずに喋り始められる
  }
  return clips;
}
```

ここまで来ると、MuseTalk は「リップシンク・モデル」から「**喋るデジタルヒューマンの口**」に変わります。**外注で差がつくのはまさにこの統合部分**——モデルを動かすだけなら誰でもできますが、ASR/LLM/TTS との型安全な接続、ストリーミングの遅延設計、アバター再利用、品質ゲートまで含めて**本番で落ちない基盤**にするのは、踏んだ地雷の数がそのまま品質になります。

---

## 他のリップシンクモデルとの比較

「結局どれを使う？」に答えるための整理です。**用途で選ぶ**のが正解で、万能の1つはありません。

| モデル | 方式 | 強み | 弱み | ライセンス | 向く場面 |
| --- | --- | --- | --- | --- | --- |
| **MuseTalk** | 潜在空間インペインティング（単一ステップ） | **リアルタイム・アバター再利用・自然な画質** | 256×256上限、ジッタ、細部の同一性 | **コードMIT** | 対話アバター・配信・大量ドラフト |
| **[LatentSync](/blog/latentsync-lip-sync-diffusion-model-production-guide)** | 音声条件付き潜在拡散 | **最高画質・512・時間的一貫性** | 反復ぶん遅い、相応のVRAM | Apache-2.0 | 高品質吹替・主役アップ |
| **Wav2Lip** | GAN系（軽量） | 軽い・速い・**同期スコアが高い** | 解像度・口元の精細さが低い | 研究用途中心（要確認） | プロト・低負荷の大量処理 |
| **SadTalker** | 3DMM + 顔生成 | **静止画1枚**から喋らせられる | 動画ベースの自然さでは劣りがち | 要確認 | 写真からのトーキングヘッド |

実務の意思決定はおおむねこうです。

- **対話・配信・低遅延・大量** → **MuseTalk**。
- **吹替の最終品質・顔のアップ** → **LatentSync 1.6**。
- **静止画1枚しかない** → SadTalker。
- **量と質の両立** → **MuseTalk でドラフト → 採用分を LatentSync で本生成**の二段構え。

> 各モデルのライセンスは更新されます。**商用利用は必ず一次情報で確認**してください。MuseTalk は本稿執筆時点で**コードがMIT**、**学習済みモデルは商用含め利用可**、ただし**依存モデルとテストデータはそれぞれの条件**に従います。

---

## よくある質問（FAQ）

**Q. 商用利用できますか？**
A. MuseTalk の**コードは MIT ライセンス**（学術・商用とも可）で、**学習済みモデルも商用を含め利用可**と公式に記載されています。ただし**依存（Whisper・sd-vae・dwpose 等）はそれぞれのライセンス**に従う必要があり、**同梱テスト素材は非商用研究のみ**です。加えて、生成物に映る**人物の肖像権・音声の権利**は別問題——本人同意のある素材で使ってください。

**Q. 日本語の音声でも使えますか？**
A. 使えます。公式は**中国語・英語・日本語など各言語に対応**と明記しています。音声は Whisper の特徴を介して条件付けされ、**言語に依存せず口の動きを生成**します。

**Q. MuseTalk と LatentSync、どちらを使うべき？**
A. **リアルタイム・対話・配信・大量処理なら MuseTalk**、**最終画質・顔のアップなら LatentSync 1.6**。詳細は[使い分け章](#latentsync-との使い分け拡散-vs-単一ステップ)。私は実運用で**両方を用途で使い分け**ています。

**Q. 必要なGPU / VRAMは？**
A. 推論は比較的軽く、**V100 で 30fps+ のリアルタイム**。低スペックでも動き、公式は **RTX 3050 Ti で8秒動画を約5分（fp16）**としています。`--use_float16` と `--batch_size` でVRAMと速度を調整します。学習は別物で 8×H20 級が必要ですが、**通常は推論だけで足ります**。

**Q. 本当に「リアルタイム」で配信できますか？**
A. **生成スループットは 30fps+** ですが、対話全体の遅延は ASR→LLM→TTS を含みます。体感の即応性は、**アバターの事前焼き込み**と**TTSストリーミング連携**で決まります（[応用章](#応用リアルタイムデジタルヒューマン基盤の組み方)）。

**Q. 出力がボヤける / 口元が浮きます。**
A. まず **256×256 上限**を理解し、顔が大きいカットは**超解像（GFPGAN等）を併用**。継ぎ目は `extra_margin`・`*_cheek_width`・`parsing_mode` で馴染ませ、口の開きは `bbox_shift` で調整します（[チューニング章](#パラメータ実践チューニング用途別プリセット)）。

**Q. mmcv / mmdet のインストールで必ず失敗します。**
A. MuseTalk セットアップ最大の難所です。**`mmcv==2.0.1` / `mmdet==3.1.0` / `mmpose==1.1.0` を `mim` 経由でこのバージョンのまま**入れること。新しいmmcvを入れると依存が壊れます。Python 3.10 / PyTorch 2.0.1 / CUDA 11.7 の組み合わせを守るのが安定の鍵です。

**Q. 自前GPUとAPI、どちらが安い？**
A. **少量・検証ならAPI**（環境構築ゼロ、1回数¢〜）。**定常的に大量・低遅延・データ非公開**なら、GPUをアバター再利用で埋めるセルフホストが1本単価で有利。まずAPIで品質と需要を確かめ、量が増えたらセルフホストへ移すのが王道です。

---

## まとめ：MuseTalk を「動く」から「本番で稼ぐ」へ

MuseTalk の本質は、**「拡散の反復をやめ、潜在空間での単一ステップ・インペインティングに振り切ることで、リアルタイム性能を手に入れた」**点にあります。だからこそ速く、だからこそ**アバター再利用**が効き、だからこそ 256×256・ジッタ・細部の同一性という**設計に根ざした制約**を理解して扱う必要があります。

実装の道筋はシンプルです。

1. **API（fal.ai / Replicate 等）** で自分の素材の品質をまず確かめる（自前GPU不要）。
2. 手応えがあれば **v1.5 をセルフホスト**し、`bbox_shift` / `extra_margin` / `parsing_mode` を用途別プリセットで詰める。
3. **真価はアバター事前生成＆再利用**——ASR/LLM/TTS と繋いで、**対話型デジタルヒューマン**にする。
4. **本番は冪等性・回復性・可観測性・コスト**を設計に織り込む——顔検出ガード、超解像、VADで無音スキップ、SyncNet信頼度ゲート。

ここまでやって初めて、デモではなく「**顧客の素材で落ちない**」プロダクトになります。そして、ここが一番伝えたい点ですが——**モデルを繋ぐだけのデモは誰でも作れます**が、**リアルタイム・大量・低解像度・横顔の現実素材で破綻しない基盤**は、踏んだ地雷の数がそのまま品質になります。

> 私は、本稿の落とし穴と回復性設計を**実際に本番運用しているAI動画ローカライズ基盤**で実装し、MuseTalk を**速度とアバター再利用が効く場面**で使い続けています。リアルタイム・デジタルヒューマンやリップシンクを含む動画AIパイプラインの構築・改善をお考えなら、[実績](/case-studies/ai-video-localization-lipsync)をご覧のうえ、お気軽にご相談ください。**一人 × 生成AI**で、PoCから本番運用まで一気通貫で、速く・安く・安全に作ります。

---

## 出典・公式リソース

- **公式リポジトリ（GitHub）**：[TMElyralab/MuseTalk](https://github.com/TMElyralab/MuseTalk) — README・`inference.sh`・`scripts/inference.py`・`configs/inference/*.yaml`・`download_weights.sh`
- **論文（arXiv）**：[MuseTalk: Real-Time High Quality Lip Synchronization with Latent Space Inpainting (2410.10122)](https://arxiv.org/abs/2410.10122) — 潜在空間インペインティング・選択的サンプリング(SIS)・定量結果
- **モデル配布（HuggingFace）**：[TMElyralab/MuseTalk](https://huggingface.co/TMElyralab/MuseTalk) — v1.0 / v1.5 チェックポイント
- **サードパーティAPI**：[fal.ai（fal-ai/musetalk）](https://fal.ai/models/fal-ai/musetalk) / [Replicate（douwantech/musetalk）](https://replicate.com/douwantech/musetalk) — 入力スキーマ・料金・実行環境

※ バージョン・パラメータ・料金・ライセンスは更新されます。**実装前に必ず一次情報を確認**してください。本稿の数値（256×256・30fps+/V100・FID 6.43/CSIM 0.8225/LSE-C 6.53・FID改善 11.55%/44.34%・SIS FID 4.39 vs 23.95・RTX 3050 Ti 8秒≈5分(fp16)・v1.5 2025/03/28公開・argparse既定値・各API参考価格 など）は本稿執筆時点の公式情報および各サービスの公開情報に基づきます。