JBlankedがZimaBoard 2でFlipper Zero、Cardputer、PicoCalcをローカルAIに接続する方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How JBlanked Connects Flipper Zero, Cardputer, and PicoCalc to Local AI with ZimaBoard 2 - Zima Store Online

ローカルAIを組み込みデバイス開発に導入する別の方法を記録してくださったJBlankedに感謝します。完全版動画では、ZimaBoard 2をローカルOllamaサーバーに変え、Cardputer-ADV、PicoCalc、Flipper Zeroなどのハンドヘルドデバイスをその共有AI環境に接続しています。

小型デバイスごとに大規模言語モデルを直接実行しようとするのではなく、この実験では処理を分離しています。ZimaBoard 2がローカルAIサービスを担い、ハンドヘルド機器は軽量な開発インターフェースとして機能します。JBlankedはその後、オープンソースのPicoware Agentを使って、アプリケーションの作成、デバイス情報の確認、そしてこのローカルAI接続を通じたハードウェアの管理を行います。

共同制作に関する開示：この記事は、JBlankedが実演したセットアップと、PicowareおよびFlipperHTTPの公開ドキュメントに基づいています。ソフトウェアのバージョン、AIモデルの利用可能性、ハードウェアの互換性、ローカル推論の性能は、時間の経過とともに変わる可能性があります。

結果：1台のコンパクトなホームサーバーで、リソースに制約のある複数のメーカーデバイスにAIレイヤーを提供できます。ハンドヘルド機器は引き続き独自のファームウェアとインターフェースを実行し、計算負荷の高い言語モデルタスクはローカルサーバー上のOllamaで処理できます。

ローカルAIセットアップの概要

このプロジェクトでは、コンパクトなx86サーバーと複数の組み込みプラットフォームを組み合わせています。すべてのデバイスに同じソフトウェアスタックを無理に適用するのではなく、JBlankedは各デバイスが対応する機能に応じて異なる接続レイヤーを使用します。

コンポーネント	セットアップにおける役割	重要な考慮事項
ZimaBoard 2	ZimaOSを実行し、AI環境をホストする中央ローカルサーバーとして機能します。	モデルの性能は、ボードのCPUだけでなく、ハードウェア構成全体に左右されます。
ZimaOS	Ollamaのデプロイに使用するサーバー環境とApp Storeを提供します。	機密性の高いプロジェクトでサーバーを使用する前に、アプリケーション設定とネットワークアクセスを確認してください。
Ollama	言語モデルをローカルで実行し、接続されたデバイスからのリクエストに応答します。	モデルによって、必要なメモリ、ストレージ、アクセラレーターが異なります。
NVIDIA GeForce RTX 3060	実演されたZimaOS環境では、12GBのVRAMを搭載した利用可能なGPUとして表示されます。	動画に表示されているGPUは実演された構成の一部であり、推論結果を評価する際に考慮する必要があります。
Cardputer-ADV	Picowareを実行し、Agentインターフェースを使ってローカルAIサーバーと通信します。	ハンドヘルド機器はインターフェースとして機能し、言語モデル自体はサーバー上で実行されます。
PicoCalc	同じローカルAIワークフローの別のクライアントとしてPicowareを使用します。	利用できる機能は、現在のPicowareビルドとデバイス構成によって異なります。
Flipper Zero	ローカルAIサービスとの通信には、ネットワークリクエスト経路を使用します。	ネットワーク通信には、Wi-Fi対応のブリッジまたは開発ボードが必要です。

AIサーバーとしてZimaBoard 2を使う理由

このプロジェクトの興味深い点は、ZimaBoard 2でAIアプリケーションを実行できることだけではありません。小型組み込みプロジェクトのアーキテクチャを、ボードがどのように変えるかという点にあります。

Cardputer、PicoCalc、Flipper Zeroなどのデバイスは、携帯性と用途に特化した組み込みハードウェアを中心に設計されています。インターフェース、スクリプト、ファームウェアの実験、ネットワークツール、ポータブルアプリケーションに役立ちますが、搭載リソースは一般的なAIワークステーションよりはるかに限られています。

ZimaBoard 2ミニホームサーバーは、有線ネットワーク、ストレージ接続、PCIe拡張に対応した独立したx86ホストを提供します。これにより、より負荷の大きいサーバー処理を別の場所に移し、ハンドヘルドデバイスを小型に保つことができます。

JBlankedのワークフローでは、ZimaBoard 2がZimaOSを実行し、Ollamaがローカル言語モデルサービスを提供します。このサービスがローカルネットワーク上で利用可能になると、対応デバイスは、それぞれのハンドヘルド機器がモデルをホストするのに十分な計算能力やメモリを備えていなくても、サービスと通信できます。

