自動運転におけるMLOpsと2026年5月現在の動向を調べてみた

Posted at 2026-05-31

はじめに

前回の記事では、AWSを活用した「実運用を意識した最小構成」を題材に、MLOpsの全体像やデータ・特徴量の管理、そして継続的学習（CT）の仕組みについて解説しました。筆者の私自身も機械学習システムを壊さずに継続運用するためのライフサイクル設計について、共通の理解を深めることができたと感じています。

前回の記事はこちら：AWS構築を想定したMLOPsパイプラインの全体像と考え方

今回はその続編として、自動運転システムにおける次世代MLOpsアーキテクチャについて調べましたので記事にしていこうと思います。特に2026年5月に発表された「5層アーキテクチャ（5-Tier Connected ADS MLOps Architecture）」（参考論文: arXiv:2605.12719）が面白い＆今後の潮流になるのではないかと思ったので本記事ににおける次世代MLOPsアーキテクチャは本論文で紹介されているもの、として記載します。

こんな人に読んでほしい

本記事は、以下のような方に向けて執筆しています。

一般的なMLOpsの全体像（データ管理やパイプライン）を理解した方
自動運転（AD/ADAS）領域における最先端のソフトウェアおよびシステムアーキテクチャ動向に関心がある方
「安全性保証」と「継続的学習」を高度に両立させる、実践的な知能システム設計に興味がある方

今回の記事は機械学習の基礎知識や前回の記事のようなMLOPsの基本概念については理解していることを前提としています。

本記事で学べること

この記事を読むことで、以下の知識を体系的に学ぶことができます。

一般的なWeb系MLOpsと、自動運転MLOpsの決定的な違い
接続型自動運転のための最新リファレンス「5層アーキテクチャ（5-Tier ADS MLOps Blueprint）」の全体像
車両（エッジ）とクラウド（車両群＝フリート）を結ぶ、自己進化型「集合学習」のメカニズム
自動運転MLOps特有の「シミュレーション（SIL/HIL）検証」と「安全性ケース（Safety CCA）」の仕組み
ROS2やZenoh、AUTOSAR Adaptiveといった車載特有 of の技術スタックの整理

それでは、通常MLOpsと自動運転MLOpsの違いから見ていきましょう。

通常MLOpsと自動運転MLOpsの違い

自動運転システムの開発や運用（以下、自動運転MLOpsやAVOpsとも呼ばれます）は、一般的なWebサービスのMLOpsとは、その設計思想や評価軸が異なります。

まずは、自動運転の文脈で頻出する自動車業界特有の必須キーワードを整理し、通常のMLOpsとの違いについて紐解いていきます。

自動運転を理解するための必須キーワード

自動運転や車載ソフトウェアの領域では、独自の専門用語が数多く使われます。初学者の方にも分かりやすいよう、その本質的な意味を解説します。

ADAS / AD（先進運転支援システム / 自動運転）
ADAS（Advanced Driver Assistance Systems）は、衝突被害軽減ブレーキや車線維持支援など、ドライバーの運転操作をサポートするシステムの総称です。一方、AD（Autonomous Driving）はシステム自身が主体となって運転を行う自動運転を指します。どちらも、カメラやLiDARといった車載センサーから得られるデータを高度なAIモデルで認識・判断する点が共通しています。
ODD（運行設計領域：Operational Design Domain）
自動運転システムが安全に作動するための前提条件（場所、天候、速度、時間帯など）の定義です。例えば「高速道路上のみ」「時速60km以下」「晴天時のみ」といった制約です。この範囲（ODD）から外れる場合は、システムがドライバーに運転交代を促すか、安全に車線へ停止するフェイルセーフ動作を行う必要があります。
DDT（動的運転タスク：Dynamic Driving Task）
ステアリング操作、加減速、周囲の監視、合流や車線変更の判断など、走行中の運転操作のすべてを指す言葉です。自動運転向けAIモデルは、まさにこのDDTを人間のかわり行う「頭脳」の役割を果たします。

