モビリティ領域に NVIDIA スタックで挑む Cosmos から始める第⼀歩 製造ビジネステクノロジー部 モビリティチーム 若槻 ⿓太 

⾃⼰紹介 ● 若槻 龍太（わかつき りゅうた） 所属 ○ クラスメソッド株式会社 ○ 製造ビジネステクノロジー部 ○ モビリティチーム テクニカルリードエンジニア ● ● ● ● Japan AWS Top Engineers (2024 / 2025) Japan AWS All Certifications Engineers AWS Community Builders (User Group Leaders) JAWS-UG IoT 専門支部 運営メンバー ● ● ブログ書いてます https://dev.classmethod.jp/author/wa katsuki-ryuta/ ・島根県出雲地方出身 ・自動運転の普及が待ち遠しい 

1. NVIDIA の⾃動運転スタック概要 

NVIDIA と言えば、 何を思い浮かべますか？ GPU？ 生成 AI？ ロボットの Isaac Sim？ 

NVIDIA は⾃動運転への取り組みも強化している 2026 年 1 月 （CES） 2026 年 1 月 （CES） 2026 年 2 月 2026 年 3 月 （GTC） 2026 年 6 月 2026 年 8 月 Alpamayo ファミリーを発表。10B の推論型 VLA モデル、AlpaSim、 1,700 時間のデータを公開 DRIVE Hyperion のエコシステムを拡大。Bosch、Sony、ZF など部 品各社が参画 メルセデス・ベンツが新型 S クラスに DRIVE Hyperion と L4 対応の DRIVE AV を搭載予定 Alpamayo 1.5 を公開。ティアフォーが Autoware に統合、いすゞの L4 バスが DRIVE AGX Thor を採用 Cosmos 3 を発表。Alpamayo 2 Super のベースになる Cosmos 3 Super Reasoner を含む Alpamayo 2 Super（34B）を公開。ファミリー全体の重みを商用利用 できるライセンス（OpenMDW-1.1）に変更 出典: NVIDIA Newsroom / NVIDIA Japan Blog の各発表、調査メモ「NVIDIA の自動運転施策 整理」8-1 

では、⾃動運転で何を提供しているのか。公式ページを⾒て も、製品名が多くて全体像が分かりにくい ● DGX、Omniverse、 Cosmos、RTX、DRIVE AGX、Halos、Hyperion、 Alpamayo と製品名が並ぶ ● それぞれの機能や関係性 が分かりづらい 出典: NVIDIA「自動運転車ソリューション」ページ （2026-10-24 時点のキャプチャ） 

整理すると、学習‧検証から⾞載までのスタック⼀式を提供 している DRIVE AGX （Thor / Orin） DRIVE Hyperion Alpamayo Cosmos Omniverse NuRec Halos これらは、縦方向の垂直スタック と、横方向の改善パイプラ インの 2 軸に整理できる（本セッションでの整理） 

縦のスタック: 6 層全てを取り揃え、各層を単独でも採⽤可 能としている 学習・検証基盤 DGX、Cosmos、Omniverse NuRec、AlpaSim / AlpaGym AI モデル Alpamayo（推論型の VLA モデル） 車載ソフト DRIVE AV、DriveOS / DriveWorks 車載ハード DRIVE AGX（Thor / Orin） 車両リファレンス DRIVE Hyperion（センサー配置と安全設計を含 む） 今日扱うのは、いちばん上の「学習・検証基盤」の層にある Cosmos Halos 安全 認証 全層 

いちばん上の学習‧検証基盤の層を横に広げると、横の軸の 改善パイプラインになる 学習・検証基盤 AI モデル 実走行の 映像を集め る 足りない条 件の映像を 生成する 録画に無い 視点を作る 映像でモデ ルを学習す る シミュレー ションで検 証する 車載ソフト AWS（S3） Cosmos NuRec DGX AlpaSim ◀ 評価の結果から足りない条件を見つけ、再び映像を生成する 車載ハード 横の軸: 学習・検証基盤のツール群を、データの流れに沿って並べたもの 車両リファレンス ● 縦の軸（前のスライド） ● 縦の 1 層にまとまっているツール群は、横に並べると「集めて、 生成して、学習して、検証する」流れになる この流れは AWS などのクラウドと組み合わせて動かす。まず、 なぜ「生成」と「検証」が必要なのかを見る 

