OpenUSDとは？Universal Scene Descriptionの合成の仕組み・USDファイル形式・AOUSD標準化【v26.11対応】

OpenUSD（Universal Scene Description）は、Pixarが自社の長編アニメーション制作のために作った3Dシーン記述の仕組みです。ファイル形式として語られがちですが、本体は「複数のファイルに書かれた意見（オピニオン）を、決まった強さ順で1つのシーンに合成する」ライブラリにあります。この記事では、usd-core 26.11で実際に動かした合成例と読み込み時間の実測を示しながら、Stage・Prim・スキーマの基本、.usda・.usdc・.usdzの違い、glTFとの使い分け、Alliance for OpenUSD（AOUSD）による標準化の現在地までを整理します。

まとめ：OpenUSDの要点

• OpenUSDはPixarが2016年にオープンソース化した3Dシーン記述の仕組みです。2026年11月時点の最新リリースは2026年10月21日公開のv26.11.1です。
• 中核はコンポジション（合成）です。元ファイルを書き換えずに、上位のレイヤーから値やバリアントを上書きできます。強さ順は公式用語集でLIVERPSと定義されています。
• シーンはStage（合成結果）とPrim（要素）の木で表し、ジオメトリ・マテリアル・ライト・物理などの意味は標準スキーマ（UsdGeom・UsdShade・UsdLux・UsdPhysicsなど）が決めます。
• .usdaはテキスト、.usdcはバイナリ、.usdzは無圧縮・無暗号化のzipパッケージです。v26.11からは0.4.0より古い形式の.usdcを既定で読み込まなくなりました。
• pipのusd-coreはPython 3.11以上で使えますが、ビューアのusdviewや描画機能は入っていません。
• glTFは実行時の配信用、USDは制作パイプラインでの合成用という設計目的の違いがあります。
• AOUSDは2023年8月1日に設立され、2025年12月17日にCore Specification 1.0を公開し、2026年7月にはCore Specification 1.1でISO化の手続きに入りました。

OpenUSDの定義とPixarでの誕生経緯

openusd.orgの「Introduction to USD」によると、USDはPixarにとって第4世代の「合成されたシーン記述」です。『トイ・ストーリー』ではショットごとに1本のプログラムファイルで記述していましたが、『バグズ・ライフ』以降、社内アニメーションシステムMarionette（社内名Menv）に参照・レイヤー・バリエーションの概念を足し、その後継のPrestoを経てUSDに至りました。

Pixarが正式なオープンソース公開を発表したのは2016年7月26日です。2025年12月17日のAOUSDの発表文は、Pixarが『ファインディング・ドリー』で実力を確かめたうえで公開したと振り返っています。

ライセンスは「Tomorrow Open Source Technology License 1.0（TOST 1.0）」です。LICENSE.txtの冒頭には、Apache License 2.0との違いは第6条（商標）だけだと明記されています。商用のパイプラインやツールに組み込むこと自体は妨げられませんが、Pixarの商標を製品名に使う場合は第6条を読む必要があります。

リリースは「年.月」形式の版番号で年に数回出ています。CHANGELOGでは、v26.03（2026年2月24日）、v26.05（4月24日）、v26.08（7月20日）、v26.11.0（10月20日）と続き、翌10月21日にGPUメモリーの不具合を直したv26.11.1が出ています。

Stage・Prim・スキーマ：USDのデータモデル

Stage・Prim・属性・レイヤーの関係

USDのシーンを読むときに最初に出てくる語は4つです。レイヤーはシーン記述を保持する単位で、ファイルに保存するものとメモリー上だけに存在するものがあり、Stageは複数のレイヤーを合成した結果として見えるシーン全体、PrimはStageの中の要素（「/World/Prop」のようなパスで呼ぶ木構造の節）、属性（Attribute）はPrimが持つ値（サイズや色など）です。合成結果はStageから読み書きでき、個々のレイヤーはSdf.Layerから直接操作できます。Stageで見える値は合成の規則に従って決まります。

Primの種類（Cube・Mesh・Lightなど）と、そのPrimが持つべき属性の名前と型を定めるのがスキーマです。たとえばUsdGeom.Cubeはsize属性を持ち、値を書かなければ既定値2.0が使われます。DCCツール同士が同じUSDファイルを同じ意味で読めるのは、このスキーマを共有しているからです。

標準スキーマとHydraの役割

