執筆者：ウーブン・バイ・トヨタ Vice President兼Head of Arene ジャンフランスワー・カンポー


自分の仕事について聞かれると、今でも母のことを思い浮かべます。

何年にもわたり、母は私にこう尋ねてきました。「ジャンフランスワー、実際のところ何をしているの？」テクノロジーとは関係のない仕事をしている母にとって、コンピューターやソフトウェアは身近なものではありません。そのため、正確かつ分かりやすく説明をすることに、長年苦労してきました。そして最近、ようやくしっくりくる答えを見つけたのです。

「ソフトウェアがアップデートされた後も、クルマが期待通りに動き続けるようにすることだよ。」

それは、とても簡単なことのように聞こえるかもしれません。しかし、お客様の期待値が高まり続ける一方で、車両ソフトウェアはますます複雑化し、いくつもの絡み合った複数のシステム層が車両全体の挙動を形作るようになっています。どう考えても、簡単なことではありません。

技術的な課題はさることながら、この移り変わりにより、自動車メーカーには新たな責任が求められています。車両全体にわたるアップデートを遂行するため、お客様と直接かつ継続的な関係を築く必要性が生じているのです。しかもそのアップデートは、お客様の走行体験にしっかりと寄り添うものでなければなりません。単なる信頼の維持ではなく、信頼をさらに深めていくことでもあります。

信頼できる、ソフトウェアによって定義される車両（SDV）とは何か

私は、カナダの中流家庭で育ちました。そこでは誰もが、信頼性の高さから日本車に乗っていました。私の母や妻、子どもたち、義父母も全員です。冬が危険をはらむ地域に住む人々にとって、クルマは単なる乗り物ではありません。命綱です。雪が降る夜には、A地点からB地点へ、安全に車で行って帰って来られるという安心感が求められます。

私が思い描くSDVとは、ドライバーと共に成長し、ハンドルを握る人に安心感と心地良さをもたらし、そして何よりも道路上での安全を確かなものにするクルマです。その一番中核にあるもの、それが「信頼」なのです。

変化が違和感を生むのではなく、クルマをより良くするものであるという信頼。改善が、目新しさではなく、相手を想うからこそという信頼。その過程で、大切なものが失われないという信頼です。

そのためには、車両開発に取り組む上で２つの重要な変化が必要です。

• ソフトウェアの要件は、ソフトウェアが進化していく中でも車両の挙動を予測可能で快適なものに保つため、より早い段階からチーム横断かつ車両全体レベルで定義すること

• お客様の体験を損なうことなくソフトウェアをOTA（Over-the-Air）でアップデートし、新しい価値が継続的に提供されること

なぜOEMにとってこの変化は難しいのか

外から見ると、SDVが抱える課題は単純なソフトウェアの問題に見えるかもしれません。一部のコードをアップデートし、新しいバージョンをリリースし、それを繰り返す。しかし実際には、自動車メーカーが採用する設計、検証、オペレーションの方法に関わる大きな変化なのです。長年に渡り、ハードウェア優先の考え方で成功してきた企業がこれに対応するのは、非常に困難です。なぜなら、従来のオペレーションモデルは、クルマが工場から出荷された後も絶え間なく変化するソフトウェアには対応していないからです。具体的には、以下の通りです。

ハードウェアには適していたモジュール化が、ソフトウェアによってひずみが生じている

従来の自動車づくりは、モジュール化を前提とした構造になっています。モジュールやドメインに分割された車両は、それぞれ異なるチームやサプライヤーの下で製造され、最後にそれらが組み立てられます。この仕組みは、ハードウェアにおいては非常にうまく機能します。

ソフトウェアではどうでしょう。各モジュールがほぼ独立して開発され、「ブラックボックス」として扱えた時代には、うまくいっていました。しかし複数ドメインにまたがる機能によって、モジュールが互いに依存するようになると、問題の検出がより難しくなり、車両の挙動に影響を与えかねません。こうした問題は、機能の提供を遅らせるだけでなく、アップデート後に予期していない挙動を引き起こし、統合と検証をより困難にする可能性があるのです。なぜなら、一つのドメインへの変更が、何の変更も加えていない他のドメインにも影響する可能性があるからです。

複雑化の進行とクロスドメインの挙動

