← AI 3Dワークフロー

AI 3Dアセットパイプラインを​工程ごとに​解説

AI 3Dアセットパイプラインとは、制作指示書をエンジン対応の3Dアセットに変えるために、生成と最適化の工程を決まった順に並べたものです。コンセプト画像、3D再構成、ウォータータイト化、トライアングル数の上限に合わせたリトポロジー、UV展開、PBRテクスチャリング、キャラクター用のリグ、LOD、そして来歴を付けたGLB書き出しへと続きます。

どの工程も、次の工程が必要とするものを出力します。1つ飛ばしても時間の節約にはなりません。問題が後工程に先送りされるだけで、たいていはエンジンへのインポート時か、アートディレクターの最初のレビューで表面化します。

Atlasで試す

最終確認日

単体の​生成ツールではなく​パイプラインを​使う​理由

このガイドでは各工程を順に、仕組みのレベルで見ていきます。それぞれが何を出力し、欠けると何が壊れ、エンジンが実際にどんな数値を求めるのか。実例はゲーム制作のためのAI 3Dアセットパイプラインです。ワークフローの全カタログと、そもそもパイプラインを回すべき理由はAI 3Dワークフロー一覧にまとめています。

生成ツールは、プロンプト1つにつきメッシュを1つ返します。パイプラインは、同じ入力でグラフを実行するたびに同じメッシュを返します。指定した上限に合わせてリトポロジーし、確定済みのアートディレクションに沿ってテクスチャを付け、エンジンが読める履歴とともに書き出します。再現性、アートディレクション、出力の上限、来歴。スタジオが対価を払うのはこの部分であり、どれも単一のAIモデルの中にはありません。

Atlasキャンバス上のプロップ用ワークフロー。左から順にInput Text、Text Generation (LLM)、Text to Image、Remove Image Background、Tripo3D v3.1によるImage to 3D、Meshy RemeshによるOptimize Meshと続き、SFブラスターを出力
パイプラインを1本のグラフにしたもの。スタイライズ系のSFブラスターを求める1行のリクエストが左から入り、各ノードが出力を次へ渡して、右端から最適化済みのメッシュが出てきます。

12の​工程と、​それぞれが​欠けると​壊れるもの

この表は上から下へ、依存関係の連鎖として読んでください。各工程が使えるのは、すぐ上の工程が出力したものだけです。一般的な目標値は、Atlasのワークフローが合わせている値です。実際の数値はエンジン、プラットフォーム、描画負荷の上限によって決まり、何かを生成する前に制作指示書に書いておくべきものです。

工程出力欠けると起きること一般的な目標値
制作指示書とリファレンス仕様シート:エンジン、トライアングル数の上限、テクスチャサイズ、スタイルのリファレンス、スケールとピボットのルール上限が生成後に決まり、後続の工程がすべてやり直しになるアセットの系統ごとに指示書を1つ作り、バッチ全体で使い回す
コンセプト画像承認済みの2Dルックデブレンダーアートディレクションの判断が、変更コストが最も高いテクスチャ付きメッシュの段階にずれ込む方向性ごとにレンダー1枚、デモワークフローでは1枚15〜30秒
3D再構成トポロジーが整理されていない高密度の生メッシュなし。この工程は省略できない高密度メッシュ、上限はまだない
ウォータータイト化閉じたマニフォールドのシェル穴や反転した法線でリトポとUV展開が失敗し、ベイクに黒く抜けた部分が出る開いたエッジ0、法線の向きが揃っている
リトポロジー上限内に収まり、形に沿ったエッジフローを持つクリーンなメッシュ描画負荷の上限超過、スキニングの破綻、インデックスバッファの上限到達モバイル約5kトライアングル、コンソール約20k、PC約50k
UV継ぎ目とパディングを含む0〜1の展開レイアウトテクスチャの行き場がない。ベイクに継ぎ目が出る実行の中でリトポ後に展開
PBR​テクスチャリングベースカラー、ラフネス、メタリック、ノーマル。ベイクした場合はハイトとAOエンジンのライティング下でのっぺり見え、マテリアルが正しく割り当てられないモバイルは1Kテクスチャ、コンソールとPCは2K
リギング(キャラクターのみ)ヒューマノイドのスケルトン、スキンウェイト、基本アニメーションクリップキャラクターが動かないプロップになるスケルトンとクリップをメッシュと同じGLBに格納
LOD距離に応じてトライアングル数を減らしたコピー遠くのオブジェクトもフルコストで描画される5k / 3k / 1kトライアングル(WebGL)、20,000 / 7,500 / 2,500面(UEFN)
書き出しメッシュ、マテリアル、テクスチャ、スキン、アニメーションをすべて含む1つのGLBばらばらのファイル、欠けたテクスチャ、リグを格納できないフォーマットGLB。FBXはプラットフォームが求める場合のみ
エンジンへのインポートマテリアルが割り当てられたプレハブ、シーン、またはアクタースケールの誤り、上方向の軸の誤り、割り当てられていないマテリアルエンジン標準のインポーター、またはエンジン独自のインポートパッケージ
承認と来歴検証可能な履歴を持つ承認済みアセットアセットごとにスタイルがぶれ、IPの問題が起きても監査証跡がないすべてのアセットが履歴を持ったままエンジンに入る