OpenUSDに同梱される主な標準スキーマは次のとおりです。いずれもpipのusd-core 26.11に含まれていることを、パッケージの中身で確認しました。

UsdShadeの公式説明は「シェーディングネットワークを内包するマテリアルの作成と割り当て」で、MaterialXの読み込みは別のプラグイン（UsdMtlx）が担います。v26.03では、AOUSDのEmerging Geometry関心グループの提案に基づき、3D Gaussian Splatを表すUsdVolParticleField3DGaussianSplatが加わりました。このスキーマは、3D Gaussian SplatのデータをUSDシーン内で記述するためのものです。表示できるかは、利用するツールやレンダラーの対応に依存します。

描画を担うのはHydraです。Hydraの公式説明は「複数のシーングラフと複数のレンダラーの間の通信を可能にするフレームワーク」で、OpenGL系のStorm、RenderMan、Embreeなどのレンダラーを差し替えて同じStageを描けます。ただしHydraはpipのusd-coreには入っていません（次の章で扱います）。

OpenUSDの導入：usd-coreとusdviewの入手方法

Pythonからシーンを読み書きするだけなら、pipのusd-coreで足ります。PyPI上の最新版は26.11（2026年10月21日）で、対応はPython 3.11以上3.15未満です。v26.11でPython 3.9と3.10のサポートが外れたため、26.8までの手順書にある古いPythonでは26.11を入れられません。配布はmacOS（universal2）、Windows、Linux（x86_64と、26.11から加わったaarch64）向けです。

python3.13 -m venv .venv
.venv/bin/python -m pip install usd-core==26.11
.venv/bin/python -c "from pxr import Usd; print(Usd.GetVersion())"
# (0, 26, 11)

入らないものもあります。PyPIの説明は「オプションのプラグインや、完全版USDの描画（imaging）機能は含まない」としており、Pixarのクイックスタートガイドも、pip版にはimaging・usdview・Alembicなどのプラグインが無いと明記しています。手元の仮想環境でも、binにusdview・usdcat・usdzipといったコマンドは1つも入りませんでした。代わりに次の手段を選びます。

• usdviewでシーンを見たい：NVIDIAがビルド済みのUSDを配布しています。2026年11月時点の配布はUSD 25.08・Python 3.12用のWindows版とLinux版で、PyPIの最新より1年ほど古い版です。
• 最新版のCLIやHydraが要る：リポジトリを取得し、READMEのとおりpython OpenUSD/build_scripts/build_usd.py /path/to/my_usd_install_dirでソースからビルドします。26.11から依存ライブラリがVFX Reference Platform 2025準拠（既定でoneTBB）に上がり、usdviewのGUIはPySide2が非推奨となってPySide6が前提です。
• DCCツールの中で使う：HoudiniやMayaは自前のUSDを同梱しているので、ツール付属のPython環境からpxrを読み込めます。

USDコンポジションの仕組みと非破壊編集

レイヤーとオピニオン：強いレイヤーの値が採用される非破壊編集

USDでは、1つのレイヤーに書かれた値を「オピニオン（意見）」と呼びます。同じ属性に複数のレイヤーが値を書いていると、強い側のオピニオンが最終的な値になります。弱い側のファイルは書き換えられないので、ライティング担当が照明だけを別レイヤーに書き、モデリング担当の元データには触れない、という分担が可能です。

サブレイヤーを並べた場合は、リストの先頭に書いたレイヤーほど強いという規則です。対象レイヤーによる上書きを取り消すには、サブレイヤー一覧からそのレイヤーのパスを削除します。レイヤーファイル自体を削除する必要はありません。

見落としやすいのが、サブレイヤーを束ねているルートレイヤー自身に書いた値は、どのサブレイヤーの値よりも強い点です。先頭のサブレイヤーに半径9.0、ルートレイヤーに半径7.0を書くと、合成結果は7.0になりました。修正用のサブレイヤーを足しても値が変わらないときは、ルートレイヤーに同じ属性の値が残っていないかを先に確かめてください。

コンポジションアークの強さ順LIVERPS

レイヤーの重ね方（コンポジションアーク）には複数の種類があり、openusd.orgの用語集はその強さ順をLIVERPSと定義しています。1つのLayerStackの中で、次の順に強いオピニオンが探索されます。

