ZephyrOS（Zephyr RTOS）とは？特徴・FreeRTOSとの比較とLTSの選び方・westでの始め方

ZephyrOS（正式な表記は Zephyr、または Zephyr RTOS）は、Linux Foundation のもとで開発されているオープンソースのリアルタイムOS（RTOS）です。ライセンスは Apache 2.0 で、2026年10月23日時点の最新版は 4.4.2（2026年8月7日公開）、長期サポート版は 3.7 LTS です。次の 4.5 はリリース候補の rc3 まで進んでおり、正式版は2026年10月下旬の予定です。v4.4.2 のソースには 1,014 のボード定義と 11 のアーキテクチャが入っており、Arm Cortex-M のマイコンから RISC-V、ESP32 まで同じ書き方でアプリケーションを作れます。

この記事では、Zephyr の仕組みと版の選び方、FreeRTOS との違い、開発環境を作って LED を点滅させるまでの手順を、公式リポジトリとドキュメントで確かめた内容に沿って説明します。なお「Zephyros（ゼピュロス、ゼフィロス）」はギリシャ神話の西風の神の名で、同名の会社や製品もあります。ここで扱うのは組み込み向けOSの Zephyr です。

まとめ：ZephyrOSの要点とFreeRTOSとの選び分け

• 正体：Linux Foundation がホストするオープンソースのRTOS。ライセンスは Apache 2.0 で、商用製品に無償で組み込めます。
• 版：最新は 4.4.2。次の 4.5 は2026年10月22日に rc3 が出て、GitHub のマイルストーン期日は10月26日です。製品には 2029年7月27日まで保守される 3.7 LTS、新しいドライバーが必要なら 4.4 系を選びます。次の LTS は2027年4月予定の 4.6 です。
• 対応範囲：v4.4.2 で 1,014 ボード・11 アーキテクチャ。ハードウェアの差は Devicetree、機能の取捨は Kconfig で吸収します。nRF52840 DK でビルドすると、hello_world は Flash 約20KB・RAM 5KB弱、BLE の心拍センサーのサンプルは Flash 約158KiB・RAM 約28KiB でした。
• FreeRTOSとの違い：FreeRTOS は小さなカーネルを持ち込んで周辺はベンダーSDKに任せる形、Zephyr はドライバー・Bluetooth・ネットワーク・ビルドの仕組みまで一式そろった形です。BLE や Wi-Fi をつなぐ製品、複数のマイコンに展開する製品は Zephyr、既存のベンダーSDKが FreeRTOS 前提なら FreeRTOS が手堅い選択です。
• 始め方：Python 3.12 以上と CMake 3.20.5 以上を入れ、west init → west update → west sdk install → west build → west flash の順に進めます。

Zephyr RTOSの正体：名称・運営・ライセンス

ZephyrOS・Zephyr OS・Zephyr RTOSの表記と読み方

プロジェクト名は「Zephyr Project」です。公式のブランドガイドが推奨する表記は「Zephyr Project」「Zephyr OS」「Zephyr RTOS」「Zephyr Platform」で、OS は「Zephyr OS」と語の間を空けて書きます。GitHub の組織名は zephyrproject-rtos です。日本語の記事や求人では「ZephyrOS」と続けて書く例が多く、検索でもこの表記が使われていますが、指しているものは同じです。読み方は英語の zephyr（そよ風、西風）と同じ「ゼファー」です。

Wind River由来のカーネルとLinux Foundationでの運営

Linux Foundation は2016年2月17日に、IoT 機器向けRTOSの共同プロジェクトとして Zephyr Project を発表しました。カーネルの源流は Virtuoso という DSP 向けOSで、Wind River が買収した後に「Rocket」と呼ばれていたものが、Linux Foundation への移管で Zephyr になりました。

運営費と開発者は会員企業が出しています。最上位のプラチナ会員は、会員一覧ページ（2026年10月23日時点）に載る Google、Meta、Intel、NXP、Nordic Semiconductor、Qualcomm、Renesas、Silicon Labs、Analog Devices、Wind River、Antmicro、CARIAD、ZEISS の13社に、2026年10月1日に昇格が発表された Infineon Technologies と Texas Instruments を加えた15社です。GitHub のリポジトリ zephyrproject-rtos/zephyr のスター数は約1.69万、フォーク数は約1.02万です。