学習‧検証の層が必要なのは、実⾛⾏だけでは安全を証明す ることが⾮常に難しいから 出典: RAND, Driving to Safety（2016） 人間並みの安全性を示すだけで、数億〜数 千億マイルの走行が必要になる。既存の車 両台数では数十〜数百年かかる だから、足りない走行はシミュレーションで 補う必要がある 同ページの Key Takeaways。実走行の 試験だけでは、安全性を示す十分な証拠 にならない 

シミュレーションには録画に無い映像が必要。NuRec で視 点を作り、Cosmos で条件を変える Omniverse NuRec: 1 本の映像から「 2m 左を 走った場合」「右 90 度」の映像を作る（ AWS Summit 2026、筆者撮影） Cosmos Transfer 2.5: 実写の映像を雪の場 面に変換する（同ブース、筆者撮影） 

この横の軸を AWS と組み合わせた構成が、AWS Summit 2026 の AWS ブースで⽰されていた 【ブースレポート】 AWS と NVIDIA による自動運転 / ADAS 向けワー クロードの展示を訪問してきた 開発の全体像、2 つのアーキテク チャ例、Cosmos Transfer と NuRec のデモが展示されていた dev.classmethod.jp/articles/aws-summit-2026-aut onomous-driving-adas-nvidia/ AWS Summit 2026 のブース（筆者撮影） 

展⽰されていた構成の 1 つは、データ前処理を中⼼にしたも のだった ● ● アーキテクチャ例 2（ブースの展示、筆者撮影） 車から S3 への取り込みか ら、シミュレーション上でソフ トを動かす検証（SIL）まで を、1 つの構成図で示して いる 各ステージに AWS のサー ビスと NVIDIA のコンポー ネントが対で示されている 

このパイプラインの各ステージに、AWS は NVIDIA のコン ポーネントを組み込んでいる 1 取り込み S3、Data Transfer Terminal – 5 データ拡張 EC2（GPU） Cosmos Transfer 2 品質確認・抽 出 AWS Batch – 6 ニューラル再 構成 AWS Batch Omniverse NuRec 3 キュレーション 4 検索 SageMaker HyperPod Cosmos Curator OpenSearch Service Cosmos Dataset Search 7 モデル訓練 8 シミュレーショ ン検証（ SIL） SageMaker HyperPod Alpamayo EC2 AlpaSim 各カードの上段はステージ、中段は AWS 側、下段は NVIDIA 側を示す。この構成 は AWS Industries Blog で公開されている。私たちが担うのは、これらを組み合わ せて安く確実に運用する作業である 

その中で Cosmos は 4 つのコンポーネントからなり、今⽇ 扱うのは Transfer コンポーネント 何をするか 自動運転での用途 Predict 未来の映像を予測して生 成 実際には起きなかった危険な場面 の映像を生成する Transfer 実写の映像を、雪・夜・霧・ 1 本の実走行映像から、多様な気象 雨など別の条件の映像に 条件の映像を作る 変換 Reason VLM による映像の理解・ 要約 Curator 大規模動画のキュレーショ 学習データの選別・重複排除 ン 走行ログの検索・キャプション 今日扱うのは Transfer 2.5（2B）で、Cosmos 3（2026-06 発表、Transfer 系は 16B）は対象外としている 

この章のまとめ ● 縦（NVIDIA）: 学習‧検証から⾞載までを⼀式で提供し、使 うほど GPU の利⽤が増える構造になっている ● 横（AWS）: データパイプラインの各ステージに NVIDIA の コンポーネントを組み込む。この構成は AWS Industries Blog で公開されている ● 検証はシミュレーションが前提で、危険な場⾯の映像は⽣成 する。その⽣成に使うモデルの 1 つが Cosmos Transfer で ある 

2. 検証: Cosmos Transfer 2.5 で ⾞載映像を霧‧⾬‧夜に変換する 