古い解説記事や書籍には「LIVRPS」と書かれていることがあります。これはRelocatesが入る前の呼び名で、CHANGELOGでは24.05でRelocatesの実装に着手し、24.08で「Completed the work of adding relocates composition」と完了が記録されています。24.08より前の版を使う環境では、Relocatesを前提にしないでください。

InheritsとReferencesの違いは実務で迷いやすい点です。用語集によれば、参照（References）は参照先を完全に包み込むため、さらに上位から参照されると関係が見えなくなります。一方、継承（Inherits）の関係は何段参照を重ねても生きたまま残ります。参照元アセットを変更すれば、Referencesでも複数の参照先へ変更を反映できます。Inheritsは、参照元を書き換えず、参照を重ねた上位のシーンから共通クラスへの変更を一括反映したい場合に使います。

Pythonで確かめる参照・バリアント・サブレイヤーの合成結果

次のコードは、usd-core 26.11（Python 3.13・macOS）で実行したものです。書き込み可能な空の作業ディレクトリで実行してください。赤と青のバリアントを持つ箱（box.usda）をショット（shot.usda）に参照で配置し、別レイヤー（lighting_fix.usda）からサイズとバリアント選択を上書きします。

from pxr import Usd, UsdGeom, Sdf

# 1) アセット：色違いのバリアントを持つ箱
asset = Usd.Stage.CreateNew("box.usda")
box = UsdGeom.Cube.Define(asset, "/Box")
asset.SetDefaultPrim(box.GetPrim())
vset = box.GetPrim().GetVariantSets().AddVariantSet("color")
for name, rgb in [("red", (1, 0, 0)), ("blue", (0, 0, 1))]:
    vset.AddVariant(name)
    vset.SetVariantSelection(name)
    with vset.GetVariantEditContext():
        box.CreateDisplayColorAttr([rgb])
vset.SetVariantSelection("red")
asset.GetRootLayer().Save()

# 2) ショット：アセットを参照で配置
shot = Usd.Stage.CreateNew("shot.usda")
prop = shot.DefinePrim("/World/Prop")
prop.GetReferences().AddReference("./box.usda")
shot.GetRootLayer().Save()

# 3) 上書き用レイヤー：元ファイルに触れずサイズとバリアントを変える
fix = Usd.Stage.CreateNew("lighting_fix.usda")
over = fix.OverridePrim("/World/Prop")
over.CreateAttribute("size", Sdf.ValueTypeNames.Double).Set(3.0)
over.GetVariantSets().AddVariantSet("color").SetVariantSelection("blue")
fix.GetRootLayer().Save()

# 4) サブレイヤーで重ねる（リストの先頭ほど強い）
root = Usd.Stage.CreateNew("root.usda")
root.GetRootLayer().subLayerPaths = ["./lighting_fix.usda", "./shot.usda"]
root.GetRootLayer().Save()

stage = Usd.Stage.Open("root.usda")
p = stage.GetPrimAtPath("/World/Prop")
print("size =", p.GetAttribute("size").Get())
print("color =", p.GetVariantSet("color").GetVariantSelection())
print("displayColor =", p.GetAttribute("primvars:displayColor").Get())
src = Usd.Stage.Open("box.usda")
print("box.usda size =", src.GetPrimAtPath("/Box").GetAttribute("size").Get())

実行結果は次のとおりです（26.8でも同じ出力でした）。

size = 3.0
color = blue
displayColor = [(0, 0, 1)]
box.usda size = 2.0

合成後のステージではサイズが3.0、色が青になりました。一方、box.usdaを単独で開くとサイズは2.0のままです。2.0はCubeスキーマの既定値で、box.usdaにはサイズの値が書かれていません。上書きはlighting_fix.usdaの中だけにあり、その中身は次の数行です。

#usda 1.0

over "World"
{
    over "Prop" (
        variants = {
            string color = "blue"
        }
        prepend variantSets = "color"
    )
    {
        custom double size = 3
    }
}

defではなくoverで書かれている点に注目してください。overは「定義はせず、既存のプリムに意見だけを足す」指定子です。このファイルをroot.usdaのサブレイヤー一覧から外せば、箱は赤・サイズ2.0に戻ります。

採用された属性値の出所とレイヤーの確認

レイヤーが増えると「この値はどのファイルから来たのか」が分からなくなります。そのときは、属性やPrimに意見を書いているレイヤーを強い順に取り出します。上のコードを実行したディレクトリで、続けて次を実行します。

