ロボタクシーの安全性は「あとから足す」では間に合わない──NVIDIAが示したHalos OSの本質

ドライバーなしのタクシーが「日常」になり始めた

アプリが「お迎えに来ました」と通知する。乗り込んでみると、運転席に誰もいない。

これはもう、近未来の話ではない。世界の数十都市で、ロボタクシーサービスはすでに商業運用に入っている。NVIDIAが2025年のGTC Taipeiで発表した内容を見ると、その広がりは地理的にも組織的にも加速していることがわかる。

UberとAutoBrainsはミュンヘンでロボタクシープログラムを立ち上げる。FoxconnはNVIDIAとの協業を拡大し、台湾でロボタクシーフリートを展開する。VinFastはAutobrainsと組んで東南アジア市場にレベル4車両を投入する。そしてHUMAINはサウジアラビアでDRIVE Hyperion搭載のロボタクシーを展開しようとしている。いずれもNVIDIA DRIVE Hyperionプラットフォームを共通基盤にしている点が目立つ。

これだけのプレイヤーが同時に動き出しているということは、業界の重心が「できるかどうか」から「どう安全に展開するか」へと確実に移ったことを意味する。

なぜ今、「安全の組み込み方」が問われるのか

ロボタクシーの安全性をめぐる議論は、これまで「何を認識できるか」「どう判断するか」という知覚・意思決定の話が中心だった。それ自体は正しい問いだ。正確な認識、適切な判断、想定外への対応──どれも難しい技術課題であり、実際に進歩も続いている。

だが、規制当局が求めているのはそれだけではない。元記事の表現を借りれば、「システム全体が信頼性を持って動作すること、障害を拡大前に隔離できること、設計上の動作境界の外には絶対に出ないこと」が求められている。

つまり、「賢い判断ができる」と「安全に動作することを証明できる」は、別の話なのだ。

プロトタイプ段階では多少の曖昧さも許容されてきた。しかし商業運用に入り、不特定多数の乗客を乗せる段階になると、「ある確率で安全」ではなく「証明可能な安全」が求められる。認証、監査、文書化、再現性──これらを後から付け足すことは、構造的に難しい。だからこそNVIDIAが出してきたHalos OSのメッセージは「Built In, Not Bolted On（組み込む、後付けではなく）」という言葉になっている。

Halos OSとは何か──3つの構成要素を整理する

Halos OSはNVIDIAの「Halos」フルスタック安全システムの一部として位置づけられており、NVIDIA DRIVE Hyperion上に構築された安全基盤だ。構成要素は3つある。

Halos Coreは、いわゆるOSの核心部分で、自動車安全規格のISO 26262 ASIL D認証を取得している。ハイパーバイザーと呼ばれるソフトウェア層が安全クリティカルな機能を分離することで、障害が車両制御に到達しないよう設計されている。NVIDIA CUDAとTensorRTの安全認証済みサポートを含み、大規模言語モデルの推論向けにTensorRT Edge-LLMオープンソースフレームワークも提供する。

Halos SDKは、センサー統合の複雑さを解消する層だ。ロボタクシーはカメラ、レーダー、ライダー等のセンサーをそれぞれ異なるフォーマット・レートで扱う必要がある。センサー抽象化レイヤーにより、センサーの変更や追加がアプリケーションコード全体に波及しない設計になっている。加えて、ゼロコピープロセス間通信による低レイテンシ、決定論的なアプリケーションスケジューラ、システム全体のエラーハンドリングフレームワークなど、安全クリティカルなソフトウェアが要求するランタイムの基礎部品を揃えている。

Halos Applicationsは、AIモデルに対して決定論的・ルールベースのガードレールを設ける層だ。自動緊急ブレーキ、車線逸脱警告、ブラインドスポットモニタリング、衝突警告といった機能群を含むNVIDIA DRIVEアクティブセーフティスタックがここに入る。エンドツーエンドAIモデルとの組み合わせも想定されており、その際には説明可能性と透明性が必要とされるとしている。Alpamayoファミリーのオープンモデルがその文脈で言及されている。

さらに、クラウド側の開発インフラとしてHalos Infraがあり、AI学習・シミュレーション・検証をスケールで実行できる環境を提供する。NVIDIAは330本以上の研究論文と1,000件以上の特許がHalos OSの基盤を構成すると述べており、この数字は積み上げの重さを示している。

