本文へ移動

Turing TechTalk#43 エッジでリアルタイムを成立させる最適化 ─ 自動運転パイプラインの性能設計と実践

この記事に登場する人
CTO
山口 祐 Yu Yamaguchi
産業技術総合研究所 研究員/米国NIST客員研究員として研究する傍ら、独自にゲームAIの深層学習の開発を開始。日本の囲碁AIプロジェクトの開発代表として、最大1100GPUの並列分散強化学習を設計・開発し、世界大会準優勝、将棋AIでも世界大会優勝などの実績がある。HEROZ株式会社 執行役員を経て、2022年、チューリングに創業メンバーとして参画。2024年8月、CTO就任。基盤AIチームマネージャー兼任。
Driving System3チーム マネージャー
鈴木 達矢 Tatsuya Suzuki
Canonで画像処理や3次元計測、ロボットビジョンに取り組み、日産で量産に関わるシステム開発を経験。SenseTime japanで、モジュールベースの自動運転システム全体の開発に携わる。チューリングでは、E2E自動運転の開発においてシステム全体を俯瞰してさまざまな技術イシューに取り組んでいる。

はじめに

チューリングが開発する完全自動運転AIは、車載のエッジ計算機上でリアルタイムに動作しています。学習だけでなく、実際に車の中で毎秒10回、100ミリ秒以内に画像取得から推論、車両制御までの一連の処理を終える必要があり、この極めてタイトな制約のもとでいかに高速化・最適化を行うかが大きな技術的課題になっています。

今回のTech Talkでは、CTOの山口祐と、Driving System3チームのチームマネージャーである鈴木達矢が登壇。チューリングの自動運転パイプラインを題材に、ゼロコピー設計、CUDAストリームの活用、TensorRTによるレイヤー・カーネル融合、演算精度の使い分け、そしてNsight Systemsを用いたボトルネック解析まで、エッジ環境で“リアルタイム”を成立させるための技術的な工夫を詳しく紹介しました。

※本記事は「Turing Tech Talk #43」の内容をもとに、一部編集のうえお届けします。

山口:皆さん、こんにちは。Turing Tech Talk 第43回「エッジでリアルタイムを成立させる最適化 ── 自動運転パイプラインの性能設計と実践」を始めていきたいと思います。私はTuringのCTOの山口です。本日はDriving System3チームのチームマネージャーである鈴木達矢さんに来てもらっています。鈴木さん、今日はよろしくお願いします。

鈴木:よろしくお願いいたします。

山口:今日は、自動運転AIをエッジ計算機(車載コンピュータ)上でリアルタイムに動かすための高速化・最適化がテーマです。AIには学習と推論(学習済みモデルを実際に動かす処理)の2つのフェーズがありますが、今回は推論側の話が中心になります。それでは鈴木さん、簡単に自己紹介をお願いします。

鈴木:2009年、新卒でキヤノンに入社し、画像処理やロボットビジョンの研究開発に取り組みました。その後デンソーで自動運転開発に携わり、車両業界に飛び込みました。その後SenseTime japanでモジュールベースの自動運転システム開発に従事し、現在はチューリングで推論周りの開発を担当しています。在籍は1年半になります。

山口:私はチューリングのCTOを務めています。TuringTechTalkは、チューリングの最新の研究開発内容を担当エンジニアが直接解説するオンラインイベントです。今日はエッジ環境での最適化ということで、GPUやCUDA関連の話が中心になるかと思います。チューリング株式会社は2021年8月設立、本社は東京都平和島(羽田空港近くの物流倉庫街の一角)にあります。累計資金調達額は最近更新されまして365億円、社員数はまもなく100人です。事業内容は完全自動運転システムの開発で、どんな場所・シチュエーションでも人間の介入なしに運転できる、いわば究極の自動運転を指しており、こうした開発を進めるディープテックスタートアップとして日々取り組んでいます。それでは、ここから鈴木さんに説明してもらいます。

リアルタイム推論を支えるエッジ計算機

鈴木:今日は、1つのエッジデバイス上でリアルタイムに処理させるためのパイプラインの設計方法と、動かしていく中で生じるボトルネックの解析方法について解説していきます。

我々が使用しているのはNVIDIA DRIVE AGX Orin(車載用の計算機。内部にJetson AGX Orinを搭載)です。推論だけでなく、カメラやGNSS(衛星測位システム)、車載のCAN(Controller AreaNetwork、車両内の通信プロトコル)情報の取得もあわせて行っています。

デバイス上では複数のプロセスが協調して動作しています。カメラ画像や車両情報、ナビ情報を取り込み、学習済みモデルがそれを受け取って推論し、車のコントローラーに制御信号として出力します。これを10Hz(1秒間に10回、つまり100ms以内に一連の処理を終える必要がある)というリアルタイム制約のもとで動かしており、制御と並行して各種センサーデータや通信ログをストレージに保存しています。

山口:この計算機はNVIDIA製で、Ampere世代(NVIDIAのGPUアーキテクチャの1つ。現行最新はBlackwell、その前がHopperで、Ampereはさらに前の世代)の車載用に特化したチップです。スペックは約2650TOPS(Tera Operations Per Second、演算性能の指標)で、データセンター向けGPUには劣りますが、身近な例で言うとNintendo Switch 2のSoC(NVIDIA製カスタムチップ)に近い性能とイメージしていただければと思います。このパイプラインで重くなりやすいのは、カメラの画像処理とモデルの推論処理だと聞いています。10Hz・100msという制約は、たとえば言語モデルをデータセンターのサーバー上で推論サービスとして提供するような場合とは性質が異なり、少しでも遅延すればそのまま車の制御が遅れてしまう、非常にタイトなリアルタイム性が求められる領域です。

鈴木:はい、今日の話の中心もそこになります。

ボトルネックの所在とゼロコピー設計

