ポイント
- OpenUSDを使うと、複雑な3Dシーンを組み立てたり、制作部門やソフトをまたいで共有したりしやすくなります。
- Fortune Business Insightsによると、世界の3Dデジタルアセット市場の規模は2025年に324億7,000万ドルで、2026年には367億2,000万ドルに達する見込みです。
- Alembic、FBX、glTF、MaterialX、OpenEXR、OpenVDBなどのファイル形式にも、それぞれ得意なデータや用途があるため、制作現場では今でも重要です。
- ファイル形式を選ぶときは、何のデータを引き継ぎたいか、受け渡した後も編集するか、次にどの工程で使うかを考えることが大切です。
要約
3D制作では、工程によって必要なデータが異なるため、複数のファイル形式を使い分けます。OpenUSDはシーンの構成や管理、Alembicはアニメーションを含む形状データの受け渡し、FBXは3Dデータの幅広い受け渡し、glTFはゲームやWebなどで表示するためのデータの配布に向いています。マテリアルにはMaterialX、煙や雲などのボリュームデータにはOpenVDB、レンダリング画像にはOpenEXRが使われます。また、制作中は各ソフト独自のプロジェクトファイルも欠かせません。プロの制作現場では、一つの形式で済ませるのではなく、目的に応じて組み合わせて使っています。
プロの3D制作でファイル形式が重要な理由
3D作品は、モデリング、リギング、アニメーション、シミュレーション、ライティング、レンダリング、コンポジットなど、いくつもの工程を経て完成します。工程ごとに担当者や使用するソフトが異なることもあるため、必要な情報を失わずにデータを受け渡すことが重要です。

3Dコンテンツの活用が広がるにつれ、こうしたデータの受け渡し形式はますます重要になっています。Fortune Business Insightsによると、世界の3Dデジタルアセット市場は2025年に324億7,000万ドルの規模となり、2026年には367億2,000万ドルに達する見込みです。映画やアニメーション、ゲーム、建築などのビジュアライゼーション、シミュレーション、インタラクティブコンテンツなど、さまざまな分野で3D制作が進むほど、制作工程の間でデータを確実に受け渡す方法はとても重要です。
.blend、.ma、.mb、.max、.c4dなど、各ソフト固有のファイル形式には、そのソフトで使う機能や設定を保存できます。一方、ソフト間の受け渡しに使うファイル形式は、必要なデータを別のソフトへ移すことを目的としています。
OpenUSDとは?
OpenUSDは、複雑な3Dシーンを記述・構成し、ソフトや制作チームの間で共有するためのオープンな仕組みです。名称に含まれるUSDは「Universal Scene Description」の略で、もともとは多くのアーティストや部門が一つのシーンを共同で制作できるよう、Pixarが開発しました。
OpenUSDでは、モデルの形状やアニメーション、位置・回転・大きさ、マテリアル、参照ファイル、バリエーションなどの情報を、一つの大きなファイルにまとめずに管理できます。素材ごとのデータを別々に保存したまま、一つのシーンとして組み合わせられます。
OpenUSDとUSDの違い
USD(Universal Scene Description)は、3Dシーンを表現する仕組みやデータの構造を指します。一方、OpenUSDは、その技術を公開・開発するオープンソースのプロジェクトや、関連するツールを含めて指す言葉です。
2025年12月には、Alliance for OpenUSD(AOUSD)が「OpenUSD Core Specification 1.0」を正式に承認しました。この仕様では、USDのデータ構造やシーンを組み合わせる仕組み、設定値の決まり方、基本的なファイル形式などが定義されています。
USDで使われる主なファイル形式は、次の4つです。
- .usd:USDファイルに使われる一般的な拡張子。
- .usda:テキスト形式で保存されるため、内容を読んで確認できる。
- .usdc:バイナリ形式で保存され、シーンのデータを効率よく読み込める。
- .usdz:USDのデータと関連する素材を一つにまとめて扱える形式。
大規模な制作でOpenUSDが役立つ理由
OpenUSDの大きな強みは、別々のファイルにあるデータを組み合わせて、一つのシーンを作れることです。モデルやアニメーション、マテリアルをすべて同じファイルにコピーする必要はありません。それぞれのデータを別々のファイルから参照し、一つの大きなシーンとして組み合わせられます。
「USD(Universal Scene Description)を使った制作フローを取り入れていなければ、これほど多くの要素をシーンに盛り込むことはできなかったでしょう」――グレン・メレンホースト『ジュマンジ/ウェルカム・トゥ・ジャングル』VFXスーパーバイザー(Art of VFXより)
例えば『ジュマンジ/ウェルカム・トゥ・ジャングル』では、メレンホーストらが岩や木々など、数百万もの要素からなる峡谷をフルCGで制作しました。環境全体を一度に読み込むにはデータが大きすぎたため、作業中は簡略化した地形を使用し、操作が必要な要素を制作工程の各段階からUSDシーンへ受け渡していました(Art of VFXより)。
レイヤーを使えば、作業内容ごとにデータを分けることもできます。例えば、元のデータを直接変更せずに、一方でアセットを更新し、もう一方で照明や配置を調整できます。また、バリアントを使うと、マテリアルや形状、構成が異なる複数のバージョンを、一つのアセットに用意できます。
そのため、OpenUSDは特に次のような用途に適しています:
- 広大な背景や複雑なショットの制作
- 複数の部門が関わる制作
- アセットの再利用やシーンライブラリの構築
- 製品の構成違いの管理
- シミュレーションや可視化のワークフロー
- 多数のシーン要素を整理して管理する必要があるプロジェクト
アニメーションやジオメトリをベイクして受け渡すためのAlembic
Alembicは、一般に.abc形式で保存される、ジオメトリのキャッシュに適した形式です。アニメーションやシミュレーションの処理手順をすべて保持するのではなく、処理後のジオメトリを保存します。
「FBXやAlembicのような業界標準の形式のおかげで、世界中の制作スタジオがカメラトラッキングのデータからシミュレーションのキャッシュまで、さまざまなデータを容易にやり取りできるようになりました」――フランソワ・デュムラン『ファンタスティック・フォー』VFXスーパーバイザー、(Art of VFXより)
例えば、あるソフトウェアで作成した布のシミュレーションをAlembic形式で書き出し、別のソフトウェアに渡してライティングやレンダリングを行えます。受け取る側は、元のシミュレーションの設定がなくても、動きの付いたジオメトリを利用できます。
Alembicは、一般に次のような用途で役立ちます。
- 布や髪のシミュレーション
- 変形するメッシュ
- アニメーション付きのジオメトリ
- データ量の多いプロシージャルなシーン
- レンダリング用にキャッシュしたアセット
一般的なアセットの受け渡しに使うFBXとOBJ
FBXは、3D制作ソフトウェア間でデータを受け渡す際に広く使われる形式です。ソフトウェアや書き出し設定によって、メッシュ、アニメーション、骨格情報、カメラ、ライト、マテリアルなどのシーンデータを含められます。

