組込みOS/RTOSの選び方｜7軸で用途とリアルタイム性から導入製品を絞る

組込みOS/RTOSの選び方でつまずく開発現場が多いのは、製品名は知っていても「自社の機器に必要なリアルタイム性のレベル」と「許容できるライセンス・サポート形態」を先に言語化できていないためです。検索すると「RTOSとは」の解説と、個別製品の機能一覧ばかりが目につき、どの軸を上から評価すれば候補が絞れるのかが整理されていません。結果として、無料のOSSで始めて後から機能安全認証に詰まる、逆に商用RTOSを過剰に選んで小型機器のコストが合わなくなる、といった手戻りが起きます。

この記事は組込みOS/RTOSを選ぶうえで外せない7軸（用途とリアルタイム性・対応MCU/アーキ・機能安全認証・商用かOSSか・開発環境とミドルウェア・セキュリティ・ライセンスとコスト）を順に整理し、用途別の出発点、導入の進め方、典型的な失敗パターンとその回避策まで踏み込みます。製品ごとの機能比較は別記事「組込みソフトウェア比較」で扱うため、本記事は選定フレームワークに特化します。RTOSやスケジューリングの基礎をまず押さえたい場合は用語解説の「組込みOSとは」を先に読むと、本記事の各軸が理解しやすくなります。

結論：最初に決めるべきは「リアルタイム性をハードに保証する必要があるか」と「機能安全認証（IEC 61508/ISO 26262など）が要るか」の二点です。この二点でOSSと商用RTOSのどちらの系統に進むかがほぼ決まり、そのうえで対応MCU・開発環境・セキュリティ・コストを順に確認すれば候補は2〜3製品に絞れます。厳密な応答時間と認証が要るならQNX Neutrino・INTEGRITY・VxWorksなどの商用RTOS、コストと導入の軽さを優先するならFreeRTOS・TOPPERS/ASP、国産で日本語サポートを重視するならμC3という分岐が出発点になります。

組込みOS/RTOSの選定は七つの軸を順に評価すると、漏れと後戻りが減ります。用途とリアルタイム性→対応MCU/アーキ→機能安全認証→商用かOSSか→開発環境とミドルウェア→セキュリティ→ライセンスとコストの順で各軸を確認し、候補製品を2〜3に絞り込んでから比較記事に進む流れです。編集部はこの用途・リアルタイム性、対応MCU/アーキ、機能安全認証、商用/OSS、開発環境/ミドルウェア、セキュリティ、ライセンス/コストという7軸の観点で整理しました。

編集部コメント：7軸は独立ではなく、上流の軸ほど後戻りのコストが大きい順に並べています。なかでも「リアルタイム性」と「機能安全認証」を曖昧にしたまま価格やライセンスだけで選ぶと、量産直前で系統ごと乗り換える事態になりやすい点に注意してください。

ここからは7軸を上から順に掘り下げます。各軸は前の軸の判断を引き継ぐ前提で並ぶため、飛ばさず順に確認してください。

用途とリアルタイム性の見極め

選定の出発点は、自社の機器がハードリアルタイムを必要とするか、ソフトリアルタイムで足りるかの切り分けです。ハードリアルタイムは「締切を1回でも超えると重大な結果を招く」制御、たとえばモーター制御・ブレーキ・医療機器の動作などを指します。ソフトリアルタイムは「多少の遅延が許容される」用途、たとえば表示更新やデータ収集などです。

ハードリアルタイム性が必須なら、応答時間の上限が保証され、割り込み遅延が確定的なRTOSを選びます。QNX Neutrinoはマイクロカーネル構造で障害をプロセス単位に隔離しつつ確定的な制御を実現し、INTEGRITYはハードリアルタイム性能と高信頼を両立します。VxWorksも高信頼分野で長年の実績があります。一方、IoTセンサーや簡易な機器制御のようにソフトリアルタイムで十分な用途では、FreeRTOSやTOPPERS/ASP、μC3など軽量なRTOSで過不足なく対応できます。

ここで重要なのは「念のため厳しい方に倒す」発想がコストに跳ね返る点です。ソフトリアルタイムで足りる機器に認証付き商用RTOSを選ぶとライセンス費が量産コストを圧迫し、逆にハードリアルタイムが要る機器をOSSで押し切ると応答保証の検証や認証対応を自社で抱え込むことになります。

編集部コメント：「リアルタイム性」は感覚で決めず、制御周期と許容ジッタを数値で書き出すのが近道です。要求応答時間がマイクロ秒〜数ミリ秒で締切超過が許されないならハード、数十ミリ秒以上の遅延を許せるならソフト、と数字で線を引くと後段の判断もぶれません。