通常のMLOpsと自動運転MLOpsの対比

最も大きな違いは、評価軸が「ビジネスの利益（精度）」から「人命（安全性）」にシフトすることです。以下の表に主要な観点での違いをまとめました。

評価の観点	通常のMLOps（Web系など）	自動運転のMLOps
最優先の評価指標	精度（F1スコアやAUCなど）の平均値	安全性（致命的なエッジケースの排除）
モデルの検証手法	既存テストデータでのオフライン検証	仮想空間での閉ループシミュレーション
アノテーション	人手（クラウドソーシング等）による分類	自動ラベリング＋アクティブラーニング
デプロイの目的	新機能の追加やビジネスロジックの改善	ODD内での安全性ケースの継続的強化
更新パイプライン	CI/CD（継続的統合・配備）	CI/CD/CT ＋ SafetyOps

1. 精度重視から「安全性最優先」へのシフト

通常のMLOpsでは、モデルの予測精度が99.9%であれば大成功です。しかし自動運転では、10,000回中9,999回正しく前方の歩行者を検出できても、残りの1回で検出を誤って事故を起こしてしまえば許されません。
そのため、平均的な精度の高さだけでなく、極限状態で発生する「失敗ケース（最悪シナリオ）」を確実にゼロに近づける安全性保証が最も重要視されます。

2. オフライン評価の限界と「閉ループ検証」の必要性

一般的な機械学習モデルは、あらかじめ用意した評価用データセットを入力して正解率を測定する「オフライン評価」を行います。
しかし車両の運転は、AIの出力（ハンドルを切る、ブレーキを踏む）によって周囲の車や道路の状況（次の入力データ）が刻々と変化する「閉ループ（クローズドループ）」の動的システムです。
そのため、固定されたデータだけで検証を行うのには限界があり、仮想の3D空間で車両モデルを実際に走らせて挙動を検証する「シミュレーション（SimulationOps）」が必須プロセスとなっています。

このように、自動運転MLOpsでは、単なるパイプラインの自動化にとどまらず、自動車業界が長年培ってきた「安全性保証のプロセス」と融合させる高度なアプローチが求められます。

次に、これらの厳しい要求を満たすために提案されている次世代のアーキテクチャ「5層構造」の全体像について解説します。

次世代アーキテクチャ：5層集合学習ブループリントの全体像

自動運転システムの安全性と継続的学習を高い次元で両立させるために、どのようなシステムが必要なのでしょうか。

ここで注目したいのが、先ほども述べた「5層アーキテクチャ（5-Tier Connected ADS MLOps Architecture）」です。

このアーキテクチャの立ち位置

従来のMLOpsは、クラウド上の「自動訓練パイプライン」や「APIのデプロイ」といった、システムの一部（点）に焦点を当てたものが主流でした。

しかし、実際の自動運転では、実車（エッジ）から送られてくる膨大な走行ログを効率的に集約し、クラウドで新たなモデルを安全に学習・評価し、再び車載SoCへと配信するという、車とクラウドを結ぶ広範なシステム（線と面）の設計が必要になります。さらに、近年のソフトウェア・ディファインド・ビークル（SDV：ソフトウェアを中心に定義される自動車）の潮流により、自動車の知能を数日・数週間単位で迅速にアップデートする重要性が増しています。

今回は、その切り口となるアーキテクチャとして提案されている「5層アーキテクチャ（5-Tier Connected ADS MLOps Architecture）」を中心に紹介していきます。
この「5層アーキテクチャ（5-Tier Connected ADS MLOps Architecture）」は、学術的な理論だけで突如として生み出されたものではありません。テスラが先駆者として実用化した「シャドウモード（バックグラウンド検証）」や、Waymoなどが実戦投入している「閉ループシミュレーション検証」、さらにはドイツの産学官メガプロジェクト「UNICARagil」（主要な自動車メーカーや技術ベンダー、大学が参画する次世代自動運転コンソーシアム）などにおいて、各OEMやサプライヤーが部分的に開発・提案・実装してきた技術や設計思想を学術的に集約し、自動車業界共通の総合設計図として体系化したものです。