そのためFBXは、キャラクターアニメーションやモーションキャプチャ、ゲーム開発のほか、Maya、3ds Max、Blender、ゲームエンジンなどの間でアセットを受け渡す際によく使われます。ただし、複雑なプロシージャル処理やレンダラー固有のマテリアルは、完全には引き継げない場合があります。実際の制作で使用する前に、書き出したデータを読み込んで問題がないか確認することが大切です。
当社でレンダリングを行ったスタジオの事例を見ると、このようなデータの受け渡しが実際の制作でなぜ重要なのかが分かります。例えば、Classic Colorでは、非常に高密度なCADモデルをModoで扱うことが難しくなっていました。そこで、アセットをFBX形式で書き出してBlenderに読み込み、ジオメトリの確認や編集をしやすくしました。そしてその後、このスタジオではBlenderを普段の制作にも使うようになりました。
この事例から、データ交換形式の役割はソフトウェア間の互換性のためだけではないことが分かります。次の制作に適したソフトウェアへアセットを移すための、手段になる場合もあるのです。
OBJはFBXよりもシンプルな形式で、主に静的なポリゴン形状の受け渡しに使われます。テクスチャ座標や面の法線、基本的なマテリアルへの参照も記録できます。アニメーションやリグ、複雑なシーン構成を含めず、メッシュだけを別のソフトウェアに移したい場合に便利です。
リアルタイム用途への受け渡しに使うglTFとGLB
glTFは、3Dアセットを効率よく転送・読み込みできるよう設計された形式です。Web上の3Dビューアーやインタラクティブなコンテンツ、製品の3D表示、モバイルアプリなど、ユーザーが実際にコンテンツを操作・閲覧する環境でよく使われます。
.gltfファイルにはシーンの構成が記述され、関連するデータは別ファイルに保存することも、ファイル内に埋め込むこともできます。一方、.glbファイルはアセットを一つのバイナリファイルにまとめるため、配布しやすくなります。
OpenUSDが制作やシーンの組み立てに大きな役割を果たすのに対し、glTFは完成したアセットを届ける段階で使われることが多い形式です。インタラクティブなアプリやビューアーで、アセットを効率よく読み込ませたい場合に適しています。
マテリアルとルック開発に使うMaterialX

アプリケーション間で形状データを受け渡せても、マテリアルまで正しく引き継がれるとは限りません。あるレンダラー向けに作成したシェーダーには、別のレンダラーが対応していないノードや機能が含まれている場合があります。
MaterialXは、マテリアルやシェーディングネットワーク、テクスチャ、ルック開発に関する情報を記述するためのオープンな標準規格です。対応するアプリケーション同士で共通の記述を利用できるため、異なるツールやレンダリングシステム間でもマテリアルを受け渡しやすくなります。
MaterialXは、特に次のような場合に役立ちます:
- アセットを複数のレンダラー間で受け渡す場合
- 再利用できるマテリアルライブラリを作りたい場合
- 制作工程全体でマテリアルの定義を統一したい場合
- OpenUSDと併せてマテリアルデータを扱う場合
レンダリング画像データに使うOpenEXR
OpenEXRは、一般に.exr形式で保存され、プロの現場でのレンダリングやコンポジットに広く使われています。高ダイナミックレンジの画像データに加え、複数のチャンネルやパート、メタデータなど、ポストプロダクションで役立つ情報も保存できます。
レンダラーは、メインの画像に加えて、AOVや各種パスも保存できます。ライティング情報、深度、マスク、サーフェス情報などを個別のチャンネルとして保持できるため、すべてを一枚の画像に統合してしまうのではなく、コンポジットの段階で調整できます。
ボリュームエフェクトに使うOpenVDB

OpenVDBは、3次元グリッド上の密度がまばらなボリュームデータを効率よく扱うために設計された形式です。煙や炎、雲、霧、爆発などのエフェクトによく使われます。
VDBファイルを使えば、ボリュームシミュレーションの結果を対応するアプリケーション間で受け渡せます。例えば、あるソフトウェアで制作した煙をOpenVDB形式で保存し、別のソフトウェアに読み込んでライティングやレンダリングを行えます。
OpenVDBもAlembicと同様に、データを生成した仕組み全体ではなく、計算済みの結果を受け渡すためによく使われます。
各ソフトウェア固有のファイル形式も重要
データ交換用の形式は重要ですが、アセットの制作中は、それぞれのソフトウェア固有のプロジェクトファイルも欠かせません。Blenderでは.blend、Mayaでは主に.maや.mb、3ds Maxでは.max、Cinema 4Dでは.c4dが使われます。
こうしたソフトウェア固有のファイルには、モディファイア、リグ、プロシージャルな仕組み、アプリケーションの設定、編集可能な作業履歴など、制作時の設定をまとめて残せます。アセットを次の制作段階へ渡す際には、必要なデータを選び、USD、Alembic、FBX、MaterialX、OpenVDBなど、用途に合った形式で書き出せます。
制作現場での各形式の使い分け

