本文へ移動

TuringTechTalk#40 世界モデル時代の自動運転 ──2026年の最新トレンドとリアルタイム処理技術

この記事に登場する人
CTO
山口 祐 Yu Yamaguchi
産業技術総合研究所 研究員/米国NIST客員研究員として研究する傍ら、独自にゲームAIの深層学習の開発を開始。日本の囲碁AIプロジェクトの開発代表として、最大1100GPUの並列分散強化学習を設計・開発し、世界大会準優勝、将棋AIでも世界大会優勝などの実績がある。HEROZ株式会社 執行役員を経て、2022年、チューリングに創業メンバーとして参画。2024年8月、CTO就任。基盤AIチームマネージャー兼任。
Driving AI3チームリーダー
石原 啓志 Keishi Ishihara
豊橋技術科学大学大学院と東フィンランド大学のダブルディグリープログラムを修了し、修士(工学)および MSc in Computer Science and Engineering を取得。修了後、本田技術研究所に新卒入社し、先進安全支援システムの機能開発・検証に従事。その後、株式会社ALBERT(のちにアクセンチュアに統合)に入社し、E2E自動運転におけるTrajectory予測の研究や、大規模言語モデルの研究開発に取り組む。2024年、チューリング入社。E2E自動運転モデルおよび世界モデルの研究開発を推進し、自動運転向けVQAデータセットSTRIDE-QAを提案した論文をAAAI 2026で口頭発表。

はじめに

チューリングでは、環境認識から経路計画、運転制御までを単一のAIで行うE2E(End-to-End)自動運転と、大規模基盤モデルの研究開発を進めています。2026年はVLAの次の潮流として、動画生成モデルや世界モデル(World Model)をロボットや自動運転へ接続する研究が急速に盛り上がっています。

今回のTechTalkでは、CTOの山口と、Driving AI3チームの石原が登壇。2026年現在の世界モデルの外部トレンドを整理し、世界モデルタスクで学習する重要性を議論。更にチューリングとしての見立てと今後の方針をご紹介します。

※本記事はTuringTechTalk#40の内容を元に一部編集してお届けします。

今回は「世界モデル」回

山口:皆さん、こんにちは。TuringTechTalk第40回「世界モデル時代の自動運転──2026年の最新トレンドとリアルタイム処理技術」を開始します。本日は世界モデルを開発しているチームリーダーの石原さんに来てもらってます。石原さん、今日はよろしくお願いします。

石原:よろしくお願いします。

山口:今回は世界モデル回ということで、このテックトークでは世界モデルについてこれまで何度か取り上げてきたんですけれども、どの回も結構人気があって、今回も非常にご注目をいただいているところかなと思っております。それでは石原さん、簡単に自己紹介をお願いします。

石原:はい。Driving AI 3チームのチームリーダーをやっております石原と申します。2021年に大学院を卒業した後、本田技術研究所に新卒で入社しまして、栃木の四輪のR&Dセンターで務めておりました。そちらでは、いわゆるADAS(Advanced Driver-Assistance Systems)、車の安全支援システムの一部の機能開発を担当しておりました。その後転職をしまして、株式会社ALBERTというところに入社しまして、そちらではE2E(End-to-End)の自動運転開発をテーマにした研究をやっておりました。その後会社がアクセンチュアに統合になりましたので、自分自身も転籍という形で移動して、そちらで1年半ほど働いた後、2024年の10月にチューリングに入社したという経歴になっております。

山口:石原さんは一貫してリサーチ寄りのことを担当するチームに所属していたのかなと思っていて、最初期の方は例えば強化学習とかVLM(Vision-Language Model)とか、こういったところのデータセットを作るみたいなところとか、世界モデルみたいなところも当然入った当初からいろいろとやっていて、多分最初にチューリングでやった仕事はその世界モデルのベンチマークを作るみたいなところが論文として出ていたところかなと思います。合ってますよね。

石原:はい。その通りですね。

山口:チューリングの中でも非常に世界モデルに造詣が深いというところですね。今日はこの世界モデルの開発、あるいは最近のトレンドですね、2025年から2026年にかけていろんな世界モデルが広がりを持ってきているというところなので、この辺りのトレンドについて是非色々と聞いていこうかなと思っております。


世界モデルとは何か

石原:まず、世界モデルの話をする上で絶対毎回話さなきゃいけないと思うんですが、世界モデルとは何かということです。ある時刻の状態と行動から未来の状態を予測する、状態遷移モデルであるという定義が一番標準的な定義かなと思っております。今回のTech Talkでもこの定義に則って話を進めていく予定です。

山口:いきなり数式が出てきて半分ぐらいの人がブラウザバックしてしまったんじゃないかと心配なので、もう少し説明を聞きたいなと思います。右の図の方が多分分かりやすいかなと思うので聞いていこうと思うんですが、これはよくある強化学習の……

石原:そうですね。マルコフ連鎖的な、環境とエージェントが決定的に相互作用してくぞみたいな感じです。

山口:このエージェントって書いてるのが例えば人間だったりAIだったりするんですが、要するになんか自律的に行動するものだという風に想像していいかなと思うんですけれども、それは自分の意思で動かせると。で、自分の意思で動かせないけど、なんか影響与えられるものとして要するに周囲の環境、エンバイラメントというものがあるという、そういう想定ですよね。

石原:はい。

山口:このエンバイラメントは、例えばゲームで言うと将棋だったら将棋盤、囲碁だったらその碁盤と碁石で、自動運転だったら本当に道路とか周りの車とか信号機とか歩行者とかそういったものがこう環境になっていくというイメージで合ってますか?

石原:はい、合ってます。

山口:エージェントはそれを例えば将棋だったらプレイヤーだったり、自動運転だったら車を運転する人がこうエージェントになってくるというところですよね。この環境、世界と言い替えていいと思うんですけど、この世界をモデル化したのがつまり…。

石原:世界モデルです。

山口:完全に理解しました。数式のところで言いますと、とにかく未来の世界がどうなっているかを予測するモデルですね。

石原:はい。その通りです。

山口:これが世界モデルと言って、平たく言っていいかなと思っていて、人間も頭の中で無意識のうちにシミュレートしてるかなと思っていて、例えばそのガラスのコップを適当にこの辺で放り投げたらどういう風な軌跡を描いて落ちて割れるみたいな、そういった想像ができる能力は当然人間は持ってますし、椅子に座るとかドアを開けるとかそういったものでも実はなんとなく未来の予想をしてたり、当然運転でも今ここでハンドルをこういう風に切ったらどういう風に車が動くかみたいなところをイメージしながら人間は運転して、それが現実の世界とちょっとずつ補正をしながら動いてるみたいな。そんな感じで大丈夫ですか?

石原:そんな感じで大丈夫だと思います。


2026年に世界モデルが急増した背景

石原:2026年になってからかなりの世界モデルが登場しているという状況になってきておりまして、これがなぜなのかという背景を自分なりに考えてみたんですけれども、2つあるかなと思っていて、1つは基礎的な技術が確立してきたということと、もう1つがフィジカルAIというトレンドが来ているということがあるかなと思います。

石原:基礎技術の確立の方なんですけれども、これは冒頭で山口さんからもご説明があった動画生成モデルの技術の確立というところだと思います。動画生成モデルというと、プロンプトを投げると動画を作ってくれるAIというのが一般的に知られているところだと思うんですけれども、これは非常に大量の動画を使って非常にたくさんの計算資源を投入して作らなきゃいけないものなので、基本的にはOpenAIとか、クローズドなAIとして開発がされてきたんですけれども、最近はこれがオープンなモデルというのもポツポツ出てきています。その1つが「Wan」という、中国のAlibabaが出したオープンな動画生成モデルで、これは研究者が自分で使って開発とか研究に役立てることができると。オープンなモデルが登場してきているのが1つの要素になっているんじゃないかと思います。

もう1つがフィジカルAIですね。ロボットアームのタスクとかヒューマノイドのタスクを考えたとしても、例えばコップを離すと落ちていって割れるかもしれないみたいなことを事前に学習できている世界モデルがあれば、フィジカルAI・ロボットのAIを作る方にも役立てることができるんじゃないかというところで、そちらにも応用が進んでいます。基礎が成り立ってきていて、フィジカルAIというトレンドが来ている、だから世界モデルが求められているという仮説を持っております。

山口:動画のモデルで言うと一般的には、例えばOpenAIが出しているSoraとかが最近なんかサービス終了しちゃいましたけれども一時期すごい話題になって、すごいリアルな映像を出せるぞみたいなところで話題になりましたし、オープンソースの文脈で言うとそのOpenSoraというSoraをオープンソースで作るぞみたいなプロジェクトも昔あったような気がしていますけれども、これがいろんな研究が進んできて、本当に実用的に使えるようなオープンな動画生成モデルが一般的になってきた。テクニカルにはコモディティ化してきたといったところですよね。

ロボティクス・フィジカルAIという文脈でロボティクスの話が出てきましたけれども、車載カメラの例みたいなやつっていうのはこれまでもなんかあったんですか?

石原:そうですね。いくつかあったかなと思いますね。今パッと思いつくところで言うと、我々の競合ですけれどもWayveですね。Wayveはよく動画を使った研究プロジェクトというのをたくさんやってきていて、自分が今覚えている範囲で言うと2018年あたりから動画を応用する研究というのは出してきたりしていましたね。


自動運転×世界モデル:各社の最新動向

石原:自動運転の世界モデルを語る上では外せないと思うんですけど、このGAIAシリーズというのはWayveがGAIA-1、2、3と出しているんですが、これは自動運転の世界モデルとして外せないところかなと思っています。GAIA-3は特に画像のクオリティが非常に高くて、かつ世界モデルなのでこう動画入力とアクションの入力があるんですけども、この入力したアクション(トラジェクトリ)に忠実に行動を再現した世界を生成することができるという風に言われています。

山口:GAIA-1は2023年に出ていますよね。CVPRという画像系のトップカンファレンスがあるんですけれども、23年のワークショップで発表されたのが基本的には最初かなと思っています。私たまたま現地(バンクーバー)で行ってそこのワークショップに参加していたんですよ。当時はWayveのことあんまり知らなくて、プレゼンしていたのはWayveのCEOのAlex Kendallさんだったんですけども、その人がバンとこの動画のスライドを出してきて、もうなんかカメラ映像いっぱい撮ってんなと思ったらそれは全部生成動画だったみたいな話をプレゼンで始めて、非常に当時印象に残っていますね。そこから非常にWayveの知名度も上がっていったのかなと思っています。

Teslaも去年のICCV(International Conference on Computer Vision)、ハワイであったICCVで、久しぶりにTeslaのAIの責任者の人がなんか2年ぶりぐらいこういった場に出てくるみたいなところで発表したのがTeslaのワールドモデルの話でしたよね。各社結構こういうの作っているというところですね。

ちょっと聞いておきたいんですけど、いわゆる世界モデルと動画生成モデルの違いですね。アクションにこう追随するみたいなところは別に普通の動画生成モデルでもできるところはあると思うんですけど、それとワールドモデルの厳密な区別みたいなやつがあったりするんでしょうか?

石原:厳密な区別は個人的に結構難しいかなとは思うんですけど。動画生成モデルというのは基本的にはテキストのプロンプトを入れて、ある場合はスタートのフレームがあってそこから先を作ってくれるというものですね。ただし世界モデルになると毎フレームその時のアクションを入れなきゃいけないというのが大きな違いになるかなと思います。

山口:つまり映像生成のモデルは無からも作れるし、テキストの指示も出せるし、アクションとか動作を入れることもできるしいろんな入力がありますけど、世界モデルはどっちかというと今この状態があって、その状態が未来どうなっていくかみたいなところに基本的にフォーカスしているという、目的の違いみたいなやつがあるということですかね。

石原:一括にテキストプロンプトを入れて、ある場合は最初のフレームを指定して数秒間の動画を作るというのがこれまでの動画生成モデルでした。ここで紹介しているのはですね、インタラクティブな世界を生成することができるモデルということで、一括に長い動画を作るのではなく、リアルタイムで行動入力に反応し続けながら次のフレームを逐次的に作っていく世界モデルというのが特に今年凄くホットな分野になっております。

山口:リアルタイムにこういったものを生成することってできるんですか?

石原:これはできます。技術的には難しいんですけど、それができるようになってきたのが2026年です。

石原:左がNVIDIAが出しているOmniDreamsで、右がTeslaの展示ですね。

山口:CVPR 2026というのは先々週、アメリカのデンバーで行われていて、チューリングからも論文発表があったので何人か社員が行っていたんですが、そこでNVIDIAとTeslaがブースを出していて、その展示を撮ってきたというところになりますね。Teslaの方を見るとどうですか?ちょっと荒いですか?なんか見た目。

石原:ちょっとタイミングが悪かったのかもしれないんですけど、道路じゃなくて変なところに入っていて。苦手なところだったかもしれないんですけれども、バックして道に戻るみたいな動作も生成できているっぽいので、かなりこれはすごいなと思っております。

山口:ちょっと段差乗り越えるみたいな動きも、カメラのところだと地面の凹凸を拾ってそうな動きもしていますね。結構リアルな印象があります。

石原:結構リアルですね。


チューリングで開発している世界モデル

石原:チューリングで開発している世界モデルの紹介になります。この世界モデルが生成しているシーンは、動画生成ベースで、指示追従性(アクションへの指示への追従性)が高くかつマルチカメラで生成できる世界モデルシミュレータということになっております。

右側の動画の一番右端に出ている黒いところにトラジェクトリが映っていると思うんですけど、これで条件付けをした世界が生成されていまして、4段あると思うんですけど、それぞれ違うアクションを指示していて違うシーンが生成されているという例になっております。

山口:オリジナルのカメラ映像、この場合だとカメラが3つあってフロントと斜め左・斜め右みたいな感じでカメラが付いていて、そのオリジナルの映像から途中からこんな感じで動いているみたいな指示をこの右側の線のように指示を行って、その通りに映像が出てきている様子がこの4つで比較できるということですね。一番下とかはこれ止まるように指示しているということですか?

石原:そうです。これはまさに止まるように指示をしていて、右側に出ているトラジェクトリを見ると短くなっていって、最後は完全に停止するというアクションになっています。

山口:ちゃんと止まれるし走れるし曲がれるというところで、車の動きをちゃんと再現できるというようなマルチカメラの世界モデルを作っているということですね。

石原:もう1つ例をあげているんですけれども、こちらは車体の揺れ、カメラがよく見ると横に揺れたりとか縦方向に揺れたりとかというのがよく見ると分かる例になっておりまして、特に2段目のところは最初のフレームは道の真ん中にいてそこから左側にはみ出るようなアクションを入れています。そうすると左側の斜めになっているところに乗り上げていって車体もちょっと右に傾いているみたいな映像が生成できていたりとか、一番下とかは完全に停止したら左側の草木がいい感じに揺れているシーンとかも結構再現できていて、よく生成できている例かなと思っております。

山口:単純にその車が水平移動していくだけじゃなくて、車の車体としてのリアルな映像を生成するみたいなところですね。実際の車ってずっと同じ視点で動いていくわけじゃなくて、ブレーキかけたらちょっと前荷重になってカメラとしてはこのピッチ方向が下になって、逆に加速すると後ろ荷重になってちょっと上向くみたいなのは皆さんも直感的に分かるかなと思いますし、カーブする時も、例えば右カーブで曲がっていくような時には車ってこう微妙に遠心力というか外側に基本的に傾いたりしますし、そういったところの情報もなんとなく再現しているということですね。でも傾きの情報とかは別に指示を与えていなくてなんかよしなにやってくれているみたいな感じなんですか?

石原:これはもう完全にモデルが学習してくれていて、言ってしまえばよしなにやってくれているということになりますね。

山口:道を走っているうちは多分いいと思うんですけど、草むらに突っ込んでいったりとか建物に突っ込んでいったりとかするとさすがに崩れてしまうというのは仕方ないところですか?

石原:これは仕方ないところだと思っております。基本的にこの学習データはチューリング社内で実際の道を走行して収集した走行データを元にこの世界モデルの学習を行っているんですけれども、基本的にはこのE2Eのモデル開発をするために収集した走行なので、プロのドライバーさんが素晴らしい運転をして完璧な走行データを取ってくれています。なので、右の歩道に突っ込んでいくとかのデータは当然普通に運転していたら得られないような映像なので学習データとしては少ない。学習データとして少ないとなかなか再現するのは一般的には難しくなりますね。


インタラクティブドライビングシミュレータの実現

石原:先ほどの世界モデルをインタラクティブに世界の中を動き回ることができるように追加の学習を行ったものを、実際にドライビングシミュレータとして使えるようにセットアップしたというのがこのスライドになっています。

山口:これはさっき話していたCVPR 2026でテスラとNVIDIAが展示していたやつと基本的には同じようなものなんですね。

石原:そうですね。基本的には同じようなレシピで作られたものだと思っていただければ。

山口:聞いたところによるとNVIDIAのブース展示していたやつはかなりデータセンター向けのハイパワーのGPUを何台も使ってリアルタイム推論を実現していたと思うんですけども、今回の我々のやつはどのくらいのマシンパワーでリアルタイムで動かしているんですか?

石原:これ実はですね、RTX 4090というGPUを1つ使っているだけですね。

山口:NVIDIA製のいわゆるコンシューマー向けのGPUですね。一般の人がゲームとかやるPCとかに組み込む用の、今5090というのが一番最新の世代なんですけど、その1個前の世代の一番ハイエンドのやつを使っているということですかね。家庭用のGPU 1個でも結構このくらいのモデルをリアルタイムで動かすことができるようになっているということですね。

石原:できるようになってきました。

山口:もうちょっと自慢してもいいんじゃないですか?

石原:そうですね…(笑)。これ結構リアルタイムとは言っているんですけど、NVIDIAが出しているOmniDriveの方がやはりかなり推論の画像の更新頻度、FPSは高いです。こっちの方がまだまだ完全にリアルタイムではないんですけれども。

山口:そうですね。まあ1Hz、2Hzぐらいですかね。アクセル踏んだりハンドル切ったりした時のちょっと遅延ある感じ。

石原:そうですね。アクションの入力に対する反応性がまだちょっと改善のポイントになっています。

山口:今後に期待というところですね。


世界モデルの開発レシピ

石原:ここからは今のシミュレーターをどうやって作っていったかというところで、動画生成モデルをベースとしたマルチカメラモデルをどうやって作ったかというところから簡単にご紹介させていただきます。これが世界モデルのモデルの全体像でして、もしかしたら気が付くかもしれないんですけれども、かなりGAIA-2を意識したアーキテクチャになっております。入力としてマルチカメラのカメラ映像が左から入ってきまして、エンコーダーというのがあるんですけれども、エンコーダーで画像をレイテントの表現に圧縮をして、そこで大きなトランスフォーマーを動かして、将来の映像を生成してデコーダーでピクセル空間に復元するという動きをするモデルになっております。

山口:この辺の話は一般的な動画生成モデルとかでフレームのコンディショニングをしていくみたいな時でも似たような感じになっていますか?それともGAIA-2などの特有のアーキテクチャになっていますか?

石原:GAIA-2として特有のアーキテクチャになっているところで言うと、普通の動画生成モデルと大きく違うところは、基本的にはマルチカメラを扱うところと、アクションの条件付けが入力されているというところで、真ん中の水色で書いているところですね。行動の入力というのが追加されているというのが一番大きな分かりやすい違いになっています。

石原:先ほどの図で、エンコード・デコードをするというところがあったと思うんですが、実際にそれを行っているのがこのVideo Tokenizerです。なぜこのVideo Tokenizerが必要かというと、マルチカメラの映像をそのまま使うとかなり情報量が大きいので、これを強く圧縮して小さい表現にする必要があります。それを行っているのがVideo Tokenizer、VAE(Variational Autoencoder)という技術です。

石原:このVAE・Video Tokenizerとその前に紹介した世界モデル本体の2つでようやくパーツが揃ったということで、じゃあこれをどうやって学習するかということを説明しているのがこのスライドで、Flow Matchingという生成モデルを作るための学習手法を使っています。やっていることは何かというと、ノイズからデータへ向かう方向を予測するモデルです。この世界モデルというのが、ノイズを入力に受け取って、トラジェクトリの条件付けを入れて将来の映像を生成するということを行っています。

山口:よく対比として言われるDiffusion Model・拡散モデルと何が違うのかという話があると思っていて、拡散モデルも基本的にはノイズからなんかちょっとずつノイズを取り除く、デノイズするというのが基本的な考え方かなんですけれども、拡散モデルとFlow Matchingの関係についてちょっと教えてもらっていいですか?

石原:Diffusion ModelとFlow Matchingというのは非常に近い生成モデルの学習のやり方でして、拡散モデルというのは基本的にはノイズを徐々にデノイズしていくのでノイズのちょっとデノイズした先のまだノイズのデータを生成するというのを繰り返していくんですけれども、Flow Matchingの場合はノイズのちょっとデノイズした先ではなくてデノイズする方向を予測しているという違いがあります。

山口:そうすると何が嬉しいんでしょうか?

石原:一般的によく言われるのは拡散モデルよりも安定した学習ができるというのと、生成が早いというこの2つの大きな利点があるかなと思います。


石原:1番最初の方で話した一般的な動画生成モデルというのは、ある程度長い動画を一気に作るモデルという話をしたんですけれども、これを次のフレーム、次のフレームと徐々に生成させるために必要な学習のやり方をここに書いています。

まず、学習時にCausal Attention Maskというのを入れてコーザルという処理を行います。これは言語モデルでは一般的にやられていることなんですけれども、何をやっているかというと、今まで入力した過去の動画を見つつ次の将来の動画を生成するんですが、将来の動画トークンは過去の動画トークンを参照できないという制約をトランスフォーマーに加えて学習するというやり方がここに書いてある話です。

山口:機械学習に詳しい人はこの図を見てCausal Attention Maskはすぐ分かると思うんですけど、多分普通の人はこのマス目を見ても何も分からないと思うんですが、要するに未来の予想をするのに未来の情報を使ったらそれはなんかチートしてしまうから、見えないようにちょっと隠して学習したらうまく未来予想が学習できるよね、ということですよね。

石原:はい。そうです。

山口:で、次のKV Cacheですね。これもまたちょっと専門的な話になってきましたけど。

石原:はい。このKV Cacheというのも同じく言語モデルではもう定番になっている技術なんですけれども、今話した未来を隠しながら学習をさせるということを行うとこのKV Cacheというものを使うことができるようになります。これは何かというと、推論時に生成を速くするためのテクニックになっていまして、逐次的に画像フレームを生成していく際に、一度生成したところの計算結果を保存しておいて、次のステップの計算にその保存しておいた結果を再利用して次のフレームの生成を行うというテクニックです。これをすると推論がめちゃくちゃ高速になります。

山口:推論が早いのは嬉しいですね。これはプログラミングの話で言うといわゆるメモ化とかキャッシュみたいなところに当たるかなと思っていて、トランスフォーマーと呼ばれるアーキテクチャだとこの形式を取ってこう計算がどんどんされていくわけなんですが、入力した情報に対して毎回毎回計算していると物凄く時間がかかってしまうので、いい感じに昔計算したやつを再利用できるやつは取っておいて、必要になった時に呼び出せばその無駄に何回も計算するのを省けるから単純に早くなるよねということで、それが劇的にこの実際に動かす時に効果があるというのがこのKV Cacheで、最近のLLMとかでもほぼほぼこのKV Cacheで高速化するというのは一般的には行っているところかなと思います。

石原:今日話してきているリアルタイムに世界の中を動き回る世界モデルを作るためには必須の技術になっていて、いろんな世界モデルが出ていると思うんですけど、おそらくもうほとんど全てのこの世界モデルがこれを実際に行っています。

具体的に中身の説明をしていくと、逐次的に生成するようにできるのはいいんですけれども、モデル自身が生成した次のフレームを実際に入力にまた渡してさらにその次を生成していくということを繰り返して長いシーンを作っているんですけれども、こうすると何が難しいかというと、モデル自身が生成したシーンというのは必ずしも100%正しいわけじゃなくて、ハルシネーションをしていたりとかアーティファクトが出てしまったりすることがあるので、それをモデル自身が理解してちょっとずつ修正していくような能力を獲得するために必要な学習手法になっています。また、Flow Matchingのモデルというのは新しいシーンを作るためには何回も推論を行う必要があるので、これが多いとリアルタイム推論が間に合わないということになってくるので、これは減らしたい。このモデル自体の推論の回数を減らしつつかつ自分のこう間違いを徐々に修正していくことができるようにするための魔法のようなテクニックになっています。

山口:なんから自分自身のエラーが積み重なっていくというのは基本的にそうなのかなと思っていて、自分が予想したものをまた利用してどんどんやっていくから、一個間違いがあるとそれがどんどん広がっていくというのは直感的には分かる部分かなと思っていて、それをうまく修正するように学習できたらいい感じになんか整った予想ができるというのはその通りかなと思っていて、具体的にどうやってこのエラー修正をしているんですか?

