はじめに
「組み込みLinuxの仕組み」シリーズ（Cシリーズ）ではLinuxが動くボードの世界を歩きましたが、組み込みの現場の少なくとも半分は、Linuxを載せない世界――Cortex-MクラスのMCU、ベアメタル、RTOSの世界です。
この短期シリーズ「MCU開発環境の地図」では、その世界の入口を整理します。第1回の今回は最上流の問い、「この装置、Linuxが要るのか？MCUで足りるのか？」 に判断軸を与えます。C-1で予告した線引きの話の、回答編です。
用語を先に整理しておきます。本シリーズでは慣例に従い、MPU＝MMUを持ちLinuxが動くクラスのプロセッサ（Cortex-A等）、MCU＝フラッシュ・RAM内蔵のマイクロコントローラ（Cortex-M、PIC、RL78等）と呼び分けます。境目は厳密にはグラデーションですが、実務では「Linuxがまともに動くか」で分けて概ね困りません。
判断軸1：時間（起動とリアルタイム性)
| 観点 | MCU（ベアメタル/RTOS） | Linux（MPU） |
|---|---|---|
| 起動時間 | ミリ秒〜数十ミリ秒 | 数秒〜数十秒（短縮技術はあるが戦い） |
| 割り込み応答 | マイクロ秒オーダーで確定的 | 標準では非確定（PREEMPT_RT等で改善はする） |
| 制御周期の保証 | しやすい | 苦手分野 |
「電源ONから100ms以内に動作開始」「1ms周期の制御を絶対に外せない」という要件が1つでもあれば、その部分はMCUの領分です。Linuxで頑張る道もありますが、たいていはMCUを1個置く方が安く確実です。
判断軸2：機能（ネットワーク・GUI・資産）
C-1で挙げた「Linuxを選ぶ動機」の裏返しです。
- リッチなネットワーク（TLS、Web管理画面、クラウド連携多数）→ Linux優位。ただし単純なMQTT送信程度ならMCU＋無線モジュール（Bシリーズのホストレス型）で十分
- リッチなGUI（タッチパネル、多言語、動画）→ Linux優位。セグメントLCDや小型キャラクタ表示ならMCUで十分
- ファイル・大容量データ→ Linux優位
- 既存OSS資産・Python等→ Linux優位
「十分」のラインが年々MCU側に動いている（MCUでもTLSやそこそこのGUIが動く時代）ことも、頭に入れておきたい変化です。
判断軸3：電力・コスト・実装
| 観点 | MCU | Linux（MPU） |
|---|---|---|
| 消費電力 | μA〜mAオーダーの世界。電池駆動◎ | 百mA〜Aオーダー。電池は厳しい |
| 部品コスト | 数十円〜数百円＋周辺最小 | SoC＋DDR＋ストレージ＋PMICで千円単位〜 |
| 基板設計 | 2〜4層で完結しやすい | DDR配線等で難度↑（→C-4のSoM論） |
| 開発環境 | 無償IDE＋数千円の書き込み器（D-2） | クロス開発、Yocto等（C-10） |
電池で年単位動かす機器はほぼ自動的にMCUです。逆に商用電源前提でBOMに余裕があれば、この軸はあまり効きません。
判断軸4：更新・保守・セキュリティ
見落とされがちですが、長寿命機器ではここが決め手になることがあります。
- Linux側の負担：カーネル・OSSの脆弱性対応を製品寿命の間ずっと追う体制が要る（C-10の「台帳」の話）。可視性が高くツールも揃う一方、対象が膨大
- MCU側の負担：コード全部が自分の書いた物なので対象は小さいが、TLSスタック等を載せた瞬間に更新義務は同様に発生する
- 人の確保：Linuxエンジニアは比較的採りやすく、特定MCU＋RTOSの熟練者は社内資産に依存しがち――という組織側の事情も、実務では立派な判断材料です
判断の型：「分ける」が正解のことも多い
実際の装置では、二者択一ではなく分担構成が正解になることがよくあります。
リアルタイム制御と安全監視はMCUに、GUIとネットワークはLinuxに。C-9で見たCPU＋FPGA SoCも思想は同じで、「確定的な仕事」をPL（ハード）に置くか、MCUに置くかの違いです。Linux側が再起動しても計測・安全機能が止まらない、という故障分離の利点も大きく、産業機器ではこの構成が本当に多い。
判断フローとしてまとめると次の図です。製品全体を最初からMCUかLinuxの一択にせず、機能ごとに両方の要件を確認するのがポイントです。
両方の領域が必要なら分担構成を第一候補にします。どちらでも成立する場合は、開発・保守体制、数量、BOM、将来拡張まで含めて決めます。
ハマりどころ
- 「せっかくならLinuxで」の過剰装備：LEDと数個のボタンの機器にLinuxを載せると、起動時間・電源断対策・脆弱性対応という「Linux税」を全部払うことになります
- 「MCUで十分」の楽観：後から「クラウド連携も」「画面もう少しリッチに」が来るのが世の常。拡張の見込みは最初に確認する
- RTOSを入れる／入れないの判断：タスクが2〜3個ならベアメタル＋割り込みで足ります。通信スタックや複数の非同期処理が絡み出したらRTOS（FreeRTOS/Zephyr等）の出番
- 分担構成の通信プロトコル設計を後回しにする：MCU-Linux間のフレーム設計・エラー処理・FW更新経路は、両チームの境界仕事として最初に決める（C-9コラムの「境界人材」問題と同型です）
現場コラム：「その要件、本当に要件ですか」
選定会議で「起動は一瞬がいい」「画面はリッチに」「電池でも動くと嬉しい」と全部盛りの要望が出ることがあります。全部叶えると分担構成＋大容量電池のフルコースになり、コストが跳ねます。
効くのは、要望を 「must（製品が成立しない）」と「want（あると嬉しい）」に仕分けし直す ことです。「起動一瞬」がmustなのは安全装置の話であって、設定用GUIの起動が10秒かかっても実は誰も困らない――そんな整理が済むと、アーキテクチャは驚くほど素直に決まります。技術選定の半分は、要件の解像度を上げる仕事だと思っています。
まとめと次回
- 判断軸は「時間（起動・リアルタイム）」「機能（GUI・ネット）」「電力・コスト」「保守体制」の4つ
- 相反する要件が同居するなら、MCU＋Linuxの分担構成が第一候補
- 過剰装備のLinux税にも、楽観のMCU選定にも罠がある
次回D-2は、MCU側に決めた後の実務、STM32・NXP・PIC・ルネサスの公式IDEと書き込み器の早見表です。「どのメーカーを選んだら、何を買って、何をインストールすることになるのか」を一望します。