組み込みOS・RTOSとは？汎用OSとの違い・仕組み・選び方をわかりやすく解説

組み込みOSは、特定の機器に組み込まれて、その機器の動作を制御するために動くOSです。パソコンのように利用者が自由にソフトを追加して使う汎用OSと異なり、機器の役割に合わせて必要な機能だけを持たせ、限られたメモリやCPUでも動くように作られています。家電の制御基板から産業用ロボット、自動車のECU（電子制御ユニット）まで、機器の中で目立たず動いているのが組み込みOSです。

組み込みOSのうち、リアルタイム性を重視したものがRTOSです。リアルタイム性とは、ある処理を「いつまでに終わらせる」という時間の制約を守る能力を指します。RTOSは、複数の処理（タスク）に優先順位をつけ、より重要なタスクを決めた時間内に確実に実行できるよう制御します。処理をたくさんこなす速さよりも、決めた時間を守れる確実さ（予測可能性）を重視する点が、RTOSの本質です。

RTOSが扱う中心的な単位がタスクです。機器の中の仕事を、センサーを読む、モーターを動かす、通信するといった単位に分け、それぞれをタスクとして管理します。RTOSは各タスクの状態と優先度を見ながら、どのタスクをいつ動かすかを切り替えます。これにより、複数の処理が同時に走る機器でも、重要な処理が他の処理に邪魔されて遅れる事態を防げます。

RTOSを使わずにマイコンを直接プログラムする方式は、ベアメタルやOSレス開発と呼ばれます。処理が単純で数も少ないうちは、ベアメタルのほうが軽量で無駄がありません。一方、処理が増えてタスク同士の調整が複雑になると、ベアメタルでは管理が難しくなります。タスクの優先順位づけや切り替えをOSに任せられる点が、RTOSを導入する大きな動機になります。機器の機能が増えるほど、RTOSによるタスク管理の価値が高まります。

RTOSと汎用OSの最大の違いは、何を最優先に設計されているかです。WindowsやLinux、macOSといった汎用OSは、多くのアプリを効率よく動かし、全体の処理量（スループット）を高めることを狙います。多少の処理の遅れは許容し、平均的に速く動くことを重視します。一方RTOSは、個々の処理が決めた時間内に終わることを最優先し、応答時間を予測できるように作られています。平均の速さより、最悪の場合でも時間を守れることが大切にされます。

この違いは、処理の切り替え方に表れます。汎用OSは、多くの処理に公平にCPUを割り当てる方式が中心で、ある処理がどれだけ待たされるかは状況によって変わります。RTOSは、優先度の高いタスクが実行可能になった瞬間に、動いているタスクを止めて切り替えます。重要な処理を最優先で動かせるため、応答時間のばらつきが小さく、予測しやすくなります。同じ入力なら同じ時間で応答する決定論性が、RTOSの強みです。

規模やリソースの面でも違いがあります。汎用OSは多機能なぶん、大きなメモリと高性能なCPUを前提とします。RTOSは汎用OSよりはるかに軽量・コンパクトで、小さなマイコンでも動きます。組み込み機器はコストや消費電力の制約からリソースが限られることが多く、この軽量さがRTOSが選ばれる理由になります。ただし、画面表示や複雑なネットワーク処理、豊富なアプリが必要な機器では、Linuxのような汎用OSのほうが向く場合もあります。

実際の機器では、両者を使い分けたり組み合わせたりすることもあります。たとえば、画面表示や通信は汎用OSに任せ、モーターのリアルタイム制御はRTOSや専用の処理に分ける、といった構成です。RTOSと汎用OSは優劣ではなく、機器に求められる時間制約とリソース、機能の組み合わせで選び分けるものだと整理できます。自社の機器がどこまで厳しい時間制約を持つかを見極めることが、選択の出発点になります。

リアルタイム性は、時間の制約をどこまで厳密に守る必要があるかによって、ハードリアルタイムとソフトリアルタイムに分かれます。この違いは、機器が「期限に間に合わなかったとき何が起きるか」で決まります。自社機器がどちらを必要とするかは、RTOS選びと安全設計に直結します。

