UN-R155対応の進め方：CSMS構築から型式認証まで
UN-R155（UNECE WP.29）は、車両サイバーセキュリティを「製品の出来」だけでなく「組織のプロセス（CSMS）」として説明・証明することを求める規制です。従来の型式認証とは異なり、開発〜生産〜市場運用までのライフサイクル全体を対象に、継続的にリスクへ対応できる体制と証跡が重要になります。本記事では、UN-R155で何が義務化されたのかを整理した上で、CSMS構築から開発・運用プロセスへの落とし込み、監査準備、型式認証に向けた進め方をロードマップ形式で解説します。サプライチェーンを含む関係者の役割分担や、UN-R156との同時対応の考え方も扱います。
車載ソフトウェア開発のお問い合わせはこちら
AUTOSAR・機能安全から車載Android、SDV、サイバーセキュリティまで車載ソフトウェア開発を一貫して支援
目次
UN-R155（WP.29）で何が義務化されたか
UN-R155は、車両を取り巻くサイバー脅威に対し、組織としての管理（CSMS）と車両としての適合（型式認証での説明責任）を求める規制です。まずは「何が審査されるのか」を押さえます。
UN-R155のポイントは、サイバーセキュリティを機能や部品単位の対策で終わらせず、組織として継続運用できる仕組みを持つことを義務化した点にあります。型式認証では、車両が脅威に対して適切にリスク低減されていることに加え、それを生み出すプロセスが回っていることを説明できなければなりません。
審査の観点は大きく二つに整理できます。一つ目がCSMSの適合で、方針、役割、リスク管理、開発から市場までのプロセス、サプライチェーン管理、改善活動が制度として成立しているか。二つ目が車両タイプごとの適合で、TARAなどに基づくリスク評価と、設計・検証・運用計画が整合しているかが見られます。
実務で重要なのは、技術資料を「提出用に作る」発想ではなく、日々の意思決定の記録がそのまま監査証跡になるようにプロセスを設計することです。後追いで文書を整えると、判断根拠の不整合や改ざん疑義を招きやすく、監査リスクが上がります。
UN-R155の適用範囲と対象（OEM・サプライヤー、車種・市場）
適用範囲の誤認は、開発計画・販売計画に直結するリスクになります。OEMとサプライヤーで求められる準備の違い、車種・市場ごとの見立て方を整理します。
UN-R155はUNECE加盟国などでの型式認証に紐づくため、どの市場で販売するかで要求の強制力が変わります。まずは自社の販売国、車両カテゴリー、販売時期（新型か継続生産か）を軸に、適用のタイミングを正確に把握することが出発点です。適用時期の読み違いは、認証取得の遅れによる販売停止や、仕様凍結後の設計変更につながります。
OEMはCSMS適合を取得し、車両タイプごとに型式認証で説明責任を負います。一方サプライヤーは直接の認証主体でない場合が多いものの、OEMが説明するための根拠資料やプロセス証跡を提供する責務が現実的に発生します。要求の受け身ではなく、自社の開発・運用プロセスを整備しておくほど、見積・契約・納期の交渉力が高まります。
対象の見立てでは、車両のコネクティビティ有無だけで判断しないことが重要です。診断ポート、近距離無線、スマホ連携、サードパーティーアプリ、工場や整備で接続する機器など、攻撃面は広いからです。境界を狭く定義してしまうと、後から追加評価が必要になり、開発の後工程ほどコストが跳ね上がります。
UN-R155の要求事項の全体像（CSMS）
UN-R155の中心はCSMSです。ガバナンス、リスク管理、開発・生産・運用の各プロセス、証跡管理までを一つの枠組みとして設計する必要があります。
CSMSは、サイバーセキュリティを品質や安全と同じくマネジメント対象として扱い、責任と手順を明確にする枠組みです。ここでのゴールは「強い製品を作る」だけでなく、「脅威が変化しても、組織として検知・判断・是正できる」ことを示すことです。
全体像は、方針とガバナンス、リスク管理（TARAを含む）、開発プロセスへの組込み、サプライチェーン管理、生産・変更管理、市場監視とインシデント対応、証跡管理と継続改善で構成されます。特に見落とされがちなのが、変更管理と運用フェーズです。量産後に脆弱性が出ることを前提に、誰が情報を受け、影響を評価し、顧客・当局・サプライヤーとどう連携して是正するかまでを定義しておく必要があります。
審査で強いCSMSは、文書が立派なだけでなく、意思決定の流れが一貫しています。例えば、リスク受容の基準が明文化され、例外処理の承認者と条件が決まっていて、例外が蓄積しないように定期レビューされている状態です。逆に、現場の判断でリスクを先送りし、後から帳尻合わせをすると、型式認証で説明不能になりやすい典型パターンになります。
UN-R156（SUMS）との関係と同時対応の考え方
UN-R155とUN-R156は別規制ですが、実務では重なる領域が多く、分断して進めると手戻りが起きやすくなります。共通化すべきプロセスと設計方針を明確にします。
UN-R155はサイバーセキュリティの管理全般、UN-R156はソフトウェアアップデートの管理（SUMS）を扱います。ただし、運用で脆弱性が見つかった際の是正手段がアップデートである以上、両者は一連の運用プロセスとしてつながっています。別プロジェクトに分けると、用語、責任分界、記録体系がずれ、監査で整合性を問われやすくなります。
同時対応の要点は、共通の基盤を先に決めることです。具体的には、構成管理（SBOMやバージョン体系を含む）、変更審査、リリース判定基準、ロールバック方針、鍵管理、ログと監視、インシデント対応のチケット運用などは共通化し、R155側のリスク評価とR156側の更新管理で同じ証跡を参照できる状態にします。
設計方針としては、アップデートを「機能追加の手段」ではなく「リスク低減の制御手段」として位置づけると整理が進みます。そうすると、TARAで特定したリスクがどの更新で低減され、更新の失敗時にどのように安全側へ戻すかまでが一貫して説明でき、監査でも評価されやすい構造になります。
対応ロードマップ全体像（計画→構築→運用→監査）
UN-R155対応は一過性のプロジェクトではなく、計画から監査対応までを通した“運用可能な仕組み化”がゴールです。全体工程と成果物の流れを俯瞰します。
ロードマップは、計画、構築、運用、監査の四つの段階で考えると抜け漏れを減らせます。計画では適用範囲の確定、ギャップ分析、認証スケジュールと体制、成果物一覧（どの証跡をいつ作るか）を決めます。この段階で、品質・安全・法規の既存プロセスと統合できる部分を見極めると、運用コストが大きく下がります。
構築ではCSMS文書体系（方針、手順、テンプレート、記録保管）を整え、開発・購買・生産・運用に活動を埋め込みます。ここで重要なのは、文書の完成度よりも、実際に回して記録が残ることです。最初から完璧を狙うと、現場が運用できず形骸化します。
運用では、市場監視、脆弱性対応、アップデート、インシデント訓練、定例レビューを回し、指標で改善します。監査では、内部監査とマネジメントレビューの結果、是正処置、リスク受容の判断履歴などを束ねて、型式認証で一貫したストーリーとして提示できるようにします。
体制づくり：責任者、役割分担、教育
CSMSは組織能力の証明でもあるため、責任者の権限設計、部門横断の役割分担、教育・力量管理が審査の要点になります。立ち上げで押さえるべき勘所をまとめます。
体制づくりは、まずCSMS責任者の設置と権限の明確化から始めます。重要なのは肩書きよりも、リスク受容やリリース判定に対して、品質・開発・生産・法規を横断して調整し、止められる権限があることです。責任だけを負わせて権限がないと、監査で「仕組みが機能しない」と見なされやすくなります。
次にRACIの考え方で、誰が決め、誰が実行し、誰がレビューし、誰へ報告するかを主要プロセスごとに定義します。特に、もめやすいのは、脆弱性情報の受付窓口、影響分析の責任（OEMとサプライヤーの分担）、例外承認、量産後の不具合対応とセキュリティ対応の優先順位です。ここがあいまいだと、初動が遅れ、結果としてリスクが拡大します。
教育は「受講履歴」ではなく「力量の証明」が求められます。役割別に必要スキルを定義し、TARAやセキュア設計、ログの読み方、インシデント対応など、実務に直結する訓練と評価を組み合わせます。外部委託に頼る場合でも、判断を丸投げせず、社内が成果物をレビューできる最低限の力量を持つことが、継続運用の観点で不可欠です。
サプライチェーン管理の進め方（要求展開・評価・契約）
サイバーリスクはサプライチェーン全体に広がるため、要求展開・評価・契約・変更管理を一貫させることが重要です。OEM／サプライヤー双方の実務観点で進め方を整理します。
サプライチェーン管理は、要求を出して終わりではなく、相手が実装・運用できる形に落とし込むことが要点です。まずOEM側は、車両レベルのTARAやアーキテクチャー方針から、サプライヤーへ渡す要求を整理し、成果物の期待値（例：TARA結果、設計根拠、テスト証跡、脆弱性対応手順）を明確にします。
評価は、書類チェックだけでなく、開発プロセスと運用能力を見る設計にします。例えば、脆弱性の受付から修正・リリースまでのリードタイム目標、重大度判定基準、鍵管理、ログの取り扱い、委託先管理など、運用を含めた実装可能性を確認します。ここでのコツは、監査項目を増やしすぎず、型式認証で説明に使う論点に直結する評価軸に絞ることです。
契約では、責任分界と情報共有、変更時の影響分析、脆弱性の通知義務、サポート期間、EOL時の扱いまでを条項化します。サプライヤー側は、要求が不明確なまま受諾すると後でコストが膨らむため、要求の前提（脅威モデル、利用環境、更新方針）を確認し、追加費用が発生する条件を事前に合意しておくことが、長期的には双方のリスクを下げます。
車載ソフトウェア開発の詳細はこちら
当社の強みから開発実績までをご紹介
開発工程の進め方（コンセプト〜量産）
開発ライフサイクルにセキュリティ活動を組み込み、要求から検証までをトレーサブルにすることが型式認証での説明力につながります。コンセプト段階から量産までの要点を段階別に示します。
開発工程では、セキュリティを後付けのレビュー作業にしないことが最重要です。コンセプトで資産と境界、接続形態、想定利用者、更新方針を固め、その前提に基づいてTARAを回し、要件と設計へ落とし込みます。前提が揺れると、後工程のテストや証跡が無効化し、認証に必要な説明が崩れます。
次に、要件から設計、実装、検証、リリース判定までをトレーサブルにします。どのリスクがどの要件になり、どの設計要素で実装され、どのテストで確認されたかを追えることが、型式認証での説得力になります。ツールは何でもよいですが、リンクが切れない運用ルールが必要です。
量産に向けては、製造・サービス工程も含めた攻撃面を確認します。工場治具や診断機、鍵や証明書の発行・注入、サービスでのアクセス権限、ログの保全など、現場の実務がそのままリスク要因になるためです。開発だけを整えても、生産・サービスで崩れると全体として不適合になり得ます。
TARAの実施手順（脅威分析とリスク評価）
TARAは、資産を守るために何を優先すべきかを決める作業です。まず資産（機能、安全、プライバシー、サービス継続）とシステム境界を定義し、ECU、ネットワーク、クラウド、アプリ、整備ツールなどのデータフローと攻撃経路を洗い出します。ここで境界があいまいだと、リスクが取りこぼされ、後から再評価が必要になります。
次に、脅威シナリオを具体化します。誰が、どこから、何を足掛かりに、どう侵入し、何を達成するのかを言語化し、影響度と成立可能性でリスクを算定します。算定方式は組織で統一し、リスク受容基準と例外承認の条件を先に決めておくと、議論が感情論になりません。
成果物は、TARAレポートだけでなく、リスク登録簿と対策トレーサーが重要です。リスクが要件・設計・テスト・運用のどこで低減されるかを追える形にします。また更新タイミングも定義します。設計変更、サプライヤー変更、脆弱性情報の入手、市場でのインシデントや運用知見の獲得など、トリガーを明確にすると、継続運用としてのTARAが成立します。
セキュリティ要件定義と設計への落とし込み
TARAの結果は、そのままでは設計に使えないため、セキュリティ要件へ翻訳します。要件はシステム要件、ソフトウェア要件、運用要件に分け、何を防ぎ、何を検知し、失敗時にどう復旧するかまでを定義します。ここで「暗号化する」など抽象的に書くのではなく、対象データ、鍵の保管、更新方法、アクセス権限、ログの取得点と保存期間など、実装に落ちる粒度にします。
設計では、アーキテクチャーとインターフェースにセキュリティを組み込みます。代表例は、アクセス制御、認証・認可、セキュアブート、通信保護、鍵管理、診断機能の保護、ログと監視です。安全・品質・機能要件との両立も設計論点で、例えば強い認証がユーザビリティを損ねる場合は、脅威と利用シーンに基づく合理的な落としどころを説明できるようにします。
サプライヤー分担は、責任範囲を文書化し、成果物のインターフェースを揃えることが大切です。暗号モジュールや証明書、ログ形式などがばらばらだと統合で破綻します。変更管理では、設計変更や部品差し替えがTARAや要件、テスト範囲に与える影響分析を必須にし、認証上の前提が崩れていないことを常に確認できる状態にします。
検証・妥当性確認（テスト、レビュー、証跡）
検証は、テスト実施そのものよりも、判定基準と証跡の一貫性が重要です。設計レビュー、コードレビュー、静的解析、依存ライブラリの脆弱性確認、設定値レビューなどを計画し、いつ、誰が、何を基準に合否判定したかを記録します。セキュリティは「ゼロリスク」を証明できないため、合理的な基準と判断履歴が説明力になります。
動的な検証として、脆弱性診断やペネトレーションテストを位置づけます。重要なのは、やみくもに広範囲を叩くのではなく、TARAで優先度が高い攻撃経路や資産に対して、狙いを持ったテスト範囲を定義することです。そうすると、型式認証でも「なぜその範囲で十分と言えるのか」を論理的に説明できます。
逸脱時の扱いも事前に決めます。発見された脆弱性を修正するのか、設計を変えるのか、暫定対策でリスク受容するのかを、重大度と露出度で判断できるルールにします。是正処置はチケットで追跡し、再発防止（根本原因分析、教育、プロセス改善）までつなげると、監査で求められるPDCAの証跡になります。
車載ソフトウェア開発の詳細はこちら
当社の強みから開発実績までをご紹介
市場運用の進め方（監視、インシデント対応、脆弱性管理）
UN-R155は量産後の運用能力も重視します。監視、脆弱性受付、影響分析、是正（アップデート含む）、再発防止までの運用プロセスを用意し、継続改善できる状態にします。
市場運用では、脆弱性や攻撃は必ず発生する前提で、検知から是正までの時間を短くする仕組みが求められます。外部からの脆弱性報告窓口、社内でのトリアージ（重大度判定）、影響車両の特定、暫定対策、恒久対策、顧客・当局対応までを一連のフローとして定義します。
監視は「ログを取る」だけでは不十分で、何を異常として検知し、誰が判断し、どのレベルでエスカレーションするかを決める必要があります。車両側のログ、バックエンドのログ、更新配信のログをつなげると、インシデント時の原因究明が早くなり、影響範囲の特定にも役立ちます。
脆弱性管理は部品表と直結します。どの車両・ECU・ソフトウェア・ライブラリに影響があるかを追える構成管理がないと、対応が遅れ、結果としてリスクとコストが膨らみます。運用で得た知見をTARAと要件へフィードバックし、次期開発で同種問題を潰す流れまで作ると、UN-R155が求める継続改善として説得力が出ます。
監査・型式認証に向けた準備（文書化、記録保持、PDCA）
監査では「実施していること」だけでなく「継続的に回っていること」を証跡で示す必要があります。必要文書の整備、記録保持、内部監査とマネジメントレビューによるPDCAの作り方を整理します。
文書化は、規程・手順・テンプレート・記録の四層で整理すると管理しやすくなります。規程で方針と責任、手順でやり方、テンプレートで記録の形式、記録で実施事実を示します。重要なのは、監査直前に作った文書ではなく、運用の中で自然に蓄積された記録があることです。
記録保持では、保存期間、保管場所、改訂管理、アクセス権限を明確にします。TARA、要件、設計根拠、テスト結果、例外承認、サプライヤー評価、インシデント対応の履歴などは相互に参照されるため、リンク切れや版不一致が起きない設計が必要です。ここが弱いと、個々の成果物が良くても全体の説明が崩れます。
PDCAは、内部監査とマネジメントレビューを形式にしないことがカギです。監査で見つかった不適合や改善点が是正処置として完了し、再発防止がプロセスへ反映され、次のレビューで効果が確認される流れを作ります。型式認証では、このループが回っていること自体が「継続的にリスクへ対応できる組織」の証明になります。
まとめ：UN-R155対応を確実に進めるチェックポイント
最後に、CSMS構築から開発・運用・監査までを一貫して進めるためのチェックポイントを整理します。抜け漏れを防ぎ、型式認証で説明できる状態に到達するための確認観点として活用してください。
適用範囲とスケジュールを最初に確定し、成果物を後追いで作らない計画にしているかを確認します。特に、新型・継続生産、販売市場、車両カテゴリーの整理があいまいだと、認証計画が崩れます。
CSMSは文書の有無ではなく、責任と意思決定が機能しているかが本質です。リスク受容基準、例外承認、変更管理、サプライチェーン管理、市場対応が一つの流れとしてつながり、記録が残る運用になっているかを点検してください。
開発ではTARAから要件・設計・テスト・運用へトレーサブルに落ちていること、運用では脆弱性管理とアップデートを含む是正プロセスが回っていることが要です。内部監査とマネジメントレビューで改善が回り続ける状態を作ると、型式認証で説明できる強いUN-R155対応になります。
車載ソフトウェア開発のお問い合わせはこちら
AUTOSAR・機能安全から車載Android、SDV、サイバーセキュリティまで車載ソフトウェア開発を一貫して支援