車載サイバーセキュリティとは：重要性・法規対応・対策の全体像
車載ソフトウェアの大規模化とコネクテッド化により、自動車は走るITシステムへと進化し、サイバー攻撃の対象になっています。
本コラムでは、車載サイバーセキュリティが重要視される背景から、想定脅威、主要法規（UN-R155/156、ISO/SAE 21434）、CSMS構築、具体的対策、開発プロセスとの関係、実務で使えるチェックリストまでを体系的に整理します。
規制対応を要件充足で終わらせず、製品安全と事業継続の観点でライフサイクル全体に落とし込むための全体像をつかむことを目的とします。
車載ソフトウェア開発のお問い合わせはこちら
AUTOSAR・機能安全から車載Android、SDV、サイバーセキュリティまで車載ソフトウェア開発を一貫して支援
目次
車載サイバーセキュリティが重要視される背景
車載サイバーセキュリティが技術論から経営・法規・安全のテーマへ拡大した理由を、技術トレンドと攻撃動向の両面から整理します。
車載サイバーセキュリティが注目される根本理由は、車が単体の機械から、ネットワークにつながるサービス基盤へ変わったことです。車両の価値がソフトウェアで決まり、販売後も更新され続ける以上、攻撃される可能性も販売後に増え続けます。
さらに、攻撃が現実の事故や大規模リコールにつながり得る点が、自動車特有の重さです。情報漏えいだけでなく、操舵や制動に近い領域へ影響が及べば、人命・法規・ブランドの問題になります。
この状況を受け、各国で型式認証と結びついた規制が整備され、組織として継続的に守れることが求められるようになりました。つまり、対策の対象は車両だけでなく、開発・サプライチェーン・運用を含む全体の仕組みへ広がっています。
コネクテッド化・SDV化で攻撃面が拡大
常時接続が当たり前になると、車両は外部から到達可能な入口を持ちます。通信モジュール、IVI、スマホアプリ、クラウドAPIなど、以前は存在しなかった接点が増えるほど、攻撃面も広がります。
SDVでは機能追加や設定変更がソフトウェア中心で行われ、車は出荷後も変化します。これは価値提供の強みですが、更新のたびに新しい脆弱性が混入したり、設定のミスで露出面が増えたりするリスクも同時に抱えます。
実務上は車両だけを守る発想では不十分です。車両、スマホ、クラウドを一つのシステムとして資産と境界を定義し、どこが侵入点になり得るか、侵入後にどこまで到達できるかを前提に設計する必要があります。
サプライチェーン攻撃が増加
車は多数のサプライヤー部品と外部サービスで成り立ち、開発環境も委託やクラウド利用が一般化しています。そのため、攻撃者にとっては最も弱い組織や工程を起点に侵害し、最終的に車両やバックエンドへ波及させる方が効率的です。
重要なのは、技術対策だけでなく契約と責任分界まで含めて管理することです。誰が何を実装し、どの成果物をいつ提出し、どう検証し、脆弱性が出たら誰がどの期限で対応するのかを合意しておかないと、最後にリスクが宙に浮きます。
監査や第三者評価を活用し、サプライヤーの実力を見える化することも有効です。ただし評価は目的ではなく、開発と運用で守り続ける能力を確保するための手段として設計することがポイントです。
サイバー攻撃が車両制御と安全に直結
車載ECUや車載ネットワークが侵害されると、機密情報の漏えいだけでなく、車両のふるまいそのものが変えられる可能性があります。安全機能に近い領域ほど影響は重大になり、社会的な許容度も低くなります。
ここで重要なのが、機能安全とセキュリティの相互依存です。安全を守るための冗長化やフェイルセーフも、セキュリティが破られると無効化され得ますし、セキュリティ対策が過剰だと安全上必要な操作や診断を阻害することもあります。
従って、設計段階から安全とセキュリティを同じリスク管理の枠組みで調整し、運用段階でも異常検知や更新で安全状態を維持することが、現実的な落としどころになります。
車載ソフトウェア開発のお問い合わせはこちら
AUTOSAR・機能安全から車載Android、SDV、サイバーセキュリティまで車載ソフトウェア開発を一貫して支援
想定される脅威と攻撃経路
車両に対する攻撃は車内ネットワークだけでなく、外部接点から侵入し横展開するため、代表的な経路を押さえることが重要です。
脅威を考えるときは、どの資産を守るか、どこが境界か、侵入後にどう広がるかの順に整理すると抜け漏れが減ります。車両は複数の入口を持ち、入口ごとに攻撃者の難易度と到達範囲が変わります。
また、車両単体の守りだけでは不十分で、スマホアプリやクラウドが突破されて車両に指示が送られる形の攻撃も起こり得ます。外部接点は利便性の源泉である一方、攻撃者にとっても効率のよい入口になりやすい点に注意が必要です。
最後に、侵入の可能性をゼロにできない前提で、侵入後の拡大を止める設計と、早期検知して被害を抑える運用をセットで考えることが実務的です。
ECU・車載ネットワーク（CAN/Ethernet）への攻撃
代表例はCANへの不正メッセージ注入やリプレイで、正規のECUが出す指令に見せかけて挙動を変える攻撃です。診断機能が強力であるほど、権限管理が甘いと悪用されやすくなります。
根本の論点は、車内ネットワークの境界と権限です。どのECUがどのメッセージを出せるのか、診断や書き込みは誰が許可されるのか、領域間の通信はゲートウェイでどう制御するのかを明確にしないと、侵害が横に広がります。
対策は暗号化の有無だけでなく、セグメンテーション、ホワイトリスト制御、診断アクセス制御、ログ取得といった設計原則の組み合わせで効いてきます。どこで止めるかを設計で決め、検証で実証することが重要です。
テレマティクス・IVI・スマホ連携からの侵入
TCUやIVIは外部に露出する機能が多く、脆弱性が見つかると遠隔侵入の入口になり得ます。Bluetooth、Wi-Fi、USBなどの近距離接続も、実装や設定次第では侵入の足がかりになります。
スマホアプリやクラウドAPIは車両と同等に重要です。認証や認可の不備、APIの設計ミス、クラウド設定の誤りは、車に触れなくても遠隔操作や情報取得につながる可能性があります。
実務では、外部露出面を棚卸しし、到達可能性と権限を軸に優先度を決めます。車両側の堅牢化だけでなく、バックエンドのID管理、APIゲートウェイ、レート制限、監視まで含めて一体で設計する必要があります。
OTAアップデート悪用とソフトウェア改ざん
OTAは便利な一方で、更新経路が乗っ取られると広範囲に影響が出ます。配布物の改ざん、署名検証の不備、更新サーバへの侵入などは、車両の信頼を根本から崩します。
見落としやすいのがロールバック攻撃です。古い脆弱なバージョンへ戻されると、署名が正しくても安全性は下がります。更新の真正性だけでなく、適用すべきバージョンの強制や整合性確認が必要です。
OTAの安全性は、車両全体の信頼の根になります。更新が安全に回る設計と運用があるからこそ、脆弱性対応を迅速に行い、ライフサイクルで安全性を維持できます。
車載ソフトウェア開発の詳細はこちら
当社の強みから開発実績までをご紹介
車載サイバーセキュリティの主要法規・規格
各国で規制整備が進む中、UN規則と国際規格を軸に、何が求められ、いつまでに、どの範囲で対応すべきかを整理します。
車載サイバーセキュリティは、ガイドラインの推奨事項から、型式認証に結びついた要求へ移行しています。特にUN規則は各国の制度に取り込まれやすく、実質的にグローバル対応の基準になります。
重要なのは、規格を読んで文書を作ることではなく、要求の意図を自社の開発と運用に翻訳することです。審査で問われるのは、脅威を理解し、リスク評価に基づいて対策し、市場投入後も監視と改善を回せることです。
そのため、R155とR156を軸に、実装と運用を支えるISO/SAE 21434を組み合わせ、CSMSとSUMSを整合させて回す全体設計が現実解になります。
UN-R155（車両サイバーセキュリティ）と適用スケジュール
UN-R155は、車両の型式認証においてサイバーセキュリティ要件を求める規則です。単に製品に機能を載せるだけでなく、組織として安全な車両を開発・提供し続ける能力が問われます。
適用は地域や車種、移行期間により考え方が異なるため、自社製品がどの市場でいつから対象になるのかを最初に確定させることが重要です。ここを曖昧にすると、過剰対応や対応漏れのどちらにもつながります。
実務では、販売地域、型式の新規性、OTAの有無などを切り口に適用可否を整理し、開発スケジュールと証跡整備の計画へ落とし込みます。法規対応は後工程で巻き返しが難しいため、早期判断がコストを左右します。
UN-R155の要求事項：CSMS・リスク評価・監視・インシデント対応
R155の要求は大きく、CSMSの確立、リスク評価の実施、開発から運用までの証跡、継続監視とインシデント対応、脆弱性管理に整理できます。ポイントは、単発の評価ではなく継続的な管理能力として示すことです。
リスク評価はTARAなどの方法で、資産・脅威・攻撃経路・影響を体系的に評価し、対策の優先順位を決めます。重要なのは、テンプレートを埋めることではなく、設計判断やテスト範囲の根拠として使える粒度で残すことです。
また、市場投入後の監視と対応が要求の中心にあります。脆弱性情報を収集し、影響を評価し、修正や緩和策を提供し、必要なら顧客・当局へ説明できる体制が整って初めて、規制の意図に沿った実効性が出ます。
ISO/SAE 21434の概要とライフサイクル
ISO/SAE 21434は、車載サイバーセキュリティをライフサイクル全体で扱うための国際規格で、R155対応の実務を具体化する土台になります。コンセプトから開発、生産、運用、廃止までを通じて、必要な活動と成果物を定義します。
特長は、組織プロセスとエンジニアリング活動がセットになっている点です。体制やルールだけ整えても、設計やテストに反映されなければ意味がありませんし、現場の頑張りだけでも継続性と説明責任が担保できません。
このライフサイクルの考え方は、どのタイミングで何を決め、何を証拠として残すかを明確にするのに役立ちます。監査対応のためだけでなく、設計の手戻りを減らし、運用での判断速度を上げる実利が出ます。
UN-R156（ソフトウェアアップデート）とSUMSの要点
UN-R156はソフトウェアアップデートに関する規則で、更新を安全かつ統制された形で実施できることを求めます。ソフトウェアが価値の中心になるほど、更新の品質と信頼性が型式認証の焦点になります。
中核はSUMSで、更新の承認、配布、検証、記録を行う体制とプロセスが必要です。何を誰が承認し、どの車両にいつ適用し、結果がどうだったかを追跡できないと、問題発生時に影響範囲を確定できません。
ここで構成管理との連携が重要になります。車両ごとのソフトウェア構成、使用コンポーネント、鍵や証明書の状態まで含めて管理して初めて、更新の安全性と説明可能性が成立します。
車載ソフトウェア開発のお問い合わせはこちら
AUTOSAR・機能安全から車載Android、SDV、サイバーセキュリティまで車載ソフトウェア開発を一貫して支援
CSMSの構築ポイント（UN-R155対応）
UN-R155の中核となるCSMSは、単なる規程整備ではなく、責任・プロセス・証跡・継続改善が機能する仕組みとして設計する必要があります。
CSMSはサイバーセキュリティを継続的に回すための経営システムです。文書の整備で終わらせず、意思決定の責任者、現場の実行手順、監査可能な証跡、改善のサイクルが日常業務として回る状態を目指します。
実務でつまずきやすいのは、部門をまたぐ責任の曖昧さです。開発、生産、品質、法規、アフターサービス、IT、クラウド運用が関与し、誰が最終判断するかが不明だと、インシデント時に対応が遅れます。
もう一つの要点は、型式認証を見据えた説明可能性です。なぜそのリスク評価で、なぜその対策で、どう検証し、運用でどう監視するのかを一貫したストーリーで示せると、審査対応だけでなく社内の意思決定も速くなります。
ガバナンスと責任分界（OEM・サプライヤー）
CSMSの起点はガバナンスです。経営が関与し、製品セキュリティの責任者と意思決定経路を明確にし、現場が迷わず動ける状態にします。役割としては、全社のCISOに加え、製品側の責任を担うCPSOや、脆弱性対応のPSIRT機能を置く設計が現実的です。
OEMとサプライヤーの責任分界は、口頭の理解ではなく合意文書で固定します。インターフェースの仕様、セキュリティ要求、成果物、レビュー時期、テスト範囲、脆弱性発生時の連絡と対応期限まで具体化すると、後工程のもめ事を減らせます。
サプライヤー管理は締め付けではなく、全体最適のための設計です。要求が抽象的だと実装の品質がばらつき、結局OEM側で統合リスクが増えます。リスクベースで要求を絞り、重要領域は監査や第三者評価で確度を上げるのが効果的です。
型式認証を見据えた適合性評価の進め方
適合性評価は、ギャップ分析から始めます。現状の規程、開発プロセス、証跡、運用体制を要求と突き合わせ、足りない点を計画に落とし込みます。ここで重要なのは、理想像ではなく、期限内に審査に耐える最小実装を定義することです。
次に、証跡を揃えます。リスク評価結果、要求と設計へのトレーサビリティ、テスト結果、脆弱性管理の記録、インシデント対応訓練の結果など、後から作れないものを優先して整備します。
最後に、内部監査とレビューで説明の筋を通します。サイバーセキュリティケースは、成果物の寄せ集めではなく、主張と根拠を一貫させる枠組みとして組み立てると、第三者説明が格段に楽になります。
車載ソフトウェア開発の詳細はこちら
当社の強みから開発実績までをご紹介
車載サイバーセキュリティ対策のポイント
対策は技術導入だけでは不十分で、要求定義から運用までの一貫した管理と、更新・監視・対応の継続性が要となります。
車載サイバーセキュリティ対策は、多層防御の技術だけでなく、それを選ぶ根拠と運用で効かせ続ける仕組みがセットで必要です。攻撃は設計の穴だけでなく、設定ミス、運用の抜け、サプライチェーンの弱点も突きます。
効果を出すコツは、リスクベースで優先度を付けることです。守るべき資産と影響の大きさ、攻撃の成立しやすさ、検知と復旧の難しさを軸に、投資対効果の高い順に手を打ちます。
また、車は出荷して終わりではありません。脆弱性は後から見つかり、攻撃も変化します。更新できる設計、検知できるログ、迅速に判断できる体制が、結果的に安全とコストを両立させます。
セキュリティ・バイ・デザイン（要求定義～設計）
最初に行うべきは、リスク評価に基づくセキュリティ要求の定義です。何を守り、どの脅威をどのレベルで許容しないのかを決めないと、設計もテストも焦点が定まりません。
設計では多層防御と最小権限を基本にします。たとえば、セキュアブートで起動時の信頼を確立し、重要領域は分離し、通信や診断には認証と権限を設け、異常時に追跡できるログを設計段階で織り込みます。
重要なのは、単一対策への依存を避けることです。暗号化だけ、ゲートウェイだけ、といった一点突破を防ぐには、侵入を遅らせ、横展開を止め、検知して復旧する設計の組み合わせが必要です。
開発・検証：TARA、設計レビュー、ペネトレーションテスト
TARAは開発の早い段階で実施し、アーキテクチャーが固まる前に大きなリスクを潰すのが効果的です。成果物は、脅威の一覧ではなく、要求と設計判断、テスト範囲の根拠として使えることが重要です。
設計レビューでは、境界と権限、デフォルト設定、鍵の扱い、ログの粒度、診断や更新の安全性など、攻撃者視点の観点を定型化して確認します。コード品質の観点ではSAST/DASTやファジングを組み合わせ、バグの混入を早期に減らします。
ペネトレーションテストは車両だけでなく、ECU、バックエンド、アプリを含めて範囲を定義します。合否基準も重要で、重大度、悪用可能性、修正期限、暫定回避策の可否まで含めた判断基準を決めておくと、リリース直前の混乱を防げます。
運用：脆弱性管理とPSIRT（開示対応・パッチ）
市場投入後は、脆弱性が見つかる前提で回す必要があります。窓口を整備し、協調的脆弱性開示の流れで受け付け、トリアージして影響を評価し、修正や回避策を提供します。
PSIRTは単なるメール窓口ではなく、判断と実行のエンジンです。どの製品・構成に影響するか、悪用される可能性はどれくらいか、更新で直すのか、運用で緩和するのかを短時間で決められることが価値になります。
さらに、法規や顧客対応が絡むため、広報、法務、品質、販売会社との連携も設計しておくべきです。SLAや連絡体制が決まっていないと、技術的に直せても市場対応が遅れ、信頼を失います。
監視とインシデントレスポンス（継続的なリスク管理）
監視は車両だけでなく、クラウドとアプリを含めて設計します。どのイベントをログに残し、どの異常をアラートにするかを決め、ノイズを減らして重要な兆候を見逃さないようにします。
インシデントが起きたら、封じ込め、影響範囲特定、復旧、再発防止の順で動きます。フォレンジックを見据えてログ保全と証跡管理を行い、更新停止や機能制限などの暫定措置も選択肢として準備します。
CSMSのPDCAとして、KPIを置いて改善します。たとえば平均対応時間、未修正脆弱性の滞留、検知から封じ込めまでの時間などを追うと、現場のボトルネックが定量で見え、投資判断につながります。
安全なソフトウェアアップデート（OTA、鍵管理、署名）
OTAの基本は署名と検証です。配布物に署名し、車両側が信頼できる根で検証できることが前提になります。加えて、鍵管理が弱いとすべてが崩れるため、HSMなどを活用し、鍵の生成・保管・更新・失効まで運用設計します。
配信面では、セキュアな通信路、段階的ロールアウト、失敗時のフェイルセーフが重要です。更新が途中で止まっても安全状態を保ち、影響が出た場合に対象車両を即座に特定できる記録が必要です。
さらに、構成管理やSBOMと連携すると、脆弱性対応が速くなります。どの車両にどの部品バージョンが入っているかが追えれば、影響範囲の特定と優先順位付けが現実的なスピードで行えます。
車載ソフトウェア開発の詳細はこちら
当社の強みから開発実績までをご紹介
自動車開発プロセスとの関係（Automotive SPICEなど）
セキュリティ活動を現場に定着させるには、既存の開発プロセスと整合させ、成果物とゲートを明確化することが近道です。
車載サイバーセキュリティを新しい業務として追加すると、現場では負担増として受け止められやすく、形骸化の原因になります。定着させるには、既存の開発プロセスの中に自然に組み込み、ゲートで確認される状態にすることが重要です。
Automotive SPICEのようなプロセス評価の枠組みと合わせると、要求管理、設計、検証、変更管理、問題解決といった既存活動に、セキュリティの観点と成果物を紐づけられます。たとえば要求にセキュリティ項目を追加し、設計レビューの観点を定型化し、テスト計画に脅威ベースの項目を入れるといった形です。
ポイントは、証跡が後から作れないようにフローを設計することです。TARA結果が要求に反映され、要求が設計に落ち、設計がテストで検証され、その結果が変更管理と運用へつながる流れができると、規制対応と品質向上が同時に進みます。
車載サイバーセキュリティの進め方チェックリスト
初期診断から立ち上げ、開発適用、運用までを抜け漏れなく進めるために、実務で使える確認観点をチェックリスト形式で整理します。
適用範囲の確認：販売地域と対象規則、対象型式、OTA有無、車両だけでなくクラウドとアプリを含むシステム境界が定義されているか。守るべき資産と安全影響の大きい機能が特定されているか。
体制とプロセス：CSMSとSUMSの責任者、PSIRT、意思決定経路、部門間連携、サプライヤー要求と責任分界が明文化されているか。ギャップ分析とロードマップ、内部監査の計画があるか。
開発と検証：TARAの実施タイミングと成果物、要求から設計・テストへのトレーサビリティ、設計レビュー観点、SAST/DAST/ファジングやペンテストの範囲と合否基準、ログと診断アクセス制御の設計が揃っているか。
運用と継続改善：脆弱性受付とトリアージ、影響評価、修正と配布、顧客・当局対応の手順、監視とアラート、インシデント対応訓練、OTAの署名検証と鍵管理、構成管理と記録、KPIで改善が回っているか。
まとめ
車載サイバーセキュリティは、脅威の理解、法規・規格対応、CSMS/SUMSの構築、セキュア開発と運用の継続によって成立します。自社の適用範囲と優先順位を明確にし、証跡を伴うプロセスとして定着させることが、型式認証対応と製品価値の両立につながります。
車載サイバーセキュリティは、車両がつながり続け更新され続ける以上、開発だけで完結しないライフサイクルの課題です。攻撃面の拡大、サプライチェーンの複雑化、安全への直結という特性が、規制と市場要求を一気に押し上げました。
UN-R155とUN-R156は型式認証に直結し、ISO/SAE 21434は実務で回すための具体策を与えます。対応の中心は、技術だけではなくCSMSとSUMSとして継続的に回せる体制と証跡を作ることです。
成功の鍵は、適用範囲の確定、リスクベースの優先順位付け、開発プロセスへの組み込み、運用での脆弱性対応と監視の実装です。規制対応を単なる提出物ではなく、製品安全と事業継続を守る仕組みとして設計すると、認証対応と競争力の両方に効いてきます。
車載ソフトウェア開発のお問い合わせはこちら
AUTOSAR・機能安全から車載Android、SDV、サイバーセキュリティまで車載ソフトウェア開発を一貫して支援