石原:そうですね。具体的にどうやっているかというと、普通学習時はTeacher Forcingと言って実際のデータを持ってきて、それを入力して将来を生成させるというのが普通のやり方なんですけれども、ここでこう入力に実際の映像を入れてしまうと推論時もこの実際の映像が出てくるんじゃないかと期待してしまうわけですね。なのでどうするかというと、モデル自身が実際に生成したちょっと劣化したデータ・映像というのも作ります。そしてこれを実際の学習時の入力に当てはめるということを行います。こうするとエラーを含んでしまった映像から本当に良いシーンを生成するための学習、つまりエラー訂正ができるような学習ができるという仕組みになっています。

山口:なるほど。元々のオリジナルの綺麗なものが入力が入ってそれにこうスポイルされていると、実際に動かす時にそんなものが入力で常に来るわけではないのでなんかエラーがどんどん膨らんでしまうけれども、元々なんか自分が生成したものを学習時にもインプットとして入れるようにしておけば、その拡大はおそらく抑えられるんじゃないかという発想で、これは結構腑に落ちるところであります。

それとこのTeacher Forcingの、マルチステップからもう少し小さなステップに蒸留する部分は、どう関係があるんでしょうか?

石原:言ってしまうとちょっと独立した物事ではあるんですけれども、この蒸留をやっている理由は目的として小ステップで生成をできるようにしたいというのがあります。これはですね、Teacherと書いているのは先ほどお話した長い動画を一括で生成するモデルで、Studentと書いているのは逐次的に生成をするモデルですね。この逐次的に生成するモデルを細かく見ていくと、実際本当にやらなきゃいけないのは何回もこのモデルを推論させて新しいシーンを生成するということなんですけど、この推論のステップ数を減らしたいという目的でこのTeacher Studentという枠組みを入れて蒸留を行うということをやっています。

山口:発想としては蒸留の方が先にやりたい話としてはあるのかなと思っていて、やっぱりその推論を早くするというのは生成モデルに関してはかなり重要なステップかなと思っていて、ただそのまま蒸留するとモデルの学習とかディストレーション自体の安定化とかもかなり難しくなるので、そこでうまくその修正をするような仕組みを入れると蒸留がかなりうまくいくよみたいな流れの発想で作られたんじゃないかなというのはちょっとなんか想像はしますけれども。

石原:そうかもしれないですね。単純にその学習のステージをその分1個減らすことができるので、2つを組み合わせてやりやすかったというのもあるかもしれないです。


World-Action-Model(WAM)と実車公道走行

石原:最近よく話題になっているのがWorld-Action-Model(WAM)というものが登場しています。これは何かというと、これまではVLA(Vision-Language-Action)モデルというのがずっとトレンドとしてあったと思います。弊社もそれに取り組んできたんですけれども、2026年からこの世界モデルをバックボーンとしてアクションを生成させることができるように改変したモデル、これがワールドアクションモデルと呼ばれるパラダイムになっています。

これを何故取り上げたかというと、この紹介している論文が言っていることなんですけれども、単純にアクションを生成させるだけの学習をするよりも世界モデルタスクというのを同時に入れて学習させることで、同じデータ量で学習しても、より世界モデルタスクを含めた方が性能がぐんと上がるということを主張している論文になっています。なので我々も今後のトレンドとしてこのWAMというものにフォーカスを当てて、必要な技術を取り込んでE2Eのモデル開発に役立てる必要があるんじゃないかということで、この話題を取り上げさせてもらいました。

山口:世界モデルでアクションを出すということで、この世界モデルというのはこの映像を生成するとかアクションのコンディショニングをして、それに順じたシミュレータとして使うだけじゃなくて、何かアクションさせる。ロボットだったら何か物を掴むとかそういったところが、ロボティクスとかでも結構出てるところがあると思いますし、自動運転でもできるはず、つまり世界モデルに車を運転させることができるはずということですね。

石原:できると思います。

山口:お、何か来ました。何ですか?

石原:はい。私のいるDriving AI 3チームでは、実際にこのWAMという技術を使ってE2Eのモデル開発を行っています。そして先週、実際に車両にこのWAMで作った自動運転モデルをデプロイして、公道の試験まで行ってきました。

山口:これ運転してるのは、もしかして石原さん本人ですか?

石原:はい。そうですね。

山口:自分で作ったモデルを自分で試験をしているということで、チューリングの社員の人結構これ運転していますよね。これがまさに先ほど言っていた、自分たちで学習した世界モデルがあって、それにアクションのエクスパートの部分をつけて車を運転できるようにした、つまり車載でリアルタイムで推論できるようにと、そういったモデルを作って実際に自動運転システムの方に搭載したということですよね。アクセルとかブレーキとかステアリングも自動で動いてくれるということなんですか?

石原:はい。全て自動で動きます。

山口:素晴らしいですね。ロボットとかだとこのWAMでマニピュレーターとかを動かすとかは見たことがあるんですけれども、車でこう動かしているみたいな例というのは、かなり珍しいというかほとんど見たことないなと思っていて、実際この自動運転の文脈でこのWAMを実車で動かしたみたいな例というのは聞いたことがないですが、前例はあるのでしょうか。

石原:自分が知る限りは、パッと思いつくものはないですね。

山口つまり世界初…

石原:まあ全てのことを知る手段はないので分からないですけど(笑)。

山口:もうちょっと自慢してもいいのかなと思いますが(笑)。さらっと出てきたんで流されそうになっていましたけど、とにかく世界モデルを使って実際に車を走らせるぐらいのところまでチューリングの中では内部的に技術開発が進んでいるということですよね。

石原:はい。

山口:この辺の詳細がまた別の機会でどういう風になっているかというところをご紹介する機会もあるのかなと思いますけど、今日のところは実際に車を動かしていますよという紹介のところですね。この世界モデルの開発、今のチームでやり始めてどのくらいですかね?

石原:今のチームができたのが4月なので2ヶ月半ぐらいです。

山口:それでもう車を動かすところまで行っているということで、結構期待が持てる技術かなと思いますが、具体的にWAMとして車載にデプロイする過程での難しさはありましたか?

石原:一番難しかったところで言うと、やっぱり推論速度ですね。車載のコンピューターはOrinというもので動いているんですけれども、Orinに搭載可能なサイズで、かつリアルタイムに推論することができるという状態まで持っていくところが非常に難しかったです。基本的に世界モデルというのはかなり大きなモデルでして、小さいものでもおそらく2B(Billion)とか少なくともそれくらいのサイズはあるんですけど、さすがにこの大きさを車両に持っていくことはできないということで、車両でリアルタイムに動くアーキテクチャというものを最初に見繕っておいて、そこから学習するという手順で開発を進めました。

それをやると実際にリアルタイムで動かせるアーキテクチャを見つけることはできるんですけれども、やっぱりサイズが小さくなるということもあるので、動画生成モデルというのは基本的にモデルが大きくないとなかなか動画を作ったりすることができないというところで、その小さいモデルでうまく学習をするかというところも難しかった点だという風に感じていますね。

山口:元々車載で動く用にコンパクトに作らなきゃいけないというのが、普通のいわゆる動画生成のモデルとかのプレトレーニングされた動画をファインチューンしますよみたいなやつだとこれ全然乗らないみたいな話になるので、そもそもコンパクトになるようにうまく狙って作らなきゃいけなかったということですよね。


今後の展望

山口:なぜ世界モデルを使うのかという理由付けとして、我々で言うと今東京とか最近だと大阪とか名古屋でE2Eの自動運転モデルは動かしているんですが、そことの差、つまりパラメーターサイズもリアルタイムで動かそうとすると大体まあ似たような形になると思うんですが、世界モデルを使うと何が嬉しいでしょうか。

石原:チューリングは自社でデータ収集を行っているんですけれども、プロのドライバーさんも雇っていますし車両自体の数も限られているので、自分たちが使えるデータというのはやっぱり量が限られてしまいます。ですが、自分たちの競合であるWayveとかTeslaみたいなところというのは膨大にデータを持っているわけなんですよね。そこに勝つためにはどうすればいいかということを考えた時に、自分たちが持っているデータから得られる学習信号・情報、自動運転のモデルを作るための情報を最大限抽出しようというモチベーションがあります。

チューリングがメインストリームで開発しているモデルは基本的にアクションを使って模倣学習をしているんですけれども、WAMになってくるとその動画そのものも学習と学習の信号として使えます。そして動画は非常に大きな情報量があるのでこの学習信号を逃すのはもったいないというところで、持てるデータを最大限生かすためのアプローチとして私はこれを考えています。

山口:メインストリームで開発しているE2E自動運転は、いわゆるBehavior Cloningが中心になっていて、人間のドライバーのデータをうまく模倣するために基本的に学習しているんですが、そうではなくて、例えばバックボーンとして使うモデルとしてプレトレーニングでいろんな動画データをたくさん使うような形ができたら、もっと賢い運転・自動運転モデルの性能が上がるんじゃないかという仮説があって、そのアプローチとして世界モデルというのがその動画の情報量を一番使えるということで合ってますか?

石原:合ってます。

山口:世界モデルのところ、2026年はトレンドになってくるんじゃないかなという風に思っていますし、最近で言うとVLAと世界モデルを組み合わせる、例えばVLAのロスでワールド的なロスを加えるとか、それらを融合して学習するみたいな話も出ていますし、先日NVIDIAがCosmos 3というのを発表していましたよね。あれはなんか双子みたいな感じになっていて、片や生成モデル、片や言語モデルでそのクロスアテンションを共有して両方できるぞみたいな感じで出てきたんですけれども、世界モデルと言語モデルというのは技術的に系統としてちょっと異なるモデルではあるんですが、それが徐々に近づいていくみたいな話も技術トレンドとしてはもしかしたらあるのかなということをちょっと感じています。

両方ともロボティクスとか自動運転の分野では昔から注目されていた部分ではあるかなと思うので、この辺が今後どういう風に展開していくかというのは非常に楽しみなポイントがありますね。


Q&A一覧(一部抜粋)

以降は視聴者のQAに回答していきました。詳しくは動画をご覧ください。

  • 世界モデルはピクセル描画の精度の優先度、または完全に捨てるかで派閥が分かれている理解をしていますが、自動運転に関連する世界モデルにおいてはどれくらいピクセル再構成は重視されているのでしょうか?
  • WAMとVLAの関連の言及がありましたが、チューリングさんとしては今世界モデルは現行のE2Eとは独立したアプローチとして研究しているのでしょうか。
  • WAMの世界モデルヘッド(動画生成)は、推論時にも実際に未来映像を生成しているんでしょうか?それとも学習時の表現学習のためだけで、推論ではアクションエクスパートだけ動かしているんでしょうか?

チューリングでは、完全自動運転の技術を共に創る仲間を募集しています。今日お話しした世界モデルに取り組んでいるDriving AI 3チームはもちろんのこと、機械学習エンジニア、リサーチャー、ソフトウェアエンジニア、組み込みエンジニア、インフラエンジニアなど、非常に幅広いエンジニア職種で仲間を募集しています。ご興味のある方は、ぜひ採用ページをご確認ください。多様な職種がありますので、ご自身がどれに当てはまるか、ぜひチェックしてみてください。

TuringTechTalk#39 実車で動かすVLAモデル「DriveHeron」──公道走行実現とその先の進化

この記事に登場する人
CTO
山口 祐 Yu Yamaguchi
産業技術総合研究所 研究員/米国NIST客員研究員として研究する傍ら、独自にゲームAIの深層学習の開発を開始。日本の囲碁AIプロジェクトの開発代表として、最大1100GPUの並列分散強化学習を設計・開発し、世界大会準優勝、将棋AIでも世界大会優勝などの実績がある。HEROZ株式会社 執行役員を経て、2022年、チューリングに創業メンバーとして参画。2024年8月、CTO就任。基盤AIチームマネージャー兼任。
基盤AIチーム シニアエンジニア
加藤 利幸 Toshiyuki Kato
大学院を卒業後、東芝グループ企業に入社。機械学習を用いた受託開発やMLOps基盤の開発に従事。大学院時代から機械学習コンペティション「Kaggle」に参加し、「Kaggle Grandmaster」の称号を持つ。2024年4月にチューリングへ入社し、E2E自動運転で30分間の公道連続走行を目指す「Tokyo30」プロジェクトに参画。2025年11月より基盤AIチームに所属。

はじめに

チューリングでは、環境認識から経路計画、運転制御までを単一のAIで行うE2E(End-to-End)自動運転AIと、人間社会の常識や背景、文脈の理解を獲得した大規模基盤モデルを同時に開発し、これらを統合することで、あらゆる条件下において車が人間に代わって運転操作を行う「完全自動運転」の実現を目指しています。

2026年3月、国内で初めてVLAモデルによる公道でのリアルタイム制御および走行を実現しました。今回のTechTalkでは、CTOの山口と、基盤AIチームの加藤が登壇。自動運転VLAモデル「DriveHeron」による公道での走行が実現するまでの取り組みをはじめ、更なる性能の向上に向けた取り組みをご紹介します。

※本記事はTuringTechTalk#39の内容を元に一部編集してお届けします。

今回はVLAモデル「DriveHeron」を深堀り

final_001_000m00s

山口:皆さん、こんにちは。TuringTechTalk第39回「実車で動かすVLAモデル『DriveHeron』──公道走行実現とその先の進化」を始めていきたいと思います。本日は基盤AIチームのシニアエンジニア、加藤さんに来ていただいています。加藤さん、よろしくお願いします。

加藤:よろしくお願いします。

山口:久々となりますTechTalkですが、再開1回目のテーマは「VLA」ということでですね、3月から4月にかけてVLAモデルを公道で走らせたというアナウンスをしていましたが、その裏側の技術について、深堀りしていこうと思います。それでは加藤さん、簡単に自己紹介をお願いします。

加藤:はい。大学院修了後、東芝グループ企業で9年間、機械学習を活用した受託開発やMLOps基盤開発に従事しました。さまざまなドメインのデータに触れるなかで「一つのドメインに絞って深く開発をやってみたい」という思いが強くなり、自動運転と出会ってチューリングへ入社しました。また、学生時代からKaggleのコンペティションに参加しており、Kaggle Grandmasterを取得しています。チューリングには2024年4月に入社して、今年で3年目になります。入社後は「Tokyo30」プロジェクトに携わり、2025年11月に基盤AIチームに所属しました。

山口:加藤さんは、Kaggle Grandmasterとしても著名で、チューリングの中でも、自動運転のAIモデルを開発するといったところで、主力として活躍してもらっています。社内には現在Kaggle Grandmasterが4人いまして、いずれも開発で活躍していますが、加藤さんもその一人です。

山口:今日のテーマにある「VLA」ですが、あまり聞き慣れない言葉かもしれません。VLAは「Vision-Language-Action」の略で、視覚・言語・行動が一体となったモデルです。ロボティクスの分野で注目されており、LLM(大規模言語モデル)に視覚入力を加えたVLM(Vision-Language Model)に、さらに現実のモーターや車両を動かすアクション出力を加えたものがVLAになります。

山口:最近我々このVLAモデルを走らせたわけですが、モデルに名前があるんですよね。

加藤「DriveHeron」ですね。

山口:この「Heron」というのは何なのか、ついでに教えてもらっていいですか?

加藤:この「Heron」という名前は、チューリングが昔から開発しているVLMにつけられた名前で、私が入社するよりも前から開発が進められていました。そのオリジナルのVLMは自動運転そのままをさせることはできないんですけど、それを自動運転に応用したものが今回のVLAモデル「DriveHeron」であるという風に認識していますが、合ってますか?

山口:そうです。Heron自体は2023年の7月から開発をしていて、その時はまだ車の運転とか関係なくて、言語モデルだったんですね。視覚言語モデル・マルチモーダルモデルの国内での走りとして実は我々開発してたんですけれども、それを作っていたのも、今回ご紹介するような車を動かすために実は作っていたというところなので、これがどういう変遷を経て車に搭載され、またそれが実際に道路で走るようになったのかといったところが今日のテーマになってくるというところです。

完全自動運転開発の「二つの軸」

山口:早速中身のほうを加藤さんに解説していただきたいと思います。

加藤:チューリングの自動運転開発には大きく二つの軸があります。ひとつが「E2E(End-to-End)自動運転AI」です。自動運転というとクラシックなものは認識・計量・計画・制御、そういったモジュールをそれぞれ作った後にそれらをつなげて自動運転を動かすというあり方がありましたが、AIの技術が進歩してきまして、それらを単一のAI・単一のディープラーニング(深層学習)モデルで実行するという方法論としてE2E自動運転が進化してきました。このアプローチを利用すると全体のシステムをシンプルな構造にしたまま直接最適化を行っていくことが可能になりまして、人間の運転のような自動運転ができるといった点で大きく期待されています

この巨大なAIモデルをトレーニングするために利用するのが人間の走行データです。人間のドライバーが現実世界を運転してデータ収集を行い、そのデータをもとに巨大なニューラルネットワークに入力と出力の組み合わせを与えていわゆる模倣学習(Imitation Learning)を行う。これを非常に大規模な規模で行うことによって、従来のモジュールベース・ルールベースではできなかったような自動運転ができるようになっていくという仕組みになっています。「Tokyo30」では、このE2E手法でチューリング製の車載チップ上で動作する軽量モデルを開発し、2025年11月末に東京都内30分間の無介入走行に成功しました。

そして、もう1つの軸が「大規模基盤モデル」になっています。チューリングが力を注いで開発してきたもののうちの1つが先ほど出てきたVLM(Vision-Language Model)になっています。このモデルは大規模言語モデル・LLMをベースにしていますので、人間社会の常識・背景・文脈を理解することができます。また言葉による推論や説明可能性も高いと言われていて、これを自動運転に適用することで標識・指示・状況の意味的な解釈が可能になるということが期待されています。チューリングは汎用的なVLMとしてHeronを開発してきました。2025年の5月には「Heron-NVILA-Lite」という名前でHugging Faceにモデルを公開しまして、多くの方にモデルを使っていただいています。

参考:日本語VLM「Heron-NVILA」公開 ─ Qwen2.5-VL-7B・Gemma3-12Bに匹敵する性能

加藤:そして今日お話しするVLAモデルのDriveHeronは、これら2つの軸を組み合わせて実際に公道を走行するというところまで行き着いた、チューリングにとっての最初の取り組みという風になっています。

山口:ちなみに最近チューリングでは銀座とか新橋のあたり、割と都心でも走れるようになったという発信もしているんですけれども、あれで走っているモデルはまだ言語モデルではないですよね。

加藤:そうです。あれは軽量モデルのE2E自動運転になっています。

山口:なるほど。つまりこのスライドで言うところの左側のE2E自動運転AIというのが今我々がメインストリームで車を走らせているもので、今日お話しするのはそれを一歩進めたような、言語モデルと融合したモデルということですね。

なぜVLA自動運転を作るのか

加藤:なぜVLA自動運転を作るかといったところを、少し違う角度から説明していきたいと思います。自動運転の大きなアプローチとして3つあります。1つが従来のモジュール型AI、次がE2E自動運転、そして今日お話しするようなVLAモデルといった大規模基盤モデルを組み込んだものです。

モジュール型AIの場合は、判断根拠が分かりやすいといった点や、それぞれのモジュールを開発して丁寧に検証ができるので、比較的シンプルな状況では導入が進みやすいといったところがあります。HDマップ(High Definition Map:高精度3次元地図)を作成すれば事前に決めた通りの動きをするというところが自明になりますので、レベル4の自動運転などでこちらの技術が普及していっています。

E2E AIの場合は、よりレアなシーン・人間じゃなければ運転が難しいようなシーンでも、トレーニングデータの中に似たようなシーンが含まれていると、それらの知識を機械学習によって学習しているので、人間らしい運転ができるようになっていくということで、レベル2自動運転を市街地で行う時などに非常に飛躍的な成長を遂げている技術という風になっています。

しかしながら、このE2E自動運転は、トレーニングデータがあってこその振る舞いになりますので、トレーニングデータの中に稀にしか現れなかったことや全く現れなかったことについてうまく振る舞うということが保証されません。そこで期待されている技術として大規模基盤モデルがあります。事前の学習で人間らしい言語や文化的な背景を知識としてモデルに教え込ませているので、それらを自動運転に適用した時も人間らしい思考ができるようになっていく。これによって、E2E自動運転だけではたどり着けなかったような高度な、非常にレアケースを含むレベル4の自動運転や完全自動運転に近いものを作ろうとする時にこの技術が必要になってくるのではないかという仮説のもと開発を進めています。

これを言うと「VLAやフィジカルAIはE2Eと全然違うものなんじゃないか」と感じられる方もいるかもしれないですけど、実は全然そんなことはなくて、VLAの運転を行う場合は従来のE2E AIの延長線上にあるようなものという風に考えておりまして、人間が運転して集めたデータもトレーニングに使うし、全体としてシンプルな構成にしてE2Eのトレーニングを行うといったところは変わっていないんですが、そのベースになるものとして基盤AIモデルを使っていくというものになっています。これによって、直接的な最適化やシンプルなシステムを保ったまま、VLMの言語知識で通常のE2E自動運転の弱点を埋めていくことができると、そういった点に期待しております。

山口:このモジュール型AIというのは、どちらかというとこの流れ自体は2004年にアメリカの国防省が開催した自動運転レースからスピンアウトしてきたような技術が思想のベースとなっていて、センサーをたくさんつけてそのセンサーに従って正確に運転するというのが非常に強力だったんですね。今でも例えばアメリカのサンフランシスコだと、Waymoの無人タクシーがたくさんあって、非常に快適に乗れるし、もう生活の一部として存在している。そういった限られた地域で運行するという意味では今でもすごく強力なところなんですね。ただこれを自分が持っている車に搭載できるか、あるいはいろんなところの市街地の複雑な新しい場所に適用するみたいなところだと、意外とうまく行かない。

これと別の潮流で深層学習がありまして、2012年頃にAlexNetが出てきてそれからどんどん新しい手法が出てきて、というところの流れを組んでいるのがやはりE2Eというところですね。さらにそれがChatGPT以降、GPT-4以降の2023年頃から言語モデルというところが来て、また新しい波が来ているというところで、自動運転もそういった波を受けながら技術の潮流が変わっているというところかなと思います。

加藤さんとしては、このE2E AIとVLAの部分は、構造としては別に変わらないということなんですかね。

加藤:そうですね。モジュール型かモジュール型じゃないかというところに着目すると、E2E自動運転と大規模基盤モデルを組み込んだフィジカルAIの差というのは実はちょっとした差でしかないんですが、しかしながらその中に組み込まれている基盤モデルというのが圧倒的に賢いものであれば、性能的には大きな差が開く可能性があるからということで期待しています。

実車走行の進め方と、DriveHeronの基本仕様

加藤:我々がVLAモデルの実車走行をどのように進めていったのかを説明していきます。

加藤:先ほども説明がありましたが、チューリングは以前「Heron」というVLMを自社開発していました。このHeronをトレーニングする時はウェブの画像やテキストをとにかくたくさん利用して、一般的な知識を獲得するということを行いました。

そして今回の取り組みはですね、チューリングが自分たちの会社の開発車両をたくさん走らせて、東京、最近は東京以外も行ってますけど、交通ドメインデータをたくさん収集して、そのデータセットに車をどのように操作したかみたいな情報も付けられますので、身体性を獲得させるための追加モジュールの山をVLMに付け足しまして、VLAモデルのDriveHeronを作るということを行いました。

チューリングではここ2年ほど「Tokyo 30」プロジェクトで、軽量E2Eモデルで公道走行できる実車走行のプロジェクトを進めてきていて、センサーや自動運転車両をどういう風に取り扱えば良いかとそういった知見も溜まってきていましたので、その知見と今回開発したVLAモデルを統合して組み合わせることによって、VLAモデルによる実車走行を実現していきました。

加藤:このDriveHeronがどのようなものか紹介していきたいと思います。

まずベースモデルですが、このVLAモデルは大部分がVLMを組み込んだ形になっておりまして、そこで自社開発したHeronを利用しております。このモデルが持っているニューラルネットワークのパラメータ数の規模としては1B(ビリオン:10億)から2B、10億から20億パラメータになっています。

次に制御周期なんですけども、実際に現実世界でリアルタイムに処理を行って車を走らせる時には反復的に推論を行っていく必要があるんですが、その周期を今回10Hz(1秒間に10回)という風にしました。これを実現するためには、ディープラーニングの入力が入ってきてから中身の計算を行って出力するまでの処理を100ミリセカンド(0.1秒)以内に行わなければならないということになります。

実車での推論に利用するチップとしては、今回NVIDIAのRTX 5090という商品を利用させてもらいました。これは一般にゲーミングPCに搭載されるようなハイスペックなグラフィックボードになっておりまして、現段階ではロバスト性が保証された車載用の機器のスペックだと推論が追いつかなかったというところがありますので、今回ハイスペックなゲーミングPCを追加してシステムを作りました。

また実車推論を行う時の推論精度ですが、今回推論を高速化するためにFP16(半精度浮動小数点数)まで量子化して処理を行うという風にしました。推論のランタイムとしては、モデルを実車の上で動かす時に推論を早くさせるためのフレームワークとして、今回TensorRTというものを利用しました。

カメラ数については、今回パラメータがこれだけの規模のモデルを初めて動かすというところだったので、1カメラ入力にしました。チューリングの開発車両は7個から8個カメラがついていて、本来マルチカメラの自動運転もできるようになっているんですけど、今回の取り組みでは1カメラで検証を行いました。またMLモデルに入力する画像のサイズは448×448pxという風になっています。

山口:このパラメータサイズですが、1Bから2Bというのは、LLMとかVLMの世界でいうとどのくらいの規模と考えたらいいんですか?

