2026.07.29 インフラ

QNXとは？マイクロカーネル型RTOSの構造とSDP 8.0・安全認証から採用判断まで実装者向けに解説

車載や産業機器の案件でQNXの名前が出ると、実装側がまず知りたいのは「Linuxと何が違って、なぜ有償のOSを選ぶのか」でしょう。用語辞典は「カナダ製のマイクロカーネル型RTOS」で説明を止めてしまいます。本記事ではQNXの中身をプロセスとAPIの粒度で分解し、採否の判断までを2026年7月時点の一次情報で整理しました。

まとめ：QNXの正体と採用判断の結論

QNXは、カナダで生まれたマイクロカーネル型の商用リアルタイムOSです。ファイルシステムもネットワークスタックもデバイスドライバもカーネルの外側にあり、独立したプロセスとして動きます。ドライバが落ちてもカーネルは巻き込まれません。この構造が価格差の理由でもあります。RTOSという枠組み自体の定義や、FreeRTOS・Zephyr・TOPPERSまで含めた選定軸はRTOSとは？リアルタイムOSの仕組みと採用判断で整理しています。

現行は QNX SDP 8.0（GA 2024年3月21日）で、8.0.2以降はARMv9にも対応しました。旧世代の SDP 7.1 は2020年7月のリリースで、販売終了が2028年7月31日、サポート終了が2030年7月31日という見込みです。新規開発なら8.0系を選んでください。

採用理由の中心は安全認証にあります。QNX OS for Safety 8.0 は TÜV Rheinland により ISO 26262 ASIL D、IEC 61508 SIL 3、IEC 62304 Class C、ISO/SAE 21434 の認証を受けており、OSそのものを認証し直す作業が要りません。認証が要件に無いならLinuxのほうが人材もライブラリも揃い、工数は少なく済みます。試すだけなら費用はかからず、QNX Everywhere の無償ライセンスで手元のRaspberry Pi 4に載せられます。

QNXとは何か｜マイクロカーネル構造で耐障害性を確保する商用RTOS

マイクロカーネルとは何か｜OSの機能をユーザー空間のプロセスへ出す

Linuxのカーネルには、プロセス管理もメモリ管理もファイルシステムもネットワークスタックもデバイスドライバも入っています。ドライバのバグでカーネルパニックが起きるのは、それらが同じアドレス空間で動いているからです。

QNXのカーネル（procnto）が担うのは、スレッドのスケジューリング、プロセス間通信、割り込みの取り次ぎ、タイマ、メモリ管理まわりに絞られます。ファイルシステムもTCP/IPスタックもUSBドライバも、カーネルの外でユーザー空間のプロセスとして動く設計です。

差は障害時の挙動に出ます。ネットワークドライバが異常終了しても、止まるのはそのプロセスだけ。監視プロセスが再起動すればシステム全体は動き続けられます。プロセス間の受け渡しで増えるオーバーヘッドを詰めてきたのがQNXの歴史です。

45年続く開発の歴史と、2億7,500万台の車両に載るという実績

QNXの開発は1980年代初頭に始まり、公式資料では45年以上にわたり同じマイクロカーネル設計を磨いてきたと説明されています。途中でBlackBerryの傘下に入り、現在はQNXブランドの製品群として展開中です。公式サイトの2026年7月時点の公表値では、搭載車両は2億7,500万台以上。対象業界として自動車、医療機器、産業用制御、ロボット工学、商用車、鉄道、航空宇宙および防衛が挙がっています。

QNXが選ばれる領域｜車載・医療機器・産業制御に共通する要件

これらの領域には3つの共通点があります。第一に、応答時間の上限が仕様として決まっていること。エアバッグの展開判断が「たいてい速い」では通りません。第二に、機能安全規格の認証が調達条件になっていること。第三に、製品寿命が10年から20年と長く、OSベンダーの保守期間がそのまま製品の寿命を縛ることです。汎用OSでこの3つを満たすなら、認証作業とパッチ供給体制を自前で抱える覚悟が要ります。

QNX OS 8.0の中身｜カーネル・IPC・スケジューリングの実装解像度

同期メッセージパッシング｜MsgSendとMsgReplyでプロセスを繋ぐ

