トレンドコラム

技術解説

フィジカルAIの推論基盤「Cosmos Reason」をローカル環境で検証― Isaac SIM連携によるロボット環境理解AIの実装 ―

2026.04.10

サービスクリエーション本部　GPUエンジニア　岡本 朋之

サービスクリエーション本部
GPUエンジニア
岡本 朋之

このエントリーをはてなブックマークに追加
フィジカルAIの推論基盤「Cosmos Reason」をローカル環境で検証― Isaac SIM連携によるロボット環境理解AIの実装 ―

【目次】

  1. はじめに
  2. 検証環境概要
  3. Cosmos Reasonの展開
  4. 推論テストの実施
  5. Isaac SIMとCosmos Reasonの連携（基本編）
  6. Isaac SIMとCosmos Reasonの連携（応用編）
  7. まとめ

1. はじめに

本記事では、NVIDIAが提供する物理世界向け推論モデル「Cosmos Reason」を、NIM（推論マイクロサービス）としてローカル環境で起動し、Isaac Sim のカメラ画像を入力して推論結果を得るところまでを検証します。
まずは「Cosmosを試す」ことを優先し、最小構成として (1) NIMコンテナ起動 → (2) API推論確認 → (3) Isaac Sim連携 の順に進めます。

前回までは、Isaac SIM・ROS 2・Nav2を用いて、仮想空間上でロボットが自律走行する基盤を整備しました。
【前編】フィジカルAIを支えるOmniverse／Isaac Simによる仮想ロボット自律走行シミュレーション環境の構築｜GPUサーバープラットフォームの設計/構築なら「技術力」のNTTPC
【後編】フィジカルAIを支えるOmniverse／Isaac Simによる仮想ロボット自律走行シミュレーション環境の構築｜GPUサーバープラットフォームの設計/構築なら「技術力」のNTTPC
ロボットが地図を参照し、経路を計画し、障害物を回避しながら移動する――その一連の流れを実装しましたが、これはあくまで「フィジカルAIを支える開発基盤」の構築でした。つまり、

  • センサーで観測し
  • アルゴリズムで判断し
  • 指示に従って移動する

という構造は実現していましたが、「人間のように状況を理解し、推論するAI」にはまだ触れていません。
そこで今回は、フィジカルAIの“知能”に近い部分を体験するために、Cosmos Reasonをローカル環境へ実装し、前回構築した仮想ロボット環境と連携させてみます。

● Cosmosとは？

過去の記事でもご紹介しましたが、NVIDIA Cosmosは、ロボティクスや自律システムといった「フィジカルAI」を支えるために設計された、世界基盤モデル（World Foundation Models）のプラットフォームです。
従来のAIが「テキスト」や「画像」単体を扱うことが多かったのに対し、Cosmosは物理世界そのものを理解・予測・評価することを目的としています。

ロボットが動く世界には物理法則、時間の流れ、空間関係、人間の常識などが存在します。Cosmosは、そうした“現実世界の文脈”を扱うためのAI基盤です。Omniverseとも関係が深く、”Omniverseは現実タスクの3Dシミュレーション環境、Cosmosは基盤モデル群で、Omniverseのシミュレーションを入力（instruction video）としてTransfer等に使える”と公式では整理しています。
引用：世界基盤モデルを使用したフィジカル AI | NVIDIA Cosmos

● Cosmosを構成する3つのモデル

Cosmosには大きく3つのモデル群があります。

■ Cosmos Predict

未来を予測するモデルです。動画や時系列データを入力として、

  • この後どうなるか？
  • 次に何が起きるか？
  • 物体はどのように動くか？

といった「未来の物理状態」を生成・予測します。
主にトレーニングデータ生成やシミュレーション拡張に利用されます。

■ Cosmos Transfer

環境間の変換・適応を担うモデルです。例えば、

  • シミュレーション環境で生成した映像を、実環境に近づける
  • 光条件や天候を変えた合成データを作る
  • 異なるカメラ条件へ変換する

といった用途で活用されます。
Sim2Real（シミュレーションから実機への橋渡し）を支える技術です。

■ Cosmos Reason（今回利用）

今回の記事で利用するのが Cosmos Reason です。Cosmos Reasonは、Vision-Language Model（VLM）をベースとした推論特化型モデルです。特徴は、

  • 画像や動画を理解する
  • 文脈や常識を踏まえて状況を解釈する
  • クエリに対して推論結果を返す

という点です。単なる物体検出ではなく、

  • この状況は危険か？
  • どの経路が安全か？
  • 人の動きから次の行動を予測できるか？

といった「意味理解」に基づく判断を行います。
参考：
世界基盤モデルを使用したフィジカル AI | NVIDIA Cosmos

※Cosmos 世界基盤モデルは、NVIDIA Open Model License の下で誰でも利用できます。

●今回の構成イメージ

前回の連携図にCosmos Reasonを加えると、つぎのような構成になります。


図1-1.シミュレーション連携図

ここで重要なのは、今回はCosmos Reasonの体験にフォーカスするため、連携対象はIsaac SIMのみとする点です。ROS 2やNav2との高度な統合は、将来的な発展形として位置付けます。まずは、

  1. Isaac SIM上のロボットカメラ画像を取得
  2. その画像をCosmos Reasonへ送信
  3. 推論結果（危険評価・走行提案）を取得

という流れを構築します。上記に基づいた本記事のゴールは、Isaac Simのカメラ画像を Cosmos Reason に入力し、推論結果（危険評価・行動提案）を返せるところまでを再現することです。

Cosmos Reasonは、

  • 事前学習された膨大な知識
  • 物理的な常識
  • 文脈理解能力

を活用し、単なる画像分類ではなく、状況理解に基づく推論結果を返します。これは、観測 → 判断 → 行動というフィジカルAIの中でも、「判断」の高度化に相当します。

