組み込み機器上でAIモデルを動かす「Edge AI（エッジAI）」という領域が、静かに存在感を増しています。
マイクロコントローラー（MCU、家電や産業機器に搭載される小型の演算チップ）でAI推論を動かす取り組みで、クラウドのAIとは前提がかなり異なります。
この記事はWebフロントエンド・アプリケーション開発を担当していて、IoTやエッジ向けの案件に関わる可能性がある方に向けて書きます。ChatGPTやGeminiのようなクラウドAIとEdge AIの違いを技術的に整理し、フロントエンド技術者としてどこに接点があるかを確認できる内容にしています。
クラウドAIが苦手とする5つの場面
ChatGPTやClaude、Geminiは巨大なデータセンターのGPU上で動いています。この構成には暗黙の前提が5つあります。
1つ目はレイテンシ（応答までの遅延）です。チャットボットなら数百ミリ秒の往復は気になりません。ですがモーターの異常振動を検知して即座に停止させる制御では、その遅延が故障につながります。
2つ目はプライバシーです。医療用ウェアラブルの生体情報や家庭内カメラの映像を外部送信すること自体が、法的・倫理的に許容されない場面があります。
3つ目はネット依存です。工場の奥まった場所や農地、移動中の車両など、通信環境が悪い場所ほどエッジデバイスの価値が高いという逆説があります。
4つ目は信頼性です。パケットロスやサーバーメンテナンスなど、ネットワークは常に不安定さを抱えています。5つ目はコストで、大量のセンサーデータを常時クラウドに送り続けると、帯域とバッテリーの両方を消耗します。
Edge AIの仕組みを段階的に理解する
まず「エッジコンピューティング」は、データが生まれる場所（センサーやカメラの近く）で処理を完結させる考え方です。中央のサーバーに全部送るのではなく、現場で処理します。
次に「Edge AI」は、そのエッジ側のハードウェア上で機械学習モデルを実行することを指します。データを知能のところへ送るのではなく、知能をデータのところへ持っていく発想の転換です。
その中核にあるのが「オンデバイス推論（on-device inference）」です。学習済みモデルがデバイス上でローカルに動作し、センサー値や画像、音声といった生の入力を、分類・予測・検知といった結果に変換します。サーバーを一切介しません。
学習（トレーニング）自体は通常クラウドで行われます。計算資源が潤沢にあるためです。学習済みのモデルを圧縮・最適化してMCUに書き込み、推論だけをエッジで行う、という役割分担が一般的な構成になります。
Webフロントエンドの技術動向との接点を整理する
ここで、フロントエンド技術者が既に触れている技術との比較をしておきます。ブラウザ上でML推論を動かす技術としては、TensorFlow.jsやONNX Runtime Web、WebAssembly（Wasm、ブラウザやサーバーで高速に実行できるバイナリ形式）を使ったモデル実行が挙げられます。
これらはブラウザという「エッジ」でオンデバイス推論を行う点で、MCU上のEdge AIと発想が共通しています。ただし実行環境の制約はまったく異なります。ブラウザはメガバイト〜ギガバイト単位のメモリを前提にできますが、MCU向けのEdge AIはキロバイト単位のRAMで動作するモデルを扱います。
もう1つの比較対象がエッジランタイムです。Cloudflare WorkersやDeno Deploy、Vercel Edge Functionsといった「エッジランタイム」は、CDN（コンテンツ配信network）の拠点でサーバーサイド処理を実行し、レイテンシを下げる技術です。これはユーザーに近い場所で処理する発想がEdge AIと共通していますが、動作環境はV8やWasmベースの軽量サンドボックスであり、依然としてサーバー側のリソース（数百MB〜数GB）を使えます。MCU上のEdge AIとは扱えるリソースの桁が大きく違います。
WebAssemblyはこの2つの世界をつなぐ技術としても注目されています。WasmはCコードなどをコンパイルして、ブラウザだけでなく組み込み環境に近いランタイムでも動かせる移植性を持っています。TensorFlow LiteやONNX RuntimeのモデルをWasm経由でブラウザ実行する構成は既に実用段階にあり、この延長線上でエッジデバイス向けランタイムとの技術共有が進む可能性があります。
今日確認できること
自分の担当プロダクトがEdge AIやWasm推論と接点を持つかどうか、次の観点で確認できます。
- ブラウザ上で画像認識・音声認識を行う機能要件があるか（TensorFlow.js・ONNX Runtime Webの採用候補になる）
- IoTデバイスやスマートホーム機器と連携するWebダッシュボードを開発しているか（バックエンドがMCU上のEdge AIである可能性がある）
- レイテンシに敏感な処理をエッジランタイム（Cloudflare Workers等）に寄せる設計を検討しているか
- モデルサイズや量子化（モデルを軽量化する手法）について、機械学習チームとの会話が必要になっていないか
これらに1つでも当てはまる場合、TensorFlow.jsの公式サイトにあるモデル一覧と、対応する量子化フォーマット（TFLite形式）を確認しておくと、MCU側のエンジニアとの会話がスムーズになります。ONNX Runtime WebのGitHubリポジトリには、Wasmバックエンドの対応状況やパフォーマンス指標が公開されているので、ブラウザ推論を検討する際の判断材料になります。
Zephyr RTOS（組み込み向けのリアルタイムOS）やARM Cortex-Mシリーズという単語がプロジェクトの会話に出てきたら、それはMCU側のEdge AI開発の話であり、Web側の技術スタックとは別レイヤーで動いていると認識しておくと混乱を避けられます。
まとめ
クラウドAIとEdge AIは対立する技術ではなく、レイテンシ・プライバシー・接続性・コストという制約の違いによって使い分けられる関係です。
フロントエンド開発者にとっての実務的な接点は、ブラウザ上でのオンデバイス推論（TensorFlow.js・ONNX Runtime Web）と、CDN拠点で処理するエッジランタイムの2つです。どちらもWebAssemblyという共通基盤を経由して、MCU向けのEdge AI技術とゆるやかにつながっています。
まずは自分の担当プロダクトが上記のどの接点に該当するかを洗い出し、該当する場合はTensorFlow.jsやONNX Runtime Webの公式ドキュメントでモデルサイズと推論速度のベンチマークを確認するところから始めてみてください。