超低レベルC言語プログラミング・オープンソースRTOSの現在地

小規模デバイスを対象とした組み込みソフトウェア開発現場における、オープンソース系リアルタイムOS の現在地について書き記しました。

個人的な主観がかなり入っている記事ですので、「そういう感じ方もあるのか」程度に軽く読んでいただければ幸いです。

結論

いきなり結論ですが。
そこそこのスペック（フットプリント）を持つマイコンで、かつ、ある程度の規模のソフトウェア開発を、これから新規案件で進めるなら 「Zephyr OS 一択」 になっていくのではないかと感じています。

この結論に至った事柄を順を追って解説していきます。

過度的には、マイコンメーカーの SDK が対応しているRTOS＆ミドル、例えばSTマイクロのSTM32であれば、現時点では Eclipse ThreadX（NetX Duo / FileX）が標準でエコシステムに組み込まれていますので、メーカー縛りというロックインを受け入れるのであれば、これらは現時点でも魅力的な選択肢ではあります。

ITRON系RTOS

主に μT-Kernel や TOPPERS といったプロジェクトの成果物ですね。TOPPERS はμ秒オーダーのモーション・リアルタイムシステム対応やマルチコア対応など、今でも積極的な開発が進んでいるようです。

とは言え、どちらかというと「仕様自体はオープンだけど、実質的には商用RTOS」というイメージで、コミュニティが積極的に開発を進めているという、いわゆる OSS な立ち位置ではないという認識で、本稿では触れないでおきます。

同様に、商用 RTOS ＆ミドルについては言及しない記事となっています。ITRON 系で言うならミスポさんの NORTi やイーフォースさんの μC3、非ITRON系ですと QNX や VxWorks、GreenHills の INTEGRITY や µ-velOSity、 SEGGER の embOS といった、歴史があり安全認証も取られていてサポート体制も充実している商用 RTOS を使われている現場も多いか（むしろ製造業ではほとんど）と思います。こちらは、（欧州サイバーレジリエンス法対応という大きな波はあるものの）今後も大きな変化はないのかな、という風に受け取っています。

μITRONと海外勢の比較

μITRONとFreeRTOSの両方に触れた方なら、これらのRTOSの根底にあるポリシーの違いに気が付いたのではないでしょうか。このあたりのことについて少し掘り下げます。

先ずは、ITRONと海外勢の表面的な比較から。

項目	TRON系	FreeRTOS	Eclipse ThreadX	Zephyr OS
主な推進母体	国内団体 (トロンフォーラム / NPO)	AWS (Amazon)	Eclipse Foundation	Linux Foundation
ライセンス	T-License / TOPPERSライセンス	MITライセンス	MITライセンス	Apache 2.0
設計ポリシー	高効率・高リアルタイム性 仕様の標準化と最適化	シンプル・軽量 圧倒的な導入の手軽さ	高信頼・安全認証済み・ミドルウェアの充実	モダン・多機能Linuxライクな開発環境
強み・エコシステム	国内の産業機器・車載で強固な実績。仕様が厳密。	世界シェア1位。AWSや各種マイコンとの連携が最強。安全認証済み。	元・高級商用OSのコード品質。	最新の通信技術やデバイスドライバを標準網羅。
弱み・課題	海外での知名度・英語ドキュメントやエコシステムが弱い。	OS自体はシンプルすぎて、高度な機能は自作・連携が必要。	Microsoftの手を離れた過渡期であり、今後のコミュニティ次第。	メモリ消費（フットプリント）が従来のRTOSより大きい。

ポリシー・思想の決定的な違い

後述しますが、コンセプト自体、ITRON系の「タスクの動的・静的管理」やイベントフラグの挙動など、よりシステムを意識した思想に対し、欧米流のセマフォ/ミューテックス至上主義といった感じで、根底の部分でかなりの違いがあります。

一般論的な事柄を軽くまとめます。

1. 「OS単体の性能」 vs 「開発プラットフォームの利便性」
   1. 国内勢： マイコンの性能を100%引き出すための「リアルタイム性」や「省メモリ」というOS自体の職人的な完成度を重視
   2. Zephyr/FreeRTOS等： OS単体の軽さよりも、「最新のBluetoothやクラウド連携のコードが最初から動く」という開発をいかに早くスタートできるかという利便性を重視
2. エコシステムの規模と「英語圏」の壁
   1. 海外勢： Linux FoundationやAWSといった巨大な資金・コミュニティがあるため、世界中のエンジニアがバグ修正や最新マイコンへの対応を推進している
   2. TRON系： 技術的には優れているものの、コミュニティが日本中心かつ内向きであるため、最新マイコンやドライバが公式で用意されにくいという側面がある

いつだったかFreeRTOSがバージョンアップの時に「日本人からのリクエストでイベントフラグ（イベントグループ）を実装したよ」と言ってきたけど、μITRONのイベントフラグとは似て非なるもので「これじゃμITRON用に書いたコード（タスク）のマイグレーションは無理だな」となったことがあります。
結論としては「冷静に考えるとITRONチックなイベントフラグを多用するのは、コードの抽象度が低くなるし良くないよね」といなり、こちら側の意識も欧米風のスタイルに近づいていきましたが。

FreeRTOS や ThreadX、Zephyr OS といった海外発のリアルタイムOSと、日本発の T-Kernel / TOPPERS（ITRON系）との最大の違いは、「グローバルなエコシステム（標準化団体・巨大IT企業）の巻き込み方」と「開発コミュニティのポリシー」にあります。

日本のITRON系が「仕様の標準化や実用的な職人技」を重視してきたのに対し、海外勢は「ライセンスの手軽さ」や「巨大テック企業によるクラウド連携・エコシステム化」を武器に世界シェアを広げてきました。

FreeRTOS

2010年台に入ってから日本国内でも普及が進みました。
既にITRON系RTOSに代わりデファクト的な立ち位置にまでなっているので、解説は不要かと思います。