加藤:これが出てきた当初は非常に大きなモデルという印象だったんですけども、最近は数十Bとか数百BのLLMなどもオープンソースみたいな感じでどんどん配布されていたりするので、実はLLMとかVLMの世界の中ではコンパクトな部類のモデルになります。

山口:例えばOpenAIが動かしているものは、裏では数Trillionのモデルが動いているんじゃないかという話もありますので、それに比べるとだいぶ小さいというところですね。ただこのくらいでもVLMとして喋れますし、画像を入れてこれが何なのかと答えることもできる。実は我々がiOSのHeronのアプリを過去に出していて、それのモデルが確かに2Bなので、実車で動かしたものと実は同じぐらいのスペックなんですね。

制御周期の10Hzというところもパラメータサイズと関係していますが、パラメータサイズを大きくすると10Hzに間に合わなくなるということなんでしょうか?

加藤:そうですね。全体で見るとパラメータサイズだけじゃなくてカメラ数をいくつにするかとか、入力する画像の解像度をいくつにするかといったところと全ての兼ね合いで決まるんですけど、今回なるべく大きなパラメータのものを動かそうとして、リーズナブルなところはどのくらいかなとチームで議論したんですが、やはり10億から20億のパラメータ数がちょうどいいかなというところで。これより大きなパラメータになってしまうと入力する画像の解像度を極端に小さくしなきゃいけなくなって、見えちゃいけないものが見えなくなってしまったりしますし、逆にこのパラメータ規模を例えば半分とかもう1桁減らしたりすると、従来のE2E自動運転の軽量モデルとの差が見えにくくなってくるといったところもありますので、VLA自動運転モデルとして今試すべきは1Bから2Bかなという風な感触がありました。

山口:なるほど。なのでこれはいわゆる推論、実際に車を動かす時の実行の速度から逆算して大体このくらいだろうというところで開発しているということですね。大体エッジ(端末側)で動かすようなロボティクスとか自動運転・車載の場合はスタンドアローンで動かさなければいけないので、この辺の推論のスピードというのが基本的にはかなり制約として乗ってくるということですね。

「DriveHeron」が公道走行に至るまで

加藤:「DriveHeron」が公道走行に至るまでどのように進めていったかを、順を追って説明します。

大きな流れとしてはまず机上で検証できること。ソフトウェアだけで検証できることから始め、段階的に本番の実車環境に近づけていくという流れになっております。いきなりハードウェアや車を扱って簡単なことでつまづいてしまったりすると大きな手戻りになってしまうというか、ハードウェアを扱った実験や検証を行うにはそれだけ準備も大変になりますので、なるべく手軽に検証ができるものから優先して進めていったという形になっています。

ポイントとなるのは、今回VLAモデルという新しい技術を組み込んだ自動運転を動かしたという話になるんですけども、実はチューリングが「Tokyo 30」プロジェクトで開発してきたE2E自動運転の方と、大まかな進め方としては同じ進め方になっています。そうするとチューリングの中にはその仕組みをスムーズに着実に進めていくための社内エコシステムのようなものがそれぞれ存在していて、サポートしてくれるメンバーもたくさんいますので、これらのプロセスを効率的に進めることができたという形になっています。

加藤:それでは各ステップについて具体的に説明していきます。まず1つ目のステップはモデル開発です。今回は実車走行させるリアルタイムシステムを作っていくというところがありましたので、推論速度を10Hz・100ms未満でちゃんと追いつくように設計したというところがポイントになります。

DriveHeronを実車走行させるためのシンプルな最小構成のアーキテクチャとしては、ベースになるVLMに対してシンプルなプランニングヘッドを追加したものになっています。また入力しているのがカメラとEgo Motionですね。カメラ画像複数枚とEgo Motion・車のセンサーデータなどを入力すると、VLMが出てきた結果をプランニングヘッドに渡して、それが出てきたもので車を動かすという最初の構成になります。

今回プランニングヘッドとしてシンプルな回帰ヘッド(数値を直接予測する手法)を採用しました。VLAモデルはロボティクスなどの領域でも使われておりまして、そちらでは「生成型」と呼ばれるアプローチ、具体的にはDiffusionやFlow Matchingといった技術を組み入れたもう少し複雑なプランニングヘッドが利用されることが多いです。最初我々もそれに倣って生成型のプランニングヘッドを利用しようとしたんですが、そういった系の技術は推論時に反復計算が必要となってしまいレイテンシが大きくなってしまうという難しさや、高速化のためにモデルを量子化していくと累積誤差によってサンプリングが乱れやすいといった課題がありました。

そこで今回、早くて壊れにくい回帰ヘッドを採用しました。車両制御に必要な情報を値として直接予測するような仕組みになっておりまして、L1 LossやL2 Lossという非常にシンプルで安定的に動作するロス関数(損失関数)で学習が可能です。

山口:基本的には我々がこれまでHeronを作ってきたVLMのアーキテクチャが踏襲されていて、それに対してプランニングヘッドと言われるものをつける、ここをうまく学習するというのが肝になるということで合ってますかね。

加藤:はい。その通りですね。

加藤:2つ目のステップは机上評価です。このプロセスはMLモデルを車に乗せる前に、まずはオフィスの机の上でできる検証を文字通り机上で行っていくというプロセスになっています。

推論速度がちゃんと100ms以内に収まっているかを確認してリアルタイム推論ができることを確認します。チューリングが実際に集めた過去の走行データをソフトウェア的にシステムに再入力して、推論に使うMLモデルだけを差し替えて推論させてみるという仕組みを持っていますので、初めにそれで推論がちゃんと回るかというところを確認します。

また実車環境とチューリングの車に搭載されているカメラと全く同じ種類のカメラを手に持ちまして、車に搭載する予定の計算機なども机の上に一式置いてある状態で、そのカメラにノートパソコンに表示した走行データの映像を映してカメラを手元で見せてあげることで、推論結果がちゃんとしているかを確認しています。

また、社内に持っているシミュレーション環境を使います。これは3DGS(3D Gaussian Splatting)といった技術で作られているシミュレータで、このシミュレータの世界の中をMLモデルに走らせてみることができます。直進で対向車が来ている例や急なカーブで折り返しているような例などで、うまく他の車を意識しながらカーブできているかなどを確認します。またシミュレーション結果を数値的にスコアリングして評価し、各評価項目ごとに合格点みたいなものがなんとなくありますので、雰囲気問題なさそうであればと、そういった判断になります。

山口:ここまでの話をいわゆる机上検証、つまり論文とかでVLAモデルを作りましたと言っても大体皆さんここぐらいまでやるというところで、このシミュレーター上でやりましたというスコアがどのくらいですというところがある。ここから先がいよいよ実車でどう動かすのかというところで、ここの先はあんまり論文などに出てこない部分になっていきますよね。

実車検証、クローズドコース検証、そして公道へ

加藤:3つ目のステップからは車を使った検証を進めていきます。

まず実験車両に計算機一式を載せて必要なセンサーやケーブルを接続して動作確認を行います。それができたらMLモデルによる推論を有効化して、実際にラボの外を走ってみるということを行います。これを試す時最初は、自動運転による制御はオンにしないで、あくまでも運転は人間がしているんですが、リアルタイムで推論だけは動いているという状態で試験を行います。ここで確認する項目の例としては、システムが安定的に期待通り動作しているかという点、推論速度が目標時間に収まっているかという点、そしてプランニングの出力が妥当に見えるかといった点です。

山口:トランクを開けたところにこういった計算機が積まれていて、そこで実際のこの計算機が回って車を操作するといったところになっていますよね。右側に映っている黒いものが5090が乗っているマシンで、その左側に見えているちょっと緑っぽい計算機、これがOrinが動いているオリジナルの車載計算機で、この間を繋いで通信しながらVLAの計算だけをオフロードするというところですね。この通信のプロトコルも内製化していて、結構面白い仕組みになっているところです。

ちなみにこの写真に映っているのは同じチームの横井さんですね。横井さんも実はKaggle Grandmasterで、Kaggle Grandmasterが2人いるチームは国内でもあんまりいないんじゃないかなと思っていますけれども、横井さんもこのベースのVLMを作っていたということで過去にTechTalkで色々と話していただいてますけども、このKaggle Grandmasterの力を合わせて実はできたのが今回のDriveHeronというところですね。

final_027_057m00s

加藤:次は実際に制御を入れて車を走らせてみます。いきなり公道や交通量の多いところで行うと危険がありますので、クローズドコースを貸し切って検証を行います。

この検証を行う時はなるべく簡単なアクションから段階的に検証を行っていきます。今回は右カーブを最初に着目したんですけども、カーブがあってハンドルを切っていって曲がり終わったらハンドルを切り戻していくというシンプルな動きでも、システム的にはエラーが出ていないけど実はちょっと画像の前処理が間違っていたりするとうまく動かなかったりするので、そういった点に注意しながら安定的に動作するよう繰り返し検証を行っていきます。

右カーブができるようになったら次は左カーブを行いました。日本は左側通行なのでハンドルの切れ角としてはより大きく回さなきゃいけないという難しさがありますし、コーナー自体も急になりますので、右カーブよりも不安定になりやすいんですけど、こちらも徐々にできるようになっていきます。

その後は発進と停止の検証です。我々の開発車をもう1台用意して先行車がいる状態を作り、「目の前に車がいるから止まらなきゃ」という停止の確認、また交差点での信号機が青だから進んでいっていいというところも期待通り動くようになりました。そして最後は右折です。ハンドルの切れがこの4つの中で一番大きくなるので、最初はなかなか思い通り動かなかったりするんですけど、検証を重ねていくとできるようになっていきます。それぞれのアクションが1回できた後も、成功率を高めていく、走行軌跡が人間の運転のような軌跡になっているか、動きとして滑らかになっているかといった点を磨いていくということを行います。

山口:実車で動かすとなるといろんなトラブルもありましたよね。まずモデルを載せたはいいけどそもそも全然真っすぐ走らないぞみたいなことも結構ありましたよね。

加藤:そうですね。机上での検証ではちゃんとまっすぐ走るはずだしカーブも曲がれるはずなのに、実車で動かしてみるとあれなんかうまくいかないといったことはどうしても起きますね。実車にしかないパラメータみたいなものがあったり、システムや車両のコンディションが影響してきたり、そういった難しさはどうしてもあるかなという風に思いますね。

山口:運転しているのは加藤さんですよね。

加藤:そうですね。ハンドルを両手で握って基本的に自動運転に任せてみるんですが、ちょっとでも危ない動きをしたらすぐに介入すると、そういったことを繰り返して徐々に安定していくという進め方になっています。

加藤:5つ目のステップはいよいよ公道走行です。クローズドコースでの検証結果を社内で共有しまして、丁寧に確認しまして、これなら公道のこのエリアなら試しても大丈夫だろうというところで承認を得ましたので、公道のところで実際に試験を行うというところにたどり着きました。

いきなり高速域や交通量の多いところで試すのは危険なので、まずは低速域で周囲に他の車が少ないところで試験を行いました。信号が赤になって停止線の手前まで停止して青になって発進すると、そういった動きが自動運転でできています。またロータリーのようなところでハンドルを大きく切らなきゃいけない場面でも安定的に車を制御することができました。

クローズドコースでかなり念入りに検証を行ってからこちらのエリアに行きましたので、ほぼ初日から今表示しているような動画くらいにはなったというところで、良い進め方ができたかなという風に思うんですが、試してみると課題も色々見えてきまして、例えばクローズドコースだと時速10km・20kmとかの速度でしか試せなかったんですけど、公道に行って時速30kmを試すと中速域での加減速に課題感があるなというところが見えてきたりしました。これは簡単に言うと乗り心地が悪かったということになりますね。乗り心地の良さはシミュレーターとかで確認できないので、それはそうという感じもするんですけど、そういう風に実際に実験を進めていくと新しい課題が見つかったりというのは必ずあるんですが、実験が終わったら振り返りとか走行データのデータ分析を行って仮説を立てて改善を回していく。これによって今話しているような課題もかなり改善してきていたりします。

山口:加藤さんは過去にチューリングが自動運転公道で走るためのモデルとして「TD-1」という、2024年の10月にアナウンスしたものの開発もしていましたし、それから「Tokyo 30」の主流のE2E自動運転モデルの開発もしていましたし、今回加えてVLAの開発もしているということで、それぞれのモデルで公道での違いみたいなものはありましたか?

加藤:もちろん開発が進んでいるものほどうまく走れるというところはあるんですけど、今回このDriveHeronのVLAモデルを作ってみて実際に運転席に座っていたんですが、モデルのトレーニングに使ったデータの割には賢い動きをするなという状況が多くありまして、トレーニングデータに例えば検証に使っていたクローズドコースみたいな道とか全然入っていないんですけど、人間らしい動きをしようとしているなという局面が結構ありました。

ただ、なんかパラメータ数が多いからか、ちょっとこうなんか頭でっかちな感じがするというか、身体性を後から追加していくというプロセスを経ているので、賢さとしては分かってるんだけど体がまだついていかないみたいなところがどうしてもあったりするのかなというフィーリングもありまして、そこは先ほどの乗り心地が悪いといったところに繋がっていくかなと思います。

他の取り組みとして例えば軽量なパラメータの少ないモデルですと、モデルのトレーニングも高速に進むんですけど、走りもちょっと軽快な感じになって乗り心地もいいんですけど、ちょっと慎重に考えなきゃいけない場面でなんかもうちょっと丁寧さが欲しいなみたいなところがあったりします。TD-1というのはパーセプションのサブタスクがついていて、3次元物体検出とかマップ認識の結果をモデル学習させる時もモデル推論させる時もプランニングと一緒に行うという方式で、周りの様子を意識しながら振る舞っていくというか、難しい局面になっても丁寧さがあるといったところはありましたね。あとは今回のVLAモデルはAIとしては賢いなというところがあったんですけど、1カメラでフロントしか見えていないので横や後ろで起きていることに反応することができないという違いも当然ありました。

「Alpamayo」との比較

山口:我々以外でVLAの自動運転モデルを作っている会社はあるんですか?

加藤:今日ここで紹介するのがNVIDIAのオープンモデルの「Alpamayo」です。NVIDIAといえばこの業界の人なら知らない人はいないと思いますが、NVIDIAでも最近は自動運転の開発に乗り出していて、実は自動運転の技術開発自体昔から行っていることを我々は知っていたんですが、このAlpamayoを発表して世の中的に大きな話題になりました。

このAlpamayoなんですが、NVIDIAがこのモデルを公開した時に「AlpaSim」というシミュレータも一緒に公開しました。このAlpaSimも3DGSベースのシミュレーターになっていまして、MLモデルと繋げて動かしてみるとリアルにレンダリングされた3D空間を自動運転で動かして、その運転が良かったか悪かったかみたいなところをスコアリングしてくれるシステムになっています。

今回はAlpamayoのモデル2つと我々が用意したDriveHeronのモデル2つをAlpaSimの上で動かして評価するということをしてみました。Alpamayoについては今公開されているモデルが10Bのパラメータのモデルになっています。公開されているモデルは2種類ありまして、最初に公開されたAlpamayo-R1もしくはAlpamayo-1というモデルと、その後に公開されたAlpamayo-1.5という別のモデルがあります。

我々のDriveHeronについては、先ほどの公道走行に利用した2Bのモデルをまず評価の候補にしました。そして、Alpamayoが10Bもあるということだったので、我々も8Bのモデルをトレーニングして準備しました。この8Bのモデルはパラメータが多すぎるので実車走行はできないサイズになっています。

この4つのモデルを比較すると、DriveHeronもAlpamayoに近いスコアが出るということが分かりました。2Bのモデルだと1.5の方には勝てなかったんですが、Alpamayo-1の方には同じくらいのスコアを出すことができましたし、8BのDriveHeronであればAlpamayo-1.5の公開モデルよりも良いスコアを出すことができました。

山口:AlpamayoはVLA自動運転の業界で今すごく一番注目されていますし、NVIDIAが論文で出して、あるいはCESで発表した後にHugging Face上でモデルを公開したり、AlpaSimを公開したということで非常に話題になっていたということで、NVIDIAが実際に公開しているシミュレータで公開したモデルを評価すると、スコアとしてはこのくらい出ますよというところです。論文のモデルは公開されていなくて、論文で評価したデータセットも公開されていないから、これはあくまで論文の値は参考値として載っているというところですね。これ、我々のモデルも簡単に評価できるものなんですか?

加藤:初めはインターフェースが違うのでなんか我々のモデルの入力と出力両方合わせてあげるという作業があるんですよね。AlpaSimが想定しているカメラの画角などの情報も公開されているので、前処理の部分を改造してあげてAlpaSimの世界と我々のモデルがうまく繋がるように入力調整してあげるというのがまず1点と、出力の方もAlpaSimで動かすことを想定して作っていたものではないので、出力に変換処理をかましてあげて我々のモデルがこの世界を走るよう改造したというところがありますね。

山口:DriveHeronの8Bのモデルだと公開のAlpamayoのモデルはもう超えているというところで、スコア的には上回っているということで。論文のスコアには届いていないですけど、いずれ我々もどんどん性能を上げていくと、論文のスコアも超えるようなモデルが作れるんじゃないかなと思っていますね。

加藤:我々としてはなるべく誠実に評価したつもりなんですが、論文で使ったとされるnuScenesのデータ全ては公開されていないというところはありますし、Alpamayo-1とAlpamayo-R1がどう違うかといったところも明言はされていないというところがあったり、Alpamayo-1が公開された後にAlpamayo-1.5というものが別に出てくるというのも当初は全く想定していなかったので、もしAlpamayoに詳しい方が視聴者の中にいたら知見を共有してくれると大変嬉しいです。

今後の展望:「DriveHeron」はここからが本番

山口:DriveHeronはこの先も進化の余地があるんですかね?

加藤:進化の余地があるというよりかは、私としてはまだDriveHeronの開発は始まったばかりかなという風に思っています。ベースになるVLMがありまして、それをVLAに変えて制御に繋げて車を動かしてみましたというところまで来たんですが、実はここからが本番かなという風に思っています。

次に何をやるのかというところなんですが、まずはより大規模なデータで学習するということですね。VLA自動運転もE2E自動運転の延長線上にあるものですので、自動運転モデルとしてのトレーニングに使うデータはもちろん多ければ多いほど良くなっていきますし、なんやかんやそれが一番効くみたいなところもあるかなと思います。

また、時系列の拡張といったところがありまして、今モデルが時間的に何秒ぐらい意識できるか、現在フレームだけじゃなくて何秒前まで意識しながら推論できるかみたいなファクターがあるんですが、より長い文脈を加味した推論ができるように変えていくといったところもあるかなと思います。

次はセンサ拡張で、まずは単純にカメラ数を増やすということがあるかなと思っていて、今フロントカメラ・1カメラでやっていましたが、左右のカメラや後方のカメラを追加していく。あるいは単純に追加するだけだとモデルのトレーニング時間や推論時間が大きくなってしまうので、それを抑えるための高速化を検討していくといったことも活動の一部になっていくかなと思います。

そして言語的な能力を活かすという観点でも改良できるかなと思っていましてCoTなど、LLMの世界にある人間らしい思考をこの運転の中でより明示的に発揮させる、そういった設計も効くかなという風に思っていたりします。

final_034_078m00s

加藤:次はVLMモデルのアップデートについてです。今回利用した「Heron-NVILA」という我々のVLMモデルは、イメージエンコーダとして448×448pxの画像を入力するという方式が主流でした。高解像度の画像を入力したい時はこの448×448の正方形のタイルを複数入力できるような仕組みになっていたんですが、扱いたい画像のサイズが長方形になっている時などにちょっと設計の柔軟性に欠けるといったところがありました。

この「SigLIP 1」と呼ばれていた方式の業界標準がありましたが、最近「SigLIP 2」というより進んだビジョンエンコーダーが出てきまして、動画を任意の解像度で入力して、しかもVLMとしてもちゃんとパフォーマンスが出せるという方式が出てきています。「Qwen3-VL」というVLMもこのSigLIP 2を採用していったりします。こういったものを我々のVLA自動運転にも取り入れていくと、ベースの性能が向上すると同時に設計の柔軟性も向上していくというところで非常にいいことかなと思います。

加藤:最後はより賢いモデルで小さいモデルを育てるというアプローチです。今回2Bのモデルを実車で動かして100ms未満で推論させてリアルタイムで車を動かすというのはかなりすごいことかなと思うんですが、最初の方にお話しした通り2BのモデルもLLMやVLMの最先端のものとしてはパラメータ数がもはや小さいサイズのものになってきていまして、どうしても賢さにも限界があるかなというところがあります。

そこで、実車に搭載できないサイズの大規模モデルをも学習するということに取り組んでいきたいと思っていまして、Alpamayoとの比較で8Bのモデルを学習しましたが、やはりパラメータを大きくすると賢くなるというところがあります。8Bとか30B程度の大規模モデルを学習しますと、2Bのものと比べるとはるかに高い理解力や推論力を持っているだろうということが期待されます。そしてこれを作ったらどう使うかと言いますと、Teacher・Studentのパターンと呼ばれる使い方が色々知られていまして、最も有名なのは「蒸留(Distillation)」と呼ばれる技術があります。これは、収集したデータを単純に軽量のモデルで学習するというアプローチじゃなくて、このティーチャーモデルに1回推論させて、その出力をGTにして、軽量なモデル、スチューデントモデルをトレーニングするというものです。これを行うと普通にモデルをトレーニングするよりもより良い推論結果が得られるという方式が知られています。

こういったアプローチはVLA研究ではかなりスタンダードなテクニックの1つになっていまして、最近の研究でもこのティーチャーモデルを作ってその知識をスチューデントモデル・よりパラメータの小さいモデルに移していくというアプローチはVLAのロボティクスの研究などでもよく使われているので、そういったテクニックを取り入れていくということも進めていきたいと考えています。

山口:非常にこのVLA開発どういう思想あるいはどういう流れでやられているかというところがよく理解できたかなと思います。やはり我々のDriveHeronというのは、元々マルチモーダルモデルを作っていて、それの最終形としてこういう風になったらいいねというところがより具体的に実現したというのがここ最近の開発の成果なのかなという風に思っています。NVIDIAのAlpamayoとかとの比較もありましたけれども、これからこのVLAが自動運転でもどんどん会社が作っていって発信もされていくのかなという風に思っていますので、我々もそれに負けないように作っていきたいですね。

Q&A一覧(一部抜粋)

以降は視聴者のQAに回答していきました。詳しくは動画をご覧ください。

  • 自動運転用データで追加学習することで、元々の言語能力(認識能力)が失われないでしょうか?
  • 回帰ヘッドは多峰性に対応が難しいのでは?
  • NVIDIAのVLAモデルと比較評価するにあたって、どのような前処理の工夫が必要でしたか?
  • クローズドコースで検証したアクション(右カーブ・左カーブ等)はどんな順序・基準で選んだのですか?

チューリングでは、完全自動運転の技術を共に創る仲間を募集しています。今日お話しした基盤AIチームはもちろんのこと、機械学習エンジニア、リサーチャー、ソフトウェアエンジニア、組み込みエンジニア、インフラエンジニアなど、非常に幅広いエンジニア職種で仲間を募集しています。ご興味のある方は、ぜひ採用ページをご確認ください。多様な職種がありますので、ご自身がどれに当てはまるか、ぜひチェックしてみてください。

技術の外側のすべてが、自分の仕事ーCxO直下で、誰も正解を知らない問いに向き合い続けるチューリングの事業開発。

この記事に登場する人
事業開発部 ビジネスチーム
亀川 翔 Sho Kamekawa
2018年大阪大学法学部卒業。Speee、Medleyを経て2024年3月チューリング入社。国家プロジェクト(GENIAC/DTSU)の申請・運用、OEM・Tier1パートナーとの事業提携交渉、政府・自治体との渉外対応を担う。

完全自動運転社会の実現に必要なのは、優れたAIだけではない。規制・資金・パートナーシップ・社会的合意——技術が完成しても、その外側が整わなければ自動運転車は社会に普及しない。その「技術の外側のすべて」を担うのが、チューリングの事業開発チームです。大阪大学法学部出身、SaaSと医療の事業開発を経てチューリングに入社した亀川さんに、この仕事の本質と面白さを聞きました。

「必要な取り組みをすべてやる」組織

ーーチューリングの事業開発チームの仕事は、一言で言うとどんな仕事ですか?

一言で言うと、チューリングが取り組んでいる自動運転の技術を社会に届けていく、あるいは事業として実現させていくために「必要な取り組みを全てやる」という組織ですね。

ーー世の中の事業開発と比べて、チューリングの事業開発が特徴的なところはどこでしょうか?

現在チューリングが取り組んでいる完全自動運転はまだ誰も成し遂げていない難しいチャレンジで、いわゆる「ディープテックスタートアップ」という分類に入る取り組みかなと思っています。

一般的な事業開発と違うところで言うと、技術開発のために必要な資金がかなり多いので、使った資金に見合う規模——大きな規模の事業を立ち上げなきゃいけないというところが一つ特徴になっています。自動運転を開発する中で様々な要素技術が生まれていって、それでビジネスをしようとか収益化をしたいと思うこともあるんですけど、頂いている資金に見合った事業を作るためには、より長期的で、かつ大きな規模の成功を実現する必要があります。

