はじめに

2026年10月、オープンソースの組み込み向け OS Zephyr RTOS の周りで、2 つの発表が続きました。10月1日、Texas Instruments（TI）が、自社のマイコン（MCU）・マイクロプロセッサー（MPU）・無線デバイスを Zephyr で正式にサポートすると発表しました。10月9日には Zephyr Project が、PyTorch の端末向け推論実行系 ExecuTorch が Zephyr の公式の外部モジュールになったと発表しました。

片方は「どのチップで動くか」、もう片方は「その上で AI モデルをどう動かすか」の話です。2 つを重ねると、ベンダーをまたいで同じ OS・同じ推論ランタイムでファームウェアを書けるという形が見えてきます。ESP32-S3 で書いたセンサーと推論のコードを、TI のマイコンや NPU 付きの Arm マイコンに、ボードの指定を変えて持っていく。チップを選び直すたびに SDK と書き方を覚え直す手間が、設定の差し替えに縮みます。この記事では、Zephyr・ExecuTorch・NPU の基礎から始め、2 つの発表の中身、NPU の実測で見えた「前処理が推論より長い」という事実の読み方、手元の ESP32-S3 で west build を通す手順までを順に見ていきます。内容は 2026年10月10日時点の一次資料にもとづきます。

📌 この記事の3行まとめ
  • ExecuTorch が Zephyr の公式外部モジュールに。west のマニフェストに足して prj.conf で有効にし、ほかのモジュールと同じく west build でビルドする
  • Ethos-U55 NPU 付きのマイコンで量子化 MobileNetV2 を動かした実測では、推論 27.7ms に対して入力の前処理が 33.3ms。NPU の手前の「餌やり」がボトルネックだった
  • TI は Cortex-M0 クラスの低消費電力マイコンから Cortex-M33、MPU、無線デバイスまでを Zephyr の対象とし、upstream first（先に本家に入れる）の開発を掲げる

🌱 1. Zephyr RTOS とは

Zephyr は、Linux Foundation のもとで開発されているオープンソースのリアルタイム OS（RTOS）です。ライセンスは Apache 2.0 で、Arm Cortex-M・RISC-V・Xtensa（ESP32）など多くの CPU とボードに対応しています。成り立ちや採用が広がっている理由は、Zephyr RTOS の入門記事で詳しく扱っているので、ここでは今回の話に必要な 3 つの道具だけを押さえます。

道具 役割 例
devicetree 基板のハードウェア構成（どのピンに何がつながっているか）を、コードの外のファイルで記述する LED が GPIO 何番か、I2C センサーのアドレス
Kconfig ソフトウェアの機能の入り切りを設定ファイルで選ぶ prj.conf に CONFIG_EXECUTORCH=y と書く
west ソースの取得・ビルド・書き込みをまとめるコマンド west update・west build -b <ボード>・west flash

ポイントは、アプリのコードとボードの違いが分離されていることです。LED の位置は devicetree が知っていて、アプリは「led0 を点ける」と書くだけです。だから同じ blinky のサンプルが、-b に渡すボード名を変えるだけで ESP32-S3 でも Pico 2 でも TI のマイコンでもビルドできます。

