{{item.title}}
{{item.text}}
{{item.title}}
{{item.text}}
「自動運転社会の構造と実現に向けたアジェンダ ―導入編―」で解説したように、自動運転社会を実現するためには、自動車メーカーや行政に加えてさまざまな業界のプレイヤーが相互かつ密接に連携し、エコシステムを構築することが不可欠です。
一方でこうした新たな連携は、自動運転社会実現の前提となる利用者の安心安全を脅かすさまざまなリスクにもつながります。本コラムでは、自動運転技術を用いた移動サービス(以下、自動運転移動サービス)を国内で実装する際に想定されるリスクと、各プレイヤーに求められる対応について解説します。
日本では自動運転車両の実用化に向けて※1、自動運転レベル4※2の公道走行を可能とするため、2022年4月に道路交通法が改正されました。2023年5月にはレベル4の自動運転移動サービスが開始され※3、現在、自動運転の実証実験が自治体主導で進められています。
海外では自動運転車両と配車サービスを組み合わせたいわゆる「ロボタクシー」のサービスも実用化され、さまざまな企業の参画が進んでいます。
こうしたサービスの実装が進む一方で、人の意思を介せずにシステムが車両の挙動を判断・操作するレベル4以上の自動運転車両においては、サイバー攻撃などによって不正に制御されることによる人命への被害などの懸念が以前より指摘されています。
また、自動走行機能のみならず、スマートフォンアプリを使った配車や車内インフォテインメントといった新たな移動体験を提供する機能を実現するため、車両を含むさまざまな機器や周辺システムがネットワークでつながっていますが、これにより、セキュリティ対策が不十分なシステムがサイバー攻撃の起点となることや、被害がサービス全体に広がることのリスクも高まっています。
こうしたサイバーセキュリティリスクは、自動運転移動サービスが安心・安全なサービスとして社会に受け入れられ、普及していく上で大きな障害となり得ます。そのため、サービスに関与するプレイヤーは想定されるリスクを考慮した上で、十分かつ説明力のある対策を講じる必要があります。
自動運転移動サービスのセキュリティを担保する上で特に重要となるのは、サービスを実現するために、これまで以上にさまざまな機器やシステムがネットワークでつながり、それらを提供する多様なプレイヤーが関与することで、複雑なサービスが実現されるという点です。
よって、サービスを運営管理するモビリティサービス事業者や官公庁、自治体などのサービサーや自動車メーカーが、サービスに関わるプレイヤーのセキュリティ活動を把握、管理することが求められます。各プレイヤーがそれぞれのスコープでセキュリティ対策を実施することは重要ですが、個別最適とならないよう、サービス全体を俯瞰した一貫性のある、隙間のないセキュリティ活動を推進する必要があるためです。
以下では複数のサービスやプレイヤーが関与する特徴を持つ自動運転移動サービスにおいて、これらを実施する上で事前に取り決めるべき3つのポイントを示します。
サービス実装に際して構築されるシステムの構成要素とその関連性、動作原理などの枠組みや設計(以下、システムアーキテクチャ)にセキュリティの観点を取り入れることは、サービスの安全性を担保する上で不可欠です。よって、システムアーキテクチャに関する要件を設け、各プレイヤーに遵守を促すことが重要です。さらに、新規プレイヤーの参画などにより、新しくシステムを接続する際にはそのシステムが要件を満たせているか、評価する必要があります。
データ連携におけるサービス内共通のルールを設定し、各プレイヤーのルール遵守状況を定期的に確認することが必要です。ルール策定における観点の例を以下に示します。
セキュリティインシデントが発生した場合、攻撃を受けた資産を管理するプレイヤーは主体的に対応する必要があります。また、サービサーはセキュリティインシデントについて外部に説明を行うことが求められます。セキュリティインシデント発生時の実施事項と、事前に決めておくべき事項の例を以下に示します。
自動運転移動サービスでは、図表3の5つのstepでセキュリティ対策を推進することを推奨します。また、各stepのポイントを以下に説明します。
自動運転移動サービスのセキュリティ対策に特化した公的なガイドラインが整備されていないため、関連するガイドラインやサービスのプレイヤーの保有するポリシーなど多数の基準を参照し、セキュリティ要件を定義する必要があります。一貫性のあるセキュリティ活動を推進するためには、前述したシステムアーキテクチャに関する要件やデータの取り扱いに関するルールや、セキュリティインシデント発生時の対応などについてもセキュリティ要件として定めておくことが重要です。また、これらのセキュリティ要件が満たせない場合の対応に関するルールを定める必要もあり、対応の例としてサービスの停止や要件不遵守システムの切り離しなどが考えられます。
Step1で策定した内規に基づいて、各プレイヤーがセキュリティ要件を満たせているかをアセスメントし、その結果に基づいて対応計画を策定する必要があります。また、アセスメントの方法について、セキュリティ要件に関するチェックシートに対するプレイヤーのセルフチェック結果と要件遵守状況に関する証跡をサービサーまたは第三者機関が確認する方法などが考えられます。
Step3までの決定事項に沿って、step4では各プレイヤーが確実にセキュリティ対策を実施することが非常に重要です。Step5ではその実施状況を管理するために、横断的なモニタリングを実現するガバナンスの構築が求められます。また、施策実施や運用を通じ明確にすべきルールや、新たなリスクなどが判明した場合、必要に応じて内規を改訂します
※1
https://www.mlit.go.jp/common/001155023.pdf
https://www.mlit.go.jp/jidosha/content/001583988.pdf
https://www.npa.go.jp/bureau/traffic/selfdriving/index.html
※2
システムがすべての運転操作及び作動継続が困難な場合への対応を一定の条件下で実行。運転操作の主体はシステム。
※3
https://www.meti.go.jp/press/2023/05/20230512002/20230512002.html