ハードリアルタイムは、決めた時間（デッドライン）を一度でも超えると、致命的な結果につながる性質です。たとえば、自動車のエアバッグの制御や、産業機械の緊急停止、医療機器の制御では、処理が少しでも遅れると人命や重大な事故に関わります。こうした機器では、最悪の場合でも必ず時間を守れることが絶対条件になります。ハードリアルタイムを要する機器ほど、応答時間が保証され、機能安全認証に対応したRTOSが求められます。

ソフトリアルタイムは、時間を多少超えても致命的にはならず、品質や使い勝手が下がる程度に収まる性質です。たとえば、動画の再生で一瞬コマが飛ぶ、機器の表示更新が少し遅れる、といった場面です。望ましい応答時間はあるものの、たまに守れなくても全体としては機能します。ソフトリアルタイムの機器では、厳密な時間保証より、平均的な応答性やコスト、開発のしやすさを優先する選択もできます。

実務では、一つの機器の中にハードとソフトの両方の要件が混在することも珍しくありません。安全に関わる制御はハードリアルタイムで確実に守り、表示や通信はソフトリアルタイムで扱う、という設計が行われます。自社機器のどの処理がハードリアルタイムで、どの処理がソフトリアルタイムかを切り分けておくと、過剰な安全対策も、逆の手抜きも避けられます。この切り分けが曖昧なまま開発を進めると、後から安全要件を満たせず大きな手戻りになる場合があります。

RTOSが時間制約を守れるのは、タスクをどう動かすかを決めるスケジューリングの仕組みによります。中心になるのが、タスクに優先度をつけて管理する方式です。仕組みを知ると、RTOSがなぜ応答時間を予測できるのかが理解しやすくなります。

RTOSは、機器の処理をタスクという単位に分け、それぞれに優先度を割り当てます。スケジューラと呼ばれる仕組みが、実行できる状態のタスクのうち、最も優先度の高いものを選んでCPUに割り当てます。優先度の高いタスクが実行可能になると、いま動いているより優先度の低いタスクを中断して、すぐに高優先度のタスクへ切り替えます。この割り込み的な切り替え（プリエンプション）によって、重要な処理が他の処理に待たされずに動けます。

タスクは、実行中・実行可能・待機といった状態を移り変わりながら管理されます。あるタスクがセンサーの入力やタイマーを待っている間は待機状態になり、その間CPUは他のタスクに使われます。待っていた条件が整うと、タスクは実行可能状態に戻り、優先度に応じて再びCPUを得ます。こうした状態の管理をOSが担うことで、開発者は個々のタスクの中身に集中でき、タスク同士の調整に悩まされにくくなります。

複数のタスクが同じデータや機器を取り合う場面では、調整の仕組みも必要になります。あるタスクが使っている資源を別のタスクが横取りしないよう、排他制御やタスク間の通信の仕組みがRTOSに用意されています。これらを適切に使わないと、優先度の高いタスクが低いタスクに待たされる優先度逆転のような問題が起きることがあります。RTOSはこうした問題への対策も備えますが、使いこなすには設計者の理解が前提になります。仕組みに任せきりにせず、タスクの設計を丁寧に行うことが、安定した動作につながります。

RTOSは、提供形態によって大きく商用とオープンソースに分かれます。どちらを選ぶかは、サポートの手厚さ、ライセンス費用、機能安全認証の要否によって変わります。代表的な製品を、性格ごとに整理します。

商用RTOSは、ベンダーが開発・保守し、サポートや認証取得品を提供する製品です。高信頼が求められる分野で長年の実績を持つVxWorks、障害をプロセス単位で隔離するマイクロカーネル構造で車載・医療に強いQNX Neutrino、航空宇宙・防衛など最高水準の安全性が必要な領域で選ばれるINTEGRITY、長い市場実績と機能安全認証を持つNucleusなどがあります。これらはライセンス費用がかかる一方、機能安全認証への対応や手厚いサポートが必要な機器で選ばれます。国産では、省メモリ設計と日本語サポートに強いμC3が、リソースの限られた国内向け機器で扱いやすい選択肢になります。