単なる「AIモデルの学習フロー」ではなく、インフラ、フリート運用、車載エッジ制御、そして安全性評価（SafetyOps）までを一気通貫でカバーしています。

5層集合学習アーキテクチャの全体図

このアーキテクチャは、開発層（Layer 1）から車両運用層（Layer 5）までの5つの階層で構成されています。それぞれの層が独立しつつ、双方向のデータ循環ループによって密に連携しています。

以下に、その全体構造を示します。

双方向のデータ循環：UP / DOWNループ

このアーキテクチャの中核は、階層間を流れる双方向のデータ循環メカニズムです。

アップストリーム（UP）：脅威の検知と遡上
実車が物理世界で遭遇した「微小な異常」や、新旧モデルの出力が食い違う「乖離データ」を検知し、車載からフリートデータストア（FDS）へと送信します。そして、フリート全体の「集団学習（Collective Learning）」によって過信を正し、最終的に「評価層」へと危険事象をエスカレーション（遡上）します。これにより、実世界の未知の危機（ブラックスワン事象）を既知のエッジケースに変換します。
ダウンストリーム（DOWN）：適応と配備
開発・学習された新しいAIモデルを、安全性検証（HIL/SILテスト）および「安全性ケース信頼性評価（Safety CCA）」という厳格なゲートキーパーに通します。安全性が確認・承認されたモデルだけが「Valid App Registry（承認アプリ登録所）」に登録され、OTA（Over-The-Air：無線配信）を通じて、実車（エッジ）へ安全にデプロイされます。

この双方向のループが正常に機能することで、システムは自己進化する知能として機能し、より複雑な環境へと自律的に適応していくことが可能になります。

続く第4章では、この全体図を構成する5つの各レイヤーの役割と、多重分岐フィードバックを司る中核ゲートキーパー「Safety CCA」の具体的な機能について詳細に見ていきます。

5つのレイヤーの役割と多重分岐フィードバックの詳解

3章では、実車とクラウドを結ぶ次世代の「5層アーキテクチャ」の全体像と、UP/DOWNループによる双方向のデータ循環について解説しました。

4章では、この全体図を構成する5つの各レイヤーの役割を紐解いていきます。ただし、各レイヤーの解説に入る前に、まずはそれらの連携と検証を支える3つの難解なキーワードについて、事前に分かりやすく整理しておきます。

これらの基本コンセプトを理解しておくことで、各階層の役割が格段にスムーズに理解できるようになります。

自動運転MLOpsを成立させる中核技術・コンセプト

自動運転システムの検証や運用プロセスを支える、極めて重要な3つの基本概念です。

1. SIL / HIL（ソフトウェア / ハードウェア・イン・ザ・ループ検証）

自動運転のシステム検証では、実車にいきなり未検証のAIを載せるわけにはいきません。そこで、以下の2つのテスト手法（X-in-the-Loop）を段階的に実施して安全性を確認します。

SIL（Software-in-the-Loop）: 仮想のシミュレータ上に構築した3D空間と、仮想の車載ソフトウェアをPC内で接続し、挙動をテストする手法です。すべてソフトウェアのみの仮想環境で完結します。
HIL（Hardware-in-the-Loop）: シミュレータの外部に、実際に実車に搭載する「SoCやECU（車載コンピュータの物理基板）」を直接接続し、現実の電気信号レベルで整合性や処理遅延を含めてテストする手法です。

2. シャドウモード（Shadow Mode）

