2026.08.22 インフラ・クラウド

Azure RTOSとは？Eclipse ThreadX移管後の入手先・ライセンス・Azure IoT連携の現状を実装者向けに解説

Azure RTOSは、Microsoftが2019年にExpress Logicを買収して得たRTOSカーネルThreadXを中核に、TCP/IPスタックやファイルシステム、USB、GUIを束ねた組み込み向けソフトウェア群の呼び名です。この名前で検索して出る情報の多くは、2023年11月にEclipse Foundationへ移管される前の姿を写しています。この記事では、名称と入手先がどこまで移ったのか、MIT化で消えた対象ハードウェア制限とは何だったのか、6つの部品が2026年6月の版でどう揃ったのかを実測で示し、Azure IoT連携ミドルウェアが削除へ向かう事実と代替経路まで扱います。

まとめ｜Azure RTOSの現在地と移管後に採用可否を分ける3つの確認点

結論から言えば、Azure RTOSという製品はもう存在しません。カーネルもミドルウェアもEclipse ThreadXの名でEclipse Foundationの下に置かれ、MITライセンスのままGitHubで配布されています。変わったのは保守の担い手です。

確認すべき点は3つ。1つ目は入手先で、Microsoft Learnの旧ドキュメントURLはGitHubへ転送され、その転送先もすでにアーカイブ済みです。2つ目はライセンス。2024年2月にLICENSED-HARDWARE.txtが削除され、特定ベンダのマイコン上でのみ無償という制限が消えました。対象外だったSoCでもロイヤリティなしで出荷できます。

3つ目がAzure IoT連携。NetX Duoに同梱されるアドオンは、Microsoftが離れた2024年2月のv6.4.1以降ほぼ手が入っておらず、2026年8月に削除予定と明記されました。Azure IoT Hubへつなぐ前提でこの製品を選ぶ判断は成立しません。逆に、Azure連携を要件から外して認証済みカーネルとして評価するなら候補に残ります。

Azure RTOSの定義とEclipse ThreadX移管の経緯・名称が併存する理由

製品の履歴を押さえないと、検索で出る情報の賞味期限が判定できません。買収から寄贈までを日付とともに整理します。

Express Logic買収からEclipse財団への貢献に至る2019年以降の時系列

ThreadXはBill Lamie氏が1997年にExpress Logicで開発したRTOSです。Microsoftは2019年に同社を買収し、周辺ミドルウェアごとAzureブランドへ組み込んで「Azure RTOS」として再パッケージしました。登録済みの対象マイコン上ならライセンス費なしで使える形態が採られ、STやルネサスのSDKへ同梱される流れができます。

転機は2023年11月。MicrosoftはAzure RTOSの技術一式とThreadX商標をEclipse Foundationへ提供し、プロジェクトはベンダ中立のガバナンス下へ移りました。ソースはMITで全面公開され、2024年2月のv6.4.1がMicrosoft関与の最後のリリースです。

Azure RTOSとEclipse ThreadXの名称が実務で併存し続ける理由

正式名称はEclipse ThreadXですが、現場では旧名が消えません。理由は配布経路にあります。STMicroelectronicsのSTM32Cube拡張パッケージは「X-CUBE-AZRTOS」という名前のまま更新が続いており、ソース側のシンボル名もtx_thread_createやnx_azure_iot_hub_client系のまま。名前では新旧を判別できないため、版番号とリポジトリのURLで確認してください。

MITライセンス化で対象ハードウェア制限が消えた2024年2月の変更

Azure RTOS時代の無償利用には条件がありました。リポジトリ直下のLICENSED-HARDWARE.txtに列挙されたマイコンやMPU上で動かす場合に限ってロイヤリティなしで使える、という建て付けです。対象表は随時更新され、2023年3月にはルネサスのMPU追加も反映されています。

この制限は移管で撤廃されました。eclipse-threadx/threadxのプルリクエスト#355「update license.txt and delete licensed-hardware.txt」が2024年2月7日にクローズされ、対象一覧そのものが消えています。2026年8月時点で両リポジトリの直下にあるライセンス関連ファイルはLICENSE.txt1本のみ、中身は標準的なMIT Licenseです。

ThreadXとNetX Duoなど6コンポーネントの構成と版番号の読み方

Eclipse ThreadXはカーネル単体ではなく、独立したリポジトリに分かれた6部品の集合です。どこまで採るかで見積りが変わります。

カーネル本体ThreadXのpicokernel構造とプリエンプション閾値

ThreadXはpicokernelと呼ばれる構造を採り、機能を階層化せずカーネル本体へ直接埋め込みます。呼び出しの段数が浅いぶん、割り込み応答とコンテキストスイッチのオーバーヘッドを削れる設計です。ROM数KBから十数KB規模で動く点は他のRTOSカーネルと同水準。

