Turing Tech Talk 第11回 「自動運転のための大規模データレイクの設計」

2025年1月28日、チューリングではTuring Tech Talk 第11回「自動運転のための大規模データレイクの設計」と題したオンラインイベントを開催しました。

今回は、我々が自動運転をやるにあたって、そのデータをどういう風に扱っているか、それをどのように設計しているかについて、深掘りするというテーマでお話ししました。当社のCTOである山口祐、シニアエンジニアの松田和樹が登壇し、現場とマネジメント双方の目線から解説を行いました。今回は、当日の模様をイベントレポートとしてお届けいたします。

山口：皆さんこんにちは。CTOの山口と申します。Turing Tech Talk第11回を始めさせていただきます。今回は、自動運転のための大規模データレイクの設計ということで、MLOpsチームでソフトウェアエンジニアを務める松田とともにディスカッションしていきたいと思います。

はじめに、松田より自動運転のための大規模データレイクがどういう風になっているかを説明してもらおうと考えています。

松田はMLOps周り、いわゆるデータ基盤のところを一手に担ってくれている立場のエンジニアになります。では、簡単に自己紹介をお願いします。

松田：チューリングに入る前は、AWSでスタートアップ専任のソリューションアーキテクトとして、自動運転からロボティクス、またBtoB SaaSなどを開発してる会社などをメインでお仕事をさせていただいていました。

その前はインターネット広告系の会社に所属していて、割とデータが多い環境には慣れているバックグラウンドだと思っています。よろしくお願いします。

山口：よろしくお願いします。AWSから来てもらって、ちょうど1年ぐらいですか。2024年の2月頃からですよね。

松田：そうですね、ぼちぼち一年ですね。

山口：松田には、チューリングでどういう風にデータを集めるかがまだ決まっていない頃から、1年間ずっとMLOpsの分野で色々やってもらっています。

今日は、この1年でどういう風にデータをハンドリングするところを設計してきたか等を、ぜひ色々と聞いていきたいなと思っております。

改めまして、私はチューリングCTO兼Director of AIの山口です。チューリングのソフトウェア開発、AI開発を統括しています。

会社の方もぜひ紹介させてください。チューリング株式会社の創業は2021年で、もう3年半ほどになる会社になっています。昨年の12月に10億円を調達して、累計調達額が70億円になりました。従業員は現在50数名で、エンジニアもどんどん増えていっています。事業は非常にユニークで、完全自動運転車の開発です。まだ人類が誰もできていない完全自動運転の領域を目指し、非常に野心的な目標を掲げています。今日は、その完全自動運転を実現するにはどういったデータが必要なのかを、色々とお話ししていきたいなと思っております。

我々が今取り組んでいるメインのプロジェクトは、End to End自動運転のモデルを作ることです。これにはTD-1という名前がついていて、TDの略称は　T：「チューリング」や「東京」、D：ドライビングモデルを作っている、その最初のモデルとしてTD-1という名前になっております。

チューリングは今、東京都内で人間の介入なしで30分間走行するTokyo30（トウキョウサーティー）という非常に野心的な目標を掲げていますが、これを実現するために東京都内で沢山のデータ収集車を走らせて、さらにそれを学習して車を動かす、ということをやっています。

去年から実際に試験走行をしていますが、実はその前からデータは結構取っていて、これがどういう風に取られて、さらにどういう風に加工されて機械学習までやっているかを、今日はお話ししていきたいなと思っています。

ということで、ここからメインのパートで、松田から「自動運転のための大規模データの設計」についてお願いしたいと思います。

松田：はい。先ほどEnd to EndモデルのTD-1の紹介があったので、さらっとご説明したいと思います。旧来の自動運転がそもそも存在していないので、「従来のシステムに該当するものは何なのか」とよく言われます。

既存のADAS（先進運転支援システム）や、もしくはその延長にあるものは、物体検出をして、検出をした後に、検出した物体を認識してルールベースでやります。一部AIを使っているものもあるかもしれないですけれども、最終的にはルールベースで白線の内側を走ったり、いくつかのルールを組み合わせてやったりすることが多いかなと思います。

ですが、チューリングはEnd to Endなので、すごく簡素化した図が今出てるかと思いますが、8個のカメラを設置して、そのカメラの入力を元にモデルが何かしらの推論を行って、「道路の状況がこのような感じだからこういう風に走ったらいいのではないんですか」と車の経路を出す。ある意味、モデルの中身がブラックボックスのようになっているモデルを、End to End自動運転モデルとして今開発しているところです。

このモデル開発にあたっての裏側の話をしていきたいと思います。End to Endモデルの学習のためには、当たり前ですが良いデータが必要です。良いデータって定義がふわっとしているんですけども、一般には量と質と多様性の3つが重要だと言われているんですね。

1番目の量は、色々なシチュエーションに対応するためには、そもそものデータ量を膨大に集めないといけない、ということです。1時間とか2時間走っただけの車の走行データのみだと、当然ですがモデルの学習には足りないので、量を増やす必要があります。

