エッジAI×組込みLinux
AIの推論をクラウドに送らず、手元の機器そのもので行う考え方をエッジAIと呼びます。ラズパイとカメラを組み合わせた画像認識は定番の入門テーマで、軽量な推論ランタイムと量子化されたモデルがそれを支えます。組込みLinuxの知識がそのままエッジAIの土台になることを、この単元で確かめます。
スマートフォンのカメラアプリが、シャッターを切らなくても画面越しに顔を検出して枠を出すのを見たことがあるはずだ。あの処理の多くは、インターネットの向こうのクラウドではなく、手元の端末そのものの中で完結している。通信が不安定な場所でもカメラアプリの顔検出が止まらないのは、このためだ。
このように、AIの推論（学習済みモデルを使って答えを出す処理）を、クラウドに送らず手元の機器で行う考え方をエッジAIと呼ぶ。エッジとは「端」を意味する言葉で、データが生まれるまさにその場所、つまりネットワークの端っこで処理を済ませてしまう発想だ。
ここまでの単元でMCPを通じてAIに手足を与える話をしてきたが、エッジAIはさらに一歩進んで、その手足自体を小さな機器の中に閉じ込めてしまう話だと捉えられる。頭脳（推論）も手足（機器の制御）も、同じ1台のボードの上にまとまっているイメージだ。
🌐 エッジの利点——遅延・プライバシー・費用・オフライン
エッジAIが選ばれる理由は主に4つある。ひとつ目は低遅延だ。クラウドに送って結果を待つ往復の通信時間がなくなるため、判断がその場で即座に返る。工場のライン検査やロボットの制御など、コンマ何秒の遅れが致命的な場面で重要になる。
2つ目はプライバシーだ。カメラ映像や音声データを外部に送信せず手元で処理が完結すれば、個人情報が機器の外に出ていくリスクを減らせる。
3つ目は通信費の削減だ。映像のような大きなデータを常時クラウドへ送り続けると通信量がかさむが、エッジ側で判断だけ済ませて必要な結果だけを送れば、通信量を大きく抑えられる。4つ目はオフラインでも動くことで、ネットワークが不安定な場所や、そもそも通信環境がない現場でも推論を止めずに済む。
この4つの利点は、組込み機器が置かれる現場の事情とよく噛み合う。工場・農地・山間部の設備・移動する車両など、安定した通信を前提にできない現場は多い。エッジAIは、そうした「クラウド任せにできない」現場でこそ真価を発揮する技術だと言える。
📷 定番入門——ラズパイとカメラで画像認識
エッジAIの入門として最もよく選ばれるのが、ラズベリーパイとカメラモジュールを組み合わせた画像認識だ。すでにこのポータルのラズパイ関連トラックで扱った基本操作の延長線上にあり、機材のハードルが低いのが魅力になる。
カメラの映像を扱う土台として、Raspberry Pi OSにはlibcameraという枠組みに基づくコマンド群が用意されている。まずカメラが正しく認識されているか確認するところから始めるとつまずきにくい。
撮影した映像をPythonのライブラリ経由で取り込み、あとで説明する軽量な推論ランタイムに渡す、という流れが典型的な構成になる。Pythonは書きやすく、AI関連のライブラリも豊富にそろっているため、エッジAIの入門言語としてよく使われる。
この構成の良いところは、必要な要素をひとつずつ確かめながら組み立てられる点だ。まずカメラの疎通を確認し、次に映像を静止画として保存できるか試し、そのうえで推論ランタイムに渡す、という順番で進めれば、途中でうまくいかない箇所があってもどこが原因か切り分けやすい。
⚙️ 軽量推論ランタイムという縁の下の力持ち
非力な組込み機器の上でAIモデルを動かすには、モデルを効率よく実行してくれる専用のソフトウェアが要る。これを推論ランタイムと呼ぶ。代表的なものに、ONNX Runtime、LiteRT（旧称TensorFlow Lite）、llama.cpp系のランタイムなどがある。
ONNXは、いろいろな学習の枠組みで作ったモデルを共通の形式に変換して扱えるようにする仕組みで、ONNX Runtimeはその形式を実行するためのソフトウェアだ。LiteRTはモバイルや組込み向けに軽量化されたランタイムで、スマホや小型ボードでの利用を強く意識して作られている。llama.cpp系は、文章生成の大きめのモデルを、なるべく軽い計算資源でも動かせるように工夫されたランタイム群を指す。
どのランタイムを選ぶかは、使いたいモデルの形式・動かす機器の種類・すでに慣れている言語といった条件で決まってくる。最初から最適解を選ぼうとせず、まずは情報の多い組み合わせで一度動かしてみて、感触をつかむのがおすすめだ。
🪶 量子化と小型モデルで非力な機器でも動かす
そのままのAIモデルは、パソコンのような潤沢な計算資源を前提に作られていることが多く、組込み機器にはサイズも計算量も重すぎることが多い。そこで使われる工夫が量子化だ。
量子化とは、モデルの内部で使われている数値の精度を意図的に落として、サイズと計算量を小さくする工夫のことだ。精度をわずかに犠牲にする代わりに、非力なCPUやメモリの少ない機器でも現実的な速度で動かせるようになる。
量子化に加えて、そもそも軽量に設計された小型モデルを選ぶという選択肢もある。大きなモデルほど賢い傾向はあるが、組込み用途では「その機器で実用的な速度と精度で動くか」のほうが重要になる場面が多い。
実務では、量子化と小型モデルの選定を組み合わせて使うことが多い。まず用途に見合った小型のモデルを選び、そのうえでさらに量子化を掛けてサイズを絞り込む、という二段構えでちょうどよい着地点を探っていく進め方になる。
☁️ クラウドとエッジの分担
エッジAIは、クラウドを完全に否定するものではない。多くの現場では、AIモデルの学習（大量のデータから賢くする作業）はクラウドの強力な計算資源で行い、できあがったモデルを使う推論だけをエッジ側で行う、という分担が一般的だ。
この分担を理解しておくと、エッジAIの限界も見えてくる。エッジ側の機器で新しいことを一から学習させるのは基本的に不向きで、あくまで「すでに賢くなったモデルを、現場で効率よく動かす」のがエッジAIの主戦場になる。学習し直したいときは、クラウド側でモデルを更新し、できあがった新しいモデルをエッジ機器へ配り直す、という流れになる。
この「配り直す」作業も、Linuxの知識がそのまま生きる場面だ。新しいモデルファイルを機器に転送し、動作確認をして、問題なければ切り替える。これは通常のソフトウェア更新の手順と何ら変わらない。
🔗 組込みトラック群への橋渡し
ここまでの話は、実は目新しいものではない。カメラ制御・省リソースでの実行・ハードウェアの制約に合わせたチューニングといった要素は、このポータルの組込みLinux関連のトラックで扱ってきた考え方そのものだ。
たとえば、GPIOでセンサーの値を読む話、クロスコンパイルで小さな機器向けにソフトウェアを用意する話、リソースの限られた環境でプロセスの状態を確認する話は、いずれもエッジAIの土台として直接つながってくる。AIという言葉が付くと難しく感じがちだが、支えている技術の多くは既に学んできたものの延長線上にある。
エッジAIは、その上に「軽量なAIモデルを動かす」という一枚を重ねただけとも言える。組込みLinuxの基礎を知っている人ほど、エッジAIの学習はスムーズに進む。逆にエッジAIから入った人は、遠回りに見えても組込みLinuxの基礎に戻ることで理解が深まる。
この相互補完の関係を意識しておくと、学習の順番に迷ったときの指針になる。エッジAIでつまずいたら組込みLinuxの基礎に戻り、組込みLinuxの学習に飽きたらエッジAIの題材で手を動かしてみる、という行き来がちょうどよい刺激になることも多い。次の単元では、視点をさらに広げて、AIインフラを支えるサーバー側のLinux技術を見ていく。