STM32で始める Zephyr RTOS
FreeRTOSとの違いと
使い分け判断ガイド

はじめに：なぜ今Zephyrなのか

STM32のRTOSといえば長らく「STM32CubeMXでFreeRTOSを有効化」が定番でした。弊社でも多くの案件でこの構成を採用しており、その基本は STM32 + FreeRTOS 入門 で解説したとおりです。しかしここ数年、新規案件のRTOS選定でZephyr RTOSが対抗馬として挙がる機会が急激に増えています。

背景には3つの流れがあります。

• プロジェクトの成熟：ZephyrはLinux Foundation傘下で2016年に発足し、2026年で10周年を迎えました。2026年3月のembedded world（ニュルンベルク）では10周年が大きく取り上げられ、参画企業も拡大を続けています。サポートボードは1000種類超、STM32はNucleo/Discoveryを中心にほぼ全シリーズが公式対応です
• EUサイバーレジリエンス法（CRA）：2024年12月に発効したCRAは、2026年9月11日から脆弱性報告義務、2027年12月11日から本格適用が始まります。Zephyrは2017年からCVE採番機関（CNA）として活動し、SBOM自動生成（west spdx）や脆弱性アラート登録制度を整備しており、「CRA時代のRTOS」として注目されています
• 「カーネルだけ」では足りない製品要件：BLE・Wi-Fi・USB・ファイルシステム・OTA更新が当たり前になり、カーネル単体のFreeRTOSでは周辺ライブラリの寄せ集めとバージョン管理が負担になってきました

本記事では、実際にNucleo-F446REを使ってwest環境構築 → Lチカ → スレッド → デバイスツリーと手を動かしながらZephyrの世界観を掴み、最後にFreeRTOSとの使い分け基準を整理します。なお執筆時点（2026年7月）のZephyr最新安定版はv4.4.0（2026年4月14日リリース）、長期サポート版（LTS）はv3.7です。

ZephyrはFreeRTOSと何が違うのか

最初に押さえるべき本質的な違いは、提供範囲です。

• FreeRTOSは「カーネル」：スケジューラ・タスク・キュー・セマフォを提供するC言語ソース一式（十数ファイル）です。GPIOやUARTのドライバはST社のHAL、BLEやTCP/IPは別ライブラリを自分で組み合わせます。プロジェクト構成の主導権はSTM32CubeMX/CubeIDEにあります
• Zephyrは「OSディストリビューション」：カーネルに加えて、デバイスドライバ（GPIO/UART/I2C/SPI/ADC/CAN…）、Bluetooth LEスタック、ネットワークスタック、ファイルシステム、ロギング、シェル、テストフレームワークまでを単一のソースツリーとビルドシステムで提供します。ST社のHALもhal_stm32モジュールとしてZephyrのドライバ内部に取り込まれています

この違いが開発フローに直結します。FreeRTOSでは「CubeMXでポチポチ設定してコード生成」でしたが、Zephyrではwest（メタツール）でソースを取得し、デバイスツリーでハードウェアを記述し、Kconfigで機能を選択してビルドします。GUIのコード生成ツールは基本的に使いません。Linuxカーネル開発の作法をマイコンに持ち込んだ、と考えると理解が早いです。

つまりZephyrの学習コストの大半は、RTOSカーネルのAPIではなくビルドシステムと設定機構（west・デバイスツリー・Kconfig）にあります。逆に言えば、そこさえ越えればカーネルAPIはFreeRTOS経験者ならすぐ読めます。

west環境構築：実コマンドで一気に

Ubuntu（WSL2含む）での手順です。Zephyrの公式Getting Startedに準拠しています。事前にaptで cmake（3.20.5以上）、ninja-build、device-tree-compiler（1.4.6以上）、python3-venv 等を入れておきます。Pythonは3.12が強く推奨されています（新しすぎるPythonでpipパッケージのビルドに失敗する事例があるため）。

# 1. Python仮想環境を作成してwestをインストール
python3 -m venv ~/zephyrproject/.venv
source ~/zephyrproject/.venv/bin/activate
pip install west