新しく開発されたAIモデルを、実際の運転操作には影響を与えない「影のモデル」として車載コンピュータのバックグラウンドで並行実行する検証手法です。
実際の運転は実績のある現行モデル（アクティブモデル）が行いますが、影のモデルも同時にカメラなどのセンサー入力を受け取って「もし自分が運転するならこうする」という予測を出力し続けます。そして、両者の判断が食い違った「乖離データ」を検知し、クラウドへ送信して検証に利用します。これにより、乗員や車両を危険にさらすことなく、実走行データに基づいた新モデルの安全評価が行えます。

3. コレクティブラーニング（集合学習）

1台の車が道路上で「うまく認識できなかった物体」や「予期せぬ挙動（ドライバーの介入）」を経験した際、その情報（エッジケース）をフリート全体で集約して学習することで、フリート内のすべての車両の知能を同時にアップデートする仕組みです。人間が「他人の失敗から学ぶ」のと同じように、車両が「他の車両の失敗から集団的に学ぶ」ことで、自己進化のスピードを劇的に加速させます。

5つの各レイヤーの役割

事前知識が整理できたところで、Layer 1〜5それぞれの役割を詳細に見ていきましょう。このアーキテクチャは、開発・学習・評価を行う「クラウド側（Layer 1〜3）」と、フリート全体の統括や実車での走行を行う「フリート・車両エッジ側（Layer 4〜5）」に分かれています。

Layer 1: Development (開発層)
手動でモデルを組み上げるのではなく、「自動でモデルが訓練・評価されるパイプライン（仕組み）」そのものを設計・構築する層です。また、評価層から「分析要請」が下りてきた際に、データの不整合や誤ったラベリングなどの根本原因を探求する拠点でもあります。
Layer 2: Model Training (モデルトレーニング層)
推論環境（車両エッジ）から完全に切り離された、自動化されたモデル製造ファクトリーです。特徴量を一元管理する「Feature Store（特徴量ストア）」を用いてデータの再利用性を高め、自動的に学習・単体評価を行います。完成したモデルは、性能プロファイルを明記した「アプリ（App）」としてパッケージ化され、アプレジストリへ登録されます。
Layer 3: Assessment (評価層)
システム全体の「創発的振る舞い（Emergent Behavior：個々の部分の足し算を超えて、システム全体として予期せず現れる挙動）」を検証する、極めて厳格なゲートキーパーです。モデル単体での静的なテストだけでは不十分なため、先述のSIL/HIL検証を用いたシステムレベルでの動的な安全性テストを行います。
Layer 4: Fleet Operation (フリート運用層)
路上を走る多数の車両から送られてくる情報をマクロな視点（車両群＝フリート）で統括する頭脳です。実車の走行データや異常データを集約し、先述の集合学習を行って知識をアップデートします。さらに、新アプリを安全に実車に配備するためのカナリアリリースやA/Bテスト、走行エリアを限定するODD配備戦略も担います。
Layer 5: Vehicle Operation (車両運用層)
物理的な道路上で、配信されたアプリを使って「動的運転タスク（DDT：実際のハンドルやアクセル操作）」を実行する車両エッジそのものです。先述の**シャドウモード（Shadow Mode）**で安全に実証検証を行いながら、推論の不確実性や機能不全を検知した場合は直ちにフェイルセーフ（最小リスク動作）を作動させます。

ゲートキーパー「Safety CCA」の4つの多重分岐

評価層（Layer 3）の中核機能である「Safety CCA（安全性ケース信頼性評価：Safety Criticality and Credibility Assessment）」は、システム全体の安全性を担保するための究極の分岐点（ゲート）です。検証されたアプリケーションに対し、その結果に基づいて以下の4つの異なるアクションへ的確に振り分けを行います。