制作指示書は、​すべての​工程が​参照する​仕様シート

ターゲットエンジン、トライアングル数の上限、テクスチャ解像度、アートディレクターが承認したスタイルのリファレンス、エンジンが前提とするスケールとピボットの規約。Atlasでは、こうしたコンテキストはグラフの中、つまりノードのシステムプロンプトと、実行に添付したリファレンスにあります。そのため、プロンプトごとに書き直さなくても、すべての実行がそれを引き継ぎます。これがないと、メッシュができてから上限が決まり、チェーン全体をもう一度回すことになります。

具体的な規約を1つ挙げます。UEFNキットは512cmグリッドに合わせてスケールし、ピボットは底面中央です。これは制作指示書の段階で決めておくべき情報です。この情報なしで届いたメッシュは、1つずつ手作業で配置することになります。

メッシュより​先に​コンセプト画像を​生成する​理由

コンセプトレンダーは、パイプラインの中でアートディレクションを考え直すのに最もコストが低い段階です。デモワークフローでは、2Dルックデブレンダーにかかるのは15〜30秒。再構成には1〜2分、テクスチャリングにさらに1〜2分かかります。ルックを2Dで承認しておけば、コストの高い工程は1回で済みます。ここを飛ばすと、アートディレクターがテクスチャ付きのメッシュを見てマテリアルの方向性を差し戻し、再構成、リトポロジー、ベイクがすべてやり直しになります。

このレンダーはどのみち後で再利用されます。PBRのベイクがこれを参照するので、完成したメッシュは新しいプロンプトの結果ではなく、承認された画像どおりの見た目になります。

Atlasキャンバス上のコンセプト工程。Input Textノード、リクエストを「単色の明るいニュートラルグレー背景に置いた単体のアセット」のプロンプトへ展開するText Generation (LLM)ノード、レンダリングされたブラスターを表示するText to Imageノード
コンセプト工程。LLMが1行のリクエストを詳細なプロンプトに展開し、画像生成AIモデルがそれをレンダリングします。再構成にはニュートラルな背景の入力を渡してください。ここではプロンプトで明示的に指定しています。

3D再構成は​どのように​画像を​メッシュに​変えるのか

再構成AIモデルはコンセプト画像を読み取り、見えない部分の形状を推定して、大まかな表面色を持つトポロジーが整理されていない高密度のトライアングルメッシュを出力します。ライブラリにはAtlasが開発したTitan v1を含む複数の再構成AIモデルがあり、ワークフローでそれらをフォールバックとして連結すれば、実行が失敗したときに次のAIモデルで再試行できます。ここで出てくるのはあくまで出発点で、上限も、きれいなエッジフローも、使えるUVもありません。

ここでは3つの問題が起きます。細かなディテールが潰れ、非対称の物体に存在しない対称性が生まれ、裏側は推測で埋められます。正面と側面から形がはっきり読み取れるコンセプトをニュートラルな背景で用意すれば、3つとも減らせます。これがコンセプト工程を置くもう1つの理由です。使われるAIモデルはAIモデルのページに一覧があります。

