日産が挑む「AIで動くクルマ」開発の舞台裏──3つの技術戦略

ソフトウェアによって機能や体験を継続的に進化させる「SDV」は、いまや自動車業界全体で実現に向けた取り組みが本格化している。その中で、日産自動車はさらにその先を見据えている。

本記事では、日産のソフトウェア開発を統括する吉澤隆氏らが語った、AIを中核に据えた新しいクルマづくりの全貌を紹介する。2027年度に市場投入予定の自動運転技術「AIドライブ技術」、運転中の煩わしさを消す「AIパートナー技術」、そして10年かけて築いた開発基盤と大阪新拠点の狙い。700名以上のエンジニア育成、80%近いソフトウェア再利用率を実現してきた同社が、なぜ今「委託型」から「協業型」への転換を迫られているのか。その挑戦の裏側に迫る。

アーカイブ動画

日産が描く「AIで動くクルマ」の未来像とは

AIでクルマが進化する時代が始まった。日産自動車は2026年4月、「モビリティの知能化で、毎日を新たな体験に」という長期ビジョンを発表し、AIを中核に据えた新しいクルマづくりの方向性を示した。SDVの先を行く「AIディファインドビークル(AIDV)」という概念を打ち出し、2027年度には一般道でも使える自動運転技術を搭載したクルマを市場投入する計画だ。本記事では、日産のソフトウェア開発を統括する吉澤隆氏らが語った、AIとクルマの融合がもたらす具体的な価値と、その実現に向けた技術戦略を紹介する。

日産自動車株式会社
ソフトウェアデファインドビークル開発本部執行職
吉澤隆（よしざわたかし）氏

「SDVの先」を目指す3つのAI技術

吉澤氏は、日産がこれから目指すクルマづくりの方向性を「AIDV」と表現した。ソフトウェアでクルマを定義するSDVは今や業界の標準になりつつあるが、日産はその先を見据えている。ソフトウェアとAI技術を融合させた、AIで定義されるクルマがAIDVだ。

この構想を支える柱は3つある。1つ目は「AIドライブ技術」。AIがクルマを運転する自動運転技術だ。2つ目は「AIパートナー技術」。ドライバーに寄り添い、今知ってほしいこと、次に期待することをサポートするエージェント機能を指す。3つ目は「AIソフトウェア開発」。ソフトウェア開発そのものをAI技術で効率化する取り組みだ。

今年度から、新しいSDVプラットフォーム「Nissan Scalable Software Platform」を搭載したクルマが順次発売される。AIドライブ技術を搭載したクルマは2027年度に市場投入予定だ。AIパートナーは、今年度以降に発表されるクルマから段階的に機能を拡充していく計画だという。

日産が掲げる新ビジョン「モビリティの知能化で、毎日を新たな体験に」。モビリティの知能化をすべての人に届け、安心と安全でクルマのある生活を楽しんでもらう。その実現に向けた技術開発が、今まさに進んでいる。

では、このビジョンを実現するために、日産の開発組織はどのような変革を進めているのか。

10年かけて築いた開発基盤、その先に見据える「協業型」への転換

ソフトウェア開発の内製化は、多くの企業が掲げる目標だ。しかし、実際に10年間取り組み続けた企業はどのような変遷を経てきたのか。日産自動車でソフトウェア開発部を率いる杉本一馬氏は、2017年の組織立ち上げから現在までの歩みと、今まさに挑戦している開発モデルの転換について語った。700名以上のエンジニア育成、80%近いソフトウェア再利用率の実現、そしてクラウド完結型の開発環境構築。これらの実績を持ちながらも、次のステージに進むために「委託型」から「協業型」へとビジネスモデルを変えようとしている。

日産自動車株式会社
ソフトウェアデファインドビークル開発本部ソフトウェア開発部部長
杉本一馬（すぎもとかずま）氏

内製化10年の軌跡と積み上げた成果

日産自動車のソフトウェア内製開発部が立ち上がったのは2017年。杉本氏自身も中途入社組であり、2015年に日産に加わった。

当時、自動車会社には内製開発の文化がなかった。CI/CDの概念も、ソフトウェアのブランチ管理も浸透していなかった。ハードウェア中心の開発が当たり前で、ソフトウェアはハードウェアとセットで開発されていた。

この10年間で取り組んできた主な施策は3つある。一つ目は、ソフトウェアトレーニングセンターの設立だ。2018年頃に立ち上げ、これまでに700名以上の日産社員を教育してきた。

