TinyML実践入門【2026年版】｜LiteRT for MicrocontrollersでESP32・Arduinoに機械学習モデルを載せる手順

マイコン上で機械学習の推論を完結させるTinyMLは、クラウドに送らずに音・振動・加速度を判定できるため、通信量・遅延・プライバシーの三つを同時に解決できる手法です。この記事では、2026年時点で現実的な二つの経路——GoogleのLiteRT for Microcontrollers（旧TensorFlow Lite Micro）を直接使う方法と、Edge Impulseで学習からデプロイまでを自動化する方法——を比較したうえで、モデルをCの配列に変換してESP32やArduinoへ書き込むまでの手順を、公式ドキュメントの記載に沿って具体的に解説します。テンソルアリーナの見積もりなど、実機で最初につまずく箇所も最後にまとめます。

TinyMLとは：数十KBのメモリで推論を完結させる技術

TinyMLは、数百KB以下のRAMしか持たないマイコン上でニューラルネットワークの推論を動かす技術の総称です。ポイントは「学習はPC・クラウドで行い、推論だけをマイコンに載せる」という役割分担にあります。学習済みモデルを量子化して小さくし、推論に必要な計算だけを組み込みコードに埋め込むため、常時通電のセンサーノードでも電池で動かせます。

用途として実績が多いのは、キーワード検出（特定の単語だけを聞き分ける）、加速度センサーによる動作分類・異常検知、超低解像度の画像による人物検知などです。Googleの公式ドキュメントも、マイコン向けのサンプルとして「Hello World」「Micro speech（yes／noの検出）」「Person detection（人の有無の検出）」の三つを挙げています。概念の全体像はエッジAI・TinyML完全解説、Cortex-M側の実装事情はArm Cortex-MとエッジAI完全ガイドで整理しています。

2026年の選択肢：LiteRT for Microcontrollers と Edge Impulse

LiteRT for Microcontrollers（旧TensorFlow Lite Micro）

Googleは2024年にTensorFlow LiteをLiteRTへ改称し、マイコン向けの実装はLiteRT for Microcontrollersという名前になりました（GitHubのリポジトリ名は現在も tflite-micro のままです）。公式ドキュメントによると、コアランタイムはArm Cortex-M3上で16KBに収まり、OSのサポート・標準C／C++ライブラリ・動的メモリ確保のいずれも必要としません。C++17で書かれた32ビット向けの実装で、Arm Cortex-Mシリーズで広くテストされているほかESP32へも移植されており、Arduinoライブラリとしても提供されています。

公式に対応ボードとして挙げられているのは、Arduino Nano 33 BLE Sense、SparkFun Edge、STM32F746 Discovery kit、Espressif ESP32-DevKitC、ESP-EYE、Wio Terminal、Sony Spresenseなどです。手に入れやすさで選ぶなら、ESP32-DevKitCかArduino Nano 33 BLE Senseが無難でしょう。

一方で制約もはっきり書かれています。対応する演算子はTensorFlowの一部に限られること、APIが低レベルのC++でメモリを手動管理する必要があること、デバイス上での学習に対応しないことの三点です。Raspberry Piのような組み込みLinux機であれば、通常のLiteRTを使ったほうが統合は容易だとも明記されています。

Edge Impulse（2025年にQualcommが買収を発表）

Edge Impulseは、データ収集・信号処理・学習・最適化・デプロイをブラウザ上で一気通貫に行えるプラットフォームです。Qualcommは2025年3月のEmbedded WorldにあわせてEdge Impulseの買収契約締結を発表し、17万人を超える開発者がエッジ向けAIモデルを作成・展開・監視できる体制を、同社のIoT製品群に統合すると説明しています。ブランドは維持したまま、Dragonwingプロセッサなど産業・組み込み向けSoCへの対応を広げる方針です。

実務上の使い分けはシンプルです。データ収集とラベリングから始める必要があるならEdge Impulse、すでにモデルがあり、フラッシュとRAMを1KB単位で削りたいならLiteRTを直接——という判断でおおむね間違いありません。半導体ベンダーが開発ツール層を取り込む流れが続いているため、将来的にどのシリコンへ載せる可能性があるかも、選定時に意識しておく価値があります。

実装の流れ：学習からマイコン書き込みまでの5ステップ

LiteRT for Microcontrollersの公式ワークフローは、大きく「モデルを作る」「デバイスで推論する」の二段階です。実際の作業に落とすと次の5ステップになります。

ステップ1：小さなモデルを設計・学習する

まず、対象デバイスに載るサイズで、かつ対応演算子だけで構成されたモデルを用意します。全結合層と1次元畳み込みを数層重ねる程度の規模から始めるのが現実的です。センサーの生波形をそのまま入れるより、移動平均・FFT・MFCCなどの特徴量に変換してから入力したほうが、モデルを小さく保てます。

ステップ2：LiteRT形式へ変換し、量子化する

学習済みモデルをコンバータで .tflite 形式へ変換します。このときint8へのポストトレーニング量子化を適用すると、重みが32ビット浮動小数点から8ビット整数になり、単純計算でモデルサイズは約4分の1になります。FPUを持たないCortex-M0+などでは、整数演算になること自体が速度面でも効きます。量子化・枝刈り・蒸留の使い分けは組み込みAIのモデル軽量化入門で詳しく扱っています。

import tensorflow as tf

converter = tf.lite.TFLiteConverter.from_saved_model("saved_model")
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_data_gen  # 校正用データ
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
converter.inference_input_type = tf.int8
converter.inference_output_type = tf.int8
open("model.tflite", "wb").write(converter.convert())

ステップ3：Cのバイト配列に変換する