再構成したSFブラスター。テクスチャ付きの状態の横に生のワイヤーフレームがあり、密度が高すぎてトライアングルが白い一つのシルエットに溶け込んでいる
再構成直後の生のメッシュ。形と表面色はできていますが、トライアングル数が多すぎてワイヤーフレームが塗りつぶしたシルエットに見えます。

ウォータータイト化で​直るもの

シェルを閉じる工程です。穴を埋め、ノンマニフォールドのエッジと内部シェルを取り除き、法線の向きを揃え、自己交差を解消します。結果として、開いたエッジのない1つの閉じたサーフェスができます。

リトポロジー、UV展開、テクスチャのベイクは、どれもこのサーフェスを前提にしています。穴や反転した法線があるメッシュにかけると、リトポツールはでたらめなエッジフローを作り、UV展開は裂け、ノーマルベイクはレイを虚空へ飛ばして黒く抜けた部分を返します。エンジンも同じ前提に立っています。コリジョン生成は閉じたボリュームを想定しており、シェルが開いていると、キャラクターが木箱をすり抜けて落ちる原因になります。

生成した​メッシュに​リトポロジーが​欠かせない​理由

リトポロジーは、高密度の再構成メッシュを、決められたトライアングル数のクリーンなメッシュとして作り直し、エッジループを形に沿わせます。Atlasのワークフローは、指定した上限に合わせてリトポロジーとポリゴンリダクションを行います。目安はモバイルで約5k、コンソールで20k、PCで50kトライアングルです。これがないと、生のメッシュが描画負荷を食いつぶし、リグで変形させると崩れ、エンジン標準のインデックスバッファが許す頂点数を超えることもあります。

最後の上限には具体的な数値があります。Unity標準のインデックスバッファは16ビットで、1メッシュあたり65,535頂点が上限です。32ビットインデックスを使えば上限は上がりますが、すべてのモバイルGPUで対応しているわけではありません。生の再構成メッシュはこの線を超えることがあります。リトポロジー済みのプロップが超えることはありません。

変形するものには、クアッドが重要です。静的なプロップなら、上限内のクリーンなトライアングルメッシュが目標です。そのためデモワークフローでは、結果を約35kのクアッド/トライアングル数の上限として示しています。この工程単体についてはゲームアセット向けAIリトポロジーで解説しています。

リトポロジー後の同じSFブラスター。テクスチャ付きの状態の横に、トライアングルが1つずつはっきり見える最適化後のワイヤーフレーム
Optimize Meshノードを通した同じブラスター。シルエットはそのままで、トライアングル数はエンジンが扱える範囲に収まっています。

出典:Unity scripting reference, Rendering.IndexFormat(英語)(2026年9月時点)。

UVの​役割と、​UVが​ないと​壊れるもの

UVは、メッシュ上のすべての点を、0〜1の平らなテクスチャ空間上の位置に対応させます。継ぎ目は目立たない場所に置き、フィルタリングで色がにじまないようアイランドの間にパディングを取ります。PBRセットのテクスチャはすべて、このレイアウトの上に描かれるかベイクされます。UVがなければ、テクスチャの行き場はありません。UVが悪ければ、ノーマルマップに継ぎ目が出て、アセット内でテクセル密度がばらつき、ミップマップで隣り合うアイランド同士がにじんで混ざります。

AtlasではUV展開を後からDCCツールで行うのではなく、実行の中で、リトポロジーの後、ベイクの前に行います。ここでは順番が重要です。高密度メッシュを先に展開してからポリゴンリダクションをかけると、レイアウトは失われます。

PBRテクスチャセットの​条件と、​エンジンが​重視する​理由

PBRセットは、描き込んだハイライトではなく、エンジンのライティングが計算できる値で表面を記述します。Khronosの仕様書「glTF 2.0 specification」は、メタリック・ラフネス方式を、ベースカラー、非金属0.0から金属1.0までのメタルネス、滑らか0.0から粗い1.0までのラフネスで定義しており、それぞれ係数、テクスチャ、またはその両方で指定できます。Atlasのワークフローは、ベースカラー、ラフネス、メタリック、ノーマルを出力し、ワークフローがベイクする場合はハイトとアンビエントオクルージョンも出力します。

