役員SNS
MLとソフトウェアのキーパーソンが明かす！自動運転MLモデル開発の苦労と醍醐味
2024年10月30日、チューリングは独自の自動運転モデル「TD-1」（※）の開発を開始し、走行試験を開始したことを発表しました。
※TD-1……チューリングが、2025年12月に人間の介入なしで都内を30分間走行できる自動運転システムを開発するプロジェクト「TOKYO30」のための自動運転AIのこと。カメラ映像のみを入力とし、周辺地図や車両／歩行者の認識、自身の運転操作までを単一のモデルで出力するTransformerモデルとなっている。
この走行試験によってチューリングでは、物理世界からのデータ収集からAIモデル開発、エッジ環境へのデプロイ、走行までの一連のプロセスを初めて1周したことになります。大規模な自動運転MLモデル開発のプロセスを、複数の開発チームがどう連携しながら進めていったのか。そこから見えてきた課題と次のフェーズでの展望とは。
今回、ともに2024年4月以降にチューリングにジョインし、E2EチームでTD-1の開発に携わったシニアMLエンジニアの加藤利幸さん、シニアソフトウェアエンジニアの安本雅啓さんにインタビューしました。
机上の開発にとどまらず、現場で車の挙動を確認
――加藤さん、安本さんのお二人が開発に長く関わってきたTD-1が、ようやくリリースされました。まず加藤さんから、このプロジェクトにおける役割をお聞かせください。
加藤：MLエンジニアとしては、手元のデータセットの中でモデルを学習し、学習結果を評価します。例えば、テストデータに対する推論結果を数値的に評価したり、動画で可視化して考察を行います。最終的に車がどちらの方向に進めばいいかパスを出せるようにするというのがタスクの中心となります。
また、テストコースでの走行データを記録し、一連のデータをリプレイできるように保存しました。最初は単純に動画とパスを可視化するだけのものでしたがその後に確認すべき項目がどんどん増えてきたので、ビジュアライザーに表示させる項目を徐々に増やしていきました。また、現場で利用していたモデルと別のMLモデルに差し替えて推論結果を机上で検証できる体制が整いました。
――データ収集からエッジデプロイまでの一連の開発プロセスを担っていたと思いますが、その中でいちばん大変だったのはどんな開発内容でしたか。
加藤：机上での評価と、実際に車が走ったときの挙動を一致させることですね。例えば机上では道の真ん中にパスができて「このとおりに走ったらいけそうだ」という感触が得られたとしても、実際に車を走らせてみるとレーンから逸れてしまうような挙動が、とくに最初は多かったんです。その机上と実地の不一致の原因をチームのみんなで検証し、一つひとつ潰していくのに苦労しましたね。
当時は週に1回以上はKMF（※）に行き、実際に車に乗って挙動を確かめるようにしています。木曜か金曜にはKMFに行き、そこで出た課題を持ち帰って週末のうちに改善点を各自で検討し、週明けの月曜、火曜で改善のための実装を行い、水曜にモデル学習し、また木・金に実験に行く……というのが、もはやルーティーンになっていました（笑）。
※KMF（KOIL MOBILITY FIELD）：柏の葉キャンパス駅にある、走行テスト試験場。チューリングの創業期の開発を支えた場所である。なお、走行テストフィールドは2024年末より別場所に移動。オフィスからのアクセスが良くなっています
――すごい。まさに自動運転ML開発のリアルですね。
加藤：こうして現場に頻繁に足を運び、実際に車がどういう挙動をするかを全身で感じるのは、MLエンジニアとして大事なことですし、チューリングのMLエンジニアならではの醍醐味でもありますね。これまでWeb系の機械学習モデルの開発をしていたときは、モデルの評価は基本的にはインドアで作業が完結していました。ただ、自動運転ともなると、現実世界でのテストを見据えないといけません。そのスケジュールに順応するための体力が必要だと感じました（笑）。
大規模開発ならではのボトルネックを見極める難しさ
――一方の安本さんはソフトウェアエンジニアの立場から、今回の開発プロセスにおいてどんなところが大変でしたか。
安本：TD-1とは直接関係ないかもしれませんが、制御を担当するDriving Softwareチームと一緒にプロジェクトを進める中で、私たちが作成したコードとエッジ側で動いているコードの差異が発生して思うように動かないことがしばしばありました。
その課題に対応するため、現在はコードの共通化を進めています。また、双方の入出力が一致することを確認するテストを実装し、CI上で動作するようにしています。それによりチームが違っても、挙動自体は常に一致させるための担保を構築しているところです。
その作業自体も大変なのですが、加えて感じたのはチームを横断して開発を進めることの難しさです。車の挙動に問題が発生したときに、その問題がML、制御、ミドルウェアのどのレイヤーで発生しているのかの切り分けが難しいんです。私たちも他チームのレイヤーの知見や開発のステータスをすべて把握できているわけではないので、そこにチームをまたいだ大規模開発特有の難しさを感じましたね。
――安本さんはバリデータやキュレーターの実装をリードしていた印象があるのですが、そこの大変さについては？
安本：そこに関しては、実はそれほど大変ではなかったですね。基本的には、チームの中で閉じた開発となることが多かったので。
データ周りの開発よりは、実車にデプロイして動かすところやチームが複数にまたがる中でボトルネックを見極めるところが大変でしたね。
データセット作成の自動化で作業時間が3日から数時間に！
――TD-1の開発プロセスを1周回していく過程で、MLエンジニアとソフトウェアエンジニアの協業体制も徐々に構築されていったように思います。実際にどんな業務フローが簡略化されたり効率化されたりしましたか？
加藤：データセットの準備ですね。これまでは、私が手作業でツール実装をしていて、2〜3日はかかっていました。そこを自動化できないか安本さんに相談したら、クラウド環境で動き、かつスケールさせられるツールを実装してくれたんです。結果、データセットの準備が数時間でできるようになりました。
――2〜3日かかっていたのが数時間で！ すごいインパクトですね。具体的にはどのような自動化を？
加藤：最初に自動化してもらったのは、動画データの特定のシーンを切り出して機械学習のデータセットを作る「サンプリング」のプロセスです。それ以前は500シーン（3時間分）のデータセットを作るだけでも苦しかったのですが、おかげで1000シーン（6時間分）のデータセットも簡単に作れるようになりました。
次に、アノテーションされたデータから三次元物体検出モデルを学習し、その予測結果を教示データとして付与する「オートラベリング」。これまでは私が物体検出のプログラムを手元で動かしながらラベリングを実行していたのですが、そのプロセスをクラウド側で実行してもらうことによって、数千シーンを超えるようなデータセットも作りやすくなりました。
そして、シーンごとに作ったデータを統合して1個のデータセットにまとめる「マージ」の作業も自動化してもらいました。これで1万シーン（60時間分）のデータセットが作れるようになり、作業時間が非常に短縮されましたね。
――安本さん、めちゃくちゃ自動化に貢献していますね。
安本：いや、これでもまだまだですよ（笑）。究極的には、ボタン1つでGaggle Cluster（※）が自動で学習、みたいなところまでやりたいですね。
※Gaggle Cluster……96基のNVIDIA H100 GPUを搭載したチューリングの専用計算基盤。2024年10月から運用を開始。
加藤：安本さんが自動化を実現してくれたおかげで、これまではJADD（※）のデータセットを作れるのが私しかいなかったのですが、今では私以外のメンバーもある程度の規模までを作れるようになりました。この進歩はものすごく大きいですね。
※JADD……「Japan AI Driving Dataset」の略で、チューリングが独自に開発・収集した自動運転AI用のデータセット。
――ちなみに、どのタスクやフローを自動化すべきか、という優先順位づけについては、安本さんと加藤さんの間でどのように整理していったのですか？
安本：シンプルに加藤さんというN＝1のユーザーに向き合いました。加藤さんがどの作業に、どう時間を取られているのか、愚直にユーザーインタビューをしながら課題の優先順位づけをしたんです。そこからMVPを作り、α版からβ版へと実装を進めていったイメージです。
また、この自動化を実現する過程で、私も助けられたことがあります。加藤さんが、クラウドへの移行作業がどのようなものかを理解した上で、クラウドへの移行が簡単にできるように、事前にDockerfileやシェルスクリプトを書いてくれたりしました。そのお陰で、私も作業が進めやすかったです。
加藤：確かに。私も前職ではMLOpsなどもけっこうやっていましたね。
安本：加藤さんのようにソフトウェアに知見の強いMLエンジニアと協業できると、前提としてある程度の共通理解があるので議論がしやすいですね。例えば、業務が分散したときに、どこが独立して処理可能か、みたいなところでクリティカルに議論が進むんです。そういう人がいると開発は加速しやすいですね。
ただ、これまでは加藤さんだけ、N＝1の声を聞いていればよかったのですが、今後はチームのメンバーも増えていきます。仕様がまだ加藤さんしか理解できてないところがけっこう残っているので、これからはチーム内でも実装できるように仕様を周知していきたいですね。
開発をスケールさせるために解消すべき課題とは？
――TD-1の開発は一区切りついたわけですが、現在の開発課題は何でしょうか。
加藤：TD-1においては、とにかくモデルを形にすることを最優先しました。今後はデータセットを1万シーンから3万シーン、10万シーンへとスケールさせていくことが課題となります。現在はその飛躍に向けた準備期間ですね。
安本：そのシーン数を増やす過程では、クラウドデータ作成や機械学習時の学習環境などにも様々なボトルネックが潜んでいそうなので、それらを加藤さんが修正して技術負債を解消してくれているところです。
――その技術負債とは、具体的には……？
加藤：一つが、モデルを学習する際のリソースの使い方ですね。
チューリングでは今年の10月に稼働したGaggle Clusterをはじめ、CPUやメインメモリについてもかなり強力な計算リソースを持っています。
Dataloaderでストレージからデータを読んで処理する際の負荷や、バリデーションをどれくらいの頻度で実施するか、確認の動画を見るための計算リソースをどう用意するか、ONNX変換の自動化をどのリソースで行うか……挙げればきりがないですが、そういった細かい技術負債を一つひとつ解消しているところですね。
またデータセットの作成についてもスケーラビリティを高めていく必要があります。例えばオートラベリングを実施する際に1000個のGPUインスタンスを一気に立ち上げて一気に落とすなど、力技で押しきっていたところがありましたが、GPUは資源として高価なので、その力技には限界があります。
データセット作成のスケールを上げていくためにも、これからは分散並列処理やETL（Extract、Transform、Load）などによってコンピューティングリソースの配分や調整を行う必要があります。
――そんな細かいところまで考えながら、リソース活用の効率化を図っているのですね。
加藤：もう一つ、スケール化にあたって注意しなければならないのは、仮に3万シーン、10万シーンとデータ量が増えても、それに比例してモデルの精度が向上するよくなるわけではありません。
例えば1万シーンのときは2台のデータ収集車で1ヶ月分でデータ収集していたところ、10万シーンになるとデータ収集車10台で2ヶ月分のように増えます。収集車が増える分、データを統合する際に車両ごとのカメラ位置の細かい違いで誤差が生じてしまい、結果としてせっかくデータ量を増やしたのにモデルの精度が上がらない、ということは往々に起こりうるんです。このようなシーズの多いデータセットに特有の難しさを念頭に置きつつ、今後はより正確なキャリブレーションにも対応する必要があります。
「MLを全身で体感したい人」に来てほしい
――チューリングの採用選考では、「自動運転開発の経験者はどれくらいいるのか？」「自分には自動運転開発の経験はないが、問題ないか？」という質問をよく受けます。お二人から見て、今後の自動運転開発においてはどんな経験やスキルが求められますか？
加藤：アルゴリズムの観点で言うと、Computer Vision領域の知見や深層学習への知見はかなり必要だと思いますね。実務で触っていなくても、Kaggleなどのコンペティションに参加した経験があったり、普段から論文を読み込んだりしていることが望ましいです。
ただ、先ほどもお話ししたように、チューリングのMLエンジニアは机上で機械学習の論文を読んでアルゴリズムを実装する以外にも、実務ならではの多種多様な課題に日々向き合っています。一つの課題に長期間向き合えるような人、車を動かし精度をひたすら良くしていくことに情熱を注げる人がいいですね。言うなれば「MLを全身で体感したい人」かな（笑）。
それと、チューリングでは「データセントリックAI開発」を標榜しており、データの品質に徹底的にこだわっています。そのためにも他ドメインの知見を貪欲に吸収したり、チームメンバーと協力しながら様々な課題を掘り起こしたりするスタンスが求められますね。
――安本さんは、ソフトウェアエンジニアにどういったことを求めますか。
安本：MLOpsの基盤は、社内向けとはいえ、一つのプロダクトだと思っているので、プロダクト開発に向き合った経験がある方に来てほしいですね。あと、大規模なデータを扱った経験も活かせると思います。
チューリングでは、日に数十TBものデータがAWSのS3（Simple Storage Service）にアップロードされます。データレイクに上がったデータをどのような処理方法でバリデーションし、メタデータ付与を効率よく行うか、付与されたメタデータの検索をどうすれば効率化できるか、といった様々なイシューに向き合わなければなりません。
その点で、加藤さんとも重複しますが、一つの課題に長期間取り組めるかどうかは私も重視するポイントですね。とくに技術負債に長期間向き合ってきた経験のある人は頼もしいと感じます。
加藤：そうですね。私たちはこれまでは一直線に開発を進めてきましたが、これからはデータが日々蓄積されていき、機械学習のレポジトリも進化し続けます。そうなると1つのコードを維持・メンテナンスすることの重要度が高まるので、既存のコードと向き合いながら新しい機能の追加方法を考えて開発を進められる人がより求められると思います。
デプロイ先が「マシン」という自動運転開発の面白さ
――ちなみに、お二人とも自動運転ドメインの開発は未経験でした。どのように知見をキャッチアップしていったのですか？
加藤：自分に足りない知識はチームのメンバーに教わりながら都度勉強していきましたね。例えば、座標変換などはMLエンジニアとはやや異なる分野なので、入社した当初は私もあまり得意ではありませんでした。
安本：もちろん他社の技術ブログを読んだり、自動運転の論文を読んだりもします。ただ、E2E自動運転に関しては肝心なところが論文になっていないことも多いので、そこは他のメンバーと議論したり検証したりしながら進めていますね。
ただ、キャッチアップというより、単純にチームの目標、ひいては会社の目標があるので、そこから個人のタスクにブレークダウンして、いま何が必要か考える、という意識のほうが強いですね。
安本：そもそも、何をもって自動運転エンジニアと言うのか、と思うことがあります。私自身、「自分は自動運転エンジニアだ」とはあまり思っていませんし（笑）。
例えば、経費精算システムを作っている人たちを「経費精算エンジニア」とは言わないですよね。それと同じで、自動運転のドメインは特殊ではあるものの、一般的なMLエンジニア、ソフトウェアエンジニアとして取り組んできたことと大きくは変わらないというのが、チューリングに入ってみての実感です。だから、自動運転開発の経験の有無はそれほど気にしなくていいと思います。
――最後に、入社から半年以上経ったお二人が感じる、自動運転開発の面白さや魅力をぜひお聞かせください。
安本：デプロイ先が「車」なのは、自動運転開発ならではですよね。一般的なエンジニアは、最後にデプロイする先はクラウド上のサーバーであることが多いと思うのですが、車という機械に乗せて、しかも制御までする。そこがめちゃくちゃ難しいのですが、同時に他にはない面白さだと思っています。
学習に使うことができるデータセットのサイズを大きくすることができたとしても、実際に車を走らせてダメだったら意味がない。そもそもそのデータセットを下支えするデータ基盤の強化と、実際の走行・車両制御検証を行う制御エンジニアやテストドライバーの協力も不可欠です。すべてのピースの開発をバランスよく進め、うまくはめていくのが自動運転開発の難しさでもあり、面白さだと感じますね。
加藤：最近感じるのですが、どこまで課題が難しくなったり大きくなったりしても、結局やっていることは機械学習であることには変わりません。様々なデータやアルゴリズムでモデルを学習させ、実装し、挙動の変化を見ながら、うまくいかなかった原因を考える。この繰り返しですが、最終的に原因を突き止められた瞬間は本当に楽しいですね。
でも、ホッとしたのも束の間で、一つの課題を解消したら、「ここをもっとこうしたら……」という新しい課題が見えてくる。常に目の前の課題で頭がいっぱいですが、次の実験が楽しみで仕方なくなります。
安本：加藤さん、根っからのデータサイエンティストですね（笑）。E2Eチームには「至高を求める」という理念があるのですが、それをまさに体現している。
加藤：いえ、安本さんの絶妙なバランス感覚に、E2Eチームは助けられてるんですよ。
――今日のインタビューを通じて、お二人の脳内がすごくシンクロしているのを感じました。普段から密にコミュニケーションをとりながら職種やチームを超えた連携を図ることで、大規模な自動運転開発を進めていることがよくわかりました。今日はありがとうございました！
