以前、AUTOSARは組み込みソフトウェアの領域にとどまっていましたが、現在では、自動車メーカー（OEM）や一次サプライヤー、ソフトウェア開発のサービス提供者にとって、ソフトウェア定義車両（SDV）への移行を支える戦略的な柱となっています。AUTOSARは、標準化とスケーラビリティを両立するため、最新の自動車ソフトウェアアーキテクチャの中核として機能しています。
しかし、AUTOSARの導入はあくまで第一歩に過ぎません。効果的に活用するためには、適切なアーキテクチャ設計を検討し、製品ラインとプラットフォームを各地域で統一することが重要です。また、納期の遅延や技術的負債の増加を招く落とし穴を回避する必要があります。本記事では、AUTOSARがどのように実装されているのかを解説し、次世代の自動車ソフトウェア戦略を立案する際に考慮すべきポイントを明らかにします。ぜひご一読ください。
AUTOSARとは
AUTOSAR（Automotive Open System Architecture）は、2003年に誕生しました。この開発プロジェクトは電子制御ユニット（ECU）開発の困難を解消するという明確な目的のもと、自動車業界の大手企業（BMW、Bosch、Daimler、Continental、Siemens VDO、Volkswagen）によって設立されました。アイデアは、AUTOSARを標準として、スケーラブルで再利用可能、かつ現代の複雑な自動車に対応できるECUを実現することです。
コンポーネントベースのアーキテクチャ
AUTOSARはモノリシックアーキテクチャを構築するのではなく、コンポーネントベースのアーキテクチャを導入します。各ソフトウェアコンポーネント（SWC）は、明確なインターフェースを持って開発され、様々な車種やプラットフォーム、サプライヤー、世代を超えて再利用することができます。このモジュール設計により、以下のようなメリットが得られます。
・開発期間の短縮
・保守性の向上
・各国の開発チームでの並列開発の実現
Classic platformとAdaptive platform
広く使用されているAUTOSARプラットフォームには、2つの種類があります。
・Classic Platform（CP）：リソース制約のあるECU（パワートレイン、シャシ、ボディ）で実行され、リアルタイム処理が求められる機能に最適化されています。予測可能な動作が特徴で、堅牢かつ成熟しており、量産車への実装実績も豊富です。
・Adaptive Platform（AP）：ADAS（先進運転支援システム）、計算負荷の高いECU（インフォテインメント、セントラルコンピューティングなど）向けに設計されています。POSIX準拠OS、動的メモリ管理、サービス指向通信（SOME/IPなど）に対応しており、OTA（データ無線通信技術）とSDVに最適です。
AUTOSARが重要になっている理由
SDVには、なぜAUTOSARが必要になったのか？
SDVとは、単にソフトウェアを多く搭載した車ではなく、従来とはまったく異なる製品概念を持つ次世代の車です。AUTOSARの導入に伴う最も目立った変化は、ソフトウェアの開発・導入、そして機能・サプライヤー・ライフサイクルでの進化にあります。
現代の車両には、ブレーキ、ステアリング、インフォテインメント、運転支援まで、100以上のECUが搭載されており、かつてないほど複雑化しています。このような複雑さを構造化せずに維持することは現実的ではありません。その課題を解決するため、AUTOSARは、スケーラブルで長期運用可能なモジュール化された車載ソフトウェアアーキテクチャを提供します。
実際のメリット：
・AUTOSARのコンポーネントを再利用できるため、プラットフォームやサプライヤーごとにソースコードを再構築する必要がない。
・AUTOSARは自動車のミドルウェアとして機能するため、ソフトウェアとハードウェアが分離され、チップセット間の移行やソフトウェアのアップグレードが容易になる。
・安全性・性能・保守性を支える標準インターフェースと診断機能が備わり、システム間の通信を一から設計し直す必要がない。
安全で接続性が高く、常にアップデート可能な車両の提供を求められるプレッシャーが高まる中、分断されたレガシーシステム上でこれらを実現するのが困難になっています。こうした背景から、AUTOSARの採用は単なる流行ではなく、現実の課題を解決できるソリューションとして、将来の車両プラットフォーム構築に取り組むOEMが増えています。
2025年におけるAUTOSARの動向
AUTOSARへの移行はすでに急速に進んでいます。2025年までに、世界中のOEMの半数以上が研究開発の試験的なプロジェクトだけではなく、実際の製品開発においてもAUTOSAR準拠のアーキテクチャを採用することが予測されています。インフォテインメント、ADAS、パワートレイン、ゾーンアーキテクチャなど、全領域での統合が進んでいます。
以下の指標からその戦略的な重要性が明らかになっています。
・AUTOSARミドルウェア市場は、2023年に16.3億ドルに達し、2030年までに約11.1％の年平均成長率（CAGR）で34億米ドルに達すると予測されています。
同期間中、Adaptive PlatformはClassic Platformよりも早く成長し、OEMがセントラルコンピューティング、安全分離対策、OTAを優先する中で、ミドルウェア市場における収益を拡大すると見込まれています。
この成長は世界各地域で均等に見られます。
・ヨーロッパは市場の40％以上を占めており、規制の統一とプラットフォーム標準化により市場をリードしています。
・日本と韓国など、アジア太平洋地域は、EV（電気自動車）、ADAS、ゾーンアーキテクチャの量産により、最も急速に成長しています。
一方、一次サプライヤーは、AUTOSARに合わせてツールと製品戦略を再構築しています。ツールチェーンの互換性、統合支援、ミドルウェアのバージョン管理は、もはやエンジニアリングの問題にとどまらず、経営層が検討すべき課題となっています。
OEMにおけるAUTOSARの活用方法
最新の乗用電気自動車（EV）：CPが主流を維持しつつも、APが急速に成長
パワートレイン・ボディ系統など、時間制約とハードウェア密結合が求められる領域では、CPが依然として強みを発揮しています。AUTOSARツールチェーンの完成度と信頼性の高いRTE自動生成機能が、量産プロセスでの安定稼働を支えています。
一方で、APは今やプロジェクトの中核となりつつあり、ゾーンコンピューティング、インフォテインメント、OTA、ADASなど、多くの領域で活用されています。VolkswagenやStellantisといった大手メーカーでは、サービス指向のAUTOSARアーキテクチャにより、ゾーンECUクラスタへのAP導入を実現しています。AUTOSAR Builderのような自動設定ツールは、サプライヤーからのインプットをもとに、XML記述、RTE生成、BSW階層構成の管理を支援し、一貫性とセキュリティ準拠を確保します。
このような戦略的ワークフローは、初期のPSAパイロットプロジェクトと同様に以下の取り組みを実現します。
・サプライヤーは、標準化されたファイル（.arxml）に基づいてソフトウェアコンポーネント（SWC）を提供します。
・OEMは、既存の信号定義や車両マトリクス形式をインポートし、それらをVFB（仮想機能バス）互換モデルへ変換します。
・ツールは、SCVTのようなモジュールを通じてXMLメタデータと生成されたCコードの整合性とトレーサビリティを検証し、RTE契約コードの最終化前に一貫性を担保します。
プレミアム商用車：運用管理を支えるハイブリッドAUTOSAR
商用車への本格展開には、車両バリエーションの多様化、Uベースモデルへの対応、V2X技術の進化、フリート管理ダッシュボードなど、多くの複雑な要素を統合する必要があります。Volvo TrucksのようなOEMは、これに対して以下のようにハイブリッドアーキテクチャを導入しています。
・CP：時間制約のある制御ロジック
・AP：高度な診断、OTAアップデート、テレマティクスによる分析
ワークフローは、既存のユースケースをもとに、エコシステム内のサプライヤー間で緊密な協力体制を構築できるよう設計されています。AUTOSARツールチェーンを活用することで、以下を実現します。
・複数ベンダーによるSWC検証
・既存のECU定義からのトポロジー・通信マトリクス取り込み
・レガシーデータをもとにBSWモジュールやCOMスタックを自動で構成するスクリプトによる自動化
こうした機能により、フリート全体の稼働率を維持しつつ、異なる車両間でソフトウェア構成を柔軟にスケーリングすることができ、重複する機能ロジックや手作業による負担を大幅に削減します。
自動運転プラットフォーム：AP中心の統合アーキテクチャ
レベル4以上の自動運転車両（L4+）、自動運転シャトル、ロボタクシーなどの開発では、AP型のAUTOSARがランタイムの中核となっています。そのアーキテクチャの選定理由は以下の通りです。
・POSIX OS対応、動的メモリ割り当て、サービス指向通信（例：SOME/IPなど）
・自動運転計算スタックにおける診断・安全分離
・AI/ML処理やモジュール型センサーフュージョンに対応する再構成可能なミドルウェアアーキテクチャ
MobileyeやNAVYAといった企業は、センサーマネジメント、認識サービス、OTA制御を個別のSWCに配置した、完全なAPファーストスタックを実装しています。これらはAUTOSARオーサリングツールを使って検証され、VFBからRTEへの抽象化を管理しつつ、各コンポーネントが規格に準拠し、安全の要件を満たしていることを保証します。
VTIの事例紹介：日本の大手自動車メーカー向けのSAP S/4HANAクラウド移行
AUTOSARのグローバル展開状況
地域によって、AUTOSAR導入の状況や優先事項は大きく異なります。こうした多様なアプローチは、各地域の特性に応じたAUTOSAR戦略展開の好例と言えるでしょう。
ヨーロッパ
ヨーロッパは依然として、世界中で最もAP採用が活発な地域となっています。規制の準拠、セントラルコンピューティングの採用、そして確立された一次サプライヤー基盤が、この動きを後押ししています。Volkswagen、Stellantis、BMWなどの自動車メーカーは、ゾーン型・集中型アーキテクチャにAPを組み込み、ADAS、インフォテインメント、ソフトウェア・オーバー・ジ・エア（SOTA）の高性能アプリケーションを実現しています。
2024年、ヨーロッパのサプライヤーとOEMは、世界のAUTOSARミドルウェア収益の30～35％を占めており、アジア太平洋地域に次ぐ第2位にあります。この成果は、UNECE規制準拠の厳格なスケジュール管理、サプライヤーとの密な連携、イノベーションラボ・本番環境双方への包括的なAP導入により実現されました。
日本
日本におけるAUTOSAR、特にAPの展開は、依然として慎重に進められています。現在も多くの量産モデルでは、ボディ、パワートレイン、シャシーを中心に、CPがECU設計の主流となっています。ただし、ソフトウェアトランスフォーメーションの兆候が見え始めています。
カウンターポイントリサーチ社によると、2025年第1四半期における日本のコネクテッドカーの販売は前年比34%増加し、トヨタはそのT-Connectプラットフォームによって43%のシェアを獲得しました。この成長は、ソフトウェア中心のイノベーションへの明確なシフトを示しており、AP（Adaptive Platform）の導入は主にパイロット段階や高級モデルに限られているものの、確実に進展を見せています。
韓国
ヒュンダイや起亜（Kia）などの韓国のOEM企業は、実用的なアプローチを取っています。まずはCP（Classic Platform）を使ってコントロール機能を提供し、次にAPをインフォテインメント、コネクティビティ、テレマティクスに適用する戦略です。その結果、スケールアップが可能であり、進化に柔軟なハイブリッドアーキテクチャ戦略が急速に進化しています。
AUTOSARベースのプラットフォームは、韓国の急成長中の複数のモデルに採用されています。特に、電動SUVや次世代商用車両の新たなプラットフォームに活用されています。韓国のEV目標とソフトウェア定義のビジョンは、中級のAPの拡張にとって魅力的なテストケースとなっています。
アメリカ
米国では、AUTOSARの採用状況はバラバラで、統一された戦略が見られません。GMやフォードなどの大手OEMは、コア生産車両には主にCPを使用している一方で、EV部門や先進技術チームはAPの可能性を探求しています。APは、コネクテッドサービス、集中型コンピューティング、OTAワークフローのための試みが進められています。
一方で、テスラやリビアンなどの非伝統的なプレイヤーは、AUTOSARを避け、カスタムスタックを採用し続けています。それでも、APはTier-1（一次サプライヤー）のR&D部門やスタートアップ企業、AI駆動の安全システムにおいて確実に存在感を高めています。特にISO 26262やツールチェーンの再利用が重要な分野において、APは着実に支持を集めています。
2025年、OEM企業が見過ごせないAUTOSARの課題とリスク
強力なアーキテクチャを持っていても、適切に実行されなければ失敗に終わることがあります。以下はAUTOSAR戦略が行き詰まる主な要因です。回避できるものばかりですが、放置すれば大きな損失につながります。
不適切なプラットフォーム選定
Classic AUTOSARは、安全性ならびにリアルタイム性が極めて重要な分野において依然として最適な選択肢です。しかし、動的なアップデートやスケーラブルなコンピューティングが求められる分野には限界があります。一方、Adaptive AUTOSAR はそうした要件に対応可能ですが、パフォーマンスオーバーヘッドやハードウェア依存といった課題を抱えています。つまり、用途に合わないプラットフォームを選ぶと、システムの複雑化を招き、解決すべき課題が増加する結果となります。プラットフォームはそれぞれのドメインに最適なものを妥協せずに選択することが重要です。
統合を一度きりのプロジェクトとして扱う
多くのチームがAUTOSARの導入が単発で終わると考えがちですが、実際はそうではありません。ソフトウェアは常に進化し、バージョンも変わり続け、サプライヤーも固定されているとは限りません。統合を一度きりのマイルストーンとして扱い、継続的なプロセスとして管理しないと、ズレや手戻り、遅延が発生します。コンプライアンスは、チェックリストの項目として処理するのではなく、納品サイクルに組み込まれた継続的な取り組みとして定着させるべきです。
ツールチェーンのバラつき
統一されたツールチェーンがないまま開発を進めると、CPとAPの実装に早い段階から見えないズレが生じ始めます。 このズレは当初は顕在化しませんが、やがてXMLの処理の不整合やRTE層のミスマッチ、設定フォーマットの非互換性といった形で、プロジェクトの終わりが近づき、スケジュールが逼迫しているタイミングで一気に表面化するのです。そのため、社内チームやサプライヤーネットワーク全体でツールチェーンを標準化することで、スムーズな引き継ぎとトレーサビリティが確保されます。
SWC（ソフトウェアコンポーネント）の検証不足
サプライヤーが提供するSWCは、システム要件に完全に合致しないことが多く、インターフェースの不一致、未定義の実行可能コード、または規格に準拠しない実装が見受けられます。「プラグアンドプレイ」の前提で進めることは非常にリスクが高いため、XMLレベルでの静的検証およびCコード生成時の検証プロセスを早期に確立することが重要です。
ミドルウェアのバージョン管理の怠り
CPおよびAPのツールチェーンは急速に進化します。ミドルウェアのバージョンを追跡しないと、ランタイムの挙動が予期しない形で変化し、コンプライアンスにギャップが生じます。バージョンの不一致は開発段階ではなく統合時に表面化することが多く、その時点での修正は非常に困難です。そのため、サプライチェーン全体で計画的にバージョン管理を行うことが不可欠です
安全性とセキュリティのトレーサビリティを軽視するリスク
AUTOSARはISO 26262や自動車サイバーセキュリティ基準に対応していますが、そのサポートは自動的に機能するわけではありません。要求から実行可能コード、テストに至るまで一貫した厳密なトレーサビリティを確保しないと、認証が脆弱になります。トレーサビリティはプロセスの一部として組み込み、後から追加するものではありません。
まとめ
AUTOSARのような技術標準が業界の主流となりつつある一方で、それを現場で正しく、効果的に適用・展開するための実行力はまだ追いついていないのが現実です。アーキテクチャを正しく設計することはもはや前提条件にすぎず、真の課題は、それを実際に複数の車種・サプライヤー・地域にまたがって、いかにスケーラブルに展開できるかにあります。
VTIは、AUTOSAR導入の現実的な課題に対して、確かな実行力でOEMやTier-1企業を支えています。
ミドルウェア統合からAP/CPプラットフォームの標準化に至るまで、当社の車載ソフトウェア開発チームは、AUTOSARに精通した専門知識と量産レベルのエンジニアリング力をもって、複雑な開発課題に対応します。新たなSDV（Software Defined Vehicle）構想の立ち上げであれ、レガシー資産の近代化であれ、VTIは「パフォーマンス」「スケーラビリティ」「コンプライアンス」を設計段階から組み込みます。
品質を妥協せず、スピード感を持って進めたいとお考えなら、ぜひ一度ご相談ください。私たちは問題の重大さを深く認識した上で、真摯に取り組み、ご期待に応える結果をお届けします。
