【デンソー】命を守るソフトウェア検証の舞台裏――安全と品質を支える検証基盤づくり【DENSO Tech Night 第五夜】

車のハンドルを操作するその瞬間に、様々な制御が行われていることをご存じでしょうか。私たちが何気なく使う製品の裏側には、想像を超える技術の積み重ねがあります。

本記事では、世界トップクラスの自動車部品メーカーである株式会社デンソーの開発現場に迫ります。100万分の1秒という驚異的な精度で動くステアリングシステムの仕組み、増え続けるテストを87%削減した組織づくりの工夫、そして2030年に向けたAI活用の展望まで。命を預かるモノづくりの最前線で、技術者たちがどのような課題に向き合い、どう乗り越えようとしているのかを紹介します。

アーカイブ動画

究極のレスポンスと最高の安全性を両立する〜100万分の1秒を制御するステアリングソフト開発の挑戦〜

株式会社デンソー
ソフトウェア技術4部
第1設計室長
滝雅也（たき・まさや）氏

EPSとは何か――「曲がる」を支える製品

2005年に株式会社デンソー（以下「デンソー」）入社以来、一貫してステアリング系のソフトウェア開発に従事してきた滝氏。世界初の2系統機電一体EPSのソフトウェア開発リーダーとして、2019年に文部科学大臣表彰を受賞した実績を持つ。現在は次世代製品「ステア・バイ・ワイヤ」のソフト統括を務める傍ら、社内の高度スキル人材認定制度「SOMRIE認定」においてレベル4に認定されている、名実ともに同社のソフトウェアエキスパートの一人だ。

EPS（Electric Power Steering：電動パワーステアリング）は、モーターの力でハンドルの操作をサポートする製品だ。車の三大要素である「走る・曲がる・止まる」のうち、「曲がる」を担当している。ドライバーの力をアシストするだけでなく、自動駐車や自動運転の際には、ドライバーに代わってハンドルを操作し、車の進む方向をコントロールする役割も担う。

普段はその存在を意識することのない製品だが、正しく動かなければ人命に関わる。自動車業界で最も安全要求レベルが高いASIL-D（ISO26262で定義される最高水準の安全性）が求められる製品である。

世界初の2系統MCU（Motor Control Unit）が生まれた背景

従来の電動パワーステアリングでは、電子回路やモーター巻き線に不具合が発生すると、アシストを停止するしかなかった。そのため、ドライバーは予告なくハンドルが重くなる状況に対応せざるを得ない。

この課題を解決するため、デンソーは2014年に世界初の2系統電動パワーステアリングを開発した。独立した2つの電子回路と2つのモーター巻き線で構成され、通常時は2系統でアシストを行う。万が一、片方に不具合が発生しても、もう片方でアシストを継続できる設計だ。

2系統を実現した鍵は、モーター巻き線の特殊な巻き方と電子回路の集積化技術にある。これにより大幅な小型化を実現しながら、より安心・安全な走行を可能にした。

1マイクロ秒以下の同期制御という挑戦

2系統MCUのソフトウェアには、極めて厳しいリアルタイム性が求められる。モーターの電流制御は100μ(マイクロ)秒周期(＝1000分の1秒周期)で行われている。一般的なゲームの画面更新が60fps（約16.6ミリ秒）であることと比較すると、その100倍以上の速度だ。

さらに難しいのは、2つのマイコン（動作制御を行う小型コンピュータ、ICチップ）を協調させる点にある。滝氏は「それぞれのマイコン、ソフトウェアを、なんと100万分の1秒の精度でタイミング合わせをしている」と語る。1マイクロ秒以下のタイミングで2つのモーターを同期させることで、静かで快適な制御を実現している。

マイコンの性能は、一般的なパソコンの10分の1以下のクロック数しかない。限られたリソースの中で、この精度を実現することが求められる。

ソフトウェアの安全品質へのこだわり