# 2. Zephyr本体と依存モジュール（hal_stm32等）を取得
west init -m https://github.com/zephyrproject-rtos/zephyr ~/zephyrproject
cd ~/zephyrproject
west update          # 数GB。初回は時間がかかる

# 3. CMakeパッケージ登録とPython依存のインストール
west zephyr-export
west packages pip --install

# 4. Zephyr SDK（クロスコンパイラ一式）をインストール
cd ~/zephyrproject/zephyr
west sdk install

ポイントを補足します。

• west update が取ってくるのはZephyr本体だけではない：modules/hal/stm32（ST公式HAL/LL）など数十のモジュールリポジトリを west.yml（マニフェスト）に従って一括チェックアウトします。FreeRTOSで「HALのバージョンとミドルウェアのバージョンの組み合わせ」に悩んだ経験があるなら、このマニフェストによるバージョン一括固定はZephyrの大きな魅力です
• SDKはARM GCCを含むツールチェーン集：west sdk install 一発で入ります。STM32CubeIDE同梱のGCCとは独立しているので既存環境を汚しません
• 仮想環境の有効化を忘れない：シェルを開き直したら毎回 source ~/zephyrproject/.venv/bin/activate が必要です。「昨日は動いたのに west: command not found」の原因はほぼこれです

Nucleo-F446REでLチカ（blinky）

まずは公式サンプルの samples/basic/blinky を焼いてみます。Nucleo-F446REはZephyrに nucleo_f446re というボード名で登録されており、オンボードLED（LD2 / PA5）とユーザーボタン（PC13）、コンソール用UART（USART2、115200bps 8N1、ST-LINKの仮想COM経由）まで定義済みです。

cd ~/zephyrproject/zephyr

# -p always: ビルドディレクトリを毎回クリーン（ボード切替時の事故防止）
west build -p always -b nucleo_f446re samples/basic/blinky

# ST-LINK経由で書き込み（STM32CubeProgrammerランナー）
west flash

LD2が1秒周期で点滅すれば成功です。blinkyの main.c は本質的に次の内容です。

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

#define SLEEP_TIME_MS 1000

/* デバイスツリーの led0 エイリアスからピン情報を取得（ビルド時に解決） */
#define LED0_NODE DT_ALIAS(led0)
static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios);

int main(void)
{
    if (!gpio_is_ready_dt(&led)) {
        return 0;
    }
    gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE);

    while (1) {
        gpio_pin_toggle_dt(&led);
        k_msleep(SLEEP_TIME_MS);
    }
    return 0;
}

FreeRTOS + HALの感覚で見ると、コードのどこにも「GPIOA」「ピン5」が出てこないことに気づくはずです。DT_ALIAS(led0) は「このボードで led0 と名付けられたLED」をデバイスツリーから引いてくるマクロで、実体（PA5）はボード定義ファイルに書かれています。だからこのmain.cは一切書き換えずに west build -b nucleo_h743zi でH7ボードでも動きます。これがZephyr流の移植性です。

スレッドを作る：FreeRTOSとの対応表つき

ZephyrではFreeRTOSの「タスク」に相当するものを「スレッド」と呼びます。もっとも簡単な作り方は K_THREAD_DEFINE マクロによる静的定義です。

#include <zephyr/kernel.h>

#define STACK_SIZE 1024

/* センサー読み取りスレッド（高優先） */
void sensor_thread(void *p1, void *p2, void *p3)
{
    while (1) {
        /* ここでI2Cセンサー読み取りなど */
        k_msleep(100);
    }
}

/* ログ出力スレッド（低優先） */
void logger_thread(void *p1, void *p2, void *p3)
{
    while (1) {
        printk("uptime=%lld ms\n", k_uptime_get());
        k_msleep(500);
    }
}

/* K_THREAD_DEFINE(名前, スタック, エントリ, 引数x3, 優先度, オプション, 開始遅延ms)
   注意: Zephyrは数値が小さいほど高優先度（FreeRTOSと逆！） */
