RTOSとは？リアルタイムOSの仕組み・主要製品の比較と採用判断を実装者目線で解説

RTOS（リアルタイムOS）は、決められた期限内に処理を終えることを設計上の保証にしたOSです。処理量を稼ぐ汎用OSとは目的が違い、平均的な速さではなく「最悪でも何マイクロ秒で応答するか」を守ります。この記事では、RTOSの定義とカーネルの中身、優先度逆転やスタック不足といった実装で必ずぶつかる論点、FreeRTOS・Zephyr・QNX・VxWorks・TOPPERSの選定軸、ベアメタル実装やPREEMPT_RT対応Linuxとの境界線までを、制御ソフトを設計する立場から整理しました。

まとめ：RTOS採用の可否を分ける応答時間要件と製品選定の結論

RTOSを入れるかどうかは、機能の多さではなく「守るべき締切があるか」で決まります。ミリ秒単位の締切を破ると製品が壊れる、人が危険にさらされる、法規に触れる。この3つのどれかに当たるなら、RTOSかそれに準じる仕組みが要ります。逆に、締切が緩く周期処理が数本しかない装置では、RTOSはメモリと学習コストを食うだけの重石になりかねません。

製品選定は、ライセンス費よりも「認証が要るか」で分岐させると迷いません。ISO 26262やIEC 62304の認証書類が必要な案件は、認証パッケージを売っているQNXやVxWorksが結局は安く付きます。認証が不要な産業機器・IoT機器なら、FreeRTOS（MITライセンス・カーネル11.3系）かZephyr（Apache-2.0・4.4.0）で足ります。既存資産がITRON系に寄っているなら、TOPPERSカーネルの継続も現実的でしょう。

判断の順番は、①許容遅延の数値化 → ②認証要否 → ③公式ポートの有無 → ④ライセンス条件です。この順で潰せば、比較表を眺める前に候補は2つ程度まで絞れます。

RTOSの定義とリアルタイム性の意味、汎用OSとの構造的な違い

RTOSはReal-Time Operating Systemの略で、組込み機器の制御ソフトを載せる土台として使われます。誤解されやすいのは「リアルタイム＝高速」という読み方です。RTOSが保証するのは速度ではなく、時間の予測可能性のほうにあります。

決められた時間内に処理を終える保証としてのリアルタイム性の定義

リアルタイム性とは、あるイベントが発生してから応答を返し終えるまでの時間に上限が引かれ、その上限が設計時に見積もれる性質を指します。たとえばモータの過電流を検知してからPWM出力を止めるまでを200マイクロ秒以内、と決めたなら、どんな負荷状況でもその200マイクロ秒を超えない構造になっていなければいけません。平均150マイクロ秒でも、最悪値が5ミリ秒に跳ねる実装は不合格です。

この「最悪値で語る」姿勢が、RTOSと他のソフトウェア基盤を分けます。RTOSのカーネルは、割り込み禁止区間の長さやコンテキストスイッチのサイクル数を、対象CPUごとの数値として仕様に載せているものが多くあります。

ハードリアルタイムとソフトリアルタイムを分ける許容遅延の基準

期限を1回でも破ると製品として失敗するものがハードリアルタイム、破っても品質が落ちるだけで済むものがソフトリアルタイムです。エアバッグの展開判定やインバータの電流制御は前者、動画のフレーム描画やログのアップロードは後者に入ります。

実務では、この2つが1台の機器に同居します。判定を誤らないコツは、機能単位ではなくタスク単位で仕分けることでしょう。制御ループのタスクはハード、通信とUIのタスクはソフトと割り切れば、優先度の付け方が自然に決まります。全部をハード扱いにすると、優先度がフラットになって設計の意味が消えます。

汎用OSとRTOSでスループットと応答遅延の設計思想が逆転する理由

汎用OSは、限られたCPU時間で全体の処理量を増やすためにスケジューラを組みます。公平性を保ち、キャッシュのヒット率を上げ、平均の待ち時間を縮める。Linuxのプロセス管理とディストリビューションの仕組みを見ると、この方針がはっきり読み取れます。結果として、優先度の高いタスクでも数ミリ秒待たされることが起こりえます。

RTOSは逆です。全体の処理量が落ちても、最優先タスクを最短で走らせます。低優先度タスクが延々と待たされる状態（スタベーション）も、設計上そう決めたなら許容します。差はコード規模にも表れ、RTOSカーネルはROM数KB〜数十KB、RAM数KB程度で動くものが主流です。

RTOSカーネルの中核機能とスケジューリング方式ごとの応答特性の差

RTOSと呼ばれる製品の中身は、突き詰めればスケジューラ・同期機構・時間管理の3つに集約されます。ファイルシステムやTCP/IPスタックは、その上に載る別コンポーネントです。

タスク管理と割り込み処理を担うRTOSカーネルの最小構成要素

カーネルが持つのは、タスク制御ブロック（TCB）によるタスクの状態管理、レディキュー、ティックまたはティックレスの時間管理、そして割り込みハンドラからタスクへ通知を渡す経路です。FreeRTOSならxTaskCreateでタスクを作り、vTaskDelayUntilで周期実行を組みます。Zephyrではk_thread_createが同じ役割を担います。

押さえておきたいのが、割り込みハンドラの中で使えるAPIが限られる点です。FreeRTOSは末尾にFromISRが付いた別系統のAPIを用意しており、取り違えると動作が不安定になります。移植時のバグの多くは、この境界の踏み外しから生まれます。

優先度ベースのプリエンプティブ方式とラウンドロビンの使い分け

主流は固定優先度のプリエンプティブスケジューリングです。高優先度タスクがレディになった瞬間、実行中の低優先度タスクは中断されます。同じ優先度のタスクが複数ある場合に限り、タイムスライスで回すラウンドロビンを併用する構成が一般的でしょう。

周期タスクの優先度は、周期の短いものほど高くする（レートモノトニック）が出発点です。理論上、CPU使用率がおよそ69%以下なら、この割り当てで全タスクが締切を守れることが知られています。実務ではこれを目安に、使用率70%を超えたら設計を見直す線引きにしておくと安全側に倒せます。

セマフォ・ミューテックス・キューによるタスク間同期の実装選択

同期機構の選び方には型があります。排他制御にはミューテックス、イベント通知にはバイナリセマフォ、データの受け渡しにはキュー。この3つを混同すると、後述する優先度逆転を自分で仕込むことになります。

• ミューテックス：所有者の概念があり、優先度継承を効かせられる。共有リソースの保護に使う
• セマフォ：所有者の概念がなく、割り込みからの通知やカウント管理に向く
• キュー：データのコピーを伴う受け渡し。生産者と消費者の速度差を吸収する

まず押さえるべきはミューテックスとキューです。この2つで組めない同期パターンは、設計そのものを疑ったほうが早いでしょう。

割り込み応答遅延とコンテキストスイッチ時間が実測で示す性能差

製品比較で見るべき数値は、割り込み応答遅延（割り込み発生からハンドラ先頭までのサイクル数）と、コンテキストスイッチに要するサイクル数です。Cortex-M4クラスのマイコンでは、いずれも数十〜数百サイクル、動作周波数が100MHzなら1マイクロ秒未満に収まる製品が多くあります。

優先度逆転とWCET見積りで実装が破綻する典型パターンと回避策

RTOSを載せただけでは、締切は守れません。破綻の原因はカーネルではなくアプリ側の設計にあり、しかも症状が再現しにくい形で出ます。

優先度逆転が起きる条件とミューテックスの優先度継承による回避

低優先度タスクが共有リソースを掴んだまま、中優先度タスクにCPUを奪われる。その結果、リソース待ちの高優先度タスクが中優先度タスクよりも後回しになる。これが優先度逆転です。1997年の火星探査機マーズ・パスファインダーで発生した再起動障害が有名な事例として知られています。

回避策は、共有リソースの保護に優先度継承付きミューテックスを使うことに尽きます。FreeRTOSではxSemaphoreCreateMutexで作ったミューテックスが優先度継承に対応し、バイナリセマフォでは対応しません。「排他制御にセマフォ」の実装が危ういのは、この差があるためです。

WCETを見積もらずにタスク周期を決めた設計が破綻する典型例

WCET（最悪実行時間）を測らずに周期を決めると、負荷が上がった局面だけで締切を破る不具合になります。しかも机上の試験では出ません。通信が混み、ログが溜まり、フラッシュ書き込みが走った瞬間に、制御周期が飛びます。

測り方はシンプルです。タスクの入口と出口でGPIOをトグルし、想定される最悪の負荷を同時にかけた状態で数時間走らせ、パルス幅の最大値を記録します。この最大値が周期の60%を超えたら、処理を分割するか周期を延ばす判断に入ります。

タスクごとのスタックサイズ不足が引き起こす再現困難な不具合の兆候

各タスクは自前のスタックを持ちます。ここが足りないと、隣のメモリを破壊して別のタスクが異常終了する、という原因追跡の難しい壊れ方をします。printf系の関数やfloat演算は数百バイト単位でスタックを食うため、デバッグ用のログを足した途端に発症するパターンが典型です。

対策は2つあります。開発中はスタックに既知のパターンを埋めておき、uxTaskGetStackHighWaterMarkのような残量取得APIで最小残量を監視すること。もう1つは、MPU（メモリ保護ユニット）を持つマイコンならMPU対応版のカーネルを使い、越境アクセスを例外として捕まえることです。FreeRTOS 11.3系ではMPU対応の範囲が広がっています。

動的メモリ確保によるヒープ断片化を避ける静的確保という設計原則

長時間動き続ける組込み機器では、malloc相当の動的確保を原則として使いません。断片化が進み、数週間後に確保失敗で止まるからです。タスク・キュー・セマフォは起動時にすべて静的確保し、以後は増やさない。FreeRTOSもZephyrも静的確保のAPIを備えています。

主要RTOS5製品のライセンス・安全認証・移植性の比較と選定軸

候補は多いようでいて、実際に検討の俎上に載るのは5系統ほどです。ライセンス費の有無より、認証書類が付いてくるかどうかで総額が変わります。

FreeRTOSとZephyrに代表されるOSS系RTOSの適用範囲と限界

FreeRTOSはMITライセンスで、商用製品に組み込んでもソース公開の義務はありません。カーネルは11.3系（2026年3月）、長期サポート版のFreeRTOS 202604 LTSは2026年5月1日に告知され、2年間のセキュリティ修正が付きます。小規模なマイコンで確実に動かす場面の第一候補でしょう。

Zephyrはより新しく、デバイスツリーとKconfigによる構成管理、無線スタックやセンサドライバの同梱が持ち味です。ZephyrOSの概要と基本的な機能で触れているとおり、Linuxに近い開発体験を組込みに持ち込んだ設計になっています。最新版は4.4.0（2026年4月14日）、長期サポートは3.7.0（2024年7月26日リリース・2029年7月27日までサポート）です。限界は、機能が多いぶんフットプリントが大きく、数十KBのRAMしかない機器では窮屈になる点にあります。

QNXやVxWorksなど商用RTOSがライセンス費に見合う場面

車載・医療・鉄道・航空のように、第三者認証の書類提出が要る領域では商用RTOSが現実解です。カーネル本体に加え、安全マニュアルや故障モード分析、検証レポートが付属します。この書類群を自前で作る工数を考えれば、ライセンス費のほうが安く上がります。

マイクロカーネル構成で障害の波及を抑える設計については、QNXの構造とSDP 8.0・安全認証の詳細にまとめてあります。VxWorksは航空宇宙や産業機器での実績が長く、DO-178Cへの適合実績が選定理由になります。

TOPPERS系カーネルとEclipse ThreadXの国内案件での位置付け

国内の産業機器では、μITRON4.0仕様を拡張したTOPPERSカーネル（第3世代カーネル統合仕様書は3.6系）の資産を抱える現場が今も多くあります。既存コードの移植コストを考えると、新規案件でもTOPPERS系を継続する判断に合理性が出ます。ティックレスの高分解能時間管理に対応しており、マイクロ秒単位の時刻制御が可能です。

Eclipse ThreadXは、MicrosoftのAzure RTOSがEclipse Foundationへ移管されたもので、MITライセンスの6.4系として公開されています。NetX Duo（TCP/IP）やFileX、USBX、GUIXが揃うため、周辺スタックまで一式で欲しい場合の候補です。

表の4項目に加え、対象マイコンの公式ポートの有無を必ず確認してください。公式ポートが無い石を選ぶと、移植だけで数人月が飛びます。

ベアメタル実装とリアルタイムLinuxを選ぶべき条件、RTOSを外す判断

RTOSは万能の土台ではありません。上下に隣接する選択肢があり、そちらのほうが総コストで勝つ場面がはっきり存在します。

タスク数と周期の少ない制御でベアメタル実装が有利になる判断条件

周期処理が3本以下、割り込み処理が数個、通信スタックを載せない。この条件を満たす装置なら、メインループとタイマ割り込みだけで組むベアメタル実装のほうが速く、読みやすく、検証も軽くなります。RTOSを入れるとROM・RAMを数KB以上消費し、スケジューラのオーバーヘッドも乗ります。

境界線は「状態機械が2つ以上、非同期に走り始めたとき」に引くのが実務的でしょう。メインループで複数の状態機械を回すと、遅延の見積りが人力になり、機能追加のたびに全体の再検証が要ります。この段階でRTOSへ移す価値が出ます。

PREEMPT_RT対応Linuxで足りるケースとRTOSが要るケース

Linux 6.12でPREEMPT_RTがmainlineへ統合され、外部パッチなしでリアルタイム機能を有効にできるようになりました。達成できる応答遅延は、構成次第でおおむね数十〜数百マイクロ秒の水準です。画面表示やネットワークが要り、締切がミリ秒オーダーの装置なら、Linux側で完結させたほうが開発は楽に進みます。

一方、締切が数十マイクロ秒より厳しい制御ループや、機能安全の認証が要る部分は、Linuxでは踏み込めません。この場合は、Linuxを載せたアプリケーションプロセッサと、RTOSを載せた制御用マイコンを分ける2チップ構成が定番です。エッジAIの実装で問われる判断基準と同じく、推論や表示は上位、締切のある制御は下位、と層で切り分けます。

RTOSを採用すべきでない案件の具体条件と代替手段の決め方の指針

次の3条件のいずれかに当たるなら、RTOSは採用しないと決めてかまいません。第1に、周期処理が3本以下で締切がすべて10ミリ秒より緩い装置。第2に、チームにRTOS経験者がおらず、開発期間が3か月を切っている案件。第3に、RAMが8KB未満のマイコンを既に基板設計で確定させている場合です。

2番目を軽く見ると失敗します。RTOSは載せた瞬間から、優先度設計・スタック見積り・同期機構の選択という判断を開発者に要求します。習熟していないチームが短期間でこなすと、優先度逆転やスタック破壊を仕込んだまま出荷することになりかねません。経験者を確保できないなら、ベアメタルで確実に作るか、設計フェーズだけ外部に入ってもらうほうが安全です。

機能安全認証が必要な案件のコスト構造と外注時の工数見積りの勘所

RTOS選定の費用対効果は、ライセンス費だけを並べても見えません。認証、移植、検証の3つを合算して初めて比較になります。

IEC 61508やISO 26262認証品を選ぶ際の費用と納期の実態

機能安全の認証を取った商用RTOSは、開発ライセンスに加えて出荷台数に応じたロイヤリティが乗る契約形態が一般的です。加えて、認証パッケージが別費用になる場合もあります。見積り依頼では、開発ライセンス・ロイヤリティ・認証パッケージ・年間保守の4項目を分けて出してもらうと比較できます。

移植・ドライバ整備・検証に必要な工数の内訳と見積り時の目安値

公式ポートがあるマイコンなら、カーネルを起動させるところまでは数日で到達します。工数が膨らむのはその先です。内訳はおおむね、周辺ドライバの整備が全体の4割、タスク分割と優先度設計が2割、WCET測定を含む検証が3割、残りがビルド環境とCIの整備という配分になります。

1. 評価ボードでカーネルとティックを動かし、コンテキストスイッチ時間を実測する
2. 周辺ドライバ（UART・SPI・ADC・タイマ）を割り込み駆動で整備する
3. タスク分割と優先度を確定し、レートモノトニックで使用率を算出する
4. 最悪負荷をかけてWCETとスタック最小残量を測り、余裕率を確認する

この4段階のうち、見積りで削られやすいのが4番目です。ここを省くと、量産後に「たまに止まる」という最も高くつく不具合として返ってきます。

外注する場合に発注側が事前に確定させておくべき要件項目の一覧

制御ソフトの開発を外部に委託するとき、発注側が先に決めておくと見積り精度が上がる項目があります。対象マイコンの型番、締切のある処理とその許容遅延（数値）、認証の要否と規格名、想定出荷台数、既存資産の有無。この5点が揃えば、RTOS選定を含む構成提案まで一度で出せます。

逆に、締切の数値が決まっていない状態で相談すると、要件定義から始めることになり期間が伸びます。センサ機器や産業機器の制御ソフトを含む開発は、AI・IoT開発の受託サービスで構成設計から検証まで対応しています。手元に仕様が固まっていない段階でも、締切要件の洗い出しから相談してください。

よくある質問

RTOSの検討でよく聞かれる質問を、判断に直結する形で5つ挙げます。

RTOSと汎用OSの違いを一言で言うと何ですか？

守るものが違います。汎用OSは全体の処理量と公平性を守り、RTOSは個々のタスクの締切を守るのが役割です。そのためRTOSでは、低優先度タスクが長時間待たされる状態も設計上は許容されます。カーネル規模もROM数KB〜数十KB程度と小さく、ファイルシステムやネットワークは必要な分だけ後から足す構成です。ミリ秒より厳しい締切がないなら、汎用OSで足ります。

FreeRTOSは商用製品に無償で組み込めますか？

カーネルはMITライセンスで公開されており、商用製品への組み込みやソースの非公開が可能です。ライセンス表示の義務は残るため、製品のドキュメントや同梱ファイルに著作権表示とライセンス全文を含めてください。機能安全認証が必要な用途では、認証取得済みの別製品（SafeRTOS）や商用RTOSの検討が要ります。無償なのはカーネルで、認証書類は別という切り分けです。

RTOSを載せるとROMとRAMはどれくらい必要になりますか？

カーネル単体なら、Cortex-Mクラスで概ねROMが5〜10KB、RAMが数KBという水準です。ここにタスクごとのスタック（1本あたり数百バイト〜数KB）とキューのバッファが積み上がります。RAMの見積りはスタック合計で決まるため、タスク本数と各スタックサイズを先に置いて足し算するのが確実でしょう。RAMが8KB未満の石では、載せる余地はほぼありません。

RTOSの応答時間はどうやって測ればよいですか？

評価ボードでGPIOをトグルさせ、オシロスコープかロジックアナライザでパルス幅を読む方法が確実です。割り込み発生からハンドラ先頭までを測るなら、外部トリガ信号の立ち上がりとGPIO出力の時間差を見ます。カタログ値は最良条件の測定なので、通信やログ、フラッシュ書き込みを同時に走らせた最悪負荷で数時間記録し、最大値を採用してください。この実測値がないと、余裕率を語れません。

RTOSの選定はプロジェクトのどの段階で決めるべきですか？

基板設計でマイコンを確定させる前です。公式ポートが存在しない石を選ぶと、移植だけで数人月を要します。順序としては、締切要件の数値化 → 認証要否の確定 → RTOS候補の絞り込み → その候補が公式対応するマイコンの選定、という流れが安全です。既に基板が確定しているなら、そのマイコン向けの公式ポートがある製品だけを候補にしてください。

関連記事

• QNXとは？マイクロカーネル型RTOSの構造とSDP 8.0・安全認証から採用判断まで実装者向けに解説：認証が要る車載・医療案件で候補になる商用RTOSの内部構造を扱っています
• エッジAIとは？クラウドAIとの違い・仕組み・実装の判断基準を解説：制御層と推論層を分ける2チップ構成を検討する際の判断材料になります
• TinyGoとは何か？Go言語を組み込み・IoT開発向けに使える小型コンパイラ：C言語以外で組込みファームウェアを書く選択肢の参考になります
• IoTとは？仕組み・身近な例・AIとの組み合わせを簡単にわかりやすく解説：RTOSを載せた機器が接続される上位のシステム像を把握できます