対応MCU/アーキテクチャの確認

次に、採用予定のマイコン（MCU）のアーキテクチャとメモリ容量にOSが対応しているかを確認します。RTOSはカーネルがCPUアーキテクチャに密接に依存するため、対応していないアーキでは移植に大きな工数がかかります。Arm Cortex-Mのような広く使われるアーキはほとんどのRTOSが対応しますが、独自アーキや特殊なDSPでは候補が限られます。

FreeRTOSは40を超えるマイクロコントローラアーキテクチャに対応し、対応の広さで導入障壁が低いことが強みです。VxWorksも広範なCPUに対応し、長期運用が前提の製品開発に向きます。一方、メモリ容量の制約が厳しい小規模マイコンでは、省メモリ設計のRTOSが現実解になります。μC3は小規模マイコンでも動く省メモリ設計が特徴で、安価なマイコンにも載せやすい点が国内の機器開発で扱いやすさにつながっています。TOPPERS/ASPはμITRON系仕様に基づき、国内に知見と派生カーネルの選択肢が多い点が利点です。

確認すべきは現行マイコンだけでなく、将来の派生機種で使う可能性のあるマイコンまでです。複数アーキにまたがる製品ラインを持つなら、対応アーキの広いRTOSを選ぶと機種ごとにOSを変える手間とノウハウの分散を避けられます。

機能安全認証への適合

自動車・医療・産業機器・航空宇宙などでは、機能安全規格への適合が選定を左右します。IEC 61508（産業機器の機能安全）、ISO 26262（車載）、IEC 62304（医療機器ソフト）、DO-178C（航空）などが代表で、これらの認証を取得する際にOS自体が認証取得済みか、認証取得を支援する成果物（安全マニュアルやテスト証跡）を提供できるかが大きな差になります。

商用RTOSの多くは認証対応版を用意しています。INTEGRITYはISO 26262やDO-178Cに準拠した開発を支援し、EAL 6+の認証実績を持ちます。QNXは車載・医療・産業制御で機能安全認証の実績があり、VxWorksも安全認証取得品（Cert Edition）を別構成で提供しています。一方、OSSのTOPPERS/ASPやFreeRTOSは、機能安全認証を自社対応するか別途委託する必要があり、認証取得済みOSと比べて成果物の整備負担が大きくなります。μC3も機能安全認証の用途では個別確認が前提です。

編集部コメント：認証は「OSが認証されていれば製品も認証される」わけではなく、機器全体で取得するものです。OSはその構成要素として証跡を提供する立場に過ぎないため、認証版OSを選んでも自社の開発プロセスとテスト証跡の整備は別途必要になる、という前提で工数を見積もってください。

商用RTOSかOSSかの判断

組込みOSは大きく、ベンダーが保守・保証する商用RTOSと、ライセンス費なしで使えるOSSに分かれます。この選択は機能だけでなく、保守責任を誰が負うかという組織の問題でもあります。

商用RTOS（VxWorks・QNX・INTEGRITYなど）は、ベンダーによる長期サポート・不具合対応・認証支援が受けられる代わりに、ライセンス費や量産時のロイヤリティが発生します。高信頼が求められライフサイクルが長い機器では、保守を外部に委ねられる安心感が費用に見合います。一方OSS（FreeRTOSはMITライセンス、TOPPERS/ASPはTOPPERSライセンスで商用利用可）は導入障壁が低くライセンス費がかかりませんが、品質保証やトラブル対応は基本的に利用側の責任です。FreeRTOSは公式サポートがAWS契約前提である点、TOPPERS/ASPはベンダー保守・保証が基本的にない点を許容できるかが分かれ目になります。

中間的な選択肢として、国産商用RTOSのμC3のように日本語ドキュメント・サポートが充実し、商用の安心感と扱いやすさを両立する製品もあります。OSSの自由度は魅力ですが、量産後の長期保守を自社で抱える覚悟がないなら、商用のサポート契約を前提に設計する方が安定します。

開発環境とミドルウェアの充実度

RTOSのカーネル単体が動いても、製品開発には統合開発環境（IDE）・デバッガ・TCP/IPスタック・ファイルシステム・USBスタックなどの周辺ソフトが必要です。これらを純正・標準で提供しているか、自前で用意する必要があるかで、開発工数は大きく変わります。