ーー「技術の外側の全てを担う」というのは、具体的にはどういうことでしょうか?

大きく分けると2つの側面があると思っています。一つは技術を開発するために必要なリソースを外側から持ってくること。もう一つは、作っている技術を外にアピールすることです。必要な資金を集めてきたり、必要なパートナー企業様とのご契約を結んだりといった、外部とのやり取りを全て事業開発が担う——そういう意味合いです。

入社直後、仕事がなかった2週間

ーー入社後、比較的早い段階で重要なプロジェクトを任されたと伺っています。どのような点を評価いただいたと感じますか?

実は入社して早々は、仕事がない日々が2週間ぐらいありまして・・・(笑)。元々は私も営業経験があったので営業するつもりで入社したのですが、会社が自動運転EVの量産から自動運転AIの開発に事業をピボットをする中で売るものがないという時期がありました。

評価していただいたというか、その時に僕が頑張ってたのは、こういう変化の中でもネガティブに考えずに「自分ができることをその中から見つけていこう」って取り組んだところが1つ。そこから経営陣にも「安心して何でも任せられる」っていう風に思っていただいたところかなと思っています。最初はエンジニアに「作って欲しい」って言われてる地図をマウスで手書きしながらアノテーションして納品して、エンジニアにダメ出しされるみたいなのが入社して最初の1ヶ月目にあって。「事業開発というか、営業で来たんだけどな」みたいな思いを抱えながらも、その中でやれることを見つけていったら、どんどん任せてもらえる仕事も大きくなっていきました。

自分から「こういうことやってみたらどうか」という提案が通って実現できたこともあったりするので、能力というよりはそういった「姿勢」を評価していただいたのかなと思います。

ーーこれまでのご経歴の中で、一見この領域と関係なさそうに見える経験が今の仕事に生きていると感じる瞬間はありますか?

「ある意味分からなくても図々しく前に進む」というか、分からないなりにそれでも進めていくというところは、昔別の会社で新規事業立ち上げなどをやっていた時と同じようなことがあって。分からないことに対して知ってるふりをせずに、知ってる人に対して素直に聞きに行ったりとか、「これが正解かどうか分からないけど、とりあえずアクションしてみよう」という姿勢は前職での経験が生きていますね。

自動運転も正直、入社した時はさっぱり分からない状態だったのですが、とにかく分かる人に対して図々しく色々聞きながら、それでも分からないことはある中で「とりあえず前に進んでみて、間違ってたら修正する」という繰り返しです。そこは過去の経験がすごく生きたかなと思います。

「調整」ではなく、「判断」する仕事

ーーこの仕事は「単なる渉外や調整ではない」と求人に記載がありますが、どこが一番違うと思いますか?

自動運転というフィールドにおいては、まだ誰も正解を見つけられていないんですよね。それは技術開発の部分でもそうですし、事業開発の面でも「まだこれが正解」というものはないので、基本は試行錯誤しながら見つけていくということが必要な領域です。

なので、何か決まり切った調整業務などがあるわけではなくて、基本的には「誰もまだ実現していないところに対して、分からないなりに判断をして進んでいく」。そういうことが必要なポジションかなと思っています。

“分からないなりに判断をして進んでいく——それが、正解のない領域で仕事をするということ。”

「東京でいい感じの工場を探してきて」——無茶ぶりが日常の現場

ーーこの事業開発という仕事の面白さはどこにありますか?

面白いところであり難しいところでもあるんですが、経営陣から結構無茶ぶりがたくさん飛んでくるというところかなと思っていて(笑)。例えばチューリングの本社があって今まさに撮影しているこの「東京流通センター」も、入社して数ヶ月ぐらいの時にCEOから「東京でいい感じの工場探してきて」みたいに言われて(笑)。

工場探しなんてしたこともないし、工場で働いたこともなかったんですけど、とにかくいろんな仲介業者さんに連絡をして何件も回って、やっと見つけた場所だったりします。その時には方針が変更になり、結局入居しなかったのですが、その半年後に移転することになりました。

そういった業務もありますし、もちろんチューリングが技術開発する上では何百億という単位での資金が必要になってくるので、そういった資金を集めていくための座組みを作ったり、パートナー企業様との連携を深めたり、投資家と対話したりとか。そういったすごく難易度高い仕事にチャレンジできるところも面白さですし、やりがいを感じられるところかなと思います。

「素敵な勘違い」が、人を動かす

ーーこの仕事を通じてどのような成長やキャリアの広がりが得られると思いますか?

よくCEOの山本一成さんが言う「素敵な勘違い」という言葉が僕はすごい好きで、その言葉のおかげで色んな機会を得て成長できたなって感じています。

僕自身、大学時代は法学部で、チューリングに入る前はSaaSの営業したり人材紹介の事業したりとか、全然ディープテックや自動運転には無縁な業界だったんですね。もし僕がCEOの立場だったら、あまり任せられないというか——経験もないので、そういう考えもあるかとは思うんですけど、一成さんはそこを全く考慮せずに難しい仕事をバンバン依頼してきます。

昔の自分だったら結構そこで「自分ではできないかもしれない」って制限を設けてたかもしれないんですけど、今はある意味自分を勘違いさせるというか、「いや、これできるかも」って自然と思うようになってきて。もちろん失敗もたくさんあります。いいところだけではないんですけど、いい面の方がすごいやっぱり多かったなと思って、この2年間(3年目になるんですけど)すごく成長したなと感じます。

「自分ではできないかもしれない」と制限を設けていた昔の自分が、今は「いや、これできるかも」と自然と思うようになってきた。

来てほしい人——変化に強く、好奇心が旺盛な人

ーーこの事業開発チーム、どんな人に来てほしいでしょうか?

事業開発は定常的な業務ももちろんあるんですが、経営陣からたくさん無茶ぶりのようなオーダーが飛んでくる環境です。基本的には決まっていない役割、定義されていない役割の中で働くことが前提になるので、とにかく変化に対応できるというか、「変化がむしろ好きな方」とか、変化がある中でも「タフに動いていただける方」に来てほしいなと思っています。

加えて、このチームでは、自分の担当範囲をきれいに区切って動くというよりも、必要だと思ったことに自分から手を伸ばして、責任を持って最後までやり遂げることが求められます。なので、「これは自分の仕事ではない」と線を引くのではなく、範囲を限定せずにチャレンジできる方、難しいことでも最後まで粘り強くやり切れる方と一緒に働きたいと思っています。

例えばマネジメントをしている立場で「いや、もっと自分もフロントに立っていきたい」という思いがあるベテランの方にも是非来ていただきたいと思ってますし、あるいは若いうちから裁量の大きな環境で難易度の高い仕事にチャレンジしていきたい――そういった方にも是非来ていただきたいなと思っております。

「毎日面白い」——それが、転職して一番よかったこと

ーー転職を考えている方にメッセージをお願いします。

僕自身、チューリングに入社してすごく良かったなと思っているんですけど、一番良かったなと思っているのは、成長したからとか色々ある中で、単純に「毎日面白い」というところです。経営陣の近くで色んな無茶ぶりをされるのもやっぱり面白いですし、僕自身変化が好きだし、新しい技術に触れるというのもすごい好きなタイプなので。

毎月チューリングにも新しい技術が生まれて使われて、「これ新しいな」と思ったら翌月にはみんな「あれはもう古いよ」って言ってたりとかして、すごく好奇心が掻き立てられるというか。そういう環境で、技術者ではないんですけど事業開発という立場で横で一緒に仕事できるというのが、本当に転職してしまうと「こんな環境ってどこにもないんだろうな」って思うぐらい面白くて。

ここは伝えるのが少し難しいんですけど、それだけでも入社してよかったなと思えるぐらいなので。是非、好奇心旺盛な方とか新しいものが好きな方は、多分もう来てしまうと「入社したくなる」って思っていただけるんじゃないかなと思います。

「毎日面白い」——それだけでも入社してよかったと思えるぐらい、こんな環境はどこにもないと思う。

CxO直下で、完全自動運転の
社会実装を前進させる。

このポジションに興味がある方はこちら

応募する

TuringTechTalk#38 E2E自動運転をスケールさせる ─ Tokyo30を支えたデータと学習のエコシステム

この記事に登場する人
CTO
山口 祐 Yu Yamaguchi
産業技術総合研究所 研究員/米国NIST客員研究員として研究する傍ら、独自にゲームAIの深層学習の開発を開始。日本の囲碁AIプロジェクトの開発代表として、最大1100GPUの並列分散強化学習を設計・開発し、世界大会準優勝、将棋AIでも世界大会優勝などの実績がある。HEROZ株式会社 執行役員を経て、2022年、チューリングに創業メンバーとして参画。2024年8月、CTO就任。基盤AIチームマネージャー兼任。
E2Eスケールアップチームリーダー
塩塚 大気 Daiki Shiotsuka
新卒でチューリングに創業メンバーとして参画。創業当初からEnd-to-End自動運転を実現するためにMLモデル開発・車両開発業務に従事。現在はEnd-to-End自動運転チームのシニアエンジニアとしてモデル開発・学習データの収集・マップ推定業務をリード。久留米高専、東京大学大学院卒。

はじめに

チューリングでは完全自動運転の実現に向けて、実世界で確実に動作するAI開発を追求しています。その一つの方向性として自動運転モデルをどのようにデータ・地域・車種に展開するかの開発を進めています。その中で重要なのが、走行データをどのように均質化させるかという問題です。昨年(2025年)に達成した東京都内30分間の無介入運転プロジェクト「Tokyo30」はどのように達成したのか。今回のテックトークでは、CTOの山口と、モデル開発・走行試験を担当したスケールアップチームの塩塚が登壇。自動運転を「スケール」させるポイントを深堀りします。

※本記事はTuringTechTalk#38の内容を元に一部編集してお届けします。

今回は「Tokyo30」達成の裏側に迫る

山口:皆さん、こんにちは。TuringTechTalk第38回「E2E自動運転をスケールさせる ─ Tokyo30を支えたデータと学習のエコシステム」を開始したいと思います。今日はE2Eスケールアップチームのチームリーダーの塩塚さんをお招きしております。塩塚さん、よろしくお願いします。

塩塚:よろしくお願いします。

山口:塩塚さんはTechTalkに2回目の登場になります。前回は地図を自動運転のためにどういう風に作っていくかというお話をしてもらいましたけれども、今回は毛色が変わってE2E自動運転モデルの話になります。

昨年我々チューリングは「Tokyo 30」という、東京都内を30分間無介入で運転するという長らく続けてきたプロジェクトを達成しました。実はその達成したモデルを作って、さらにそれを運転していたというのが塩塚さんのチームですよね。一番近いところで「Tokyo 30」達成の瞬間を見ていたというところで、今日はその達成の裏側に迫っていこうかなと思います。どうぞよろしくお願いします。

塩塚:よろしくお願いします。

山口:それでは早速始めていこうかなと思いますけれども、簡単に自己紹介をお願いします。

塩塚:はい。2021年に当時大学院の修士2年生だったんですけども、当時チューリングの社員数は代表の2名だけだったんですが、インターンとして参加して色々経験を積ませていただいて、そのまま新卒で2022年に横の山口さんと一緒に入社したという形になります。現在は、E2Eスケールアップチームのチームリーダーとして自動運転開発に取り組んでいます。

山口:チューリングの創業時からいるメンバーとして、私も同じタイミングでチューリングに入りましたので、同期入社という形になります。チューリングの最古参のうちの1人という形になりますね。まだ車もまともにないような状態の時代から、自動運転をどう作ってきたかといったところで、まさにチューリングの自動運転開発の生き字引と言ってもいいかもしれないということで、ちょっとその辺の話も今日は色々聞いておこうかなと思っております。

山口:今日の本題に入ります。「E2E自動運転モデル走行性能アップの取り組み」とありますけど、やっぱりE2E自動運転モデルって走行性能に差があったりするんですか?

塩塚:やっぱりかなり差がありますね。

山口:例えば、性能が低いモデルはどういう動きをしたりするんでしょうか?

塩塚:例えば、まっすぐな道を走るということはある程度モデルが上達していくと大体できるようになってくるんですけど、R(カーブの半径)がきついカーブとかはやっぱりモデルが習熟しないと厳しかったりします。あとは急な黄色信号で人間と同じようにちゃんと停止できるかといったところも、モデルが賢くないとなかなか難しいかなというところがありました。

山口:本当にモデル開発の最初期は「道をまっすぐ走るのも全然無理」みたいな話があってですね。これ結構皆さん想像できないかもしれないんですけれども、やっぱりE2Eモデルってモデルの形がシンプルですよね。カメラの入力があって、そこから車をどうコントロールするかというところを予測する、本当にこれだけですから。

そのコントロールの予測が本当に1度ずれるだけでも、100mもいらないですね、本当に数十mで全然車線をはみ出しちゃうみたいなことになっちゃうんですね。そうすると当然人間が安全のために介入するわけですけど、本当に最初は障害物がないところで運転をするんですけれども「いや全然まっすぐ走らんぞ」みたいな話が本当にあるんですね。

それがどういうプロセスを経て、本当に複雑な市街地走行、歩行者対応、そして長時間の無介入運転に繋がったかといったところを今日は色々聞いていこうかなと思ってます。

「Tokyo 30」達成映像を解説

山口:まずはこちらの動画をご覧ください。

山口:「Tokyo 30」達成時の動画ですね。ハンドルを触ってないのをご覧いただけると思いますけど、左折する時に歩行者をちゃんと待って行くところですね。所々倍速になっているのでスピーディですけど、実際にはもっと滑らかに曲がってますよね。

塩塚:そうですね、はい。

山口:こうして見ると路上駐車とかも結構上手く避けてますよね。

塩塚:そうですね。路上駐車避けは最初はなかなか難しかったんですけど、モデルが賢くなっていくと、特に道幅が狭い時に前の車と反対車線の車を見ながら安全な時に追い越しをしていくみたいなところは、モデルが賢くなると出てきた現象でしたね。

山口:対向車が来てすれ違わなきゃいけない時に、両サイドに路上駐車がいたりすると片側交互通行しないといけない。そうすると相手と呼吸を合わせながらやらないといけないけど、このモデルはそういうことができるんですか?

塩塚:これはできますね。

山口:信号で止まった場面を見たかなと思うんですけど、結構遠くの信号でもかなり正確に反応します。で、信号を間違えることもないですよね。

塩塚:ほぼ無いですね。

山口:この辺の大通りだと矢印信号が東京都内ではすごくたくさんあるんですけれども、これも相当正確に認識してますよね。信号って我々のE2Eモデルは明示的に学習しているんでしょうか?

塩塚:いや、学習してないんですよね。

山口:だけど「止まる」、「進む」が判断できている、これなんでなんですか?

塩塚:とにかくデータをたくさん学習させるっていうところが効いたかなと思ってまして、データ数が少ない時は「赤信号と青ぐらいは分かるかな、でも矢印信号は結構間違えるな」みたいなところが課題としてあったんですけど、そこで別に信号機を検出するみたいなことはやらずに、学習データ数を増やすということをやり続けると、あらゆる信号に対してロバスト(堅牢)になったというところがありました。

山口:やっぱりE2Eモデルはシンプルなので、何で性能を上げるかというとデータってことですね。今日のテーマもそうですが、データのクオリティをどう上げていか、どういうデータを学習させるか、どういう分量でスケールさせていくか、データのスケーラビリティといったところがE2E自動運転の鍵だったということですね。

山口:動画内で運転席に座っているのが塩塚さんですが、走行時間が30分超えた時はどういう気持ちでした?

塩塚:もちろんすごく嬉しかったですね。普段例えば10分とかしかできなくてたまたま30分できたとかじゃなくて、普段の実験から計測してない時とかは30分超えてたりとか実はしていたりして、この撮影はお昼過ぎぐらいに撮ってるんですけど、午前中にもほとんど30分近いものを走っていましたね。

山口:奇跡のワンショットが撮れたわけではなくて、もう日常的に「このくらいだったらまあできるよ」みたいなぐらいにはもう仕上がっていたというわけですね。

塩塚:撮影していない時でも何回達成はしていたので、この時も「撮れたね、帰ろう」といった感じでしたね。

山口:チューリングが2024年から「Tokyo 30」という東京都内を30分間無介入で運転するE2Eモデルを作りましょうというところを目指していたわけですけれども、この達成時の映像が昨年(2025年)の11月末ですので、まだ数ヶ月しか経っておりませんけども、そこから我々もさらに進化しているということですね。

E2Eスケールアップチームについて:スケールアップの難しさとは?

山口:今日はE2Eスケールアップチームのチームリーダーとして出てもらっているわけなんですけれども、このチームについてちょっと簡単に教えてもらえますか?

塩塚:「Tokyo 30」は1つのチームだけで作ったプロジェクトではなくて、会社全体で取り組んだプロジェクトになるんですけれども、その中で自分のチームと関わりが深いところが今4チームあります。まず一番上に「E2E先行開発チーム」がありまして、ベースのモデルや制御のところを作ってくれて、シンプルな条件でモデルや制御の開発をしていきます。「E2Eスケールアップチーム」はその技術を受け取って、データをスケールさせる(規模を拡大する)ところをメインに取り組んでいます。

その後は、そのモデルをRL(Reinforcement Learning:強化学習)をやっている「RLチーム」に渡したりして、さらに自動運転の性能を上げるというところをこの3チームでバトンを渡すような形で開発しています。そして、その3チームのデータセットを作成したりとか、GPU(Graphics Processing Unit)の学習環境を整えてくれたりとか、そういったことをやっているチームが「MLOpsチーム」になっていて、こういった関係で「Tokyo 30」を一緒に作ったというところになります。

山口:「スケールアップ」とあるので色々規模を拡大していくイメージなんですけど、これ何をスケールアップするんですか?データっていうのは1つありますけど、データだけなんですか?

塩塚:まずはデータ収集の車ですね。シンプルに話すと、1台で学習するより10台、100台で学習した方が、モデルってデータが増えるほど賢くなるよねみたいなところがあると思うんですけど、そういったところに取り組んだのが分かりやすいところかなと思います。

山口:「スケールアップの難しさ」と書いてありますね。やりたいことは、たくさんの車でデータ収集してたくさんのデータで学習する。すごくシンプルで、最近のAIやLLMを中心に、スケーリング則(Scaling Law)というのがあって、パラメータサイズを大きくしますよ、データを大きくしますよ、トレーニング時間を長くしますよ、これで性能どんどん上がっていきますよっていうのがTransformer以降のモデルだとよく言われています。

自動車の場合はエッジで動かす関係があってパラメータサイズはあんまり大きくできないけど、データはいくらでも増やせる、とにかくデータを増やしたいですよね。増やしたら良さそうに見えますけど、なぜ難しいんですか?

塩塚:分かりやすいところで言うと2つ難しいところがありまして。1つは、ドライバーがそもそも複数いるので「運転ポリシーが違う」というのがありまして。運転って人によって全然違うものですよね。E2E自動運転なので人の運転をそのまま学習させるんですけど、あるドライバーはこの道でこういう運転をした、あるドライバーが同じ道を走った時に違うような運転をしたみたいなところがあると、モデルって迷っちゃうんですね。

塩塚:例えばこの図で言うと、あるドライバーさんが「二度踏み」をしていたみたいなところがありまして。これを学習してみると、一回止まったあとに、ちょっと発進して止まるみたいな変な挙動が起こるんですよね。

山口:普段車を運転してない人は「二度踏み」にピンと来ないですよね。車が赤信号とかで止まる、あるいは前に車が詰まっていて停車しなきゃいけないって時に普通はブレーキ踏みますよね。二回踏む理由ってなんでしょうか?

塩塚:停止時にG(加速度)がかからないように1回ブレーキを離して緩やかに止まる、みたいなのがあるんですけど、ドライバーさんが良かれと思って行ったことですが、それによってモデルが止まる直前に最後ちょっとだけ進む、みたいな意図してない挙動を出すことがありました。

山口:それ以外にもドライバーさんの癖みたいなのはあったりしますか?例えば停止線の位置のズレもありますか?

塩塚:ありました。面白かった挙動がありまして、停止線ピタピタの人と手前の人を混ぜて学習すると、最初停止位置の手前で止まって、その後「もうちょい前だろう」みたいにもう1回発進して止まる、みたいなことも起こっていました。大量にデータがあれば平均化されて良いところに行くのかもしれないですが、今のフェーズではデータをちゃんと均一化できるところは均一化する必要がありました。

山口:データを揃えるというのは、ソフトウェア的に後処理で軌跡を調整したりしたくなりますけど、物理で揃えたんですね。

塩塚:人工的にデータを修正する時期もあったんですけど、長期的には良いモデルにならないという教訓になりまして、人工的に修正するのではなく、人間のオリジナルデータを揃えに行こうという発想になりました。

もう一つの難しさとキャリブレーション

山口:ドライバーのデータを揃える話をしましたが、それ以外、例えば車はいじらなくて大丈夫なんですか?

塩塚:はい。車側もかなり頑張りました。

塩塚:左が車両Aに取り付けたフロント向きカメラ、真ん中が車両Bです。アルファードに同じような見た目になるように取り付けているんですが、車という大きなハードウェアの上にカメラを付けるので、取り付け誤差はどうしても発生します。右の画像は2台のカメラ映像を比較したもので、ライトの位置などを見るとズレが分かりやすいと思います。

山口:上の蛍光灯の位置が、車両Aと車両Bで色分けされていて、このくらいズレているのがよく分かりますね、ボンネットの位置も結構ズレてますよね。カメラ自体のズレもあるし、取り付け誤差もありますし、様々な要因がありますよね。

塩塚:ルールベースなら物体検出して距離さえ分かればよく、ここまで合わせる必要はないんですが、E2Eはカメラ入力のみなので、見え方をきちんと揃えることが非常に重要で、そこが難しかったポイントです。

山口:我々の自動運転がカメラベースであることが大きいですね。LiDARとHDマップがあれば、ここまで合わせ込まなくてもいいですが、LiDARは距離が取れますし、3次元マップと合わせると自己位置も取れるので、多少カメラセンサーがズレても調整が効きますよね。

でも我々はLiDARを車から外したので、カメラで頑張るしかない。カメラのズレ、レンズ歪み、収差などが影響して、モデルから見ると「こっちの車とこっちの車で違う、どっちが正しいんだ」となりますよね。最初に話題に出したまっすぐ走らない問題にも、センサー誤差が大きく影響していました。これ、どう解決したんですか?

塩塚:「キャリブレーション」という、センサーがどの位置に付いているかを計測する技術があります。カメラ配置が分かれば、それを補正して同じように見えるように合わせ込むことができるので、そういったことを開発しました。次のスライドがその結果ですね。

山口:前のスライドでは気づかなかったですが、端の柱がぐにゃっと曲がっていて、周辺部ほど歪んでいるってことですよね。画角の広いカメラですか?

塩塚:そうです。画角は120度あります。

山口:正確にはもう少し広いですが、FOVの規定は120度前後ですね。広角だと端が歪むので補正する必要がありますね。補正だけでなく、ズレ部分を合わせたり切り出しを工夫したりします。行列変換になるので、カメラモデルに詳しく補正できる人が物理的な補正も含めてやると、ピッタリ合わせられるということですね。

塩塚:ピッタリ合って気持ちいい図になってますね。

山口:これを全車両でやっていて、ピッタリ合うんですか?

塩塚:ピッタリ合ってます。合わないものも一部あるんですが、合わないものを検知してもう一回やり直して、ピッタリ合わせる作業をしています。

山口:車両ごとの違いによる課題が解消されることが期待されますよね。自動運転の話題ではあまり表に出にくいですが実はすごく重要な取り組みです。

山口:データをスケールさせる、データサイズをどんどん増やしていくというのは簡単のように見えて、実はそこにすごく様々な課題があります。それを1個1個丁寧に解消していって、その結果学習データを増やすことができて、一気に走行性能が上がったということですね。

塩塚:特に複雑な道路環境の時に対応できるようになったというところが一つ大きなところかなと思います。

プロジェクト達成を支えたエコシステムあれこれ

山口:データは具体的にどの地域を走って取っていたり、どのような分布になっているのでしょうか?

塩塚:「Tokyo 30」の動画はお台場・有明が多いので「そこだけで集めたの?」と聞かれがちですが、全くそんなことはなく、関東全域でデータを収集しています。

山口:静岡・山梨も一部入っていますね。千葉もほぼ1周してますし、都内だけでなく郊外も含まれているのは意外ですね。

塩塚有明・お台場エリアは学習データの2%程度で、98%はそれ以外の箇所で集めた学習データです。

山口:昔は検証で特定シチュエーションに過学習させることもありましたけど、今はやっていないですよね。満遍なく学習させ、色んな場所を運転できるようにしていまして、専門的に言うと「汎化」しているわけですね。

塩塚:右側のグラフは、取得データがどういった行動を持っているかを可視化したものです。速度・加速度などを数値的に見られるようにして、「このシーンが足りないから学習データに含めよう」「データを取りに行こう」など、モデルの性能向上に利用しています。

山口:車って意外とまっすぐしか走らないですよね。グラフで見ますと右左折シーンは全体の数%程度ですよね。取ってきたデータをそのままを全部入れるのではなく、分布を再配置して、モデルが上手く運転できる分布に調整している、この辺りがデータセントリックな工夫ですね。