解像度はプラットフォームに合わせます。モバイル向けの設定では1Kテクスチャ、コンソールとPCでは2Kです。この工程を飛ばすと、エンジンのライティング下でアセットがのっぺり見え、金属と塗装の区別がつきません。

出典:glTF 2.0 specification, §3.9.2 Metallic-Roughness Material(英語)、バージョン2.0.1(2026年9月時点)。

リグが​必要なのは​変形するものだけ

キャラクター、クリーチャー、手足や顔のあるものすべて。リグは、スケルトンと、各頂点を1つ以上のボーンに結び付けるスキンウェイトでできています。Atlasのキャラクター用ワークフローは、ヒューマノイドのスケルトン、スキンウェイト、基本的なアニメーションクリップを、メッシュと同じGLBに入れて出力します。プロップはこの工程をまるごと飛ばします。ウェイトが悪いキャラクターは、肘がキャンディの包み紙のようにねじれてつぶれます。

ウェイトにも上限があります。Unityのキャラクターモデリングのガイドは、1頂点あたりのインフルエンスを最大4つに抑えたリニアブレンドスキニングを推奨し、パフォーマンスのためにボーン数を減らすよう勧めています。リギングはリトポロジーの結果にも左右されます。ヒューマノイドのスケルトンは関節にエッジループがあることを前提としますが、生の再構成メッシュにはそれがありません。

出典:Unity Manual, Modeling characters for optimal performance(英語)、Unity 6.6(2026年9月時点)。

LODとは​何か、​アセットに​いくつ​必要か

LOD(Level of Detail)は、同じアセットのトライアングル数を減らしたコピーで、画面上でオブジェクトが小さくなるにつれてエンジンが差し替えます。Unityはこの手法を、描画の負荷を減らしてパフォーマンスを高めるものと説明しています。Atlasでは、LODの工程を含むワークフローでこれを生成します。WebGLパイプラインではおよそ5k、3k、1kトライアングル、UEFNキットでは20,000、7,500、2,500面です。LODがないと、遠くのプロップも手前のヒーローアセットと同じコストがかかります。

LODは生のメッシュではなくリトポロジー後のメッシュから作り、各段階がUVを保つので、1つのテクスチャセットですべての段階をまかなえます。一般的なのは3段階です。切り替え距離を決めるのはアセットではなく、エンジン側のLODグループです。

定義の出典:Unity Manual, Level of detail(英語)、Unity 6.6(2026年9月時点)。

GLB書き出しに​実際に​含まれるもの

メッシュ、マテリアル、テクスチャ、スキン、アニメーションクリップを、すべて1つのバイナリファイルに収めます。Khronosの仕様書「glTF 2.0 specification」は、これをJSON、バッファ、画像を含むアセット全体を単一のバイナリBLOBに格納できるコンテナとして紹介しています。拡張子は.glb、登録済みのメディアタイプはmodel/gltf-binaryです。AtlasのワークフローはPBRマテリアルをメッシュに埋め込んだGLBを書き出します。

GLBでなければファイルはばらばらになります。アセットパックを受け取ったことがある人なら覚えのある失敗です。テクスチャのないメッシュ、あるいはパイプラインが作ったものを格納できないフォーマット。Godotのインポートのドキュメントには、OBJはスキニング、アニメーション、UV2、PBRマテリアルに対応しないと書かれています。プラットフォームが別のフォーマットを求める場合は、ワークフローがそれで書き出します。UEFNキットはFBXを出力します。

出典:glTF 2.0 specification, §4 GLB File Format(英語)、バージョン2.0.1、Godot docs, Available 3D formats(英語)、Godot 4.7(いずれも2026年9月時点)。

エンジンへの​インポートで​制作指示書が​試される

