STM32N6とNeural-ART NPU
マイコン単体で動く
エッジAI実践ガイド

はじめに：「マイコンでAI」の何が変わったのか

これまでSTM32でAI推論といえば、STM32Cube.AIで学習済みモデルをCコードに変換し、CPUで実行するTinyMLが定番でした。この方式は消費電力とコストの面では優秀ですが、実行主体はあくまでCortex-MコアのCPUです。数十〜数百KBの小さなモデルなら実用になる一方、カメラ画像に対する物体検出のようなワークロードでは推論に数百ミリ秒〜数秒かかり、「リアルタイムの画像AIはJetsonかラズパイ＋アクセラレータで」というのが実務上の相場でした。

この前提を変えたのが、STマイクロエレクトロニクスが投入したSTM32N6シリーズです。STM32として初めてNPU（Neural Processing Unit）であるNeural-ART Acceleratorを内蔵し、マイコン単体で最大600 GOPSのニューラルネットワーク推論を実行できます。CPU推論の従来型TinyMLと、Linuxボードによるエッジ推論のあいだにあった性能の空白地帯を、1チップのMCUで埋める存在です。

本記事では、カタログスペックの紹介にとどまらず、「N6で何ができて何ができないのか」「Jetson/ラズパイとどう使い分けるか」「ONNXモデルをどうやって実機に載せるか」「量産採用で何を確認すべきか」を、受託開発の実務目線で整理します。

STM32N6とNeural-ART NPUのアーキテクチャ

まず主要スペックを整理します。数値はいずれもST公式の製品ページ・製品プレゼンテーションに基づきます。

アーキテクチャ上のポイント3つ

(1) NPUはCPUから独立した推論エンジン。Neural-ARTは約300個のMACユニットを持つ専用ハードウェアで、コンパイル時にモデルをNPU用マイクロコードに変換して実行します。CPU（Cortex-M55）は推論中も空くため、前処理・後処理・通信・制御を並行できます。RTOSタスクとして推論と制御を同居させる設計は、STM32 + FreeRTOS入門で解説したタスク設計の延長線上で考えられます。

(2) NPU非対応の層はCortex-M55にフォールバック。ST Edge AI Coreのコンパイラは、モデルの各レイヤをNPU実行とCPU実行に自動で振り分けます。Cortex-M55はHelium（MVE）ベクトル拡張を持つため、フォールバック時もCortex-M4/M7比では高速ですが、CPUフォールバックが多いモデルはNPUの意味が薄れます。NPUの対応オペレータ一覧はST Edge AI Coreの公式ドキュメントに公開されているので、モデル設計の段階で対応表と突き合わせるのが実務の鉄則です。

(3) カメラパイプラインが1チップで完結。MIPI CSI-2＋ISP＋NPU＋H.264エンコーダを内蔵するため、「カメラ入力→AI推論→結果のみ送信（または録画）」という典型的なスマートカメラ構成が外付けプロセッサなしで成立します。従来この構成には一般にLinux SoCクラスのプロセッサが必要でした。

Jetson・Raspberry Piとの使い分け判断基準

エッジAIの実装先を相談される際、弊社では「演算量」「電力・熱」「起動時間と制御性」「コストと運用」の4軸で判断しています。代表的なプラットフォームと比較します。

STM32N6が向くケース

• 単機能のビジョンAI：1カメラでの人検知・物体検出・分類・姿勢推定・異常検知など、int8量子化したCNN 1〜2本で完結するタスク
• 電池・PoE・限られた電源枠：ファンレス密閉筐体、ソーラー＋バッテリー運用、常時給電が難しい屋外設置
• リアルタイム制御との同居：モーター制御や安全系のマイクロ秒応答とAI判定を1チップで両立したい装置組込み（LinuxのソフトリアルタイムではNGな案件）
• 瞬時起動・高信頼：電源断→復帰が頻繁な環境。ファイルシステム破損リスクのあるLinuxブートを避けたい場合
• BOMコストと部品点数の圧縮：SoC＋DRAM＋eMMC＋PMICの構成をMCU＋外部フラッシュ1個に集約したい量産品