回路を2系統化しても、ソフトウェアに異常をきたせば製品としての安全を担保できない。滝氏は「ソフトウェアの中身、内部状態について、例えば個々の変数に対して、どういう状態になるのかをパターン化し、システムの安全性に対してどういう影響を与えるのかを検証している」と述べる。

例えば、EPSの異常動作には「ドライバーの意図に反して勝手にハンドルが操作されてしまう」「ハンドル操作ができなくなる」といったパターンがある。ソフトウェアの内部状態、その状態パターン、そしてシステム状態を掛け合わせて検証し、影響がある箇所には対策を講じていく。

次の挑戦――4つのソフトが連携するステア・バイ・ワイヤ

現在、デンソーはステア・バイ・ワイヤという新しい製品の開発に取り組んでいる。ハンドル側とタイヤ側が機械的に結合されず、電気的に結合されている製品だ。ハンドル側とタイヤ側それぞれに2系統MCUを使用し、安全に操作できる構成を提案している。

つまり、1つのMCUに2つのソフトウェアが入り、それが2つ協調して動く。合計4つのソフトウェアが1つのステアリングシステムを構成するため、検証すべきモードは掛け算で増え、検証の難度は跳ね上がっていく。

滝氏は「検証すべき項目や実際にテストをすべき項目も、指数関数的に増加する」と課題を示す。複雑化するソフトウェアの品質を守り抜くためには、増え続けるテストをいかに攻略するかが鍵となる。

安心・安全なモビリティ社会の実現に向けて

安心・安全なモビリティ社会の実現に向けて、EPSの開発は、乗用車だけでなく大きな出力が必要となるバスやトラックなど大型車両にも広がっている。この広がりを支えるのが、筐体の小型化と構造の共通化の実現である。小型化にはECU（Electronic Control Unit：電子制御ユニット）の高密度実装技術や、基板の両面から放熱を行う独自技術が貢献し、構造の共通化によって、コネクタやモーター、ケースなどの部品を、車両のニーズに合わせて柔軟に選択・差し替えできる設計を実現した。さらに将来的には、ステアリング以外の小型モビリティの「走る」領域への展開も視野に入れている。

命を守る製品開発には、究極のリアルタイム性と徹底した安全検証の両立が求められる。100万分の1秒という精度で制御を行いながら、変数の1個にまで検証を行う姿勢が、世界最高水準の安全性を支えている。

命を守る検証が｢回る｣　～現場で使える検証基盤づくり～

株式会社デンソー
ソフトウェア技術4部
テスト革新課
担当課長
鈴木雅彦（すずき・まさひこ）氏

車載ソフトウェア開発が抱える固有の難しさ

2008年のデンソー入社以来、パワートレインECUのソフトウェア開発を一貫して担当してきた鈴木氏。車載ソフトウェアのプラットフォームである「ベーシックソフトウェア(BSW)」の開発や、エンジンECUプロジェクトの新規立ち上げなど、製品開発の全工程を歩んできた現場のスペシャリストだ。現在はその豊富な経験を活かし、ソフトウェア開発のDX推進を担当している。

車載ソフトウェア開発には、Webやアプリ開発とは異なる特有の制約がある。鈴木氏によると、Webや情報系のソフトウェアでは機能やユーザー体験の実現が主な目的となり、リソースは比較的潤沢で、後からメモリを増やしたり性能を増強したりすることも可能だ。時間的な制約としても、人が体感的に速いと感じられれば問題ないことが多い。

一方、車載組み込み系のソフトウェアでは、性能と安全性の両立が最優先となる。小さなマイコン上で動作させなければならず、一度販売した後にリソースを拡張することはできない。そして何より重要なのがリアルタイム性だ。100μ秒単位での制御が求められ、各々がハードウェアに直結されており、ソフトウェアとハードウェアが直結している関係上、それらが正しく連携して動いているかを緻密に検証する必要がある。