※Cosmos Reasonは、ロボットを直接制御するエンジンや、速度指令を生成する制御スタックではありません。あくまで「推論を出力するAI」です。その推論結果をどう行動へ反映させるかは、

  • Nav2のような制御スタック
  • ROS 2による通信基盤

などと組み合わせることで実現します。

2. 検証環境概要

本章では、本記事で使用した検証環境を整理するとともに、Cosmos Reasonを利用する際に特に注意すべき「VRAM消費」についても解説します。今回の検証環境は、前回の記事と同一構成です。

検証環境：
OS：Ubuntu 24.04
CPU：Intel🄬 Xeon🄬 Gold 6526Y プロセッサー
RAM：512GB DDR5 SDRAM
Storage：NVMe SSD 2TB ×2
GPU：NVIDIA RTX™ 6000 Ada ×2
Driver：580.95.05
CUDA：13.0
※ GPUドライバーおよびCUDAの導入手順は本記事では扱いません。
※ 前回記事手順にて、Isaac SIM・ROS 2・Nav2の連携が完了している状態とします。

Cosmos Reasonは、Vision-Language Modelをベースとした大規模推論モデルであり、推論時にも相応のVRAMを消費します。一方で、Isaac SIMもまた、

  • 物理演算（PhysX）
  • RTXレンダリング
  • センサーシミュレーション
  • 高解像度カメラ出力

などにより、GPUメモリを使用します。つまり、Cosmos Reason と Isaac SIM を同一GPU上で同時実行すると、VRAM競合が発生しやすいという構造になります。そのため、可能であれば、別マシンでCosmos Reasonを起動し、API経由でIsaac SIMと連携させるという構成が理想的です。

3. Cosmos Reasonの展開

本章では、Cosmos ReasonをNVIDIA NIM（NVIDIA Inference Microservices）として起動する手順を紹介します。Cosmos ReasonはNIMコンテナ形式でも提供されているため、Docker環境上で比較的簡単にデプロイできます。
※NIMコンテナ以外の方法としては、Githubからデプロイすることも可能です
※本記事は技術検証を目的とした構成例です。Cosmos Reasonのモデル自体は前述の通りオープンライセンスで提供されていますが、モデルのデプロイに利用するNVIDIA NIMはNVIDIA AI Enterpriseに含まれるソフトウェアです。PoC（実証実験）段階ではNIM単体での利用も可能ですが、ミッションクリティカルな企業ユースケースではNVIDIA AI Enterpriseとの組み合わせが強く推奨されます。NVIDIA AI Enterpriseは、長期的なセキュリティパッチの提供、APIの安定性保証、SLA（サービス品質保証）を含むエンタープライズグレードのサポートを提供します。

■ Cosmos Reasonの起動方法

前述の通り、Cosmos Reasonは、NVIDIAが提供する NIMコンテナ として配布されています。
今回は、NGC Catalogからコンテナイメージを取得し、Dockerを用いて起動する手順を紹介します。ただし、NGC Catalogからコンテナイメージを取得するためには、事前につぎの作業準備が必要です。

  • NVIDIA Developer アカウントの作成
  • NGC APIキーの取得

APIキーは、NGCコンテナレジストリへログインする際の認証情報として使用されます。APIキーの取得方法については、つぎの公式ドキュメントを参照してください。
https://docs.nvidia.com/nemo/retriever/latest/extraction/ngc-api-key/

■ NGC Catalogとは

NGC Catalog（NVIDIA GPU Cloud）は、NVIDIAが提供するAI向けソフトウェアやコンテナを公開している公式リポジトリです。ここではこのようなコンテンツが提供されています。

  • AIモデル
  • 事前構築済みDockerコンテナ
  • CUDA・AIフレームワーク
  • NIM推論サービス

これらはGPU環境での利用を前提として最適化されており、研究用途から商用システムまで幅広く活用されています。
今回使用する Cosmos ReasonのNIMコンテナ も、このNGC Catalogから取得します。
NGC Catalogを利用するためには、APIキー取得後、つぎのコマンドを実行します

export NGC_API_KEY=<Your Key>
echo "$NGC_API_KEY" | docker login nvcr.io --username '$oauthtoken' --password-stdin
# Login success を確認

※$oauthtoken は NGC Docker 認証で用いる固定のユーザー名であり、実際の認証情報はパスワードとして渡す NGC API Key です。
※上記が上手く行かない場合は、公式ドキュメント側の手順を実行してください

$ docker login nvcr.io
Username: $oauthtoken
Password: <Your Key>
export NGC_API_KEY=<Your Key>

■ NIMコンテナとは

NIM（NVIDIA Inference Microservices）は、NVIDIAが提供する推論用マイクロサービス基盤です。簡単に言うと、AIモデルをAPIサーバーとしてすぐに利用できるようにしたDockerコンテナです。通常、AIモデルを利用する場合は

  • モデルのダウンロード
  • 推論コードの作成
  • APIサーバーの実装
  • GPU最適化

といった作業が必要になります。しかしNIMを利用すると、これらの処理があらかじめコンテナ化されているため、コンテナを起動するだけでAI推論APIを利用できるようになります。今回利用するCosmos Reasonも、NIMとして提供されているため、

  • コンテナを起動する
  • APIを呼び出す

という形で推論を実行できます。

■ Cosmos Reason（NIM）の起動

準備が整ったら、NGC CatalogからCosmos ReasonのNIMコンテナを取得し、Dockerで起動します。起動後、Cosmos Reasonは推論APIサーバーとして動作し、

  • 画像
  • 動画
  • テキストプロンプト

などを入力として受け取り、推論結果を返します。今回の構成と合わせるとこのようなイメージとなります。

NGC Catalog
↓（コンテナ取得）
NIMコンテナ
↓（Docker起動）
Cosmos Reason API
↓
Isaac SIM

Cosmos ReasonのNIMコンテナは、つぎの手順で起動します。
まず、NIMのキャッシュディレクトリを作成します。