そのFreeRTOS、当時、大きなニュースになりましたが2017年、AWSに買収されました。
それまで純粋なオープンソースとして極めてシンプルだったFreeRTOSですが、買収後は「AWSのクラウド（AWS IoT Core）に繋ぐためのライブラリ」が大量に同梱され、どんどん肥大化していくこととなります。

純粋にローカル環境で動かしたいエンジニアからすると、「Amazonの影がちらつくようになった」「余計なライブラリが増えて見通しが悪くなった」と、この変化にちょっと違和感を感じたり感じなかったり。

FreeRTOSは元々個人（Richard Barry氏）のホビープロジェクトからスタートし、長年の「継ぎはぎ」で肥大化したため、コードの可読性や一貫性に難があり、毎年のように重大な脆弱性（CVE）が報告される構造的な弱さもあります。

FreeRTOSのカーネルソースに対し、ちょっと垢抜けない感じというか、そこはかとない古さ（あるいは素人っぽさ）を感じるのは私だけではないでしょう。それでも、STマイクロ・ルネサス・NXPと、そうそうたるマイコンメーカーが自社のエコシステムとして採用してきたので大したものですが。
これに対し、元から軍事・航空宇宙レベルの「プロ向け商用コード」として書かれたThreadXと、Linux財団が総力を挙げてモダンな設計で開発しているZephyr RTOSは、どちらも圧倒的に洗練されている印象を受けます。

また、FreeRTOSはカーネル本体の他にミドルウェアとしてTCP/IPプロトコルスタックが含まれていますが、ネットワーク対応の機器では、OSSのミドルウェアである LwIP（TCP/IPプロトコルスタック）や FatFS（FATファイルシステム）と組み合わせて使用することが多かったのではないでしょうか。

これらミドルウェアもFreeRTOSに増してアマチュアっぽいソースコードで、「正直大丈夫かいな？」という印象を持った次第です。実際、大丈夫ではなく、これらを採用したソフトは、前職である「弊社」から世に送り出されることが無かったというオチも付きました。

少々ディスった解説になりましたが、個人的に大好きだったRTOSです。

Eclipse ThreadX (Azure RTOS)

Microsoft が商用 RTOS の雄だった ThreadX を買収し、自社クラウドである「Azure」の名を冠して世に送り出した RTOS です。

かなりセンセーショナルな登場で、一時は「これからは FreeRTOS じゃなくて Azure RTOS の時代か？」という雰囲気も感じました。
実際、STマイクロ（STMicroelectronics）は、同社の看板マイコンである STM32Cubeエコシステムにおいて、長年親しまれてきた FreeRTOS ＋ LwIP のオープンソース構成から、「信頼性とパフォーマンスが格段に高い」という売り文句と共に Azure RTOS への完全なフルモデルチェンジを大々的にブチ上げていました。

しかし2024年、Microsoftはその権利を手放して、完全なオープンソース化（Eclipse Foundationへの寄贈）すると共に、その名称を「Eclipse ThreadX」と変えます。

非常に興味深い変遷ですので、文字数を割いて追っていきます。

ThreadX・主な特徴とメリット

1. 極小のフットプリント（省メモリ）
   カーネル部分のコードサイズはわずか2〜6 KB、RAM使用量も2 KB程度に抑えられます。そのため、リソースが極めて制限されたマイクロコントローラ（MCU）にも問題なく実装可能です（FreeRTOSとほぼ同等かと）。
2. 圧倒的な高速性と決定論的スケジューリング
   サブマイクロ秒単位での高速なコンテキストスイッチ（タスク切り替え）を実現しており、すべてのAPIが O(1)（一定時間）で実行されます。タイミング精度が厳格な制御システムでも安定して動作します。
3. 独自の最適化機能
   • プリエンプション・スレッシュホールド（Preemption Threshold）：
     二重の優先度を設定することで、不要なコンテキスト切り替えを減らし、処理能力が低いプロセッサの効率を最大化します。
   • 優先度継承ミューテックス：
     リアルタイムシステムで注意が必要な「優先度の反転」を自動的に回避します。
4. 高い安全認証実績
   航空機向けの「DO-178C」、産業機器向けの「IEC 61508」、自動車向けの「ISO 26262」など、ミッションクリティカルな分野の安全規格・認証を多数取得しています。
5. クラウド連携とエコシステム
   Microsoftのクラウドサービスである Azure IoT Hub や Azure IoT Central との親和性が非常に高く設計されています。Azure IoT Middleware を介して、セキュリティ（TLS等）を保ったままエッジデバイスからクラウドへ簡単にメッセージ送信が可能です。
   また、主要なマイコンベンダーの統合開発環境（IDE）やハードウェアに深く統合されており、メーカーが提供するSDKやドライバと組み合わせてすぐに開発を始められるエコシステムが構築されています。

ThreadX・主要な構成コンポーネント

用途に応じて組み合わせられる包括的なソフトウェアスイートとして構成されています。

コンポーネント名	役割・機能
ThreadX	システムの核となるリアルタイムカーネル（マルチタスクやメモリ管理を制御）
NetX Duo	IPv4およびIPv6にネイティブ対応したTCP/IPネットワークスタック
FileX	各種ストレージ（FAT12/16/32やexFATなど）に対応したファイルシステム
USBX	ホストおよびデバイス双方をサポートするUSBスタック
GUIX	組み込み機器の画面UIを表示・制御するためのグラフィックスライブラリ
TraceX / GUIX Studio	実行時の挙動の可視化や、GUI画面のレイアウト・デザイン設計を行うWindows用ツール

衝撃の撤退劇

各マイコンメーカーのSDK（開発キット）に標準で組み込ませるほど強力なプロモーションを行っていたため、この撤退劇は組み込み業界でも大きな衝撃を持って受け止められました。
Microsoftが手放してオープンソース（Eclipse Foundationへの寄贈）に踏み切った背景には、「IoT戦略の割り切り」と「生成AIへの急速なシフト」という、巨大テック企業ならではのシビアな経営判断があります。主な理由は以下の3点に集約されます。

