法務:「改正道路運送車両法 – 特定改造等許可制度の新設」

法務:「改正道路運送車両法 – 特定改造等許可制度の新設」

Newsletter (2020年10月) │ 法務

はじめに

今回は、「改正道路運送車両法 – 特定改造等許可制度の新設」についての法務ニュースレターをお送りします。いわゆるレベル3[1]の自動運転の実用化に対応する一連の法改正の一環として、通信を用いた車載ソフトウェアのアップデートに関する特定改造等許可制度が、道路運送車両法(以下「法」といいます。)において導入されます。いわゆるOTA(Over The Air)と呼ばれる無線通信によるアップデートが今後積極的に活用されることが想定され、同制度の導入が関連する企業の事業に与える影響は少なくありません。改正法の施行日(Q14)まで約1か月となりましたため、このニュースレターでは、関係省令、告示、審査事務規程等の内容も踏まえて、同制度についてQ&Aの形式でお届けいたします。

 

 

Q1 今回の制度新設の狙いとするところは何ですか。

昨今の自動車技術の進展に伴い、自動車の製造販売後であっても、その使用過程時に、通信(無線のみならず、有線も含みます。以下同じ)を活用して自動車の電子制御装置に組み込まれたソフトウェアをアップデートすることにより、性能変更や機能追加を大規模かつ容易に行うことが可能となっています。このことを踏まえ、自動車の使用過程における適切なソフトウェアアップデート及びサイバーセキュリティを確保する環境を整備するものとされています。

 

Q2       車載ソフトウェアのアップデートについての従来のルールはどのようなものでしたか。

従来のルールは、通信を用いた使用過程時における車載ソフトウェアのアップデートを含む改変による自動車の改造に特に着目した規制はなく、自動車の改造一般における当該自動車の保安基準(国が定める保安上又は公害防止その他の環境保全上の技術基準)への適合性審査により対応していました。具体的には、型式指定を受けたメーカー等との関係では、①メーカー等において指定を受けた型式の車両の構造、装置又は性能等に変更がある場合に変更届出を提出させ、変更後の型式に係る保安基準適合性を審査し[2]、また②保安基準に適合しなくなるおそれがある状態又は適合していない状態にある同一の型式の一定の範囲の車両について、その原因が設計又は製作の過程にある場合は、メーカー等に改善措置[3]を講じさせることなどにより対応していました。また、個々のユーザーとの関係では、③使用過程時における保安基準に適合しなくなる改造等を禁止[4]し、④定期的な自動車の検査(いわゆる車検)等において保安基準適合性を審査する[5]とともに、⑤保安基準に適合しなくなるおそれがある状態又は適合していない状態にある車両についてはユーザーに整備命令等[6]を発することなどにより対応していました。

 

Q3       今回導入される特定改造等許可制度とは、どのような制度ですか。  

今回の改正は、使用過程時に通信を用いて車載ソフトウェアを改変しようとする者等に対して、「特定改造等」に該当する行為(Q5)をしようとする場合には、そのソフトウェアアップデート及びサイバーセキュリティにかかる能力や体制等が所定の基準に適合することを国土交通大臣が事前に審査する許可制度(Q6)を導入するとともに、許可を受けた後もその能力や体制を維持する等の義務を課しています(Q12)。

 

この制度の特徴は、従来求めていた車両の保安基準適合性(Q2)に加えて、ソフトウェアを改変しようとする者等の組織体制に係る基準適合性をも求めている点です。当該組織体制に係る基準が定量的な試験法や基準値を設けるのではなく必要なプロセスを定めている点を捉え、同制度はプロセス認可を導入するものとも言われています。

 

また、特定改造等の許可は、原則としてソフトウェアを改変する毎に取得する必要があります[7]。加えて、申請に係るソフトウェアの改変により改造される自動車毎に取得するのが原則ですが、既に指定を受けている型式毎に取得することも可能です(省令第3条1項)。

 

Q4       いわゆるレベル2の自動運転車両も特定改造等許可制度の対象となりますか。

今般の一連の法改正で、保安基準の対象となる装置にレベル3の自動運転を可能とする自動運行装置[8]が加わりました。しかし、Q5①のとおり、自動運行装置以外の装置に組み込まれているプログラム等の改変も特定改造等に含まれます。そのため、同制度の適用は、いわゆるレベル3以上の自動運転車両に限定されるものではなく、レベル2の自動運転を可能とするADASを備えた車両であっても、ソフトウェアの改変をしようとする場合には、特定改造等として事前の許可が必要な場合があります。ただし、自動運行装置を搭載しない車両については、例外的な取り扱いがなされています(Q7(2)、Q12)。

 

Q5       許可が必要な特定改造等とは、どのような行為ですか。

改正法は、以下の各行為を特定改造等と定義しています(法第99条の3第1項各号。以下、①の行為についての許可を申請する者を「1号申請者」、②の行為についての許可を申請する者を「2号申請者」と言います。)。