export LOCAL_NIM_CACHE="$HOME/.cache/nim"
mkdir -p "$LOCAL_NIM_CACHE"

つぎに、Cosmos ReasonコンテナをDockerで起動します。

docker run -it --rm --name cosmos-reason1-7b \
--runtime=nvidia \
--gpus all \
--shm-size=32GB \
-e NGC_API_KEY=$NGC_API_KEY \
-v "$LOCAL_NIM_CACHE:/opt/nim/.cache" \
-u $(id -u) \
-p 8000:8000 \
nvcr.io/nim/nvidia/cosmos-reason1-7b:1.4.1 #バージョン指定注意※

※記事執筆時点でReason2がリリースされており、先日のGTCにおいてはReason3が発表されましたが、本記事では動作確認を行ったReason1 ver1.4.1を利用します。
https://catalog.ngc.nvidia.com/orgs/nim/teams/nvidia/containers/cosmos-reason1-7b
※--shm-size=32GBは公式推奨値となります。GPU/環境により16GB等の調整も可能です

コンテナ起動後、別ターミナルを開いてヘルスチェックを実行します。

curl -i http://127.0.0.1:8000/v1/health/live
curl -i http://127.0.0.1:8000/v1/health/ready

つぎのレスポンスが返れば、Cosmos Reasonは正常に起動しています。

HTTP/1.1 200 OK

Cosmos Reasonを別マシンで起動している場合は、
127.0.0.1 をCosmos Reason環境のIPアドレスに変更します。
例：

curl http://192.168.10.20:8000/v1/health/live

また、以降の手順でも同様に localhost部分をCosmos ReasonサーバーIPへ読み替えてください。

Cosmos Reasonが正常に起動したら、実際に推論が行えるかを確認します。
次章では Web上の画像を入力としてCosmos Reasonが推論を行うかを検証します。

参考：Query the Cosmos Reason1 7B API — NVIDIA NIM for Vision Language Models (VLMs)

4. 推論テストの実施

本章では、先ほど起動した Cosmos Reason に対して
画像入力を用いた推論テストを実行します。
まずは Web上の画像を入力としてCosmos Reasonが正常に推論を行うことを確認し、
その後の章で Isaac SIMとの連携を実施します。

最初に、起動しているNIMが返すモデル一覧を確認します。

sudo apt install -y jq
curl -s http://127.0.0.1:8000/v1/models | jq .

正常に起動している場合、つぎのようなレスポンスが返ります。

{
  "data": [
    {
      "id": "nvidia/cosmos-reason1-7b"
    }
  ]
}

この model id を後ほどの推論リクエストで使用します。

つぎに、画像URLとプロンプトをCosmos Reasonへ送信し、AIが画像内容をもとに推論できるかを確認します。今回は例として、つぎのような質問を投げます。
「この画像において、これから起こり得る危険性を予測して」
公式ページを参考に、OpenAI互換APIに準拠したAPIリクエストコマンドを実行します。

MODEL="nvidia/cosmos-reason1-7b"

curl -s http://127.0.0.1:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "'"$MODEL"'",
"messages": [{
"role": "user",
"content": [
{
"type": "text",
"text": "この画像において、これから起こり得る危険性を予測して"
},
{
"type": "image_url",
"image_url": {
"url": "https://images.pexels.com/photos/325229/pexels-photo-325229.jpeg"
}
}
]
}],
"max_tokens": 256,
"temperature": 0
}' | jq .

正常に推論が実行されると、つぎのように JSON形式のレスポンス が返ります。

{
  "id": "chatcmpl-b9bb89bc0ccf4186914a17fedca360a6",
  "object": "chat.completion",
  "created": 1772675885,
  "model": "nvidia/cosmos-reason1-7b",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "reasoning_content": null,
        "content": "このデータセンターの画像から予測される危険性は以下の通りです：\n\n1. **サーバーラックの倒壊**: 2列に並んだサーバーラックは、重力や地震、または物理的な干渉（例えば、人間の誤操作）によって倒壊する可能性があります。重いサーバーラックが倒れると、周囲のサーバーや人命に重大な被害をもたらします。\n\n2. **冷却システムの故障**: データセンターは、サーバーの発熱を冷却するための効率的なシステムが求められます。この画像では、冷却システムの状態は見えませんが、冷却エラーはサーバーの過熱を引き起こし、データの損失やシステムのダウンをもたらす可能性があります。\n\n3. **電力供給の不安定**: 画像では電源の状態は見えませんが、データセンターは24/7稼働するため、安定した電力供給が重要です。電力供給の問題は、サーバーのダウン、データの損失、さらには火災のリスクを高め",
        "tool_calls": []
      },
      "logprobs": null,
      "finish_reason": "length",
      "stop_reason": null
    }
  ],
  "usage": {
    "prompt_tokens": 7188,
    "total_tokens": 7444,
    "completion_tokens": 256,
    "prompt_tokens_details": null
  },
  "prompt_logprobs": null,
  "kv_transfer_params": null
}

このように、Cosmos Reasonは画像を解析し、
状況理解や危険予測といった推論結果をテキストとして返します。

同じ推論処理は、Pythonから実行することも可能です。
ここでは、簡単なテストスクリプトを作成して実行してみます。
まず reason_test.py を作成します。

# reason_test.py

import requests

BASE = "http://127.0.0.1:8000"
MODEL = "nvidia/cosmos-reason1-7b"

payload = {
  "model": MODEL,
  "messages": [{
    "role": "user",
    "content": [
      {
        "type": "text",
        "text": "この画像において、これから起こり得る危険性を予測して"
      },
      {
        "type": "image_url",
        "image_url": {
          "url": "https://images.pexels.com/photos/325229/pexels-photo-325229.jpeg"
        }
      }
    ]
  }],
  "max_tokens": 200,
  "temperature": 0
}

res = requests.post(
  f"{BASE}/v1/chat/completions",
  json=payload
)

print(res.json())

つぎに、Pythonスクリプトを実行します。

