クルマは「走るコンピュータ」と呼ばれる時代に突入し、ソフトウェア更新が製品価値を大きく左右するようになった。中でもOTA（Over The Air＝ソフトウェアのアップデートを遠隔から届ける仕組み）は、機能改善やサービス提供を加速させるカギとなる。しかし、クルマのソフトウェアアップデートは、スマホやIoTのように容易にできるものではない。車種・年式・仕様・ECUごとに最適化した開発がなされており、世界中のあらゆる環境を移動するためネットワーク条件も複雑だからだ。今回のイベントでは、本田技研工業株式会社でSDV事業に携わる4名が、OTA導入の背景やグローバル配信に向けた取り組み、課題について語った。
この記事に登場する人
INDEX
アーカイブ動画
SDVがひらくモビリティの未来——Hondaが描くクルマの進化像
登壇者①
SDVマネジメント部 部長
板垣 良
はじめに、四輪事業本部 SDV事業開発統括部 SDVマネジメント部 部長の板垣が「SDVで変わるモビリティのビジネスモデル」と題し、モビリティ業界の変化とSDV、OTAはSDV実現の扇の要であること、Hondaのチャレンジについて講演を行った。
自動車業界は今、100年に一度の変革期を迎えている。コネクティッド（Connected）、自動運転（Auronomous）、シェアリング（Shared）、電動化（Electric）といった「CASE」と呼ばれる領域で技術革新が進む中、クルマの概念は大きく変わろうとしている。
こうした価値観の変化の中心にあるのが、ソフトウェアによって機能や性能が定義・アップデートされる自動車、ソフトウェア・デファインド・ビークル（SDV）だ。
Hondaがソフトウェア・デファインドで実現したい世界観とは、個人や社会とつながりながら、モビリティが自動化され、パーソナライズ化されて進化することで、1人ひとりの夢を実現し、異動の喜びを提供することです。
従来のクルマは、納車した瞬間が価値のピークだった。しかしSDVでは、納車後にユーザーのニーズに応じて新しい機能が追加され、価値が向上していく。さらに、データを起点にサービス企画、開発、アップデートを継続することで、ユーザーとの関係性は長期的に続いていく。顧客からのフィードバックをもとに機能を改善・追加することで、顧客とともに成長する。この関係性を技術で担保するのがOTAだ。
OTA（Over The Air）は、無線通信を通じてソフトウェアを更新する技術を指す。SDVが目指す「進化し続けるクルマ」は、OTAなくして実現できない。OTAがもたらす価値は、大きく3つ。「迅速な不具合修正」「継続的な価値向上」「顧客体験の改善」だ。
OTAのアップデートを安全かつ確実に行うためには、厳格なプロセスを踏む必要がある。サーバー側でアップデートパッケージを作成・配信し、クルマが受信・認証してインストールを実行、完了ログをサポートするというのが基本の流れだ。
このプロセスに関係する技術領域は多岐にわたる。署名検証や整合性チェック、車両の電源状態や条件監視をするゲーティング、デュアルバンク、一部のユーザーから配信を開始するカナリア配信など段階配信技術や、異常時の緊急停止などだ。
OTAには大きく2つの種類がある。SOTA（Software OTA）とFOTA（Firmware OTA）だ。SOTAは、ナビゲーションシステムやインフォテインメントシステムなど、比較的更新リスクの低いソフトウェアの更新を指す。FOTAは、エンジンやブレーキ、バッテリー管理など、車両の根幹を制御する制御系ECUのファームウェアを更新する技術だ。そのため、FOTAには高い信頼性とセキュリティが求められる。
SDV時代には、SOTAやFOTAを支えるOTAプラットフォームの重要性が増している。プロダクトを継続成長させるコアは、「配る力」だ。セキュリティやグローバル展開、テスト・検証の自動化の3点を横断的に担保するプラットフォームである必要がある。
SDVにおける競争領域の1つはスピードで、このプラットフォームによる配りやすさ、つまり、設計、開発、テスト、改善といった一連の工程を短期間で繰り返すイテレーション速度が、今後の競争力の要になると考えています。
Hondaでは、2018年から北米でSOTAを開始し、現在はグローバルに展開中だ。2023年からはFOTAの導入にも踏み切った。SDV時代をリードするため、Googleとの協業も開始。従来のクルマ作りにAndroid Automotive OSを導入することで、Fun領域の俊敏さを実現している。
社外との連携により、Hondaのソフトウェア開発のスピードアップと、豊富なサードパーティ製アプリのエコシステムへのアクセスを可能にし、継続的にOTAアップデートをすることでお客様に豊かな体験を提供しています。
そのSDVを前提にゼロから設計された新世代のEVが「Honda 0シリーズ」だ。このクルマはOTAを通じて、購入後も機能が追加・改善され続ける「進化する体験」を提供していく。
クルマのアップデートの難しさ——「クルマのアップデート」開発の裏側
登壇者②
SDVマネジメント部
ソフトウェアアップデートエンジニアリング課
滝 知明
続いて、四輪事業本部 SDV事業開発統括部 SDVマネジメント部 ソフトウェアアップデートエンジニアリング課の滝 知明が、OTAアップデート開発の裏側について語った。
2017年当時、滝氏はサービス技術開発部に所属していた。PCやスマートフォンは当たり前にOTAをしているが、クルマのリコールのためには顧客がディーラーに足を運ばなければならない。この状況に疑問を抱いていた滝氏は、制御系ECU開発を行う部門にOTA導入を提案した。
しかし、『自動車業界にOTAは向かない』『インターネットで配信した破損ファイルや改ざんされたファイルが書き込まれたらどうするんだ』と大反対にあいました。
スマートフォンのアプリやOSと、クルマのECUのアップデートとの違いを比較すると、クルマにおけるOTAアップデートの難しさがよく分かる。
スマートフォンのアプリ更新は、Google Play StoreやApple App Storeといったプラットフォーム事業者が定めた厳格な規定に従い、一元的に管理・配信されているのでアップデートが失敗することは稀だ。OSアップデート自体も少数のOSを開発している企業が開発したテンプレートを適用するのでバリエーションが限られている。いわば、規格化されたマンションのようなものである。一方、クルマのECUはそれぞれ異なるサプライヤーのハードウェア、ソフトウェアで構成されている。多様な注文住宅に例えることができよう。
クルマには1つの車両に平均20から30のECUが搭載されており、それぞれが異なる仕様や世代を持つ。スマートフォンのように統一規格ではなく、いわば「木造・鉄骨・ログハウスが混在する家」を1つのルールで改修するものだ。
OTAの開発には制約が多く、バリエーションも多い。世代の異なるユニットが混在する中で開発していかなければならないというのが、クルマの、特に制御系ECUのOTA開発の難しさです。
先行企画を進めるに当たっては、In Carの制御系ECU開発者、ナビゲーションシステムの開発者、サーバーの開発者など主要な要素のメンバーで議論を行った。滝氏は、OTA開発はそれぞれの「あたりまえ」があるエンジニア間の異文化交流だと言う。
例えば、通信速度。仮に2GBを転送する場合、PCでは100Mbpsで2.8分、10Mbpsでも28分で転送が終わる。一方、車両内通信は500kbpsであるため、同じ2GBの転送に9時間32分かかる。通常の車両制御の通信で帯域が逼迫している場合、仮に20%使えたとして47時間もかかってしまう。このように、「2GB」という数字だけを見て会話しても、ECUとナビ、サーバーのエンジニアの間で、これだけの時間感覚のズレが生じてしまうのだ。
OTAを導入するに当たって、Hondaではサーバーの内製化も行っている。この開発も困難を極めた。PCやAndroidなど、エッジ端末側が強力なスペックを持つ前提でクライアントサーバーの機能配置を考えていたためだ。更新ソフトの検索なども、サーバー側ではせず、車両内の状態に合わせてアップデート対象を抽出させようと考えていた。
しかし、組み込みのECUでバリエーションの複雑な車両でそれを処理することは困難でした。結果的にデータベース側で厳密なマスタを持ち、照合することになりました。基本的に車両製造はハードウェアの組み付けの世界なので、SBOM（ソフトウェアの部品表）を作るところからのスタートでした。
文化や常識の違うメンバーが集まって始めた先行企画だが、参画したメンバーは手を動かせるエンジニアだったため、実際に動くものを作りながら会話を繰り返す中でお互いの理解が深まった。ECU側はRaspberry Piで模擬し、IVI側は開発用のデバッグボードにサービスとUIアプリを実装し、サーバーもAWS上に構築した。さらに、これらの機材をスーツケースに詰め込んでデモ機も作成。クルマへのOTA適用に否定的だった上位層にも実際に動くものを見てもらったことで、少しずつ流れが変わり始めた。
制御系OTAが成功につながったのは、物を作りながら議論して考えるという活動のおかげだと思います。文化の違いで生じた仕様のアンマッチも、その場で直して試すということを繰り返し、お互いを理解することができました。量産開発においても強固につながったメンバーが連携して開発・検証することで、開発終盤、リリース終盤は非常にスムーズなコミュニケーションがとれるようになりました。
OTA導入で不安を抱えていた市場担当者も、PoC機を見せたことで考えが変わっていったという。三現主義を大切にしているHondaらしく、実際に動くものを見せて、それをもとに議論し、現場の声を吸い上げる。課題があれば修正・実装し、それをもとにまた議論する。その繰り返しで現場の不安を払拭していった。
アメリカや中国ではOTAが活発にリリースされているが、いずれもEVへの導入が主だ。EVは大容量のバッテリーを搭載しており、イグニッションをオフにしていても、電力を潤沢に使用できる。これに対して、Hondaはハイブリッド車のバッテリー電力を使う方法でOTAを導入した。そんな中、市場からはガソリン車へのOTA導入を望む声が少なくなかった。北米だと、フラッグシップのアコードでの販売比率はハイブリッド：ガソリン車が50：50で、例えばリコールを想定すると、ハイブリッドのみへのOTA適用だと半分の顧客にはディーラーに足を運んでもらう必要があった。
結果的に1面のECUでも3分程度、2面なら一瞬でアップデートが終わるシステムを実現したが、それを量産開発するとなると異なる難しさがあった。量産開始を1年後に控えた段階で、現地での検証作業が本格的に稼働を開始。PoCも行い、単体ユニットでもテストを進めていたが、クルマ1台分に仕上げてみるとほとんど動かないところからのスタートだった。しかし、「120%の良品を目指す」というHondaの文化と粘り強さで、すべての課題を解決に導いた。
OTAを支える舞台裏——開発から運用へ
登壇者③
SDVマネジメント部
ソフトウェアアップデートエンジニアリング課
岩村 武
3人目として登壇したのは、四輪事業本部 SDV事業開発統括部 SDVマネジメント部 ソフトウェアアップデートエンジニアリング課の岩村 武だ。開発したOTAを運用する過程について、講演を行った。
自動車のソフトウェアアップデートはこれまで、顧客がクルマの不具合を発見し、販売店に来場した際に、ソフトウェアアップデートによって不具合が解消する“修理の一環”として対応されてきた。もしくは、定期点検でソフトウェアアップデートを実施するなど、いずれも年に1〜2回アップデートされる程度だった。
例えばアメリカでは、毎年100万台以上のクルマが売れる。10年経てば、1,000万台以上のクルマが走っていることになる。それぞれのクルマに年2回のサービスデマンドがあるが、それを全米にある約1,000店舗のみで対応するのは現実的ではない。さらに、アップデート作業は売上に直結するものではなく、敬遠されがちな作業だった。
また、ソフトウェアの配信方法も煩雑だった。各開発部門がソフトウェアを作成し、それをDVDに焼いて、日本から全世界にある現地法人に送る。現地法人では、それを販売店ごとにパックして郵送するといった具合だ。
2023年4月、海外の赴任先から帰国したときに、ちょうど最新のOTAのプラットフォームが導入され、市場配信されました。北米のみの配信でしたが、毎時数千台というペースでソフトウェアアップデートが完了していきます。1日で2万台弱、その後も日を追うごとにアップデート台数が増えていきました。これまでのアップデートの過程を思うと衝撃でした。
北米でスタートしたOTAの配信は、その後中近東、南米、アジア、日本へと拡大した。それに伴い不具合の報告も増え、地域対応専用のチームを置くこととなった。
さらに運用を困難にしたのは、サーバーセキュリティや個人情報保護管理といった法規の適用だ。欧州と日本で施工された自動車のソフトウェアアップデートプロセスに関する法規（通称SUMS法）では、ソフトウェアの設計から生産、システム、市場に出てからのアップデートまで、自動車のバリューチェーン全体を通じてプロセスを文書化し、実行して記録を残さなければならない。
特に、ソフトウェアバリエーションの管理は厄介だ。1つひとつのクルマのモデル、グレード、そこに搭載されているECUのバージョンの更新履歴を、いくつもある車両関連法規と結びつけて管理しなければならない。
また、ソフトウェア供給の旧プロセスを改良する形で設定した新たな共有プロセスは、実際に運用してみると新たな市場配信の手法や法規、それに対応するプロセスの理解が進んでいないといった課題が浮き彫りになった。各工程でさまざまな問題が発生し、極めて歩留まりが悪い状態に陥ってしまった。
各工程では、自工程の要件も周知されておらず、さらに次の工程が何を求めているかもわからない状況で、工数とリードタイムばかりがかかり、部門をまたぐ不満や文句のぶつけ合いが発生しました。ルールの土台が変わったことに、組織としてついていけない状態でした。
あまりにも問題が山積したことで、「このままではまずい」という雰囲気が醸成されたことが転機となった。上流から下流までの問題認識が一致し、One Teamの意識が一気に高まった。源流にあたる開発部門が音頭を取り、ソフトウェアを整流化するためにコミッティーを設立、一丸となって取り組む体制が築かれた。こうして全体の目線が合ったことで、動きがスムーズになった。
車両のソフトウェアアップデートをするためには、サーバーの理解やソフトのリプログラミングの知見、自動車のオペレーションについての知識など幅広い知見が必要だ。そこでスキルマップを作り直し、人材戦略を練り直しながら、同時に採用活動も行うこととなった。
グローバルで統一したソフトウェア配信、供給体制を実現することによって、いつでもどこでも何でも対応できるOTA運用を実現したい。それによって届けられるソフトウェアで、お客様の移動の喜びを広げ、世の中に笑顔を増やせればと思います。
価値は品質対応から「体験の提供へ」HondaのSDVが目指す未来
登壇者④
SDVマネジメント部
ソフトウェアアップデートエンジニアリング課
村松 大輔
最後に、四輪事業本部 SDV事業開発統括部 SDVマネジメント部ソフトウェアアップデートエンジニアリング課の村松 大輔が、「品質対応のOTAから、付加価値提供のOTAへ」と題し、現実課題と将来に向けた取り組みについて語った。
Hondaでは、クルマの使用時に感じるさまざまなストレスを最小化し、クルマの楽しさを最大化する新たな価値提案を、魅力豊かな移動空間の創造のために行うことを掲げている。しかし現実は、ソフトウェアの配信リードタイムが長く、配信目的も市場の不具合対策に偏っているなど、クリアしなければならないさまざまな課題がある。
自動車競合他社を見てみると、アメリカのT社、中国のX社は、有料で追加できる付加価値機能や高度な運転支援機能などを高頻度でOTA配信している。上のグラフからも、T社や中国のX社ともに、Hondaと比べOTAの回数には大きな違いがあり、継続的に顧客への価値提供をしていることが分かる。SDVに関わる開発費や人材規模も大きく異なっている。
競合他社の強力な進化に対し、Hondaは「何ごとにも挑戦する」という企業文化でSDV開発を推進する。
8年前、当時所属していたサービス本部の本部長から、『クルマの新たな価値サービスを検討せよ』と号令がかけられました。このときアライアンスを組んだのが、自動車からもっとも縁遠い業界にいる株式会社ドワンゴさんでした。
互いの組織文化の違いを乗り越えながらさまざまな議論を重ねた結果、リアルタイム車両データをもとに、キャラクターがドライブを盛り上げるアプリ「Honda史上、最高にミク」が誕生した。
少数メンバーで推進したこのプロジェクトは、最終的にHonda内の研究開発のメンバーやデザイナーなど挑戦好きなメンバーが集まり、企画からリリースまでわずか1年足らずで達成することができました。本気になれば、新たな価値提供を、スピード感を持って達成できる組織だと感じました。
このプロジェクトを皮切りに、SDV事業開発統括部内では新たな価値を生み出す活動として「デジタルラボ」を組織した。Honda独自のアセットをベースとし、先進のITやデジタル技術を活用して、顧客価値・アイデアを高速で試しながら、競争力のあるSDV戦略を企画、立案する組織として活動している。
その1つが「RoadPerformance」だ。スマートフォンのアプリで、日常の道路を舞台として運転スキルを試すことができる。また、「with Emile」はApple Vision Proと連携し、車両の動きをデジタル空間で楽しめる新体験を提供する。
今後はアプリだけでなく、本業である製品としての「走る・止まる・曲がる」に関係する領域においても付加価値を提供していく。
それが、次世代ADASである「Navigate On Autopilot」だ。一般道か高速道路かを問わず、目的地までの全経路においてクルマがアクセルやハンドルなどの運転操作を支援する仕組みだ。
交通参加者が多様で、交差点での右左折が頻繁に発生する市街地は技術難易度が高いが、自動運転開発で培った技術を応用しながら開発を進めている。
さらにハイブリッド車へも搭載することで、大規模な事業スケールを活用した高い商品競争力と低コストを両立しながら、付加価値の高い「移動の喜び」を届けようとしている。
質疑応答
質疑応答では、イベントに登壇した4名が、イベント参加者から投げかけられた質問に回答した。
Q.SDV事業のこれからにおける一番の課題は何ですか？
自動車産業は100年に一度の変革期と言われていますが、これだけ大きな産業だからこそ、舵取りは困難を極めます。これまで何十年と培ってきたレガシーの中で、営業、サービス、品質、工場、開発とさまざまな部門からどう理解と共感を得るか、それを持って事業をどう推進していくかが一番の課題だと考えています。
Q.ソフトウェアアップデートの法規は品質保証やセキュリティ確保を目的としたものと認識していますが、実務上、品質向上への寄与よりも開発運用の負担のほうが大きいのでしょうか。
法規の遵守はお客様に価値を届けるうえで必ず必要なことです。こうした法規はお客様の安全を守るために作られました。「移動の喜び」として届けている自動車が、お客様にとっての凶器とならないよう、メーカーとして遵守しなければならないと考えています。
開発の観点からは、法規がなかったとしても品質保証やセキュリティは当然追求していきます。OTAの先行企画が開始してからは、どこまでセキュリティを高めるかを議論して開発をしてきました。法律によって記録を残すことが求められているのは、品質にバラツキが出ないようにするという側面があるのではないかと感じています。
Q.SBOMはどのように作ったのですか？
Hondaはもともとハードウェアの会社で、ソフトウェアを単独で管理する概念がありませんでした。そもそも、ディーラーに来ていただいたお客様のクルマを目の前で書き換えるという価値観だったのです。それをサーバーから配信しようとすると、「このソフトはどのモデルに配信すべきか」といったデータベースが必要となります。そこで、ECUに搭載されているソフトウェアがどのモデルに紐づいているかを逆展開していくことで、初期のデータを構築しました。量産が終わった後も、互換性の情報はソフトウェアアップデートを正しくやっていくために必要なので、そこに紐付けてソフトウェアのチェーンを構築しています。今後はさらにそれが複雑になっていくというところで、SBOMの管理改善をプロジェクトとして進め、SDV時代に備えています。
Q.OTAの取り組みの成果を評価するうえでは、どのような指標を重要視していますか？
一番は、OTAを配信した際の失敗率・成功率です。OTAは一旦開始すると、数分単位で何千件、何百件と更新されていきます。何か問題が発生した際、それをいかに早く止めるかが重要なのです。
Q.市場で品質不具合が見つかった際、OTAだけで対応するか、従来型のリコールをするか、その線引きはどうしていますか？
OTAのみでの対応となると、少なからずお客様に依存してしまうことになります。一方、従来型のリコールだと、コストがかかります。このように、コスト、アップデートの内容など複合的な要素を客観的に比較し、どういった市場対応をするのが最適かを地域の各リージョンの運用者と議論して決定しています。
Q.OTAシステムを自社開発しているとありましたが、In Car側でのゲートウェイから各ECUの配信システム開発における苦労話があれば教えてください。
ゲートウェイから複数のECUへ更新データを配信していく仕組みは、開発の中でも難易度が高い領域でした。サーバーとゲートウェイ間の通信仕様は固定されているため設計がしやすいのですが、問題は、ゲートウェイが受け取った更新データを各ECUへ書き込む車両内側の処理です。ECUごとに特性が異なるため、設計どおりに共通のシーケンスで進めようとしても、どうしても個別の事情が出てきます。
たとえば、ECUごとの応答速度の違いなど、統一したプロセスでは吸収しきれない部分があり、そのたびに設計変更を加えながら対応する必要がありました。ゲートウェイ側で最後まで品質を担保し続けるために調整を重ねる点が最も苦労したところだと感じています。
Q.複数ユニットに対してOTAを実施するケースで、各ユニットを含めたシステム全体として保証する必要があると思うのですが、失敗や不整合が発生した場合もシステムレベルで防ぐ仕組みなどはあるのでしょうか。
ご指摘のとおり、複数ユニットを一体のシステムとして保証する必要があります。そのため、「どのユニットとどのユニットを一緒に書き換えなければならないか」をサーバー側で定義し、その情報をソフトウェアと一緒にゲートウェイへ渡しています。書き換えの順番も含めて管理し、例えば2つ目のユニットの更新が失敗した場合は、1つ目の更新を有効化しない形で、システム整合性を保つ仕組みを備えています。
さらに、ソフトウェアバージョンの不整合が起きること自体を想定した設計にしています。というのも、ディーラーでECU交換が行われる際、保守部品に古いソフトウェアが入っているケースがありますし、故障時にお客様自身で部品を交換される可能性もあります。そうした多様なケースを前提に、古いバージョンが混在した場合でも自動的にバージョンを合わせ込む仕組みなど、幅広いシナリオに対応できるよう開発を進めてきました。
Q.イグニッションをオフにしてアップデートを実行する際、そのタイミングでネットワークがない場合にはどうなるのでしょうか。
クルマの場合、お客様がどこを走り、どこに停めるかを事前に想定することはできません。地下駐車場のように電波が届かない場所や、山奥など全くネットワークがない環境でアップデートを実行する可能性もあります。こうした状況を前提に、ネットワークがなくてもアップデートが失敗しないよう実装しています。
具体的には、ネットワーク接続が必要な処理はすべてイグニッションOFFまでに完了させる設計としています。そのため、アップデート自体はオフライン状態でも最後まで実行できます。一方で、アップデート結果のログは法規上の履歴管理が必要になるため、クルマが再びネットワークに接続されたタイミングでサーバーへ送信されます。
なお、「ネットワークがない」という状態の定義は非常に難しく、4G回線にはつながっていないが、テレマティクスユニット側の仕様上、ネットワークに接続したように見えるケースもあります。こうした曖昧なケースを1つひとつ潰していくために、先ほどお話しした1,200時間に及ぶテストを実施しました。ネットワークが途切れる状況や完全でない場所でのアップデートなど、多様な環境下で検証を重ね、安全にアップデートできる仕組みを作り込んでいます。
文＝鹿野 恵子（プレーンテキスト）
※ 所属組織および取材内容は2025年11月時点の情報です。