①自動運行装置その他の装置に組み込まれたプログラム等(プログラムその他の電子計算機による処理の用に供する情報をいう。以下同じ。)の改変による自動車の改造であって、当該改造のためのプログラム等が適切なものでなければ自動車が保安基準に適合しなくなるおそれのあるものとして国土交通省令で定めるものを、電気通信回線を使用する方法その他の国土交通省令で定める方法によりする行為(同項1号)

➁前号に規定する改造をさせる目的をもつて、電気通信回線を使用する方法その他の国土交通省令で定める方法により自動車の使用者その他の者に対し当該改造のためのプログラム等を提供する行為(同項2号)

 

上記①の行為は、要するに、通信を用いた車載ソフトウェアの改変であって、当該改変が保安基準により規制される法41条1項に定める各装置(エンジン、ハンドル、ブレーキなど)の性能を変更するものをいいます(自動車の特定改造等の許可に関する省令(以下「省令」といいます。)1条1項。ただし、保安基準に適合することが明白であるものは除かれます。)。そのため、例えばブラウジングサービスなどのいわゆるインフォテインメント機能を充実させることを目的とするソフトウェアアップデートは、当該各装置の性能に変更がない限り、該当しません。

 

また上記②の行為は、要するに、上記①の行為をさせる目的で、ユーザーや整備事業者等に通信を使用するか又は電子的記録媒体(CD-ROM等)を配布して改造のためのソフトウェアを提供する行為をいいます(省令1条3項)。

 

Q6       特定改造等の許可を受けるための要件は何ですか。

改正法は、申請者が以下の基準に適合していることを許可要件として定めています(法第99条の3第3項)。

①申請者が特定改造等を適確に実施するに足りる能力及び体制を有する者として国土交通省令で定める基準に適合する者であること。

➁申請に係るプログラム等の改変により改造された自動車が保安基準に適合すること。

 

上記①は、要するに、申請者が、適切なソフトウェアアップデート及びサイバーセキュリティを確保するために必要な業務管理能力を有すること(省令第4条1項。以下「能力要件」といいます。)、並びにソフトウェアアップデートに起因した不具合の是正を適確に実施するために必要な体制を有すること(同2項。以下「体制要件」といいます。)を求めています。 また、上記②は、ソフトウェアアップデートされた自動車が保安基準に適合すること(省令4条3項。以下「保安基準適合性要件」といいます。)を求めています。なお、国土交通大臣は許可をするにあたり、自動車特定整備事業の認証同様、条件や期限(法第99条の3第2項)を付すことが可能です。

 

Q7 能力要件とはどのようなものですか。審査はどのように行われますか。

(1)能力要件について

申請者は、プログラム等の適切な管理及び確実な改変並びにサイバーセキュリティを確保するための業務管理システムとして、「プログラム等改変業務管理システムの技術基準」(以下「SUMS技術基準」といいます。)及び「サイバーセキュリティ業務管理システムの技術基準」(以下「CSMS技術基準」といいます。)にそれぞれ適合する組織体制を用意する必要があります(自動車の特定改造等の許可に関する技術上の基準に係る細目等を定める告示(以下「告示」といいます。)第1条1項及び同別添1及び2。それぞれの技術基準は本レター別紙にも添付しています)。ただし、上記Q5②に定める行為をしようとする申請者はCSMS技術基準を満たす必要はありません(同2項)。

 

これらのSUMS技術基準及びCSMS技術基準の内容や、能力要件の事前証明制度(Q7(2))は、国際連合欧州経済委員会(UN/ECE)「自動車基準調和世界フォーラム」(以下「WP29」といいます。)が本年6月24日付で採択した各UN Regulation(いわゆる協定規則)[9]に忠実に定められており、その他の保安基準同様、国際基準との協調を図っています[10]

 

(2)審査について

特定改造等の許可を申請しようとする者は、能力要件を充足することについてあらかじめ国土交通大臣の証明を受ける必要があり(省令第2条1項)、国土交通大臣は、能力要件を充足するものと判断した申請者に対し、能力基準適合証明書を交付します(省令2条5項)。そして、申請者は、特定改造等の許可申請時に、その時点で有効な能力基準適合証明書の写しを申請書に添付して国土交通大臣に提出します(省令第3条3項)。能力基準適合証明書の有効期間は3年です(省令2条6項)。

国土交通大臣は、能力要件の審査については、独立行政法人自動車技術総合機構(以下「機構」といいます。法第99条の3第8項)に委託しています。機構は、申請者から提出を受けた資料(申請に係る業務管理システムの概要を記載した書面、所定の宣誓書及び誓約書。省令2条3項)を元に、申請者の業務管理システムがSUMS技術基準及びCSMS技術基準に適合するか否かを判断します。審査は書面審査及び実地調査により行われ、処理期間は審査の開始から原則8週間以内とされています(審査事務規程2-5)。

 

なお、自動運行装置を搭載しない自動車については、当分の間、能力要件に関する審査は行われません(省令附則2項、告示5条)。また、自動運行装置を搭載する自動車についても、2022年6月30日までに製作、型式指定を受けた等の自動車については、CSMS技術基準が一部不適用とされています(告示附則2条)。

 