STM32N6では無理をしないほうがよいケース

• LLM・VLM（視覚言語モデル）：数百MB〜GB級のモデルはメモリ的に対象外。VLM級の推論はRaspberry Piで動かすvLM完全ガイドで扱ったようなLinuxボード以上が前提
• 複数カメラの同時解析・高解像度リアルタイム処理：演算量が0.6 TOPSを恒常的に超える構成
• モデルを頻繁に差し替える運用：コンテナやPythonランタイムでモデルを入れ替えるスタイルの開発・運用にはLinux機が向く（N6は再コンパイル＋ファーム更新が基本）
• 学習・ファインチューニングをデバイス上で行う用途

開発に必要なもの：評価ボードとST Edge AI Suite

評価ボードは2種類

カメラAIの評価が目的なら、カメラ・LCD・サンプルアプリがそのまま動くSTM32N6570-DKから始めるのが最短です。ST公式のGitHubに画像分類・物体検出・姿勢推定などのGetting Startedリポジトリ（STM32N6-GettingStarted-ImageClassificationなど）が公開されており、ビルド済みバイナリを書き込めば当日中にデモが動きます。

ソフトウェア側：ST Edge AI Suiteの構成

N6のAI開発ツール群は「ST Edge AI Suite」という傘の下に整理されています。実務で触るのは主に次の4つです。

• ST Edge AI Core（stedgeai CLI）：無償のコマンドラインツール。TensorFlow Lite / ONNX / Kerasのモデルを評価・最適化し、Neural-ART用マイクロコードとCコードに変換する中核。本記事執筆時点の対応バージョンはv4系（後述のGetting StartedはSTEdgeAI v4.0.0を要求）
• GUIツール（STM32N6-AI / STM32Cube AI Studio）：CubeMX連携のN6用AIパッケージがSTM32N6-AI、従来のX-CUBE-AIの後継となるデスクトップGUIがSTM32Cube AI Studio（STEDGEAI-CUBEAI）。いずれも中身はST Edge AI Coreベースで、GUI派はこちら
• ST Edge AI Developer Cloud：ブラウザからモデルをアップロードし、リモートの実機ボードでレイテンシとメモリをベンチマークできる無償サービス。ボード購入前の見積もりに有効
• STM32モデルZoo（GitHub: STMicroelectronics/stm32ai-modelzoo）：量子化済みの学習済みモデル＋学習/評価スクリプト集。まず自分のタスクに近いモデルをここから選ぶのが定石

このほか、ビルドと書き込みにSTM32CubeIDEとSTM32CubeProgrammer（Getting Startedの要求はそれぞれv1.17.0 / v2.18.0以降）を使います。

ONNX/TFLiteモデルのデプロイフロー

N6へのモデル搭載は「①int8量子化 → ②stedgeaiでNPU用にコンパイル → ③アプリに組み込みビルド → ④署名して外部フラッシュへ書き込み」の4段階です。順に見ていきます。

Step 1：int8量子化（必須）

Neural-ARTで実行するモデルは、重み・アクティベーションともにint8（scale/offset形式、per-channel）で量子化されていることが前提です。float32のONNXをそのまま渡してもNPUには載りません。ONNXの場合はQDQ形式の量子化モデルを用意します。

# ONNXモデルを int8 (QDQ) に静的量子化する例（onnxruntime）
from onnxruntime.quantization import quantize_static, QuantType

quantize_static(
    "model_fp32.onnx",
    "model_int8.onnx",
    calibration_data_reader=reader,   # 実運用に近い画像数百枚で校正
    activation_type=QuantType.QInt8,
    weight_type=QuantType.QInt8,
    per_channel=True,                 # Neural-ARTはper-channel int8が前提
)

