欧州サイバーレジリエンス法（CRA）への対応を、今すぐ確かなものに。

DEKRAを選ぶ理由：標準化の最前線に立つ専門性

• 規格開発への貢献: CEN/CENELEC JTC13/WG9（水平規格）および ETSI CYBER WG（垂直規格）のメンバーとして、規格策定の議論をリードしています。
• ENISAとの協力: 欧州連合サイバーセキュリティ機関（ENISA）による「EUCC（欧州共通基準）とCRAの相互運用パイロットプロジェクト」の支援組織として選定されており、CRA適合性評価の仕組みづくりを担っています。
• グローバルなネットワーク: スペイン、オランダ、そして日本を含む世界各地に、IEC 62443やRED（無線機器指令）の専門知識を持つ試験所を展開しています。

プレアセスメントサービスのメリット

1. ワークショップの開催: セキュリティのスペシャリストがCRAについて基本的な対応方針についてのダウンロードを実施します。
2. ギャップ分析チェックリスト: 貴社の製品仕様や開発プロセスを、将来の整合規格（EN 40000-1-2、40000-1-3）の要件と比較可能なチェックリストを提供し、不足している要素を明確にします 。
3. 製品機能要件への対応: 既に草案が公開されている「重要製品（クラスI・II）」に向けた垂直規格の動向を踏まえた高度な評価を提供します。

主要なCRAタイムライン

DEKRAの包括的なソリューション

DEKRAについて

はじめに

本ブログでは、これまでも度々触れてきた、Zephyr® について、今回は、AMD™ 社製 KV260 で動作させる手順の概要について紹介します。

KV260 は、Vision AI Starter Kit として位置付けのリファレンスで、ARM Cortex a53、ARM Cortex r5、FPGA を搭載しています。

下記サイトの内容に従い、KV260 ボードで Zephyr® のコードを実際に動作させました。

① Zephyr® 生成環境の構築、および生成手順

参照サイト：https://docs.zephyrproject.org/latest/develop/getting_started/index.html

② KV260 Development Board RPU Cortex-R5 で Zephyr Hello_world デモコードを動作させる手順

参照サイト：https://docs.zephyrproject.org/latest/boards/amd/kv260_r5/doc/index.html
上記 1) で生成した、Zephyr® コードを KV260 ボードで動作させます。
より詳細には、r5 で動作する Zephyr® コードを、a53 で動作している Linux 経由で実行しています。

③ KV260 にて、Linux を経由せず Zephyr® コードを r5 で動作させる手順

作業環境として、Ubuntu 22.04 LTS を使用しました。
それでは、手順詳細を順に紹介していきます。

①Zephyr® 生成環境の構築、および生成手順

手順の詳細は以下のサイトを参照しました。
参照サイト：https://docs.zephyrproject.org/latest/develop/getting_started/index.html

作業手順(参照したサイトの内容から抜粋しています)

Install dependencies(依存パッケージのインストール)

Ubuntu 22.04 LTS で必要となるパッケージをインストールします。

$ sudo apt update
$ sudo apt upgrade
$ sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1

Get Zephyr and install Python dependencies(Zephyr® の取得および Python® 依存関係のインストール)

Create a new virtual environment(新しい仮想環境の作成)

新しい仮想環境を作成します。

$ mkdir zephyrproject
$ cd zephyrproject
$ python3 -m venv ./zephyrproject/.venv
* python3 等がインストールされていなければ、以下を実行します。
$ sudo apt install python3-venv

Activate the virtual environment(仮想環境の有効化)

仮想環境を有効化します。

$ source ./zephyrproject/.venv/bin/activate

Install west(west のインストール)

west をインストールします。

$ pip install west

Get the Zephyr source code(Zephyr® ソースコードの取得)

Zephyr® ソースコードを取得します。

$ west init ./zephyrproject
$ cd ./zephyrproject
$ west update

Export a Zephyr CMake package(Zephyr® CMake パッケージのエクスポート)

Zephyr® CMake パッケージをエクスポートします。これにより、CMake は Zephyr® アプリケーションの生成に必要な定型コードを自動的に読み込むことができるようになります。

$ west zephyr-export

Install Python dependencies using west packages(west packages を使用して Python® 依存関係をインストール)

Zephyr® の west 拡張コマンドを用いて、Python® 依存関係をインストールします。

$ west packages pip --install

Install the Zephyr SDK(Zephyr® SDK をインストールする)

Install the Zephyr SDK using the west sdk install(west sdk install を使用し、Zephyr® SDK をインストールします)

$ cd ./zephyr
$ west sdk install

サンプルコードの生成

$ west build -p always -b <your-board-name> samples/basic/blinky
^^^^^^^^         ^^^^^^^^^^
kv260_r5         samples/hello_world

今回は、hello_world を Build するので、

$ west build -p always -b kv260_r5 samples/hello_world

hello_world は、~/zephyrproject/zephyr/samples/hello_world/ 以下にあります。

生成の結果、以下に、zephyr.elf が生成されます。

~/zephyrproject/zephyr/build/zephyr/zephyr.elf

②KV260 Development Board RPU Cortex-R5 で Zephyr Hello_world デモコードを動作させる手順

手順の詳細は以下を参照しました。
参照サイト：https://docs.zephyrproject.org/latest/boards/amd/kv260_r5/doc/index.html

実際の手順は以下の通りでした。

起動用 SD Card image のダウンロード

以下のサイトより、OpenAMP を含んだイメージをダウンロードします。
参照サイト：https://www.xilinx.com/member/forms/download/xef.html?filename=petalinux-sdimage_xilinx-k26-starterkit.wic.xz

以下のコマンドで、SD Card 書き込みます。

$ sudo dd of=/dev/sdb if=Downloads/amd/petalinux-sdimage_xilinx-k26-starterkit.wic

デモコードを 対象機にコピー

前の手順で生成した zephyr.elf を使います。
開発環境側(Ubuntu 22.04 LTS)から以下のコマンドで対象機に zephyr.elf をコピーします。

$ scp <path_to>/zephyr.elf petalinux@<board-ip-address>:/home/petalinux

実行例は以下の通りです。

$ scp workspace/zephyrproject/zephyr/build/zephyr/zephyr.elf petalinux@192.168.13.205:/home/petalinux
petalinux@192.168.13.205's password:
zephyr.elf 100% 375KB 4.0MB/s 00:00

下記メッセージが表示されてエラーが出る場合は、-O オプションを使用します。

<エラーメッセージ>
sh: line 1: /usr/libexec/sftp-server: No such file or directory
scp: Connection closed

$ scp -O workspace/zephyrproject/zephyr/build/zephyr/zephyr.elf petalinux@192.168.13.205:/home/petalinux
petalinux@192.168.13.205's password:
zephyr.elf 100% 375KB 4.0MB/s 00:00

対象ボード側で zephyr.elf がコピーされていることを確認します。

xilinx-k26-starterkit-20221:~$ pwd
/home/petalinux
xilinx-k26-starterkit-20221:~$ ls
zephyr.elf <<< zephyr.elf がコピーされた
xilinx-k26-starterkit-20221:~$

重要

公式手順に記載されている以下の内容に従い、
対象ボード側の /lib/firmware 以下にも zephyr.elf をコピーします。

After that move the file to /lib/firmware directory, then you be able to start the firmware on the desired RPU via remoteproc with:

デモコードの実行に従い、対象ボード側のコンソールは、r5 の出力用に使用するため ssh 接続で操作します。

$ ssh petalinux@192.168.13.249
petalinux@192.168.13.249's password:
xilinx-k26-starterkit-20221:~$ sudo -i
Password:
root@xilinx-k26-starterkit-20221:~# pwd <<< target 側の shell
/home/root
root@xilinx-k26-starterkit-20221:~# cd ../petalinux
root@xilinx-k26-starterkit-20221:/home/petalinux# ls
xilinx-kv260.tar.gz zephyr.elf
root@xilinx-k26-starterkit-20221:/home/petalinux# ls -l
total 177512
-rwxr-xr-x 1 petalinux petalinux 449772 Aug 27 21:49 zephyr.elf
root@xilinx-k26-starterkit-20221:/home/petalinux#
root@xilinx-k26-starterkit-20221:/home/petalinux# echo zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware
root@xilinx-k26-starterkit-20221:/home/petalinux# echo start > /sys/class/remoteproc/remoteproc0/state

コンソール側の結果

*** Booting Zephyr OS build v4.3.0-1097-g5220936bbc02 ***
Hello World! kv260_r5/zynqmp_rpu

上記出力が対象ボード側のコンソールに表示されました。

なお、本作業は、2025年12月9日に実施したものです。

③KV260 にて、Linux を経由せずに Zephyr® コードを r5 で動作させる手順

本手順では、KV260 の基本構成に基づく Vivado™ XSA ファイルを使用します。

(注) XSA ファイルについて
XSA(eXtensible System Archive)ファイルとは、FPGA/SoC 設計のハードウェア情報(IP、ピン配置、クロック、メモリ設定など)と作成時の Vivado™/Vitis™ バージョンなどのメタデータをまとめたアーカイブファイルです。本手順では .xsa ファイルが必要で、生成には、Vivado™ を使用します。

Vitis™ の起動 (Vitis™ Embedded を使用)

Vitis™ は、AMD™ FPGA processors のためのアプリケーションソフトウェア開発環境です。
以下のサイトより、Vitis™ Embedded をダウンロードします。(本記事では、2025.1 を使用)

参照サイト：https://japan.xilinx.com/support/download/index.html/content/xilinx/ja/downloadNav/vitis.html

Worksapce の作成

作業用フォルダの作成と初期化を行います。
あらかじめ、作業用フォルダを作成します(例：$ mkdir -p workspace/kv260_zephyr)。

次に、Vitis™ メニューにて、
[File] [Set Workspace …] を選択し、kv260_zephyr を指定します。

Platform Component の作成

Vivado™ で設計した XSA ファイルに基づき、BSP、FSBL を生成するための Platform Component を作成します。Platform Component は、Vivado™ で設計したハードウェア情報(XSA ファイル)に基づき、BSP(Board Support Package)、FSBL(First Stage BootLoader)を生成するためのプロジェクトです。これを作成します。

VITIS EXPLORER にて、[Create Platform Component] を選択します。
Component name に任意の名称を入力します(本例では、kv260_zephyr)(図1)。入力後、[Next]ボタンを押下します。

図1

[Hardware Designe(XSA) For Implementation] の [Browse]ボタンを選択し、あらかじめ作成しておいた .xsa ファイルを指定します(図2)。指定後、[Next]ボタンを押下します。

図2

[Generate Boot artifacts] がチェックされていること、および[target processor to create FSBL:] が、cortexa53 になっていることを確認します(図3)。確認後、[Next]ボタンを押下します。

図3

Summary の画面にて、[Finish]ボタンを押下します。
これで、Platform Component の作成が完了します。

Platform Component の生成

FSBL(fsbl.elf)を生成します。
[Build]ボタンが追加されているので(図4)、選択して、生成を実施します。

図4

fsbl.elf が生成されます(図5)。

図5

Boot Image の作成

生成した fsbl.elf と 動作させたいアプリケーションを結合し、起動可能なイメージである、BOOT.bin を生成します。

上記動作させたいアプリケーションを生成した zephyr.elf とします。

Vitis メニューにて、
[Vitis] [Create Boot Image] [Zynq Ultrascale+] を選択します。
図6 の [+]ボタンを押下し、fsbl.elf を登録します。
[File Path] に fsbl.elf への path を指定します。
[Type] は自動的に “bootloader” が選択されます。
[Destination CPU] は a53-0 を選択し、[OK]ボタンを押下します。

図6

続けて、再度[+]ボタンを押下し、zephyr.elf を登録します。
[Type] は、datafile、[Destination CPU] は r5-0 を選択します(図7)。
[OK]ボタンを押下します。

図7

[Output BIF File Path] に任意のファイル名をパスと併せて入力します。
[Output Image] のファイル名が BOOT.bin になっていることを確認します(図8)。
赤枠のファイル名の順序が異なる場合は、[+] 右側にある矢印で変更できます。
確認後、[Create Image] ボタンを押下します。
BOOT.bin、および bootImage.bif が生成されます。
Vitis での操作はこれで終了です。

図8

KV260 Flash Memory への BOOT.bin のコピー

KV260 の web サーバーによる BOOT.bin イメージのコピー

KV260 ボードの FWUEN(Firmware Update) Button を押したまま、RESET Button を押すと、web サーバーが使用可能になります。
ブラウザから http://192.168.0.111 に接続します。
KV260 の Flash Memory は、Image A、Image B の 2 領域があり、いずれか一方を選択して使用します。

BOOT.bin イメージのコピー手順は以下の通りです(図9)。

• 1) Recover Image 下の [Browse] ボタンで、<path to>/BOOT.bin を選択
• 2) [Select Image to bo recovered] で、Image A または Image B を選択
• 3) [Upload] ボタンを押下してコピーを実施

次に、(図9) の Boot Image Status 下にて、

• 4) [Requested Boot Image] で、コピーした Image A または Image B を選択
• 5) コピーした側の Image の Bootable ボタンを有効化
• 6) [Configure] ボタンを押下

これで、コピー処理および BOOT.bin を動作させる準備が完了します。

図9

 

BOOT.bin の起動

電源 OFF —> ON、または RESET ボタンで BOOT.bin を動作させます。
コンソールに、以下の出力が表示されました。