山口:モデル開発の話に入ります。スライドはモデルの性能をどう測るかという話ですよね。「シナリオテスト」とありますが、どうテストしていますか?

塩塚:シナリオテストは、赤信号停止、右左折、横断歩行者待ち、Rが厳しいカーブなど、事前に用意したシナリオごとにモデルを推論させて評価します。赤〜青のグラデーションで、濃い青が良い性能です。新しいモデルを作ったらまずシナリオテストにかけ、真っ赤なら実験に持って行くのは危ないとなります。逆に真っ青なのに実験でおかしければ、モデル以外にバグがある可能性も分かります。実験に持って行ってはいけないモデルのフィルタと、走行期待値の事前把握という2つの目的で使っています。

山口:ざっくりと説明しますと、open-loopは録画データの中で評価するものですね。対してこのあと解説しますclosed-loopは、モデルが動くと周囲の映像も変わります。open-loopは軽量なので大量シナリオを高速評価できますね。実際の走行軌跡に対してどれくらいずれているかで評価するんですかね?

塩塚:そうですね。トラジェクトリ(軌跡)がどれだけズレたかでスコア化し、ヒートマップ表示しています。

山口:次のスライドがclosed-loopですね。これは実際の走行映像ではないですよね?

塩塚:はい。RLチームが開発している3D Gaussian Splattingという技術で3次元を構成し、その中でモデルを走らせます。closed-loopでモデルが動くと景色も変わるので、より実車に近い形になります。評価も、open-loopの後にこれを見てから実機に持って行っています。

山口:昔からゲームエンジンを使ったシミュレーターというのがありましたが、チューリングでは今は使ってないですよね?

塩塚:昔は使っていた時期もありましたね。現在はこちらの方がフォトリアリスティックなのですが、遠目に見たらまるで実写のようですよね。

山口:3D Gaussian Splattingの技術はチューリングが世界的にもかなり頑張っているのではと思いますね。走行データから全シーンに再構成をかけるようMLOps的にはなっていますね。社内では数万シーン規模のクローズループ環境があり、評価や強化学習ができるエコシステムが整っていて、「Tokyo 30」達成モデルも鍛えられてきたわけですね。詳細は前回のTech Talkで紹介していますので、こちらもぜひご覧ください。

人間の運転のような動きも。実際の走行動画を紹介。そして今後の目標は?

※配信では実際の走行動画を映像で紹介していますので、併せてご視聴ください。

山口:ここから先はおまけではないですが、自慢ですね。

塩塚:これは「複雑な状況下で待てる」とありますが、路駐を待ってますね。

山口:対向車が来るので待って、対向車が行ってから路駐を避けてる、これけっこう賢いですよね。遠くの車まで見てるんですかね?

塩塚:前からバスが来る場面でも1回待ってるんですよね。行ってから避けてます。

山口:対向車を見て「行ってから行く」判断をしているのは意味を理解していますよね。

塩塚:最初にこれができたときは結構感動しましたね。

山口:次は「unprotected right turn(保護されていない右折)」。右折待ちですね。信号が青になって右折するかと思いきや、対向車が来るのであまり行かないで、対向車を待てていますよね。

塩塚:このあとのシーンでも右折が3回ありますが、ちょっと顔を出してから行かないと対向車がわからない場面もありますね。

山口:対向車が来てるかが中央分離帯でカメラに映らない状況で、微妙に前に出て確認して「いない」と判断して行ったということですよね。人間でも免許を取る時に右折は難しいですけど、大通りの右折もスムーズに曲がれていますね。

塩塚:このモデルは左右・後方カメラも使っていまして、T字路で左から来る車をフロントだけで見えなくても別カメラで捉えて待ち、通り過ぎたら右折する、という動きもします。

山口:これはかなり人間っぽい動きをしていますよね。

山口:最後のスライドは「東京の交通ドメイン」。

塩塚:都内の方はお馴染みかもしれないですね。

山口:いわゆる“マリオカート”のような特殊小型車両ですかね。都内ですと意外と走ってますよね。学習データに多いわけではないですけど、ちゃんと手前で止まります。ルールベースですと車両認識が難しいですよね。E2Eだと車として扱い、車間距離を取りながら追従できるのは面白いですよね。

塩塚:遭遇すると面白いですね。自然に止まって発進していました。これは東京ならではですので紹介してみました。


Q&A一覧

以降は視聴者のQAに回答していきました。詳しくは動画をご覧ください。

  • 左折した時に交通誘導員がいた場面でモデルは状況の意味理解をしているのでしょうか?意味理解しているとしたら、どのように証明しているのでしょうか?
  • 二度踏みやかっくんブレーキの説明がありましたが、E2E開発をしていて、人の感性に合わないと言われがちな挙動はありますか?E2Eモデルを改善することに注力して、車両側アクチュエータ特性を変更することはやらないのでしょうか?
  • 歪補正は、特定の場所の特定の被写体に対して物理的にカメラの調整を行っているのですか?
  • Wayveのモデルと比べますと、今はどのレベルに来ているのでしょうか?
  • スケールアップにあたり、今後の課題はどのようなものがありますか?

チューリングでは、完全自動運転の技術を共に創る仲間を募集しています。今日お話ししたE2Eスケールアップチームはもちろんのこと、機械学習エンジニア、リサーチャー、ソフトウェアエンジニア、組み込みエンジニア、インフラエンジニアなど、非常に幅広いエンジニア職種で仲間を募集しています。ご興味のある方は、ぜひ採用ページをご確認ください。多様な職種がありますので、ご自身がどれに当てはまるか、ぜひチェックしてみてください。

TuringTechTalk#37 E2E自動運転モデル×強化学習 ─ 3DGSが支えるシミュレーション技術

この記事に登場する人
CTO
山口 祐 Yu Yamaguchi
産業技術総合研究所 研究員/米国NIST客員研究員として研究する傍ら、独自にゲームAIの深層学習の開発を開始。日本の囲碁AIプロジェクトの開発代表として、最大1100GPUの並列分散強化学習を設計・開発し、世界大会準優勝、将棋AIでも世界大会優勝などの実績がある。HEROZ株式会社 執行役員を経て、2022年、チューリングに創業メンバーとして参画。2024年8月、CTO就任。基盤AIチームマネージャー兼任。
RLチームリーダー
妹尾 卓磨 Takuma Seno
新卒でSony Researchに入社、社会人博士として慶應義塾大学でコンピュータサイエンスの博士号を取得。Sony Researchのシニアリサーチサイエンティストとして、Gran Turismo Sophyプロジェクトを牽引。人間を凌駕するゲームAI開発に貢献する。オフライン強化学習ライブラリ「d3rlpy」含め、オープンソース活動を行っており、国内外の主要学会での多数の受賞歴を持つ。

はじめに

チューリングでは完全自動運転の実現に向けて、実世界で確実に動作するAI開発を追求しています。その一つの方向性として強化学習の研究開発を推進しています。走行動画から道路シーンを三次元に再構成する3DGSを土台に、内製の車体ダイナミクスと組み合わせたクローズドループ環境で大規模な試行を回します。今回のテックトークでは、CTOの山口と、RLチームリーダーの妹尾が登壇。強化学習から3DGS、クローズドシミュレーションを行うための大規模パイプラインなどを深掘りしていきます。

※本記事はTuringTechTalk#37の内容を元に一部編集してお届けします。


チームとして独立できるほど熱い強化学習

山口:皆さん、こんにちは。TuringTechTalk第37回「E2E自動運転モデル×強化学習 3DGSが支えるシミュレーション技術」を始めていきたいと思います。本日はRLチームリーダーの妹尾さんをお招きして、強化学習について深掘りしていきたいと思います。妹尾さん、本日はよろしくお願いします。

妹尾:はい、よろしくお願いします。

山口:妹尾さんはTechTalk2回目の登壇になります。前回は、いわゆる「RLチーム」がまだなかった時期に来ていただいたのですが、今回はRL(Reinforcement Learning:強化学習)を専門に進めるチームがある状況です。強化学習をやるチームが独立するぐらい、今チューリングの中では強化学習が熱い、ということでもあります。本日はこのあたりをじっくり深掘りできればと思っております。簡単に自己紹介をお願いできますでしょうか。

妹尾:はい。私は去年(2025年)の7月にチューリングへ入社いたしました。それ以前はSony AI、Sony Researchに所属しており、「Gran Turismo Sophy(グランツーリスモ・ソフィー)」というプロジェクトに取り組んでおりました。これは『グランツーリスモ』というレースゲームにおいて、人類のトッププレイヤーにも勝てるレースAIを強化学習で学習する、という内容です。実際にトッププレイヤーの方々と対戦して勝利し、その成果が『Nature』に掲載されたり、さらに1年後にはPlayStation上で動く家庭用ゲーム機としては初の深層強化学習エージェントの製品化にも繋がったりと、さまざまなことに取り組みました。

その後「もっと面白いプロジェクトはないか」と探していたところチューリングと出会いまして、「デジタル世界で強化学習で車が走るのなら、現実世界でも走るはずだ」と考えて、チューリングで本当の車を走らせに来た、という形になります。

山口:ありがとうございます。「ゲームから現実へ」という流れですね。新しい場所で大活躍していただいています。本日はそんな妹尾さんに、実車=現実世界での強化学習がどうなっているのか、じっくり伺っていきます。

私自身も昔、囲碁や将棋などのゲームAIで深層学習/強化学習に取り組んでいました。AlphaGoや、弊社CEOの山本が以前開発していた将棋AIのPonanzaなども、強化学習の流れにあります。そうした背景も踏まえつつ、「自動運転では実際どうなのか」を聞いていければと思います。よろしくお願いします。

妹尾:よろしくお願いします。

山口:昨年12月に開催した「Turing AI DAY」で強化学習の紹介も行いましたが、今回はそこから数ヶ月経ってどうなっているのか、当時話せなかった裏側も含めて深掘りしていきます。

そもそも強化学習(RL)とは何か

妹尾:機械学習は大きく「教師あり学習」「教師なし学習」「強化学習」に分類される、と説明されることが多いです。「教師あり学習」は、インプットとそれに対する正解のアウトプットのセットが大量にありまして、例えば「この画像の正解は猫です」のように、インプットとアウトプットの関係を学習します。

一方で「強化学習」は、正解のアウトプットがなく、その代わりに「報酬」があります。「環境」と「エージェント」が相互作用しながら、エージェントが試行錯誤して「どうしたら報酬を最大化できるか」を探索して学習していきます。将棋の例で言えば、対局して勝てばプラスの報酬、負ければマイナスの報酬を受け取る、という形です。AlphaGoのように「トッププレイヤーに勝つ」など、教師ありでは正解ラベルが用意しにくい問題で、強化学習が使われることが多いです

山口:ポイントは、エージェント(AI)が環境の中で試行錯誤し、報酬で方向づけされながら賢くなる、ということですね。では、その「報酬」は具体的にどういうものが報酬になりますか?

妹尾:囲碁や将棋であれば、勝ったらプラス1、負けたらマイナス1のような信号です。レースゲームなら、例えば「ぶつかったらマイナス100」「速く進めば進んだ分だけプラスの大きい報酬がもらえる」など、設計できます。基本的には人が設計するものになります。

山口:エンジニアやリサーチャーが「この報酬設計なら良い行動が育つはずだ」と予想しながら設計して、設定後はエージェントが環境でサイクルを回して進化していくわけですね。GT Sophyの報酬設計について、直感的ではないものもありますか?

妹尾:あります。例えば接触(コンタクト)にはペナルティを入れていますが、特に「相手のリア(後方)に衝突する」ことは一番やってはいけない行為なので、その接触には非常に大きいペナルティがかかるように報酬関数を作り込んでいます。

山口:ゲーム自体は「ぶつかってはいけない」というルールではなく、ゴールラインを早いタイムで通過すればよいゲームですけど、それだけを目的にすると、相手を押し出したり、妨害したりする学習が出てきますよね。それはよろしくないので、実際のレーシングドライバーのスポーツマンシップに近い振る舞いになるように、報酬設計にルールや価値観を組み込むのが面白いところですね。ちなみにですが、もし衝突ペナルティを無くしたら、やはり速くなってしまうのでしょうか?

妹尾:はい。衝突のペナルティが無いと、ぶつかった方が自分に有利になるケースが出てきます。相手をコースアウトさせて抜く、などが学習されがちです。一度コースアウトすると復帰が大変なので、スピンさせたら勝ち、という形になってしまいます。

環境として利用する3DGSと、LiDARレスによる3DGS再構成技術

山口:では、自動運転で強化学習をする際に重要な「環境」をどうするか、という話に移ります。いまスライドにある「3D Gaussian Splatting(3DGS)」が、我々の環境になっている、という理解でよろしいでしょうか。3DGSについて教えてください。

妹尾:はい。ざっくり言うと、空間上に「Gaussian」という点(ボクセルに近いイメージ)を大量に配置し、それぞれが大きさや色を持っていて、これらを最適化することで元の画像を再現します。

我々の場合、元になる走行動画があり、その動画から3DGSを最適化していくと、3次元の空間が再現できます。元の走行軌道で視点移動すると非常にリアルな映像になりますし、空間として再現されるので、視点を自由に動かすこともできます。例えば曲がる代わりに直進させて衝突させる、といったことも可能です。2023年頃にフランスのInriaが発表して以来、爆発的に人気になり、3次元再構成のホットトピックになっています。

山口:NeRFと比較されることも多いですが、3DGSは「点」による再構成で、軽量にレンダリングできるのが強みです。点描のように打った点を3次元に分布させて、どこから見ても破綻しないようにする、という理解で合っていますか?

妹尾:はい、合っています。

山口:チューリングは3DGSにかなり力を入れていますよね。

妹尾:はい。RLチームもメンバーの多くがここに時間を割いています。加えて、以前は車両にLiDARがあり、LiDAR点群から3DGSを再構成していましたが、最近はLiDARがなくなりました。LiDARなしでも同じことができるような取り組みも進めています。

山口:補足すると、LiDARはレーザーで距離を測り、点群として空間を取得するセンサーです。一方で最近のE2E自動運転では、カメラがリッチな情報なので、AIが解釈できればLiDAR無しでもよい、という流れが強まっています。チューリングも最近、全ての車両からLiDARを外しています。その上で「Feedforward点群予測」、つまり画像を入力すると点群が出るモデルが重要になります。ここはどうでしょうか。

妹尾:はい。近年、特にここ1年で急速に進歩した分野です。最初にVGGTのような流れが出て、研究が盛んになりました。チューリングでも、画像だけから高精度な点群を予測できるレベルになってきています。LiDARが外れると3DGS的には困る、という懸念がありましたが、点群予測の進歩により、LiDARが無くても点群を作り、その点群から3DGSを学習できるようになってきました。

山口:Feedforward点群予測のメリットは「LiDAR不要」だけではなく、他にもありますか?

妹尾:難しい点は多いです。7カメラそれぞれで点群予測すると、カメラ間のスケールが合わない問題が出たり、時間方向でもスケールが揃わなかったりします。自動運転シーンで綺麗に点群予測するのは難易度が高いです。

一方でメリットとして、不思議なことに「見えていない部分の点群予測ができる」ことがあります。特に車両に関しては、見えていない面にも点がある、ということが起こります。LiDARだと見えない部分は絶対に取れませんが、点群予測では基盤モデルが「車はこういう形だろう」と補ってくれるので、見えていない部分にも点を置けることがあります。

山口:なるほど。LiDAR無しでも近づいている上に、LiDARでは得られない“補完”が起きることがあるわけですね。

クローズドループシミュレーション:絵を作るだけではシミュレーターにならない

妹尾:先ほどまでは3次元空間を再構成して、レンダリングした絵でシミュレーションを行う話をしましたが、実際にシミュレーションを行うには画を作るだけでなく、車の動きもシミュレーションする必要があります。

3DGSでレンダリングした画像を入力としてE2E自動運転モデルが運転操作(行動)を予測し、その予測に応じて車両を動かします。動いた先の絵をまたレンダリングし、サイクルを回すことで、初めてクローズドループシミュレーションになります。

山口:図の「Dynamics Simulation」というのはなんでしょうか?

妹尾:これはステア角やアクセル量に応じて車がどう動くか、という車の挙動の物理シミュレーションです。

山口:ここが厳密でないと、実車では走るモデルがシミュレーターだと走らない、などが起きますか?

妹尾:起きます。最初は絵のクオリティが問題でしたが、絵が綺麗になっても走らないことがあり、車体のシミュレーションが重要だと分かって改善しました。絵だけでは成立せず、挙動シミュレーションも重要です。

山口:ちなみに縦方向、段差や坂道はどうでしょうか?

妹尾:なかなかいい質問でして、結構難しいんですよね。本来は地面のメッシュが必要です。詳細は言えないのですが、現状は非常に原始的な方法でシミュレートしています。このあたりは挑戦領域で、シミュレーションに強い方がいらしたら、ぜひ遊びに来てほしいですね。

山口:E2Eモデルは私たちで作っていますが、3DGS・レンダリング・ダイナミクスまで、このあたりも内製ですよね。

妹尾:はい、完全内製です。3DGSもオープンソースは多いですが大規模運用には使い勝手が悪いものが多く、フルスクラッチでフレームワークを作っています。レンダリングは元々gsplatという有名なサードパーティーのソフトウェアがありますが、これも最近は手を加えていまして、レンダリングするためのCUDAカーネル部分にも手を入れてカスタム版gsplatを作っています。

山口:依存性を含めて内製化し、シミュレーターとして動くまで作り込んでいる会社は世界的にも多くないと思います。強化学習だけでなく評価にも使えるように磨かれているのは大きいですね。

大規模パイプライン:シーン検索、3DGS生成からモデル評価まで

山口:では実際に、3DGSをどう作っているのか、パイプラインを教えてください。

妹尾:はい。チューリングには大量の走行データがありますが、シミュレーションしたいのは特定のシーンであることが多いです。例えば右左折を検証したいなら、右左折に関係するシーンを検索してシミュレーションするわけですよね。

まずデータセットから所望のシーンを検索し、例えば「歩行者のいる右左折」などを抽出します。それをAWS Batchで並列に3DGSを学習します。100シーン、1000シーンを数時間で学習できます。学習した3DGSのシーンを使って、モデル評価や分散強化学習に使います。評価も、1モデルを100シーンで評価したいなら100並列で回して、10分程度で評価結果が得られます。最近はKubernetesベースへの移行も進めています。

山口:我々が取得しているデータセット全てに適用できる体制になってますよね。

妹尾:はい。ワンコマンドで学習もできますしモデルの評価もCLIで実行できます。

山口:1シーン作る際のコスト感はどうでしょうか。

妹尾:1000円はしないです。最近高速化が進んで数百円オーダーです。

山口:20秒程度のシーンで、新規視点をぐりぐり動かせるものが数百円のコストで作れますよね。数万〜場合によっては数十万、極端には100万シーンも、時間とお金があれば可能ということですね。そして分散強化学習側はRayを使っている、と。

妹尾:はい。Ray自体に強化学習の機能もありますが、我々は主に分散システムのフレームワークとして使っています。ワーカー間通信を隠蔽してくれるので、分散構成を作りやすいです。

山口:この規模のパイプライン、開発期間はどれくらいでしたか?

妹尾:基盤化はMLOpsチームとも協力しています。3DGS学習部分のパイプラインは、去年(2025年)の8月の終わり頃には出来ていて、モデル評価側も11月末頃には出来ています。

山口:妹尾さんの入社は7月ですから、そこから数ヶ月でここまで作っているのは驚異的なスピードですよね。

妹尾:チューリングがMLOps周りに強いことも大きいですね。

山口:モデル評価について聞いてみようと思います。これは評価の様子ですね。

妹尾:はい。上の映像は3DGS内でシミュレーションしている映像です。実車でも同じ場所を走ったことがあり、似た軌跡で走れていることが示せます。下は、モデルが苦手な状況を狙ってテストしている例です。待つべき状況で待てずにずるずる前に出てしまう、といった挙動も再現して評価できます。

山口:ここで重要なのは、周りの車や人が動いていることです。一般的な3DGSは静止シーンが多いですが、自動運転では動かないと検証になりません。ここは工夫しているのですよね。

妹尾:はい、特別な工夫をしています。さらに、Gaussianが最終表現としてあるので、編集もしやすいです。削除すれば車を消せますし、足せば出現させることもできますので、シーンの編集も容易です。

山口:最近はWaymoが動画編集用のモデルを使用して、実際の走行シーンに動物を出現させるデモを行なっていましたが、3DGS上でもGaussianを用意すれば同様にエッジケースを再現できる、ということですよね。

妹尾:そうですね。最近はBlenderなどのCG系のソフトウェアで3DGSのサポートが厚く、3DGS上に別アセットを置くこともやりやすくなっているので、キリンのアセットがあれば道路上にキリンを出すみたいなこともできます。

大規模分散強化学習:教師ありより“一気に複雑”になる理由

山口:強化学習のほうにも本題に入りまして、大規模分散強化学習基盤について教えてもらっていいですか。

妹尾:教師あり学習(模倣学習)は、データセットからデータを読み出して学習するだけなので構造はシンプルです。一方で分散強化学習は、シミュレーターを動かしながら学習データを集めます。大規模になるとシミュレーターを1つではなく多数動かしたくなります。

そのためにRayなどを使って、1つのGPUノード上で多数のシミュレーターを並列に動かします。加えて推論サーバーでモデル推論をさばき、データをバッファに集め、それをトレーナー側で学習します。複数のワーカーが非同期に動くのが特徴です。

山口:GPUの使い方としては、大きく「環境の再現(3DGSのレンダリング)」「推論」「学習」の3つに分かれるということですが、割合としてはどうでしょう。

妹尾:現状は、トレーナーノード1に対してenvノード(シミュレーター側)をたくさん割いています。3DGSは絵をレンダリングするので、昔のAtariのような軽いゲームに比べると1GPUあたりに並べられるシミュレーター数に限界があります。大量に並べるためにenv側を厚くしています。

山口:非同期構成はボトルネックが出やすいですが、全体が流れるように配分している、と。強化学習部分は基本的に妹尾さんが中心で実装されているのですね。

妹尾:はい。3DGSは私だけでなくチームメンバーも取り組んでいて、物理シミュレーションは荒居さんという別のメンバーが担当していますが、強化学習の分散構成は私が主にやっています。

山口:トレーナーが更新した重みは、推論側へどう配布していますか?

妹尾:右側にWeight Serverがあり、トレーナーが新しいパラメータを作るとそこに送ります。Forward Serverは定期的にWeight Serverを見に行って、新しいパラメータがあればそこから引っ張ってくるという形です。

強化学習の作例あれこれ

山口:では強化学習するとどうなるのか、作例を見ていこうと思います。「ファインチューニング」はどういう意味ですか?

妹尾:左が模倣学習モデルで、この右折シーンでは大回りになり、現車軌道から外れて早期終了しています。これを3DGSシミュレーション上で強化学習してファインチューニングすると、右のように綺麗に右折してレーンに入る動きを獲得できます。模倣学習だけだと走りながら学習していないので車両挙動の理解に限界があり、強化学習で「どう曲がればうまくいくか」を自分で獲得します

山口:強化学習はスクラッチでやるだけではなく、模倣学習モデルを最後に賢くする用途にも使える、ということですね。シミュレーター内だけでなく、公道でも動かしていますか?

妹尾:はい。前回のTechTalk時に「入社3ヶ月で公道に出たい」と言っていたのですが、実際に入社3ヶ月で公道に出ました。

山口:凄いですね。7月入社からまさに3ヶ月で東京都内の公道を走った、という最初の映像ですね。初走行のときは怖さもあったのではないでしょうか。

妹尾:怖さはあります。前日にCEOの山本さんに「明日公道に持っていきます」と伝えたら「引くのも勇気だからね」と言われました。ただ、私は「絶対に走るので大丈夫です」と確信して持って行きました。

山口:安全性が大前提なので、確信がないと公道テストに出せません。そこを突破したのは大きいです。その後どんどん進化していき、11月にはお台場へ進出し、他車交通や左折を含む環境での比較もしていますね。

妹尾:はい。左が模倣学習で、この時期は右折が苦手でぎこちない動きが出ます。一方で強化学習モデルでは右折も滑らかで、ライン取りも自然になります。

山口:モデルのアーキテクチャ自体は揃えていて、学習方法だけが違うんですよね。

妹尾:はい。LLMもベースのLLMを学習してRLファインチューニングして一部のパラメータだけを更新してより賢くするという方法を行うと思いますが、それと全く同じパラダイムです。

妹尾:12月にはさらに右左折性能が飛躍的に上がりまして、難しい状況も介入なしでこなせるようになってきました。

山口:対向車待ちの右折なども、かなり自然にできるようになってきましたよね。強化学習で鍛えられたからこそできるようになったということですね。さらに難しいシーンもできていると聞いています。

山口:ここは車内映像で少し見にくいですが、どういうシーンでしょうか。

妹尾:右折で大回りになってしまい、このまま行くと曲がり切れず、普通なら介入が必要な状況です。しかし強化学習モデルは復帰能力が非常に強く、エラー状態から元の経路に戻ろうとします。ここでは一旦止まり、ステアを右に切り直して進む、という挙動ができています。模倣学習ではほぼ見ない振る舞いです。もちろん公道では安全を確認し、後続車や歩行者がいない状況で検証しています。