QNXでプロセス同士をつなぐ基本手段は、同期メッセージパッシングです。クライアントが MsgSend() を呼ぶとブロックし、サーバー側の MsgReceive() が受け取って処理し、MsgReply() を返した時点でクライアントが動き出します。

ここで効くのが優先度の継承です。低優先度のクライアントからメッセージを受け取ったサーバースレッドは、送信側の優先度を引き継いで動きます。これがないと、高優先度スレッドが低優先度スレッドの完了を待つ優先度逆転が起き、確定的な応答時間という前提が崩れるでしょう。ファイルを開く、読む、デバイスへ書くという操作はすべてメッセージ送受信です。

リソースマネージャ｜デバイスドライバをプロセスとして差し替える

QNXのデバイスドライバは、リソースマネージャと呼ばれる普通のプロセスです。起動するとパス名空間に自分の担当パスを登録し、そこへの open や read や write をメッセージとして受け取ります。ネットワークなら io-pkt、ブロックデバイスなら devb- で始まるプロセス群、シリアルなら devc- 系。pidin でプロセス一覧を見れば、OSの機能がそのままプロセスとして並ぶ様子が確認できます。

運用上の意味は大きいところです。ドライバの入れ替えにカーネルの再ビルドが要りません。開発中のドライバをデバッガでステップ実行する手順も、通常のアプリケーションと変わりません。

スケジューラの選択肢｜FIFO・ラウンドロビン・スポラディックの使い分け

QNX OS 8.0のスケジューラは固定優先度のプリエンプティブ方式で、同一優先度内の扱いを3つのポリシーから選べます。

ポリシー 挙動 向く用途
FIFO 自ら手放すまで走り続ける 短時間の割り込み後処理
ラウンドロビン 時間切れで同優先度へ交代 同格タスクの並走
スポラディック 予算内は高優先度で動く 散発的な負荷の抑制

スポラディックは、通信の受信処理のように「普段は軽いが、たまに大量に来る」タスクの暴走を抑えます。実行予算を使い切ると優先度が下がり、補充されるまで他のタスクが動ける仕組みです。8.0ではスレッドを動かすコアをコア単位・クラスタ単位で指定でき、タイマもティックレス方式へ変わりました。

アダプティブパーティショニング｜CPU予算を割り当てて枯渇を防ぐ

優先度だけで組むと、高優先度タスクの暴走で低優先度側が動けなくなります。アダプティブパーティショニングは、プロセス群をパーティションにまとめてCPU時間を百分率で配分する仕組みです。

肝は「余ったら貸す」という挙動にあります。制御系に70パーセント、UI系に30パーセントと決めておき、制御系が予算を使い切らなければUI系はその余りまで使えます。負荷が上がれば配分どおりに引き戻される設計です。認証が要る制御ロジックと認証が不要な画面表示が同じSoCに載る構成では、この配分表が「後者の負荷が前者の締切を侵さない」ことの説明材料になります。

8.0で変わった点｜細粒度ロックと割り込みサービススレッドへの移行

QNX OS 8.0は、7.1系からカーネル内部を作り替えています。実装者に効く変更は3点です。

1点目はロックの粒度。カーネル全体を覆う単一ロックから、プロセス内で閉じた同期オブジェクトが内部ロックを共有しない設計へ移りました。公式資料では1〜64コアでのニアリニアなスケールと、およそ10〜20マイクロ秒の割り込みレイテンシが示されています。

2点目は割り込み処理の形です。割り込みハンドラ（ISR）中心から、割り込みサービススレッド（IST）中心へ移行しました。割り込み処理を通常のスレッドとして書けるため、ハンドラ内で使えるAPIの制約に悩む場面が減ります。

3点目は製品名の整理。従来「QNX Neutrino RTOS」と呼ばれたOS本体が、8.0では「QNX OS」という名称になりました。古い文献にNeutrinoが残っていても指すものは同じです。

QNX SDP 8.0の開発環境｜対応アーキテクチャとツールチェーン

対応アーキテクチャとボード｜x86_64とAArch64のどちらを選ぶか