1. 「OSの囲い込み」はクラウドの利益に繋がりにくかった

MicrosoftがThreadXを買収した最大の目的は、「自社のクラウド（Azure）へモノを繋ぐための強力な武器」にすることでした。しかし、組み込みの世界にはすでに「FreeRTOS」（AWSがサポート）などの強力な無料オープンソースOSが定着していました。

開発者から見れば、いくら高性能でも「Microsoftが権利を持つOS（Azure RTOS）」を使うと、将来的にAzure以外のクラウド（AWSやGoogle Cloudなど）へ移行しにくくなるリスク（ベンダーロックイン）を懸念して敬遠されがちでした。OSのレイヤーで囲い込む戦略が、思うようにAzureのシェア拡大に直結しなかったのです。

2. 「安全認証」の維持・保守コストが重すぎた

Azure RTOS (ThreadX) の最大の強みは、航空機や自動車、医療機器で使えるレベルの「厳格な安全・セキュリティ認証」を多数取得している点です。

しかし、これらの認証を維持し、コードが改定されるたびに検証ドキュメントをアップデートし続けるには、莫大なエンジニアリングリソースと維持コスト（機能安全コスト）がかかります。すでに「十分に成熟し、Azureと連携できるライブラリも一通り完成した」段階に達したため、Microsoftとしては「これ以上自社だけでこの重い保守・運用コストを抱え続けるメリットが薄い」と判断したようです。

3. 生成AI（Copilot）への爆発的なリソース集中

これが最も決定的な理由です。

2022年末のChatGPTの登場以降、Microsoftの社内戦略は「生成AI（Copilot）」へ最優先でリソースを集中させる方向へ激変しました。時価総額トップを争う厳しい戦いの中で、「エッジデバイス向けの地味で手のかかるRTOSの運用」に人員や予算を割くよりも、クラウドとWindowsをAI化する「Copilotエコシステム」の構築にすべてのリソースを突っ込んだ方が、はるかにリターンが大きいと経営陣が判断したためと推測できます。

結局はMicrosoftがAmazon(AWS)に対抗するためRTOSを抱え込もうとしたけど、時代が変わったから手放したってことですね。ビッグテックって怖い。AlteraをIntelが買収して手放したのと似た構図を感じます。

結果として : 誰も損をしない「前向きな手放し」

一見すると「Microsoftに、無責任に見捨てられた」ようにも見えるのですが、実はEclipse Foundationへの寄贈は決して悪い話ではありません。

業界・開発者にとっては、特定のクラウドベンダーに依存しない「ベンダーニュートラル」なOSになり、AWSなど他社クラウドとの接続性も向上する。かつ、商用利用しやすいMITライセンスで、世界最高峰の安全認証を持つRTOSが「無料」で使えるようになった。

現在、ThreadXの安全認証の維持やエコシステムの拡大は、ルネサスやSTマイクロ、NXPといった主要な半導体メーカーが参加する「ThreadX Alliance」などのコミュニティに引き継がれ、オープンな形で開発が継続されています（Microsoftはこのように、時代に合わせて自社のこだわりを捨てて大胆に方針転換することで知られています）。

「Eclipse」って、あのIDE（開発環境）のEclipse？

はい。あのJavaの開発環境などで有名な 「Eclipse」の運営母体 です。

正確には、IDEそのものではなく、そのIDEを管理・運営するために設立された非営利の標準化団体「Eclipse Foundation（エクリプス財団）」に寄贈されました。なぜここに寄贈されたのか、そして現在の位置づけについて簡単に整理します。

元々はIBMが作ったコミュニティEclipseは2001年にIBMが開発したIDEがベースになっていますが、特定の企業（IBM）に依存しないオープンな開発環境にするため、2004年に「Eclipse Foundation」という独立した非営利団体が作られました。

現在は組み込みシステム、IoT、自動車向け OSS の巨大なハブへと進化しています（例えば、自動車業界の標準オープンソース活動である「Eclipse Velocity」や、IoT向け通信プロトコル「MQTT」のオープンソース実装（Paho）なども、すべてEclipse Foundationが管理しています）

だからこそ、Eclipse Foundationが「信頼できる、ベンダーニュートラル（特定の企業に偏らない）で、組み込み業界に強い団体」として Microsoft から選ばれたのだと推測されます。
これにより、特定のクラウドに縛られないニュートラルなOSであることが証明され、ルネサスやSTマイクロ、NXPなどの半導体ベンダーも安心して「ThreadX Alliance」として資金や技術を出し合える拠り所となったのです。

皮肉なことに、Microsoftの勝手な都合で手放された結果、「特定のビッグテックに振り回されない、最も安全なコミュニティ（Eclipse）」に保護されることになったのは、ThreadXにとって不幸中の幸いだったと言えます。

なぜSTマイクロはあれほどAzure RTOSに社運を賭けたのか？

STマイクロ が FreeRTOS から Azure RTOS へ乗り換えたのを信じて、評価や移行の準備を進めていた開発者にとっては、まさにハシゴを外された形です。

どうしてSTマイクロがここまで深くコミットしてしまったのか、そしてこの「大誤算」のあと、STマイクロが現在どう動いているのか（FreeRTOS＋LwIPの代替としての行方）について、生々しい業界の裏側を掘り下げます。

STマイクロがFreeRTOS＋LwIPを捨ててでもAzure RTOS（ThreadX）に移行したかったのには、明確なメリット（計算）がありました。

• 「継ぎはぎ」からの脱却
  それまでの「FreeRTOS（OS）＋LwIP（ネットワーク）＋FatFs（ファイルシステム）」という組み合わせは、世界中で使われているものの、すべてバラバラのオープンソースをエンジニアが手作業で統合した「継ぎはぎのシステム」でした。一方、Azure RTOS（ThreadX/NetX Duo/FileX）は、最初からすべてが完全に密結合するように設計された「プロ仕様のオールインワンスイート」だったため、性能もバグの少なさも段違いでした。