山口:人間には自然に見えますが、自動運転では非常に難しい領域です。通常の走行データは「正常系」が多く、異常系から正常に戻るデータが少ないため、模倣学習だけでは復帰が苦手になりがちです。
強化学習ならシミュレーター内で無限に試行できるので、異常系から正常に戻す学習ができる、というポイントですね。

3DGSだけではない、世界モデルへの取り組み

山口:ここまでは3DGSの話がメインでしたが、3DGS以外のことも行なってたりするんですよね。

妹尾:はい。RLチームでは世界モデルにも取り組んでいます。ここでは「動画生成モデル」としての世界モデルです。絵を生成する世界モデルを開発しています。

山口:マルチカメラで4カメですが、かなり同期した生成ができていますね。

妹尾:3DGSはGaussianをレンダリングするのでマルチカメラ一貫性は作りやすいのですが、動画生成では強い制約がないと前と横で違うものが出る可能性があります。それでもここではかなり一貫性のある映像が生成できています。

山口:この世界モデルも最近アップデートしているみたいですね。

妹尾:はい。世界モデルをシミュレーターとして使うには、運転操作(指示)通りに動画が生成され続ける必要があります。ここではトラジェクトリ指定に応じて生成が変わることを示しています。停止指示なら進まない、といった挙動も含みます。

山口:3DGSと世界モデルの使い分けはどう考えていますか?

妹尾:基本は3DGSで多くの評価・強化学習ができますし、手軽に実データ由来のシーンを再現できます。一方で、走行動画として存在していないシーン(雨、夜など条件変化)や、3DGSの再構成範囲を超えるOut-of-Distributionな状況は、世界モデルのほうが得意です。天候だけ後から条件付けで変える、といったことも可能です。

山口:映像を見て気づいたのですが、ボンネットやフロントガラスの反射まで生成できていますね。

妹尾:はい。反射は動画生成モデルでは難しい要素ですが、横断歩道や車線の反射などが出ています。

山口:3DGSでボンネット反射を扱うのは大変なので、世界モデルは絵と物理の要素が一体になったEnd-to-Endシミュレーションとして別の強みがありますね。


Q&A一覧

以降は視聴者のQAに回答していきました。詳しくは動画をご覧ください。

  • エッジケースの評価が可能とのことでしたが、そもそも、どのようなエッジケースを想定するか、ということはどのような方法や考え方で行なっているのでしょうか?
  • 3DGSやVGGTを利用する強化学習において、報酬関数はどのように定義されますか?
  • 予測モデルの評価は何の値で行っていますか?
  • 3DGSは手動で直さなくても、アルゴリズムだけで自動運転のシミュレーションに十分なデータになるのでしょうか?
  • 3DGS上で既存の車に違う動きをさせたりする場合、穴になる部分や影だった部分の調整もしていますか?
  • カメラやイメージャー、センサーの種類が変わったときには同じシミュレーションのファイルが使用できると考えていますか?

チューリングでは、完全自動運転の技術を共に創る仲間を募集しています。今日お話ししたRLチームはもちろんのこと、機械学習エンジニア、リサーチャー、ソフトウェアエンジニア、組み込みエンジニア、インフラエンジニアなど、非常に幅広いエンジニア職種で仲間を募集しています。ご興味のある方は、ぜひ採用ページをご確認ください。多様な職種がありますので、ご自身がどれに当てはまるか、ぜひチェックしてみてください。

TuringTechTalk #36 「チューリングのインフラチームが描くーフィジカルAIのGPUクラスタ構想」

この記事に登場する人
CTO
山口 祐 Yu Yamaguchi
産業技術総合研究所 研究員/米国NIST客員研究員として研究する傍ら、独自にゲームAIの深層学習の開発を開始。日本の囲碁AIプロジェクトの開発代表として、最大1100GPUの並列分散強化学習を設計・開発し、世界大会準優勝、将棋AIでも世界大会優勝などの実績がある。HEROZ株式会社 執行役員を経て、2022年、チューリングに創業メンバーとして参画。2024年8月、CTO就任。基盤AIチームマネージャー兼任。
インフラチームリーダー
渡辺 晃平 Kohei Watanabe
高等専門学校で電子工学(半導体やレーザー)を学んだ後、新卒で大手通信会社に入社。新設されたクラウドサービス部で当時国内でも新しいクラウドサービスの開発に携わった後、サービス企画部門に異動し、クラウドサービス企画を担当しながら、複数のGPUクラスター案件を担当。その後、外資系ストレージベンダに転職し、ストレージ技術を学んだ後、チューリングに入社。
インフラチーム シニアエンジニア
深澤 開 Kai Fukazawa
2013年にヤフー(現:LINEヤフー)へ新卒入社し、大規模Hadoop基盤(最大70PB)の設計・構築・運用に従事。 データセンターネットワークやGPUクラスタ向けネットワークの設計・構築や米国子会社へ出向し、 米国データセンターの立ち上げや大規模分散処理基盤向けのインフラ設計・構築・運用も担当。 そのほか、バックボーンネットワーク統合プロジェクトのマネジメントなどを経験し、グローバルかつ横断的なインフラ運用を推進。チューリングでは大規模計算基盤を担当し、世界で戦える高効率な計算インフラの実現を目指す。

はじめに

チューリングでは、2022年当時ほぼGPUゼロからの増強を重ね、オンプレミスGPUクラスタ「Gaggle Cluster」の構築など、2025年12月時点で初期比約8倍の計算力を常時運用しています。現在のE2E自動運転モデルは学習データを増やすほど素直に性能が伸びるフェーズにあり、「GPUがあるだけ使い切る」状況です。今回のテックトークでは、CTOの山口と、2026年1月に組成されたばかりのインフラチームより、チームリーダーの渡辺とシニアエンジニアの深澤が登壇。AI DAYで発表した次のGPUクラスタ構想の詳細や、その課題などを掘り下げます。

※本記事はTuringTechTalk#36の内容を元に一部編集してお届けします。

現在進行形で進むインフラ整備

山口:皆さんこんにちは。CTOの山口です。今回は「チューリングのインフラチームが描くーフィジカルAIのGPUクラスタ構想」と題しまして、チューリングが現在使っている、あるいは今後作ろうとしているGPU基盤を、どのようにしていくのかという点について、インフラチームの2人、渡辺さん、深澤さんに伺っていこうと思います。渡辺さん、深澤さん、本日はよろしくお願いします。

渡辺・深澤:よろしくお願いします。

山口:インフラチームは2026年1月から立ち上がりまして、本格的に次の大きなインフラをどう整備していくかというところを、まさに今進めている状況です。

渡辺さんと深澤さんのお二人に共通しているのは、大型のGPUクラスタを、かなりベースのところから構築してきた経験がある点だと思います。インフラエンジニアは、ネットワーク専門、ストレージ専門、サーバー専門、あるいは物理側など、会社規模が大きいほど分担されがちですが、お二人は全体も触りながら進めてこられたという印象があります。そのような経験をお持ちのお二人が、今チューリングで何を考えながら仕事をされているのか、今日は色々と伺っていこうと思います。

山口:今日のテーマにあります「次期GPU計算基盤」ですが、正直どこまで話せるかは難しい問題がありますので、話せる範囲でお話しします。

渡辺:レイヤーが上から下まで多岐にわたり、関係者も多いですし、お金の話もモノとしての話も含めて、多くの方と相談しながら検討を進めている段階です。そのため、ここで話せる情報と、ジェネリックにイメージが持てる課題感とかはお話しできればと思っています。

山口:ご存じない方に補足しますと、2025年12月に「Turing AI DAY」というイベントを開催し、AI開発に関する最先端の情報をお伝えしました。その場で「GPUを次どうするのか」という話もさせていただき、報道などにも採用していただきました。

結局、我々は自動運転、とりわけ世界のプレイヤーと戦っていくためにGPUを増やしていく必要があり、AI DAYでは「とにかく(GPUを)増やしていく」という話をしました。ただ、当時は抽象度が高く、解像度としては「増やす」という話に留まっていたと思います。今日はインフラエンジニアのお二人をお呼びして、より具体的なところを深掘りする回です。

現行のGPUクラスタとGaggle Clusterについて

山口:まず、我々がGPUクラスタをどのように用意しているか、というところから見ていきたいと思います。

渡辺:ちょうど私が2024年3月頃にチューリングにジョインしたタイミングで、最初に作ったクラスタがあります。NTTPCコミュニケーションズさんにご協力いただいて作った、チューリングとして初めての自社専用基盤「Gaggle Cluster」です。当時はH200が出回り始めたぐらいのタイミングでしたので、GPUはH100を採用し、96基の規模でした。

渡辺:また、ストレージとネットワークが特徴で、ストレージは1PB、想定性能値としては100GB/s程度のスループットを持っています。当時のインターコネクトで最速クラスの400GB/sで、GPU間通信として400Gbpsを捌けるInfiniBandを採用して構築しました。これが現在稼働していて、MLエンジニアが日常的に使っている状況です。

山口:非常に安定して動いていまして、1年4か月ほど稼働していますが、大きな問題はほとんどありません。もちろん、たまに不具合が発生して止まることはありますが、その場合も交換対応を行い、復旧できています。かなり快適に使える、チューリングとしても自慢できるクラスタだと思っています。深澤さんも、入社されて早い段階から交換対応などを担当してもらっていますよね。

深澤:そうですね。入社したのが(2025年の)12月だったのですが、ちょうど年末前後で、インフラではよくある「いくつか同時に問題が起きる」タイミングに当たってしまったのか、入社してからはずっと面倒を見てまして…。

渡辺:ノードのGPU交換を何度か対応してくれましたよね。

山口:これは不思議なのですが、納品してしばらくは調子が良いのに、一定期間経つと同じタイミングで複数の機器が調子を崩すことがありますよね。インフラではよくある話でしょうか。

深澤:あるあるですよね。理由が明確に分かるわけではないのですが、経験上、よく起きます。

渡辺:一般的には「バスタブ曲線」と呼ばれていますね。納品直後に初期故障が集中する期間があり、その後は安定期に入りますけど、製品によっては1年後、2年後、3年後といったタイミングで、同じ時期に導入したパーツがまとめて故障し始めることがあります。

これは製品不良というより、仕様や特性上、そういったタイミングが存在するという理解ですよね。ネットワークでもストレージでもサーバーでも、どのレイヤーでも結構あるあるな話ですね。

山口:GPUの場合ですと、意図的に高負荷をかけて不具合を炙り出すこともありますよね。

渡辺:バーンインテストみたいな感じですよね。

山口:本当に火が出るのではないかというくらいの熱と電力を使いますが、チューリングのクラスタでも最初にそれを実施しました。その後しばらく安定していましたが、最近になって交換が必要なタイミングが徐々に出てきている、という状況ですよね。

深澤:ただ年明け以降は比較的安定しているので、ひとまずその波は落ち着いたのかなと感じています。 

山口:改めて構成を整理しますと、H100を96枚、12ノード構成で、ストレージは1PB、インターコネクトはNDRの400Gbps、InfiniBandで組んでるという感じです。

山口:このクラスタが完成・稼働したのは2024年10月頃でしたね。

渡辺:そうですね。8月から10月にかけて動き始めたという形です。

山口:それ以前、実は我々はGPUをほとんど使えていませんでした。こちらのグラフは、我々が使ってきた計算性能をFLOPS単位で大まかにプロットしたものです。2022年頃、私が入社した当時は、ほぼゼロでした。創業期で、まだ会社員もほとんどいない時期でした。

当時は、AIを作らなければならないのにGPUがない。さらに資金調達も10億円程度で、オンプレミスのGPUクラスタを作るキャッシュがそもそもない、という状況でした。

そこから最初に計算資源が増えたきっかけが「GENIAC」です。経済産業省やNEDOが提供している、生成AI開発を支援するプロジェクトで、我々は第1期から第3期まで連続で採択していただいています。GENIACでは、GPUの計算資源を期間限定で使わせてもらうことができました。ただこのときはクラウドGPUを借りて使わせていただいていました。

この支援によって良い成果は出たのですが、自動運転を本格的にやるには、明らかにGPUが足りないという結論になりました。そこで作ったのが、先ほど説明したオンプレミスのGaggle Clusterです。

2024年10月にGaggle Clusterを導入し、計算性能はそれまでの3〜4倍程度になりました。当時は「これだけあれば大丈夫だろう」という話をしていましたね。

渡辺:この当時でも相当贅沢な計算容量でしたね。

山口:当時、機械学習エンジニアも5人ぐらいだったんですよね。GPUが96枚もあれば1年は持つだろう、と思っていました。ところが、実際には3日ほどで「もう足りんぞ」と…。当時悲しかった思い出がありますが、それだけ我々のGPU需要が大きいということでもあります。その結果、「これはどんどん増やしていかないといけない」という判断になりました。

山口:そして今はどうなっているかといいますと、2025年12月時点の情報ですが、Gaggle Cluster換算で、オンプレミスとクラウドを合わせて約8倍のGPU計算資源を使用しています。

Gaggle Clusterの8倍と言っても分かりづらいと思いますので、具体例として、日本のスーパーコンピューター「富岳」と比較します。富岳のAI演算性能(FP16・ノンスパースの場合)の約40%に相当する規模です。

渡辺:「富岳」はAI用途特化ではありませんが、こうして言われると規模感としてはかなり大きいですね。

山口:スタートアップとして、自己資金を中心にここまで計算資源を確保しているのは、かなり頑張っているほうだと思っています。

深澤:私が2025年12月に入社した時点で、すでにこの規模のGPUがあったので、渡辺さん一人でここまで支えてきたのは本当にすごいと思いました。

山口:渡辺さんは2024年3月入社で、Gaggle Cluster構築が最初の仕事でしたが、その後もオンプレとクラウドをほぼ一人で切り盛りして、最近深澤さんが加わり、ようやく分担できるようになってきました。

渡辺:先日社内ブログも出ていましたが、MLOpsチームがクラウド側で運用や組み込み側を進めてくれたことで、スケールできた部分も大きいです。インフラチームだけでなく、MLOps側も計算リソースの重要性を理解してくれていたのが大きいです。会社全体で計算基盤を重視しているという背景がありますね。

今後どうするのか:AI DAYで示した方向性

山口:では、「今後どうするのか」という本題に入ります。とにかく我々、自動運転が着実に進化してきているんですよね。AI DAYのタイミングではTokyo30を達成した時期でした。

これまでの自動運転モデルは、計算資源が増えても、必ずしも性能が素直に伸びる状況ではなく苦労していた、というのは最近のTechTalkでもお話ししていたかと思います。それが最近では、データとGPUがあればあるほど性能が伸びるフェーズに入ってきています。

渡辺:これは良い面もあれば、課題もあります。ですが、これまで2年ほど計算リソースを集め、スケールさせてきた結果、きちんと成果が出てきたという点は、大きなマイルストーンだと思っています。

山口:正直に言うと、スタートアップとしてこれほどGPUに投資するというのは…。

深澤:聞いたことがないですよね。

山口:一般的には優れた経営判断とは言われない部分もありますよね。しかし、我々が目指している高度な自動運転を実現するためには、どうしても必要な投資だと考えています。

山口:では今後どうするのかという話ですが、現在「富岳」の約40%ほどある計算性能を、今後2年で5〜10倍に増やす、というのが我々の目標です。FLOPSで言うと、現在は約0.7EFLOPS(FP16・ノンスパース)ですが、これを5〜10倍なので、3.5〜7EFLOPS規模にしていきます。オンプレミスとクラウドを組み合わせて進める想定です。まあ結構な規模ですよね。

渡辺:結構な量というレベルじゃないですね。

山口:これまでの傾向を見ると、計算性能は1年で2倍以上のペースで増えています。とにかくGPUを使い、どんどん学習し、良いモデルを作るというのが我々の基本方針です。

次期GPU基盤の設計思想と3つのポイント

山口:ここからは、GPUクラスタの具体的な設計思想について触れていきましょう。大きく3つのポイントがありますが、渡辺さん、このポイントについて説明をお願いできますか。

渡辺:はい。オンプレミスやクラウドで作るという状況で運用してくると、この辺が苦しいよね、というポイントが見えてくるんですよね。大きく3つのポイントに分けることができます。

1つ目は量を確保すること、GPUをどれだけ多く確保するかです。当然無駄なリソースが多く存在しても仕方がないので、CPUやローカルメモリ、ストレージを必要以上に盛らず、できるだけ多くのGPUを打てるように目指しています。

2つ目はインターコネクトです。GPU間通信は大規模なモデル学習、もしくは学習してるモデルを並列で計算して早くモデル学習を完了させる、この2つの目的で使うという意味合いでインターコネクトは非常に重要で、現時点ではGPU間を800Gbpsで接続することを目標に設定しています。

3つ目は我々特有、または自動運転や視覚情報を扱うAIを開発する上で重要なのがストレージです。大規模なデータを高速に読み出す必要がありますが、これに対応するためには高速なデータ基盤が必要で、一般的なHPCやAIワークロードよりも、さらに踏み込んだ性能と容量が求められます。ただし、無限にコストをかけることはできないため、ストレージを階層化し、安価なストレージと高速ストレージを使い分ける構成を検討しています。

山口:GPUクラスタというと、GPUの枚数やFLOPSが注目されがちですが、実際のワークロードでは、インターコネクトとストレージが非常に重要になります。用途にもよりますがストレージについては軽視されることが多く、例えば、言語モデルの学習ではテキストデータが中心で、ファイルサイズが小さいため、ストレージ性能はそこまで重視されませんよね。

渡辺:データ量がある程度見えているという点もありますね。

山口:一方で、自動運転やフィジカルAIでは、動画データを扱います。時系列・空間情報を含むため、読み出すデータ量が桁違いになります。PB級のデータを計算サーバーの近くに配置しなければ、ストレージがボトルネックになり、GPU性能の10%も使えないという事態になります。

渡辺:ストレージは常に問題を抱えてますね。

山口:先ほど、インターコネクトが重要だという話が出ましたが、ネットワークについてもう少し詳しく伺いたいと思います。800Gbpsという数字だけを聞くと、とんでもなく速いですよね。

渡辺:軽い気持ちで言ってますけど、10年前を考えたら信じられない数値ですよね。

山口:深澤さんはネットワーク専門の立場から見ると、この速さはどう見えていますか。

深澤:GPU8枚構成のサーバーを想定すると、1ノードあたりGPUだけで8×800Gbps、つまり6.4Tbps出せます、ということになりますよね。さらにCPUノードとかの通信も含めると、1ノードあたり7Tbps前後出すみたいな構成になります。

私がネットワークに携わるようになった当時は、サーバーが光ではなくてカッパーのケーブルで1Gbpsが主流でした。そこから考えると、80倍になってるんですよね。その次は1.6Tbpsといった話も出ていますが、これだけの帯域が必要とされるのは、みんなが求めてるからだと思います。

山口:最近はモデルが大型化して、1台のGPUサーバーで学習させることが難しくなり、分散学習が前提になっていますよね。チューリングでも8ノードや16ノードといった構成で分散学習を行うことが一般的になっています。

深澤:Hadoopなどの分散処理基盤と比べても、GPUの分散学習は要求される通信性能が非常に高いです。GPUの進化スピードが非常に速いため、ネットワーク側も「データセンター」というより、「1つの巨大なコンピューター」を構成する感覚に近づいています。

課題はデータセンター

山口:ここまでが、次期GPU基盤に求めるスペックの話でした。正直なところ、すでにかなり具体的に動いていますよね。

渡辺:はい。かなり動いています。

山口:詳細をお話しできないのは冒頭に申し上げた通りですが、その中でに出てきた課題についてここからお二人と深掘りしていきます。まず最初の課題は、データセンターの場所ですね。これはどういう点が難しいのでしょうか。

渡辺:AIブームによってデータセンターの建設ラッシュが起きていますが、完成予定が来年や再来年のものが多いです。一方で、我々の開発のスピード感ですと、今すぐデータセンターが欲しいという状況です。実はまだAI向けに特化したデータセンターは十分な数ができていないため、既存の選択肢の中からどれを選ぶか、というのが結構悩ましいですね。

山口:前提としてデータセンターは簡単に建設できるものではなくてですね、対災害性や電力、冷却、ネットワークなど、多くの要素を考慮しなければなりませんね。簡単に「作ろう」と思ってもポンと作れるものではありません。最近は需要が急増しているので各所で作り始めている一方で、供給が追いついていない状況です。

最近では、KDDIさんが工場跡地をデータセンターに転用する事例もありましたが、その点はいかがでしょうか。

渡辺:工場跡地は、データセンターに向いているケースが多いです。工場はもともと大量の電力を受電していることが多く、工場が撤退した後も電力インフラが残ります。KDDIさんのアプローチはまさにこのケースですね。

深澤:工業用水用に水も引き込まれていることが多く、冷却用の水を確保しやすい点も利点ですよね。海外では、そのような設備を活用して水冷GPUクラスターを構築する事例もあります。

山口:最近のデータセンターはIT設備というより、工場に近づいている印象がありますね。スライドには「水冷対応」と書いてありますが、そもそもデータセンターには水冷と空冷の2種類がある、という理解でよろしいでしょうか。

渡辺:はい。最近の高密度GPUサーバーでは、水冷を前提とした設計が増えています。GPUの発熱量が非常に大きく、空冷では冷却能力が追いつかないケースが増えてきています。そのため、水のように熱を効率よく運べる冷媒を使う必要があります。NVIDIAも、次世代以降のGPUは水冷前提になるという話をしていますよね。その流れもあり、水冷対応は避けて通れないテーマになっています。

山口:データセンターに行くと、かなり騒音が大きいですよね。

渡辺:空冷のデータセンターはかなりうるさいですね。サーバールームに入る前の部屋に耳栓が置いてあったり、イヤーマフを装着しないと長時間いられないケースもあります。

山口:「都市型」と書いてありますが、データセンターにも都市型や地方型、キャンパス型など、いくつか型があるということですかね。

渡辺:はい。従来は都市部に集中していましたが、最近は電力や土地の制約から、郊外に大規模なキャンパス型を作るケースが増えています。それでも需要に追いつかず、コンテナ型のデータセンターも出てきています。

山口:それぞれにメリット・デメリットがある、ということですね。いずれにしても、データセンターが決まらないと、スペックやコスト、工期が決められないという点が大きいですね。

GPUサーバーの選定とネットワークの物理設計

山口:機器の話に入りますと、次に問題になるのがGPUサーバーそのものの選定だと思います。今はNVIDIAやAMDなどがデータセンター向けのGPUを出していますよね。性能も上昇していますが、価格もかなり上昇しているのが現状ですよね。

渡辺:最近は価格が凄く上がりましたね。パソコンを触る人全員に影響がある話ではありますが…。

山口:メモリやSSDの価格もかなり上昇していますよね。我々もこれからGPUサーバーを購入するとして、価格も判断材料としては重要ですよね。

渡辺:我々も無限に予算があるわけではないですからね。また、現状では水冷だけでなく空冷も選択肢に存在はしています。

山口:例えばNVIDIAのGPUを買いますとなった場合は、サーバーもNVIDIAのものを購入するのでしょうか。

深澤:選択肢としては二つありまして、Gaggle Clusterと同様にNVIDIA製のサーバーでGPUも同じというDGXと呼ばれるパターン。もう一つはDellやHPE、SupermicroなどがNVIDIA製のGPUを搭載して、各社が提供するHGXと呼ばれるパターンですね。それぞれにも水冷か空冷かがありますので、選択肢の幅としては広いですね。

山口:続いてネットワークについてですが、物理設計の観点で一番大変な点はどこでしょうか。

深澤:まず一番大変なのは、物理的な配線量です。GPUを8枚搭載したサーバーの場合、NICなども含めると1台あたり10数ポートになります。それが100台、200台と増えると、数千本単位のファイバーケーブルが必要になります。さらに、GPU間通信に加えて、ストレージ接続も含めると、その倍近くになるケースもあります。

最近の400Gbpsや800Gbpsの光ファイバーでは、従来の2芯ではなく、12芯や16芯を使う構成が一般的になっています。そのため、全体としては「何万芯」という単位になり、総延長もキロメートル単位になります。

山口:設計段階で、かなり細かく詰めないといけないですね。「広帯域化に伴う伝送規格の多様化」は、芯数が増える以外の話になりますよね。

深澤:はい。昔はSRやLRといったシンプルな規格でしたが、現在はSR、DR、FR、ZRなど、多くの規格があります。誤った組み合わせで発注してしまうと、物理的に接続できない、あるいは通信できないという問題が起きます。

渡辺:インフラではよくある話ですが、両端で別々に機器を発注して、規格が合わないことに後から気づく、という事故が起きやすいですね。

山口:規模が大きくなるほど、事故のリスクも高まりますね。スライドのその下の、LPO(Linear Pluggable Optics)やCPO(Co-packaged Optics)といった言葉について教えていただけますでしょうか。

深澤:LPOは、今まで用いていたSFPと呼ばれるモジュール内にあったDSPなどの処理を機器側に寄せることで、消費電力や発熱を抑える仕組みです。これによって従来と比べて約半分の消費電力になります。

CPOはCo-packagedと書いてあるとおり、モジュールを抜き差しして規格を変えられるんですよね。「50mだからこの規格にしよう」「100mだからこの規格にしよう」というように変更できる仕組みを、パッケージ化して一緒に扱うアプローチです。まだ主流ではありませんが、今後普及してくる可能性はあると考えています。