独自機能として知られるのがプリエンプション閾値でしょう。タスクごとに「この優先度より上のタスクにしか割り込まれない」上限を設定でき、優先度の細かい区分を保ったまま不要なコンテキストスイッチを抑えられます。優先度逆転やWCET見積りはRTOSとは？リアルタイムOSの仕組み・主要製品の比較と採用判断を実装者目線で解説で扱っているため、ここでは製品固有の機構だけを挙げます。

NetX Duo・FileX・LevelX・USBXが担う通信とストレージの分担

周辺スタックは役割ごとに分かれています。NetX DuoはIPv4とIPv6の両対応TCP/IPスタックとTLS、MQTTなどを担い、FileXがFATファイルシステム、LevelXがNANDとNORフラッシュの摩耗平準化、USBXがホストとデバイスの両側を受け持ちます。GUIXは組み込み向けGUIフレームワークで、画面設計用のGUIX Studioが付属。カーネルだけならthreadxリポジトリ単体で完結し、通信が要る機器はThreadXとNetX Duoの2本が最小構成です。

6コンポーネントを四半期ごとに揃える版番号方式と差分の見分け方

版番号は6.5.1.202602のようにセマンティックバージョンと年月を連結した形式です。移管直後は版がばらつきましたが、v6.4.5の時点で最も進んでいたNetX Duoの番号へ揃えられました。リリースノートには、Eclipse Foundationのセキュリティチームの助言を受け、変更が無い四半期でも全部品の新版を公開する方針と、版番号のみの更新ならその旨を明記する方針が示されています。

コンポーネント	役割	現行版	公開日
ThreadX	RTOSカーネル	6.5.1.202602a	2026年6月8日
NetX Duo	TCP/IP・TLS・MQTT	6.5.1.202602	2026年6月8日
FileX	FATファイルシステム	6.5.1.202602	2026年6月8日
LevelX	フラッシュ摩耗平準化	6.5.1.202602	2026年6月8日
USBX	USBホストとデバイス	6.5.1.202602	2026年6月8日
GUIX	組み込みGUI	6.5.1.202602	2026年6月8日

ThreadXだけ末尾にaが付くのは、同日公開のv6.5.1.202602にCortex-M向けのコンパイル退行が見つかり修正版が出たためです。直前のv6.5.0.202601（2026年3月6日）ではRISC-V32ポートとClang対応、v6.5.1.202602ではRISC-Vのベクトル拡張とWin64ポートが加わりました。2026年1月9日のv6.4.5.202504はPOSIX互換層のCVE-2026-0648に対処しており、この層を使う構成なら前の版で止めない理由になります。

入手先がGitHubへ移った現状とベンダ配布パッケージの確認手順

移管の影響が最も分かりにくいのがドキュメントです。旧URLは生きて見えて、実際は2段階で転送されます。

Microsoft Learnの旧URLがGitHubへ転送され文書が移った経路

検索上位に残るlearn.microsoft.comのAzure RTOS ThreadX解説ページは、2026年8月時点でgithub.com/eclipse-threadx/rtos-docsへ301転送されます。ところが転送先はすでにアーカイブ済みで、説明文は「Use rtos-docs-asciidoc instead」、最終更新は2026年2月6日で止まったまま。現行の文書はAsciiDoc形式のrtos-docs-asciidocへ移り、2026年8月9日に更新されました。製品ページ側のazure.microsoft.comのRTOS URLも寄贈告知記事へ転送されます。手順書が旧URLを指したままなら、2段階分の付け替えが要ります。

STのX-CUBE-AZRTOSなどベンダ配布が旧名称のまま続く実態

半導体ベンダの配布物は、更新状況がシリーズごとに違います。STの例では、x-cube-azrtos-h7rsが2026年7月1日、x-cube-azrtos-h7が2026年5月21日に更新される一方、x-cube-azrtos-l5・wb・g4は2023年で止まったまま。同社は別途stm32-mw-threadxというミドルウェア単体のリポジトリを持ち、2026年6月10日に更新されました。ベンダSDKの版は上流より遅れ、カーネル本体はMITでも同梱ドライバに別条件が付く場合があります。CVE対応を上流で追うのかベンダSDKの更新を待つのかを設計段階で決め、取得元と版番号は構成管理へ記録してください。両方を混ぜるとビルド構成が壊れます。

Azure IoT連携ミドルウェアの削除方針と接続を続ける場合の代替経路

製品名に残る「Azure」の実体は、NetX Duoのアドオンとして提供されるAzure IoT接続ミドルウェア。ここが2026年に大きく動きました。

NetX DuoのAzure IoTアドオンが2024年2月以降未保守になった経緯

