車載ソフトウェア開発の挑戦！自動運転を支えるデータ処理と開発の舞台裏

昨年10月に始動した「自動運転システム統合プロジェクト」。さらなるシステム増強を目指し、データ収集システムと制御系システムを統合する一大プロジェクトです。今回は、同プロジェクトを担当したDriving Softwareチームの徳弘さんに、プロジェクトが立ち上がった背景や課題、今後の展望などについて話を伺いました。

膨大なデータ処理を支える。自動運転システム統合プロジェクトの舞台裏

ー「自動運転システム統合プロジェクト」が生まれた背景について教えてください。

当初はデータを収集することを目的にシステム開発・運用を行っていましたが、AIモデルが完成したタイミングで、リアルタイムでAIの推論を回して車制御を行うシステムも必要になったんです。社内で使用していた自動運転システムのベースとなるソフトウェアは、データ収集を行うシステムと互換性がない状態でした。このままだと、「データを収集するシステム」と「車制御を行うシステム」の2つを同時に開発・運用する必要が出てくるため、2024年10月に自動運転システムに統合するプロジェクトが始動しました。

ー当時、抱えていた技術的課題について教えてください。

技術的な課題としては大きく3つでした。まず1つめが先ほども触れた異なる2つのシステムを同時に開発・運用しなければならなかった点ですね。システムの規模が大きいため、それぞれ個別で不具合や故障などが発生すると、それだけで工数が逼迫してしまいます。

2つめがハードウェアの構成が一部違うシステムを扱っていたこと。この場合、データ収集車の使い分けやマネジメントが求められます。

3つめが、今使用している計算機では計算能力的に今までのデータ収集ソフトウェアと推論制御ソフトウェアを同時に動かせない点です。同じ計算機を使って今まで処理・記録していたデータの品質を落とさずにAI推論を実行するのはリソース的に厳しかったです。

ー確かに、実車にAIを搭載するとなると、今までとは比べものにならないほどに変数が増えそうですね。

そうですね。一連の流れとしては、まずカメラから取得したデータをカメラごとの個体差に合わせてサイズ加工・補正をかけたのち、モデルに入力して推論を進めます。同時に、撮影した画像を動画に変換してからストレージに保存、さらにそのデータを収集というサイクルを繰り返します。

確実にデータを記録し続ける状態を維持しながら、空いたリソースを使って正常にモデルが駆動するための制御・バランスを行うんです。計算機が計算できる量は決まっているため、キャパシティをコントロールするのは非常に難しいと思いますね。また、システムのユーザーが操作するアプリケーションやセンサ制御のソフトウェア開発から、ブートローダーやカーネルに起因する不具合の対策もした上でのAI実車搭載の開発をしています。そのため、さまざまなレイヤーを理解・把握して課題や不具合に対処しないといけません。

ーこのプロジェクトが始動したときは、率直にどのように感じましたか？

「ついに来たか……！」という感覚でした。いずれ統合するだろうなというのは、メンバーみんなが薄々感じていたんじゃないですかね。

ただ、たくさんの車で運用するためハード・ソフトの構成管理をしっかりしたいという要件や、データを収集して抜け漏れなく保存する要件と、 さまざまな実験を複数回試したいというAI開発の要件が、相性の良いものではなかったんです。

そのため、1つのシステムに統合するのは難易度が高いなと感じていました。

高速な仮説検証サイクルを回し、プロダクトを磨き込む

ー具体的にどのような形で開発を進めていましたか？

スクラムというチーム開発手法を採用していました。2週間のスプリントという単位でゴールを定め、ゴールの達成に必要なタスクを洗い出して取り組み、それを繰り返すというものです。稼働中のシステムのトラブル対応や改善など、新機能開発だけではなくオペレーション業務も担当しています。そのため、リーダーが優先度を適宜変更しながら柔軟に開発を行っています。

ー統合プロジェクトで、印象に残ったことや大変だったことを教えてください。

コードが膨大かつ複雑であるため、開発者1人が全てを理解できない状態になっていたことです。気づいたら新しい機能が追加されていた、なんていうこともよくあります。

たった1つの機能が追加されただけでも、それに依存・影響を受ける機能が多いと思いもしないところで不具合が発生することもあるんですよね。

ピタゴラスイッチのように、システムが大きくなればなるほどコードの依存関係が複雑化するため、最終的にコードを大幅に変更したことが印象に残っています。

ー開発が盛り上がった時期はチームで平和島ラボの拠点によく集まっていました（※）。具体的にどのようなことをしていましたか？

※現在はメインの開発拠点を大崎から平和島ラボへと移しています

システムとしてある程度形になってくると、システムを構成する全てのハードウェアが繋がった状態で動作確認やデバッグをしないといけない場面も増えてきました。そのため、実際の運用環境により近いように車のそばで開発することが多いです。

実車を走らせてみて、初めてわかる情報は非常に貴重だと感じましたね。例えば、LiDARを机の上に置いて計測した場合と実際に走行している車に載せた場合では、データのサイズが違います。そのため、システムを載せた車を実際に走らせないと確認できないことはたくさんあります。自動運転に限った話ではなくて、おそらく現物が関わるソフトウェア開発はどれも同じではないかと思います。

「完全自動運転」のAI・システムが安定して動くことを”当たり前”にしていくことが価値

ー自動運転の組み込みソフトウェア・ミドルウェア開発の面白さは？

業務で扱う技術的な面白さももちろんあるのですが、安全性や保安基準といった必須要件を満たしたうえで、自動運転を支える機能を自らの手で開発できることですね。今は公道での試験走行にも取り組んでおり、日々チャレンジングな実験ができているので、とても面白いです。

ー自動運転におけるミドルウェアの価値や真価はどこにあると思いますか？

「意識せずに使えるソフトウェア」にしていくことにミドルウェアの価値があると思っていて。例えば、皆が普段使っている電気やガス、水道なども多くの人の力や技術のうえに成り立っています。

インフラという言葉がまさにぴったりな表現で、信頼性・安定性に価値があると思います。Turingの自動運転システムはまだ量産したり商品として販売しているわけではありませんが、大量の学習用データを収集するために1台・1日当たりの運用時間が10~18時間と長いため安定性が非常に重要になります。そのためにはアプリケーションはもちろんのこと、より低いレイヤのソフトウェアの品質の継続的な改善が必要不可欠です。

ー今後の展望について教えてください。

データ収集制御システムを開発していないエンジニアチームでも、AIモデルを使って実験をしたり、データ収集機能を使った走行ができる状態までシステムが成熟してきました。

ただ、これはスタートラインに立ったに過ぎません。今構築しているシステムにリプレイスしつつ、実車10台〜20台の同時運用に耐えうる品質を担保するというミッションが待ち受けています。

さらに、開発組織が大きくなれば、それに伴ってソフトウェアの規模や機能が拡張していきます。いかに「この人でないと動かせない」という属人性から脱却できるかがカギになると思っています。まずは、ツールやドキュメントなどを活用し、技術的な知見を共有できるようにしたいですね。

また、チューリングが掲げるミッションは「完全自動運転を実現する」ことです。これを踏まえると、今の計算機やエッジデバイスだけでは、いずれ性能的な限界を迎えます。複数の計算機を組み合わせたり、今後出てくるであろう次世代の計算機を使って今よりも大きなAIモデルが動くシステムを構築していきたいです。

また、チューリングの開発はここからが本番です。まずは中の構造を意識しなくても、車を動かせるようになるまで安定化させるところまで品質を高めていきたいです。