デンソーでは「品質と安全のデンソー」という標語を掲げており、ソフトウェア開発においても同様のこだわりを持って進めている。マイコンのレジスタ値がどうなっているか、高速通信が電気的に正しく動いているかまで細かく検証する。C言語で書いたコードがコンパイラでどのようなアセンブラーコードに展開され、マイコンの中でどのように動くかまで追いかける。

「ソフトウェアだけではなくて、基盤となるハードウェアのことも理解して、それを判断できるエンジニアがソフトウェアの振る舞いを検証している。こうすることで、小さな違和感があっても不具合を見つけられる」と鈴木氏は語る。

安全品質へのこだわりと大規模検証の両立

さらに検証項目は年々増加している。機能安全、サイバーセキュリティ、法規制対応、OTA（無線によるソフトウェア更新）など、開発量よりも検証量の増加スピードが速い。同じ機能であっても、正常時と故障時、それぞれのシチュエーションを組み合わせてテストする必要があり、検証すべきパターンは指数関数的に増えていく。

しかし、この徹底した検証と増え続ける検証量との両立が最大の課題となっている。従来対応である人海戦術では限界がある。そこでデンソーでは、安全品質へのこだわりと大規模検証のやりきりを使い分けて対応している。豊富な知識と経験を持つエンジニアが、その人でないと気づけないような不具合を見つける領域と、パターン化して自動化できる領域を明確に分けているのだ。

車載組み込みソフトにおける「V字モデル」の重要性

こうした膨大な検証を効率的に、かつ確実に進めるために欠かせないのが「V字モデル」の考え方だ。

V字の左側は「何をどうつくるか」を定義する設計工程（要求定義から実装まで）であり、右側はそれに対応して「正しくつくられているか」を確認する検証工程（ユニット検証から車両統合検証まで）となっている。

鈴木氏は、このモデルにおいて「上の工程（車両統合検証など）に行けば行くほど、不具合が見つかった時の手戻りの影響が大きくなる」と説明する。そのため、各工程を一つひとつ確実に積み上げるウォーターフォール的なアプローチによって、高い品質を確保することが重要だ。

シミュレーション技術を活用した検証の自動化

この全体像を踏まえたうえで、次に重要となるのが「どの工程で、どのような検証手段を選択するか」という戦略である。

大規模検証のやりきりには、シミュレーション技術の活用が鍵となる。ここで鈴木氏は、以下4つのシミュレーション技法を紹介した。

MILS（Model-in-the-Loop Simulation）：（C言語などで）実装する前に、モデルを用いて要求や設計の考え方が正しいかを検証する
SILS（Software-in-the-Loop Simulation）：作成したコードの振る舞いが正しいかを設計者のPC上で検証ができる。ハードウェアが不要なため、比較的検証のハードルが低い
HILS（Hardware-in-the-Loop Simulation）：実際のハードウェアとシミュレーターを組み合わせ、ECUとしての振る舞いが正しいかを実環境に近い形で検証する
VILS（Vehicle-in-the-Loop Simulation）：複数のECUを組み合わせ、より実車に近い環境で検証を行う

検証が上位工程に行くほど、テストの制約や不具合発覚時の手戻りの影響が大きくなるため、検証項目に応じて適切なタイミングと手段を選ぶことが、効率的な開発において不可欠だ。

具体例として、まずはSILSの活用が挙げられる。波形画面を用いて演算結果を細かく検証できるため、ハードウェアの準備を待たずに手軽にソフトウェアのテストを行えるメリットがある。ただし、あくまでソフトウェア単体のシミュレーションであるため、最終的には実機ECUを用いた結合確認が必要となる。

そこで、より実環境に近い検証を担うのがHILSだ。

特にHILSでは、製品ごとに検証対象や環境が異なるため、個別最適化や属人化が起きやすい。「あの人しか動かせない環境」「あのプロジェクト専用のテスト」という状況は、自動化やテスト再利用の妨げになる。

