SDVとサイバーセキュリティ/法規制(UN-R155等)の経営インパクト
SDVにおけるサイバーセキュリティと法規制への対応は、「あれば望ましい」付加価値ではなく、対応しなければ型式認証が通らず市場に出せないという前提条件である。本記事は、なぜそれが前提条件なのか、問われるのが「製品」ではなく「体制」であること、脅威をどう体系的に評価するか、そして経営として何を整えるべきかを論点として整理する。結論を先に言えば、規制対応は一度きりの製品要件ではなく、継続して運用する経営機能として持つ必要がある。
なぜ「あれば良い」でなく前提条件なのか
つながり、更新できる車は、サイバーセキュリティとソフトウェア更新の管理を制度として求められる。これらの要件は、車を市場に出すための型式認証に組み込まれている。型式認証は、量産・販売に先立って設計が技術基準に適合することを当局が審査・承認する制度で、その国際的な枠組みが1958年協定(UNECE/WP.29)である。つまり、これらの規則が適用される市場では、適合できなければ認証が得られず、結果として販売できない。セキュリティ・規制対応が「コストか投資か」を論じる以前に、市場参入の可否を左右する前提条件だ、というのが経営が押さえるべき第一点である。
何が・どの規則で・何を求められるかを整理すると、次のようになる。
| 領域 | 関係する規則 | 求められる体制・識別 |
|---|---|---|
| サイバーセキュリティ | UN-R155 | CSMS(サイバーセキュリティ管理体制) |
| ソフトウェア更新 | UN-R156 | SUMS(ソフトウェア更新管理体制) |
| 認証関連ソフトの識別 | UN-R156 | RXSWIN(ソフト識別番号) |
問われるのは「製品」ではなく「体制」
ここが従来の安全基準と大きく違う点である。CSMSもSUMSも、個別の車両ではなくメーカーの管理体制(プロセス・責任・ガバナンス)に対して認可される。つまり「良い車を1台作れるか」ではなく「サイバーセキュリティとソフト更新を組織として管理し続けられるか」が問われる。しかも、これらの体制認可は一度取得すれば終わりではなく、継続的な運用と維持が前提になる。規制対応を製品開発プロジェクトの一部として一過性で捉えると、この「続く性質」を取りこぼす。
脅威をどう体系的に評価するか
セキュリティ対応は、思いつきの対策の寄せ集めではなく、体系立てた評価に基づく必要がある。その中核となる考え方がTARA(脅威分析・リスクアセスメント)で、守るべき資産・想定される脅威・それらのリスクを体系的に特定し、対策の要否と優先度を判断するためのプロセスである。本記事では具体的な攻撃手法には立ち入らないが、経営として重要なのは「リスクを勘ではなく体系的に把握し、優先順位をつけて投資判断につなげる」枠組みを組織に持たせることである。
経営として何を整えるか
以上を踏まえると、整えるべきは単発の対策ではなく、継続して回る仕組みである。サイバーセキュリティとソフト更新の管理を、製品開発の一機能ではなく、人材・プロセス・責任体制を伴う継続的な経営機能として位置づける必要がある。あわせて、その運用・維持にかかる継続コストを事業計画に織り込むことも欠かせない(予算面の考え方は後述の関連記事を参照)。具体的にどの体制をどう設計し、どこから着手するかは、製品ポートフォリオや対象市場によって個別性が高い。
まとめ:規制・セキュリティで自社が整えるべきこと
SDVの規制・セキュリティ対応は、市場参入の前提条件であり、かつ継続して運用する経営機能である。自社で具体化する際、まず決めたい論点は次のあたりになる。
- サイバーセキュリティとソフト更新の管理体制を、誰が・どの責任で継続運用するか。
- 体制の構築・維持にかかる継続コストを、事業計画にどう織り込むか。
- 脅威評価(TARAの考え方)を、どのプロセスで意思決定に接続するか。
全体像は 【SDV入門】経営層が掴むSDVの全体像 を、規制対応の継続コストの捉え方は SDV関連予算の立て方・ROIの測り方 をあわせて参照してほしい。ここまでは規制対応の「枠組み」だが、自社の製品・体制に即した規制対応戦略や体制設計は個別性が高く、自社固有の前提に落とし込む段階では、外部の視点を入れると論点整理が速い。