はじめに

「組み込み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と書き込み器の早見表です。「どのメーカーを選んだら、何を買って、何をインストールすることになるのか」を一望します。