この課題に対し、デンソーでは3つのアプローチで取り組んでいる。1つ目は検証環境の標準化、2つ目はテストケースの抽象化と製品の個別要素のコンフィグ化（CFG）、3つ目は作成したテストの一元管理と再利用だ。

エンジニアが全ての操作をPCから行えるようにすることで、自動化の難易度が下がった。製品ごとに異なる要素をコンフィグとして切り出すことで、テストの標準化・再利用を図っている。「何が共通で、何が製品固有の要素なのか、そのあたりは製品や技術を知り尽くしているデンソーだからできること」と鈴木氏は述べる。

安全品質と効率化、2つの柱で検証に向き合う

鈴木氏は、指数関数的に増え続ける検証量に対して、2つの柱で対応してきたとまとめた。1つ目は安全品質への徹底的なこだわり、2つ目は大規模検証のやりきりだ。

しかし、検証の仕組みを導入しても、現場に定着するまでには多くの課題があるという。技術だけでは解決できない、組織や人の問題が次の焦点となる。

DXは人が動いて初めて動き出す～テスト自動化からはじめる現場変革と組織心理アプローチ～

株式会社デンソー
ソフトウェア技術4部
テスト革新課
課長
堀川まゆみ（ほりかわ・まゆみ）氏

増え続けるテストに、力技はもう限界

キャリアの大半を車載ECUのソフトウェア開発に捧げ、通信や診断、プロジェクトマネジメントを長年経験してきた堀川氏。現在は部門やグループ会社をまたいだDX推進を担う。「SOMRIE認定」においてメソドロジストのレベル4に認定され、コーチングの資格も持つという、技術と組織心理の両面に精通したスペシャリストだ。

車載システムの中にはECU（電子制御ユニット）があり、その中にソフトウェアがある。ソフトウェアはさらにコンポーネント、ユニット、関数と階層構造になっている。仕様変更や機能追加が入るたびに、この階層すべてに影響が波及する。

堀川氏は「新しい機能だけテストすればいいわけではない。過去の全機能が壊れていないことを保証する必要がある」と語る。たった1箇所の変更でも全体に影響を与える可能性がある以上、全機能の検証が求められる。そのため力技での検証には限界がある。

この課題に対し、デンソーではHILSのテスト自動化を導入した。国内外の拠点からクラウドに接続し、365日24時間フル稼働でテストを自動的に回す仕組みを構築。テストケースの設計と結果確認はエンジニアが行うが、実行は全自動で走る。

導入から数カ月後に聞こえてきた声

技術的な仕組みは整えた。導入後、現場は動いたのか？

導入から数カ月が経つと、意外な声が聞こえてきた。「手動テストの方が早い」「忙しくて自動化システムを使う余裕がない」。堀川氏は自動化後によくある症状として、次の5つを挙げた。

利用者がなかなか増えない
準備や報告の工数が増える
手動の方が安心だと感じて戻ってしまう
詳しい人が異動して自動化が回らなくなる
推進側と現場で熱量が異なる

振り返ると、ツールの実装には全力を尽くした。しかし「人がどう行動していくか」の設計が抜けていた。これが堀川氏の気づきだった。

実際、日本企業ではDXを実施しても4割以上が成果を実感できていないというデータがある。失敗を恐れ確実な成果を選ぶ組織心理、挑戦への動機づけの欠如。技術の問題ではなく、人が動けない構造になっている可能性が高い。

技術・標準化・組織心理の三位一体

この課題に対し、堀川氏がたどり着いた答えが「三位一体のアプローチ」だ。技術、標準化、そして組織心理。この3つが内発的動機でつながり、循環していく必要がある。

技術だけでは属人化する。標準化だけでは形骸化する。組織心理だけだと精神論で疲弊し、続かなくなる。どれか1つでは回らない。

