Sonatus AI テクニシャン・ビルダー

00:00 概要

『Driving Innovation 』の新たなエピソードへようこそ。このポッドキャストは、自動車業界を「ソフトウェア定義のイノベーション」という新たな時代へと導く最先端のソリューションやテクノロジーを探求することを目的としています。

本日は、適切なSDVインフラによって支えられた人工知能が、OEM各社がシームレスで快適なカーライフ体験を提供できるようどのように後押ししているかについて詳しく見ていきます。

今回の対談には、Sonatusの「AI 」技術者向けビルダーのプロダクトマネージャー、スティーブ・ストッダード氏をお迎えしています。

スティーブは、この革新的なソリューションが、強力なAI とリアルタイムの車両データをどのように活用して、車の所有やメンテナンスを簡素化しているかを、私たちに解説してくれます。

また、こうした高度なアプリケーションを実現する基盤となるSDV技術についても探っていきます。

それでは、始めましょう。

01:00 先進自動車技術の複雑さ

スティーブ、Driving Innovation へようこそ。サンジェイ、ありがとう。ここに来られて嬉しいです。ご出演いただきありがとうございます。今日の自動車には、多くの技術が詰め込まれています。

また、それらは非常に複雑化しています。この複雑さが人々にどのような課題をもたらしているのでしょうか？

そうですね。それは素晴らしい質問です。ドライバーにとってよくある問題の一つは、車両の警告灯やダッシュボードに表示される記号に対する誤解だと思います。そのため、多くのOEMメーカーは、そうしたことを理解してもらうためにデジタル版取扱説明書を作成していますが、それらは「それらの記号が実際に何を意味するのか」「実際にどう対応すべきか」という点を見落としている傾向があります。 整備士にとっては、デジタル化が進むにつれて、部品を丸ごと交換せざるを得なくなったり、DTCや信号コードの増加に伴い、それらが何を意味するのかについてさらに混乱が生じたりしていると思います。また、OEMにとっては、車両全体を通じて実際に何が起きているのか、どのような問題が発生しつつあるのかという洞察を得られず、その結果、リコールを回避できないという問題に直面することがよくあります。

さて、今回はソナタの「AI 」テクニシャン・ビルダーについてお話しします。おそらく、こうした問題の多くは「AI 」のようなテクニシャンを活用することで解決できるとおっしゃるでしょう。そこで、「AI 」テクニシャンとはどのようなものなのか、またこのソリューションにおける「ビルダー」の部分にはどのような内容が含まれているのか、詳しく説明していただけますか。

そうですね。その通りです。私たちが分かったことの一つは、こうしたツールの利用者の多くが、自分の車両で何が起きているかというリアルタイムの情報について、十分な把握ができていないということです。ご存知の通り、AI の分野では、今日、多くの進歩が見られます。

また、車に問題があった場合、Googleに尋ねたりChatGPTに質問したりすることはできると思いますが、問題は、得られる答えがインターネット上の情報や、彼らがあなたの車の状況をどう推測しているかに基づいているという点です。 本当に欠けているのは、その車両との接続部分、つまりデータ接続と、その質問に答えるために必要な、その背後にある情報へのアクセスです。そこで私たちが気づいたことの一つは、AI の技術者たちが活動するために必要な基盤技術は、ソフトウェア定義車両（SDV）に大きく依存しているということです。データを収集する能力、例えばSonatusの製品であるCollectorAI のようなものや、車両内で実際にアクションを起こす能力こそが、この機能を前進させ、車両で利用可能にする上で非常に役立つのです。

03:09 「Sonatus 」のご紹介AI テクニシャン

基盤となる技術について話す前に、先ほどSDVについて言及されましたね。もちろん、AI もこれに関わっています。ここでは、AI の技術者が、この技術と関わる可能性のあるさまざまなユーザーに対して、どのようなサポートができるかに焦点を当ててみましょう。具体的には、オーナー、サービス技術者、さらにはOEMのエンジニアといった方々です。ええ、その通りです。

つまり、これらは3つの非常に優れたユースケースであり、この種の製品の想定ユーザーとなります。

ユーザーや車両の運転者、所有者にとって、AI の整備士が支援できることの一つは、車両内で起きている可能性がありながら、すぐには把握しにくかったり、理解しにくかったりする事象を理解できるよう手助けすることです。 例えば、エンジンに問題があるにもかかわらず、「チェックエンジン」ランプが点灯しないといった状況を想像してみてください。AI の技術者は、実際に何が起きているのかを解明し、オーナーに対して整備に出すべきかどうかについてアドバイスを提供することができます。 また、その際、事前に整備士にデータを提供することも可能です。これにより、整備士は車両の状態をより容易に診断でき、お客様が車両を持ち込まれた際に適切な部品をすぐに用意できるようになります。その結果、部品がようやく到着する3週間後に再来店する必要がなくなり、長期間にわたって車両を使用できないという事態を回避できます。