K_THREAD_DEFINE(sensor_tid, STACK_SIZE, sensor_thread, NULL, NULL, NULL, 5, 0, 0);
K_THREAD_DEFINE(logger_tid, STACK_SIZE, logger_thread, NULL, NULL, NULL, 7, 0, 0);

スケジューラの起動コード（FreeRTOSの osKernelStart() 相当）がどこにも無い点に注目してください。Zephyrではカーネルが main() より先に初期化され、main() 自体が1つのスレッドとして走ります。K_THREAD_DEFINE したスレッドは起動時に自動で走り出します。動的生成したい場合は k_thread_create()（スタック領域は K_THREAD_STACK_DEFINE で確保）を使います。

最重要の注意：優先度の向きがFreeRTOSと逆

Zephyrの公式ドキュメントには「数値が小さい優先度が、数値が大きい優先度に優先する」と明記されています。つまり優先度5のスレッドは優先度7のスレッドより偉い。FreeRTOS（数値が大きいほど高優先）の頭のままコピペ移植すると、優先度設計が丸ごと反転する事故になります。さらにZephyrでは負の優先度は協調（cooperative）スレッドという特別な意味を持ち、自分からブロックするまでプリエンプトされません。

FreeRTOS API → Zephyr API 対応表

ISR まわりはZephyrの方がシンプルで、セマフォやメッセージキューはFreeRTOSのように「FromISR版を呼び分ける」ことなくそのまま使えます（ISR内ではブロック禁止＝K_NO_WAITを指定）。ただしすべてのAPIがISR対応（isr-ok）ではなく、たとえばミューテックスはISRから一切使えない点には注意してください。FreeRTOSでのISR連携の勘所は FreeRTOS編の記事 で解説しています。

デバイスツリー：FreeRTOS経験者が最初に躓く壁

Zephyr導入でつまずくポイントの筆頭がここです。逆にここを理解すればZephyrは一気に楽になるので、考え方を丁寧に説明します。

考え方：ハード構成をCコードから追い出す

CubeMX + HALの世界では「PA5を出力に設定」というハードウェアの事実が、生成コードやマクロ定義としてCソースの中に散らばります。Zephyrではこれをデバイスツリー（Devicetree）という宣言的なテキスト（.dts / .dtsi / .overlay）に分離します。階層は次のとおりです。

• SoC定義（.dtsi）：stm32f446.dtsi など。USART2は0x40004400にある、といったチップの事実。Zephyr本体に同梱
• ボード定義（.dts）：nucleo_f446re.dts。LD2はPA5、コンソールはUSART2、といったボードの事実。これも同梱
• アプリのオーバーレイ（.overlay）：自分の基板・配線の事実。アプリ側で「上書き・追記」する差分ファイル

アプリのディレクトリに boards/nucleo_f446re.overlay（または全ボード共通なら app.overlay）を置くと、ビルド時に自動で合成されます。たとえばI2C1に温度センサーを追加する場合はこう書きます。

/* boards/nucleo_f446re.overlay */
&i2c1 {
    status = "okay";                 /* Nucleo-F446REの板定義では既にokayだが、SoC定義でdisabledのボードでは必須 */
    clock-frequency = <I2C_BITRATE_FAST>;   /* 400kHz */

    temp_sensor: lm75@48 {           /* I2Cアドレス0x48のセンサーを登録 */
        compatible = "lm75";
        reg = <0x48>;
    };
};

ここで重要なのが2点。

• status = "okay" の概念：SoC定義には全ペリフェラルが書かれていますが、大半は disabled 状態です。使うものだけをボード定義かオーバーレイで okay にします。「CubeMXでペリフェラルにチェックを入れる」操作のテキスト版だと思えば良いです
• compatible がドライバとの結び付け：compatible = "lm75" と書くと、Zephyrに同梱されたLM75ドライバがこのノードに紐付き、アプリからは sensor_sample_fetch() 等の統一センサーAPIで読めます。デバイスドライバを自分で書かずに済むのがZephyrの生産性の源泉です

Kconfig（prj.conf）の基本

デバイスツリーが「ハードに何があるか」なら、Kconfigは「ソフトの機能を何を組み込むか」です。アプリ直下の prj.conf に CONFIG_* を列挙します。