では具体的にどう行動を設計するのか。堀川氏は「意識を変えてから行動させる」という従来のアプローチを逆転させた。「行動があって体験が生まれ、そこに意識がついてくる」という順序だ。

テスト自動化における4つのステップを紹介した。まず、ツールの複雑性を隠蔽し、エンジニアがつまずくポイントをなくす。次に、CI/CD（継続的インテグレーション/継続的デリバリー）に自動テストを組み込み、テストが勝手に回っている状態にする。そして成功体験の共有会を開き、どんなに小さな成果でも発見と挑戦を歓迎する空気を作る。最後に、テスト1本から自動化を始める体験型ワークショップで、次の行動への燃料を燃やす。この仕掛けが回り始めると「今までの仕事ではもうやってられない」という声が出てくる。

とある製品のテスト工程では、自動化自体にも工数はかかるものの、一度自動化すれば再実行のたびに時間が固定される。トータルでは87%の大幅な効果が出た。さらに回せば回すほど効いてくる。

小さな成功体験から変革は始まる

堀川氏は冒頭の「なぜDXは、技術を入れるだけではうまくいかないのか」という問いに対し、「人の成功体験を設計していないから」と回答した。

変革は小さな行動を仕掛け、成功体験で後押しすることで動き出す。明日から始められることとして、堀川氏は3つを提案した。1本の自動化をしてみること、小さな成功を共有すること、そして組織やチームの強みを知ることだ。

ソフトウェアの重要性が増すなか、開発のあり方自体がAI駆動型に再定義されていく時代が来る。しかし、どんなに技術が進化しても、人が動いて初めてDXは動き出すのだ。

デンソーが考えるAI駆動型ソフトウェア開発の未来

株式会社デンソー
技術企画部
ソフトR&D室
課長
中江俊博（なかえ・としひろ）氏

車載ソフトウェアの爆発的増加がもたらす限界

デンソーでAI活用プロジェクト「AI4SE：AI for Software Engineering」を推進する中江氏は、2017年の入社以来、AIの実用化に取り組んできた。製品搭載AIの品質保証から始まり、現在はソフトウェア開発全体をAIで変革する挑戦を続けている。

ソフトウェア・ディファインド・ビークル（SDV）の時代に入り、自動車のソフトウェアは急速に大規模化・複雑化している。中江氏によると、これにより情報量が爆発し、人の認知負荷が増大。データやナレッジの断片化も進み、それを理解するためにさらに負荷が上がるという悪循環が生まれている。

「これまでの開発のやり方が限界に達してきている」と中江氏は現状を語る。

一方で、AIコーディングエージェントの進化は目覚ましい。Claude CodeやCodex、Copilot Agentなど、さまざまなツールが登場している。AIの性能評価を行う団体METRのデータによると、ソフトウェアタスクにおけるAIの能力は、おおよそ1年で10倍のペースで伸びている。イベント開催時点での最先端モデル（Claude Opus 4.6）では、14時間30分もの間、自律的にタスクを遂行できるレベルに達しているという。

Anthropic社のCEO ダリオ・アモデイ氏も「1年以内にAIモデルはソフトウェアエンジニアの業務をエンドツーエンドで遂行できるようになる」と発言している。

しかし、中江氏は実際の開発現場での適用には慎重な見方も示す。ある研究では、大規模な開発でAIを使った場合、むしろタスクの完了時間が19%増加したという結果も出ている。要因として、AIへの過剰な期待や、巨大なリポジトリからの長いコンテキストの処理が挙げられる。

この課題を突破するために重要なのが、ステートレスなAIを制御する「コンテキストエンジニアリング」だ。現在のAIはモデルが固定されており、独自のデータを与えてもその都度忘れてしまう。そのため、適切な情報を適切な粒度で与え続ける技術が不可欠だが、情報が積み重なると重要な情報が抜け落ちる「コンテキスト崩壊」などの問題も起きてくる。これらを克服する仕組みの構築が、AI駆動開発の鍵を握る。