nRF Connect SDKやChromebookのECでの採用

Zephyr を土台にした製品やSDKはすでに広く出回っています。Nordic Semiconductor の Bluetooth 向けマイコン nRF シリーズの公式SDK「nRF Connect SDK」は Zephyr を組み込んだSDKで、nRF Connect SDK で開発する場合は Zephyr が土台になります。ただし Zephyr を使わない旧来の nRF5 SDK もあるので、nRF を選べば必ず Zephyr になるわけではありません。Google の Chromebook では、2021年7月以降の新しい設計でキーボードや電源を制御するエンベデッドコントローラー（EC）のファームウェアが Zephyr ベースに切り替わっています。

Apache 2.0ライセンスで商用製品に組み込める範囲

本体はApache License 2.0です。ソースを公開する義務はなく、製品に組み込んで販売できます。再配布するときは、ライセンス文を添付し、変更したファイルには変更した旨を明示します。ソース形式で派生物を配布する場合は関連する著作権等の表示も保持し、NOTICE ファイルがあれば関連する帰属表示を引き継ぐ必要があります。ただし、取り込んだ一部のモジュールには別のライセンスが付いているものがあります。出荷前には west spdx でSBOMを出し、ライセンスの一覧を確認しておくと安全です（手順は後述のセキュリティの章）。

最新版とLTS：4.4.2と3.7 LTSの選び方

Zephyr は 4.4 から、毎年4月と10月に出す6か月周期へ移りました。通常版のサポートは2リリース分（約1年）です。長期サポート版（LTS）は2.5〜3年ごとに出て約5年保守され、最初の2年はバグ修正とセキュリティ修正、残りの期間はセキュリティと安定性の修正だけになります。公式ドキュメントの予定表では、2027年4月の 4.6 が次の LTS（LTS4）、2027年10月の 5.0 から 5.x 系に入ります。

公開済みの版は公式ドキュメントのSupported Releasesの表、予定は同じページのリリース計画によります。4.3 は2026年10月15日でサポートが終わったので、4.3 系を使っている場合は 4.4 系か、4.5 の正式版へ上げてください。

4.4で増えた主な機能

4.4.0 のリリースノートで目立つ変更は次のとおりです。

• OpenRISC アーキテクチャへの対応
• Zephyr SDK 1.0 への対応（GNU ツールチェーンの更新、Clang/LLVM の試験対応）と、C 言語の最低規格を C17 へ引き上げ
• Wi-Fi P2P（Wi-Fi Direct）と WireGuard VPN
• Arm Cortex-M の新しいコンテキストスイッチ実装（CONFIG_USE_SWITCH）
• ヒープ破壊を検出する CONFIG_SYS_HEAP_HARDENING と、スコープを抜けるときに後始末を自動で行う cleanup ヘルパー

4.5で入る予定の変更：rc3時点のリリースノート草稿

4.5.0 は2026年9月30日に rc1、10月22日に rc3 が出ました。v4.5.0-rc3 のタグに含まれるリリースノートの草稿（Working Draft）が挙げる主な変更は次のとおりです。正式版までに項目が変わる可能性があります。

• アーキテクチャに Infineon TriCore（車載向け AURIX）と Qualcomm Hexagon（DSP）を追加。arch/archs.yml は11から13に増えます
• ネットワークに QUIC と HTTP/3、SSH のサーバーとクライアント、AI エージェントから機器の機能を呼べる MCP（Model Context Protocol）サーバー、IPv4 転送と NAT を追加。TCP のスループットは zperf のループバック測定で最大21%向上
• 新しいドライバー API として、ブザー、クロック監視、照明制御の DALI、車載シリアルバスの LIN など
• west spdx が SPDX 3.0 の SBOM に対応
• 新規ボード178種と、拡張ボード（シールド）29種

4.5 のサポート期間は通常版と同じ約1年なので、量産製品の土台にするなら、2027年4月予定の 4.6 LTS を待つか、3.7 LTS を使う判断になります。

製品開発ではLTS、試作では最新版を選ぶ判断基準

