役員SNS
自動運転開発の屋台骨を支えるのは、ソフトウェアエンジニア。働く醍醐味や魅力に迫る
よくカジュアル面談で、エンジニアの方から「自動運転開発で、どんな業務をしているかわからない」「ソフトウェアエンジニアの活躍の場所がわからない」という話を耳にします。そこで、このインタビューではEnd-to-End自動運転開発の第一線で活躍している安本さんと岩政さんに、今行っている開発内容について話を聞きました。
自動運転開発で「大規模データ」が必要不可欠な理由
ーーはじめに、なぜチューリングの自動運転開発で大規模データが必要になるのか教えてください。
岩政さん：従来の自動運転システムは、物体の認識、予測、プラニングを各モジュールごとに開発を行っており、ルールベースでの設計が行われていました。ただ、実際の運転には頻度は少ないものの難易度が高い状況、いわば「ロングテール」の問題があります。
※会社紹介資料より引用、ロングテール問題について解説
安本さん：ルールベース手法で、ロングテールの状況を解決するには、その状況に対するルールの追加が必要になり、どうしても限界が出てきてしまいます。そのなかで大量の走行データを活用した学習ベースのアプローチに取り組むことでロングテールの問題を解決しようとしています。
岩政さん：ただ量を集めればいいというわけではなく、質と多様性も重要になります。例えば、信号機が工事中で、かつ手信号をしている人の指示に従って運転するケースなど、日常でも稀に遭遇するシーンを走行データとして多く保有しておく必要があります。
安本さん：岩政さんが言ったとおりで、データは量と質と多様性が大事なんですね。特に多様性を担保するには、まず圧倒的なデータ量を集めなければいけません。
岩政さん ：そもそも、私たちが持っているデータセットが少ないんですね。例えば、自動車メーカーならお客さんに協力してもらい、市販車にデータ収集装置をつけて、多くのデータを収集することも可能です。私たちはメーカーではないため地道に取得しないといけません。
ーーつまり、ソフトウェアの制約すらも自ら定義付けしていく必要があるということですね。
安本さん：そうですね。車種が自社のもので限定されていれば、その車でどう達成するかを考えれば良いのですが、我々はそのような制約が現状ないため、車載カメラから何からすべて選択する必要があります。
岩政さん：安本さんがお話ししていたデータを収集するセンサーや車載カメラなどの機器だけでなく、走行ルートも天候状況や道路状況といった、環境的な変数や多様性が求められるので、非常に自由度が高いです。
非構造データの構造化とパイプライン自動化の重要性
ーー大規模なMLモデルを構築するプロセスについて教えてください。
安本さん：車から収集したデータはすべて使うわけではなくて、品質がよく、かつ多様性に満ちたデータを集めて1つのデータセットにします。そのデータを使って機械学習モデルを学習し、学習されたモデルは最終的にエッジコンピューターに搭載されます。
データの収集、保存から始まり、モデルのデプロイまでのフローのことを、一般的には、データや機械学習のパイプラインと呼びます。
岩政さん：とにかくパイプライン構築は果てしないです……。
安本さん：そうですね。機械学習のパイプラインと言えば、最後にwebサービスとしてデプロイされることの方が一般的かなと思います。一方、私たちはエッジコンピューターに搭載することを最終目標としているので、少し毛色が違うかもしれません。
ーー大規模なMLモデルの構築で、何が重要になるのでしょうか？
岩政さん：いくつかあって、1つはデータに異常がないかをチェックすること。センサーが壊れていたり、ケーブルが断線していたりなど諸要因によってデータが収集できていない可能性も考えられるからです。もう1つが非構造データの構造化です。
チューリングでは、動画やLiDAR点群、自己位置情報、センサーデータなどを時系列データとして保管したうえで、効率的に検索できるよう自動でメタデータを付与しています。
ーー安本さんは他の業界で多くのセンサーデータやテーブルデータを扱ってきていますが、それと比べて非構造データの管理・分析は大変ですか？
安本さん：大変ですね。構造化データであればSQLを流して次のテーブルに移し、それをまたSQLで加工することで解決するのですが、画像やセンサーなどの非構造データは、そのままだと扱いづらいので、まず構造化しておくことが良い場合が多いです。
さらに、私たちが扱っているデータは動画なのでサイズも比較的大きいと言えます。例えば、30FPSで撮ったら1秒間に30枚の画像が増える計算になります。つまり、8カメラで換算すると1秒間に240枚の画像が新しく保存されることになります。
岩政さん：非構造化データで難しいのは、収集したデータからどのようにロングテールなデータを抽出するかという部分ですね。
究極的には、モデルが苦手なシーンを意図的に選ばないといけないんです。学習済みのモデルで推論を行ったときに予測がうまくいかなかったり、不確実性が高かったりした箇所をデータセットに追加して、再学習させるサイクルを回す必要があります。
安本さん：モデルを車両にデプロイして、ドライバーがその車両で走行すると、基本的にはどこかで介入（機械学習モデルの結果だけを使って走行を続けると危険であるとドライバーが判断し、ハンドルやブレーキ操作を行うこと）が入ります。介入したポイントは、その時点のモデルにとって難しいデータということになりますよね。このようなデータもデータセットに追加していくことを想定しています。まさにHuman-in-the-Loop 機械学習ですね。
岩政さん：あと、データの抽象化も大事だと思っていて。チューリングは「1つの大きなAIニューラルネットワークで運転タスクを動かす」を目標に掲げていますが、これを実現するには、さまざまなサブタスクを解決しなければいけません。構造化したデータを抽象化した状態で保有しておくと、処理もかけやすくなります。汎用的にデータを使えるようにする考え方が極めて重要だと思いますね。
実験サイクルの高速化と精度向上には、MLエンジニアとソフトウェアエンジニアの連携が欠かせない
ーー従来のソフトウェア開発と、チューリングでのソフトウェア開発の違いを教えてください。
安本さん：そこまで大差はないと感じます。私たちが開発しているMLモデルは、学習に使うデータが常に増え続けているし、パイプラインも動き続けています。長期的にメンテナンスが必要なところも一般的なソフトウェア開発と共通しています。
ソフトウェア開発は、基本的には何らかのドメインをモデリングする作業であると言えると思うのですが、その観点で言うと、我々は、機械学習というドメインを扱っていると言えるかなと思っています。
だから、ソフトウェアエンジニアもMLをある程度理解していくことが求められます。例えば、ECに携わるソフトウェアエンジニアがECの仕組みを熟知していないと適切なソフトウェアを構築するのは難しいと思いますが、それと同じかなと思います。
ーー安本さんが業務を可視化して、効率化・安定化することは、MLエンジニアにどういう影響を与えるのでしょうか？
岩政さん：業務効率の向上に大きな影響を与えますね。パイプライン構築は完全に自動化するのが理想的ですが、私たちは人命に関わる自動車を扱っていて、かつ実験フェーズであるため、人力で精査することも一定必要です。
ML学習は不確実性が高い分野であるため、金銭的にも時間的にもリソースがかかってしまいます。ソフトウェアなど機械学習以外の部分で改善しないと、機械学習の実験サイクルが効率的に回らなくて良いモデルができないんですよね。
安本さん：当社では、当初はMLエンジニアが決められた手続きに従ってコードを動かしたり、目視で確認したりして、MLモデルを構築・駆動させていました。
でも、この方法は非常に大変でミスも生まれやすいし、前の実験結果が残らない場合もあるんですよね。そこで私はMLエンジニアの業務フローを可視化して、彼らの業務プロセスで効率化できる部分を探したり、ボトルネックとなっている箇所を特定したりして課題解決する動きを行っています。
岩政さん：LLM（大規模言語モデル）の分野は「質の高いデータセット」「計算リソース」「モデルのパラメータ数」の3つがあることで、大きく性能が向上するといわれています。チューリングもそれに近いと思っていて。ただ、データ基盤はソフトウェアがないとうまくワークしないですね。
ーーまさに、MLエンジニアにとってソフトウェアエンジニアは必要不可欠な存在になるわけですね。
安本さん：MLエンジニアとソフトウェアエンジニアは協調し合うポジションなんですよね。互いの強みが生かされるというか、どちらかが欠けてたら成立しない開発になっています。
岩政さん：ML出身ですが、この業界に入ってみて、MLを効率化するソフトウェアの重要性を痛感しました。結局MLも機械学習パイプラインの一要素なので、お互いの分野を理解していると、解像度高く業務ができるようになりますね。
ーーML開発において、どんなところにやりがいや面白さを感じますか？
安本さん：大きく3つあって、1つめが、動画などの非構造データを整理していくこと。モデルの精度にも直結するため、やりがいも大きいです。
2つめが、我々が扱っている自動運転というドメインがユニークなことから、機械学習のパイプラインを作る際、既存のツールやSaaSをそのまま使ったり、業界のベストプラクティスをそのまま持ち込んだりといったことが難しく、ゼロベースでの課題解決が必要となる場面が多いことです。例えば、ECやマーケティングの領域では、大きなマーケットが既に存在するため、そのためのSaaSやツールも多く存在していると思います。一方、自動運転、しかもLevel5の実現に向けたものとなると、世界的に取り組んでいる会社もまだそれほど多くない状況のため、他社事例は参考にするものの、一から検討し設計する機会が多いなと思います。
3つめが、大規模データに触れる機会があることです。チューリングでは、1日に数TB〜数十TBのデータ量がアップロードされています。このような多量かつ様々なモダリティを扱うデータ基盤に触れる機会は貴重で、エンジニアにとってはチャレンジングな環境であると言えるのではないかなと思います。
HR立石の編集後記vol.32
大規模な自動運転AI開発においてなぜソフトウェアエンジニアが必要か。MLエンジニアとソフトウェアエンジニアがどのように関わって仕事しているのか。といった疑問が解消されたインタビューでした。チューリングでは日々自動運転AI開発のアップデートがあります。今後も自動運転開発の最前線を発信し続けていきます。
ライター：俵谷Turingの中をのぞいてみたい方は、ぜひイベントに参加ください！選考意思問わずカジュアルな参加をお待ちしています。こちらをクリック