Q8 体制要件とはどのようなものですか。審査はどのように行われますか。

(1)体制要件について

体制要件は、事業者の一般的な組織体制が審査の対象となる能力要件と異なり、個別のソフトウェアの改変及び自動車の改造毎の組織体制が審査の対象となります。具体的には、特定改造等に係る、改造のためのプログラム等の設計及び製作、プログラム等の管理及び改変、当該改変により改造される自動車のサイバーセキュリティの確保(申請者が1号申請者である場合に限る。)並びに当該自動車に発生した不具合(当該改造に係るものに限る。)の是正への対応の行程を、申請者が統括して管理及び改善する体制を整備する必要があります(省令第4条2項)。

 

(2)審査について

申請者は、許可申請にあたり、上記の体制を整備していることを証する書面を申請書に添付します(省令3条3項2号。具体的には、所定の誓約書、品質保証体系図等)。体制要件は、能力要件及び保安基準適合性要件と異なり、国交省が自ら審査を行います。

 

Q9 保安基準適合性要件とはどのようなものですか。審査はどのように行われますか。

(1)保安基準適合性要件について

保安基準適合性要件は、体制要件同様、個別のソフトウェア及び自動車毎に求められる要件です。具体的には、申請に係るプログラム等の改変により改造された自動車の改造に係る部分に関する構造、装置及び性能は、法第40条各号に掲げる事項ごと及び法第41条第1項各号に掲げる装置ごとに保安基準に適合するものでなければなりません(省令第4条3項)。例えば、ソフトウェアのアップデートによって、高速道路等における運行時に車両を車線内に保持する機能を有する自動運行装置を備える自動車であって、自動運行装置作動中の最高速度が60km/h以下であるものとなる場合、道路運送車両の保安基準の細目を定める告示別添122「高速道路等における低速自動運行装置を備える自動車の技術基準」に適合する必要があります(保安基準48条、道路運送車両の保安基準の細目を定める告示第72条の2第14号等)。なお、当該改変により指定を受けた型式の自動車の性能等を変更する場合であって、指定型式毎に特定改造等の許可申請をするとき(Q3)は、変更後の型式について指定を受けたこと等を証する書面の提出も必要となります。

 

(2)審査について

申請者は、許可申請にあたり、申請に係るプログラム等の改変により改造された自動車について、改造に係る箇所が保安基準に適合することを証する書面を提出する必要があります(省令3条3項4号)。国土交通大臣から審査を委託されている機構(法第99条の3第8項)は、申請者から提出を受けた資料及び提示された自動車を元に、保安基準適合性を判断します。審査の処理期間は審査の開始から原則6週間以内とされています(審査事務規程2-4)。

 

Q10 誰が特定改造等の許可の申請をすべきでしょうか。

特定改造等の許可は、特定改造等をしようとする者(Q5)、すなわち直接通信を用いて車載ソフトウェアの改変を行う者又は当該改変をさせる目的でソフトウェアを第三者に提供する者が申請者となります。そして、複数の事業者がソフトウェアのアップデートに関与する場合、申請主体については以下のように考えることができます。

 

(1)まず、外部のベンダー(ソフトウェアベンダーやソフトウェアを組み込んだ部品メーカーなど。以下同じ)から提供を受けたソフトウェアをもって車両メーカーが改変を行う場合や、車両メーカーが整備事業者にソフトウェアを提供し、メーカーの指示に従って整備事業者が改変を行う場合、車両メーカーやベンダー、整備事業者の各行為がともに特定改造等に該当し得ます。しかし、申請者がサプライヤー、サービス提供者、申請者の下位組織と協働してソフトウェアを改変することは告示でも想定されており(CSMS技術基準3.2.5)、また国交省としても、申請者がその責任において、当該ソフトウェアの改変に関与する各事業者全体として許可要件を具備し、また後述の義務の遵守を確保していれば、不都合はないものと考えられます。そのため、車両メーカーが、ベンダーや整備事業者との連携を含めた社内外の組織体制を整えて許可を取得することができれば、重ねてベンダーや整備事業者が当該ソフトウェアの改変にあたり許可を取得する必要はないと考えられます。なお、整備事業者に改変させる車両メーカーが、1号申請者となるか2号申請者となるかは、両者の関係や役割分担等によって異なり得ますが、CSMS技術基準を適用しない理由に乏しく(Q7(1))、通常は1号申請者となるものと考えられます。

 

(2)同様の問題は、国外メーカーから提供を受けたソフトウェアをもって輸入業者が改変を行う場合にも当てはまります。この場合、(1)同様に、国外メーカー自身が申請者となることもできますが、許可を受けるにあたっては、国交省及び機構との迅速かつ適切なコミュニケーションが可能な組織体制が求められるものと考えられます[11]。また、許可を受けた後も、申請者は一定の義務を遵守すべきところ(Q12)、そもそも国外メーカーに対するこれらの規制の実行性には疑問が残ります。そうすると、実際上は、国外メーカーではなく輸入業者が申請者となるべき場合も少なくないものと考えられます。なお、本改正により、許可を受けた者の施設においてソフトウェアに関する一定の情報を記録及び保管する義務が課されることになるため(省令第5条2号、告示2条。Q12)、もし輸入業者が申請者となる場合には、従前は自身で記録等していなかったような当該情報の管理について、必要な対応を迫られることとなります(Q13①も参照)。

 

