SDVに向け改めてAUTOSARを「ひとごと」ではなく「自分事」にすべし：AUTOSARを使いこなす（38）（2/3 ページ）

[櫻井剛，MONOist]

イベント報告：「AUTOSAR & JASPAR Japan Day」

　2025年7月14日に、JASPARとAUTOSAR日本事務局の共催イベント「AUTOSAR & JASPAR Japan Day（mini AOC in Japan）」を開催しました。

　台風の影響がある中にもかかわらず、東京品川オンサイトだけでも約30人、名古屋オンサイトで約20人、オンラインでピーク時参加者約180人（一部のみの参加者含めますとオンラインで延べ220人以上）にご参加いただきました。誠にありがとうございます。

　ご講演くださいました、COVESAの宗像様、ASAMの庄井様、SOAFEEの石川様、ならびに再演をご許可くださいましたEclipse Foundation Eclipse SDVのAnsgar Lindwedel様、EUのFederate様、そして、共催で多大なるご協力をくださいましたJASPARの皆さまに感謝申し上げます。

　また、『皆さまの「自分事」としての標準化活動』と題した筆者の講演では、AUTOSARでの標準化活動への国内からの参加状況と、標準化／オープンソースコミュニティー活動への参加の障壁、そしてそれらに関する提言を行いました。

　約360社が参加するAUTOSARには、2023年の市場総売り上げトップ20の自動車メーカー（総売り上げの約80％を占めます）のうち18社が参加しています。トップ20社では日本勢が売り上げの約23％を占めていること、その一方で現状では標準化活動への日本からの参加者数が極めて少ないこと、参加の障壁として考えられる6＋α個の要因をご紹介いたしました。

　その後、オンサイト参加の方には、突然ではありましたがワイガヤ形式で、現状のままで良いのか、どうしたらよいかなどについて議論いただきました。東京品川会場ではだいぶ盛り上がりまして、イベント後のアンケートでもかなりのフィードバックを頂戴できました。特に、本連載の第21回でもご紹介した「安全保障」の側面について、考えてみたこともなかったなどのご感想をお寄せいただいた方も少なくありません。

　SDVのために欠かせない要因として、20世紀から言われてきた「再利用」や「自動化」^※1）、その加速手段として最近特に注目が寄せられる「仮想化」に加えて、標準化やオープンソースなどのコミュニティー活動（何か新しいことを提案するだけではなく、動向を積極的かつ継続的に把握するという意味も含めて）、つまり「協働」の重要性について^※1）、改めてご認識、ご理解いただくことができたとしたら幸いです。

※1）当然のことですが、自動化には、プロセス構築と情報を機械的に処理可能なデータに変換することが必要です。AUTOSARは、実はこういったことを広く標準化で扱っていますし、そのもともとの狙いにも「自動化」は含まれています。

※2）率直に申し上げますと、自動車業界では、コミュニティーベースの活動に対する価値が、ソフトウェアに対する価値と同様に、見直されるまでにはまだ長い時間がかかるように感じました。ただ、業界内の捉え方は決して一様ではありません。若い世代の方々や、IT系から自動車分野に移った方々の中には、協働の価値や、タダ乗り行為へのペナルティーについてのご理解を十分に（筆者以上に）お持ちの方々もいらっしゃいます。

　理解しているからといってすぐに集団内の理解を書き換えるための行動に出る人ばかりではありませんので、理解と実践の間に時間差を持ちながらの「二極化」「併存」「混在」のような状態が続くのでしょうが、「一方が他方を食い物にする」ようなことは、双方ともに理論的には可能である（仕返し、しっぺ返しを食らわせることもできる）ということについては、リスクマネジメントの観点からも忘れてはならないでしょう（より分断が進むリスクもありますから、起きてほしくはありませんが）。変化に時間がかかるということは、相手側にとっては準備期間と回収期間の両方を確保できるということでもあります。

「初期導入だけは済ませたからキャッチアップできている」はだいぶ古い

　ここ最近のことです。「初期導入だけは済ませたから、キャッチアップできている。それで十分だ」という、だいぶ古い考え方が、SDVの重要性が叫ばれる今でも強く国内に残っていることを、各種展示会の展示ブースや先ほど紹介したAUTOSAR & JASPAR Japan Dayに来場された方々とお話しする中で改めて強く感じました。

　2005年ごろでしょうか、国内で発言力のある方々から、このような、不適切で、誤解を招く説明が繰り返されていたのを覚えています。しかし、AUTOSARは、基本機能のモジュール群にとどまるというものでは決してありません。

　一口に「AUTOSARの導入／利用」と言っても、それが意味することはさまざまです。

　開発プロジェクトの要求として、特定のBSW（Basic Software）や通信プロトコル、データ交換形式の利用が求められたから導入した、ということは少なくないと思います。

　導入の要因としては以下の3つが挙げられるでしょう。

• 構造面の相互接続性の確保
• 通信プロトコル面での相互接続性の確保
• Methodology面での相互接続性の確保

　しかし、これらの初期導入だけですと、もし既に同様の手段、ツールや部品などをお持ちなのであれば、実はそれは、「実現されること／かなえられることを変えずに、コストをかけて実現手段だけを差し替えただけ」で終わってしまうのかもしれません。単にAUTOSARを初期導入したというだけ、初期導入の手間と投資をしただけでは、それに見合う効果は生み出せていません。上乗せだけです。