この動画では、実演されたサーバー構成に関する重要な点も示されています。Ollamaの動作中、ZimaOSのシステムダッシュボードには、12GBのVRAMを搭載したNVIDIA GeForce RTX 3060が表示されています。つまり、デモで示された性能は、CPUのみのZimaBoard 2テストではなく、GPUを搭載したローカルサーバーの環境を前提に理解する必要があります。

システムダッシュボードにNVIDIA GeForce RTX 3060と12GBのVRAMが表示された、ZimaOS上で動作するOllama

ZimaOS環境内でOllamaが動作しています。背後に表示されているシステムダッシュボードには、NVIDIA GeForce RTX 3060と12GBのVRAMが表示されており、実演されたローカルAIサーバーでGPUアクセラレーションが利用可能であることがわかります。

ローカルAI接続の仕組み

基本設計は、次の3つの層として理解できます。

サーバー層: ZimaBoard 2がZimaOSを実行し、Ollamaをホストします。
Agentまたはネットワーク層: PicowareまたはFlipperのネットワークスタックが、組み込みデバイスとローカルサーバー間でリクエストを送信します。
デバイス層: Cardputer-ADV、PicoCalc、またはFlipper Zeroが物理インターフェースを提供し、デバイス固有のアクションを実行します。

この分離は、すべてのハードウェア上で言語モデルを直接実行する必要がないという点で有用です。各デバイスのファームウェアは対応する機能を公開し、サーバーはリクエストの解釈や開発タスクの支援に使用されるモデル機能を提供できます。

Cardputer-ADVとPicoCalcがPicoware Agentを使用

JBlankedのPicowareプロジェクトは、Cardputer-ADV、PicoCalc、Flipper Zero、その他のESP32またはRaspberry Pi Picoベースのデバイスをサポートするオープンソースのファームウェア環境です。

この実験で重要なコンポーネントはPicoware Agentです。Agentは単なる汎用チャットウィンドウではなく、さまざまな操作コンテキストを備えたLLM搭載インターフェースを提供します。

ドキュメントに記載されたモードには、一般的なチャット、Picowareアプリケーションの作成や編集に特化したApp Creator、そして情報やコマンドを扱えるデバイス管理機能が含まれます。これらの機能をローカルサーバー上のOllamaインスタンスに接続することで、小型デバイス上でモデルの処理を行わずに、ハンドヘルドデバイスでAI支援による開発ワークフローを実現できます。

Flipper ZeroがローカルAIサーバーにリクエストを送信

Flipper Zeroは、異なる操作パターンに従います。動画では、JBlankedがFlipperに取り付けたWi-Fi対応開発ボードを介して、デバイスからローカルモデルへ構造化されたリクエストペイロードを準備する様子を紹介しています。

画面に表示されたペイロードには、モデル欄として「 qwen3.5:9b。これは役割分担を明確に示しています。Flipperがリクエストを準備して送信し、選択した言語モデルは、より高性能なローカルサーバー上で実行されます。

Flipper Zeroが、Wi-Fi開発ボードを取り付けた状態で、qwen3.5:9bモデル向けのローカルAIリクエストペイロードを入力しています。

Flipper ZeroがローカルAIサービス向けのリクエストペイロードを準備しています。画面にはモデル欄に「 qwen3.5:9b一方、Wi-Fi対応の開発ボードがデバイスの上部に取り付けられています。

この区別は重要です。Flipperは完全な言語モデルをローカルで実行しているわけではありません。その役割は、携帯可能なインターフェースとネットワーク経路を提供することであり、Ollamaと選択したモデルはサーバー上で実行されます。

ローカルAI Agentで実際にできることは？

ハンドヘルドデバイスをLLMに接続することがより興味深くなるのは、モデルが質問に答える以上のことをできる場合です。JBlankedは、組み込み開発ワークフローの一部としてAIサーバーを実演しています。

Picowareアプリを作成する

Picowareには、AI Agent用のApp Creatorコンテキストが含まれています。これにより、開発者は自然言語でアプリケーションや変更内容を説明し、モデルを使って対応するPicowareアプリケーションの作成や編集を支援させることができます。

デモでは、起動時に「hello from youtube」という挨拶を表示するシンプルなアプリケーションをApp Creatorに作成させています。Agentは、要求された動作とインターフェースの仕組みを構造化して説明します。

Flipper ZeroとCardputer-ADVの横で、「hello from youtube」アプリケーション用のPicoware App Creatorを実行するPicoCalc

PicoCalc上で動作するPicowareのApp Creator。Agentは「hello from youtube」と表示するアプリケーションのリクエストを処理しており、Flipper ZeroとCardputer-ADVがデバイスの横に置かれています。

これにより、アイデアからプロトタイプまでの距離を縮められます。特に、小さな画面上で大量のソースコードを直接入力・編集するのが煩雑になりがちなデバイスでは有効です。