車両のコンピューティング能力とネットワーク機能の向上に伴い、ドメインをまたぐ機能の数と複雑性が増しています。その結果、複数のチームが開発したソフトウェアの統合が、さらに難しくなっているのです。ネットワーク信号やECU、APIといったインターフェースは、他への影響を明確に把握しきれないまま変更される可能性があり、結果として、車両に関する情報は断片的なものになります。

エンジニアは、多くの時間を費やしてソフトウェアやインターフェースの各層にまたがる問題を追跡することになり、製品の改善に時間を割けなくなるのです。また、一つのソフトウェアの変更が、予期していない形で複数の機能に影響を及ぼすリスクも高まります。

歴史の浅いソフトウェアエンジニアリング手法

土木や機械のエンジニアリングに比べると、ソフトウェアエンジニアリングの歴史はまだ浅いものです。「このような要件であれば、このように設計すれば安全である」といった万能の手引きは存在しません。優れた慣行やツールはすでに存在しますが、とりわけ、数百万台ものクルマと多岐にわたるその派生モデルに複雑なソフトウェアを拡張する際の手法は、まだ進化の途上にあります。

その未成熟さは、一握りの熟練者の勘に頼らざるを得ないという形で、実際の現場で露呈します。専門外の人員が高度な専門性を必要とするポジションに配置されることで、見落としのリスクが高まり、あらゆるアップデートがお客様の期待するクルマの体験に見合う、あるいはそれを上回るものを提供することが難しくなります。

なぜ、スマホのようにアップデートできないのか

SDVが「車輪のついたスマホ」と表現されるのを耳にするたび、思い出す出来事があります。母から「スマホが壊れた」と電話がかかってくるのです。それも一度や二度ではありません。アップデートにより動作がほんの少し変わっただけなのですが、それでも母にとっては、もう以前のようには使えないと感じてしまうのです。技術的に言えば、そのスマホは正常に作動していました。ただ、母の感覚としては、壊れたのです。

では、運転中にその感覚になったと想像してみてください。

クルマに乗ることは、全身の感覚を伴う体験です。視覚、聴覚、触覚など、複数の感覚を同時に使う体験です。脳は、予測していたことと実際に起きていることを、絶えず比較しています。それが一致しているとき、安心感を覚えます。違いがあると、本能的に不安を感じ、警戒心が目を覚まします。

ソフトウェアのアップデートにより車両の挙動が変わっていたとすると、たとえそれが些細な変化であったとしても、もはやドライバーの予測とは一致しません。楽しみが損なわれるのはまだ良い方で、最悪の場合、安全が脅かされる可能性があるのです。ドライバーは、それがソフトウェアの問題だとは捉えません。そのクルマが、あるいはブランドそのものが期待外れだったと感じるでしょう。それゆえ、車両のアップデートを、モバイルアプリの気軽なアップデートと同じように扱うことはできないのです。ここで求められるのは、単に製品自体を変えることではなく、開発の仕方そのものを変えることなのです。

開発の仕方の見直し

私の経験から言うと、真に信頼されるSDVを実現するためには、いくつかの変化は不可欠です。

ブラックボックスをホワイトボックスへ

自分たちが理解できないものを管理することはできません。SDV開発においては、ソフトウェアをブラックボックスの集合体として捉えるのではなく、ユーザー体験を形作る車両の中核システムとして捉え直さなければなりません。OEMは、ソフトウェアの挙動に、エンドツーエンドで責任を負う必要があります。また、パートナーの存在は不可欠で、その知的財産権は尊重されなければいけませんが、その一方で、ブラックボックスのままではリスクを伴います。OEMは、車両全体に責任を負うと同時に、主要な挙動やアーキテクチャ、インターフェースについての詳細をパートナーと共有する必要があります。これらのドメインに透明性を持たせることで、OEMは、統合されたシステムを理解・管理できるようになるのです。また、ソフトウェアが進化し続けても、一貫したユーザー体験を維持することができ、お客様が信頼を置いている機能が不用意に変更されてしまうリスクを低減することもできます。

車両レベルでのシステムアーキテクチャとインターフェースの管理

