OpenUSD(Universal Scene Description)は、Pixarが自社の長編アニメーション制作のために作った3Dシーン記述の仕組みです。ファイル形式として語られがちですが、本体は「複数のファイルに書かれた意見(オピニオン)を、決まった強さ順で1つのシーンに合成する」ライブラリにあります。この記事では、usd-core 26.8で実際に動かした合成例を示しながら、.usda・.usdc・.usdzの違い、glTFとの使い分け、Alliance for OpenUSD(AOUSD)による標準化の現在地までを整理します。
まとめ:OpenUSDの要点
- OpenUSDはPixarが2016年にオープンソース化した3Dシーン記述の仕組みで、2026年9月時点の最新リリースは2026年7月20日公開のv26.08です。
- 中核はコンポジション(合成)です。元ファイルを書き換えずに、上位のレイヤーから値やバリアントを上書きできます。
- 強さ順は公式用語集でLIVERPS(Local・Inherits・VariantSets・Relocates・References・Payload・Specializes)と定義されています。
- .usdaはテキスト、.usdcはバイナリ、.usdzは無圧縮・無暗号化のzipパッケージです。
- 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が『ファインディング・ドリー』で実力を確かめたうえで公開したと振り返っています。GitHubリポジトリ(PixarAnimationStudios/OpenUSD)の作成日は2016年5月6日です。
ライセンスは「Tomorrow Open Source Technology License 1.0(TOST 1.0)」です。LICENSE.txtの冒頭には、Apache License 2.0との違いは第6条(商標)だけだと明記されています。商用のパイプラインやツールに組み込むこと自体は妨げられませんが、Pixarの商標を製品名に使う場合は第6条を読む必要があります。
2026年9月時点の最新リリースはv26.08(2026年7月20日)で、その前はv26.05(4月24日)、v26.03(2月24日)でした。年に数回、「年.月」形式の版番号で出ています。Pythonからはpipのusd-coreパッケージで導入でき、26.8の対応範囲はPython 3.9以上3.15未満です。
USDコンポジションの仕組みと非破壊編集
レイヤーとオピニオン:強いレイヤーの値が採用される非破壊編集
USDでは、1つのファイル(レイヤー)に書かれた値を「オピニオン(意見)」と呼びます。同じ属性に複数のレイヤーが値を書いていると、強い側のオピニオンが最終的な値になります。弱い側のファイルは書き換えられないので、ライティング担当が照明だけを別レイヤーに書き、モデリング担当の元データには触れない、という分担が可能です。
サブレイヤーを並べた場合は、リストの先頭に書いたレイヤーほど強いという規則です。対象レイヤーによる上書きを取り消すには、サブレイヤー一覧からそのレイヤーのパスを削除します。レイヤーファイル自体を削除する必要はありません。
見落としやすいのが、サブレイヤーを束ねているルートレイヤー自身に書いた値は、どのサブレイヤーの値よりも強い点です。usd-core 26.8で、先頭のサブレイヤーに半径9.0、ルートレイヤーに半径7.0を書くと、合成結果は7.0になりました。修正用のサブレイヤーを足しても値が変わらないときは、ルートレイヤーに同じ属性の値が残っていないかを先に確かめてください。
コンポジションアークの強さ順LIVERPS
レイヤーの重ね方(コンポジションアーク)には複数の種類があり、openusd.orgの用語集はその強さ順をLIVERPSと定義しています。1つのLayerStackの中で、次の順に強いオピニオンが探索されます。
| 順 | アーク | 主な用途 |
|---|---|---|
| L | Local(サブレイヤー含む) | そのレイヤースタック内の直接の値 |
| I | Inherits | クラスの変更を全継承先へ反映 |
| V | VariantSets | 色違い・LOD違いの切り替え |
| E | Relocates | 参照先の名前空間の付け替え |
| R | References | アセットの配置 |
| P | Payload | 重いデータの遅延読み込み |
| S | Specializes | 最も弱い既定値の提供 |
古い解説記事や書籍には「LIVRPS」と書かれていることがあります。これはRelocatesが入る前の呼び名で、OpenUSDのCHANGELOGでは24.05でRelocatesの実装に着手し、24.08で「Completed the work of adding relocates composition」と完了が記録されています。24.05ではRelocatesの実装が進行中だったため、24.08より前の版では、利用する版の対応範囲を確認してください。
InheritsとReferencesの違いは実務で迷いやすい点です。用語集によれば、参照(References)は参照先を完全に包み込むため、さらに上位から参照されると関係が見えなくなります。一方、継承(Inherits)の関係は何段参照を重ねても生きたまま残ります。参照元アセットを変更すれば、Referencesでも複数の参照先へ変更を反映できます。Inheritsは、参照元を書き換えず、参照を重ねた上位のシーンから共通クラスへの変更を一括反映したい場合に使います。
Pythonで確かめる参照・バリアント・サブレイヤーの合成結果
次のコードは、usd-core 26.8(Python 3.14・macOS)で実行したものです。再現する場合は、仮想環境で python -m pip install usd-core==26.8 を実行し、書き込み可能な空の作業ディレクトリでコードを実行してください。赤と青のバリアントを持つ箱(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())
実行結果は次のとおりです。
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に戻ります。
.usda・.usdc・.usdzの違いと使い分け
| 拡張子 | 中身 | 向いている用途 |
|---|---|---|
| .usda | テキスト(先頭行 #usda 1.0) | 差分レビュー・手修正・小さな上書きレイヤー |
| .usdc | バイナリ(Crate形式) | 大規模ジオメトリ・高速読み込み |
| .usd | 上記どちらでもよい | 中身の形式を後から切り替えたい場合 |
| .usdz | 無圧縮・無暗号化のzip | テクスチャ込みの1ファイル配布 |
先ほどのステージを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の音声です。
手元で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年9月時点)
「USD対応」と書かれていても、合成の仕組みまで扱えるのか、ジオメトリを読み書きできるだけなのかはツールごとに違います。各社の公式ドキュメントの記述を並べると次のとおりです。
| ツール | 公式ドキュメント上の対応状況 |
|---|---|
| Houdini | Karmaレンダラーのネイティブなシーン記述形式がUSD |
| Maya 2026.2 | USD for Maya 0.33(USD 24.11と25.05を同梱) |
| Blender | 一部のデータ型のみ。インポートはレイヤーと参照を未処理 |
| Unreal Engine 5.8 | アセットのインポートは本番利用可、レベルは実験的 |
| Unity | 新USD Importerはプレリリース、Exporterは実験的 |
| NVIDIA Omniverse | OpenUSDを基盤に構築 |
| Apple(iOS・visionOS) | 3Dアセットの推奨形式がUSDZ |
HoudiniとOmniverseは、USDの合成を扱うパイプラインの候補です。Mayaも公式プラグインでUSDステージを直接開き、レイヤーを編集できます。Mayaは公式プラグインで往復編集ができます。一方、Blenderのマニュアルは、インポーターが「layers and references」などの合成の概念をまだ扱わないと明記しています。Blenderで開いて保存し直すと、上書きレイヤーの構造は残らず、合成済みの結果だけになると考えてください。Unityは新しい公式インポーターがプレリリースの段階なので、USDアセットのインポートに限れば、Unreal Engine 5.8のInterchangeには本番利用可という公式の位置づけがあります。ただし、レベルのインポートは実験的です。Appleの端末では、Safari・メッセージ・メールなどのクイックルックがUSDZを3DやARで表示し、対象にはApple Vision Proも含まれます。
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氏です。
運営委員会は創設5社から1名ずつと、一般会員から選ばれた代表で構成されます。2024年11月19日には初の輪番委員として、SideFXのMark Tucker氏(任期3年)とTrimbleのSean Snyders氏(任期2年)が選ばれました。
Core Specification 1.0の公開と1.1でのISO化着手
2025年12月17日、AOUSDは最初のOpenUSD Core Specificationを公開しました。Pixarのソースコードそのものではなく、データモデルと合成の論理を文書で定めた仕様です。AOUSDのブログによると、USDA・USDC・USDZの各形式の詳細な仕様と、実装者が準拠を判定するための基準(Compliance Framework)を含み、準拠テスト用のサンプル実装も公開されています。これまで「USDの正しい挙動」はPixarの実装を動かして確かめるしかありませんでしたが、今後は自作のツールやパーサーを仕様と照らし合わせて検証できます。
2026年7月21日(SIGGRAPH 2026)の発表では、Core Specification 1.1のリリースでISO認証の手続きを始めたと述べています。狙いは、国際規格への準拠を調達条件にする製造業・自動車・政府機関での採用障壁を下げることです。
AOUSD加盟企業の推移と会員区分
AOUSDのニュース一覧で発表された新規一般会員を、日付順に並べると次のとおりです。
| 発表日 | 新規一般会員(抜粋を含む) |
|---|---|
| 2023-12-12 | Epic Games、Meta、SideFX、Unity、IKEAなど12社 |
| 2024-03-11 | Ansys、Intel、Siemens、Trimble、WPPなど8社 |
| 2024-07-25 | Microsoft、Sony Group、Shutterstockなど6社 |
| 2024-11-19 | Cadence、Foxconn、Pickford |
| 2025-03-17 | Amazon、Rockwell Automationなど5社 |
| 2025-08-11 | Accenture、Esri、PTC、Renaultなど8社 |
| 2026-03-25 | Qualcomm、Booz Allen Hamiltonなど7社 |
| 2026-07-21 | ByteDance、Huawei、Physicl、Unity |
2023年はゲームエンジンとDCCツールの会社が中心でしたが、2024年以降はSiemens、Rockwell Automation、Renault、Esriと、製造・自動車・地理情報の企業が増えています。工場や設備を仮想空間に写し取るデジタルツインでUSDを共通形式にする動きが、加盟企業の顔ぶれに表れています。
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つで、Steering Memberは運営委員会と各Working Groupに、General Memberは各Working Groupに参加します。ContributorはSteering Committeeに加わらず、指定されたWorking Groupなどに参加する形態です。なお、Unityは2023年12月と2026年7月の両方の発表で新規一般会員として名前が挙がっています。
ゲーム制作でのUSD採用事例:グランツーリスモ7
グランツーリスモ7:コンバートパラメータの非破壊編集から段階導入
ポリフォニー・デジタルはCEDEC2022の講演資料「『グランツーリスモ7』開発における 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を採用すべきでない場面と既知の制約
openusd.orgは「What can’t USD do?」として、設計上の制約を2つ明記しています。
1つ目はGUIDを持たないことです。USDはプリムを「/World/Prop」のような名前空間のパスで識別するため、参照先アセットの内部で階層名を変えると、上位レイヤーに記録した上書きが外れます(fall off)。Pixarは過去にGUIDを試したうえで、時々まとめて名前空間を修正するコストを受け入れる判断をしています。アセットの階層名を頻繁に変える運用のままUSDを入れると、上書きが静かに効かなくなる事故が起きます。命名規則を先に固めてから導入してください。
2つ目はリギングシステムではないことです。USDのシーングラフは低メモリ・高レイテンシ寄りの設計で、高速なリグ評価に必要な高メモリ・低レイテンシとは逆向きだと説明されています。キャラクターのリグ評価はDCCツールやゲームエンジン側に残します。
このほか、完成済みの単体モデルをWebで表示するだけの用途にUSDを持ち込むのは過剰です。合成の仕組みを使わないならglTFで足ります。
よくある質問
USDファイルは何で開けますか?
.usdaはテキストなので、エディタで中身を読めます。表示には、OpenUSDのツール群に含まれるビューアusdview、USDに対応したHoudini・Maya・Blender、NVIDIA Omniverseなどを使います。.usdzはmacOSやiPhoneの標準機能でプレビューできます。Pythonで中身を確認するだけなら、pipでusd-coreを入れ、Usd.Stage.Openでファイルを開けば、プリムや属性を一覧できます。
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がプレリリース、USD Exporterが実験的という位置づけです。Unityで本番運用するなら、使う版のパッケージ文書で対応範囲を確かめてから採用してください。