商用RTOSは充実した開発環境がそろっている傾向があります。VxWorksは広範なCPU対応と合わせて開発環境が整い、長期運用の製品開発を支えます。μC3はTCP/IPスタックやファイルシステムなどのミドルウェアと組み合わせて使える構成で、周辺機能を含めて国内サポートを受けられます。FreeRTOSはAWS IoTとの連携が用意され、クラウド接続機器の開発で扱いやすい構成です。TOPPERS/ASPは用途別の派生カーネルを選べる柔軟性がありますが、ミドルウェアの組み合わせは利用側で設計する範囲が広くなります。

確認の勘所は、自社が必要とする周辺機能のうち何が標準提供で何を自前実装または追加調達するかを洗い出すことです。カーネルが無料でも、TCP/IPやセキュア通信を自前で整備する工数を積むと、商用RTOSの一式提供の方が総工数で安くなる場合があります。

セキュリティ要件への対応

ネットワークに接続する組込み機器が増え、セキュリティは選定軸として無視できなくなりました。セキュア通信（TLS等）、安全なファームウェア更新（セキュアブート・OTA）、脆弱性が出た際の対応体制、そして障害や侵害を局所化するアーキテクチャ構造が論点です。

マイクロカーネル型のQNXは、障害をプロセス単位で隔離できる構造が、一部の不具合や侵害が全体に波及しにくいという点でセキュリティ・信頼性の両面で評価されます。INTEGRITYはEAL 6+の認証実績が示すとおり、高いセキュリティ水準を要する領域で採用されています。OSSを採用する場合は、脆弱性が公表された際にパッチを誰が適用し、出荷済み機器をどう更新するかという運用体制を自社で設計する必要があります。FreeRTOSはAWS IoTと組み合わせてクラウド側でセキュリティ機能を補完する構成が取れますが、その場合はクラウド契約を前提とした設計になります。

セキュリティは製品出荷時だけでなく、出荷後の数年間に脆弱性へどう対応し続けるかまで含めて評価します。長期間ネットに接続する機器ほど、更新の仕組みとベンダーの脆弱性対応窓口の有無が後から効いてきます。

ライセンスとコストの総額設計

最後に、ライセンス形態と総コストを評価します。組込みOSのコストは初期のライセンス費だけでなく、量産1台ごとに発生するロイヤリティ、年間のサポート費、認証版の追加費用まで含めた総額で比較しないと、量産台数が増えてから採算が崩れます。

OSSはライセンス費がかからないのが最大の利点です。FreeRTOSはMITライセンスで商用利用も無料、TOPPERS/ASPもTOPPERSライセンスで無償・商用利用が可能です（商用サポート版は別途有償）。商用RTOSは個別見積もりが基本で、VxWorks・QNX・INTEGRITYはいずれもライセンス・ロイヤリティ構成で要問い合わせとなり、認証版はさらに別構成です。国産のμC3は目安が公開されており、μC3/Compactは約80万円、μC3/Standard（シングルコア版）は約150万円が目安です（2026年5月時点）。

編集部コメント：「無料だから安い」とは限らないのが組込みOSのコストです。OSSはライセンス費ゼロでも、認証対応・脆弱性保守・周辺ソフト整備を自社人件費で賄うため、量産規模やライフサイクルが長い製品では商用RTOSのロイヤリティ込み総額の方が結局安くなることもあります。台数とサポート工数を前提に総額で比べてください。

これまでの7軸を踏まえ、自社のタイプ別に出発点となる候補系統を整理します。本記事で扱った製品・情報の範囲で、読者の立場ごとに先に検討すべき方向を示します。

車載・医療など機能安全認証が必須の高信頼機器の場合

ISO 26262やIEC 61508などの認証取得を前提とする機器では、認証対応版を持つ商用RTOSが出発点です。INTEGRITYはISO 26262/DO-178C準拠開発を支援しEAL 6+の実績を持ち、QNX Neutrinoは車載・医療・産業制御での機能安全認証実績と障害隔離構造を備えます。認証版は通常版と別ライセンスになる点を見込んだうえで検討します。

ハードリアルタイムと長期運用が前提の産業機器の場合

確定的な応答時間と長いライフサイクルが求められる産業機器では、VxWorksが候補になります。広範なCPU対応・充実した開発環境・長期サポートがそろい、製品ライフサイクル全体を支える構成です。商用ライセンス費は高めになりやすいため、小規模・低コスト機器には過剰になりがちな点を踏まえて適用範囲を絞ります。

IoT機器やクラウド連携を前提に、コストと導入の軽さを優先する場合

ソフトリアルタイムで足り、クラウド連携を重視するIoT機器では、FreeRTOSが出発点です。MITライセンスで商用利用も無料、40超のアーキ対応で導入障壁が低く、AWS IoT連携でクラウド側の機能を補完できます。ハードリアルタイム要件や公式サポートを重視する場合は商用RTOSへの切り替えを検討する前提で使います。