また、OEMにとっては、車両群レベルからサービス拠点に至るまで、そのデータを収集できるようになるため、新たに発生しつつある問題を把握し、自社の車両群で何が起きているかをより深く理解することが可能になります。これにより、次世代車両の改善を図ったり、問題が拡大した場合に発生しかねないリコールを未然に防いだりすることができるようになります。

AI の技術者が収集した情報が、OEMブランドのサービスショップに提供されることを考えれば、オーナーである私にとって、そうしたショップを利用しようという動機付けになるのは理解できます。このようなソリューションが、ユーザーだけでなくOEMにとっても、全体としてどのようなメリットをもたらすのでしょうか。

そうですね。その通りです。まさにその通りですね。こうした洞察があれば、ディーラー直営の整備工場でのサービス体験は、よりスムーズで、はるかに効率的になります。

そうすることで、サービス業務の効率化が図れます。さらに、OEMにとっては、そのプロセスや所有体験全体を通じて、顧客に満足感をもたらすことにもつながると思います。その結果、顧客ロイヤルティが高まり、「この車を所有してとても良い体験ができたから、今後もこのメーカーを使い続けよう」という意識が生まれます。次の車も、同じメーカーから購入しようと思うようになるのです。

そう。そう。

05:31 Builder を使った「AI 」技術者の作成

さて、AI のテクニシャン自体についてお話ししました。念のため明確にしておきますが、Sonatus は実際にはAI のテクニシャンを製造しているわけではありません。そこで「ビルダー」という役割が登場するわけです。その点について、もう少し詳しく説明していただけますか。

そうですね。その通りです。先ほども触れましたが、多くのOEMメーカーが、デジタル取扱説明書のようなアプリや車載型バーチャルアシスタントの導入を検討しています。そこで私たちが気づいたことの一つは、モデルやグレードの違いなどによって、その車両固有の専門知識が数多く存在するため、これらの機能を車種ごとにカスタマイズする必要があるということです。

したがって、これをスケーラブルにするためには、OEMがこのプロセスを繰り返し実行できるプラットフォームが不可欠です。 そして、理想を言えば、OEMは、AI や車両そのものの専門家である必要なく、この情報を把握できる能力を持つ「テクニシャン」を構築できるようにすべきです。そこでSonatus では、OEM内の様々なユーザーが、顧客向け、社内（エンジニア向け）、さらにはカスタマーサービスレベルなど、実際の利用目的に応じて、これらの異なる「テクニシャン」を実際に作成できるビルダープラットフォームを構築しました。

つまり、基本的には、自社の車種やグレード、場合によっては所有者レベルにまで絞り込んだ、非常に特化した技術者を育成できるということですか？

もちろんです。まず、彼らが提供してくれるものの一つは、車両そのものに関する資料です。具体的には、取扱説明書や、より社内向けの資料といったものです。サービス技術者向けには、整備マニュアルや配線図などが含まれます。

ユーザーであるOEMエンジニアの場合、通常、FMEA文書やその他のフォールトツリーなどが用意されているでしょう。これらは、いわば車両に関する技術的知識を構成しています。次に、車両から得られる実際のリアルタイムデータとこれらを照合したいところですが、そこで、車両のVINや特定の所有者に紐づけられた実際のデータや、整備記録、製造履歴といった情報を結びつけ始めることになります。 これらすべてが可能となります。

それは、OEMが実際に接続したいと考えているさまざまなデータソースによって大きく異なります。そして、それは、その特定の技術者向けシステムを構築する際のユースケースや、対象となる具体的なユーザーによって決まってくるでしょう。

まるで、自分専用のAI の技術者がいるようなものですね。本当に気に入っています。

07:36 SDV技術の実現とAI

さて、これが実際にどのように機能するのかについて、徐々に掘り下げていくところですね。もちろん、AI という要素はありますが、単にAI を車両に載せるだけでは済まないでしょう。そうですよね？ こうしたアプリケーションを実際に導入するためには、明らかに何らかの前段階や前提条件が必要になるはずです。そうした基盤技術にはどのようなものがあるのか、詳しく教えていただけますか。

そうですね。その通りです。そこで、私たちが極めて重要だと考えている要素の一つは、車両自体からデータを取得できる能力です。つまり、車両に搭載され、車両ネットワーク内で動作し、さまざまなECU間で通信を行い、特定のDTCやネットワークの特定の領域だけでなく、車両のあらゆる情報にアクセスできる製品です。

つまり、これは車載ソフトウェアの基盤技術の一つであり、データをリアルタイムで収集し、異なるノード間でそのデータにアクセスできるようにするものです。2つ目の側面は、実際にそのデータをクラウドに送信することです。これはどちらかといえばデータ収集製品に近く、Sonatus collector（AI ）のようなもので、非常に軽量なポリシーを通じてデータをクラウドに送信します。 こうした基盤となるコンポーネントが整えば、より包括的な機能の構築を開始し、その車両データ上で実行可能な特定のAI モデルなどを導入できるようになります。

つまり、非常に専門的な知識や特定の分野の専門知識が必要な場合、AI の技術者だけに頼るのではなく、さまざまなツールにアクセスできるエージェントを呼び出して、車両に関する情報を推論できるようにするということです。