Valid App承認 (配備可能承認)
SIL/HIL検証において十分な安全性が証明されたアプリに対し、配備可能な正式バージョンとしての承認を与え、Valid App Registryに登録してフリート運用層（Layer 4）へ配備を指示します。
シャドウモード指定タグの付与
「シミュレーション上では合格しているが、まだ安全のために実走行で直接ハンドルを握らせる段階ではない」と判断されたアプリに対し、シャドウモード専用のタグを付与してフリート配備へ回します。
再訓練のトリガー
「特定の危険シナリオにおいてわずかに性能が足りない」など、追加の学習が必要と判断された場合、該当するエッジケースのデータを付与して、トレーニング層（Layer 2）へ自動訓練の再起動を指示します。
分析要請 (Revoke：ステータス剥奪)
重大な安全性の逸脱（例えば、シミュレーション内で障害物を見落として事故を起こすなど）が確認された場合、ただちにそのアプリの進行を差し止め、ステータスを即座に剥奪（Revoke）して開発層（Layer 1）へ根本原因分析を要請します。

この多重分岐による徹底した検証とフィードバックがあるからこそ、自動運転システムは安全性を最優先に守りながら、継続的かつ迅速な知能のアップデートを実現できるのです。

続く第5章では、これらの5層アーキテクチャを実現するために、どのような「具体的な技術スタックやツール」が使われているのかを解説します。

自動運転MLOpsを支える技術スタック

自動運転MLOpsを実現するためには、一般的なAI開発で使われるデータ管理やパイプラインツールに加え、車両シミュレータや車載エッジ向けのミドルウェアといった自動車業界特有の技術を組み合わせる必要があります。

5章では、これらの技術スタックの全体マップと、初心者の方には馴染みの薄い専門ツール・基盤の役割を整理して解説します。

カテゴリ別ツールマップ（OSS vs マネージド）

自動運転MLOpsの各プロセスで採用される主要な技術の対比表です。

カテゴリ	OSS / 代表的技術	クラウド / マネージド	自動運転における具体的な役割
Orchestration	Kubeflow, Argo	SageMaker, Vertex AI	大規模な学習・検証パイプラインの自動化
Data Validation	Great Expectations	AWS Glue Data Quality	センサーデータの不整合や異常値の自動検知
Feature Store	Feast	SageMaker Feature Store	特徴量の一元管理と再現性の確保
Simulation	CARLA	dSPACE, DRIVE Sim	仮想空間を用いた閉ループでの安全性検証
Experiment Mgmt	MLflow, W&B	SageMaker Experiments	パラメータと評価結果のトレーサビリティ管理
Edge Deployment	TensorRT, TVM	NVIDIA DRIVE, AWS IoT	車載SoCへのモデル最適化とOTA配信
Monitoring	Prometheus, Grafana	CloudWatch	推論の不確実性や介入発生のリアルタイム監視

特性の異なるシミュレーション環境の使い分け

4章で解説したSIL/HIL検証を行うためには、適切なシミュレータの選択が欠かせません。ADS（自動運転システム）開発では、テストの目的（フェーズ）によって以下のシミュレータを使い分けます。

CARLA (オープンソース)
Unreal Engineをベースにした、オープンソースの自動運転シミュレータです。扱いやすく拡張性が高いため、初期段階での認識アルゴリズムや経路計画のロジック検証に広く用いられます。
NVIDIA DRIVE Sim (デジタルツイン)
物理法則に忠実なセンサー挙動の再現や、高品質な合成データ（CGによる学習用データ）の生成に強みを持つシミュレータです。カメラやLiDARの光学的な特性まで精密にシミュレートできます。
dSPACE / IPG CarMaker (リアルタイムHIL向け)
リアルタイム動作の信頼性が極めて高く、実際の車載ECU（電子制御ユニット）を物理的に接続して行うHIL検証の業界標準ツールです。電気信号レベルでの車両の運動挙動（挙動の遅延や急ブレーキ時の車両の傾きなど）を厳格に再現します。

エッジ・ミドルウェアとSDV基盤の役割

AIモデルを単に動かすだけでなく、実際の車のハンドルやブレーキと安全に連携させるために、車載エッジ（車の中）では以下のような特殊なミドルウェアやOS規格が動いています。