from pxr import Usd

stage = Usd.Stage.Open("root.usda")
prim = stage.GetPrimAtPath("/World/Prop")
attr = prim.GetAttribute("size")

# 値を出しているレイヤーを強い順に並べる
for spec in attr.GetPropertyStack():
    print(spec.layer.GetDisplayName(), spec.default)

# プリムに意見を書いているレイヤー（強い順）
for spec in prim.GetPrimStack():
    print(spec.layer.GetDisplayName(), spec.path)

# 合成の入力になったレイヤー一式
print(sorted(l.GetDisplayName() for l in stage.GetUsedLayers()))

lighting_fix.usda 3.0
lighting_fix.usda /World/Prop
shot.usda /World/Prop
box.usda /Box
box.usda /Box{color=blue}
['box.usda', 'lighting_fix.usda', 'root-session.usda', 'root.usda', 'shot.usda']

サイズの値を持つのはlighting_fix.usdaだけだと分かります。Primの一覧では、参照先のbox.usdaが2回出てきます。2回目の/Box{color=blue}は、選ばれた青のバリアントの中身が別の記述として積まれていることを示します。root-session.usdaはStageを開いたときに自動で作られる、保存されない最上位のレイヤーです。上書きが効かないときは、まずGetPropertyStack()の先頭に想定どおりのレイヤーがいるかを見ると、ルートレイヤーに値が残っているなどの原因にすぐ行き着きます。

.usda・.usdc・.usdzの違いと使い分け

先ほどのステージをExport("flat.usdc")で書き出すと、ファイル先頭8バイトはPXR-USDCでした。拡張子.usdの場合、USDは中身を見てテキストかバイナリかを判別します。テキストを書き込んだ.usdファイルもそのまま開けましたが、Usd.Stage.CreateNew("new.usd")で新規に保存したファイルの先頭はPXR-USDCで、既定はバイナリでした。差分レビューしたいレイヤーは、拡張子を.usdaにして作ってください。

.usdzについて、openusd.orgの仕様（Usdz File Format Specification）は「zero compression, unencrypted zip archive」と定め、パッケージ内の各ファイルのデータが先頭から64バイトの倍数の位置で始まることを、レイアウト上の絶対条件としています。圧縮も暗号化も許さないのは、.usdaや.usdcをmmapで直接読む前提を崩さないためだと仕様に書かれています。格納できるのはusda・usdc・usdのシーン、png・jpeg・exr・avifの画像、M4A・MP3・WAVの音声です。v26.11の文書更新では、.usdzの中に.usdzを入れ子にしてよいことが仕様に明記されました。

手元でUsdUtils.CreateNewUsdzPackageを使ってshot.usdaをパッケージ化すると、shot.usdaのデータ開始位置は64バイト目、参照先box.usdaは256バイト目で、どちらも64の倍数、圧縮方式は無圧縮（0）でした。一般的なzipツールで固め直すと圧縮や位置ずれが起きてこの条件を満たさなくなるため、.usdzはUSD付属のツールで作ります。

USD・glTF・FBXの設計目的と用途の違い

glTFの仕様書は、glTFを「API-neutral runtime asset delivery format」と定義し、実行時の効率を重視する点は「典型的な3Dオーサリング形式とは異なる設計目標」だと述べています。Khronos Groupは「The JPEG of 3D」とも表現しており、glTF 2.0は2022年にISO/IEC 12113:2022として国際標準になりました。

USDは逆に、制作途中の多数のファイルを合成し、担当者ごとの上書きを重ねるための仕組みです。判断基準は次のとおりです。

• Webブラウザや軽量アプリへ完成済みの3Dモデルを配るだけなら、glTF（.glb）を選びます。Three.jsでのglTF表示のように、Webの3Dライブラリが標準で読み込めます。
• 複数人・複数ツールで同じシーンを並行して編集し、変更を戻せる状態を保ちたいなら、USDを選びます。
• iPhone・iPadのARで表示する配布物は、.usdzで用意します。Web-ARとアプリの選び分けはARコンテンツの作り方で整理しています。

FBXとの比較では、ポリフォニー・デジタルのCEDEC2022資料が出発点を率直に書いています。講演者は「FBX があるのに、なぜ新しいフォーマットが話題になるのだろう？」と感じていたものの、学ぶうちにコンポジションとPython APIの価値に気づいたと述べています。FBXはモデルを受け渡す交換形式で、USDのように複数ファイルの意見を強さ順で合成する仕組みは持ちません。