python3 reason_test.py

成功すると、curl実行時と同様に JSON形式の推論結果 が出力されます。

この段階で確認しているのは、つぎの2点です。

  • Cosmos ReasonのNIMコンテナが正常に起動している
  • 画像入力を用いた推論が問題なく実行できる

これが確認できれば、Cosmos Reasonは 推論APIとして利用可能な状態です。

ここまでで、Cosmos Reasonが画像を入力として推論できることが確認できました。
次章では、いよいよIsaac SIMで取得したロボットカメラ画像をCosmos Reasonへ送信し、仮想ロボット環境とAI推論を連携させる検証を行います。

5. Isaac SIMとCosmos Reasonの連携（基本編）

本章では、前章までで起動した Cosmos Reason とIsaac SIMの仮想ロボット環境を実際に連携させます。Cosmos Reasonは APIとして利用可能な推論エンジンであるため、
Isaac SIMから取得したカメラ画像を送信することで、

  • 状況理解
  • 危険予測
  • 行動提案

といった推論をリアルタイムで取得することができます。
今回はまず 基本的な連携方法として、Isaac SIMのViewport画像を取得し、Cosmos Reasonへ送信して推論するというシンプルな構成で検証を行います。

まず、Isaac SIMを起動します。（ディレクトリは前回記事で構築した環境を基準としています）

cd ~/isaac-sim-5.1.0
./isaac-SIM.sh

Isaac SIMが起動したら、
前回と同じロボット環境をロードします。
メニューバーからWindow > Examples > Robotics Examples を選択します。

左下の領域に表示されたRobotics Examplesからつぎの通りサンプルをロードします。
ROS 2 > NAVIGATION > Nova Carter

つぎに、Cosmos Reasonへリクエストを送るためのPythonスクリプトを実行する準備を行います。メニューからWindow > Script Editorを選択し、Script Editorを開きます。

Script Editorにつぎのようなスクリプトを貼り付け、Runを実行します。

import os, base64, json, asyncio, shutil, glob
import carb
import omni
import omni.ui as ui
import omni.usd
import omni.replicator.core as rep
from pxr import UsdGeom
from urllib import request

# ---------------- config ----------------
BASE_URL = "http://127.0.0.1:8000"
MODEL_ID = "nvidia/cosmos-reason1-7b"

# Camera prim path (same as your Full_*_v5 script)
DEFAULT_CAMERA_PRIM_PATH = "/World/Nova_Carter_ROS/chassis_link/sensors/front_hawk/left/camera_left"

OUT_DIR = os.path.expanduser("~/.cosmos_bridge")
TMP_DIR = os.path.join(OUT_DIR, "_captures_tmp")
LATEST_PNG = os.path.join(OUT_DIR, "capture_latest.png")

os.makedirs(OUT_DIR, exist_ok=True)
os.makedirs(TMP_DIR, exist_ok=True)

RESOLUTION = (1280, 720)

DEFAULT_PROMPT = (
    "Summarize this 3D scene in 3 bullet points. "
    "If there are any safety or hazard concerns, list them."
)

# ---------------- helpers ----------------
def log(msg):
    carb.log_info(str(msg))

def _cleanup_tmp_pngs():
    # Replicator BasicWriter tends to emit rgb_*.png (and possibly others) under output_dir.
    # We keep a stable single file (capture_latest.png) and remove temporaries.
    try:
        for p in glob.glob(os.path.join(TMP_DIR, "*.png")):
            try:
                os.remove(p)
            except Exception:
                pass
        # Also clean up stray /tmp rgb dumps (reported previously)
        for p in glob.glob("/tmp/rgb_*.png"):
            try:
                os.remove(p)
            except Exception:
                pass
    except Exception as e:
        log(f"cleanup warning: {e}")

def _find_latest_png_in_tmp():
    pngs = glob.glob(os.path.join(TMP_DIR, "*.png"))
    if not pngs:
        return None
    return max(pngs, key=os.path.getmtime)

def _validate_camera_prim(stage, cam_path: str):
    prim = stage.GetPrimAtPath(cam_path)
    if not prim.IsValid():
        raise RuntimeError(f"Camera prim not found: {cam_path}")

    # Ensure it's (or behaves like) a Camera
    # Some assets wrap cameras; we still try to treat the prim as a camera if UsdGeom.Camera succeeds.
    try:
        cam = UsdGeom.Camera(prim)
        if not cam:
            raise RuntimeError
    except Exception:
        # Fallback: accept prim type name "Camera"
        if prim.GetTypeName() != "Camera":
            raise RuntimeError(f"Prim is not a Camera: {cam_path} (type={prim.GetTypeName()})")

async def capture_scene_png_from_stage_camera(cam_path: str) -> str:
    stage = omni.usd.get_context().get_stage()
    if stage is None:
        raise RuntimeError("No USD stage loaded")

    _validate_camera_prim(stage, cam_path)

    # Clean previous temp outputs so "latest" is deterministic
    _cleanup_tmp_pngs()

    log(f"Using STAGE camera: {cam_path}")

    # IMPORTANT: RenderProduct must be created from the camera prim path (NOT the active viewport)
    rp = rep.create.render_product(cam_path, RESOLUTION)

    writer = rep.WriterRegistry.get("BasicWriter")

    # Re-init each capture to avoid accumulating attachments across runs
    writer.initialize(output_dir=TMP_DIR, rgb=True)

    # Attach to our camera render product
    writer.attach([rp])

    # Advance one frame to render
    await rep.orchestrator.step_async()

    # Small delay to ensure file flush on slower disks
    await asyncio.sleep(0.05)

    latest = _find_latest_png_in_tmp()
    if not latest:
        raise RuntimeError("No PNG generated in TMP_DIR (replicator did not write output)")

    # Copy to stable path (single file)
    shutil.copy2(latest, LATEST_PNG)

    # Best-effort detach to avoid duplicates (API availability differs by Isaac/Replicator version)
    try:
        writer.detach([rp])
    except Exception:
        pass

    # Remove temporaries
    _cleanup_tmp_pngs()

    return LATEST_PNG