• 「無料なのに最高品質」という魔法のパッケージ
  ThreadXは、本来なら数百万〜一千万円レベルのライセンス費用が飛ぶ超高級・高信頼性RTOSです。それをMicrosoftが買収し、「STM32のユーザーならロイヤリティフリー（無料）で使っていい」というライセンス契約をSTマイクロと結びました。STマイクロからすれば、「自社のマイコンを買えば、世界最高峰の有料級OSと通信スタックがタダで付いてくる！」という、競合（NXPやルネサスなど）に圧倒的な差をつけるための最強のセールストークになるはずだったのです。

結果として、STマイクロは膨大なエンジニアリングリソースを投じて、STM32CubeMXのコード自動生成ツールの中にAzure RTOSをガチガチに組み込みました。それが、わずか数年でMicrosoft側から一方的に「もうやめます」と言われたのですから、STマイクロの担当者の衝撃と怒りも想像を絶するものだったはずです。

今、STM32のエコシステムはどうなっているのか？（現状と対策）

ハシゴを外されたSTマイクロですが、現在は以下のような形で「実質的な救済措置と軌道修正」を進めています。

1. Eclipse ThreadX（旧Azure RTOS）としての継続サポート
   Microsoftが手放したThreadX一式は、オープンソース（MITライセンス）の Eclipse ThreadX として生まれ変わりました。これを受けてSTマイクロは、これまでSTM32Cubeに組み込んできたAzure RTOSの資産を捨てるのではなく、Eclipse ThreadXへとパッケージを置き換えてサポートを継続しています。つまり、「FreeRTOS＋LwIP」の代替として、「ThreadX（OS）＋NetX Duo（ネットワーク）」の組み合わせは、現在もSTM32でそのまま（しかもMITライセンスで完全に無料で）使い続けることができます。Microsoftという後ろ盾は失われましたが、コードの圧倒的な軽さと通信スタックの速さはそのまま残っています。
2. 主要半導体ベンダー連合による「共同保守」への移行
   「Microsoftが保守してくれないなら、バグや脆弱性が出たらどうするんだ？」という不安に対し、STマイクロは、ライバルであるルネサスやNXP、そしてAMDなどと手を組み「ThreadX Alliance」を結成しました。自社たちのマイコンの売れ行きに直結するため、現在は半導体メーカーたちが共同で資金と技術を出し合い、Eclipse ThreadXのバグ修正やアップデート、安全認証の維持を支えています。
3. 「FreeRTOS＋LwIP」への回帰・二刀流
   皮肉なことに、Microsoftの撤退劇によって「やっぱり特定の1社（巨大テック企業）の都合で方針が変わる独自ライセンスは怖い。オープンソースの方が長生きする」というマインドが業界に広がりました。そのため、STマイクロも現在は「ThreadX一択」という強硬姿勢を緩め、FreeRTOSやLwIP、あるいは次世代のセキュアなネットワークスタックなどを並行して選べる「選択肢の一つ」へと、STM32Cubeの立ち位置をマイルドに戻しています。

今後、STM32ユーザーはどちらを信じて選ぶべきか？

「FreeRTOS＋LwIP」を信じていたのに裏切られ、さらに「Azure RTOS」に期待したのにまた激変が起きた今、今後の選定は非常に悩ましい状況です。現在の着地点としては、以下の2つの視点で判断するのが最も現実的です。

• 性能・品質を最優先するなら：Eclipse ThreadX（旧Azure RTOS）のまま進む
  Microsoftのロゴは消えましたが、コード自体の素性の良さは組み込み業界トップクラスです。半導体ベンダー連合が維持しているため、突然使えなくなるリスクはほぼ消滅しました。「FreeRTOS＋LwIP」よりもメモリ効率が良く、ネットワーク（NetX Duo）のバグも少ないため、技術的な優位性を理由に選ぶのであれば、今からでもEclipse ThreadXを使う価値は十分にあります。
• 長期的な「枯れ感」と安心感を最優先するなら：FreeRTOS＋LwIPに戻る
  性能はThreadXに劣るものの、世界中の数百万人のエンジニアが10年以上使い古し、あらゆるバグが出尽くしているという「圧倒的な安心感」があります。また、仮にAWSがFreeRTOSの手を引いたとしても、コミュニティが巨大すぎて完全に消滅することはあり得ません（とは言えLwIPの脆弱性に対する不安はありますが）。

巨大テック企業の「気まぐれ」に振り回されたSTマイクロと組み込み業界ですが、結果として「ThreadXという超高性能なOSが、特定の企業の利権から解き放たれて完全なパブリック資産（MITライセンス）になった」という意味では、災い転じて福となす、とも言える状況に着地しています。

現在の「Eclipse ThreadX」が抱える懸念点と課題

オープンソース化（MITライセンス）され、Eclipse Foundationに保護されたことで最悪のシナリオは免れたThreadXですが、現場目線ではいくつかの生々しい課題が浮き彫りになっています。

• 最大の強みだった「安全認証」のパッチワーク化と特許問題
  「最初から医療・車載の安全認証（ISO 26262等）がある」のが売りでしたが、Microsoftから譲渡される際、特許権の関係でFileX（ファイルシステム）からexFATサポートが削除されました。コードが変わったため、当時一時的に安全認証が「未認証」状態へと巻き戻るトラブルが発生しました。現在は半導体ベンダー連合（ThreadX Alliance）が必死に再認証を進めていますが、「最新版ならいつでもどこでも100%安全認証付き」という神話には少し傷がついています。