Hello World! kv260_r5/zynqmp_rpu

最後に

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

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

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

---

• AMD™、Vivado™、Vitis™ は、Advanced Micro Devices, Inc. の商標または登録商標です。
• Zephyr® は The Linux Foundation の商標です。
• Python® は Python Software Foundation の登録商標です。

---

[2026年01月20日 時点]

ソフトウェアに含まれる部品やライセンス、脆弱性を一覧化して「見える化」する仕組みがSBOM（Software Bill of Materials）です。SBOMには、複数のフォーマットが存在しており、どれを選ぶべきか悩んでいる方も少なくないでしょう。

この記事では、国際的なガイドラインや実務事例を踏まえながら、主要フォーマットの特徴と得意分野を整理します。また、目的別の選び方や、自動生成ツールとの連携、運用のベストプラクティスなども解説しています。

 

SBOMフォーマットの基礎知識

SBOMフォーマットは、ソフトウェア部品の情報を共通の「書き方」にそろえるための仕組みです。ここでは、フォーマットが果たす役割と、SPDX／SPDX LITE／CycloneDX／SWIDタグの違い、求められる背景を解説します。

 

SBOMフォーマットの役割

SBOMフォーマットの役割は、ソフトウェア部品の情報を機械が扱いやすい形に整え、組織やツールをまたいでも同じ意味で読めるようにすることです。

例えば、Excelで自由に作った部品表は、人間には分かりやすくても、ツールによる自動解析や他社との連携には向きません。そこで、どの項目を、どの程度の粒度で、どのような形式で記録するのかを定めた標準フォーマットが重要となります。標準フォーマットを使うことで、ライセンス管理や脆弱性管理を効率化することが可能です。

経済産業省の資料では、SBOMは「機械処理可能な形式」で提供することが前提とされています。（※）

このように、SBOMフォーマットは自動生成や継続的なモニタリングを支える基盤として重要です。

※出典：経済産業省「ソフトウェア管理に向けた SBOM（Software Bill of Materials）の導入に関する手引 ver 2.0」（Page 6）

 

主要フォーマット（SPDX・SPDX LITE・CycloneDX・SWIDタグ）の定義

SBOMは、「ソフトウェアの材料表」と考えると、分かりやすいでしょう。材料表の書き方にはいくつかの決まった型があり、代表的なものが、SPDX、SPDX LITE、CycloneDX、SWIDタグです。それぞれ、得意分野や使われ方が異なります。

 

SBOMには複数のフォーマットがあり、得られる情報の粒度や得意とする用途が変わります。日本企業では、既存のExcel台帳と親和性の高いSPDX LITEを入り口として採用し、その後に自動生成されたSPDXやCycloneDXと組み合わせていく進め方も増えています。

自社が「ライセンスをきちんと管理したいのか」「脆弱性を追跡したいのか」「資産管理を強化したいのか」といった目的を整理した上で、最適なものを導入していく方法がよいでしょう。

 

SBOMフォーマットが必要とされる背景

現在のソフトウェア開発では、メーカーがすべて製作しているわけではなく、OSS（オープンソースソフトウェア）や外部ライブラリを組み合わせて作っています。そのため、「何がどこに使われているのか」が見えにくくなり、トラブル時に影響範囲を追跡するのが難しくなっています。

背景と、SBOMが担う役割は下表のとおりです。

 

こうした背景から、SBOMは必要な資料として注目されています。特に、重大な脆弱性が公表された際に、どの製品に影響があるのかを迅速に把握することは、インシデント対応のスピードに大きく関係します。

また、海外の政府調達や大手顧客との取引では、SBOMの提出が条件となるケースも増えつつあります。

標準フォーマットでSBOMを整備しておけば、社内のセキュリティ対策だけでなく、取引先・監査機関に対して分かりやすく説明が可能となるでしょう。そのため、SBOMフォーマットは技術だけでなく、ビジネス上の信頼を支える土台になります。

※出典：

NIST（米国国立標準技術研究所）「大統領令14028号、国家のサイバーセキュリティの向上」

経済産業省「ソフトウェア管理に向けた SBOM（Software Bill of Materials）の導入に関する手引 ver 2.0」

警察庁「Javaライブラリ「Apache Log4j」の脆弱性（CVE-2021-44228）を標的とした攻撃の観測について」

 

SBOMフォーマットの違い

SBOMフォーマットは、それぞれ得意分野や運用しやすい場面が異なります。ここでは、SPDXとその簡易プロファイルであるSPDX LITE、CycloneDX、SWIDタグの特徴を整理し、「どの場面でどれを選ぶか」をイメージしやすいように解説します。

 

SPDXおよびSPDX LITEの特徴と得意領域

ソフトウェアの部品情報を正確に管理したい組織では、記録形式の違いを理解することが重要です。SPDXは詳細な情報を扱う標準仕様で、SPDX LITEは日本の実務に合わせて必要最小限の項目に絞った軽量版です。用途や体制に応じて使い分けることで、運用負荷を抑えながら適切に管理できます。

以下に、SPDXとSPDX LITEの特徴をまとめました。

 

SPDXは、ライセンス名の統一や著作権表記など、多くの情報を一つの形式にまとめられるため、国際的な取引や厳密なコンプライアンス対応が求められるケースに向いています。

一方で、最初からSPDXを使うと項目数の多さが負担になる場合も考えられるでしょう。SPDX LITEはこの負担を減らしながら国内組織間で必要な情報をやり取りできるように最適化された書式です。

既存の台帳やスプレッドシートとも組み合わせやすく、段階的にSBOMを導入したい組織に適しています。組織の規模と目的に応じて両者を使い分けることで、無理のないSBOM運用が実現可能です。

※出典：

Linux Foundation「SPDX」

OpenChain日本ワークグループ「SPDX LITE」

 

CycloneDXの特徴と得意領域

CycloneDXは、ソフトウェアの安全性を確保するために必要な情報を整理しやすい形式です。部品同士のつながりや、すでに報告されている脆弱性を扱いやすく設計されているため、問題発生時の影響範囲を素早く把握できます。

セキュリティ管理に重点を置く組織で効果を発揮するでしょう。主な特徴は、次のとおりです。

 

CycloneDXは、依存関係の把握と脆弱性管理に強みを持つ形式です。どのコンポーネントがどの製品に影響するのかを追跡しやすい仕組みが備わっており、セキュリティチームが利用するツールとも連携しやすく設計されています。

クラウド構成やサービスも扱えるため、現代の複雑なシステム構成にも対応が可能です。脆弱性の早期発見と影響分析を重視する組織にとって、CycloneDXは有力な選択肢となります。

※出典：OWASP「CycloneDX」

 

SWIDタグの特徴と得意領域

SWIDタグは、PCやサーバに「どのソフトがインストールされているか」を正確に把握するための仕組みです。製品名・バージョン・提供元などの情報を統一形式で記録できるため、資産管理やライセンス管理を効率化したい組織で活用されています。

SWIDタグの主な特徴は、次のとおりです。

 

SWIDタグは、実際に端末へインストールされた製品を正確に識別できる点が大きな強みです。NIST（米国国立標準技術研究所）が推奨基盤として位置づけていることもあり、資産管理やパッチ適用管理の精度を高めたい組織で採用が進んでいます。

手動による台帳管理では限界が生じやすい大規模環境でも、SWIDタグを利用することで自動的に構成情報を収集でき、SBOMとの併用でさらに透明性を高めることが可能です。ソフトウェア保有状況を正確に管理したい組織に適した手法といえます。

※出典：

NIST（米国国立標準技術研究所）「ソフトウェア識別 (SWID) タグ付け」

ISO「ISO/IEC 19770-2:2015」

 

SBOMフォーマットの選び方

SBOMフォーマットは、目的に応じて、向き不向きが異なります。ここでは、ライセンス管理、脆弱性・依存関係管理、サプライチェーン要求という3つの観点から選び方を解説します。

 

ライセンス管理を重視する場合の選択肢

ソフトウェアに含まれる部品ごとのライセンス情報を正確に把握したい場合、記録できる項目の多さが重要になります。特に組織が外部とやり取りする際は、著作権表記やライセンス条件を統一的に扱える形式が重要です。そのため、まず候補になるのがSPDXとなります。

SPDXの特徴は次のとおりです。

 

• ライセンス名を統一的に扱える仕組みが整っている
• 著作権表記や由来情報など詳細な項目を記録できる
• 国際的な標準として認知されており、取引との整合性を取りやすい
• 帳票や社内台帳とのひも付けがしやすく運用に組み込みやすい
• 簡易運用にはSPDX LITEを併用して負荷を調整できる

 

ライセンス管理では、どの部品がどの条件で利用できるかを正確に示す必要があります。SPDXは、こうした要件に応えるための項目がそろっており、グローバルなレベルで実務に使われている点が大きな強みです。

すべてを詳細に管理するのが難しい場合でも、SPDX LITEを組み合わせることで運用負荷を抑えつつ、必要な情報だけを正確に整理できます。

まずは自社がどこまで確認したいのかを明確にし、それに合わせてSPDXを中心に構成すると管理しやすくなります。

※出典：

Linux Foundation「SPDX」

OpenChain日本ワークグループ「SPDX LITE」

 

脆弱性管理・依存関係管理を重視する場合の選択肢

どの部品がどの部品に依存しているか、また既知の脆弱性がどこに影響するのかを把握したい場合は、依存関係を扱いやすい形式が最適です。脆弱性データベースやスキャンツールと連携しやすいことも重要で、この条件を満たす形式としてCycloneDXが選ばれることが増えています。

CycloneDXの特徴としては、次のとおりです。

 

• 依存関係を標準化された形で表現できる
• 既知の脆弱性情報との関連づけがしやすい
• セキュリティツールとの連携事例が多く実務に取り入れやすい
• ソフトウェアに限らず、クラウド構成やサービスも扱える
• 影響範囲の特定がしやすく調査時間の短縮につながる

 

CycloneDXは、多くのセキュリティツールで利用できる形式として広く採用されています。例えば、SBOMを取り込んで脆弱性を調べるツールや、依存関係を分析するCIサービスと組み合わせると、問題のある部品の特定が自動化されます。

この仕組みにより、影響範囲の把握が効率的になるといえるでしょう。

※出典：OWASP「CycloneDX」

 

サプライチェーン要求・規制対応を重視する場合の選択肢

取引先や行政機関からSBOMの提出を求められるケースが増えています。このような状況では、自社だけでなく相手の要件に適合する形式を選ぶことが必要です。特に国際的なガイドラインでは、複数の標準形式が前提となっています。

主な要求としては、次のとおりです。

 

• NIST（米国国立標準技術研究所）・NTIA（米国商務省電気通信情報局）の最小要素では複数形式が標準として扱われている
• CISA（米国サイバーセキュリティ・インフラセキュリティ庁）が調達要件にSBOMを入れ始めている
• 日本でも国際機関と連携したSBOM普及が進んでいる
• 形式を固定せず複数フォーマットを扱える体制が必要
• ほかの形式へ変換できる運用が将来の監査にも有利になる

 

規制対応やサプライチェーン要求では、自社だけで形式を決めるのではなく、相手が何を前提にしているかを踏まえて選択することが不可欠です。国際的な文書では、SPDX・CycloneDX・SWIDのいずれも標準として扱われており、一つの形式だけに依存すると将来的な要件変更に対応しづらくなります。

複数形式の扱いを前提にし、必要に応じて変換できる運用を整えることで、取引先や監査機関とのコミュニケーションがスムーズになるでしょう。長期的な視点で見ても、柔軟な運用体制が組織のリスク低減につながります。

※出典：

NIST（米国国立標準技術研究所）「大統領令14028号、国家のサイバーセキュリティの向上」

CISA（米国サイバーセキュリティ・インフラセキュリティ庁）「2025 ソフトウェア部品表（SBOM）の最小要素」

経済産業省「サイバーセキュリティのためのソフトウェア部品表（SBOM）の共通ビジョンに関する国際ガイダンスに国家サイバーセキュリティオフィス（NCO）と共同で署名」

 

SBOMフォーマットの作り方

SBOMを継続的に活用するには、手動作成と自動生成をうまく組み合わせ、機械可読なフォーマットで管理することが重要です。ここでは、SPDX LITEを使った手動作成と、自動生成・フォーマット変換のポイントを解説します。

 

手動作成を前提としたSPDX LITEの活用ポイント

SPDX LITEは、最低限の項目だけをまとめたシンプルな書式で、Excelを使って手作業で整理しやすい点が特徴です。自動生成ツールが整っていない環境でも扱いやすく、既存の部品表や納品情報をそのまま反映しやすいフォーマットとして、日本の組織でも採用例が増えています。

活用のポイントとしては、次のとおりです。

 

• 必要最低限の情報だけに絞られているため、手作業でも作成しやすい
• Excelで記入・更新でき、既存台帳との整合を取りやすい
• 日本企業の実務に合うように設計され、取引先間でも扱いやすい
• ライセンス情報の漏れや記載漏れを防ぐ「型」として機能する
• 将来フルSPDXへ移行するときの土台として再利用しやすい

 

SPDX LITEは、いきなり本格的な自動生成に踏み切れない組織でも無理なく始められる形式です。まずは手動で必要項目を整え、運用が軌道に乗ってからフルSPDXや自動化へつなげるという段階的アプローチを取りやすい点が強みです。

