車載ソフトウェアとは？定義から市場動向、SDV開発の課題と未来まで徹底解説

自動車産業は今、「100年に1度の変革期」を迎えています。その中心にあるのが車載ソフトウェアです。かつて「機械」だった自動車は、ソフトウェアによって機能や価値が進化する「走るデバイス」へと姿を変えつつあります。本記事では、車載ソフトウェアの定義と歩みから、市場動向やCASE・SDV（Software Defined Vehicle）といった最新トレンド、現在担っている機能の全体像、SDV対応（アーキテクチャ）の課題、標準化動向、機能安全・セキュリティを含む品質保証、そして求められる人材までを解説します。

車載ソフトウェアとは、車両のあらゆる機能を担うプログラム群の総称です。対象は、エンジンやブレーキといった基本走行の制御から、自動運転、運転支援、さらに自動車の情報や娯楽をドライバー・同乗者に伝えるインフォテインメント・システム（IVI：In-Vehicle Infotainment）まで広がります。これらは従来、車両全体に分散配置された多数のECU（Electronic Control Unit）に組み込みソフトウェアとして実装されてきました。各ECUが状況を判断し、ECU間で連携することで、一台の車両としての挙動を最適化しています。車載ソフトウェアは、人間の「頭脳」や「神経」のように、自動車の安全性や快適性を支える重要な役割を果たしています。

その規模は年々拡大し、現代の自動車は数億行規模のソフトウェアコードによって制御される「走るコンピュータ」へと進化しています。まずは、車載ソフトウェアがどのように広がり、どのような構造へ発展してきたのかを、1970年代から2010年代までの歩みとして振り返ります。

車載システムは、搭載機能の増加と高度化に伴って大規模化・複雑化してきました。その始まりは1970年代です。自動車排出ガス規制への対応として、コンピュータ制御によるエンジンコントロールユニット（エンジンECU）の開発が始まりました。これにより、燃料の噴射量をエンジンの負荷や回転速度といった運転状況に応じてきめ細かく変化させられるようになりました。その結果、エンジン出力の向上と燃費の改善だけでなく、排出ガスに含まれる有害成分を低減することができるようになりました。

その後、エンジン以外にも電子制御が組み込まれ、それらの電子制御装置を総称してECUと呼ぶようになります。制御対象とシステム構造は、次のように段階的に広がってきました。

• 電子制御の登場（パワートレイン制御）：ガソリン、ディーゼルエンジンの動力と、その動力伝達を制御する領域から電子制御が始まりました。
• 走行制御：走行時の操舵、ブレーキ、サスペンションなどをアシストする領域です。従来はハンドルやタイヤなどが機械制御で物理的につながっていましたが、最近では機械的なつながりをなくし、ハーネス（配線）によるデータ通信で転舵を伝える「ステアバイワイヤ」と呼ばれる方式が採用され始めています。
• ボディ制御：ライトやドアロック、空調など、快適性・利便性に関する機能を担う領域です。電子制御で機能を実現するようになり、他の車両情報（外の明るさ、外気温、車速など）と連携しながら機能を実現する形へと移行しました。
• マルチメディア：カーナビやIVI（In-Vehicle Infotainment、通信やエンターテインメント、車両設定などを幅広く統合した車載システム）など、車内への情報伝達を担う領域です。これまでスピードメーターといえば速度を伝えるもの、CDプレイヤーといえば音楽を伝えるものと単一の機器が保有している情報を表示するだけの機能でしたが、電子制御で機能を実現するようになり、車両全体の情報を伝える機能へと移行しました。
• 車載システムのネットワーク化：制御内容の高度化による入出力の増加と、複数ECUにまたがる制御の増加に伴い、必要な数だけ配線で接続する従来方式では限界が生じます。配線本数・費用・重量・スペースが増大し、故障も増えるためです。そこで複数のECU間配線を1本の通信線に集約し、ECU間のデータ転送による協調制御を行う形へ変化していきます。通信線の代表的なものにCANなどがあります。