09:06 エージェントモデルの実装

最近では、単にデータを分析してそこから推論を行うだけでなく、ある種のフィードバックループを形成する「エージェント型モデル」について多くの議論がなされています。「AI 」のテクニシャンビルダーやインフラ全体において、このエージェント型モデルに適した要素はありますか？

その通りです。先ほどお話ししたさまざまなデータソースは、通常、個別のエージェントとして構築するのが望ましいでしょう。つまり、AI の専用モジュールのようなもので、特定の1つのことに極めて優れているのです。例えば、取扱説明書のデータを解析したり、車両から送られてくる信号を理解するためにデータベースを構築したりといったことが挙げられます。

つまり、データにアクセスできるだけでなく、それを解釈して、「ああ、特にこのタイミングでのこうしたシグナルは、こういうことを意味しているんだ」と理解できなければならないのです。 そして、そのデータに基づき、設計文書に関する知識と組み合わせることで、システムは「ああ、こういう現象が見られたら、これはこういう問題だ。ユーザーにはこうアドバイスすべきだ」と把握できるようになります。つまり、これらのさまざまなエージェントは一般的に、それぞれのデータソースに接続されており、それを通じて、さまざまなツールを活用することができるのです。

その一例として、Sonatus コレクター（AI ）に接続することが挙げられます。ここでは、AI の技術者の判断に基づき、新しいデータ収集ポリシーを展開することができます。つまり、ユーザーのクエリに基づいて車両から送信されるデータを分析し、新しいデータポリシーを起動して車両に展開することで、それまでは入手できなかったデータの収集を開始することが可能になります。

AI の技術者は、次の手順や、適切な診断と対応を行うために必要な追加情報について、ほぼリアルタイムで考えているかのようです。

10:42AI 関係するモデル

AI に特有の技術について、少しお話ししましょう。

これらは、従来のAI の機械学習モデルでしょうか？この用途にはどのようなモデルを使用しているのですか？

ええ、その通りです。通常、私たちも今日よく見かける他の多くのアプリケーションと同様に、LLMを活用しています。最終的には基盤となるLLMに基づいていますが、私たちはオープンソースを優先しており、それをファインチューニングして、より自社独自のモデルに仕上げています。その理由の一つは、そうすることで特定の自動車分野においてより優れたパフォーマンスを発揮できるからです。 2つ目の理由は、多くのOEMが自社モデルをホストし、データが保護されていることを確認したいと考えているからです。これは、エンドユーザーの観点からの個人識別情報（PII）だけでなく、AI の技術者向けの知識ソースとしてOEMが提供する独自のデータについても同様です。 そこで私たちは、これらのカスタムLLMを基盤として、リトリーバル拡張生成（RAG）やエージェント型フレームワークといった技術を組み込み、システムプロンプティングのノウハウを活かすことで、これらすべてがシームレスに連携するようにしています。

了解しました。

11:43 まとめと締めくくり

つまり、要約すると、ソリューションにはAI という要素がある一方で、その基盤となるインフラストラクチャも存在します。また、よりアクセスしやすいネットワークや、モデルにデータを提供するための共通のデータ交換手段についてもお話しされていました。ここには、サービスベースのアーキテクチャやサービス指向アーキテクチャといった要素も関わってくるのではないでしょうか。つまり、これが全体像におけるSDVの部分にあたるわけです。

そうですね。間違いなく、車載EEアーキテクチャは重要な役割を果たしています。そして、これらさまざまなデータソースにアクセスできることで、一般的なテレメトリデータはもちろん、DTCやログファイルといったもの、さらにはネットワークトラフィックデータなども取り込むことが可能になります。特にサイバーセキュリティやその種のアプリケーションを考えると、こうしたデータは有用です。 ですから、アーキテクチャが最新であればあるほど、AI の技術者たちの能力も高まるというのは、間違いなく非常に重要なことですね。

素晴らしいですね。そして、これらについてはすべて、私たちが先程公開した最新のソリューション・ブリーフ『AI テクニシャン・ビルダー ソリューション・ブリーフ』に詳しく記載されています。スティーブ、ありがとうございました。大変参考になりました。また次の『driving innovation 』のエピソードでも、ぜひご出演いただければ幸いです。

素晴らしいですね。サンジェイ、ありがとう。とても楽しかったです。Sonatusの「AI 」技術者向けビルダーは、SDV 技術と車両のAI が、OEM各社が車両の所有体験を変革し、車両のメンテナンスや修理に伴う煩わしさやストレスを解消しながら、ブランドロイヤリティを構築し、顧客生涯価値を獲得するのにどのように役立つかを示す素晴らしい好例です。

詳細については、sonatus .com から「AI Technician Builder」のソリューション概要をダウンロードし、実際の動作を確認するためのデモをご予約ください。

『Driving Innovation 』の今回のエピソードをご覧いただき、ありがとうございました。次回のエピソードでもまたお会いできるのを楽しみにしています。