USD入門｜ゲームスタジオで何が変わるか・段階移行と現状
ここ数年、USD（Universal Scene Description） という単語をゲーム業界でも頻繁に耳にするようになりました。映像業界では Pixar 発の標準として定着していますが、ゲームスタジオに入れたら何が変わるのか──実務経験がないと、抽象的な理解にとどまりがちです。
本記事では、USD の主要概念（Stage / Layer / Prim / Composition Arcs）から、ゲームスタジオで採用するメリットとコスト、UE5 / Unity / Houdini の対応状況、段階的な移行ステップまでを、CG 経験はあるが USD は未経験という TA（Technical Artist：アーティストとプログラマの橋渡し役）・テクニカルディレクター（パイプライン全体を設計する技術責任者）層向けに整理します。
夕宮たいだふぁ……みんな〜、USD って最近よく聞くよねぇ。映像のひとたちはバリバリ使ってるみたいだけどぁ、ゲーム側ではどう関わるか、いっしょに整理していこ〜。
1. USD って何だっけ
ひとことで：複数DCCで一貫してシーンを記述する、Pixar 発の Open USD 仕様です。
USD（Universal Scene Description）は、Pixar が公開しているオープンなシーン記述フォーマットです。OBJ や FBX のような「ジオメトリ＋アニメ」を運ぶフォーマットというより、シーン全体を非破壊で重ねて記述する仕組み に近い存在です。
主要な特徴は次のとおりです。
- 拡張子：
.usd.usda（テキスト）.usdc（バイナリ）.usdz（パッケージ） - 複数のレイヤーを重ねて1つの統合シーンを構築できる
- ジオメトリ・カメラ・ライト・マテリアル・スケルトンなどを共通フォーマットで持てる
- 参照・バリアント・上書きで「非破壊的に」シーンを編集できる
「FBX の置き換え」ではなく、シーン管理そのものの設計を変える 道具だ、と捉えると見通しが良くなります。FBX が「アセット運搬の箱」だとすれば、USD は「アセットを構成する設計図」と言える存在です。
2. なぜ Pixar が作ったか・何を解決したか
ひとことで：「複数DCC・複数ショットで同じシーンを編集する」という長年の悩みを解決します。
映像制作（特に長編CG）では、1本のシーンに対して、モデリングは Maya、シミュレーションは Houdini、ライティングは Katana（Foundry社のライティング・ルックデブ専用ソフト。映像業界で広く使われる）、レンダリングは RenderMan（Pixar 社の業務用レンダラ）／ Arnold（Autodesk 社のレンダラ。Maya 標準で映像業界の定番）──といった具合に、ツールが横断的に絡みます。さらにシーンは「キャラA」「セット」「ライティング」「カメラ」など、担当者別にレイヤー分けされ、別々に進行します。
従来は「FBX で書き出して投げる」「シーンをロックして他人に触らせない」「最新版を全員に配り直す」など、運用の仕組みでカバーしていました。USD は、それらの 運用の暗黙ルールをファイル形式自体に組み込んだ のが特徴です。レイヤー別編集、参照、バリアント、上書き──運用パターンが「ファイルレベルで標準化」されたことで、ツールが違っても同じシーンを共有できるようになりました。
夕宮たいだほよ? シーンの「言語」って、運用ルールをファイルに組み込むって発想なんだぁ。FBX とは出発点がぜんぜん違うんだねぇ。
3. 主要概念：Stage / Layer / Prim
ひとことで：Stage（全体）／Layer（編集単位）／Prim（ノード）の3階層が骨格です。
USD を扱うときに最初に押さえる3語です。順に説明します。
Prim（プリム）
シーン上の1つの「もの」を指すノードです。メッシュ、カメラ、ライト、グループなど、すべて Prim として表現されます。/World/Characters/Hero/Body のような パス で階層的に管理されます。Maya の Outliner や Unreal の Actor 階層に近い感覚です。
Layer（レイヤー）
1つの USD ファイルが1つの Layer に対応します。複数の Layer を重ねてシーンが構成されます。下のレイヤーを上のレイヤーが上書き・追加していくイメージで、Photoshop のレイヤー機構に近い発想です。
Stage（ステージ）
複数の Layer を合成した結果として観察される シーン全体のビュー です。Stage そのものはファイルではなく、ランタイム上の「合成結果」として存在します。
下図のように、Stage の中に複数の Layer が積まれ、各 Layer が Prim ツリーを持つ三層構造として理解できます。
4. Composition Arcs：参照・継承・バリアント
ひとことで：レイヤー同士・Prim 同士の関係を表す、6種類の合成ルールです。
USD のもっとも特徴的な機能が Composition Arcs（合成アーク）です。Layer や Prim の関係を表現するルールが6種類あり、それぞれ用途が異なります。
| Arc | ひとこと用途 |
|---|---|
| Sublayer | 同じ Stage 内で他レイヤーを重ねる |
| Reference | 別 USD ファイルを Prim として参照する |
| Payload | 重い参照を遅延ロード（メモリ節約） |
| Inherits | クラス的な継承（共通設定をベースに派生） |
| Specializes | 特殊化（弱い継承、ベースの値が優先） |
| Variants | バリエーションの切り替え（色違い、装備違い） |
各 Arc には「強さの順序」があり、複数が同じ Prim に効く場合の合成結果の優先度が決まっています。最初は Sublayer / Reference / Variants の3つ だけ覚えれば、ほとんどの実務に耐えます。Inherits / Specializes / Payload は、必要になってから足せば十分です。
夕宮たいだうぐぅ……6種類もあるの、むずかしいねぇ。でも、最初は3つで十分って思うと気が楽になるよぉ。
Hydra と Storm の関係
USD のもう1つの柱が Hydra（ハイドラ）というレンダリング抽象化レイヤーです。USD のシーンを Hydra に渡せば、どのレンダラーでも統一インターフェースで描画できる、という設計になっています。標準実装が Storm（リアルタイムビューア）で、UE5 や Houdini Solaris のビューポートはこの仕組みで USD を表示しています。「USD はデータ、Hydra は描画窓口」と整理しておくと混乱しません。
5. ゲームスタジオで USD を採用するメリット
ひとことで：レイヤー編集・バリアント・非破壊運用が、量産パイプラインで効きます。
ゲーム制作で USD を導入するメリットは、大きく4点です。
レイヤー別編集
キャラクターのモデル / アニメ / マテリアル / ライティングを、別々の Layer に分けられます。担当者別の作業が衝突せず、Git の運用（差分が小さい）にも乗せやすくなります。FBX で「全員のシーン上書き合戦」をしていた現場ほど、効果を実感します。
バリアント運用
1キャラに「赤・青・緑」の色違い、「武装A・B・C」の装備違いを、Variants として1ファイルで持てます。FBX 別ファイルで管理していたものが、ファイル数を増やさず差し替え可能になります。
参照階層（インスタンシング）
群衆シーンや量産敵で、同じキャラを大量にインスタンス化できます。メモリ効率も良く、ベースを変えると全インスタンスに反映されます。Reference の上に Variants を組み合わせれば、「同じベースキャラを参照しつつ、各インスタンスで色だけ変える」といった量産パターンも、ファイル数を増やさずに実現できます。
非破壊編集
上のレイヤーで Prim の値を上書きしても、下のレイヤー本体は変わりません。「シーン固有の調整」「個別の演出」を、本体ファイルを汚さず重ねられます。失敗しても上のレイヤーを捨てれば元に戻ります。
夕宮たいだふふ、使いこなせばほんとに便利なんだよぉ。レイヤー、バリアント、参照……量産系の現場と相性いいんだぁ。
6. 採用のコストと現実的な導入ステップ
ひとことで：学習コストとツールチェーン改修が大きく、段階移行が現実的です。
USD は「すぐに全面移行」ではうまくいきません。コストは大きく3つです。
- 学習コスト：Stage / Layer / Prim / Composition Arcs の理解、
usdview（USDに付属する公式のシーン表示・検証ツール。コマンドラインから USD ファイルを開いて中身を確認できる） などのツール操作、Pixar 公式ドキュメントの読み込み - ツールチェーン改修：既存スクリプト、ビルドパイプライン、エンジンインポーター、命名規約、すべてを USD 対応に書き直す必要がある
- 命名・パス設計：Prim パスを最初に設計しないと、後で全置換になる。プロジェクト初期に時間を取る必要がある
夕宮たいだぁぅ……導入はちょっと大変なんだぁ。一気に全部やろうとすると、絶対こけるよぉ。気をつけてねぇ。
段階移行の4ステップ
現実的な導入は、次のように段階を踏みます。
1. 単独 USD ファイル：FBX の代わりに USD を1ファイル書き出して使う。既存パイプラインへの影響を最小化 2. レイヤー分割：モデル / マテリアル / アニメで Layer を分ける。担当者別の編集が衝突しなくなる 3. ショット参照：複数キャラ・セットを1つの統合 USD に Reference で集約。レビュー用シーンが軽くなる 4. Variant 運用：色違い・装備違いを Variants で管理。アセット数の爆発を防げる
各ステップで「ここまでは使える」と確認しながら進めるのが安全です。途中で止めても元の FBX パイプラインに戻せる、というのが USD 移行の大きな安心材料です。
7. UE5 / Unity / Houdini での対応状況
ひとことで：UE5 と Houdini が先行、Unity は限定対応という状況です。
主要環境の対応状況（2026年時点）は次のとおりです。
Unreal Engine 5
USD Stage Actor という機能で、USD をシーンにロードできます。レイヤー編集、Variants 切り替え、Stage Actor 経由のインスタンシング（同じデータを共有しつつ大量配置する仕組み）まで対応。Live Link（Unreal の DCC リアルタイム連携機能。Maya や Motion Builder の操作を即時に Unreal へ反映）経由で DCC との連携も可能です。プロダクション（実制作の現場）での USD 採用事例も増えており、選択肢として現実的です。注意点は、ランタイム（ゲーム実行中）での USD 直接利用ではなく、原則「ビルド時に変換してネイティブアセット化」する運用が一般的という点です。
Houdini Solaris（LOP）
USD を扱う標準環境として、Houdini が一番進んでいます。LOP（Lighting / Layout Operators） ネットワークで、レイヤー作成・参照・Variants まですべて GUI で構築できます。シミュレーションを SOP（Surface Operators：Houdiniの基本ジオメトリ操作系統）で作って LOP に持ち上げるのが定石で、USD ベースのレイアウト・ライティングはほぼ Solaris 一強です。
Unity
USD Package が公式提供されていますが、UE5 ほど統合は深くありません。プロトタイプや特定パイプライン用途には十分使えますが、フルパイプラインの中核に据えるには別途検討が必要です。
8. ハンズオン演習
ひとことで：簡単な USDA を usdview で開いて、ツリー構造を確認しましょう。
まずは最小の USDA をテキストエディタで作成します。
“` #usda 1.0
def Xform “World” { def Sphere “Ball” { double radius = 1.0 } } “`
これを hello.usda として保存し、コマンドラインから usdview hello.usda で開きます。左ペインに /World/Ball の階層、中央のビューポートに球体、下ペインに Layer Stack が表示されます。Prim パス・レイヤー階層・合成結果としての Stage を、実物で触って体感できます。
慣れたら、Houdini Solaris で同じ USD を読み込み、LOP ネットワークから参照・上書きを試してみると、Composition Arcs が一気に実感できます。「コードを読む前に、まず触る」のが USD 学習の近道です。
9. チェックリスト
ひとことで：USD 導入検討時のセルフチェック項目です。
- [ ] Stage / Layer / Prim の3語を自分の言葉で説明できる
- [ ] Sublayer / Reference / Variants の3つの Arc の用途を即答できる
- [ ] 既存の FBX パイプラインのどの部分を USD に置き換えるか、絞り込めている
- [ ] Prim パス設計（命名規則、階層構造）の初期案がある
- [ ] 採用するエンジン（UE5 / Unity / Houdini）の USD 対応状況を確認した
- [ ] 段階移行のうち、最初の「単独 USD ファイル」から試せる小さな案件がある
10. よくある間違い・トラブルシュート
ひとことで：パス設計の崩壊・Layer 順序の誤解・Variant の暴走・参照の循環、が定番です。
パスがフラグメンテーション化
Prim パスを「とりあえず」で切ると、後で大量にリネームが必要になります。プロジェクト初期に、/World/Characters/{Name} /World/Sets/{ShotID} のような 明示的な命名規則 を文書化します。後から変えると参照ファイルすべてに波及するので、初期設計のコストを惜しまないこと。
Layer 順序の誤解
USD の Layer は「下が弱い、上が強い」と覚えるのが基本です。Sublayer の順序を入れ替えると、上書きが効かない・効きすぎる事故が起きます。順序の意味を理解せず複製運用すると、デバッグが困難になります。
Variant の暴走
Variants を入れ子にしすぎると、組み合わせが指数的に増え、管理不能になります。1階層・最大数バリアント に留め、複雑なバリエーションは別 USD ファイルに切り出すのが鉄則です。たとえば「色 × 装備 × 表情」を1つの Variant Set に詰めると、5 × 5 × 5 = 125 の組み合わせを抱え、品質保証が追いつきません。
参照の循環
A.usd が B.usd を Reference し、B.usd が A.usd を Reference する状況。USD ランタイムが警告を出しますが、設計初期の依存関係図で防ぎます。プロジェクトの USD 構造を1枚の図で説明できる状態を保つこと。
夕宮たいだふぁ……USD、概念は最初むずかしいけど、Stage と Layer と Prim を覚えれば視界が開けるよぉ。次は Python でのパイプライン横断や、Solaris 入門に進めるよ〜。
11. 次に読む記事
ひとことで：USD の概念を、実機・パイプラインに繋げていきましょう。
- CR-07 FBX/glTF/USD/Alembic：他のシーンフォーマットとの位置づけ整理
- CR-10 Pythonで横断パイプライン：USD Python API での自動化
- CR-09 アセット命名・バージョン規則：Prim パスの命名設計と地続きの土台ルール
- HD-I10 Solaris/USD 入門：Houdini Solaris での実機ハンズオン（公開準備中）
- HD-A09 Solaris 応用：Solaris の発展的トピック（公開準備中）
—