プロの制作現場では、一つの形式ですべての作業をまかなうことはほとんどありません。通常は、各部門の作業に合わせて複数の形式を使い分けます。
3D制作パイプラインでは、ファイル形式を一つに統一するよりも、作業の段階や担当する部門に応じて、それぞれに適した形式を組み合わせて使うのが一般的です。
実際にレンダリング用のデータを受け渡す際は、ファイルを一つ選べばいいというものでもありません。当社がレンダリングを担当する案件でも、ソフトウェア固有のプロジェクトファイルのほかに、連番テクスチャやVDBデータ、シミュレーションのキャッシュ、参照している別のシーンなどが必要になる場合があります。
だからこそ、「最適な3Dファイル形式は何か」と一括りに考えるより、「この作業にはどの形式が適しているか」と考えるほうが実用的です。例えば、編集するシーン、キャッシュしたジオメトリ、ボリュームデータにはそれぞれ別の形式を使い、最終的なレンダリング画像はOpenEXRで保存する、といった使い分けができます。
例えば、キャラクターをMayaのプロジェクトファイルで制作し、完成したアニメーションをAlembicでキャッシュします。そのキャラクターを、背景や小道具とともに、より大きなOpenUSDシーンに参照として組み込めます。さらに、完成したキャラクターをWebサイト上のインタラクティブなビューアーで見せる場合は、glTFやGLB形式に変換できます。このように、一つの制作の中でも、工程ごとに異なる形式を使い分けます。
3Dファイル形式でよくある疑問と問題
二つのソフトウェアが同じファイル形式に対応していても、データを必ずしも完全に受け渡せるとは限りません。特によく起こる問題には、次のようなものがあります:
- 書き出した後にマテリアルの見た目が変わるのはなぜ? マテリアルには、特定のソフトウェアやレンダラーでしか使えないノードが含まれている場合があります。そのため、形状は正しく受け渡せても、シェーダーやテクスチャの設定が引き継がれなかったり、マテリアルの見え方が変わったりすることがあります。
- モディファイアやプロシージャルな設定、リグが消えたのはなぜ? 多くのデータ交換形式は、制作時の設定をすべて保存するのではなく、完成した形状や動きなどの結果を保存します。例えばAlembicでは、動きの付いたジオメトリをベイクして受け渡せますが、元のシミュレーション設定やモディファイア、プロシージャルな操作項目までは保持されません。
- 別のソフトウェアに移すとアニメーションが崩れるのはなぜ? ソフトウェアによって、リグやコンストレイント、変形、アニメーションの処理方法が異なるためです。骨格を使ったアニメーションの受け渡しにはFBXがよく使われます。一方、最終的な形状の動きを書き出す前にベイクできる場合は、Alembicが役立ちます。
- 読み込んだモデルのサイズや回転、向きが変わるのはなぜ? ソフトウェアによって、使用する単位や座標系、軸の向きが異なるためです。別のツールにアセットを移す際は、書き出し時と読み込み時の設定を調整する必要がある場合があります。
- ファイル形式を変換しても、すべての情報を残せる? 必ずしも残せるとは限りません。変換後も保持できるのは、変換元と変換先の両方の形式が対応している情報です。プロシージャルな操作項目や複雑なマテリアル、ソフトウェア固有の機能、編集可能な作業履歴などは失われる場合があります。
- 書き出した後も、元のプロジェクトファイルは残しておくべき? 通常は残しておくべきです。.blend、.ma、.max、.c4dといった各ソフトウェア固有のファイルには、編集に必要な設定や情報を残せます。一方、書き出したファイルだけでは、元の設定が残らないことがあります。
レンダーファームに送るデータで気をつけること
レンダーファームでシーンを正しく読み込むには、メインのシーンファイルだけでなく、そのシーンが参照するテクスチャやキャッシュなどの外部ファイルも必要です。
.blend、.max、.ma、.c4d形式のプロジェクトは、制作者個人のPCでは正常に開けても、外部のテクスチャ、シミュレーションキャッシュ、VDBシーケンス、リンクされたシーン、プラグインなどに依存している場合があります。そのプロジェクトを別のPCやレンダーファームに移すときは、依存するファイルも一緒に移すか、移動先からアクセスできる状態にしておく必要があります。
たとえば、私たちのBlender用ワークフローでは、シーンで使うアセットを正しくリンクし、提出前に不足しているアセットがないか確認することを推奨しています。シミュレーションや物理演算のデータも、レンダリング前にキャッシュを作成し、正しくリンクしておく必要がある場合があります。
だからこそ、ファイル形式を適切に選ぶだけでは、確実にデータを引き渡せません。制作の現場では、そのファイルが外部のどのデータを参照しているかを把握することも、同じくらい重要です。
まとめ

プロの3D制作では、用途に合わせてファイル形式を選ぶことが大切です。OpenUSDは複雑なシーンの記述や構成に適した枠組みです。一方、Alembic、FBX、glTF、MaterialX、OpenEXR、OpenVDBなどは、それぞれ制作工程のより専門的な用途を担います。
各形式でどのデータを保持できるかを理解しておけば、重要なデータを失わずに、モデリング、アニメーション、シミュレーション、レンダリング、コンポジット、最終納品の各工程へアセットを引き継ぎやすくなります。複数のツールを使うスタジオにとって、ツール間でアセットを受け渡せる柔軟性は、信頼できる3D制作パイプラインを築くうえで特に重要です。
今すぐ登録して、$50分の無料クレジットをゲット!