def cosmos_post_json(url, payload, timeout=180):
    data = json.dumps(payload).encode("utf-8")
    req = request.Request(
        url=url,
        data=data,
        headers={"Content-Type": "application/json"},
        method="POST",
    )
    with request.urlopen(req, timeout=timeout) as resp:
        body = resp.read().decode("utf-8", errors="replace")
        return resp.status, body

# ---------------- UI ----------------
WINDOW_TITLE = "Cosmos Reason Bridge (Stage Camera)"
win = ui.Window(WINDOW_TITLE, width=780, height=600)

prompt_model = ui.SimpleStringModel(DEFAULT_PROMPT)
base_url_model = ui.SimpleStringModel(BASE_URL)
model_id_model = ui.SimpleStringModel(MODEL_ID)
camera_path_model = ui.SimpleStringModel(DEFAULT_CAMERA_PRIM_PATH)
result_model = ui.SimpleStringModel("(Result will appear here)")

def set_result(text):
    result_model.set_value(text)

with win.frame:
    with ui.VStack(spacing=8):
        ui.Label(
            "Capture from a USD Stage Camera prim → Send to Cosmos Reason → Show response",
            word_wrap=True,
        )

        with ui.HStack():
            ui.Label("Camera Prim", width=110)
            ui.StringField(model=camera_path_model, width=640)

        ui.Label("Prompt:")
        ui.StringField(model=prompt_model, multiline=True, height=90)

        with ui.HStack():
            ui.Label("BASE URL", width=110)
            ui.StringField(model=base_url_model, width=640)

        with ui.HStack():
            ui.Label("MODEL", width=110)
            ui.StringField(model=model_id_model, width=640)

        ui.Label("Result:")
        ui.StringField(model=result_model, multiline=True, height=300)

        analyze_btn = ui.Button("Analyze Scene", height=44)

# ---------------- core logic ----------------
async def analyze_once():
    try:
        cam_path = camera_path_model.get_value_as_string().strip()
        set_result(f"Capturing scene from STAGE camera...\n{cam_path}")

        png_path = await capture_scene_png_from_stage_camera(cam_path)
        log(f"Captured PNG (stage camera): {png_path}")

        set_result(f"Sending image to Cosmos Reason...\n{png_path}")

        with open(png_path, "rb") as f:
            img_b64 = base64.b64encode(f.read()).decode("ascii")

        url = base_url_model.get_value_as_string().rstrip("/") + "/v1/chat/completions"

        payload = {
            "model": model_id_model.get_value_as_string(),
            "messages": [
                {
                    "role": "user",
                    "content": [
                        {"type": "text", "text": prompt_model.get_value_as_string()},
                        {
                            "type": "image_url",
                            "image_url": {"url": "data:image/png;base64," + img_b64},
                        },
                    ],
                }
            ],
        }

        status, body = cosmos_post_json(url, payload)

        if status != 200:
            set_result(f"HTTP {status}\n{body}")
            return

        # OpenAI-compatible response expected
        try:
            data = json.loads(body)
            answer = data["choices"][0]["message"]["content"]
            set_result(answer)
        except Exception:
            set_result(body)

    except Exception as e:
        set_result("Error:\n" + str(e))
        log(e)

def on_click():
    asyncio.ensure_future(analyze_once())

analyze_btn.set_clicked_fn(on_click)

このスクリプトでは、つぎの処理を行っています。

  1. Isaac SIMのViewport画像をキャプチャ
  2. キャプチャ画像を ~/.cosmos_bridge ディレクトリへ保存
  3. Cosmos Reasonへ画像とプロンプトを送信
  4. 推論結果を取得して表示

Script EditorのRunを実行すると、つぎのような 推論実行ウィンドウ が表示されます。

このウィンドウの Analyze Scene ボタンを押すと、ViewportのシーンがCosmos Reasonへ送信され、推論が実行されます。
なお、プロンプトは英語で記述されています。これはOmniverse / Isaac SIM環境においては英語入出力が適しているためです。また、今回利用しているスクリプトは生成AIを利用して作成した簡易検証用コードです。

推論対象となるカメラとViewportの視点を合わせます。Viewport右上のカメラメニューからCameras > camera_leftを選択します。

今回のサンプル環境では同じカメラ名が複数存在する場合があります。正しいカメラを確認するにはつぎの手順を行います。

  1. カメラ名の横にある スライドアイコン をクリック
  2. Stageビューで該当カメラが選択される
  3. Property → Prim Path を確認

このPrim Pathが推論実行ウィンドウの Camera Prim と一致していれば正しいカメラです。

つぎに、前回記事と同様に Nav2を起動し、ロボットが自律走行できる状態にします。また、Isaac SIM上でもシーン再生（Playボタン）を有効化しておきます。

ここからは、Nav2で自律走行をさせたロボットの位置ごとにCosmos Reasonの推論結果を確認していきます。本記事ではこのあと 3つのシーン を例に紹介します。

全シーン共通プロンプト（日本語訳）：

この3Dシーンを3つの箇条書きで要約してください。
安全上の懸念や危険要素があれば、それも列挙してください。

シーン1：初期位置

推論結果（日本語訳）

このシーンは工業用倉庫内を舞台としており、パレット上に整然と積み上げられた段ボール箱の列に焦点が当てられています。
箱はスペース効率を最大化するために千鳥状に配置されており、しっかりと固定されています。一部の箱には印刷されたラベルや「取扱注意（FRAGILE）」の表示も確認できます。
パレットは密に並べられた状態で整理されており、構造全体は金属製のビームによって支えられ、安定性が確保されています。画面左側にはフォークリフトも確認でき、倉庫内で積み込みまたは積み下ろし作業が行われている状況を示唆しています。
背景には追加の棚ユニットも見られ、全体として整然と管理された保管施設であることがうかがえます。床面は濃色の素材で覆われており、重工業用途に適した耐久性の高い樹脂またはゴム系素材であると考えられます。これにより、フォークリフトなどの機械類がスムーズに走行できる十分なグリップ性能が確保されていると推察されます。