オープンソースのRTOSは、ライセンス費用をかけずに利用できる点が特徴です。40を超えるマイコンのアーキテクチャに対応し、AWSが管理するFreeRTOSは、IoTデバイスや低コストの組み込みで広く使われています。国内では、μITRON系仕様に基づくTOPPERS/ASPカーネルが、教育機関から産業機器まで採用され、ライセンス費用なしで商用利用もできます。オープンソースは導入の障壁が低い一方、ベンダーによる保守・保証が基本的にない点や、機能安全認証は自社対応または別途委託が必要になる点を、採用前に押さえておく必要があります。

商用とオープンソースのどちらが合うかは、開発体制と要件によって分かれます。社内に組み込み開発力があり、コストを抑えたい場合はオープンソースが選択肢になります。一方、安全認証や手厚いサポートが前提の機器では、商用RTOSのほうが結果的に開発期間や保守の面で有利になることが多くなります。製品の安全要件と、社内でどこまで対応できるかを照らし合わせて選ぶと、後からの作り直しを避けられます。

RTOSは、すべての組み込み機器に必要なわけではありません。時間制約の厳しさやタスクの複雑さ、リソースの大きさによって採用の妥当性が変わるため、向き不向きを判断軸で押さえておくと検討がぶれません。ここで言う向き不向きは、機器の種類そのものより、時間制約の厳しさ・タスク数・安全認証の要否・リソースの大きさといった条件で決まります。

向いているのは、厳しい時間制約のもとで複数の処理を並行して動かす機器です。モーターやアクチュエータをリアルタイムに制御する産業機器、安全に関わる車載・医療機器、複数のセンサーや通信を同時に扱う機器では、優先度に基づくタスク管理と応答時間の予測が品質に直結します。とくに、期限超過が許されないハードリアルタイムの処理を含む機器では、応答時間を保証でき機能安全認証に対応したRTOSが前提になります。タスクが増えてベアメタルでは管理が複雑になってきた機器も、RTOS導入の効果が出やすい典型です。

一方で、処理が単純で数も少ない小規模な機器では、RTOSがオーバースペックになることがあります。一つか二つの処理を順番に回すだけの機器なら、ベアメタル開発のほうが軽量で、メモリやコストの面でも有利です。厳しい時間制約がなく、リソースも極端に限られる機器では、RTOSの導入が負担になる場合もあります。逆に、画面表示や複雑なネットワーク、豊富なアプリが必要な機器では、RTOSより汎用OS（組み込みLinuxなど）のほうが向きます。RTOSの採用を目的にせず、機器の要件が先にあるかが分かれ目になります。

判断に迷う場合は、いくつかの問いを自社の機器に当てると整理できます。期限を超えると致命的になる処理があるか。複数の処理を優先度をつけて並行させたいか。機能安全認証が必要か。リソースは小さいか、ある程度余裕があるか。これらに当てはまるほど、RTOSの採用が妥当になります。逆に当てはまらない場合は、ベアメタルや汎用OSで足りないかを先に確認するほうが、過剰な設計を避けられます。

編集部コメント：RTOSが要るかどうかは、製品の派手さではなく「期限超過が許されない処理があるか」と「タスクが優先度づけを要するほど増えているか」で見極めるのが実務的です。安全に関わる制御や、複数処理の並行が複雑になってきた機器ほど、RTOS導入の効果が表れます。一方、目的が曖昧なまま高機能な商用RTOSを入れると、ライセンス費用と認証対応の負担だけが残りがちです。まず自社機器の処理を「ハードリアルタイムか、ソフトか、そもそも時間制約が緩いか」で切り分けることが、製品選びの起点になります。

自社の機器に合うRTOSを具体的に探す段階では、ITトレンドの組み込みソフトウェアカテゴリで、対応アーキテクチャや認証などの条件から製品を絞り込み、比較できます。