ライセンス費を抑え、国内の知見を活かしたい場合

認証が当面不要で、コストを抑えつつ国内の知見を活用したいなら、TOPPERS/ASPが候補です。μITRON系仕様で国内に知見が多く、用途別の派生カーネルを選べます。ベンダー保守・保証は基本的にないため、保守と認証対応を自社または委託で賄える体制があることが前提になります。

国産の商用サポートと省メモリ設計を両立したい場合

安価なマイコンで動く省メモリ設計と、日本語の手厚いサポートを両立したいなら、国産商用RTOSのμC3が出発点です。TCP/IP等のミドルウェアと組み合わせやすく、価格目安も公開されているため見積もりが立てやすい一方、大規模・高機能用途では機能が限定的になる点と、機能安全認証の用途は個別確認が必要な点を踏まえて判断します。

候補が2〜3製品に絞れたら、いきなり量産設計に入らず、評価ボードと自社の代表的な制御ロジックを使った検証（PoC）を行うと本番での手戻りを減らせます。期間は1〜3ヶ月程度を見込み、最も厳しい制御周期のタスクを実装して応答時間・割り込み遅延が要求を満たすかを実機で測定します。

検証では、(1)要求応答時間を満たすか、(2)採用予定マイコンに載るか、(3)必要なミドルウェア（TCP/IP・ファイルシステム等）が動くか、(4)IDE・デバッガで開発・解析しやすいか、(5)認証が要る場合は成果物の提供範囲が要件を満たすか、を確認します。費用面では評価段階は評価版や無償版で進められることが多い一方、量産フェーズではロイヤリティやサポート契約が発生するため、PoCと並行して量産時の総額見積もりをベンダーから取得しておくと稟議が滑らかになります。

組込みOS/RTOS選定で失敗する開発現場には共通パターンがあります。事前に把握しておくと、設計や稟議の段階で先回りして対策できます。

第一は「リアルタイム性過小評価」型です。ソフトリアルタイムだと思って軽量OSを選んだものの、実際にはハードリアルタイムが必要で締切を守れず、量産直前で商用RTOSに乗り換えるパターンです。回避策は、制御周期と許容ジッタを数値化し、PoCで最悪値を実測してから系統を確定することです。

第二は「認証後付け」型です。認証不要として無償OSで開発を進めたあと、市場要件で機能安全認証が必要になり、成果物が足りずに再選定になるパターンです。回避策は、製品が将来参入する市場の規制を選定段階で確認し、可能性があるなら認証支援のある製品を初めから候補に入れることです。

第三は「コスト総額の見落とし」型です。ライセンス無料に着目してOSSを選んだものの、認証対応・脆弱性保守・周辺ソフト整備の人件費がかさみ、結果的に商用RTOSより高くついたパターンです。回避策は、ライセンス費だけでなく保守・認証・ロイヤリティを含めた総額で、量産台数を前提に比較することです。

第四は「サポート体制軽視」型です。量産後に不具合や脆弱性が出た際、保守の責任者がおらず対応が滞るパターンです。回避策は、OSSなら自社の保守体制と更新の仕組みを設計に織り込み、商用ならサポート契約の範囲と窓口を契約段階で明確にすることです。

編集部コメント：四つの失敗パターンは、いずれも「リアルタイム性・認証・総額・サポートのどれかを後回しにした」結果として生じます。本記事の7軸とPoCの確認項目を設計レビューや稟議資料にそのまま落とし込むと、これらの典型的なつまずきを量産前に潰せます。

組込みOS/RTOSの選定は七つの軸（用途とリアルタイム性・対応MCU/アーキ・機能安全認証・商用かOSSか・開発環境とミドルウェア・セキュリティ・ライセンスとコスト）を順に評価すると失敗が減ります。まず制御の締切と認証の要否でOSSと商用RTOSのどちらの系統に進むかを決め、対応マイコンと開発環境を確認し、セキュリティと総コストで候補を2〜3に絞り、最後にPoCで実機検証する流れです。

認証と高信頼を軸にQNX・INTEGRITY・VxWorksから選ぶか、コストと導入の軽さでFreeRTOS・TOPPERS/ASPを選ぶか、国産サポートと省メモリでμC3を選ぶかが典型的な分岐です。具体的な製品候補を機能面で並べて比較したい場合は、別記事「組込みソフトウェア比較」で各製品を確認できます。カテゴリ全体の製品一覧は組み込みソフトウェア（組込みOS・RTOS）から、用語の基礎は「組込みOSとは」からたどれます。本記事のフレームワークで自社要件を整理してから比較に進むと、選定が短期間で完了します。