小規模チームでも導入しやすい現実的な選択肢といえます。

※出典：

Linux Foundation「SPDX」

OpenChain日本ワークグループ「SPDX LITE」

 

CI/CDパイプラインへのSBOM自動生成を組み込む

SBOMを常に最新の状態に保つには、開発やリリースのタイミングで自動生成する仕組みを組み込むことが効果的です。CI/CDパイプライン（ソフトウェア開発→テスト→リリースまでを自動で流れる仕組み）の中で処理を自動化すれば、更新漏れを防ぎながら、依存関係や脆弱性の変化を継続的に把握できます。

結果として、管理負荷を大幅に減らせるようになります。自動生成の特徴は次のとおりです。

 

• ビルド時にSBOMが自動生成され、常に最新の状態を維持できる
• 人手依存を減らし、情報の抜け漏れや記入ミスを防ぎやすい
• 脆弱性チェックなど複数の自動化ツールと連携しやすい
• 生成されたSBOMをリポジトリや成果物として一元管理できる
• 手動形式（SPDX LITE）と併用する運用にも取り入れやすい

 

CI/CDパイプラインでのSBOM自動生成は、日々変化する依存関係や脆弱性への対応をスムーズにします。手動では追いきれない部分を機械に任せることで、品質を保ちながら運用負荷を抑えることが可能です。

SPDX LITEとの併用も可能なため、組織の成熟度に合わせて柔軟に取り入れられます。

※出典：

Linux Foundation「SPDX」

OpenChain日本ワークグループ「SPDX LITE」

 

フォーマット変換と統合管理の方法

組織や取引先ごとに求められるSBOM形式が異なる場合は、一度情報を集約し、必要に応じて形式を切り替えられる仕組みが役立ちます。専用ツールを使えば、自動生成した形式を別の形式へ変換でき、複数のフォーマットが混在する環境でも整理が可能です。

フォーマット変換が可能になることで、得られるメリットは次のとおりです。

 

• 一度集約したSBOMを別形式へ変換でき、取引先ごとに対応しやすい
• 複数形式を受け付けて統合管理できるツールを活用できる
• 異なる開発チームや外部パートナーとの情報差を吸収しやすい
• 手動形式（SPDX LITE）は項目マッピングで他形式と併用できる
• 将来の調達要求や監査に備え、柔軟な対応体制をつくれる

 

フォーマット変換や統合管理の仕組みを整えておくことで、組織内外でSBOMの形式がそろわなくても対応しやすくなります。自動生成形式とSPDX LITEの双方を無理なく扱える体制をつくれば、現場の実態に合った運用を維持しながら、取引先や規制要求にも確実に応えられるようになるでしょう。

 

SBOMフォーマット運用のベストプラクティス

SBOMは、継続運用の仕組みに乗せることが重要です。ここでは、SBOMを自社で活用するための仕組みについて解説します。

 

依存関係・脆弱性の継続的モニタリングを仕組み化

多くのソフトウェアは、さまざまな部品を組み合わせて作られており、弱点がどこに潜んでいるのかをつかむのが難しいです。SBOMを活用し、専用ツールで自動的に監視する仕組みを整えることで、素早く対応が可能となります。

例えば、次の運用項目を仕組み化するのがよいでしょう。

 

依存関係や脆弱性を把握する作業は、人の目だけでは追いきれない場面が多くあります。SBOMを専用ツールに連携させることで、公開された脆弱性にどの製品が関係するかを自動で確認でき、優先順位を付けた対応が可能です。

SBOMを単なる一覧ではなく「継続的に更新される情報源」として扱うことで、セキュリティ対策の精度が向上し、チーム全体の負担も軽減できます。

 

SBOM提出要求に備えて更新フローを整備

顧客や規制当局からSBOMの提示を求められるケースが増えています。慌てず対応するには、日々の変更を確実にSBOMへ反映できる仕組みを事前に整えておくことが重要です。

次のような更新フローがよいでしょう。

 

SBOMは作って終わりではなく、製品の更新に合わせて正確に保つ必要があります。更新フローをあらかじめ決めておけば、提出依頼があっても迷わず対応でき、監査や調達プロセスでも信頼される資料として扱ってもらえます。

特に「誰が」「いつ」「どの形式で」作るかを明確にすることで、組織の中で共通した運用が実現可能です。継続的な更新を前提に仕組みを整えることが、SBOMを価値ある情報として保ち続けるカギになります。

 

社内の標準ルールとしてフォーマット運用を定着

SBOMを社内で活用するには、プロジェクトごとに形式が異なる状態を避け、共通ルールを決めることが重要です。統一されたやり方があるほど品質が安定し、関係者間で共有しやすくなるでしょう。

運用のポイントは次のとおりです。

 

SBOMの形式や作成方法がチームごとに異なると、管理の負担が増え、取引先への説明も難しくなります。最初に共通ルールを定めておけば、どの担当者でも同じ品質のSBOMを作成できるようになり、組織全体の成熟度を高めることが可能です。

また、小さな成功体験を積み重ねながら改善していけば、自然と運用が根付き、SBOMが日常的に活用される環境が整います。

 

SBOMフォーマットの国際標準動向

SBOMは、NIST・CISAなどの政府機関や、SPDX・CycloneDXといった標準化団体の取組やガイドラインによって方向性が形づくられています。ここでは、その最新動向を整理し、今後の方針検討に役立つ視点を解説します。

 

NISTのSBOM要件とフォーマットの位置づけ

NIST（米国国立標準技術研究所）は、米国大統領令14028に基づくソフトウェアサプライチェーン対策の中で、SBOMを重要な要素として扱っています。NISTの「Software Security in Supply Chains」では、SBOMをベンダーリスク評価やOSS管理、脆弱性管理と並ぶ基盤的な仕組みとして位置づけています。

一方で、特定フォーマットだけを指定するのではなく、「進化する標準やツール」の一つとして、機械可読なSBOMの活用を推奨するスタンスとなっています。NISTのガイダンスを土台にしながら、標準フォーマットに沿ってSBOMを整備しておくことで、海外の調達要件や将来の規制にも対応しやすくなります。

※出典：NIST（米国国立標準技術研究所）「大統領令14028号、国家のサイバーセキュリティの向上」

 

CISAのSBOM要件

CISA（米国サイバーセキュリティ・インフラセキュリティ庁）は、SBOMの「Minimum Elements（最小要素）」を定義し、2025年には改定版のドラフトも公表しています。2025年版では、従来のNTIA2021版を引き継ぎつつ、「データフィールド」「自動化支援」「運用プロセス」の3つの観点から、より具体的な要求事項が整理されています。

例えば、コンポーネント名やバージョンだけでなく、サプライヤ情報や依存関係の表現、機械可読な形式での配布などが求められています。

また、2025年時点ではドラフトであり、パブリックコメントを通じて国際的な調整を進めていることも明示されています。Minimum Elementsは、現在のベストプラクティスをまとめた指針と位置づけられており、製品輸出やグローバル展開を想定している場合は、これを念頭に置いてSBOM項目やフォーマットを設計しておくことが重要です。

※出典：

CISA（米国サイバーセキュリティ・インフラセキュリティ庁）「2025 ソフトウェア部品表（SBOM）の最小要素」

CISA（米国サイバーセキュリティ・インフラセキュリティ庁）「ソフトウェア部品表（SBOM）」

 

SPDX・CycloneDXの最新アップデート

SPDXとCycloneDXの動向を押さえることは、今後のフォーマット選定に直結します。SPDXはLinux Foundationが主導する標準で、仕様はISO/IEC 5962として国際規格化されているものです。（※）

2024年にはSPDX 3.0および3.0.1が公開され、セキュリティやAIなど幅広いユースケースに対応できるようモデル拡張が進んでいます。（※）

一方、CycloneDXはOWASPプロジェクトとして進化を続け、v1.6が2024年に公開されました。このバージョンでは、暗号鍵やアルゴリズムを管理する「Cryptographic BOM（CBOM）」や「アテステーション（CDXA）」など、セキュリティ運用を意識した機能が追加されました。（※）

また、CycloneDX v1.6は、Ecma InternationalによりECMA-424として標準化されており、2025年にはv1.7発表と第二版標準化の予定も公表されています。（※）

このような国際標準化の流れを踏まえると、SPDXとCycloneDXはいずれも長期的に安心して採用しやすいフォーマットといえます。

※出典：

Linux Foundation「SPDX」

spdx/spdx-spec「パッチリリース 3.0.1」

CycloneDX「CycloneDX v1.6 リリース」

ecma「ECMA-424」

CycloneDX「CycloneDX v1.7」

 

まとめ

今回は、SBOMフォーマット（SPDX／SPDX LITE／CycloneDX／SWIDタグ）の役割と違いを整理し、目的に応じた選び方と運用の考え方を解説しました。

ライセンス管理・脆弱性管理・資産管理といった観点から得意領域を比較し、SPDX LITEによる手動作成とCI/CDでの自動生成を組み合わせるアプローチも効果的です。

継続的なモニタリングや提出フローの整備、NIST・CISAなど国際ガイドラインの動向を踏まえ、将来の調達要件や監査にも対応しやすいSBOM体制をつくっていくことが重要となります。

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

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

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

---

[2026年01月20日 時点]

自社で開発したソフトウェアに、どのようなOSS（オープンソースソフトウェア）やライブラリが含まれているのかを把握しておくことが重要です。脆弱性やライセンス条件の見落としがあった場合、予期しないトラブルに発展するおそれがあります。

こうしたリスクを抑える手段として役立つのが、「SBOM（Software Bill of Materials）」です。SBOMは、ソフトウェア製品やコンポーネントに関する情報を体系的に整理した「部品表」です。

この記事では、SBOMの役割や特徴、メリット、作り方、活用方法、導入事例などを解説します。企業の信頼性向上を支える仕組みとして、SBOMがなぜ重要なのかを理解できる内容です。

 

SBOMとは

SBOMは、一つひとつのソフトウェアが「何でできているか」を整理して「見える化」するための仕組みです。ここでは、SBOMそのものの意味と役割、注目される背景、ソフトウェアサプライチェーンとの関係について解説します。

 

SBOMの定義と役割

SBOM（Software Bill of Materials）は、ソフトウェアを構成するコンポーネントやライブラリを一覧にした「ソフトウェアの部品表」です。誰がどの部品を使い、どのような関係で組み合わさっているかを記録する台帳と捉えると理解しやすいでしょう。

経済産業省でも、SBOMの導入を推奨しています。（※）

部品の名前やバージョン、提供元、ライセンスなどを整理することで、後から脆弱性を突き合わせたり、ライセンス違反の有無を確認したりすることが可能です。例えば、障害が発生した場合の影響範囲の特定や、アップデートの有無の判断に使用できます。

SBOMは、ソフトウェアの中身を把握し、運用やセキュリティ、コンプライアンスを支えるための基本情報です。

※出典：経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver 2.0」

 

SBOMが注目される背景

SBOMが注目されている背景には、ソフトウェア開発の環境が大きく変わったことが挙げられます。現在の多くのシステムは、自社開発コードだけでなく、OSSや外部ライブラリを多数組み合わせて作られている状況です。

そのため、サプライチェーンを狙った攻撃や、広く使われているライブラリの脆弱性が大きな問題になる事例も増えています。対策するにしても、どの製品にどのコンポーネントが含まれているか分からない状態では、影響調査や対策が後手に回ってしまうでしょう。

そこで、構成要素を一覧にするSBOMを整備しようという流れが、各国政府や業界団体のガイドラインを通じて急速に広がっています。

※出典：

経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver 2.0」

CISA（サイバーセキュリティ・インフラセキュリティ庁）「ソフトウェア部品表（SBOM）」

 

サプライチェーンセキュリティとの関係

SBOMは、ソフトウェアサプライチェーンセキュリティを高めるための重要な要素です。サプライチェーンセキュリティとは、自社だけでなく、部品を提供するベンダーやその先の開発者までを含めて、全体のリスクを管理する考え方です。

どの製品にどのコンポーネントが使われているかが分かれば、特定のライブラリに重大な脆弱性が見つかったときでも、影響を受ける製品や設備を素早く洗い出せます。また、取引先に対してSBOMを提供することで、「どのような部品で構成されているか」を説明でき、透明性の高い取引にもつながります。

このようにSBOMは、サプライチェーン全体でリスクと信頼を共有するための共通基盤となります。

 

SBOMの主な特徴

SBOMには、大きく分けて「構成要素の透明性」「依存関係の可視化」「ライセンス情報の把握」という3つの特徴があります。ここでは、それぞれの特徴がどのようにソフトウェア管理やセキュリティ対策に役立つのかを解説します。

 

構成要素の透明性が向上

SBOMは、ソフトウェアの中にどのような部品（OSS・ライブラリ・モジュール）が含まれているかを細かく「見える化」する仕組みです。例えば、食品の原材料表示のように、中身を正確に確認できるため、障害発生時の調査や老朽化した部品の把握にも役立ちます。主な特徴としては次のとおりです。

 

• ソフトウェアに含まれる部品を一覧で確認できる
• バージョンや提供元などの情報を整理できる
• 障害発生時に調査対象を絞り込みやすくなる
• 古い部品やサポート終了コンポーネントを見つけやすい
• 開発側と運用側で同じ情報を共有しやすくなる

 

