MENU
シニアが日々の課題をAIを使って解決しようとするサイト
  1. ホーム
  2. プログラミング
  3. 【Arduino UNO Q】 Arduino App CLIの概要

【Arduino UNO Q】 Arduino App CLIの概要

プログラミング 電子工作 ＡＩ

Arduino UNO Qを最初に取り上げた下記の記事「Arduino UNO Qと開発環境 Arduino App Lab」で、Arduino App CLIについても触れていたが、本記事で追加調査を行ったので紹介する。
また、下記の記事「Zephyr RTOS: 組込み開発の新パラダイムを深掘り」では、MCUがZephyrのOS上で動作し、そのOSの機能の1つにLLX（OS稼働中にコンパイル済みのコードモジュールを動的にメモリへロードし、実行する仕組み）があることを紹介したが、Arduino App CLIにも関連する機能なので、これについても追加調査した。

あわせて読みたい
Arduino UNO Qと開発環境 Arduino App Lab Linuxを動かすMPUと、リアルタイム制御向けMCUが同居した「Arduino UNO Q」を調査した
あわせて読みたい
Zephyr RTOS: 組込み開発の新パラダイムを深掘り Arduino UNO QのリアルタイムOS「Zephyr 」について調べた

（注）本記事の内容は正確性を保証するものではない。

（2026年1月15日 追記）YouTube動画を追加しました。　https://youtu.be/rJEmsXTuC5A

目次

Arduino App CLIの位置付け

Arduino UNO QのArduino CLIがソフトウェアのどの階層に位置するかを示す図があったと思います。
それを探して解説してください

ChatGPT 5.2 Thinkingの回答

https://www.qualcomm.com/developer/blog/2025/10/meet-arduino-uno-q-qualcomm-dragonwing-fueled-ai-in-a-blink

了解です。公式ドキュメントやGitHub/ブログ等をWeb検索して、その「UNO QのArduino CLIがどの階層にあるか」を示す図（または同等のアーキテクチャ図）を特定して提示します。

探されていた「Arduino UNO Qで、Arduino CLI（/CLI系ツール）がどの階層にいるか」を示す“ソフトウェアスタック図”としては、上の Qualcomm公式ブログ記事に掲載されている図 が該当します。

この図の読み方（上→下の階層）を、要点だけ整理するとこうなります。

  • Arduino App Lab（最上位）
    UNO Q向けの統合環境。ここで「Arduino Apps（アプリ）」として、Linux側（Python等） と MCU側（Sketch/C++） を一体として扱うイメージです。(docs.arduino.cc)
  • Arduino Apps（アプリの中身）
    • Python（MPU側）
    • Sketch（MCU側）
    • 両者をつなぐ RPC（Arduino Bridge）
    • 便利機能として Arduino Bricks（部品） と Sketch Libraries
      という構造になっています。(docs.arduino.cc)
  • Arduino App CLI（その下の層）
    UNO Q上で動作し、アプリ（Linux側＋MCU側）を 管理・起動/停止・ログ取得 など“運用するためのCLI”として位置づけられています（GitHubの説明もこの位置づけ）。(GitHub)
  • Linux OS（Debian）→ ハード（QRB2210）
    MPU側は Debian Linux 上で動きます。(docs.arduino.cc)
  • MCU側（STM32U585 / Zephyr）
    MCU側は Zephyr上でArduinoスケッチが動く という説明になっています。(docs.arduino.cc)

じゃあ「Arduino CLI」はどこ？

UNO Qの文脈で混同されやすいのですが、

  • arduino-cli（一般的なArduino CLI） は、基本的に「スケッチをビルド/書き込みするための開発ツール」で、MCUの“実行時レイヤ”ではなく、ビルド・デプロイ側のレイヤにいます。公式も「Arduino CLIをワークフローに統合できる」と説明しています。(docs.arduino.cc)
  • UNO Qでは、アプリ全体を扱う都合上、arduino-app-cli（App Lab CLI） が前面に出てきて、記事でも「App Lab CLIがMPU+MCU両方をオーケストレーションする」と説明されています。また、MCU側の sketch.yaml は Arduino CLIのスケッチ用プロジェクトファイル とされています。(Shawn Hymel)

要するに、この図でいう位置づけは
（Debianの上で）Arduino App CLI / App Lab が“アプリ運用の中核”、その内部で MCUスケッチのビルド/管理にArduino CLI相当の仕組みが使われる（そして sketch.yaml がその前提）——という捉え方が一番ズレません。(Shawn Hymel)

ARDUINODOCSサイトのCLI実画面解説