• エコシステムの「厚み」でZephyrやFreeRTOSに劣る
  Eclipse Foundationの調査でも、依然としてFreeRTOSや、Linux財団が推す次世代RTOS「Zephyr」がシェアを伸ばしています。ThreadXは元が高級なクローズドソースだったため、ネット上の野良コード（GitHubのサンプルやTips）の量が圧倒的に少なく、開発者が自力でトラブルシューティングする際のハードルが高めです。
• オープンソース化に伴うセキュリティ脆弱性（CVE）の表面化
  クローズド時代は表に出にくかったバグや脆弱性が、ソースコードが公開されたことで次々と発見されています。NetX DuoやUSBXにおいて、バッファオーバーフローなどの脆弱性（CVE-2024〜2026シリーズ）が報告され、Eclipse ThreadXのセキュリティアップデートで頻繁にパッチが当てられています。オープンになったことで品質は上がりますが、定期的なアップデート対応という「OSSならではの手間」が現場に発生しています。

Zephyr RTOS (Zephyr OS)

このように、現時点では「FreeRTOSを使い続けるか、ThreadXに乗り換えるべきか、それとも別の選択肢を模索するか」という強烈なジレンマに陥っています。
さらに状況を複雑化させているのは、「欧州サイバーレジリエンス法への対応」という課題です（こちらについては後の方で掘り下げます）。

そこで浮上してくるのが「Zephyr OS」となります。

この記事を読まれている方々にとっては、何を今更という感じかもしれませんので、Zephyr に関するディテールは省略し、「ThreadXとの対比」に絞って解説していきます。

Zephyr RTOS の圧倒的な強み

現場が「Zephyr一択」に傾く理由は、そのモダンな開発体験とLinux譲りのスケーラビリティにあります。

• 「デバイスツリー（Device Tree）」によるハードウェア抽象化
  Linuxと同様に、ピン配置やペリフェラル（UART, I2C等）の設定をソースコードではなく「.dts」という設定ファイルに分離します。これにより、マイコンを別のメーカーのものに変えても、（理論的には）アプリケーションコードを1行も書き換えずに移植できるという神がかったポータビリティを実現しています。
• CMake / Kconfig による洗練されたビルド
  FreeRTOSやThreadXのように「IDEにファイルを追加してビルドする」泥臭い方法ではなく、Web開発やLinux開発と同じくVS Code＋GitHub＋CMakeで完全に自動化されたモダンなCI/CD環境が作れます。
• 圧倒的なコミュニティの厚み
  Linux財団がバックにいるため、世界中のトップエンジニアが寄ってたかってコードを綺麗にリファクタリングしています。FreeRTOSのような「個人臭さ」はなく、コードの堅牢性・セキュリティのレビュー体制は現在トップクラスです。

Zephyr RTOS vs Eclipse ThreadX ・徹底比較

ITRONの項で既に出しましたが、この二つに絞り、詳細に比較します。

項目	Zephyr RTOS	Eclipse ThreadX
ルーツ / コードの出自	Intelの商用OS（Rocket）がベース	Express Logic社の超高級商用OS（ThreadX）
設計思想・スタイル	「組み込み版Linux」（デバイスツリー、CMake）	「伝統的な超高速RTOS」（C言語の純関数）
フットプリント（サイズ）	やや大きい（最小でも数十KB〜）	極小（カーネルは2KB〜6KB程度）
動作パフォーマンス	標準的（機能が豊富な分、オーバーヘッドあり）	圧倒的に高速（決定論的、コンテキストスイッチが最速）
エコシステム / 勢い	現在世界No.1の勢い。対応ボードが膨大	半導体ベンダー連合（ThreadX Alliance）が維持
機能安全認証	「セキュア版」を構築中（認証取得はこれから）	取得済み（航空DO-178C、車載ISO26262等）
開発環境（IDE）	VS Code ＋ ターミナル（モダン）	Eclipse系 ＆ 各社ベンダーIDE（伝統的）

RTOSの性能そのものの他に、「職場がモダンな開発手法を受け入れるかどうか」が大きな分かれ道のような気がします。

もう一度、おさらいとして各RTOSの特徴をまとめます。

1. FreeRTOS
   • ポリシー
     「圧倒的な手軽さと、クラウド（AWS）へのシームレスな接続」
   • 特徴
     MITライセンスという極めて自由度の高いライセンスを採用し、世界で最も普及しているRTOSの一つです。非常に軽量で、あらゆるマイコンベンダーが標準サンプルに採用しています。AWS傘下に入ったことで、IoTデバイスからクラウドへ安全・簡単にデータを送るためのセキュリティ・通信機能が標準で強化されています。
2. Eclipse ThreadX (旧 Azure RTOS / Express Logic)
   • ポリシー
     「商用品質・安全認証の最高峰を、オープンソースへ」
   • 特徴
     元々は有料の高級商用RTOS（ThreadX）でしたが、Microsoftによる買収を経て、現在はEclipse Foundationに移管され、MITライセンスのオープンソースとなりました。医療、航空、自動車などの厳しい安全規格（IEC 61508、ISO 26262など）の認証を最初から取得している、極めて信頼性の高いカーネルです。
3. Zephyr OS
   • ポリシー
     「組み込み界のLinux（巨大なマルチベンダーエコシステム）」
   • 特徴
     Intel、NXP、STMicroelectronics、Nordicなど、世界中の半導体大手が共同で開発を主導。
     従来のRTOSとは異なり、Linuxのように「デバイスツリー」を採用し、最初から膨大なハードウェアのドライバや最新の通信プロトコルスタック（Bluetooth Low Energy、Wi-Fi、Threadなど）を内包している「オールインワン型」の近代的なOSです。

ラッパーという考え方

以上を集約すると、
「最終的には Zephyr RTOS、ただし過度的＆小規模開発では ThreadX を併用」
というのが、私個人の、暫定的な、現時点での判断となります。

しかし、先はまだまだ見渡せない状況のようにも思えます。

これまで見てきたように、個人開発や、高額な商用RTOSを全社的に採用できない規模の製造業では、以下のようなタイムラインで遷移してきたケースが多いのではないかと考えます。