製品の保守期間が2029年7月までに収まり、3.7 が対応するSoCとドライバーで足りるなら、3.7 LTS を選んでください。期限までセキュリティ修正が届き、版を上げる作業を製品のライフサイクルに合わせて計画できます。出荷が2027年後半以降になる新規開発なら、4.4 系で開発を始め、2027年4月予定の 4.6 LTS に乗り換える計画も現実的です。一方、3.7 にない新しいSoCや、4.x で入ったドライバー（USB ホスト、NAND フラッシュ、Wi-Fi P2P など）が必要なら 4.4 系を使います。4.4 のサポート終了は2027年4月12日です。4.6 LTS は同月の公開予定なので、移行・検証期間を確保するため、保守中の 4.5 を経由する計画も見積もってください。3.7 から 4.x へ上げるときは、版ごとの Migration Guide に書かれた非互換の変更を順に当てる必要があります。

カーネルと構成の仕組み：KconfigとDevicetree

スレッドとスケジューリング・メモリ保護

カーネルは優先度ベースのスケジューラを持ち、協調型（自分で CPU を明け渡すまで切り替わらない）と横取り型（優先度の高いスレッドが割り込む）のスレッドを混在させられます。同じ優先度どうしはラウンドロビンにもできます。MPU や MMU を持つ x86・ARC・Arm では、スレッドごとのメモリ保護とユーザー空間を使えます。MPU の無い小型マイコンでは、アプリとカーネルを1つのアドレス空間で動かす1枚のイメージになります。

Kconfigで機能を選びDevicetreeでハードウェアを記述する構成

Zephyr の設定は2本立てです。どの機能をビルドに入れるかは Linux カーネルと同じ Kconfig で、アプリの prj.conf に CONFIG_xxx=y の形で書きます。どのピンに何がつながっているかは Devicetree で記述し、ボードごとの .dts と、アプリ側で差分を足す .overlay に書きます。

公式サンプル Blinky（samples/basic/blinky）を見ると、2つの役割の違いが分かります。prj.conf は1行だけです。

CONFIG_GPIO=y

ソースの src/main.c は、LED のピン番号を一切書いていません。Devicetree で led0 という別名が付いたノードを参照し、ピンの情報はビルド時に埋め込まれます。以下は v4.4.2 の公式サンプルそのまま（Apache-2.0）です。

/*
 * Copyright (c) 2016 Intel Corporation
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <stdio.h>
#include <zephyr/kernel.h>
#include <zephyr/drivers/gpio.h>

/* 1000 msec = 1 sec */
#define SLEEP_TIME_MS   1000

/* The devicetree node identifier for the "led0" alias. */
#define LED0_NODE DT_ALIAS(led0)

/*
 * A build error on this line means your board is unsupported.
 * See the sample documentation for information on how to fix this.
 */
static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios);

int main(void)
{
	int ret;
	bool led_state = true;

	if (!gpio_is_ready_dt(&led)) {
		return 0;
	}

	ret = gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE);
	if (ret < 0) {
		return 0;
	}

	while (1) {
		ret = gpio_pin_toggle_dt(&led);
		if (ret < 0) {
			return 0;
		}

		led_state = !led_state;
		printf("LED state: %s\n", led_state ? "ON" : "OFF");
		k_msleep(SLEEP_TIME_MS);
	}
	return 0;
}

このため、同じ main.c を STM32 のボードでも nRF のボードでも、ビルド時の -b の指定を変えるだけで動かせます。led0 を定義していないボードでは GPIO_DT_SPEC_GET の行でビルドエラーになるので、その場合は .overlay で別名を追加します。

対応アーキテクチャとボード：11アーキテクチャ・1,014ボード

v4.4.2 のソースで arch/archs.yml と各ボードの board.yml を数えた結果は次のとおりです。

v4.4.2 のボードは 1,014 件で、board.yml の vendor 欄の値は160種類あります。Espressif の ESP32 系、Raspberry Pi の Pico と Pico 2、M5Stack の Core2 や AtomS3 といった、日本で手に入りやすいボードも含まれています。手元のボードが対応しているかは、ワークスペースで west boards を実行するか、公式ドキュメントのボード一覧で調べます。

native_simとQEMUによる実機なしの動作確認