添付画像は、Arduino UNO QのCLI画面で、アプリのログを表示させた画面だそうです。
画面の内容について説明してください。

https://docs.arduino.cc/software/app-lab/tutorials/cli/?utm_source=chatgpt.com

ChatGPT 5.2 Thinkingの回答

画像内のコマンド行と、その結果として出ているログの意味を、行ごとに噛み砕いて説明します。

画面は、UNO Q 側のターミナルで Arduino App（App Lab のアプリ）のログを、CLI コマンドで表示している様子です。
上から順に読むとこういう意味です。

1) 実行したコマンド

arduino-app-cli app logs /home/arduino/ArduinoApps/test --all

  • arduino-app-cli：UNO Q のアプリを操作するための CLI
  • app logs：指定したアプリのログを表示するサブコマンド
  • /home/arduino/ArduinoApps/test：対象アプリの場所（この例では “test” アプリ）
  • --all：ログを「全部（過去分も含めて）」出す指定（その分、同じ起動ログが複数回見えることがあります）

2) 表示されているログ（[main] の意味）

各行の先頭にある [main] は、アプリのメイン側（実行主体）のログであることを示していると考えてOKです。

3) 各行の内容（行ごとの説明）

  • [main] Using CPython 3.13.5 interpreter at: /usr/local/bin/python
    → アプリ実行に使う Python が CPython 3.13.5で、実体は /usr/local/bin/python。
  • [main] Creating virtual environment at: .cache/.venv
    → 依存ライブラリ用に 仮想環境（venv）を .cache/.venv に作成している。
  • [main] Activating virtual environment
    → その仮想環境を 有効化している。
  • [main] Running user: arduino home: /tmp/arduino
    → 実行ユーザーは arduino。ホームディレクトリは /tmp/arduino になっている
    （一時領域にホームを切って動かす “サンドボックス寄り” な実行形態の雰囲気があります）。
  • [main] Hello World!
    → アプリ（または起動スクリプト）が出した標準出力ログ。典型的な動作確認メッセージ。

4) 同じ塊が2回出ている理由

Activating virtual environment 〜 Hello World! が 2回繰り返し出ています。これはだいたい次のどれかです。

  • アプリが 2回起動された履歴が --all で両方出ている（最も自然）
  • 何らかの理由で 再起動（リスタート）が走った
  • ログに「起動時の定型出力」が残っていて、それをまとめて表示している

最後にプロンプト arduino@uno-q:~$ に戻っているので、コマンド自体は正常に終了しています。

添付画像は、Arduino UNO QのCLI画面で、アプリの一覧を表示させた画面だそうです。
画面の内容について説明してください。

https://docs.arduino.cc/software/app-lab/tutorials/cli/?utm_source=chatgpt.com

ChatGPT 5.2 Thinkingの回答

この画面は arduino-app-cli app list の出力なので、列（ID/NAME/ICON/STATUS/EXAMPLE）が何を意味し、表示されている各アプリがどんな種類かを整理して説明します。

この画面は、UNO Q 上のターミナル（adb shell のようなシェル）で インストール済みアプリの一覧を、CLIで表示した結果です。

1) 実行したコマンド

arduino-app-cli app list

  • arduino-app-cli：UNO Q の App（App Lab アプリ）を管理するCLI
  • app list：登録されているアプリを一覧表示

プロンプトが arduino@kallo:/ $ になっているので、端末名（ホスト名）が kallo の環境で実行している、という情報も読み取れます。

2) 表の列の意味（画面に出ている見出し）

一覧は次の列で出ています。

  • ID
    アプリの識別子。例：examples:weather-forecast や user:my_app
    examples: はサンプル（同梱/公式例）、user: はユーザーが作成・追加したアプリ、という区別に見えます。
  • NAME
    人間が読むためのアプリ名（表示名）。
    例：Weather forecast on LED matrix など。
  • ICON
    アプリに紐づくアイコン（絵文字で表示されている）。
  • STATUS
    現在の状態。少なくとも running（実行中）と stopped（停止中）が表示されています。
    画像では先頭の Real-time Accelerometer が running、それ以外は stopped が多いです。
  • EXAMPLE
    そのアプリが「サンプル扱い」かどうかの真偽値。true/false で出ています。
    examples: の行は基本 true、user: の行は false になっています（ユーザー作成なので）。

3) 表示されているアプリの内容（ざっくり分類）