山口:先日、ワールドカップ観戦から帰国されたばかりの本田 圭佑さんに、弊社の自動運転車で空港から送迎させていただいた動画をチューリングのYouTubeチャンネルでご紹介しました。よくできた自動運転というのは、乗っていても「自動運転をしている」ことを意識させないくらい自然になるものです。運転が上手なタクシーの運転手ほど印象に残らないのと同じで、安定して自然であることこそが良い自動運転だと感じています。

鈴木:システム設計で苦労するのは、カメラが5メガピクセルという比較的高画質であるため演算量が大きくなり、大容量画像のリアルタイム処理が課題になる点です。画像をコピーするとCPU負荷や転送遅延が増え、フレームがドロップしてしまうと、モデルは画像が順序通り届くことを前提に動いているため、車両の挙動が乱れる原因になります。それを防ぐには、コピーを発生させず同じメモリ領域からポインタで受け渡す「ゼロコピー」の実装が重要になります。

山口:計算機の内部では、ストレージからメモリへの展開、メモリからCPUレジスタへの転送など、随所でコピーが発生します。特に今回のDRIVE AGX OrinはCPUとGPUが一体化したSoCですが、内部では処理系統が分かれているため、CPUとGPUの間でデータをやり取りするたびにオーバーヘッドが生じます。

8台のカメラの映像はそのままAI推論に使うだけでなく、記録のために動画としてエンコード(圧縮)してストレージに保存する処理も同時に走っています。スマートフォンで長時間動画を撮影しているとカメラ部分が熱くなることがありますが、あれは撮影した信号をリアルタイムに動画へエンコードする処理が走っているためです。カメラ1台でもそれだけの負荷がかかるところを、8台分を同時にこなす必要があり、しかもメモリ・CPU・GPUといったリソースはすべて推論処理と共有しているため、計算機のリソースは非常にカツカツな状態になります。

鈴木:まさにそうですね。だからこそ、できる限り効率的にリソースを使い切る設計が求められます。このボトルネックを解消するため、カメラ画像の前処理から推論までを同一のCUDA(NVIDIAが提供するGPU向け並列計算プラットフォーム・開発キット)プロセスに集約し、GPUから直接参照可能なメモリ上でデータを受け渡すことで、不要なコピーとプロセス間の同期待ちを削減しています。あわせて前処理・推論・記録処理の順序をうまく制御し、リソースの競合を避けることもポイントです。

CUDAストリームとTensorRTによる高速化

鈴木:CUDAでは「ストリーム」という単位でGPU上の処理順序を制御します。CPUが1つずつ命令を出してはGPUの処理完了を待つ、という進め方をすると待機時間が無駄になってしまうため、複数の命令をまとめてストリームに投入し、GPUを常に稼働させ続けること、そしてCPU・GPU間の同期はできる限り減らすことがポイントです。

山口:なるほど。これはたとえるなら、指示を出す人と実際に働く人が2人いて、その都度「これ終わりました、次は何をしますか」と確認を挟んでしまうと仕事が進まない、という状況に近いですね。朝のうちに今日やることをまとめて指示しておき、休みなく作業を進めてもらった方が、1日のアウトプットは大きくなります。

鈴木:まさにそのとおりで、GPUを絶えず働かせ続けることが重要になります。学習済みモデルの推論には、TensorRT(NVIDIAが提供する推論高速化ライブラリ・SDK)を使用しています。TensorRTは学習済みモデルの計算グラフを解析し、畳み込みや活性化関数など連続する演算を1つのGPUカーネルにまとめる「レイヤー・カーネル融合」を行うことで、GPU起動のオーバーヘッドやメモリアクセスを削減します。また、入力サイズやGPUの種類に応じて最適なカーネルサイズを自動的に探索するチューニング機能も備えています。

山口:GPUはもともとグラフィックス、つまり映像処理のために作られたもので、大量の演算器を並列に並べ、色データなどを一斉に処理することを得意としています。その並列処理の仕組みをAIの推論にも活用しているのが今のGPUです。ハードウェアの特性を踏まえてソフトウェア側から最適な形に変換してくれるのがTensorRTというわけです。CUDAやTensorRT自体は10年以上の歴史がありますが、当初は数倍程度だった高速化効果が、NVIDIAによるソフトウェアとハードウェア双方の作り込みによって、現在では大幅に向上しています。

演算精度とゼロコピー実装の詳細

鈴木:あわせて重要なのが演算精度です。モデルの学習時にはFP32(32ビット浮動小数点)を使いますが、推論時にはその半分のFP16(16ビット)や、さらに低精度なINT8(8ビット整数)に精度を落とすことで、演算に使うメモリを削減し、データの取り回しを速くできます。低精度化は精度とのトレードオフになりますが、コンピュータは整数演算を得意とするため、INT8化(量子化)は高速化に大きく寄与します。TensorRTはこの量子化のチューニングも自動的に行ってくれます。

鈴木:ゼロコピーの実装面では、通常のcudaMalloc(GPUメモリを確保するCUDAの基本関数)は仮想アドレスの予約と物理メモリの割り当てを同時に行ってしまうため、これらを分離できる低レベルAPI(バーチャルメモリマネジメント)を用いています。これにより、プロセス間でIPC(Inter-Process Communication、プロセス間通信)を介してGPUメモリをそのまま共有する仕組みを実装しています。あわせて、過去の画像や推論結果を再利用するために、タイムスタンプ付きのリングバッファ(あらかじめ確保したバッファ数を使い回す仕組み)で時系列データを蓄積しています。画像処理と推論はCUDAストリームを共有し、同期は推論が完了した1回だけにとどめることを徹底しています。

Nsight Systemsによるボトルネック解析

鈴木:ボトルネックの解析には、Nsight Systems(NVIDIA製のプロファイリングツール)を使用しています。これはCPU、GPU、OS、DLA(Deep Learning Accelerator、GPU以外の演算アクセラレータ)など、すべてのプロセッサの処理タイミングを可視化してくれるツールです。

山口:実際のプロファイルを見ると、画像の前処理とGPUでの推論処理の間に隙間があり、GPUが遊んでしまっている状態が見つかりました。

