ティアフォーは2026年11月11日、地図情報の有無やセンサー構成など、異なるシステム要件に対応する5種類のエンドツーエンド（E2E）自動運転AIモデルを発表した。E2E自動運転は、周辺環境の認識から走行軌跡の生成までをニューラルネットワークで結び付ける技術で、同社は今回のモデル群を次世代アーキテクチャ「Autoware 2.0」の具体的な開発成果として紹介している。Autoware 2.0は、AIモデルと従来のルールベース技術を柔軟に組み合わせる構成を採用しており、自動車メーカーなどが用途や要求性能に応じて技術を選択できるようにすることを目指す。ただし、各モデルが必要とするセンサーや地図の条件に加え、Autowareへの統合状況も異なるため、実際の導入にあたっては両方を確認する必要がある。

AD

5種類のE2E自動運転AIモデル、入力条件と統合状況を比較

 

ティアフォーが11月11日に紹介したのは、「Alpamayo 2 Edge」「AutoE2E」「METEOR」「OnePlanner」「LatentDrive」の5種類だ。カメラ画像のみで走行軌跡を生成するモデルから、LiDARや高精度地図を活用するモデルまで幅広く、走行計画の手法もそれぞれ異なる。Autowareへの統合が完了しているモデルがある一方、統合や車載環境での検証を進めているモデルもある。

以下の表は、ティアフォーの発表をもとに、各モデルの構成と統合状況を整理したものだ。METEORについては、発表内容に加えて公開モデルの公式カードに記載された実装状況も反映している。

モデル 主な構成・入力条件 軌跡生成の特徴 Autowareへの統合状況
Alpamayo 2 Edge カメラ画像のみ。20億パラメータ 推論能力を活用して走行軌跡を生成 統合済み。最適化と実車への適合開発を継続
AutoE2E Reactive Modelを中心に、World ModelとReasoning Modelを組み合わせる設計。カメラ単独からLiDAR・レーダーを使う構成まで対応 リアルタイムの走行判断を担うReactive Modelを公開 Reactive Modelは統合済み。World ModelとReasoning Modelは開発中
METEOR 高精度地図不要。発表ではカメラ1〜8台、LiDAR・レーダーにも対応 カメラ画像をBEV表現に変換し、周辺認識と軌跡生成で共有 配布中のv157は独自ランタイムによる参照モデル。AutowareのROS 2ノードは未実装
OnePlanner LiDAR点群、高精度地図、経路情報、信号機の状態、車両の走行状態を使用 BEVFusionを基盤に、6秒先までの走行軌跡を生成 統合済み
LatentDrive カメラ1台または3台。高精度地図は不要 V-JEPAの潜在特徴を使い、4秒先までの走行軌跡を生成 統合と車載環境での検証を進行中

表中の6秒と4秒は、モデルが生成する走行軌跡の時間範囲を示すもので、処理遅延や自動運転を継続できる時間ではない。また、Autowareへの統合が完了していても、それだけで商用運行に必要な安全性の検証や認可が完了したことにはならない。用途に適した入力構成を備えているかに加え、実際に利用できるソフトウェアや学習済みモデルの状態も確認する必要がある。

各モデルは、走行計画の仕組みにも違いがある。例えばOnePlannerは、認識処理で抽出した特徴量を行動計画に直接利用し、従来のように物体の位置や速度などの情報へ変換する中間処理を減らしている。一方、Alpamayo 2 Edgeは20億パラメータの推論型モデルであり、AutoE2Eは7,990万パラメータの比較的軽量な構成を採用する。ただし、パラメータ数だけで認識精度や走行性能、消費電力の優劣を判断することはできない。ティアフォーはAutoE2Eについて、ロボタクシー用途での商用化も検討している。

ティアフォーの加藤真平CEOは、特定のAIモデルや半導体環境に依存せず、用途や要求性能に応じて技術を選択できることが重要だと説明している。今回の発表は、こうした選択肢を広げるための取り組みだ。ただし、5種類のモデルを同一条件で比較した性能評価が示されたわけではなく、実際の優劣は用途や車載環境に応じた検証が必要となる。

METEORの公開実装から見える半導体対応と移植の条件

今回紹介されたモデルのうち、METEORはティアフォーが独自に開発した、高精度地図に依存しないマルチタスク型E2E自動運転AIだ。主に自家用車向けの利用を想定しており、畳み込みニューラルネットワーク（CNN）を用いてカメラ画像から特徴を抽出し、車両周辺を上から見た俯瞰表現（Bird's-Eye View：BEV）に変換する。このBEV表現を周辺環境の認識と走行軌跡の生成で共有することで、複数のタスクを単一のニューラルネットワークで処理する。高精度地図を必要としない一方、カメラの構成や実行する半導体によって実装上の条件が変わる点には注意が必要だ。

METEORのGitHubリポジトリによると、この技術は単一のモデルではなく、共通の学習基盤を持つモデルファミリーとして開発されている。公開リポジトリでは、基本モデルのMETEORに加え、複数カメラに対応するMETEOR2と、単眼カメラ向けのMETEOR2 Nanoが区別されている。モデル間で共通するのは学習データや学習手法、認識・走行計画の基本構成であり、半導体への対応で重要になるのはカメラ画像の特徴をBEVへ変換する処理だ。対象半導体が対応する演算に合わせて、この変換部分の実装を変更することで、異なる計算環境への展開を図っている。