2番目が質です。先ほど8個のカメラを積んでるという話をしましたが、カメラの他にも教師データとして正解データを取るためにLiDARを載せたり、位置情報を取るためにGPSより精度が高いGNSSのようなセンサーも積んだりしています。

そういった複数のセンサーを積んでいる場合、センサー間での誤差、社内ではキャリブレーションと呼んでいますが、そうしたものを正確に取れていないと、実際の物理空間の位置関係とモデルが認識している位置関係がずれてしまうようなことが起きます。だから、単に量を取ればいいという話ではなくて、意味のある綺麗なデータを取ることが必要です。

3番目は多様性ですね。量が多くてセンサー的にしっかり取れているデータがあったとしても、ワンパターンのデータだと意味がありません。色々な交通条件、例えば天候だったり、右左折の比率であったり、もしくは逆光とか日照条件ですね。

同じ晴れでも順光・逆光があったり、同じ曇りでも照度に結構差があったりするので、そういう様々な条件を満遍なく含んでいることが結構重要かなと思います。

実際の僕らが生活してる環境って、晴れの日と雨の日みたいに2分割できるわけじゃないので、何を条件にそのグループ化をしていくかも腕の見せ所、チューニングポイントになるかなと思います。

また、我々が集めているデータは今のところ20秒1シーンを1つの単位として、シーン数をどうやって増やしていこうか、ということをやっています。

これ、左は収集データが出ていますけれども、集めている膨大なデータをまずは一旦20秒ずつ区切って、「この20秒のシーンは右折してますね」であるとか、「この20秒のシーンは渋谷のような通行人の多いシーンを含んでいますよ」といったラベル付けをして、このシーンが綺麗に分布するようにデータセットを作っているところですね。

去年の年始はこれが100シーンや1000シーンだったんですけど、今は1万シーン、3万シーンとどんどん増えていって、直近で1番大きいものだと16万シーンという感じで順調に増やしているところです。

他社のグローバルな先行研究や先行事例だと、200万シーンや800万シーンのような事例が出ていて、一定成果が出ています。しかし、それでまだ完全自動運転ができているわけではないです。今後もこういった多種多様なデータを今までの規模以上に集めることが必要になります。

そして、このデータを集めている基盤の裏側はどうなっているかというと、ここに2.0とありますけれども、第1世代は割とプロトタイプ的な作りをしていました。そのため、去年の10月頃から刷新をして、データの持ち方を変えるようにしています。

そして今どうなっているかというと、スライドの1番左側を見てください。左側の車が収集したデータには、大きく分けてビデオ、ログ、PCDファイルの3つがあります。カメラで映してるデータは動画で、いわゆるMP4のような1分ずつの動画の形で上がってきます。それプラス、収集するシステムが取っているログデータ、このログの中には位置情報や、アクセルをどのくらい踏んでいるかなど車の情報などが入っています。そして、PCDファイルと書いてあるのは、LiDARが取っている点群ファイルですね。

クラウド側ではDatabricksを使っていますが、全てのデータを時系列データとして扱って、テーブルに格納してハンドリングしています。

過去はファイルのままオブジェクトストレージに置いているだけだったところを、テーブル形式で加工して、しっかりとした時系列タイムスタンプでインデックスを貼ることによって、「この車両のいつ時点のデータをください」といったことが綺麗にクエリが通るようになって、新しくデータを再処理したり、過去分を取りたい時に効率的に処理できるようにしています。ビジネスの柔軟性を高める上で、この構造にしました。

そのデータを貯めているところが、Databricksですね。このDatabricksに入ってるものは色々データがあるんですけれども、大部分がローデータに分類されるものです。

そして、スライド真ん中の辺りにあるDataset Creatorで、20秒ずつに区切った走行データを固めて、16万シーン含まれているデータセットを作るなどをやっています。内部的にはAWS Step Functions、 AWS Lambda、AWS Batchのようなサービスを使っていますが、それで事前に条件を書いて、バッチ処理をしてデータセットを作ることをしています。

作ったデータを基に、AWS上の学習環境であるとか、オンプレミスの、以前TechTalkにも出てきたH100を大量に持っているGaggle Clusterに持っていって学習していくことをしています。

チューリングはAI企業なので、ゴリゴリ機械学習を回していると思われている方も結構いるのですが、実際はモデルやアルゴリズムはあまり更新もしていなくて、今最も更新が行われているのはこのデータセットの部分です。

いわゆる世間一般ではデータセントリックAIやデータセントリックアプローチという言われ方をしていると思うんですけれども、データセットの中身に含まれているデータの種類を変えたり、データ量を増やしたり、データセットをいじって学習コードを法則化したら効率化はするけれども、あまり変えずにやっています。なので、我々E2Eチームの業務の大半は、「データセットをどうやって作るか」というところに分類されます。