鈴木:原因は、CPU側が画像処理の完了を待ってから次の命令を出していたことでした。また前処理のブロックが長くなっている箇所では、不要な画像コピーが発生していました。パイプライン全体では104ms程度かかっており、そのうち推論部分(FP32使用時)だけで96ms程度を占めていました。これは100msというリアルタイム制約をわずかに超えてしまう水準です。そこで、CPU・GPU間の同期の削減、不要なコピーの削減、そしてTensorRTでのFP16化を行った結果、104msだった処理時間は60ms未満まで短縮できました。FP16程度の精度低下であれば、運転の制御性能への影響はないこともこれまでの検証で確認しています。

山口:この手のプロファイル分析は、まさにエンジニアの間でよく言われる「推測するな、計測せよ」という格言そのものですね。専門知識があるとつい「こうだろう」と感覚で議論しがちですが、結局コンピュータの速度や性能を決めるのは実際に計測した結果でしかありません。自動運転そのものについても同じで、こういうアーキテクチャなら運転が良くなるはずだ、というのはあくまで仮説であり、実際に車の上、計算機の上で動かして検証して初めて確かめられます。

山口:モデルは大きいほど賢くなる一方で、パラメータ数が多いほど演算コストも増えるというトレードオフがあります。パイプラインを高速化して生まれた余裕を、より大きく賢いモデルの搭載に充てるという積み重ねを重ねてきた結果、これまで全体として2~3倍程度の高速化を実現してきました。かつてはギリギリでしか動かなかった処理も、今では余裕を持って動かせるようになっています。

チーム体制と今後

鈴木:このチームは現在、私を含めて3人体制です。もう1人は監視カメラなど別のデバイスで同様のノウハウを培ってきたメンバー、もう1人は新卒からチューリングに入りずっとこのシステムに関わってきたメンバーです。チューリングとしてもまだ5年ほどのスタートアップですが、若いメンバーと経験のあるメンバーがともに1つの課題に取り組んでいます。

山口:鈴木さん、今日はありがとうございました。非常に勉強になりました。次回のテックトーク第44回は、1ヶ月後の8月12日(水)18時から、「車両の制約下で成立させる自動運転 ── 機構と統合設計」というテーマでお届けします。次回は、いま我々が開発している自動運転車、つまり市販車にセンサーや計算機を追加改造して作っている車両について、その改造・設計・メンテナンスを支えるハードウェア技術を扱います。Driving System2チームのシニアエンジニアである山岡さんに登壇いただき、走行系・電装系をどのように設計し施工しているかを解説する予定です。

山口:鈴木さん、今日はいかがでしたか?

鈴木:今日は自分なりにわかりやすく説明したつもりでしたが、振り返るとやや難しくなってしまった部分もあり、反省点があるかなと思います。また機会があれば、皆さんにもっとうまく解説できるようブラッシュアップしていきたいと思います。

山口:今日は、ありがとうございました。

Q&A一覧(一部抜粋)

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

  • この車載計算機(DRIVE AGX Orin)はどれくらいの金額なのでしょうか?
  • ログを撮りながら10Hzで動くのがすごいです。ログはどこまで撮っているのですか?
  • システム設計とアルゴリズムは何が異なるのでしょうか?リアルタイムにするためにどういったアルゴリズムを使っているのか気になりました。
  • CPU・GPU間の同期はプロセス間の依存関係を解決するために必要だと思います。仮想メモリ部分から実装し直す必要があったと思いますが、難しかったことはありましたか?
  • 通常、学習モデルにはPyTorchなどを使うと思いますが、推論部分はどの言語を使われていますか?CUDAライブラリを直接コールしているのでしょうか?
  • 初心者でもこういった高速化のためのシステム設計を行いたいと思ったら、とっつきやすい材料などはありますか?
  • INT8を使うことでモデルを高速化するとのことですが、運転挙動やモデル精度にはどれほど影響があるのでしょうか?

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

TuringTechTalk#42 ペタバイト級データセットの作り方 ─ 学習を止めないためのスループット・再現性・運用設計

この記事に登場する人
CTO
山口 祐 Yu Yamaguchi
産業技術総合研究所 研究員/米国NIST客員研究員として研究する傍ら、独自にゲームAIの深層学習の開発を開始。日本の囲碁AIプロジェクトの開発代表として、最大1100GPUの並列分散強化学習を設計・開発し、世界大会準優勝、将棋AIでも世界大会優勝などの実績がある。HEROZ株式会社 執行役員を経て、2022年、チューリングに創業メンバーとして参画。2024年8月、CTO就任。基盤AIチームマネージャー兼任。
自動運転第4グループマネージャー
安本 雅啓 Masahiro Yasumoto
新卒で日立製作所に入社し、鉄道のITシステムの研究開発に従事。その後AIスタートアップのアラヤにて開発案件に携わり、CTOに就任。2021年4月にatama plusへ入社し、アルゴリズム開発エンジニアとしてAI教材atama+のレコメンドエンジンの開発を担当。2024年5月にチューリングに参画し、入社当初から一貫してMLOps領域を担当。現在は自動運転第4グループのMLOpsチームマネージャーとして、ペタバイト級の自動運転データパイプラインの設計・運用を推進している。

はじめに

自動運転AIの性能は、モデルそのものだけでなく、どのようなデータを学習に利用するかによって大きく左右されます。高品質なモデルを継続的に開発するためには、膨大な走行データを効率よく収集・管理し、学習に適したデータセットへ変換する仕組みが欠かせません。

チューリングでは、自社で収集した走行データがすでにペタバイト級に達しており、その膨大なデータを安定して運用しながら、機械学習モデルの学習を止めないデータ基盤の構築に取り組んでいます。

今回のTech Talkでは、CTOの山口祐と、自動運転第4グループマネージャーの安本雅啓が登壇。チューリング社内で開発・運用しているデータセット基盤「GARUDA」を題材に、ペタバイト級データセットの設計思想から、データパイプライン、ストレージ設計、開発者体験の改善、そして運用まで、その技術的な取り組みを詳しく紹介しました。

