なぜ今、「マイコンで動くAI」が必要なのか？
「現場に設置したセンサーの電池が、想定よりも早く切れてしまった」
IoTプロジェクトに関わるエンジニアの方なら、一度はこんな苦い経験があるのではないでしょうか。特に画像データや高周期のセンサーデータを扱うシステムの場合、データ量が膨大になるため、クラウドへ常時送信しようとすれば通信モジュールの消費電力だけでバッテリーは瞬く間に枯渇します。
AIエンジニアとしてエッジコンピューティングの設計に向き合う中で、私が常に意識しているのは「精度」以上に「持続時間」の重要性です。山間部の送電線監視や、電源確保が難しい工場の旧式ラインなど、頻繁な電池交換や配線工事が不可能な場所こそ、センサーデータ解析とAIによる自動化が求められているからです。
ここで救世主となるのがTinyML（Tiny Machine Learning）です。一言で言えば、「クラウドではなく、手のひらサイズのマイコン上でAIを動かす技術」のこと。数mW（ミリワット）という極小の電力で動作するマイコン上で推論を行うことで、通信頻度を劇的に減らし、バッテリー寿命を数ヶ月から数年単位まで延ばすことが可能になります。
本記事では、このTinyMLを用いて「超省電力な物体検知」を実現するために、現場のエンジニアが押さえておくべき技術用語と概念を解説していきます。単なる用語集ではありません。「なぜその技術が省電力化に効くのか」という視点で、データの流れに沿って紐解いていきましょう。
クラウド依存からの脱却と「通信コスト」の壁
従来のIoTシステムは、センサーデータをすべてクラウドに送り、強力なサーバーで解析する「クラウド集中型」が主流でした。しかし、画像データのようなリッチな情報をLTEやWi-Fiで送信する場合、その消費電力は膨大です。
データ分析の観点からも、すべてのデータをクラウドに送ることは非効率です。例えば、一般的なWi-Fiモジュールで画像を1枚送信するのに必要な電力は、マイコンが数百万回の演算を行う電力に匹敵することもあります。つまり、「通信」こそがバッテリーを食いつぶす最大の要因なのです。
TinyMLのアプローチは逆転の発想です。「データを送る」のではなく、「現場で判断結果（推論結果）だけを送る」。
- 従来：画像データ（数MB）を送信 → クラウドで「異常なし」と判定
- TinyML：マイコンで画像解析 → 「異常なし」なら何も送らない（0バイト）
この差が、バッテリー寿命に決定的な違いをもたらします。通信コスト（回線費用）の削減というビジネスメリットも無視できません。
バッテリー駆動デバイスにおける消費電力の現実
エッジコンピューティングのデバイスを設計する際、私たちは常に「パワーバジェット（電力予算）」という厳しい制約に向き合うことになります。単三電池2本で動くデバイスが使えるエネルギーは限られています。
例えば、Raspberry Piのようなシングルボードコンピュータ（Linux搭載）は、高機能ですがアイドル時でも数百mAを消費します。これを電池で動かし続けるのは至難の業です。一方、TinyMLがターゲットとするマイコン（MCU）は、スリープ時なら数μA（マイクロアンペア）、動作時でも数十mA程度で済みます。
「高性能なAIを動かしたい」という欲求と、「電気を使いたくない」という制約。このトレードオフを解消するために、モデルを極限まで小さくし、ハードウェアの能力を使い切る技術がTinyMLなのです。
TinyMLシステムの全体像を理解する基本用語
まずは、TinyMLの世界観を正しく掴むための基本用語を整理しましょう。特に「学習」と「推論」の場所の違いを理解することが、システム設計の第一歩です。
TinyML（Tiny Machine Learning）
TinyMLとは、mW（ミリワット）以下の電力で動作するハードウェア上で、機械学習モデルを実行する技術領域を指します。具体的には、メモリが数百KB（キロバイト）しかないようなマイクロコントローラ（MCU）で、センサーデータ解析や音声認識、簡易的な画像認識を行うことを目指します。
「エッジAI」という言葉もよく聞きますが、TinyMLはその中でも「最もリソースが制約された環境」に特化しています。NVIDIA JetsonのようなGPU搭載のエッジデバイス（数W〜数十Wクラス）とは、戦う土俵が違うと考えてください。TinyMLは、ボタン電池や環境発電（エナジーハーベスト）での動作さえ視野に入れています。
エッジコンピューティング vs エッジAI
- エッジコンピューティング: データをクラウドではなく、現場に近い場所（エッジ）で処理する「概念」そのもの。
- エッジAI: エッジコンピューティングの中で、特にAI（機械学習）アルゴリズムを実行すること。
TinyMLはエッジAIの一種ですが、より極端な省電力・省リソース環境を指します。AIモデルの実装において、私は「これは一般的なエッジAIか、それともTinyMLか」という線引きを明確にすることをおすすめしています。これにより、想定するハードウェアのスペック（Linuxが動くMPUか、動かないMCUか）をプロジェクト全体で正確に共有できるからです。
推論（Inference）と学習（Training）の分離
AIモデルの実装において、初心者が最も混乱しやすいポイントがここです。TinyMLでは、マイコン上でAIが「学習」して賢くなるわけではありません。
- 学習（Training）: 大量のデータを使ってAIモデルを作る工程。これには高性能なGPUを持つPCやクラウドが必要です。
- 推論（Inference）: 作られたモデルを使って、未知のデータを判定する工程。これは計算量が比較的少ないため、マイコンでも実行可能です。
TinyMLの開発フローは、「PCで学習し、完成したモデルを圧縮してマイコンに書き込む」という流れになります。つまり、マイコンが行うのは「推論のみ」です。
「現場で学習させたい（オンデバイス学習）」というニーズもありますが、現在のTinyML技術では、リソースの制約上、非常に限定的な再学習（転移学習の一部など）に限られます。まずは「学習はクラウド、推論はエッジ」という役割分担を明確にイメージしてください。
「モデルを小さくする」ための技術用語
マイコンのメモリ（RAM/Flash）は非常に限られています。例えば、Arduino Nano 33 BLE Senseのような人気のボードでも、RAMは256KB、Flashは1MB程度です。一般的なPC向けのAIモデルは数百MBあることも珍しくないため、そのままでは到底入りません。
そこで必要になるのが、モデルを「小さく、軽く」する技術です。これこそがAIモデルの実装を担うエンジニアの腕の見せ所であり、省電力化の核心部分だと私は考えています。
量子化（Quantization）：精度を保ちつつサイズを1/4にする魔法
省電力化において最も効果的で、かつ頻繁に使われる技術が「量子化」です。
通常、AIモデルのパラメータ（重み）は「32ビット浮動小数点（float32）」で表現されています。これを「8ビット整数（int8）」に変換して表現し直す技術が量子化です。
- データサイズ: 32ビット → 8ビットになるため、モデルサイズは単純計算で1/4になります。
- 省電力効果: データ量が減ると、メモリからプロセッサへのデータ転送量が減ります。実はプロセッサが計算する電力よりも、メモリへのアクセスにかかる電力の方が支配的な場合が多く、転送量の削減は直接的に消費電力削減に繋がります。また、多くのMCUは浮動小数点演算よりも整数演算の方が高速かつ低消費電力で処理できます。
「精度が落ちるのでは？」と心配されるかもしれませんが、データ分析とモデル最適化の適切な手法（量子化意識トレーニングなど）を用いれば、精度低下を1%未満に抑えることも可能です。AIエンジニアの視点から言えば、TinyMLにおいてint8量子化は「ほぼ必須」の処理です。
プルーニング（Pruning）：不要な結合の枝刈り
ニューラルネットワークの中には、判定にほとんど寄与していない「無駄なパラメータ」が存在します。これらを特定し、削除（値を0にする）してしまう技術がプルーニング（枝刈り）です。
庭木の剪定と同じで、不要な枝を落とすことでモデル全体をスリム化します。これにより計算量が減り、推論速度が向上し、結果として消費電力が下がります。ただし、ハードウェアによっては「0」の計算をスキップできず、思ったほど高速化しない場合もあるため、ターゲットとするマイコンの特性に合わせたAIモデルの実装が求められます。
モデルアーキテクチャ（MobileNet, EfficientDet-Lite）
ゼロからモデルを設計するのではなく、最初からモバイルやエッジ向けに設計された軽量なモデル構造（アーキテクチャ）を採用するのが定石です。
- MobileNet: 画像認識向け。精度と速度のバランスが良いデファクトスタンダード。
- EfficientDet-Lite: 物体検知向け。パラメータ数が少なく、マイコンでも動作させやすい。
- FOMO (Faster Objects, More Objects): Edge Impulseなどが提唱する、さらに軽量な物体検知手法。位置特定のみを行い、ボックスのサイズ推定などを簡略化することで、極小マイコンでも高速に動作します。
「YOLOv8を使いたい」という要望は多いですが、標準的なYOLOはマイコンには重すぎることが一般的です。エッジコンピューティング環境で動かすなら、YOLOの極小版か、上記のようなTinyML専用のアーキテクチャを選択するよう私は推奨しています。
「省電力に動かす」ためのハードウェア・実装用語
ソフトウェア（モデル）の準備ができたら、それを動かすハードウェアとフレームワークの選定です。スペック表を見る際、どこに注目すべきかを解説します。
MCU（Micro Controller Unit）とMPUの違い
ここの選定を誤ると、プロジェクトの進行に大きな支障をきたす可能性があります。AIエンジニアとして、ハードウェアの特性理解は不可欠だと強調しておきます。
- MCU（マイコン）: メモリ統合型、OSなし（またはRTOS）、数MHz〜数百MHz駆動。消費電力はmWオーダー。スリープからの復帰が高速。TinyMLの主戦場。
- MPU（マイクロプロセッサ）: メモリ外付け、Linuxなどが動作、GHz駆動。消費電力はWオーダー。Raspberry Piなどはこっち。
省電力化を最優先するなら、Linuxが動くMPUではなく、MCUを選ぶべきです。OSのオーバーヘッドがなく、自分で電力管理を完全にコントロールできるからです。
DSP（Digital Signal Processor）とNPU（Neural Processing Unit）
最近のマイコンには、汎用的なCPUコア（Arm Cortex-M4など）に加えて、特定の計算を高速化するアクセラレータが搭載されているものがあります。
- DSP: デジタル信号処理に特化。音声処理やセンサー波形処理に強い。
- NPU: ニューラルネットワークの積和演算に特化。AI推論を爆速かつ低消費電力で処理する。
NPUという用語は、昨今ではPCやスマートフォン向けのプロセッサでも標準的な機能となりました。IntelのCore UltraシリーズやAMDのRyzen AI搭載モデルなど、最新のプロセッサではNPU性能が大幅に強化され、最大50〜60TOPS（Trillions of Operations Per Second）といった高い処理能力を実現しています。しかし、これらは主にOS上で動作する生成AIや高度な画像処理を想定したものです。
TinyMLの主戦場であるマイコン（MCU）領域におけるNPU（Arm Ethos-Uなど）の役割は、絶対的な演算性能よりも「電力効率」にあります。CPUだけで計算するよりも数十倍の効率で推論を行い、「同じ処理を短時間で終わらせて、すぐにスリープする」ことでバッテリー寿命を延ばすのが狙いです。スペック表を見る際は、PC向けのTOPS値と比較するのではなく、マイコンとしての消費電力あたりの推論性能に注目してください。エッジコンピューティングにおける省電力化の鉄則として、NPU搭載マイコンの選定は非常に有効な選択肢だと私は捉えています。
TensorFlow Lite for Microcontrollers (TFLM)
Googleが開発したTensorFlowの「マイコン版」です。PCで作ったTensorFlowモデルを、数KBのメモリしかないマイコンで動かせるC++ライブラリに変換します。
OSがなくても動作し、動的メモリ割り当て（malloc）を使わない設計になっているため、メモリリークのリスクがなく、組み込みシステムの厳しい制約に適しています。TinyML開発における事実上の標準フレームワークの一つです。
現場で失敗しないための運用・評価用語
モデルが動き出しても、それで終わりではありません。実際のフィールドで「電池を持たせる」ためには、運用設計が重要になります。
推論レイテンシとスループット
- レイテンシ: 1回の推論にかかる時間（例：100ms）。
- スループット: 単位時間あたりに処理できる回数（例：10FPS）。
省電力の観点では、レイテンシが短いことが重要です。処理時間が短ければ短いほど、CPUがアクティブな時間を減らし、スリープ時間を長く確保できるからです。「リアルタイム性は不要だからゆっくり処理すればいい」というのは誤解です。センサーデータ解析の効率化という観点からも、「速く処理して、すぐに寝る」のが正解です。
偽陽性（False Positive）と偽陰性（False Negative）の電力リスク
精度の指標ですが、電力消費に直結します。
- 偽陽性（誤検知）: 何もないのに「異常あり」と判定してしまうこと。→ 無駄な通信が発生し、電力を浪費する。
- 偽陰性（見逃し）: 異常があるのに気づかないこと。→ 重大な事故につながるリスク。
省電力化の観点では、特に「偽陽性」を抑えるデータ分析とチューニングが重要です。風で揺れる木を「侵入者」と誤検知して毎回画像を送信していたら、電池は数日でなくなります。
ウェイクワード / トリガー検知
最も重要な運用テクニックです。消費電力の大きい画像認識AIを、常に動かし続ける必要はありません。
- Stage 1: 超低消費電力な加速度センサーや人感センサー（PIR）で監視（数μA）。動きがあったらマイコンを起こす。
- Stage 2: 低解像度で簡易的な物体検知を行う（数mW）。「人っぽいもの」が映ったら次へ。
- Stage 3: 高解像度で詳細なAI推論を行う（数十mW）。確信度が高ければ通信する。
このように、処理の重さが異なる検知を階層的に組み合わせる手法を「カスケード検知」や「トリガー検知」と呼びます。スマートスピーカーが「OK, Google」というウェイクワード（軽い処理）を待ってから、重い音声認識を始めるのと同じ仕組みです。
いきなり重い処理を走らせない設計こそが、年単位のバッテリー寿命を実現する鍵となります。AIモデルの実装においては、こうした多段的なアプローチが極めて有効です。
用語のつながりで理解する実装ロードマップ
ここまで解説した用語は、実際の開発フローの中で以下のように繋がっています。
- 要件定義: 通信頻度とバッテリー寿命の目標設定（MCU選定の基準）。
- データ収集: 現場でのデータ収集。
- 学習・モデル作成: MobileNetなどのアーキテクチャを選定し、PC/クラウドで学習。
- モデル圧縮: 量子化（int8）を行い、モデルサイズを削減。
- 実装: TFLMを使ってマイコンに実装。NPU活用も検討。
- 評価・チューニング: 実機でのレイテンシ計測と、誤検知（False Positive）対策。
- 運用設計: センサーによるトリガー検知を組み込み、全体の消費電力を最適化。
次に学ぶべきこと
用語と概念が整理できたら、次は実際に手を動かしてみるフェーズです。Edge Impulseなどのノーコード/ローコードツールを使えば、ブラウザ上でデータの取り込みからモデル作成、マイコン用ライブラリのエクスポートまでを一貫して体験できます。
「小さく生んで、賢く育てる」。TinyMLは、限られたリソースを知恵と工夫で乗り越える、エッジコンピューティングの醍醐味が詰まった技術です。まずは手元の開発ボードで、LEDをチカっと光らせるAI作りから始めてみませんか？その小さな光が、センサーデータ解析の大きな課題を解決する第一歩になるはずです。
コメント