MCP

FrankenSonos MCP:AI エージェントが自宅 LAN で Sonos スピーカーを操作する

手持ちの Sonos スピーカーをターミナル、HTTP API、または MCP を話す AI エージェントに操作させたいとき、FrankenSonos はメモリセーフな Rust バイナリ 1 つで 3 つの入口を同時に提供する。ただしプロジェクトは pre-release で、ソースからのビルドが必要であり、デーモンはスピーカーと同じ LAN 上のマシンで動かす必要があり、外部からのアクセスには Tailscale tailnet がさらに要る。

公式ソース · FrankenSonos

インストール

git clone https://github.com/Dicklesworthstone/frankensonos
cd frankensonos
cargo build --release

こんな人に向いている

すでに Sonos スピーカーを所有していて、家中のオーディオをターミナル、HTTP API、あるいは MCP を話す AI エージェントに任せたい人へ。FrankenSonos は公式に memory-safe(メモリ安全)と説明される Rust 製コントローラー兼デーモンで、バイナリ 1 つで家中の機器を動かせる。3 つの入口はそれぞれ別の読者に対応する:コマンドを打ちたい人は fsonos CLI、連携を作りたい人は OpenAPI ドキュメント付きの HTTP API、AI に任せたい人は MCP サーバー。コマンドラインとスクリプト化を好むホームオートメーションユーザーには特に馴染む。所有済みのスピーカーだけを対象にし、新しいハードウェアの購入は伴わない。

前提を先に示す:プロジェクトは pre-release 段階で、直接ダウンロードできる正式バイナリはまだない。初回利用はソースからのビルドから始まる(Rust ツールチェーンのバージョンは rust-toolchain.toml で固定)。デーモンはスピーカーと同じ LAN 上のマシンで動かす必要があり、どこからでもアクセスしたいなら、そのマシンを Tailscale tailnet に参加させることも要る。コマンド 1 発でインストールされ、すぐ使える状態を期待する人は正式リリースを待とう。この 2 つの前提から、即席アプリというよりセルフホスト型のインフラに近い。両方とも受け入れられるなら、まず一回試す流れに進んでよい。

向かない人・様子見:Sonos スピーカーが無い、Rust ツールチェーンを入れたくない、スピーカーと同じ LAN に常時置けるマシンを用意できない——どれかでも当てはまると前提を満たしにくい。他ブランドのスピーカーで使えるかは証拠に書かれていないので、勝手に想定しないこと。

3 分で最初の一回

推奨ルートは公式の手順どおり、ソースからビルドし、初期設定を済ませ、エージェントをデーモンへ向けること。ダウンロードを選ばない理由:CI は main へのプッシュごとに Apple Silicon と x86_64 Linux のビルド成果物を出すが、パイプラインと一緒に期限切れになる。正式なダウンロードは 0.1.0 から始まると公式が明言している。作業の間、スピーカー側には何もインストールしない。

前提:スピーカーと同じ LAN 上のマシン 1 台と、Rust ツールチェーン。

手順 1、クローンしてビルド:

git clone https://github.com/Dicklesworthstone/frankensonos
cd frankensonos
cargo build --release

手順 2:そのマシンで fsonos setup を実行する。公式によれば、以降の初期設定はこれが引き受ける。

手順 3:任意の tailnet 上のマシンから、エージェントをデーモンへ向ける:

claude mcp add --transport http fsonos https://<mac>.<tailnet>.ts.net:8443/mcp

最初の呼び出しは最も軽い一歩を推奨する:MCP リソース sonos://zones を読んでスピーカーゾーンを確認し、機器を動かす前に経路が通るか確かめる。成功シグナルについて、証拠は具体的な出力テキストを記述していない。確認できるのは、エンドポイントとリソース名がいずれも公式原文由来だという点。エージェントに制御系の動作を実行させるなら、それらは実機に作用する点に注意。証拠は取り消し手段を示しておらず、取り消し可能な操作とは扱わないこと。確認ポイントは動作の前に置く:エージェントが何を呼び出し、どのゾーンに作用するか見極めてから許可する。読み取り専用の初回試行と実際の制御を分けて練習するのが一番気楽なやり方だ。

使用例

例 1:エージェントに家中のスピーカーを点検させる。シーン:エージェントが上のエンドポイント経由でデーモンに接続済みで、出かける前にどの部屋で音楽が流れているか手早く確認したい。試すこと:MCP リソース sonos://zones を読む。期待できる結果:スピーカーゾーンの情報が手に入る。具体的なフィールドと形式は証拠にないため、実際の応答を基準にする。同じネットワークにいないときも、任意の tailnet 上のマシンから同じ読み取りをエージェントに任せられるので、外出の多い人ほど実用的。長く使うなら、この読み取りを毎日の点検ルーティンにしてもよい。

例 2:エージェントを経由せず、ターミナルから直接家中のオーディオを制御する。シーン:デーモンを動かしているマシンそのままの前で作業している。試すこと:どこでも --json をサポートする fsonos CLI を使う。期待できる結果:出力が JSON で、スクリプトでの解析や既存の自動化への接続が楽。個別のサブコマンド一覧は証拠に載っていないので、1 本ずつでっち上げた例は書かない。スクリプトは CLI を、エージェントは MCP を呼ぶ——2 つの方式は場面に応じて組み合わせられる。

利用の境界

  • 読み書きの性質:制御系の呼び出しはスピーカーに実際に作用する。証拠は個々の MCP ツールの読み書き区分、名称、パラメータを提供しておらず、確認できるのはツール群の存在と sonos://zones、sonos://dj の 2 リソースのみ。
  • スピーカーそのものへ:公式は「Nothing is installed on the speakers and nothing about them is changed」と明言しており、スピーカーへのインストールもスピーカーの変更も行わない。ただし動作に副作用がないこととは別で、再生制御は機器上の実際の変更である。スピーカー以外のローカルファイルやデータの読み書きについても証拠は述べていない。
  • クライアントと入口:公式が示すエージェント接続コマンドは claude の 1 本だけで、MCP 転送は streamable HTTP または stdio に対応。他クライアントの接続方法は証拠にない。
  • ネットワークと配置:同一 LAN が厳しい前提。ネットワーク越しのアクセスは tailnet 依存で、エンドポイントは https://<mac>.<tailnet>.ts.net:8443/mcp 形式。URL 内のプレースホルダーは自分の tailnet ドメインに置き換える。認証と資格情報の要件は証拠にない。
  • バージョン状態:pre-release で、正式リリースのダウンロードはなく、CI 成果物はパイプラインとともに期限切れ、正式版は 0.1.0 から始まる。アップグレード経路は証拠にない。
  • 未確認事項:MCP ツールの名称とパラメータ、認証機構、リソース読み取りが機器の動作を引き起こすか、取り消し機構。不明だからリスクがないわけではない。初めてエージェントに自律操作させる前は、動作を読み取り系に限定し、段階的に広げること。