※本記事は「Turing Tech Talk #42」の内容をもとに、一部編集のうえお届けします。

山口:皆さん、こんにちは。Turing Tech Talk 第42回「ペタバイト級データセットの作り方」を始めていきたいと思います。私はTuringのCTOの山口です。本日は自動運転第4グループのマネージャーで、MLOps(機械学習の開発・運用基盤)を担当している安本さんに来てもらっています。安本さん、今日はよろしくお願いします。

安本:よろしくお願いします。

山口:今回「ペタバイト級データセットの作り方」ということで、結構大きく出たタイトルかなと思うんですけど。

安本:そうですね。大きく出ないとなかなか来ていただけないかなと思って、今回は大きく出てみました。

山口:煽り気味ですね。ただ間違ってはいなくて、言っていること自体は本当にペタバイト級のデータを扱っているので、その作り方をお話しできればと思います。実際にこのペタバイト級のデータを扱ってデータセットを作っているのがまさにTuring内部でやっていることで、その中身がどうなっているかを今日は深掘りできたらと考えています。それでは登壇者紹介です。安本さん、簡単に自己紹介をお願いします。

安本:私は新卒で日立製作所に入社し、鉄道のITシステムの研究開発を担当していました。その後、AIスタートアップのアラヤにて開発案件に携わり、CTOに就任。2021年4月にatama plusへ入社し、アルゴリズム開発エンジニアとしてAI教材atama+のレコメンドエンジンの開発を担当しました。2024年5月にTuringへ入社し、ちょうど2年と少しが経ったところです。

山口:安本さんは入社当初からずっとMLOpsに関わっていて、今はその責任者を務めています。MLOpsがまだ担当者1人という時代から、Turing社内のMLOpsを立ち上げてきて、いよいよスケールするようになってきたというところなので、今日はその歴史的経緯も含めて色々と聞いていければと思います。Turing Tech Talkは、Turingの最新の研究開発の内容を、担当エンジニアが直接解説するという企画です。今回はデータセット設計、特に自動運転というドメイン、あるいは最近でいう「フィジカルAI」(現実世界のセンサー情報を扱うAI全般を指す言葉)のドメインで、データセットをどう設計し、どう運用するかについて、幅広く応用可能な技術を取り上げます。この後、会社紹介を挟んで、安本さんから本題であるペタバイトデータセットの作り方を解説してもらいます。本日のタイトルは「実例を元に解説、自動運転モデル開発のためのペタバイト級データセットの作り方」です。

安本:実例を話すというより、MLOpsの設計やアーキテクチャに踏み込んだ話が中心になります。これからMLOpsをやりたいという方には参考になる内容かなと思います。

データパイプラインの全体像

安本:自動運転AIの学習データがどのように作られるのか、その全体像を紹介ご紹介します。Turingは自動運転の開発のために自社で車両を保有し、データを収集しています。平和島の車庫にたくさんの車両があり、それが毎日東京中、さらには全国を走り回ってデータを取得しています。このデータをいかにMLモデルへ読み込める形にするか、というのが今回のデータパイプラインの内容です。

流れとしては、まず車から上がってきたデータが、クラウド(AWS)内に格納されます。最初に入るのが「データレイク」で、これは動画や生のバイナリデータなど非構造化データを格納する場所です。ただこれだけではデータがどこにあるか分かりにくいため、そこから構造化したデータに変換して格納する場所が「レイクハウス」で、Turingでは実際の基盤としてDatabricks(データ分析基盤サービスを提供する企業、およびそのサービス)上に構築しています。レイクハウス上のデータはテーブル形式、いわばデータウェアハウスのようなものです。このテーブルのままではMLモデルに直接入力するのは難しいため、最終的にファイル形式のデータセットに変換して保存する工程があり、これが「データセット作成」で、できあがったデータセットはS3(Amazon S3、AWSのオブジェクトストレージサービス)のバケットに格納されます。さらに、このS3上のデータセットは、オンプレミスのGPUクラスターで使う際には、Lustre(大規模計算環境向けの高速並列ファイルシステム)と呼ばれるストレージシステムにダウンロードして利用します。

山口:ここまでの流れが非常に分かりやすかったのですが、何人かエンジニアではない人も聞いているかもしれないので、ベースから色々と教えて欲しいなと思います。

チューリングは自分たちで車両を持っていて、センサーをつけたりして人間が運転をしてデータを集めている訳なんですけれども、一日どれくらいの分量が取られていますか?

安本:日によってかなり変動しますが、数十テラバイトは入っているという形ですね。

山口:車両には4TBほどのSSDを積んでいますが、1日の走行で1台分が足りなくなることもあり、10台程度が走ると1日で40TB程度のデータが上がってくることもあります。これがSSD経由でインターネット越しにAWSへアップロードされ、データレイクに蓄積されていきます。すでにデータレイクに入っているデータの量が、タイトルにもある「ペタバイト級」です。普通のPCで100GBのZIPファイルを扱うだけでも時間がかかりますが、それが1000倍、1万倍の規模になるということです。保存コストも当然大きな課題です。

DatabricksとSparkについて

山口:Databricksという会社について補足しておくと、Databricksは米サンフランシスコに本社を置く未上場のソフトウェア企業で、時価総額はおよそ20兆円規模とされ、日本の上場企業でいえば時価総額10位前後に匹敵する規模です。Databricksは、Apache Spark(分散データ処理のためのオープンソースフレームワーク。Apache Software Foundation、略称ASFが管理する)を開発したメンバーが立ち上げた会社で、Sparkをエンタープライズ向けに使いやすく、また高性能にチューニングし、クラウド上で扱えるようにしたマネージドサービスです。Apache Sparkは2010年前後に登場したフレームワークで、その前身にあたるHadoopのMapReduce(分散処理の仕組みの一つ)がディスクへの書き込みを多用して低速だったのに対し、Sparkはできるだけインメモリで処理を完結させることで高速化を実現した、という歴史的経緯があります。

プロジェクト「GARUDA」