量子化の校正データは学習データからのランダム抽出ではなく、実運用環境で撮影した画像を混ぜるのが精度劣化を抑えるコツです。TensorFlow系ならTFLiteのfull-integer quantizationで同様にint8化します。量子化とメモリ最適化の考え方自体はSTM32Cube.AIでTinyMLを量産品質にする記事で解説した内容がそのまま土台になります。

Step 2：stedgeaiでNeural-ART向けにコンパイル

# TFLite(int8)モデルをNeural-ARTターゲットでコンパイル（公式ドキュメントの例）
stedgeai generate -m mobilenet_v2_0.35_224_fft_int8.tflite \
    --target stm32n6 --st-neural-art

# ONNX(QDQ int8)でも同様
stedgeai generate -m model_int8.onnx --target stm32n6 --st-neural-art

--st-neural-artを付けるとNPU用のコンパイルが走り、NPUで実行できる層はマイクロコードに、非対応の層はCortex-M55用コードに振り分けられます。コンパイル時の最適化方針やメモリ割り当ては、コンパイルプロファイル（neural_art.json）とメモリプール記述ファイル（stm32n6.mpool）で制御します。リンカスクリプトでセクション配置を決めるのと同じ感覚で、「重みをどのメモリに」「アクティベーションをどのRAMに」置くかをここで設計します。

生成されたレポートには、各レイヤのNPU/CPU割り当て・メモリ使用量・推定サイクルが出力されます。ここでCPUフォールバックが多発していたら、モデル側のオペレータを見直すサインです。

Step 3〜4：ビルド・署名・外部フラッシュへの書き込み

N6はフラッシュレスのため、書き込み対象は外部フラッシュです。ブートROM→FSBLと続く署名付きブートチェーンが各段のヘッダを検証するため、アプリケーションバイナリにも署名ツールでヘッダを付与します。ST公式Getting Started（画像分類）の手順は次の通りです。

# 1. ビルド済みバイナリに署名（ブートチェーンが検証するヘッダを付与）
# ※パスはプロジェクト構成に合わせて読み替え（公式READMEでは build/Application// 配下）
STM32_SigningTool_CLI -bin build/Project.bin -nk -t ssbl -hv 2.3 \
    -o build/Project_sign.bin

# 2. 外部フラッシュ用ローダを指定して書き込み（STM32N6570-DKの例）
export DKEL="<CubeProgrammer>/ExternalLoader/MX66UW1G45G_STM32N6570-DK.stldr"

# FSBL（第一段ブートローダ）
STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -el $DKEL -hardRst -w FSBL/ai_fsbl.hex
# ネットワーク重みデータ
STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -el $DKEL -hardRst -w Model/network_data.hex
# 署名済みアプリケーション（外部フラッシュ 0x70100000 へ）
STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -el $DKEL -hardRst -w build/Project_sign.bin 0x70100000

開発中はボード上のブートスイッチをデベロップメントモード（RAMに直接ロードしてデバッグ）に、確認後はBoot from Flashに切り替えて電源再投入で起動します。従来のSTM32のように「内蔵フラッシュにELFを焼いて終わり」ではなく、FSBL・重み・アプリの3点を外部フラッシュの決められたアドレスに配置するという、MPU（STM32MP1等）に近いブートフローになる点が最初の関門です。

メモリ制約の現実：4.2MB SRAMとフラッシュレス構成

N6採用可否の8割はメモリ設計で決まります。押さえるべき構造は次の通りです。

メモリ階層と配置の優先順位

Neural-ARTのコンパイラは、推論中の中間バッファ（アクティベーション）を次の優先順位で割り当てます。

1. NPU専用RAM（NPURAM/AXISRAM3〜6）：NPUアクセスに最適化された最速の領域。コンパイラはまずここを使う
2. 汎用AXISRAM（AXISRAM1〜2）：NPU RAMが埋まった場合の次候補。アプリケーションと取り合いになる
3. 外部メモリ（PSRAM/フラッシュ）：最終手段。ここに落ちた時点で性能は大きく低下する