RTOSは、対応するマイコンのアーキテクチャ、リアルタイム性能、機能安全認証の有無、ライセンス形態（商用／オープンソース）、サポート体制、リソースの軽さという観点で性格が分かれます。ここでは編集部が、組み込み開発での使われ方をふまえ、工程管理適合性・品質管理適合性・生産管理適合性・中堅中小製造業との相性という軸で各製品を整理しました。高機能であるほど良いわけではなく、自社機器の要件に必要な範囲が揃っているかが選定を左右します。

組み込み開発でよく検討されるRTOSを、上記の観点で並べると次のようになります。スコアは編集部が製造業適合性の観点で評価した相対的な目安で、5を上限とします。価格・ライセンスは2026年6月時点の公開情報・代理店情報をもとにしており、商用製品の多くは要見積です。

産業機器や航空など、高信頼で長期運用が前提の機器では、豊富な採用実績と機能安全認証への対応、広範なCPU対応を持つVxWorksが有力な選択肢です。商用ライセンス費用は高めになりやすく、小規模・低コスト機器には過剰になりがちな点は押さえておく必要があります。車載や医療のように障害の隔離と高信頼が必須の機器では、マイクロカーネル構造で機能安全認証の実績が豊富なQNX Neutrinoが向きます。POSIX準拠で開発・移植がしやすい一方、こちらも小規模機器にはオーバースペックになりやすい製品です。

航空・防衛・自動車のADASやECUなど、最高水準の安全性が求められる領域では、EAL 6+認証の実績を持ちISO 26262やDO-178Cの開発を支援するINTEGRITY RTOSが候補になります。長い市場実績と機能安全認証を備え、Siemensの製品エコシステムと組み合わせやすいNucleusも、機能安全が必要な機器で選ばれます。いずれもライセンス費用が高く、コンシューマ向けの小規模機器には負担が大きくなります。

リソースの限られたマイコン機器で、日本語のドキュメントとサポートを重視する国内開発には、省メモリ設計の国産RTOSであるμC3が扱いやすい選択肢です。コストを抑えたい開発で、社内に組み込み開発力がある場合は、ライセンス費用なしで使えるオープンソースが選択肢になります。μITRON系仕様で国内に知見が多いTOPPERS/ASPカーネルや、40を超えるアーキテクチャに対応しAWS IoTとの連携に強いFreeRTOSが代表例です。オープンソースはベンダー保守が基本的にないため、手厚いサポートや認証が前提の機器では、商用RTOSと比較して慎重に判断する必要があります。

製品ごとに、対応アーキテクチャと認証、ライセンス形態が分かれるため、自社機器の安全要件・リソース・開発体制を軸に比較すると絞り込みやすくなります。具体的な対応状況や条件を確認する段階では、ITトレンドの組み込みソフトウェアカテゴリで各製品を確認できます。

組み込みOS・RTOSとは、機器を決められた時間内に確実に動かすことを最優先するOSです。処理量の効率を狙う汎用OSと違い、タスクの優先度に従って即座に切り替え、応答時間を予測できる点が核になります。リアルタイム性には、期限超過が許されないハードリアルタイムと、多少の遅れを許容するソフトリアルタイムがあり、機器のどの処理がどちらに当たるかの切り分けが設計の出発点になります。

RTOSは、厳しい時間制約のもとで複数の処理を並行させる機器ほど効果が表れます。優先度に基づくタスク管理と応答時間の予測、機能安全への対応が主な利点です。一方で、処理が単純な小規模機器ではベアメタルで足り、画面表示や複雑な処理が中心なら汎用OSが向く場合もあります。商用かオープンソースか、機能安全認証が要るかどうかも含め、自社機器の要件を整理して選ぶ進め方が現実的です。

自社の機器にどのRTOSが合うかが見えてきたら、次は具体的な製品の比較です。対応アーキテクチャ、機能安全認証、ライセンス形態によって適した製品が分かれるため、ITトレンドの組み込みソフトウェアカテゴリで自社の条件に合う製品を確認できます。