安本:今回お話しする新しいデータセット作成の仕組みには、開発時のコードネームとして「GARUDA(ガルーダ)」という名前がついています。ガルーダはヒンドゥー教などにおける神鳥の名で、インドネシアの国章やガルーダ・インドネシア航空の社名にも使われています。【大事なデータをMLモデルやMLエンジニアに届ける、そのための力強い鳥】、というイメージから名付けました。

安本:GARUDAには、社内のユーザー(Turingの車内エンジニア)に対する「4つの約束」があります。1つ目は全く新しいデータセットフォーマット(ガルーダビルダー)、2つ目は刷新された開発者体験、3つ目はオンザフライでの動画デコーディング、4つ目は圧倒的なストレージコストの効率化です。これらはすでにすべて実現されており、社内では旧システムから完全に移行が完了しています。それでは一つずつ説明していきたいと思います。

約束1:新しいデータセットフォーマット

安本:以前は、nuScenes(自動運転分野でデファクトスタンダードとなっている、複数の関連データをリレーショナルデータベースのような形で正規化して格納するデータセットフォーマット)準拠の形式を採用していました。これは拡張性が高く、アカデミアの実装や論文でよく引用されるため、既存のモデルを試しやすいというメリットがありました。一方で、nuScenes自体が公開している走行データはおよそ6時間分と非常に少なく、大規模スケールを想定した設計にはなっていません。また、1つのJSONファイルが数十GBに達し、メモリに載り切らなくなるなど、フォーマット自体にスケーラビリティの限界がありました。

安本:そこでGARUDAでは、1テーブルのみ、1レコードが1サンプルに対応するシンプルなフォーマットに変更し、必要なデータをすべてそこに格納するようにしました。これにより高速な読み込み性能と高いスケーラビリティを確保しています。ただし、キャリブレーション情報のように本来はサンプルごとに変化しないデータも、あえて冗長に持たせるトレードオフを採用しています。これは、スケーラビリティと高速な読み出しを最優先した設計判断です。

山口:なるほど。なお、車両データはほぼ映像データが容量の大部分を占めており、CAN(Controller Area Network、車内の通信プロトコル)から得られるステアリングやウインカーの情報、IMU(慣性計測装置)やGNSS(衛星測位システム)による位置・加速度情報なども含まれますが、これらのデータ容量は全体の1%以下です。またTuringのデータはカメラ(RGBカメラ)ベースであり、現状ではライダーやレーダーのセンサーデータは含めていないという状態でしたよね。

約束2:On-the-fly GPUデコーディング

安本:以前は、動画から画像を事前にすべて切り出し、学習時はその画像を読み込んでいました。これはモデル学習時の取り扱いが簡単というメリットがある一方、切り出し作業に時間がかかること、動画と画像を二重に保存するためストレージコストが増大すること、さらに動画から画像への変換時にエンコード・デコードを繰り返すことで画質が劣化する可能性がある、というデメリットがありました。

GARUDAでは、NVIDIA GPUに搭載されたハードウェアデコーダーであるNVDEC(NVIDIA Decoder、動画デコードに特化した専用回路)を利用し、学習中に動画をon-the-fly (その場)でデコードする方式に変更しました。これにより画像の事前準備が不要になり、動画をそのまま学習に使えるようになりました。デコードされたデータはGPUメモリ上に直接展開され、そのまま学習に利用できるため、CPU・GPU間でのメモリ転送というボトルネックも回避しています。

山口:一般的な機械学習では、動画を画像に分解して学習しますが、画像として保存するとデータ量が大幅に増えます。GARUDAでは、ストレージコストや転送時間を抑えるため、動画をそのまま学習に利用し、NVDECで学習時にリアルタイムでデコードする方式を採用しています。

安本:一方で、高性能なNVDECをフルに活用する必要があり、GPU1基あたり搭載されているNVDECは7基程度で、複数の動画を並列にデコードし続けるマルチプロセス処理を適切に管理する必要がありました。また前処理やデータ拡張(オーギュメンテーション)もすべてGPU上、つまりCUDA(NVIDIAのGPU向け並列計算プラットフォーム)で実装する必要があり、実装難易度は高いものの、社内のCUDAに強いエンジニアが移植を担当し、最終的に旧方式と同程度の速度を実現しました。

約束3:刷新された開発者体験

安本:以前は、データセット作成にAWS Batch(AWS上でバッチ処理を実行するサービス)とEC2(Amazon Elastic Compute Cloud、AWSの仮想サーバーサービス)インスタンス群を利用していました。本番環境は作り込まれていた一方、開発環境の整備が追いついておらず、MLエンジニアがデータセットに変更を加えたい場合はローカルでデバッグしたうえで本番にマージする必要があり、大規模実行して初めて分かるバグを踏みやすいという課題がありました。

安本:現在はDatabricksが提供するサーバーレスのSpark環境を利用し、事前にサーバーを用意しなくてもデータ量に応じて自動的にスケールするようになりました。これにより開発環境と本番環境がほぼ同一のSpark環境となり、MLエンジニアが少し試して問題なければ、そのまま本番でも同じ環境で実行できるようになったことで、バグを踏みにくくなりました。またPySpark(PythonからApache Sparkを扱うためのAPI)によりSparkやデータベースに詳しくないエンジニアでも扱いやすく、ジョブの実行も数分程度で結果が返るため、開発サイクルの速度も大きく落ちていません。

約束4:圧倒的なストレージコスト効率化

安本:以前は、異なるデータセットが同じシーン(同じ時間帯の走行データ)を参照する場合でも、それぞれのデータセットに画像を重複して保存していました。これは、メタデータと画像データが1つのディレクトリにまとまっているためポータビリティが高いというメリットがある一方、MLエンジニアが試行錯誤のたびに多数のデータセットを作成するため、重複した画像の保存コストが膨大になるという問題がありました。現在は、異なるデータセットが同じシーンを参照する場合でも、動画そのものへのポインタ情報だけを保持し、動画データ自体は重複して持たない方式に変更しました。データ利用時には、そのポインタに紐づく動画を都度ダウンロードする必要がありますが、データ容量やストレージコストの観点では圧倒的に効率的です。この変更により、同じLustreストレージ容量で扱えるシーン数はおよそ10倍に向上したとのことです。また、元の動画ファイルは変更不可(イミュータブル)かつリードオンリーとして扱われ、どのデータセットがどの動画を参照しているかをデータベースで管理しているため、不要な動画を安全に判別・削除できる仕組みになっています。