SDP 8.0が対象とするのは x86_64 と AArch64 の2系統です。AArch64側は ARMv8.0 または v8.2 の命令セットが条件で、ARMv9への対応は8.0.2以降。32bit ARM は対象外です。

公式に検証済みのボードは、Raspberry Pi 4、NXP i.MX8 系、TI Jacinto 7 系、Intel Celeron から Core i9 までのx86機です。量産で使うSoCが一覧に無いなら、BSPの有無を最初に確認してください。BSPが無ければ移植から始めることになり、見積の桁が変わります。

ツールチェーンの版｜GCC 12.2とPython 3.11で固定される環境

SDP 8.0に同梱されるツールチェーンは版が決まっています。GCC 12.2（binutils 2.41.0）、GDB 11.2、Python 3.11、C++17とC++20に対応する LLVM libc++ 16。IDEは Eclipse ベースの QNX Momentics 8.0 で、Visual Studio Code 向けの QNX Toolkit も用意されています。新しいGCCを前提にしたサードパーティライブラリをそのまま持ち込める保証はないため、依存ライブラリの要求コンパイラ版は着手前に洗い出してください。

QNX Hypervisorという選択｜1台にQNXとLinuxを同居させる

1つのSoCに、認証が要る制御系と、認証が不要で機能が多い情報系を同居させたい要件はよく出てきます。QNX Hypervisor はそのための製品で、QNX OS のゲストとLinuxのゲストを同じハードウェア上で分離して動かします。車載でいえばメーターの表示は確定的に、ナビや音楽アプリはAndroidやLinuxの資産で、という構成です。

仮想化の型と選定の考え方そのものはハイパーバイザーとは？Type1・Type2の違いから仮想化基盤の選定までで扱っているため、本記事はQNX側の位置づけに絞ります。

QNX OS for Safetyと安全認証｜ISO 26262 ASIL Dの取得範囲

QNX OS for Safety 8.0が持つ認証｜ASIL DとSIL 3の範囲

QNX OS for Safety 8.0（QOS 8.0）は、TÜV Rheinland による認証を受けた版です。2026年7月時点で公表されている認証は次のとおり。

規格 取得レベル 主な対象領域
ISO 26262 ASIL D 自動車の機能安全
IEC 61508 SIL 3 産業機器の機能安全
IEC 62304 Class C 医療機器ソフトウェア
ISO/SAE 21434 準拠 車両のサイバーセキュリティ

関連製品の QNX Filesystem for Safety は ISO 26262 ASIL B。C言語とC++のツールチェーンは、ISO 26262 の TCL3、IEC 61508 の T3 として分類済みです。

OSを認証済みにする意味｜自社アプリの認証だけで済ませる考え方

認証済みOSを買う価値は、認証作業の範囲が縮むところにあります。未認証のOSで ASIL D のシステムを組むなら、OSの設計文書、テスト証跡、故障モード解析、さらにビルドに使ったコンパイラの適格性確認までを自分たちで用意し、審査に出さなければなりません。

QOSを土台にすれば、認証の対象は自社が書いたアプリケーション層に絞れます。無償のRTOSと有償のQNXを金額だけで比べても答えが出ないのは、比べるべきがライセンス費と「認証を自前で通す工数と期間」の差だからです。

QNX OSとQNX OS for Safetyのバイナリ互換という設計

実装の進め方として押さえたいのが、QNX OS 8.0 と QOS 8.0 がバイナリ互換だという点です。開発中は通常版のSDPで作り、認証が必要な最終段階でQOSへ載せ替えるとき、再コンパイルなしで移行できます。プロトタイプ段階から高価な安全認証版を調達しなくてよい段取りになります。

QNXとLinux・FreeRTOS・Zephyrの違い｜RTOS選定で効く判断材料

QNXとLinuxの違い｜PREEMPT_RTでは埋まらない確定性の差

LinuxにもPREEMPT_RTパッチがあり、応答時間はかなり詰められます。それでも両者が同じにならない理由は3つ。1つ目は構造で、Linuxはモノリシックカーネルのためドライバの不具合がカーネル全体を巻き込みます。2つ目は認証で、ASIL DやSIL 3を持つLinuxディストリビューションは選択肢が限られます。3つ目は最悪応答時間の保証です。