native_sim は Zephyr のアプリをカーネルごと Linux の実行ファイルとしてビルドするボードです。単体テストや CI で実機を使わずに動かせます。ただし生成物は Linux 用なので、Windows では WSL、macOS では Linux の仮想マシンを使います。既定の native_sim は32ビットの実行ファイルを作るため、Debian や Ubuntu では gcc-multilib を入れておかないと bits/libc-header-start.h が見つからないというエラーで止まります。64ビットで作るなら -b native_sim/native/64 を指定します。v4.4.2 の hello_world を Debian のコンテナで動かすと、起動時に *** Booting Zephyr OS build v4.4.2 *** と表示されたあと Hello World! native_sim/native が出力されました。CPU の命令セットまで再現したいときは qemu_x86 や qemu_cortex_m3 を指定すると QEMU 上で起動します。Zephyr SDK 1.0 からは QEMU が各OS向けに同梱されています。

開発環境の構築とビルド手順：westでBlinkyを動かす

Zephyr のソース取得・ビルド・書き込みは、すべて west というコマンドで行います。v4.4.2 の Getting Started で求められる最低バージョンは CMake 3.20.5、Python 3.12、Devicetree コンパイラ 1.4.6 です。以下の macOS の手順は Apple Silicon 搭載の Mac 向けです。v4.4.2 の公式ガイドは x86-64 の macOS（Intel Mac）をサポート対象外としているので、Intel Mac では Linux の仮想マシンかコンテナを使ってください（この記事のメモリ使用量の測定も Debian のコンテナで行いました）。Apple Silicon の Mac では、Homebrew で依存ツールを入れます。

brew install cmake ninja gperf python3 python-tk ccache qemu dtc libmagic wget openocd

続けて Python の仮想環境を作り、west を入れて 4.4.2 のソースを取得します。--mr で版のタグを指定しないと、開発中の main ブランチが取得されます。west update は HAL などのモジュールも取りにいくので、数GBの通信と時間がかかります。手順の原典は4.4 版の Getting Startedです。

python3 -m venv ~/zephyrproject/.venv
source ~/zephyrproject/.venv/bin/activate
pip install west

west init --mr v4.4.2 ~/zephyrproject
cd ~/zephyrproject
west update
west zephyr-export
west packages pip --install

cd ~/zephyrproject/zephyr
west sdk install

この手順は 4.4.2 向けです。3.7 LTS には west packages と west sdk がまだ無いので、--mr v3.7.2 で取得したあと、Python の依存は pip install -r ~/zephyrproject/zephyr/scripts/requirements.txt で入れ、ツールチェーンは v3.7.2 が指定する Zephyr SDK 0.16.9 のアーカイブを展開して setup.sh を実行します。詳しくは3.7 版の Getting Startedに従ってください。

準備ができたら Blinky をビルドして書き込みます。

cd ~/zephyrproject/zephyr
west build -p always -b <ボード名> samples/basic/blinky
west flash

-p always は前回のビルド結果を消してから作り直す指定で、公式は初めての人に推奨しています。nRF5340 DK のようにコアが複数あるボードでは、nrf5340dk/nrf5340/cpuapp のようにSoCとコアまで指定します。LED のないボードでは、代わりに samples/hello_world を使います。

ZephyrとFreeRTOSの比較：ライセンス・構成・実測性能

組み込み向けのオープンソースRTOSで、Zephyr と並んで選ばれるのが FreeRTOS です。両者は同じRTOSでも、何を提供するかの範囲が違います。

v4.4.2のFlash・RAM使用量：nRF52840 DKでサンプルごとにビルドした結果

ドライバーまで一式そろう Zephyr が実際にどれだけメモリを使うかを確かめるため、v4.4.2 を Zephyr SDK 1.0.1（GCC 14.3.0）で公式サンプルごとにビルドし、リンカーが出力する使用量を記録しました（2026年10月23日）。ボードは Nordic の nRF52840 DK（Flash 1MB、RAM 256KB）で、基本はサンプルの既定設定です。minimal だけは common.conf・arm.conf に no-mt.conf か mt.conf を組み合わせ、-DCONF_FILE で指定しました。既定ではサイズ優先の最適化（CONFIG_SIZE_OPTIMIZATIONS=y）、MPU によるスタック保護、完全版の printf が有効になっています。

