【ITニュース解説】AI 3D Character Creation — No GPU Required

このニュース記事は、AIを活用した3Dキャラクター作成が、高性能なグラフィック処理装置（GPU）なしで、一般的なサーバーのCPUだけでも実現できることを紹介している。以前は独立していたキャラクター作成ツール「CHARFORGE」とゲームエンジンが統合され、単一のシステムとして機能するようになった。最も注目すべきは、このシステム全体が、特別なGPUを必要とせず、CPUのみで動作する仮想プライベートサーバー（VPS）上で実行されるという厳しい制約の元に構築されている点である。

このシステムの根幹にある重要な変化は、「アクター」という概念の導入である。ゲームエンジンはもはや特定のデータ形式に縛られず、「アクター」という抽象的なインターフェースとしてキャラクターを認識するようになった。アクターとは、ゲームエンジンからの「どれくらいの速さで動くか」「どうやってアニメーションを再生するか」「どうやって倒れるか」といった基本的な質問に答えられるもの全てを指す。このインターフェースが確立されたことで、キャラクターが手作業で作成されたものであろうと、他の人が作った既存のモデルであろうと、プログラムによって自動生成されたクリーチャーであろうと、BlenderとMPFB2を使ってCPUで生成された人間であろうと、さらには一枚の写真から再構築された3Dモデルであろうと、ゲームエンジンはそれらをすべて同じように扱うことが可能になった。各キャラクターは一度作成されると、リグ付け（骨格構造の定義）、必要に応じてリターゲット（アニメーションの適用調整）が行われ、共有のキャラクターライブラリに格納される。ゲームエンジンはライブラリ内のすべてのキャラクターを区別なく扱うのだ。このアクターというインターフェースを中心にシステムを構築することで、開発のロードマップは「様々なデータ形式に対応する」ことから「アクターの契約（インターフェースの要件）を満たす」ことへと変わり、問題解決の対象が大幅に絞り込まれるという大きなメリットがある。

キャラクターを作成するための方法は主に四つのパスに分けられる。

一つ目のパスは、モーフを使って人間を彫刻する方法である。これは、ベースとなる3Dモデルを、性別や年齢、体型といったパラメータに応じて変形させることでキャラクターを生成する。骨格構造に基づき、回転計算によってモデルが制御される。これらの彫刻、スキン（メッシュと骨格の結合）、質感を加えるシェーダー処理は全て、ブラウザのCPU上でJavaScriptによって実行される。特別なGPUの機能は必要ない。このパスにおける新しい点は、キャラクターデータがブラウザのローカルストレージだけでなく、自動的にMySQLデータベースに保存されるようになったことだ。これにより、データが失われるリスクが減り、さらに各キャラクターに対して最大15世代分の履歴を自動で保存し、バージョン管理を行う機能が実現された。

二つ目のパスは、他の人が作成したモデルをインポートする方法である。既存の資産を活用することで開発の手間を省くためのアプローチだ。GLBやVRM形式のファイルはそのまま取り込める。FBXやOBJといった形式は、ブラウザ内またはサーバー側でヘッドレス（画面表示なし）のBlenderをCPUで実行してGLB形式に変換される。また、KayKitのアセットパックも利用でき、これらは共有アニメーションクリップをライブラリ全体に提供する。このパスの技術的に興味深い点は、リグの検出とリターゲットの処理である。様々なソースのリグは異なるボーン名を持っているため、システムはそれらに対して名前ベースのボーン検出を試み、認識できない場合は階層構造を辿る代替策を用いる。リグが特定されると、アニメーションクリップがモデルごとに一度だけワールド空間で調整され、モデルごとの手動でのリターゲット作業なしにアニメーションが正確に再生される。実運用上の細かな工夫として、VRM以外のモデルの半透明描画問題に対し、強制的に不透明マテリアルを適用し、切り抜きが必要なテクスチャのみアルファテストを行うというシンプルな解決策が採用された。

三つ目のパスは、プログラムによってクリーチャーを生成する方法である。クリーチャーラボでは、ファイルをインポートするのではなく、タイプ、シード、スライダーといった簡単なパラメータから、ロボット、ゴブリン、エイリアン、四足動物などをブラウザ内でリアルタイムに生成する。サーバーとの通信は一切なく、ファイル入出力や変換、リグ検出といった処理も不要であるため、四つのパスの中で最も効率的でコストがかからない。