SBOMによって構成要素が可視化できると、ソフトウェアの構成をより正確に把握できます。中身が分からない状態では、障害発生時の原因調査や脆弱な部品の特定に多くの時間がかかりますが、SBOMがあれば必要な情報にすぐアクセスが可能です。

また、更新が必要な古いライブラリを早期に発見できるため、トラブルの未然防止にもつながります。開発チームと運用チームが同じ情報を前提に判断できるようになるため、組織全体での管理品質も高まり、安定した運用が可能となります。

 

依存関係を明確に把握できる

SBOMは、どのライブラリがどの部品に依存して動いているのかを段階的に把握することが可能です。ある部品に問題があった場合、その影響がどこまで広がるのかをすぐに確認できるため、影響調査や優先順位付けがスムーズになります。以下は、主な特徴です。

 

• コンポーネント間のつながりを可視化できる
• 下位のライブラリ依存関係まで把握できる
• 脆弱性が見つかった際に影響範囲を特定しやすい
• 修正すべき箇所の優先順位をつけやすい
• サプライチェーン全体のリスク管理を効率化できる

 

ソフトウェアは多くのライブラリが重なり合って動いているため、一つの脆弱性が想像以上に広い範囲に影響を及ぼす場合があります。SBOMを使って依存関係を把握しておくと、問題が発生した際に「どこまで影響が及ぶのか」を速やかに判断でき、適切な対応が可能です。

特にOSSやライブラリは、複雑な依存関係を持つことが多く、手作業で追跡するのは困難となります。SBOMによる構造的な可視化は、調査の精度を大きく高め、セキュリティ対策の負荷軽減につながるものです。

 

ライセンス情報を適切に管理できる

SBOMには、利用している各コンポーネントのライセンス情報をまとめて記録することが可能です。再配布の条件や改変のルールを事前に確認できるため、把握していないライセンス違反を防ぎ、安心してOSSを活用しやすくなります。主な特徴は、次のとおりです。

 

• ライセンス種別をまとめて確認できる
• OSSの利用条件を把握しやすくなる
• 再配布や改変のリスクを事前に把握できる
• 法務・調達部門との情報共有がスムーズになる
• ライセンス違反によるトラブルを予防できる

 

OSSは非常に便利ですが、プロジェクトによって利用条件が大きく異なるため、知らずに使うとライセンス違反につながるおそれがあります。SBOMにライセンス情報を整理しておけば、どの部品にどの条件が適用されているのかを明確に確認でき、コンプライアンスを保ちながら開発を進めることが可能です。

また、法務部門や調達部門とのデータ共有も容易になるため、組織としての運用体制も強化されます。適切なライセンス管理は、ビジネスリスクの回避だけでなく、安心してOSSを活用するための基盤づくりにもつながるでしょう。

 

SBOMの構成要素

SBOMは、単に部品名を並べた一覧ではなく、「どの項目をどの形式で記録し、どう運用するか」まで含めて設計する必要があります。ここでは、データフィールドの中身、SPDX LITEを含む手動作成向けのポイント、継続運用の考え方などを整理します。

 

データフィールドに含まれる情報を理解

SBOMのデータフィールドには、ソフトウェアの部品を正確に識別するための基本情報が整理されます。サプライヤー名やバージョンなどがそろっていると、脆弱性やライセンス情報と照合しやすくなるでしょう。

これらはSBOMを活用する上で欠かせない「設計図」のような役割を果たします。主な項目としては、次のものです。

 

データフィールドが整ったSBOMは、ソフトウェアの構成を正しく理解するための重要な役割を果たします。特に、バージョンや識別子といった要素がそろっていると、脆弱性情報やライセンス条件との突き合わせをスムーズに行うことが可能です。

また、標準形式であるSPDXやCycloneDXに合わせてデータを整理しておくことで、社内ツールとの連携や取引先との情報交換もスムーズになります。

 

SPDX LITEを含む手動作成向けのサポート項目を把握する

SPDX LITEは、ライセンス管理に必要な最低限の項目を抽出した簡易版のSPDX形式です。Excelなどの手動管理にも向いており、ソフトウェア構成情報をまず整理したい企業にとって扱いやすいフォーマットとなります。主な項目は、次のとおりです。

 

SPDX LITEは、まずはライセンス情報を整理したい企業にとって非常に取り組みやすい方法です。SPDXのフル仕様に比べて項目が絞られているため、専用ツールがなくても記入と管理ができます。

手動管理が中心の現場でも無理なく使えるように設計されているため、日本の開発現場との相性もよい形式です。

また、SPDX LITEのデータは将来的にSPDXフル仕様やSBOM生成ツールへ移行しやすい構成になっているため、段階的に自動化へ進みたい企業にも向いています。小さく始めたい場合の実務的な選択肢として有効といえるでしょう。

 

運用方法の定義と継続更新の重要性を理解

SBOMは作成して終わりではなく、ソフトウェアの更新に合わせて定期的に見直す必要があります。作成タイミングや粒度、保管場所、更新フローなどの運用ルールを決めることで、インシデント発生時にも迷わず活用できる「使えるSBOM」として機能します。

以下は、運用ルールとして決めるべき項目の例です。

 

SBOMを長く安心して使うためには、更新ルールとガバナンスの整備が重要です。ソフトウェアは日々バージョンアップし、依存関係も変化します。古いSBOMを放置すると実態とずれてしまい、脆弱性調査やインシデント対応で誤った判断につながります。

作成タイミング、参照・更新権限、保管場所などをあらかじめ定めておけば、どの担当者でも迷わず扱える統一された運用が可能です。

また、改訂履歴を残しておくことで監査や取引先からの問い合わせにもスムーズに対応できます。更新し続けることで、SBOMは現場で信頼できる情報基盤として機能します。

 

SBOMのメリット

SBOMを導入することで、セキュリティ対応やライセンス管理だけでなく、システム全体の信頼性向上につなげられます。ここでは、脆弱性管理、ライセンスコンプライアンス、品質・信頼性という3つの観点からメリットを解説します。

 

脆弱性管理の効率化

SBOMがあると、どの製品にどのコンポーネントが含まれているかを一覧で確認できます。そのため、新たな脆弱性情報が公開されたとき、影響を受けるシステムを素早く洗い出すことが可能です。

影響調査やパッチ適用の優先順位付けにも役立つため、限られた人員でも継続的な脆弱性管理を行いやすくなります。このようにSBOMは、セキュリティ運用を省力化しつつ、対応スピードを高めるための有力な手段です。

 

ライセンスコンプライアンスを強化

SBOMには、各コンポーネントの「ライセンス種別」「提供元」といった情報をまとめて登録できます。OSSのライセンスには、さまざまな種類があり、「再配布のルール」「ソースコード公開の必要性」などの条件が異なります。

例えば、GPLのように公開義務があるライセンスもあれば、MITライセンスのように自由度の高いものもあります。

こうしたライセンスが混在すると、後から条件を確認するのが難しくなるでしょう。そのため、SBOMに情報が整理されていれば、どのライブラリにどの条件が紐づくのかを簡単に把握できます。開発チームが新しいOSSを追加した場合でも、法務部門や調達部門が後から追跡しやすいため、知らないうちにライセンス違反になってしまうリスクを下げることが可能です。

SBOMは、OSSライセンス管理の台帳として機能し、コンプライアンス面の安心感を高める役割を果たします。

 

ソフトウェアの信頼性を向上

SBOMを整備すると、システムに含まれるコンポーネントの履歴や状態を継続的に把握できます。サポートが終了したバージョンや、既知の不具合を抱えたライブラリを早期に見つけ出し、計画的に更新することが可能です。

結果として、予期せぬ障害の発生を抑え、長期運用時のトラブルを減らすことができます。

また、取引先やユーザーに対して構成情報を提示できるため、「中身が分かるソフトウェア」としての信頼も高まるでしょう。こうした技術面とビジネス面の両方で安心感が得られ、ソフトウェアの総合的な信頼性向上につなげられます。

 

SBOMの標準形式

SBOMには複数の標準形式があり、それぞれ得意分野や用途が異なります。ここでは、CycloneDX、SPDX／SPDX LITE、SWIDタグの特徴を整理し、目的に合った形式を選ぶための判断材料を解説します。

 

CycloneDXの特徴

CycloneDXは、OWASP（Webセキュリティ向上を目指す国際的な非営利団体）が策定したSBOM形式で、ソフトウェアの構成要素をコンパクトに整理できる点が特徴です。（※）

JSONやXMLなど複数の形式に対応しているため、多くの開発ツールと連携しやすく、クラウドやAIモデルなど最新の技術領域を含む幅広い資産管理に向いています。主な特徴としては次のとおりです。

 

• OWASPが策定したセキュリティ重視のSBOM標準
• JSON・XML・Protocol Buffersなど複数形式に対応
• 依存関係をコンパクトに表現できる
• AIモデル・クラウドサービスなども対象にできる
• 多くの開発・運用ツールと連携しやすい

 

CycloneDXは、ソフトウェアだけでなく、クラウド、AIモデル、コンテナなど、現代のシステムに必要な幅広い要素を表現できる柔軟な形式です。複数のデータ形式に対応しているため、運用ツールにも組み込みやすく、最新の開発環境に自然にフィットします。

セキュリティ管理の観点でも使いやすく、モダンなシステム全体を整理したい組織にとって扱いやすいSBOM標準です。

※出典：OWASP「CycloneDX」

 

SPDX／SPDX LITEの特徴

SPDXは、Linux Foundationが策定した国際標準のSBOM形式で、特にライセンス情報を詳しく扱える点が強みです。（※）

一方SPDX LITEは、実務のやり取りに必要な最小限の項目だけを抜き出した簡易版で、Excelなど手作業の運用にも適しています。主な特徴は次のとおりです。

 

• SPDXはISOで標準化された国際標準（ISO/IEC 5962）（※）
• ライセンス識別子や著作権表記を詳細に扱える
• SPDX LITEは必要最小限の項目のみを抽出した簡易版
• 手作業で扱いやすく、日本企業の実務に適合
• SPDX／LITEを使い分けることで自動化と現場運用の両立が可能

 

SPDXは情報量が豊富で自動化との相性がよく、企業全体で統一したライセンス管理を行いたい場合に向いています。一方、SPDX LITEは手作業で管理する現場で扱いやすく、導入初期の負担を小さくすることが可能です。

まずは、SPDX LITEでライセンス情報を整理し、その後にSPDX全体や自動生成ツールへ移行するという方法が、多くの組織に適した段階的アプローチといえます。両者を目的に応じて使い分けることで、無理のないSBOM運用が可能です。

※出典：

Linux Foundation「SPDX」

OpenChain日本ワークグループ「SPDX LITE」

ISO「ISO/IEC 5962:2021」

 

SWIDタグの特徴

SWIDタグは、ソフトウェア識別のためにISOで標準化された仕組みで、インストールされた製品の名前やバージョンをXML形式で記録します。（※）

PCやサーバ上のソフトを自動的に見つけて識別できるため、資産管理や監査に役立てることが可能です。以下に主な特徴をまとめています。

 

• ISO/IEC 19770-2で標準化された識別タグ（※）
• インストール済みソフトウェアの名称・バージョンを自動記録
• XML形式で製品ごとにタグを付与
• 資産管理（SAM）やライセンス監査で活用
• SBOMと組み合わせることで構成情報と実態を両面で管理可能

 

SWIDタグは、インストールされているソフトウェアを自動的に識別できるため、PCやサーバの棚卸作業を効率化できます。特に、企業規模が大きくなるほど製品の種類や台数が増え、正確な把握が難しくなるため、SWIDタグのような仕組みが有効です。

SBOMと組み合わせると「実際に何が入っているか」「どのような構成情報を持つか」を両面から確認でき、より精度の高い管理につながります。

※出典：

NIST（米国国立標準技術研究所）「ソフトウェア識別 (SWID) タグ付け」

ISO「ISO/IEC 19770-2:2015」

 

SBOMの作り方

SBOMは、最初から高度な自動化を目指す必要はありません。自社の開発規模や体制に合わせて、ツールによる自動生成とSPDX LITEによる手動管理を組み合わせることで、無理なく導入が可能です。ここでは、SBOMの作り方と運用のポイントを解説します。

 

自社の運用に合ったSBOM生成方法を選ぶ

SBOMの作成方法は、会社の規模や開発の進め方によって最適な手段が異なります。自動で情報を集める方法が向く場合もあれば、まずは手作業で整理したほうがよい場合もあるのです。

特に日本企業では、扱う項目を必要最小限に絞れる「SPDX LITE」が、最初の一歩として選ばれる場面が増えています。

 

SBOMをどう作るかは、企業によって最適な方法が変わります。自動生成ツールは最新の情報を保ちやすく、規模の大きい開発でも負担の軽減が可能です。

一方で、まずは基本的なライセンス情報を整えたい企業にとっては、必要な項目だけに絞れるSPDX LITEが扱いやすいでしょう。現場でも浸透しやすい方法です。

自社の現状や開発体制に応じて、自動化と手動管理のどちらを主軸にするかを見極めることで、無理のないSBOM導入、長期的な安定運用につなげられます。

 

CI/CDパイプラインに連携・自動生成と人手確認を両立

SBOMを継続して更新するには、自動化できる部分を日々の作業プロセスに組み込むことが重要です。開発やテストの流れの中でSBOMを自動生成すると、抜け漏れを防ぎやすくなります。

一方、ライセンスの確認など細かい判断が必要な部分は、人の目で確かめることが必要です。下表に、自動化と人手確認を両立する場合の役割を整理しています。

 