シーン2：移動中

推論結果（日本語訳）

この3Dシーンは、広い内部空間を特徴とする大規模な倉庫環境を描写しています。つぎに、安全上の懸念点も含めて概要を整理します。

1. 環境

倉庫はモダンな設計となっており、半透明の白い壁の上部には黄色がかった半透明パネルが配置され、半円状のアーチ構造を形成しています。これにより、空間全体に明るく開放的な印象が生まれています。
床面は滑らかな灰色の素材で構成されており、白線が引かれています。これらのラインは、フォークリフトなどの車両が通行する通路や作業区画を示している可能性が高いと考えられます。

2. フォークリフトの位置

黄色のフォークリフトがシーン中央付近に配置されています。鮮やかな色は視認性が高く、安全確保の観点では有利に働きます。
一方で、この位置で停止した状態のまま運用される場合、床面に示された通路を塞ぐ可能性があり、周囲を移動する作業者や他の機器にとって潜在的なリスクとなる可能性があります。

3. 照明および全体的な安全性

天井には長方形の照明が設置されており、空間全体は十分に明るく照らされています。そのため視認性は良好であり、照明設備に起因する明確な危険は確認できません。
ただし、倉庫空間が広大であることから、半透明パネルや構造支持部材の安全性を維持するためには、継続的な保守・点検が重要になると考えられます。

潜在的な危険要因

主な懸念点として挙げられるのは、通路上に停止しているフォークリフトです。指定された区域から十分に離れない状態で稼働を開始した場合、他の車両との衝突や歩行者との接触事故を引き起こす可能性があります。
また、倉庫の規模が大きい環境では、空間的な混乱を防ぐために、明確な標識や通路表示を適切に設けることが重要になります。

シーン3：移動完了

推論結果（日本語訳）

この3Dシーンは、高い天井を金属製の梁で支えられた広々とした工業用倉庫を舞台としています。倉庫の床は濃い灰色に塗装されており、白線によって通路や作業区画が示されています。左側の壁は黄色と白で半分ずつ塗り分けられており、右側は黄色と黒のパネルが組み合わされています。天井には長方形の蛍光灯が並んで設置されており、空間全体は十分に照らされています。
前景には、大型の黒いパレットトラックが目立つ形で配置されており、赤いキャスター（小型車輪）が装備されています。このトラックには、紫色のプラスチック製クレートが4段に積み重ねられています。黄色のフォークリフトが2台確認でき、1台は画面右中央付近でフォークを上げた状態で停止しており、もう1台はさらに奥に位置し、同様に停止しています。右側のフォークリフト周辺には、赤白ストライプ付きの黄色い安全バリアが設置されています。
また、壁に取り付けられた消火器と思われる設備や、フォークリフト上部に設けられた安全柵など、各種産業設備や安全対策も確認できます。全体として、資材の搬送や整理が行われている、活動的でありながらも管理された工業作業環境であることを示唆しています。

今回の検証では、比較的シンプルなプロンプトを利用しているため、回答内容には多少のばらつきが見られました。しかし、各シーンに対する状況分析としては概ね妥当な内容が得られています。特に興味深い点として、Cosmos Reasonはつぎのような推論を行っていました。

  • 床面の素材を推定し、ロボット走行への影響を考慮する
  • 床面のラインを安全ラインと仮定し、ラインの損傷リスクを指摘する
  • 環境内の障害物配置から潜在的な衝突リスクを推定する

これらの挙動からも分かるように、Cosmos Reasonは単なる画像認識ではなく、
物理環境や作業環境を前提とした推論ができるようチューニングされている
ことが見て取れます。これは、Cosmosがロボティクスや産業環境での利用を前提としたフィジカルAI基盤として設計されているためです。

ここまでの手順で、

  • Isaac SIMで取得したカメラ画像
  • Cosmos Reasonによる状況理解
  • AIによる危険予測

を組み合わせた 基本的なフィジカルAI推論環境を構築することができました。次章では、この仕組みをさらに発展させた連携について紹介します。

6. Isaac SIMとCosmos Reasonの連携（応用編）

前章では、Isaac SIMのカメラ画像をCosmos Reasonへ送信し、AIによる状況理解や危険予測を取得する 基本的な連携方法を実装しました。本章ではさらに一歩進めて、自律走行ロボットの判断材料として活用できる推論を目指し、Cosmos Reasonとの連携方法を拡張します。

前章の例では、つぎのようなシンプルなプロンプトを使用していました。
この画像において、これから起こり得る危険性を予測してこの方法でも環境の状況理解は可能ですが、ロボットの走行判断に直接利用するには情報が不足しています。例えば自律走行においては、

  • どの程度危険なのか
  • 進んでよいのか
  • 停止すべきか
  • 回避するべきか

といった 判断材料 が必要になります。そこで今回は、Cosmos Reasonに対するプロンプトを改良し、

  • 必ずリスク評価を返す
  • ロボットの行動提案を含める

といった条件を満たす推論結果を得られるよう調整しました。

改良したプロンプトでは、つぎのような情報を出力するよう指示しています。

  • 環境の状況説明
  • 潜在的な危険
  • リスクレベル
  • 推奨されるロボットの行動

これにより、Cosmos Reasonの推論結果をロボット制御の判断材料として利用しやすい形式にすることができます。

もう一つの課題は、推論の実行方法です。前章では Analyze Sceneボタンを押すことで推論を実行していましたが、この方法では人手による操作が必要になり、自律走行には適しません。そこで今回は、つぎの処理をスクリプトへ組み込みました。

  • 一定間隔でViewport画像を自動取得
  • Cosmos Reasonへ自動リクエスト送信
  • 推論結果を取得

