LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

車がネットワークにつながり、ソフトウェアで機能が変わるようになると、「人を危険にさらさないこと」と「攻撃に耐えること」は切り離せなくなります。この前提を型式の認可に組み込んだのがUN R155・R156で、開発の工程としてどう実現するかを示したのがISO/SAE 21434です。

本記事では、車載ソフトウェアや周辺システムの開発を受託する立場、あるいはサプライヤとして要求に応える立場の担当者に向けて、法規と規格の関係、CSMSとSUMSの中身、脅威分析の進め方、そして成果物として何を残すべきかを整理します。制度と規格は改定されるため、実際の対応は公式文書で確かめながら進めてください。

法規と規格の関係——R155・R156とISO/SAE 21434

まず整理しておきたいのが、法規と規格の役割の違いです。UN R155は、車両メーカーに対して「サイバーセキュリティ管理システム（CSMS）」を持つことを求め、車両の型式ごとに適合を示させます。UN R156は同じ考え方をソフトウェア更新に当てはめ、「ソフトウェア更新管理システム（SUMS）」を求めます。国内では、これらが道路運送車両の保安基準に取り込まれ、対象となる車両の範囲が順次広がってきました*1*2。

いっぽうISO/SAE 21434は、法規が求める体制を開発の工程として具体化した国際規格です。企画から設計、検証、生産、運用、廃棄までの各段面で何を行うのかを定めており、脅威分析とリスク評価（TARA）を軸に、要件へ落とし込んで検証していく流れが示されています。法規が「持っていることを示せ」と言い、規格が「こう回せばよい」と示す——この対応で捉えると混乱しません。

もう一点、機能安全（ISO 26262）との関係も押さえておきましょう。機能安全は故障や誤動作から人を守る規律、サイバーセキュリティは悪意ある行為から守る規律です。両者は別ですが、同じ電子制御装置に対して同時に適用され、成果物の作り方や検証の考え方には共通点があります。片方の運用があるなら、その型を流用できる部分は少なくありません。

CSMSとSUMS——組織として何を持つのか

法規が求めるのは、個別の対策の羅列ではなく、組織として回る仕組みです。おおまかには次のような要素で構成されます。

ここで実務上の要になるのが、供給網の中での責任分担です。車両メーカーは自社の体制だけでなく、部品やソフトウェアの供給元が要求を満たしていることも示さなければなりません。したがって受託側には、「うちの範囲ではこれを行い、この記録を残しています」と提示できる状態が求められます。契約時に成果物の一覧として合意しておくと、後の摩擦が減ります。

ソフトウェア更新の側では、配信の仕組みそのものが評価対象に入ります。更新をどう識別し、影響をどう評価し、車両に適用された結果をどう記録するか。スマートフォンアプリの更新配信と考え方は近い部分もあり、OTA更新の仕組みで扱っている配信と戻しの設計は、考え方として参考になります。

TARA——脅威分析とリスク評価をどう進めるか

ISO/SAE 21434の中核にあるのが、脅威分析とリスク評価（TARA）です。手順としては、守るべき資産を洗い出し、それに対する脅威の道筋を描き、影響と実現の容易さからリスクを見積もり、対応方針を決めていきます。文章にすると単純ですが、実務では最初の一歩でつまずくことが多いところです。

つまずきの原因は、資産の粒度が定まらないことにあります。「車両」では粗すぎ、「この変数」では細かすぎる。実際には、機能とデータの単位（例：ドアの施解錠、走行データの送信、鍵の保管領域）で並べると扱いやすくなります。この一覧が固まれば、脅威の洗い出しは進みます。

もう一つの勘どころが、リスクの評価基準を先に決めておくことです。影響の大きさをどう区分するか、実現の容易さをどう測るか。ここを案件ごとに場当たりで決めると、社内でも取引先とも議論が噛み合いません。基準を文書として持ち、プロジェクトをまたいで使い回す形にしておきたいところです。

そして、TARAは一度作って終わりではありません。設計が変わればやり直しになり、運用中に新たな脆弱性が見つかれば見直しが必要になります。「更新される文書」として扱い、変更履歴を残せる置き場所に置いておくことが、後の説明を楽にします。

実装で問われること——ログ・鍵・通信・更新

要件に落ちたあとの実装では、次のような論点が並びます。組込み側とクラウド側の両方に関わるため、境界の設計が重要になります。

• 起動と署名：正しいソフトウェアだけが動く仕組み（セキュアブート、署名の検証）
• 鍵の扱い：鍵をどこに置き、どう配布し、漏えい時にどう入れ替えるか
• 通信の保護：車内ネットワークと外部通信の分離、認証と暗号化
• 検知と記録：異常の検知と、後から追えるログ。車両側の保存容量とクラウド側への転送の設計
• 更新の配信：段階的な配信、失敗時の戻し、適用状況の把握
• 脆弱性の管理：使用しているソフトウェア部品の一覧と、新たな脆弱性が出たときの影響調査

