カーナビは、目的地まで案内するための単機能からIVI（In-Vehicle Infotainment）※1 領域へと拡張し、現在は運転空間全体を統合制御する領域へと進化している。その背景には、⾞載システム間の連携・最適化や、快適性・安全性・利便性を統合して制御する思想がある。Hondaでは「スマートキャビン」構想のもと、運転空間の総合デザインを推進している。それを担う2人のエンジニアが次世代スマートキャビン開発の苦労と醍醐味を語り合った。
※1 IVI（In-Vehicle Infotainment）とは 主に⾃動⾞（⾞載システム）について⽤いられ、「情報の提供」と「娯楽の提供」を実現するシステムの総称、あるいは特に情報‧娯楽の両要素の提供を実現する（⼀体化された）システムの呼び名のこと。
——まず、日下部さんのHonda入社以降のご経歴を教えてください。
2020年にHondaに入社し、2023年発売のアコード向けカーナビのソフト開発リーダーを担当しました。現在は、次世代BEV（Battery Electric Vehicle：電気自動車）向けソフトウェアアーキテクトを務めています。
加えて、カーナビで利用するOSSのコンプライアンスや脆弱性対応にも携わり、ISO/IEC 5230（OSSライセンス管理）および ISO/IEC 18974（OSSセキュリティ管理）といった国際規格に基づくセルフサーティフィケーション(自己認証)を、Hondaが自動車業界で初めて取得しました。
それらを自社の開発プロセスに取り入れることで、第三者から見てもHondaのソフトウェア開発が適切に進められていることを示し、その基盤の上で新しい取り組みを進めるための推進活動を行っています。
また、Automotive Grade Linux（AGL）というオープンソースコミュニティにも参画しており、他の自動車関連企業と連携しながら、SDV※2向けのオープンプラットフォーム開発にも並行して取り組んでいます。
※2 SDV（Software Defined Vehicle）とは
ハードウェアではなくソフトウェアの更新によって、機能や体験を進化させていく次世代のクルマの考え方。
——標準化やオープンソース活動では、前職の経験は活きていますか？
そうですね。前職では、他社と連携しながらSBOM（ソフトウェア部品表）の標準化にも取り組んでいました。
カーナビではおおよそ6,000〜7,000点ほどのソフトウェア部品リストが必要になりますが、各社でフォーマットが異なると管理が非常に煩雑になるため、その共通化・標準化を進めていました。
当時構築した仕組みは後にISO規格として制定され、現在では実際の開発現場で活用されており、工数削減にもつながっています。
——伊東さんは2023年に中途入社されたそうですね。
はい。2014年に新卒で総合電機メーカーに入社し、9年間、IVIのプラットフォーム開発をしていました。欧州の自動車メーカー向けの純正IVIの開発です。2023年4月にHondaに入社し、日下部のチームでプラットフォームアーキテクトとして仕事を始めました。
その後、日下部がそのチームを離れるタイミングで引き継ぎ、私が日下部の担当していたポジションであるリードアーキテクトに、2024年6月に就きました。
その期間中には、他の業務にも携わっており、その一つがRES（リアエンターテインメントシステム）※3に関する取り組みです。
Hondaでは従来からIVIユニットと分離した形でRESユニットの開発を進めてきましたが、今回アーキテクチャを刷新し、CDC（コックピット・ドメイン・コントローラ）※4でRESを含むシステム全体を統合的に制御する形へと移行しました。
ディスプレイ構成としては最大5枚となっており、メーターディスプレイ、センターディスプレイ、パッセンジャーディスプレイに加え、リア2枚のディスプレイを1つのユニットで制御する仕組みです。
また、各画面に対してユーザーが個別にログインし、自身のスマートフォンと連携して利用できるシステムとなっており、Hondaが他社に先駆けて取り組んだ事例でもあります。
このPoCプロジェクトでは、プロジェクトリードとして参画し、キックオフから約半年間で開発完了し、社内のステークホルダー向けにデモを行いました。
※3 RES（リアエンターテインメントシステム）とは 後席乗員向けに映像や音声などを提供するエンターテインメントシステム。
※4 CDC（コックピット・ドメイン・コントローラ）とは メーター、ディスプレイ、エンタメ機能など、車内（コックピット）領域を統合制御するコンピューター。
——前職でもIVIの開発に従事されていたということですが、Hondaに移ってからの仕事の違いは？
一番大きいのは、立場の違いです。前職はTier1※5として、完成車メーカーからの要求に応える立場でした。ユニットを作ってそれをいかに低コストかつ最適な品質で応えるかが任務でした。完成車メーカーの要求が全てで、それ以上にエンドユーザーのリクエストに応えようとしても高コストになってしまってはTier1のビジネスモデルとしては嬉しくありません。
しかし、Hondaでは、ユーザー価値を起点に最初の仕様そのものを変えることだってできる。ユーザー価値が全てなので、それを生み出さない仕様であれば変えたらいいし、そのためにいろいろなことを考えることができます。同じIVIでも、視座と意思決定の重みがまったく異なります。
※5 Tier1とは 完成車メーカー（OEM）に直接部品やシステムを供給する一次サプライヤー。
——エンドユーザーのことを思い浮かべながら、どのような価値をもたらすかを考えるのは、やはり大変ですか？
純粋に面白いですね。IVIの技術は他のドメインに比べ進化が非常に速く、2〜3年違うだけで、使っている技術も、オープンソースも含めて大きく入れ替わります。さらに、今まさにSDVの発展期で、さまざまなプレイヤーが登場して、何がこれからのスタンダードになるのか全くわからない。そうした不確実性の中で、ユーザー価値を軸に考えながらものづくりができる点に、面白さを感じています。
——Hondaの「スマートキャビン」が目指す世界観とはどういうものですか？ Hondaのスマートキャビンは何を提供しようとしているのか。現時点では技術的にまだ提供しきれていない部分も含めて、数年後にはどういう世界を実現したいのか。それぞれのイメージを教えてください。
短絡的な世界観で言うと、これまでのクルマは、ユーザーの要求に「応える」ことが基本でした。従来は、スイッチを押す、画面を操作する、といった明示的な入力があって初めてクルマが反応していました。
一方で、スマートキャビンが目指す世界観の一つには「ユーザーの行動の先読み」があります。
たとえば、ユーザーの姿勢や視線、動きといった情報から状況を理解し、「次に何をしたいのか」を先回りして支えることを目指しています。
ただし、想定できるユースケースは無数にあります。我々は「不定のユースケース」と呼んでいますがそのすべてに対応できる万能な仕組みはまだありません。
ユーザーの行動を先読みするとなると、AI的な処理が不可欠になります。
我々のスマートキャビンを定義すると、「知能化によるキャビン統合制御」となります。キャビンの制御自体はある程度、イメージできると思うのですが、今まではディスプレイとオーディオの関係だったものが、キャビンにはシート、照明、エアコンなど、さまざまな要素があります。それらを統合して制御し、さらに知能化していく。まさに今、その取り組みを進めているところですね。
私がHondaのスマートキャビンで重要だと思うのは、アーキテクチャの変化だと思っています。「Honda 0シリーズ」では、複数のECU※6を統合し、3つのECUを軸にアーキテクチャを再設計しました。その中心となるセントラルECUにCDC（コックピット・ドメイン・コントローラ）が直接つながる構成になっています。
従来はECUが機能ごとに分かれていたため、シートや空調といった車両機能を統合的に制御することが難しい状況でした。
しかし、セントラルECUと連携するアーキテクチャに変わったことで、個別の制御系を過度に意識することなく、よりスムーズに車両機能へアクセスできるようになりました。
たとえば、シートや空調の制御など、カーナビ以外の領域にも連携しやすくなっています。
このアーキテクチャの変更こそが、スマートキャビンを成立させる鍵になると考えています。その上で、どういうサービスを設計するかはまだこれからの検討課題ですが、いろいろなアイデアは出てきています。
たとえば、自動運転のために用意されているカメラの技術を応用することによって、個人がキャビンの中でどのような状況なのかを検知することができます。本来の用途とはまた違う使い方をいろいろ組み合わせることによって、新しい価値が生み出せるはずです。
ハードウェアのアーキテクチャが変わったことで、できることの幅が格段に広がりました。AIを使った超個人最適化も、その一つです。
※6 ECUとは
「Electronic Control Unit」の略。車両内の各機能を制御するコンピューター。セントラルECUは、それらを統合的に制御する中枢となるECU。
——セントラルECUを起点にしたアーキテクチャへの変更は、かなり大胆で、大変な変更だったと思いますが、いかがでしたか。
おっしゃる通りで、4～5年単位の長期プロジェクトです。今も進行中で、Honda 0シリーズでようやく最終段階に入ってきました。
開発体制の変化に伴い、部署ごとに違う文化や言語、プロセスをどうすり合わせていくかには苦労しました。ただ「良いクルマを作りたい」という思いは共通です。議論は激しいですが、みんな前向きに取り組んでいました。
私もCDC（コックピット・ドメイン・コントローラ）とセントラルECUの両方を見るようになって、ソフトウェア開発プロセスの違いに驚きました。各部署の間でも、開発のやり方がまったく違います。Hondaの車両側の開発の規定は整備されているので、そこは頼りになるのですが、ソフトウェアの開発になると開発ユニット間で共通となる開発基準はまだありません。
開発のクロスドメイン化を進める中で、これまで見えなかった課題が表に出てきている段階だと思います。そこはちょうど苦労しているところですが、逆に言うと、それが面白いとも言えます。“良いとこ取り”をしながら、標準的なものをつくり上げるプロセスを楽しんでいますね。
——その中で、スマートキャビンの理想の開発スタイルはどうあるべきか、という議論も盛んに行われているのではないかと思います。あるべきHondaのスマートキャビンの開発プロセスとは、どのようなものでしょうか。
自動車ソフトウェアの開発では常にそうなのですが、アジャイルな開発体制とクルマの安全規格の両立はいつも悩むところです。私たちはAndroidベースで高速に進化するIVIと、ASIL（Automotive Safety Integrity Level)※7のクリアが必須のメーター系ソフトウェアを、同一CPUで動かそうとしています。
クルマの「走る・曲がる・止まる」という、それこそ人命に直結するソフトウェアと、OTA※8 で頻繁に更新しながらAIを活用するようなアプリの開発を、どう分離・共存させるか。従来の機能をいかに崩さずに新しいことをやっていけるか。それらを統合するアーキテクチャも開発プロセスも、まだまだ模索中です。
海外の自動車メーカーでは、意思決定もトップダウンで速い。一方、Hondaは積み上げた品質基盤があるぶん、変革がなかなか難しい面があります。
スピードだけ見れば、トップダウンによる意思決定は速い。でも、Hondaのボトムアップにも良さがある。どちらが正解だと言い切るのは簡単ではありませんね。
※7 ASILとは 「Automotive Safety Integrity Level」の略。自動車ソフトウェアの安全性を定量的に評価する国際規格。人命に関わる機能では高いレベルの認証が求められる。 ※8 OTAとは 「Over The Air」の略。無線通信を介してソフトウェアやファームウェアなどのアップデートを含む、⾞両とのデータの送受信を⾏う技術のこと。
——あらためて、Hondaのスマートキャビンの優位性はどこにありますか。
2025年のCESで、Hondaは「ASIMO OS」というコンセプトを発表しました。ECUを統合的にコントロールし、スマートフォンにおけるAndroid OSやiOSのように、さまざまなアプリケーションを動かすための環境を車両に提供する。ここにアーキテクチャの刷新が関わってくるのです。
Honda 0シリーズで刷新したE&Eアーキテクチャ※9。中でも、CDC（コックピット・ドメイン・コントローラ）を前提にした構成は、他社に先行している部分だと思います。これによってユーザーに新しい体験価値を提供できるようになると考えています。
※9 E&Eアーキテクチャとは 車両内の電気（Electrical）・電子（Electronic）システム全体の構成設計。
たとえば、EVの充電時間や将来の自動運転では「車内で何をするか」が重要になります。以前、伊東と一緒にアメリカに出張したとき、Honda車ではない他社のEVを使ったのですが、充電中が暇なんですよね。治安もよくわからないアメリカの田舎町で、あまり外に出たくない。車内でぼーっとしながら、1時間ぐらい過ごしていました。
クルマの中の過ごし方は、人によってやりたいことが違いますよね。YouTubeを見たい人もいれば、ゲームしたい人もいるし、寝ていたい人もいる。中にはTeamsでオンライン会議に参加せざるをえない人もいるでしょう。
まさに十人十色。だからこそ、それぞれの人にあった超個人最適が必要になる。車室カメラや座席センサーなどからの情報をAIが理解して、「この人はいま一番こうしてほしいだろうな」ということをリコメンドできるクルマをつくっていきたい。それこそが、EVならではの使い方なんだと思っています。
超個人最適化をするためには、やれることを増やさなければいけない。たとえ一人しか使わない機能であっても、大量のコンテンツを使えるというのは重要なのかなと思います。
そこでは、Google Play Storeのような外部エコシステムを活用することも重要になります。Honda自身もアプリを配信できるし、私たちがすべてを開発しなくても、サードパーティがアプリを開発してクルマをどんどん変えていける。ユーザーも好きなアプリをダウンロードして楽しめます。
──スマートキャビンでユーザーの体験価値を高める。そのためには、たった一人のユーザーのニーズでも想像し、必要であればサービス化する。キリがなくても、それに対応していく、ということですね。
それができたら理想かもしれませんが、いま私たちが取り組んでいる一例として、ユーザーがカーナビをどう使っているかというデータを分析しています。たとえばユーザーがカーナビ操作でよく間違うパターンを分析し、それが頻繁に起こっているようであれば、画面遷移を少し変えるだけで、ずっと操作性が良くなります。
さすがに十人十色とはいかないですけれど、まずはそうしたユーザーのデータを分析して、OTAによる次の配信でアップデートするという取り組みはすでにやっています。
一人ひとりのユーザーに最適化されたサービスは、まさに無限のユースケースとの戦いですね。人の手で開発するともうキリがない。個人的には、これはもうAIを使うしかないと考えています。サービス提供のアルゴリズムもAIで作る。こういった世界観に変えないと、究極のパーソナライズ化は実現できないと思っています。
先ほど、セントラルECUに集約することでさまざまなデータを取得できるようになったとお話ししましたが、それらをサーバーなどを活用して分析しようとすると、車両から収集できるデータ量は非常に膨大になります。
実際に、データを丁寧に取得していくと、その規模はエクサバイト級に達する可能性もあります。これだけのビッグデータを分析することは、世の中でもまだ多くはないと思います。そこにAIを使って、かつ今までの運転以外のところに新しいサービスを出していくのは、やはり難しいですね。
その課題を超えるためには、前提としてデータフォーマットの整理や、バラバラなAPIを超えた処理が不可欠になります。今は、国内の業界団体でも、そうした点を巡って盛んに議論しているところです。
自動運転なら、ある程度の正解があるのかもしれませんが、スマートキャビンには正解がない。無限にパーソナル化しようとすると、無限のケースに向き合うことになります。
たとえば、ドライバーの心拍数を測った際に、通常よりかなり高い場合は急いで家に帰れるようにアシストするとか、冷房も少し弱めにしておこうとか、シートポジションを少し変えるだけで楽になるんじゃないか、など。
本当にやりたいこと、できることがいくらでもあるため、やはりスマートキャビンは難しい。けれども、私たちはそこにチャレンジしたいのです。
なぜなら、クルマの車室は、それ自体とても魅力的な空間だからです。プライベートな空間にエアコンもあれば、ディスプレイもある。サラウンドのスピーカーや手元のライトもあって、車室空間の色も明るさも変えられる。ベンチレーションやヒーター、マッサージ機能つきで、シートバイブレーションまで備えた座席もある。こんな空間、自宅のリビングにもないでしょう。
Wi-Fiもついているので、たとえば音楽に合わせてシートバイブレーションを連動させたり、アンビエントライトなども制御することもできます。
今ある車室内のデバイスもさらに進化するかもしれません。フロントガラスはただのガラスですが、たとえばAR/XRをそこに投影すれば、面白いことがどんどん広がります。そういうことも私の夢の中にはあります。会社の資料には一切出てないですけど(笑)
こうした環境をフルに活用して、スマートキャビンでこれまでにない「自分だけの空間」を作れる。家にもどこにもなかった空間を作れる。これは私自身、魅力的だと思いますし、知らない世界だと思っている人にも魅力的に感じられると思っています。
——そうしたスマートキャビンの可能性が感じられるようになってきた中で、開発者の皆さんのマインドに変化が起こっていますか？
それはあると思いますよ。たとえば、人間の心理や快適感は、人それぞれ感じ方が違いますよね。その人にとって、クルマの中における快適さとはどのようなものかというのを3日間ワイガヤ※10 で議論しても、なかなか解は出ません。
ただ、これまでは要求仕様に基づいてソフトウェアを作るのがメインでした。それが今は、ユーザーがどういう価値を求めているのか、場合によっては人間の心理まで踏み込んで考え、自分たちで仕様に落としてソフトウェアとして実装していくようになった。そこが、スマートキャビンになって変わってきたところだと思っています。
その際に使っているのが、クリティカル・ユーザー・ジャーニーという、顧客が製品やサービスを利用する中で、最も重要となる目的達成までの体験の流れに焦点を当てて可視化・分析する手法です。たとえば、弊社の役員がゴルフの練習場に行くまでのパターンを洗い出してユーザーシナリオを作って、これが快適なんじゃないかといった議論もするようになりましたね。
※10 ワイガヤとは 「夢」や「仕事のあるべき姿」などについて、年齢や職位にとらわれずワイワイガヤガヤと腹を割って議論するHonda独自の文化のこと。
組織的にも変化がありました。量産開発をしているメンバーから切り離して、新しい価値を考える組織を作りました。
「新しいことを考えるのはこの課、それ以外の人は考えなくてもよい」という状態になるという懸念もありましたが、実際はそうなりませんでした。「新価値を考える」専任の課を作ったことで、むしろみんながいろいろなことを考えるようになった。
かつては、それぞれが分担して部品を作るという考え方が普通でした。それが今は、CDC(
コックピット・ドメイン・コントローラ）という”部品”は作っているのですが、意識としては「一つのクルマを一緒につくる」というように変わってきました。
その意識の変化はすごく感じますね。それこそが、サプライヤーではなく完成車メーカーの醍醐味でもありますし、スマートキャビン特装車という車種があって、ソフトウェアを実車に載せて、実際動いているのを見ると感動もひとしおです。
でも、シートポジションやハンドル位置といった言葉でいくら話していても、実車に載せてみるとハンドルが遠すぎてダメになることもある。それはそれでリアルな話です(笑)
私がHondaに入った3年前は、部署全体のミッションがソフトウェアの内製化、手の内化でした。今はユーザーが求める新しい価値創造へと、みんなの意識がシフトしています。組織の上位者の発信もそれに応じて変わってきたし、組織全体に浸透しているように感じます。
——部品として開発していた時と現在では、サプライヤーとの付き合い方も変わりそうですか。
たとえば、今までの部品を作る形では、ある程度要件は固まっているので、ハードウェアのリソース管理などを前提に、ハードウェアのTier1がそれをクリアする、という進め方ができていました。
しかし、今はハードウェア上で動作するソフトウェアがどんどん進化します。アプリケーションが追加され続けると、どれだけハードウェアのリソースを使うかがコントロールしづらくなってしまいます。
そこは、まさに私たちがコントロールしなければならない。これまではTier1にお任せしていたところも、私たちがきちんと対応していく必要が出てきています。例としては、そういう点が変わっていますね。
今までは部品メーカーがある程度担っていたことも多く、部品一つの開発であれば、そこで投資できていたから成立していました。でも、何か新しい部品を作るとなると、Hondaの違う部署同士と部品メーカー、さらに別の部品メーカーがいて、この4者の組み合わせでディスカッションしていかないと、なかなか前に進まなくなってきました。
私たちOEMの立場で言えば、ソフトウェアの内製化に加えてアーキテクチャが変わり、いろいろなことができるようになった。その意味で、ようやく環境が整ってきた、いうことが大きいと思いますね。
とはいえ、ハードウェアサプライヤーが不要になるということではありません。ソフトウェアディファインドになって、あたかもソフトウェア偏重という論調もあるのですが、個人的にはまったくそうではないと思っています。もちろんソフトウェアは重要ですが、ハードウェアも当然、重要です。
ソフトウェアがどんどん進化するからこそ、ハードウェアもどんどん進化させていかなければならない。そういう意味ではサプライヤーの技術というのは実はさらに必要になっている側面もあります。
ユーザーの利用シーンを深く想像するなど、ソフトウェア開発以外の多岐にわたるところも必要なのですが、それを実現しようと思ったらやはり今ボトルネックになっていることが、いかにハードウェアの機能を最大限引き出せるかということなのです。
これまで以上に、スマートキャビンの開発者にはハードウェアに関する知識が求められるようになっています。ユーザーにとっての利用価値などを検討する一方で、それを実現するためには、ローレベルなハードウェアとアーキテクチャを理解した上で設計を進める必要があります。また、AIを活用する場合も、適切なアルゴリズムやデータ構造を踏まえて開発しなければならず、より幅広い技術的視点が重要になっています。
これから求める人材要件には、ハードもソフトもAIもユーザーマーケティングも、全部セットで必要なので、どんな人が必要かと言われるとスーパーマンになってしまうので、徐々に考えていかないとですね(笑)
——スマートキャビンの将来像から、アーキテクチャを含めた開発体制の変化、それに伴うサプライヤーとの関係の変化、さらには求める人材要件まで、幅広いお話が聞けたかと思います。本日はありがとうございました。
※記載内容は2025年12月時点のものです