主要DCCツール・ゲームエンジンのUSD対応状況（2026年11月時点）

「USD対応」と書かれていても、合成の仕組みまで扱えるのか、ジオメトリを読み書きできるだけなのかはツールごとに違います。各社の公式ドキュメントの記述を並べると次のとおりです。

HoudiniとOmniverseは、USDの合成を扱うパイプラインの候補です。Mayaも公式プラグインでUSDステージを直接開き、レイヤーを編集できます。一方、Blender 5.2 LTSのマニュアルは、インポーターが「layers and references」などの合成の概念をまだ扱わないと明記し、エクスポートもレイヤーやバリアントには対応していません。Blenderで開いて保存し直すと、上書きレイヤーの構造は残らず、合成済みの結果だけになると考えてください。

Unityは公式パッケージレジストリ上の最新が、Importerは1.0.0-pre.2（レジストリへの公開は2024年9月17日、変更履歴の日付は8月23日）、Exporterは2023年12月公開の1.0.0-exp.1のままで、2年以上プレリリースから動いていません。USDアセットのインポートに限れば、Unreal Engine 5.8のInterchangeには本番利用可という公式の位置づけがあります。ただし、レベルのインポートは実験的です。Appleの端末では、Safari・メッセージ・メールなどのクイックルックがUSDZを3DやARで表示し、対象にはApple Vision Proも含まれます。

ロボティクス・デジタルツインでのOpenUSDの使われ方

2024年以降、USDの用途は映像制作から、工場や設備を仮想空間に写し取るデジタルツインとロボットのシミュレーションへ広がっています。ここで効いているのがUsdPhysicsスキーマです。公式説明は「物理シミュレーションの表現を構成するPrimと属性のスキーマ」で、剛体の質量やコライダー、ジョイントを、どの物理エンジンにも依存しない形で書けます。

• NVIDIA Isaac Sim：ロボットやセンサーのアセットをUSDで扱うシミュレーターです。ライセンスやGPU要件はIsaac Simの解説にまとめています。
• MuJoCo：Google DeepMindの物理エンジンで、公式ドキュメントはOpenUSD対応を「実験的」と明記しています。.usd・.usda・.usdc・.usdzの読み込みと書き出しができ、物理は標準のUsdPhysicsで表し、表せないMuJoCo固有の機能だけを独自のmjcPhysicsスキーマで補います。

標準で表せない部分を独自スキーマで足せるのはUSDの利点ですが、独自スキーマを知らないツールではその部分の意味が失われます。ツール間で物理設定まで受け渡すなら、まずUsdPhysicsの範囲に収まるかを確かめてください。

AOUSD（Alliance for OpenUSD）による標準化の現在地

2023年8月1日の設立と創設5社・JDFの役割

AOUSDは2023年8月1日、Pixar・Adobe・Apple・Autodesk・NVIDIAの5社が、Linux Foundation系列のJoint Development Foundation（JDF）とともに設立を発表しました。発表文によると、JDFを母体に選んだ理由は、仕様を効率よく策定できることに加え、国際標準化機構（ISO）での承認への道筋があるためです。初代議長はPixarのCTO、Steve May氏です。

Core Specification 1.0の公開と1.1でのISO化着手

2025年12月17日、AOUSDは最初のOpenUSD Core Specificationを公開しました。Pixarのソースコードそのものではなく、データモデルと合成の論理を文書で定めた仕様です。AOUSDのブログによると、USDA・USDC・USDZの各形式の詳細な仕様と、実装者が準拠を判定するための基準（Compliance Framework）を含み、準拠テスト用のサンプル実装も公開されています。これまで「USDの正しい挙動」はPixarの実装を動かして確かめるしかありませんでしたが、今後は自作のツールやパーサーを仕様と照らし合わせて検証できます。

Core Specificationが定めるのは土台の部分で、発表文は「Geometry・Materials・Physicsの分野別の標準は策定中」と位置づけています。ワーキンググループの一覧にはCore Specification・Materials・Geometry・Marketing・Physicsの5つが並び、2026年3月25日にはスケルタルアニメーションなどを扱うCharacters, Motion, and Interactivity（CMI）関心グループも設けられました。つまり、Core Specificationに準拠していても、マテリアルや物理の解釈がツール間でそろう保証はまだありません。

