NVIDIA VSS 3.1.0 EA とハノーバーメッセで見えた製造業 VSS の今を調べてみた
はじめに
こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。
2026 年 3 月に下記の記事を公開したのですが、その後の 2 か月で VSS 周辺がずいぶん動いていました。
VSS 3.1.0 EA が 3 月 25 日に公開され、Warehouse Blueprint も 4 月 30 日付けで 3.1.0 に更新。さらにハノーバーメッセ 2026（4/20〜24）では、製造業向けに VSS を組み込んだプロダクトの発表が相次ぎました。
前作の続編にあたる本記事では、まずハノーバーメッセで見えた製造業の現場で VSS がどう使われ始めているかを 4 社の事例で整理してみました。
VSS 3.1.0 EA 公開と 3 月からの動き
3.1.0 EA は NVIDIA Developer Forum でアナウンスされました。
Warehouse Blueprint のドキュメントも 4 月 30 日付けで 3.1.0 に更新されています。GA はまだ出ていない一方で、DGX Spark が AGX/IGX Thor と並んで「Validated Platforms」に正式に列挙されました。
| 日付 | 出来事 |
|---|---|
| 2026-03-25 | VSS 3.1.0 EA 公開（Developer Forum） |
| 2026-03-16〜19 | GTC 2026（VSS のキーノートでの言及はなし） |
| 2026-04-20〜24 | ハノーバーメッセ 2026（製造業向け VSS 採用が一気に表面化） |
| 2026-04-30 | Warehouse Blueprint 3.1.0 ドキュメント更新 |
おもしろいのは、ソフトウェア側の進化（3.0 → 3.1）と現場側の動き（事例の表面化）が、ほぼ同じタイミングで起きていることです。3 月の記事を書いていた時点では、VSS 3.0 EA は「アーキテクチャは派手だがまだ手元で苦労する EA」という位置づけでしたが、5 月のいま見直すと、世界中の製造業の現場で実装フェーズに入り始めているのがわかります。
ここから 4 社の事例を順番に見ていきましょう。NVIDIA 公式ブログと各社の公式情報をベースに、VSS との関わりが見える範囲を整理しました。
製造業 VSS 事例 1: Invisible AI Vision Execution System
ここからは事例パートです。NVIDIA がハノーバーメッセ 2026 に合わせて公開したブログ記事をベースにしつつ、各社の公式情報で補足する形で、4 社を順番に見ていきます。
最初の事例は Invisible AI の Vision Execution System です。NVIDIA Metropolis VSS Blueprint と Cosmos Reason 2 を採用した製品として、上記ブログで紹介されています。
Invisible AI のコンセプトはシンプルで、製造ラインの各ステーションに軽量なカメラを設置し、作業のサイクルごとに「何が起きたか」を AI が自動で構造化データに変換していくというものです。Capture（撮る）、Structure（構造化する）、Act（現場に返す）の 3 ステップが公式サイトに掲げられています。
Lightweight cameras see every cycle on every line. No wearables, no operator disruption.
ウェアラブルなしで、作業者の動きを邪魔せずに収集する点が特徴ですね。製造ラインで作業者にセンサーを身に着けさせるのは現場との合意が難しいので、カメラ側だけで完結する設計は採用ハードルを下げる方向に効きます。
採用企業として公式サイトに掲げられているのは Mercedes-Benz、Ford、Toyota、BMW、General Motors、Nissan の 6 社。自動車業界の大手がほぼ揃っている形で、Toyota からは次のコメントが寄せられています。
Invisible AI has been a great partner for Toyota as we work toward building the manufacturing processes of the future.
数値も具体的で、「10x faster than manual time studies」「3-5x ROI on each device」「Every minute of downtime we prevent saves us $1k」「every workstation we can remove saves us $200k per year」と、現場の人時計算と直結する形で効果を訴求しています。
VSS との接点は、映像を「サイクル単位の構造化データ」に変換する部分です。VLM（Cosmos Reason 2）が映像を読み解いてイベントを抽出し、Behavior Analytics が ROI やトリップワイヤー、近接違反などの分析イベントを生成する部分が、Invisible AI の Capture → Structure に相当します。VSS そのものを直接触らせることはせず、Invisible AI のプラットフォームに包んで届けている形です。
製造業 VSS 事例 2: Tulip Interfaces Factory Playback
Tulip Interfaces は「Composable AI for Frontline Operations」を掲げる現場向けプラットフォームで、ハノーバーメッセ 2026 で発表された Factory Playback は VSS Blueprint と Cosmos Reason 2 を組み合わせた新機能です。映像と生産データを 1 つのタイムラインに重ねて、巻き戻したり掘り下げたりできるようにする、という発想ですね。
Combine video and production data into a single timeline you can rewind, explore, and analyze.
NVIDIA の公式ブログでは「synchronize machine telemetry, operator workflows, quality events and video」と説明されています。機械のテレメトリと作業者のワークフロー、品質イベント、そして映像を同じ時系列で揃えて見られるので、「いつ何が起きて、その時の映像はこう」を一気通貫で確認できる使い方になります。
採用事例として紹介されているのは、建機メーカーの Terex です。
estimated 3% increase in yield and 10% reduction in rework
歩留まり 3% 向上、リワーク 10% 削減という数字を「estimated」付きで掲げているあたりは、慎重な書き方ですね。歩留まりや手戻りは要因が複雑で、AI だけの寄与を切り出すのが難しいためです。
ちなみに Tulip 自体は VSS と組まない事例も豊富で、TICO Tractors では検査・リワーク時間を 60% 削減、Sharp では臨床試験向け梱包処理を 30% 高速化したと公式サイトに記載があります。プラットフォーム自体に厚みがある会社が、その上に VSS のレイヤーを足してきた、という時系列で読むのが正確そうです。
製造業 VSS 事例 3: Fogsphere Vision Agent Platform
3 社目の Fogsphere は英国ロンドン拠点の Computer Vision AI 企業で、ハノーバーメッセ 2026 では ARM ベースのエッジに NVIDIA Cosmos Reason 2 + Metropolis VSS Blueprint を載せたプラットフォームを発表しました。前 2 社のように施設内サーバーに集約して動かすのではなく、Fogsphere は CCTV 直近のエッジに AI を分散配置する設計を強く打ち出しているのが特徴です。
Distribute AI at the 'Edges' of the city. Run AI over CCTV even with unstable 4g connections.
不安定な 4G 環境でも CCTV 上で AI を回せる、と謳っているあたりに、過酷な現場での運用を狙う気配があります。Edge-to-Fog-to-Cloud の 3 段アーキテクチャでデータを階層的に処理する構成です。
対象業界は 9 つに及びます。Retail / Chemical / Construction / Smart City / Logistic / Oil & Gas / Power Generation / Healthcare / Manufacturing。ハノーバーメッセで発表された Saipem の採用事例は、この中の Oil & Gas に近いポジションで、安全と環境のリスク事象を映像から拾う用途で使われています。
detect and respond in real time to high-risk safety and environmental events
ARM ベースのエッジ展開という点は、DGX Spark 連載で扱ってきた Jetson Orin Nano Super のラインとも相性が良さそうです。「ARM エッジでの VSS 展開」が商用プロダクトの形で表に出てきたのは、エコシステムが成熟してきた証拠だと感じます。
製造業 VSS 事例 4: Pegatron PCB アセンブリ
最後は時間軸が少し前にさかのぼりますが、台湾の電子機器メーカー Pegatron の事例です。2025 年 5 月の NVIDIA 公式ブログで紹介された VSS Blueprint の代表事例で、PCB（プリント基板）アセンブリ工程の SOP（標準作業手順）分析と従業員訓練に使われています。
the agents have reduced Pegatron's labor costs by 7% and defect rates by 67%
労働コスト 7% 削減、不良率 67% 削減という数字を「the agents」という表現で書いているのが目を引きます。VSS そのものではなく、その上に乗ったエージェントが効果を生んでいる表現になっていて、現場では VSS が「映像を読む基盤」として裏方に回り、エージェントが意思決定する側に立つ構図が見えてきます。
不良率 67% 削減はベースラインの数値次第で受け取り方が変わります。元々の不良率が高いラインなら桁違いの削減ですが、すでに低いラインだと絶対値としては小さくなります。出典記事には絶対値の記載がないので、参考値として受け取るのが安全です。
同じブログでは Siemens の Industrial Copilot for Operations（生産性 30% 向上）や、台湾高雄市の Linker Vision（スマートシティ向けの VSS 採用）も並べて紹介されていて、VSS が製造業だけでなく公共領域にも縦断的に広がっていることがわかります。
4 社並べてみて見えるもの
4 社を並べてみると、いくつか共通の傾向が見えてきます。
第一に、VSS は単独プロダクトとしては表に出てこない ことです。Invisible AI も Tulip も Fogsphere も、自社プラットフォームの内部で VSS を「映像理解の差し込み口」として使い、表のブランディングは独自のプロダクト名で立てています。NVIDIA 側はリファレンスアーキテクチャ提供者として裏方に徹し、現場と接する部分はソリューションプロバイダが担う、という二層構造ですね。
第二に、VLM はほぼ Cosmos Reason 2 がデフォルトになりつつあります。3 月時点の VSS 3.0 EA で Cosmos-Reason2-8B / Cosmos-Reason1-7B / Qwen3-VL の選択肢が出ていましたが、ハノーバーメッセで発表された 3 社はそろって Cosmos Reason 2 を採用しています。VSS 3.1.0 でも Qwen3-VL が増えたものの、デフォルト推奨は Cosmos Reason 2 という流れがしばらく続きそうです。
ただし、ここから先はもう一段動く可能性があります。NVIDIA は 2026 年 4 月末に Nemotron 3 Nano Omni（30B-A3B、text / image / audio / video の 4 modality 対応）を公開しました。
後者では Cosmos Reason 2 を含む 3 モデルを Heron-Bench と JMMMU で直接比較していて、ベンチごとに得意領域がはっきり分かれることが見えてきました。VSS の VLM 候補に並ぶ未来は遠くなさそうです。さらに Cosmos Reason 2 の次の世代（Cosmos Reason 3 と呼ばれるかはわかりませんが）が出てくれば、デフォルト推奨もそのタイミングで塗り替わるはずですね。半年後に VSS の VLM ラインナップがどう動いているか、個人的にはここが一番の見どころだと思っています。
第三に、ARM ベースのエッジ展開が想像以上に強いニーズになっています。Fogsphere の例が象徴的ですが、製造業の現場や CCTV ネットワーク、あるいは現場周辺のサーバーは、必ずしも x86 + dGPU の前提で組まれていません。NVIDIA 側も Jetson Thor や IGX Thor、そして DGX Spark という ARM 系のラインアップでこのニーズに応えてきていて、VSS Warehouse Blueprint 3.1.0 が DGX Spark を Validated Platforms に正式列挙したのは、その流れの一部です。
そして最後に、日本の製造業に取り入れる視点で言えば、「VSS をフルスクラッチで構築する」のはまだ重い選択肢で、こうした海外ソリューションベンダーが提供する VSS 内蔵型プラットフォームの導入か、あるいは VSS Blueprint をベースにしたカスタム実装の二択になります。前者は早く動き出せる一方で日本語対応や工程の特殊性に弱く、後者は工数がかかる代わりに自社業務にフィットさせられる、というトレードオフですね。以前の検証記事で日本語 LLM 差し替え検証したような工夫は、後者の選択肢の一例だと思っています。
DevelopersIO 現地レポートとの接続
事例 4 社の話と並べて読みたいのが、クラスメソッドの社員がハノーバーメッセ 2026 で現地取材したレポートです。VSS そのものを論じた記事はないのですが、製造業 AI の潮流を肌で見てきた感覚として、ここでの 4 社の動きと地続きの内容になっています。
濱田（ハマコー）さんの AWS ブース訪問レポート（2026-04-28）は、Isaac Sim / Cosmos WFM / GR00T / Jetson Thor が並ぶ展示を「現場のシステムを残しつつエージェントが上から束ねる」と総括しています。VSS は AWS ブースには出ていなかったようですが、「AWS×NVIDIA 連携が一段と立体的になっている」という記述は、本記事で見てきた VSS のソリューションプロバイダ展開とも重なる視点です。
もう 1 本、T-Systems × Siemens × NVIDIA の取り組みを取り上げた記事（2026-04-27）は、Industrial AI Cloud の文脈で「孤立したパイロットから、AI で駆動される相互接続された工場へ」とまとめています。VSS は工場の映像レイヤーを担うピースの 1 つで、こうしたソブリン AI や Industrial AI、フィジカル AI のレイヤー構造に組み込まれて、初めて事業として走り出します。VSS 単独で売れるプロダクトではない点で、本記事の 4 社事例とも通じる構図ですね。
3.1.0 で大きく変わった部分
ここからは検証パートです。3.0.0 EA から 3.1.0 EA への差分のうち、DGX Spark で動かす立場で意味のある変更を 6 つピックアップしました。NGC からダウンロードした compose パッケージの中身を観察して整理した内容になります。
Minimal Profile がデフォルト有効に
3.0.0 EA で立ち上げると 42 サービスが同居して DGX Spark の 128 GB UMA を圧迫していた点は前作で書きましたが、3.1.0 では warehouse/.env のデフォルトが MINIMAL_PROFILE="true" になっています。
MINIMAL_PROFILE="true" # Minimal profile
この Minimal Profile では ELK（Elasticsearch + Kibana）や Video Analytics API/UI、監視レイヤーを除外して必要最低限のサービスだけを上げるので、デプロイ時間が「5 分以内・4 倍速」と公式アナウンスで言及されています。前作で「42 サービスを 1 台に詰め込んで重い」と書いた状況に対する明確な答えで、Agentic Search を試したいだけ、Behavior Analytics の生データだけ欲しい、といった用途で使い勝手がよくなります。
VLM-as-Verifier が独立サービスに昇格
前作のハマりポイントとして「Alert Bridge のコードバグ 4 件にパッチを当てた」と書いていたのですが、その対象が 3.1.0 では vlm-as-verifier/compose.yml として独立サービスに昇格しています。
deployments/
├── vlm-as-verifier/
│ ├── README.md
│ ├── compose.yml
│ └── scripts/
└── warehouse/
├── vlm-as-verifier/ # warehouse 固有設定
└── ...
ベースサービスとして compose.yml の include に組み込まれていて、Warehouse 側にも warehouse/vlm-as-verifier/ という固有設定ディレクトリができている形です。前作で当てた 4 件のパッチがそのまま反映されているかは中身を実機で動かさないと厳密にはわからないのですが、設計レベルでは「アラート検証を 1 つのサービスに集約する」方向に進んでいます。
Perception モデル + データディレクトリが app-data に同梱
これが個人的に一番うれしい変化です。3 月時点では Perception コンテナを起動しても Cannot access ONNX file '/opt/storage/rtdetr_warehouse_v1.0.fp16.onnx' でエラーになり、NGC nvidia/tao/rtdetr_2d_warehouse を別途ダウンロードして $MDX_DATA_DIR/models/mtmc/ に手動配置する必要がありました。
3.1.0 では vss-warehouse-app-data:3.1.0 を NGC からダウンロードすると、以下のファイルが最初から同梱されています。
vss-warehouse-app-data/
├── models/
│ ├── mtmc/rtdetr_warehouse_v1.0.1.fp16.onnx
│ └── sparse4d/ov/sparse4d_warehouse_v2.1.onnx
├── data_log/
│ ├── elastic/
│ ├── kafka/
│ ├── redis/
│ └── vss_video_analytics_api/
└── videos/
├── nv-warehouse-4cams/
├── warehouse-4cams-20mx20m-synthetic/
└── warehouse-loading-dock-3cams-synthetic/
RT-DETR は v1.0 → v1.0.1 にアップ、Sparse4D は v2.0 → v2.1 に進化しています。さらに前作で mkdir -p data_log/{elastic,kafka,redis,...} と手動で作っていたデータディレクトリもまとめて入っています。MDX_DATA_DIR をこのディレクトリに向けるだけで起動準備が整うので、初回セットアップの摩擦が体感で半分くらいに減りました。
DGX Spark 専用 hw env が部分的に登場
3.0.0 EA では NIM 用 hw 環境ファイルが hw-DGX-SPARK.env として用意されておらず、hw-DGX-THOR.env を流用して手動作成する必要がありました。3.1.0 で確認したところ、対応状況はこのようになっています。
| NIM | DGX Spark 用 hw env | 状態 |
|---|---|---|
cosmos-reason2-8b |
あり | 公式サポート |
nvidia-nemotron-nano-9b-v2-fp8 |
あり | 公式サポート（後述、中身は vLLM） |
nvidia-nemotron-nano-9b-v2（BF16） |
なし | 3 月のハマりポイントは継続 |
cosmos-reason1-7b |
なし | DGX Spark 非対応 |
nemotron-3-nano |
なし | DGX Spark 非対応 |
qwen3-vl-8b-instruct |
なし | H100 系のみ |
llama-3.3-nemotron-super-49b-v1.5 |
なし | H100 系のみ |
gpt-oss-20b |
なし | H100 系のみ |
Cosmos Reason 2 8B（VLM）と Nemotron Nano 9B v2 FP8（LLM）の組み合わせなら、3 月のハマりポイントは手当てされたことになります。一方で BF16 版 Nemotron や大型モデルは引き続き DGX Spark のローカル NIM では動かせません。Known Limitations にも以下の記述が残っています。
L4, RTX 6000 ADA, IGX-THOR and DGX-SPARK local NIMs are not supported
「DGX Spark で Local NIM を完全サポート」になったわけではなく、「FP8 + Cosmos Reason 2 という特定の組み合わせなら手当てされた」と読むのが正しいですね。前作で採用した「NGC vLLM での代替」は、依然として有効な選択肢です。
FP8 LLM の中身が公式 vLLM コンテナに
DGX Spark 用 hw env が用意された Nemotron Nano 9B v2 FP8 の compose を覗いてみると、もう 1 つおもしろい発見があります。
services:
nvidia-nemotron-nano-9b-v2-fp8:
image: nvcr.io/nvidia/vllm:25.12.post1-py3
command:
- python3
- -m
- vllm.entrypoints.openai.api_server
- --model
- nvidia/NVIDIA-Nemotron-Nano-9B-v2-FP8
NIM コンテナではなく、NGC の vLLM コンテナを使っています。前作で「LLM NIM が ARM64 で exec format error を返すので、NGC vLLM で代替する」と書いた workaround が、ほぼそのまま公式手段に昇格した形ですね。Tool calling のパーサーは Hugging Face の nvidia/NVIDIA-Nemotron-Nano-9B-v2 リポジトリから nemotron_toolcall_parser_no_streaming.py を取得して同梱、というところまで作り込まれています。
ARM64 NIM をフルで整備するよりも、vLLM ベースで素早く形にして配る方を優先した判断が透けて見えます。個人的には、この変化が一番気持ちよかったですね。
NIM ラインナップが拡充
最後に、3.0.0 EA から追加された NIM オプションを並べておきます。
| LLM オプション | DGX Spark 用 env |
|---|---|
nvidia/nvidia-nemotron-nano-9b-v2（既存） |
なし |
nvidia/nvidia-nemotron-nano-9b-v2-fp8（新規） |
あり |
nvidia/nemotron-3-nano（新規） |
なし |
nvidia/llama-3.3-nemotron-super-49b-v1.5（新規） |
なし |
openai/gpt-oss-20b（新規） |
なし |
| VLM オプション | DGX Spark 用 env |
|---|---|
nvidia/cosmos-reason2-8b（既存） |
あり |
nvidia/cosmos-reason1-7b（既存） |
なし |
Qwen/Qwen3-VL-8B-Instruct（新規） |
なし |
DGX Spark 単体で動かすなら現実的に Cosmos Reason 2 + Nemotron Nano FP8 の二択ですが、Remote NIM 構成（LLM_MODE=remote で build.nvidia.com を叩く）に切り替えれば、Llama 3.3 Nemotron Super 49B や gpt-oss-20b をクラウド経由で組み込むこともできます。「DGX Spark でフロントの分析、クラウド NIM で重めの推論」というハイブリッド構成は GA に向けて選択肢になりそうです。
まとめ
3 月時点の VSS 3.0.0 EA は「アーキテクチャは派手だが、DGX Spark で動かすには手作業の連続」という状態でした。5 月に 3.1.0 EA を追いかけてみると、こんな印象です。
- セットアップ周りは目に見えて改善: Minimal Profile デフォルト、Perception モデルとサンプル動画の app-data 同梱、データディレクトリの事前作成も不要に
- DGX Spark 連載文脈で一番大きいのは Cosmos Reason 2 + Nemotron Nano FP8 という組み合わせの公式サポート: 3 月の
exec format errorハマりは、この経路に乗れば回避できる - ただし BF16 版 Nemotron や大型モデルの Local NIM は引き続き未対応で、Remote NIM か vLLM 自前運用が現実解
- VLM-as-Verifier の独立サービス化、Agentic Search の Alpha、Multi-turn Agent Conversation 改善など、機能面でも EA 同士で世代が一つ進んだ感がある
そして事例パートで見えたのは、世界の製造業で VSS が「ソリューションプロバイダのプラットフォーム内部に組み込まれた映像理解エンジン」として浸透し始めているという事実です。Invisible AI、Tulip、Fogsphere、Pegatron のいずれも自社プロダクトの裏側で VSS を動かしていて、現場との接点はソリューションベンダー側が握る構図でした。日本の製造業に取り入れるなら、こうした内蔵型プラットフォームの導入か、自社向けのカスタム実装かの二択で、前作で試した日本語 LLM 差し替えは後者のアプローチに当たります。3.1.0 が示してくれた DGX Spark + FP8 + Cosmos Reason 2 の経路に、Nemotron 9B-v2-Japanese を vLLM 経由で差し替えるのが現実的なルートになりそうです。
GA を待つかどうかは、ユースケースによって判断が分かれます。安全監視や PoC レベルなら 3.1.0 EA はもう十分使える段階に入っています。一方で本番運用は EA のセキュリティ未成熟（TLS なし、認証なし、レート制限なし）が引っかかるので、GA 待ちの判断もありですね。3 月の記事で苦労した Alert Bridge パッチ 4 件が VLM-as-Verifier の独立サービス化でどう吸収されたか、Minimal Profile が本当に 5 分で立ち上がるか、このあたりは別の機会に実機で追いかけたいと思っています。
参考リンク
- VSS 3.1.0 EA フォーラム発表
- Warehouse Blueprint 3.1.0 Release Notes
- Warehouse Blueprint 3.1.0 Known Limitations
- Warehouse Blueprint 3.1.0 Prerequisites
- Warehouse Blueprint 3.1.0 Quickstart
- ハノーバーメッセ 2026 製造業 AI ブログ
- NVIDIA blog: VSS Blueprint（Pegatron 事例含む、2025-05-18）
- Invisible AI 公式
- Tulip Interfaces 公式
- Fogsphere 公式
- 前回の記事: VSS 3.0.0 EA を DGX Spark で試してみた
- Nemotron 3 Nano Omni を DGX Spark で動かしてみた（4 modality launch bench）
- Nemotron 3 Nano Omni × Cosmos Reason 2 × Gemma 4 を Heron-Bench / JMMMU で比較
