フィジカル AI (物理的に基盤のあるシミュレーション環境で認識し、推論し、行動する AI システム) は、工場フロアより製品が出荷されるはるかに前の段階からチームがロボットや産業システムを設計および検証する方法を変えています。GTC 2026 において、NVIDIA はフィジカル AI をロボティクスとデジタル ツインの重要な方向性として強調しました。フィジカル AI では、物理的な基盤に基づいた環境においてトレーニングおよび検証されます。
NVIDIA Omniverse を既存のアプリケーションに簡単に統合できるようにするために、NVIDIA は既存のプラットフォームに加えて、モジュール式のライブラリベースのアーキテクチャを追加します。Omniverse の中核となるコンポーネント (RTX レンダリング、PhysX ベースのシミュレーション、データ ストレージ パイプライン) は、C++ および Python バインディングを備えたスタンドアロンの ヘッドレスファースト C API (ovrtx、ovphysx、ovstorage) として公開されています。スタックを確立している開発者にとって、これらのライブラリは、アーキテクチャの大規模な書き換えの必要性を削減します。また、Omniverse コンテナー スタック全体を導入することなく、Omniverse の機能を統合できます。
モジュール式シミュレーションを通じた価値の提供
大規模なロボティクスや産業用展開では、モノリシック ランタイムがシミュレーションの拡張、ヘッドレスでのデプロイ、または既存の CI/CD システムとの統合を困難にします。ライブラリファースト アーキテクチャは、単一の Omniverse ランタイム内ですべてを実行する代わりに、レンダリング、物理学、ストレージを既存のサービスに直接組み込むことで、これらの制約に対処します。完全なアプリケーション フレームワークを採用する代わりに、チームは独自のプロセスやサービスから Omniverse のレンダリング、物理、ストレージ API を直接呼び出すことができます。
コア ラインナップ
これらのライブラリは、産業用ソフトウェア開発の統合における特定のペイン ポイントを解決するように設計されています。
| ライブラリ | 主な機能 | エンジニアリングの影響 |
ovrtx (EA) | 高忠実度、高性能なレンダリング | 最先端の RTX リアルタイム パス トレーシングとセンサー シミュレーションを既存のアプリケーションに直接統合することで、マルチモーダル ロボティクスによる認識、合成データ生成、その他多くのワークフローを可能にします。 |
ovphysx (EA) | 高速な USD ネイティブの物理シミュレーション | 既存のアプリケーションに、軽量でハードウェアによる高速化がされた物理シミュレーションを追加します。ロボティクスのトレーニングとリアルタイムの制御ループの統合向けの高速データ交換を可能にします。 |
ovstorage (EA) | 統合されたフィジカル AI データ パイプライン | 既存のストレージと PLM/PDM インフラを API 主導のライブラリ経由で Omniverse エコシステムに直接接続できます。これにより、大規模な分散データ管理と高いパフォーマンスが可能になると同時に、コストのかかる手動のデータ移行を回避できます。 |
これらのライブラリは、シーン記述 (OpenUSD)、シミュレーション対応のアセット (SimReady)、およびアプリケーション開発 (Omniverse Kit Framework) のために既存の Omniverse コンポーネントにプラグインします。
ライブラリの可用性と本番環境へのパス
現在、ovrtx、ovphysx、ovstorage は、GitHub と NGC で早期アクセス版が提供されています。早期アクセスのビルドでは、リリース間で API が変更される可能性があります。NVIDIA は移行ノートを公開し、GitHub と Omniverse Discord を通じてフィードバックを募集しています。早期アクセス期間中、対象の範囲 (物理特性、センサー モデル) を拡大し、GPU 利用率を最適化することに焦点を当てています 今年の後半に、API の安定性と長期サポートを備えた製品版のリリースを予定しています。
NVIDIA は、これらのライブラリを内部で活用し、次世代のフィジカル AI ブループリントとフレームワークを強化しています。
- NVIDIA Isaac Lab: 現在、Omniverse Kit フレームワークから ovphysx と ovrtx を搭載したモジュール式アーキテクチャへと移行しています。 これにより、明示的な実行制御、決定論的なシミュレーションが可能になり、UI に依存することなく、高密度なヘッドレス物理シミュレーションを実行できます。
- NVIDIA Omniverse DSX Blueprint: DSX リファレンス デザインのデジタル ツインを実現したものです。AI ファクトリーの施設とそのハードウェア/ソフトウェア エコシステム全体で、設計、シミュレーション、運用のために Omniverse ライブラリを活用する方法を開発者にデモンストレーションします。
これらのライブラリをまず高性能な内部スタックと産業用ブループリントでテストすることで、一般提供開始前に、エンタープライズ規模のフィジカル AI の厳しい要件を満たしていることを確認しています。
エージェント型オーケストレーション: MCP 対応ライブラリによるフィジカル AI のスケーリング
シミュレーションを LLM ベースのエージェントから使用できるようにするために、Omniverse は、Model Context Protocol (MCP) サーバーを介してその機能を公開しています これらのサーバーは、機械で読み取り可能なスキーマで操作 (USD シーンの読み込み、プリムの編集、シミュレーションのステップなど) を記述しているため、Claude や Cursor などのツールは安全にこれらを呼び出すことができます。
- Kit USD エージェント: Kit、USD、OmniUI 向け MCP サーバーの集合体です これにより、エージェントは API のブラウズ、シーン コードの生成、および高レベルな記述からのレイヤー階層や UI 要素の操作が可能になります。
MCP サーバーのセットアップ
各 MCP サーバーは、Docker または Python でローカルで実行できます 個々のサーバーのドキュメント（USD Code MCP、Kit MCP、OmniUI MCP）をご覧ください。
クイック スタート (Docker – 推奨):
# Set your NVIDIA API key first
export NVIDIA_API_KEY=your_api_key_here # Linux/macOS
# or
set NVIDIA_API_KEY=your_api_key_here # Windows
# Build wheels and start all MCP servers
cd source/mcp
./build-wheels.sh all # or build-wheels.bat all on Windows
docker compose -f docker-compose.ngc.yaml up --build
これは、API キーを介して NVIDIA のクラウドでホストされたエンベッダーと再ランキング サービスを使用します。ローカル GPU は必要ありません。
これらのワークフローを拡張するために、開発者は OpenClaw コミュニティ向けの新しいインフラ スタックである NemoClaw を活用し、ポリシーベースのガードレールによって保護され、隔離されたサンドボックス内に、安全で常時稼働の自律エージェントをデプロイできます。MCP サーバーが Omniverse への低レベルのリモート プロシージャ コール (RPC) を処理しているため、チームはすべてのシミュレーション API 呼び出しを手動で行う必要なく、エージェントの動作とガードレールの定義に集中できます。
ケース スタディ: モジュール式ライブラリによる NVIDIA Isaac Lab の最適化
ライブラリファースト アーキテクチャへの移行は、NVIDIA Isaac Lab の現在のエンジニアリングの進化によって最もよく実証されています。強化学習 (RL) 向けの高性能ロボティクス シミュレーション フレームワークとして、Isaac Lab には、高い拡張性と決定論的制御が必要です。
Isaac Lab 3.0 Beta により、NVIDIA は、Isaac Lab の基盤層を、モノリシックな Kit フレームワークから、モジュール式のマルチバックエンド アーキテクチャに移行しました
- 物理学の側面では、開発者はシミュレーションの要件に応じて、PhysX SDK をラップするスタンドアロン ライブラリである
`ovphysx`か、MuJoCo-Warp を搭載した Kitless Newton バックエンドのいずれかを選択できます。 - レンダリング側では、プラグイン可能なレンダラー システムが OVRTX、Isaac RTX、Newton Warp、および Rerun や Viser のような軽量の可視化機能をサポートしています。
このリリースは現在ベータ版であり、今年後半に一般提供を予定しています。このマルチバックエンドの設計により、NVIDIA が内部的にシミュレーション スタックを構成する方法が大きく変わり、単一のランタイムから、相互交換可能な物理バックエンドとレンダリング バックエンドのセットへと移行します。
実装の詳細:「フレームワークのロック」の解決
Isaac Lab エンジニアリング チームにとって、スタンドアロン ライブラリへの移行は、アーキテクチャにおける 3 つの主要なボトルネックを解決します。
- 明示的な実行制御: スタンドアロン API が Kit ランタイム ループに取って代わり、開発者は物理ステップを手動でトリガーできるようになります これにより、決定論的な実行が確保され、フレームワークに起因する遅延が排除されます。
- 分離された更新頻度: モジュール式ライブラリは、シミュレーション コンポーネントの独立したステップ操作を可能にします 高周波センサー (IMU) と低周波ビジョン システムは、単一の環境内でネイティブ レートで動作できるようになりました。
- スケーラブルなヘッドレス デプロイ: 分離されたライブラリは、Linux クラスターに最小限のバイナリ フットプリントを提供します 開発者は、UI に依存することなく高密度物理演算を実行できます。デバッグや可視化のために
ovrtxを付加できます。
プラットフォームの配管を剥ぎ取ることで、Isaac Lab はテンソル化されたデータ交換を活用し、GPU バッファを介してシミュレーションの状態に直接的に高速にアクセスできます (例: ホスト コピーなしの PyTorch テンソルとしての位置/速度)。
確立されたスタックの拡張: 業界での採用
産業デジタル ツインおよびロボティクス シミュレーション パートナーは、パイロットまたは初期の本番環境の統合において、ワークフローに Omniverse ライブラリを導入し始めています。
ABB Robotics、Adobe、Cadence、PTC、Siemens、Synopsys などのパートナーにとって、重視している価値は、アーキテクチャの完全な再プラットフォーム化なしで、基礎的な RTX レンダリング、高忠実度 PhysX シミュレーション、ネイティブ OpenUSD サポートを組み込めることです。
ABB Robotics のようなロボティクス シミュレーションのリーダーは、Omniverse を RobotStudio に組み込み、業界で信頼されているバーチャル コントローラー、オフライン プログラミング、試運転ワークフローを基盤に、大規模なフィジカル AI で産業用ロボットのトレーニングと検証を行っています。また、PTC は、Onshape を Isaac Sim に直接接続し、クラウド ネイティブ ロボットの設計、テスト、デプロイを行っています。 Siemens をはじめとするグローバルな産業用ソフトウェア大手企業は、Omniverse ライブラリを統合し、大規模な産業用デジタル ツインを構築しています。
意思決定ガイド: フレームワークかライブラリか?
適切な統合パスの選択は、アプリケーション スタックの特定の要件によって異なります。
意思決定ガイド: モジュール式ライブラリと完全なプラットフォームとのどちらを選ぶべきか。
- Omniverse ライブラリが最適なケース: 既存の 3D または CAD アプリケーションにフィジカル AI 機能を組み込みたい場合、または Omniverse のフルスタックを採用せずに、高忠実度の物理シミュレーションやセンサー レンダリングを必要とする新しいワークフローを構築したい場合は、Omniverse ライブラリを使用してください。また、軽量でヘッドレスの多い導入や、依存性と複雑さを最小限に抑えながら集中した機能を必要とする専門的な自律エージェントにも適しています。
- Omniverse Kit フレームワークが最適なケース: フル UI、インタラクティブなビューポート、およびレンダリング、物理、その他の Omniverse 機能にわたる緊密な連携を必要とする、豊富な機能を持つ OpenUSD アプリケーションまたはサービスを構築したい場合に、Omniverse Kit を使用してください。アプリケーションをまだ所有しておらず、組み込みのメニューやウィンドウ表示が必要で、多くの拡張機能やライブラリを自動的に連携させる標準的なアプリ フレームワークを求める場合に最適です。これにより、低レベルの統合ではなくドメイン ロジックに集中できるようになります。
入門編: フィジカル AI のパイプラインへの組み込み
Omniverse ライブラリ、特に ovrtx と ovphysx の最大の利点の 1 つは、それらの可用性が包括的な Omniverse Kit フレームワークから分離されていることです。どちらのライブラリも、それぞれの C API 上で構築された薄い Python バインディングを提供しており、独自のアプリケーションに簡単に統合できます。
DLPack をサポートしているため、NumPy、PyTorch、Warp などの人気のあるフレームワークとともに、ゼロコピーの転送データ交換を使用して、直接、それらとやり取りできます。
開始方法
ovrtx によるフレームのレンダリング:
ovrtx は、RTX ハードウェアで高速化されたレンダリングへの軽量アクセスを提供します。NumPy を使用して、わずか 10 行のコードでシーンを読み込み、フレームをレンダリングし、PNG ファイルに保存できます。
*要件: Python バインディングは ctypes を使用し、C ライブラリ以外の依存関係を必要とせず、Python 3.10 以降の環境で動作します。
from ovrtx import Renderer
import numpy as np
from PIL import Image
# 1. Create the renderer with optional configuration
renderer = Renderer()
# 2. Ingest the scene
renderer.add_usd("/path/to/robot.usda")
# 3. Step the sensor simulation and retrieve rendered outputs
products = renderer.step(render_products={"/Render/Product_Robot_01"}, delta_time=1.0/60)
# 4. Save rendered output into PNG via numpy DLPack and PIL
for frame in products["/Render/Product_Robot_01"].frames:
with frame.render_vars["LdrColor"].map(device="cpu") as mapping:
pixels = np.from_dlpack(mapping.tensor)
Image.fromarray(pixels).save("robot_pose.png")
コードの内容について
- 効率的でシンプルなシーン作成:
ovrtx_add_usd()は、高度なキャッシュとストリーミングを使用して効率的なロードを行い、指定された USD レイヤーをステージにロードします。 - 分離されたステップ:
ovrtx_step()コマンドは、提供されたデルタ時間を使用してレンダラーを決定的に進めます。これにより、アプリケーションはレンダリングの実行を完全に制御できるようになります。 - セマンティック認識テンサー: コンテキスト マネージャー
(with… as mapping:)は、RGBA や深度などのレンダリングされた変数を CPU または GPU メモリにマッピングするのを自動的に処理し、その結果を NumPy と簡単に共有できます。テンサーがガベージコレクションされる際に、アンマッピングとクリーンアップは自動的に処理されます。
詳細については、ovrtx Github リポジトリをご覧ください。
ovphysx を使用した最小限の物理ループ
ovrtx がビジュアルを処理する一方、ovphysx はコア PhysX SDK と USD/Tensor 環境を接続するブリッジとして機能します。
物理シミュレーションを実行するために、アプリケーションフローは、コア API によって駆動される 5 つの基本的な非同期ステップに従います。
- インスタンスのライフサイクル:
ovphysx_create_instance
USD シーンの読み込み、シミュレーションの実行、またはテンソルへのアクセスを行うには、まずインスタンスを作成する必要があります。 - シーンの取り込み:
ovphysx_add_usd
このステップでは、USD ファイルからランタイム ステージにアクター、ジョイント、物理マテリアルを読み込み、物理世界を定義します。 - シミュレーションの進行:
ovphysx_step
これはシミュレーション ループの中核です。時間の経過とともに、物理学を決定的に進行させます。 - 同期:
ovphysx_wait_op
ライブラリは非同期のストリーム順序実行モデルを使用しているため、ステッピングまたは USD のロードが完了したことを確認するための操作を使用する必要があります。これにより、データの読み書きを試みる際の競合状態を防止します。 - 状態アクセス:
read_tensor_binding/write_tensor_binding
テンソル バンディングは、ライブラリ向けのスケーラブルな I/O メカニズムです。このステップにより、物理的な状態 (速度や位置など) を観察したり、テンソル化された形式で制御 (力の印加など) を行ったりすることができます。
詳細については、ovphysx Github リポジトリをご覧ください。
ovstorage によるデータ ソースの接続
ovrtx と ovphysx がアプリケーションにレンダリングと物理機能を提供していますが、ovstorage は統合ストレージ層として機能します。統合された API 層を介して、PLM または既存のリポジトリを Omniverse エコシステムに直接接続します。 これにより、同期ジョブとコストのかかるデータ移行が不要になり、ファイルを移動することなく USD ワークフローが可能になります。
Kubernetes 対応のヘッドレス デプロイ向けに設計された ovstorage は、アーキテクチャ全体を制御して、マイクロサービスを独立してスケーリングし、モノリシックなレガシー スタックの制約を受けずに、本番環境の需要を満たします。
始め方
- 既存のインフラを統合する: Omniverse を現在のストレージ バックエンド (S3 または Azure など) に接続し、所定の場所でバージョン管理を維持します。
- サービス アダプターのデプロイ: カスタム アダプターを迅速に構築し、クライアント アプリケーションを変更することなく、ストレージのバックエンドを統合 API に公開します。
- コンプライアンスの確保: コンフォーマンス テスト済みのアダプターを使用すると、特定のデータ常駐、ソブリン、コンプライアンスの要件を満たしながら、真実の単一ソースを維持できます。
これらは ovstorage の初期機能に過ぎず、今後さらなる機能が予定されています。
ovstorage 実装のアーキテクチャ例。詳細については、NVIDIA NGC 上の ovstorage リソースをご覧ください。
モジュール式のフィジカル AI の未来
NVIDIA Omniverse は、独自のフィジカル AI スタックに構成できるライブラリとフレームワークとなる、モジュール式の構築ブロックのセットになりつつあります。NVIDIA は、ovrtx や ovphysx などの高性能プリミティブを提供することで、開発者がすでに所有しているエコシステム内で次世代の自律システムを構築できるようにしています。
Omniverse Kit フレームワークは、まったく新しい、豊富な機能を備えたアプリケーションを構築する開発者にとって理想的な選択肢です。これらのスタンドアロン ライブラリにより、チームは既存のスタック内でイノベーションを推進できます。産業用 ISV や Isaac Lab 内で初期に導入されていることで、モジュール式ライブラリにより、シミュレーションを既存の製品やトレーニング パイプラインに簡単に統合できる可能性があります。
今すぐ始める
以下の次のステップに従って、モジュール式のフィジカル AI を既存のアプリケーションに統合しましょう。
- Omniverse ライブラリをインストールする: GitHub から
ovrtxとovphysxを、NVIDIA NGC から ovstorage をダウンロードして、フィジカル AI のパイプラインへの統合を開始しましょう。 - 詳細について: 最新の GTC 2026 セッションにアクセスし、近日開催予定の OpenUSD Insiders ライブストリームを視聴して、Omniverse 開発について詳しく学びましょう。
- コミュニティとの交流: Omniverse Developer Discord でフィードバックを共有し、他の開発者と協力して、エンタープライズ対応のフィジカル AI の未来を形作るのに貢献しましょう。
翻訳に関する免責事項
この記事は、「Integrate Physical AI Capabilities into Existing Apps with NVIDIA Omniverse Libraries」の抄訳で、お客様の利便性のために機械翻訳によって翻訳されたものです。NVIDIA では、翻訳の正確さを期すために注意を払っておりますが、翻訳の正確性については保証いたしません。翻訳された記事の内容の正確性に関して疑問が生じた場合は、原典である英語の記事を参照してください。