2026年7月21日（SIGGRAPH 2026）の発表では、Core Specification 1.1のリリースでISO認証の手続きを始めたと述べています。狙いは、国際規格への準拠を調達条件にする製造業・自動車・政府機関での採用障壁を下げることです。2026年11月2日時点で、AOUSDのニュース一覧にこれより新しい発表はありません。

AOUSD加盟企業の推移と会員区分

AOUSDのニュース一覧で発表された新規一般会員を、日付順に並べると次のとおりです。

2023年はゲームエンジンとDCCツールの会社が中心でしたが、2024年以降はSiemens、Rockwell Automation、Renault、Esri、PLMのArasと、製造・自動車・地理情報の企業が増えています。

2026年9月14日に確認したAOUSD公式のLandscapeでは、組織会員は53社で、内訳はSteering会員5社（Adobe、Apple、Autodesk、NVIDIA、Walt Disney Studios）とGeneral会員48社です。会員規約（Membership Agreement）が定める区分はSteering Member・General Member・Contributorの3つで、運営委員会は創設5社の代表に加え、一般会員から選ばれる輪番委員で構成されます（2024年11月にSideFXとTrimbleから初めて選出）。

ゲーム制作でのUSD採用事例：グランツーリスモ7

ポリフォニー・デジタルはCEDEC2022の講演資料「『グランツーリスモ７』開発における USD 活用事例」（2022年8月23日）で、USD導入の経緯を公開しています。前提は、100レイアウトのコース、400台以上のクルマ、東京・福岡を中心にエンジニア57人・アーティスト133人という規模でした。

最初にUSDを使ったのは3Dモデルではなく、アセットをゲーム用に変換する際のコンバートパラメータです。資料の例では、ニュルブルクリンクのライトベイクのサンプル数に、全コース既定値256（ベイクエンジニア）、コース設定値512（担当アーティスト）、品質テスト用1024、デバッグ用1という4者の値が優先度付きで重なります。これをUSDのコンポジションで調停し、その後アセットライブラリへと範囲を広げました。

資料のまとめは「少しづつでも導入は可能で、十分なメリットが得られる」です。既存の独自形式やMaya中心の環境を一度に置き換えず、合成の仕組みが効く小さな領域から始めた点は、ゲーム以外の現場にもそのまま当てはまります。クルマのカスタムパーツ制作では、USDをフルサポートするHoudiniのSOLARISを使い、Mayaで作ったモデルとマテリアルをHoudiniへ持ち込む経路をUSDで作っています。

OpenUSDを採用すべきでない場面と既知の制約

GUID不在による階層名変更時の上書き失効

openusd.orgは「What can’t USD do?」として、設計上の制約を明記しています。1つ目はGUIDを持たないことです。USDはPrimを「/World/Prop」のような名前空間のパスで識別するため、参照先アセットの内部で階層名を変えると、上位レイヤーに記録した上書きが外れます（fall off）。Pixarは過去にGUIDを試したうえで、時々まとめて名前空間を修正するコストを受け入れる判断をしています。アセットの階層名を頻繁に変える運用のままUSDを入れると、上書きが静かに効かなくなる事故が起きます。命名規則を先に固めてから導入してください。

2つ目はリギングシステムではないことです。USDのシーングラフは低メモリ・高レイテンシ寄りの設計で、高速なリグ評価に必要な高メモリ・低レイテンシとは逆向きだと説明されています。キャラクターのリグ評価はDCCツールやゲームエンジン側に残します。

参照ファイル数と読み込み時間の実測

参照先のファイルを細かく分けると、Stageを開く際のファイル解決と読み込みの負担が増えることがあります。読み込む範囲は、ペイロードのロード設定や選択したバリアントなどによって変わります。立方体1個だけのアセットをN個の.usdcに分け、1つのシーンからN回参照したStageと、それをstage.Export("scene_flat.usdc")で1ファイルに平坦化したものの、Usd.Stage.Openから全Primを走査し終えるまでの時間を測りました（usd-core 26.11・Python 3.13.14・Intel Core i9-9880H・macOS 26.6.2。毎回新しいプロセスで5回測った中央値。測定コードではOSのファイルキャッシュを明示的に消去していません）。