SBOMを確実に更新し続けるには、自動化だけでも人手だけでも不十分です。CI/CDパイプライン（ソフトウェア開発→テスト→リリースまでを自動で流れる仕組み）に、SBOM生成を組み込むことで、リリースのたびに最新の構成情報を自然に蓄積できます。

一方、ライセンス条件の確認や契約面のチェックなど、機械だけでは判断が難しい部分は、人の目での確認が必要です。その際には、必要な情報だけに絞っているSPDX LITEが役立ちます。

自動化で作業負担を減らしつつ、人の判断が必要な部分は手作業で補うことで、効率と正確さを両立したSBOM運用が可能になります。

 

SBOMとSPDX LITEを継続更新・運用ルール維持

SBOMは、一度作っただけで終わりではありません。ソフトウェアが更新されるたびに、使っている部品やライセンスも変わります。その変化に合わせて、「いつ・誰が・どのように更新するか」というルールを整えておくことが必要です。

ルールを決めておく必要のある項目を、以下にまとめています。

 

SBOMとSPDX LITEを役立つ情報として保ち続けるには、継続的な更新と、しっかりとした運用体制が必要です。どのタイミングで更新するか、誰が管理するか、どこに保存するかなどの基本的なルールを決めておくことで、情報のずれや混乱を防げます。

また、修正方法や履歴の残し方を決めておくことで、監査や取引先への説明にもスムーズに対応ができます。

 

SBOMの活用方法

SBOMは、脆弱性管理やインシデント対応、品質保証など、日々の運用に組み込むことで価値が高まります。ここでは、脆弱性データベースとの連携、インシデント対応、監査や品質保証での活用方法について解説します。

 

脆弱性データベースと連携

SBOMは、脆弱性データベースと組み合わせることで、リスク把握に役立つ情報基盤になります。SBOMに記録されたコンポーネント名やバージョン情報をNVD（米国の脆弱性データベース）やJVN（日本の脆弱性情報ポータル）などの情報と照合すると、自社製品に影響する脆弱性を自動的に抽出可能です。（※）

従来のように、担当者が手作業で製品一覧と脆弱性情報を突き合わせる方法と比べ、漏れや重複を減らしやすいでしょう。危険度に応じて優先順位をつけることで、限られたリソースでも効率的にパッチ適用や回避策の検討を進めることが可能です。

※出典：

NVD（米国の脆弱性データベース）「国家脆弱性データベース」

JVN（日本の脆弱性情報ポータル）「JVN」

 

インシデント対応を迅速化

インシデント発生時にも、SBOMは対応スピードを上げる材料になります。例えば、特定のライブラリにゼロデイ脆弱性（まだ知られていないセキュリティ上の欠陥）が見つかった場合でも、SBOMからそのライブラリを利用している製品やシステムを即座にリストアップすることが可能です。

これにより、影響範囲の調査に時間を取られにくくなり、対策方針の決定や関係部署への連絡を迅速に実施できます。

また、取引先やユーザーからの問い合わせに対しても、SBOMをもとに「影響あり／なし」の根拠を示して回答が可能です。結果として、技術面だけでなく説明責任の観点からも、インシデント対応の質とスピードを高めやすくなります。

 

品質保証や監査に活用

SBOMは、品質保証や内部監査・外部監査の場面でも有効です。構成要素や依存関係が一覧化されていれば、テスト計画を立てるときに重点的に確認すべき箇所を整理しやすくなります。

例えば、変更頻度が高いコンポーネントや、過去に不具合が多かったライブラリを重点テスト対象として抽出可能です。また、監査では「どの製品にどのOSSが含まれているか」を説明する場面が増えていますが、SBOMを活用することで資料作成の手間を減らし、説明内容の一貫性も保ちやすくなるでしょう。

こうした取り組みを通じて、開発プロセス全体の見通しがよくなり、ソフトウェア品質の底上げにもつながります。

 

SBOM

SBOMは、基本概念だけを知っても、実際にどう使われているか見えにくい場合があります。ここでは、現場での具体的な導入事例について解説します。

他業界に広がるSBOMの採用動向

SBOMへの取り組みは、金融・通信だけでなく、医療機器や自動車などの分野にも広がっています。経済産業省の実証事業では、医療機器分野や自動車分野、ソフトウェア製品分野を対象に、SBOMを活用した脆弱性管理や項目選定の検討が進められている状況です。

産業全体の現状や海外規制の影響をまとめた技術解説も公開されており、今後SBOMは複数の業界で標準的な取り組みとして定着していくことが期待されています。

※出典：経済産業省「ソフトウェア管理に向けた SBOM（Software Bill of Materials）の導入に関する手引 ver 2.0」（Page 88）

 

まとめ

SBOMは、ソフトウェアの構成要素を「部品表」として一覧化し、透明性とセキュリティを高めるための重要な仕組みです。構成情報や依存関係、ライセンスを整理することで、脆弱性管理やコンプライアンス対応を効率化できます。

また、標準形式や生成ツールとの連携を組み合わせて継続的に更新することで、インシデント対応や品質保証、監査にも活用が可能です。

金融・通信をはじめとしたさまざまな業界で導入が進んでおり、今後はソフトウェアサプライチェーン全体を守る上で、SBOMが欠かせない前提条件になっていくと考えられます。

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

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

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

---

[2026年01月20日 時点]

製造ラインや発電設備、交通システムなど、社会を支える多くの現場では、機械がネットワークにつながり便利になっています。しかしその一方で、サイバー攻撃のリスクも増えている状況です。

「自社のシステムは本当に大丈夫なのか」「もし止まったらどう対処すればいいのか」など、不安に感じる方も多いでしょう。そのような場合、機械（フィジカル）と情報システム（サイバー）の両方を守る考え方である、サイバーフィジカルセキュリティが重要となってきます。

この記事では、サイバーフィジカルセキュリティの基本から、攻撃の入り口、検知・復旧方法、設計時の工夫、外部委託の注意点などを分かりやすく解説します。

 

サイバーフィジカルセキュリティとは何か

サイバーフィジカルセキュリティは、工場や交通、エネルギーなどにおける「機械」と「ITシステム」を一体で守る考え方です。（※）

ここでは、その仕組みや背景を解説します。

※出典：経済産業省「工場システムにおけるサイバーフィジカルセキュリティ対策ガイドライン」

 

CPS／CPSFの定義と背景

「CPS（サイバーフィジカルシステム）」とは、現場の機械やセンサーなどの物理的な仕組みと、コンピュータやネットワークといった情報の仕組みをつなげたシステムのことです。例えば、工場の生産ラインをセンサーが監視している場合、データをもとにAIが自動で監視範囲を調整するような仕組みがCPSとなります。

このCPSを安全に動かすための枠組みが「CPSF（サイバーフィジカルセキュリティフレームワーク）」です。CPSFでは、設計・運用・監視・復旧までを一連の流れとして整理し、どの段階で何を守るべきかを明確にします。（※）

これにより、情報システム部門と現場部門の連携が取りやすくなり、事故やトラブルを防ぐ仕組みが整えられます。

※出典：経済産業省「サイバーフィジカルセキュリティ対策フレームワーク（CPSF）とその展開」

 

サイバー空間と物理空間を統合して守る必要性

これまでのセキュリティ対策は、情報システム（IT）と現場設備（OT）を別々に考えることが多くありました。しかし、近年はネットワークでつながる機器が増え、どちらか一方が狙われると、もう一方にも影響が及ぶような構成になっています。

例えば、遠隔操作で工場設備を制御している場合、通信が悪用されると誤動作や機械停止につながるおそれなどです。こうしたリスクを防ぐには、「サイバー空間（データや通信）」と「物理空間（機械や装置）」を一体として守る必要があります。そのため、情報の流れを見える化し、接続点でアクセス制限や監視を行うことで、被害の広がりを防ぐことが重要です。

 

代表的な脅威「サイバーキネティック攻撃」とその実例

代表的な脅威として「サイバーキネティック攻撃」があります。サイバーキネティック攻撃とは、ネットワークを通じて現場の機械や装置の動作を変更し、物理的な影響を与える攻撃のことです。例えば、水処理施設で薬品の注入量を不正に遠隔操作されると、水質が変わり利用者の安全に関わる可能性が出てきます。

実際2021年には、アメリカの石油パイプライン企業が攻撃を受け、燃料供給が一時的に停止した事例もあります。このように、デジタル上の侵入が社会インフラ全体の停止につながるため、深刻な状況を招くといえるでしょう。（※）

サイバーフィジカルセキュリティでは、こうした現実的な被害を想定し、監視・制御・復旧までを一体で設計することが重要となります。

※出典：米国サイバーセキュリティ・インフラストラクチャ庁（CISA）「コロニアル・パイプラインへの攻撃」

 

サイバーフィジカルセキュリティの脅威

サイバーフィジカルシステムでは、ITと現場の機器が密接につながるため、攻撃者が入り込む経路も数多くあります。センサーやIoT機器、通信経路、ソフトウェア更新など、一見小さく見える入口が被害の引き金となる場合もあります。

ここでは、現場で起こりやすい代表的な3つの侵入経路と、攻撃の仕組みや防ぐための取り組みについて解説します。

 

IoT機器・センサーの弱点を狙う攻撃

IoT機器やセンサーは便利な一方で、初期設定のまま使われることが多く、これが攻撃者に狙われやすい部分です。基本設定を見直すだけでも、被害を防ぐ効果があります。主な対策ポイントは、次のとおりです。

• 機器ごとに「設置場所」「機能」「管理者」を明確にする
• 初期パスワードを変更し、強固な認証方式を設定する
• 多要素認証を導入し、アクセス制限を強化する
• メーカー提供の更新プログラムを定期的に適用する
• 利用していない機能やポートは停止しておく

IoT機器は、規模の小さな装置でもネットワーク全体への入り口になり得ます。特に、監視カメラや温度センサーのような身近な装置ほど、更新や設定の管理が後回しにされがちです。

どんな小さな機器でも、「一つのコンピュータ」として扱い、パスワード変更や更新を定期的に行うことが重要です。基本の積み重ねが、もっとも効果的な防御になります。

 

ネットワーク・通信経路でのマルウェア侵入

ネットワークを共有していると、社内メール経由で制御システムにマルウェアが侵入する可能性があります。通信経路を整理し、分離設計を行うことが基本です。主な対策ポイントは以下のとおりです。

• 制御系と事務系ネットワークを物理的・論理的に分離する
• 不要な通信を遮断し、アクセス範囲を最小化する
• 通信ログを常時監視し、異常を早期に発見する
• 遠隔保守は限定的に行い、操作履歴を残す
• ファイアウォールやVPNを活用し、安全な接続を維持する

ネットワークは利便性と同時に、攻撃者にとってもっとも使われやすい侵入口です。便利な接続を増やすほど、監視と制御の仕組みが重要になります。日常的な通信を「見える化」し、普段と違う動きをすぐに把握できるようにしておくことが、被害の早期発見につながります。

ネットワークの構成図を常に最新の状態に保ち、全体の通信ルートを把握することが安全の第一歩です。

 

ソフトウェア脆弱性やファームウェア改ざん

古いソフトウェアやファームウェアには欠陥（脆弱性）が残っており、攻撃者はその点をついて侵入します。改ざんされたファイルを取り込んでしまうと、機器の動作を勝手に変えられることも考えられる状況です。対策としては、次のポイントが重要となります。

• 機器ごとにバージョンや最終更新日を一覧で記録する
• 更新ファイルは必ずメーカーの公式サイトから入手する
• 電子署名を確認し、正規の更新ファイルかどうかを確かめる
• セキュアブートを導入し、起動時に改ざんを検出できるようにする
• 更新作業の手順と担当者を明確にし、定期的に見直す

ソフトウェアの更新を後回しにすると、すでに見つかっている弱点を攻撃者に悪用されるおそれがあります。更新ファイルを装って不正なプログラムが送り込まれると、機器の制御が奪われたり、内部のデータが書き換えられたりすることも考えられるでしょう。

こうした事態を防ぐには、公式な更新手順を守り、改ざんを見抜ける仕組みを用意しておくことが欠かせません。更新管理を日常業務の一部として習慣化することが、もっとも確実な防御策です。

 

設計段階における防御設計のポイント

システムや装置を安全に運用するためには、完成してから対策を加えるのではなく、設計の初期段階からセキュリティを考慮することが重要です。後付けの対策はコストが高く、抜け漏れも発生しやすくなります。ここでは、設計段階で意識すべき視点について、実践しやすい形で解説します。

 

セキュリティ・バイ・デザインの原則

「セキュリティ・バイ・デザイン」とは、システムを作る初期段階から「安全性」を設計に組み込む考え方です。（※）

完成後に対策を加えるのではなく、構想・設計・開発・運用・廃止までを一つの流れとして考えます。例えば、アクセス権を必要最小限に設定したり、不要な機能を最初から排除したりする方法です。

また、システムのライフサイクル全体を通じて、変更や更新に対しても安全性を保つことが求められます。図面や設計書に情報の流れや管理範囲を明記しておくことで、後から引き継ぐ人も安全に運用が可能です。結果として、設計時の小さな配慮が、長期的に見てもっとも確実な防御になります。

※出典：独立行政法人 情報処理推進機構（IPA）「セキュリティ・バイ・デザイン 導⼊指南書」（Page-4）

 

境界制御とセグメンテーション

