ISO/SAE 21434（自動車サイバーセキュリティ）とは
コネクテッド化・OTA・ECU高機能化により、自動車はサイバー攻撃の対象になり、開発から市場運用まで一貫した管理が求められるようになりました。
ISO/SAE 21434は、自動車の電気／電子（E/E）システムに対するサイバーセキュリティを、組織・プロジェクト・製品ライフサイクルの観点で体系化した国際規格です。
本記事では、規格が求められる背景（UN-R155／156との関係）、適用範囲、全体構成、実務での進め方までを見出しに沿って整理します。
車載ソフトウェア開発のお問い合わせはこちら
AUTOSAR・機能安全から車載Android、SDV、サイバーセキュリティまで車載ソフトウェア開発を一貫して支援
目次
ISO/SAE 21434が求められる背景
車両がネットワークにつながりソフトウェアで価値が決まる時代、製品単体の対策だけではなく、開発・運用を通じた“仕組み”としてのセキュリティが必要になりました。
従来の自動車は外部と切り離された前提が強く、セキュリティ対策も「侵入されにくい構造にする」など設計面の工夫が中心でした。しかし現在は、スマートフォン連携、クラウド連携、V2X、リモート診断、OTA更新など、外部接点が増え続けています。接点が増えるほど攻撃経路も増え、完成後に発覚する脆弱性が安全性やリコールに直結します。
そのため求められるのは、個別の技術対策だけでなく、どのタイミングで何を判断し、誰が承認し、どの証拠を残すのかという開発運用の管理です。ISO/SAE 21434は、サイバーセキュリティを品質や安全と同じく、計画・実施・評価・改善のサイクルで回す考え方を提供します。
また、自動車は単独の製品ではなくサプライチェーンで作られます。自社で完結する対策には限界があり、要求の分配、変更管理、受け入れ評価、脆弱性情報の共有まで含めて統一したやり方がないと、最終的な説明責任を果たせません。規格が重視するのは、まさにこの説明可能なプロセスと成果物です。
法規制との関係：UN-R155（CSMS）とUN-R156（SUMS）
ISO/SAE 21434は規格（標準）ですが、各国で適用が進むUN-R155／156の法規制対応を進める上で、実務上の拠り所として位置づけられます。
UN-R155は車両のサイバーセキュリティに関する法規で、メーカーに対してCSMS（Cyber Security Management System）を構築し、さらに車両型式としての対策が適切であることを示すことを求めます。つまり、現場でやったと言い切るだけでは不十分で、当局や第三者に対して「仕組みが回っている」「車両が要求を満たす」ことを証拠で説明できる必要があります。
ISO/SAE 21434は法規そのものではありませんが、CSMSや車両開発で行うべき活動と成果物を体系化しているため、UN-R155対応を設計する際の実務標準として使われます。特に監査・レビュー、役割責任、TARA、サプライヤー管理、リリース判断の根拠作りは、規格に沿って整備すると説明が通りやすくなります。
UN-R156はSUMS（Software Update Management System）を中心に、ソフトウェア更新を安全に運用するための法規です。ISO/SAE 21434はソフトウェア更新そのものの管理体系を主目的にはしませんが、更新によって新たな脆弱性が入る、鍵や署名の運用が必要になる、変更時のリスク評価が要るといった点で密接に関係します。実務では、21434でサイバーの要求を作り、156で更新運用の仕組みに落とすイメージで併走させると整合しやすいです。
車載ソフトウェア開発の詳細はこちら
当社の強みから開発実績までをご紹介
ISO/SAE 21434の目的と適用範囲
規格の狙いは、車両のE/Eシステムについて、コンセプトから廃棄までのサイバーセキュリティ活動を一貫して管理できる状態を実現することです。
ISO/SAE 21434の目的は、サイバー攻撃の脅威を前提にしつつ、車両のE/Eシステムが許容できるリスクに収まるよう、ライフサイクル全体で活動を定義し、成果物として残すことにあります。重要なのは「絶対に攻撃されない」ではなく、想定する脅威・影響・対策の妥当性を説明でき、変更や新情報にも追従できる状態を作る点です。
適用範囲は主に車両側のE/Eシステム（ECU、車内ネットワーク、車載ソフトウェア、診断・更新の仕組みなど）です。一方で、UN-R155の文脈では車両と通信するバックエンドや運用体制も含めて評価されることがあります。車両外の領域は、ISMS（ISO/IEC 27001など）や製品セキュリティ運用の枠組みで補完し、境界と責任を明確にするのが現実的です。
また、規格は組織にもプロジェクトにも要求を置きます。開発部門だけで完結する話ではなく、品質、調達、法規、IT、カスタマーサービスなどを含めて、設計から市場対応までの流れを成立させることが求められます。
対象となるシステムとサプライチェーン（OEM・Tier）
規格で扱う「アイテム」は、車両に搭載されるE/Eシステムを一定のまとまりとして定義した対象です。例えば、ブレーキECU単体ではなく、センサーからECU、通信、アクチュエーターまで含む機能システムとして捉えることもあります。境界を曖昧にすると脅威分析や責任分界が崩れるため、外部インターフェース、前提条件、依存関係まで含めてアイテム定義を明確にします。
サプライチェーンでは、OEMが最終責任を負う一方、実装はTier1／2など複数社に分かれます。このとき重要なのは、サイバーセキュリティ要求を上流から下流へ分配し、各社の成果物を統合して説明できる状態にすることです。要求は「暗号を使う」といった抽象ではなく、鍵の管理方法、診断アクセスの条件、ログの要件、更新の認証方式など、検証可能な形で分解される必要があります。
責任分界も同様に、どこまでがサプライヤーの設計責任で、どこからがOEMの統合・運用責任かを契約と技術文書で揃えることが肝心です。UN-R155の流れでは、OEMがサプライヤーの体制や成果物を評価・監査することが事実上求められるため、サプライヤー側もCSMS相当の仕組みや説明資料の整備が避けられません。
また、車両外のバックエンドやスマートフォンアプリなどは攻撃経路として重要ですが、ISO/SAE 21434の主対象は車両側に寄っています。実務では、車両外の領域は別の規格や社内セキュリティ基準で管理しつつ、インターフェース（認証、API、証明書、運用手順）の部分を21434の成果物と接続して、一つのリスク説明にまとめることが現場での最適解になりやすいです。
ISO/SAE 21434の全体構成
ISO/SAE 21434は、組織マネジメント、プロジェクトでの活動、開発後の継続活動までをカバーする章立てになっており、全体像を先に把握すると実装が進めやすくなります。
規格は、組織としてのマネジメント要求と、開発プロジェクトでのエンジニアリング要求、そして生産・運用を含む継続活動に分かれます。最初に全体を俯瞰すると、どの成果物がどの判断に使われるのかが見え、形式的な文書作りを避けられます。
実装の流れとしては、組織のルールと責任を整え、プロジェクト計画に活動を織り込み、コンセプトでTARAとセキュリティコンセプトを作り、開発で要求を分配して実装・検証し、リリース判断の根拠をまとめ、発売後は監視と対応を回す、という一本の線で理解するとよいです。
規格が強く求めるのはトレーサビリティです。脅威とリスク評価から導いたゴールや要求が、設計・実装・テスト・受け入れ判断までつながっていること、さらに市場で新たな脆弱性が見つかった際に影響範囲を特定できることが、監査や当局説明で効いてきます。
車載ソフトウェア開発のお問い合わせはこちら
AUTOSAR・機能安全から車載Android、SDV、サイバーセキュリティまで車載ソフトウェア開発を一貫して支援
組織レベル：サイバーセキュリティマネジメント（CSMS）
まず必要になるのが、ルール・体制・監査を含む組織的なサイバーセキュリティマネジメントで、UN-R155のCSMS要求とも強く結びつきます。
CSMSは、個々のプロジェクトを超えて全社で一貫した判断を可能にする土台です。例えば、脅威の受け止め方、リスク受容の基準、サプライヤー評価の観点、暗号や鍵管理の標準、脆弱性情報の扱いなどが部門ごとにバラバラだと、統合時に矛盾が起きます。CSMSはそのバラつきを抑え、説明可能な標準手順に落とします。
また、CSMSは「作って終わり」ではなく、監査やマネジメントレビューで有効性を確認し、改善する仕組みが必要です。実務上は、監査に耐えるかどうかよりも、事故や緊急対応時に迷わず動けるかが本質です。誰が意思決定し、どの情報を根拠にし、どの連絡経路で社外へ出すのかまで決めておくことが、被害の拡大を防ぎます。
UN-R155の観点では、OEMは当局に対してCSMSの適合性を示す必要があり、サプライヤーにも同等の管理水準を求める流れになります。従って、サプライヤー管理をCSMSの中核に置き、要求提示、評価、是正、再評価のループを仕組みとして回すことが重要です。
役割・責任・能力（教育・体制）
明確にすべきはガバナンスです。最終責任者、承認経路、例外判断の基準、重大インシデント時の指揮系統を定義し、開発現場の裁量だけに依存しない構造にします。セキュリティは品質と同じくトレードオフ判断が発生するため、誰がリスクを受容する権限を持つかを曖昧にしないことが肝心です。
次にリソース確保と力量管理です。TARAや脆弱性分析は専門性が高く、形式だけ回すと過小評価や見落としが起きます。教育は座学だけでなく、実際の成果物レビューや演習で判断の質を揃えることが重要です。特に、開発者がセキュア設計原則を理解し、テスト担当が攻撃観点の検証を組み込める状態にする必要があります。
部門横断の連携も欠かせません。開発だけでなく、品質が監査の仕組みを持ち、調達がサプライヤー要求に落とし込み、法規が規制要求を解釈し、ITや運用が鍵・証明書・ログの基盤を支える、といった分担が必要です。どこかが欠けると、車両外との接点や市場対応で破綻します。
最後に監査・レビューの設計です。監査は書類点検に偏ると形骸化します。プロジェクトの節目で、リスク受容の妥当性、要求の分配漏れ、サプライヤー成果物の品質、テストの網羅性など、失敗しやすいポイントに焦点を当てたレビューを組み込み、是正が回る形にすると実効性が上がります。
車載ソフトウェア開発の詳細はこちら
当社の強みから開発実績までをご紹介
開発プロジェクトレベル：サイバーセキュリティ活動の進め方
プロジェクトでは、計画（プラン）にサイバーセキュリティ活動を組み込み、成果物を積み上げて最終的にリリース可否を判断できる状態にします。
プロジェクトでは、サイバーセキュリティを追加作業にせず、V字開発やアジャイルなど既存の開発プロセスに織り込むことが現実的です。具体的には、いつTARAを更新するか、設計レビューで何を確認するか、テストでどこまで攻撃観点を入れるか、リリース前にどんなアセスメントを行うかを計画に明記します。
重要なのは、成果物が判断に使えることです。例えばTARAがあっても、要求に落ちていなければ実装に反映されません。要求があっても、検証がなければ適合を説明できません。規格の要求は多く見えますが、実務ではトレーサビリティの鎖を切らさないことが最短ルートになります。
また、プロジェクトの途中で脅威環境は変わります。新しい攻撃手法、使用するOSSの脆弱性、サプライヤー変更などが起きたときに、影響評価と意思決定をやり直せるよう、変更管理と構成管理をセキュリティ視点で強化する必要があります。
コンセプトフェーズ：TARAとサイバーセキュリティコンセプト
コンセプトフェーズは、後工程の品質を決める最重要ポイントです。流れは、アイテム定義で対象と境界を決め、TARA（脅威分析・リスク評価）でリスクを定量・定性評価し、対応方針を決め、サイバーセキュリティゴールやクレームとして言語化し、検証可能な要求に落とし込む、となります。
TARAでは、資産（守るべきもの）を明確にし、攻撃経路（どこからどう入るか）と脅威シナリオ（何が起きるか）を具体化します。ここでの落とし穴は、技術視点だけで脅威を書くことです。実際には、影響（安全・法規・プライバシー・事業継続）を含めてリスクを捉え、どの影響をどの根拠で許容するかまで決める必要があります。
リスク対応は、低減だけでなく、共有・回避・保持も選択肢です。例えば、運用で補えるものを設計に過剰実装するとコストや複雑性が増え、別の脆弱性を生むことがあります。逆に保持するなら、なぜ許容できるのか、検出や回復の手段があるのかをクレームとして説明できなければなりません。
最後に、ゴールや要求はトレーサブルであることが必須です。どの脅威シナリオをどの要求で抑え、どのテストやレビューで証明するのかまでつなげておくと、後工程の手戻りが大きく減ります。
製品開発フェーズ：要件定義・設計・実装・検証
製品開発フェーズでは、コンセプトで定めたサイバーセキュリティ要求を、システム、ハードウェア、ソフトウェア、製造、運用などの担当へ分配し、矛盾なく実装します。ここで重要なのは、要求を「セキュアにする」ではなく、「何を満たせば合格か」が判断できる形にすることです。
設計では、攻撃面を減らし、侵害されても被害を限定する考え方が中心になります。代表例として、最小権限、権限分離、通信の認証と暗号化、セキュアブート、鍵の保護、デバッグインターフェースの制御、異常検知とログなどがあります。ただし、機能安全や性能、コストとのトレードオフが必ず出るため、TARAで決めたリスクの優先度に沿って設計判断を行うのが筋です。
実装・検証では、脆弱性分析と評価を工程に合わせて使い分けます。設計段階のレビューやモデル分析、実装段階の静的解析、依存ライブラリの脆弱性スキャン、統合段階の侵入テストやファジングなどを組み合わせ、どの脅威に対してどの証拠で抑えたかを残します。
証跡化は監査のためだけではなく、リリース後の変更時に効きます。要求、設計、テスト結果、例外判断の根拠が揃っていれば、脆弱性が出たときに影響範囲と対応優先度を素早く判断できます。これが結果として市場リスクを最小化します。
生産・運用・保守・廃棄：ライフサイクルでの管理
生産移行では、開発段階で安全でも、製造工程で崩れるリスクがあります。例えば、製造時の書き込み手順、診断ツールのアクセス制御、工場ネットワーク、鍵や証明書の生成・配布・保管などは、攻撃者にとって魅力的な標的です。製造委託や物流を含め、サプライチェーンリスクとして管理項目に落とし込む必要があります。
市場運用では、変更管理が中心になります。OTAやサービスでソフトウェアが変われば攻撃面も変わるため、変更のたびに影響分析を行い、必要に応じてTARAや要求、テストを更新します。運用の現場ではスピードが求められる一方、拙速な更新は事故を誘発するため、判断基準と承認フローをあらかじめ整えることが重要です。
保守・修理では、サービス端末や診断アクセス、交換部品の真贋、初期化手順などが弱点になりやすいです。現場作業者の利便性を考慮しつつ、特権アクセスの管理や作業ログの確保、逸脱時の検知を設計に含めると運用負荷が下がります。
廃棄・リサイクルでも、車両内データや鍵が残れば攻撃に転用され得ます。個人情報や走行データの消去、鍵・証明書の無効化、再利用部品の扱いなど、最後まで管理対象として扱うことでライフサイクル全体の整合が取れます。
車載ソフトウェア開発の詳細はこちら
当社の強みから開発実績までをご紹介
開発後の継続活動：モニタリングとPSIRT/インシデント対応
リリース後は“終わり”ではなく、脆弱性情報の収集・評価・対処を継続し、攻撃や不具合が顕在化した際に迅速に対応できる体制が求められます。
開発後に必要なのは、脆弱性や攻撃兆候を見つけて、影響を評価し、対策を決めて展開する一連の流れです。車両は長期間使われるため、発売時点で安全でも、数年後に暗号技術が古くなる、OSSに重大な脆弱性が出る、攻撃手法が一般化する、といった変化が起きます。
PSIRT（Product Security Incident Response Team:インシデント対応チーム）は、情報収集の窓口と意思決定のハブになります。社内外から入る情報をトリアージし、再現と影響範囲を特定し、修正や暫定回避策、顧客対応、当局報告の必要性を判断します。特に自動車は安全影響の可能性があるため、品質・安全・法規と連携した判断が必須です。
モニタリングは単にニュースを見るだけでは不十分です。自社の部品表（SBOMなど）、ソフトウェア構成、鍵や証明書の有効性、車両側ログや診断情報と結び付けて、影響を素早く判定できる形にしておくと対応が現実的になります。結果として、リスクとコストの両方を抑えられます。
導入の進め方：ギャップ分析、テーラリング、文書化
規格要求は抽象度が高いため、自社の開発プロセスや組織規模に合わせて具体化し、監査・審査で説明できる形に整えることが成功の鍵です。
導入の第一歩はギャップ分析です。規格の要求を一覧化し、現状のプロセスや成果物がどこまで満たしているかを確認します。このとき、文書の有無だけで判断せず、「誰が」「いつ」「どんな基準で」判断しているかまで見ます。実態が伴わない文書は監査で弱く、緊急時にも役に立ちません。
次にテーラリングです。全要求を一律に重厚にすると、現場が回らず形骸化します。車種や機能のリスク、外部接点の多さ、更新頻度、サプライヤー構造に応じて、活動の深さと証拠の粒度を調整します。重要なのは省略ではなく、なぜそのやり方で十分なのかを説明できる基準を用意することです。
最後に文書化と証跡の設計です。ポイントは、成果物同士がつながり、レビューや承認の記録が残っていることです。TARA、セキュリティ要求、設計判断、テスト結果、例外判断、リリース可否の根拠、サプライヤー評価、PSIRTの運用手順が一貫していれば、監査対応だけでなく実務のスピードも上がります。
まとめ：ISO/SAE 21434対応で押さえる要点
法規制対応の観点でも、実装の観点でも、ISO/SAE 21434は“成果物を作ること”と“仕組みとして回すこと”の両輪が重要です。
ISO/SAE 21434の中核は、ライフサイクル全体でサイバーセキュリティを管理し、説明可能にすることです。コンセプトでTARAを行い、ゴールと要求を作り、開発で実装・検証して証拠を残す流れを、変更があっても崩れない形にします。
UN-R155/156の対応では、規格に沿ったCSMSやプロジェクト活動が実務の拠り所になります。特に、サプライチェーン全体で要求を分配し、評価・監査を回せるかが成否を分けます。
導入では、ギャップ分析で現状を正確に把握し、リスクに応じてテーラリングし、トレーサビリティを意識して文書と証跡を整えることが最短ルートです。最終的に目指すのは、監査のための形ではなく、リリース判断と市場対応を迷いなく行える運用です。
車載ソフトウェア開発のお問い合わせはこちら
AUTOSAR・機能安全、車載 Android、SDV、サイバーセキュリティまで車載ソフトウェア開発を一貫して支援