AIが生成したコードにもレビューが必要です。一見もっともらしい出力でも、誤ったAPI、不完全なエラー処理、安全でない前提、または対象ハードウェアと一致しない動作が含まれている可能性があります。

ファームウェアと開発情報を確認する

Agentのワークフローは、開発アシスタントとしても利用できます。ハンドヘルドデバイスを従来型のチャットクライアントとして扱うのではなく、ローカルモデルの回答を、デバイスやそのファームウェアが提供する情報と組み合わせられます。

この方法は、手動でログやドキュメント、コマンド出力を確認するよりも、Agentに特定のリクエストを解釈させる方が速い場合がある小さなディスプレイで、特に役立ちます。

デバイスを管理する

PicowareのAgentフレームワークには、デバイス管理機能も含まれています。モデルは、ユーザーが手動で実行するテキストを返すだけでなく、ファームウェアが提供するツールを使って処理できます。

動画内の一例では、「近くにネットワークはいくつありますか」と尋ねています。デバイスマネージャーは、近くで利用可能なWi-Fiネットワークが6つあると回答しており、Agentが一般的なモデル知識だけに頼らず、デバイスレベルの情報を使って実用的なリクエストに答えられることを示しています。

Flipper ZeroとCardputer-ADVの横で、近くのWi-Fiネットワークを6つ検出したPicoCalc Picowareデバイスマネージャー

PicoCalc上のPicowareデバイスマネージャーが、「近くにネットワークはいくつありますか」という質問に回答しています。インターフェースには近くのWi-Fiネットワークが6つ表示されており、エージェントがローカルAIとデバイスから取得した情報を組み合わせられることが分かります。

ここで、AIエージェントは通常のチャットボットとは異なります。言語モデルが解釈と指示のレイヤーを提供する一方で、実際に利用できるデバイス操作や情報源を決めるのはファームウェアです。

小型デバイスに共有ローカルAIサーバーが役立つ理由

このアーキテクチャは、組み込みAIプロジェクトにおける基本的なミスマッチに対応します。最も持ち運びやすいデバイスほど、言語モデルに利用できる計算能力が少ないという問題です。

共有サーバーを使うことで、このトレードオフが変わります。開発者はポケットサイズのデバイスに物理インターフェースを維持しながら、ネットワーク経由でより高性能なローカルマシンにアクセスさせられます。

AIをハンドヘルド上で直接実行する	ZimaBoard 2をAIサーバーとして使う
計算処理は組み込みプロセッサーに限定されます。	AI処理を、専用のx86サーバーと、そこで利用可能なアクセラレータハードウェアに移せます。
モデルサイズはデバイスのメモリによって大きく制限されます。	サーバーは、システムメモリ、GPU VRAM、モデルファイル用ストレージを自身で利用できます。
各デバイスに独自のAI実装が必要です。	複数のクライアントで1つのローカル推論サービスを共有できます。
モデルを更新するには、すべてのデバイスに変更を加える必要がある場合があります。	モデルはサーバー側で一元管理できます。
ハンドヘルドは、インターフェースと推論の両方の処理を担う必要があります。	ハンドヘルドは、インターフェース、ファームウェア、ネットワーク、デバイス固有の機能に集中できます。

1つのAIバックエンド、複数のメーカーデバイス

JBlankedの実験で特に有用な考え方の一つは、ZimaBoard 2が単一のフロントエンドに縛られないことです。PicoCalcとCardputer-ADVはPicowareを通じて参加でき、Flipper Zeroも独自のネットワークワークフローを介して同じローカルAI環境と通信できます。

これにより、サーバーはより大きなメーカーワークベンチで再利用できるパーツになります。新しいマイコンやポータブルコンピューターごとにAI環境を再構築する代わりに、開発者は推論サービスを一元化し、各デバイスに適したクライアント統合の構築に集中できます。

この構成は実験も簡単にします。サーバー上でモデルを変更してもハンドヘルドを交換する必要はありません。また、ハンドヘルドのファームウェアはAIランタイムから独立して進化させられます。

この実験が証明すること、そして証明しないこと

JBlankedの構築例は、ローカルAIを組み込み開発に取り入れる方法を示す有用なデモンストレーションです。ただし、アーキテクチャと、性能やセキュリティに関する保証は区別して考える必要があります。