(3)さらに、ベンダー自らが、車両メーカーや輸入業者を介さずに直接ソフトウェアの改変を行うことも実務上想定されます。その場合、ベンダーは、許可申請に際し、体制要件の審査のために提出する書類(Q8(2))とともに、車両メーカーや輸入業者から同意を得ていることを証する書面及び当該同意の具体的な内容(申請に係るプログラム等の改変により改造される自動車の範囲、申請に係る特定改造等の実施条件を含む。)を記載した書面を提出する必要があります。なお、ベンダー自らが型式指定を受けるための申請自体を行うことも改正によって可能となり(自動車型式指定規則2条)、変更後の型式の指定申請から特定改造等の許可申請までをベンダーが担うことも制度上可能となりました。

 

Q11 従来リコールで対応していたソフトウェアの改変についても、今後は特定改造等の許可が必要ですか。

リコールは、指定型式にかかる自動車の構造、装置又は性能が保安基準に適合しなくなる恐れがある状態又は適合していない状態にあり、かつ、その原因が設計又は製作の過程にあると認める場合において、必要な改善措置を講じる場合には、あらかじめ、国土交通大臣に届出を行う制度です(法第63条の3)。この制度では、対象車両を指定された型式の仕様に戻す措置を講じることが想定されていることから、そのようなソフトウェアの改変の範疇であれば、同条に従って対応すれば足り、別途特定改造等の許可を取得する必要はないものと考えられます。他方で、当該ソフトウェアの改変の範疇を超え、リコールに際して指定型式にかかる自動車が備えるべき性能に変更を加えるような改変を行う場合には、リコールの届出と併せて特定改造等の許可申請が必要な場合もあり得ます。

 

Q12 許可を受けた者が遵守すべき義務は何ですか。

許可を受けた者は、能力要件及び体制要件にかかる基準への適合性を維持する義務を負う(法第99条の3第4項)とともに、主に以下の事項を遵守しなければならないこととされています(同第5項、省令5条)。

①許可の申請書及びその添付書面に所定の変更事項が生じたときは、その旨を国土交通大臣に届け出ること。

➁プログラム等の改変の実施状況等、当該改変に関する所定の情報を記録すると ともに、許可を受けた者の施設において当該情報を保管すること。

➂サイバーセキュリティに対する脅威及び脆弱性の監視、検出及び対応等の許可に係るプログラム等の改変の対象車両のサイバーセキュリティを確保するための措置を講じること(1号申請者に限る。)。

④許可に係るプログラム等の改変による改造の目的、内容及び所要時間、新しい機能の使用方法等の当該改造に関する情報を使用者等に提供すること。

 

さらに、国土交通大臣は、許可を受けた者による特定改造等の適格な実施を確保するために必要と認めるときは、当該者に対して報告徴収又は立入検査を実施することができ(法第100条1項17号、同2項、法第101条)、当該者が上記の義務に違反等したことが判明した場合には、特定改造等の停止命令や許可の取消をすることができます(法99条の3第7項)。

 

このように、許可を受けた後も申請者にこれらの義務を課すことにより、適切なソフトウェアアップデート及びサイバーセキュリティを車両のライフタイムを通じて確保する狙いがあります。

 

なお、自動運行装置を搭載しない自動車について特定改造等の許可を受けた者は、当分の間、上記②ないし④の義務を負いません(省令附則2項、告示5条)。

 

Q13 許可を受けた者が行った車載ソフトウェアのアップデートにより生じた損害について、当該者はいかなる責任を負いますか。

改正法は、特段特定改造等の実施によってユーザーや第三者に生じた損害に対する責任について定めるものではありません。そのため、刑事法や民事法(民法や製造物責任法)等の既存の枠組みに従って判断されます。ただ、以下のような影響も考えられるため、注意が必要です。

①上記のとおり(Q12②)、許可を受けた者の施設において改変するソフトウェアに関する一定の情報を記録及び保管する義務が課されることになりました。また、許可を受けた者は、当該情報を国交省又は機構に利用可能にすることができるプロセスを有する必要があります(SUMS技術基準1.12)。そのため、当該情報について、国交省等による監査の対象となり、それを根拠として行政又は刑事上の責任が問われ得ます。また訴訟の相手方が証拠として当該情報を利用する可能性もあり、それを根拠としてソフトウェアの設計上の欠陥に基づく製造物責任等を問われ得ます。

また、上記のとおり(Q12④)、許可を受けた者は、ソフトウェアの改変についての情報をユーザーに提供する義務を負います。かかる義務の履行が適切に行われないような場合には、行政又は刑事上の責任に加えて、ソフトウェアの指示・警告上の欠陥に基づく製造物責任等を問われ得ます。

 

Q14 改正法の施行日はいつですか。