システムを一つのネットワークでまとめてしまうと、1カ所が攻撃されただけで全体に影響が及ぶ危険性があります。これを防ぐために、役割や重要度に応じてネットワークを分ける「セグメンテーション」が重要です。

例えば、制御システムと事務系システムを分離し、通信する際は中継サーバーを通すなどの方法があります。また、遠隔保守は限定された時間だけ接続し、履歴を残すことで不正操作を妨げることが可能です。

このように、物理的・論理的な境界を設けることで、万が一の侵入があっても被害を最小限に抑えられます。システム構成を図で整理し、どこが境界であるかを明確にしておくことが第一歩です。

 

冗長性・フォールバック構成（復旧構成）と安全停止設計

どんなに堅牢なシステムでも、障害や攻撃によって一時的に停止することはあります。その際に重要なのが「安全に止まる」仕組みと「すぐに戻せる」構成です。

例えば、重要なサーバーや通信機器を二重化しておけば、一方が故障しても運用を続けられます。また、更新作業で不具合が発生した場合に元の状態へ戻せる「フォールバック構成（復旧構成）」も有効な方法です。

制御が不安定になった場合に、設備を安全な状態で自動停止させる仕組みを設計段階で考慮しておくことが望ましいです。こうした備えがあることで、障害発生時の混乱を防ぎ、復旧までの時間を短縮できます。

 

検知・対応・復旧のステップと運用上の配慮

万が一の攻撃や障害が発生した時に被害を最小限に抑えるためには、「異常を素早く検知」「適切に対応」「確実に復旧」の流れを整えておくことが重要です。ここでは、この3つのステップについて解説します。

 

リアルタイムモニタリングとアラート設計

システムを守る第一歩は、異常に早く気づくことです。リアルタイムモニタリングは、ネットワーク通信や装置の動きを常に監視し、普段と違う動作を検出します。例えば、通常より通信量が急に増えた場合や、深夜にアクセスが発生した場合など、明らかな変化を自動的に知らせるアラートを設定する形です。

アラートの重要度は「注意」「警告」「重大」のように段階を分け、対応の優先順位を明確にします。例えば、次のような取り決めです。

ただし、通知が多すぎると、重要な警告を見落としてしまいます。そのため、月に1回はルールを見直し、無駄な通知を減らすようにしましょう。監視は、社内ネットワークと、制御ネットワークの両方を対象にします。

 

フォレンジック（ログ分析）による原因究明

トラブルの発生時に必要なのは、「何が」「どのように」起こったかを明らかにすることです。そのために行うのが、フォレンジック調査とログ分析です。フォレンジック調査とは、技術的・科学的手法でログを分析し、事実関係を明確にすることです。

1. トラブルが発生
2. 影響拡大を防ぐため、関係区画の通信を一時制限する
3. 関連ログを別の保存先へ退避し、上書きや改ざんを防ぐ
4. 認証・設定変更・外部通信の順にたどり、入り口と広がり方を特定する
5. 判明した原因ごとに再発防止策（設定修正・権限見直し・手順改善）を決める

ログの正確性を担保するため、平常時からログの「保存期間」「保存場所」「閲覧権限」を決め、すべてのシステムで時刻の同期を徹底します。

 

事業継続・復旧戦略

セキュリティ対策の最終目的は、被害を「ゼロ」にするだけではなく、「早く復旧させる」ことも含まれます。災害復旧（DR）や事業継続計画（BCP）は、そのための仕組みです。あらかじめ重要な設備やシステムを洗い出し、復旧の優先順位を決めておくことで、混乱時に落ち着いた対応が可能となります。

また、バックアップデータは複数世代を保存し、定期的に復元テストを行うことが重要です。代替設備や予備拠点を用意しておくことも、事業を止めずに継続させる有効な手段となります。

 

外部委託・業者との役割分担とガバナンス体制

クラウドや外部サービスを利用すると便利になりますが、セキュリティの責任が自社と委託先の間で分かれるため、役割を明確にしておくことが重要です。トラブルが起きた際に「誰が何を担当するのか」が不明確だと、復旧が遅れたり同じ対応が重なったりしてしまうでしょう。

ここでは、責任範囲の決め方、第三者によるチェックの活用、契約で定めておくべき内容について解説します。

 

SaaS／クラウド／アウトソーサー利用時の責任と境界

クラウドや外部サービスを使うときは、「どこまでが自社の責任か」を明確にすることが重要です。設定やデータ管理の範囲を確認し、委託先との分担をはっきりさせましょう。主な確認ポイントは次のとおりです。

• 契約前に「責任共有モデル」を確認する
• 自社で管理する項目（ID・設定・データなど）を整理する
• 多要素認証やアクセス制御を必ず導入する
• 障害発生時の連絡先と手順を共有しておく
• 定期的に責任範囲を見直し、変更を反映する

クラウドサービスを利用する場合は「責任共有モデル」の理解が重要です。クラウド事業者と利用者の責任範囲を明確に分け、運用責任を共有し合っているという考え方を指します。（※）

ただし、設定漏れやデータ保護を怠ると、自社の責任範囲でトラブルが発生するおそれがあるので注意が必要です。導入前に管理範囲を洗い出し、必要な対策を実施しておくことが大切となります。

また、障害や事故が発生した際に、誰がどのように対応するかを明文化しておけば、復旧までの混乱を防ぐことが可能です。

※出典：内閣官房国家サイバー統括室「クラウドを利用した システム運用に関するガイダンス」（Page-11）

 

第三者評価・監査

外部委託先が信頼できるか確認するには、第三者機関の認証や監査結果をチェックします。客観的な証明が、安全な取引の裏付けになる形です。主なチェック項目としては、次の内容になります。

• ISO/IEC 27001（情報セキュリティマネジメントシステム）やSOC２（Service Organization Control２：サービス組織管理報告）などの認証取得状況を確認する
• セキュリティ診断やペネトレーションテスト（脆弱性検証テスト）を定期的に実施
• 診断範囲・頻度・報告書の内容を明確にする
• 指摘事項への対応状況を追跡し、改善を確認する
• 外部監査を「形式」で終わらせず、継続的改善に活用する

第三者機関による評価は、委託先の安全性を見極める有効な手段です。ISO（国際標準化機構）やSOC（Service Organization Control：サービス組織管理報告）などの認証は、一定の基準を満たしていることを保証します。ただし、それだけで安心せず、実際の運用が基準どおりに行われているかも確認してください。定期的なセキュリティ診断を依頼し、報告内容をもとに改善が実施されているかを追跡することが大切です。

 

契約条項で定めるセキュリティ要求・SLAs

外部委託では、契約時にセキュリティや品質の条件を数値で明確にすることが重要です。SLA（サービス品質保証）を活用する方法があります。主な取り決め項目は次のとおりです。

• 障害報告の期限・復旧目標時間（RTO）を設定する
• バックアップの頻度と保存場所を明記する
• データの暗号化方法・ログ保管期限を定める
• 脆弱性対応や再委託ルールを契約に含める
• 契約内容を年1回以上見直し、最新化する

契約は、安心して義務を任せるための「安全網」です。特にSLA（サービス品質保証）にて、復旧時間やバックアップ頻度などを具体的な数値で定めることで、期待する品質を明確にできます。

また、再委託や情報漏えいが起きた場合の報告義務も契約に含めておくと安心です。契約を結んだ後も、環境やサービス内容の変化に応じて定期的に見直しましょう。

 

まとめ

サイバーフィジカルセキュリティは、ITと現場機器がつながる今の時代に欠かせない考え方です。IoT機器や通信経路など、攻撃されやすい入口を把握して対策を整えてください。

また、設計段階で安全性を組み込み、異常の検知や復旧までの流れを整備することで、万一の被害を最小限に抑えられます。

クラウドや委託先など外部と連携する際は、責任範囲を明確にし、契約や監査を通じて信頼性を高めることが重要です。この取り組みを地道に続けることで、現場に合った実践的なセキュリティ体制を築くことができます。

最後に

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

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

---

[2025年11月12日 時点]

運転支援システム「ADAS」は、車がドライバーを助けて安全性を高めるための技術です。しかし「どこまで任せていいのか」「誤作動の心配はないのか」と不安を感じている人も多いでしょう。ADASは自動運転ではなく、あくまで人が主体のサポート機能です。

この記事では、自動運転レベル1、2の違い、カメラ、レーダー、LiDAR、HDマップの役割、セキュリティ対応など、ADASの基礎知識について分かりやすく解説します。

 

ADASとは

ADASは、先進運転支援システムの総称です。車が周囲を見てドライバーに危険を知らせ、操作を助けます。ここでは、ADASの定義と目的、使われる場面、注意点などを解説します。

 

ドライバー支援の定義と目的

ADAS（エイダス）は、「Advanced Driver-Assistance Systems（先進運転支援システム）」の略で、ドライバーの運転を助ける仕組みを指します。車が自動で運転するわけではなく、あくまで主役はドライバーです。

カメラやレーダーなどのセンサーが周囲の状況を監視し、危険を察知すると音や表示で注意を促します。必要に応じて、車がブレーキやステアリングをサポートすることもあります。代表的な機能には、自動ブレーキ（AEB）、車線逸脱警報（LDW）、車間を自動で保つアダプティブ・クルーズ・コントロール（ACC）などがあります。

これらの機能を正しく使えば、ドライバーの見落としを補い、事故を防ぐ可能性を高めます。重要なのは、ドライバーが常に周囲を監視し、いつでも操作できる状態を保つことです。

ADASの目的は、事故の予防と疲労の軽減にあります。長距離運転や渋滞時の負担を減らし、安全で快適な運転を支援します。

 

想定シーン別に果たす役割

ADASは走る場所や状況によって、支援の内容が変わります。高速道路、市街地、悪天候、駐車時など、それぞれの環境で異なる機能が働き、安全と快適さを保ちます。主な運転シーンとADASの役割は次のとおりです。

ADASの機能を十分に発揮させるには、環境や条件を理解することが大切です。カメラの汚れやセンサーのずれを放置すると、誤検知や作動遅れの要因になります。定期的に点検し、ソフトウェアを無線更新（OTA）で最新の状態に保つことで、安全性を高く維持することが可能です。

また、車種によって動作条件が異なるため、取扱説明書で作動範囲を確認することが重要となります。正しい理解と日常的なメンテナンスが、ADASを最大限に生かすポイントです。

 

限界と注意点

ADASはドライバーを助ける技術ですが、どんな状況でも完璧に働くわけではありません。環境やセンサーの状態によって性能が変わるため、その限界を知っておくことが安全運転につながります。

以下に、ADASが苦手とする状況と、ドライバーが取るべき対策についてまとめています。

ADASを安全に使いこなすには、「限界を理解した上での運転」が欠かせません。自動運転のように任せきりにせず、常に前方を確認して操作に戻れる姿勢が大切です。車種によって作動範囲や速度条件が異なるため、取扱説明書を確認しましょう。

また、カメラやセンサーは定期的な点検、ソフトウェアは最新状態の維持が重要です。

 

ADASのレベル

自動運転には、国際的に定義されたレベル区分（SAEレベル0～5）があります。（※）

ADASはそのうち、レベル1とレベル2に相当する「運転支援段階」を担う形です。レベル1は加減速または操舵のどちらかを支援し、レベル2は両方を同時に助けます。

レベル1とレベル2は、いずれも運転の主役はドライバーであり、自動運転ではありません。ここでは、支援の範囲と責任の違いを整理します。

※出典：国土交通省「自動運転移動サービス社会実装・事業化の手引き」（Page-15）

 

レベル1が担う支援

レベル1は、車の「前後」または「左右」いずれかの操作を部分的にサポートします。加減速や操舵のどちらかを自動で補助し、運転中の負担を軽くするのが目的です。以下に、レベル1のポイントをまとめています。

• 加減速支援：アダプティブ・クルーズ・コントロール（ACC）が前走車との距離を自動で調整
• 操舵支援：車線維持支援（LKA）が車線の中央を保つように微調整
• ドライバーは常に前方を監視し、即座に操作に戻れる準備が必要
• 雨・霧・車線消失などの環境では認識精度が低下する場合がある
• 作動条件を取扱説明書で確認し、誤操作を防ぐことが重要

レベル1の支援機能を活用すれば、渋滞時や長距離運転での疲労を大きく減らせます。しかし、あくまでドライバー主体の運転を補助する仕組みです。ハンドルやペダルから完全に手足を離す想定ではありません。ドライバーは、いつでも操作が可能な準備をしておく必要があります。

また悪天候や標識が不明瞭な道路では、誤作動のリスクがあるため、常に周囲の状況を把握しておくことも大切です。機能の特性と制約を理解した上で活用すれば、より快適で安全なドライブを実現できます。

 

レベル2が担う支援

レベル2は、加減速と操舵の両方を同時にサポートする運転支援です。自動で速度を調整しながら車線を維持し、長距離や渋滞の負担を大幅に減らします。レベル2のポイントは次のとおりです。

• アダプティブ・クルーズ・コントロール（ACC）とレーンセンタリング制御が連携して走行をサポート
• 高速道路など、直線や緩やかなカーブで安定して作動
• ドライバーは常に監視し、警告時はすぐに操作を引き継ぐ必要がある
• トンネルや逆光などでは誤認識が起きる場合がある
• 停止後の再発進やカーブ対応の範囲は車種ごとに異なるため要確認