ここからは見方の話：「安全性のアーキテクチャ」が競争軸になる構造

ここからは事実ではなく、この動きをどう読むかという話になる。

今回のHalos OSの発表で注目したいのは、技術的な機能の話よりも「競争の軸がどこに移っているか」という点だ。

ロボタクシー市場は今、興味深い転換点にある。知覚・判断のAI部分は各社が独自に磨いていく部分だが、その下層にある「安全に動作することを証明するための基盤」は、各社が個別に作るより共通プラットフォームを使う方が合理的だという判断が広がりつつある。Foxconn、VinFast、Uber×Autobains、HUMAINがそれぞれ異なる市場・異なる文脈でありながら、DRIVE Hyperionという同じ基盤に乗ってきているのは、この構造を示している。

言い換えると、NVIDIAがやろうとしているのは、ロボタクシーの「安全認証インフラのデファクト化」だ。ISO 26262 ASIL Dという認証は自前で取ろうとすると時間もコストも相当かかる。そこをHalos Coreが提供するなら、開発者はその上で差別化に集中できる。このモデルは、クラウドインフラがAWS等に集約されたのと同じ力学を持っている。

ただし、留保も必要だ。「安全の基盤を共有する」ことには、逆説的なリスクもある。共通基盤に脆弱性があった場合、影響が広範囲に及ぶ。そして規制当局がどこまでこのプラットフォーム認証モデルを受け入れるかは、国や地域によって異なる。日本でも欧州でも、ロボタクシーの認可制度はまだ形成途上だ。

実務的な論点：開発者・事業者は何を確認すべきか

このニュースを受けて、実務的に何を考えるべきかをいくつか整理しておく。

自動車安全規格の認証状況を起点に見る習慣をつける。 新しいロボタクシー関連の発表を見るとき、「どの安全規格を取得しているか」「認証は自社取得か、プラットフォームに依存しているか」を確認することが判断の基準になる。ISO 26262 ASIL Dという言葉が出てくれば、少なくとも自動車安全の最高レベルを謳っているということだ。ただし認証の取得と実際の安全性は同一ではない点は忘れずに。

センサー統合コストの問題は思ったより大きい。 Halos SDKが解消しようとしている「センサーを変えるたびにアプリケーション全体を書き直す」問題は、現場で開発したことがある人なら痛さがわかるはずだ。ロボタクシーのフリートが拡大する局面で、センサーの世代交代や追加が避けられないなら、ここの標準化は見た目以上にインパクトが大きい。

「スケールでの検証」という問いは未解決のまま残っている。 Halos Infra、DGX、Omniverse、シミュレーション──これらを使ってスケールでの検証をすると言っているが、「どのくらいのシミュレーションで公道走行相当の安全証明になるのか」は業界全体でまだ答えが出ていない問いだ。この問いへの答えが明確になっていくプロセスが、今後の規制形成と並走していく。

責任の所在は誰も明確に答えていない。 ロボタクシーが事故を起こしたとき、プラットフォーム提供者・車両メーカー・オペレーター・AIモデル開発者の間で責任はどう分配されるか。Halos OSのような共通基盤が広まるほど、この問いは複雑になる。技術の完成度とは別に、法的・倫理的な責任構造の整備は明らかに遅れている。これは日本でも欧州でも同様だ。

まとめにかえて：次のニュースを見るときの軸

NVIDIAのHalos OS発表は、ロボタクシー市場が「走れるかどうか」の段階を超えて「証明できるかどうか」の段階に入ったことを示す、ひとつの指標として読める。

今後このジャンルのニュースを見るとき、確認したい軸はシンプルだ。「その安全性の主張は、独立した認証に基づいているか、それとも自社評価に留まっているか」。そこを見るだけで、発表の重みがかなり変わって見えてくる。

「ドライバーなしの車が来た」という体験が普通になる日は近いかもしれない。だが、それを支える仕組みがどこまで検証されているかを問い続けることは、利用者にとっても開発者にとっても、必要なことだと思う。

参考元: For Robotaxis, Safety Must Be Built In, Not Bolted On – NVIDIA Blog