さらに、AIが自律的に動けるようになるにつれ、人の役割の再定義も進んでいる。人はコーディングそのものから、AIの出力をチェックする承認者や監視者へと役割を変えつつある。

これからのエンジニアには、記述能力だけではなく、創造的な問題解決能力や、AIと正確に意思疎通を図るための文章コミュニケーションスキルが求められるようになる。

要求から動くソフトウェアを高速に出力する

デンソーが目指す次世代の車載ソフトウェア開発プロセスは、従来のウォーターフォール型から大きく変わる。中江氏は「要求をインプットすると、AIエージェントを備えた基盤からソフトウェアが出てくる」というAI駆動型プロセスを描いている。

このプロセスでは、デンソーが蓄積してきた過去製品の開発成果物や知見をインプットとし、人の指示と組み合わせてソフトウェアを出力する。人は検証結果をレビューし、要求が曖昧であれば要求に戻る。このループを高速に回すことで、仕様から実装、テストまでの従来の問題を解消しようとしている。

実現に向けて、中江氏は4つの課題を挙げた。1つ目はエージェント型AIの技術キャッチアップ。モデルのバージョンが1つ変わるだけで性能が大きく変わるため、タイムリーな取り込みが欠かせない。

2つ目は統合ナレッジ基盤の構築。過去のナレッジを活用できるよう、適切な文脈を適切な粒度で与えるコンテキストエンジニアリングの仕組みが必要となる。

3つ目はガバナンス革新。人とAIのコミュニケーションをスムーズにし、データのパイプラインやツール、ハード、ソフトウェアの界面がボトルネックなく流れるよう、ルールや制度を変えていく。

4つ目はAI駆動開発人材の育成。人の役割を再定義し、スキル教育を進める。

どんな知識を蓄え、どう活用するか

なかでも中江氏が詳しく語ったのが、統合ナレッジ基盤のあり方だ。

従来は仕様書や設計書といったファイルを介して情報を受け渡していた。しかし、これではボトルネックになる。中江氏は「幹となるデータは全てデジタル化して、AIが理解できる形にし、エージェント型AIが処理する」という姿を描く。

AIエージェント時代にナレッジを活用するために重要なのは、単にデータを増やすことではない。形式知と暗黙知を選別し、本当に必要なものだけを蓄えていかなければならない。

公知の情報や、形式知からロジカルに導き出せるものは、AIの知識量と推論力に頼る。一方、不具合対応などで蓄積された属人化したドメイン知識や、プロジェクト固有の決め事は、デンソー固有のナレッジとして活用する。ローカルルールのような情報は、そもそもトレーサビリティの整備という観点でデータ環境を整える必要がある。

中江氏は「人が先回りして与えすぎると、不要なデータのメンテナンスという将来の負債化にもつながる。AIの推論力を最大限に活かしながら、本当に必要なデータを見極めていく」と語る。AIが混乱してかえって性能が落ちるリスクも指摘した。

社内展開を阻む2つの壁をどう越えるか

AI技術の進化は早く、動かすまでのハードルも高い。中江氏のチームでは、まず先行開発チームが有象無象の技術やサービスから本当に有用な道具を見極める。次にパイロットプロジェクトで実際の開発現場と一体になって試行し、効果を確かめる。そして標準開発展開チームが全社的に使えるようにしていく。

開発現場への展開では「現場中核人材」と呼ぶ、AIも使える人材を配置している。「かかりつけ医のような役割」として、各現場の課題を理解しながらAI活用を支援する体制だ。

中江氏のチームでは3つの工夫を実践している。毎週、技術俯瞰ディスカッションの時間を設け、マネージャーも担当者もフラットに興味のある技術について議論する。

2つ目に、最新AI技術をすぐに試せる環境も整備している。古いモデルでは問題だったことが、新しいモデルに切り替えたら一発で解消することがあるためだ。