「ルネサスマイコンに最適化された μITRON 系の商用 RTOS もしくは自社製 RTOS で完結」
↓
「ルネサスから ST への移行に伴う FreeRTOS 化」
↓ 
「クラウド黎明期のジレンマ（AWS・Azure・Googleどの陣営に乗っかるか）」
↓
「Zephyr の大躍進」
↓
「CRA（欧州サイバーレジリエンス法）による OSS 敬遠」
↓
「商用 RTOS への回帰」と「 Zepher 移行」どちらに進むべきか？

これがここ10〜15年の組み込み業界の荒波とトレンドの変遷であり、まさに開発現場の最前線で直面する「最も深い苦悩」そのものです。

そして、どの方向に進むか分からないが故に、自己防衛のため逃げ道を用意しておきたい。

ここで気になってくるのが、
「ThreadXを採用したプロジェクトに対し、RTOSの抽象化を図り、アプリケーションソフト（タスク）の移植性（再利用性）を高めるべきか？」
という選択肢（方針）です。

これについては、「CMSIS-RTOS」 という事例（興味深い前例）が解決の糸口に向けてのメタファーになると思われます。

CMSIS-RTOSとかいうやつ

STマイクロのSTM32CubeMXでは、長年OSの生のAPIを直接叩かせるのではなく、「CMSIS-RTOS（またはCMSIS-RTOS V2）」という共通の抽象化レイヤー（ラッパー）を標準で被せていました。これによって、下層のOSがFreeRTOSであってもKeilのRTXであっても、アプリケーション側は同じ関数（osThreadNew や osSemaphoreAcquire など）で書ける仕組みを提供していました。

現在（2026年時点）でもSTM32CubeMXでプロジェクトを新規作成する際に「CMSIS-RTOS V2」を選択可能ですが、「Disable（ラッパーを被せない）」が標準となっているようです。
RTX (RTX5)について軽く解説すると、元々は Arm の純正コンパイラなどを提供している Keil 社が開発したもの（RTX）を、Arm 社が継承して進化させた RTOS（RTX5）で、Arm としてのスタンスは「あくまでRTX5が純正、FreeRTOSはセカンドソース」ということになります。
なので正確には、「STマイクロの方針」というより「CMSISの思想・設計をSTマイクロがそのまま取り入れた」というのが本当のところです。

CMSIS-RTOSに対する、現場としての正直な評価

STマイクロやArm社が「マイコンやRTOSを自由に載せ替えられる理想の世界」を目指して作ったCMSIS-RTOSですが、実際の組み込み現場（特にシニアエンジニアの間）では、「理想は素晴らしいが、現実には中途半端で使いにくい」という評価が下されがちでした。

• 「いいとこ取り」ではなく「機能の最大公約数」になってしまった
  異なるRTOSを共通のAPIで包むため、それぞれのRTOSが持つ独自の強力な機能（例えば、ThreadXの「プリエンプション・スレッシュホールド」や、FreeRTOSの「Task Notifications」など）が、CMSIS-RTOS越しだと使えなくなってしまいます。結局、各OSの強みを殺してしまうというジレンマがありました。
• デバッグの難易度が上がる（ブラックボックス化）
  タスクがハングアップした際、スタックトレースを追うと「CMSISのラッパー関数」の中に捕らわれてしまい、生のRTOSのどこで問題が起きているのかが直感的に見えにくくなるという、デバッグ上のオーバーヘッド（足かせ）がありました。
• 不完全なポータビリティ
  「これを使えばOSをFreeRTOSからThreadXに一瞬で変えられる」というのが建前でしたが、実際にはセマフォの挙動やタイムアウトの細かなニュアンスが下層のOSによって微妙に異なるため、結局は移植時にアプリケーション側の微調整が必要になり、「完全な隠蔽」には至りませんでした。

ポータビリティに関する実例

過去に 「μITRONを含め、プロジェクトチームの中でCMSIS-RTOS V2 化して標準化するべきか？」 論議したことがあります。

しかしこれは早々に断念することとなりました。日本が誇る TRON系（µITRON / TOPPERS）のOS をCMSIS-RTOSでラップしようとする試みは、構造的に無理がありました。

• cre_tsk（タスク生成）や wup_tsk（タスク起床）といった、欧米流のRTOSとは時代・コンセプト・ポリシーが異なるTRON独自のAPIをCMSISの枠に無理やり押し込めようとすれば、必ず「細かな振る舞いの不整合（セマンティクスのズレ）」が起きてバグの温床になる。
• さらに決定的なのが、「Cortex系以外のアーキテクチャ（ルネサスRXなど）へのCMSISの強要」という矛盾。CMSISはそもそも「Cortex Microcontroller Software Interface Standard」であり、Armのライバルである独自コアのRXマイコンなどに「Armの規格」を持ち込むこと自体が、政治的にも技術的にも不自然極まりないものでした。結局、現場の「変じゃない？」という極めてまっとうな理性が、その無理な標準化を押し留めたのは必然の結果と言えます。

現在（2026年）のCMSISおよびCMSIS-RTOSの位置付け

現在、ArmのエコシステムにおけるCMSIS（Cortex Microcontroller Software Interface Standard）全体の立ち位置は、大きくシフトしています。

• CMSIS全体（Core, DSP, NN）は「超重要インフラ」として成熟
  レジスタアクセスの共通化（CMSIS-Core）や、AI・信号処理向けの「CMSIS-NN」「CMSIS-DSP」は、コンパイラやハードウェアの性能を極限まで引き出すための必須の超重要レイヤーとして、今なお全幅の信頼を置かれています。ここは完全にデファクトスタンダードです。