使用量は、ビルドの最後に表示される次の表から読み取れます（hello_world の例）。RAM欄はリンク時に割り当てられた領域のサイズで、実行中のスタックやヒープの最大使用量を測った値ではありません。

west build -p always -b nrf52840dk/nrf52840 samples/hello_world

Memory region         Used Size  Region Size  %age Used
           FLASH:       19924 B         1 MB      1.90%
             RAM:        4544 B       256 KB      1.73%

今回の nRF52840 DK 向けビルドでは、シリアル出力またはGPIOのサンプルは Flash 約20KB、RAM 5KB弱でした。Flash 64KB・RAM 16KB 級の別マイコンを採用する場合は、そのボード向けにビルドして必要容量を確認してください。samples/basic/minimal のようにスレッドやコンソールを外していくと Flash 7KB台まで下がります。一方、Zephyr 自身の BLE コントローラー（CONFIG_BT_LL_SW_SPLIT=y）とホストを載せた peripheral_hr は Flash 約158KiB・RAM 約28KiB です。BLE 製品では、アプリ本体と、MCUboot で無線更新する場合の2スロット分を足して Flash の容量を見積もってください。

なお、west update で取得するモジュールを絞っている場合、BLE のサンプルは PSA_CRYPTO の Kconfig 警告で止まります。4.4 系の BLE ホストは暗号処理を PSA Crypto API で行うので、mbedtls と tf-psa-crypto の2モジュールも取得してください。FreeRTOS は同じボードで同じ機能をそろえた公式サンプルが無いため、この表には並べていません。

UL Solutionsの実測：コンテキストスイッチと割り込み応答

性能の比較でよく引用されるのが、UL Solutions がブログで公開した測定です。STM32F429ZIT6 上で RTOSBench を各1,000回実行し、平均のCPUサイクル数を比べています。測定した版は FreeRTOS v10.4.4 と Zephyr v2.6.0 です。両OSとも assert を無効にし、Zephyr 側は v2.5.0 から既定で有効になったハードウェアのスタック保護も切った条件なので、製品の既定設定で出る数値ではありません。

切り替えと割り込みは FreeRTOS が速く、ミューテックスやキューで待ちに入る処理は Zephyr が速いという結果です。UL は差が出た理由の可能性として、FreeRTOS がミューテックスをキューのコードで実装しているのに対し、Zephyr は専用の実装を持つことを挙げています。ただし Zephyr 側は4年以上前の版で、4.4 では Cortex-M 向けに、CONFIG_USE_SWITCH で有効にする新しいコンテキストスイッチ実装が追加されています。数十サイクルの差が要件を左右するなら、Zephyr に同梱されている tests/benchmarks/latency_measure を自分のボードで実行して測り直してください。

Zephyrを選ぶ場面とFreeRTOSを残すべき場面

BLE や Wi-Fi、USB、ファイルシステムを組み合わせる製品や、同じアプリを複数メーカーのマイコンに載せる製品は Zephyr を選んでください。FreeRTOS でこれらをそろえると、ベンダーSDK・ネットワークスタック・ビルド環境を自分でつなぎ合わせることになり、マイコンを替えるたびに HAL に依存するドライバー部分とビルド設定を移植し直して検証する必要があります。Zephyr を土台にしたセンサー機器やゲートウェイの開発を外部に相談する場合は、AI/IoTソリューションで機器側の設計から相談できます。

逆に、次の場合は Zephyr への移行を急ぐ理由がありません。

• ESP-IDF のように、ベンダーSDKそのものが FreeRTOS を前提に作られていて、そのSDKの機能を使い切っている
• RAM が数KB しかなく、タスクの切り替えだけあればよい小さなマイコンで、通信スタックも不要
• CMake・Kconfig・Devicetree に慣れたメンバーがおらず、数か月で試作を終える必要がある（最初のビルドが通るまでのつまずきが大きい）

RTOS 全般の比較はRTOSの仕組みと主要製品の比較、ThreadX（旧 Azure RTOS）との違いはAzure RTOSの記事、安全認証が必要な場合はQNXの記事で説明しています。