現在主流の車載システムは、ボディ系、走行制御系など、通信速度やデータ規模といったそれぞれの制御対象に合わせて最適なネットワークを構成し、自動車全体での分散協調システムとして実現されています。

制御対象の拡大と並行して、車載ソフトウェアの構造そのものも変化してきました。ECUが登場して間もない時代には、プラットフォームという概念がなく、アプリケーションが直接マイコン（ハードウェア）を制御していました。

その後、機能数やECUの種類の増加に伴い、各ソフトウェアに共通する処理部分が増加していきます。そこで開発効率化のため、OEMやサプライヤー各社が独自でプラットフォームを構築していく流れとなりました。

車載ソフトウェアの構造は、マイコン・共通処理部・アプリケーションという3層で捉えると分かりやすくなります。共通処理部にあたるのは、処理の切り替えや優先度に応じたスケジューリングを行うOS、車載ネットワーク規格であるCAN（Controller Area Network）の送受信やネットワークマネージメントを担う通信、通信制御やDTC（故障コード）の読み書きを行うダイアグ、不揮発メモリの読み書きを行うメモリアクセス、各種センサやアクチュエータのドライバなどです。

各社が独自にプラットフォームを構築していた状況に対し、仕様を統一する「標準化」の動きが生まれます。その代表的なものとして登場したのがAUTOSAR（AUTomotive Open System Architecture）です。欧州自動車メーカーを中心に、車載ソフトウェアの共通化を目指して2003年に設立された団体であり、同時に、その共通化を実現するためのプラットフォーム仕様の名称でもあります。

車載ソフトウェアに求められる要求や品質には、特有の特徴があります。これらを開発中に意識しないままでいると、品質低下を引き起こすだけでなく、コスト増大・納期遅延にもつながることがあります。ここでは、代表的な4つの特徴を取り上げます。

これらは車載ソフトウェアに課される前提条件です。後述するSDV時代の新しい課題も、これらの制約を満たしたうえで解決していく必要があります。

今、車載ソフトウェアが注目される理由は、自動車の価値を決める主役がハードウェアからソフトウェアへ移った点にあります。本章では、その転換をもたらした需要面の変化、CASEとSDVという2つの概念、そこから生じた産業構造の変化を、順に見ていきます。

自動車は「単なる移動手段」から「モビリティ社会を構成する1つのデバイス」へと役割を変えつつあります。その背景にあるのは、次の2つの需要面の変化です。

• 社会的な要請：2050年のカーボンニュートラル実現に向けて、走行時のCO2排出削減と電動化への対応が求められています。また、ドライバーや整備人材の不足、地方における移動手段の維持が課題となっています。加えて、交通事故や渋滞による経済損失の低減、EC市場の拡大に対してドライバーが不足する物流の担い手不足（いわゆる2024年問題）への対応も急務です。こうした社会課題を解決する手段として、自動車には移動のあり方そのものを変える役割が期待されています。
• ユーザーニーズ：カーシェアやサブスクリプションの普及により「所有から利用へ」と価値観が移り、自動車を持たずに必要なときだけ使う選択肢が広がっています。スマートフォンに慣れたユーザーは、自分の好みに合わせて設定が最適化されるパーソナライズを当然のものと捉え、カタログ上の機能の多さよりも、乗っている間にどのような体験が得られるかを重視するようになりました。

こうした需要の変化は、業界に構造的な変革を求めます。その方向性を示す概念として登場したのが「CASE」です。

CASEは、Connected（コネクテッド）、Autonomous（自動運転）、Shared & Services（シェアリング・サービス）、Electric（電動化）の頭文字を取った言葉です。冒頭で触れた100年に1度と言われる変革期を象徴しています。CASEは自動車業界に大きな影響を与える一方で、車載ソフトウェアが価値を発揮できる領域でもあります。