# prj.conf の例
CONFIG_GPIO=y              # GPIOドライバ
CONFIG_I2C=y               # I2Cドライバ
CONFIG_SENSOR=y            # センサーサブシステム（lm75等のドライバ含む）
CONFIG_LOG=y               # ロギングサブシステム
CONFIG_SHELL=y             # UARTコンソールで対話シェルが使える
CONFIG_MAIN_STACK_SIZE=2048

使わない機能はリンクすらされないため、フットプリントを絞れます。設定項目は膨大ですが、west build -t menuconfig でLinuxカーネルと同じ対話UIから検索・変更できます（確定したら prj.conf に書き戻すのが流儀です）。

FreeRTOS経験者向けに対応づけると、FreeRTOSConfig.h（configTOTAL_HEAP_SIZE 等）＋「CubeMXのMiddlewareチェックボックス」を合わせたものが prj.conf です。ここで最頻出のハマりが「デバイスツリーで有効化したのにKconfigを忘れる」パターン。I2Cノードを okay にしても CONFIG_I2C=y が無ければドライバが組み込まれず、device_is_ready() が偽を返します。デバイスツリーとKconfigは両輪、と覚えてください。

FreeRTOSとの比較表と使い分け基準

使い分けの判断基準

弊社がRTOS選定の相談を受けたときに使っている判断軸です。

• FreeRTOSが向くケース：単機能の制御機器（モーター制御・計測など）／Flash 256KB未満の小容量MCU／CubeMX中心の既存開発フローを崩したくない／チームがFreeRTOS習熟済みで納期が短い／既存FreeRTOS資産の派生開発
• Zephyrが向くケース：BLE・ネットワーク・USB・OTAなどミドルウェアを複数使う製品／将来のMCUベンダー変更（供給リスク対策）を見込む／EU市場向けでCRA対応の脆弱性管理・SBOM提出が必要／複数製品でコードベースを共通化したい／CIでの自動テストを重視する

一言でまとめると、「マイコンに毛が生えた装置」はFreeRTOS、「小さなコネクテッド製品」はZephyrが第一候補です。

既存FreeRTOS資産がある場合の移行判断

「今のFreeRTOS製品をZephyrに移すべきか」という相談も増えていますが、結論から言うと動いている製品の載せ替え単体では割に合わないことが多いです。理由は3つあります。

1. カーネルAPIの置換は移行工数の2割程度：前述の対応表のとおりAPI変換自体は機械的ですが、実際の工数の大半はHAL直叩きコードのZephyrドライバAPIへの置換、割り込み設計の見直し、デバイスツリー・Kconfigへの構成移植に費やされます。実質「作り直し」に近い見積もりが必要です
2. 優先度の向きの反転などの地雷：優先度体系（数値の大小が逆、協調スレッドの存在）、ティック・タイムアウトの扱いなど、コンパイルは通るのに挙動が変わる差分が多く、リグレッションテストの整備が前提になります
3. 検証済みという資産価値：量産で実績のあるFreeRTOSコードは、それ自体が検証コスト数人月分の資産です

移行に踏み切る合理性があるのは、次のような「どうせ大きく手を入れる」タイミングです。

• 製品のネットワーク化・無線化など大規模な機能追加で、ミドルウェア寄せ集めの限界が見えたとき
• MCUの供給問題・EOLでベンダー/シリーズ変更が必要になったとき（どうせドライバ層は書き直しになる）
• CRA対応で脆弱性監視・SBOM・セキュリティ更新の長期体制をOSSコミュニティに相乗りする形で構築したいとき

現実的な進め方としては、既存製品はFreeRTOSのまま保守を続け、新規プロジェクトや次世代機からZephyrを並行導入してチームの経験値を貯める二本立てを推奨しています。

FreeRTOS経験者がハマる落とし穴

まとめ

RTOSの選定は、製品のライフサイクル全体のコストを左右する意思決定です。FreeRTOS・Zephyrそれぞれの得意領域を踏まえた技術選定からお手伝いできますので、お気軽にご相談ください。

よくある質問（FAQ）