セキュリティ体制とEU CRA対応：脆弱性の公開期限とSBOM

Zephyr には脆弱性の報告と修正を担うセキュリティ委員会があり、報告された問題を深刻度と悪用のしやすさから非公開で扱うかどうか判断します。非公開扱いになった脆弱性は最長90日で公開され、その内訳はプロジェクト内で修正する30日と、Zephyr を使う製品メーカーが修正を配布するための60日です。

非公開期間中の情報は vulnerability-alerts というメーリングリストで共有されます。会員企業以外も公式サイトの Vulnerability Registry から参加を申請でき、プロジェクトディレクターの審査で正当な関心があると認められれば登録されます。Zephyr を使った製品を出荷するなら、申請しておく価値があります。

製品の部品表（SBOM）は west spdx で作れます。ビルドに使ったソースの SPDX-License-Identifier を読み取り、4.4.2 では SPDX 2.3（指定すれば 2.2）の形式で出力します。手順は、ビルドディレクトリを先に初期化し（使用中の build があれば別名で退避しておく）、CONFIG_BUILD_OUTPUT_META=y を有効にしてビルドし（下の例はビルド時に -D で渡す形）、最後に生成する順です。

west spdx --init -d build
west build -d build -b <ボード名> samples/basic/blinky -- -DCONFIG_BUILD_OUTPUT_META=y
west spdx -d build

EU 市場に製品を出す場合は、EU サイバーレジリエンス法（CRA）も関係します。公式ドキュメントには CRA の解説ページがあり、2026年9月11日から製造者に報告義務がかかり、2027年12月11日に全面適用されると書かれています。報告の対象は、CRA 第14条で悪用が確認された脆弱性と重大なインシデントに限られています。脆弱性対応の手順と SBOM を最初から仕組みとして持っている点は、Zephyr を選ぶ理由の1つになります。

よくある質問

ZephyrOSは無料で商用利用できますか？

できます。本体は Apache License 2.0 で、利用料もソース公開の義務もありません。ただし、取り込む外部モジュールに別ライセンスのものがあるので、出荷前に west spdx で一覧を出して確認してください。

ZephyrとFreeRTOSはどちらを選べばよいですか？

BLE・Wi-Fi・USB などを使う製品や、複数メーカーのマイコンへ展開する製品なら Zephyr です。ベンダーSDKが FreeRTOS 前提で作られている場合や、タスク切り替えだけが必要な小さなマイコンなら FreeRTOS が向いています。

ZephyrとLinuxの違いは何ですか？

Linux は汎用OSで、MMU の無い CPU 向けの NOMMU 構成もありますが、主な対象は MMU を持つアプリケーションプロセッサです。Zephyr は最初からマイコン向けに設計されたRTOSで、必要な機能だけを Kconfig で選んで小さなイメージを作ります。Kconfig と Devicetree という設定の仕組みは Linux から取り入れていますが、カーネルのコードは別物です。

実機がなくてもZephyrを試せますか？

試せます。Linux 上なら native_sim でアプリを普通の実行ファイルとして動かせます。macOS や Windows では qemu_x86 などを指定し、Zephyr SDK に同梱の QEMU で起動します。

今から使うならどの版がよいですか？

量産製品なら2029年7月まで保守される 3.7 LTS、新しいSoCやドライバーが必要なら最新の 4.4 系です。4.5 は2026年10月下旬に正式版が出る予定ですが、通常版なのでサポートは約1年です。4.4 のサポートは2027年4月に終わるので、使う場合はそれまでに保守中の版、たとえば2027年4月予定の次期LTS 4.6 へ移る前提で計画してください。

関連記事

• RTOSとは？リアルタイムOSの仕組み・主要製品の比較と採用判断を実装者目線で解説
• 組み込みOSとは？3分類の境界とITRON系の位置づけ・選定判断を実装者向けに解説
• Azure RTOSとは？Eclipse ThreadX移管後の入手先・ライセンス・Azure IoT連携の現状を実装者向けに解説
• QNXとは？マイクロカーネル型RTOSの構造とSDP 8.0・安全認証から採用判断まで実装者向けに解説
• RISC-VとArm・x86の違いを比較｜ライセンス・命令長・OS対応で選ぶ【2026年】