2つ目は、ソフトウェアの管理手法の確立である。アプリケーションをコンポーネント化し、共通機能化してソフトウェアを管理する仕組みを構築した。その結果、新しいクルマが出る際も約80%という高い再利用率を実現している。

3つ目は、CI/CD環境の整備だ。2019年頃からADAS（先進運転支援システム）を中心にCI環境を構築し、近年はAWSと協業してクラウドで完結できる環境へと進化させた。

なぜ今「協業型」への転換が必要なのか

しかし杉本氏は、これまでの成果を語りながらも「ここからが本当のチャレンジ」だと語る。

従来の開発体制は、OEM（自動車メーカー）が要求を出し、その下にティア1サプライヤー、さらにその下に様々な開発会社が連なるピラミッド型だった。この構造では、SDVの時代に求められるスピードに対応できない。クルマが顧客に届いた後もソフトウェアのアップデートが続くため、その都度契約をやり直して作り直すわけにはいかない。

「プロダクトを持っている日産が中心となって、パートナーと一緒に手を組んで協業でものづくりをしていく形を作りたい」と杉本氏は話す。これによりインテグレーションの責任は日産が負うことになる。そのための環境もプロセスも必要だ。大きなチャレンジではあるが、この形を実現できなければ、AIDVの世界で生き残っていくことはできないという危機感がある。

プラットフォームの「手の内化」という挑戦

もう一つの課題は、内製化の範囲拡大だ。これまで日産が内製してきたのは、ほとんどがアプリケーションレイヤーのみだった。プラットフォームはハードウェアと一緒にティア1サプライヤーに委託していた。その結果、紙でプラットフォームを発注し、アプリケーションだけ自社で作り、車両開発の中盤から後半でインテグレーションすると不具合が出る。お互いに修正を繰り返す手戻りが発生していた。

これを変えるため、アプリケーションに影響があるプラットフォームについては、日産が協業の形で「手の内化」し、プラットフォームを先行で開発する方針に転換する。安定したプラットフォーム上にアプリケーションを構築していくスタイルだ。

ただし、日産にはまだプラットフォームを構築する知見やスキルが十分ではない。協力会社やパートナー、そしてこの領域の知識を持った新たなソフトウェアエンジニアに加わってもらい、共に挑戦していきたいと杉本氏は呼びかける。特にコックピットのプラットフォーム領域については、新たに立ち上げる大阪拠点を中心にチームづくりを進めていく計画だ。

開発スピードを競争力に変える

杉本氏が繰り返し伝えたのは、SDVやAIDVの時代において「開発スピードそのものが競争力になる」という認識だ。クルマとクラウドをつなぎ、データを吸い上げ、新しいソフトウェアをOTAで素早く届ける。このループを回すためには、従来の委託型では限界がある。

10年間で築いた内製基盤。その上に、パートナーとの協業、プラットフォームの手の内化、そして新拠点での人材確保という新たな挑戦が始まる。

では、具体的にどのような技術領域で、どのようなエンジニアが求められているのか。続くセッションでは、大阪拠点で展開するAndroid Automotive OSの開発について詳しく語られる。

なぜ日産は大阪でAndroid開発を始めるのか

クルマがスマホのように進化する時代が来た。日産自動車でソフトウェア開発を担う伊藤義信氏は、Android Automotive OSを活用したコックピット領域の内製化を進めている。年1回のAndroidアップデートへの追従、200万件を超えるテストケースへの対応、そして車両システムとの統合という複雑な課題に挑む。2026年4月、日産は大阪に新拠点を開設した。なぜ神奈川ではなく大阪なのか。本記事では、SDV時代に求められる開発体制の構築と、その実現に向けた具体的なアプローチを紹介する。

日産自動車株式会社
ソフトウェアデファインドビークル開発本部ソフトウェア開発部シニアマネージャー
伊藤義信（いとうよしのぶ）氏

クルマの中でAndroidはどこで動いているのか

SDVという言葉を耳にする機会が増えた。直訳すれば「ソフトウェアによって定義される車両」だ。伊藤氏によると、これまでのクルマはエンジンの動力性能やボディ剛性、サスペンションによる乗り心地といったハードウェアの価値に依存してきた。しかしSDV時代では、スマホがアップデートで進化するように、クルマの機能が購入後も継続的に向上していく。つまり、『お客様の手に渡った後も、ソフトウェアの力で価値が進化し続ける』。これがSDVの世界だ。

では、クルマの中でソフトウェアはどこに載っているのか。車内には多数のECU（Electronic Control Unit／電子制御ユニット）と呼ばれる小型コンピュータが搭載されている。センサーが捉えた情報はCANやイーサネットといったプロトコルを通じてECUに伝達され、OSの上で動くソフトウェアが処理を行い、最終的にアクチュエータへ命令を出す。

