はじめに：AI エージェントが「机の上」に出てきた
AI エージェント（目的を伝えると、自分で手順を考えて道具を使いながら作業を進める AI）は、ここ 1〜2 年で活動の場所を広げてきました。最初は文章で答えるだけでしたが、次に Web ページを操作するようになり、さらに PC のアプリまで動かせるようになりました。
その次に来るのが、画面・ボタン・センサー・家電といった「手元の物理的な機械」です。2026 年 10 月 2 日（米国時間）、Meta はこの方向の取り組みとして Muse Gadgets を公開しました。Meta の AI エージェント「Muse」を、数百〜数千円のマイコン基板 ESP32 や小型 PC Raspberry Pi につなぐためのソフトウェア一式（SDK）で、ソースコードはオープンソース（Apache 2.0）です。
図1：AI エージェントの手が届く範囲。Muse Gadgets は ④ の「物理デバイス」を受け持ちます。重い推論はクラウドに任せ、手元の基板は入出力だけを担当する分担がポイントです
この記事では、Muse Gadgets を次の 3 つの観点から解説します。
- 何が公開されたのか：ESP32 用・Linux 用の 2 つの SDK、Meta 製の小型機「Muse Home Link」、家電の操作手順書（スキル）
- どういう仕組みで動くのか：デバイスとクラウド上の Muse が、どのような暗号化接続とメッセージでつながっているか（ソースコードを読んで確認）
- 日本から何ができるのか：Muse 本体は米国のみの提供です。それでも Mac だけで試せた範囲（UI シミュレーター、通信の模擬実験）を、実際の結果とあわせて紹介します
想定読者は、AI エージェントや IoT（モノのインターネット）に興味があるエンジニア、またはこれから電子工作で AI 機器を作ってみたい方です。ESP32 や Raspberry Pi を触ったことがなくても読めるように、用語には説明を添えます。
この記事の確認範囲
| 項目 | 内容 |
|---|---|
| 確認日 | 2026 年 10 月 4 日（日本時間） |
| 一次情報 | 公式サイト gadgets.muse.ai、GitHub facebookincubator/muse-gadget-sdk（コミット 693cde9、2026-10-03）、SDK トークン利用規約、Meta ニュースルーム（日本語版） |
| 報道 | TechCrunch、Engadget（2026-10-02） |
| 筆者の環境 | MacBook Pro（Apple M5 Max・メモリ 128GB）、macOS 26.6.2。ESP32 基板・Raspberry Pi は持っておらず、Muse のアカウントも作っていません |
| 実際に試したこと | UI シミュレーターのビルドと実行、Linux SDK のテスト、SDK 付属の「偽の Muse」との通信実験、ESP32 ファームウェアのビルドとテスト |
実機でのペアリングや、本物の Muse との会話は試せていません。記事中で「公式ドキュメントによると」と書いた部分は、筆者が動作を確かめたものではない点にご注意ください。
Muse Gadgets とは何か
そもそも「Muse」とは
Muse は、Meta が 2026 年 9 月 8 日（米国時間）に発表した個人向けの AI エージェントです。旅行の予約、フォームの入力、買い物などを利用者の代わりに進めます。Meta の日本語ニュースルームによると、Muse は利用者ごとに用意される専用の仮想マシン（Muse Secure VM）の上で動きます。仮想マシン（VM）とは、データセンターの中に作られた「その人専用のコンピューター」のようなものです。
提供地域は米国のみで、Meta は日本での提供について「現時点で未定」としています。基本機能は無料で、より多く使いたい人向けに有料プランがあります（報道では月 20 ドルと月 100 ドルの 2 種類）。
公開された 4 つの部品
Muse Gadgets は、この Muse に「体」を与えるための部品集です。公式サイトのトップページには、丸型の画面を持つ基板、M5Stack の小型端末、Muse Home Link、Raspberry Pi、E-Ink（電子ペーパー）ディスプレイが並んでいます。
公式サイト（gadgets.muse.ai、2026-10-04 筆者撮影）。中央の赤枠が 2 つの SDK、右の赤枠が Home Link の配布条件で「米国のみ・1 人 1 台・10 月発送・先着順」と書かれています
部品は大きく 4 つに分かれます。それぞれの役割を図にまとめました。
図2：4 つの部品は、どれもクラウド上にある利用者専用の Muse につながります
| 部品 | 中身 | 何ができるか |
|---|---|---|
| ESP32 Device SDK | C 言語のファームウェア（ESP-IDF 6.0.1 で作る） | 公式対応 17 機種の ESP32 基板を Muse の端末にする。ランプ・画面・マイク・スピーカー・センサーを使える |
| Linux Device SDK | Python のパッケージ musegadget | Raspberry Pi などの Linux 機を Muse の端末にする。Muse がコマンド実行・ファイルの読み書きをできる |
| Muse Home Link | Meta が作った USB-C 給電の小型機 | 家の Wi-Fi に入り、Muse がテレビやスピーカーなど家庭内の機器へ届くようにする |
| コミュニティ スキル | Markdown の説明書 43 本 | Philips Hue、Sonos、Roomba、プリンターなど、機器ごとの操作方法を Muse に教える |
ESP32 は、Wi-Fi と Bluetooth を内蔵した安価なマイコン（小さなコンピューターのチップ）です。電子工作や IoT 機器でよく使われ、開発用の基板なら数百円〜数千円で手に入ります。Raspberry Pi は、Linux が動く手のひらサイズの PC です。
Home Link は「Meta 自身の作例」
Muse Home Link は、Meta が自分たちの SDK で作った完成品です。報道によると、Meta Superintelligence Labs でプロダクトを率いる Nat Friedman 氏が発表し、最初に 5,000 台を製造しました。有効な Muse サブスクリプションを持つ米国の利用者に、1 人 1 台まで無料で配られます。
興味深いのは、Home Link の中身が ESP32 Device SDK と同じファームウェアだという点です。ESP32 SDK の開発者向け文書（AGENTS.md）には、このファームウェアが「Muse Home Link を動かしている」と書かれています。つまり、配布を受けられない人でも、対応する ESP32 基板を買えば Home Link と同じ機能を自分で組み立てられます。
日本から使えるのか
ここが日本の読者にとって一番気になる点だと思います。整理すると、できることは 3 段階に分かれます。
図8：日本から今できる範囲。①はアカウントなしで誰でも試せます
デバイスを Muse につなぐには、公式サイトで発行する SDK トークン（mgst_ で始まる文字列）が必要です。トークンの発行にはログインが必要で、実際に会話するには Muse アプリも必要です。Muse が米国のみで提供されている以上、日本から本物の Muse につなぐのは現時点では難しいと考えるのが自然です（筆者はログインを試していません）。
一方、ソースコードは Apache 2.0 で誰でも読めて、動かせます。後半で紹介するように、Mac だけで画面のシミュレーターを動かしたり、デバイスと Muse の間の通信を模擬したりできました。仕組みを理解して基板を選んでおけば、日本で提供が始まったときにすぐ試せます。
仕組み：デバイスはどうやって Muse とつながるのか
ここからは、GitHub のソースコードとドキュメントを読んで分かった仕組みを説明します。Muse Gadgets を理解するうえで一番大事なのは、デバイスの側からクラウドへ接続しに行くという設計です。
全体の流れ
まず、デバイスが Muse とつながるまでの流れを見てください。
図3：最初だけスマホで設定し、あとはデバイスが自分から Muse の VM へ接続します
- Bluetooth で初回設定：スマホの Muse アプリとデバイスを Bluetooth（BLE）でつなぎ、暗号化されたペアリングを行います。このとき Wi-Fi の情報もデバイスに渡します
- Wi-Fi に参加：デバイスが家の Wi-Fi につながります
- デバイスから外へ接続：デバイスがクラウド上の Muse VM に向けて、暗号化された接続（WebSocket の上で Noise プロトコル）を開きます
- 命令と結果の往復：以後、Muse からの命令とデバイスからの結果は、すべてこの 1 本の接続を通ります
3 のポイントは、接続を始めるのがデバイスの側だということです。家のルーターは、外から内への接続は通常通しませんが、内から外への接続は通します。そのため、ルーターのポート開放（外からの接続を許可する設定）は不要です。スマートスピーカーなど多くの家電と同じ考え方です。
ペアリングの暗号には、楕円曲線暗号による鍵の交換（P-256 ECDH）、鍵の導出（HKDF-SHA256）、データの暗号化（AES-256-GCM）が使われています（Linux SDK の pairing.py より）。
Muse との間を流れるメッセージ
では、接続の中では何がやり取りされているのでしょうか。Linux SDK には、テスト用に「偽の Muse VM」が付属しています。これを使って、筆者の Mac で実際の暗号化セッションを張り、流れたメッセージを記録しました（手順は後半の「Mac で試す」で紹介します）。
図4：筆者の Mac で記録したメッセージの順番。経過時間は同じプロセス内での値で、実際のネットワーク遅延は含みません
流れを順に説明します。
| 順番 | メッセージ | 向き | 意味 |
|---|---|---|---|
| 1 | Noise XX ハンドシェイク | 双方向（3 メッセージ） | お互いの鍵を確かめ、暗号の鍵を決める |
| 2 | POST /link-control | デバイス → Muse | 制御用の通り道を開く。開いたまま使い続ける |
| 3 | link.register | デバイス → Muse | 「自分はこんなコマンドを持っています」と一覧（commands_v2）を送る |
| 4 | link.invoke | Muse → デバイス | Muse がコマンドを呼び出す |
| 5 | link.result | デバイス → Muse | 実行結果を JSON で返す |
| 6 | POST /chat/stream | デバイス → Muse | デバイスの側から Muse のチャットにメッセージを送る |
| 7 | link.unpaired | Muse → デバイス | 登録が外された |
3 の link.register で送るコマンド一覧には、コマンドの説明文と、必須・任意の引数（名前・型・説明）が入ります。これは、AI に道具を使わせる仕組み（Function Calling や MCP のツール定義）とよく似た形です。デバイスが「自分にできること」を説明文つきで申告し、Muse がそれを道具として呼び出す、と考えると分かりやすいでしょう。
6 の /chat/stream は逆向きの経路です。デバイスの側から「ガレージのドアが 1 時間開いたままです」のようなメッセージを Muse に送れます。ボタンやセンサーをきっかけに Muse を動かしたいときは、この経路を使います。
なお、ソースコードの中には hatch という名前があちこちに残っています（接続先のホスト名 hatch.metaaivm.com など）。Linux SDK の文書には「利用者には Hatch という名前を見せない」と書かれており、Muse の開発中の呼び名だったと思われます。
Home Link の「家庭内トンネル」
Muse Home Link のもう 1 つの特徴が、家庭内トンネル（home-network tunnel）です。これがあると、クラウドにいる Muse が、家の中のテレビや照明に HTTP で直接話しかけられるようになります。
図5：家庭内トンネルの仕組み。制御用とトンネル用の 2 つの流れが、1 本の暗号化接続に同居しています
ソースコード（noise_tunnel.h、app.c、tunnel_netif.c）を読むと、次のような作りになっていました。
- トンネル用の接続を別に張るのではなく、制御用と同じ暗号化接続の中に、2 本目の流れ（
/link-tunnel）を通している - その流れには IP パケット（ネットワーク通信の最小単位）がそのまま載る。デバイス側の住所は
10.42.0.1、Muse VM 側は10.42.0.2 - デバイスは NAPT（送り主の住所を自分の住所に付け替える仕組み。家庭用ルーターと同じ技術）で、届いたパケットを家の LAN に流す
つまり、Home Link は「Muse 専用の小さなルーター」のように振る舞います。Muse から見ると、家の LAN にある機器へ普通に HTTP でアクセスできる状態になるわけです。
では、Muse はどの機器にどんなリクエストを送ればよいかを、どうやって知るのでしょうか。そこで使われるのがスキルです。たとえば Elgato の照明用スキルには、「ポート 9123 の /elgato/lights に PUT で {"on":1} を送ると点灯する」「明るさは 3〜100 が有効」「色温度はミレッド（1,000,000 ÷ ケルビン）で指定する」といった手順と注意点が書かれています。2026 年 10 月 4 日時点で、テレビ、スピーカー、照明、プラグ、プリンター、ロボット掃除機など 43 本が登録されています。
| 分類 | スキルの例 |
|---|---|
| 照明・プラグ | Philips Hue、Lutron、Shelly、TP-Link Kasa、Elgato Key Light |
| スピーカー・テレビ | Google Cast 対応機器、Sonos、Apple TV 4K、HomePod mini、Samsung・LG のテレビ |
| プリンター・家電 | Brother・Epson・HP のプリンター、Dyson、Miele の食洗機、3D プリンター（Moonraker） |
| 掃除機・ゲートウェイ | Roomba、Roborock、Zigbee2MQTT、ESPHome |
スキルは Meta の公式な連携ではなく、コミュニティが書いたものです（README に明記）。使うときは、Muse のチャットに GitHub リポジトリのリンクを渡すか、該当する SKILL.md の中身を貼り付けます。
注意点として、トンネルにはメモリを多く使うため、PSRAM（追加の作業用メモリ）を持たない基板ではトンネルが使えません。公式の対応表では、ideaspark、Waveshare C6、M5Stack Cardputer ADV の 3 機種が該当します。これらの基板は Muse から本体を操作することはできますが、家電までは届きません。
ペアリングとランプの色
ESP32 版のペアリングは、本体のランプの色で進み具合が分かるようになっています。
図6：ペアリングの流れとランプの色（公式 README の表をもとに作成。筆者は実機で未確認）
手順は次のとおりです。
- ファームウェアを書き込むと、ランプが橙色でゆっくり点滅します（設定待ち）
- Muse アプリで「設定 › デバイス › 開発者モード」をオンにし、「デバイスを追加」から
MuseGadget-XXXXXXを選びます - ランプが青色でゆっくり点滅したら、本体の BOOT ボタンを押して本人確認をします
- 青色の点灯は Wi-Fi と Muse に接続中、緑色になれば完了です
ボタンを 5 秒長押しすると初期化できます。Raspberry Pi にはボタンがないため、Linux 版ではアプリ側の確認がボタンの代わりになり、ペアリングはインストーラーか sudo musegadget pair を実行してから 10 分間だけ受け付けます。
公式 README は、コミュニティ製のデバイスなのでメーカーの検証がなく、通信の途中に割り込む攻撃（中間者攻撃）は防げないと明記しています。ペアリングは、信頼できる自宅のネットワークで行いましょう。
何を作れるか：対応ボードの選び方
ESP32 SDK は、2026 年 10 月 4 日時点で 17 機種に公式対応しています。機種によって、使える機能がかなり違います。目的別に代表的な基板を選ぶと、次のようになります。
図7：目的別の最初の 1 台（機能は公式表のとおり。筆者は実機で未検証）
主な機種の機能を、公式の対応表から抜き出しました。
| 基板 | 画面 | 家庭内トンネル | 画像表示 | 押して話す | 備考 |
|---|---|---|---|---|---|
| ESP32-C5 DevKitC-1 | なし（ランプ） | ✅ | — | — | 公式の最短ルート。idf.py build だけで作れる |
| ideaspark ESP32（1.9 型） | 状態表示 | — | ✅ | — | PSRAM なし |
| Seeed SenseCAP Indicator | 4 型 | ✅ | ✅ | — | CO2・tVOC・温湿度センサー（D1S／D1Pro） |
| Seeed reTerminal E1002 | 7.3 型 6 色 E-Ink | ✅ | 6 色 | — | 書き換えは 1 回約 30 秒 |
| Home Assistant Voice PE | なし（LED リング） | ✅ | — | ✅ | 返事は Muse アプリに表示 |
| Waveshare ESP32-S3 AMOLED 1.75C | 丸型 1.75 型・タッチ | ✅ | ✅ | ✅ | アバター画面・電池 |
| M5Stack StickS3 | 1.14 型 | ✅ | ✅ | ✅ | ポケットサイズ |
| Seeed SenseCAP Watcher | 丸型 1.45 型・タッチ | ✅ | ✅ | ✅ | カメラ撮影（設定で有効化） |
| AIPI Lite | 128×128 | ✅ | ✅ | ✅ | 机の上の小さな相棒 |
「押して話す」（push-to-talk）は、ボタンを押している間だけ声を録音して Muse に送る機能です。ここで知っておきたいのは、Muse の返事は文字で返ってくるという点です。画面のある基板では字幕として表示されます。声で返事をさせたい場合は、返事の文字を自分で音声合成（TTS）の API に送って再生する改造が必要です。README には、改造する場所として components/muse/muse_chat_session.cpp の start_tts が示されています。
Raspberry Pi を使う Linux 版は、Raspberry Pi 3B+／4／5／Zero 2 W に対応しています（Bluetooth が必要）。Muse がシェルコマンドを実行できるため、Home Assistant の導入や、サーバーの見張りといった用途に向いています。
Mac で試す：ボードがなくても動かせた 3 つのこと
ここからは、筆者が Mac で実際に試した結果です。ESP32 基板も Raspberry Pi も持っていませんが、ソースコードに付属する道具だけで、かなりの部分を確かめられました。
準備
必要なのは、Homebrew と uv（Python のパッケージ管理ツール）です。
# ビルドに使う道具を入れる（Homebrew）
brew install cmake ninja
# SDK を取得する
git clone https://github.com/facebookincubator/muse-gadget-sdk
cd muse-gadget-sdk
筆者の環境では cmake 4.4.4、ninja 1.13.2、Python 3.12.15、uv 0.12.22 でした。
その 1：画面の UI シミュレーター
ESP32 SDK には、画面つき基板の UI を Mac や Linux で確認できるシミュレーターが付いています。README によると、シミュレーターは本番のファームウェアと同じ UI のコード（muse_ui.c）とアバターの描画処理をそのままコンパイルし、Wi-Fi や Bluetooth などの部分だけを PC 用の代役に差し替えたものです。画面は SenseCAP Watcher と同じ 412×412 ピクセルの丸型です。
# muse-gadget-sdk のフォルダで実行する
# 1. 設定（SDL と LVGL を自動でダウンロードする）
cmake -S esp32/simulator -B esp32/simulator/build -G Ninja -DCMAKE_BUILD_TYPE=Debug
# 2. ビルド
cmake --build esp32/simulator/build --parallel
# 3. 自動テスト（画面を出さずに各シナリオを 2 回描画し、結果が一致するか確かめる）
ctest --test-dir esp32/simulator/build --output-on-failure
筆者の環境では、1 の設定に約 10 分（603.5 秒）かかりました。画面描画ライブラリの SDL 2.32.10 と UI ライブラリの LVGL 9.5.0 をダウンロードするためで、回線の状況によって変わります。2 のビルドは 541 ステップで完了し、3 のテストも 11.6 秒で通りました。
シミュレーターは、key=value 形式のシナリオファイルを読ませると、画面を表示せずに（ヘッドレスで）状態を描画して画像に保存できます。
# シナリオファイルを作る（Muse が考え中の状態）
cat > thinking.txt <<'EOF'
face=thinking
caption=Checking the workshop sensors...
progress=0.68
wifi=connected
paired=true
advance=1200
EOF
# 画面を出さずに描画して PPM 画像で保存する
./esp32/simulator/build/muse_simulator \
--headless --scenario thinking.txt --run-ms 250 --screenshot thinking.ppm
face に idle（待機）、listening（聞いている）、thinking（考え中）、speaking（話し中）、error（エラー）、happy（うれしい）などを指定できます。描画時間（--run-ms）を少しずつ変えて撮影し、つなげたのが次のアニメーションです。
筆者の Mac で UI シミュレーターを動かして撮影した画面（412×412 を拡大）。ペアリングから会話、エラー表示までの状態を順に表示しています。画面のキャラクター「Jollybot」は Apache ライセンスの対象外です
対話モード（./esp32/simulator/build/muse_simulator を引数なしで実行）では、ウィンドウが開き、F1〜F7 キーで状態を切り替えたり、スペースキーを押している間「聞いている」状態にしたりできます。実機を買う前に、画面のデザインを Mac 上で作り込めるのは大きな利点です。
シミュレーターで分かった注意点：日本語の字幕は表示できない
シミュレーターで、返事の字幕に日本語を渡してみました。
左は英語、右は日本語の字幕を渡した結果。日本語は「□」になり、数字の 3 だけが表示されました
ソースコードを確認すると、字幕に使われているフォントは lv_font_unscii_16 という英数字だけを含むフォントでした。シミュレーターは本番と同じ UI コードとフォント設定を使っているため、実機でも同じく日本語は表示できないと考えられます（実機では未確認）。
日本語で使いたい場合の対策は 2 つです。
- Muse への依頼に「Answer in English」と添え、英語で返事をもらう（README も、短い返事にしたいときは依頼文で頼むよう案内しています）
- LVGL のフォント変換ツールで日本語フォントを作り、字幕のフォントを差し替える改造をする（漢字を含めるとフォントのデータが大きくなるため、フラッシュメモリの容量に注意）
その 2：Linux SDK のテスト
Linux SDK のテストは、Bluetooth も Muse もない環境で動くように作られています。
# muse-gadget-sdk/linux のフォルダで実行する
cd linux
uv run --with pytest --with . pytest -q
結果は 137 件すべて成功（9.93 秒）でした。ペアリングの暗号処理は、公開されているテスト用の値（tests/vectors/link_pairing_v5.json）と照合して確認されています。
その 3：偽の Muse とつないで、自作コマンドを呼ばせる
一番面白かったのがこの実験です。Linux SDK のテストには、本物と同じ Noise の暗号化ハンドシェイクを行う「偽の Muse VM」（tests/test_link_client.py の FakeVm）が入っています。これを流用して、自作のコマンドを Muse から呼ばせる流れを再現しました。
自作したのは、Mac のバッテリー残量を読む mac.battery というコマンドです。Raspberry Pi なら、温度センサーの値を読む処理に置き換えるイメージです。
# fake_vm_demo.py の一部：デバイスが Muse に申告する「できること」
COMMANDS = {
"mac.battery": {
"description": "Read this Mac's battery percentage and power source.",
"required": {}, "optional": {},
},
}
# Muse から呼ばれたときの処理
def run_command(command, params, timeout_ms):
if command == "mac.battery":
out = subprocess.run(["pmset", "-g", "batt"], capture_output=True, text=True).stdout
line = out.splitlines()
source = line[0].split("'")[1] if "'" in line[0] else "unknown"
pct = next((p.split(";")[0].strip() for p in out.split("\t") if "%" in p), "?")
return {"ok": True, "payload": {"percent": pct, "source": source}}
return {"ok": False, "error": {"message": f"unknown command {command}"}}
このコマンド一覧と処理を SDK の LinkSession（デバイス側の接続処理）に渡し、偽の VM から link.invoke を送ります。スクリプトの全文は記事フォルダの lab/demo/fake_vm_demo.py にあり、次のように実行します。
# muse-gadget-sdk/linux のフォルダで実行する（fake_vm_demo.py の場所に合わせてパスを変える）
uv run --with pytest --with . python ../../demo/fake_vm_demo.py
実行したときのターミナルの録画です。
筆者の Mac での実行結果。自作コマンド mac.battery が commands_v2 に載り、呼び出すと「100%・AC 電源」が返りました
ログから、次のことが確認できました。
link.registerのcommands_v2に、自作のmac.batteryが説明文つきで載る- 偽の VM が
link.invokeで呼ぶと、link.resultで{"percent": "100%", "source": "AC Power"}が返る send_chatで送ったメッセージはPOST /chat/streamになり、本文にdevice_idとsession_idが付くlink.unpairedを受け取ると、セッションが「登録解除」の状態で終わる
本物の Muse では、commands_v2 の説明文を読んだエージェントが「バッテリー残量を知りたい」という依頼に対してこのコマンドを選ぶ、という流れになるはずです（本物の Muse では未確認）。
自作コマンドを正式に追加する方法
実際の Raspberry Pi で自作コマンドを使うときは、linux/src/musegadget/executor.py を編集します。AGENTS.md に書かれている手順は次の 4 つです。
COMMAND_SPECSに、説明文（description）、必須・任意の引数（それぞれtypeとdescription）、必要ならtimeout_ms（既定は 30 秒）を足すExecutor.runに処理を足し、成功ならok(payload)、失敗ならerror(message)を返す- 機械に触れる処理は
self._child_options()を使って子プロセスで動かし、root ではなく指定したアカウントの権限で実行する tests/test_executor.pyにテストを足す
サービスを再起動すると、デバイスが link.register をやり直し、Muse に新しいコマンドが見えるようになります。
もっと手軽な方法もあります。プログラムから Muse に話しかけるだけなら、コマンドを足さなくても musegadget send-user-msg "ガレージのドアが 1 時間開いたままです" で送れます。Linux 版はシェルコマンドを実行できるので、Muse 自身に「温度が高すぎたら知らせるサービスを書いて」と頼む使い方も README で紹介されています。
おまけ：ESP32 のファームウェアも Mac でビルドできた
基板がなくても、書き込む前のファームウェア作りまでは Mac でできます。公式の既定機種である ESP32-C5 DevKitC-1 向けにビルドしてみました。ESP32 SDK は ESP-IDF 6.0.1（Espressif 公式の開発環境）だけをサポートしています。
# 1. ESP-IDF 6.0.1 を取得する（--depth 1 で履歴を省くと軽くなる）
git clone -b v6.0.1 --recursive --depth 1 --shallow-submodules \
https://github.com/espressif/esp-idf.git ~/esp/esp-idf-v6
# 2. ツールを入れる（GitHub からの取得が遅いときは Espressif のミラーを使う）
export IDF_GITHUB_ASSETS="dl.espressif.com/github_assets"
~/esp/esp-idf-v6/install.sh esp32c5
# 3. 環境を有効にする（ターミナルを開くたびに実行）
. ~/esp/esp-idf-v6/export.sh
# 4. muse-gadget-sdk/esp32 のフォルダでビルドする
cd muse-gadget-sdk/esp32
idf.py build
筆者の環境では、2 のツール取得が GitHub から何度も途中で切れました（「got only 28653641 out of 40145407 bytes」のようなエラー）。Espressif が用意しているミラー（IDF_GITHUB_ASSETS）に切り替えて入れ直したところ、C5 用のコンパイラーと Python の環境が約 7.6 分、残りのツールが 42 秒で入りました。また、macOS 標準の Python 3.9 では「ESP-IDF supports Python 3.10 or newer」と止まるので、Homebrew の Python 3.12 などを使います。
4 のビルドは 1,268 ステップ・258 秒で完了し、build/muse-gadget.bin（1,708,032 バイト）ができました。アプリ用の領域 2MB に対して 19% の空きがあります。SDK トークンを設定していないため、ビルドの途中で次の警告が出ました。
CMake Warning at cmake/validate_config.cmake:40 (message):
No SDK token: set CONFIG_GADGET_SDK_TOKEN (idf.py menuconfig > ESP32 Device
SDK) to the token from gadgets.muse.ai. Gadgets without one will stop
pairing.
トークンがなくてもビルド自体は通りますが、そのファームウェアではペアリングできなくなる、という意味です。実際に使うときは idf.py menuconfig の「ESP32 Device SDK」でトークンを設定してからビルドします。
ビルドの後は、基板なしで動く ESP32 側のテストも実行できます。
# muse-gadget-sdk/esp32 のフォルダで実行する（先に idf.py build が必要）
python3 -m unittest discover -s tests -p 'test_*.py'
結果は 156 件中 153 件成功・3 件スキップ（335.7 秒）でした。ペアリングの手順、暗号化セッション、トンネル、画像の取得、E-Ink の表示などを、PC 上の小さなテスト用プログラム（ハーネス）で確かめる内容です。
実務での使いどころ
小さな試作に向いている
Muse Gadgets の良いところは、考える部分をクラウドに任せられるので、手元の機械はとても小さく安くてよい点です。元になったアイデアを、SDK の機能に当てはめてみました。
図9：試作のアイデアと SDK の機能の対応（組み合わせは筆者の提案で、実機では未検証）
| やりたいこと | 使う部品 | 使う機能 |
|---|---|---|
| 毎朝の予定や天気を E-Ink に表示 | reTerminal E1002 | Muse が画像の URL を送る display.draw_url。本体で 6 色に減色して表示 |
| ボタンを押したら仕事を頼む | Raspberry Pi＋ボタン | musegadget send-user-msg でチャットに依頼を送る |
| 部屋の CO2 が高ければ換気を促す | SenseCAP Indicator | Muse が sensors.read で CO2・tVOC・温湿度をまとめて読む |
| 家のサーバーの容量不足やバックアップ失敗を見張る | Raspberry Pi | system.run と device.health |
E-Ink は電源を切っても表示が残るので、「朝のまとめを 1 日中表示しておく」用途と相性が良いです。ただし、6 色の E-Ink は書き換えに 1 回約 30 秒かかり、画面が点滅します。頻繁に変わる情報には向きません。
仕事で使う前に必ず確認したい 2 つの制約
実務での利用を考えるなら、次の 2 点は先に押さえておく必要があります。
1 つ目は、SDK トークンの利用条件です。 SDK トークン利用規約では、トークンは個人・非商用での利用に限られています。販売する機器、広告する機器、マーケットやアプリストアで公開する機器には組み込めません。他人に渡す機器に組み込めるのは 50 台まで、1 つのトークンにつなげるのも 50 台までです。さらに、規約には「サポートされた製品ではなく、開発者プラットフォームでもない」「予告なく変更・停止されることがある」と書かれています。社内の試作や個人の工作には使えても、そのまま製品にはできないと理解しておきましょう。なお、ソースコード自体は Apache 2.0 なので、コードを学んだり流用したりすることは別の話として自由です。
2 つ目は、Linux 版の権限です。 Linux 版では、Muse がインストール時に選んだアカウントとまったく同じ権限でコマンドを実行します。そのアカウントが sudo を使えるなら、Muse も使えます。AI エージェントに管理者権限を渡すのは危険なので、bash install.sh --run-as <アカウント名> で sudo を使えない専用アカウントを指定するのがおすすめです。
ESP32 版にも注意点があります。SDK トークンはファームウェアの中に埋め込まれるため、README は「パスワードではなく識別子として扱う」よう案内しています。漏れた場合は公式サイトで無効にして作り直します。また、Wi-Fi のパスワードなどを保存する領域（NVS）は、暗号化しないと基板を手に取った人に読まれてしまうため、対応する基板では CONFIG_HOMEHUB_NVS_ENCRYPTION を有効にすることが強く推奨されています。
自分で一から作る場合との違い
ESP32 と生成 AI の API を組み合わせた自作機器は、以前から作れました。Muse Gadgets を使う場合との違いを、筆者の視点で整理します。
| 観点 | 自分で一から作る | Muse Gadgets を使う |
|---|---|---|
| AI の頭脳 | 自分で API を呼び、会話の履歴や道具の呼び出しを実装 | Muse（利用者専用の VM）がそのまま担う |
| クラウドとの接続 | MQTT のサーバーや中継を自分で用意 | デバイスから Muse へ暗号化接続。中継の用意は不要 |
| 道具の登録 | ツール定義を自分で書いて API に渡す | link.register でデバイスが自分で申告 |
| 家電の操作 | 機器ごとに API を調べて実装 | コミュニティのスキル（Markdown）を Muse に読ませる |
| 利用条件 | 使う AI サービスの規約次第 | 個人・非商用、最大 50 台。日本では Muse 自体が未提供 |
まとめると、「AI エージェント側の仕組みを作らなくてよい」代わりに「Muse とその規約に乗る」という選択です。個人で家の中を便利にしたいなら手間が大きく減り、製品として作りたいなら自前の構成が必要、という住み分けになりそうです。
トラブルシューティング
公式ドキュメントに書かれているつまずきやすい点と、筆者が確認した注意点をまとめます。
図10：うまくいかないときの確認順
| 症状 | 原因と対処 |
|---|---|
| ESP32 に書き込めない（flash がつながらない） | BOOT ボタンを押したまま RESET を押して離し、もう一度実行する。USB ケーブルが充電専用でないかも確認する |
sdkconfig.defaults や機種の設定を変えたのに反映されない | ビルド用フォルダ（build/ など）に古い設定が残っている。フォルダを消して作り直す |
| 機種を切り替えたら部品の取得でエラーになる | 画面つきの機種とそうでない機種で部品が衝突する（LVGL が原因になりやすい）。managed_components/ と dependencies.lock を消してビルドし直す |
| Raspberry Pi で、Wi-Fi の段階まで進んだのに「Couldn’t connect」（Android） | Bluetooth の一度に送れるデータ量の設定が足りない。/etc/bluetooth/main.conf に [GATT] ExchangeMTU = 256 が必要（インストーラーが設定する） |
| スマホに GATT 133 エラー | スマホ側の Bluetooth の古い状態が原因のことが多い。スマホの Bluetooth を一度オフにしてオンにする |
| SenseCAP Watcher に書き込めない | USB 変換チップが高速通信でデータを落とす。tools/muse/paced_esptool.py（tools/muse/board.sh flash watcher）を使う |
| 字幕が「□」だらけになる | 字幕のフォントが英数字のみ。英語で返事をもらうか、日本語フォントを足す改造をする（筆者がシミュレーターで確認） |
ESP-IDF のツール取得が途中で切れる（got only ... bytes） | GitHub からのダウンロードが不安定。export IDF_GITHUB_ASSETS="dl.espressif.com/github_assets" で Espressif のミラーを使う（筆者が確認） |
ESP-IDF supports Python 3.10 or newer で止まる | macOS 標準の Python 3.9 が使われている。Homebrew の Python 3.12 などを使う（筆者が確認） |
| UI シミュレーターの設定が終わらない | SDL と LVGL のダウンロード中。筆者の環境では約 10 分かかった。一度取得すれば -DFETCHCONTENT_FULLY_DISCONNECTED=ON で再取得を省ける |
それでもランプが赤く点滅するときは、ESP32 なら idf.py -p <ポート> monitor、Raspberry Pi なら sudo journalctl -u musegadget -f でログを確認します。Linux 版は、正常に起動すると Noise session established、sent link.register、registered with the Muse がログに出ます。
コーディングエージェントで作る前提の SDK
最後に、もう 1 つ特徴的な点を紹介します。ESP32 と Linux の各フォルダには、人間向けの README.md とは別に、AI のコーディングエージェント向けの手順書 AGENTS.md が置かれています。ESP32 版の AGENTS.md は 469 行あり、ツールの準備、機種ごとのビルド方法、接続された基板の見分け方（USB の情報から機種を特定する手順まで）、新しい基板の追加方法が書かれています。
公式 README は、Meta のコーディングエージェント「Muse Code」に「ESP32-C5 DevKitC-1 用にビルドして書き込んで」と頼む方法を最初に紹介しています。あわせて、AGENTS.md を読めるエージェントなら他のものでもよいと明記しています。Claude Code や Codex でも、同じ文書を手がかりに作業を進められるはずです。ただし、基板への書き込みには USB のシリアルポートへのアクセスが必要なため、エージェントがサンドボックス（隔離された実行環境）の中で動いている場合は、書き込みとログ監視のコマンドだけ外で実行できるようにする必要があります。
「AI エージェントのための周辺機器を、AI のコーディングエージェントに作らせる」という設計は、これからのハードウェア SDK の 1 つの形になりそうです。
まとめ
Muse Gadgets について、要点を振り返ります。
- 何が公開されたか：Meta の AI エージェント Muse を、ESP32 基板（17 機種）や Raspberry Pi につなぐ SDK 一式。コードは Apache 2.0 で公開され、Meta 製の Home Link も同じファームウェアで動いている
- どう動くか：デバイスの側からクラウドの Muse VM へ暗号化接続を張り、
link.registerで「できること」を申告し、link.invokeとlink.resultで命令と結果を往復する。Home Link はさらに IP のトンネルで家の LAN へ橋を架ける - 日本からは：Muse 本体が米国のみの提供のため、本物の Muse につなぐのは現時点では難しい。ただし、UI シミュレーター、テスト、偽の Muse との通信実験、ESP32 ファームウェアのビルドは Mac だけでできた
- 実務では：試作には向くが、SDK トークンは個人・非商用で最大 50 台。Linux 版は Muse に渡す権限を必ず絞る。日本語の字幕は表示できない
次の一歩としては、まずシミュレーターを動かして画面の状態を一通り見てみること、そして作りたいものに合わせて基板を 1 枚選んでおくことをおすすめします。日本で Muse の提供が始まれば、ペアリングして試すまでの距離はかなり短いはずです。