改正法の施行日は2020年11月23日です。ただし、許可申請の事前受付は同8月23日より開始しています。

 

おわりに

この改正は、実務上問題となっていた使用過程時における車載ソフトウェアのアップデートの取り扱いについて、グローバルな議論と調和する形で、アップデート毎の事前の許可制を導入するものです。関係する企業は、本制度の枠組みを正確に理解したうえで、他の事業者と協働する場合にはその役割分担を踏まえ、特定改造等の許可取得のために求められる社内外の組織体制を準備しておくことが必要になります。改正法の施行前であるため実務上の取り扱いが不透明な部分も多く、またグローバルな議論等を踏まえて随時告示や通達等が更新されることが想定されているため、引き続き今後の動向に注視が必要です。

 

(2020年10月27日公開)

******************

ゾンデルホフ&アインゼル法律特許事務所では、道路運送車両法を含む自動車関連規制に関するアドバイス、パブリックコメント対応、コンプライアンス対応、契約作成・交渉・修正業務、研修、当局・紛争訴訟対応等、AIや自動運転、IoT、CASEやMaaSに関連する法務アドバイスを日常的に提供しています。

 

本書において提供する情報は、あくまで一般的な情報として提供されるものであり、具体的な専門的アドバイスを提供するものではありません。また、本文中の意見にわたる部分は執筆担当者の個人的な見解にすぎず、事務所としての意見またはopinionを構成するものでもありません。具体的な事案に関するご相談には個別に対応いたしますので、改めて担当弁護士(坂井健吾)まで、お問い合わせください。

 

 

