NVIDIA、AI エージェントで軽量 USD ランタイム開発を加速

OpenUSD は、物理 AI 向けの共通シーン記述言語を提供するオープンで拡張性の高いフレームワークです。これにより、チームは CAD データやシミュレーション資産、実世界のテレメトリデータを統合し、物理法則に忠実な世界観を共有できるようになります。

これまで USD の実装を作成するには、大規模な既存コードベースの改変が不可欠でした。メモリ使用量を最適化したい場合でも、異なるアプリケーションバイナリインターフェース（ABI）やパフォーマンス特性が必要となる場合でも同様です。nanousd-labs は、標準仕様そのものからランタイムを直接生成するという新たなアプローチを提供します。

この手法が可能なのは、USD が人間と機械の両方にとって読み取り可能な形式で定義された厳密な仕様に基づいているからです。Alliance for OpenUSD（AOUSD）が開発した USD Core Specification は、レイヤスタック全体にわたる USD データモデルの構成と解決方法を定めたバージョン管理された標準です。

この仕様は人間にとってもエージェントにとっても厳密な契約書として機能するため、開発者はエージェントに対して特定のワークロードに必要な機能を生成するよう指示できます。これは既存コードベースへの適応や手動での実装を補完するものであり、実装サイクルの高速化と、デプロイ環境に最適化されたエンドユーザー向けの物理 AI 製品の実現を可能にします。

nanousd-labs は、NVIDIA の Omniverse Labs（オープンで実験的なプロジェクトのコレクション）の一部として公開されています。社内ハッカソンで開発されたこのプロジェクトは、AI エージェントを活用して USD コア仕様書から直接、軽量な USD ランタイムを生成できる仕組みを提供します。

本記事では、開発者が AI エージェントと USD コア仕様書を用いて動作する USD 実装をどのように構築するかを解説します。また、nanousd-labs をそのアプローチの具体例として紹介し、物理的な AI プロジェクトで実際に試せる 2 つの入り口についてもご紹介します。

AI エージェントは USD コア仕様書に基づいてどのように構築されるのか？

nanousd-labs の手法は、USD コア仕様書を「契約」として扱うという単一のアイデアに基づいています。この仕様書が定義するのは、準拠するランタイムがどのような振る舞いをするべきかであって、その実装方法ではありません。

既存のコードベースを流用するのではなく、エージェントは仕様書を読み込み、そこで要求される振る舞いを満たすコードを書き、さらに仕様書から導き出されたテストスイートを用いて出力を検証します。標準仕様は不変でありながら、生成されるコードは柔軟です。メモリ制約やパフォーマンス要件、あるいは対象言語が異なっても、準拠性を損なうことなく再生成が可能です。

開発者の指示のもと、エージェントは仕様書をセクションごとに読み込み、各振る舞いを実装するコードを生成します。そして、同じ標準から導き出されたテストスイートで実行し、出力が仕様の要件に合致するまで反復処理を行います。シーンデータの構造化、解決、上書きを支配するルールもすべてテキストとして記述されており、エージェントはこれらを適用して検証作業を行います。この点が、本アプローチを実用的なものにしている理由です。

仕様書は、開発者がエージェントに対して構築と検証の指示を出すための「契約」となり、一度読んで手動で解釈するだけのドキュメントではありません。

実装が仕様書に基づいて生成されるため、準拠性は特定の単一の実装に依存せず、手法そのものに組み込まれています。目指しているのは、開発者がメモリやパフォーマンスなどの制約に応じてランタイムを再生成し、ワークロードに合わせてカスタマイズしながらも、標準への準拠性を犠牲にしないことです。

実務において、この手法には明確な境界線が存在します。仕様書が入力となり、規格への準拠度が成功の基準となります。これは完全な自動生成を意味するわけでも、今日時点で仕様のすべてがカバーされることを意味するわけではありません。

nanousd-labs の構築では、エージェントが構文解析、シーン構成、およびレイヤー間での値解決といった機械的な仕様からコードへの変換作業を担当し、エンジニアはパフォーマンス、トレードオフ、そしてアーキテクチャの決定に責任を持ちました。書かれた規格があることで、実装タスクごとに「正解」の定義が明確になり、テストが可能になります。

import nanousd

RACK_ASSET = "./assets/shelving_unit.usd" # ディスク上のパーツ（参照元であり、コピーではありません）

FORKLIFT_ASSET = "./assets/forklift.usd"

1) ウェアハウス規約（Z 軸上向き、メートル単位）に基づく新規ステージの作成

stage = nanousd.Stage.create()

stage.set_metadata_token("upAxis", "Z")

stage.set_metadata_double("metersPerUnit", 1.0)

stage.set_metadata_token("defaultPrim", "World")

stage.define_prim("/World", "Xform")

2) ASSEMBLE: グリッドセルごとに外部パーツを参照して配置

#

add_reference(asset_path, prim_path="") は、コピーせずにパーツを読み込みます。