画面に見えている範囲だけでも、次のようなサンプルが入っているのが分かります。

  • センサ/表示系
    • Real-time Accelerometer（加速度をリアルタイム表示っぽい）
    • Air quality on LED matrix
    • Weather forecast on LED matrix
    • Home climate monitoring and storage
  • AI/推論系（Edge Impulse的な例に近い名前）
    • Anomaly detection（Concrete crack detector）
    • Audio classification（Glass breaking sensor）
    • Image classification（Classify images）
    • Object detection（Detect objects on images）
    • Keyword spotting（Hey Arduino!）
  • ユーティリティ
    • System resources logger（CPU/メモリなどの記録系）
    • code-detector（QR/バーコードスキャン）
  • ユーザー作成アプリ
    • user:test-draw-3（NAME: TEST DRAW 3）
    • user:home-climate-monitoring-and-storage（同名のユーザー版がある）
    • user:my_app

「同じテーマのアプリが examples: と user: で並んでいる」もの（例：home-climate-monitoring-and-storage）があるので、サンプルをベースにユーザーが複製/改造して別IDで登録している状況が想像できます。

必要なら、この一覧から「特定のアプリの場所（パス）」「起動/停止」「ログ表示」へ繋げる典型操作（例：arduino-app-cli app start <ID> / ... stop <ID> / ... logs <パス or ID>）の流れも、画面の内容に合わせて整理できます。

アプリの保存・実行

これらのアプリはRAM上にあるのですか、それともストレージeMMC上にあるのですか

ChatGPT 5.2 Thinkingの回答

基本は eMMC（ストレージ）上に置かれていて、実行時に必要な分だけ RAMに展開・ロードされます。

  • アプリ本体（ソース、assets、設定、モデルファイルなど）
    → ふつうはファイルシステム上＝eMMC上に保存されています。
    app list は「インストール（登録）されているアプリ」を列挙しているので、これは 永続ストレージにあるものだと思ってOKです。
  • 実行中のアプリ（STATUS が running のもの）
    → 実行プロセスとして動くので、Python実行環境や読み込んだデータ、モデル、バッファ等は RAMを消費します。
    つまり「置き場所はeMMC、動作時はRAMも使う」という関係です。
  • ログに出ていた .cache/.venv や /tmp/arduino
    → これらは「実行のための作業領域」で、
    • .cache/.venv は ストレージ上のキャッシュであることが多い
    • /tmp は環境によって RAM上（tmpfs）のこともあれば、ストレージの場合もあります
      なので、ここは実機のマウント状況で変わります。

確認したい場合は、UNO Q のシェルで以下を見ると確実です（どこがRAM/tmpfsか、どこがeMMCかが分かります）：

mount | grep -E 'tmpfs|/tmp'
df -h

アプリの実体サイズ（ストレージ使用量）を見たいなら、アプリのディレクトリに対して：