実⾏環境の選択肢は AWS、NVIDIA Brev、DGX の 3 つ。今 回は Brev を使った AWS NVIDIA Brev DGX 本番の運用先。第 1 章で紹 介したパイプラインを AWS 上に組む NVIDIA の GPU クラウド。複 数プロバイダの GPU を選 び、時間単位で利用する 手元に置く NVIDIA の GPU 機器（DGX Spark など） GPU インスタンスの利用に は利用枠の申請が必要で、 すぐには確保しにくい 申請なしで H100 80GB を $3.00/hr で確保できた 

検証の内容: 公式サンプルの⾞載映像 4 秒を、霧‧⾬‧夜に 変換した ● 制御映像（エッジ、ブラー）は 入力から自動生成した ● パラメータは 3 本の映像で 共通にし、プロンプトだけを 差し替えた 入力の 60 フレーム目（公式サンプル、晴天、 1280×720、121 フレーム） guidance 7 / num_steps 35 / seed 42 edge 0.35（medium） vis 0.24（very_high） 

検証の⼿順: インスタンスを作り、コードとモデルを取得 し、spec を書いて実⾏する 1 2 Brev で H100 80GB のイ ンスタンスを作成する 4 5 spec（JSON）にプロンプ ト、negative_prompt、 edge / vis の重みを書く GitHub の cosmos-transfer2.5 を clone し、uv で Python 3.10 の環境を作る python examples/inference.py -i specs/*.json -o outputs/ で実行する（3 本の映像で 53 分） 3 6 Hugging Face で 3 つの モデルのライセンスに同意 し、hf auth login でトーク ンを登録する 出力の動画・制御映像・ロ グを確認し、入力と異なる 内容になった領域を調べ る 手順の詳細は記事に載せている。spec は映像 1 本につき 1 ファイルで、プロンプトと制御の重 みだけを差し替える 

GPU は NVIDIA Brev の H100 80GB インスタンスを時間単 位で利⽤した ● ● ● ● NVIDIA Brev の GPU 選択画面 hyperstack（Montreal） の H100 PCIe 80GB × 1、$3.00/hr 28 CPU / 180GB RAM / 850GB 停止と再開はできない ため、使い終わったら削 除する 環境構築から実験まで の所要時間は 4 時間 40 分、費用は約 $14 だった 

spec ① 霧: 天候はプロンプトで指⽰し、⼊⼒の構図は edge と vis の制御で保つ { } "name": "car_fog", "video_path": ".../car_example/car_input.mp4", "prompt": "A driving scene through a modern urban environment, captured from a dashcam inside a vehicle. Dense fog fills the air, heavily reducing visibility. ...", "negative_prompt": "Clear sunny weather, high visibility, crisp sharp horizon, ...", "guidance": 7, "num_steps": 35, "seed": 42, "edge": { "control_weight": 0.35, "preset_edge_threshold": "medium" }, "vis": { "control_weight": 0.24, "preset_blur_strength": "very_high" } プロンプト（日本語訳） 車内のダッシュカムから撮影した、近代的な都市部の走 行シーン。濃い霧が立ちこめ、視界が大きく落ちている。 遠くの建物は一様な灰白色のもやの中に消え、ガラス張 りの高層ビルの上層階はほとんど見えない。すぐ前方の 黒い車はまだ見えるが、輪郭はぼやけ、赤いテールラン プが霧の中で光っている。左の歩道の木々と歩行者は薄 いシルエットに見える。多車線の路面は湿っていて、拡散 した光を反射している。ロードコーンと白い矢印の路面標 示はアスファルト上に見えたままである。車が交差点に 向かって一定の速度で進む間、カメラは固定されている。 negative_prompt（日本語訳） 晴天、高い視程、くっきりした地平線、雲ひとつない空、 明るい日差し、澄んだ空気 guidance・num_steps・seed と edge・vis の設定は 3 本の映像 で共通で、差し替えるのは prompt と negative_prompt だけで ある 

spec ② ⾬: 差し替えるのは prompt と negative_prompt だけで、パラメータは霧と同じ { } "name": "car_rain", "video_path": ".../car_example/car_input.mp4", "prompt": "A driving scene through a modern urban environment, captured from a dashcam inside a vehicle. Heavy rain is falling under a dark overcast sky. ...", "negative_prompt": "Clear sunny weather, dry road, blue sky, bright sunshine, ...", "guidance": 7, "num_steps": 35, "seed": 42, "edge": { "control_weight": 0.35, "preset_edge_threshold": "medium" }, "vis": { "control_weight": 0.24, "preset_blur_strength": "very_high" } guidance・num_steps・seed と edge・vis の設定は 3 本の映像 で共通で、差し替えるのは prompt と negative_prompt だけで ある プロンプト（日本語訳） 車内のダッシュカムから撮影した、近代的な都市部の走 行シーン。暗い曇り空の下で激しい雨が降っている。雨 の筋が視界を横切り、雨粒がフロントガラスに当たる。多 車線の道路は濡れていて、水たまりと濡れた光沢が、 ヘッドライトと、すぐ前方の黒い車の赤いテールランプを 反射している。車のタイヤから水しぶきが上がる。左の歩 道の歩行者は傘を差し、木々の下を足早に歩いている。 ガラス張りの建物は灰色の空を映している。ロードコーン と白い矢印の路面標示は濡れたアスファルト上に見え る。車が交差点に向かって一定の速度で進む間、カメラ は固定されている。 negative_prompt（日本語訳） 晴天、乾いた路面、青空、明るい日差し、くっきりした影、 高い視程 

spec ③ 夜: 同じく⽂⾯だけを差し替える。「空は暗い」と 書いた点を、後で結果と照らし合わせる { } "name": "car_night", "video_path": ".../car_example/car_input.mp4", "prompt": "A driving scene through a modern urban environment, captured from a dashcam inside a vehicle at night. The sky is dark. The scene is lit only by street lights, ...", "negative_prompt": "Daylight, bright sky, sunshine, blue sky, overexposed scene, ...", "guidance": 7, "num_steps": 35, "seed": 42, "edge": { "control_weight": 0.35, "preset_edge_threshold": "medium" }, "vis": { "control_weight": 0.24, "preset_blur_strength": "very_high" } プロンプト（日本語訳） 車内のダッシュカムから夜に撮影した、近代的な都市部 の走行シーン。空は暗い。街灯、車のヘッドライト、道路 沿いの高層ビルの明かりのついた窓だけが場面を照らし ている。ネオンサインと信号機が赤・緑・オレンジに光り、 その光がアスファルトに反射している。すぐ前方の黒い車 は明るい赤のテールランプを点けている。左の歩道の 木々と歩行者は街灯にほの暗く照らされている。ロード コーンと白い矢印の路面標示はヘッドライトの光の中に 見える。車が交差点に向かって一定の速度で進む間、カ メラは固定されている。 negative_prompt（日本語訳） 日中の光、明るい空、日差し、青空、露出過多の場面、 日中の澄んだ視界 guidance・num_steps・seed と edge・vis の設定は 3 本の映像 で共通で、差し替えるのは prompt と negative_prompt だけで ある 

利⽤したリソース: コードは GitHub、モデルは Hugging Face、⼊⼒映像は公式サンプルから取得した 種類 内容 実行環境 NVIDIA Brev（brev.nvidia.com）。hyperstack の H100 PCIe 80GB × 1、$3.00/hr コード GitHub nvidia-cosmos/cosmos-transfer2.5（examples/inference.py、 assets/car_example） 手順書 Cosmos Cookbook の Setup ページ、Transfer 2.5 の Quickstart Guide （docs.nvidia.com） モデル Hugging Face の nvidia/Cosmos-Transfer2.5-2B（本体）、Cosmos-Guardrail1、 Cosmos-Predict2.5-2B（VAE / tokenizer）。3 つとも gated で、利用前に同意が必要。 Cosmos-Reason1-7B は自動取得。合計 34GB 入力映像 公式サンプル assets/car_example の car_input.mp4（1280×720、121 フレーム、約 4 秒）と car_prompt.txt ツール uv（Python 環境の構築）、 hf CLI（ログインとモデル取得） 

補⾜: 環境構築でハマったポイント ハマりポイント 内容 Hugging Face のアクセ ス許可 モデルは 3 つのリポジトリに分かれている。Transfer を 動かすには、Predict のリポジトリにもアクセス許可が必 要になる Python のバージョン リポジトリの指定は 3.13 だが、flash-attn のパッケージ が 3.10 向けしか無い。3.10 を明示して環境を作る モデルの保存先 ディスクの表示は 850GB だが、ルートは 97GB しか無 い。34GB のモデルは HF_HOME を指定して /ephemeral 側に保存する 

⽣成の結果: 霧‧⾬‧夜の天候は表現できた。⾞線‧⽮印‧ 前⾛⾞の位置は 3 本の映像とも⼊⼒と同じだった 入力（晴天） 霧 雨 夜 

補⾜: 実⾏に必要な VRAM と所要時間 項目 公式 実測 VRAM（vis のみ） 24GB 以上 65,679 MiB VRAM（edge + vis） 40GB 以上 67,517 MiB 映像 1 本（4 秒）の所要時間 – 約 17 分 モデルのファイル容量 – 34GB VRAM は公式ドキュメントの 24GB では足りず、実測では約 64GB を使っ た。80GB の GPU が必要になる 

補⾜: 映像 1 本の⽣成に約 17 分かかり、そのほとんどをサ ンプリングが占める 前半 1〜93 フレーム 7 分 52 秒 後半 94〜121 フレーム 7 分 52 秒 灰色: 前後の処理（合わせて約 1 分） ● 121 フレームを前半と後半に分けて生成するため、サンプリングが 2 回 実行される ● パラメータを 10 通り試すと、約 3 時間かかる 

出⼒をよく⾒ると、画⾯下部と左奥のビルに、⼊⼒と異なる 内容が⽣成されている 霧 雨 夜 赤枠: 入力と異なる内容が生成された領域（60 フレーム目） ● 画面下部にダッシュボードとボンネットが生成される（雨と夜） ● 左奥のガラス張りのビルが別の建物に置き換わる（3 本の映像とも） ● 中央奥のビルが別の形に変わる 

仮説①: 置き換わるのは、エッジ制御映像で輪郭が写ってい ない領域ではないか 入力（60 フレーム目） エッジ制御映像（閾値 medium）。左奥 のビルと路面に輪郭が無い ● 置き換わった領域と、輪郭が無い領域は重なっている。輪郭が無い領 域では、入力を参照せずプロンプトだけから生成されていると考えられ る ● 想定と異なる出力が出たら、まず出力ディレクトリの制御映像を確認す る 

仮説②: 夜の空が明るいままなのは、vis 制御が⼊⼒の明る さを保つためではないか 夜の出力。窓とネオンは夜になったが、 空は明るい灰色のまま ブラー制御映像。入力の昼の明るさがそ のまま保持され、空は白い ● vis は入力の明るさの配置を保持し、「空は暗い」というプロンプトより優 先されていると考えられる ● 一様な面（空・海面）が画面の大部分を占める映像で起きやすい 

実験①: エッジの閾値を下げても、左奥のビルは⼊⼒どおり にならなかった # car_fog → car_fog_edge_verylow "edge": { "control_weight": 0.35, "preset_edge_threshold": "medium" + "preset_edge_threshold": "very_low" }, 変更前 ● ● エッジ制御映像では、左奥のビルの縦の 輪郭が増えた。ただし出力では、入力のガ ラス張りの外観には戻らなかった 路面のように輪郭そのものが無い面には 影響しない 変更後 → medium: 左奥のビルが別の建物に very_low: 輪郭は増えたが、外観は入力と 異なる 

実験②: vis の重みを下げると空は暗くなるが、構図が崩れ る # car_night → car_night_vis005 "vis": { "control_weight": 0.24, + "control_weight": 0.05, "preset_blur_strength": "very_high" } 変更前 ● ● 空が暗くなり、夜の映像になった 副作用で建物の形が変わり、ダッ シュボードが生成された。vis は 構図も保持している 変更後 → vis 0.24: 空が明るい灰色のまま vis 0.05: 空は暗いが構造が崩れる 

実験①②のまとめ: 各制御が⼊⼒のどの要素を保持するかを 把握したうえで、調整するパラメータを選ぶ 症状 対処 結果 構造物が別の内容に置き 換わる edge の閾値を下げる 輪郭は増えたが、外観 は入力どおりにならな かった（実験①） 天候・時間帯の指示が通ら ない vis の重みを下げる 反映された。構造の保持 は弱まる（実験②） vis を下げたら構図が崩れ た edge の重みを上げる 未検証 輪郭の無い面に、入力に無 いものが生成される mask_prompt で領域指定 未解決 

3. まとめと次の⼀歩 

まとめ 1. NVIDIA は学習から⾞載までのスタックを 1 社で提供し、AWS は それをデータパイプラインの各ステージに組み込んでいる 2. 検証はシミュレーションが前提になる。実⾛⾏では集めにくい危 険な場⾯の映像を、Cosmos Transfer で⽣成する 3. 意図した映像を得るにはパラメータの試⾏錯誤が必要だが、1 回 の⽣成に時間がかかる（今回の 4 秒‧720p‧H100 の条件で約 17 分）。制御映像で原因の⾒当を付けてから、調整するパラメータ を選ぶ 

最終的に⽬指すのは、認識モデルを改善する流れを繰り返し 実⾏し続けること 足りない条 実際に撮影 → 件の映像を した映像 生成する 生成した映 → 像を評価す る 映像でモデ → ルを学習す る モデルの精 度をシミュ → レーション で評価する ◀ 評価の結果から足りない条件を見つけ、再び映像を生成する ● 今日の検証（天候の変換）は、この流れの 2 つ目にあたる。制御映像の 確認は、生成した映像を評価する工程の一部にあたる ● NVIDIA はこの流れを、人の手作業からエージェントが評価と改善を行 う段階へ進めようとしている。TAO 7 の Agent Skills の公開事例では、 精度が 54.41% から 93.35% に改善している 

そこへ⾄るには 4 つのフェーズがある。今⽇の検証はフェー ズ 1 にあたる フェーズ 内容 この段階で分かること 1. 天候変換の設定 パラメータとプロンプトを探索し、条 件別の設定を残す 意図した見た目をどこ まで作れるか 2. 合成データのパ イプライン化 生成した映像の評価を仕組み化す る 学習に使える映像を継 続して出せるか 3. ドメイン特化の学 習 映像で Cosmos をポストトレーニン グする 既定のモデルより精度 が上がるか 4. 自動改善（ゴー ル） 評価と改善をエージェントに任せ、人 人手をかけずに改善 の作業を減らす が続くか 

フェーズ 4 の達成イメージ: 4 つの画⾯で改善の流れをつな ぐモックアプリ ① 学習に使う映像を貯める、探す ② 足りない条件の映像を生成し、評価する ③ 選んだ映像でモデルを学習する ④ モデルのバージョンを管理し、シミュレー ションで評価する 

次の⼀歩: フェーズ 1 を進めるために、次に確かめたいこと ● Cosmos 3（2026-06 発表）の Transfer 系で同じことができるか ● mask_prompt による領域指定で、路面・空の生成を抑えられる か ● モックアプリを、生成・評価・学習の実際の処理を含めて動く形に する 

11月6日、製造ビジネステクノロジー部単体のオンライン会社説明会を実施します 日比谷Cafeから 生配信形式 🎬 19:00~ スタート 

スタンプラリーに挑戦しよう！ イベント会場（20会場）に、 QRコードが設置されております！ 全部集めて景品をGETしよう！ ※スタンプコンプリート先着10名様に 豪華景品をプレゼント！ 景品引き換え場所 ⽇⽐⾕フォートタワー26階 メイン会場 Cafe （くらにゃんブース横） 感想は ハッシュタグ #devio2026 

アンケートにご協⼒お願いします！ DevIO Passから回答が可能です