このアドオンはAzure IoT HubへMQTT経由で接続し、デバイストゥクラウドのメッセージ送信、Device Twins、ダイレクトメソッド、IoT Plug and Playのテレメトリとプロパティ、SASトークンとX.509証明書による認証を扱います。Device Update for IoT HubによるOTA更新にも対応済みでした。

問題は保守体制にあります。Eclipse Foundationのfdesbiens氏は2026年7月27日、netxduoのissue #406で「Microsoftは2024年2月のv6.4.1リリース以降このプロジェクトに関与していない」と明かし、「我々のチームは検証用のAzure IoTにアクセスできず、Azure IoT SDKを保守することはほぼ不可能だ」と述べました。テスト環境が無いのだから直せない、という率直な理由づけです。

2026年8月にAzure IoT削除方針が明示された議論と再検討の条件

issue #406そのものは実害のある不具合報告でした。Azure IoT Provisioning ClientとIoT Hub Clientがnxd_mqtt_client_websocket_set()を現行のシグネチャと合わない引数リストで呼び出し、v6.5.1.202602_relではWebSocket接続が失敗します。最新版でAzure IoTのWebSocket経路は動きません。

このissueは2026年8月19日、「非推奨化に異議があるなら再オープンしてほしい。このコードを残すなら、検証用のAzureへアクセスできる新しいメンテナが必要になる」というコメントとともにクローズされました。同日のissue #424には「Azure IoTクライアントは本リポジトリからの削除が予定されている」と明記され、CIジョブも削除されています。撤回の条件は示されていますが、名乗り出たメンテナは確認できません。

Azure IoT Hubへ接続し続ける場合に取り得る3つの実装経路

接続要件が消えない案件では、経路は3つ。優先順位は明確です。

Microsoftが保守を続けるAzure SDK for Embedded Cを直接使い、NetX DuoのMQTTとTLSの上へ自前で載せる。アドオン自体がこのSDKの上に建っており、置き換えの筋は読める
削除前の版のアドオンを社内でフォークし、自社の責任で保守する。上流が直さない欠陥を自分で塞ぐ覚悟が要る
クラウド接続層をRTOS側から切り離し、通信モジュールやゲートウェイ側へ寄せる。制御はThreadX、接続は別プロセッサという構成

3番目は工数が増えて見えますが、認証やプロトコルの更新をRTOS側の再検証から切り離せるため、製品寿命が10年を超える機器では安く付きます。制御層と上位層を分ける考え方はエッジAIとは？クラウドAIとの違い・仕組み・実装の判断基準を解説で整理した2チップ構成と同じです。

機能安全認証とサポート供給体制の現状から見た商用案件での採用条件

Azure連携を外しても、認証済みカーネルという価値は残ります。移管後も生きているかを確認します。

SGS-TÜV Saarが認証した4規格と安全成果物の入手に必要な条件

Eclipse ThreadXは、SGS-TÜV Saarによる4規格の認証を保持しています。IEC 61508-3:2010、IEC 62304:2015、ISO 26262-8:2018、EN 50128:2011の4本で、産業機器・医療機器・車載・鉄道をそれぞれ受け持ちます。オープンソース化と引き換えに認証を手放したわけではありません。

ただしコードがMITでも、認証を主張するための書類は別扱いです。安全マニュアルを含む安全成果物パッケージは、2024年10月8日に発足したThreadX Allianceの購読者向けに提供されます。同アライアンスにはSTMicroelectronicsやTexas Instrumentsなど12組織が参加し、担うのは資金と運営、安全成果物の提供、セキュリティ対応の継続。個別案件の技術支援は範囲外で、書類の入手と実装支援は別契約です。この構造はQNXとは？マイクロカーネル型RTOSの構造とSDP 8.0・安全認証から採用判断まで実装者向けに解説で扱った商用RTOSと同型です。

PX5 RTOSとRTOSXという原作者側の選択肢と移行コストの見方

ThreadXの原作者であるBill Lamie氏は、別会社PX5でPX5 RTOSを2023年1月に公開しました。POSIXのpthreads APIをネイティブ実装した点が特徴で、ThreadX固有APIからの乗り換え先というよりPOSIX資産を持つチーム向けの選択肢です。

ThreadX利用者にとって現実味があるのは、2023年11月21日に設立が発表された子会社RTOSXのほうでしょう。SLA付きのチケットサポート、CVE監視、特定版に対する最長10年の延長長期サポートを提供し、チームはThreadXやFileX・GUIX・NetX・USBXの原作者が中心です。上流の四半期リリースを追い切れない案件では、この経路が移行より安く済みます。移行コストを見積もる前に、サポート契約で足りる範囲かを先に潰してください。

Azure RTOSを新規採用してよい条件と見送るべき3つの状況の線引き

ここまでの事実を採否の判断へ落とします。玉虫色にはしません。