ROS2 (Robot Operating System 2)
ロボット開発における実質的な業界標準プラットフォームです。自動運転車内の様々なモジュール（認識、予測、計画、車両制御など）同士が、センサーデータや制御コマンドを低遅延で送受信する通信パイプラインを支えます。
Zenoh (ゼノ)
超低遅延で軽量な次世代のデータ伝送プロトコルです。走行中の車（エッジ）とクラウド、あるいは他の車両や路側機（V2X：路車間・車車間通信）との間で、無駄な通信負荷を抑えて双方向にデータをやり取りするために採用が進んでいます。
AUTOSAR Adaptive (オートザー・アダプティブ)
自動車業界共通の標準ソフトウェア・プラットフォーム規格です。自動運転のような高度なコンピューティング能力を求められる車載ECUにおいて、機能安全規格（ISO 26262など）に適合した高い安全性を維持しながら、アプリケーションの動的なアップデート（OTA）を実現するための堅牢な基盤を提供します。

これらの車載向けミドルウェアが車内で走り、クラウド側のMLOpsと連携することで、安全に「AIが車を動かす」システムが実現されます。

まとめ

本記事では、前回のAWS上での一般的なMLOps解説に続く形で、自動運転（AD/ADAS）領域における次世代のMLOpsアーキテクチャの動向について解説してきました。

自動運転におけるMLOps

自動運転の開発現場におけるMLOpsの本質は、単に「AIモデルの学習を自動化する」ことだけではありません。
人命を守るための厳格な「安全性保証」を維持しながら、ソフトウェア定義の自動車（SDV）の知能をいかに迅速かつ継続的にアップデートし続けられるかにあります。

これを実現するために、次世代の自動運転開発では、以下の4つの運用プロセスが高度に融合したシステムが必要とされています。

MLOps: 機械学習モデルの再現性、特徴量ストア、モデルのライフサイクル管理
DevOps: ソフトウェアの継続的インテグレーションと、OTAを用いた実車への安全な配信（CI/CD）
SafetyOps: シナリオに基づく評価と、Safety CCA（安全性ケース信頼性評価）による動的な安全性適合
SimulationOps: 仮想3D空間を用いたSIL/HILによる大規模かつ自動化された閉ループシステムテスト

1台の車が道路上で遭遇した「未知の危機（エッジケース）」をフリートの力で吸い上げて集団学習（Collective Learning）し、安全性を厳格に保証した上でアップデートを車両へ返す。この巨大な双方向のデータ循環ループ（UP/DOWNループ）を回し続けることこそが、自動運転の社会実装を成功に導くための鍵となります。

最後に

ここまで読んで頂きありがとうございます。本記事が、自動運転およびMLOpsに興味を持つ方々の参考になれば幸いです。

参考文献

本記事の執筆にあたり参照した、主要な論文および技術ドキュメントです。

[arXiv:2605.12719] Bastian Lampe, Lutz Eckstein. "A Five-Layer MLOps Architecture for Connected Automated Driving" (2026).
- 本記事のベースとなった、5層アーキテクチャおよび集合学習に関する最新論文。
[Hugging Face / arXiv] "AD-L-JEPA: Self-Supervised Spatial World Models with Joint Embedding Predictive Architecture for Autonomous Driving with LiDAR Data" (2025).
- 自己教師あり学習を用いて、LiDARデータから周囲の物理法則を再現するワールドモデルの最新構築手法。
[CVPR / PMLR] "Hint-AD: Holistically Aligned Interpretability in End-to-End Autonomous Driving" (2025).
- 認識から操舵判断までを一貫して行うEnd-to-End自動運転における、AIの判断根拠（解釈可能性）と大規模基盤モデルの統合に関する研究。
[German Research Initiative] "UNICARagil Project" (BMBF Germany).
- ドイツ連邦教育研究省が支援する、モジュール型自動運転車両のサービス指向アーキテクチャ（SOA）およびクラウドサービスの開発を推進する大規模産学官コンソーシアムプロジェクト。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up