C：コネクテッドでは、自動車がインターネットに常時接続されます。これにより、自動車の遠隔操作、ソフトウェアの自動更新（OTA）などが可能になり、自動車は単なる移動手段から、インターネットにつながる便利な情報端末へと進化します。自動車側では、通信回線を内蔵して外部ネットワークと双方向通信を行うTCU（Telematics Control Unit）や、車内ネットワークで異なる通信規格やシステム同士のデータを整理・分配する車載ゲートウェイなどの整備が必要です。クラウド側にも、無線で安全確実に更新するOTAや、走行データを遅延なく吸い上げるIoT・データ収集基盤などが求められます。また、外部との通信機会が増えるほど、車載サイバーセキュリティの重要性が高まります。

A：自動運転は、ドライバーの操作なしで目的地まで走行する技術です。運転支援システム（ADAS：レベル1〜2）から、条件付きでシステムがすべてを操作する自動運転（レベル3〜4）、最終的な目標である完全自動運転（レベル5）まで、段階的な実用化が進んでいます。実現を支えるのは、AIによる高度な認知処理と車載センサ（カメラ・レーダー・LiDARなど）、現在地を把握するための高精度3Dマップ（ダイナミックマップ）、ハンドル・アクセル・ブレーキを電子制御で正確に動かすアクチュエータといった技術要素です。

S：シェアリング・サービスは、自動車を所有から共有・移動サービスへと広げる動きです。車両の予約・配車・課金といった機能をソフトウェアが担い、自動車の利用そのものがサービスとして提供されます。カーシェアやライドシェア、複数の交通手段を一つのサービスとして提供するMaaS（Mobility as a Service）がその代表例です。ここでは、車両の空き状況を管理する予約システム、需要に応じて最適な車両を割り当てる配車アルゴリズム、利用時間や走行距離に応じた課金、スマートフォンで車両を解錠するデジタルキーなどをソフトウェアが担います。1台の車両を不特定多数のユーザーが利用するため、ユーザーごとの認証・権限管理や、車両状態を把握する遠隔モニタリングも必要になります。

E：電動化は、環境問題を背景に、エンジン車からHEV・BEV・FCEV（ハイブリッド車・電気自動車・燃料電池車）へ移行することを意味します。動力源が変わるにあたり、エンジン（内燃機関）の制御ソフトウェアとモーター（電動機）の制御ソフトウェアは特性が大きく異なります。また、バッテリー残量や温度を管理して電気効率を最適化するバッテリー・マネジメント・システム（BMS）により、航続距離やバッテリー寿命の最大化にもソフトウェアが貢献します。

こうしたCASEの進展を通じて、自動車は「走るデバイス」へと姿を変えていきます。市場における競争力の源泉が、ハードウェアのスペック競争からソフトウェアによる付加価値の創出へと移行しはじめました。CASEが「自動車はどうなるか」という変化の方向を示す言葉だとすれば、次に紹介するSDVは「自動車はどうあるべきか」という、CASEを実現するための構造を表現しています。

SDV（Software Defined Vehicle：ソフトウェア定義車両）では、車両の機能やユーザー体験がソフトウェアによって決まり、購入後もソフトウェア更新を通じて進化し続けます。従来の自動車は、購入した時点が機能の頂点で、その後は古くなる一方でしたが、SDVへの転換によって、自動車の在り方が変わりつつあります。ユーザーが自動車から受け取る価値も、次のように変わります。

• 機能更新：購入後もソフトウェアアップデートを通じて、運転支援機能の精度向上、不具合の修正、操作画面の改善などが行われます。
• 機能追加：あらかじめ車体に搭載されたハードウェア（カメラ、センサ、計算ユニット等）を、ソフトウェア更新によって段階的に有効化していくことで、新しい機能が後から増えていきます。
• パーソナライゼーション：ドライバーごとの運転習慣や好みをソフトウェアが学習し、シート位置、空調、運転モードなどをそれぞれのユーザーに合わせて自動的に最適化します。

