Metaが公開したMuse Gadgetsは、手元の基板や小型コンピューターをMuseにつなぐための開発キットだ。対象はESP32 Device SDKとLinux Device SDK、関連するファームウェアであり、Museのモデルやクラウド側の実行環境を自分で動かすための一式ではない。試作を始める前に、何が公開され、何がMetaのサービスに残るかを切り分ける必要がある。
Muse Gadgetsで公開された範囲──SDKとサービスを分けて見る
Metaの公式READMEは、ESP32 Device SDKとLinux Device SDKを公開し、画面、音声、センサー、ボタン、アクチュエーターをMuseにつなぐ構成を示している。ESP32側は市販の開発ボードを使った組み込み試作、Linux側はRaspberry Piや別のLinux機に自作コマンドを加える構成だ。基板が入力を受け、表示や音声を返し、決められた操作を実行する一方、依頼の理解や処理の調整はMuse側のサービスが担う。
ここでいうオープンソースは、公開されたリポジトリのSDKとファームウェアを指す。Museのモデル重み、サービス側の実行環境、アカウントやサーバーの運用権限が公開されたという意味ではない。TechCrunchはMuseのAIエージェントとMuse Sparkを報じているが、これはMuse Gadgetsのデバイスコードとは別の層の情報である。モデルを自分の機器で置き換えたい人や、クラウドに依存しない装置を作りたい人は、SDK公開をそのまま要件達成と読まない方がよい。
ESP32とLinux機の選び方
ESP32は、ボタンを押す、ランプや小型ディスプレーを動かす、音を入出力する、単一のセンサーを読むといった機能を一つずつ試す場面に向く。消費電力やメモリー、電源回路、GPIOの割り当てを自分で確認する必要があり、ESP32ならどの基板でも同じ手順で動くとは限らない。カメラや複数センサーを足す場合は、SDKの対応表と基板ごとのドライバーを先に照合する。
Linux機は、既存のプログラムやネットワークサービスを呼び出す試作に向く。READMEはRaspberry PiやLinux機に自作コマンドを加え、システム管理やHome Assistantの操作につなぐ例を挙げている。自由度が上がるほど、ファイル変更、プロセス停止、家電操作まで一つの命令から到達しうる。最初は読み取り専用の状態確認か、失敗しても影響が小さい操作に限定し、管理者権限や家庭内の認証情報を渡さない設計から始めるべきだ。
| 観点 | ESP32 | Linux機 |
|---|---|---|
| 主な用途 | ボタン、表示、音声、センサー | 自作コマンド、ネットワークサービス、既存システム |
| 確認点 | 基板、配線、電源、ファームウェア | OS、実行ユーザー、サービス、認証情報 |
| 最初の検証 | 入力一つと出力一つ | 隔離した低権限の読み取り命令 |
SDK tokenからペアリングまで
公式READMEでは、書き込みやペアリングの前にSDK tokenを取得し、iOSまたはAndroidのMuseアプリでSettings > Devicesを開き、Developer modeを有効にして「MuseGadget」で始まる機器を探す手順が案内されている。これは現時点で公開されている手順であり、すべてのアカウント、地域、基板に同じ条件が適用されることを意味しない。
tokenはパスワードと同じ扱いにする。公開リポジトリ、課題報告、通常のデバッグログに残さず、試作を止めたときは再発行や失効の方法を確認する。ペアリングに成功しても、ネットワーク断、アカウントの状態、SDKの更新、サービス側の変更で動作が変わる可能性がある。入力がどこで生成され、どのデータが端末外へ出て、返答がどの機器に届き、誰が命令を取り消せるかを図にしておくと、原因の切り分けが早くなる。
マイクやセンサーを足す場合は、起動条件と収集範囲を先に決める。部品がデータを読めることと、MuseやSDKがそのデータをどう扱うかが公開されていることは同じではない。最初の通信試験には非機微なデータを使い、家庭内の他人が収音や撮影を受ける状態を作らない。門錠、電源、暖房などの制御は、Museを使わない手動操作を残したうえで評価する。
ライセンスと保守の境界
リポジトリのライセンス表示はApache License 2.0を示す一方、READMEはminimp3、LVGL、SDLなどの第三者ファイルやビルド時に取得する依存部品がそれぞれのライセンスに従うと説明している。Jollybot avatarもApache Licenseの対象外と明記されている。個人の動作確認、変更したファームウェアの配布、製品への組み込みは別の判断になるため、使用するファイルと依存関係を固定し、公開前にライセンスを一覧化する必要がある。
ハードウェアを自作できても、サービスの保守責任まで引き取れるわけではない。SDKのバージョン、基板の型番、ビルド環境、tokenの保管場所、ペアリング解除の方法を記録し、Muse側の更新後に再試験する。サービスが停止したときに残る機能、tokenが無効になったときの窓口、保存データを削除・取得する方法が決まっていないなら、常時稼働が必要な装置や安全に関わる設備へ組み込む段階ではない。
日本ではどうなる
日本での部品代は、Muse Gadgets専用の一括価格として公表されているわけではない。Raspberry Piの本体やEspressifのESP開発キットは、それぞれの公式製品一覧から型番を確認し、国内販売店や正規流通の在庫と価格を照合する形になる。MuseのSDK token、アプリ、クラウド機能の日本向け料金や提供条件は、公開READMEとMetaのMuseダウンロードページだけでは確定できない。日本で試せるかを判断する際は、アプリストアでの提供、Metaアカウントの地域設定、Gadget SDK Terms、token発行画面を順に確認する必要がある。
無線通信を使う基板を日本国内で組み立てる場合は、電波法の確認が先になる。総務省の基準認証制度は、特定無線設備について技術基準適合証明や工事設計認証を行い、適合した機器に技適マークを表示する仕組みだ。市販のESP32開発ボードをそのまま使うのか、アンテナや無線部を変更するのかで確認事項が変わるため、総務省の基準認証制度と機器検索で型番と認証内容を照合する。独自基板を製造・輸入・販売する段階では、試作で使えたという事実だけで国内流通の要件を満たしたとは扱えない。
国内事例について、Muse Gadgetsを日本の複数拠点や家庭設備で運用したことを示す公的な導入資料は、本稿の執筆時点で確認できていない。したがって、Home Assistantとの接続例は公式READMEが示す開発用途として扱い、国内の製品事例や長期運用の実績へ広げない。価格、地域提供、サービス継続期間が決まらないまま、門錠や電源の制御を前提に部品を購入するのは避けるべきだ。まずは技適を確認した基板で、非機微な入力一つ、応答一つ、手動で停止できる命令一つを検証するのが日本での現実的な入口になる。
試作前に分ける五つの確認
第一に、SDKで実現したい入力と出力を一つに絞る。第二に、公式READMEで基板、周辺機器、ビルド条件、tokenの要件を照合する。第三に、Museアプリ、Developer mode、アカウント、地域、料金、利用規約を確認する。第四に、token、ネットワーク、OSユーザー、家電側の権限を分離する。第五に、サービス停止、ペアリング解除、データ削除、手動復旧の手順を試す。
Muse Gadgetsは、AIエージェントを現実の入力機器や家庭内サービスにつなぐ境界を試す素材としては興味深い。一方、公開されたのは装置側の開発基盤であり、モデル、クラウド、アカウント、国内提供条件まで引き受ける製品ではない。接続できたことと、長く安全に運用できることを分けて評価する必要がある。
よくある質問
Muse Gadgetsは何に対応するのか
公式プロジェクトにはESP32 Device SDKとLinux Device SDKがあり、Raspberry PiやLinux機、画面、音声、センサーなどの例が示されている。個別の基板や周辺機器の対応は、各ディレクトリのREADMEで確認する。
オフラインで使えるのか
公開READMEはSDK tokenの取得とMuseアプリによるペアリングを案内している。公開情報だけでは一連の処理が完全にオフラインで成立するとは確認できないため、ネットワークやサービス停止の影響を受ける前提で試験する。
ハードウェア開発の経験がなくても試せるのか
コードを読むだけの検証は可能だが、実機では書き込み、配線、電源、無線、ペアリング、ログ調査が発生する。最初は文書のある基板と単純な周辺機器を使い、門錠や電源など高い影響を持つ設備へ直結しない。