• しかし「CMSIS-RTOS」の存在感は急速に薄れている
  皮肉なことに、前述した「Zephyr RTOS」の台頭が、CMSIS-RTOSの存在意義を大きく揺るがしました。Zephyrは「OSそのものが強力なハードウェア抽象化レイヤー（デバイスツリーなど）」を持っているため、ArmのCMSIS-RTOSという枠組みに頼る必要がありません。また、Zephyrは標準で「POSIX thread（pthread）API」をサポートしているため、 世界標準の共通APIを使いたいならCMSISではなくPOSIXで書く 、という流れが強くなっています。

結論として

「短期的にはSTM32Cube環境＋ThreadXとし、次世代のマルチコアSoC＋Zepherへの含みを持たせる」という戦略をとるにあたり、抽象化レベルをどうすべきかという点ですが、「ラッパーは作らず、生のThreadX APIで書く」のが最もスマートだと考えます。

ThreadXは商用クオリティで非常に洗練され、一貫性のある美しいAPI設計（関数名がすべて tx_ で始まる）をしています。コードの可読性も高く、バグも入りにくい美しいC言語で書かれているため、生のThreadX APIで直接書いた方が、その圧倒的な高速性と堅牢性の恩恵を100%享受できます。

次に、マルチコアSoCのようなリッチな環境を見越した時のことを考えても、CMSIS-RTOSに代表される「APIのラッパー」という小手先の共通化ではなく、例えばハードウェアの抽象化はZephyrの「デバイスツリー」のようにOSのレイヤーに任せることで、システム根本の抽象化アーキテクチャの恩恵をフルに享受することができるので、中途半端な取り組みはむしろ逆効果だと思われます。

サイバーレジリエンス法というメガトン級の爆弾と現在の潮流について

ここからは、独自研究多め、かつ（このシリーズ恒例の）かつての職場への恨みつらみで構成されております。

ここ数年の組み込み RTOS の混迷とトレンドの移り変わりに加え、CRA（欧州サイバーレジリエンス法）の法的要件が重なったことで、技術面・法務面の両アプローチから判断が極めて難しくなっている状況にあります。現在の混迷を紐解き、次に進むべき道を整理するための3つの判断軸と各OSの現状を、生成AIの見解を基に整理しました。

CRA対応の搔い摘んだ概略

CRAの内容については、多くの（産業用）機器メーカーのエンジニアがまさに現在進行形で対応に追われてる状況、かつ数多くのネット記事であふれており、読者の皆様の方がはるかに詳しいと思われるため、本稿では丸っと省略いたします。

要するにこれを満たさないと「CEマーキング」を表示できず欧州に輸出できないというもので、逆の言い方をすると「ヨーロッパに輸出しないのなら（当面は）関係ない」ということでもあるのですが、このグローバル化された世界では、このケースはかなりレアなのではないでしょうか。

脆弱性監視と管理、SBOMの義務付け、リスク評価、CRA準拠の社内プロセス管理（IEC 62443）、製品ライフサイクルを通したプロセス管理、その他もろもろ、と、その内容は多岐に渡るのですが、この記事の文脈では「脆弱性」と「SBOM」がキーワードになります。

要点としては、SBOM、つまりソフトウェアの構成管理をすること、つまり、どのようなOSSや商用コンポーネントが組み込まれているか管理・公開し、製品ライフサイクルを通し、日々公開される脆弱性情報の監視や顧客などからの情報を受け付ける組織体制を確立、そして速やかな脆弱性対応（ファームウェアのアップデート）を行うこととなります。

ここまでの内容はある意味当然のことで、他業種のエンジニアから見ると「何をそんなに慌ててるの？」というように映るかもしれません。

しかし実態としては

認証機関（TUV SUD等）の監査をパスするための「ペーパー上のプロセス（規定）」はあるものの、実業務として回すリソースが実質的にゼロだったりします。

本社機能としてPSIRTを立ち上げたものの、開発部隊が自分たちでCVE（脆弱性データベース）を監視し、脆弱性が見つかれば現在進行中の新製品開発を中断し、該当するコンポーネントをセキュリティ対策されたバージョンに入れ替え、その影響を見極め、ソフトウェアテストと製品テストを実施し、とてもヘヴィなプロセスを経てリリース（デプロイ）し、EU加盟国全て（あるいは全世界）に対するパッチ（更新ファーム）配布を本社営業を巻き込んで（頭を下げて）アサインする……。

そのため会社としては「規定上はOKだが、実質的にはOSS非推奨」という判断（風潮）と成らざるを得ないのです。

そうでなくても「OSSなどアマチュアの作った質の悪いソフトウェア」で「短いスパンで勝手にどんどんバージョンが上がり」「しょっちゅうセキュリティホールが見つかる油断ならないもの」という、上の人達が持つ強烈なバイアスもあります。

そのため、「有料の商用RTOSへの回帰（ベンダーがCRAの法的責任やサポートを一部担保してくれるため、脆弱性の監視と管理を販売元に押し付けられる）」、もっと言うなら、「RTOSなしのフル自社製ソフトへの切り替え（実際、これまでもほとんどの製品ソフトはこのスタイルであり、ごく一部のプロジェクトでのみRTOSの使用に目を瞑っている状況）」へと舵が切られている状況でした。

Zephyrの魅力をどう解釈すべきか？

ですが、視点を少し変えてみてみると、実はCRA対応において、Zephyr OS はかなり「正解」に近い状況になっています。

ネットからの引用を記します。

「Zephyrを主導するLinux Foundationは、法規制への対応、SBOMの自動生成、脆弱性管理体制、CRA準拠のプロセス管理に対して、現在業界で最も多額の資金と人員を投入して組織的に動いています」

「コミュニティ自体のガバナンスが企業の製品開発と同等かそれ以上に強固であるため、「適当に放置されている有象無象のOSSとは一線を画す、最もCRAに対応しやすいOSS」になりつつあります」

ということで、機器メーカーよりはるかに高いレベルで、組織的に対応中ということです。しかも（Linuxと同じアプローチで）SBOM生成などが標準化されているのが大きいです。詳しく見てみましょう。