お客様はドメインを買うのではありません。買うのはクルマです。そのため、システムアーキテクチャ（とりわけ、ドライバーとの相互作用における制御ループ）は、車両レベルで定義・管理されなければなりません。インターフェースは標準化されるべきであり、統合管理する立場としてのOEMが、変更を厳密に管理する責任を負います。アップデートのたびに、ドメイン全体にその影響が波及する恐れがあるからです。こうした選択こそが、モデルのバリエーションを問わず、そして時を経ても、クルマの乗り心地の一貫性を保つことに繋がるのです。

システム開発に携わるすべての人が、その挙動を把握できるように

私にとってアジリティ（対応力）とは、予期せぬ事態に直面してもバランスを保てる能力のことです。SDV開発で言えば、エンジニアに対して、彼らの仕事が担当部品だけでなく車両全体の挙動にどう影響するかを把握できる可視性を提供することです。そうすることで、問題を早期に発見し、解決できるようにするのです。このような仕組みがあれば、混乱を招くような修正ではなく、より迅速で安全な改善が可能になります。

仮想化の導入と長期資産としてのツールへの投資

「手元の環境ではうまくいった」では不十分です。私たちに必要なのは、実際の車両を正確に再現した環境です。仮想化技術を活用すると、開発者の手元により近い形で車両を再現できます。これにより、エンジニアは、実物のクルマができるよりはるか前に、ソフトウェアの挙動をテストすることが可能となるのです。企業がこういった環境やツールを長期資産として導入して改善し続ければ、お客様は、幅広いユースケースにわたり、派生モデルのどれを使っていようとも、最初に意図した通りに機能するアップデートを体感できるのです。最終的には、透明性と協働、そしてその両方をどうやって拡大していくかということが問われています。その問いに対して私たちのチームが出した答えが、Areneなのです。

Areneはいかに信頼されるSDVを実現するのか

Areneを通じて、私たちはソフトウェア開発・テスト・統合の在り方を統一しようとしています。つまり車両全体の要件に基づいた開発、車両全体としてのテストや統合、これらを一貫した流れで行えるようにするのです。Areneは、お客様に「もっといいクルマ」を届けるために尽力している開発者や運営者、意思決定者など自動車業界のエコシステムに関わるすべての人のためのソフトウェアづくりプラットフォームです。

Areneには、車両ソフトウェアを一つの包括的なシステムとして理解し、構築する上で必要となる、SDKやTools、Dataが備わっています。Arene SDKが、チームを横断して挙動を把握するための、共通フレームワークと標準化されたインターフェースを提供する一方で、Arene Toolsは、仮想環境を活用して早期に問題を表面化することで、変更の設計やテスト、検証をサポートします。Arene Dataは、お客様が実際に価値を感じるアップデートを行うため、お客様のニーズに基づき、車両レベルで期待される挙動や状態を把握します。

さらにウーブン・バイ・トヨタには、世界規模で信頼性の高いクルマを製造・販売してきた、トヨタとそのグループ会社の長い歴史から直接学ぶという、他に類を見ない特権もあります。私たちは、協力し合いながらAreneを構築しています。こういった取り組みにより、安全、品質、信頼という守るべき基本原則を常に最優先させながら、お客様の走行体験をどこまでも向上させ続けることが可能になるのです。

時とともに進化する、「もっといい走行体験」

SDVやAreneの意義を考えるとき、私の頭に浮かぶのは、アーキテクチャやデータベースではありません。私の家族です。彼らは、冬の夜でも、カナダで快適なドライブを楽しんでいます。安心して、目的地にたどり着けるだろうと堅く信じているのです。たとえ出発直前に複雑なソフトウェアのアップデートが行われたとしてもです。

そして時が経ち、子どもたちがそれぞれの家庭を持って、ニーズが変わったとしても、そう信じる気持ちは変わらないでしょう。乗っているクルマがこれからも自分のニーズに応え続け、共に成長していくだろうということ。そして、根本的な心地良さを損なうことはないだろうという確信です。そのシンプルな期待こそが、私にとって、信頼できるSDVが守るべきものなのです。その実現は、オープンに協業し組織や分野の境界を越えて知見を共有しながら、信頼を中心に据えたソフトウェア主導の体験を築いていこうとする業界全体の姿勢にかかっているのです。

ウーブン・バイ・トヨタの技術イベント「KAKEZAN 2026」で、このテーマについて詳しく紹介したジャンフランスワー・カンポー。