今回、大阪拠点でフォーカスするのは「CDC（Cockpit Domain Controller）」と呼ばれるECUだ。これはセンターディスプレイやメーターといったコックピット領域を司っており、その一部にAndroid Automotive OSが搭載されている。単に大きなAndroidタブレットを積めばよいわけではない。クルマという特殊な環境に適合するには、アプリケーション開発だけでなく、その下回りのプラットフォーム部分を自分たちで作り込む必要がある。

内製化を阻む3つの壁

コックピット領域の内製化には、いくつかの壁が立ちはだかる。

1つ目は、従来の開発体制の問題だ。これまで自動車メーカーは要求を出し、Tier1サプライヤーがSoCベンダーやOSベンダーと連携して開発を進めてきた。この構造では納入されるソフトウェアがブラックボックスとなり、中身が見えづらい。日産はサプライヤーと直接会話しながらソフトウェアをホワイトボックス化する「協業型」への移行を進めている。

2つ目は、Androidの複雑なレイヤー構造だ。アプリケーションは表層の一部に過ぎず、その下にはAPIレイヤー、システムサービス、Androidランタイム、HAL（Hardware Abstraction Layer）、Linuxカーネル上で動くシステムデーモンといった複数の層が存在する。さらにCANやイーサネットで接続された車両側のシステムも変化し続けている。そのため車両側の設計も理解しつつ、これらレイヤーをいかに整理していくかが内製開発のコアとなる部分だ。

3つ目は、パーティション管理の問題だ。Androidは年1回バージョンアップするため、適切なパーティションにソフトウェアを配置しておかないとアップデートに追従できない。標準のAndroidソースはシステムイメージに、独自要求はプロダクトイメージに、サプライヤーが作るペリフェラル領域はベンダーパーティションにと、明確に分離してインターフェースを決めておく必要がある。

段階的な内製化と200万件のテスト自動化

日産は段階的に内製開発へ移行しようとしている。現在はアプリケーション領域にフォーカスしているが、次のステップではバニラAndroid（標準のAndroid）を活かし、独自要求を外部に切り出していく。最終的には自分たちでソフト開発からビルド、インテグレーション、検証、市場車両へのデプロイまでを一貫して行える体制を目指す。

Androidを名乗って市場に出すには、xTSと呼ばれるテストスイートをパスして認証を取得する必要がある。ATS（Android Test Suite）、CTS（Compatibility Test Suite）、VTS（Vendor Test Suite）など、その件数は約200万件に上り、Androidのバージョンが上がるたびに増加する。これをバイナリごと、バリアントごとにかけていかなければならない。手動では不可能であり、CI/CDの環境整備と並列分散処理による効率化が不可欠となる。

さらにSDV時代には、FOTA（Firmware Over The Air）だけでは機動力が足りない。FOTAはイメージごと書き換えるため、アプリケーションだけ更新したい場合でも依存するライブラリやOSを含めて再検証が必要になり、年に数回のアップデートが限界となる。バグ修正を翌日に反映したい、顧客要望にすぐ対応したいというニーズには、アプリ単位でアップデートできる仕組みが求められる。

クルマをプログラマブルにするAPI標準化

クルマの機能をAPIとして切り出す「ビークルAPI」の取り組みも進んでいる。窓の開閉、ドアの開閉、ワイパー、シートといった機能を抽象化してAPIとして提供し、開発者がそれらを組み合わせてアプリケーションを作れるようにする構想だ。

ただし、APIを用意しただけでは開発者は参入しない。伊藤氏は「アプリを作っても儲からないと思われたら誰も作ってくれない」と指摘する。開発者が魅力を感じる規模が必要であり、そのためJASPARにて他社OEMとビークルAPIの標準化活動を進めている。この成果物はOSSとしてGitHubで公開している。日産車だけでなく、他メーカーのクルマでも同じアプリケーションが動く世界を目指している。

大企業でベンチャー的に働く

なぜ大阪に拠点を設けるのか。理由の1つは、首都圏以外のエンジニアへのリーチだ。関西エリアにはSIerや組み込み開発の拠点が多く、多彩なエンジニアが集まっている。もう1つは、Androidのコックピット領域がクルマの「走る・曲がる・止まる」とは離れた領域にあり、勤務地の制約を受けにくいことだ。

開発環境はクラウド上に構築されており、ロケーションフリーで作業できる。GitHub Copilot、Cursor、ChatGPTといったAIツールも利用可能だ。フィジカルな検証環境への接続も大阪から行える。