逆にLinux側が強いのは、開発者の確保しやすさ、パッケージの豊富さ、クラウド連携の資産。認証が要件に無く、応答時間の要求が数ミリ秒程度に収まるならLinuxのほうが総コストは下がります。Linux側の事情はLinuxとは？仕組み・ディストリビューション・サーバー用途を実装目線で解説にまとめました。

FreeRTOS・Zephyrとの違い｜MMU保護とPOSIXの有無で分かれる

FreeRTOSやZephyrは、マイコン上で動く軽量なRTOSです。フットプリントは数十キロバイト規模で、MMUを持たないマイコンでも動きます。QNXはMMUを前提にプロセスごとのメモリ空間を分離するため、あるプロセスのポインタ暴走が他を壊しません。代わりに数メガバイト以上のRAMとMMU付きのSoCが要ります。

選び分けの軸は単純です。センサーノードのようにRAMが数百キロバイトの環境ならFreeRTOSやZephyr、アプリケーションプロセッサ級のSoCでプロセス分離とファイルシステムとネットワークが要るならQNX。Zephyr側の構成はZephyrOSとは何か？概要と基本的な機能を解説で扱っています。

VxWorks・ITRONと並べたときのQNXの位置づけと商用条件

商用RTOSの競合はWind RiverのVxWorksで、こちらもASIL DやDO-178Cの認証実績を持ちます。国内に長くあるITRON系（μITRON、TOPPERSなど）は、軽量でロイヤリティ負担が小さい代わりに、POSIX資産やプロセス分離ではQNXと土俵が異なります。実務上の分岐点は、案件の調達要件です。海外OEMのティア1案件ならQNXかVxWorksの指定が多く、国内の産業機器ならITRON系やLinuxが既定という現場も残っています。

POSIX準拠が効く場面｜UNIX系の資産をそのまま持ち込めるか

QNXはPOSIX準拠を掲げており、PSE52（Realtime Controller、IEEE 1003.13-2003）の認証実績があります。pthread、ソケット、標準ファイルAPIといったUNIX系のインターフェースが揃うため、LinuxやBSDで書いたデーモンやライブラリを、APIの書き換えなしに近い形で持ち込める見込みが立ちます。ただし準拠はリアルタイムコントローラ向けのプロファイルであり、汎用UNIXのすべてが揃うわけではありません。UNIX系OSの構造そのものはFreeBSDとは？Linuxとの違い・ZFS/jail/bhyveの実装から採用判断までを参照してください。

QNXの入手と検証環境の作り方｜QNX Everywhereで無償から始める

QNX Everywhereの無償ライセンス｜非商用に限るという線引き

QNXは2025年のCESでQNX Everywhereという取り組みを始めました。myQNXアカウントを作れば、非商用に限りQNX SDP 8.0を無償で入手できます。OS本体、ツールチェーン、デバッグユーティリティまで含む構成です。2026年にはQNX Hypervisor 8.0も無償対象へ加わり、発行ライセンスは12,000件を超えたとされています。

販売を目的としないプロジェクトが対象で、製品に載せて出荷するなら商用ライセンスが要ります。「社内利用だが業務に使う」といった境界事例は、契約条項を読んで判断してください。

Raspberry Pi 4で試す手順｜イメージ書き込みから起動確認まで

最短経路はRaspberry Pi 4で、流れは4段階です。

段階 やること
1 myQNXで無償ライセンス取得
2 SDPとRaspberry Pi用BSP導入
3 SDカードへイメージを書き込み
4 シリアル接続で起動を確認

起動したらpidinでプロセス一覧を見てください。ファイルシステムもネットワークスタックも独立したプロセスとして並ぶ様子が、マイクロカーネル構造の最も分かりやすい確認方法です。

商用利用に切り替えるとき｜開発シートとランタイム費用の考え方

商用ライセンスの価格は公開されておらず、案件ごとの見積です。費用の構造は、開発者が使う開発ライセンスと、出荷台数に応じたランタイムライセンスの2本立てが一般的な形になります。

見積を取る前に決めておく項目は4つ。想定出荷台数、対象SoC、安全認証版（QOS）が要るかどうか、サポート期間です。特に台数はランタイム側の単価に直結するため、桁が動くと総額が大きく変わります。国内では販売代理店経由の調達になる場合も多く、窓口の確認も併せて進めてください。