重み（読み出し専用）は外部Octo-SPIフラッシュに置くのが標準構成ですが、外部メモリへのアクセス頻度が推論時間を支配するため、頻繁に読むデータをどこまで内蔵SRAMに載せられるかが性能チューニングの本丸です。この配置は前述のmpoolファイルで明示的に制御できます。

実務上のサイズ感

• 内蔵SRAMは合計4.2MB。ただしカメラフレームバッファ、表示バッファ、アプリのヒープ/スタックもここに同居するため、アクティベーションに使える量は構成次第で大きく目減りします。800×480のRGB565ダブルバッファだけで約1.5MBを消費する計算です
• int8量子化後で数MB級までのCNN（MobileNet系、YOLO系の小型構成など）が現実的な守備範囲。STM32モデルZooに量子化済みの参照モデルが揃っているので、まず近いモデルの実測値から逆算するのが早道です
• それを超えるモデルは、入力解像度の削減・チャネル削減・蒸留でN6に収めるか、素直に上位プラットフォームへ。「量子化すれば何でも載る」わけではない点は顧客説明でも強調すべきポイントです

フラッシュレスであることの設計影響

STM32N6の内蔵不揮発メモリはOTP（ワンタイムプログラマブル）領域のみで、ユーザーフラッシュはありません。したがって自社基板では、

• XSPI接続の外部NORフラッシュ（DKはMacronix MX66UW1G45G＝1Gbit品を採用）を必ずBOMに載せる
• ブートROM→FSBL→アプリという署名付きブートチェーンを製造工程に組み込む（署名鍵の管理体制を含む）
• 必要に応じてHexadeca-SPI PSRAMを追加し、フレームバッファや大きなアクティベーションを逃がす

という設計判断が必要です。従来のSTM32Fシリーズ的な感覚で基板を起こすと確実に手戻りするため、メモリ構成は最初のブロック図の段階で確定させることをお勧めします。

量産採用の判断ポイント

評価ボードでデモが動くことと、量産製品として成立することの間には距離があります。弊社が受託案件でチェックしている観点を挙げます。

1. 精度の量産条件での検証：int8量子化後のモデルを、実運用の照明・画角・季節変動を含むデータで再評価する。評価はPC上のシミュレーションだけでなく、stedgeaiのvalidate機能や実機で行う
2. 性能マージン：目標フレームレートに対して実測で余裕があるか。CPUフォールバック層が将来のモデル更新で増える可能性も見込む
3. 熱設計：ファンレスが成立するかは筐体条件次第。NPU効率が高いとはいえ、800MHz CPU＋1GHz NPU＋カメラISPをフル稼働させる構成では実測での熱評価が必須
4. セキュアブートと鍵運用：署名付きブートは量産では「やるかどうか」ではなく「どう運用するか」の問題。OTPへの鍵情報書き込みは文字通り一度きりのため、製造フローの設計を先に固める
5. モデル更新の運用設計：N6ではモデル更新＝外部フラッシュのファーム更新。OTA更新の仕組み（二面化、失敗時のロールバック）を初期設計に含める
6. 部品供給と単価：MCU単価は数量・パッケージ・セキュリティ機能の有無（N657/N647等）で変わるため、代理店見積もりを早期に取る。外部フラッシュ・PSRAMも含めたセットでBOMを比較する
7. ツールチェーンのバージョン固定：ST Edge AI Coreは活発に更新されており、バージョン間でコンパイル結果（性能・メモリ配置）が変わり得る。量産開発ではツールバージョンをプロジェクトで固定し、更新時は回帰確認する

よくある落とし穴と対策

まとめ

STM32N6は「マイコンの開発文化のまま画像AIを製品に入れられる」初めての選択肢です。一方で、フラッシュレスのブート設計や量子化前提のモデル設計など、従来のSTM32ともLinuxエッジAIとも違う勘所があります。PoCの段階から量産を見据えた設計でお困りの際は、お気軽にご相談ください。

よくある質問（FAQ）