追加のトピック: AIエージェントとGUI

安本:GARUDAのリリース後の追加の取り組みとして、2点あります。1つ目はAIエージェントの活用です。Turingでは「Devin」と呼ばれるAIエージェントを導入しており、Slack上でDevinに話しかけてタスクを依頼すると、裏側で自動的に処理を実行してくれます。ガルーダの各種APIをDevinから呼び出せるようにしたことで、MLエンジニアは従来のCLIやクエリを自分で書く代わりに、自然言語でデータセットの作成や削除を依頼できるようになりました。

安本:2つ目はGUIダッシュボードの整備です。作成したデータセットがどの車両番号のデータをどれくらいの割合含んでいるか、どのエリア(例えばお台場など)のデータがどれくらいの割合を占めるかといった構成を可視化でき、また複数保有するGPUクラスターのうち、どのクラスターに現在どのデータセットがダウンロードされているかも確認できるようになっています。文字ベースの操作が得意なAIエージェントと、地図表示など視覚的な確認が得意なGUIとで、役割分担が進んでいる状況です。なお、GUI上からデータセットを直接ダウンロードする機能は現時点ではまだ実装されておらず、今後の課題です。

Q&A一覧(一部抜粋)

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

  • データはほぼ動画データなのでしょうか?それともカメラ以外のセンサデータなども含まれているのでしょうか?
  • nuScenesはLidar x1とRadarx5も含まれると理解していますが、今のご説明ではそれを除いたnuscenes互換のデータと解釈しました。違っていたらご指摘いただければ幸いです。
  • 動画の長さによって、NVDECでの処理にかかる時間が変わるのかなと思います。複数の動画を並列に処理するのか、単一動画を複数フレームで並列処理しているのか,どちらの方がいいのでしょうか?

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

TuringTechTalk#41 車両が増えても運用へ ─ OTAとフリート管理で実現する車両運用の省力化

この記事に登場する人
CTO
山口 祐 Yu Yamaguchi
産業技術総合研究所 研究員/米国NIST客員研究員として研究する傍ら、独自にゲームAIの深層学習の開発を開始。日本の囲碁AIプロジェクトの開発代表として、最大1100GPUの並列分散強化学習を設計・開発し、世界大会準優勝、将棋AIでも世界大会優勝などの実績がある。HEROZ株式会社 執行役員を経て、2022年、チューリングに創業メンバーとして参画。2024年8月、CTO就任。基盤AIチームマネージャー兼任。
Driving System1チーム シニアエンジニア
安部 敦 Atsushi Abe
大学院修了後、日本アイ・ビー・エム株式会社に入社。RAS (Reliability, Availability,Serviceability)エンジニアとして複数製品の開発やIBMテープドライブのファームウェア開発に従事。その後、テープストレージ向けファイルシステム「LTFS」の開発を担当する。2017年から2024年までIBM Master Inventorとして活動し、発明者として100件を超える特許を取得。2025年7月にチューリング株式会社へ入社。現在はDriving System 1チームにて、自動運転向け車載システムの開発に取り組んでいる。

はじめに

スクリーンショット 2026-06-25 午後2.31.02

自動運転の開発というとAIモデルに注目が集まりがちですが、実際にはAIを安定して動かすための車載ソフトウェアやOS、計算機、ハードウェアまで含めた基盤づくりが欠かせません。

今回のTech Talkでは、その中でもOTA(Over-the-Air)によるソフトウェア更新と、開発車両を効率よく管理するフリート管理システムに焦点を当てました。

チューリングでは現在約30台の開発車両を運用しており、車両の増加に伴い、ソフトウェアやセンサー構成の管理を手作業で行うことが難しくなっています。

今回はCTOの山口とDriving System 1チーム シニアエンジニアの安部が登壇し、OTA基盤とフリート管理システムについて、その設計思想からシステム構成、安全なアップデートを実現する仕組みまで紹介しました。

※本記事は「Turing Tech Talk #41」の内容をもとに、一部編集のうえお届けします。

OTAとは何か

山口:みなさん、こんにちは。今回のイベント「Turing Tech Talk #41」は、「車両が増えても運用へ。OTAとフリート管理で実現する車両運用の省力化」をテーマにお届けします。私はチューリングCTOの山口です。本日はドライビングシステム1チームのシニアエンジニア・安部さんに来ていただいています。

安部:よろしくお願いします。

山口:今回のタイトルにもなっている「OTA」は、普段あまり聞き慣れない言葉だと思います。まずはOTAとは何か、というところから教えてください。

安部:OTAは「Over-The-Air」の略で、Wi-FiやLTEなどのネットワーク経由でソフトウェアをダウンロードし、アップデートする一連の仕組みのことです。

山口:例えばiPhoneやAndroidでは、OSアップデートやセキュリティパッチが配信されますよね。あのイメージでしょうか。

安部:はい、そのイメージです。iPhoneのアップデートもOTAの一例です。

山口:スマートフォンでは当たり前になっているOTAですが、自動運転車ではどのように活用されているのでしょうか。今回は、このOTAが車両運用とどのようにつながっているのかを詳しく見ていきます。

まずは安部さんの自己紹介をお願いします。

安部:私は1998年に日本IBMへ入社し、26年間、ハードウェアとOSの間にあるレイヤーの開発に携わってきました。テープドライブの開発を長く担当し、現在はチューリングでも同じように、ハードウェアとOSの間にある基盤ソフトウェアを担当しています。OSの管理や、その上で動作するアプリケーションの基盤を整備し、自動運転AIが安定して動作できる環境を構築することが主な役割です。