QNXを採用してよい3つの条件と、見送るべき3つの場面の判断軸

採用してよい3条件｜安全認証・確定的な応答・長期保守が要るとき

1つ目は、機能安全規格の認証が調達要件に入っている場合です。ISO 26262 ASIL D、IEC 61508 SIL 3、IEC 62304 Class C のいずれかが仕様書に書かれているなら、認証済みOSを買うほうが速く確実に進みます。

2つ目は、最悪応答時間を数値で保証する必要がある場合。「平均は速い」ではなく「上限は何マイクロ秒」を提示する要件なら、レイテンシの公表値を持つOSが要ります。

3つ目は、製品寿命が10年を超え、保守とセキュリティ修正の供給元を契約で確保したい場合。7.1系が2030年までEOLを設定しているように、商用OSは保守期間が明示されます。

見送るべき3場面｜量産規模・人材確保・エコシステムの制約から

1つ目は、出荷台数が多く単価が厳しい民生機器。台数比例のランタイム費用が効いてくるため、認証要件が無いならLinuxやZephyrのほうが原価は下がります。

2つ目は、開発体制をこれから組む場合です。QNX経験者の母数はLinux技術者より圧倒的に小さく、採用にも教育にも時間がかかります。短納期の案件で人が集まらないリスクは、技術的な優位を打ち消します。

3つ目は、クラウド連携やコンテナ運用が主題のシステム。KubernetesやDockerを前提とする構成では、Linuxのエコシステムに勝てません。エッジ側でAI推論を回す構成なら、まずエッジAIとは？クラウドAIとの違い・仕組み・実装の判断基準で要件を整理してからOS選定へ進むほうが、順序としては自然でしょう。

QNX案件の開発を外部へ委ねるとき見積書で確かめる5つの項目

外部に依頼するなら、見積書で次の5点を確認してください。

確認項目 見るべき点
ライセンス費の所在 開発・ランタイムの負担者
対象SoCのBSP 既存BSPの有無と移植量
認証版の要否 QOS利用と証跡提出の範囲
成果物の範囲 設計書とテスト証跡の有無
保守期間 OS版上げ時の対応条件

特に3番目は金額差が大きい箇所です。「QNXで作ります」という記述だけでは、通常版で作るのか認証版で作るのかが判別できません。認証を通す前提なら、証跡の作成と提出までが作業範囲に入っているかを文面で確かめてください。組込み機器側のソフトウェアとクラウド側のデータ基盤をまとめて相談したい場合はAI/IoTソリューションで受け付けています。

よくある質問

QNXは無料で使えますか？

非商用に限れば無料です。myQNXアカウントを作ればQNX SDP 8.0とQNX Hypervisor 8.0を入手できます。製品に載せて販売するなら商用ライセンスの契約が要ります。

QNXとLinuxはどちらを選べばよいですか？

機能安全規格の認証が調達要件に入っている、最悪応答時間を数値で保証する必要がある、製品寿命が10年を超えて保守供給を契約で確保したい。いずれかに当てはまるならQNXです。当てはまらないならLinuxのほうが総工数は少なく済みます。

QNXの現行バージョンは何ですか？

2026年7月時点の現行は QNX SDP 8.0 で、GAは2024年3月21日です。8.0.2以降でARMv9に対応しました。旧世代の SDP 7.1 は販売終了が2028年7月31日、サポート終了が2030年7月31日という見込みです。

QNXでLinux向けのソフトはそのまま動きますか？

バイナリのまま動かすことはできません。QNXはPOSIX準拠（PSE52）のため、ソースからの移植なら書き換えは少なく済みます。ただしglibc固有のAPIやLinux特有のシステムコールに依存する部分は書き換えが必要です。

QNXの開発にmacOSは使えますか？

使えません。SDP 8.0はmacOSホストのサポートを終了しており、開発ホストはWindowsまたはLinuxになります。CIを回す場合もLinuxホストが前提です。macを使い続けるなら、仮想マシンやリモートのLinux環境を用意する構成が現実的です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る