レベル2は、自動運転にもっとも近い支援レベルですが、主導権はドライバーにあります。ハンドルから完全に手を離すことは想定されておらず、監視義務を怠ると危険です。システムは周囲の全状況に対応できないため、注意喚起や警報を聞いたら速やかに操作を戻す必要があります。

また、作動条件や制御範囲は車種によって異なるため、カタログだけでなく取扱説明書を確認しておくことが重要です。理解して使用すれば、安全で快適な運転支援が得られます。

 

責任範囲とドライバーの監視義務

レベル1、2の運転支援は、あくまで「サポート」であり、運転の最終的な責任はドライバーにあります。システムを過信せず、常に周囲を確認し、異常時はすぐに操作をドライバー側に戻す姿勢が必要です。以下のポイントを理解しておく必要があります。

• 運転の主体は常にドライバーであり、システムは補助的な存在
• 手放し運転や、わき見運転を前提とした設計ではない
• 異常を感じたら即座にドライバーが操作に介入することが重要
• 各メーカーの作動条件や制限を取扱説明書で確認しておくこと

ADASの支援を安全に生かすためには、ドライバーが常に責任を持つという前提を忘れてはいけません。運転支援中も前方や周囲を監視し、異常や誤作動を感じたら即座に介入する姿勢が重要です。

また、日常の点検やソフトウェア更新を怠らないことが、安心してADASを活用する一歩となります。

 

ADASのセンサー構成

ADASは、複数のセンサーを組み合わせて周囲を把握します。ここでは、ADASで使用されているカメラ、ミリ波レーダー、LiDARそれぞれの「得意分野」と「苦手分野」を整理し、どんな役割分担で使われているのかを解説します。

 

カメラが得意とする認識と弱点

カメラは人の目のように周囲を映像でとらえ、標識や信号、歩行者などを細かく認識します。一方で、光の影響を受けやすく、天候や明るさによって性能が左右されるのが弱点です。

カメラは、人の視覚に近い認識ができるため、ADASの中でも重要な役割を担います。しかし、天候や照明条件に大きく左右されるため、センサー単独では誤認識のリスクがあります。そのため、レーダーやLiDARなどほかのセンサーと組み合わせて補い合う「センサー融合」が欠かせません。

また、運用面では、カメラレンズの清掃やソフトウェア更新（OTA）を定期的に行い、精度を保つことが大切です。車種ごとの作動条件を確認しておくことで、より安全で安定した支援が得られます。

 

ミリ波レーダーが担う距離・速度検知

ミリ波レーダーは、電波を使って対象までの距離や速度を測定します。夜間や雨、霧でも安定して動作し、前方車両との車間維持や衝突防止に欠かせないセンサーです。

ミリ波レーダーは、カメラが苦手とする悪天候や暗い環境でも安定して働く、ADASの信頼性を支えるセンサーです。しかし、物体の「形」や「種類」を判別する能力は低いため、カメラやLiDARと組み合わせて使うことが一般的となります。

車間距離維持、追突警報、死角検知などで、性能を発揮可能です。定期的なセンサー清掃や角度調整を行い、正しい検知範囲を維持することが安全運転につながります。

 

LiDARが提供する形状・位置の高精度把握

LiDAR（ライダー）は、レーザー光を使って周囲を三次元的に計測するセンサーです。物体の形や位置を細かく描けるため、精密な空間認識に優れています。

LiDARは、周囲の形状を立体的に捉えるため、ADASにおける「空間の目」として重要な役割を果たします。特に、建物や車両の輪郭を正確に把握できる点が強みで、駐車支援や障害物検知などで高い精度を発揮する状況です。

ただし、天候の影響を受けやすく、コスト面でも課題があるため、カメラやミリ波レーダーとの組み合わせが不可欠です。これらのセンサーを総合的に使うことで、視界が悪い環境でも安定した検知が可能になります。

 

センサー融合における高精度地図の役割

HDマップ（高精度地図）は、センサーが捉えられない範囲を補う役割を果たします。HDマップによって、レーン形状や制限速度などの道路情報を事前に把握しておくことで、センサーが検知した内容をより正確に判断できるようになります。ここでは、HDマップの構成要素、センサーとの組み合わせ方、自車位置を特定する基本の仕組みについて解説します。

 

HDマップが提供するレーン・制限情報

HDマップ（高精度地図）は、道路を細かくデジタル化したもので、レーンごとの形状、車線数、勾配、ガードレールの位置、制限速度などを正確に記録しています。こうした情報により、カメラでは見づらい標識の影や逆光下でも、車両を安全に判断することが可能です。

例えば、カーブの曲がり具合を事前に把握し、前走車追従機能（ACC）が滑らかに減速できるように支援します。分岐や合流などでも、地図データに基づいてスムーズな走行経路を選択可能です。

HDマップは、センチメートル単位の高精度で車両位置を特定し、運転支援の精度を高めます。ただし、道路状況は常に変化するため、定期的な地図更新と車載ソフトウェアの更新が欠かせません。これらを維持することで、より安定した運転支援が実現します。

 

カメラ×レーダー×地図の融合設計

ADASでは、カメラ・レーダー・地図の3つのセンサー情報を組み合わせて使う「センサー融合」が基本です。カメラは標識や車線などの見た目を識別し、レーダーは距離や速度を正確に測定します。地図は、これらを補う「先読み情報」として、カーブや交差点などの構造を事前に提供する形です。

例えば、工事で一時的に車線が消えても、地図上のレーンデータとセンサー情報を照らし合わせることで安定した走行が可能になります。システムは天候や環境に応じて、どの情報を重視するかを自動で切り替え可能です。

悪天候時はレーダーの比重を上げ、視界が良好な場面ではカメラの判断を優先するなど、柔軟な設計がされています。性能を維持するためには、センサーの再調整と地図更新を定期的に行うことが重要です。

 

自車位置推定の基本

自車位置推定は、車が「今どこを走っているか」を正確に知るための仕組みです。基本は衛星測位（GNSS）ですが、トンネルや高層ビル街のように電波が届きにくい場所では、加速度や角度を測る慣性センサー（IMU）が補います。

また車輪の回転速度やハンドル角度などの情報を組み合わせることで、誤差を最小限に抑えます。LiDARやカメラで捉えた周囲の特徴を使い、自動的に地図を生成しながら位置を推定するSLAM技術も活用されています。（※）

これらのデータは、カルマンフィルタなどの統計的手法で統合され、安定した位置推定を実現します。車両の位置精度を保つためには、センサーの取り付け角度やタイヤ外形の変化などを点検し、誤差を定期的に補正することが大切です。

※出典：国土交通省「LidarSLAM 技術を用いた公共測量マニュアル」（1．はじめに）

 

ADASの制御アーキテクチャ

ADASは「周囲の認識 → 判断 → 車を制御」の一連の処理を、複数の電子制御ユニット（ECU）で分担しています。車には多数のセンサーや機能があるため、信号や電力を効率よくやり取りできる構成が必要です。ここでは、その仕組みと役割分担について解説します。

 

ECUとドメイン／ゾーン制御の役割

ECU（Electronic Control Unit）とは、車の“頭脳” として機能する電子制御装置です。近年では、ECUを機能ごとにまとめる「ドメイン方式」と、車体の位置ごとにまとめる「ゾーン方式」を組み合わせて、配線を減らし処理を効率化する設計が主流です。

ドメイン方式とゾーン方式を組み合わせることで、ADASのような高機能な制御を効率的に実現できます。例えば、各ゾーンECUがカメラやレーダーなどの信号をまとめ、中央のコンピュータが総合判断を行う形です。

この構成により、配線が短くなり、車の重量やコストを抑えられます。万が一、故障が起きても特定ゾーンだけに影響をとどめることが可能です。また、ソフトウェア更新やキャリブレーション（調整）をゾーン単位で統一できるため、保守が容易となります。

 

HMI設計が担う警報・介入の伝え方

HMI（ヒューマン・マシン・インタフェース）は、運転者に危険や操作支援を伝える仕組みです。警報やドライバーの介入をどう伝えるかが、安全で分かりやすい運転支援の鍵となります。以下は、HMIで使用される主な方法です。

HMI（ヒューマン・マシン・インタフェース）設計では、「驚かせずに気づかせる」ことがもっとも大切です。急な警報や過剰な介入は、ドライバーを混乱させるため、視覚、聴覚、触覚を段階的に使い分けます。

例えば、最初は警告表示で知らせ、反応がなければ音を出し、さらに無視されると軽い振動で促すなどの方法です。長時間の使用でも疲れにくく、誤解を生まないような表示文言や音の設計も重要となります。

ドライバーが自然に気づいて、操作を戻せるように導くことが、HMIの本来の役割です。

 

ブレーキ／ステアリング等アクチュエータ制御の基礎

アクチュエータとは、車の動きを実際に制御する装置のことです。ADASでは、ブレーキやステアリング（ハンドル）を電子的に操作し、滑らかで安全な支援を行います。主要なアクチュエータ制御は次のとおりです。

ADASの制御では、ドライバーの操作を補助しながら、万一のトラブル時も安全を保つ設計が求められます。ブレーキは目標減速を計算し、必要な力を各タイヤに配分します。電気制御化によって、応答が速くなり、滑らかな制御が可能です。

ステアリングも電動化され、わずかなハンドル操作で車線を維持できます。また、どちらのシステムも故障時は自動でドライバー主導へ切り替え可能となる「フェイルセーフ設計」が組み込まれている形です。

こうしたアクチュエータ制御の信頼性が、運転支援の安全を支える土台になっています。

※出典：

日本自動車研究所「機能安全（ISO26262）」

ISO「ISO 26262-1:2018」

 

ADASの代表機能

ADASの主要な機能には、前方の衝突を避ける「AEB」、車線からのはみだしを防ぐ「LKA／LDW」、車間距離を保つ「ACC」があります。これらの仕組みや働きを正しく理解し、どのような場面で効果を発揮するのか、どのあたりが機能の限界なのかを知っておくことで、安全運転に役立てることが可能です。ここでは、それぞれの機能について解説します。

 

衝突被害軽減ブレーキ（AEB）の働き

衝突被害軽減ブレーキ（AEB：Autonomous Emergency Braking）は、前方の車や人を検知し、衝突の危険を察知した場合、自動で減速・停止を支援する仕組みです。ドライバーの運転をサポートし、事故の被害を最小限に抑えます。AEBの主な働きは次のとおりです。

1. 前方の監視
   カメラやレーダーで車両、歩行者、自転車などを常時監視
2. 危険の予測
   接近速度や距離を計算し、衝突の危険性を判断
3. 警報で注意喚起
   ブザー音や表示でドライバーに危険を知らせる
4. ブレーキアシスト
   ドライバーがブレーキを踏んだ際、踏力を自動で補強
5. 自動制動の実施
   衝突回避が難しいと判断した場合、自動で強い制動をかける

AEBは、あくまで衝突を避けるための補助であり、万能ではありません。悪天候や夜間、逆光などではセンサーが誤動作したり、反応が遅れたりすることもあります。

また、センサーの汚れやずれも検知精度を下げる要因です。そのため、日常的にカメラやレーダー部分を清掃し、点検を行うことが重要となります。AEBを信頼しすぎず、前方の確認と十分な車間距離を保つことが、安全運転の基本です。

 

車線維持支援（LKA／LDW）の働き

車線維持支援（LKA：Lane Keeping Aid）と車線逸脱警報（LDW：Lane Departure Warning）は、カメラで路面の線を読み取り、車が車線から外れないようにサポートする仕組みです。LKA／LDWの基本動作は次のとおりです。

1. 路面認識
   前方カメラで白線や縁を検出し、車線の位置を把握
2. 走行位置の判断
   車が車線の中央からずれたかをリアルタイムで計算
3. 警報による注意喚起（LDW）
   はみ出しそうになると音や表示で警告
4. ステアリング補助（LKA）
   軽い操舵補助で車線中央へ戻すように支援
5. ドライバー監視と条件制御
   手放しや悪天候では支援を緩め、安全側に制御を切り替え

LKA／LDWは、居眠り運転やわき見による車線逸脱を防ぐ重要なサポート機能です。しかし、路面表示が薄い場合や雪で線が隠れている場合、工事中で区画が変わっている場合などは、正しく作動しにくくなります。そのため、常にハンドルには軽く手を添えて、システムに頼りすぎない姿勢が大切です。

作動条件や速度範囲は車種ごとに異なるため、注意が必要となります。LKA／LDWは、正しく理解して使うことで、ふらつきや注意力低下に早く気づける「第二の目」として安全運転を支えます。

 

アダプティブ・クルーズ・コントロール（ACC）の働き

アダプティブ・クルーズ・コントロール（ACC：Adaptive Cruise Control）は、前の車との距離を自動で保ち、一定の速度を維持しながら走行をサポートする機能です。ACCの基本動作は次のとおりです。

1. 前方検知
   レーダーやカメラで前走車の位置と速度を検出
2. 車間距離の設定
   ドライバーが希望の距離を選び、システムがその距離を維持
3. 自動減速
   前の車が減速すると、ブレーキ制御で車間を保つ
4. 加速・巡航
   前方が開くと設定速度まで自動で戻す
5. 渋滞追従・停止支援
   一部車種では、停止・発進を自動でサポート

ACCは、長距離運転や渋滞時の疲労を大幅に軽減する便利な機能です。しかし、急な割り込みや急ブレーキ、カーブが多い場合は、反応が遅れることがあるので注意してください。

