re:Invent 2024: ContinentalとAWSによる自動運転開発のAI革新
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Transforming AV/ADAS development at Continental with generative AI (AUT307)
この動画では、AWSのIndustry Products部門とContinentalが協業して取り組む自動運転開発の課題と解決策について解説しています。自動運転車両から生成される1日50-80テラバイトにも及ぶ大量のデータ管理や、開発者がデータ検索に60-70%もの時間を費やす非効率な現状に対し、AWSとContinentalが共同開発したCAE/dgeプラットフォームと、Generative AIベースのScene Search機能による解決アプローチを紹介しています。特に、Scene Searchでは自然言語による柔軟な検索や画像ベースの類似シーン検索が可能で、開発者の作業効率を大幅に向上させた事例が具体的に示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSとContinentalの協業：自動車産業向けソリューションの開発
Jeff Maynardと申します。AWS Industry Productsという部門のProduct Directorを務め、自動車関連製品を担当しています。私たちは自動車メーカーだけでなく、Tier 1サプライヤーなどに向けて、自動車業界に特化したサービスやソリューションを開発しています。その際、Co-developmentと呼ばれるモデルを採用しており、私たちのエンジニアやサイエンティスト、プロダクトマネージャーなどが、お客様のチームと一緒に働きながら、非常に困難な変革的な課題の解決に取り組んでいます。本日は、Continentalとの協業についてご紹介させていただきます。BryanとYannが詳しくご説明いたします。
まず自律移動における課題について説明し、それらの課題をAWSでどのように考えていけるのかをお話しします。その後、Yannから、Continentalについてご紹介します。皆さんはタイヤメーカーというイメージをお持ちかもしれませんが、実際にはそれ以上の事業を展開しています。YannがAWSとの協業の経緯や、なぜこのソリューションの開発でAWSと協力することを選んだのかについて説明し、実際に私たちが一緒に開発したものをデモでお見せします。最後に質疑応答の時間を設けています。
お客様との共同開発プログラムは、大規模な変革の必要性から始まることが多いのです。数ヶ月前にContinentalと出会った際、彼らは「より少ないリソースでより多くの成果を出したい」という課題を投げかけてきました。限られたエンジニアリソースを最大限効率的に活用したいという思いがありました。顧客向けのADAS機能を開発する中で、膨大なデータを扱う必要があり、自社で管理する負担を少しでも減らしたいと考えていました。そこで、これらのニーズに応え、かつ柔軟性の高いソリューションを一緒に構築することになりました。
私たちは、自律移動やADAS機能の開発をより速く、より安価に、そしてより良いものにしていく必要があります。皆さんやご家族が車に乗った時、Lane AssistやCollision Avoidanceといった機能があることで安心感を得られるのは、Yannとそのチームのような人々が、これらの機能の開発に携わっているからです。それでは、現在の自律移動における課題について、Bryanから説明させていただきます。
自律走行開発の課題と解決策：データ管理からシミュレーションまで
ありがとうございます、Jeff。皆様、こんにちは。全員のお顔は見えないのですが、もし差し支えなければ、前の方に来ていただけると嬉しいです。 ありがとうございます。また、簡単にお伺いしたいのですが、AVやADASの開発に携わっている方は手を挙げていただけますでしょうか？はい、何人かの方が手を挙げてくださいましたね。前に来ていただいたのはそのためでした。ご協力ありがとうございます。
私はBryan Berezdivinです。過去6年間、お客様と同じような企業の皆様と世界中で自律走行機能の開発に携わってきました。これから、その課題と解決策についてご説明させていただきます。それでは始めましょう。 まず、全体像を把握していただきたいと思います。自律移動について話す際、私が指しているのは、自動運転のためのADASとAV機能を組み合わせたものです。Society of Automotive Engineersは自動運転を6つのレベルに分類しています。レベル2からレベル3への移行時に、大きな変化とハードルが存在することが分かっています。私たちの仮説、そしてお客様からも伺っている点ですが、レベル2からレベル3に移行する際、それまでのレベル2以前の自動運転機能では運転手が制御していた状態から、レベル3では車両がより多くの制御を行う状況に変わります。これにはさまざまな課題がありますが、その一つは、車両が人間のドライバーと同等かそれ以上に安全であることを確保することです。当然ながら、これらのシステムが使用可能であることを確認するために、より多くのテストと厳密さが必要になることは想像に難くありません。この分野で働いている方もそうでない方も、
ADASの威力は、自律性の低いレベルでさえ明らかです。人間が全く必要ない完全自律ではなく、低いレベルでさえも、社会に前例のない価値をもたらしています。 具体的には、米国での交通事故死を年間2万件（約60%）削減し、170万件の負傷事故を減らし、当然ながら衝突事故も減少させています。これらすべてが、皆様の車両に搭載されている最も基本的な自律機能の威力を示しています。
皆様のほとんどは、自動緊急ブレーキ、クルーズコントロール、レーンアシストなどの機能を搭載した車をお持ちでしょう。また、Full Self-Drivingに対応したTeslaや、同様のレベル3機能を備えたBMWやMercedesの車両を運転されている方もいらっしゃるかもしれません。 認識システムは、複数のセンサーで構成されており、目的に応じて異なるタイプのものが使用されています。例えば、カメラは中距離の視認性に、レーダーは長距離で多くの場合見通し外の視認性に、そしてLIDARシステムは環境の3次元ビューのために使用されています。これらのセンサーは膨大なデータを生成し、スループットは非常に高く、1日あたり約50〜80テラバイトにも及びます。
これらのシステムを開発しているお客様は、プロトタイプシステム、量産前システム、量産システムを道路上で運用する必要があり、すべてのデータが蓄積されていきます。わずか10台のテスト車両でも、年間で100ペタバイト以上のデータを管理する必要が出てくる可能性があります。 実は、すべてのデータが常にすべての開発者にとって重要というわけではありません。これらのチームは500人から5000人程度の開発者やエンジニアで構成されていますが、開発者が実際に必要とするデータは常にわずか1%程度です。実際、多くのお客様から伺っており、Yanも話すと思いますが、必要なデータを見つけるだけでも時間の60〜70%を費やしており、データの発見が一部のお客様の足かせとなっています。
開発者やエンジニアはそれぞれ異なる種類のデータセットを必要としています。異常な道路状況に関する特定のデータを探している人もいれば、事故の可能性がある場面を探している人もいます。さまざまなシーンの広い分布を得ることは、開発者が日々遭遇するあらゆる種類のシナリオに対応できる自律機能を作成するための重要な要素の一つです。 ここでいくつかの一般的なタスクを説明します。膨大なデータは特定の時にのみ必要とされ、各チームには異なる役割があります。Ground Truthデータセットを作成するためのラベリングとアノテーションに焦点を当てるチーム、AI/MLトレーニングに焦点を当てるチーム、認識モデル、計画・予測モデルのトレーニングを行い、それらをAIやDevOpsシステムで実行できるようにするチームがあります。
同様に、実世界の走行データだけに頼ることはできないため、シミュレーションが必要になります。実世界で収集したデータだけでは不十分なのです。ソフトウェアのテストに使用されるデータの約50～60%がシミュレーションデータだと聞いています。なぜなら、人間よりも安全であることを証明するには、何百万マイルもの評価と検証が必要で、さまざまなシナリオでの安全性を確保しなければならないからです。
要約すると、自律走行モビリティの開発には以下のような重要な課題があります。 まず、数百ペタバイトにも及ぶ前例のないデータ量があります。エンジニアや開発者がデータを探すのに60～70%もの時間を費やすことがないよう、効率的なデータ活用をサポートする必要があります。また、規制遵守の観点から、どのデータが何に使用されたのかを把握するデータガバナンスが必要です。
先ほど説明したアノテーションからシミュレーション、検証に至るまでの各データ駆動タスクでは、それぞれ異なるアプリケーションやツールセットを使用します。これらは独自のデータタイプやフォーマットを持っており、お客様の課題解決を支援します。シミュレーションを実行し、プログラムの変更に対応するためのシステムスケーリングコストは相当なものです。例えば、あるサプライヤーが、Robotaxiプラットフォームを持つCustomer X、自律走行トラックの顧客、そして高級乗用車でLevel 3機能を開発している顧客と取引している場合、それぞれに対して開発プラットフォームの機能をスケールできる必要があります。
では、その方法についてお話しします。 自律走行開発のライフサイクルにはいくつかのバリエーションがありますが、 この図は一般的なパターンをよく表していると思います。左側には、本番フリート、テストフリート、Hardware-in-Loop（HIL）リグ、開発者が作業を行うデスクトップなど、様々なエンドポイントがあります。そこからデータは様々なタスクに使用されます。このサイクル全体の中心にあるのが自律走行データです。これが重要なポイントです。実世界のデータ収集を評価するためのデータ処理・分析、マップ開発、ラベリングやアノテーション作業、シミュレーション作業など、すべてのタスクの中心には自律走行データが存在します。
これが、様々な顧客で見られるソリューションの概要です。では、お客様は実際にどのように対応しているのでしょうか。ここでご覧いただけるのは、機能を抽象化したアーキテクチャ図で、その概要を理解していただけると思います。これは、開発者向けにこの環境を実現するために、お客様が使用する30～50のAWSサービスに相当します。例えば、データの取り込みと処理では、AWS Direct Connectを使用したネットワーキング、データスクラビング、Elastic MapReduceやElastic Container Servicesを使用したデータエンリッチメントが行われます。データレイク側では、大多数のお客様がストレージにAmazon S3を使用し、シナリオ検索にはOpenSearchや独自のElastic SearchシステムをAWS上で利用しています。また、Amazon Auroraなどのリレーショナルデータベースを使用するケースもあり、このリストはまだまだ続きます。ここで重要なのは、各機能に多くのサービスが関連しており、お客様が抱える複雑さが相当なものだということです。
Continentalの自動運転技術とAWSとの協業プロジェクト
それでは、Continental固有の側面についてお話しするため、Yannにバトンを渡したいと思います。ありがとうございます、Brian。私からも皆様をお迎えしたいと思います。皆様がre:Inventorを私と同じように楽しんでいただけていることと、今夜のAWS Replayで素晴らしい時間を過ごしていただけることを願っています。私はYann Baudouinで、ContinentalのAutonomous Mobility部門でData Driven DevelopmentとDevOps組織を率いています。
まず、Continental Groupについてお話ししましょう。Continentalがどのような企業かは、ほとんどの方がご存知だと思います。私たちは、没入型の湾曲ディスプレイやインストルメントクラスター、素晴らしいマルチメディア機能、そして安全でインテリジェントなブレーキシステムを、すべてのお客様に提供しています。また、センサーや車載可能なあらゆる電子機器も提供しています。そして、意外かもしれませんが、タイヤも製造しているんですよ。
Autonomous Mobilityについてお話しさせていただきます。Continentalでは、20年以上にわたってADASシステムを開発してきました。2000年にヨーロッパで高度なクルーズコントロールシステムを導入した最初のTier 1サプライヤーでした。現在、私たちはADAS技術のレベル4までをカバーする様々なソリューションを提供しています。アクティブ緊急ブレーキソリューション、自動駐車ソリューション、クルージング機能などの安全機能を提供しています。また、2027年までに米国で自動運転トラック技術を実用化することを目指しています。
もちろん、私たちはソフトウェアソリューションだけでなく、コンポーネントも提供しています。カメラ、レーダー技術、LIDAR、そしてこれらのデータを処理するために必要なすべてのコントロールユニットを含む幅広いポートフォリオを持っています。スライドでは2つの技術を強調しています。私たちのハードウェアには、車両から約500メートル離れた障害物を検知する技術があり、最新世代のコントロールユニットでは、反射技術を使って車の後ろを横切る子供を検知することができます。レベル4のトラックでは、23個のセンサーが1秒間に最大1ギガバイトのデータを生成し、私たちのコントロールユニットはそれを処理する能力を持っています。
ここで、AWSとのコラボレーション、特にData Driven Developmentの分野で私たちが一緒に取り組んでいることについてお話ししましょう。この場には多くの専門家の方々がいらっしゃることは承知しています。Continentalには、Data Driven Developmentで15年の経験があります。以前は主にオンプレミスでしたが、数年前にクラウドへの移行を決定しました。現在、これがAWSと共同で設計したプラットフォームです。Continental Automotive edge computersの略であるCAE/dgeと呼ばれ、完全にAWS上でホストされており、レベル0の安全機能から自動運転機能まで、私たちの技術を開発するために必要なすべてのサービスを提供しています。
このプラットフォームでは、1日あたり最大1ペタバイトのデータを取り込み、処理することが可能です。開発に関連するすべてのメタデータ情報を抽出し、開発者が活用できるようにしています。開発者はWorkbenchを通じてプラットフォームに接続し、開発サイクルのさまざまなユースケースに対応できます。例えば、Computer Visionアプリケーション向けのMachine Learning用データセットを選択することができます。最新システムではDeep Fusionアルゴリズムを実装しており、開発者はRe-simulationを通じて開発したComputer Visionの検証が可能です。最新世代の機能を通じて大量のデータを取り込み、それに応じてパフォーマンスを評価しています。また、お客様が実環境での機能の動作を確認し、それに基づいて機能を改善するためのフィードバックループを提供しています。
サードパーティ接続も提供しており、お客様やパートナーが私たちのシステムとインターフェースを取ることができます。Deep Fusionのための Machine Learningアプリケーションについて話す際、私たちは数百万のデータポイントを扱っています。自動運転は本質的に統計的な問題です - システムが一般的なドライバーよりも信頼性が高いことを実証する必要があります。これには膨大な量のデータが必要で、シミュレーションやGenerative AIなど様々な技術を使用して異なるシーンを生成していますが、依然として大きな課題となっています。
現在、このプラットフォーム上で約150のプロジェクトが稼働しており、ご想像の通り、これらのプロジェクトはそれぞれ異なるセンサー構成を持っています。センサーは様々なサプライヤーから、時にはお客様から直接提供されるため、非常に複雑なシステムとなっています。15年かけて構築してきたこのプラットフォームでは、過去に開発したモジュールを再利用し、定期的なリファクタリングを行っていますが、現在、運用に50%以上のリソースを費やしており、これは望ましくない状況です。開発者はツーリングではなく、製品価値の向上に注力する必要があります。
スケーラビリティも大きな課題です。トラックシステムでは、約500万キロメートルのデータを再シミュレーションする必要があり、これは私たちのセンサー構成では約100ペタバイトに相当します。これを数日で処理する必要があるのです。この目標を達成するために毎日膨大な量のデータを取り込む必要があり、このスケーラビリティの問題をAWSで解決したいと考えています。自動運転は非常にダイナミックな分野で、新しい技術が次々と登場しており、多くのスタートアップが素晴らしいアイデアを持ち込んでいます。シミュレーションパートナーも同様です。しかし、これらのソリューションを既存のモノリシックなプラットフォームに統合することに苦心していました。
そこで、私たちは協業に向けた具体的な目標を設定しました。この協業ソリューションは、アプリケーションの基盤層を提供することを目指しています。目標はシンプルです：運用コストを削減し、開発者が顧客価値の創出に集中できるようにする必要があります。運用コストを60%削減するという目標を設定しました。現在、Machine Learning専門家は、データセットの収集や、雪の中での夜間の動物データの不足といったギャップの特定に多くの時間を費やしています - これは皆さんもよくご存じの一般的な課題です。この作業時間を削減し、特にGenerative AIなどの利用可能な技術を活用して、これを達成する必要があります。
Machine Learning エンジニアが運用業務から解放されることで、アルゴリズムの改善やテストループの実行により多くの時間を費やすことができ、最終的にお客様により大きな価値を提供することができます。これこそが私たちが目指していることです。 AWS との協業を通じて、私たちの開発がどのように変革されたかを見ていきましょう。AWS の標準マネージドサービスを使用して基盤層を構築し、センサーからの生データと処理済みデータの両方を保存できるようにしました。メタデータストレージを基盤層として作成しましたが、真のイノベーションは中間層で起こっています。データ駆動型開発のための基本的なデータサービス群を開発し、アプリケーションやパートナーが日常的に使用するあらゆるサービスを標準 API を通じて提供しています。
標準 API を通じて、パートナーと協力してこれらの標準インターフェースを定義・作成し、基盤層が提供するオーケストレーションなどのサービスの統合を容易にしています。もはや誰もこれらの側面を心配する必要がなく、非常に柔軟なアーキテクチャを実現しています。この基盤の最初のユーザーとなったアプリケーションの1つが、Scene Search と呼ばれるものです。このアプリケーションは、Machine Learning エンジニアや検証エンジニアが適切なシーンを見つけるのに費やす時間を削減することを目的としており、この点については後ほど Brian が詳しく説明します。
先ほど技術的負債について話しましたが、15年以上の歴史を持つクラウドプラットフォームがあり、最新技術の統合に本当に苦労していました。私たちは最新技術を早期に採用する企業の1つでしたが、モノリシックなアプローチでは導入に数ヶ月もかかっていました。これを変えたいと考えていました。これらの標準化されたインターフェースを通じて、シミュレーションパートナーなどと協力してこの状況を変えることができました。統合にかかる時間を数ヶ月から数週間に短縮し、価値を生み出し、機能開発者のニーズにより良く応えることができるようになりました。彼らは常に素晴らしいアイデアや優れたアプリケーションを持ってきますが、それを実現することに成功しました。では、Brian に戻して、Scene Search 機能についての詳細な説明をお願いしたいと思います。
Generative AIを活用したScene Search機能のデモンストレーション
ありがとうございます。それでは皆さん、Continental のコード開発への取り組みと、彼らの課題を解決するために私たちがどのように協力したかについて少しお話ししました。その成果の1つが、Generative AI ベースの Scene Search の開発でした。 Jan が言及したように、あらゆるタイプの開発者やエンジニアが、それぞれのデータ駆動型タスクを行う際に、この複雑な運転データを見つけて理解することは非常に困難です。私たちが特定した主な課題は、彼らが探し始める前に何を探したいのかを必ずしも知らないということでした。これ自体が、開発チームやエンジニアチームを支援するためのソリューションを構築する際に、私たちが重要視した側面でした。
私たちは複数の観点からアプローチしました。まず第一に、Generative AI、ML、非MLベースの検索・抽出機能を活用した最先端のアプローチをサポートする必要がありました。つまり、複数のモデルを効果的に活用するということです。ご存知の通り、私たちはマルチモーダル機能を備えた Nova を発表したばかりです。Anthropic や他の素晴らしい企業からも、大規模なイノベーションが続いています。私たちは、開発者やエンジニアごとのデータセットのキュレーションを、進化する最先端技術を活用しながらシンプルに行えるように構築することを目指しました。
さらに、Human-in-the-loopによって作成されたカスタムアノテーション、他のMLパイプラインやMLサービスによって作成されたアノテーションを、Continentalのような規模の企業が取り込み、既存の投資から価値を得られるようにしたいと考えています。多くの企業は、再利用可能な数百、場合によっては数千のパイプラインを持っています。同様に、お客様が自然言語による検索と構造化された検索の両方を組み合わせた形で、Semantic Searchを活用できるようにしたいと考えています。皆さんの多くはおそらくChatGPTや類似のインターフェースを使用されていると思いますが、これらのLLM（Large Language Model）がどのような能力を持ち、マルチモーダルモデルとしても進化していることを実感し始めているでしょう。私たちは、開発者やエンジニアが無限のクエリ機能を持てるようにしたいと考えています - 彼らは何でも検索できます。空にいるカモメを探したいなら、それもできます。歩行者を探したいなら、それもできます。
雨の中でグレアのある状況での歩行者を探したい場合でも、それが可能です。そして、そのクエリを実行して必要な重要な運転シーンを見つけるために、事前に何かが存在している必要はありません。これらのエンジニアや開発者の主なユースケースは、素早く可視化して、それが真のPositiveなのか、あるいは関連性のないFalse Positiveなのかを判断する必要があることです。そして、それに応じてデータセットを作成する必要があります。
そこで、私たちは問題を3つの主要なコンポーネントに分解しました。 1つ目は抽出部分で、複数の異なるタイプのモデル、マルチモーダルモデル、LLM、Object Detection、オープンソースモデルを活用し、フレーム全体やビデオスニペットの複数フレームにわたるGlobal Embeddingを行うか、Local Embeddingを行うかに関わらず、それらを組み合わせて最先端の機能を実現できるようにしました。2つ目のIndexingとQueryingでは、スケーラブルなソリューションをサポートすることです。数百ペタバイトのデータに関連する膨大なフレーム、アノテーション、時系列データを検索して意味を見出す必要があることについて話しました。スケールが本当に重要で、多次元マルチモーダルアプローチをサポートすることは、実際にかなり複雑なプロジェクトでした。最後に、キュレーションの可視化とアクティビティをサポートすることが重要で、お客様やContinentalにとってそのインタラクションを簡素化できるユーザーインターフェースを持つことが必要でした。
では、私たちが構築したものの簡単なデモをご紹介させていただきます。 このデモで使用するデータは、BostonとSingaporeで収集されたオープンデータセットのnuScenesからのものです。これは行動の面で最も複雑な都市部のシーンで構成されています。画面に表示されているのは、私たちのAPIと連携するWebベースのインターフェースです。非常にシンプルで、クエリボックス、Structured Searchのオン/オフ切り替え機能があります。SemanticサーチとSimilar Image Search機能をお見せする予定です。また、必要に応じて画像をアップロードし、True Positiveと判断したシーンをキュレーションする機能も備えています。これらは、アノテーションやシミュレーションなどのダウンストリームアプリケーションで使用されます。
ここでは、工事用コーンを探すための簡単なクエリを実行してみます。 多くの場合、工事用コーンを特定するための認識モデルを必ずしも構築する必要はありません - 構築する場合もあれば、そうでない場合もあります。しかし、構築しない場合でも、開発者やエンジニアは運転データからこれらのものを検索する機能を持つことができます。ご覧のように、いくつかの結果が表示され、これらをプレビューして、True PositiveかFalse Positiveかを素早く判断できるキュレーションユースケースをサポートしています。
Semantic Searchは一般的に、非常に正確である必要はないということを覚えておくことが重要です - その目的は、網ですべての魚を捕まえるようなものです。 この例では、工事用コーンを探すように修正を加えましたが、それに加えて、 雨の中の歩行者も検索できるようにしたいと考えました。ご覧の通り、雨が降っているように見える曇り空や水たまりがある場合でも、実際には雨が降っていないケースもあり、これらは誤検出として表示されます。
もちろん、これを改善するために様々なモデルの組み合わせを検討し続けています。これにより、開発者が一般的に行っているような、このようなシーンを見つけるためだけに新しいML Pipelineを作成する必要がなくなり、時間を節約できます。システムとやり取りする開発者として、多数の検索結果から素早く必要なものを選択し、必要に応じてエクスポートできるようになっています。
これは私が、誤検出と正検出を確認するために、関連する異なるシーンを確認している様子です。インターフェースが工事用コーンのような一般的なものを検索しているシナリオが見えます。ここで皆さんにお見せしたいのは、 まったく逆のケース、つまり完全なアウトライアーを検索することです。これは、テストや予期せぬ動作で発見された問題に基づいて、Perception SystemやAutonomous Mobility Systemが問題を抱えている可能性のあるケースです。どんなものでも検索できます。この例では、道路上のニワトリを検索していますが、 シンガポールでは実際にかなりの数が見つかりました。 シーン内でそれらの正検出を特定することができます。
次にデモンストレーションする機能は、Similarity Searchを使用する場合です。Semantic Natural Language Similarity、Image、Structured Searchをすべて1回で組み合わせることができ、データの正確な検索と不正確な確率的検索の両方が可能です。ここでも、ご覧のようにニワトリの画像の検索結果が表示され始めます。
自律走行開発の未来：データ駆動型アプローチの重要性
以上でデモは終わりです。最後に簡単なまとめと行動への呼びかけをさせていただきます。 本日お話ししたすべての中心にあるのは、走行データ - つまり、カメラ、Radar、LIDAR、そしてJanが言及したContinentalが製造するControl Unitからの時系列データなど、マルチモーダルで多次元のデータです。これは自律走行開発ライフサイクルのあらゆる段階の中心となっています。さらに、複雑なToolchain、それらを統合するための時間、そして各Toolchainが異なるデータフォーマットとスキーマを持っているという複雑さに対処する必要があり、これがデータ駆動型開発を実現するための鍵となっています。
Continentalでは、自律走行開発のための標準化されたフレームワーク - 実質的にミドルウェアのような抽象化を作成することで、時間とコストを削減することができました。そして最後に、Scene Search機能による簡素化されたデータ抽象化によって、開発者の日々の作業をより効率的に進められるようになりました。アクションとしては、このコラボレーションアプローチについてもっと詳しく知りたい方は、担当者までお気軽にご連絡ください。私とJanとJeffを代表して、お時間を取っていただき、このセッションにご参加いただき、ありがとうございました。可能な際にはフィードバックをいただければ幸いです。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion