お知らせ

News

ご挨拶

コラムのお知らせ一覧です

Zephyr OSとは?特徴・利点・他のRTOSやLinuxとの違いを解説

IoTデバイスや組込みシステムの開発でRTOSを検討している方の中には、「Zephyr OS」が気になっている方も多いのではないでしょうか。Zephyr OSは、リアルタイム性能や限られたリソースでも動作する軽量さなどが特徴です。RTOSの選定は、開発後の保守性や移植性、製品寿命に直結するため重要事項となります。

この記事では、Zephyr OSの基本概要から特徴、利点、活用分野を整理し、他のRTOSやLinuxとの比較を通じて、選定の判断材料を解説します。

 

Zephyr OSの基本概要

Zephyr OSは、組み込み機器やIoT向けに設計された軽量RTOSです。小規模リソースしかなくても、必要機能を限定することでZephyr OSを組み込むことができます。ここでは、Zephyr OSの成り立ちと特徴、適用範囲などを解説します。

 

組込みシステム向けに設計されたオープンソースRTOS

Zephyr OSは、リソースが限られる機器で使うことを前提に設計されたオープンソースのRTOSです。(※)

小さなカーネル(OSの中核部分)を中心に、ドライバやネットワークなどを必要な分だけ選定して、構成できます。ライセンスはApache 2.0で、商用利用や改造がしやすい点が特徴です。(※)

Zephyr OSは、環境センサーやウェアラブル、組み込みコントローラなどで動作し、リアルタイム性と省リソース性を両立します。最小限から始めても、その後、要求に応じて機能を追加できるため、試作から量産まで一貫した開発がしやすいRTOSです。

※出典:

Wind River「Zephyrとは?

Zephyr Project「Zephyrプロジェクトコンポーネントのライセンス

 

The Linux Foundationによるプロジェクトの位置づけ

Zephyrプロジェクトは、世界的な非営利団体であるThe Linux Foundationが中立的に運営しており、Zephyr OSの開発や普及を担っているプロジェクトです。(※)

運営には多くの企業や技術者コミュニティが参加し、長期的に使い続けられるようにロードマップ(将来計画)が作られています。参加企業には「プラチナメンバー」や「シルバーメンバー」といった区分が設けられています。企業からの資金や技術の支援によって、製品やサービスが共存できるエコシステムが広がっている状況です。

こうした企業支援と、コミュニティの協力が両立していることで、Zephyr OSの導入企業は長期的に安定したサポートや情報を得やすくなります。結果として、製品の長期利用に必要な継続性と透明性を確保できる体制が整っています。

※出典:Zephyr Project「Zephyrプロジェクトについて

 

IoT・エッジデバイスにおける適用範囲

Zephyr OSは、小型のセンサーやビーコンのような超小型機器から、スマートウォッチや産業用コントローラまで、幅広い分野で利用されています。OSの中核部分であるカーネルが非常に軽量であるため、CPUやメモリの少ないマイコン(小型の制御用プロセッサ)でも、効率よく動作が可能です。

使いたい機能だけを選んで組み込めるため、電力やメモリに制約が厳しい機器でも扱いやすいのが特徴となります。また公式のサンプルコードやサポートが整備されているため、開発者は試作から量産までスムーズに進めることが可能です。

IoTやエッジ分野と呼ばれるネットワーク末端部分でのリアルタイム性、長期保守のしやすさが求められる場合などに、Zephyr OSは有効な選択肢となります。

 

Zephyr OSの主要な特徴

Zephyr OSは、軽量で柔軟に構成できるRTOSです。小型マイコンでも安定して動作し、複数CPUに対応する移植性も備えています。ここでは、3つの主要な特徴を解説します。

 

必要な機能を選択可能なモジュール構造

Zephyr OSは、機能を必要に応じて追加・削除できるモジュール方式を採用しています。開発者はKconfig(機能設定ツール)とDevicetree(ハード構成記述ファイル)を使って、最終的なプログラムに含める要素を取捨選択することが可能です。(※)

例えば、Bluetooth通信や特定のドライバを有効にする一方で、不要なファイルシステムは外すといった柔軟な構成ができます。その結果、コードのサイズや依存関係を抑えられ、メモリや電力に厳しいデバイスでも扱いやすくなります。試作から量産まで同じ開発基盤を活用でき、効率と保守性を両立できる点も魅力です。

※出典:Zephyr Project「Devicetree と Kconfig

 

小規模デバイスに適した軽量アーキテクチャ

Zephyr OSは、限られたリソースで効率的に動作するように設計されています。アプリケーションとカーネルを同じメモリ空間で動かせる構造を持ち、資源の割り当てをコンパイル時に固定することで処理の無駄を減らす方法です。この機能により、低消費電力のマイコンでもセンサー計測や無線通信などを安定して行えます。

また必要な機能だけを取り込む仕組みのため、更新時に影響が及ぶ範囲を限定しやすいのも特徴です。プロトタイプでは、最小限の構成にとどめ、量産時に必要な機能を段階的に追加するなど、開発プロセスに合わせて柔軟に拡張できます。

 

複数アーキテクチャをサポートする移植性

Zephyr OSは、ARM Cortex-M/A/R、Intel x86、RISC-V、ARC、Xtensaなど、幅広いCPUアーキテクチャを公式にサポートしています。(※)

共通のビルドシステムと抽象化されたドライバモデルを備えているため、異なるハードウェア間での移植作業にかかる工数を抑えることが可能です。例えば、評価ボードで開発したソフトウェアを将来別のSoC(システム・オン・チップ)へ移行する場合でも、基本構造を大きく変えずに対応できます。

この柔軟性により、製品ライフサイクルの長期運用に耐えられるだけでなく、新しいハードを積極的に採用する戦略にも適しているでしょう。

※出典:Nordic Semiconductor「Zephyrのご紹介

 

Zephyr OSの利点

Zephyr OSの利点は、製品導入を想定したセキュリティの強化、長期運用を可能にする体制、開発を効率化するツール群です。ここでは、それぞれの具体的な内容について解説します。

 

商用利用に対応したセキュリティ強化機能

Zephyr OSは、製品開発で必要となるセキュリティ基盤を備えています。脆弱性が見つかった際の報告方法や対応ルールを公開しており、透明性の高い運用が可能です。また開発者向けにセキュアコーディングの指針や、ソフトウェア強化の手法も提供しています。カーネルはMPU(メモリ保護機能)による安全対策が施され、スタック保護や制御フロー保護も選択可能です。

またZephyr OSは、高いセキュリティやメモリ保護機能を持つCPUアーキテクチャの「Armv8-M」と連携できます。その場合は、Armが提供するセキュリティ基盤ソフトウェアの「Trusted Firmware-M(TF-M)」と組み合わせる形です。(※)

TF-Mは、起動時の正当性確認、暗号処理、データ保護などを担っています。Zephyr OSと連携することで、機密情報を扱う処理を、安全に実行できる環境を構築可能です。この仕組みは第三者による監査やセキュリティ認証にもつなげやすいため、商用製品として長期運用するシステムに向いています。

※出典:Zephyr Project「Trusted Firmware-Mの概要

 

長期運用を支えるLTSとコミュニティサポート

Zephyr OSは、定期的なアップデートと長期サポート(LTS)で製品の長期運用を支えます。通常のリリースは「およそ4カ月ごと」に実施され、新機能や改善が継続的に追加される形です。(※)

LTSでは「2年以上」の修正提供が保証されており、安定した基盤を維持できます。(※)

LTSの更新状況は、GitHubで確認できるため、導入企業は安心して運用方針を立てることが可能です。またThe Linux Foundationには多くの企業が参加しており、近年はルネサスやWind Riverがプラチナメンバーに加わるなど、支援体制が強化されています。(※)

そのため、透明性と継続性を重視する長期製品にも対応しやすい環境が整っていると言えるでしょう。

※出典:

Zephyr Project「リリースプロセス

Zephyr Project「Zephyr Project Overview」(Page 40)

Zephyr Project「プラチナ Zephyr Project

 

開発効率を向上させるビルドシステムとツールチェーン

Zephyr OSには、開発を効率化する専用ツール群がそろっています。ソース取得、ビルド、書き込み、デバッグを一元管理する「west」や、設定を自動化する「Kconfig」などです。主なツールや仕組みを以下にまとめています。

ツール/仕組み 主な機能 利点
west ソース取得、ビルド、書き込み、デバッグを一元管理 作業工程をまとめられるため、開発の手間を削減可能
CMake ビルドシステムの管理 複雑なプロジェクトでも構成を自動化し、再現性を確保
Kconfig 機能設定の管理 必要な機能を選択して効率的に構成を調整可能
Devicetree ハードウェア構成の記録 制御基板やデバイスの情報を一元管理し、設定を簡潔に記述
Zephyr SDK 各CPUアーキテクチャ向けツールチェーンの提供 複数環境をまとめて扱えるため、移植性が向上
QEMU エミュレーション環境の提供 実機がなくても動作検証が可能
OpenOCD デバッグ支援ツール ハードウェアに接続して詳細なデバッグが可能

これらのツールや仕組みを活用することで、試作から量産まで一貫したフローを維持することができ、開発効率と品質を両立することが可能となります。

※出典:

Nordic Semiconductor「ビルド、フラッシュ、デバッグ

Zephyr Project「Zephyr SDK

Zephyr Project「入門ガイド

 

Zephyr OSの利用分野

Zephyr OSは、小型センサーからウェアラブル機器、産業機器まで幅広く対応します。ここでは、主に利用されている分野を紹介します。

 

IoTデバイスやセンサー制御への活用

Zephyr OSは、センサー制御を統一的に扱える仕組みを備えています。センサーAPIとサブシステムを利用すると、温湿度や照度などのデータを安全に取得可能です。設定はDevicetreeで記述でき、不要な機能を外すことでリソースを節約できます。Devicetreeとは、制御基板のハードウェア構成を記述するためのテキストファイルです。(※)

多数のサンプルコードが提供されているため、評価ボードを使った検証を始めやすい点も特徴となります。クラウドと連携する際にはLwM2Mクライアントを使用することで、一元管理や遠隔制御が可能です。

またZephyr OSは、省電力マイコンでも安定稼働できるため、環境モニタリングや状態監視システムの基盤としても適しています。

※出典:Qiita「Zephyr RTOS 〜 Devicetree 序章 〜

 

ウェアラブル端末やヘルスケア機器への応用

Zephyr OSは、Bluetooth Low Energy(BLE)の通信スタックを標準で備えています。BLEとは、省電力・低消費電力を重視した短距離無線通信技術のことです。(※)

BLEを利用することで、心拍や歩数などを継続的に計測し、スマートフォンへ効率的に送信できます。またGATTを利用した通信機能により、アプリケーションへのデータ反映もスムーズとなります。GATTとは「Generic Attribute Profile」の略で、BLE機器が持っているデータ構造と操作方法を定義したものです。(※)

また、Zephyr OSでは、BLEのアーキテクチャやAPIが整備されているため、開発者は容易に実装を進めることができます。実際に血圧計や活動量計などのヘルスケア機器での採用例も報告されています。(※)

低消費電力と安定した接続性を両立できるため、ウェアラブル端末や医療機器のように長時間使用する装置に適していると言えるでしょう。

※出典:

Google for Developers「Bluetooth Low Energy

TechWeb「GATTとは

Zephyr Project「心拍モニター(周辺機器)

 

産業機器やスマートホーム製品への導入

Zephyr OSは、工場やビルの管理システム、家庭用家電などの制御基盤としても活用されています。例えば、ビル内の防災、セキュリティ、照明、空調などのさまざまな設備機器の一元管理や、軽量な通信プロトコルであるLwM2Mを用いてクラウドと連携し、複数機器の状態監視、設定値の一括変更などの制御です。

また産業機器としては、評価ボードを使って早期検証を行い、製品用SoCへスムーズに移行する流れが取りやすいのも利点と言えるでしょう。SoCは「System on a Chip」の略で、CPUやグラフィック、無線通信、メモリなど、多数の機能を1枚の半導体に集積した回路です。

スマートホーム分野では、低消費電力と無線通信を組み合わせることで、利便性を高められます。公式の事例や技術資料が公開されているため、導入検討や設計の参考にしやすい環境が整っている状況です。

 

Zephyr OSと他のRTOSの比較

Zephyr OSは、ライセンス形態や開発体制、利用環境が他のRTOSとは異なります。ここでは、代表的なRTOSである「FreeRTOS」「Mbed OS」「ThreadX」との違いを解説します。

 

FreeRTOSとの相違点

RTOSは、用途や開発体制によって選択基準が変わります。特にZephyr OSとFreeRTOSは、多くの組み込み機器で検討対象となる代表的な存在です。両社はライセンスの仕組みやエコシステムの広がり、機能の構成方法に違いがあります。それぞれの特徴を下表にまとめました。

RTOS ライセンス 特徴
Zephyr OS Apache 2.0 The Linux Foundationのもとで開発。Kconfig、Devicetreeなどの機能やハード設定を分離・統合管理など、運用体制を整えやすい。
FreeRTOS MIT AWSや半導体メーカー主導で移植実績が豊富。小さなカーネルに必要なライブラリを組み合わせ、プロジェクト単位で軽量化しやすい。

Mbed OSとの相違点

Zephyr OSとMbed OSは、開発体制と将来の運用面で大きな違いがあります。Zephyr OSはThe Linux Foundationのもとで継続的に更新され、ボードやドキュメントも整備され続けている状況です。一方、Mbed OSはArmが推進していましたが、2026年7月にEOL(サポート終了)が発表され、今後の積極的な保守は期待できません。(※)

導入検討時には、標準化された管理方法を持つZephyr OSと、保守方針が変わるMbed OSの違いを理解しておくことが重要です。

RTOS サポート体制 特徴
Zephyr OS コミュニティ主導で継続更新。
ボードサポートやドキュメントを拡充中。
Kconfig、Devicetree、westを用いた標準化された構成管理方式を採用。
Mbed OS 2026年7月にEOL予定。公開は続くがArmによる積極的なサポートは終了。 HALやオンラインツールを軸に普及。今後は安定更新に限られる可能性あり。
※出典:ARM「Mbed OS EOL 発表

ThreadXなど商用RTOSとの相違点

Zephyr OSとThreadX(Azure RTOS)は、ライセンス条件と自由度の点で対照的です。Zephyr OSは、Apache 2.0ライセンスで提供され、自由に改編や再配布が可能となっています。(※)

一方、ThreadXは、ソースは公開されていますが、商用利用には制約がある状況です。

プレライセンス対象MCUであれば利用可能ですが、その他では別途契約が必要となります。導入時には、自社製品に使うMCUが対象かどうかを確認し、自由度を優先するかコストや契約条件の明確さを優先するかで判断が必要です。

RTOS ライセンス 特徴
Zephyr OS Apache 2.0 自由に利用・改変・再配布が可能。派生開発や独自拡張を設計に組み込みやすい。
ThreadX 条件付き商用ライセンス プレライセンス対象MCUなら利用可能。それ以外は追加契約が必要で、利用条件が事前に定められている。
※出典:Zephyr Project「Zephyrプロジェクトコンポーネントのライセンス

Zephyr OSとLinuxの比較

Zephyr OSとLinuxは設計思想が異なり、使われる場面にも違いがあります。ここでは、リアルタイム性、多機能性、要件定義を基準にした選定方法を解説します。

 

リアルタイム性能におけるZephyrの優位性

Zephyr OSは遅延を最小限に抑えるリアルタイム性能が強みで、制御装置や計測機器に適したRTOSです。主な特徴としては、次の内容になります。

  • 優先度ベースのスケジューラで安定したタスク制御
  • 軽量カーネルにより処理のばらつきを軽減
  • タイマーとクロックを統合し期限管理を容易化
  • KconfigやDevicetreeで静的に構成を定義
  • リアルタイム性が必須な分野で有効に機能

リアルタイム性が求められる現場では、処理の遅れが致命的な結果を招く場合があります。Zephyr OSは軽量カーネルとシンプルな設計により、応答の確実性を高める仕組みが特徴です。

また構成を静的に定義できるため、実行時の不安定要素を減らせる点も安心材料と言えるでしょう。こうした特徴から、Zephyr OSは産業用制御や医療機器など、安定したリアルタイム動作が必要な製品に適しています。

 

拡張性と多機能性におけるLinuxの強み

Linuxは多機能かつ拡張性に優れ、将来の機能追加や大規模システム開発に適したOSです。主な特徴は次の通りです。

  • 豊富なドライバとユーザー空間の資産を活用可能
  • ネットワークやセキュリティ機能を容易に統合
  • Yocto Projectで再現性の高いイメージを生成(※)
  • CI(継続的インテグレーション)との連携で開発から検証まで効率化(※)
  • PREEMPT_RTでリアルタイム性能を補強可能(※)

Linuxは多彩なドライバやライブラリを活用でき、ネットワークやセキュリティ機能を一体的に構築できます。またYocto Projectを利用すれば、再現性の高いOSイメージを生成でき、開発から量産までの効率化が可能です。

リアルタイム性が必要な場合は、PREEMPT_RTを導入して強化する選択肢もあります。多機能性や将来的な拡張を重視するプロジェクトでは、Linuxは強力な基盤として選ばれやすいOSです。

※出典:

Wind River「Yocto Projectについて理解しよう

Atlassian「継続的インテグレーションとは何ですか?

The Linux Foundation「リアルタイムプリエンプションの技術的詳細

 

要件定義に基づく適用範囲の判断基準

Zephyr OSとLinuxの選定では、性能やリソース制約を数値で明確化し、要件に基づいて適切なOSを判断することが重要です。それぞれのOSに適したケースを、下表にまとめています。

OS 適したケース
Zephyr OS ・ミリ秒単位の応答が必要
・軽量で省リソース設計
・制御系や小型機器向け
Linux ・多機能アプリケーションを統合
・将来的な拡張性重視
・ネットワークやセキュリティ機能を活用

RTOSであるZephyr OSは、遅延を最小限に抑えつつ軽量な構成ができるため、小規模デバイスや厳格なリアルタイム応答が求められる環境に向いています。

一方Linuxは、豊富な機能と拡張性を備え、大規模システムや多様なアプリケーションの統合に強みのある点が特徴です。導入前には同一条件で両者を比較し、サポート体制や外部リソースの入手性も含めて検討することで、長期運用に耐えられる最適な選択が可能となります。

 

Zephyr OSの将来性とエコシステム

Zephyr OSの将来性は、国際規格への対応、商用サポートの拡大、オープンソースコミュニティの活動によって支えられています。ここでは、それらの特徴について解説します。

 

国際規格およびセキュリティ認証への対応状況

Zephyr OSは、IoT向けのセキュリティ基準「PSA Certified Level 1」を取得し、PSA Functional API認証にも合格しています。(※)

またCVE(脆弱性識別番号)の公式機関として、脆弱性の受付を行い、透明性の高い手続きを実施している状況です。(※)

ArmのTrusted Firmware-M(TF-M)と連携することで、安全な暗号処理や実行環境を提供できるのも特徴の一つです。将来の安全認証取得に備えて、監査に対応可能な長期サポート版(LTS)の整備も進められており、製品開発に必要な環境を充実させています。(※)

※出典:

GlobalPlatform「PSA認定 Zephyrプロジェクト証明書

Zephyr Project「セキュリティとZephyr Project

Zephyr Project「リリースプロセス」(長期サポート(LTS))

 

企業による商用サポートの拡大

Zephyr OSの支援体制は、年々強化されています。2025年にはルネサスとWind RiverがZephyrプロジェクトのプラチナメンバーに加わり、エコシステム全体への投資が拡大傾向です。(※)

Wind Riverは日本語による開発・運用サポートを提供しており、要件定義から保守までを一貫して支援できます。またZephyrプロジェクトに参加している企業は、トレーニングやプロフェッショナルサービスを通じて、技術者の育成を後押ししている状況です。

そのため、Zephyr OS導入企業は、製品開発に必要なサポートを受けやすくなり、長期的な運用に向けた体制を築きやすいと言えるでしょう。

※出典:

Zephyr Project「プラチナ Zephyr Project

 

オープンソースコミュニティによる継続的な改善

Zephyr OSの開発は、活発なコミュニティによって継続的に進められています。リリースは約4カ月ごとに行われ、機能追加や改善が定期的に提供される状況です。(※)

また約2年ごとに長期サポート版(LTS)が公開され、製品用途に求められる安定性とセキュリティ更新が保証されています。(※)

リリースプロセスは文書化され、安定化の手順や公開履歴が誰でも確認可能です。このような透明性の高い開発体制により、企業は安心してZephyr OSを採用でき、長期製品にも適した選択肢となっています。

※出典:

Zephyr Project「リリースプロセス

Zephyr Project「Zephyr Project Overview」(Page 40)

 

まとめ

Zephyr OSを選ぶ際は、軽量性やセキュリティ機能、サポート体制などを整理し、Linuxなどの他の選択肢との違いを理解して検討することが重要です。

Zephyr OSは、小規模デバイスでも効率的に動作する軽量カーネルと、柔軟なモジュール構造を備えています。必要な機能だけを組み込み、消費電力やメモリ容量を抑えられるのが特徴です。そのため、IoT機器やセンサー制御のような、省リソース環境に適していると言えるでしょう。

またセキュリティ機能の充実や長期サポート(LTS)、企業コミュニティによる活発な開発活動が、長期利用における安定性を支えています。自社の製品要件や運用方針に沿った形で、OSを選ぶことが重要となります。

最後に

このコラムが、RTOSとLinuxの特長や扱い方を理解する助けになりましたら幸いです。
また弊社では無償で使える企業品質のRTOSであるZepherの開発・運用支援サービスを提供しておりますので、こちらも参考にしてください。

ウインドリバーのZephyr RTOS 開発・運用支援サービス


詳細資料をご希望の方には送付させていただきますので、以下フォームよりメールアドレスをご登録ください。

    メールアドレス(必須)

    <個人情報の取り扱い>

    ※上記内容は、弊社の掲げる個人情報保護方針に沿って管理し、本件に関するお問い合わせ、
    お申込み等いただいた内容への対応のために利用する場合がございます。
    お客様の同意なく目的外の利用や第三者への開示、提供することはございません。
    詳細につきましては、当サイトの「個人情報保護方針」をご参照ください。

    「個人情報保護方針」に同意し、送信する
    (必須)


    [2025年10月16日 時点]
    2025年10月16日

    RTOSとLinuxどちらを選ぶべき?性能・コスト・信頼性からわかる判断基準

    組込みやIoT開発で主に使用されているOSは「RTOS」と「Linux」です。RTOSは応答の確実性が求められる制御系に強みがあり、Linuxは豊富なライブラリや保守性に強みがあります。そのため「RTOS」か「Linux」か、どちらを選択すれば良いのか迷うことも多いでしょう。

    この記事では、RTOSとLinuxの違いや特徴を整理し、開発目的や要件に応じて適切に選定するための基準について解説します。

     

    RTOSとLinuxの基本

    RTOSとLinuxは、組込みシステム開発でよく比較されるOSです。ここでは、それぞれの特徴を整理し、なぜ多くの分野で注目されているのかを解説します。

     

    RTOSの定義と特徴を整理

    RTOS(リアルタイムOS)とは、処理の遅れが許されないタスクを確実に実行するために設計されたOSです。多くのベンダーから製品が出ており、μITRONやT-Kernel、VxWorksなどがあります。(※)

    RTOSは、例えば自動車のブレーキ制御や医療機器のセンサー処理など、瞬時の反応が必要なシーンで利用されます。特徴としては以下のような点が挙げられるでしょう。

    • タスクの優先度を基準に処理を切り替える仕組み
    • 割り込み処理にすばやく応答できる性能
    • 最悪応答時間を見積もりやすい設計

    最悪応答時間(WCET: Worst Case Execution Time)とは、タスクが実行可能状態になってから、処理が完了するまでの最も遅い時間です。RTOSでは、この時間が保証されています。(※)

    これらの特徴により、RTOSは「常に決められたタイミングで動くこと」が求められる場面で、強みを発揮します。

    ※出典:

    IT用語辞典 e-Word「リアルタイムOS 【real-time operating system】 RTOS

     

    Linuxの定義と特徴を整理

    Linuxはオープンソースで開発されている汎用OSで、もともとはPC向けに作られました。しかし現在では、組込み分野でも広く使われている状況です。主な特徴は以下の通りです。

    • 豊富な機能やドライバがすでに揃っている
    • ネットワーク通信やファイルシステムなどが標準で利用可能
    • ソースコードを自由に変更できるためカスタマイズ性が高い

    これらの特徴により、機能の多い製品や複数の外部機器と接続するIoT機器、スマート家電などに適しています。またLinuxは、開発者やコミュニティによる継続的な改良が行われている点も、長期運用や将来の拡張を見据えるうえで大きな強みです。

     

    組込みOSとして両者が注目される理由

    RTOSとLinuxは、どちらも注目されています。これは用途によって、それぞれの強みが異なるためです。

    OS 強み 主な利用分野
    RTOS リアルタイム性、信頼性を重視する場面に強い 自動車(ブレーキ制御、エアバッグ)、医療機器(センサー処理)など
    Linux 機能の豊富さ、拡張性を重視する場面で有利 IoT機器、スマート家電(通信、GUI、ストレージ管理など)

    また、両方を組み合わせて、制御はRTOS、画面や通信はLinuxというように分担する「ハイブリッド構成」のシステムも存在しています。(※)

    ※出典:openEuler「Embedded SIG | Multi-OS Hybrid Deployment | Linux Server OS」(図1の下の説明部分)

     

    RTOSとLinuxの違いを整理

    RTOSとLinuxは、同じOSでも役割や得意分野が異なります。RTOSは「時間通りに処理する確実さ」を重視し、Linuxは「多機能性や拡張性」を重視している点です。ここでは、リアルタイム性、ハードウェア要件、開発環境という観点から、両者の違いを解説します。

    リアルタイム性と処理速度の違い

    RTOSは、処理のタイミングを正確に守れるように設計されており、Linuxは、平均処理速度が速く、多数のアプリケーションを並行して実行可能です。

    OS 特徴や用途
    RTOS 処理のタイミングを正確に守れるように設計されており、応答の遅れが許されない制御に適している。

    医療機器のセンサー制御や自動車のブレーキ制御など、数ミリ秒の遅れが命に関わるような場合に使用される。

    Linux 平均処理速度が速く、多数のアプリを並行して実行が可能。しかし負荷が高くなると応答にばらつきが出る場合も少なくない。
    スマート家電の画面表示や通信のように、多少の遅れが問題にならない用途ではLinuxが有利となる。

    遅延が致命的になる場面ではRTOSが適し、多少の遅れを許容できる場面ではLinuxが効果的です。目的に応じた選定が必要となります。

    リソース制御とハードウェア要件の違い

    RTOSは、軽量で数KBのメモリしかない小型マイコンでも動作可能です。Linuxは、多くのメモリや高性能なCPUを必要とし、豊富な機能が装備されているのが強みとなります。

    OS 特徴や用途
    RTOS 非常に軽量で、数KBのメモリしかない小型マイコンでも動作が可能。

    省電力やリソース制約の厳しいIoTセンサー、体や衣服など身体に装着して使用するウェアラブルデバイスで利用されている。

    Linux 多くのメモリや高性能なCPUが必要となる。
    ネットワーク、ファイルシステム、USBなどの豊富な機能を容易に利用できる。

    実際の開発現場では、センサー制御やモーター駆動などのリアルタイム処理はRTOSに任せ、画面表示やネットワーク通信はLinuxに任せる「ハイブリッド構成」も一般的となっています。

     

    開発環境とサポート体制の違い

    RTOSは、ベンダーが提供する開発環境を利用します。Linuxは、「Yocto Project」などの環境を活用することで容易に開発が可能となります。

    OS 特徴や用途
    RTOS ベンダーが提供するIDE(統合開発環境)やSDK(ソフトウェア開発キット)が充実しており、初期化コードや周辺ドライバを短期間で作り込むことが可能。立ち上げが早いのが魅力となる。
    Linux 「Yocto Project」を活用して、機器ごとにカスタムOSを構築できる点が特徴。Yocto Projectとは、非営利団体である「The Linux Foundation」傘下のオープンソースプロジェクトで、IoTデバイスや組み込み機器向けのカスタムLinuxを構築するための環境を提供している。(※)
    この仕組みを活用することで、製品ライフサイクルに合わせた更新や修正が容易になり、長期運用に強みが生まれる。

    RTOSの具体的な環境としては、Arm Cortex-M向けの開発環境であるNXPの「MCUXpresso」、STM32マイクロコントローラ向けの開発環境であるSTMicroelectronicsの「STM32CubeIDE」などがあります。(※)

    また、オープンソースのZephyr RTOSのように無料で導入できる選択も可能です。どのOSを選ぶかは、開発チームのスキルや製品の寿命、保守方針に応じて決めることが大切となります。

    ※出典:

    Wind River「Yocto Projectについて理解しよう

    NXP「MCUXpresso統合開発環境 (IDE)

    STMicroelectronics「STM32CubeIDE

     

    RTOSを選ぶべき場面

    RTOSは導入する場面を見極めることで、大きな力を発揮します。リアルタイム性、省リソース、省電力、安全規格対応といった観点から、その特徴を整理します。

     

    高いリアルタイム性が求められる

    RTOSは、処理の遅れが許されない用途に適しています。例えば、自動車のエアバッグ制御では、衝突から数ミリ秒以内に膨らませることが必要です。また心拍監視や産業ロボットの制御も、わずかな遅延が大きな事故につながるでしょう。RTOSは優先度制御や割り込み処理に強く、応答を一定に保ちやすい設計です。

    一方、Linuxは多機能ですが、処理が集中すると遅延が生じる可能性があるため、こうした分野ではRTOSが選ばれています。

     

    小規模メモリや低消費電力が重視される

    RTOSは必要な機能だけを搭載できるため、数十KBのメモリでも動作可能です。この特性は、IoTセンサーやウェアラブル機器のように、省電力設計が必須の機器に適しています。多くのRTOSはCPUをアイドル時にスリープさせる仕組みを持ち、消費電力を抑えてバッテリー駆動時間を大幅に伸ばすことが可能です。

    一方Linuxは多機能である反面、比較的メモリや電力を必要とするため、軽量デバイスには向きません。小型で長寿命が求められる機器では、RTOSが有利です。

     

    安全規格に準拠したシステムが必要な場合

    車載や医療分野では、「ISO 26262(自動車機能安全規格)」や「IEC 62304(医療機器ソフトウェア規格)」の準拠が必須です。(※)

    RTOSにはこれらの規格に対応した製品が多く、ASIL-Dといった自動車分野の安全規格である「ISO 26262」の最高レベルに対応可能な製品もあります。またRTOS製品であるQNXは、豊富な認証実績を持ち、ドキュメントやツールも充実している状況です。

    一方、Linuxでも安全対応の組み込みは進んでいますが、RTOSの方が長年の実績と専用サポート体制で一歩抜き出ています。

    ※出典:

    日本自動車研究所「機能安全(ISO26262)

     

    Linuxを選ぶべき場面

    Linuxは高機能なOSで、組み込み用途でも多く利用されています。ここでは、複雑な機能、豊富な資産、長期運用の観点からLinuxが適する場面を解説します。

     

    複雑な機能やマルチタスクが必要

    Linuxは同時に複数のアプリケーションを動かす「マルチタスク処理」に強みがあります。例えば、IoTゲートウェイや産業用制御装置では、ネットワーク通信、画像処理、音声認識といった異なる処理を一つのシステムに集約する必要があります。その場合、Linuxの「完全なマルチタスク」機能で、効率的にタスク配分が可能です。

    またユーザー空間とカーネル空間を分けて動作させる仕組みにより、システムが安定しながらも柔軟な拡張が可能となります。この特性により、機能が多岐にわたる複雑な製品でLinuxは大きな効果を発揮します。

     

    豊富なドライバやライブラリの活用

    Linuxは膨大なデバイスドライバを標準で備えているため、USBカメラや無線LANモジュール、各種ストレージなどを追加開発なしで利用できます。ネットワーク関連機器についても、幅広くドライバが公開されており、開発期間を短縮することが可能です。

    またThe Linux Foundationが提供する「The Linux Foundationのプロジェクト群」を利用すれば、機械学習や暗号化といった高度な分野でもオープンソースのライブラリを簡単に組み込めます。Linux Fundationのプロジェクト群とは、オープンソースや標準の発展を促進するために支援するプロジェクトです。(※)

    新しいハードウェアやサービスをすばやく製品に組み込みたい場合、Linuxの既存資産を活用することは大きなメリットとなります。結果として、開発効率の向上と市場投入までのスピードアップが期待できるでしょう。

    ※出典:The Linux Foundation「The Linux Foundationについて

     

    将来的な拡張性や保守性を優先

    Linuxはオープンソースであるため、世界中の開発者コミュニティによって継続的に改良や更新が行われています。製品を長期運用する際には、セキュリティ更新やバグ修正を受けられる点が大きな安心材料です。

    長期サポート版カーネル「LTS」や業界団体が提供する「LTSI」、CIPによる超長期サポート「SLTS」などの仕組みを活用すれば、数年以上にわたる安定運用が可能です。(※)

    また、Yocto Projectを利用すると、製品のライフサイクルに合わせたカスタマイズや再現性のある更新が実現できます。(※)

    これらによって、Linuxは拡張性と保守性の両面で信頼性の高い選択肢となるでしょう。

    ※出典:

    ThinkIT「Linuxカーネル「Linux 6.12」が長期サポート版に

    The Linux Foundation「LTSI 長期支援イニシアチブ

    Civil Infrastructure Platform「Linuxカーネルとコアパッケージ」(SLTS)

    Wind River「Yocto Projectについて理解しよう

     

    RTOSとLinuxのトレードオフを整理

    RTOSとLinuxは、どちらが優れているかではなく、用途に合うかどうかが重要です。ここでは、開発コストや性能、自由度、セキュリティなどの観点でそれぞれを解説します。

     

    開発コストと開発スピードのバランス

    開発にかかる時間や費用は、採用するOSによって大きく変わります。RTOSは短期間で開発を進めやすく、Linuxは工数や人件費がかさみやすい傾向です。

    OS 特徴
    RTOS 仕組みがシンプルで、必要な機能に絞って動かせるため、少人数のチームでも短期間で開発を進めやすい。初期費用を抑えやすく、製品を早く市場に投入したい場合に向いている。
    Linux 多機能で拡張性が高い反面、設定や検証の手間が増えるため、工数や人件費がかさみやすい。ただし「Yocto Project(※)」のような仕組みを使えば、ビルドや配布の作業を自動化でき、複雑な製品でも効率的に進められる。

    短期間での試作品や限定機能の製品なら、RTOSが有利ですが、多機能かつ長期的に改良を重ねる製品ならLinuxの方が結果的に効率的です。開発スピードとコストのバランスは、チームの規模や製品の将来像を踏まえて判断することが重要となります。

    ※出典:Wind River「Yocto Projectについて理解しよう

     

    性能・信頼性と自由度のバランス

    システムを長期間安定して動かすか、柔軟な拡張を優先するかによって、選ぶOSが変わります。RTOSは安定した動作が特徴で、Linuxは複雑な機能に適しています。

    OS 特徴
    RTOS 構造が軽量で優先度制御や割り込み処理がシンプルなため、処理時間のばらつきを最小限に抑えやすい仕組み。その結果、数年単位で稼働し続ける制御系機器でも、安定した応答を維持しやすいのが強みとなる。
    Linux ネットワーク通信や高度なアプリケーション処理を柔軟に追加できる自由度があり、複雑な機能統合に適している点が特徴。ただしドライバやモジュールの組み合わせによって、応答時間にばらつきが出る場合もあり、リアルタイム性に欠ける。

    安定した処理時間や長期稼働が必要ならRTOS、拡張性と多機能化を重視するならLinuxが適していると言えます。

     

    長期運用とセキュリティアップデートのバランス

    組み込み機器は10年以上使われることも珍しくなく、途中での更新や保守が重要なポイントとなります。RTOSはベンダーごとに異なり、Linuxは長期サポート体制が提供されています。

    OS 特徴
    RTOS システムが小規模で更新影響を把握しやすい反面、ベンダーごとにアップデートの配布や検証体制が異なり、開発者に負担がかかる場合がある。
    特に24時間稼働の装置では、更新時期や更新方法を事前に計画しておくことが必要となる。
    Linux 長期サポート版「LTS」が定期的に提供され、産業分野ではCIPによる超長期サポート「SLTS」が利用可能。(※)
    またYocto Projectを用いれば、更新の影響範囲を管理できる仕組みも整う。(※)

    ※出典:

    ThinkIT「Linuxカーネル「Linux 6.12」が長期サポート版に

    Civil Infrastructure Platform「Linuxカーネルとコアパッケージ」(SLTS)

    Yocto Project「4つのYoctoプロジェクトのコンセプト」(4.1 Yoctoプロジェクトのコンポーネント)

     

    RTOSとLinuxの選定時に考慮すべきリスクと対策

    RTOSやLinuxを選ぶ際は、性能やコストだけでなく運用で直面するリスクにも目を向ける必要があります。ここでは、障害対応、規格準拠、ツール活用の観点から対策を解説します。

     

    トラブル発生時のデバッグや障害対応の難易度

    組込みシステムでは、障害が発生すると原因の特定に時間がかかることが多く、OSごとに有効な対策が異なります。

    RTOSは、構造がシンプルなため挙動を追いやすい反面、ログ取得や解析機能が限られていることもある状況です。その場合に有効なのが「JTAGデバッガ」です。JTAGデバッガは、メモリやレジスタの動きを直接観察できるため、詳細な障害解析が可能となります。(※)

    一方、Linuxは多彩なログ機能やデバッグツールを備えており、障害発生時に詳細な情報を得られる強みがあります。ただし、ソースコードが膨大で依存関係も複雑なため、原因の切り分けに時間を要することも考えられるでしょう。

    そのため、開発段階から運用を見据えて、どのツールを使い、どのようにログを管理するかを明確に設計しておくことが重要です。障害対応の仕組みを前もって整えておけば、復旧を早められるだけでなく、システム停止による業務への影響も最小限に抑えることができます。

    ※出典:CQ出版「基板用 JTAGデバッガ

     

    規格準拠や認証取得にかかる負担

    自動車や医療機器、産業機械といった分野では、製品が必ず安全規格や法規制に適合している必要があります。

    RTOSは、システムが軽量で機能範囲が限定されるため、認証の対象範囲が絞られ、比較的スムーズに審査が進むことが多い状況です。

    一方、Linuxは機能が豊富で複雑なため、検証すべき範囲が広くなります。例えば、IEC61508(産業機械向け機能安全規格)やISO26262(自動車向け機能安全規格)といった国際規格への適合です。(※)

    規格に適合させるため、多くの工数と時間が必要になる可能性があります。

    また考えられるリスクとしては、開発の終盤になってから規格適合の不備が判明し、追加の修正や再検証でスケジュールが大きく遅れることです。そのようなことがないように、初期段階で規格要求を明確に洗い出し、OSの選定と同時に認証取得計画を立てることが必要となります。

    ※出典:

    日本自動車研究所「機能安全(ISO26262)

     

    ツールの活用でリスクを減らす方法

    OSの選択に関わらず、適切な開発ツールや共通システムであるエコシステムの考え方を取り入れることで、運用上のリスクを抑えられます。

    RTOSの場合、ベンダーが提供する統合開発環境(IDE)や自動コード生成ツールを利用すれば、初期設定やドライバ実装のミスを防ぐことが可能です。例えば、NXPの「MCUXpresso」やSTMicroelectronicsの「STM32CubeIDE」などの開発環境となります。(※)

    一方、LinuxではYocto Projectのようなビルドシステムを利用することで、複雑な構成管理やセキュリティ更新を効率的に実施することが可能です。ツールの選定を誤ると、障害対応やアップデートのたびに余計な工数が発生してしまう可能性があります。そのため、開発初期から利用可能なツールやサポートを調査し、運用を前提にした仕組みを整えておくことが、長期的なリスク低減につなげられます。

    ※出典:

    NXP「MCUXpresso統合開発環境 (IDE)

    STMicroelectronics「STM32CubeIDE

     

    よくあるRTOSとLinuxの選定失敗ケース

    RTOSとLinuxはどちらも強みがありますが、誤った選定をすると大きな手戻りやコスト増につながります。ここでは、起こりやすい失敗パターンを紹介し、判断時の注意点を解説します。

     

    RTOS選定で失敗するケース

    RTOSは軽量でリアルタイム性に優れているため、制御処理に適していますが、複雑な機能を統合する場面では限界があります。例えば、通信機能やクラウド連携、GUI表示、セキュリティ対策を追加する段階で、必要なドライバやライブラリが不足しやすく、結果として独自実装が増えることになるでしょう。このような状況では、開発コストや期間が大幅に膨らみ、想定以上の負担となることが少なくありません。

    Linuxに標準搭載されているネットワークスタックや豊富なライブラリを活用していれば、効率的に開発を進められる可能性が高いでしょう。多機能を前提とした製品や長期的に運用するシステムでは、RTOS単独ではなくLinuxを採用する判断が適切です。

     

    Linux選定で失敗するケース

    Linuxは多機能で拡張性に優れていますが、厳密なリアルタイム性が求められる場面では不向きです。負荷が集中した時に処理応答にばらつきが出やすく、最悪応答時間(処理が最も遅れる時間)を守ることは難しいでしょう。特にモーター制御や医療機器のように、わずかな遅れが事故や不具合につながる分野では、リスクが高いと言えます。

    本来であれば要件を数値化し、ツールで遅延の分布を評価するテストが必要です。リアルタイム性を軽視してLinuxを採用すると、設計の大きな見直しを迫られる典型的な失敗につながります。

     

    まとめ

    今回は、RTOSとLinuxの基本的な特徴や違い、活用しやすい場面、選定時に想定されるリスクと対策などを解説しました。RTOSはリアルタイム性や省リソース環境に適しており、Linuxは多機能性や拡張性、長期運用のしやすさに適しています。

    重要なのは、自分たちのプロジェクトに必要な要件を明確に定義し、それに最も適したOSを選ぶことです。特徴を理解したうえで判断すれば、開発の効率性と信頼性を高めることが可能となるでしょう。

    最後に

    このコラムが、RTOSとLinuxの特長や扱い方を理解する助けになりましたら幸いです。
    また弊社では無償で使える企業品質のRTOSであるZepherの開発・運用支援サービスを提供しておりますので、こちらも参考にしてください。

    ウインドリバーのZephyr RTOS 開発・運用支援サービス


    詳細資料をご希望の方には送付させていただきますので、以下フォームよりメールアドレスをご登録ください。

      メールアドレス(必須)

      <個人情報の取り扱い>

      ※上記内容は、弊社の掲げる個人情報保護方針に沿って管理し、本件に関するお問い合わせ、
      お申込み等いただいた内容への対応のために利用する場合がございます。
      お客様の同意なく目的外の利用や第三者への開示、提供することはございません。
      詳細につきましては、当サイトの「個人情報保護方針」をご参照ください。

      「個人情報保護方針」に同意し、送信する
      (必須)


      [2025年10月16日 時点]
      2025年10月16日

      NXP® MIMXRT1060-EVKCで始めるZephyr®と MCUbootによるセキュアブート

      NXP® MIMXRT1060-EVKCで始めるZephyr®とMCUbootによるセキュアブート

      セキュアブートとは

      セキュアブートは、機器の起動時に読み込むソフトウェアの 署名やハッシュを検証して正規のコードだけを実行する仕組み です。
      不正な改ざんやマルウェアの混入を防ぎ、システムを安全に立ち上げるための重要なセキュリティ機能です。

      Zephyrとは

      Zephyrは、Linux Foundationが主導する オープンソースのリアルタイムOS(RTOS) です。
      軽量で省リソースながら、Bluetooth®やWi-Fi®などの通信機能、セキュリティ機能、デバイスドライバを幅広くサポートしており、マイクロコントローラからIoT機器まで幅広い組込み開発に利用できます。

      MCUbootとは

      MCUbootは、マイクロコントローラ向けに開発された オープンソースのセキュアブートローダ です。
      アプリケーションの署名検証や暗号化をサポートし、ファームウェアの安全な更新やロールバック機能を提供することで、IoT機器や組込みシステムの信頼性とセキュリティを高めます。

      開発環境

      システム構成要素 詳細
      ホストOS Windows® 11
      ターゲットOS Zephyr v4.2.0
      ターゲットボード MIMXRT1060-EVKC

      ボード外観と接続

      画像上部のUSBケーブル : DEBUG ポートとPCを接続
      画像下部のUSBケーブル : USB OTG ポートとPCを接続

      環境構築

      パッケージマネージャを使ってホスト環境にいくつかの依存関係をインストール

      winget install Kitware.CMake Ninja-build.Ninja oss-winget.gperf python Git.Git oss-winget.dtc wget 7zip.7zip

      7zip.exeのパスを環境変数に設定してください。

      その他ツールをインストール

      1. TeraTerm のターミナルプログラムをインストール
      2. MCUXpresso IDE をインストール
      3. MCUXpresso Secure Provisioning Tool (以後、SECと記載)をインストール
        • NXP® のウェブサイト にアクセスし、Windows 用の SEC インストーラをダウンロードします。
        • MCUXpresso_Secure_Provisioning_<version>.exe インストーラをダブルクリックしてインストールを開始します。

      Zephyr MCUBoot デモを構築

      0) 事前準備

      コマンドプロンプトを起動して以下を実行してください。

      # 新しい仮想環境を作成する
      cd %HOMEPATH%
      python -m venv zephyrproject\.venv

      # 仮想環境を有効化する
      zephyrproject\.venv\Scripts\activate.bat

      # west をインストールする
      pip install west

      # Zephyr のソースコードを取得する
      west init zephyrproject
      cd zephyrproject
      west update

      # Zephyr CMake パッケージをエクスポートする
      west zephyr-export

      # west パッケージを使って Python® の依存関係をインストールする
      west packages pip --install

      # Zephyr SDK をインストールする
      west sdk install

      # mcumgr が未導入なら(Python venv でも可)
      pip install mcumgr

      # 署名鍵(ここでは RSA-2048)
      imgtool keygen -k bootloader\mcuboot\root-rsa-2048.pem -t rsa-2048

      1) MCUboot(ブートローダ)単体をビルド&書き込み

      MCUbootをビルド

      west build -p always -b mimxrt1060_evk/mimxrt1062/qspi -d build-mcuboot bootloader\mcuboot\boot\zephyr

      MCUbootのセキュアブート書き込み手順(SEC 使用)

      1. ターゲットをSerial Downloaderモードに切り替え
        • MIMXRT1060-EVK の ブートスイッチ を Serial Downloader (USB) に設定
        • USB (DEBUG USB) を PC に接続
        • デバイスマネージャで HID デバイス / COM ポートが認識されていることを確認
      2. SEC プロジェクトを作成
        • SEC を起動 → New Workspace を作成
        • 「Processor」は「MIMXRT1060」を選択
        • 「Boot」は「Authenticated(HAB)」を選択
      3. 鍵作成
        • 「PKI management」タブで「Generate Kyes」ボタンを押下して「Authentication keys」を作成
      4. ビルドイメージ作成
        • 「Source executable image」は、MCUbootのビルド結果が格納されているフォルダパスを設定
          • 例:「..\zephyrproject\build-mcuboot\zephyr\zephyr.elf」)
        • 「Authnetication key」は、「PKI management」タブで作成した鍵を任意で選択(例:SRK1:IMG1_1 + CSF1_1)
        • 「Build image」ボタンを押下してビルド実行
      5. イメージ書き込み
        • 「Write image」タブで「Write image」ボタンを押下して書き込みを実行
      6. ターゲットを通常ブートモードに切り替え
        • EVK のブートスイッチを FlexSPI NOR Boot に戻す
        • 再起動すると、MCUboot が起動し署名検証を実行 → 有効なアプリのみ起動
      7. 動作確認
        • シリアルターミナル(115200bps)で EVK をモニタ(以下のようなログが出ていれば動作しています)

      2) 警告(USB重複)を消す:オーバレイでどちらか無効化

      usbd@402e0000usbh@402e0000 が同アドレスで同時 enable だと DTS 警告が出ます。使わない方を無効化 してください。

      • 以下の場所に overlay ファイルを作成してください。
        • zephyrproject\bootloader\mcuboot\boot\zephyr\boards\mimxrt1060_evk.overlay
      • overlayに以下を書き込んでください。USBホスト を無効化しています。
      • &usbh { status = "disabled"; };

        (Host優先なら &usbd { status = "disabled"; };

      3) パーティションを確実に:pm_static.yml(推奨)

      Slot1 へアップロードできるように、QSPI(8MB想定)に mcuboot/slot0/slot1 を明示します。

      • プロジェクト直下に pm_static.yml ファイルを作成してください。
      • 例:zephyrproject\bootloader\mcuboot\boot\zephyr\pm_static.yml

      • pm_static.ymlに以下の内容を書き込んでください。

        # 例: MIMXRT1060-EVK の QSPI 8MB を想定
        mcuboot:
        address: 0x60000000
        size: 0x00080000 # 512KB

        slot0_partition:
        address: 0x60080000
        size: 0x00380000 # 3.5MB

        slot1_partition:
        address: 0x60400000
        size: 0x00380000 # 3.5MB

      4) v0.0.0 の SMP サンプル(mcumgrサーバ)をビルド&書き込み

      バージョンを付与して署名バイナリを生成します。

      west build -p always -b mimxrt1060_evk/mimxrt1062/qspi -d build-smp-svr-v0 zephyr\samples\subsys\mgmt\mcumgr\smp_svr -- ^
      -DOVERLAY_CONFIG=overlay-serial.conf ^
      -DCONFIG_MCUBOOT_SIGNATURE_KEY_FILE=\"bootloader/mcuboot/root-rsa-2048.pem\" ^
      -DCONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS=\"--version=0.0.0\"

      build-smp-svr-v0を実機に書き込みます。

      west flash -d build-smp-svr-v0

      5) mcumgr の接続を作成(UART)

      mcumgr-cliのインストール

      1. Go をインストール(未導入なら)
      2. 以下のURLからWindows 用 MSIをダウンロードして実行してください。

        https://go.dev/dl/

      1. mcumgr-cli をインストール(公式の Go CLI)
      2. go install github.com/apache/mynewt-mcumgr-cli/mcumgr@latest

      mcumgr 接続

      mcumgr conn add COMPORT type="serial" connstring="dev=COM3,baud=115200,mtu=512"

      • “dev=COM3”はデバイスマネージャーで「MCU-Link VCom Port」を確認することでポート番号がわかります。
        • 例:「MCU-Link VCom Port(COM3)」

      mcumgr 操作 (イメージリスト表示)

      mcumgr -c COMPORT image list

      結果

      Images:
      image=0 slot=0
      version: 0.0.0
      bootable: true
      flags: active confirmed
      hash: d62f08cd883eb7d31508bfe32be94df20a773a1cd27ed79cfc51254d333c43d7
      Split status: N/A (0)

      6) v1.0.0 をビルドして Slot1 にアップロード

      west build -p always -b mimxrt1060_evk/mimxrt1062/qspi -d build-smp-svr-v1 zephyr\samples\subsys\mgmt\mcumgr\smp_svr -- ^
      -DOVERLAY_CONFIG=overlay-serial.conf ^
      -DCONFIG_MCUBOOT_SIGNATURE_KEY_FILE=\"bootloader/mcuboot/root-rsa-2048.pem\" ^
      -DCONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS=\"--version=1.0.0\"

      アップロード&イメージリスト表示

      mcumgr -c COMPORT image upload -e build-smp-svr-v1\zephyr\zephyr.signed.bin
      mcumgr -c COMPORT image list

      結果

      Images:
      image=0 slot=0
      version: 0.0.0
      bootable: true
      flags: active confirmed
      hash: d62f08cd883eb7d31508bfe32be94df20a773a1cd27ed79cfc51254d333c43d7
      image=0 slot=1
      version: 1.0.0
      bootable: true
      flags:
      hash: 1193fbc56fd090c787a33b98de6ca3a72b9a36ff7f41048bad463c384ea2e10e
      Split status: N/A (0)

      7) 新イメージを試す → 確定する

      初期状態は以下を想定しています。

      Images:
      image=0 slot=0
      version: 0.0.0
      bootable: true
      flags: active confirmed
      hash: d62f08cd883eb7d31508bfe32be94df20a773a1cd27ed79cfc51254d333c43d7
      image=0 slot=1
      version: 1.0.0
      bootable: true
      flags:
      hash: 1193fbc56fd090c787a33b98de6ca3a72b9a36ff7f41048bad463c384ea2e10e
      Split status: N/A (0)

      • HASH0 = d62f08cd883eb7d31508bfe32be94df20a773a1cd27ed79cfc51254d333c43d7
      • HASH1 = 1193fbc56fd090c787a33b98de6ca3a72b9a36ff7f41048bad463c384ea2e10e

      次回リセットで v1.0.0 を試す

      mcumgr -c COMPORT image test <HASH1>

      コマンド実行後にリセットします。

      結果

      slot0とslot1が入れ替わっていることを確認します。

      Images:
      image=0 slot=0
      version: 1.0.0
      bootable: true
      flags: active
      hash: 1193fbc56fd090c787a33b98de6ca3a72b9a36ff7f41048bad463c384ea2e10e
      image=0 slot=1
      version: 0.0.0
      bootable: true
      flags: confirmed
      hash: d62f08cd883eb7d31508bfe32be94df20a773a1cd27ed79cfc51254d333c43d7
      Split status: N/A (0)

      端末が v1.0.0 で起動したら、永続化(ロールバック防止)

      mcumgr -c COMPORT image confirm <HASH1>

      • confirm しないで再起動すると、MCUboot は 0.0(slot0)へロールバックします。

      コマンド実行後にリセットします。

      結果

      Images:
      image=0 slot=0
      version: 1.0.0
      bootable: true
      flags: active confirmed
      hash: 1193fbc56fd090c787a33b98de6ca3a72b9a36ff7f41048bad463c384ea2e10e
      Split status: N/A (0)

      最後に

      以上になります。
      このコラムが、Zephyrの特長や扱い方を理解する助けになりましたら幸いです。
      また弊社ではZepher開発・運用支援サービスを提供しておりますので、こちらも参考にしてください。

      ウインドリバーのZephyr RTOS 開発・運用支援サービス


      詳細資料をご希望の方には送付させていただきますので、以下フォームよりメールアドレスをご登録ください。

        メールアドレス(必須)

        <個人情報の取り扱い>

        ※上記内容は、弊社の掲げる個人情報保護方針に沿って管理し、本件に関するお問い合わせ、
        お申込み等いただいた内容への対応のために利用する場合がございます。
        お客様の同意なく目的外の利用や第三者への開示、提供することはございません。
        詳細につきましては、当サイトの「個人情報保護方針」をご参照ください。

        「個人情報保護方針」に同意し、送信する
        (必須)


        NXP® は NXP Semiconductors N.V. の登録商標です。
        Zephyr® は The Linux Foundation の商標です。
        Windows® は米国およびその他の国における Microsoft Corporation の登録商標です。
        Python® は Python Software Foundation の登録商標です。
        Bluetooth® は Bluetooth SIG, Inc. の登録商標です。
        Wi-Fi® は Wi-Fi Alliance の登録商標です。


        [2025年10月07日 時点]
        2025年10月7日

        PSIRTの重要性に関して

        第36回 ものづくりワールド内の「ものづくりAI/IoT」出展のご案内

        第36回 ものづくりワールド内の「ものづくりAI/IoT」出展のご案内

        はじめに

        デジタル化が加速する中で、製品に対するサイバー攻撃のリスクは年々高まっています。

        IoT機器や組込みシステムも例外ではなく、開発者や製造業者はこれまで以上にセキュリティ対策への責任を問われる時代になりました。

        そんな中、近年注目されているのが「PSIRT(Product Security Incident Response Team)」です。

        本稿では、PSIRTの概要からその必要性、実際の立ち上げ方法、実際の業務範囲までを解説します。

        PSIRTとは何か?

        PSIRTとは、製品に関わるセキュリティインシデントに対応する専門チームのことを指します。

        これは企業内で発生する情報セキュリティ問題(例えば個人情報漏洩など)を扱うCSIRT(Computer Security Incident Response Team)とは異なり、製品やサービスにおける脆弱性、あるいは市場から報告されるセキュリティ上の課題に対して、迅速かつ適切に対応することを目的としています。

        なぜ今、PSIRTが必要なのか?

        近年では、テレビや冷蔵庫などの家電から工場内の機械やセンサーまでIoT機器は私たちの生活に欠かせないものとなっています。

        利便性向上が期待できる一方で、様々な情報がネットワークを介してやり取りされる中、欧州における「CRA(サイバーレジリエンス法)」や米国の大統領令、日本の「JC-STAR制度」など、製品セキュリティに対する要求は世界的に厳しさを増しています。

        これらの規制や指針は、製品ライフサイクル全体を通じてのセキュリティ確保を求めており、脆弱性が発覚した場合の対応体制が企業にあるかどうかも重要な評価ポイントとなります。

        PSIRTを備えていない企業は、インシデント発生時に組織内での対応が混乱し、顧客や市場への説明責任を果たせず、結果として信頼の喪失や法的リスクに直面する可能性があります。

        PSIRTの立ち上げに必要な要素

        PSIRTの立ち上げには、まず社内の意識づくりと経営層の理解・支援が不可欠です。

        次に、具体的な体制づくりとして以下の要素が必要となります。

        ・体制と役割の明確化

        製品開発部門、品質保証、法務、広報などの関係部署をまたぐ体制を作り、脆弱性の受領から評価、対応、顧客への開示までを担います。

        ・脆弱性報告の受け入れ窓口の設置

        外部研究者やユーザーから脆弱性情報を受け取るための、信頼できるチャネル(メールアドレス、専用フォーム等)を用意します。

        ・標準化された対応プロセスの整備

        報告受領→初期評価→影響分析→修正方針の策定→リリース・通知まで一連のフローを明文化し、対応の品質を均一化します。

        ・情報発信と透明性の確保

        脆弱性情報の開示方針(CVE採番、アドバイザリ公開など)や、ステークホルダーへの通知の仕組みを設けます。

        PSIRTの業務範囲

        PSIRT立ち上げ後、実際にどのような業務を行うか、PSIRTの主な業務を解説します。

        ・脆弱性管理

        自社製品の脆弱性に関する情報を収集、分析します。

        内部のセキュリティ担当者やオープンソースの脆弱性データベース、セキュリティコミュニティ、ベンダーから提供される情報などの情報源を活用し、収集した情報をもとに自社製品への影響を素早く評価することで、セキュリティインシデントに迅速に対応できます。

        ・セキュリティインシデントへの対応

        セキュリティインシデントとは、情報セキュリティに関する事故や外部からの攻撃などを表します。

        外部要因と内部要因が存在し、例えば、外部要因としては、マルウェアの感染や特定の組織を狙った標的型攻撃、不正アクセスなど、内部要因としては、従業員による機密情報のご送信や紛失、内部不正などが挙げられます。

        これらのセキュリティインシデントが発生した際、PSIRTは迅速かつ適切な対応が求められます。

        具体的な対応としては、インシデントの調査や原因の特定、速やかな修正パッチの開発・配布、顧客や関係機関への説明や情報提供、セキュリティ対策の立案などが挙げられます。

        発生したセキュリティインシデントの詳細を正確に把握し、適切に対応することで、被害の拡大を防ぎ、影響を最小限に抑える必要があります。

        ・各関係部署や部門との連携

        社内では、開発部門や法務部、広報部など各部署との連携により、セキュリティ対応の質を大幅に向上させることができ、効果的な情報共有や迅速な意思決定が可能になります。

        また、自社内だけでなく、サービス利用者やサプライチェーンとの連携も求められる場合があります。

        セキュリティツールのご紹介

        PSIRTに関連して、弊社アイティアクセスでご提供している各種ツールをご紹介します。

        • HERCULES SecSAM

        製品構成の分析とソフトウェア部品表(SBOM)の作成を通じて、プロジェクト(製品)のサードパーティ・コンポーネントの脆弱性及びライセンス問題を把握し、脆弱性への対応を行うOSS(Open Source Software) リスク管理システムです。

        また、問題追跡システムでCI/CD統合を行うことも可能です。

         PSIRTでの活用方法

        SBOMの作成自体は表計算ソフトやテキストファイルでも可能ですが、社内で必要となる脆弱性対策情報をすべて把握しようとすると件数は膨大となり、手作業での対応は現実的ではありません。そこで、専用ツールを導入して作業を自動化することで、より正確かつ効率的な対応が可能となります。

        • HERCULES SecDevice

        ネットワークに接続された製品の脆弱性スキャンとファズテスト(ソフトウェアやシステムに対して意図的に不正・異常な入力を与え、想定外の挙動や脆弱性を発見するテスト手法)を行うセキュリティ評価ツールです。

        シンプルな操作性とブラックボックステストの自動化により、製品のセキュリティテスト担当者の負担を軽減します。

         PSIRTでの活用方法

        IoT機器やネットワーク機器に対するファズテストを通じて、未知の脆弱性を高精度かつ短時間で検出し、脆弱性管理に役立ちます。また、発見された脆弱性に関する影響範囲や危険度に応じて、修正版の開発やパッチの適用など対応の優先順位を決定する際にも活用されます。

         

        製品概要については、弊社HPにも情報を掲載しております。併せてご確認ください。

        <製品概要の詳細はこちら>

        まとめ

        弊社アイティアクセスでは、第三者認証機関 DEKRA やテストラボ Onward Security などのセキュリティ関連パートナー企業の知見、さらに他社での取り組み事例も踏まえ、ご紹介したセキュリティツールに加えて PSIRTの体制構築支援 をはじめ、幅広いご相談に対応します。

        また、その後に必要となる各国のサイバーセキュリティ法規制への対応についても、ワンストップで支援します。

        製品セキュリティ対応は一部門だけの責任ではなく、組織全体で取り組むべき重要課題です。

        そして、PSIRTの設置はその最初の一歩となる極めて重要な取り組みです。

        これからの製品開発、そして各国セキュリティ法規制への対応に向け、PSIRTの構築をぜひご検討ください

        ※本文中に記載されている会社名、製品名等は会社の登録商標または商標です。

        2025年9月9日

        セキュアブートをUbuntuで使う方法|有効化と動作制限を解説

        LinuxベースのOSである「Ubuntu」で、セキュアブートを利用しようとすると、「起動しない」「ドライバが読み込めない」といった予期せぬ不具合に悩まされることがあります。

        セキュアブートとは、コンピュータの起動時に不正なソフトウェアの実行を防ぐ仕組みですが、Ubuntuとの相性や設定次第で思わぬ制限が生じることも少なくありません。

        この記事では、セキュアブートの基本、Ubuntuにおける対応状況、導入手順、有効化・無効化の方法、よくあるトラブルの対処法などを解説します。

         

        セキュアブートとは何か?

        セキュアブートは、コンピュータの起動時に信頼されたソフトウェアだけを動作させる仕組みです。ここでは、基本的な考え方などについて解説します。

         

        セキュアブートの基本概念

        セキュアブートは、OSの起動時に未承認のプログラムが実行されるのを防ぐセキュリティ機能です。具体的には、起動に関わるソフトウェアが「署名付き」であることを確認し、改ざんやマルウェアの侵入を防ぎます。

        例えば、カーネルやブートローダーに署名がなければ、起動処理そのものがブロックされる仕組みです。この機能により、ウイルスがOSの起動前に介入する「ブートキット攻撃」などのリスクを低減できます。

        セキュアブートは企業や公共機関におけるセキュリティ対策として導入されることが多いですが、近年は一般ユーザーのパソコンにも標準搭載されている状況です。

         

        UEFIとの関係性

        UEFI(Unified Extensible Firmware Interface)とは、コンピュータを起動する際にハードウェアを初期化したり、OSを起動したりする役割を担うファームウェアです。セキュアブートは、UEFIの中の機能の一つになります。

        セキュアブートは、UEFI内部の「キー管理機構」により、信頼されたソフトウェアの署名を検証することで、信頼性を確認します。例えば、Ubuntuではマイクロソフトが提供する「公的鍵」によって署名されたブートローダーが使われるため、UEFIのセキュアブート機能と互換性がある形です。

         

        従来のBIOSとの違い

        セキュアブートは、従来のBIOSでは実現できなかった安全な起動環境を可能にします。BIOSはソフトウェアの正当性を検証しないため、マルウェアがブートプロセスに侵入するリスクがあります。

        一方、UEFIにはセキュアブートがあるため、OSやドライバが署名付きであることが求められ、未署名の場合は起動段階でブロックされる仕組みです。そのため、UEFI対応パソコンでは、ブート時点でセキュリティを確保できます。

         

        Ubuntuにおけるセキュアブートの対応状況

        Ubuntuでは、セキュアブートの仕組みに対応した設計がされています。ここでは、公式サポートの状況、セキュアブート有効時における制限事項などについて解説します。

         

        公式サポートの有無と対象バージョン

        Ubuntuは、バージョン12.04以降からUEFIに対応しており、セキュアブートへの対応は、12.10以降です。(※)

        特にLTS(長期サポート)バージョンでは、公式にセキュアブート環境下での動作が保証されています。現在では、Ubuntu 18.04 LTS以降の主要バージョンで、署名済みブートローダー「Shim」やカーネルが提供されており、セキュアブート環境でもインストールと起動が可能です。(※)

        インストール時に自動で署名付きコンポーネントが導入されるため、ユーザーが特別な操作を行う必要はありません。

        ※出典:

        kledge「UEFI その2」(UEFIに対応しているUbuntuのバージョン)

        ubuntu「UbuntuDesktop」(共通インフラストラクチャ)

        ubuntuのセキュリティドキュメント「UEFIセキュアブート

         

        セキュアブートが有効な状態での動作制限

        Ubuntuでセキュアブートが有効になっている場合、一部のカーネルモジュールやドライバに制限がかかります。具体的には、未署名のカーネルモジュールはロードできません。そのため、外部デバイスのドライバや自作のカーネルモジュールを使用したい場合は注意が必要です。

        またNVIDIAの独自ドライバやVirtualBoxのカーネルモジュールなども、署名がないと読み込めないため、セキュアブートを一時的に無効化する必要があります。

        セキュアブートは、セキュリティを重視する環境では、制限が有効に働きますが、カスタマイズ性を求める場合は、ユーザーにとって不便さを感じることもある状況です。

         

        対応している署名付きカーネルとモジュール

        Ubuntuはセキュアブートに対応するため、起動に必要なブートローダーやLinuxカーネルに署名を付与しています。また、標準で提供されている主要なカーネルモジュールも署名済みです。

        例えば、Ubuntuの公式パッケージからインストールされるGPUドライバやネットワークドライバの多くは、セキュアブート環境でも動作するように署名されています。一方で、カーネルを自動で再ビルドするDKMS(Dynamic Kernel Module Support)では、手動で署名する作業が必要です。(※)

        ※出典:ubuntu「DKMS

         

        Ubuntuでセキュアブートを有効にする手順

        Ubuntuでセキュアブートを利用するには、UEFIの設定変更とインストール時の手順が必要です。ここでは、設定画面への入り方から、有効手順、インストール方法などを解説します。

         

        UEFI設定画面へのアクセス方法

        セキュアブートを有効にするには、パソコンの電源投入直後にUEFI設定画面を開く必要があります。多くの機種では、起動直後に「Delete」「F2」「F10」などのキーを押すとUEFI画面に入ることが可能です。メーカーによって操作キーが異なるため、事前に確認しておいてください。

        UEFI画面に入った後は、「Security」や「Boot」タブを開きます。セキュアブートに関する項目は「Secure Boot」や「Secure Boot Control」などの表示が一般的です。この設定を変更することで、Ubuntuのインストール時にセキュアブートを利用できます。

         

        セキュアブートの有効化と再起動手順

        UEFI設定画面に入った後は、次の手順を実施します。

         

        1. 1. 「Boot」または「Security」タブ内に移動する。
        2. 2. 「Secure Boot」オプションを「Enabule(有効)」に変更する。
        3. 3. 変更後、「Save and Exit(保存して終了)」を選ぶ。
        4. 4. パソコンが再起動する。

         

        再起動後は、UEFIにより署名付きのOSやブートローダーしか読み込めない状態になります。Ubuntuをすでにインストール済みの場合でも、「Shim」などの署名付きブートローダーが使われていれば問題なく起動可能です。

         

        セキュアブート対応のUbuntuインストール方法

        Ubuntuをセキュアブート対応でインストールするには、公式のISOイメージを使用し、USBメディアなどから起動するのが基本です。Ubuntu公式サイトで提供されているインストーラーは、「Shim」や「GRUB」などのブートローダーがマイクロソフトの鍵で署名されているため、UEFIのセキュアブートが有効でも問題なく動作します。

        インストール時には特別な設定は不要で、インストーラーが自動的に署名付きコンポーネントを使用してくれる仕組みです。UEFIモードで起動していれば、セキュアブートを有効にした状態でインストールが完了します。

        ※出典:Ubuntu「Ubuntuデスクトップをダウンロード

         

        セキュアブート有効時のドライバやソフトの制限

        セキュアブートを有効にした状態では、読み込めるドライバや実行できるソフトが制限されます。ここでは、未署名ドライバの制限、DKMS利用時の注意点、サードパーティ製ソフトの扱いについて解説します。

         

        未署名ドライバの読み込み制限

        セキュアブートが有効な環境では、未署名のカーネルドライバはロードされません。これは起動時に悪意のあるコードが読み込まれないように保護する仕組みの一環です。例えば、NVIDIAの公式ドライバやVirtualBoxのカーネルモジュールなど、未署名の状態ではインストールしても正しく動作しない場合があります。

        対処方法としては、セキュアブートを一時的に無効化するか、自分でドライバに署名を行う必要があります。一方で、署名つきドライバであれば、セキュアブート環境でも問題なく動作が可能です。

         

        DKMSモジュール利用時の注意点

        DKMS(Dynamic Kernel Module Support)は、カーネル更新時にドライバを自動で再構築してくれる仕組みです。しかしセキュアブート環境では、再構築されたモジュールに署名がないと読み込めません。

        例えば、NVIDIAやVirtualBoxのドライバをDKMSで利用する場合、自分で鍵ペアを作成し、署名作業を行う必要があります。

        Ubuntuでは、証明書登録・確認ツールである「mokutil」を使用して、カーネルモジュールに署名し、公開鍵をMOK(Machine Owner Key)として登録すれば、再起動後にセキュアブート環境でも使用可能です。(※)

        ※出典:Ubuntu「セキュアブート」(ドライバーの非自動署名を行うにはどうすればいいですか?)

         

        サードパーティ製ソフトのインストール可否

        セキュアブートの影響を受けるのは、主にカーネルレベルで動作するソフトウェアです。例えば、ブート時に読み込まれるドライバやカーネルモジュールになります。通常のアプリケーションは、制限を受けません。

        そのため、一般的なサードパーティ製ソフトは、セキュアブートが有効な状態でも問題なくインストールが可能です。ただし、ドライバを伴うソフト(例えばVPNなど)の場合は、セキュアブートの制限の対象になるため、事前に対応状況を確認しておく必要があります。

         

        Ubuntuでセキュアブートを無効にする方法

        セキュアブートは便利な一方で、特定のドライバやソフトを利用する際には制限がかかる場合もあります。ここでは、セキュアブートの無効化の手順、無効化によるリスクやメリットなどについて解説します。

         

        セキュアブートを無効にする手順

        セキュアブートを無効にするには、パソコンの電源を入れてすぐにUEFI設定画面を開きます。一般的には、起動時に「Delete」「F2」「F10」などのキーを押すことで、UEFI設定画面に入ることが可能です。UEFI設定画面に入った後は、次の手順を実施します。

         

        1. 1. 「Boot」または「Security」タブ内に移動する。
        2. 2. 「Secure Boot」オプションを「Disabled(無効)」に変更する。
        3. 3. 変更後、「Save and Exit(保存して終了)」を選ぶ。
        4. 4. パソコンが再起動する。

         

        セキュアブートを無効にした後は、未署名のドライバやカスタムカーネルを読み込めるようになります。

         

        無効化によるリスクとメリット

        セキュアブートを無効にすると、未署名ドライバや独自に構築したカーネルを使用するなどの柔軟な運用が可能になります。NVIDIAやVirtualBoxのドライバ、VPNなどを利用する際に制限が解除されるため、利便性が高まるでしょう。

        一方で、起動時にマルウェアなどが侵入するリスクが増すので注意が必要です。特に業務や公共機関で使用しているパソコンの場合、セキュアブートの無効化は慎重に判断する必要があります。

        利便性とセキュリティのバランスを考慮し、目的に応じて切り替えるのがよいでしょう。

         

        無効化後に再有効化する際の注意点

        セキュアブートを無効にした後、再度有効化する際は注意が必要です。無効化中にインストールした未署名ドライバやカーネルモジュールは、再有効化後、起動時に拒否される可能性があります。そのため、再有効化前に必要なドライバを「署名済み」にしておくことが必要です。

        Ubuntuでは、証明書登録・確認ツールである「mokutil」や「update‑secureboot‑policy」で署名リストを更新することで、セキュアブート環境でも安定して動作させることができます。安易な設定変更は避け、環境が安定した状態で運用することが重要です。

         

        セキュアブートが原因で起こるUbuntuの不具合

        セキュアブートを有効にしていると、一部の環境でUbuntuの正常な起動やインストールが妨げられることがあります。ここでは、代表的な障害とその原因について解説します。

         

        起動しない・GRUBが動作しない

        セキュアブートが有効な状態で、Ubuntuのブートローダーである「GRUB」が起動しない場合があります。これは使用している「GRUB」に正当な署名がない、またはセキュアブート対応のブートローダーである「Shim」が正しく導入されていないことが原因です。

        特に1台のパソコンに異なるOSを入れている「デュアルブート環境」や、カスタムインストールを行っている際に発生しやすいでしょう。

        Ubuntuの公式インストーラーからインストールした場合は、「Shim」と「署名付きGRUB」が含まれていますが、手動で設定を行った場合は、署名付きであるかどうかを確認する必要があります。

         

        カーネルやドライバのロード失敗

        セキュアブート有効時には、未署名のカーネルやドライバが読み込まれず、ロードに失敗することがあります。例えば、NVIDIAやVirtualBoxのドライバなど、カーネルモジュールを伴うパッケージは署名されていない場合が多く、起動中にエラーが発生します。

        これにより、グラフィックが正しく表示されなかったり、仮想マシンが起動しなかったりと、さまざまなトラブルが生じてしまうでしょう。

        対処方法としては、ドライバへの手動署名か、公式のドライバを採用することです。セキュアブートを一時無効化する方法もありますが、セキュリティを考慮すると選択しないほうが望ましいでしょう。

         

        署名エラーによるインストール失敗

        Ubuntuをセキュアブート対応環境にインストールする際、署名エラーが発生するとインストールが中断されることがあります。原因として多いのは、ISOイメージの破損、署名されていないブートローダーの使用、セキュアブート未対応のインストールメディアを使ったなどです。

        特にUSBメモリで作成したインストーラが不完全な場合、Ubuntuのブートローダーである「GRUB」の読み込み前にブロックされることがあります。Ubuntu公式サイトのISOを使用し、「Rufus(ルーファス)」や「balenaEtcher(バレナエッチャー)」などのUSBドライブ作成アプリを使うことで回避が可能です。

         

        セキュアブートのセキュリティ効果と限界

        セキュアブートは、OS起動時の安全性を高める仕組みですが、万能ではありません。ここでは、セキュアブートがマルウェア対策として有効な理由と限界、組み合わせるべきほかの対策などについて解説します。

         

        マルウェアのブート感染を防止できる理由

        セキュアブートは、パソコンの起動時に信頼された署名付きソフトウェアだけを実行することで、マルウェアによるブート領域の感染を防ぎます。例えば、「ブートキット」と呼ばれるマルウェアは、OSの起動前に実行することで、ユーザーに気づかれずに情報を盗むことが可能となります。

        セキュアブートは、こうした改ざんされたブートローダーやカーネルを検出し、起動を拒否する仕組みです。正規の署名があるソフトウェアのみが読み込まれるため、不正に改ざんしたプログラムを起動することはありません。

         

        セキュアブートだけでは不十分な点

        セキュアブートは、OS起動時の安全性を確保する仕組みですが、それだけではパソコン全体のセキュリティは守れません。例えば、OS起動後に侵入するウイルスやランサムウェアには対処不可能です。

        また、正規の署名があるプログラムであっても、脆弱性があれば攻撃に利用される可能性もあります。さらに、ユーザー自身が誤って悪意あるソフトを実行した場合は、セキュアブートで防ぐことはできません。

        このように、セキュアブートは一部の脅威にしか対応していない点を理解しておくことが重要です。

         

        セキュアブートと組み合わせるべきほかの対策

        セキュアブートを有効にしていても、OS起動後のセキュリティ対策は別途必要です。定期的なOSアップデートによる脆弱性修正、ファイアウォールやアンチウイルスソフトの導入、不要なサービスの停止などが効果的となります。

        またパスワード管理や多要素認証(MFA)も有効です。物理的なセキュリティとしては、BIOSやUEFIにパスワードをかける方法も効果的でしょう。

        これらを組み合わせることで、セキュリティの穴を減らし、より堅牢な環境を構築できます。

         

        Ubuntuユーザーが知っておきたいセキュアブートの誤解

        セキュアブートは、安全性を高める機能ですが、誤解されている点も多くあります。ここでは、「セキュアブート=安全」などの誤解について解説します。

         

        「セキュアブート=安全」は正しいのか?

        セキュアブートは、信頼できるソフトのみを起動させる仕組みですが、万能なセキュリティ対策ではありません。OS起動後に動作するマルウェアや、フィッシング攻撃には対応できないからです。署名付きソフトでも、ソフト自体に脆弱性がある場合、攻撃される対象になります。

        セキュアブートはあくまでブートプロセスの安全性を高める機能であり、それだけで「安全」とは言い切れません。ほかの対策と組み合わせて使うことが重要となります。

         

        全ユーザーにセキュアブートは必要か?

        セキュアブートは、一般ユーザーすべてに必須というわけではありません。独自ドライバを使いたい開発者やカスタムカーネルをビルドするユーザーにとっては、セキュアブートが障害になることがあります。

        一方で、標準構成でUbuntuを使用し、特別なカスタマイズをしないユーザーであれば、セキュアブートを有効にしておくことで起動時の安全性を保つことが可能です。セキュアブートは使い方に応じて、必要性を判断するのがよいでしょう。

         

        有効化でパフォーマンスは変わるのか?

        セキュアブートを有効にすることで、システムの起動やアプリケーションの動作速度に影響が出るという心配はありません。セキュアブートはあくまで起動時に署名の検証を行う仕組みであり、OS起動後の処理やアプリケーションの動作速度には無関係です。

        実際の体感速度も変わらず、非公式なレビュー・使用者投稿でも、セキュアブートの有効/無効による差はほとんど認められていません。(※)

        パフォーマンスへの影響を気にして無効化する必要はないといえるでしょう。

        ※出典:

        The quru of 3D「TPM/セキュアブートは OS やゲームのパフォーマンスに影響しますか?

        Neowin「セキュアブートを有効にするとパフォーマンスが低下しますか?

         

        まとめ

        セキュアブートは、UbuntuにおいてOS起動時の安全性を確保する重要な機能です。UEFIとの連携により、署名されたソフトウェアのみを実行させ、マルウェアの侵入を防ぎます。

        ただし、未署名ドライバの制限やDKMSの扱いには注意が必要です。セキュアブートは、すべてのユーザーにとって必須ではなく、用途に応じて有効/無効を判断することが大切といえます。

        Ubuntu環境でセキュアブートを活用するには、基本概念の理解と適切な設定・運用が欠かせません。セキュアブートは、安全性と利便性の両方から導入を検討するのがよいでしょう。

        弊社が提供する「ワンストップ型セキュリティ認証取得支援サービス」では、CRAの要求に沿った現状分析から適合評価、文書化、内部体制整備まで一括で対応しています。CRA対応を進めたい企業の信頼できるパートナーとして、実効性のある支援をご提供します。

        ワンストップ型セキュリティ認証取得支援サービス

        詳細資料をご希望の方は以下フォームよりメールアドレスをご登録ください。

          メールアドレス(必須)

          <個人情報の取り扱い>

          ※上記内容は、弊社の掲げる個人情報保護方針に沿って管理し、本件に関するお問い合わせ、
          お申込み等いただいた内容への対応のために利用する場合がございます。
          お客様の同意なく目的外の利用や第三者への開示、提供することはございません。
          詳細につきましては、当サイトの「個人情報保護方針」をご参照ください。

          「個人情報保護方針」に同意し、送信する
          (必須)


          [2025年09月05日 時点]
          2025年9月5日

          EUCCとは何か?CRAとの違いや認証要件を分かりやすく解説

          近年、CRA(サイバーレジリエンス法)への関心が高まる中で、「EUCCとは何?」「CRAとどう違うのか?」と疑問を持つ方も多いのではないでしょうか。

          EUCC(EUサイバーセキュリティ認証制度)はEUが策定した制度で、ICT製品の認証方法の取り決めです。(※)

          この記事では、EUCCの定義や目的、CRAとの関係性、認証の仕組みや企業に求められる対応などを整理し、認証取得のメリットと実務での備えについて解説します。

          ※出典:経済産業省「IoT 製品に対するセキュリティ適合性評価」(3.1.3)

           

          EUCCとは何か?

          EUCC(EU Cybersecurity Certification Scheme on Common Criteria)は、EU内で製品のサイバーセキュリティ強化を図るための認証制度です。(※)

          ここでは、その定義や背景、ほかの制度との違いについて解説します。

          ※出典:enisa「EUCC認証スキーム

           

          EUCCの定義と目的

          EUCCは、EUが策定したICT製品向けのサイバーセキュリティ認証制度です。製品やサービスのセキュリティ性能を共通基準で評価し、信頼性を可視化することを目的としています。

          EU域内におけるセキュリティ基準の統一により、合否選定の透明性と効率性が高まり、企業と消費者の両方にとって利便性の高い仕組みとなっています。

           

          EUCCが策定された背景

          EUCCは、サイバー攻撃の複雑化や加盟国内で異なる認証制度が混在している状況を受けて策定されました。これまでは各国の個別制度が使われており、グローバル展開する企業にとって対応の負担が大きい状況でした。

          EU全体で統一された認証制度を整備することで、国境を越えた製品流通をスムーズにし、サイバーセキュリティ全体の底上げを図る狙いがあります。

           

          EUCCとほかのサイバーセキュリティ認証との違い

          EUCCは、製品のセキュリティ機能を対象とした認証制度です。ISO/IEC 27001のように、組織の管理体制を評価する制度とは異なります。(※)

          EUCCはEU域内で法的な裏付けを持ち、リスクに応じた複数の保証レベルを用意している点が特徴です。また、将来的にはCRA(サイバーレジリエンス法)(※)との連携も視野に入れており、EU市場での信頼性確保に重要な役割を果たすと考えられています。

          ※出典:

          総務省「情報セキュリティ対策に関連する 既存の基準・ガイドライン」(Page-8)

          経済産業省「経済産業省のサイバーセキュリティ政策について」(Page-12)

           

          EUCC認証の仕組みと要件

          EUCC認証の全体像を理解するために、評価基準と対象範囲、セキュリティレベル、取得プロセスの核要素について解説します。

           

          評価基準と適用対象製品の範囲

          EUCCは、ISO/IEC 15408(Common Criteria)とISO/IEC 18045に基づく評価基準を適用します。(※)

          ISO/IEC 15408とは、ICT製品やシステムのセキュリティ機能が適切かどうかを評価するための国際標準規格で、実際の評価の仕組みを定めているのがISO/IEC 18045です。(※)

          ICT製品や保護プロファイルに対して、この共通基準に従ったセキュリティ評価が行われます。対象には、チップ、スマートカード、ソフトウェア、ハードウェアなど幅広い製品が含まれ、自主評価は認められていません。

          これにより、認証プロセスの透明性と信頼性が確保されます。EU全域で製品の評価を統一することで、企業にとって合理的かつ一貫した対応が可能です。

          ※出典:

          経済産業省「IoT製品に対するセキュリティ適合性評価制度の 構築について」(Page-7)

          経済産業省「ITセキュリティ評価及び認証」、「IT 製品の調達におけるセキュリティ要件リスト」(Page-5)

           

          EUCCにおけるセキュリティレベルの分類

          EUCCは「substantial」と「high」という2つの保証レベルを設けています。「substantial」は基本的な脆弱性評価で、「high」はより厳密な検査が求められるものです。

          それぞれが対応している「保証脆弱性分析レベル(AVA_VANレベル)」も含めて、下表に特徴をまとめています。

          保証レベル 保証脆弱性分析レベル 特徴
          substantial AVA_VAN.1~2 基本的な脆弱性評価を実施し、初歩的な攻撃耐性を検証する
          high AVA_VAN.3~5 詳細で洗練された脆弱性分析を通じて、高度な攻撃耐性を検証する

          ※出典:European Union「欧州共通基準に基づくサイバーセキュリティ認証制度(EUCC)

           

          認証取得に必要なプロセス

          EUCCを取得する場合、セキュリティターゲット(ST)などの文書準備や、認証機関などの評価を受ける必要があります。EUCC認証取得の主なプロセスは次のとおりです。

          1. 1. セキュリティターゲット(ST)の作成
            製品に求められるセキュリティ要件や、想定される脅威、対応策を記載した文章を作成する。
          2. 2. 認証機関(CB)と評価機関(ITSEF)の選定
            EUCCに対応した認証機関(Certification Body:CB)、評価機関(IT Security Evaluation Facility:ITSEF)を選定し契約する。
          3. 3. STに基づく技術評価の実施
            作成したSTに基づき、ITSEFが脆弱性評価や機能検証などの技術的審査を行う。
          4. 4. CBによる認証判断と証明書発行
            技術評価の結果をCBが審査し、適合が確認されれば、EUCCの認証証明書が発行される。

          EUCCの認証証明書の有効期間は、最長5年です。(※)

          ただし製品の運用やソフトウェアのアップデート時には、セキュリティ影響の確認や必要に応じた再評価が求められる場合があります。

          また製品公開後に発見された脆弱性については、早急な対応と報告が必要です。そのため、継続的なセキュリティ監視体制の整備が重要といえるでしょう。

          ※出典:European Union「欧州共通基準に基づくサイバーセキュリティ認証制度(EUCC)

           

          EUCCとCRAの関係性

          EUCCとCRA(サイバーレジリエンス法)は、密接に関連しています。ここでは、EUCCがCRAの中でどのような位置づけになっているのか、役割の補完性、認証の重要性などについて解説します。

           

          CRAにおけるEUCCの位置づけ

          CRAは、製品の安全を確保するためのEU規則です。CRAの中では、EUCC認証を受けた製品は「presumption of conformity(適合の推定)」が認められ、CRAの基本要件を満たしていると判断されます。(※)

          ただし、CRAではEUCC認証が義務になっているわけではありません。EUCC認証は、企業が利用できる手段の一つという位置づけです。企業は、こうした制度を活用することで安全性を証明しつつ、認証プロセスを簡潔にすることが可能となります。

          ※出典:enisa「EUCCとその適用可能な技術要素によるサイバーレジリエンス法の実施

           

          EUCCが果たす役割と相互補完性

          EUCCは、CRAで求められる「ライフサイクルにおけるセキュリティ対策」を技術的に補完します。具体的には、EUCCの認証プロセスは国際標準規格である「CC(Common Criteria)」に基づいているため、セキュリティ要件(SFR)と評価手順(SAR)を通じて製品の安全性の定量化が可能です。

          これによりCRAの要求と一致するため、企業は認証制度と法規制の両方による確認を効率よく実施できます。

           

          CRA対象製品におけるEUCC認証の重要性

          CRAでは、デジタル要素を持つ製品を「重要(important)」「クリティカル(critical)」に分類し、それに応じたセキュリティ評価義務を課しています。(※)

          EUCCは、これらの製品カテゴリに対して、信頼性のある認証手段を提供している形です。EU認定のサイバーセキュリティ認証スキームとしてEUCCが機能しており、これを取得することでCRAの義務をスムーズに満たすことができます。

          企業側としては、規制対応の重複やコストの削減が可能となります。

          ※出典:enisa「EUCCとその適用可能な技術要素によるサイバーレジリエンス法の実施

           

          EUCCが企業にもたらすメリット

          EUCC認証を取得することで、企業は製品の信頼性向上、EU域内での競争力強化、セキュリティに起因するリスク軽減などが可能です。ここでは、EUCC取得のメリットについて解説します。

           

          製品信頼性とブランド力の向上

          EUCC認証を得た製品は、第三者による厳格なセキュリティ評価を経ていることを示します。これは、信頼性が高い製品であることを証明するため、製品のブランド価値を高める役割を果たします。

          消費者や取引先は、その製品を安心して選択できるといえるでしょう。EUCC認証は、製品の長期的なイメージ構築につながります。

           

          EU域内での競争力強化

          EUCC認証は、EU全域で共通に認められるセキュリティ保証です。認証を受けることで複数国への市場展開が可能となり、認証コストや手続きの重複が削減されます。

          その結果、企業は効率的に販売網を拡大でき、競合他社より先に顧客に製品を届けられる優位性を得ることが可能です。

           

          セキュリティ対策の標準化によるリスク削減

          EUCCは共通の評価基準に基づき、セキュリティ機能を検証します。そのため、製品設計時からセキュリティ要素を組み込み、脆弱性対策の体系化が可能です。また標準化された認証基準によって、市場アクセスが容易になるため、技術革新が促進されます。

          こうした標準化は、セキュリティ不備によるリスクを低減し、トラブル発生時にも迅速な対応が可能となります。

           

          EUCC認証を見据えた準備と対応

          EUCC認証取得を目指す企業は、社内体制の整備、外部機関との連携、情報収集に至るまで計画的な取り組みが必要です。ここでは、準備と対応について解説します。

           

          認証取得に向けた社内体制の構築

          EUCC認証取得には、明確な社内プロジェクトの体制が必要です。認証取得責任者を明確化し、ドキュメント作成やセキュリティ要件の対応を担うメンバーを配置します。続いて、セキュリティターゲット(ST)と脆弱性対応プロセスの標準化に向けた、内部作業手順を整備することも重要です。

          こうした体制がないと、プロジェクトが機能せず、認証取得までの期間が長引いてしまう可能性があります。組織されたチームは、効率的な進行と品質確保を両立できるため、結果として認証取得の成功につながります。

           

          外部機関との連携の必要性

          EUCC認証は、認定された評価機関(ITSEF)、認証機関(Certification Body)が実施します。そのため、信頼できる外部機関と早期に連携を開始することが重要です。自社単独で対応を進めるよりも、評価や文書整備の指導を受けながら実施したほうが効率的といえます。

          例えば、評価対象の範囲や技術要件の確認では、専門家の助言が役立つためです。外部機関との連携により、品質確保と進行速度の両立が可能となり、認証取得の現実性が高まります。

           

          今から始める情報収集と準備のポイント

          EUCC取得に向けた準備は、ENISAの公式ドキュメントを確認することから始まります。特に最新の「state-of-the-art」は、評価手法や設計要件を理解する上での重要な基盤です。(※)

          また「Evaluation methodology for Product series」などのガイドラインは、製品シリーズの評価に役立ちます。(※)

          こうした情報を把握し設計初期に反映することで、後工程での修正リスクを抑えて認証準備の効率化とスケジュール短縮が実現可能となります。

          ※出典:

          enisa「EUCC SCHEME STATE-OF-THE-ART DOCUMENT

          enisa「Evaluation methodology for Product series

           

          日本企業のEUCC対応に関する課題と対策

          日本企業がEUCC対応を進めるには、言語・文化の壁、グローバル対応力の強化などが必要です。ここでは、課題と対策について解説します。

           

          言語・文化・制度のギャップを乗り越えるには

          EUCCに関する文章や基準は、英語が多く、日本企業にとっては言語のハードルがあります。また報告スタイルや文書構造の違いも、混乱する要因になる場合があるでしょう。

          そのため、専門的な翻訳体制や欧州制度に詳しい人材の配置が初期の対応として重要です。例えば、社内の国際プロジェクトと連携して、文書研修やレビュー体制を整備することで、文化や制度の違いを乗り越えやすくなります。

          こうした準備が、認証取得時の認識の食い違いを減らす上で効果的です。

           

          グローバル市場への対応力強化の必要性

          EUを含む国際市場へ製品を展開するには、EUCC認証取得が競争力に直結します。特にEUは技術安全性に強く規制を設けられている市場であり、対応を怠ると参入機会を失うことも少なくありません。

          そのため、設計段階からEUのセキュリティ要件を取り込むプロセスの導入が望ましいでしょう。例えば、製品開発の初期段階から、欧州法務部や国際部門と連携し、要件を設計証書に反映することで、後工程での修正負担を軽減できます。

           

          中小企業における実務的ハードルと支援策

          中小企業にとって、EUCC取得は費用負担や手続きの複雑さが大きな障壁となります。そのため、まずは業界団体や商工会議所などの共同研修を活用し、専門知識を共有するのが効果的です。

          また外部の認証支援サービスを利用することで、少人数でも対応が可能となります。例えば、地域の中小支援機関が実施するセミナーや、EU対応の補助制度を活用することで、経済的負担を抑えつつ実務対応を進めることが可能です。

           

          まとめ

          EUCCは、EUが策定した統一的なサイバーセキュリティ認証制度です。EUCCの認証を取得することで、製品の信頼性向上とEU市場へのアクセス強化に貢献します。

          CRAとの補完関係も重要で、規制対応の効率化を図る上で、EUCC取得は実務上大きな意義を持ちます。企業は認証取得に向けた社内体制整備や、外部機関との連携を進め、言語、制度両面の壁を越えて早期に行動することが求められるでしょう。

          日本企業にとっては、EUCCへの対応は単なる法対応にとどまらず、国際競争力の強化と長期的なブランド価値の向上に直結する重要な取り組みといえます。

           

          弊社が提供する「ワンストップ型セキュリティ認証取得支援サービス」では、CRAの要求に沿った現状分析から適合評価、文書化、内部体制整備まで一括で対応しています。CRA対応を進めたい企業の信頼できるパートナーとして、実効性のある支援をご提供します。

          ワンストップ型セキュリティ認証取得支援サービス

          詳細資料をご希望の方は以下フォームよりメールアドレスをご登録ください。

            メールアドレス(必須)

            <個人情報の取り扱い>

            ※上記内容は、弊社の掲げる個人情報保護方針に沿って管理し、本件に関するお問い合わせ、
            お申込み等いただいた内容への対応のために利用する場合がございます。
            お客様の同意なく目的外の利用や第三者への開示、提供することはございません。
            詳細につきましては、当サイトの「個人情報保護方針」をご参照ください。

            「個人情報保護方針」に同意し、送信する
            (必須)


            [2025年09月05日 時点]
            2025年9月5日

            STM32® N6570-DK上でZephyrをデバッグする

            Zephyrとは

            Zephyrは、Linux Foundationによってオープンソースで開発が進めらているIoT向けのRTOS(リアルタイムオペレーティングシステム)です。
            軽量で、x86、arm、RISC-Vなどのさまざまなアーキテクチャに対応し、リアルタイム機能を持ち、さまざまなプロトコルスタックを実装し、セキュリティを重視していることなどを特長とします。

            STM32N6570-DKとは

            STM32N6570-DKは、2024年にSTMが販売を開始した評価用ボードです。
            Arm® Cortex®-M55コアベースのマイクロコントローラ(STM32N657X0H3Q)が搭載されています。

            本コラムでは、STM32N6570-DK上でZephyrを動かして、シリアルとLEDとデバッガーを動作させる手順を説明します。
            Windows環境ではGUIによるデバッグは未サポートのようなので、コマンドラインでデバッグを行う方法も簡単に説明します。

            開発環境

            システム構成要素 詳細
            ホストOS Windows 11
            ターゲットOS Zephyr v4.2.0-rc2
            ターゲットボード STM32N6570-DK

            ホストマシンはUSB-Cポートがあるとよいです。
            Type-Aだと供給電力の問題で、カメラやディスプレイを動かすときに特に動作が不安定になることがあります。

            関連ソフトウェア

            Windowsには以下のソフトウェアをインストールしておく必要があります。

            開発環境の構築

            開発環境の構築はコマンドラインからできます。
            Windows PowerShellを開いて、以下のコマンドを実行すれば開発環境を構築できます。

            > mkdir zephyr
            > cd zephyr
            > python -m venv zephyrproject\.venv
            > Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
            > zephyrproject\.venv\Scripts\Activate.ps1
            > pip install west
            > west init zephyrproject
            > cd zephyrproject
            > west update
            > west zephyr-export
            > west packages pip --install
            > $env:PATH = "C:\zephyr;" + $env:PATH
            > $env:PATH = "C:\Program Files\7-Zip;" + $env:PATH
            > cd zephyr
            > west sdk install

            二回目以降

            いちど「west sdk install」まで実行したらこれ以降は、
            PowerShellを開くたびに以下のコマンドを実行してPythonの仮想環境を有効化することでZephyrのビルドができるようになります。

            > cd C:\zephyr
            > Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
            > zephyrproject\.venv\Scripts\Activate.ps1
            > cd zephyrproject\zephyr

            samples/basic/blinkyアプリケーションのビルド

            開発環境の構築とシェルの設定ができたら、以下のコマンドでsamples/basic/blinkyアプリケーションをビルドできます。
            samples/basic/blinkyは、LEDをチカチカ点灯させる、いわゆるエルチカです。

            > west build -b stm32n6570_dk//fsbl samples/basic/blinky

            (–sysbuildオプションつきのMCUBootベースのアプリケーションだと、セキュアブートとなってしまい、デバッガーが接続できなくなってしまうようです。)

            アプリケーションの書き込み

            アプリケーションの書き込みを書き込むには、STM32N6570-DKのブートスイッチ「Development boot」にする必要があります。
            以下が「Development boot」の設定です。

            BOOT0: 0 (左)
            BOOT1: 1 (右)

            「STLINK V3EC」ポートをUSBケーブルでPCとつないだ状態で、以下のコマンドを実行すれば、ボードのフラッシュメモリにプログラムを書き込めます。

            > west flash

            シリアルとLED

            プログラムを実行する前にTeraTermを起動して「STMicroelectronics STLink Virtual COM Port」を開いておきます。
            また、シリアルポートの設定をしておきます。

            パラメータ
            ボー・レート 115200
            データ 8 bit
            パリティ none
            ストップ 1 bit
            フロー制御 none

            ボードのブートスイッチを「Flash boot」にし、ボードのリセットスイッチを押すと、プログラムを実行できます。
            以下が「Flash boot」の設定です。

            BOOT0: 0 (左)
            BOOT1: 0 (左)

            シリアルの動作が確認できました。

            LEDの動作も確認できました。

            デバッグ設定

            アプリケーションのデバッグのためには、コンパイル最適化を抑制する必要があります。
            C:\zephyr\zephyrproject\zephyr\samples\basic\blinky の prj.conf で、デバッグ用のオプションの設定(CONFIG_DEBUG)を記述することで、コンパイル最適化を抑制できます。
            prj.confの内容は、以下のようにすればよいです。

            CONFIG_GPIO=y
            CONFIG_DEBUG=y

            「west build ~」で再ビルドして、「west flash」でアプリ再書き込みを行えば、デバッグができるようになります。

            デバッガー

            以下のコマンドでデバッガーを起動できます。

            > west debug

            デバッガーの動作が確認できました。 

            コマンドラインからのデバッグは、デバッガーへの命令をすべてコマンドで送る必要があります。

            ブレークポイント

            ブレークポイント(一時停止する箇所)の設定は「b 関数名」でできます。
            その後、「c」でプログラムを実行できます。
            ブレークポイントに到達すると、プログラムはブレーク(一時停止)します。
            「l」で周辺のソースコードを表示できます。

            z_cstart()はZephyrで最初の方に呼ばれる初期化の関数です。

            ステップ実行

            プログラムを一行ずつ実行するのは「s」でできます。
            「s」は「ステップ・イン」で、関数があると関数の中に入ります。

             「スペース」を押すと直前のコマンドを繰り返せます。

            「ステップ・オーバー」は「n」で、関数があると関数の中に入らずに次の行に進みます。

            バックトレース

            「bt」はバックトレースを表示します。
            これで関数の呼び出し関係がわかります。

            変数の値の表示

            ローカル変数の値の表示は「i lo」でできます。

            main()関数の44行目まで飛んで、ローカル変数の値を見てみます。

            変数の値の変更

            変数の値の変更は「p 変数名=値」でできます。

            ローカル変数led_stateの値を変更してみます。

            その後コンソールでprintf()の表示をみると、値が変更されて結果も変わったたことがわかりました。

            最後に

            以上になります。
            このコラムが、皆様がSTMボードやZephyrに興味を抱くきっかけになりましたら幸いです。

            また弊社ではZepher開発・運用支援サービスを提供しておりますので、こちらも参考にしてください。

            ウインドリバーのZephyr RTOS 開発・運用支援サービス

            詳細資料をご希望の方には送付させていただきますので、以下フォームよりメールアドレスをご登録ください。

              メールアドレス(必須)

              <個人情報の取り扱い>

              ※上記内容は、弊社の掲げる個人情報保護方針に沿って管理し、本件に関するお問い合わせ、
              お申込み等いただいた内容への対応のために利用する場合がございます。
              お客様の同意なく目的外の利用や第三者への開示、提供することはございません。
              詳細につきましては、当サイトの「個人情報保護方針」をご参照ください。

              「個人情報保護方針」に同意し、送信する
              (必須)


              • STM32® は STMicroelectronics International N.V. またはその関連会社の登録商標です。
              • Arm および Cortex は、米国およびその他の国における Arm Limited(またはその子会社)の登録商標です。

              [2025年08月22日 時点]
              2025年9月2日

              CRA SBOM対応|全体像と要件を条項ごとに分かりやすく解説

              CRAの重要な要素の一つとして「SBOM対応」があります。SBOMとは「Software Bill of Materials」の略で、ソフトウェアを構成している部品と部品同士の依存関係をリスト化した「ソフトウェア部品表」です。(※)

              この記事では、CRAにおけるSBOMの位置付けや、CRA条項ごとの対応関係を整理し、実務で押さえるポイントを分かりやすく解説します。具体的には、SBOMの作成・運用・提供体制の構築に加え、社内教育やベンダー連携などの紹介です。

              ※出典:経済産業省「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引

               

              CRAがSBOMを求める理由と背景を理解する

              CRA(サイバーレジリエンス法)では、SBOMの提出や管理が強く求められています。ここでは、その背景や法的要請の構造について整理していきます。

               

              なぜ今SBOMが注目されているのか

              サイバー攻撃の多様化とサプライチェーンの複雑化により、製品に含まれるソフトウェアの透明性が国際的に求められています。特に2021年に米国で発令された「大統領令14028」や「NTIAのSBOMガイドライン」以降、SBOMはセキュリティ対策の「見える化ツール」として注目されている状況です。

              「大統領令14028」とは、米国のサイバーセキュリティの改善に関するもので、「NTIAのSBOMガイドライン」とは、NTIA(米国商務省電気通信情報局)が発表したSBOMの作成と利用を促進するための方針になります。(※)

              CRAでは「悪用可能な脆弱性が含まれていないこと」が要件となっており、製品に使用される全コンポーネントを正確に把握するためにSBOMの整備が不可欠とされています。(※)

              ※出典:経済産業省「ソフトウェアに向けたSBOMの導入に関する手引き ver2.0」(P17)

              European Union「EUR-Lex(附属書Ⅰ-必須のサイバーセキュリティ要件)」

               

              CRAが求めるソフトウェア構成の可視化とは

              CRA 第31条では、製品のセキュリティ特性や構成情報を技術文書として提示することが求められています。(※)

              SBOMは「構成情報の根拠資料」として活用され、各ソフトウェアコンポーネントの名前、バージョン、提供元、ライセンス情報などを明記する形です。

              また第13条では、アップデート提供に関して、改変された構成情報の明示も義務付けられており、SBOMの定期更新が必要になります。(※)

              ※出典:CYBER RESILIENCE ACT「サイバーレジリエンス法」(第13条、第31条)

               

              欧米の法制度との「共通点」「相違点」

              CRAの要件は、米国の「大統領令14028」やEUの「NIS2指令」などと類似性があります。「大統領令14028」とは、米国のサイバーセキュリティの改善に関するもので、「NIS2指令」とは、EUが施行したサイバーセキュリティ対策強化の指令です。(※)

              例えば、CRA 第13条の「脆弱性への対応責任」は、これらの欧米の法制度と考え方が共通しています。ただし欧米の法制度はガイドラインベースなのに対して、CRAは罰則付きの義務規定である点が異なっています。

              ※出典:NIS2 Directive「NIS2:欧州史上最も広範なサイバーセキュリティ指令

              CYBER RESILIENCE ACT「サイバーレジリエンス法」(第13条)

               

              CRA条文とSBOM対応項目のマッピング

              CRAではSBOMに直接言及されていないものの、多くの条文がSBOMによって対応可能となっています。ここでは、各条文が求めている情報と該当するSBOM項目を整理します。

               

              SBOMに関係する主要条文の一覧と読み解き方

              CRAの条文と、対応するSBOM項目を下表にまとめました。条文の背景を理解した上で、SBOMの各情報項目と関連付けることが重要です。

              CRA条文 条文の要求内容 対応するSBOM要素
              基本的なセキュリティ要件(第13条) 製品に既知の脆弱性を含まないこと ソフトウェア名、バージョン、ハッシュ、依存関係
              製品情報の提供(第14条) 利用者が製品の構成情報を確認できる状態にすること ソフトウェア名、提供元、ライセンス情報
              セキュリティアップデート(第13条) 更新履歴・更新理由・適用状況を文書化すること 更新履歴、差分情報、アップデート対象
              技術文書の提出(第31条) 評価機関への構成情報などを文書で提出すること 構成情報、署名付きの形式ファイル

              ※出典:CYBER RESILIENCE ACT「サイバーレジリエンス法」(第13条、第14条、第31条)

               

              条文ごとに求められるSBOM項目の具体例

              CRAでは「既知の脆弱性を含まない」ことが求められています。これはSBOMに記載されたコンポーネントのバージョン情報と、脆弱性データベースを照合する運用が対応している状況です。またCRAで「製品情報の提供」が求められていますが、SBOMの項目としてソフトウェア名、バージョン、提供元、ライセンスなどを利用者に提示できる形で保持しておくことで要求を満たすことが可能です。

              このように、各条文に対してSBOMにどの情報を含めればよいのかを明確にすることが、CRA適合への第一歩となります。

               

              評価機関への提出を想定した文書の整備ポイント

              CRAでは、適合性評価を行う際に、製品構成や更新体制の文書を評価機関へ提出する必要があります。このとき、SBOMを作成していれば構成情報の証拠資料として活用が可能です。

              求められているのは、「SPDX」や「CycloneDX」といった標準形式で整備されたSBOMで、記載内容にはソフトウェア名、バージョン、ハッシュ、依存関係、ライセンスなどを含めます。

              さらに、差分の記録や更新履歴といった動的情報もSBOMに入れることで、審査時の信頼性が向上します。評価機関からの指摘リスクを減らすには、提出前にSBOMの整合性チェックを行うことが重要です。

               

              CRAに準拠したSBOMを作成・更新する実務プロセス

              CRA対応に求められるSBOMは、「一度作成すれば終わり」ではありません。作成後も更新していく必要があります。そのため、更新を前提とした体制の構築が必要です。ここでは、SBOMに含めるべき情報、社内運用ルール、体制構築について解説します。

               

              SBOMに含めるべき情報とフォーマット

              CRAで要求されるSBOMには、標準化された情報の記載が必要となります。含めるべき主な要素は次のとおりです。

               

              • ソフトウェア名とバージョン
              • ライセンス種別と提供元
              • 暗号学的ハッシュ(SHA-256など)(※)
              • 各コンポーネントの依存関係

               

              これらを正確に記録、共有するため、SPDXやCycloneDXといった標準フォーマットの使用が推奨されます。SPDXはライセンス情報との親和性が高く、CycloneDXは脆弱性管理との統合がしやすい利点があります。製品リスクの管理目的でSBOMを提出する場合は、機械可読性があるこれらのフォーマットが効果的です。

              ※出典:IT用語辞典「SHA-256

               

              社内運用ルールの策定とツールの選び方

              SBOMは作成して終わりではなく、更新と活用を前提にした社内ルールが必要です。例えば次のような運用ルールが有効といえます。

               

              1. 各開発フェーズ内にSBOM生成を組み込む
              2. ソフトウェア統合時やリリース時に最新SBOMとの相違チェックを行う
              3. リリースドキュメントにSBOMを添付するルールを設ける

               

              SBOMを自動で生成したり、管理したりできるツールが公開されています。(※)

              ツールを選ぶ際は、社内システムとの親和性、生成フォーマット、更新対応のしやすさなどを確認することが重要です。

              ※出典:経済産業省「ソフトウェアに向けたSBOMの導入に関する手引き ver2.0」(10.3.2章)

               

              SBOMを第三者評価や出荷に活用する体制

              CRA 第31条で求められているのは、適合性評価のための技術文書の整備です。SBOMはその中核を担う資料として利用されています。例えば次のような用途です。

               

              • 評価機関への構成情報の提示
              • 出荷時に添付するソフトウェアの構成資料
              • ソフトウェアの更新内容を示す資料

               

              SBOMは電子データで管理し、改ざん防止や履歴保持ができる保管場所が必要です。クラウドストレージや内部レジストリを活用し、常に最新版を維持できる体制を整備してください。SPDXファイルに署名を付けて、証跡として活用する方法も有効です。

              ※出典:CYBER RESILIENCE ACT「サイバーレジリエンス法」(第13条)

               

              サプライチェーンと連携したSBOM提供の実務対応

              CRAに準拠するためには、自社内だけでなくサプライチェーン全体でSBOM対応が必要です。ここでは、ベンダー契約の工夫、形式統一の手法、社内教育のポイントなどを解説します。

               

              外部ベンダーとのSBOM提供契約に盛り込むべき条項

              SBOMの整合性と信頼性を確保するには、外部ベンダーとの契約書に具体的な条項を明記する必要があります。例えば、次のような要素です。

              要素 内容
              提供義務 製品に含まれるすべてのコンポーネントをSBOMに記載して提出する
              提出形式 SPDXまたはCycloneDXなど、指定フォーマットで作成する
              更新義務 バージョン変更やセキュリティパッチ適用時にSBOMの更新を義務化

              また、虚偽報告への責任範囲や、SBOMの監査受け入れに関する条文を明文化しておくのも有効な方法です。

               

              フォーマットの違いを吸収する統一運用の仕組み

              複数のベンダーから受け取るSBOMは、フォーマットや記載の粒度に差が出やすいため、社内で標準化する仕組みが必要です。例えば次のような仕組みが有効といえます。

               

              1. CycloneDXとSPDXを変換できるOSSツールを活用する
              2. 各フィールドの必須項目がルールどおりかどうかをチェックする「バリデーションスクリプト」を導入する
              3. API連携で社内SBOMへ自動インポートする仕組みを構築する

               

              受け取ったSBOMをそのまま保管するのではなく、変換や補完をするなどして統一データベース化する仕組みが必要です。

               

              開発チーム・関係者向け教育をどう実施するか

              SBOM運用は、IT部門だけでは完結しません。開発、調達、品質保証など、他部門の理解と連携が不可欠です。また評価機関からの指摘に備えて、SBOMの更新・承認プロセスを理解しておく必要もあるでしょう。例えば、次のような関係者向けの教育も有効な手段です。

               

              • CRAとSBOMの関係を図解で説明したマニュアルを社内に配布
              • SBOM作成の社内教育を実施
              • 更新時期や提出基準をまとめたガイドラインの整備

               

              継続的な教育と、属人化しない体制の構築が、信頼性の向上にもつながります。

               

              SBOMが企業のセキュリティと経営に与える本当の効果

              SBOMは法令対応だけでなく、事業リスクの低減や経営判断の支援にも関係します。ここでは、実務・法務・経営の観点から、具体的な導入効果を説明します。

               

              脆弱性対応スピードの向上と実際の事例

              SBOMを作成することで、脆弱性の影響範囲を即座に特定できます。例えば「OpenSSL」の深刻な脆弱性が報告された場合、SBOM管理を行っていれば、対象ライブラリを含む製品とバージョンを即座に洗い出すことが可能です。

              修正に取り掛かるまでの工数と時間が大幅に短縮され、顧客への影響説明も素早く行うことができます。

               

              将来の法規制・監査に備えてSBOMを活用

              SBOMは、CRAへの対応だけでなく、今後予測されるほかの規制(米国大統領令14028やEU NIS2指令)などの要件にも適合できる基盤となります。(※)

              例えば、監査時に「どのOSSがどの製品に使われているのか」と質問を受けた際、SBOMを提出することで即座に明示が可能です。事前にSBOM運用体制を構築しておくことは、複数の法令への横断的な対応として効果的といえます。

               

              ※出典:NIS2 Directive「NIS2:欧州史上もっとも広範なサイバーセキュリティ指令

               

              経営層にSBOM導入を理解・納得してもらう説明方法

              経営層にSBOMの重要性を伝えるには、コストや法対応の観点だけでなく「事業継続性の確保」「ブランド信頼性の維持」といった視点で説明することが効果的です。

              例えば、製品出荷停止やリコール対応が発生した場合、SBOMの有無で対応スピードや損害金額が大きく変わる可能性があります。定量的リスクとして説明資料を作成し、「攻めのセキュリティ投資」として位置付けることで、理解を得やすくなるでしょう。

               

              まとめ

              CRA(サイバーレジリエンス法)への対応において、SBOM(ソフトウエア部品表)は製品の透明性確保と脆弱性対策に欠かせない要素です。この記事では、CRAの各条文とSBOM項目の対応関係を明示しつつ、SBOMの作成・更新・提出の実務プロセスやベンダー契約、社内教育、経営層への説明方法などを解説しました。

              SBOMの対応は、法令だけでなく、事業継続性とセキュリティ強化の両立につながる重要な施策といえます。

              弊社が提供する「ワンストップ型セキュリティ認証取得支援サービス」では、CRAの要求に沿った現状分析から適合評価、文書化、内部体制整備まで一括で対応しています。CRA対応を進めたい企業の信頼できるパートナーとして、実効性のある支援をご提供します。

              ワンストップ型セキュリティ認証取得支援サービス

              詳細資料をご希望の方は以下フォームよりメールアドレスをご登録ください。

                メールアドレス(必須)

                <個人情報の取り扱い>

                ※上記内容は、弊社の掲げる個人情報保護方針に沿って管理し、本件に関するお問い合わせ、
                お申込み等いただいた内容への対応のために利用する場合がございます。
                お客様の同意なく目的外の利用や第三者への開示、提供することはございません。
                詳細につきましては、当サイトの「個人情報保護方針」をご参照ください。

                「個人情報保護方針」に同意し、送信する
                (必須)


                [2025年08月06日 時点]
                2025年8月6日

                CRAとは?IoT製品に必須の新セキュリティ規制と対応ポイント

                IoT機器やデジタル製品の開発に携わるIT企業にとって、自社製品の「CRA対応」が必要かどうか気になっている方も多いのではないでしょうか。

                CRA(サイバーレジリエンス法)は、EUが導入を進めるサイバーセキュリティ規制で、製品の設計からアップデート体制まで、包括的な対応が求められるものです。(※)

                この記事では、CRAの概要、対象となる製品、企業が取るべき対策などを分かりやすく解説します。

                ※出典:Cyber Resilience Act「CRA

                CRAとは何か

                CRA(サイバーレジリエンス法)は、EUが導入を進めるサイバーセキュリティに関する新しい規制です。ここでは、その正式名称や対象商品、ほかの規制との違いについて解説します。

                 

                CRAの正式名称と定義

                CRAは「Cyber Resilience Act(サイバーレジリエンス法)」の略称で、EU(欧州連合)によって策定された規則です。この規則は、ネットワークに接続されるすべての製品に対し、一定のサイバーセキュリティ要件を課すことを目的としています。

                具体的には、設計段階から安全性を確保する「セキュア・バイ・デザイン」の原則に基づいたものです。これまではソフトウェアやハードウェアに対して、一貫した基準がないことが課題とされていました。そこで統一的な基準を設けて、製造から販売、利用後のサポートまでを含めたセキュリティ対応を取り決めたのがCRAです。

                EU市場に製品を投入する全企業が対象となるため、日本企業にとっても他人事ではありません。適切な対応が必要となります。

                 

                対象となる製品と対象外の範囲

                CRAの対象は、インターネット接続機能がある「デジタル製品全般」です。例えばスマート家電やネットワーク機器、工場で使われるIoTデバイス、ソフトウェア、アプリケーションなどが含まれます。さらに製品単体だけでなく、それを構成する部品や組み込みソフトウェアも対象です。

                一方、すでにほかのEU規制が適用されている自動車や医療機器などは、CRAの対象から除外されます。また国家安全保障に関わる一部の軍用機器なども対象外です。

                企業は、自社製品の機能や接続性、流通市場を明確にし、CRAの対象かどうかを整理する必要があります。

                 

                ほかの規制との違い

                CRAは従来の規制とは異なり、「サイバーセキュリティ対策」を製品の設計・製造段階から義務付ける点が特徴です。例えば、EUで一般的なCEマーキングは、電気安全やEMC(電磁両立性)などの物理的な安全性が中心でした。CRAはそれに加えて、製品がサイバー攻撃に耐えられるかどうかという観点で審査を行います。(※)

                またNIS2指令(EUサイバーセキュリティ枠組み)は組織全体のセキュリティ対策が焦点ですが、CRAは製品単位が対象です。(※)

                企業はCRAとほかの規制の関係性を理解し、重複や漏れのない対応計画を立てる必要があります。

                ※出典:JETRO「CEマーキングの概要:EU

                NIS2 Directive「NIS2:欧州史上最も広範なサイバーセキュリティ指令

                 

                CRAが制定された背景と目的

                CRAはなぜ必要とされたのか、その背景とEUが目指す規制の目的について解説します。ここでは、時代の流れとともに生まれた課題と対策の方向性を整理します。

                 

                急増するIoT製品とサイバー攻撃リスク

                近年、家庭や企業内でインターネット接続機器を持つIoT製品が急増しています。例えばスマートスピーカーや防犯カメラ、工場内の制御装置などが日常的にネットワークに接続されている状況です。

                しかしこれらの多くはセキュリティ対策が不十分なまま市場に出回っており、実際に乗っ取りや不正操作などによるサイバー攻撃が報告されています。攻撃者は脆弱な製品を足がかりに、企業ネットワーク全体へ侵入することもあり、被害は拡大傾向です。

                このような背景から、製品レベルでのセキュリティ基準を設ける必要性が高まり、CRAの策定につながっています。

                 

                EUが目指す「セキュア・バイ・デザイン」の実現

                CRAでは「セキュア・バイ・デザイン(Secure by Design)」の考え方を重視しています。

                セキュア・バイ・デザインとは、製品の設計段階からセキュリティ対策を組み込んでいくという方針です。従来は開発後にパッチ対応するケースが多く、脆弱性が見過ごされやすい状況でした。この方法では、攻撃のリスクを根本的に減らすことができません。

                セキュア・バイ・デザインでは、製品仕様を決める初期段階から、暗号化やアクセス制御、認証機能などを組み込むことが要求されます。CRAはこのアプローチを製造業全体に広げ、安全な製品を標準とする環境づくりを進めようとしています。

                 

                消費者保護と製品安全の強化

                CRAのもう一つの重要な目的は、最終的な利用者である消費者の保護です。これまでは、多くの消費者は購入したデジタル製品にセキュリティリスクがあることを知らずに使用していました。特に自動アップデート機能がない製品や、サポートが終了している製品では、脆弱性が残ったままとなり、悪用されるおそれがあります。

                CRAでは、こうした状況を改善するため、製造者に対してアップデートの提供義務やリスク開示を求めています。安全な使用を前提とした製品流通を促進することで、消費者の信頼を高め、市場全体の健全化を図る狙いがあります。

                 

                CRAの具体的な要求事項と義務

                CRAでは、製品のライフサイクル全体にわたり、セキュリティ対策が義務付けられています。ここでは、CRAの中心的な要求事項を3つの観点から解説します。

                 

                製品ライフサイクルにおけるセキュリティ要求

                CRAでは、製品の企画から廃棄に至るまで、各フェーズでセキュリティ対策が求められています。

                各フェーズ セキュリティ対策
                設計段階 不正アクセスを防ぐ機能やデータの暗号化を組み込みます。
                製造段階 脆弱性のある部品やソフトウェアを使用しないように管理します。
                出荷後 アップデート体制や保守計画を整備します。

                例えば、出荷済み製品にセキュリティリスクが発見された場合でも、適切に対応できるような運用体制が必要です。こうした対応をライフサイクル全体で維持することが、CRA準拠の前提となります。

                 

                脆弱性管理義務

                CRAは、製品のリリース後に発見された脆弱性に対して、迅速かつ体系的に対応する義務を定めています。具体的には、重大な脆弱性が見つかった場合、24時間以内にENISA(欧州ネットワーク・情報セキュリティ機関)などの関係機関への通報と、適切な修正パッチの提供が必要です。

                また、少なくとも5年間はセキュリティアップデートを継続する義務が課されています。

                対応の迅速化のため、専門部署を社内に設置し、発見・評価・報告・修正のフローをあらかじめ構築しておくことが効果的です。

                 

                リスクアセスメントとドキュメント整備

                CRAでは製品開発に先立ち、製品が使用される状況と考えられるリスクを特定する「リスクアセスメント」を行い、その結果に基づいて設計することが求められます。つまり、どのような脅威を想定し、どの程度の対策を講じたかを明確にしておくことです。

                この内容は「技術文書(Technical Documentation)」として文章化し、審査機関や当局に提出できる状態で保管します。文章には、セキュリティ要件、設計思想、脆弱性管理の手順、試験結果などを含めることが必要です。ドキュメントの精度と整備体制は、CRA準拠の信頼性を左右する要素となります。

                 

                IT企業が準備すべきCRA対応策

                CRAの義務を果たすためには、製品が対象かどうかの判断、社内体制づくり、外部機関との連携などが求められます。ここでは、実施する内容を順に解説します。

                 

                自社製品がCRAの対象かどうかを確認する方法

                自社製品がCRAの対象に該当するかどうかを確認することが重要です。CRAの対象は、インターネットやほかの通信ネットワークに接続される「デジタル製品」とされています。判断の順序は次のとおりです。

                 

                1. 製品がネットワーク通信機能を持っているか
                2. 商業的にEU市場に供給されるか
                3. ほかのEU規制の対象になっていないか

                 

                例えば、Wi-Fi接続できる業務用端末やスマートアプリは対象となる可能性が高く、判断を誤ると規制違反につながるおそれがあります。判断が難しい場合は、専門コンサルや法務部門と連携するのがよいでしょう。

                 

                必要な技術文書と社内体制の構築方法

                CRAでは、製品のセキュリティ対策に関する詳細な技術文書の整備が義務付けられています。この文章には、製品の構成情報、リスクアセスメント結果、実装したセキュリティ対策、アップデート方針などを含めることが必要です。

                また、こうした情報を正確に収集・管理するためには、開発、法務、品質保証など、複数部門を横断した社内体制の構築が不可欠となります。例えば、セキュリティ担当者が開発現場と連携し、更新情報をドキュメントに反映するワークフローを設計するなどです。

                これらを準備しておくことで、規制対応時にかかる負担を軽減できます。

                 

                試験・認証機関との連携ポイント

                CRAでは、製品のリスクレベルによって第三者機関による審査・認証が必要になる場合があります。特に「重要な製品」に分類されるものは、自社による自己適合宣言ではなく、外部機関による技術評価と確認が要求されます。

                そのため、対象製品を扱う企業は、早い段階から該当する認証機関との連携を進めることが必要です。連携時には、評価に必要な技術文書や試験サンプルを迅速に提出できる体制を整えておくと、スムーズに進められるでしょう。

                手続きや申請フローを事前に把握しておくことで、リリーススケジュールの遅延を防ぐことができます。

                 

                CRA対応をビジネスチャンスに変える方法

                CRA対応は単なる義務ではなく、戦略的に活用すれば企業価値を高めるチャンスにもなります。ここでは、3つの視点から可能性を探ります。

                 

                セキュリティ品質を訴求して差別化

                CRAに準拠した製品は、セキュリティ面での信頼性が高いと判断されやすくなります。競合製品との差別化が難しい市場では、CRA準拠を「品質の証明」として訴求することが効果的です。

                例えば、企業向けのIoT製品で「CRA対応済み」と明記すれば、導入企業は安心して選びやすくなるでしょう。特に公共機関やインフラ関連など、セキュリティ要件が厳しい分野では有効な訴求ポイントになります。

                 

                海外市場での信頼獲得と販路拡大

                CRAへの対応は、EU市場での参入障壁を下げるだけでなく、グローバルなビジネス展開にも有利に働きます。EUはセキュリティ基準の先進地域のため、CRA準拠は「信頼性の証明」と見なされるでしょう。

                例えば、CRAに準拠した製品を扱う企業は、EU企業とのパートナーシップや現地調達案件に参加しやすくなります。またほかの地域でも、EU基準に追随する国が増えており、今後の国際競争力を高める意味でも対応は不可欠といえます。

                 

                CRA対応をきっかけにしたDX推進

                CRA対応には、製品開発プロセスや情報管理の見直しが必要です。これを単なる負担と捉えず、DX(デジタルトランスフォーメーション)への移行機会と捉えることで、組織全体の業務改善につなげられる可能性があります。

                例えば、セキュリティ文書の管理を紙からクラウドへ移行することで、他部門との連携の円滑化が可能です。また開発から運用までのデータを可視化すれば、リスクの早期発見や品質の向上にも役立つでしょう。

                 

                まとめ

                CRA(サイバーレジリエンス法)は、EU市場で求められる製品セキュリティの新基準です。対象商品の確認、設計段階からのセキュリティ対応、ドキュメント整備、第三者認証との連携など、企業に求められる準備は多岐にわたります。

                しかし、これを負担と捉えるのではなく、製品の信頼性向上や海外展開、DX促進のチャンスとして捉えることが重要といえるでしょう。CRA対応は、単なる規制遵守ではなく、未来の成長を見据えた戦略的な取り組みでもあります。

                弊社が提供する「ワンストップ型セキュリティ認証取得支援サービス」では、CRAの要求に沿った現状分析から適合評価、文書化、内部体制整備まで一括で対応しています。CRA対応を進めたい企業の信頼できるパートナーとして、実効性のある支援をご提供します。

                ワンストップ型セキュリティ認証取得支援サービス

                詳細資料をご希望の方は以下フォームよりメールアドレスをご登録ください。

                  メールアドレス(必須)

                  <個人情報の取り扱い>

                  ※上記内容は、弊社の掲げる個人情報保護方針に沿って管理し、本件に関するお問い合わせ、
                  お申込み等いただいた内容への対応のために利用する場合がございます。
                  お客様の同意なく目的外の利用や第三者への開示、提供することはございません。
                  詳細につきましては、当サイトの「個人情報保護方針」をご参照ください。

                  「個人情報保護方針」に同意し、送信する
                  (必須)


                  [2025年08月06日 時点]
                  2025年8月6日

                  Linuxの脆弱性を対策!被害事例と今すぐできる方法を解説

                  多くの企業で利用されているLinuxは、一般的に安全といわれています。しかし、システムの設計ミスや運用の不備によって脆弱性が生まれ、情報漏洩やサービス停止と言った被害を引き起こす可能性も少なくありません。

                  脆弱性とは、システムやソフトウェアに存在しているセキュリティ上の欠陥を指します。(※)

                  そのため、脆弱性は早期発見と早期対策が重要といえるでしょう。

                  この記事では、Linuxの脆弱性についての基本から、実際の被害事例、今すぐ実践できる対策などを分かりやすく解説します。

                  ※出典:総務省「脆弱性とは?

                   

                  Linuxの脆弱性とは何か

                  Linuxは高い安定性と信頼性があり広く利用されていますが、脆弱性が存在しているのも事実です。ここでは、Linuxに潜む脆弱性について、その定義や種類、原因を分かりやすく解説します。

                   

                  脆弱性の定義とセキュリティ上のリスク

                  脆弱性とは、ソフトウェアやシステムに存在するセキュリティ上の欠陥です。この欠陥が悪用されると、第三者による不正アクセスや情報漏洩の原因になります。

                  例えば、認証をすり抜けるコードの記述ミスや、古いライブラリを使用している場合などです。脆弱性を放置すると、攻撃者に侵入のきっかけを与えてしまうため、脆弱性の早期発見と適切な対策がシステムの安全を守る鍵となります。

                   

                  Linuxにおける主な脆弱性の種類

                  Linuxで多く見られる主な脆弱性は、権限昇格、バッファオーバーフロー、サービス妨害です。下表に主な脆弱性の種類をまとめました。

                  脆弱性の種類 説明
                  権限昇格 一般ユーザーの操作権限が、管理者レベルの権限を得てしまう状態です。
                  バッファオーバーフロー 一般ユーザーの操作権限が、管理者レベルの権限を得てしまう状態です。
                  サービス妨害(DoS攻撃) DoS攻撃はシステムを過負荷状態にして、正常なサービスを妨げます。

                  これらは古いカーネルやソフトウェアを利用している場合、簡単に成功してしまいます。脆弱性の種類を理解し、事前の対策が重要といえるでしょう。

                   

                  脆弱性が生まれる原因とは

                  Linuxの脆弱性が生まれる主な原因には、次のものがあります。

                  • ソフトウェアの設計ミスや実装ミス
                  • 開発時に十分なテストが行われていない
                  • オープンソースのためコードの公開範囲が広く、攻撃者が問題点を見つけやすい
                  • 長期間アップデートされていない
                  • 古いパッケージを使用している
                  • 管理者側の設定ミスや脆弱性情報を把握していない

                  このように技術的な問題だけでなく、運用面の甘さも脆弱性を生む原因となります。これらの原因を理解することで、予防の精度を高めることが可能となるでしょう。

                   

                  Linux脆弱性による被害事例

                  Linuxシステムに脆弱性がある場合、情報漏洩やサービス停止、企業の信頼失墜といった重大な被害を招く可能性があります。ここでは、代表的な事例を紹介します。

                   

                  システム侵害による情報漏洩

                  Linuxサーバーの脆弱性を突かれ、顧客情報や社内資料が不正に取得されることがあります。2024年に報告された「CVE-2024-6387」は、OpenSSHに関する脆弱性で、リモートからroot権限を奪取されるリスクです。(※)

                  この問題により外部からの第三者の侵入を許してしまうため、企業内の機密情報や個人情報が流出してしまう可能性があります。

                  ※出典:MITRE社「CVE-2024-6387

                   

                  サービス停止・業務への影響

                  「CVE-2021-3156(sudoのヒープバグ)」は、特権昇格に悪用される脆弱性として知られています。(※)

                  この脆弱性によってローカルユーザーがrootに権限昇格してしまう可能性があるため、悪用されるとシステムに重大な影響を及ぼします。その結果、企業のサービス停止や物流・販売システムの停止など、業務に大きな損害が出てしまう要因となるでしょう。

                  ※出典:MITRE社「CVE-2021-3156

                   

                  企業ブランドの信頼失墜

                  Linuxで利用されているファイル圧縮ツールの「XZ Utils」に悪意のあるコードが挿入されていました。2024年に「CVE-2024-3094」として報告されています。(※)

                  特定の条件が整うと、外部から攻撃者がSSHポート経由で接続できるようになる問題です。Linuxパッケージに「XZ Utils」を含めている場合、配布元の企業が攻撃経路を組み込んでいることになるため、企業の信頼を失墜させる要因となります。

                  ※出典:MITRE社「CVE-2024-3094

                   

                  Linux脆弱性をチェックし対策する方法

                  脆弱性は早期発見と迅速な対処が重要です。ここでは、脆弱性を調べる方法と、チェック後の基本的な対策方法を解説します。

                   

                  脆弱性情報の確認手段

                  Linux脆弱性を調べる際は、信頼性の高い情報源から最新の情報を得ることが重要です。国内ではIPAとJPCERTが運営するJVN(Japan Vulnerability Notes)があり、企業向けに脆弱性情報を提供しています。(※)

                  海外サイトでは、米国NISTのNVD(National Vulnerability Database)です。(※)

                  NVDでは、世界中の脆弱性情報をCVE番号(共通脆弱性識別子)付きで掲載しています。自社で使用しているソフトウェアやカーネルのCVE番号を検索し、影響範囲や深刻度を確認することで、優先的に対応すべき脆弱性が明確になります。

                   

                  ※出典:JVN(Japan Vulnerability Notes)「脆弱性関連情報と対策情報

                  NIST「国家脆弱性データベース

                   

                  自動スキャンツールの活用

                  自社のLinuxサーバーに脆弱性がないかどうかを自動的にチェックする方法として、スキャンツールの活用が有効です。代表的なものに「OpenVAS」や「Lynis」があり、いずれもオープンソースで利用できます。(※)

                  OpenVASは、ネットワーク経由で多様な脆弱性を検出し、レポートを生成します。Lynisは、コマンドラインで実行し、システム構成やパーミッション、パッケージの状態を総合的に診断可能です。いずれも継続的な運用を前提とし、定期的にレポートを確認することで脆弱性の見落としを防げます。

                  ※出典:Greenbone Networks GmbH「OpenVAS

                  CISOFY「Lynis

                   

                  定期的なパッチ適用・アップデートの徹底

                  脆弱性対策でもっとも基本的で確実なのが、セキュリティパッチの適用です。Linuxを使用するための環境を一つにパッケージングしたものを「Linuxディストリビューション」と呼びます。

                  「Red Hat」「Ubuntu」などのLinuxディストリビューションでは、脆弱性が発見されると対応パッチが随時提供される形です。特に深刻な脆弱性に関しては、緊急アップデートとして配信されることもあるため、随時適用することが重要となります。運用中のサーバーなど、すぐに適用が難しい場合は、適切なスケジュールと手順のもとで継続的にアップデートを行える体制づくりが大切です。

                   

                  Linux脆弱性対策の強化

                  組み込みLinuxの脆弱性対策を包括的に実施するには、Wind River Linux Servicesがおすすめです。脆弱性を検出するCVEスキャンから長期保守まで、企業が直面する不安に応える施策が可能となっています。

                   

                  CVE対応と長期サポートで脆弱性リスクを低減する

                  Wind Riverは、SBOM(Software Bill of Materials)やプラットフォームマニフェストを分析し、組み込みLinux環境に存在するCVEを自動検出します。またシステムの影響度の判定も可能です。これにより技術的な欠陥が解消され、リスクを抑えつつ長期にわたるサポートが可能となります。継続的な対応体制を整えることで、製品ライフサイクル全体の安全性を確保できます。

                   

                  セキュアブートと署名済みパッケージで信頼性を確保する

                  Wind River Linux Servicesは、セキュアブートとデジタル署名によって、ブート時の改ざん防止を実現します。これにより、マルウェアなどの不正なプログラムの起動を事前に防ぐ仕組みです。デジタル署名にはキー管理体制が不可欠となっており、Wind Riverでは設計や運用を支援します。組み込みLinux製品では、信頼できる起動の構築が製品信頼性の基盤となります。

                   

                  Yocto Projectベースの管理性と更新性を生かす

                  Wind River Linux Servicesは、Yocto Projectベースのディストリビューションを使用し、高度なカスタマイズ性と安定した更新機能を両立しています。開発後の更新機能や継続的な脆弱性対策、コンプライアンス文書、高品質なボードサポートパッケージなどです。

                   

                  まとめ

                  Linuxは高い信頼性がある一方で、設計や運用の不備により脆弱性が発生するリスクもあります。実際に情報漏洩やサービス停止などの被害事例も報告されており、定期的な脆弱性チェックとパッチ適用が不可欠です。

                  JVNやNVDによる脆弱性の情報収集、自動スキャンツールの活用に加え、Wind River Linux Servicesを活用したCVE対応や長期サポートの導入も有効です。Linux脆弱性対策は、技術面と運用面の両面から取り組む必要があります。

                  弊社のWind River Linux Servicesを利用することで、システム全体のセキュリティを継続的に維持することが可能です。

                  Wind River Linux Services

                  詳細資料をご希望の方は以下フォームよりメールアドレスをご登録ください。

                    メールアドレス(必須)

                    <個人情報の取り扱い>

                    ※上記内容は、弊社の掲げる個人情報保護方針に沿って管理し、本件に関するお問い合わせ、
                    お申込み等いただいた内容への対応のために利用する場合がございます。
                    お客様の同意なく目的外の利用や第三者への開示、提供することはございません。
                    詳細につきましては、当サイトの「個人情報保護方針」をご参照ください。

                    「個人情報保護方針」に同意し、送信する
                    (必須)


                    [2025年08月06日 時点]
                    2025年8月6日

                    CONTACT

                    まずはお気軽に
                    お問い合わせください!

                    PAGE TOP