また、標識認識や制限速度への対応は別の機能に依存している場合があります。常に周囲の状況を確認し、必要に応じてアクセルやブレーキを自分で操作できるように準備が必要です。ACCは「任せる運転」ではなく、「支援を受けながらドライバーが運転」するための技術となります。

 

ADASのライフサイクル管理

ADASは、安全性と性能を高め続けるために「設計 → 検証 → 量産 → 運用 → 改善」というサイクルを繰り返しながら進化しています。開発段階では、シミュレーションや試験で動作を確認し、運用後も実走行データやソフトウェア更新で精度を高めることが必要です。

ここでは、モデルベース検証、データ管理、OTA更新の流れを、実務で役立つ視点から解説します。

 

モデルベース検証（SIL／HIL）の進め方

ADAS開発では、実車を使わずに動作を確かめる「モデルベース検証」が重要です。SILとHILの2つの方法があります。

SILとHILは、ADAS開発の品質を支える両輪です。SILでは設計初期からシミュレーションを繰り返し、ソフトウェアの論理や境界条件を洗い出します。HILでは実際のECU（電子制御装置）や通信を使って、遅延や互換性を確認し、実車に近い精度で検証する方法です。

現場では、SILで設計を固め、HILで完成度を高めるのが一般的となります。テスト不合格が発生した場合は、次に同じことが起きないようにテストケース化し、ASIL（機能安全レベル）に合わせて、テスト範囲と要件確認を整理して管理します。（※）

こうした仕組みを保つことで、見落としのない安全なシステムづくりが可能です。

※出典：IPA 独立行政法人 情報処理推進機構「車載システム開発時に使用するソフトウェアツールをISO 26262の要求事項に準拠させるための作業項目の抽出と考察」（Page-11）

 

実走行データの収集・管理とテスト設計

実走行データは、ADASの性能を現実の環境で確かめるための土台です。どのシーンのデータをどれだけ集めるかを計画し、標準形式で整理、活用することが重要です。実走行データの収集と活用の流れは、次のとおりとなります。

実走行データを活用するには、収集から管理、検証までを一貫して行うことが大切です。特に、天候や交通密度などの条件をそろえたシナリオごとの再現試験が有効となります。

テスト不合格の項目に関しては、テスト資産として蓄積し、再発防止に役立てる形です。ASAMの標準形式を使うことで、他部門やサプライヤともデータを共有できます。ASAM（Association for Standardization of Automation and Measuring Systems）とは、自動車業界の自動化や計測システムに関する国際標準化団体です。（※）

また、個人情報保護や匿名化を徹底することで、法規にも対応した安全な運用が可能になります。こうした改善サイクルを継続的に回すことが、現実の道路環境に強いADASを構築する鍵となります。

※出典：ASAM「ASAMとは」

 

OTA更新で性能を維持・改善する

OTA（Over The Air）は、車のソフトウェアを無線通信で更新する仕組みです。ディーラーや整備工場に車を持ち込まなくても、不具合の修正や新しい機能の追加ができます。更新は段階的に配信され、セキュリティ対策を行いながら安全に運用されます。OTA運用のポイントは、以下のとおりです。

OTAを成功させるには「安全に配信し、いつでも戻せる」体制が大切です。まず小規模に配信して動作を監視し、異常があればすぐ停止とロールバックを行います。更新パッケージは電子署名で真正性を確認し、鍵は厳格に管理する形です。

ユーザーには、更新内容と所要時間、走行中の制約を事前に伝え、混乱を防ぎます。開発側は更新後の再学習やキャリブレーションの整合をチェックし、次回配信に知見を反映します。

※出典：

国土交通省「4-3．サイバーセキュリティ及びプログラム等改変システムに係る基準」

経済産業省「自動走行システムにおけるサイバーセキュリティ対策」（Page-11）

ISO「ISO 24089:2023」

 

ADASの安全規格対応（ISO 26262）

車に搭載される電子制御システムは、故障が起きると人命に関わるリスクがあります。そのため、自動車業界では「ISO 26262」という国際規格に沿って、安全を体系的に設計・確認することが求められています。

この規格では、リスクの重大さを「ASIL（安全要求レベル）」で分類し、企画から開発、検証、運用までの一連の流れを「安全ライフサイクル」として管理します。

ここでは、ISO 26262の基本的な考え方と、故障時の設計方針、成果物管理のポイントを解説します。

※出典：

日本自動車研究所「機能安全（ISO26262）」

ISO「ISO 26262-1:2018」

 

ASILと安全ライフサイクルの要点

「ISO 26262」は、車の電子制御を安全に製作するための国際規格です。まず「どのような危険が起こり得るか」を分析し（HARA）、危険の大きさに応じて「ASIL（安全要求レベル）」を決定します。レベルが高いほど、より厳しく確認する必要があります。

ソフトウェアの開発は、「計画 → 設計 → 検証 → 評価」を繰り返す流れで進みます。部品単位の試験や解析を行い、要件定義からテスト完了までを一貫して行えるように管理する方法です。製品を出荷した後も、不具合情報を集めて改良を行います。

ADASでは、認識・判断・制御などの機能ごとに安全レベルを決め、変更があれば影響範囲を見直します。これにより、設計から運用まで「安全が途切れない」仕組みを実現しています。

 

フェイルセーフ／フェイルオペレーショナル設計

「フェイルセーフ」は、壊れたら安全な状態に戻す考え方です。例えば、支援機能が異常を検知したら、すぐドライバーに操作を戻す仕組みが該当します。

一方「フェイルオペレーショナル」は、一部が壊れても動き続けられるようにする設計です。例えば、センサーや計算装置を二重にして、片方が故障しても安全に走れる時間を確保します。

どちらを採用するかは、システムの重要度で決定します。ブレーキやハンドルのように、影響が大きい部分では、冗長な電源・回路・監視ソフトを組み合わせます。

ADASでは、センサーの誤作動や反応遅れなどの「想定トラブル」をすべて洗い出し、「異常を検知 → 切り替え → 警告」する流れを具体的に設計します。これにより、故障が起きても安全に車を制御することが可能です。

 

要求・設計・検証の成果物管理

「成果物」とは、安全を証明するための記録や資料のことです。例えば、安全計画、リスク分析の結果、要求仕様、設計図、試験結果、レビュー記録などがあります。これらをまとめたものを、「セーフティケース」と呼びます。

大切なのは、最初の要求から試験結果まで一貫して成果物がつながっていることです。仕様変更が入ったときに、どの設計・コード・テストに影響するか、すぐに分かるようにするためです。

量産後も、OTAや設計変更のたびにセーフティケースを更新します。これにより、「どうやって安全を確保してきたか」を説明できる状態になります。

 

ADASのセキュリティ対応（ISO/SAE 21434）

車は今や、ネットワークにつながる『走るコンピュータ』と呼ばれるほどに、多くの通信機能を備えています。そのため、不正アクセスやデータ改ざんなどのサイバー攻撃から守る仕組みが欠かせません。

こうした脅威に対応するための国際規格が「ISO/SAE 21434」です。この規格では、リスクを特定して対策を立てる「TARA（脅威分析とリスク評価）」、ソフトウェアを安全に更新する「OTA（無線アップデート）」、そして鍵管理やサプライチェーン全体でのセキュリティ体制づくりを求めています。

ここでは、それぞれの考え方と具体的な対応ポイントを整理します。

※出典：

国土交通省「4-3．サイバーセキュリティ及びプログラム等改変システムに係る基準」

経済産業省「自動走行システムにおけるサイバーセキュリティ対策」（Page-11）

ISO「ISO/SAE 21434:2021」

 

TARAで脅威を洗い出し要件化する

TARA（Threat Analysis and Risk Assessment）は、車の電子システムにどんな攻撃が起こり得るかを整理し、優先度を決めて対策に落とし込むための手順です。次のような順序で実施します。

1. 車の中で守るべき資産を洗い出す（例：制御データや通信情報）
2. 攻撃される経路を図にまとめる
3. 攻撃が起こる確率と影響の大きさを評価する
4. 優先度をつけ、どのリスクを先に対策すべきか決める
5. 結果を「セキュリティ要件」として設計・試験に反映する

TARAは、単なる机上の分析ではなく、開発から運用までつながる安全対策の地図です。新しい脅威情報が出た際には、再評価を行い、システムを最新の状態に保ちます。「UNECE R155」のサイバーセキュリティ管理体制（CSMS）と併せて運用すると、量産後の監視や是正まで一貫して管理が可能です。

「UNECE R155」とは、車のサイバーセキュリティと管理システムに関する国連の規則です。（※）

※出典：UNECE「国連規則第155号」

 

セキュア更新（OTA）と鍵管理の実装

OTA（Over The Air）は、車のソフトウェアを無線通信で更新する仕組みです。不正改ざんを防ぐために、電子署名や暗号化による安全な通信が欠かせません。OTAの仕組みは次のとおりです。

1. 更新パッケージに電子署名を付け、車側で正しいか確認
2. 通信経路と保存データを暗号化して保護
3. 鍵は「署名鍵」と「検証鍵」に分けて安全に管理
4. 少数の車から順に段階的に配信し安全を確認
5. 問題が起きた場合はすぐに元の状態に戻せるように準備

OTAは整備工場に車を入庫せず、ソフトウェアを更新できる便利な仕組みです。しかし、安全のための管理は欠かせません。鍵管理の分離や段階配信、ブート時の署名検証などを組み合わせることで、攻撃や改ざんのリスクを防ぎます。

「ISO/SAE 21434」や「UNECE R156」などの国際基準に沿った設計が、信頼できる車両運用の土台となります。

※出典：

経済産業省「自動走行システムにおけるサイバーセキュリティ対策」（Page-11）

UNECE「国連規則第155号」

 

組織・サプライチェーンのセキュリティ体制

車のセキュリティは、メーカー単体では守れません。開発組織と部品供給網（サプライチェーン）全体で、協力する体制が必要です。主な取り組みとしては次の内容があります。

1. 責任者を置き、セキュリティ方針と教育を明確化する
2. 開発段階で設計レビューと脆弱性評価を定例化する
3. 調達時にサプライヤへセキュリティ要件を提示する
4. SBOM（ソフトウェア部品表）や鍵管理、更新手順を契約に明記しておく
5. 量産後はインシデント対応や情報共有の流れを運用する

サイバー攻撃は、一つの部品やたった一社の外部委託先から入り込むこともあります。組織として方針と役割を明確にし、開発から運用までセキュリティを「共通言語」で管理することが大切です。

「UNECE R155」のCSMS体制やNHTSA（米国運輸省道路交通安全局）のガイドラインに基づき、検知・評価・対応・改善のサイクルを回すことで、持続的な防御力を高められます。（※）

※出典：

経済産業省「自動走行システムにおけるサイバーセキュリティ対策」（Page-13）

UNECE「国連規則第155号」

 

まとめ

ADAS（先進運転支援システム）は、運転を「任せる」技術ではなく「助ける」技術です。自動運転レベル1、2の段階では、あくまでドライバーが主役であり、常に周囲の確認が必要となります。カメラやレーダー、LiDAR、高精度地図（HDマップ）などの情報を組み合わせ、車が状況を判断してブレーキや操舵を支援する形です。

代表的な支援機能である、自動ブレーキ（AEB）、車線維持支援（LKA）、アダプティブ・クルーズ・コントロール（ACC）は、正しい使い方と作動の限界を理解することで、安全性を大きく高められます。

開発では、シミュレーションや実走行データで検証し、ソフトウェアの無線交信（OTA）で性能を維持、向上させます。

自動車機能安全規格「ISO 26262」と自動車サイバーセキュリティ国際標準規格「ISO/SAE 21434」に基づき、安全と安心を両立させる取り組みが重要となります。

最後に

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

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

---

[2025年11月12日 時点]

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」などです。主なツールや仕組みを以下にまとめています。

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

※出典：

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は、多くの組み込み機器で検討対象となる代表的な存在です。両社はライセンスの仕組みやエコシステムの広がり、機能の構成方法に違いがあります。それぞれの特徴を下表にまとめました。

Mbed OSとの相違点

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

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

※出典：ARM「Mbed OS EOL 発表」

ThreadXなど商用RTOSとの相違点

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

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

プレライセンス対象MCUであれば利用可能ですが、その他では別途契約が必要となります。導入時には、自社製品に使う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に適したケースを、下表にまとめています。

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を選ぶことが重要となります。

最後に

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

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

---

[2025年10月16日 時点]

組込みや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は、どちらも注目されています。これは用途によって、それぞれの強みが異なるためです。

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

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

 

RTOSとLinuxの違いを整理

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

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

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

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

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

 

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

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

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は工数や人件費がかさみやすい傾向です。

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

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

 

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

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

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

 

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

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

※出典：

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を選ぶことです。特徴を理解したうえで判断すれば、開発の効率性と信頼性を高めることが可能となるでしょう。

最後に

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

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

---

[2025年10月16日 時点]

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

セキュアブートとは

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

Zephyrとは

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

MCUbootとは

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

開発環境

ボード外観と接続

画像上部の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@402e0000 と usbh@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 をインストール（未導入なら）

以下のURLからWindows 用 MSIをダウンロードして実行してください。

https://go.dev/dl/

1. mcumgr-cli をインストール（公式の Go CLI）

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 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日 時点]

はじめに

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

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の構築をぜひご検討ください。

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