• Tesla（テスラ）：早くからSDVの考え方を実装し、インフォテインメント・システムの拡張や、ADASの性能向上をネットワーク経由でもたらす体験を一般化させました。
• トヨタ（ウーブン・バイ・トヨタ）：独自のプラットフォーム「Arene（アリーン）」を開発し、SDV時代をリードするシステムの投入を推進しています。

CASE・SDVの流れを受けて、産業構造にも変化が生じています。

従来の自動車産業は、完成車を設計・製造する自動車メーカー（OEM）を頂点として、部品メーカーが段階的に連なる取引構造が一般的でした。OEMに直接部品やシステムを供給するTier1サプライヤー、Tier1に部品を供給するTier2サプライヤー、半導体メーカー、ソフトウェアベンダーなど、それぞれの企業が専門領域を担っています。

この構造は、日本の自動車産業が得意としてきた「すり合わせ型（インテグラル型）」の開発、すなわち部品同士を細かく調整し合って全体最適を実現する方式と結びついていました。しかしSDVへの移行に伴い、ソフトウェアとハードウェアを分離する「組み合わせ型（モジュラー型）」への転換が進んでいます。

電気自動車（EV／BEV）の登場も、この動きを加速させました。エンジン車は部品点数が多く、自動車メーカーを中心としたグループ内の強固な取引関係が商品性能、ひいては競争力へとつながっていました。しかしEVは部品点数が少なく、構造面でも差別化しにくいという特徴があります。そのため、調達の単位そのものが変わりました。部品をそのまま調達するのではなく、モーターや減速機、インバーターなどを組み合わせた「eアクスル」や、バッテリー・ホイールなどを組み合わせた「EVプラットフォーム」として調達できるようになり、IT企業・スタートアップ・異業種からも自動車業界への参入が可能になりました。また、Tier1サプライヤーは複数の自動車メーカーへ部品を供給するメガサプライヤー化が進んでいます。

こうした構造変化のもとで自動車メーカーは、各社の強みを生かした差別化や、サブスクリプションによる継続的な収益の確保へと軸足を移しつつあります。販売時点で完結していた取引関係も、購入後の機能追加や改善を通じて、ユーザーと自動車メーカーが継続的に関わる形へと変わります。

前章で見たように、車載ソフトウェアは技術革新の中心として注目を集めています。技術的な変化を理解する出発点として、本章では現在の車載ソフトウェアが担っている機能を、制御系と情報系に分けて整理します。

車載ソフトウェアが担う領域は、「走る・曲がる・止まる」「乗る・くつろぐ」「伝える・つながる・楽しむ」の3つに整理できます。さらに、その役割と特性から「制御系」と「情報系」の2つに大別されます。具体的な機能は次のとおりです。

制御系ソフトウェアは、車両の物理的な動きや車内空間の利便性を支える制御プログラムです。
パワートレイン・走行制御は、加速・燃費・排出ガスといった走行性能を直接左右する領域であり、ADAS・自動運転と同様、わずかな遅延も許されない「リアルタイム性」が求められます。たとえば衝突被害軽減ブレーキ（AEB：自動ブレーキとも呼ばれます）では、センサが障害物を検知してから瞬時に判断し、ミリ秒単位でブレーキ制御へ反映させる必要があります。制御の内部では、マイクロ秒単位の周期処理が求められます。また、乗員の命を守る領域であるため、ISO 26262（機能安全）などの規格への適合が求められます。

一方、ボディ制御は車内空間の利便性を支える領域で、リアルタイム性や機能安全への要求はパワートレイン・走行制御と比較すると緩やかな傾向があります。最近では、コネクテッド機能と連携したスマートフォンからの車両操作や、車内を一つの空間として捉えた制御モードの実装が進んでいます。

情報系ソフトウェアは、モビリティ体験をより豊かで快適なものへと進化させる役割を担います。インフォテインメント（IVI）・コックピットとコネクテッド・通信がこの領域にあたり、交通情報をリアルタイムで届けるナビゲーションシステム、スマートフォンとの連携、音声認識による操作、OTAによる購入後の機能アップデートなどを実現します。