山口:安部さんが所属するドライビングシステム1チームでは、車載アプリケーションだけでなく、OSやカーネル、計算機周りまで幅広く開発しています。

チューリングは自動運転AIを開発している会社というイメージを持たれることが多いですが、実際にはAIだけではなく、それを支えるソフトウェアやOS、車載計算機、さらにはハードウェアまで自社で開発しています。

安部:ソフトウェアだけでなく、ハードウェアや配線、電源周りなど、車両全体を対象に開発しています。

山口:今回は、その基盤となる車載システムがどのように管理され、どのようにOTAでアップデートされているのかをご紹介します。

今回はTech Talkでも初めて扱うテーマです。普段あまりお見せすることのない、車載システムの基盤やOTAの仕組みについて、安部さんに詳しく解説してもらいます。


車両が増えると何が難しくなるのか

山口:今回のテーマは「膨らむ更新・管理コストを、OTAとフリート管理でどう解決するか」です。現在チューリングでは約30台の開発車両を運用していますが、データ収集用の車両や実験用の車両など用途はさまざまで、運用形態も日々変化しています。

安部:そうですね。運用が変わることも多く、どの車両がどの用途なのか、常に把握し続ける必要があります。

山口:10台を超えたあたりから、手作業で車両を管理するのはかなり難しくなってきました。

安部:当初はAnsibleを使って各車両へソフトウェアを配布し、センサーの更新も手作業で行っていました。ただ、更新時にエラーが発生すると最初からやり直しになり、全車両への展開に2週間かかることもありました。また、ソフトウェアだけではなく、車両に搭載するハードウェアも変化しています。以前はLiDARを搭載していましたが、現在はすべてカメラベースの構成へ移行しました。GNSSなどの周辺機器も世代交代に合わせて入れ替わっており、どの車両にどのセンサーが搭載されているかも含めて管理する必要があります。

チューリングのFleet管理システム

山口:そこで構築したのが、今回ご紹介するOTAとフリート管理システムです。このあと、その仕組みについて詳しく見ていきます。以前よりも構成はシンプルになりましたが、その一方で、複数車両の状態をどう管理していくかが重要になってきました。

安部:約30台の車両を運用する中で、

  • 車両一覧を見たい
  • 車両に搭載されているエッジや周辺機器の情報を確認したい
  • 車両に載っていない開発用の計算機も管理したい

といった要望が出てきました。また、OTAではネットワーク経由でソフトウェアを更新しますが、更新に失敗して車両が使えなくなると、実験や開発が止まってしまいます。そのため、安全に更新できるようA/Bアップデート方式を採用しました。

このような要件をもとに構築したのが、今回ご紹介するフリート管理システムです。完成したシステムでは、車両IDごとの一覧から、それぞれの車両に搭載されているセンサーやシリアル番号、ソフトウェアの状態などを確認できるようになっています。

現在、約30台の開発車両を管理していて、それぞれがデータ収集を行ったり、AIチームが新しいソフトウェアを載せて走行実験を行ったりと、日々さまざまな用途で運用されています。

10台ほどまでは手作業で管理していました。新しいソフトウェアが完成すると、Ethernet経由でAnsibleを使って各車両へデプロイし、センサーのファームウェア更新も個別に対応していました。更新内容は文書データベースへ記録するなど、すべて手作業で管理していたんです。

ただ、Ansibleによる更新ではエラーが発生することも多く、そのたびに最初からやり直さなければなりませんでした。すべての車両へ展開するまでに2週間ほどかかることもあり、このままでは運用が成り立たないと感じ、システム化を進めることにしました。

山口:ソフトウェアだけではなく、車両に搭載するセンサー構成もかなり変わってきましたよね。以前はデータ収集のためにLiDARを多く搭載していましたが、現在はすべて取り外しています。

安部:はい。現在はLiDARは搭載していません。

山口:GNSSも新しい機種へ置き換えていますし、ハードウェア自体もアップデートが続いています。ソフトウェアだけではなく、「どの車両にどのハードウェアが載っているのか」まで含めて管理する必要が出てきたわけですね。

安部:まずは、チューリングの車載システムの構成をご紹介します。

車両には「エッジ」と呼んでいる車載計算機を搭載しており、NVIDIA Orin SoCを採用しています。エッジにはLTEモジュールとSIMが搭載されていて、外部ネットワークと通信できるようになっています。

さらに、7〜8台のGMSLカメラを接続し、ネットワークスイッチを介してGNSSなどの測位センサーから位置情報を取得しています。以前はLiDARも搭載していましたが、現在はカメラベースの構成へ移行しました。最終的にはECUへ制御指令を送り、車両を制御しています。

山口:車載システムに馴染みのない方向けに補足すると、チューリングの自動運転はカメラベースです。車両の周囲に配置した7台のカメラから取得した映像を、Orin上でリアルタイムに処理しています。また、IMUやGNSSによって車両の位置や姿勢を推定しています。

安部:GNSSはRTK補正情報を利用するため、LTE経由で外部と通信しています。また、平和島の車両基地ではWi-Fiにも接続できるようになっており、大容量のOTAアップデートはWi-Fi経由で実施しています。

山口:以前よりも構成はシンプルになりましたが、その一方で複数車両の状態を管理することが重要になっています。

安部:約30台の車両を運用する中で、「車両一覧を見たい」「開発用の計算機もまとめて管理したい」「周辺機器の情報も確認したい」といった要望が出てきました。そこで構築したのが、このフリート管理システムです。完成したシステムでは、車両IDごとの一覧から、それぞれの車両に搭載されているセンサーやシリアル番号、ソフトウェアの状態などを確認できます。

山口:ブラウザからアクセスできるWebアプリケーションになっていて、社内のメンバーは車両ごとのOSやソフトウェアのバージョンも確認できます。

安部:当初は、この管理画面から車両ごとにOTAを実行していました。ただ、30台規模になると手動運用にも限界があります。現在はスマートフォンのアップデートと同じように、車載ディスプレイへ更新通知を表示し、ドライバーがボタンを押すだけでアップデートできるようにしています。そのため、管理画面からOTAを実行することはほとんどありません。