これにより、ロボットが移動する環境を継続的に解析し続ける仕組みを実現しています。ただしこの仕組みでは、推論のたびにキャプチャ画像が保存されるため、画像ファイルが大量に生成される可能性があります。そこで今回のスクリプトでは、

  • 古いキャプチャ画像の自動削除
  • 保存枚数の制限

といった 安全対策 も実装しています。これにより、長時間のシミュレーションでもストレージ容量を圧迫しないよう配慮しています。

今回のスクリプトは、生成AIと対話しながら設計と実装を進めました。具体的には、

  • Isaac SIM APIの利用方法
  • Cosmos Reason APIの呼び出し
  • 画像キャプチャ処理
  • 推論スケジューリング
  • ファイル管理

といった要素を組み合わせながら、段階的に改善を行っています。最終的には 約1000行程度のスクリプトとなり、リアルタイム推論に近い挙動を実現することができました。

このあとは、実際にこの仕組みを動作させた際のデモ動画です。

ロボットが移動する環境をCosmos Reasonが解析し、その結果をもとに状況理解やリスク評価を行っている様子が確認できます。

動画内の推論結果について考察してみます。

推論結果例1：

日本語訳：

リスク評価
Risk: LOW / Action: SLOW

リスク：低
推奨行動：減速

Hazards（潜在的危険）
  • フォークリフトが動き出す可能性があります。予期せず起動した場合、ロボットが近くにいると危険になる可能性があります。
  • ロボットは直進していますが、障害物や経路の変化に遭遇した場合、十分な時間内に検知できない可能性があります。
  • 現時点では明確な障害物や歩行者は見えませんが、フォークリフトが突然動く可能性があるため潜在的な危険は存在します。
Reason（理由）
  • フォークリフトは現在停止していますが、予測不能に起動する可能性があります。
  • ロボットは前方に進んでいるため、その動きを十分に考慮していない可能性があります。
  • 通路は開けており即時の危険性は低いです。
  • ただしフォークリフトのマストや荷物などの構造物は完全には見えていない可能性があります。
  • センサーが検知範囲外の場合、障害物を検出できない可能性があります。
  • 映像からは整然とした工業環境に見えますが、工場環境では物体の落下や転がりなど突発的な事象が起こることがあります。
最終判断
Action: SLOW

→ 減速して走行することを推奨

今回のシーンでは、通路上に停止したフォークリフトが存在しています。Cosmos Reasonはこの状況を リスクLOW と評価しつつ、「フォークリフトが突然動く可能性があるため減速して進むべき」という判断を提示しました。興味深い点は、単にフォークリフトを障害物として認識するだけでなく、

  • フォークリフトは突然動き出す可能性がある
  • センサーの検知範囲外のリスクが存在する
  • 工業環境では突発的な事象が起こり得る

といった 物理環境を前提とした推論を行っている点です。これは単純な画像認識とは異なり、ロボティクス環境を想定した推論が行われていることを示しています。

推論結果例2：

日本語訳：

リスク評価
Risk: LOW / Action: SLOW

リスク：低
推奨行動：減速

Hazards（潜在的危険）
  • 背景にあるフォークリフトは停止しているように見えますが、突然前進したり作業を開始する可能性があり、潜在的なリスクがあります。また視界を部分的に遮っている可能性があります。ロボットはフォークリフトの予期しない動きに注意する必要があります。
  • 床面には摩耗や劣化の兆候（ひび割れや変色）が見られます。これは直接的な危険ではないものの、液体などが存在する場合には滑りやすい状況を示している可能性があります。ロボットは安定した速度を維持し、滑りやすい箇所に備えるべきです。
  • 近くに障害物や歩行者は見当たらないため、衝突リスクは低い状況です。ただし、突然の障害物や人の出現には引き続き注意が必要です。
Reason（理由）
  • フォークリフトは停止していますが、予期せず動き出すと衝突リスクがあります。ロボットはその位置を監視し、速度を調整する必要があります。
  • 床面の摩耗は滑りの可能性を示唆しているため、ロボットは慎重に進むべきです。
  • 近くに明確な障害物や歩行者は見えませんが、フォークリフトの動きや床の状態が主な懸念要素となります。
最終判断
Action: SLOW

→ 減速して走行することを推奨

今回のシーンでは、ロボットの進行方向にフォークリフトが近い位置に存在しています。
Cosmos Reasonはこの状況を リスクLOW と評価しつつ、「フォークリフトの予期しない動きや視界遮断の可能性があるため減速して走行すべき」という判断を提示しました。また、興味深い点として、Cosmos Reasonは

  • フォークリフトによる視界遮断
  • 床面の摩耗状態
  • 工業環境特有のリスク

といった複数の要素を同時に考慮して推論を行っています。特に床面の摩耗から滑りの可能性を指摘している点は、単なる画像認識ではなく 物理環境を前提とした推論が行われていることを示しています。このようにCosmos Reasonは、環境中の物体だけでなく
環境の状態や潜在的リスクまで含めて状況理解を行う能力を持っていることが確認できました。

推論結果例3：

日本語訳：

リスク評価
Risk: MEDIUM / Action: SLOW

リスク：中
推奨行動：減速

Hazards（潜在的危険）
  • 背景にあるフォークリフトは停止しているように見えますが、倉庫環境では突然動き出す可能性があります。特にフォークリフトの旋回半径が広いため、遠くにある場合でもその動きがすぐには視認できない可能性があります。
  • 床面には摩耗や劣化の兆候（ひび割れや汚れ）が見られます。これらは滑りやすい床や不安定な地面につながる可能性があり、ロボットの転倒やスリップのリスクを高める可能性があります。
  • ロボットのカメラは低い位置にあり、地面に近い視点となっています。この視点では小さな障害物や破片、床面の凹凸を検出できない可能性があり、ナビゲーションに影響する可能性があります。