マイコンにはファイルシステムがないことが多いため、モデルはプログラムメモリ（読み出し専用領域）に配列として埋め込みます。標準的なツールで変換できます。

xxd -i model.tflite > model_data.cc
# 生成された配列に const を付け、ヘッダから extern 宣言する

ステップ4：推論コードを書く

推論側は、モデルの読み込み・演算子の解決・テンソルアリーナの確保・実行という定型処理です。動的メモリ確保を使わない設計なので、アリーナは静的配列として自分で用意します。

constexpr int kArenaSize = 32 * 1024;   // 実測して詰める
alignas(16) static uint8_t tensor_arena[kArenaSize];

const tflite::Model* model = tflite::GetModel(g_model_data);
static tflite::MicroMutableOpResolver<5> resolver;
resolver.AddConv2D();
resolver.AddFullyConnected();
resolver.AddSoftmax();

static tflite::MicroInterpreter interpreter(model, resolver, tensor_arena, kArenaSize);
interpreter.AllocateTensors();

TfLiteTensor* input = interpreter.input(0);
// input->data.int8[i] にセンサー値（量子化スケールを合わせて）を書き込む
interpreter.Invoke();
TfLiteTensor* output = interpreter.output(0);

使う演算子だけを MicroMutableOpResolver に登録するのが定石です。すべての演算子を登録する実装に比べ、フラッシュ使用量を大きく削減できます。

ステップ5：実機で検証する

PC上の推論結果と、マイコン上の推論結果を同じ入力で突き合わせます。量子化の影響で完全一致はしませんが、クラス分類なら判定ラベルは一致するはずです。ずれる場合は、入力の正規化やスケール／ゼロ点の扱いを疑います。

🛠️ TinyMLを試すときの機材（Amazonで探す）

ESP32 開発ボード Arduino Nano 33 BLE Sense 加速度センサー（MPU-6050）I2S MEMSマイク電子工作スターターキット

※型番・在庫は変動します。無線を使う場合は技適マーク付きの正規流通品を選んでください。Amazonアソシエイトの広告を含みます。

メモリ設計：テンソルアリーナはどう見積もるか

実機で最初に詰まるのが AllocateTensors() の失敗です。テンソルアリーナは推論中の中間テンソルを置く領域で、必要量はモデル構造で決まります。事前に正確な計算をするより、大きめ（例：64KB）から始めて、interpreter.arena_used_bytes() の実測値を見て削るのが実務的な手順です。

フラッシュ側の内訳は「ランタイム＋登録した演算子カーネル＋モデル配列」です。モデルを小さくしても演算子を全部登録していれば削減効果は薄いため、両方を同時に見ます。RAMは「テンソルアリーナ＋センサーバッファ＋通信スタック」で、Wi-Fiを併用する構成ではネットワークスタックの消費量が意外に大きい点に注意が必要です。ESP32でセンサー送信まで行う構成はESP32でWi-Fi温湿度モニターを作る実践入門で扱っており、そこに推論を足す形が現実的な出発点になります。

つまずきやすいポイント

非対応の演算子でコンバートが通っても実行時に落ちる：resolverへの登録漏れが典型。エラーメッセージに演算子名が出るので、そのまま追加する。
量子化のスケール／ゼロ点を無視して入力を書き込む：float値をそのままint8にキャストすると精度が崩壊する。入力テンソルの params.scale と params.zero_point を使って変換する。
アリーナのアライメント不足：16バイト境界に揃えないと動作が不安定になる環境がある。alignas(16) を付ける。
学習データと実機データの分布ずれ：センサーの取り付け方向やサンプリング周波数が学習時と異なると、精度は簡単に落ちる。データ収集は必ず実機・実装状態で行う。
デバイス上で再学習しようとする：LiteRT for Microcontrollersはオンデバイス学習に対応しない。適応が必要なら、しきい値の調整やクラウド側での再学習＋OTA更新で設計する。

まとめ：まず16KBの世界を実機で体験する

TinyMLは、理屈よりも「載せてみると何が足りないか」が分かる領域です。ESP32-DevKitCかArduino Nano 33 BLE Senseを1枚用意し、公式のHello Worldとキーワード検出サンプルを動かすところから始めれば、モデルサイズ・アリーナ・演算子登録という三つの制約が体感として理解できます。そこまで進めば、自前のセンサーデータで分類器を作る作業は、ステップ2〜5の繰り返しに落ちます。

よくある質問

TinyMLはどのくらいのメモリがあれば動きますか？

LiteRT for Microcontrollersのコアランタイムは、Arm Cortex-M3上で16KBに収まるとGoogleの公式ドキュメントに記載があります。実際にはこれに加えてモデル本体（int8量子化で数十KB前後の例が多い）と、推論中の中間データを置くテンソルアリーナが必要です。SRAM 520KBのESP32クラスであれば、キーワード検出や加速度センサーの異常検知といった小さなモデルは十分に動きます。

TensorFlow Lite MicroとLiteRTは別物ですか？

同じものです。GoogleはTensorFlow Liteブランドを2024年にLiteRTへ改称し、マイコン向けはLiteRT for Microcontrollersという名称になりました。GitHubのリポジトリはtensorflow/tflite-microのまま運用されているため、検索時は両方の名前で情報を探すのが確実です。

Edge ImpulseとLiteRTはどちらを選ぶべきですか？

データ収集・前処理・学習・デプロイを一気通貫でやりたい場合や、チームで再現性を持たせたい場合はEdge Impulseが向きます。すでに手元にモデルがあり、フットプリントを自分で削り込みたい場合はLiteRT for Microcontrollersを直接使うほうが自由度が高くなります。Edge ImpulseもLiteRT形式で書き出せるため、後から移行することは可能です。