既存ThreadX資産を持つ製品が移管後も継続採用してよい2条件

すでにThreadXで動く製品を持つなら、移管を理由に乗り換える必要はありません。継続してよい条件は2つ。第1に、Azure IoT連携を使っていないか、切り離せる構成であること。第2に、v6.4.1以降の版へ追随できる体制があること。CVE-2026-0648への対処が入ったv6.4.5.202504より前で止めたまま出荷する運用は避けてください。MIT化でハードウェア制限が消えたぶん、次の機種展開では自由度が上がります。

新規案件でAzure RTOSを候補から外してよい3つの具体条件

逆に、次の3条件のいずれかに当たる新規案件では、候補から外して構いません。第1に、Azure IoT HubやIoT Centralへの接続が要件に入っている場合。削除予定のアドオンに依存する設計は、量産後に自社保守へ転嫁されます。第2に、無線スタックやセンサドライバの同梱が前提の場合。ZephyrOSとは何か？概要と基本的な機能を解説で扱ったZephyrのほうがエコシステムで勝ります。

第3が、社内にThreadXの経験者がおらず、開発期間が半年を切っている場合です。ドキュメントの所在が2回移り、日本語の解説記事の多くが移管前の記述で止まっている現状では、情報収集の工数が読めません。この条件ではFreeRTOSのほうが動作確認までの距離が短い。3分類の境界は組み込みOSとは？3分類の境界とITRON系の位置づけ・選定判断を実装者向けに解説で整理しました。

移行や新規採用を決めた案件で設計着手前に前倒しすべき確認工程

採用または継続を決めたら、コードを書き始める前に片付ける工程が3つあります。ライセンス表示義務の対象ファイルを洗い出す。安全成果物が要る案件ならThreadX Allianceへの購読可否を調達部門と詰める。そしてAzure IoT依存の有無を全モジュールで棚卸しすることです。

3番目を後回しにする案件が最も危険です。アドオンの削除は上流の都合で進み、開発日程とは無関係に来ます。既存機器の移行判断や、Azure連携を含むIoT機器の設計を内製するかで迷っているなら、AI・IoT開発の受託サービスで構成設計から検証まで対応しています。締切要件が固まる前でも相談してください。

よくある質問

Azure RTOSの検討で繰り返し聞かれる質問を5つ挙げます。

Azure RTOSは今も無償で商用製品に組み込めますか？

組み込めます。2024年2月にMITライセンスへ全面移行し、対象ハードウェアを列挙したLICENSED-HARDWARE.txtも同時に削除されました。以前は登録済みのマイコン上でのみ無償という条件でしたが、その制限は残っていません。義務として残るのは著作権表示とライセンス全文の同梱です。ただし機能安全の認証書類は別扱いで、安全成果物パッケージはThreadX Alliance購読者向けです。

Azure RTOSとEclipse ThreadXは別物ですか？

同じものです。Microsoftが2023年11月にEclipse Foundationへ技術とThreadX商標を提供し、名称がEclipse ThreadXへ変わりました。コードベースは連続しており、APIのシンボル名も従来のまま。混乱の元は配布側で、STの拡張パッケージは現在もX-CUBE-AZRTOSという名前で更新が続いています。新旧の判別は名称ではなく版番号で行い、v6.4.1がMicrosoft関与の最後の版だと押さえてください。

Azure IoT Hubに接続する既存製品はどうすればよいですか？

NetX DuoのAzure IoTアドオンは2024年2月以降ほぼ未保守で、2026年8月19日にリポジトリからの削除が予定と明記されました。最新のv6.5.1.202602ではWebSocket接続が失敗する不具合も残っています。取り得る経路は、Azure SDK for Embedded Cを直接使う、削除前の版をフォークして保守する、接続層をゲートウェイ側へ寄せる、の3つ。製品寿命が長い機器では3番目が有利です。

FreeRTOSやZephyrではなくThreadXを選ぶ理由は残っていますか？

残ります。判断軸は認証です。ThreadXはSGS-TÜV Saarによる4規格の認証を保持したままオープンソース化されており、産業機器・医療機器・車載・鉄道を1つのカーネルで横断できます。加えて周辺スタックが四半期ごとに版を揃えて出るため、一式を同じ供給元から取りたい構成に向く製品です。無線やドライバの品揃えを重視するならZephyr、小規模ならFreeRTOSという住み分けになります。

機能安全の認証書類はどこから入手できますか？

ThreadX Allianceの購読を通じて入手します。2024年10月8日に発足したEclipse Foundation主催の枠組みで、安全マニュアルを含む安全成果物パッケージを購読者向けに提供しています。個別案件の技術支援は範囲外のため、実装支援が要るならメンバー企業の商用サポートやRTOSXの延長長期サポートを別途検討してください。