RTOS（リアルタイムOS）は、機器の複数の処理に優先度をつけ、決めた時間内に応答できるよう実行の順番を管理する基本ソフトです。機器に組み込まれたマイコン（小さなコンピューター）の上で、処理の段取り役を務めます。
OSを載せずにプログラムを直接動かす「ベアメタル」でも、製品はつくれます。
小規模な機器の多くはいまもこの方式です。ただ、処理の数が増え、応答までの時間の条件が厳しくなるほど、実行の順番を自前で組むよりRTOSに任せるほうが割に合うようになります。
この記事では、ベアメタルとの違いを先に整理したうえで、RTOSの仕組みと使うべきかを判断する基準を説明します。続いて、導入後に増える落とし穴、組込みLinuxとの線引き、主なRTOSの選び方の順にまとめます。
RTOSとは｜ベアメタルとの違いを先に整理
RTOSは、複数の処理（タスク）に優先度をつけ、決めた時間内に応答できるよう実行順を管理するOSです。パソコンのOSのように画面やファイル操作を提供するものではなく、中心にあるのは「次にどの処理を動かすか」を決めるカーネルです。
ここでいうリアルタイムは、処理が速いという意味ではありません。期限までに応答が終わることを、設計の段階で見通せるという意味です。平均では速くても、たまに大きく遅れる仕組みはリアルタイムとは呼びません。
期限の厳しさには2段階あります。FreeRTOSの公式解説では、期限を破るとシステムとして失敗になるものをハードリアルタイム、破っても使えなくなるわけではないものをソフトリアルタイムと説明しています。
前者の例がエアバッグの展開、後者の例がキー入力への応答です。
一方のベアメタルは、OSを載せずにマイコンの上で直接プログラムを動かす方式です。組込みエンジニアの仕事では、小規模な機器の多くがいまもこの方式でつくられています。両者の違いを先に表で見ておきます。
どちらが上ということはなく、処理の数とタイミング要求で向き不向きが分かれます。
※ベアメタルでも割り込みを使えば速い応答は実現できます。差が出るのは、処理が増えたときの見通しのよさです。
使うべきかの答えを先に言えば、処理が少なく単純な機器ならRTOSは要りません。
FreeRTOSの公式解説も、単純なシステムではカーネルなしの手法が最適な場合があり、どこが分かれ目かは主観的だと書いています。以降の章は、その分かれ目を自分の案件で見極めるための材料です。
ベアメタル（スーパーループ）の構造と限界
ベアメタルの典型は、スーパーループと呼ばれる構造です。初期化のあと無限ループに入り、入力の読み取り、演算、出力、通信といった処理を順番に呼び出します。急ぎの事象は割り込みで受け、フラグを立ててループ側に知らせます。
ループは上から順に処理を回し、割り込みは「起きたこと」だけを記録します。
※割り込みの中で長い処理をすると、ほかの割り込みやループが待たされます。割り込みは短く、が基本です。
この構造の利点は軽さと見通しのよさです。処理は書いた順にしか動かないため、同時に動く処理どうしの競合は割り込みとの間だけ考えれば済みます。回路設計の担当者がファームウェアも書くような小さな案件では、いまも合理的な選択です。
入力を読み、プログラムを上から実行し、出力を更新して先頭に戻る。この繰り返しは、PLCのスキャン方式と考え方が同じです。1周の時間がそのまま応答の遅れになる点も共通しています。
処理が増えると表に出る3つの限界
1つ目は、最悪の応答時間がループ1周の長さに引きずられることです。フラグが立っても、ループがその処理の番に来るまでは実行されません。途中に時間のかかる処理が1つあれば、全体が遅れます。
2つ目は、機能を足すたびに既存の処理のタイミングが変わることです。通信機能を追加したら制御の周期が乱れた、という不具合はこの構造から生まれます。変更のたびに全体のタイミングを測り直す手間が増えていきます。
3つ目は、待ちを含む処理の書きにくさです。応答待ちや書き込み完了待ちでループを止めるわけにいかないため、処理を細かい状態に分けて、呼ばれるたびに少しずつ進める書き方になります。状態の数が増えると、読む人が流れを追いにくくなります。
RTOSが提供する4つの仕組み
RTOSは、上の3つの限界をカーネルの機能で肩代わりします。製品ごとに名前や細部は違いますが、骨格になる仕組みは共通です。
ベアメタルで自作していた段取りを、カーネルが共通の部品として提供します。
タスクと優先度つきのスケジューリング
RTOSでは、制御、通信、表示といった処理を別々のタスクとして書きます。タスクはそれぞれ専用のスタックを持ち、自分だけが動いているかのように、上から下へ素直に書けます。待ちが必要なら、その場で待つと書くだけです。
どのタスクを動かすかはスケジューラが決めます。多くのRTOSが採るのは、実行できるタスクのうち最も優先度の高いものを常に動かす方式です。
優先度の高いタスクが実行可能になると、動作中のタスクを中断して切り替えます。これをプリエンプションと呼びます。
優先度の高いタスクが実行可能になると、低いタスクは中断され、あとで続きから再開します。
※表示の更新は遅れますが、制御は周期どおりに動きます。遅れてよい処理に遅れを寄せるのが優先度設計の考え方です。
優先度が高いタスクほど、ほかの処理の都合に左右されません。ベアメタルではループ全体で決まっていた応答時間を、処理ごとに切り分けて考えられるようになります。
ただし、高優先度のタスクが待ち状態に入らないと、低優先度のタスクはいつまでも動けません。
タスク間の同期と通信
タスクが分かれると、タスクどうしで待ち合わせやデータの受け渡しが必要になります。そのための部品が、セマフォ（事象の通知や資源の数の管理）、ミューテックス（共有資源の排他）、キュー（データの受け渡し）です。
たとえば受信タスクは、キューにデータが届くまで待つと書きます。待っている間はCPUを使わず、届いた瞬間に起こされます。事象が起きたかどうかを周期的に見に行く必要がなくなるのが、ベアメタルとの大きな違いです。
時間管理とティック
多くのRTOSは、ティックと呼ばれる周期割り込みで時間を数えます。FreeRTOSの場合、ティックの周波数を100Hzに設定すると、時間の刻みは10ミリ秒です。一定時間の待ちや周期起動は、この刻みを単位に指定します。
ティックは便利な反面、何もすることがなくても周期的にCPUを起こします。電池駆動の機器では、次に用事がある時刻までティックを止めて眠るティックレスの仕組みが使われます。
FreeRTOSは省電力向けのオプションとして、TOPPERS/ASP3カーネルは時間管理の方式として備えています。
割り込み処理をタスクへ渡す
RTOSを使っても、ハードウェアからの事象を最初に受けるのは割り込みです。違いは、割り込みの中ではセマフォやキューで通知するだけにとどめ、重い処理を優先度のついたタスクへ渡せる点にあります。
割り込みを短く保ちやすくなり、処理の優先順位も一元的に整理できます。
RTOSを使うべきか判断する6つの基準
ここからが本題です。RTOSを入れるかどうかは、マイコンの性能ではなく、載せるソフトウェアの性質で決まります。次の6つを順に確認すると、判断の根拠を言葉にしやすくなります。
当てはまる項目が多いほど、RTOSを入れる利点が導入の手間を上回ります。
※05だけは向きが逆で、余裕がなければベアメタルを選ぶ理由になります。
1. 期限の異なる処理が同居しているか
最も重要な基準です。1ミリ秒周期の制御、数十ミリ秒かかることもある通信、100ミリ秒ごとの表示更新が1つのマイコンに載る場合を考えます。このときは、遅くてよい処理が速い処理の邪魔をしない仕組みが必要になります。
逆に、処理がすべて同じ周期で回り、1周の時間に十分な余裕があるなら、スーパーループで足ります。タイマ割り込みで周期をつくり、その中で順番に処理を呼ぶ構成は、動きを説明しやすいという強みがあります。
2. 通信スタックやミドルウェアを載せるか
TCP/IP、Bluetooth、USB、ファイルシステムといったミドルウェアは、内部で待ちやタイムアウトを多用します。
RTOSのタスクや同期の仕組みを前提に書かれたものも多く、マイコンメーカーが配布するサンプルにも、RTOS込みのものがあります。
ネットワークにつながる機器では、この基準だけでRTOSの採用が決まることも少なくありません。ベアメタルで動かせるスタックもありますが、周期的に処理関数を呼ぶ責任が自分の側に残ります。
3. 低消費電力で待機する必要があるか
FreeRTOSをはじめ多くのRTOSでは、動かすタスクがないときにアイドルタスクが実行されます。ここでマイコンを低消費電力モードに入れる構成が定番です。処理が事象駆動で書かれているため、用事のない時間をまとめて眠りに充てられます。
ベアメタルでも省電力設計はできますが、ループのどこで眠ってよいかを自分で管理する必要があります。処理が増えるほど、眠ってよい条件の判定が複雑になります。
4. 複数人・複数機種で開発するか
タスクは、役割とインターフェースのはっきりした単位です。担当者ごとにタスクを分ければ、互いのタイミングを細かく知らなくても開発を進められます。
FreeRTOSの公式解説も、モジュール性、チーム開発、テストのしやすさ、コードの再利用を利点に挙げています。
機種展開が多い製品では、RTOSのAPIがマイコンの違いを吸収する層としても働きます。要求分析から量産までの組込み開発の各工程を複数人で回す体制なら、この利点は大きくなります。
5. メモリに余裕があるか
RTOSはカーネル本体のROMに加え、タスクごとにスタックのRAMを使います。タスクを10個つくれば、スタックも10個分です。RAMが数キロバイトしかない小型マイコンでは、この負担が導入の壁になります。
目安として、AWSはFreeRTOSのライブラリ一式に必要なRAMを挙げています。マイコン上で動かす場合は64KB超、通信や暗号の処理を別チップに任せる場合は16KBです。
これはTLSなどクラウド接続用のライブラリを含めた数字です。
カーネルだけならずっと小さく、FreeRTOSの公式FAQはARM7向けの最小構成での例を示しています。カーネルのROMが約5〜10KB、RAMがスケジューラ本体で236バイト、タスク1つにつき64バイトとスタックの分です。
実際の使用量は、試作段階でスタックの消費を測って決めます。
6. 安全規格への対応が必要か
自動車、産業機械、医療機器などで安全規格への適合が求められる場合、OSも評価の対象になります。認証を取得済みのRTOSを使えば、OS部分の説明に認証の証拠資料を活用できます。一方で、適用条件を守って使う義務と、ライセンス費用が発生します。
安全に関わる部分をあえて単純なベアメタルで組み、説明しやすくするという判断もあります。どちらが有利かは、求められる安全度水準と、ソフトウェアの規模によって変わります。
想定例で考える
想定例として、小型モータを回しながら上位機器と通信し、状態を液晶に表示する装置を考えます。制御は1ミリ秒周期、通信は不定期で1回の処理が長め、表示は100ミリ秒ごとで足りるとします。
スーパーループでは、通信処理が長引いたときに制御の周期が乱れないよう、通信を細かい状態に分ける工夫が必要です。
RTOSなら、制御を高優先度、通信を中、表示を低に割り当てるだけで、図4のような動きになります。基準の1と2に当てはまる時点で、RTOSを検討する価値があります。
同じ装置でも、通信がなく、制御と表示だけなら話は変わります。タイマ割り込みで制御を回し、ループで表示を更新する構成で十分です。
RTOSを入れると増える落とし穴
RTOSは、タイミングの問題を消してくれるわけではありません。ベアメタルにはなかった種類の不具合が新しく入ってきます。導入を判断するときは、利点と同じ重さで見ておく必要があります。
どれもタイミングに依存して起きるため、再現しにくいのが共通点です。
優先度逆転と優先度継承
RTOSに特有の不具合として知られるのが優先度逆転です。低優先度のタスクがミューテックスを持っている間、同じ資源を使いたい高優先度のタスクは待たされます。
そこへ中優先度のタスクが動き出すと、低優先度タスクが進めず、高優先度タスクの待ち時間が際限なく延びることがあります。
対策が優先度継承です。ミューテックスを持つタスクの優先度を、待っているタスクの優先度まで一時的に引き上げます。
ただしFreeRTOSの公式解説は、これは逆転を解消するのではなく時間を抑えるだけで、頼りきるのは良い習慣ではないと明記しています。資源の共有そのものを減らす設計が先です。
スタックとヒープの管理
タスクごとのスタックは、小さすぎるとあふれ、大きすぎるとRAMを無駄にします。あふれたときの症状は、無関係な変数が書き換わる、まれに暴走するといった形で現れ、原因にたどり着きにくいのが厄介です。
動的なメモリ確保にも注意が必要です。一般的な確保・解放の処理は、かかる時間が一定でなく、断片化の恐れもあります。
FreeRTOSは、タスクやキューを静的に確保する方法を用意しており、実行時の確保失敗への対処が不要になり、断片化のリスクもなくなるとしています。
長時間動き続ける機器では、静的確保か、起動時の一括確保が無難です。
デバッグの難しさが変わる
ベアメタルの不具合は、ブレークポイントで止めて順に追えば見つかることが多いものです。RTOSでは、止めた瞬間にタイミングが変わり、症状が消えることがあります。
そのため、タスクの切り替わりを記録して時系列で見るトレースツールや、RTOSの状態を表示できるデバッガが実務では重宝されます。RTOSを選ぶときは、カーネルの機能だけでなく、こうした道具がそろっているかも確認しておくと後で助かります。
組込みLinuxとの線引き
RTOSを検討していると、いっそ組込みLinuxにすべきかという議論も出てきます。両者は置き換えの関係ではなく、対象とするハードウェアと得意分野が異なります。
時間の厳しさを取るか、機能の豊富さを取るかで分かれます。
※メモリ量と起動時間は構成によって大きく変わるため、目安としてご覧ください。
Linuxのリアルタイム性は年々改善しています。
応答の遅れを小さくするPREEMPT_RTという仕組みは、長く別配布のパッチでしたが、2024年11月公開のLinux 6.12で本体に取り込まれました。
それでも、マイクロ秒単位の周期制御や、安全に関わる処理はRTOSやベアメタルに任せる設計が一般的です。
1つのチップに性能の高いコアとマイコン向けのコアを両方載せた製品もあります。
たとえばSTマイクロエレクトロニクスのSTM32MP1は、Cortex-A7でLinuxを、Cortex-M4でRTOSを動かす使い方を想定しています。
前者に画面や通信を、後者に制御を担当させる構成です。どちらか一方を選ぶのではなく、役割で分けるという考え方もあります。
主なRTOSと選び方
RTOSは数が多く、提供元やライセンスが変わった製品もあります。ここでは組込み開発でよく名前の挙がるものを、2026年9月時点で各公式サイトに記載されている内容をもとに整理します。
提供元とライセンスは、採用前に必ず公式サイトで最新の内容を確認します。
※2026年9月時点で各公式サイトに記載の内容です。
オープンソースのRTOS
FreeRTOSは、マイコンメーカーの開発環境に組み込まれていることが多く、最初に触れる機会の多いRTOSです。現在はAWSが管理しており、ライセンスはMITです。AWSの利用者でなくても、商用製品に無償で使えます。
Zephyrは、カーネルだけでなくドライバ、通信スタック、ビルドの仕組みまでを一体で提供します。ライセンスはApache 2.0で、公式サイトでは対応ボードが1,000種を超えるとしています。
機能安全の認証はIEC 61508のSIL 3を目標に活動中で、取得済みではありません。
Eclipse ThreadXは、かつてAzure RTOSと呼ばれていた製品です。
2023年11月にMicrosoftがEclipse Foundationへの寄贈を発表し、現在はMITライセンスのオープンソースとして公開されています。
安全規格の認証は6.1系がSGS-TÜV Saarから取得しており、移管後の6.4系は認証予定とされています。認証関連の文書は、ThreadX Allianceの会員向けに有償で提供されます。
国内発のTRON系
国内の組込み開発では、ITRON仕様のAPIが長く使われてきました。その流れをくむオープンソースがTOPPERSプロジェクトのカーネル群です。
TOPPERSライセンスは、機器に組み込んで出荷する場合、利用をプロジェクトへ報告すれば足りるという条件が特徴です。車載向けには、AUTOSARのOS仕様をベースにしたATK2も公開されています。
トロンフォーラムが開発するT-KernelとμT-Kernelも、ITRONの技術を受け継ぐRTOSです。T-Licenseのもとで無償で商用利用できますが、製品に組み込む場合はマニュアルなどへの表示が求められます。
トロンフォーラムは2025年6月、2024年度の調査結果を公表しました。組込みシステムに組み込んだOSのAPIとして、T-Kernel仕様とITRON仕様の合計が約60％を占めました。
ただし、国内展示会の来場者などを対象にしたアンケートで、有効回答は99人です。OSを使っていない回答を除いた複数回答の集計でもあります。
世界全体のシェアではなく、国内の傾向を示す参考値として読むのが適切です。
商用のRTOS
Wind RiverのVxWorksや、QNXは、航空宇宙、車載、医療、産業機器で使われる商用RTOSです。
たとえばQNX OS for Safety 8.0は、TÜV Rheinlandの認証を受けたと公表しています。対象は、ISO 26262のASIL D、IEC 61508のSIL 3、IEC 62304のClass Cです。
FreeRTOSと同じ機能モデルを持つ安全向け製品として、WITTENSTEIN high integrity systemsのSAFERTOSもあります。
IEC 61508-3のSIL 3とISO 26262のASIL Dについて、TÜV SÜDによる事前認証付きで提供されています。FreeRTOSからの移行がしやすい点を特徴にしています。
選ぶときに見る5つの点
RTOSの基本機能は、どれを選んでも大きくは変わりません。差が出るのは周辺です。実務では、次の5点で候補を絞ることが多くなります。
- 使うマイコンのメーカーが、開発環境やサンプルで公式に対応しているか
- ライセンスの条件（表示や報告の義務、改変部分の扱い）が自社の製品に合うか
- 安全規格の認証が必要か。必要なら、対象のバージョンと適用条件は何か
- 必要な通信スタックやファイルシステムが、そのRTOS向けにそろっているか
- 製品寿命に見合うサポート期間があるか。社内に経験者がいるか
見落とされやすいのは最後の点です。産業機器は長期間にわたって使われることが多く、その間の不具合修正を誰が担うかを決めておく必要があります。
オープンソースは無償で使える一方、保守の責任は自社に残ります。RTOSの経験は組込みエンジニアのスキルとしても評価されやすく、社内に知見をためる価値は小さくありません。
まとめ
- RTOSは、複数の処理を優先度に従って期限どおりに動かすための段取り役
- 処理が少なく周期がそろっている機器は、ベアメタルのスーパーループで足りる
- 期限の異なる処理の同居、通信スタックの搭載、複数人での開発が、導入を考える主な目安
- 優先度逆転、デッドロック、スタックあふれなど、タイミング依存の不具合が新たに増える
- 製品選びは、マイコンの対応、ライセンス、認証、ミドルウェア、サポート期間で絞る
RTOSを入れるかどうかは、流行ではなく、載せる処理の性質で決めるものです。迷ったときは、図5の6項目に自分の案件を当てはめてみてください。関連する職種はソフトウェア・組込みと電気・電子設計のページにまとめています。
RTOSが使われる製品分野については、自動車・輸送機器やFA・自動化システムの業種ページから関連記事もあわせてご覧ください。
出典
出典・参考資料（13件）を開く出典・参考資料を閉じる
- RTOSの基本概念、ハード／ソフトリアルタイム、RTOSを使う理由、ティック、優先度逆転と優先度継承、メモリ確保：FreeRTOS「Mastering the FreeRTOS Real Time Kernel」（FreeRTOS Kernel Book）
- FreeRTOSのライセンス、対応アーキテクチャ数、必要メモリの目安：AWS「FreeRTOS FAQs」、カーネル単体のROM・RAM：FreeRTOS「FAQ – Memory Usage, Boot Times & Context Switch Times」
- Zephyrのライセンスと機能：Zephyr Project Documentation「Introduction」、対応ボード数：Zephyr Project 公式サイト
- Zephyrの機能安全認証の状況：Zephyr Project Documentation「Zephyr Safety Overview」
- Eclipse ThreadXの認証の状況：ThreadX Alliance「Safety Certifications」、ライセンス：Eclipse ThreadX（GitHub）
- Eclipse Foundationへの移管の経緯：Eclipse Foundation Blog「Eclipse ThreadX: Charting our course for 2025」
- TOPPERSのカーネルとライセンス：TOPPERSプロジェクト「TOPPERS/ASP3カーネル」、「TOPPERSライセンス」、「TOPPERS/ATK2」
- T-KernelとT-License：トロンフォーラム「T-Kernelとは」
- RTOSの利用動向調査：トロンフォーラム プレスリリース（2025年6月3日）「2024年度組込みシステムにおけるリアルタイムOSの利用動向に関するアンケート調査報告書」
- VxWorks：Wind River「VxWorks」、QNX：QNX「QNX OS and QNX OS for Safety」
- SAFERTOS：WITTENSTEIN high integrity systems「SAFERTOS」
- Linux 6.12でのPREEMPT_RTの統合：Linux Kernel Newbies「Linux 6.12」
- LinuxとRTOSを1チップで動かす構成の例：STMicroelectronics「The ST Blog」（STM32MP1の紹介記事）
NEWSLETTER
選んだ職種・業種に合わせた記事を、週1回メールで
週刊MONOSCOPEは、登録時に選んだ職種・業種に合わせた記事を週1回お届けする無料のメルマガです。
職種・業種を選んで登録へ ›
無料・週1回。登録後に届く確認メールのリンクを押すと登録が完了します。配信はメール内のリンクからいつでも停止できます。
WEEKLY NEWS
今週の製造業ニュース10選
メルマガは職種・業種に合わせた記事。LINEとnoteでは、全員共通の10本を毎週土曜の朝にお届けします。
LINEでニュース10選を受け取るnote今週のニュース10選をnoteで読む ›
コメント