ティアフォーは11月11日の発表で、METEORがNVIDIAやルネサスなどの半導体環境に対応すると説明している。ただし、すべての半導体で同一の学習済み重みをそのまま実行できるという意味ではない。実際にはモデルの構成や変換処理、推論エンジンを対象の半導体に適合させる必要があるため、利用可能なモデルと実行環境を個別に確認しなければならない。

公開されているコードと学習済みモデルの範囲にも違いがある。GitHubにはMETEOR2とMETEOR2 Nanoのコードが収録されているが、両モデルの事前学習済み重みは今後公開する予定と記載されている。このため、ソースコードを入手できても、直ちに学習済みモデルをダウンロードして同じ推論結果を再現できるとは限らない。車載半導体への移植を検討する際には、必要なモデルの重みが公開されているかが最初の確認事項となる。

なお、METEOR自体は11月11日に初めて公開されたものではない。ティアフォーは9月8日の技術記事で、すでにオープンソースの参照モデルとして紹介している。同記事によると、METEORの学習にはCo-MLOpsで収集した走行データを使用し、オートラベリング基盤「CoMET」がLiDARなどの情報から教師データを生成する仕組みを採用している。つまり、実際の走行時にはカメラ画像のみを使う構成であっても、学習に必要なデータを生成する段階ではLiDARを活用している。推論時に必要なセンサーと、学習データの作成に利用するセンサーは区別して考える必要がある。

安全性についても、ニューラルネットワークによる走行計画だけに依存する構成ではない。ティアフォーは、AIが生成した走行軌跡とは独立して、ルールベースの安全確認を併用する方針を説明している。また、METEORの開発ではエージェントAIによるデータ処理、学習、評価、改善の自動化を進めているが、人間は開発目標の設定と結果の確認を担う。こうした仕組みもAutoware 2.0が掲げる、AIと従来技術を組み合わせた自動運転システムの一部となる。

AD

公開モデルを車載システムに組み込むまでの課題

現在、Hugging Faceで配布されているMETEOR v157は、ティアフォーのデータ収録システム（DRS）に搭載された8台のカメラを前提としている。公式モデルカードによると、入力には8台分のカメラ画像に加え、各カメラの内部・外部パラメータなどの較正情報と自車速度が必要だ。公開されたONNXモデルはカメラのみを使う構成で、単一時点の画像から推論する方式を採用しており、過去の画像情報を利用する時間履歴の処理は含まれていない。別のカメラ構成でもモデルを実行できる場合はあるが、学習時と異なる構成では再学習や較正に関する処理の調整が必要となり、精度は保証されない。

推論エンジンも、使用する半導体に合わせて構築する必要がある。METEORはONNX形式で配布されているものの、TensorRTの実行エンジンはGPUのアーキテクチャやTensorRTのバージョンに依存するため、対象環境ごとに生成しなければならない。さらに、配布中のv157は独自のPython・C++ランタイムを備えた参照モデルであり、Autowareに直接接続するためのROS 2ノードはまだ実装されていない。モデルを取得して単体で推論できることと、Autowareを使用する車載システムに組み込めることは別の段階にある。

モデルの規模についても、公開資料の間に食い違いがある。ティアフォーの11月11日の発表ではMETEORのパラメータ数を1,600万としているが、配布中のv157のモデルカードには5,400万と記載されている。GitHubの説明では、この5,400万には追加の補正処理を担うrefinerも含まれる。発表で示された1,600万パラメータのモデルと配布中のv157が同じ構成・バージョンなのかは確認できておらず、両者を同一モデルの仕様として扱うことはできない。モデルの規模や処理性能を比較する際には、この差を解消する必要がある。

安全性に関する制約も明確にされている。METEOR v157のモデルカードでは、配布モデルを研究・評価用の成果物と位置付けており、認証済みの自動運転システムではないと説明している。公道で車両を制御する目的に使用してはならないとも明記されている。また、内部検証で測定した認識精度などの絶対値は公表されていないため、現時点で実用環境における安全性や性能を独立して評価するための情報は限られる。ただし、これらは配布中のMETEOR v157に関する制約であり、今回紹介されたほかのモデルにそのまま当てはまるものではない。

ティアフォーが今回示した5種類のE2E自動運転AIモデルは、自動車メーカーや開発者がセンサー構成、地図の要否、車載半導体などの条件に応じて技術を選ぶための選択肢を広げるものだ。一方、オープンソースとしての公開状況やAutowareへの統合段階には違いがあり、モデルの存在だけで車載システムへの導入が完了するわけではない。今後は、対象車両のカメラ構成に対応する学習済みモデルを入手できるか、使用する半導体で推論環境を構築できるか、Autowareへの接続と実車での検証が進むかが重要になる。これらの条件が整うことで、開発者は自社の用途に適したモデルを選び、実用化に向けた評価を進められるようになる。