渡辺:以前はGPUサーバー側の消費電力が注目されがちでしたが、最近は800Gbps、1.6Tbpsと帯域が上がるにつれて、ネットワーク側の消費電力の割合が伸びていて、消費電力を抑える動きがネットワーク側でも大きくなっています。

InfiniBandからEthernet(RoCE)へ

山口:現行のGaggle ClusterではInfiniBandを採用していますが、次期基盤ではどうする予定でしょうか。

深澤:次期基盤では、InfiniBandではなく、EthernetベースのRoCE v2を採用する方向で検討しています。Ethernetは今後GPUや周辺技術が変化しても、柔軟に対応できるようにということで採用しました。

山口:Ethernetでロスレスな通信をするのは昔は技術的にも難しい印象がありましたが、最近はRoCEがよく使われていますよね。

深澤:Ethernetでパケット制御や輻輳制御というところは機能としては今までもあったので、うまく組み合わせてロスを生まないように輻輳制御して、といった部分を今は行なっています。国内外でRoCEを使ったGPUクラスタの事例は増えており、適切に設計・運用すれば問題なく使えると考えています。

渡辺:Ethernetという規格のコミュニティが大きいのも採用した理由の一つですね。

山口:クラウドでのストレージコストについても伺っていこうと思います。

渡辺:はい。クラウドのストレージコストですが、自動運転開発のようなワークロードでは、大量のデータセットを扱うため、数百万円というレベルではなくそれ以上にかかり、コストの最適化はオンプレでも重要になると考えています。

山口:クラウドストレージを使うと、データを保存するコスト、計算時に読み出すコスト、別の場所に移動するコストなどが積み重なって、特に我々のような動画データを自社で多く持っていて、学習データにしている会社ですと結構クリティカルな問題ですよね。

渡辺:データをどこに置いて計算をどこで行うか、というのはさまざまな面で効いてきますね。

山口:その下には「データには引力(重力)がある」と、何やら格言めいたものが書かれていますが。

渡辺:これはIT系の調査会社などが用いる言葉で、実際に「データグラビティ」という言葉がありまして、データが大量にあればあるほど、さまざまなメリットが要因となって周辺にシステムやものが集まってくる、という事象が起こることに由来していますね。

山口:我々のデータも今後増えていくことは目に見えていますので、移行が大変になる前に次の計算クラスタを設計する必要がある、ということですね。

共に計算基盤を作る仲間が増えてほしい

山口:ここまでお話を伺ってきて、かなり大規模で複雑な計画だということがよく分かりました。正直なところ、この規模の基盤を、今の人数で作れるのでしょうか。

渡辺:結論から言うと、2人では難しいですね。

山口:やはりそうですよね。EFLOPS級の計算基盤になると、日本国内でも有数の規模になります。設計、調達、構築、運用を考えると、インフラエンジニアは複数名必要になりますよね。ちなみに何人ぐらいいたら嬉しい、というのはありますか。

渡辺:よく社内で話題になりますよね。言っていいのなら「30人」と言いたいですが(笑)。ただ今日話したのは物理的なパートが多かったので、計算クラスタを動かすためのソフトウェア側のことも考えると、2桁人クラスは必要だなというのはあります。

山口:ネットワークとストレージについてはお二人もかなり詳しいですが、例えばサーバーやソフトウェアの部分で、今後もさまざまな話が出てくるかなと思いますね。

渡辺:非常に面白い経験ができる場所ではありますよね。なかなかできるチャレンジではないとは思っています。

深澤:そうですね。近くにMLエンジニアの方がいて、一緒に同じ目標で作っていくという環境は、インフラエンジニアにとってはとても刺激になりますよね。この面白い環境で仲間を増やしていきたいなと思いますね。


チューリングでは、完全自動運転の技術を共に創る仲間を募集しています。今日お話ししたインフラチームはもちろんのこと、機械学習エンジニア、リサーチャー、ソフトウェアエンジニア、組み込みエンジニアなど、非常に幅広いエンジニア職種で仲間を募集しています。ご興味のある方は、ぜひ採用ページをご確認ください。多様な職種がありますので、ご自身がどれに当てはまるか、ぜひチェックしてみてください。

TuringTechTalk #34「E2Eモデルの進化と、2026年の目標」

この記事に登場する人
CTO
山口 祐 Yu Yamaguchi
産業技術総合研究所 研究員/米国NIST客員研究員として研究する傍ら、独自にゲームAIの深層学習の開発を開始。日本の囲碁AIプロジェクトの開発代表として、最大1100GPUの並列分散強化学習を設計・開発し、世界大会準優勝、将棋AIでも世界大会優勝などの実績がある。HEROZ株式会社 執行役員を経て、2022年、チューリングに創業メンバーとして参画。2024年8月、CTO就任。基盤AIチームマネージャー兼任。
自動運転第1グループマネージャー
棚橋 耕太郎 Kotaro Tanahashi
2015年に新卒でリクルートに入社し、機械学習で広告・人材マッチング・配送ルートなどの最適化に従事した後、量子アニーリング技術を社会実装する中で未踏のプロジェクトに関わり、業界のデファクトスタンダードとなるOSS、PyQUBO(量子アニーリングを簡単に使うためのPythonライブラリ)の実装を手がける。2023年5月にチューリングに入社し、現在は、主にモデル開発を行う自動運転第1グループマネージャーをつとめる。

はじめに

チューリングのEnd-to-End(E2E)自動運転は、モデルの完成度だけでなく「実車で動く」「改善が回る」フェーズへと進み、開発の重心が“理論”から“実装とスケール”へ明確に移り始めています。
今回のテックトークでは、CTOの山口と、自動運転開発の現場を統括する棚橋が登壇。E2E自動運転の基本から、車載計算機とカメラ中心の構成、車両制御・データ収集・評価という“氷山の下”のリアル、そしてTokyo30(東京都内30分無介入走行)達成の裏側まで、現場目線で解き明かします。

※本記事はTuringTechTalk#34の内容を元に一部編集してお届けします。

平和島から始まる2026年

山口: 皆さんこんにちは。チューリングCTOの山口です。TuringTechTalk第34回、「E2Eモデルの進化と2026年の目標」を始めます。今日はチューリングの自動運転開発を現場で牽引している棚橋さんに来てもらっています。棚橋さん、よろしくお願いします。

棚橋: よろしくお願いします。

山口: まず雑談から入るんですけど、拠点が大崎から平和島へ移って、配信環境も含めて色々変わりましたよね。現場として平和島の環境、どう受け止めてます?

棚橋: 想像以上に良いです。天井も高いし、同じ空間を全員で共有できて、コミュニケーションも取りやすい。あと地味に嬉しいのが社食ですね。月曜から木曜まで毎日出て、クオリティが高いです。

山口: そうそう。研究開発って、机とPCだけあれば進むようでいて、実は「同じ場所で同じテンポで会話できる」だけで速度が上がることがある。平和島に移って2週間ちょっとですが、そこは私も満足してます。


E2E自動運転とは

山口: 今日はE2E自動運転の話を、モデルだけじゃなくて、実車で成立させるところまで含めて話したいです。まず前提として、棚橋さん、E2E自動運転って一言でいうとどういうものですか?

棚橋: 従来の自動運転は、センサーやHDマップを前提に、パーセプション(認識)→プレディクション(予測)→プランニング→コントロール、みたいにモジュールを分けて組み合わせる構成が多かったと思います。E2Eはそれを分解せず、単一のニューラルネットワークにカメラの画像や映像を入れて、車をどう動かすかというアクションを直接出力します。

山口: ありがとうございます。従来の自動運転ではWaymoなどが有名ですが、最近はE2Eという言葉を聞くこともかなり増えてきましたよね。

棚橋: そうですね。あと、最近E2Eが注目されたタイミングって、LLMが一般化したタイミングと少し重なっていると思っていて。LLMも、複雑な質問に答えるとき、内部でルールを手書きしているわけじゃなく、大量データで学習して成り立っている。E2Eも似ていて、「次のアクションを予測するだけで複雑な運転ができるの?」って直感に反するんですけど、データが増えるほど、人間が考えているかのような運転が出てくる感覚があります。

山口: 歴史の話で言うと、2016年頃にNVIDIAがDAVE-2を出していて、CNNベースで「画像→ステアリング」みたいなE2Eの芽は昔からありました。ただ当時は、レーンキープ的なところが中心で、都市の複雑なネゴシエーションまで飲み込むフェーズではなかった。ここ数年でモデル・データ・計算の条件が揃って、ようやく“勝負になる”土俵ができた、という見方もできます。


見えてるのは氷山の一角、E2Eを実写で動かす勝負は水面下

山口: ここからが今日の肝です。AI DAYでも「氷山」のスライドを出しましたが、E2Eって「モデル作れば走る」と思われやすい。でも現実は逆で、モデルは氷山の上に見えてる部分で、下が圧倒的に大きい。

棚橋: まさにそうで、E2Eモデル開発って言っても、実際に車を走らせるには別の技術が必要になります。例えば、センサーの取り扱い、動画データを作る、運転アクションを作る、車両制御の遅延や追従性を詰める、評価する、クローズドループで回す、みたいな話ですね。

山口: 自動運転はリアルタイム性が厳しい。LLMみたいに「数秒待って返ってくる」が許されない。0.1秒の遅れが命取りになる。だから、AIの賢さだけでは閉じず、車載ソフトウェアとハードウェアの整合が必須になる。

棚橋: もう1つ大きいのが評価です。公道走行で評価すると、同じシナリオが再現できない。時間帯で交通状況も変わるし、同じ交差点でも歩行者の出方が違う。モデルAとモデルBの差を見たいのに条件が揃わないので、「どっちが良いのか」を定量で判断しにくい。シミュレーターやクローズドループ評価についても、現実と同じ再現性を持って行うことはかなり難しいです。

山口: “E2Eの難しさ”って、モデルの数式よりも、現実の制約を飲み込むエンジニアリングにある。ここを理解してもらえると、チューリングの仕事の面白さが伝わると思います。


Orin 250TOPS、そして車両を増やしてデータを増やす

山口: では車両の話に入ります。チューリングの車両はアルファードベースで、外から見るとカメラがさりげなく付いている。計算機は1台でまとめてます。棚橋さん、計算機のスペックを改めて。

棚橋: NVIDIAのOrinを使っていて、だいたい250TOPSぐらいですね。

山口: 最新のGPUアーキテクチャと比べると古い部分もありますが、当時は選択肢が少なかったこともあり、車載でE2Eを回す前提で採用しています。自動運転領域ではかなり一般的なSoCですね。ここで重要なのは、車両が1台じゃないことです。29号車まで同じ構成を作って、データ収集もできるし制御もできる。なぜ同じ構成を増やすかと言うと、結局E2Eはデータが勝負だからですね。そして、チューリングでは同じ車両をデータ収集と制御の両方に使用できるんですよね?

棚橋: そうですね。データ収集専用にしてしまうと、制御実験の速度が落ちる。逆に制御用だけだとデータが増えない。なので同一車両で両方できるのが開発上は効きます。

山口: そして“ゴツい自動運転車”のイメージと違って、計算機1個でかなりコンパクトにまとめている。量産を見据えると、この方向性が大事にりますね。


AI以前に「車が思い通りに動かない」

山口: 開発の振り返りをすると、最初はモデル以前に「車が動かない」という壁がありました。2024年10月頃のクローズドコースでの検証、まずはラインに沿って走らせるところからでしたよね。

棚橋: はい。最初はMLモデルを入れずに、単純にコースに従って走れるかを検証しました。そもそも車をプログラムに従って動かす、というだけで難しかったので。そこから自動運転モデルと結合していく形です。

山口: ガソリン車だと縦制御が難しい、という話もありました。棚橋さん、理由をもう少し噛み砕くと?

棚橋: 低速域でこちらが加速度を渡しても追従性が高くなく、縦制御が安定しない。車両側にブラックボックス的な制御が入っていたり、アクチュエータの反応速度や遅延も絡むので、思った通りの動きにならない。ハイブリッドだとモーターが効いて滑らかに制御しやすい、という差もありました。当時は毎日、絶望しては解決されて喜ぶ、の繰り返しでしたね(笑)。

山口: この壁を越えて、AIの改善がちゃんと走行性能に反映される“土台”ができましたね。


モデル設計の方針

山口: 次にモデルの話。今のE2Eモデルは、イメージバックボーン→Transformer→トラジェクトリー出力という、比較的シンプルな構造です。ここで話題になるのがBEV(Bird eye view)やオキュパンシー、UniAD※みたいな複雑設計との違いですよね。

※CVPR2023でBest Paper Awardを受賞したUniAD [Yihan Hu+, CVPR2023]

棚橋: 我々がBEVに強く寄せていない理由はいくつかありますが、1つはデバッグ性です。複雑な構成だと、走らなかったときにどこが悪いのか追いづらい。もう1つは開発資産の継続性で、普通のコンポーネントで組んでおくと、高速化やチューニングのノウハウが積み上がって、次のモデルにも引き継げる。

山口: モデルの工夫でちょっと性能を上げるより、データを増やし、スケールに耐える構造で伸ばす方が、最終的に勝ちやすい。

棚橋: はい。モデル改善はあるにせよ、古典的に「アーキテクチャをこねて勝つ」より、データの質量が支配的になっている感覚はあります。


都内で“人間っぽい”挙動が出始めた瞬間

山口: 2025年の春頃には、クローズドコースでもかなり自在に操れる状態になってきて、そこから公道で安定して走れるようになりました。平和島から大崎のルートを走る映像、あれは2025年8〜9月頃でしたよね。

棚橋: そうですね。その頃には、信号で止まる、右左折する、レーンチェンジする、みたいな基本動作が滑らかになっていました。面白いのは、山道みたいな比較的シンプルな環境も十分凄いんですが、データを増やしていくと市街地みたいな複雑環境でも人間っぽい“創発”が出始めることです。例えば、信号待ちで車が詰まっていたら空いてる車線にスッと移って前に出る、とか。

山口: こういう挙動って、ルールで書くと沼なんですよね。でもE2Eだと、データが積まれるほど自然に出てくることがある。

カンブリア爆発の正体

山口: ここでデータの話。最初は単一号車・単一ドライバーで検証して、そこから複数車両・複数ドライバーへ拡張しました。データを増やすと、センサー差分や運転スタイル差分を吸い込む必要が出てきます。

棚橋: そのためにキャリブレーションを揃えたり、データパイプラインを整備したり、地味だけど重い作業が必要になります。ここが氷山の下の部分ですね。

山口: そして、ある時期にモデルの評価指標が一気に青くなった。社内では“カンブリア爆発”と呼びました。

棚橋: AIの進化ってリニアじゃなくて、ある日突然来るんだな、という体験でした。データがあるラインを超えたときに、モデルが急に“粘り強く”なった感覚があります。

E2E自動運転が強いシーン

山口: 具体例を挙げると、対向車を見ながら中避けするネゴシエーション、歩行者が大量に渡る横断歩道、マリオカート風の小型車両、工事現場の誘導員のジェスチャー。こういう「抽象度の高い情報」が混ざる環境で、E2Eが強みを見せることがある。

棚橋: 特に特殊車両は面白いですね。学習データにほとんどないはずなのに、車間を空けて止まって、全部行ったら後ろに付いていく、みたいな挙動が出た。モジュール型だとカテゴリ定義が必要になるので、そこを“映像のまま”処理できるのはE2Eならではです。

山口: もちろん万能ではない。だからこそ、データと評価を回して、こういうシーンを着実に潰していくのが2026年の勝負になりますね。

Tokyo30達成と、“回る開発”の完成度

山口: Tokyo30、東京都内30分無介入走行は大きな節目でした。引き金はデータスケールで、9〜11月にデータが増えて、11月に“閾値”を超えた感覚がある。

棚橋: そこに加えて、MLOps基盤が効きました。データを集め、前処理し、データセット化して、GPUクラスターに転送し、学習し、デプロイして走行実験して、結果をまた学習に戻す。このループを自動化して回せるほど、改善の速度が上がります。

山口: そして評価。クローズドループ評価がようやく実用になってきた。3DGSで空間を再構成し、モデル出力で車を動かして、車線逸脱や曲がり損ねを定量化できる。現実の制御アルゴリズムまで組み込むのが難しいけど、最近かなりうまくなってきた。

棚橋: はい。最初は3DGS空間を作るだけでも難しかった。でも最近は再構成も安定してきて、フィジックスや制御まで含めて“実験と同じ走り”を再現できるようになってきた。評価が回ると改善が回るので、ここは大きいです。

山口: 配信でも質問がありましたが、LiDARはどうですか?

棚橋: 収集時に教師ラベル用途で付けていた時期はありますが、結論として今は自動運転入力としては使っていません。

山口: そうですね。もう外してます。カメラ中心で成立させる設計に寄せています。


2026年の目標は、より複雑な東京で、より安定に、ナビ連携も現実へ

山口: 最後にタイトル回収です。2026年の目標を、棚橋さんの言葉でまとめると?

棚橋: 30分走れたのはスタートです。2026年は、より複雑な都内で安定して30分無介入を出すこと。さらにナビゲーション連携を安定させること。周囲車両とのインタラクションも、より自然にしていく。ここが次の課題だと思っています。

山口: “できる”から“どこでも安定してできる”へ。地味で重い工程が増えるけど、チューリングはそこをやり切るために、データ・車両・評価・MLOpsを全部つないでいます。


Q&A一覧

以降は視聴者のQAに回答していきました。詳しくは動画をご覧ください。

  • LiDARなどのセンサーも利用していますか?それとも画像認識とニューラルネットワークだけで制御していますか?
  • 競合と比較して、初期から強みや差別化を意識した部分はありますか?
  • E2Eモデルが出力するトラジェクトリーは座標集合ですか?速度の値も含まれますか?
  • 学術界のE2Eモデルと産業で使われるE2Eモデルにはギャップがありますか?博士で研究しても無用になり得ますか?
  • 量産車に適用する際の課題/自動車メーカーにお願いしたい領域はどこですか?
  • 晴れ映像が多いが、夜や雨は難しいですか?
  • ナビゲーション連携(NOA)実現の課題はどこにありますか?
  • データが増える中で、学習は全データを使っていますか?サンプリングで一定量にしていますか?
  • 歩道走行ロボットの起業家へ、これから自動運転に挑む企業家へのアドバイスは?
  • ハイブリッド構成(E2E+モジュール)/ニューラルシンボリックは研究・実用で使われていますか?
  • お台場・有明の映像が多いが、そのエリアのデータだけで学習しているのですか?
  • アルファード改造にメーカー許可は必要ですか?自分でもやってみたい

チューリングでは、完全自動運転の技術を共に創る仲間を募集しています。今日お話ししE2Eスケールアップチームはもちろんのこと、機械学習エンジニア、リサーチャー、ソフトウェアエンジニア、組み込みエンジニア、インフラエンジニアなど、非常に幅広いエンジニア職種で仲間を募集しています。ご興味のある方は、ぜひ採用ページをご確認ください。多様な職種がありますので、ご自身がどれに当てはまるか、ぜひチェックしてみてください。

インフラチーム対談 〜チューリングで目指す次の計算環境構築〜

この記事に登場する人
インフラチームリーダー
渡辺 晃平 Kohei Watanabe
高等専門学校で電子工学(半導体やレーザー)を学んだ後、新卒で大手通信会社に入社。新設されたクラウドサービス部で当時国内でも新しいクラウドサービスの開発に携わった後、サービス企画部門に異動し、クラウドサービス企画を担当しながら、複数のGPUクラスター案件を担当。その後、外資系ストレージベンダに転職し、ストレージ技術を学んだ後、チューリングに入社。
インフラチーム シニアエンジニア
深澤 開 Kai Fukazawa
2013年にヤフー(現:LINEヤフー)へ新卒入社し、大規模Hadoop基盤(最大70PB)の設計・構築・運用に従事。 データセンターネットワークやGPUクラスタ向けネットワークの設計・構築や米国子会社へ出向し、 米国データセンターの立ち上げや大規模分散処理基盤向けのインフラ設計・構築・運用も担当。 そのほか、バックボーンネットワーク統合プロジェクトのマネジメントなどを経験し、グローバルかつ横断的なインフラ運用を推進。チューリングでは大規模計算基盤を担当し、世界で戦える高効率な計算インフラの実現を目指す。

はじめに

2024年に自動運転と大規模AI学習に特化した自社専用計算基盤「Gaggle Cluster」を構築するなど、これまで大規模な計算インフラを構築・運用してきたチューリング。2025年12月に開催されたTuring AI DAY 2025では、山口祐CTOから今後の計算基盤の方向性について、その規模やロードマップの発表が行われました。

今回は新たに組成したインフラチームの2人による対談を実施。チーム組成の背景から、次期GPU基盤構築というチャレンジの詳細、新たにチームに求める人物像などを語ります。

インフラチームが組成された背景

渡辺 昨年(2025年)まではCTO室、CTO直下という形でインフラ全般を見ていました。具体的には、会社全体の計算資源をどう調達し、それを各研究テーマや開発用途にどう割り当て、どう使いやすい形にするか、そのための基盤づくりが主な役割でした。クラウドサービスを活用することもあれば、オンプレミスの「Gaggle Cluster」を構築・運用することもありました。

昨年末のTuring AI DAYで発表が行われた内容の通り、ここから先は計算資源律速で、自分たちが開発しているモデルが進化していくことはほぼ見えてきているので、それに向けて心機一転で新しいチーム及びインフラを作っていくという意味で、CTO室から分離し、インフラそのものに専念するインフラチームを組成するという判断に至りました。

これまでのCTO室ではインフラ担当はほぼ私1人でやってきました。今回のチーム組成にあたって、ジョインしてもらったのが深澤さんです。簡単に自己紹介をお願いします。

深澤:2025年12月からチューリングに参加した深澤です。前職ではインターネット広告事業の会社に所属し、主にデータセンター内のネットワーク、バックボーンと言われている拠点間をつなぐネットワーク、そしてインターネットとの境界部分、ピアリングルーターの管理などを担当していました。

また、前職ではアメリカにデータセンターを持っていたため、現地に約5年滞在し、データセンターの運用や物理構築にも携わっていました。

渡辺:ちょうど入社して1〜2ヶ月ほど経ったと思いますが、前職と比べて、チューリングに来て感じた一番の違いやギャップは何でしょうか。

深澤:一番大きいのは、エンドユーザーが非常に近いことですね。前職では、広告主やレポートを見る人たちがエンドユーザーでした。一方で、チューリングではMLエンジニアが社内にいて、日々直接フィードバックをもらえる。実際に仕事をしていると、「ここが調子悪い」「こういうことがしたい」と。自動運転に向けていいものを作っていくところに、こうした形で協力できるのは魅力的だと思います。

渡辺:ユーザーが近いのは幸せな反面、ユースケースが多い場合は基本的にパンクするじゃないですか。ただ、チューリングの場合は、やることがほぼ全員同じで、「完全自動運転AIを開発する」、あるいはそれに関連する基礎研究を行う、という方向性が揃っている。そのため、ワークロードも共通しやすく、起きる問題も似通っている。この共通課題を前提に、新しいインフラを打つ必要が出てきた、というのがチーム組成の背景です。

チューリングが目指すこれからの計算環境

渡辺:AI DAYで発表があったとおり、結構チャレンジングな計算規模をこれから打ちますと宣言していまして、それに向かって現在様々な準備を進めています。これからの計算環境について、技術的に超えなければいけない壁は大きく2つあります。1つは当然、GPUの計算リソース量。もう1つは、それに付随するネットワークとストレージといった周辺コンポーネントです。

GPUだけを増やしても、ネットワークやストレージが追いつかなければ意味がありません。この点については、去年からCTOと私で管理し、議論を重ねてきました。その中で、今回新しいオンプレミス基盤を作るという構想が立ち上がり、現在動いている最中です。

そこでネットワークに詳しく、かつGPUクラスタの構築経験がある深澤さんに参加してもらったので、これからサーバー、ストレージ、ネットワークと、考えるべき要素は山ほどあるのでこれから広げていこうというところです。

深澤さんはAI DAYで発表された計算環境のコンセプトについて、率直にどう感じていますか。

深澤:純粋に面白いですね。自分がインフラを始めた頃は、サーバー1台10Gbpsでも「速い」と言われていましたが、それが今では平然と「800Gbpsです」と言ってて。そこにチャレンジすること自体が面白いですし、それを実現するために、どの規格を選び、どの技術を採用するかを考えるのも楽しい。メーカーや他社のGPUクラスタ運用者と話をする中で、最先端の情報に触れられるのも魅力です。

渡辺:最近のITインフラは昔と比べて、特定のメーカーを揃えれば完成する時代ではなくなっています。パーツの1個1個レベルでメーカーが違い、そういうのを集めていく感じが合う人も多いです。

それからテクノロジーもディープになってきていて、これを一人で見るというのは結構限界になっていて、でも聞いている1個1個の内容は先端技術であり、とても面白いですね。

深澤:面白いですよね。それを組み合わせなきゃいけないという難しさもある。自分の中ではインフラは、全体最適をしなきゃいけないと思っています。各レイヤーである意味最適化し過ぎると、どこかで不整合が起きると思うんですよね。それがGPUだと最終的に凄いクリティカルになる。