伊藤氏は「大企業でありながらベンチャー企業的な気質を両立できるポジション」と表現する。ソフトウェアエンジニアの数が他のOEMに比べてまだ少ないからこそ、一人あたりの責任と権限が大きい。「これよろしく」と言われれば、投資も含めて自分で成し遂げることを期待される環境だという。

SDV時代のソフトウェア開発は、作って終わりではない。クルマが顧客の手に渡った後も価値を届け続ける。その基盤を自分たちの手で作る挑戦が、大阪から始まろうとしている。

Q&Aセッション

Q. Googleアップデート対応まで内製化すると人的コストが増えると思いますが、開発速度向上がその目的になるのでしょうか？

伊藤：実際にやってみないと見えてこない部分もあります。Androidに限らず、ボディ領域、Linux領域でも内製化を進めています。最初は投資がかさみますが、新しい要求が出てきたときに自分たちですぐ開発・修正できるメリットは大きいです。特にSDVの領域ではそれが強く求められますので、Androidのプラットフォーム領域でも内製化を進めることで、クイックなソフトウェアアップデートや継続的な価値提供を実現していきたいと考えています。

Q. 2017年にソフトウェア開発の組織が立ち上がる前は、各部署でバラバラに開発していたのですか？

吉澤：自動車会社はどこもそうだったと思いますが、システム軸で組織が作られていました。パワートレイン、シャシー、ボディ、内装、外装というようにファンクションごとに分かれていて、その中にエアコンやドアロックなどの制御系チームがいました。ソフトウェア開発が会社の中で縦にバラバラになっていたのです。それをソフトウェアを軸にした開発にするために、ソフトの階層を全部横切って私がまとめたのがソフトウェアディファインドビークル開発本部の由来です。2017年以前はおっしゃる通り点でバラバラ、仕事のやり方もツールもバラバラでしたが、今は横軸ができつつあり、ツールもプロセスも人もワンチームでできるようになってきました。

Q. 委託型から協業型へ移行する目的の一つがホワイトボックス化だと理解しましたが、協業先にとっては技術を公開するリスクもあるように見えます。協業先のメリットは何でしょうか？

杉本：おっしゃるポイントは非常に重要です。ブラックボックスかホワイトボックスかという話と、IPをどう扱うかは、協業が進むほど難しくなる領域です。一方で、IPをあまり気にしていない中国ではすごいスピードで協業が進んでいます。IPを侵害しない領域でどれだけ協力できるかが鍵だと思っています。競争領域と協調領域を分けて、競争領域はそれぞれのIPを保持しながら、協調領域はオープンソースの考え方に近い形でみんなで使えるアセットを作っていく。この仕組みを日本の中でもっと広げていかないと、日本のソフト作り自体が勝てなくなると思っています。全部公開してくださいという乱暴なやり方ではなく、ウィンウィンになる形を協力してくださるパートナーさんと一つ一つ詰めながら、スピードを落とさない仕事のやり方を作っていく必要があります。

Q.ソフトウェアエンジニアとして日産で働くことの魅力を教えてください。

伊藤：日産はソフトウェアエンジニアの数が他のOEMさんに比べてまだ少ないのですが、裏を返せば一人あたりのレスポンシビリティが非常に高いということです。「これよろしく」と言われるのは、投資も含めて権限を移譲し、責任を持ってソフトウェア開発をやらせてくれるということ。それが日産の魅力だと思っています。

Q. 日産が目指すビジョンはAIを活用した知能化だと理解しましたが、具体的にどのようなスパンやマイルストーンでAIDVを目指しているのか教えてください。

吉澤：今回日産は「モビリティの知能化で、毎日を新たな体験に」という新しいビジョンを作りました。モビリティの知能化を全ての方に提供し、お客様に安心安全なカーライフを楽しんでいただきたいという想いです。AIを使った知能化の中核である自動運転については、2027年度、つまり2027年4月から2028年3月までの間に、End to EndのAIドライブ技術を実装したクルマを世の中にお届けします。クルマの機種も発表しており、社会に対してお約束した形になっていますので、確実に提供します。もう一つのAIパートナー技術については、色々なものが徐々に進化していくものですので、最初のステップは今年度からこれから発売・発表するクルマから徐々に採用していくロードマップで進めています。

文：坂本奈穂
※所属組織および取材内容は2026年4月時点の情報です。

日産が挑む「AIで動くクルマ」開発の舞台裏──3つの技術戦略

アーカイブ動画