四つ目のパスは、CPUに人間を生成させる方法である。これは、通常GPUが必要だと考えられがちな処理をCPUのみで実現している点で注目される。一つは、BlenderとMPFB2アドオンを使ったリアルな人間生成だ。専用のワーカーサーバーが、ヘッドレスのBlender 4.5.14とMPFB2アドオンを純粋なCPUレンダリングで実行し、完全にリグ付けされた人間メッシュを生成する。この処理には数分かかるが、完了すると自動的にライブラリに格納される。もう一つは、写真から3Dモデルを再構築する機能である。ユーザーが写真をアップロードすると、まずrembgが背景を削除し、次にTripoSRがその一枚の画像からCPUモードのPyTorchを使って3Dメッシュを再構築する。最後に、自動リガーが骨格を追加する。これは未来的な機能で、体の形状は概ね良好だが、顔や手のディテールは完璧とは言えない。しかし、専用のハードウェアなしで、数分で写真をゲームのアクターに変えるパイプラインとしては非常に画期的なものだ。これらの処理は、ジョブをキューに入れてポーリングし、HTTP接続を維持せず、結果は自動的にライブラリにコミットされるという仕組みで運用されている。

このシステムでは、言語（Ollamaによるキャラクターの性格生成）、画像（PyTorchとdiffusersによる服装の生地生成やAIポートレート）、3D（Blender+MPFB2、TripoSR、rembgによる人間生成、写真から3D変換）という三つの異なる種類のAIが、わずか11GBのRAMを持つ一つのCPU環境で動作している。これらは同時に実行されるのではなく、明示的に順番に処理が行われる。例えば、3Dや画像生成がメモリを多く必要とする場合、言語モデルは一時的にアンロードされる。これは、GPUなしで複数のAIを動かす方法に対する具体的なエンジニアリングの回答であり、個々の処理を高速化するのではなく、同じメモリ領域を巡ってAI同士が競合しないように管理することで、限られたリソース内で多様なAIタスクを実現しているのだ。

このシステムが示唆する最も重要なエンジニアリングのポイントは、「いかにして3Dキャラクターを生成するか」という個別の問題から、「いかにしてGPUに依存しない四つの全く異なる生成方法が、同じデータベース内で同じ種類の『市民』（キャラクター）を生み出すようにするか」という問題へと焦点が移ったことである。彫刻、インポート、プロシージャル、AI再構築といったどのパスで作成されたキャラクターも、種類、作者、サムネイル、タグ、フォルダ、お気に入り、そしてバージョン履歴といった情報を持つデータベースの行として管理される。ゲームエンジンが利用する「アクター」インターフェースと、ライブラリが共有するスキーマ（データの構造）は、どちらも「契約を一度定義し、その契約をあらゆる生成元が独立して満たすようにする」という同じ考え方を適用したものだ。この設計により、モーフベースの彫刻とは全く異なるパイプラインを持つ写真からの3D再構築モデルでも、ゲームのキャラクターリストに「他のキャラクターと同じように」表示され、ゲームエンジン側で特別な処理を施す必要が一切なくなる。

現状にはまだ改善の余地がある点も存在する。写真からの3D再構築の品質はまだ粗く、顔や手のディテールは近似レベルである。MPFB2による人間生成やTripoSRによる再構築は、いずれも完了までに数分を要し、画像ワーカーと同じRAMを競合して使用する。インポートされた特殊なリグは構造検出に頼るため、アニメーションが完璧ではない場合もある。また、ブラウザ側のエディターでは、モーフやスキンニングの計算がいまだにJavaScriptでCPU上で行われている。しかし、これらはシステムの根幹を揺るがす問題ではなく、専用のグラフィックアクセラレータを持たないという制約の中で、高い目標を掲げた際に生じる通常の課題であり、今後の開発ロードマップに含まれている。

このニュース記事から得られる重要な教訓は、複数のソースからコンテンツを取り込むシステムを構築する場合、その教訓は3Dキャラクターに限らず汎用的に適用できるということだ。すなわち、「コンテンツタイプ」をそれぞれが知る複数の独立したパイプラインを構築するのではなく、どのようなパイプラインでも満たせる単一のインターフェースを構築することである。これにより、多様なソースからのコンテンツが、保守の負担ではなく、システムの強みとなる。そして、何かの処理にGPUが必須だと決めつける前に、実際に検証してみるべきだ。このシステムで使われているAIモデルは、全て意図的にCPUでの推論（計算）に耐えるように選定されている。クリーチャーラボで生まれたゴブリンと、写真から再構築された人間は、内部構造的にはほとんど共通点がないが、このシステムでは同じゲーム内で並び立ち、同じ行動をとり、ゲームエンジンもデータベースも、そして一台のGPUも、彼らが異なる方法で作られたことを知る必要が全くないのだ。