情報系ソフトウェアでは、文字・音声・動画・画像などの多様なデータを取り扱います。そのため、複数のアプリケーションを同時に動かせる処理能力が求められ、LinuxをベースとしたOSやクラウドを活用したアプリケーション開発が拡大しています。また、スマートフォンやクラウドサービスと同じく、購入後もユーザー体験（UX）を継続的に向上させられるよう、開発手法も頻繁にソフトウェアをアップデートする方式へと変わりつつあります。電気自動車（EV／BEV）やコネクテッドカーが普及するにつれ、エンドユーザーが直接触れるUXは、自動車メーカーの競争力を左右する重要な要素になってきています。

CASEの進展とSDVへの移行は、車載ソフトウェア開発に新しい課題を突きつけています。本章では、従来の車両アーキテクチャが抱える構造的な限界と、それに対応するための技術の方向性を解説します。

従来の自動車は、機能が増えるたびに専用のECUを追加する「分散型アーキテクチャ」で発展してきました。この構造は、電子制御の高度化が進むなかで、次の3つの限界に直面しています。

1. 電子制御の複雑化への対応の難しさ：自動車の電動化（EV）や自動運転（ADAS）の進化に伴い、車内の電子制御がかつてないほど複雑化し、ECUごとの個別最適では車両全体の整合を取りにくくなっています。
2. ECU数と配線の増加：機能ごとにECUを追加してきた結果、車両には多数のECUが搭載され、特に高級車では100個を超えるといわれます。これらのECUは単独で動くのではなく、通信線で互いに接続され、データをやり取りしながら協調して車両を制御しています。そのためECUが増えるほど、電源線と通信線を合わせた配線（ハーネス）も増加します。ハーネスの肥大化は車両重量の増大につながり、ハードウェアの軽量化とコスト削減の妨げとなります。
3. OTAのしづらさ：機能ごとのECUが互いに密接に連携しているため、一部のソフトウェアを更新した際に他のECUへどのような影響が及ぶかを見極めにくく、更新のたびに膨大な検証が必要になります。SDVの前提となる頻繁な更新が困難なのです。

つまり、従来の「分散型アーキテクチャ」そのものが、SDVの実現を阻む壁になっています。こうした課題への解決策が、車両アーキテクチャの見直しです。

解決策として進められているのが、分散したECUを少数の高性能なユニットに集約する「ECU統合」です。まず検討されたのが、ドメインアーキテクチャです。個々のECUを直接ネットワークに接続する形態から、各ドメイン（パワートレイン系、運転支援系といった役割ごとのグループ）に置いたドメインコントロールユニット（DCU）がECU群を制御する形態への移行です。

さらに現在検討されているのが、ゾーンアーキテクチャです。ビークルコンピューティングと呼ばれる中央演算ユニット（VCU）が、車両前方・後方といった物理的な位置ごとのグループ（ゾーン）を集中的に管理する構成です。この検討の背景には、2つの要因があります。1つは、センサから取得するデータ量が膨大になり、高速性に加えて低遅延も求められるネットワークが必要になったことです。もう1つは、開発の効率化と品質向上に向けてAUTOSARへの対応、信頼性向上、セキュリティ対策といった要求にも応えられる構造が求められていることです。

これにより、センサからのデータを一元的に収集・処理できる基盤が整い、OTAによる高度なソフトウェアアップデートが可能になります。ただし、ドメインアーキテクチャとゾーンアーキテクチャのどちらが主流となるかは、各社が研究・検討を進めている段階です。いずれの構成であっても、ECU統合という方向性は共通しています。

統合型アーキテクチャへの移行を推進している企業としては、車載プラットフォームの統合を牽引するデンソーやAstemoなどが挙げられます。

