![]() |
まずチャン氏は「なぜ今,顔アニメーションなのか」を語った。グラフィックス(ビジュアル)の品質はいまや全体的に高水準で均一化し,ボディアニメーションもモーションキャプチャで底上げされた。そのなかで人々が次に期待するのが顔のアニメーションだ,というのが氏の主張である。
実際,会場では元のゲーム画面(唇が動かない)と自社技術を適用した映像を並べ,ユーザーの体感品質に大きな差が生じることを示した。グラフィックスやボディがいくら良くても,顔アニメーションがないと違和感・不快感を覚えるレベルにまで来ているという。
それゆえ多くの開発会社がここに注力する。たとえば『モンスターハンター:ワールド』では顔アニメーションだけで5つ以上のスタジオが関わっているとされる。
従来こうした顔アニメは顔モーションキャプチャ(ヘッドマウントカメラを装着して演技)で作られてきたが,ボディに比べてキャプチャ品質が良いとは言えず,最終的にはアーティストの手作業に頼らざるを得ない。制作できるボリュームに限界があるのだ。そこでAIによる自動生成技術の開発に,多くの企業が取り組んできた。
![]() |
既存ソリューションとしては,Speech GraphicsやJALIといった企業が事業化しており,国内でもクラフトン,スマイルゲート,ネットマーブル,そしてNCなど各社が自社開発を進めてきた。
近年はNVIDIAやEpic Gamesも技術を公開している(NVIDIAのものは多言語対応をうたい,無料で使える)。学術的にも,リップシンク研究は長く続き,2017年のNVIDIA論文が代表格だ。最近はモデルとしてディフュージョン+トランスフォーマーを用いる形がほぼ定着し,3DGSやアニメーションテクスチャでしわまで表現するなど,氏いわく「技術開発はほぼ終わった」段階にあるという。
![]() |
では,なぜ現実のゲームで自然な表情アニメが使われていないのか。氏は公開技術の弱点を率直に挙げた。ゲームのセリフは激しい演技トーンで,強い残響効果がかかることが多い。だが一般的な発話音声データにはそうした要素が含まれないため,NVIDIAの技術を適用すると性能が低下する。
MetaHuman(Epic)の場合,口を開けた笑顔の基本表情に唇の変位だけを加える形になりがちで,唇の動きが不自然になり感情表現がうまくいかない。Epicはゲーム会社ゆえ震え(ジッタ)をかなり抑え込んでいるが,今度は滑らかすぎて唇の形がつぶれ,発音がはっきり表現されない。結局どれも商用適用には後処理が必要で,人員・コスト・時間がかさみ,導入は容易でない。
![]() |
そこでチャン氏らはまず,現場のニーズを調査した。結論は意外なものだった。品質はむしろそれほど重要ではない――「これまでできなかったことが問題なのであって,今できるものが動けば十分」。
ただし新たな問題が起きてはならない。震えの抑制や全体的な品質の安定性が最も重要で,何より安定性確保のための後処理に追加の人員・コスト・時間をかけないことが求められていた。そこで彼らは,品質のばらつきを抑え安定品質を提供する方向に舵を切った。
![]() |
技術のワークフローはシンプルだ。ニューラルネットという“ブラックボックス”に音声を入力すると,すぐにアニメーションカーブの値が出力される。声優の録音がない量産NPCのサブクエストなどでは,TTSで音声を生成し,そこからアニメを作ることも可能だ。追加演出が必要ならオプションを指定すれば,感情表現などを考慮して後処理でアニメが自動生成される。
NCはUnrealを多用するため,出力はそのままUnrealで使える仮シーケンスアセットとして生成されるよう実装した。核となるモデルは,前述の“学会で完成済み”のディフュージョン+トランスフォーマーを利用している。
![]() |
ここからが本題の,課題とその解決だ。リップアニメ品質の評価で最も重要なのは,唇の動きの正確さである。とりわけ両唇音(韓国語の「ㅁ」「ㅂ」「ㅍ」など)は,いったん唇を閉じてから開いて発音する。この“閉じて開く”動きが再現されないと人はすぐ違和感に気づく。
逆にそれ以外は多少もごもごしても自然だと受け止められる。ところが既存の論文・事例では品質が良くない。理由は一言で言えば学習データが両唇音を正しく表現できていないことだ。元映像自体が不正確なのだ。多くの開発会社はMax Planckが作った「SMPL」データをそのまま使っており,それゆえ結果品質に限界がある。
![]() |
そこでチャン氏らは独自に顔モーションキャプチャ技術(専用装置)を開発した。大きな後処理なしでも相応のアニメが得られる水準のデータを取得し,キャプチャ時の演技が良くない場合に備えて学習データ化のための後処理技術も用意。こうして両唇音データを高品質かつ多く投入することで,第一の課題を解決したという。
![]() |
次の難所が,シンク(同期)の本質的な難しさだ。同じ「あ」でも,ボリュームもピッチも,太い声か音程を上げるかで,コンピュータが受け取る情報は大きく異なる。しかも声が似ていても,発話時の唇の形は人により,その都度異なる。つまり入力と出力が多対多の対応になる。
これをそのままAIに学習させると平均的な状態に収束し,ただモゴモゴ喋るだけの動きになってしまう。既存研究は前後シーケンス情報やモーションロス(Motion Loss)の導入,あるいは後処理で対処してきたが,チャン氏らはこれをモデル側で解決した。
ディフュージョン+トランスフォーマーを用いると,元の学習データで実際の人間が行ったシーケンスを可能な限り復元する形でアニメが生成される。これにより,1人分のデータについてはモデルの改良で解決できたという。
![]() |
だが実際のゲームには何百体ものNPCがいて声も多様で,キャラごとに個性も要る。そのため扱う音声データの範囲が広がって管理が難しくなる――商用ゲームでも未解決の領域だ。NVIDIAやEpicは,男性,女性,子ども,高齢者の声を用意し,Voice Conversionで10人分を100人,1000人分に拡張して学習させる。だが,氏いわく「それでは決して解決しない」。音声データの領域をすべてカバーできないのだ。
そこでチャン氏らは“ちょっとしたトリック”を使った。100人,1000人の話者を,あえて1人の音声にマッピングしてしまう「Retrieval方式のVoice Conversion」だ。しかも単にその話者の声に変えるのではなく,その話者が音声キャプチャ時に実際に発話したデータにマッピングする。これにより,どんな音声が入力されても“既に見たことのある音声”へ明確に置き換えられ,その入力でアニメを生成するため,ノイズやジッタが発生しない。
![]() |
さらに,多数のアニメ結果にはさまざまなキャラが含まれるが,これらが決して混ざってはいけない。ボーンベースであれブレンドシェイプベースであれ最終的にはリグのパラメータ値が生成されるが,混ざると「ある発音で上唇は俳優Aのもの,下唇はB,目はまた別人」というように表情そのものが破綻し,使い物にならない。
そこで話者を識別するIDを埋め込む技術を適用。会場では1つの音声に対し3体のキャラがそれぞれ少しずつ異なる動きを見せつつ,唇のめり込みや不自然な跳ねもなく,個性が保たれたまま生成される様子が示された。
![]() |
なお氏は,デモに使ったサブカルチャー系キャラについて「自社技術とは無関係に,デモ用に用意したもの」と断ったうえで,重要な前置きをした。「AIを使っているというとかえって良くない印象を与える社会的雰囲気がある。本日は技術そのものの説明にだけ注目いただき,どこにどう適用されているかという話題は出さないでほしい」。本稿もこの意向を尊重し,適用先には触れない。
そのサブカル系キャラでは,人間のアニメをそのまま再現するとかえって不自然になる(従来のキーフレーム作業に慣れているため)。そこで,生成する3つのポーズ間をリニアブレンディングするだけでアニメが出せるようロジックを変換し,最小限のアニメで成立させて解決したという。
![]() |
最後に感情だ。従来の感情アニメ制作では喜び・悲しみなどごく限られた種類しか扱えず,増やすのも難しい(アーティストの手作業が膨大なため)。しかも「喜び」のデータだけ抽出して学習させても,喜びの表情はうまく出ない。俳優は1時間も2時間も喜びの演技を続けられないからだ。
実際の人間も,話の途中で時々笑うのが“喜び”である。そこでチャン氏は,本当に強く感情が伝わる部分だけを選別してラベルを付け直すことで解決した。
![]() |
成果とデモも紹介された。ただし氏は正直に,会場で触れたあるゲームには「最高品質ではなく,社内でも最も低い品質のバージョン」が入っていると明かす。本来は顔全体のアニメを入れないと自然にならないが,そのケースでは唇の動きしか入れられず全体の動きを抑えているためだ。
一方で,この技術の最大の利点は後処理が一切不要な点である。QAを経ずそのまま適用できる品質に仕上げており,企画者がシナリオスクリプトを入力するだけでアーティストを介さず自動生成され,カットシーンまで自動で作られるという。ローカライズも自動生成のため,他国版でアニメと音声を差し替える際も大きなコスト負担がない(日本語デモは東京ゲームショウ出展時のもの)。
既存技術との比較では,通常発話なら各技術とも基本品質は出る。だがチャン氏らの技術は感嘆詞のような発話でこそ強い。小さい「あ」と大きい「あ」で唇の動きの大きさが変わるのは,比較対象の中で同社の技術だけ。他技術は安定化のため常に一定のアニメにマッピングされ,動きの大きさが変わらない。
ゲームには感嘆詞の場面が多いため,そのデータを多めに投入したという。首を横に向けた場面や後頭部だけの場面ではアニメを生成しない作りになっている点も示された。
![]() |
続いてチャン氏は,今後さらに改善できる点――「いちばん重要」と語る将来像を提示した。生成AIによる映像はとても自然に見えるのに対し,ゲームキャラでの再現は物足りなく感じられる。その打開策として氏が挙げたのが,学習データを俳優やアナウンサーから集めるのではなく,映像生成AIで作ることだ。
多少品質が落ちても100時間,1000時間とデータを作っておき,その中から学習に役立つものを選別すれば,品質は飛躍的に向上するという。
もう一つは表現力の幅だ。従来のフェイシャルは,まばたきや笑いなど決まった表情をリニアブレンドして表現するため,人間の細かな笑顔や泣き顔を再現しきれない。それでもこの方式が使われ続けるのは,リグの実装自体が非常に複雑で,より細かな表情を表現できるリグを作る技術が今ないからだ。
そこで氏はAIによるリグの自動生成に期待を寄せる。感情についても,喜怒哀驚といった分類程度では映画のような自然さは得られない。一般的な演技のあらゆるデータを学習に使えるようにし,状況を細かくLLMでラベリングできれば,「虚しさがにじむ苦笑い」のような複雑な感情ディレクションにも応えられるようになるという。
さらに,体は動くのに顔が動かないと不自然だから,という理由でリップシンクに取り組んだ結果,現場からは「次は目も動いてほしい」「表情が付くと今度はジェスチャーが不自然だ」と要望が連鎖していく。これまで全体的にできていなかったから気づかなかった不自然さが,一つずつ見えてくるのだ。
最終的には口元・表情・ジェスチャーが別々ではなく,調和して自動生成される必要がある。チャン氏らはこの研究を一通り終え,社内向けデジタルヒューマンを作ってSIGGRAPHで発表したこともあるという。氏は改めて「これは特定技術の宣伝や採用事例の話ではなく,どのように技術を作ってきたかを伝えるための発表だ」と述べ,講演を締めくくった。
![]() |
Q&Aも活発だった。アニメーションカーブを「離散的に生成してブレンドしているのか,連続カーブを直接生成しているのか」との問いには,各フレームごとに表情を生成し,データ量が多くなるためアニメーション圧縮を行うと回答。要所にキーフレームが設定され間は補間される従来システムをそのまま活用しており,アニメーションカーブの一本一本が各表情のブレンドウェイト値を表す(ブレンドシェイプは10〜40個,映画分野では最大1000個規模)という。
「SMPLに問題があり独自スキャンしたとのことだが,データフォーマットは独自か」との問いには,標準では45種類の表情を使い,それ以外はEpic Gamesの標準規格に合わせると説明。「ディフュージョンモデルは生成の最大長が決まっているはずで,長いセリフはどう処理するか」には,ハードウェアスペック次第で,テスト時は30秒〜1分程度まで対応できたと回答。実運用では全セリフを一度に入れず文単位(通常5〜10秒)で分割入力し,その長さならGPU(RTX 5090)でもおおむね問題なく回るとした。
「サブカル系は従来手法のほうが良いとのことだったが,今後アニメ調の3D/2Dにも適用するか」には,入手しやすい人間のキャプチャデータをそのまま再現できる実写系が最優先ターゲットでAAAクラスでの実運用を目指すと回答。一方でサブカル市場も大きく,変換してみたところ人手と同等以上の品質を素早く出せると確認できたという。
ただし今後どちらに重点を置くかについては,現時点で追加研究の予定はなく,パッケージ化したものを現状のまま配布しているとのこと。理由は「技術の価値や限界というより,フューチャーワーク(今後の課題)を多く盛り込んだから」であり,チャン氏自身が現在フィジカルAIの分野を担当していることもあって,次のステージは用意していないと率直に語った。



















![画像ギャラリー No.001のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/001.jpg)
![画像ギャラリー No.002のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/002.jpg)
![画像ギャラリー No.003のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/003.jpg)
![画像ギャラリー No.004のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/004.jpg)
![画像ギャラリー No.005のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/005.jpg)
![画像ギャラリー No.006のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/006.jpg)
![画像ギャラリー No.007のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/007.jpg)
![画像ギャラリー No.008のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/008.jpg)
![画像ギャラリー No.009のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/009.jpg)
![画像ギャラリー No.010のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/010.jpg)
![画像ギャラリー No.011のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/011.jpg)
![画像ギャラリー No.012のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/012.jpg)
![画像ギャラリー No.013のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/013.jpg)
![画像ギャラリー No.014のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/014.jpg)
![画像ギャラリー No.015のサムネイル画像 / 音声を入れるだけで後処理もQAも不要な表情アニメを自動生成。「VARCO SyncFace」の開発ノウハウとは[NDC26]](/games/991/G999104/20260618002/TN/015.jpg)