山口:車両だけではなく、開発用の計算機も同じシステムで管理しているんですよね。

安部:はい。開発用の計算機は約75台あり、自動テストやCIで使用するマシンも、すべてこのシステムで管理しています。また、周辺機器ごとの一覧表示にも対応しています。車両・計算機・周辺機器はリレーショナルデータベースで紐付けられているため、それぞれの視点から状態を確認できます。固定資産の管理にも活用しています。


OTA基盤のアーキテクチャ

安部:OTA基盤は、AWSとMenderを中心に構成しています。フロントエンドにはVercel、データベースにはSupabaseを採用しています。MenderはOTAの配信や進捗管理を担うサービスです。OTA基盤をすべて自前で実装するよりも、実績のあるサービスを活用した方が開発スピードを上げられると考え、採用しました。また、Menderと管理画面を連携させるためにAWS IoT Coreを利用しています。エッジから送られてくる車両の状態はIoT Coreを経由し、最終的にデータベースへ反映されます。

山口:MenderはOTAイメージを配信する役割を担っています。一方で、「どの車両にどのバージョンが入っているのか」といった情報は、AWS IoT Coreを経由してSupabaseへ保存し、Vercel上のWebアプリケーションで可視化しています。

安部:車両を初期セットアップする際は、まずAnsibleでキッティングを行い、Menderへ登録します。

このときAWS IoT Coreにも自動でThing Nameが登録され、エッジはその識別子を使ってIoT Coreへ接続します。その後、接続されているセンサーやソフトウェアの状態をJSON形式でAWS IoT CoreのDevice Shadowへ1分ごとに送信しています。キッティングが完了すると、接続されているセンサーやソフトウェアの状態をJSON形式でAWS IoT CoreのDevice Shadowへ1分ごとに送信します。

山口:1分ごとの更新はかなり頻度が高いですね。

安部:目的はバージョン管理だけではありません。センサーの故障や接続断などを検知したり、エッジが正常に稼働しているかを監視したりするためにも利用しています。

山口:AWS側ではどのように処理しているのでしょうか。

安部:Device Shadowへデータが届くとAWS Lambdaが実行され、Supabaseの情報を更新します。送信するデータは1KB程度なので、負荷も非常に小さく運用できています。


OTA更新の仕組み

山口:実際のOTA更新はどのような流れで行われるのでしょうか。

安部:車両を起動すると、新しいソフトウェアがある場合はディスプレイへ通知が表示されます。ドライバーが更新を開始すると、エッジがMenderへリクエストを送り、OTAが実行されます。更新イメージは約5GBあります。LTE回線ではなく、車両基地のWi-Fiを利用して配信しており、更新時間は約10分です。ドライバーが朝出社して更新を開始し、その間に準備をしているとアップデートが完了するイメージです。

安部:ソフトウェアの作成方法も見直しました。以前のように各車両へAnsibleで個別更新するのではなく、「ゴールデンイメージ」となる基準環境を作成し、そのイメージをOTAで配信しています。

山口:ゴールデンイメージをアップロードした後は、各車両がバージョンを比較し、必要な場合だけ更新する仕組みになっています。

安部: 更新処理では、MenderがOTAの更新ハンドラを呼び出します。

Mender自体は更新処理の入口を担当しており、実際の更新処理はOTAイメージ内に含まれているスクリプトが実行します。

イメージのダウンロード後、更新スクリプトの実行、再起動、起動確認まで順番に処理が進み、最後に正常に起動したことを確認して更新が完了します。


A/Bアップデートによる安全な更新

安部:OTAでは、更新に失敗して車両が起動しなくなることは避けなければなりません。そのため、エッジにはeMMCとNVMeを搭載し、システム領域はA/Bの2つのパーティションに分けています。

例えばA領域で動作している場合は、B領域へ新しいイメージを書き込みます。更新が正常に完了したことを確認してから起動先をBへ切り替えるため、万が一失敗しても元のA領域から起動できます。SSHキーなどの固有情報は共通領域へ保存しているため、更新後もそのまま利用できます。

山口:スマートフォンのOSアップデートと同じ考え方ですね。

安部:Menderは更新処理の入り口を担当するだけで、実際の更新処理はイメージ内のスクリプトで制御しています。Dockerコンテナが正常に起動することまで確認し、問題があればエラーとして更新を中止し、元の環境へ戻るようにしています。

山口:Orinは最初からA/Bアップデートに対応していたのでしょうか。

安部:NVIDIAの開発キットでは対応していましたが、現在利用している車載計算機については、供給元に対応していただきました。

山口:現在はどのくらいの頻度で更新していますか。

安部:新しいリリースは月に1回程度です。運用管理チームと相談しながら展開し、およそ1週間で全車両への更新を完了しています。開発用の計算機は、エンジニアの作業状況に応じて更新を後回しにできるようにしています。


今後の展望

山口:自動運転業界ではSDV(Software Defined Vehicle)が進み、車載システム全体をOTAで更新することが当たり前になりつつあります。今後の改善点はありますか。

安部:現在は約5GBのイメージを配信していますが、変更のない部分まで毎回ダウンロードするのは効率的ではありません。今後は差分アップデートに対応し、更新が必要なモジュールだけを配信することで、数MBから数百MB程度まで通信量を削減できる仕組みを実現したいと考えています。

山口:車両が300台、1,000台と増えていくと、ネットワーク全体を考えた配信設計も重要になりますね。

安部:CDNやMenderのローリングアップデート機能を活用しながら、ネットワーク負荷を抑えつつ、安全に更新を展開できる仕組みへ発展させていきたいと思っています。


https://youtube.com/live/W_FeYLLch90

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

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エンジニアの方がいて、一緒に同じ目標で作っていくという環境は、インフラエンジニアにとってはとても刺激になりますよね。この面白い環境で仲間を増やしていきたいなと思いますね。


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