flowchart TD subgraph OLD["ベンダー SDK ごとの縦割り"] A1["アプリ A"] --> S1["ESP-IDF"] --> H1["ESP32-S3"] A2["アプリ B"] --> S2["Pico SDK"] --> H2["RP2350"] A3["アプリ C"] --> S3["MSPM0 SDK"] --> H3["MSPM0"] end subgraph NEW["Zephyr で横断"] B["1 つのアプリ
＋ ExecuTorch"] --> Z["Zephyr
devicetree・Kconfig・west"] Z --> M1["ESP32-S3"] Z --> M2["RP2350"] Z --> M3["MSPM0"] Z --> M4["Alif E8"] end OLD ~~~ NEW

ベンダーの SDK は、そのチップの機能を最大限に使えるのが強みです。その代わり、チップを替えるとビルドの仕組みからドライバの書き方まで変わります。Zephyr は共通の土台を用意して、ベンダーごとの差（HAL）をモジュールとして下に入れる、という作りです。

🔥 2. ExecuTorch とは

ExecuTorch は、PyTorch で作った AI モデルを、スマートフォン・ウェアラブル・マイコンなどの端末で動かすための、PyTorch 公式の書き出し（エクスポート）と実行の仕組みです。ライセンスは BSD 3-Clause です。

flowchart TD P["PyTorch のモデル
（PC 側）"] --> Q["書き出し・量子化
（int8 に変換）"] Q --> D["分割：NPU で動く部分を
バックエンドに委任"] D --> V["NPU 用コンパイラ
（Arm Vela）"] V --> PTE[".pte ファイル"] PTE --> FW["Zephyr のファームに組み込み
（マイコン側）"] FW --> NPU["NPU：畳み込みの本体"] FW --> CPU["CPU：NPU が扱えない処理
（CMSIS-NN）"]

PC 側でモデルを書き出し、マイコンが読める .pte という 1 つのファイルにまとめます。このとき、NPU が得意な計算はその NPU 向けの「バックエンド」に委任（delegate）し、NPU にできない計算は CPU 用のカーネルに残す、という分割が自動で行われます。マイコン側では、ExecuTorch の小さな実行系（ランタイム）が .pte を読み込んで推論します。

⚡ 3. NPU（Ethos-U）とは

NPU（Neural Processing Unit）は、ニューラルネットワークの計算、特に大量の掛け算と足し算（積和演算）に特化した演算器です。Arm の Ethos-U は Cortex-M と組み合わせて使うマイコン向けの NPU で、U55・U65・U85 の系列があります。今回の実測に使われた Ethos-U55 は、1 サイクルに 256 回の積和演算を行う構成でした。

Zephyr のブログによると、Ethos-U55 は整数専用で、浮動小数点の変換はできません。そのため、量子化されたモデルの入口と出口（float と int8 の変換）は CPU が受け持ちます。この分担が、次の節の実測の読み方につながります。

📊 4. 発表の中身

ExecuTorch が Zephyr の公式モジュールに

Zephyr の「モジュール」は、west がビルドに取り込む外部のリポジトリで、ベンダーの HAL やファイルシステム、Bluetooth なども同じ仕組みで入っています。ExecuTorch もこれと同じ扱いになりました。使い方はブログの説明どおり 3 段です。

  1. west のマニフェスト（west.yml）に ExecuTorch のリポジトリを足して west update
  2. アプリの prj.conf に CONFIG_EXECUTORCH=y を書く（Ethos-U を使うなら CONFIG_ETHOS_U=y も）
  3. ほかのアプリと同じく west build でビルドし、PC 側で書き出した .pte を -DET_PTE_FILE_PATH= で渡す
manifest:
  projects:
    - name: executorch
      url: https://github.com/pytorch/executorch
      revision: main   # またはリリースのタグ
      path: modules/lib/executorch
      submodules: true

サンプルは hello-executorch と、実測に使われた mv2-ethosu の 2 つが同梱されています。ボード設定が用意されているのは、Alif Ensemble E8、Arm の Corstone-300／320 FVP（ハードウェアを模擬するシミュレーター）、Arduino UNO Q です。ほかの Cortex-M ボードでは、ボードごとの設定と、モデルが収まるだけのメモリが必要だとブログは書いています。

実測：前処理が推論より長い

ブログは、Alif Ensemble E8 DevKit（Cortex-M55＋Ethos-U55）で、int8 に量子化した MobileNetV2（入力 224×224×3）を動かし、時間の内訳を測っています（ExecuTorch v1.5.1・Zephyr 4.4.0・Zephyr SDK 1.0.1）。

段階 どこで動くか 時間 全体に占める割合
入力の前処理（uint8 → float32、150,528 要素） Cortex-M55 33.3 ms 約 55%
推論 execute()（20 回・最小 27.68／最大 27.71） Ethos-U55（境界の変換は CPU） 27.7 ms 約 45%
出力の取り出し Cortex-M55 約 1 µs ほぼ 0%
合計 61.0 ms 100%

割合は表の値からの計算です。そのほかの数字は次のとおりです。

項目 値
モデル（.pte）の大きさ 3,364,928 バイト（MRAM に格納）
ファームウェア＋モデル 3,811,280 バイト（フラッシュ 5,600KB の 66.5%）
RAM 3,257,044 バイト（8MB の 38.8%）
分割 Ethos-U の区画 1 つ。int8 と float の境界だけ CPU

推論そのものより、NPU に渡す前の入力の準備のほうが長くかかっています。ブログの分析では、画像は uint8 で届くのにモデルは float32 を受け取る作りなので、15 万個の値を Cortex-M55 が 1 つずつ変換しています。400MHz で 1 要素あたり約 88 サイクルで、引き算と割り算に必要な量を大きく上回っています。MRAM から読んで 602KB の float32 を書き出すループなので、計算ではなくメモリの読み書きが律速になっている、という説明です。

ブログの結論は「このパイプラインでは、アクセラレーターはボトルネックではない。ボトルネックは、アクセラレーターに餌をやることだ」でした。カメラを使う用途で NPU の大きさを決めるときに、勘定に入れるべき点だとしています。なお、この変換は取り除けます。ExecuTorch の QuantizeInputs という変換を使うと、モデルが int8 の入力を直接受け取るようになり、float への変換が要らなくなるとブログは注記しています。

推論の正しさも確かめられていて、犬・バナナ・モデムの 3 枚の写真で、マイコン（int8＋NPU）と PC（float32）の分類結果がすべて一致しました。

💡 ワード解説：版の指定に注意

2026年10月10日時点で、資料ごとに ExecuTorch の版が違います。Zephyr のドキュメントの例は v1.4.0、ブログの計測は v1.5.1（PyPI の最新）で、ブログの分類例そのものは「1.6.0 以降、未公開ならマニフェストで revision: main」が必要と書かれています。ブログが示す PC 側の前提は、Linux か macOS・Python 3.12 以上・cmake 4.0 未満です。

TI の対応範囲

TI の発表は、マイコン・MPU・無線デバイスの「幅広い組み込み製品群」を Zephyr で正式にサポートするというものです。FAQ では、対象を「超低消費電力の Arm Cortex-M0 クラスから高性能な Cortex-M33 までのマイコン、MPU、無線デバイス」と説明しています。開発の進め方として次の点を挙げています。

  • upstream first：SDK を出す前に、Zephyr のコミュニティが TI のコードをレビューする
  • 公開の CI/CD：GitHub 上で、SDK になる前の新機能に早く触れられる
  • 長期の保守：検証済みのリリースや移行ガイドをそろえ、10 年を超える製品寿命を支える
  • 規制への対応：TI は自社の Zephyr プラットフォームを EU のサイバーレジリエンス法（CRA）に準拠したものと説明している

「幅広い」がどこまでかを、Zephyr 本体のリポジトリの boards/ti で確かめました（2026年10月10日時点）。

区分 主なボード（Zephyr のボード名） CPU
汎用マイコン MSPM0 lp_mspm0g3507・lp_mspm0g3519・lp_mspm0l2228 Cortex-M0+
汎用マイコン MSPM33 lp_mspm33c321a Cortex-M33（160MHz）
モーター制御マイコン lp_am13e230 Cortex-M33（200MHz）
無線（BLE） lp_em_cc2340r5 Cortex-M0+
無線（Sub-GHz・BLE ほか） cc1312r1・cc1352p1・cc1352p7・cc1352r1・cc1352r_sensortag・cc26x2r1 の各 LaunchPad Cortex-M4F
無線（Wi-Fi） cc3220sf・cc3235sf の各 LaunchPad Cortex-M4
MPU（Sitara） sk_am62・am62l_evm・sk_am64・am243x_evm・lp_am243 Cortex-A53・M4F・R5F の各コア
従来品 msp_exp432p401r・tm4c123gxl（Tiva C） Cortex-M4F

このうち lp_mspm33c321a・lp_am13e230・lp_am243・tm4c123gxl は、2026年10月10日時点では開発版（main）に入っていて、Zephyr の最新リリース系列 4.4 のタグ（v4.4.0）にはまだありません。次のリリースで正式に入ると思われます。MPU のボードでは、Zephyr は Linux を動かす大きなコアの横にある Cortex-M4F や R5F のコアを担当する構成が中心で、AM62 と AM62L では Cortex-A53 向けのボード設定もあります。

🔧 5. 手元で試す手順

ESP32-S3 で west build を通す

まずは「同じ手順でボードを替えられる」ことを手元で確かめます。Zephyr の Getting Started Guide に沿った Windows の例です（Ubuntu と macOS も同じ流れです）。Python は 3.12 が強く推奨されています。

winget install Kitware.CMake Ninja-build.Ninja oss-winget.gperf Python.Python.3.12 Git.Git oss-winget.dtc wget 7zip.7zip
cd $Env:HOMEPATH
py -3.12 -m venv zephyrproject\.venv
zephyrproject\.venv\Scripts\Activate.ps1
pip install west
west init -m https://github.com/zephyrproject-rtos/zephyr zephyrproject
cd zephyrproject
west update
west packages pip --install
cd zephyr
west sdk install
west blobs fetch hal_espressif

ESP32 系は無線の動作に Espressif のバイナリ（blob）が必要で、west update の後に west blobs fetch hal_espressif で取得します。準備ができたら、ESP32-S3-DevKitC のボード名でサンプルをビルドして書き込みます。

west build -p always -b esp32s3_devkitc/esp32s3/procpu samples/hello_world
west flash

シリアル端末（115200bps）に Hello World! とボード名が出れば成功です。LED が devicetree に定義されているボードなら、samples/basic/blinky も同じ形でビルドできます。

同じワークスペースで Pico 2 W も試せます。ボード名は rpi_pico2/rp2350a/m33_0/w です。Pico 2 W は Wi-Fi チップの先に LED がつながっているため、Zephyr のドキュメントでは blinky に未対応とされています。Wi-Fi のファームウェアを west blobs fetch hal_infineon で取得してから、samples/net/wifi/shell を試すよう案内されています。

ExecuTorch のサンプルは FVP でも動く

NPU 付きのボードがなくても、Arm の Corstone-300／320 FVP で hello-executorch を動かせます。ブログの前提は Linux か macOS のホストです。手順は ExecuTorch の Zephyr モジュールの README にまとまっていて、要点は次のとおりです。

  1. west init --manifest-rev v4.4.0 でワークスペースを作り、zephyr/submanifests/executorch.yaml に ExecuTorch を足して west update
  2. west sdk install --gnu-toolchains arm-zephyr-eabi で Arm 用のツールチェーンを入れる
  3. ExecuTorch のセットアップと、Arm のツール（TOSA・Vela・FVP）を入れるスクリプトを実行する
  4. 足し算だけの小さなモデルを .pte に書き出し、west build -b mps3/corstone300/fvp … -t run でビルドと実行をまとめて行う

FVP は動作を正確に模擬しますが、実機よりずっと遅いとブログは注意しています。FVP で測った時間は実機の速度の目安になりません。確かめられるのは「書き出したモデルが Zephyr 上で正しく動くか」までです。

結果を入れる表

試すこと ボード／環境 結果
hello_world のビルドと書き込み ESP32-S3 未実施
blinky のビルドと書き込み ESP32-S3（LED 定義のあるボード） 未実施
Wi-Fi shell のビルド Pico 2 W 未実施
hello-executorch の実行 Corstone-300 FVP（Ubuntu） 未実施
📌 筆者の見方

筆者はふだん ESP32 を ESP-IDF で、STM32 をベンダーのツールで書いていて、チップを替えるたびに「ビルドの仕組みを覚え直す時間」を払ってきました。ESP-IDF v6.1 の記事で見たように、同じベンダーの中でも版が上がれば破壊的変更を踏みます。ボードの違いを devicetree に押し込み、推論までモジュール 1 つで足せる Zephyr の方向は、複数のチップを行き来する個人の作り手にこそ効くと筆者は受け止めています。

いちばん面白かったのは、前処理 33.3ms の話です。オシロで波形を見ていても、遅いのは目立つ部品ではなく、その手前のデータの受け渡しだった、という経験は何度もあります。NPU という派手な演算器を積んでも、15 万個の値を CPU が 1 つずつ変換しているうちは速くならない。公式のブログが、自分たちのデモの弱点をそのまま数字で出し、直し方まで添えている点も好ましく感じました。

CRA については、TI は自社のプラットフォームを CRA 準拠と説明していますが、CRA の本体の義務が始まるのは 2027年12月11日で、製品としての適合は最終的に製造者が示すものです。脆弱性に何年も追従し続けるという点で、upstream first と長期保守の約束は CRA の考え方と同じ向きだと筆者は読んでいます。ROS 2 と micro-ROS の記事で触れた Zephyr 上の ROS 2 とあわせて、まずは手持ちの ESP32-S3 と Pico 2 W で、同じワークスペースから 2 つのボードにビルドを通すところから確かめるつもりです。

✅ まとめ

  • 2026年10月9日、ExecuTorch が Zephyr の公式外部モジュールになった。マニフェストに足し、prj.conf で有効にし、west build でビルドする
  • Ethos-U55 での実測は、前処理 33.3ms・推論 27.7ms・合計 61.0ms。NPU の手前の入力変換が律速で、QuantizeInputs で取り除ける
  • 2026年10月1日、TI はマイコン・MPU・無線デバイスの Zephyr 対応を発表。Zephyr の boards/ti には Cortex-M0+ の MSPM0 から Cortex-M33、Sitara の MPU まで 21 のボードがある（main・10月10日時点）
  • ボードの違いを devicetree と Kconfig に寄せる Zephyr に、推論ランタイムまで乗ったことで、ベンダーをまたいだ同じ書き方が AI の部分まで広がった
  • 次の一手は、手元の ESP32-S3 と Pico 2 W で同じワークスペースからビルドを通し、FVP で hello-executorch を動かすこと

よくある質問（FAQ）

Q: ESP32 で ExecuTorch は動きますか？

A: 2026年10月10日時点で ExecuTorch の Zephyr サンプルにボード設定があるのは、Alif Ensemble E8、Corstone-300／320 FVP、Arduino UNO Q で、いずれも Arm のコアを使う環境です。ブログは、ほかのボードではボードごとの設定と、モデルが収まるメモリが必要だとしています。ESP32 での動作は公式には示されていません。

Q: なぜ前処理が推論より長くなったのですか？

A: モデルが float32 の入力を受け取る作りで、uint8 の画像 150,528 要素を Cortex-M55 が 1 つずつ変換していたためです。ブログはメモリの読み書きが律速だったと分析しています。ExecuTorch の QuantizeInputs でモデルが int8 を直接受け取るようにすれば、この変換は不要になります。

Q: NPU がないマイコンでも ExecuTorch は使えますか？

A: 使えます。Zephyr のドキュメントは、Ethos-U NPU を使う手順と、NPU のない CPU だけの手順の両方を案内しています。CPU だけの場合は Cortex-M 向けの CMSIS-NN のカーネルで動かします。

Q: TI のどのチップが Zephyr で使えますか？

A: Zephyr のリポジトリの boards/ti には、MSPM0（Cortex-M0+）、MSPM33 と AM13E（Cortex-M33）、CC13xx／CC26xx／CC23xx／CC32xx の無線マイコン、AM62／AM64／AM243x などの MPU のボードがあります（2026年10月10日時点の main）。一部は次のリリースから入る見込みです。

Q: Zephyr を試すのに特別な機材は要りますか？

A: 要りません。ESP32-S3 の開発ボードや Pico 2 W など、手持ちのボードでサンプルをビルドできます。ExecuTorch のサンプルは、Arm の FVP（シミュレーター）を使えばボードがなくても動かせます。

関連記事

参考