クラウドAPIを呼ばずに、Raspberry Piのような小型コンピュータ上で生成AIを動かす。数年前までは「できても実験用途」という印象が強かった構成ですが、2026年8月時点ではかなり現実的な選択肢になってきました。
Googleは2026年8月11日、Raspberry Pi 5上でLiteRTとGemmaを使い、ロボットの物体認識、音声認識、推論、音声応答までをローカルで実行する構成を公開しました。Gemma 4 E2Bでは、Raspberry Pi 5のCPU上でプリフィル99 tokens/sec、デコード9 tokens/sec、ピークメモリ約1,432MBという値も示されています。
このニュースで重要なのは、「Raspberry PiでもLLMが動いた」という話だけではありません。クラウドに送れないデータを扱う現場、通信が不安定な環境、遅延を減らしたいIoT機器などで、AI処理を端末側へ戻す設計が選びやすくなっている点です。
一方で、Raspberry PiがクラウドAIの代わりになるわけではありません。モデルサイズ、精度、メモリ、発熱、電源、保守など、小型端末ならではの制約もあります。
この記事では、Google公式発表を基に、LiteRTとGemmaをRaspberry Pi 5で動かす仕組み、どこまで実用的なのか、SEが業務システムやIoT開発で考えるべきポイントを整理します。確認時点は2026年8月13日です。
Googleが公開したRaspberry Pi向けエッジAI構成
Google Developers Blogで公開された構成では、Raspberry Pi 5上で複数のAI処理を並行して動かしています。デモに使われたReachy Miniでは、カメラ映像から物体を検出し、音声を文字へ変換し、Gemmaが状況を判断し、最後に音声で返答するところまでをローカルで実行しています。
処理の役割分担は次のようになっています。
- 物体検出：Ultralytics YOLOをGPUで実行
- 音声認識：MoonshineをCPUで実行
- 推論・行動判断：Gemma 4 E2BをCPUで実行
- 音声合成：CPUで実行
ポイントは、すべてをLLMひとつに任せていないことです。画像認識、音声認識、言語推論といった処理を、それぞれ向いたモデルへ分けています。
SEの視点で見ると、この構成はかなり重要です。生成AIを業務に組み込むときも、「何でも一つの巨大モデルに任せる」より、処理ごとに適した小さなモデルを組み合わせる方が、速度、コスト、安定性を確保しやすいケースがあります。
Raspberry Piのように計算資源が限られる環境では、その考え方がさらに重要になります。
LiteRTとは何か
LiteRTは、Googleが提供するオンデバイスAI向けの推論ランタイムです。もともとのTensorFlow Liteの流れを引き継ぎつつ、現在はLLMを含む新しいAIモデルを端末上で効率よく動かすための基盤へ発展しています。
クラウドAIでは、入力データをインターネット経由でAPIへ送り、サーバー側で計算して結果を返してもらいます。一方、LiteRTを使う構成では、モデル自体を端末へ配置し、その端末のCPUやGPUで推論します。
この違いは、単なる「クラウドかローカルか」ではありません。設計上は次のような差があります。
| 項目 | クラウドAI | ローカルAI |
|---|---|---|
| 通信 | 原則必要 | オフライン運用可能 |
| データ送信 | 外部サービスへ送る場合あり | 端末内で完結可能 |
| モデル性能 | 大規模モデルを使いやすい | 端末性能に制約される |
| 遅延 | ネットワーク影響あり | 端末内処理なら一定にしやすい |
| コスト | API利用量に応じる | ハード購入・電力・保守が中心 |
LiteRTは、このローカルAI側の実行環境を整える役割を持ちます。Googleの発表では、CPU上でXNNPACKを使った最適化に加え、Raspberry Pi 5のVideoCore VII GPUをWebGPU（Vulkan）経由で利用する仕組みも紹介されています。
Gemma 4 E2BはRaspberry Pi 5でどこまで動くのか
Googleが公開した測定では、Raspberry Pi 5上でGemma 4 E2BをLiteRT-LMから動かした場合、プリフィルが99 tokens/sec、デコードが9 tokens/sec、ピークメモリが約1,432MBとされています。
ここでプリフィルとは、ユーザーが入力した文章などを最初に読み込む処理です。デコードは、その後に回答文を1トークンずつ生成していく処理を指します。
9 tokens/secという数字だけを見ると、クラウドの高速モデルと比べて圧倒的に速いわけではありません。ただし、ローカル端末上でリアルタイム性を保ちながら会話や制御へ利用する用途では十分に検討できる水準です。
GoogleはGemma 4 E2Bのトークナイザについて、平均で1トークンあたり約4.2文字を収められるとしており、デモでは約27.3文字/秒、約300語/分に相当する生成速度を示しています。
大切なのは、数字だけで「速い」「遅い」と判断しないことです。
例えば、工場設備の異常メッセージを分類する用途なら、1秒以内に返れば十分かもしれません。逆に、人間との自然な音声会話では、数秒の待ち時間でも使いにくく感じることがあります。
用途ごとに必要な応答時間を先に決め、その要求を満たせるかで判断する方が実務的です。
利用できるGemmaモデルをどう使い分けるか
Googleの今回の発表では、Raspberry Piの用途に合わせて複数のGemmaモデルが紹介されています。
Gemma 3 270M
非常に小さいモデルで、感情分類や固有表現抽出など、特定用途へ調整して高速に動かす使い方が想定されています。
複雑な文章生成を任せるより、「この文章は問い合わせか苦情か」「このログから機器名を抜き出す」といった限定されたタスク向きです。
EmbeddingGemma 300M
文章をベクトル化する埋め込みモデルです。RAG、意味検索、分類などに向いています。
例えば、工場内の保守マニュアルをRaspberry Pi上へ配置し、ネット接続なしで検索する仕組みを作る場合に利用できます。
Gemma 3 1B
比較的小型のテキストモデルで、要約や文章生成など幅広い用途へ使える位置付けです。
単純な分類だけでは足りないものの、巨大なモデルを動かす必要もない場合の候補になります。
Gemma 4 E2B
今回のRaspberry Pi 5デモで中心的に使われているモデルです。メモリ効率を重視しており、画像・音声・テキストを組み合わせるエッジ環境での継続動作を想定しています。
Gemma 4 E4B
より強い推論能力を持ちながら、Raspberry Piでも扱えるサイズとのバランスを狙ったモデルです。
ただし、モデルが大きくなるほどメモリ消費や処理時間も増えます。「大きい方が安心」と考えるより、必要な精度を満たす最小モデルを選ぶ方が、エッジAIでは安定しやすくなります。
SE実務で考えられる利用場面
Raspberry PiとローカルAIの組み合わせは、一般的なWebシステムを置き換えるものではありません。強みが出るのは、「その場所で判断したい」「外へデータを送りたくない」「通信が切れても動かしたい」といった条件がある場合です。
工場や倉庫の現場端末
カメラ映像から物体や状態を検出し、異常時だけ通知する仕組みは代表的です。
常時映像をクラウドへ送ると通信量やプライバシーの問題が出ますが、端末側で判定し、必要なイベントだけ送信すれば通信量を抑えられます。
LLMを組み合わせると、「検出した異常内容を保守担当者向けの文章にまとめる」「関連マニュアルを検索して候補を提示する」といった処理も考えられます。
オフラインの作業支援
通信環境が弱い場所では、クラウドAPIへの依存が業務停止の原因になります。
現場マニュアル検索、点検手順の案内、定型報告の下書きなどを端末内で完結させれば、通信障害時でも最低限の支援を続けられます。
機密データを扱う補助端末
データを外部へ送信しないことが重要な環境でもローカルAIは有効です。
例えば、社内文書の検索や機器ログの分類など、クラウドへの送信が難しい情報を端末側で処理できます。
ただし、「ローカルだから安全」とは限りません。端末そのものの盗難、OSの脆弱性、SSH設定、モデルファイルの改ざんなど、別のセキュリティ対策が必要になります。
家庭菜園や農業IoT
ブログのテーマとも相性が良いのが農業IoTです。
畑のカメラ映像から植物や動物の変化を検出する、温湿度や土壌センサーの値をまとめる、異常時に短い説明文を生成するといった用途が考えられます。
畑ではWi-Fiや携帯回線が安定しないこともあるため、ローカルで処理し、結果だけを送る構成には合理性があります。
ただし、病害虫や農薬判断をAIだけに任せるのは避けるべきです。画像認識や文章生成は補助情報として使い、農薬使用などは製品ラベル、登録内容、専門機関の情報を確認する必要があります。
クラウドAIよりローカルAIが向いている条件
ローカルAIの導入判断では、技術的に動くかどうかより、「なぜローカルにするのか」を明確にすることが大切です。
次の条件がある場合は、検討価値があります。
- 通信が不安定、または完全オフラインで動かしたい
- 画像や音声を外部へ送信したくない
- 応答遅延を一定にしたい
- API利用料を継続的に発生させたくない
- 現場端末単体で最低限の判断を継続したい
反対に、複雑な推論、高精度な文章生成、大量の情報を横断した調査が必要なら、クラウドの大規模モデルの方が向いています。
実際のシステムでは、どちらか一方に決める必要もありません。
例えば、通常時はRaspberry Piで簡単な分類と異常検知を行い、判断が難しいケースだけクラウドAIへ送るハイブリッド構成も考えられます。
この設計なら、通信量とAPI料金を抑えながら、高度な処理も利用できます。
GPUを使えば必ず速くなるわけではない
Googleの発表では、Raspberry Pi 5のCPUとGPUを並行利用しています。
Raspberry Pi 5のCPUはクアッドコアARM Cortex-A76で、Googleの説明ではFP32で約153.6 GFLOPS、INT8で最大約2.0 TOPSとされています。一方、VideoCore VII GPUはFP32で約76.8 GFLOPS、INT8で約0.24 TOPSです。
数字だけを見るとCPUの方が強く見えます。それでもGPUを使う理由は、処理を分担できるからです。
例えば、物体検出をGPUへ任せれば、CPUはGemmaの推論や音声処理に集中できます。1つの処理を最速にするのではなく、システム全体を止まりにくくするための役割分担です。
業務システムでも同じで、AI処理の一部分だけ高速化しても、データ取得やI/Oが詰まれば全体は速くなりません。
エッジAIでは特に、CPU使用率、GPU使用率、メモリ、温度、ストレージI/Oをまとめて見ながら設計する必要があります。
導入前に注意したい5つのポイント
1. メモリ容量
Raspberry Pi 5には複数のメモリ容量があります。モデルだけでなく、OS、画像処理、音声処理、アプリケーションも同時にメモリを使います。
Gemma 4 E2Bのピークメモリが約1.4GBだからといって、2GB環境で余裕を持ってシステム全体が動くとは限りません。実務では余裕を確保した方が安定します。
2. 発熱と電源
LLMや画像認識を継続的に動かすとCPU負荷が高くなります。
短時間のデモでは問題なくても、24時間運用では温度による性能低下や電源不足が問題になる可能性があります。冷却、電源品質、ケース設計まで含めて考える必要があります。
3. ストレージ寿命
ログを大量に書き続ける構成では、microSDカードの寿命が問題になることがあります。
常時稼働させるなら、SSDの利用やログローテーション、監視設計を検討した方が安全です。
4. モデル更新
クラウドAIではサービス側がモデルを更新しますが、ローカルAIでは自分たちでモデルを配布し直す必要があります。
どの端末にどのモデルバージョンが入っているかを追跡できないと、現場ごとに挙動が違う状態になります。
モデルファイルもアプリケーションと同じようにバージョン管理し、更新とロールバックの仕組みを用意することが重要です。
5. 出力の誤り
ローカルで動いても、LLMの誤回答がなくなるわけではありません。
特に設備制御や物理動作につなげる場合は、AIの出力をそのまま実行せず、安全なコマンドだけを許可する仕組みが必要です。
「AIが右へ移動と言ったからモーターを動かす」のではなく、速度上限、移動範囲、停止条件などをプログラム側で制約する設計が必要になります。
LiteRT CLIで試すまでの流れ
GoogleはLiteRT CLIを使った導入方法も公開しています。公式例では、Python環境から次のようにインストールします。
pip install litert-cliその後、Hugging Faceの認証トークンを設定し、LiteRT向けに用意されたGemmaモデルを指定して実行します。
公式例では画像ファイルを添付し、「目の前の主な物体を特定し、位置を答え、短い行動案を出す」という処理をGemma 4 E2Bへ依頼しています。
実務で試すなら、最初からロボット制御へ進む必要はありません。
まずは次の程度で十分です。
- Raspberry Pi 5へLiteRT CLIを入れる
- 小さなGemmaモデルを1つ動かす
- 応答時間とメモリ使用量を記録する
- 自分の業務データに近い入力を試す
- クラウドAPIとの速度・精度・コストを比較する
この順番なら、ハードウェア購入や複雑な開発へ進む前に、自分の用途に合うか確認できます。
今後はRaspberry Pi AI HATへの対応も予定
Googleは今後、LiteRTとGemmaをHailo AIアクセラレータへ対応させる予定も明らかにしています。
対象としてRaspberry Pi AI HAT+、AI HAT+ 2が挙げられており、同じLiteRTのワークフローから推論処理をアクセラレータへオフロードできる方向です。
ただし、2026年8月13日時点では「coming soon」とされている段階です。対応済みとして構成を決めるのではなく、実際の提供開始と対応モデルを確認してから採用した方がよいでしょう。
エッジAIの性能向上は、CPUの高速化だけでなく、こうした専用アクセラレータの普及によって進む可能性があります。
フリーランスSEが試すなら何から始めるか
フリーランスSEがこの分野を学ぶ場合、いきなり高度なロボット開発を目指す必要はありません。
おすすめなのは、既存業務を小さくローカル化することです。
例えば、CSVログを読み込んで異常候補を要約する、社内マニュアルをEmbeddingGemmaで検索する、USBカメラから特定の物体だけ検出する、といった小さなテーマです。
ここで確認したいのは、モデル性能だけではありません。
- 起動時間
- メモリ使用量
- CPU温度
- 連続稼働時の安定性
- モデル更新の手間
- クラウドAPIと比較した保守コスト
受託開発や業務改善提案では、「AIを使えます」より「クラウドへ送らず現場端末で処理できます」という方が価値になる案件もあります。
特に製造、物流、小売、農業、介護施設など、物理的な現場を持つ業種では、エッジAIの知識がシステム提案の幅を広げます。
まとめ：Raspberry PiのAIは「小さなクラウド」ではなく別の設計思想
Googleが公開したRaspberry Pi 5、LiteRT、Gemmaの構成は、小型端末でも言語モデル、画像認識、音声処理を組み合わせたAIシステムを実用的な速度で動かせることを示しています。
ただし、重要なのはクラウドAIをそのままRaspberry Piへ移すことではありません。
処理を小さく分け、適したモデルを選び、CPUとGPUを使い分け、必要なデータだけを扱う。エッジAIでは、この設計が性能そのものより重要になります。
SEが試すなら、まずは「クラウドに送らなくても価値が出る1つの処理」を探すのがよいでしょう。マニュアル検索、ログ分類、画像検出など、小さな用途から始めるとRaspberry Piで動かす意味を判断しやすくなります。
ローカルAIは万能ではありませんが、通信、プライバシー、遅延、APIコストが課題になる現場では、クラウドAIとは別の有力な選択肢になりつつあります。
参考情報
- Google Developers Blog：Mastering Edge AI on Raspberry Pi with LiteRT and Gemma
- Google AI Edge：LiteRT
確認日：2026年8月13日
コメント