今はチームが2人だからこそ、自分たちて各所を見ながら「ここはこの選択をする」と決められる。インフラチームとしては、MLエンジニアに使ってもらうにはどうすればいいかを目標にしていて、その過程で色々なところから刺激をもらったり、考え方がシンプルに広がるというのは、そこも面白い部分だと思いますね。

渡辺:以前構築したGaggle Clusterでは、NVIDIAのリファレンスアーキテクチャに沿って作るというコンセプトで構築しました。今回チャレンジングな要素として一つあるのが、前回GPU間通信にInfiniBandを使っていた部分を、今回はEthernetにし、さらにRoCE v2を採用して800GbpsをEnd-to-EndでGPUを繋ぐことです。

この辺りはアメリカが先行してる分野だとは思いますが、日本で1社単独で取り組むには、かなり…。

深澤:チャレンジングですよね。

渡辺:かなりコストもかかりますよね。私と深澤さんが20代の頃に触っていたネットワークスイッチは1台100万円、高くても数百万円でしたが、今回我々が入れようとしている機械は本体だけで1000万円を超えていて、光通信モジュールも1個10万円を平気で超えている。これを何十何百とGPUに繋ぐチャレンジができる会社って減ってくるという感じはしませんか?

深澤:そうですね。今ネットワークもそうですし、サーバー自体も昔のサーバーに比べると凄い価格も上がってるというのもあって、そんな中この規模で投資するという判断するというのは、技術だけでなく、投資判断も含めて難易度が高いと思います。ここができるっていうのはチューリングの魅力の一つだと思いますね。

渡辺:深澤さんは今のところ、この1ヶ月半ほどやっている内容は満足してます?

深澤:だいぶ満足といいますか、やっぱり楽しいですよね。ここでこの規模のインフラを打たないと、「We Overtake Tesla」という目標に対して近付ける意義、より近付けるかどうかの瀬戸際だと思っていまして、このチャレンジに対して道、というよりやることは決まっていますので、あとはそれに対して全力でやるというところですね。あと、作って終わりじゃないですので。

渡辺:そうなんですよね、そこからなんですよねこの会社は。

深澤:作って、MLエンジニアの人たちが使って、自動運転を開発する。これをどんどん事業化するのが結局インフラの手段ですので。インフラチームとして、作ったものを使ってもらえるか、という部分ではこの先もいい意味で楽しみですね。

渡辺:私も2024年3月に入社して、そこから計算リソースクラウドで用意したり、Gaggle Clusterを作るなどした結果、Tokyo30ができた。1〜2年周期で大きなアウトプットが出てくる、しかも自分たちの作った計算インフラによってある意味成果として出てくる、そういったサイクルがあるというのは結構幸せなことなんですよね。

現時点で我々が2024年からやってきた計算資源の戦略は、一旦間違ってなかったという状態になるぐらいに成果を出してくれたのは、もう社内のMLエンジニアの方々に非常に感謝しています。そして今回さらに大きな規模で動き出してるってのは私の中で嬉しくて、我々が今作ろうとしてるインフラを使って今度は何をどこまで作ってくれるかは本当に楽しみですね。

自動運転開発とインフラのビジネスモデル

渡辺:私が入社してから言い続けていることですが、このインフラの規模を投資して、それをどのように回収するかというのは結構ポイントがあると思っています。インターネットの広告事業のように、ITシステムは5年ほど動かしたシステムの中で、何%利用料みたいな感じで社内的な取引をして、実際に広告事業やコンテンツ事業を行なっているプロダクトとして、費用を負担してもらって…という流れですが、今回の規模ってその延長線上でできるって感じはあまりしないですよね。

深澤:そうですね。この規模ですぐ成果というのは難しいと思う部分もあると思いますね。

渡辺:一方で、サブスクリプションのようなビジネスモデルって、安定して収益を得られる。当時も多分新しい基盤とか増設する時に、今のビジネスでこのぐらいのIT投資ができるから、実行後10年に向けてもっと大きな投資しましょう、みたいなことをやってたじゃないですか。

結局今の自動運転開発も未来はそうなっていまして、アメリカのTeslaでは完全自動運転用のライセンスサービスが月額サブスクになりましたよね。この流れはおそらく他の自動車会社も追従してくると思っています。そうなりますと我々が自動運転を提供する時には、みなさんが乗っている車に展開されて走っているわけでして、売ったら終わりではなく、アップデートも必要になります。より良い運転システムとかを提供し続けるという意味では、同じようなビジネスモデルは取るようになると思っています。

自動車が毎年世界的に数千万台買い替えられていく中で仮に今Teslaだと99ドル、日本円で言うと1万6000円月額で払っているので、それが数十万台、数百万台って積まれたら大きなマーケットになる。このぐらい大きなビジネスモデルがないと、耐えきれるインフラ規模じゃないんですよね。

深澤:最近車買おうかなと思って会社の皆さんと相談もしていたのですが、とあるメーカーさんの車を買うと、今は色々とサブスクが豊富なんですよね。Teslaが今行なっている自動運転のサブスクも、そのうち他の会社さんも入れて、この自動運転のまずパッケージでいくらですとか、さらにこれを連携しますとか、様々な話になってくると、マネタイズっていいなと思いますし、サブスク入ったりとか自動運転機能があると、保険が安くなるとかいっぱいあるじゃないですか。

そういった世界がどんどん来るので、チューリングが作った自動運転の技術を、様々な会社さんがサブスクとして取り扱って、それを運転する人が入れることによってメリットが絶対出てくるので、その辺りのビジネスモデルとかっていうのは凄い良いな、筋いいなと思いましたね。

渡辺ある程度用途も決まってて、使い道も決まってるというのは、我々インフラエンジニア側からするとかなり楽なんですよね。「こういうところの可用性を諦める」、「ここのパフォーマンスを諦める」とか、「こういう機能を諦める」みたいなことをバンバン決められて、結構スリムになった要件の中で作るってことになっていますが、やることは最先端のことができる、これが結構大きいですよね。

こなれた技術を使うことも大事ですが、取れるところのリスクは最大限取る、これがかなり面白いなと思っていまして。いわゆるインフラをデザインする上で、ネットワークって一番基礎の部分で、サーバー系とかストレージの話など、詰めていきたい部分がありまして、そういった分野も今後、一緒にやっていける仲間やパートナーを増やして、そういった経験をした人を日本で増やしていけたらなと今でも思っています。

深澤:みんなが使う前提のチューニングって、割と中立的になるんですよね。だからプラットフォームとかも、このチューニングをしたらこっちが立たないから、このプロダクト入れられません、みたいな箇所もあったりするので、大きくみんなで使うってのは、コスト的なところで大事な部分ではあるんですけど、それを経験したが故に、今どんどん早くしようみたいなところは、凄いみんな考えてますよね。

渡辺:若干テクニカルですけど、中立的なことを行うための技術が確立する前に、インフラ全体のテクノロジーが次のステップに上がっていっちゃうんですよね。例えば今回で言うと、200Gbpsのインターフェースが出たと思ったら、400Gbpのインターフェースが出て、800Gbpsが出て、次1.6Tbpsが出て…、さらに3.2Tbpsのロードマップもあったりと。結構このようなことが各分野で起きていて、ユースケースをどんどん絞っていかないと最新技術にはついていけないだろうなって感じはしてますね。

深澤:そこを突き詰めてやれる経験って、凄い大事かなとは思いますね。

※動画では番外編として、データセンターと水冷についてもトークしております。詳しくは動画をご覧ください。

TuringTechTalk #35「E2E自動運転を支える車両システム — Less is Moreの設計思想」

この記事に登場する人

この記事に登場する人
CTO
山口 祐 Yu Yamaguchi
産業技術総合研究所 研究員/米国NIST客員研究員として研究する傍ら、独自にゲームAIの深層学習の開発を開始。日本の囲碁AIプロジェクトの開発代表として、最大1100GPUの並列分散強化学習を設計・開発し、世界大会準優勝、将棋AIでも世界大会優勝などの実績がある。HEROZ株式会社 執行役員を経て、2022年、チューリングに創業メンバーとして参画。2024年8月、CTO就任。基盤AIチームマネージャー兼任。
自動運転第2グループマネージャー
渡邉礁太郎 Shotaro Watanabe
Turing株式会社 Driving Softwareチーム マネージャー。大学院修了後、サイバーエージェントに入社。ゲーム、SaaS・EC・広告のサービスなどさまざまな分野で技術選定段階から開発を経験。リクルートを経て、Turingへ転職。Turingが初めてエンドユーザー向けに販売した「THE FIRST TURING CAR」のプロジェクトリーダーを務める。現在はDriving Softwareチームで自動運転システム開発のマネジメント。

はじめに

E2E自動運転は「モデルが賢くなれば走れる」という話に見えがちです。でも実際は、カメラや測位、車両制御、デプロイ、フリート運用まで“走らせ続ける仕組み”が揃って初めて、改善が加速します。
今回のテックトークでは、CTOの山口と、車両・車載ソフトウェア・運用基盤まで幅広く担う渡邉が登壇。アルファードをどう調達し、どう自動運転車両に仕立て、どう安全に制御し、どうCI/CDやOTAで「更新できる車」を作っているのか。さらに、LiDARを外した背景なども含めて、Less is Moreの思想でつながる現場の設計判断を掘り下げます。

※本記事はTuringTechTalk#35の内容を元に一部編集してお届けします。

今日はAIではなく、AIを支える“車両システム”の話

山口: 皆さん、こんにちは。チューリングテックトーク第35回「E2E自動運転を支える車両システムの設計思想」を始めます。私はCTOの山口です。本日は自動運転第2グループのマネージャー、渡邉礁太郎さんに来てもらっています。

チューリングの自動運転は大きく3つのグループで進めています。私が全体を見つつ、第1グループが自動運転AI(走りの中核のモデル)、第2グループが車載システムと車両、第3グループが大規模モデルやリサーチに近い領域。今日はその第2グループの話です。それでは渡邉さん、よろしくお願いします。

渡邉: よろしくお願いします。


アルファードをどう手に入れ、どう“自動運転車両”に仕立てるのか

山口: まず、チューリングはどこまでやっているか。車両は「購入から」ですか?

渡邉: はい、購入からです。ただし新車というより、30系アルファードなので中古市場から調達することが多いです。状態の良い個体を選んで集めています。

山口: で、買ってきたアルファードは普通の車ですよね。そこから「自動運転車両に仕立てる」。具体的には?

渡邉: センサー、計算機、その上のソフトウェアを搭載します。電源まわりも含めて、買ってきた車を“自動運転が動かせる状態”に持っていく。OSやアプリケーションも含めて全部セットアップして、実験に耐える状態にします。

山口: ここって外からは見えないけど全車両でやっていて、これを経て自動運転車両を制御できていると言うことですね。

山口: よく聞かれるのが「市販車をソフトでいじれるの?」という点です。チューリングはどうやって車両制御しているんですか?

渡邉: 30系アルファードはADAS(運転支援)が載っている世代です。ACC(アダプティブクルーズコントロール)やLKAS(レーンキープアシスト)がある。車の中では既に制御が行われているので、その信号を利用して、自動運転しています。ゼロからアクセルやブレーキ、ハンドル角を直接制御するというより、車両が持つプラットフォームの上に乗せる形です。

山口: つまり、物理的な制約や安全側の枠組みは車両のレギュレーションに乗りつつ、上に自動運転の意思決定を載せるイメージですね。

渡邉: はい。

山口: 一般の方でも、もしACCやLKASが付いているなら高速道路などで使ってみると便利です。ただ、市街地は別の難しさがあるので、そこは私たちが開発している領域ですね。


なぜアルファードなのか:入手性+“ハンドルを切れる”条件

山口: で、そもそも、なぜアルファードを使っているのか。歴史的経緯もありますよね。

渡邉: 諸説ある前提で話すと(笑)、最初期にアルファードを一台確保したことが起点になっているのは大きいと思います。加えて、ADASの標準状態だと制約が強くて、市街地で必要な右左折やUターンのような操舵が難しい。そこでステアリング(EPS)周りのカスタム品を入手できた背景があって、アルファードと条件が噛み合った、というのが大きいです。

山口: たまたま「車両」と「EPSのカスタム周り」の両方が揃って、自動運転車両として成立しやすかった。もちろん中古市場の在庫やグレードの幅、運用面での快適さもある。実験は10時間単位になることもあるので、乗り心地が良いのは現場では効きますよね。

渡邉: はい。実験しやすいです。

山口: 次にハード構成。車両のセンサーと計算機はどうなっていますか?

渡邉: カメラは7〜8台。フロントが3カメラのパターンもありますが、最近はフロント2カメラで合計7台がスタンダードになってきています。あと測位センサーとしてGNSSとIMUを積んで、天井に1つ載せています。車内にはAGX Orinが載っていて、あとは配線、という構成ですね。

山口: 自動運転車ってもっとゴツいセンサー盛り盛りのイメージがあるけど、意外とコンパクト。で、ここで気付く人がいる。「LiDARないの?」と。

渡邉: はい、気づいてしまいましたね(笑)。

「さよなLiDAR」:外した理由は“カメラで代替できた”+“運用負債を減らす”

山口: 実はAI Dayのスライドから唯一変わったのがここで、LiDARを外しました。社内では「さよなLiDAR」って呼んでましたね。

渡邉: そうですね。最後のLiDARも外して、今はLiDAR無しです。

山口: 理由を整理すると、カメラだけで物体検出やデプス推定の精度が上がってきた。LiDARはレーザーで距離を点群で取れる一方、データ量が大きいし、雨など環境条件の影響もある。カメラのビジョンモデルで3Dボックスや点群相当を推定できるなら、運用上のメリットも大きい。

渡邉: 車両はデータ収集と自動運転の兼用ですが、LiDARは基本的に収集目的で、走行制御には直接使っていなかった。なので外しやすかったです。外すとデータ量・処理量も減るし、活用していないなら負債になりやすい。

山口: ソフト側も、センサーが減るとパイプラインもシンプルになる。これが今日のテーマの「Less is More」に直結します。


ソフトウェアアーキテクチャ:モジュール分割で変更に強くする

山口: 車載ソフトのアーキテクチャは見通しが良い設計になっていると思うんですが、どうですか?

渡邉: ロボティクスや自動運転のシステムって、センサー処理、推論、制御など専門領域が同時に動くので複雑です。ただ、各モジュールを独立させてプロセス間をつなぐ形にすると、変更しやすいし見通しも良くなる。例えばLiDARを外すなら、そのモジュールを消すだけで済む、といった具合です。

山口: このソフトウェアアーキテクチャは内部でいじり始めてかなり経ってますよね。

渡邉: そうですね。2年以上は経ってると思います。

山口: チューリングはソフトウェアの設計や要件を出して作り込んでいくというよりは、その時の要求に応じてアジャイルで作り替えていくことが多いので、その点のやりやすさもこのアーキテクチャが役立っているのかなと思いますね。

渡邉: そうですね。そういうサイクルを回しやすいアーキテクチャになってると思います。


 大きなモデルへの対応:リモート推論とeGPU

山口: 次は「様々な自動運転モデルへの対応」。チームが複数あると、モデルのサイズや要求が違う。車両は同じ基本セット。どう吸収していますか?

渡邉: そうですね。アルファードに載っている基本構成はJetson AGX Orin 1台です。この構成だけでTokyo30も達成していますが、研究用途では「もっと大きいモデルを試したい」という要求が出てくる。そのたびに車載計算機そのものを載せ替えるのは、運用的にも開発的にも現実的ではありません。

山口: そこで採っているのが、「推論だけを車外(あるいは別デバイス)にオフロードする」という設計ですよね。

渡邉:社内では「リモート推論」と呼んでいて、カメラ入力やセンサー処理、車両とのインターフェースといったリアルタイム性と安定性が求められる部分はOrin側で担当する。一方で、ニューラルネットワークの推論だけを別の計算リソースに切り出す、という構成です。

山口: 実装としては大きく2パターンありますね。

渡邉: 1つ目がワークステーション型です。Orinと外部のワークステーションをEthernetで接続し、カメラ画像を送って推論し、結果(軌跡や制御指示)だけを戻す。VLAモデルの実車走行デモでは、RTX 4090を積んだワークステーションでこの構成を使っていました。

山口: 「LANで繋ぐだけでしょ」と思われがちですが、実際はここが一番難しい。

渡邉: そうですね。特にネックになるのは画像データの転送です。
複数台のカメラ映像を、1GbEという制約のある帯域で送りつつ、レイテンシを数十ミリ秒に抑えなければならない。なので、単にソケットで投げるのではなく、プロトコル設計やデータ圧縮、転送単位の最適化をかなり細かくやっています。

山口: もう1つがeGPU型ですね。

渡邉: はい。こちらはワークステーションを丸ごと積むのではなく、GPU単体をOrinに接続して推論をオフロードする方式です。最近はUSB4やThunderbolt 4によるPCIトンネリングが使えるようになってきて、USB経由でもPCIデバイスのようにGPUを扱える。現在はAMDのRadeon系GPUで実験・検証が進んでいて、研究用途では十分に使えるレベルまで来ています。

CI/CD:ロボティクスで“実機込みの自動テスト”を回す

山口: ここからソフトウェア開発の話。CI/CDにかなり力を入れていると。

渡邉: 自動運転システムは複雑で、コード変更の影響範囲が読みにくい。速度は落としたくない。だから自動テストが重要なんですが、ハード依存があるのでクラウドだけでは完結しない部分もあります。そこでチューリングではCI/CDのパイプライン自体を強くして、変更を素早く安全に流せる形を作っています。

ユニットテストのようにクラウドで十分回せるものはGitHub Actionsなどの通常ランナーで回す。一方で、CUDAやNVIDIA系API、Arm環境など“車載に近い前提”が必要な部分は、Orin実機をCI用に並べて自動テストを回す。さらに、CPU/アーキテクチャのバリエーションが必要なところは、Namespaceのような外部ランナーも使っていて、クラウド/外部ランナー/Orin実機を“同じCIの中で同列に扱える”ように統合しています。

山口: クラウドでできるものはクラウド、CUDAやNVIDIA APIなど実機が必要なものはOrinで、という切り分け。

渡邉: そうです。さらにテスト時間もモニタリングして、長くなったら改善する。カバレッジもCodecovで可視化していて、以前は取りにくかった領域も、Orin実機テストを組み込むことで段階的にカバレッジを上げてきた、という流れです。

山口: ロボティクスの分野でここまでCI/CDを整えている会社は、まだ多くない。ここはチューリング独自の頑張っているところですね。将来的には、引退した車両そのものをCIのテスト環境として組み込む、みたいな発想もあり得ますね。

渡邉:  はい、そうですね(笑)。


フリート管理とOTA:台数が増えるほど“人手管理”が破綻する

山口: 次はフリート管理。車が増えると、デプロイが大変になりますよね。

渡邉: はい。Webのように100台へ一気にばらまく、ができない。車ごとに用途やセンサー構成が違うし、チームが使っていて「今は無理」もある。最初はExcelやNotionで管理しましたが、いろんなデータベースを紐づけると重くて破綻する。だから、車両や機材、ソフトの状態を自動取得して、Webで見えるフリート管理システムを作りました。

山口: 開発期間は3ヶ月程度。内製でクイックに立ち上げた。

渡邉: はい。最後に残っていた“自動化できてない部分”を自動化した感じです。OTAもここに統合していて、更新状況が見えます。

山口: OSレイヤーまで更新できる、というのは攻めてますね。失敗すると起動しなくなるリスクがある。

渡邉: そこでA/Bアップデート方式です。スマートフォンでも同様の形式がとられてたりしますが、A領域が現行、B領域に新しいイメージを書いて、起動確認できたら次回からBで起動という形になっています。失敗したらAに戻れるので安全性が高いですね。

Less is More:コードもハードも手順も“削る”ほど強くなる

山口: いよいよ本題。「Less is Moreの設計思想」。渡邉さんの言う“削る”は、具体的に何を指します?

渡邉: ソースコード削減、ハードウェア削減、手順簡略化の3つです。

例えば同じことができるなら、より少ないコードで実現できる方を選ぶ。使われていないコードや、歴史的に残っているだけの処理は積極的に消す。結果としてテストカバレッジも上がるし、新しく入ってきたエンジニアが全体像を掴むスピードも早くなります。

山口: 次がハードウェア。LiDARを外したのは象徴的な判断でしたが、「性能が足りるか」だけでなく、データ量・計算資源・運用負荷・故障点まで含めて見た結果ですよね。

渡邉: はい。センサーが1つ増えると、それに対応するドライバ、データパイプライン、監視、トラブル対応が全部増える。もし同等以上の情報がカメラ+ソフトウェアで得られるなら、ハードは減らした方が全体として強くなる。これはLiDARに限らず、測位センサー(GNSS/IMU融合ユニット)についても同じ考え方です。

山口: 天井に載っているデバイスが減ると、車高制限や駐車場制約といった運用上の摩擦も減る。Less is Moreは、性能だけでなく「現場で使い続けられるか」という観点でも効いてきますね。

渡邉: そして3つ目が手順です。自動運転システムは放っておくと、「この順番でスイッチを入れて、ここを確認して…」という暗黙知だらけの操作になりがちです。でもそれは再現性がなく、チームがスケールした瞬間に破綻します。

山口: 実験できる人が限られる、という状態は開発速度のボトルネックになりますよね。

渡邉:はい。なので、誰が触っても同じように立ち上がることを最優先にしています。ソフトウェアの起動順、デバイスの初期化、ログ取得まで含めて、「考えなくていい状態」を作る。これもLess is Moreの一部です。

山口: E2Eの思想も「シンプルにしてスケールで勝つ」。車載システムでも同じ思想で、ブラックボックスや依存が増えるほど運用と改善が遅くなる。ここまでソフトウェアの話が中心でしたけど、これはチューリング全体の思想でもありますよね。


今後の展望:車種対応、次世代SoC、ベンダー多様性へ

山口: 最後、今後の展望。渡邉さんのチームとして何をやっていきますか?

渡邉: 大きく3つです。1つはアルファード以外の車種への対応。2つ目は次世代SoCへの対応で、Orinの次のThorなども見据える。3つ目はNVIDIAだけでなく、他ベンダーSoCも含めて対応していくこと。量産を考えると、SoCがNVIDIAとは限らないので、ここは避けて通れません。

山口: つまり“走れるAI”を“どの車でも動く”に持っていく。これは単なる技術対応というより、事業としてスケールするための前提条件ですよね。今は自分たちの開発車両を中心に取り組んでいますが、今後はより多くの車両、より多様な計算機やSoCに対応していくことになります。アーキテクチャの工夫で吸収できる部分は最大限共通化していくとしても、やはりチームや組織の規模そのものを段階的に広げていくことは避けられないですよね。

渡邉:はい。実際にシステムを前に進め、運用まで含めて支えていくためには、エンジニアの人数をきちんとスケールさせていくことも必要だと考えています。Less is Moreは「削ること」そのものが目的ではなく、やりたいことを実現するために、できるだけ余計なものを増やさないという考え方です。たとえば、NVIDIAのSoCで動かすケースもあれば、Snapdragonなど他ベンダーのSoCで動かすケースも出てきます。そうした状況でも、それぞれにきちんと対応しつつ、共通化できる部分は極力共通化していく、という進め方になると思います。

山口:そうしたシステムを一緒に作っていく人材としては、どんなバックグラウンドの方がフィットしそうでしょうか。

渡邉:第2グループでいうと、Linuxを中心にシステム全体を見ながら開発してきた方は特に相性がいいと思います。車載や組み込みに近い領域を触ってきた方や、車のECUアーキテクチャに詳しく、その上で動くソフトウェアを書いてきた方もフィットします。
また、ソフトウェアが主軸だけれど車両やデバイスにも関わっていきたい、ソフトとハードの境界をまたいで考えることを楽しめる方には、かなり手触りのある環境だと思います。

山口:純粋なソフトウェアエンジニアであっても、車や計算機、デバイスといったハードウェアとの関わりが大きいのが、この車両システム開発の特徴ですよね。

渡邉:はい。ソフトだけ、ハードだけ、という分業ではなく、その両方を行き来しながら考えられる人にとっては、今まさに面白いフェーズだと思います。

山口:そうした仲間を増やしながら、車両システムやソフトウェアスタックそのものも、これからさらに成長させていきたいと考えています。

Q&A一覧

以降は視聴者のQAに回答していきました。詳しくは動画をご覧ください。

  • どんなセンサー構成でしょうか?(LiDAR/カメラ/ミリ波レーダー等、取得情報について)
  • LiDARなしだと雨や物影に誤認識するのでは?(センサー特性について)
  • 市販アルファードを自動運転車に改修する際、1台あたりハード追加費はどのくらい?
  • 車体ごとにインストールが異なる場合、テスト結果も異なるが統一的に管理している?

チューリングでは、完全自動運転の技術を共に創る仲間を募集しています。今日お話ししE2Eスケールアップチームはもちろんのこと、機械学習エンジニア、リサーチャー、ソフトウェアエンジニア、組み込みエンジニア、インフラエンジニアなど、非常に幅広いエンジニア職種で仲間を募集しています。ご興味のある方は、ぜひ採用ページをご確認ください。多様な職種がありますので、ご自身がどれに当てはまるか、ぜひチェックしてみてください。