アーキテクチャが変わることで、開発にも変化が求められます。SDVでは購入後も機能を追加・更新し続けるため、開発の高度化・効率化・高速化が必要になります。中核技術（ADAS、自動運転、コネクテッド、IVI）を実現するうえで重要となるのは、次の技術・開発手法・開発環境です。これらはさらに、サードパーティーが利用できる仕組みへと広がっていきます。

• 技術：クラウドと車載エッジ環境の一貫した開発環境を実現するクラウドネイティブ、車載ソフトウェアを最新の状態に保つOTA・セキュリティ、APIのオープン化と開発環境の整備が進むビークルOS（車両全体のソフトウェアを統括し、アプリケーションから車両機能を扱えるようにする基盤ソフトウェア）、自動運転だけでなく開発の効率化・高度化にも用いられるAI・ROS（Robot Operating System）。
• 開発手法：複雑さを増すシステムを構造的に整理し、要求や設計のトレース性を高めるシステムズエンジニアリング、不確実性に強く短サイクルで迅速にリリースするアジャイル、機能安全（ISO 26262）・SOTIF（ISO 21448）・サイバーセキュリティ（ISO/SAE 21434）への準拠による安全性証明。
• 開発環境：クラウド上で膨大なシミュレーションテストを実行し迅速にリリースするCI/CD・DevOps、実機に依らず検証を行うシミュレーション、高精度地図データを活用するマップ。

アーキテクチャの進化と並行して進んでいるのが、ソフトウェアの仕様を統一する「標準化」です。SDVの実現には、業界全体で足並みをそろえる領域が欠かせません。第1章で触れたAUTOSARの登場以降、標準化の対象はプラットフォームから、その上位にあたるAPI、さらに開発環境へと広がっています。本章ではこの3つの動きを順に見ていきます。

頻繁なソフトウェア更新に対応し、異なる車種、サプライヤーやOEM間での相互運用を可能にするため、プラットフォームの標準化が進んでいます。共通の制御はOEM間で非競争領域（協調領域）として標準化を進め、各社は競争領域であるアプリケーションに注力する、という考え方です。

プラットフォームは、対象とするECUの性質によって系統が分かれます。制御系ECU向けは高信頼性・リアルタイム性が重視され、現在はAUTOSAR Classic Platformが業界標準となっています。一方、情報系ECU向けは高機能・高い開発効率が重視されます。かつてはLinuxをベースとした複数の団体の取り組みが並行し、現在は車載向けLinuxであるAGL（Automotive Grade Linux）などがあります。

そして自動運転やコネクテッドカーの実現に向けては、制御系処理と大規模情報処理の両方への対応が必要になります。
そのために、ハードウェアとして複数マイコンやマルチコア搭載の高性能SoCを採用し、AUTOSAR CPとLinux系の両方を搭載することで、両方への対応を実現するようになってきました。
このような動きに対応し、Linux系の大規模情報処理プラットフォームとして、AUTOSAR Adaptive Platform（AP）が策定され、昨今では、1つのSoC上でAUTOSAR CPとAUTOSAR APが動く構成が主流となってきています。

ビークルAPIでは、車そのもののAPIを標準化します。これによって、サプライヤがOEM各社用に個別に製品を開発しなくてよいようになります。さらに、車両構造に精通していない開発者でもアプリケーションを開発できるようになるため、サードパーティ製アプリも作りやすくなります。

この領域では、COVESA、JASPAR、Open SDV Initiativeといった団体が標準化に向けて活動しています。SDVの実現に向け、業界横断での取り組みが加速しています。

SOAFEE（Scalable Open Architecture for Embedded Edge）という自動車業界の企業が主導するプロジェクトにおいて、車載ソフトウェア開発におけるクラウドネイティブ開発のための共通アーキテクチャの整備が進んでいます。Arm社が創設したプロジェクトで、クラウドネイティブ開発のメリットを生かして、機能安全やリアルタイム制御といった自動車特有の課題や制約に対応することを目指しています。