もちろん、データセットを作るための機械学習もあるので、そういったところで機械学習の知見は活きてきます。また、このデータセットを作るときには機械学習で使いやすいように作らなければいけないので、データセットを作るオペレーションの中でも機械学習の知見を活かしています。

というのが機械学習周りの一連の流れ、大枠のところですね。

あとはあまり関係がないところで言うと、車が集めてる動画は先ほどMP4と言いましたが、実際にはタイムスタンプが含まれてない、いわゆるMacやWindowsなどですぐに再生できるような形式ではなくて、その動画の中にあるHEVCと言われる、画像が生で入っている画像コンテナの状態で持っているので、それは再生できなくて、「今日走ったデータが実際どんな感じなのかな」と見ることができません。

今配信で見られてるYouTubeとかは、画面で再生バーをシークしたら好きなとこにジャンプできると思うんですけども、そういうストリーミングフォーマットのデータ形式に変換をして持っていたり、現在進行形で持とうとしていたりとか、そういった自分たちの貯めてるデータを可視化するための画面をNext.jsやフロントエンドを実装して作っています。そして、そのフロントの画面からデータセットを作れるようにしよう、とかをしているので、関連して色々なWebの試験や技術などを使っています。

一旦そんなところかなと思います。

最後に、チューリングの基盤チームMLOps周りで最近ホットなところを軽く紹介します。炎マークをつけてみたんですけれども、先ほどデータセットをチューリングが作ってると話しましたが、だんだんデータセット作成が初期に作ったものからサイズが増えていって、1個のデータセットを作るのにすごく時間かかるようになっているので、データセットを作るところに工数を付加しようとしていますね。

これは頑張ればできそうな感じですが、実際はそのデータが、AWSのS3に溜まっています。キャッシュデータや中間データなども、S3に潜っているので、S3のAPIのリクエストのクォータに引っかかるなどして、並列数を上げたり、コンピューティングパワーを増強したりみたいなところや、意外といろんなところで上限に引っかかるようなところがあるので、そのクラウドの上限を縫っていきながら緩和して高速化しようと頑張っていたりもします。

またオンプレミスでH100のGaggle Clusterを持っているのですが、実はEnd to Endの自動運転を使っているモデルが、今LLMなどはFP16やFP8とかを量子化していく流れがあります。GPUもそっちに寄っていると思うんですけれども、我々とEndtoEndの自動運転というモデルは比較的まだFP32で計算している領域が多い。実は、必ずしもH100がベストソリューションじゃないケースがあります。もちろんH100は早いんですけれども、よりコスパの良い学習環境をなんとか提供できないかなと調整しているところです。

あと、オンプレミスのGaggle Clusterにデータを持っていく時間も結構ばかにならないというか、データサイズが大きいので、その観点でもクラウドの併用を今は進めています。

そして、今HEVCの動画でファイルを持っていて、そこからフレーム画像をJPEGで全部切り出していますが、最初は事前に切り出して、そのJPEG画像を使い回そうという設計思想を持っていました。現在、意外ともう1回切り直しのロジックを変えることなどが発生するので、できるだけ再処理しやすいようにしたいな、と考えています。

すると、オブジェクトストレージを、バイトの何番目から何番目から取るみたいなことが機能的にできるので、それを使って、事前に貼ったインデックスを使って動画の中から任意のフレームを切り出すようなことを実装できたら、より効率的に元データとデータセットの間を行き来できるようになるので、そういったことも今後やっていこうかな、というところをホットトピックで挙げさせてもらいます。

山口：ありがとうございました。今、我々チューリングがどういうことを考えていて、その上でどういう風に設計しているかという全体像を説明してもらいましたけれども、今の形になるまで結構変遷がありましたよね。

さっき2.0ってありましたけれども、1.0も当然あったわけで。その時は、さっき話の中にもあったけれど、結構S3にも直でファイルがあって、それをパイプラインとして結構頑張って処理して、最後にようやくデータセットができるみたいな感じでした。ピタゴラスイッチじゃないですけれども、ファイルを直参照してるから大変なところもたくさんありました。

だけど、これを時系列のデータベースとして保持するようにしたというのが今回の1番大きな設計変更になりそうです。

松田：そうですね。全部車から集めて、ファイルのまま置いて、それを20秒ずつに動画をエンコードするし、ログファイルも20秒ずつテキストで切るようなことをやっています。学習観点だと「ちょっと非効率だけど、データできてるからいいよね」みたいな観点はありました。ただ、今うちの車が取っているデータ収集状況がどうなのとか、他のメトリックスを取りたいとか、再利用したいなと思った時に、正規化されてないのでクエリも通らないし、現状よくわからないという感じだったので、様々なところでデータ活用できるようにしていきました。

山口：なるほど、ありがとうございます。

※以降では、参加者との質疑応答が展開されました。本イベントの全内容は、ぜひ以下のリンクからご覧ください。

【イベント概要】
Turing TechTalk #11 自動運転のための大規模データレイクの設計
https://www.youtube.com/watch?v=_S1q6c-2if4