AI駆動開発 2026年9月22日

物理AIの安全性は「後付け」では詰む——NVIDIAが全層安全システムHalosで狙う構造的な先手

何の話か：物理AIが「証明責任」の時代に入った

自動運転車（AV）と産業用ロボットが、研究室やパイロットプログラムの外へ出ていく段階に入っている。

ABI Researchは2035年までにレベル3〜5の自律走行車が世界で4900万台規模のインストールベースを形成すると予測し、Omdiaは2026年から2035年の間に約6000万台の産業用ロボットが展開されると推計している。工場、倉庫、公道——これらは人と機械が同じ空間を共有する環境だ。

問題は、これだけの規模の機械が「動く」だけでなく「安全に動く」を証明できなければならないという点にある。しかも、導入前に一回チェックして終わりではない。ソフトウェアアップデート、新しいタスク、変化する運用環境——物理AIのライフサイクル全体を通じて安全性が継続的に担保される必要がある。

NVIDIAが「NVIDIA Halos」として打ち出しているのは、まさにその「証明の仕組み」を全層にわたって構築する取り組みだ。ハードウェアからソフトウェア、AIの行動、運用環境、認証プロセスに至るまで、一気通貫で安全性のエビデンスを積み上げるフルスタックシステムと位置づけている。

なぜ今それが重要か：安全性の「後付け」は構造的に無理

従来の機能安全（Functional Safety）のアプローチは、ハードウェアやソフトウェアの誤動作を想定したものだった。ISO 26262（自動車）やIEC 61508（産業機器）はその代表的な規格だが、これらはAIが推論した結果として「意図しない行動」を取るリスクを体系的にカバーしていない。

NVIDIAの元記事では、物理AI固有の安全課題として四つのシフトを挙げている。

動的環境への対応：道路や工場は静的ゾーンや物理バリアで完全にコントロールできない。自律システムは変化する状況を認識し、予期しないことが起きたときに安全な状態に遷移しなければならない。
AI行動固有のアシュアランス：テストは従来の機能安全とAIソフトウェアを並行して評価する必要がある。ISO/IEC TS 22440のような新規格がAI固有のリスクに対応し始めているが、業界全体の標準化はまだ途上だ。
展開が継続的であること：AVもロボットもソフトウェアアップデートで進化する。重要な変更が加わるたびに追加の安全テストが必要になり得る。
大規模検証にはシミュレーションが不可欠：実走行だけで想定されるシナリオ数と複雑さを網羅することは現実的でない。シミュレーション、合成データ生成、シナリオ再構成との組み合わせが必要になる。

ここが本質的な難しさだ。安全設計はシステムアーキテクチャに織り込まれて初めて意味を持つ。後から「安全層を追加する」という発想では、既存の設計との整合性、エビデンスの追跡可能性、認証の再取得など、コストが雪だるま式に膨らむ。「Built In, Not Bolted On（組み込む、後付けではなく）」というメッセージがNVIDIAの発表で繰り返されるのは、そのためだ。

事実の整理：Halosスタックの構成と第三者認証の状況

NVIDIAはHalosを、AVとロボティクスの両ドメインをカバーするフルスタック安全システムとして構成している。

AVドメインでは以下の層で構成される。

ハードウェア：NVIDIA DRIVE AGX Thorが安全エンジニアリング済みの計算基盤を提供し、NVIDIA Hyperionがレベル4 AV向けのフルスタック車両プラットフォームおよびリファレンスアーキテクチャとなる。
OS・ミドルウェア：Halos OSはASIL-D認証済みのDriveOS上に構築された統合ソフトウェア基盤。Halos CoreとHalos Middlewareがシステム分離・監視・決定論的通信をサポートする。
エンドツーエンドモデル：NVIDIA Alpamayoがオープンな推論ビジョン言語アクションモデルを提供し、ロングテールシナリオへの説明可能性を担う。
シミュレーション・検証：Halos Safety Evaluation Frameworkが安全ケース構築のためのツールとガイドラインを提供する。

ロボティクスドメインでは、NVIDIA IGX Thorが産業グレードのモジュールとして機能し、専用のFunctional Safety IslandをSoCに統合する。IEC 61508・ISO 13849準拠の開発をサポートする設計だ。さらに、オープンソースの「Halos Outside-In Safety Blueprint」が外部カメラとビジョンAIエージェントを使って施設レベルの安全監視を可能にする点も興味深い。オンボードセンサーの限界を外部視点で補う発想だ。