SOAFEEは、車両に搭載する組み込みソフトウェアを、クラウド上のソフトウェアと同じ手法で開発・テスト・運用できるようにする仕組みです。実機がなくてもクラウド上の仮想環境で開発・検証を進められる点が特徴です。これにより、IT業界で培われた開発ノウハウを車載ソフトウェアにも持ち込めるようになり、開発の効率と品質の向上が見込まれています。ただし、開発の速度を上げるほど、品質と安全をどのように保証するかという問いも重くなります。次章では、車載ソフトウェアのプロセスと品質保証を取り上げます。

自動車は「大切な命を乗せて走るもの」です。スマートフォンであれば、アプリの不具合は再起動や修正版の配信で済みます。しかし、自動車の不具合は人の命に直結します。購入後もソフトウェアが更新され続けるSDVだからこそ、品質と安全をどのように保証するかが一層重要になっています。

自動車が危険な状態に陥る原因は、3つに分けられます。①故障によって壊れること、②故障していなくても、性能の限界やユーザーの誤使用によって意図しない挙動となること、③外部から攻撃を受けることです。この3つの原因にそれぞれ対応する国際的な枠組みが、①機能安全（ISO 26262）、②SOTIF（ISO 21448）、③サイバーセキュリティ（ISO/SAE 21434）です。本章では、この3つを順に解説します。

機能安全は、「故障を完全になくすことはできない」という現実を前提に置く考え方です。万が一の故障が発生した場合にも安全目標を侵さないよう、システムによっては安全に停止させたり、機能を制限して運転を継続させたりする設計思想を指します。

自動車業界では、Automotive SPICE®（A-SPICE：開発プロセスの能力を評価する業界標準）に準拠したうえで、ISO 26262に対応するのが主流になっています。A-SPICEへの準拠を前提にすることで、要求定義・設計・テストといった開発工程にとどまらず、生産・運用・保守を含む製品ライフサイクル全体を通じた、厳格な管理プロセスを適用できます。この「A-SPICE＋国際規格への準拠」という組み合わせは、次に述べるSOTIFとサイバーセキュリティにも共通します。

SOTIFは「Safety Of The Intended Functionality（意図された機能の安全性）」の略で、ISO 21448として規格化されています。機能安全（ISO 26262）が「故障が起きたとき、どう守るか」を扱うのに対し、SOTIFは「故障ではないが、性能の限界やユーザーの誤使用によって意図しない挙動となる事故」をどう防ぐかを扱います。

従来の機械部品は、壊れない限り設計どおりに動きました。一方、センサやAIは、正常に動作していても、周囲の状況によって誤った判断をすることがあります。たとえば、カメラセンサが逆光で歩行者を認識できない、AIが想定外の道路状況を誤判断する、運転者が想定外の使い方をしてしまう、といったケースが対象です。機能安全とSOTIFは互いに補い合う関係にあり、両者を統合した安全設計が国際的な標準として広がりつつあります。

自動車は長期間にわたって使われることを前提に、その間の安全性の維持とサイバーセキュリティへの対応が求められます。コネクテッド化によって車両が外部とつながったことは、利便性の向上と同時に、外部から攻撃を受ける入口が生まれたことも意味します。故障や性能の限界が偶発的に生じるのに対し、攻撃は意図をもって仕掛けられます。だからこそ、守り方にも異なる発想が求められます。

各国では車両のサイバーセキュリティに関する法規制の整備（UN-R155など）が進んでおり、その対応は販売の前提条件になりつつあります。

車載ソフトウェアに関わる国際規格についてまとめます。

機能安全・SOTIF・サイバーセキュリティの詳細については、こちら車載ソフトウェアの品質保証で詳しく解説しています。

SDVへの移行は、必要とされる人材にも変化をもたらしています。自動車業界では長年、ハードウェアの設計・製造技術が競争力の中心であり、人材もハードウェア領域に重点的に配置されてきました。しかしSDVへの移行によってソフトウェアが車両の価値を左右するようになり、ソフトウェア人材の需要が拡大しています。