Primの数は同じでも、参照するファイルが1,000本で約3.6倍、5,000本で約8.3倍の差になりました。この差は立方体だけを含むファイルを測った結果です。ネットワークストレージ上の実アセットでは、通信遅延・データ量・キャッシュなどの条件が変わるため、同じ手順で別途測定する必要があります。制作中はレイヤーを分けたまま使い、ゲームエンジンやビューアへ渡す段階で平坦化する、という使い分けが現実的です。平坦化すると合成の構造は失われるので、元のレイヤー群は必ず残してください。

古いバイナリファイルとusdviewの脆弱性（v26.11）

v26.11.0のCHANGELOGは、セキュリティ上の理由でバージョン0.4.0より古い.usd・.usdcバイナリを既定で読み込まなくなったと記しています。0.4.0以上0.8.0未満は警告付きで読めます。何年も前に書き出したアセットを抱えている場合は、付属のusdupdatecrateで新しい形式へ更新してから26.11に上げてください。同じ版では、レイヤーの中身から作ったパスをシェルのコマンドに埋め込んでいたusdviewとusdeditのコマンドインジェクションも修正されています。外部から受け取ったUSDファイルをusdviewで開く運用なら、26.11以降に上げる理由になります。

このほか、完成済みの単体モデルをWebで表示するだけの用途にUSDを持ち込むのは過剰です。合成の仕組みを使わないならglTFで足ります。

よくある質問

USDファイルは何で開けますか？

.usdaはテキストなので、エディタで中身を読めます。表示には、OpenUSDのビューアusdview（NVIDIAのビルド済み配布かソースビルドで入手）、USDに対応したHoudini・Maya・Blender、NVIDIA Omniverseなどを使います。.usdzはmacOSやiPhoneの標準機能でプレビューできます。Pythonで中身を確認するだけなら、pipでusd-coreを入れ、Usd.Stage.Openでファイルを開けば、Primや属性を一覧できます。

OpenUSDは無料で商用利用できますか？

できます。ライセンスはTOST 1.0で、LICENSE.txtによるとApache License 2.0との違いは第6条（商標）だけです。自社のパイプラインや製品にライブラリを組み込んで配布できますが、再配布時には第4条に従い、ライセンスの添付、変更したファイルへの変更表示、該当する著作権表示やNOTICEの保持などが必要です。ただし、Pixarの名称やロゴを製品名・宣伝に使う行為は商標条項の制限を受けます。AOUSDへの加盟はライブラリの利用条件ではないため、加盟せずに使えます。

AOUSDとOpenUSDは何が違いますか？

OpenUSDはPixarが開発しGitHubで公開しているソフトウェアと、そのシーン記述の技術そのものです。AOUSD（Alliance for OpenUSD）は、その仕様を文書化し標準化するために2023年8月1日に設立された業界団体で、Joint Development Foundationのプロジェクトとして運営されています。AOUSDは2025年12月17日にCore Specification 1.0を公開しました。

USDとglTFはどちらを使えばよいですか？

用途で分けます。glTFは仕様書で「runtime asset delivery format」と定義された配信用の形式で、Webやアプリで完成済みの3Dモデルを軽く表示するのに向きます。USDは複数のファイルを合成し、担当者ごとの上書きを非破壊で重ねる制作用の仕組みです。制作はUSDで行い、配信時にglTFへ書き出す、という併用も成り立ちます。

OpenUSDはUnityやUnreal Engineで使えますか？

どちらも公式に対応していますが、成熟度が違います。Unreal Engine 5.8のリリースノートでは、Interchange経由のUSD対応はアセットのインポートが本番利用可（production ready）、レベルのインポートが実験的（experimental）とされています。Unityは公式USD Importerが2024年に出た1.0.0-pre.2、USD Exporterが1.0.0-exp.1のままです。Unityで本番運用するなら、プレリリースのパッケージで足りるかを自分のアセットで確かめてから採用してください。

関連記事

• Houdiniとは？何ができるソフトか・料金・Blenderとの違い【Houdini 22対応】
• Mayaとは？できること・料金と安く買う方法・無料版・基本操作【Maya 2027対応】
• Isaac Simとは？無料で使えるライセンスの範囲・GPU要件・導入方法【6.2対応・2026年10月】
• Three.jsとは？r187の導入手順とglTF表示・バンドルサイズ実測まで解説
• デジタルツインとは？意味・シミュレーションとの違い・事例と導入の判断基準を解説