別紙(SMUS技術基準)
1. 対象
本技術基準は、プログラム等の適切な管理及び確実な改変を確保するための業務管理システムに適用する。
2. 定義
2.1. 「車両型式」とは、少なくとも次に掲げる点において異ならない車両をいう。
(1) 自動車製作者等が指定する型式
(2) プログラム等の改変のプロセスに関する車両の設計の根本的な点
2.2. 「RXソフトウェア識別番号(以下「RXSWIN」という。)」とは、車両の性質に関連する特定の協定規則(車両並びに車両への取付け又は車両における使用が可能な装置及び部品に係る調和された技術上の国際連合の諸規則の採択並びにこれらの国際連合の諸規則に基づいて行われる認定の相互承認のための条件に関する協定に附属する規則をいう。)の規定への適合性に影響を与える電子制御装置の型式認可に関連するプログラム等についての情報を表す専用の識別符号であって、自動車製作者等により定義されたものをいう。
2.3. 「プログラム等の改変」とは、プログラム等を新しいバージョンに更新(設定パラメータの変更を含む。)するための一連の行為をいう。
2.4. 「プログラム等改変業務管理システム」とは、本技術基準に従ったプログラム等の改変の提供に関する要件に適合するための組織的なプロセス及び手順を定める組織的な取組方法をいう。
2.5. 「自動車の使用者」とは、車両を使用若しくは運転する者、車両の所有者、権限を有する運行管理者の代表者若しくは従業員、当該車両の自動車製作者等の代表者若しくは従業員又は権限のある技術者をいう。
2.6. 「無線改変」とは、ケーブルその他のローカル接続を使用する代わりに無線を使用するプログラム等の改変をいう。
2.7. 「完全性検証データ」とは、データのエラー又は変更を検出するために比較可能なデジタルデータをいう。当該検証データは、チェックサム及びハッシュ値を含むことができる。
3. 要件
3.1. プログラム等改変業務管理システムは、次の3.1.1.から3.1.12.までに掲げるプロセスを有するものでなければならない。
3.1.1. 本技術基準に関連する情報が申請者により文書化され、かつ確実に保管されるとともに、要求に応じ、国土交通大臣又は独立行政法人自動車技術総合機構交通安全環境研究所(以下「試験機関」という。)に対して利用可能にするプロセス
3.1.2. 完全性検証データを含む全ての初期及び改変されたプログラム等のバージョンに関する情報並びに道路運送車両の保安基準(昭和26年運輸省令第67号。以下「保安基準」という。)に関連するシステムのハードウェアの構成要素を一意に特定できるプロセス
3.1.3. RXSWINを使用する場合において、改変前及び改変後における車両のRXSWINに関する情報にアクセスし、これを更新できるプロセス。このプロセスは、各RXSWINに対する全ての関連プログラム等のバージョン及び完全性検証データに関する情報を更新する能力を含むものとする。
3.1.4. RXSWINを使用する場合において、保安基準に関連するシステムの構成要素に存在するプログラム等のバージョンが、関連するRXSWINによって定義されるものと整合していることを申請者が検証できるプロセス
3.1.5. 改変されたプログラム等に係るシステムと他のシステムとの相互依存を特定できるプロセス
3.1.6. 申請者がプログラム等の改変のために当該改変の対象車両(以下「対象車両」という。)を特定できるプロセス
3.1.7. プログラム等の改変のためのプログラム等の発行前において、対象車両の構成に関する当該改変の互換性を確認するプロセス。このプロセスは、当該互換性を確保するための対象車両における最新のプログラム等及びハードウェアに関する構成の評価を含むものとする。
3.1.8. プログラム等の改変が、保安基準に関連するシステムに影響するかどうかを評価、特定及び記録するプロセス。このプロセスは、当該改変が、当該システムを定義するために用いられるパラメータに影響を及ぼし、若しくは当該パラメータを変更するかどうか、又は当該システムの保安基準に関連するパラメータを変更する可能性があるかどうかを検討するものとする。
3.1.9. プログラム等の改変が、新規登録の時点において存在していなかった若しくは有効でなかった機能を追加、変更若しくは有効化するかどうか、又は3.1.8.のパラメータ以外の保安基準に関連するパラメータ若しくは機能を変更若しくは無効化するかどうかを評価、特定及び記録するプロセス。当該評価は、次の3.1.9.1.から3.1.9.3.までに掲げる事項の検討を含むものとする。
3.1.9.1. 道路運送車両法(昭和26年法律第185号。以下「法」という。)第75条第1項、第75条の2第1項若しくは第75条の3第1項の規定に基づく自動車、共通構造部若しくは装置の型式の指定に係る申請書及びその添付書面又は国土交通大臣が定める書面の記載事項を変更する必要があるかどうか。
3.1.9.2. 保安基準への適合性に関する審査の結果が、改変後における車両に対しても有効であるかどうか。
3.1.9.3. 車両の機能に対する変更が当該車両の保安基準への適合性に影響を及ぼすかどうか。
3.1.10. プログラム等の改変が車両の安全かつ継続的な運転に必要な他のシステムに影響を及ぼすかどうか、又は当該改変が車両の機能を新規登録の時点から追加若しくは変更するかどうかを評価、特定及び記録するプロセス
3.1.11. 自動車の使用者がプログラム等の改変について通知を受けることができるプロセス
3.1.12. 申請者が3.2.3.及び3.2.4.の情報を国土交通大臣又は試験機関に対して利用可能にすることができるプロセス
3.2. 申請者は、対象車両に適用される各プログラム等の改変に関し、次の3.2.1.から3.2.5.までに掲げる情報を記録及び保管しなければならない。
3.2.1. プログラム等の改変のために申請者により使用されるプロセス及び当該改変の適合性を実証するために使用される関連標準を説明する文書
3.2.2. 保安基準に関連するシステムに係るプログラム等の改変前後における車両の構成を説明する文書。当該文書は、保安基準に関連するシステムのハードウェア及びプログラム等に対する一意の識別子(プログラム等のバージョンを含む。)並びに関連する車両又はシステムのパラメータを含むものとする。
3.2.3. 各RXSWINに対し、プログラム等の改変前後における車両の当該RXSWINに関連する全てのプログラム等を説明する監査可能な記録が存在しなければならない。当該記録は、各RXSWINに関連する全てのプログラム等について、そのバージョン及び完全性検証データに関する情報を含まなければならない。
3.2.4. 対象車両及び対象車両における最新の構成に関する互換性の検証をリスト化した文書
3.2.5. 対象車両に対する全てのプログラム等の改変に関し、次の3.2.5.1.から3.2.5.9.までに掲げる事項を説明する文書
3.2.5.1. 当該改変の目的
3.2.5.2. 当該改変が影響を及ぼす可能性がある車両のシステム又は機能
3.2.5.3. 3.2.5.2.のシステム又は機能のうち保安基準に関連するもの(該当する場合)
3.2.5.4. 当該改変が保安基準に関連するシステムの保安基準への適合性に影響を及ぼすかどうか(該当する場合)。
3.2.5.5. 当該改変が、システムの保安基準に関連するパラメータに影響を及ぼすかどうか。
3.2.5.6. 当該改変に対する許可が求められたかどうか。
3.2.5.7. 当該改変が実施可能な方法及び条件
3.2.5.8. 当該改変が安全かつ確実に実施されることの確認
3.2.5.9. 当該改変が検証及び確認の手順を順調に経ていることの確認
3.3. 申請者は、セキュリティに関し、次の3.3.1.から3.3.3.までに掲げる事項を実証しなければならない。
3.3.1. プログラム等の改変プロセスが開始される前において、改ざんを合理的に防止するために、当該改変が保護されることを確保するために使用するプロセス
3.3.2. プログラム等の改変の提供システムの開発を含め、使用される改変プロセスが、危殆化を合理的に防止するために保護されていること。
3.3.3. プログラム等の機能性及び車両において使用されるプログラム等のコードを検証及び確認するために使用されるプロセスが適切であること。
3.4. プログラム等の無線改変に対する追加要件
3.4.1. 申請者は、無線改変が運転中に実施される場合において、当該改変が安全性に影響を及ぼさないことを評価するために使用するプロセス及び手順を実証しなければならない。
3.4.2. 申請者は、無線改変のプロセスを完了させるために、プログラミング後におけるセンサの再校正等、当該改変が特定の技能又は複雑な行為を要する場合において、当該行為を実施する技能を有する者が存在する又は当該プロセスの管理下にあるときにのみ当該改変が行われることを確保するために使用するプロセス及び手順を実証しなければならない。

 

 