統合と標準化が進むにつれて、「車両のすべてを理解していなくても、アプリケーションを開発できる」状態となります。前章で述べたビークルAPIの標準化は、その前提を整える取り組みにあたります。このように今後の車載ソフトウェア開発ではプラットフォームとアプリケーションの分離が進むことでハードウェアの違いをプラットフォームが吸収するため、アプリケーション開発者はハードウェアの違いを意識することなくアプリケーション開発に集中できるようになります。

一方で、この分離を成り立たせる側、つまり統合ECUやプラットフォームといった基盤そのものを作る開発には、車両制御と先進的なIT技術を両立できる人材が欠かせません。車両アーキテクチャの進化は、アプリケーション開発の裾野を広げると同時に、基盤を支える高度技術者への需要を高めています。こうしたスキルを持つ技術者は、自動車業界だけでなくIT業界をはじめとする幅広い業界で求められており、業界を横断した獲得競争が起きています。人材不足は、一社の努力では解消が難しい、業界の構造的な課題となっています。そのため業界全体では、関係省庁や業界団体によるSDV人材の育成方針の策定、標準化団体を中心として認定制度「SDVスキル標準」を活用した人材獲得・育成や、学生や海外人材の獲得、リスキリングの促進といった取り組みが進められています。

車載ソフトウェアは、自動車の価値そのものを定義する役割へと変わりました。SDV化の潮流のなかで問われるのは個々の技術ではなく、制御系から情報系、クラウドまでを一貫して設計・検証できる開発体制です。本章では、業界に求められる今後の取り組みを整理します。

今後は、安全性・信頼性を確保しながら、新しい技術やサービスを取り入れていくことが、業界全体に求められています。そのためには、技術力の底上げと、人材・体制の強化が欠かせません。富士ソフトも、この変革を支える一員として、車載ソフトウェアの未来創造に取り組んでいきます。

SDVへの移行やコネクテッド技術の進化により、現在の自動車業界は、これまでの組み込みシステム（OT）の枠を超え、クラウド（IT）やサイバーセキュリティ、AIといった広範な技術領域を統合し、一気通貫で開発することが求められる局面を迎えています。富士ソフトは、こうした広範な技術領域にまたがる開発支援を担っています。

車載ソフトウェア（OT）×クラウド（IT）×AIを融合させた技術により、お客様のニーズに対してシステム一気通貫でのご提案をいたします。

当社は、「モビリティ社会の実現と普及に貢献」することをビジョンに掲げています。

当社は30年以上前から車載ソフトウェアベンダーとして、自動車業界における成長分野・先端技術分野の開発に貢献してきました。

全国6拠点・2,500名を超える技術者集団で、自社のみならず、お客様、アライアンスパートナー、業界団体との協業・共創による受託開発および自他社プロダクト事業を展開し、国内主要OEM・Tier1サプライヤーのお客様を筆頭に、国内100社以上のお客様とお取引をいただいています。

• 提案力：車載システム（OT）×クラウド（IT）×AIを融合させた技術により、システム一気通貫でのご提案をいたします。
• 案件対応力：先進技術の早期習得、確かで高度な技術力、幅広い技術範囲により、お客様の多様な案件にご対応いたします。
• 組織力：自動車開発の知見を有する2,500名を超える技術者集団としての対応体制と品質保証能力により、お客様のご要望にお応えしてまいります。

先行開発から量産向け開発、組み込みソフトウェア領域（下位レイヤーのドライバ、OS、アプリケーション）から、クラウドに至るまで、あらゆる領域において一気通貫でご対応します。

次世代車載ソフトウェア開発を支える当社の先端技術・開発プロセスへの取り組みを進めています。

富士ソフトは、こうした技術と体制による価値提供を通じて、お客様と共に安心・安全で心躍る未来を創り上げていきます。

※記載されている会社名および商品名は、各社の商標または登録商標です。