実験が示すこと	保証されるものではない
ZimaBoard 2は、組み込みデバイスのクライアント向けにローカルOllamaホストとして動作できます。	デモ環境で示されたGPUがなければ、同じパフォーマンスが得られるとは限りません。
ZimaOSのデモ環境では、12GBのVRAMを搭載したNVIDIA GeForce RTX 3060が認識されています。	すべてのモデルが12GBのVRAMに収まり、同じ速度で動作するとは限りません。
PicoCalcとCardputer-ADVは、ローカルAIワークフローの一部としてPicowareを利用できます。	すべてのPicoware機能やモデルが、対応するすべてのデバイスで同じように動作するとは限りません。
Flipper Zeroは、ネットワーク機能を備えた構成を通じて、ローカルAIサーバーに構造化されたリクエストを送信できます。	Flipper Zero自体が言語モデルを実行しているわけではありません。
AIエージェントは、アプリ作成やデバイス管理のワークフローを支援できます。	AIが生成したコード、解釈、コマンドが自動的に正しい、または安全であるとは限りません。
1台のローカルサーバーで、複数の小型デバイス用インターフェースをサポートできます。	ローカルネットワークによって、認証、分離、または完全なプライバシーが自動的に提供されるわけではありません。

ローカルでも設定が不要になるわけではない

Ollamaをローカルで実行すれば、すべての推論リクエストをホスト型チャットボットサービスに送信する必要はなくなりますが、システム全体には通常のサーバーおよびネットワーク計画が依然として必要です。

初期モデルとアプリケーションパッケージをインストールし、ハンドヘルドデバイスがサーバーにネットワーク接続できるようにする必要があります。また、公開するサービスは、想定するネットワーク境界を踏まえて設定してください。デバイス管理機能を有効にする前に、AIエージェントが呼び出せるツールを正確に確認する必要もあります。

アクセラレーターの構成も重要です。JBlankedのZimaOSダッシュボードに表示されているRTX 3060には12GBのVRAMが搭載されているため、モデルの選択では、利用可能なGPUメモリ、ランタイムのサポート、想定するワークロードのパフォーマンス要件を引き続き考慮する必要があります。

コード生成の用途では、バックアップやバージョン管理を維持することが特に重要です。AIの支援による編集でアプリケーションやファームウェア設定が使用できない状態になった場合、開発者は既知の動作状態に戻れる必要があります。

このような構成を検討すべき人

このアーキテクチャは、組み込みデバイスを扱っている一方で、すべてのプロジェクトをクラウドAPI統合にしてしまうことなく、ローカルLLMを試したい開発者やメイカーにとって特に興味深いものです。

次のような用途に役立つ可能性があります。

Picowareアプリケーションを開発しているCardputerおよびPicoCalc開発者。
ネットワーク接続ツールを試しているFlipper Zeroユーザー。
テスト対象のハードウェアの近くでAI支援を利用したい組み込み開発者。
ローカルサーバーで実用的な別のワークロードを探しているホームラボユーザー。
複数の低消費電力デバイスで1つのAIバックエンドを共有したいメイカー。

たまにチャットやコード生成を利用するだけで、サーバーの管理を望まないユーザーにとっては、クラウドAIサービスのほうが簡単な場合もあります。モデルサイズと推論速度が主な優先事項である場合は、より大型のワークステーションや、より強力なGPU搭載システムのほうが適していることもあります。

ZimaBoard 2のアプローチは、AIサービスを同じホームラボ内に置き、そのサービスを複数の独立したプロジェクトから利用できるようにすることが目的なら、さらに魅力的になります。

メイカーラボ向けのローカルAIハブを構築する

JBlankedのプロジェクトは、ローカルAIの有用な方向性を示しています。すべての小型デバイスで言語モデルを実行できるかを問うのではなく、それらのデバイスが、より適した場所で実行されている共有モデルを利用できるかを問うのです。

ZimaOSでOllamaをZimaBoard 2上でホスティングし、PicowareがPicoCalcやCardputer-ADVなどのデバイスにAI支援インターフェースを提供し、ネットワーク対応のワークフローによってFlipper Zeroも同じ環境に組み込むことで、このシステムは組み込み機器の実験に対応する柔軟なローカルAIハブになります。

4つのデモは、サーバーを完全なシステムとして評価すべき理由も示しています。ハンドヘルドデバイスがインターフェースとハードウェア固有の機能を提供し、Ollamaがモデル提供レイヤーを担い、ZimaOSで認識されるGPUがローカルAIワークロードに追加の計算リソースを提供します。

同じプラットフォームでローカルモデルに何ができるのかを別の角度から確認するには、ZimaBoard 2ローカルAIアシスタントのテストをご覧ください。コンパクトサーバーハードウェア、モデルサイズ、ストレージ、AIワークロードの関係を検証しています。

セットアップとデバイスのワークフローを直接確認するには、JBlankedの完全版動画をご覧ください。Agentと対応デバイスの関係を理解したい場合は、GitHubのPicowareプロジェクトもご覧ください。

コンパクトサーバーやローカルAI、ユニークなハードウェアを使って、他のビルダーが何をしているのか見てみませんか？ ZimaSpace Discordコミュニティに参加して、さらに多くの構築例を見たり、セットアップを比較したり、自分の実験を共有したりしましょう。