第三者認証の状況は以下の通りだ。TÜV SÜDがNVIDIAの自動車製品ライフサイクルソフトウェアプロセスおよびDriveOS 6.0をISO 26262 ASIL D認証し、自動車エンジニアリングプロセスをISO/SAE 21434に認証している。TÜV RheinlandはNVIDIA DRIVE AVのUNECE安全評価を独立して実施した。ロボティクス側でも、TÜV RheinlandがIGX Thor・Halos OS・Holoscan Sensor Bridgeの機能安全認証準備の検査を進めている。そしてANABがHalos AI Systems Inspection LabをISO/IEC 17020検査機関として認定している。

エコシステムの側では、Geely、いすゞ、Nissan（Wayveソフトウェア搭載）、EinrideがNVIDIA Hyperion上でレベル4対応車両を開発中。Uber、Grab、Lyftも同プラットフォームでロボタクシー開発を拡大している。ロボティクス側ではAgility RoboticsがDigit 5ヒューマノイドにIGX ThorとHalos Coreを統合し、KIONグループが自律フォークリフト向けに機能安全エージェントを開発中だ。

AIおじさんの見方：「安全認証インフラのデファクト化」という戦略読み

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

今回のHalos全体像で注目したいのは、技術スペックよりも「競争の軸をどこに設定しようとしているか」だ。

ISO 26262 ASIL Dの認証を自前で取得しようとすると、プロセス整備・文書化・外部審査のサイクルで年単位の時間と相当なコストがかかる。これをHalos Coreとして外部調達できるなら、開発者はその上の差別化——知覚精度、経路計画、サービス設計——に集中できる。NVIDIAが10年以上のAV安全開発と330本以上の研究論文、1000件以上の特許を積み上げてきたと述べているのは、単なる実績の話ではなく「これを自前で再現するコストを考えてみてください」というメッセージでもある。

もうひとつ見えてくるのが「調達条件の形成」というシナリオだ。Halos AI Systems Inspection Labに参加する企業がAUMOVIO、Bosch、Hesai、Valeo、Wayveなど業界の主要プレーヤーに及ぶ中、「Halos認証を通過していること」が将来的に顧客側の調達条件になるシナリオが現実味を帯びてくる。そうなると、エコシステムへの参加が事実上必須になる。技術の優劣ではなく、「認証済みかどうか」が市場参加の入り口条件になる構造だ。

この読み方が正しいとすれば、NVIDIAがやっているのは物理AIの性能競争での勝利ではなく、安全性を証明するインフラの先占だ。

ただ、留保も必要だ。現時点でHalosは進行中のプロジェクトであり、認証の多くは「準備の検査」段階にある。ASIL D認証を取得済みのコンポーネントと、認証準備中のコンポーネントが混在している点は把握しておく必要がある。発表の重みを正確に読むには、「認証済み」と「認証予定」の区別を丁寧に見ることが重要だ。

実務的な示唆と今後の論点

開発者・アーキテクト向け：安全設計は「後半のフェーズで対応する」ものではなくなっている。AIの行動アシュアランスをアーキテクチャ設計の初期から組み込まないと、後で認証を取ろうとしたときに設計の根本から見直しが発生するリスクがある。物理AIプロダクトを作っている、あるいは検討している組織は、安全設計のコストを初期見積もりに明示的に入れるタイミングに来ている。

プロダクト・経営側：「安全性の証明」はコストではなく、市場参加の条件として扱うべき段階だ。ロボタクシーが商業展開を拡大し、工場ロボットが人と同じ空間で動く世界では、保険・規制・調達の全てが「証明可能な安全性」を前提に動く。競合との差別化として安全性をアピールする以前に、最低条件として問われる。

今後追うべき論点が三つある。

ひとつは責任分配の問題だ。物理AIが事故を起こしたとき、プラットフォーム提供者（NVIDIA）・車両メーカー・システムインテグレーター・AIモデル開発者・オペレーターの間で責任はどう分配されるか。Halosのような共通基盤が普及するほど、この問いは複雑になる。技術の成熟と法制度の整備はほぼ確実にズレる。

ふたつ目はシミュレーション検証の規制受容だ。実走行マイレージを統計的なシミュレーション結果で補完するアプローチを、規制当局がどこまで認めるか。受け入れられれば開発コストと時間が大幅に変わるが、規制側の判断は慎重だ。

三つ目はAI行動の監査可能性だ。ISO/IEC TS 22440のような規格が整備されつつあるが、「AIがなぜその判断をしたか」を事後に追跡できる設計がどこまで普及するか。Alpamayoが説明可能性（explainability）を訴求ポイントにしているのはこの文脈だが、現時点では業界全体の標準にはなっていない。