for row in range(3):

for col in range(5):

rack = stage.define_prim(f"/World/Racks/Rack_{row}_{col}", "Xform")

rack.add_reference(RACK_ASSET) # <- 参照によるアセンブリ

rack.create_attribute("xformOp:translate", "double3")

rack.set_vec3d("xformOp:translate", (col * 3.0, row * 6.0, 0.0))

order.append("xformOp:translate")

3) 外部アセットがなくてもファイルが空にならないよう、組み込みジオメトリを追加する:

floor = stage.define_prim("/World/Floor", "Cube")

floor.create_attribute("size", "double")

floor.set_double("size", 1.0)

place(floor, translate=(6.0, 6.0, -0.05), scale=(30.0, 40.0, 0.1))

4) MOVE: 時間サンプリングされた移動操作でフォークリフトをアニメーション化する（ジオメトリを動かす）:

stage.set_metadata_double("startTimeCode", 0.0)

stage.set_metadata_double("endTimeCode", 96.0)

stage.set_metadata_double("timeCodesPerSecond", 24.0)

forklift = stage.define_prim("/World/Forklift", "Xform")

forklift.add_reference(FORKLIFT_ASSET)

forklift.create_attribute("xformOp:translate", "double3")

waypoints = [(0.0, (0.0, 0.0, 0.0)),

(48.0, (12.0, 0.0, 0.0)),

(72.0, (12.0, 18.0, 0.0)),

(96.0, (0.0, 18.0, 0.0))]

for t, pos in waypoints:

forklift.set_sample_vec3d("xformOp:translate", t, list(pos)) # 時刻 t にキーフレームを設定

forklift.create_attribute("xformOpOrder", "token[]")

forklift.set_token_array("xformOpOrder", ["xformOp:translate"])

5) 保存

stage.write_usda("warehouse.usda")

print("Wrote warehouse.usda")

nanousd-labs とは何か

nanousd は、USD ランタイムデータモデル（シーンを読み込んでクエリした際の動作を規定するルール）の独立した実装です。これは USD コア仕様書から直接導出され、安定した C 言語 ABI を通じて公開されています。実装は C++ で行われており、あらゆるプログラミング言語が直接呼び出せるパブリックな C API も用意されています。

nanousd はレンダラーではなくデータレイヤーです。シーンデータの解析、合成、クエリ、書き出しを行い、ピクセル処理が始まる手前で役割を終えます。エージェントはコア仕様のランタイムデータモデルを実装し、nanousd が担うのは特定のワークロードに必要な機能のみです。これらは安定した C ABI を介して公開されます。既存の OpenUSD スタックもそのまま動作を継続します。重要なのは導入すべき手法であり、実装自体はその証明に過ぎません。

USD コア仕様は、ランタイムが果たすべき役割を定義する一方で、メモリ管理やスレッド処理、ABI（アプリケーションバイナリインタフェース）、言語選択については実装側の裁量に委ねています。nanousd においては、現状の主要な選択は安定した C 言語 ABI です。これに伴うメモリ効率やパフォーマンスの詳細については、まだ探索が続いています。

クライアントコードは固定された C API を対象としてコンパイルされ、実際の処理は実行時に実装をロードします。この仕組みにより、バックエンドを変更しても呼び出し側のコードは一切変更する必要がありません。例えば、OpenUSD を Omniverse ライブラリとして使用する場合や、nanousd に差し替える場合でも、クライアント側には手を加えずに済みます。

また、このアプローチは測定結果の精度も保ちます。共通 API に対してスクリプトを実行する際、裏側でバックエンドを切り替えて比較できるためです。重要なのは「どちらの実装が高速か」という点ではなく、標準と安定した ABI を持つことで、AI エージェントにワークロードに適した実装へと反復改善させる道筋をつけることができるという事実にあります。

USD コア仕様と AI エージェントを用いた 2 つの構築方法

軽量で目的特化型の USD ランタイムを必要とする物理 AI パイプラインやアプリケーションを開発するチームには、nanousd-labs を活用して始めるための 2 つの方法があります。1 つ目は、今日からすぐに使える実装版を提供する方法です。もう 1 つは、その手法の仕組みを理解し、自社のスタックに応用したいチーム向けのアプローチです。

まずは、nanousd を直接クローンしてビルドすることから始めましょう。これは C API を備えたコンパイル済み実装であり、あらゆるプログラミング言語から呼び出し可能です。既存の USD ステージを即座に参照できる状態になっています。

物理 AI 開発者の多くは、まず nanousd-python から着手します。これは nanousd の C API を基盤とした Python パッケージで、GPU が不要なため、どのようなマシンでもヘッドレス環境で動作します。インストールは以下のコマンドで簡単に行えます：

python -m pip install -e ./nanousd-python

ステージを開き、その構成要素であるプリム（USD シーンを構成する個々の要素）を順に辿る処理は、以下のようなコードになります。