du -sh /home/arduino/ArduinoApps/*

（パスは環境で違うことがあるので、実際にアプリが置かれている場所に合わせてください。）

eMMCに複数のアプリを保存しておいて、SSHでアプリ（スケッチ及びC++）の停止・起動や、PCへのログ出力を指示できるということですか

ChatGPT 5.2 Thinkingの回答

はい、App Lab の“Arduino Apps”としてパッケージされたもの（= Python側＋スケッチ/C++側を含むアプリ）であれば、

  • eMMC に複数アプリを置いておく
  • SSH 経由で 起動・停止を指示する
  • SSH 経由で ログをPCへ出力（保存）する

…は可能です。公式ドキュメントでも arduino-app-cli で Apps を起動/停止できる、という形で案内されています。 (docs.arduino.cc)

できること（App Lab “Apps” の範囲）

1) eMMCに複数アプリを保存

arduino-app-cli app list で出てくる examples: / user: のアプリは、通常 ストレージ（eMMC）上に存在し、実行時にRAMを使います（あなたが見た一覧表示はその「保存されているアプリ」を列挙しているイメージです）。 (docs.arduino.cc)

2) SSHで起動・停止

SSHでUNO Qに入って、次のように リモートから start/stop できます（下は典型例）。 (GitHub)

ssh arduino@<UNOQ_IP> "arduino-app-cli app start examples:home-climate-monitoring-and-storage"
ssh arduino@<UNOQ_IP> "arduino-app-cli app stop  examples:home-climate-monitoring-and-storage"

3) PCへのログ出力（取得・保存）

logs を SSH 越しに叩いて、PC側でリダイレクトすれば そのままファイル保存できます。 (GitHub)

ssh arduino@<UNOQ_IP> "arduino-app-cli app logs examples:home-climate-monitoring-and-storage" > unoq.log

重要な注意点（「スケッチ及びC++」の意味によって変わる）

ここがポイントです。

A) 「App Lab のアプリに含まれるスケッチ/C++」なら → 上の通りOK

UNO Q の Apps は「MPU側（Linux/Python等）」と「MCU側（Sketch/C++）」をひとまとめに扱う設計なので、起動/停止は“アプリ単位”で制御する、というのが基本です。 (docs.arduino.cc)

B) 「MCU単体のスケッチ（App Lab外）」だと → “停止/起動”は別の考え方

一般にMCUのスケッチはOSプロセスみたいに自由に stop/start というより、

  • 新しいスケッチを書き込む（置き換える）
  • リセットする
  • あるいは Zephyr の動的ロード（ELFロード）で差し替える

…という系になります。Zephyr系コアではスケッチをELFとして動的ロードする仕組みが説明されていますが、それをUNO Qで“SSHからどう操作するか”は、App Lab の管理経路に載っているかどうかで手段が変わります。 (Arduino Blog)

結論

  • はい：eMMCに複数の「Apps」を置いておいて、SSHで 起動/停止・ログ取得（PC保存）はできます。 (docs.arduino.cc)
  • ただし「スケッチ/C++」が App Labのアプリ内に含まれるものであることが前提（単体MCUスケッチは運用が別系統になりがち）です。 (Arduino Blog)

もし、いま扱っているのが ~/ArduinoApps/<名前> のようなフォルダ（app.yaml や sketch.yaml がある構成）か、MCU単体スケッチかが分かれば、あなたの用途に合わせて「SSHで叩くコマンド一式（起動/停止/ログ保存/再起動まで）」をそのまま貼れる形で整理します。

リモートで“スケッチ相当のコード”を転送・ロード・実行する

MCUはZephyr上で動作していると思いますが、Zephyrには、LLXという機能があり、OSが稼働中に、コンパイル済みのコードモジュールを動的にメモリへロードし、実行する仕組みを備えているそうですが、これにより、リモートでスケッチをロードして実行できるということですか

ChatGPT 5.2 Thinkingの回答

まずLLX/Zephyrの“動的ロード”が何を指すかを最新仕様で確認しつつ、UNO QのMCUがそれを採用している前提が妥当かを切り分けて説明します。

はい、原理的には「リモートで“スケッチ相当のコード”を転送して、MCU上でロードして実行」が可能になります。
ただし、あなたが書かれている 「LLX」＝ Zephyrの “LLEXT（Linkable Loadable Extensions）” を指している前提での話です。

Zephyr LLEXT で何ができるか

Zephyr の LLEXT は、OS（Zephyr本体）が動いたまま、

  • 事前にコンパイルした ELF形式の拡張（モジュール）を
  • 検証して（任意）ロードし
  • 既存のZephyrバイナリにリンクし
  • 関数を呼び出して実行
  • さらに不要ならアンロード

…という仕組みです。 (Zephyr Project Documentation)

「ArduinoのZephyr系コア」はまさにこの方式

Arduino 側も「ZephyrOSベースのコア」で、

  • スケッチは 単体の巨大ファームではなく
  • freestanding な ELFとして生成され
  • それを 事前に書き込まれた Zephyrベースの“loader” が動的に読み込む

という方式を説明しています。 (Arduino Blog)

ArduinoCore-zephyr のREADMEにも同じ趣旨が明記されていて、従来の「ブートローダで丸ごと書き込む」形と違い、loaderがスケッチのロードを担うと書かれています。 (GitHub)

つまり「リモートでスケッチをロードして実行」できる？

できます（ただし前提条件つき）。

前提条件（重要）

  1. MCU側に LLEXT対応のloaderファームが入っていること
    （初回は “Burn bootloader / loader導入” が必要な流れになっています） (GitHub)
  2. リモートからELFを届ける経路があること
    （例：UART、ストレージ、ネットワークなど。Arduino側は「UART等で置換できる」旨も言及しています） (Zephyr Project)
  3. ELFが そのボード向けにビルドされ、loaderが公開しているシンボル範囲で動くこと
    未公開のZephyr関数を呼ぶと Undefined symbol ... になり、必要ならエクスポート追加→loader再ビルドが必要、とされています。 (GitHub)

UNO Q での「リモート実行」の実際（イメージ）

UNO Q は Linux側（MPU）に SSH できるので、典型的には

  • PC →（ssh/scp）→ UNO Q（Linux側）へアプリ/スケッチを配置
  • UNO Q上でコマンド実行して、MPU側のPythonと、MCU側のスケッチをロードして起動

という運用になります（実例として、SSHして起動する流れが紹介されています）。 (Shawn Hymel)

注意点（期待しすぎ防止）

  • 何でも自由に“その場で差し替え”というより、loaderが許可する範囲・メモリ枠・公開シンボルの制約を受けます。 (GitHub)
  • スケッチが大きいと メモリ不足になり得る（スタックが大きい等）こともREADMEで触れられています。 (GitHub)
  • “OSが落ちずに完全ホットスワップ” は設計次第で、Arduino側の実装では「loaderは常駐し、スケッチは入れ替え」という方向性です。 (GitHub)

必要なら、あなたのUNO Q環境で 「MCU側のloaderが入っているか」と 「SSH経由でスケッチを差し替えて動かす最短手順」を、今のCLI（arduino-app-cli）の使い方に合わせて手順化できます。

「SSH経由でスケッチを差し替えて動かす最短手順」を教えてください

ChatGPT 5.2 Thinkingの回答

以下は「SSH経由でスケッチ（C++）を差し替えて、UNO Q上で動かす最短手順」です。
ポイントは、UNO Qの “App” は ~/ArduinoApps/<アプリ名>/ に置いたプロジェクト一式（app.yaml + python/ + sketch/）を、arduino-app-cli が ビルド→更新→起動まで面倒を見てくれる点です。
(Shawn Hymel)

最短手順（ローカルで編集→scp→SSHで再起動→ログをPCへ）

0) 前提（プロジェクト構造）

最低限、こんな構造になっている必要があります（名前も重要）。 (Shawn Hymel)

<project>/
├── app.yaml
├── python/
│   ├── main.py
│   └── requirements.txt   (任意)
└── sketch/
    ├── sketch.ino
    └── sketch.yaml        (任意だが推奨)

1) ローカルPCでスケッチを編集

例：sketch/sketch.ino を修正（必要なら sketch/sketch.yaml も）。

2) UNO Qへコピー（差し替え）

「全部送る」のが最短で確実です（サイズが大きい場合は sketch/ だけでもOK）。

# 例：プロジェクト直下で
scp -r * arduino@<UNO_Q_IP>:~/ArduinoApps/<APP_NAME>/

このやり方（~/ArduinoApps/... へ scp -r）が、UNO Q CLI運用の典型として紹介されています。 (Shawn Hymel)

3) SSHでUNO Qへ入り、いったん停止→起動（＝更新反映）

ssh arduino@<UNO_Q_IP>

# 停止（動いていれば）
arduino-app-cli app stop ~/ArduinoApps/<APP_NAME>

# 起動（ここでスケッチ側・Python側の必要ビルド/更新が走る）
arduino-app-cli app start ~/ArduinoApps/<APP_NAME>

app start/stop が基本操作です。 (Shawn Hymel)

初回や依存が増えたときは、PythonライブラリやArduinoライブラリの導入で起動に時間がかかることがあります。 (Shawn Hymel)

4) ログをPCへ出力（保存）

ログはPC側でリダイレクトすれば一発で保存できます。

ssh arduino@<UNO_Q_IP> "arduino-app-cli app logs ~/ArduinoApps/<APP_NAME>" > unoq_app.log

app logs はこの用途で紹介されています。 (Shawn Hymel)

さらに「最短」にしたい場合（UNO Q上で直接編集→再起動）

VS Code Remote-SSH 等で ~/ArduinoApps/<APP_NAME>/sketch/sketch.ino を直接編集して、

arduino-app-cli app stop  ~/ArduinoApps/<APP_NAME>
arduino-app-cli app start ~/ArduinoApps/<APP_NAME>

だけでも差し替えできます（転送が不要）。 (Shawn Hymel)

うまく動かないときの超重要チェック（1点だけ）

起動ログに「python provisioning」等が出たあと動かない場合、Python側に App.run(...) が無いのが原因になりがちです（CLI記事でも注意されています）。 (Shawn Hymel)

必要なら、あなたのアプリ構成（~/ArduinoApps/<APP_NAME> の中身：app.yaml / sketch.yaml の有無、IDで起動しているかパスで起動しているか）に合わせて、そのままコピペで使えるコマンド列に整えて書き換えます。

今回は、Arduino App CLIについて、特にSSH経由でアプリを操作したり、スケッチを差し替えて動かしたりする方法の概略を調査した。Arduino App CLIについては、別途、別の観点で追加調査を行う。

プログラミング 電子工作 ＡＩ
App CLI Arduino Arduino App CLI ChatGPT GPT-5 GPT5 LLEXT LLX UNO Q Zephyr
目次