最後に、AI活用を推進する立場でありながら、自分たちの業務もAIで効率化することに取り組んでいる。

人を煩雑な作業から解放する

中江氏は、2030年に向けた目標を語った。

「人を煩雑な作業から解放し、本来担うべき役割に集中できるようにする」。

AIは工程の自動化と人のアシストを担い、人は何を作るべきか、どこまで許容できるかという意思決定・判断を行う。アウトプットの最終責任を人が負うことは変わらないが、責任を果たすためのやり方は変わっていく。

デンソーでは、2030年までにソフトウェアの品質が磨き上がる仕組みをつくり、開発効率を2倍にしていく（ように開発を続けていきたい）。

【Q&Aセッション】

Q&Aセッションでは、登壇者4名がイベント参加者から投げかけられた質問に回答した。

Q. 命を守る製品開発は責任が重く、業務遂行が怖くなることはありますか？どのような心持ちで平静を維持しているのか教えてください。

滝氏：怖いところもありますが、それだけやりがいがあるということでもあります。実際に製品が動いたとき、車に乗ったときは本当に感動しますし、お客さまが喜んでくれることもモチベーションになっています。また、世界に向けて発信されている動画を見せてもらったりすると、頑張ってきて良かったなという気持ちになります。

Q. 開発の工程としてはウォーターフォールが基本となりますか？

鈴木氏：車の開発ではハードウェアとソフトウェアを動かす段階があるので、大きな節目という意味ではウォーターフォールが基本的に使われています。ただ、工程の中で合理的に考えていくことは日々行われていますので、そこは使い分けています。

Q. 冗長なMCU構成で同期を取りながら実行する場合、水晶の発振ずれによりマイクロ秒オーダーの同期は高い頻度で行わなければならないと思います。どのような方法で同期を取っているのでしょうか？

滝氏：おっしゃる通り、水晶の発振ずれによって放っておくとどんどんずれていきます。オシロスコープで見ると片方のマイコンともう片方が出す波形がどんどんずれていくのが分かります。ですので、ポイントポイントでタイミングを合わせにいきます。それが先ほど申し上げた±100万分の1秒でのタイミング同期です。

Q. テストケースの再利用には過去のテスト実績一覧と概要共有がないと、似たようなテストケースを再生成しそうですが、具体的にはどうメンバーに共有されていますか？

鈴木氏：先ほどご紹介した共有するための仕組みが、開発エンジニアがみんな見られるような環境になっています。また、その中で共通化できる良いテストケースを抽出して、専門部隊がきちんと横串を刺して展開していくことで、テストの再利用性や品質を高めています。

Q. HILSなどのモデルを活用した検証において、実時間との相関をどのように取っていますか？実時間での応答検証についての工夫があれば教えてください。

鈴木氏：MILSはより細かい時間を引き延ばした形で検証しますが、リアルタイム性を確認するためのものがHILSです。そのためHILSを用いて検証することでリアルタイムの部分をきちんと見ています。また、環境内外のズレについても同期を取れるような環境を用意して評価していますので、リアルタイム性が中も外もきちんと見えるようになっています。

Q. AI駆動開発とAutomotive SPICEをどのように両立させようとしているのでしょうか？

中江氏：正直まだこれからの課題ではありますが、AIを使ってAutomotive SPICE（車載ソフトウェア開発の品質と信頼性を保証するための国際的なプロセス評価モデル）に必要な成果物は出力できると考えています。一方で、Automotive SPICEは人が開発することを前提にしたプロセスになっていますので、AI駆動型に変えていくにあたって障壁になるところがあれば、業界団体に働きかけて相場を作っていきたいと思います。本質的なものをちゃんと残していく方向を目指しています。

Q. Anthropic社が9割のコーディングをAIで実現できているなか、「2030年までに」というデンソーの目標は遅くないですか？