import nanousd

stage = nanousd.Stage.open("scene.usda")

for prim in stage.traverse():

print(prim.path, prim.type_name, prim.attribute_names())

cube = stage.get_prim_at_path("/World/Cube")

if cube is not None and cube.has_attribute("size"):

print(cube.read_double("size"))

このようにして、USD コア仕様に基づいたエージェントが、記述と検証の処理を担当します。アセットを構築する手順は以下の通りです。

倉庫用自律移動ロボット（AMR）向けの USD ステージを作成します。基本となるトランスフォーム、LiDAR センサー用のプリム、そして 1 つの共有アセットへのインスタンス可能参照として読み込まれた 2 つの車輪メッシュを含めます。

USD コア仕様に従ってください。

作成が終わったら、それを再合成して解決されたプリムツリーを表示し、仕様準拠のために修正が必要だった箇所があれば指摘してください。

エージェントはステージを記述し、nanousd-labs を通じて再合成することで正しく解決されるか確認します。その後、合成されたシーン構造と、修正した箇所のメモを返却します。

以下の出力は、シーン内の各要素とそのタイプ、そしてどのように組み立てられたかを示しています。

/World/Lidar Cube (センサーのプレースホルダー)

/World/WheelL Xform [インスタンス可能 → /_assets/Wheel]

/World/WheelR Xform [インスタンス可能 → /_assets/Wheel]

注：最初のドラフトでは、車輪を「インスタンス可能」としてマークしていなかったため、それぞれの車輪が完全な個別コピーとして構成されていました。

コア仕様（Core Spec）はシーングラフのインスタンシングを無効にするため、両方の車輪で instanceable = true を設定し、再構成してください。そうすれば、両方が 1 つのプロトタイプを共有するようになります。

「インスタンス可能」とは、2 つの車輪がそれぞれ独立した完全なコピーを持つのではなく、シーン内で定義を 1 つだけ共有することを意味します。これが USD が繰り返し出現する要素を効率的に処理する方法です。

既存のアセットの有効性検証も同じ手順で行います。

これはエクスポート直後の robot.usda です。

このファイルがコア仕様に準拠しているか確認しましょう。ファイルを構成（compose）し、その結果をトレースして、仕様で定義されるべき解決結果とどこが異なるのかを具体的に指摘してください。

テキストから推測するのではなく、実際にファイルを開いて構成された値を読み取るようにしてください。

エージェントはファイルの構成を行い、解決結果が仕様のルールに合致しているかチェックします。そして、シーンのどの部分が仕様から外れているのか、その理由、そして正しい結果はどうあるべきかを具体的に回答します。これにより、開発者はツールの挙動を解釈する必要なく、明確な準拠判定を得ることができます。

この手法の核心に迫るもう一つの側面は、実践的なアプローチです。最初の段階では、エージェントが直接「Core Specification（コア仕様）」に対して構築されますが、その際の手順はすべて手書きで記述されています。

ここで重要なのが「Skillgraph」です。これは人間の指示を再利用可能なスキルとしてコード化する場所であり、構造化されたレシピやプロンプト、テストを通じて、仕様に準拠した動作をどのように生成するかを定義しています。

これを実践的に理解するための約 10 分間のチュートリアル 10-minute tutorial が用意されています。このチュートリアルでは、コア仕様に準拠した USD ASCII（USDA）パーサーを生成するスキルを実行し、手法の理解を深めるとともに、実装のための出発点を得ることができます。

まだすべての機能が完成しているわけではありませんが、グラフは成長中であり、多機能な結合性が今後の課題です。しかし、これは長く続く基盤となる層です。仕様こそが契約であり、Skillgraph は各実装でゼロから作り直すのではなく、ワークフローを再利用可能にする役割を果たします。

始め方

ゼロから始めることなく、目的に特化した USD ランタイムの構築が可能になりました。USD の Core Specification（コア仕様）は、エージェントが構築するための明確な基盤を提供しており、nanousd-labs ではその実践的な姿を示しています。この手法はオープンであり、規格も公開されています。これからさらに発展していく余地があります。

開発者は今日から GitHub で新しいスキルや言語サポート、物理 AI のユースケースを提供できます。AOUSD メンバーである組織は、コア仕様ワーキンググループを通じて標準そのものの策定に貢献することができます。

コア仕様は永続的な基盤であり、「nanousd-labs」プロジェクトは、エージェントとオープンスタンダードが連携することで何が可能になるかの好例です。

• OpenUSD の標準仕様「USD Core Spec」を確認する
• 「nanousd-labs」プロジェクトで実験を行う
• コア仕様ワーキンググループに参加し貢献する
• まず、OpenUSD を活用して効率的な 3D ワークフローを構築するためのスキル習得を支援する無料のオープンソース学習パス「Learn OpenUSD」から始める
• SIGGRAPH 2026 の Physical AI Day で OpenUSD についてさらに詳しく学ぶ