エンジンはGLBを読み込んでメッシュアセットを作り、メタリック・ラフネスのマテリアルを独自のシェーダーに割り当て、スケルトンとクリップがあればそれも作成します。Godotは.glbを直接読み込み、Khronosの標準3D形式(GLBはそのバイナリ版)を推奨のインポート形式としています。Unityは専用パッケージのcom.unity.cloud.gltfastで読み込みます。Unreal Engine 5(アンリアルエンジン5)、Roblox Studio、UEFNにはそれぞれ独自の経路があります。この段階で問題になるのは、ほぼ必ずスケール、上方向の軸、または割り当てられていないマテリアルです。

Atlasの出力は、Unity、Unreal Engine 5、Godot、Roblox Studio、UEFN、そしてThree.js、Babylon.js、PlayCanvasといったWebGLフレームワークを対象にビルドとテストを行っています。GLBはキットバッシュ用にBlender、Maya、3ds Max、Cinema 4Dでも開けます。各ワークフローのページに、その出力がどの環境でテストされたかを記載しています。

出典:Godot docs, Available 3D formats(英語)、Unity package manual, com.unity.cloud.gltfast(英語)(いずれも2026年9月時点)。

最後に​承認と​来歴が​加えるもの

承認はアートディレクターのゲートです。アセットはプロジェクトに入る前に、制作指示書とリファレンスに照らしてチェックされます。来歴は、そこに至るまでの記録です。どのAIモデルが、どの入力と設定で、どのコンテキストのもとで実行されたか。Atlasでは、すべてのアセットが明確で検証可能な履歴を持ったままエンジンに入り、ワークスペースで実行できるAIモデルそのものを許可リストで決められます。これがないと、アセットごとにスタイルが少しずつぶれ、半年後にIPについて問われても誰も答えられません。

承認フローの結果は制作指示書にフィードバックされます。差し戻されたアセットはグラフが持つコンテキストを変え、次の実行がその修正を引き継ぎます。こうしてプロップのカタログは、プロンプトのたびにぶれることなく、1つのビジュアル言語にまとまります。

実際の​ワークフローでは​どうなるか

デモワークフローのゲーム制作のためのAI 3Dアセットパイプラインは、このチェーンのプロップ版を最初から最後まで実行します。入力はテクスチャのないクレイのプロトタイプです。ビジョンAIモデルが形状を読み取り、LLMがそれをルックデブ用のプロンプトに変え、画像生成AIモデルがコンセプトをレンダリングし、再構成AIモデルがメッシュを作り直し、約35kのクアッド/トライアングル数の上限でリトポロジーし、レンダーを基準に4KのPBRマップをベイクします。全体の実行時間は2〜4分で、出力はベースカラー、ラフネス、メタリック、ノーマルの各マップを備えたGLBです。

このデモはテクスチャ付きのメッシュで終わります。宝箱は変形しないのでリグはなく、LODの段階もありません(LODはWebGLとUEFNのワークフローで作ります)。ページに記載された工程ごとの時間は、ビジョン処理とプロンプト作成が5〜15秒、レンダーが15〜30秒、再構成が1〜2分、リトポロジーが30〜60秒、ベイクが1〜2分です。

パイプラインが​担う​範囲

エンジン対応の段階までです。ヒーローアセットの最終仕上げは、今もアーティストの仕事です。Atlasは、プロトタイピング、アートディレクションのイテレーション、プレイヤー主導のコンテンツのために作られています。こうした場面では、遅くて完璧なものより、速くて十分なもののほうが価値を持ちます。Atlasで作ったアセットはリリース済みのゲームに使われており、どこに仕上げ(ポリッシュ)の工程がまだ必要かは各ワークフローのページに記載しています。パイプラインは、上限に収まり、テクスチャが付き、記録の残ったメッシュを数分でチームに渡します。そのため、アーティストの時間をリトポではなく、人の手が必要な工程に使えます。

…Atlas AI Studioは、プロダクションで使えるAIワークフローに向けた重要な一歩です…
Jack Buser(ゲーム部門グローバルディレクター、Google Cloud)

パイプラインは​読むより​動かして​確かめる

ワークフロー一覧から選ぶか、デモワークフローを開いて手元のプロトタイプで実行してみてください。

新規登録