Reason（理由）
  • フォークリフトは倉庫環境では一般的な機械であり、突然動き出した場合には衝突リスクとなります。
  • 床面の摩耗は、凹凸や滑りやすい箇所が存在する可能性を示しています。
  • カメラの視点が低いため、小さな障害物を検知する能力が制限される可能性があります。
最終判断
Action: SLOW

→ 減速して走行することを推奨

今回のシーンでは、ロボットの視点が床面に近い低い位置にあり、進行方向の床の摩耗跡やフォークリフトの存在が確認できます。Cosmos Reasonはこの状況を リスクMEDIUM と評価し、「フォークリフトの予期しない動きや床面状態、カメラ視点による検知制限を考慮し減速して走行するべき」という判断を提示しました。
興味深い点は、単にフォークリフトを危険要因として認識するだけでなく、

  • 床面の摩耗状態
  • カメラの視点位置
  • 小さな障害物の検出限界

といった ロボットのセンサー特性や環境条件まで含めて推論している点です。
このような推論は、単純な画像認識モデルでは難しく、ロボティクス環境を前提としたフィジカルAIとしての特徴が表れている結果と言えます。

このようにCosmos Reasonは、単なる物体認識ではなく、環境の性質や潜在的なリスクを考慮した推論を行うことができ、ロボティクス分野におけるフィジカルAIの可能性を感じさせる結果となりました。

なお、今回作成したスクリプトは検証用途として作成したものであり、

  • Isaac SIM API
  • Cosmos Reason API
  • キャプチャ管理（キャプチャ画像を削除し、ストレージ肥大化を回避）
  • 推論スケジューリング（なるべく推論間隔を短くし、リアルタイム性を確保）

など複数の機能を統合しています。コード量が 1000行近くに達するため、本記事では全文の掲載は控えています。より詳細な実装内容に興味のある方は、ぜひお問い合わせください。

7. まとめ

今回の検証では、Cosmos Reason を用いたロボットの状況理解と行動判断をテーマとし、Isaac SIM 上のロボット環境と連携させる形で実験を行いました。
具体的には、

  • カメラ画像の定期取得
  • Cosmos Reason へのプロンプト送信
  • リスク評価と行動提案の生成

といった一連の仕組みをスクリプトとして実装し、ロボットの周囲環境に対してAIが推論を行うプロセス を実際に体験することができました。今回の検証では、AIによる

  • リスク評価（LOW / MEDIUM 等）
  • 潜在的危険の指摘
  • 推奨行動（SLOW など）

といった推論結果を取得するところまでを確認しています。一方で、これらの推論結果を

  • Nav2 の行動計画にどのように反映するか
  • 推論実行ごとに発生する数秒程度のタイムラグをどう扱うか

といったAIの判断を実際のロボット行動へ結びつける部分については、今後の検証課題となります。

今回の検証を通じて感じたのは、フィジカルAIの検証環境を構築するハードルは、想像していたよりも低いという点です。今回利用した環境は主につぎの2つです。

  • Isaac SIM（Omniverse）
  • Cosmos Reason

Isaac SIM については、NVIDIA が多くのサンプル環境を提供しており、今回の検証でも倉庫環境などのサンプルシーンをベースに検証を進めることができました。
これらのサンプルをベースにすることで、比較的短時間でシミュレーション環境を構築することが可能です。また Cosmos Reason についても、NGC Catalog（NVIDIA GPU Cloud）からコンテナを取得し、比較的容易にデプロイすることができました。
このように

  • シミュレーション環境（Omniverse / Isaac SIM）
  • AI推論モデル（Cosmos）
  • GPU向けコンテナ配布（NGC）

といった要素が 統合された形で提供されている点は、NVIDIAのソフトウェア戦略の特徴と言えます。ハードウェアだけでなく、

  • AIモデル
  • 開発ツール
  • シミュレーション環境
  • デプロイ基盤

をまとめて提供することで、開発者が フィジカルAIの実験を比較的容易に始められるエコシステム が整えられていると感じました。

一方で、実際に検証を進めてみると、

  • Cosmos Reason をどのような形でロボット制御に組み込むべきか
  • 仮想環境をどの粒度で設計すべきか
  • 推論結果を行動計画へどう反映するか

といった点については、まだ手探りの部分も多いと感じました。
こうした課題に対するアプローチとして、NVIDIA が提供している NVIDIA Blueprint が参考になる可能性があります。
Blueprint は、

  • AIモデル
  • ワークフロー
  • サンプルコード
  • システム構成

などをまとめた 実装テンプレートのようなものであり、特定のAIユースケースを実装するための設計例が提供されています。ロボティクスやフィジカルAIの分野でも、

  • シミュレーション環境
  • AI推論
  • ロボット制御

を組み合わせた Blueprint が今後増えていくことで、今回の検証のような 試行錯誤の部分が体系化されていく可能性があります。

NTTPCでは、引き続きフィジカルAIの重要な要素である

  • Omniverse
  • Cosmos

を中心とした技術検証を進めていきます。ロボティクスやデジタルツインといった分野において、AIによる環境理解や推論をどのように活用できるのかを探りながら、今後も検証結果を共有していく予定です。
▶︎ お問い合わせはこちら

※本記事に掲載しているコマンド、設定例、手順等は、2026年3月時点での情報をもとに作成しています。
本記事の内容を実行した際に発生する損害について、弊社は一切の責任を負いません。また、設定手順等が記載通りに再現されない場合があります。

※「NVIDIA Omniverse」「Isaac SIM」「NVIDIA RTX 6000 Ada」「CUDA」は、米国およびその他の国におけるNVIDIA Corporationの商標または登録商標です。
※「Intel」「Xeon」は米国およびその他の国におけるIntel Corporationの登録商標または商標です。
※「ROS」はOpen Source Robotics Foundation, Inc.の商標です。
※「Ubuntu」はCanonical Ltd.の登録商標です。