別紙(CSMS技術基準)

1. 適用範囲
本技術基準は、自動車のサイバーセキュリティを確保するための業務管理システムに適用する。
2. 定義
2.1.  「車両型式」とは、少なくとも次に掲げる点において異ならない車両をいう。
(1) 自動車製作者等が指定する型式
(2) サイバーセキュリティに関する電気・電子構造及び外部インターフェースの根本的な点
2.2. 「サイバーセキュリティ」とは、車両及びその機能が、電気部品又は電子部品に対する脅威から保護されている状態をいう。
2.3. 「サイバーセキュリティ業務管理システム」とは、自動車のサイバーセキュリティに対する脅威に関連するリスクを処理し、当該自動車をサイバー攻撃から保護するための組織的なプロセス、責任及び管理を明確にする、リスクに基づく組織的な取組方法をいう。
2.4. 「開発段階」とは、(1)及び(2)に掲げる自動車の区分に応じ、当該(1)及び(2)に定める期間をいう。
(1) 法第75条第1項の規定によりその型式について指定を受けた自動車 当該指定を受けるまでの期間
(2) (1)に掲げる自動車以外の自動車 その生産が開始されるまでの期間
2.5. 「生産段階」とは、車両型式又は車両の生産期間をいう。
2.6. 「生産後段階」とは、車両型式又は車両の生産が終了してから使用可能な当該型式又は車両が存在しなくなるまでの期間をいう。
2.7. 「軽減策」とは、リスクを軽減する手段をいう。
2.8. 「リスク」とは、自動車のサイバーセキュリティに係る脆弱性を悪用することにより、特定の脅威が組織又は個人に危害を与えるおそれをいう。
2.9. 「リスクアセスメント」とは、リスクの性質を理解し、リスクを分析(リスクのレベルを決定することをいう。)するための当該リスクの特定(リスクを発見、認識及び説明することをいう。)及びリスクを評価(当該リスク又はその重大さが受入可能又は許容可能であるかどうかを決定することをいう。)するための当該分析の結果とリスク許容基準(許容することができるリスクかどうかを判断するための基準をいう。)との比較に関する全体的なプロセスをいう。
2.10. 「脅威」とは、システム、組織又は個人に危害を与える可能性のある望まない事案の潜在的な要因をいう。
2.11. 「脆弱性」とは、一つ以上の脅威によって悪用されるおそれのあるデータ資産又は軽減策の弱点をいう。
3. 要件
3.1. 試験機関は、審査のため、申請者がサイバーセキュリティ業務管理システムを導入していることを検証するとともに、本技術基準への適合性を検証しなければならない。
3.2. サイバーセキュリティ業務管理システムは、次の3.2.1.から3.2.5.までに掲げる要件を満たさなければならない。
3.2.1. 申請者は、試験機関に対し、サイバーセキュリティ業務管理システムが次に掲げる段階を考慮していることを証明しなければならない。
(1) 開発段階
(2) 生産段階
(3) 生産後段階
3.2.2. 申請者は、サイバーセキュリティ業務管理システムにおいて使用されるプロセスにより、別紙に規定する脅威及び軽減策を含め、サイバーセキュリティを十分に考慮することが確保されていることを証明しなければならない。この場合において、当該プロセスは次に掲げるプロセスを含むものとする。
(1) サイバーセキュリティを管理するための組織内で使用されるプロセス
(2) 車両へのリスクの特定のために使用されるプロセス。当該プロセスにおいては、別紙のパートAに規定する脅威その他の関連する脅威が考慮されるものとする。
(3) 特定されたリスクの評価、分類及び処理のために使用されるプロセス
(4) 特定されたリスクが適切に管理されていることを検証するために導入されているプロセス
(5) 車両のシステムのサイバーセキュリティをテストするために使用されるプロセス
(6) リスクアセスメントが最新に保たれていることを確保するために使用されるプロセス
(7) 車両へのサイバー攻撃、サイバーセキュリティに対する脅威及び脆弱性の監視、検出及び対応のために使用されるプロセス並びに実施されたサイバーセキュリティを確保するための対策が、特定された新たなサイバーセキュリティに対する脅威及び脆弱性に照らして依然として有効であるかどうかを評価するために使用されるプロセス
(8) 実施されたサイバー攻撃の分析に資する関連データを提供するために使用されるプロセス
3.2.3. 申請者は、サイバーセキュリティ業務管理システムにおいて使用されるプロセスにより、3.2.2.(3)の分類及び3.2.2.(7)の対応に基づき、サイバーセキュリティに対する脅威及び脆弱性のうち対応が必要なものが合理的な期間内に軽減されることが確保されることを証明しなければならない。
3.2.4. 申請者は、サイバーセキュリティ業務管理システムにおいて使用されるプロセスにより3.2.2.(7)の監視が継続的であることが確保されていることを証明しなければならない。この場合において、当該監視は、次の3.2.4.1.及び3.2.4.2.に掲げる要件を満たすものとする。
3.2.4.1. 初めて新規登録を受けた車両が監視対象に含まれていること。
3.2.4.2. サイバーセキュリティに対する脅威及び脆弱性並びにサイバー攻撃を車両のデータ及びログにより分析及び検知することができること。この場合において、車両の所有者又は運転者に係る個人情報その他のプライバシーの保護に関する権利が尊重されるものとする。
3.2.5. 申請者は、3.2.2.の規定に関し、サイバーセキュリティ業務管理システムが、その契約するサプライヤー、サービス提供者又は申請者の下位組織との間に存在する関係をどのように管理するかについて証明しなければならない。

 

 