• 「West」ツールによるSBOMの自動生成：
  Zephyrの標準ビルドツール「West」は、ソースコードをコンパイルするのと同時に、CRAで要求されるSPDX形式などのSBOM（部品構成表）をコマンド一つで自動出力します。
• Vulnerability Tracking（脆弱性追跡）の仕組み：
  Linux Foundationの強力な資金力を背景に、Zephyrプロジェクト自体が独自のCNA（CVE番号採番機関）となり、OSや含まれるミドルウェアの脆弱性を組織的に一元管理しています。開発者は、Zephyrのソースを最新（あるいはLTS：長期サポート版）にアップデートし、ビルド時に自動チェックをかけるだけで、「自分たちでCVE（脆弱性データベース）を毎日監視する」という不毛な業務から解放されます。

「弊社」のような「回せない組織」を救う仕組みがOS側に組み込まれている訳です。上の人達がそれを受け入れるかどうかは、また別問題ですが。

グローバルトレンド

「人員がいなくて脆弱性監視のプロセスを回せない」というのは、実は世界中の多くの中堅・中小組み込みメーカーが直面している共通の問題です。これを解決するために、Zepher のみならず海外の主要OSコミュニティは進化を続けています。
今後の組み込み業界（特に海外市場を相手にする企業やエンジニア）のトレンドは、「脆弱性監視やSBOMを『人間が頑張って回す』のを諦め、OSのエコシステムやツールチェーンに『完全に自動化（アウトソース）させる』方向」へ一気に進んでいます。つまり、人間が回せないなら「OSとツール」に丸投げするという方向性です。

つまり、「自動化」がキーワードなのですが、その言葉自体、企業の上層部と、モダンな開発手法を目指す現場との間では、大きく乖離している状況です。

上の人たちが考えている「自動化」とは

往々にして「Excelのボタンを1回押したら、人間がやっていた作業がパッと終わるマクロ」のような極めて局所的で単純なイメージです。
CRA（欧州サイバーレジリエンス法）が求めるような、サプライチェーン全体を巻き込んだ「継続的な脆弱性監視の自動化」や、それに伴う開発プロセスの根本的な変革（CI/CDの構築など）とは、スケールも思想も完全にかけ離れています。

なぜ上層部と現場でこれほどまでの致命的なギャップが生まれるのか、その構造的な原因を整理してみます。

「自動化」を理解できない3つの理由

• 「1回作れば、あとはタダで動く」と思っている（運用の視点がない）
  上層部は自動化システムを「物理的な設備（一度買えばしばらく使える機械）」と同じように捉えがちです。しかし、脆弱性監視の自動化は、日々更新されるCVE（脆弱性データベース）や、OSのアップデートに追従し続ける「生き物」です。ツールの保守や、アラートが出た際の仕分けといった「運用コスト」の存在を理解していません。
• IT・ソフトウェアのモダンな開発文化（DevOps）を知らない
  多くの日本の組み込みメーカーの上層部は、10〜20年前の「一度書き込んだら不具合がない限り触らない」時代の成功体験で止まっています。「GitHubにコードをプッシュしたら、クラウド上で自動的にビルドと脆弱性スキャンが走り、SBOMが生成される」というモダンなCI/CDパイプラインの概念自体が、彼らの頭の中の地図に存在しません。
• 「規定（ペーパー）」さえ通れば目的達成だと思っている
  上層部の最大の関心事は「認証をパスして、製品を出荷すること」です。彼らにとって、自動化とは「現場を楽にするため」のものではなく、「監査官に『我が社は自動化ツールを導入してプロセスを回しています』と言い訳するための材料」に過ぎないケースが多々あります。

それは「形だけのDX」の極地であり、エンジニアが最も疲弊する「道具は21世紀、プロセスは20世紀」の歪んだ状態です。

CRAの認証を取るため、遅ればせながら「弊社」でもホスティングシステムの導入に踏み切りました。
しかし、GitLabという世界屈指の強力な「自動化・コラボレーションツール」を導入しながら、やっていることは手動での静的解析ツールの実行、結果のExcelへの転記、対面レビュー、ハンコ（承認）待ち……。

これは完全に「ツールに使われている」状態で、何のために導入したのか分からない状況です。

さらに「インターネット隔離環境（オンプレミス / エアギャップ環境）」という制約が、海外のモダンな恩恵（最新プラグインやSaaS連携）を受けにくくさせ、国内独自の「泥臭いウォーターフォールへの固執」に拍車をかけています。なぜこんな悲劇が起きるのか。

GitLabを入れても相変わらずのExcelウォーターフォール

偉い人の頭の中が以下のように凝り固まっているように思えます。

• 「GitLab = 高性能なファイル置き場（ただのSVN/Gitの代わり）」という誤解
  GitLabの本質が、マージリクエスト（MR）を中心とした非同期コミュニケーションや、CI/CDによるプロセスの自動化・省人化にあることを理解していないのか。「人間の目とExcelによるチェック」しか信用していない。
  「静的解析ツールがOKと言っている」ことよりも、「静的解析ツールの結果と人間の書いた「問題なし」というコメントが入力されたExcelファイルと、それが対面レビューで承認されたというエビデンス、その書類に人間の印鑑があること」を重視。
  これは、責任をツールではなく「承認した人間」に押し付けたいという、古い組織の自己防衛本能です。
• V字モデルの「フェーズ（成果物）」の呪縛
  ウォーターフォール開発では「〇〇の書類が揃ったから次のフェーズへ進む」という管理をします。そのため、GitLabという素早いイテレーション（反復）が得意なツールを入れても、結局「フェーズの境界線」でExcelやWordの書類を大量生産させられることになります。

私が職を辞してから、上の方の認識もアップデートされ、この辺りの事情もかなり変わっているはず……ということを信じ、一旦筆を置きたいと思います。
愚痴に付き合っていただき、ありがとうございました。