とくに最後の点は、供給網の話と直結します。どの部品がどのバージョンで入っているのかを一覧として持っていなければ、脆弱性が公表されたときに影響範囲を答えられません。この考え方はIT側の議論と同じで、ソフトウェアサプライチェーン対策で扱っている部品表の整備が、そのまま効いてきます。

組込みとクラウドをまたぐ体制づくりでは、人材の確保が課題になりがちです。車載の知識とセキュリティの知識を併せ持つ人は限られており、育成にも時間がかかります。組込み・ファームウェア開発の委託のように外部の体制を組み合わせる選択肢も、現実的な打ち手として検討に入れておきたいところです。

国内での適用の広がりと、社内体制の作り方

国内では、これらの国際基準が保安基準に取り込まれる形で運用されています。当初は自動運転に関わる装置を備えた車両が対象でしたが、その後に対象が広げられ、より多くの車両が要求の範囲に入ってきました*1*2。したがって、いま関わっていない案件でも、次のモデルでは対象になるという前提で構えておくほうが現実的です。

社内体制としては、三つの役割を明確にしておくと動きやすくなります。ひとつは、脅威分析とリスク判断を担う役割。もうひとつは、要件を実装と検証に落とす役割。そして、記録を保持し、外部からの照会に答える役割です。小規模な組織では一人が兼ねることもありますが、少なくとも「誰がその判断をしたのか」が後から辿れる状態にしておく必要があります。

教育の位置づけも見落とせません。規格は、担当者が必要な知識を備えていることを求めます。外部の研修を受けた記録、社内での勉強会、実務でのレビュー——形式はさまざまですが、続けている証跡が残る仕組みにしておくと、監査での説明が容易になります。

なお、これらの体制づくりは供給網の上流から順に求められる傾向があります。二次・三次の取引先まで一気に整えるのは難しいため、まずは自社の担当範囲で成果物を用意し、再委託先には必要な項目だけを絞って依頼する——この段取りが現実的でしょう。

受託・委託開発で押さえる実務ポイント

受託側の視点では、次の四点を最初に固めておくと後が楽になります。

第一に、成果物の定義です。TARAの文書、要件の一覧、検証の記録、部品表、ログの仕様。これらのうちどこまでを自社が作るのかを、契約の段階で書き出します。「セキュリティ対応込み」という曖昧な合意は、後の解釈違いを招きます。

第二に、トレーサビリティの仕組みです。脅威から要件へ、要件から設計・実装へ、そして検証結果へ。この対応関係を追える形にしておくことが求められます。表計算ソフトで始めても構いませんが、変更が多い案件では管理ツールに載せたほうが破綻しません。

第三に、変更時の流れです。設計変更が起きたとき、脅威分析のどこを見直すのか、誰が判断するのか。この手順を決めておかないと、変更のたびに議論が振り出しに戻ります。

第四に、運用フェーズの取り決めです。量産後に脆弱性が公表された場合、影響調査を誰が行い、更新をどう出すのか。保守契約の範囲に含めるのか別枠にするのか。ここを決めておくと、いざというときに動けます。

これらは結局のところ、「決めたことを、追える形で残す」という一点に集約されます。IoT機器の分野でも同じ流れが進んでおり、IoT領域の開発体制と共通する備えとして捉えると、投資の説明もしやすくなるはずです。

まとめ：車載セキュリティ対応で押さえる3つの視点

車載サイバーセキュリティは、法規と規格と実装の三層で捉えると全体像がつかめます。押さえたい視点は三つです。第一に、UN R155・R156が組織としての管理体制（CSMS・SUMS）を求め、ISO/SAE 21434がそれを開発工程としてどう回すかを示すという役割分担があること。第二に、国内では保安基準に取り込まれ、対象となる車両の範囲が段階的に広がってきたため、供給網の中で自社が示すべき範囲を明確にする必要があること。第三に、受託・委託開発では、脅威分析の成果物、要件と検証の対応、部品表、更新の配信と記録を「追える形で残す」ことが実務の要になることです。まずは成果物の定義とトレーサビリティの仕組みを契約段階で固めるところから始めてみてください。

よくある質問

出典

1. *1　参考：国土交通省「報道発表：自動運転技術に関する国際基準等を導入します（保安基準等の一部改正）」（https://www.mlit.go.jp/report/press/jidosha10_hh_000242.html）。サイバーセキュリティ（第155号）・プログラム等改変システム（第156号）の国内基準への導入の参考として（2026年8月確認）
2. *2　参考：国土交通省 車両安全対策検討会「サイバーセキュリティについて（UN-R155関係）」（https://www.mlit.go.jp/jidosha/content/001842954.pdf）。適用範囲と国内での取り扱いに関する公的資料の参考として（2026年8月確認）

Tweet