中江氏：その感覚は非常に正しいですし、私も2030年までに2倍というのはちょっと低い目標だと思います。実際にはもっと早く前倒しで何倍にもしていきたいと思っています。技術開発の部分は1〜2年で何倍にもなるだろうと思いますが、現場に浸透させていくとなると、今までとの連続性がありますので、ペースダウンする可能性はあるかなと思っています。

Q. 余裕がない人に対してどのような伝え方をすると動いてもらえますか？新しいことの導入を「余計なこと」と防御する人への働きかけ方を聞きたいです。

堀川氏：私の個人的な意見かもしれませんが、余裕がない時は1回目はやって見せてあげること。次には代わりにやってあげること。それでも難しかったら隣に座って、背中を押してあげる事。「誰々がやってますよ」「あっちではできてますよ」といった形です。状況判断は必要ですが、やる気が出る人もいますので、人を見ながら対応することが大切です。

Q. 無線での自動アップデートもあるのでしょうか？

滝氏：はい、あります。（想定されています。）

Q. ステア・バイ・ワイヤになると、どこかに電気的な不具合が発生した場合にメカ的に補完できなくなると思いますが、ASIL-Dを達成するための条件は明確になっていますか？

滝氏：ASIL-Dを達成するために「こうすればOK」というものは特にないと思っています。お客さまと一緒にしっかりと車を見て考えていくことが大切です。システム構成は車によって全然変わります。ただ、ステア・バイ・ワイヤというシステム自体に対しては、現在ISO化の話も上がっていて取り組みがされていますので、そういったところがガイドラインになってくるかと思います。

Q. 自動テストにおいてECUへの入出力がメカ・エレキ的なものである場合の適合性はどうやって確認していますか？

鈴木氏：CANからの信号だけで評価するのか、車全体をHILSシミュレーター上に構築して評価するのかの違いかなと思います。例えばエンジンの場合には、エンジンのモデルをシミュレーター側に作り込んでおいて、ECUからの噴射信号を入れたときにどのくらいトルクが出ているか、それがメーターのシミュレーションにちゃんと表示できているかまで見る必要があります。モデリングの規模や粒度の話で、これらは使い分けながら評価しています。

Q. 自動車業界はMATLAB/Simulinkを製品開発に使っていますが、AI駆動開発としては遅れを取っている認識です。SimulinkをやめてCコード(言語)に戻るような動きはありますか？

中江氏：技術的に言うと、Simulinkのフォーマットや構文をAIが理解していれば全然可能だと思います。

滝氏：Simulink自体の良さはシミュレーションで検証できることだと思いますので、わざわざ戻すというのはどうかなと個人的には思います。

鈴木氏：SimulinkのモデルをAIを使ってコーディングしていく世界は来ると思っています。Simulinkモデル上で検証して、そこで検証されたコードをオートコードできる世界観ができているなかで、それをAIでもう一度作り直す必要があるのかは議論するポイントかなと思います。

Q. 世の中に出ているAIの指標はIT系の比重が多く、組み込み系のような時間軸を加味するコーディングにはまだ学習データが足りないため、自動生成がままならないと考えていますが、いかがでしょうか？

中江氏：組み込み系はまだAIの領域では弱いかなと思っています。特にソフトとハードの界面などが、この業界の強みでありデンソーの強みでもあると思います。そういったところはデンソーのドメイン知識をAIに活用できるようにしたいと思っています。

鈴木氏：プラットフォームの領域やマイコンのマニュアルをきちんと理解して、そうした領域でAIが情報を提示してくれる形での活用は進んでいくと思います。ただ、システム全体としてAIが作りきるというのは、物理の世界と論理の世界がまだきちんと分かれきっていないので難しいかなと思います。そこを我々の知見の中で作り込んでいくのかなと思っています。

文＝宮口佑香（パーソルイノベーション）

※所属組織および取材内容は2026年3月時点の情報です。