別紙 脅威及び対応する軽減策の一覧
1. 本別紙は3つのパートから構成される。本別紙のパートAは脅威、脆弱性及び攻撃方法の基本的な水準を、パートBは車両に関連した脅威に対する軽減策を、パートCは車両外の領域(例えばITバックエンド)に関連した脅威に対する軽減策を、それぞれ定める。
2. 申請者が実施するリスクアセスメント及び軽減策にあっては、パートA、パートB及びパートCを考慮するものとする。
3. 高次の脆弱性又は脅威及びこれらに対応する脆弱性又は攻撃方法の例には、パートAにおいて項目番号が付されている。パートB及びパートCの表においても、それぞれのサイバー攻撃又は脆弱性及びこれらに対応する軽減策の一覧を関連付けるため、同じ項目番号が参照されている。
4. 脅威分析においては、攻撃により生じ得る影響についても考慮するものとする。これは、リスクの重大性の確定及び追加リスクの特定に役立つ可能性がある。攻撃により生じ得る影響には、次の4.1.から4.8.までに掲げるものが含まれる可能性がある。
4.1. 車両の安全な操作に影響すること。
4.2. 車両の機能が停止すること。
4.3. プログラム等が改変され、車両の性能が変更されること。
4.4. 車両の操作への影響はないが、プログラム等が改変されること。
4.5. データの完全性が侵害されること。
4.6. データの機密性が侵害されること。
4.7. データの可用性が失われること。
4.8. その他の影響(犯罪行為に関するものを含む。)
(パートAないしC略)

 

 

[1] SAE InternationalのJ3016(平成28年9月)及びその日本語参考訳であるJASO TP 18004(平成30年2月)における自動運転レベルの定義による。以下同じ。

[2] 法75条(自動車の指定)、自動車型式指定規則等参照

[3] 第63条の3(改善措置の届出等)等

[4] 法第99条の2(不正改造等の禁止)

[5] 法第62条(継続検査)等

[6] 法54条、54条の2(整備命令等)

[7] 第118回国会衆議院国土交通委員会第九号(令和元年5月8日)奥田政府参考人発言「プログラムの改変による改造につきましては、その目的に応じて内容が千差万別であることから、その適切性が確保されているかどうかについて、原則としてプログラムごとに確認を行う必要がございますが、複数の特定改造を同一の組織、体制のもとで実施する場合にあっては、許可にあたり、必ずしも改造のためのプログラムごとに申請者の能力、体制の適切性を個別に確認する必要はないと考えられることから、当該許可に係る確認の一部を省略する等の運用を行うことによって申請者の負担軽減に努める一方、許可を受けた者に対する監査等の事後チェックを適切に実施することにより自動車の特定改造を行う者の能力及び体制の維持に万全を期して参りたい」

[8] プログラム(電子計算機(入出力装置を含む。この項及び第九十九条の三第一項第一号を除き、以下同じ。)に対する指令であって、一の結果を得ることができるように組み合わされたものをいう。以下同じ。)により自動的に自動車を運行させるために必要な、自動車の運行時の状態及び周囲の状況を検知するためのセンサー並びに当該センサーから送信された情報を処理するための電子計算機及びプログラムを主たる構成要素とする装置であって、当該装置ごとに国土交通大臣が付する条件で使用される場合において、自動車を運行する者の操縦に係る認知、予測、判断及び操作に係る能力の全部を代替する機能を有し、かつ、当該機能の作動状態の確認に必要な情報を記録するための装置を備えるもの(法第41条2項)

[9] SUMS技術基準に関するUN Regulation:

https://undocs.org/ECE/TRANS/WP.29/2020/80

CSMS技術基準に関するUN Regulation:

http://www.unece.org/fileadmin/DAM/trans/doc/2020/wp29grva/ECE-TRANS-WP29-2020-079-Revised.pdf

[10] SUMS技術基準については該当Regulationの7.1項を、またCSMS技術基準については該当Regulationの7.2項や各Tableを、それぞれほぼそのまま翻訳したものであり、また能力要件の事前証明制度についても、各Regulationの 6項を省令2条として導入するものとなっています。

[11] 例えば、SUMS技術基準3.1.1及び3.1.12では、国交省及び機構との適切なコミュニケーションが可能であることが求められるものと考えられます。また体制要件として申請者が統括管理等すべき、対象車両に不具合が生じた場合に是正するプロセスにおいても、同様に国交省との迅速かつ適切なコミュニケーションが可能であることが求められるものと考えられます。