MuseとGrok Botとの比較（HOME Assistantとの連携編）

少し前から、お節介なMuseを無料プランで使い始めた。そこで、色々な面で、Grok BotとMuseを比較しようと考えた。まずは、HOME Assistantとの連携である。すでにGrok Botは、ローカルのMac miniを介してHAの情報を取得できているので、MuseがHAにアクセスできる構成を調査して構築しGrok Botの場合と比較する。

---

注）本記事の内容は正確性を保証するものではありません。

（2026年11月12日 追記）YouTube動画を追加しました。　https://youtu.be/_HT1S6jmWDA

MuseにHAとの連携方法を相談する

（以下、Museの回答）

できます。方法をご説明します。

私のコンピューターはクラウド側にあるため、ご自宅のネットワーク内にあるMac mini上のHome Assistantには、このままでは直接届きません。安全な接続経路を作れば連携できます。

おすすめ：Tailscale経由

1. Mac mini（またはHome AssistantのVM）にTailscaleを入れてサインインしておく（既に入っていればそのままで大丈夫です）
2. 私のコンピューターを、あなたのTailscaleネットワークに「muse」という名前で参加させる。承認用のリンクを出すので、あなたに承認してもらいます
3. Home Assistant側で長期アクセストークンを発行し、安全な形で受け渡す
4. 私がHome AssistantのAPI経由で、機器の状態確認や操作（照明・スイッチ・センサー・オートメーションなど）ができるようになります

ルーターのポート開放は不要ですし、安全面からもTailscaleの方がおすすめです。Home Assistant Cloud（Nabu Casa）のリモートアクセスでも代替できます。

なお、部分的には今も連携できていて、HASS Bridge経由でHomeKitに出ている機器は、現在のHome連携で見たり操作したりできます。ただしHome Assistant本体の全エンティティやオートメーションに届くのは、上記の直接連携をしてからになります。

セキュリティを気にするのは正しい視点です。まずTailscaleの長所・短所を正直に並べます。

Tailscaleのメリット・デメリット

観点	メリット	デメリット・注意点
公開面の安全性	ルーターのポート開放が不要。自宅のHome Assistantがインターネットに直接さらされず、無差別スキャンの対象にならない	—
暗号化	WireGuardによる端末間の暗号化通信。Tailscaleのサーバーは通信の中身を見られない（鍵の交換を仲介するだけ）	暗号化の前提として、参加デバイス自体の信頼性は必要
到達範囲	家の外からでも自宅LAN内と同じように届く	Mac miniやVMがスリープ・停止していると届かない
信頼の境界	承認したデバイスだけが参加できる	私のコンピューターがあなたのネットワークの「参加者」になる。つまり、参加を認める範囲を絞る設計が重要（下記のACLで対処）
依存とコスト	個人利用は無料枠で足りることが多い。設定も簡単	Tailscale社の調整サーバーとアカウントに依存。アカウントを乗っ取られると危険なので、Tailscaleログインへの多要素認証は必須
運用	管理画面で参加デバイスの一覧確認・削除がいつでもできる	本格的なアクセス制御（ACL）は管理画面でポリシーを書く必要がある

正直なところ、最大の注意点は「外部の機械（私のコンピューター）を自宅ネットワークに入れる」という点そのものです。だからこそ、権限を最初から最小に絞る設定が肝心です。

Museの権限の絞り方（3層で設定できます）

層	設定できること
Tailscale管理画面 （あなたが管理）	新規デバイスの参加に管理者承認を必須化。ACL（アクセス制御）で「デバイス muse は、Mac mini上のHome Assistantのポート8123にだけ接続可。それ以外は不可」と限定できる。デバイスキーの有効期限も設定でき、管理画面でデバイスを削除すれば即座に締め出せる
私（Muse）の側	私のTailscaleはクライアント専用で、外向きの接続だけを行い、外部からの接続は受け付けず、何も公開しません。さらに、新しい接続先アドレスごとに、初回はあなたの承認カードが必要で、承認された範囲だけで接続します
Home Assistant側	Muse専用のユーザー（管理者権限なし）を作り、その長期アクセストークンだけで接続する。不要になればHome Assistant側でそのトークンだけを失効できる

私のおすすめ初期設定

• Tailscaleアカウントに多要素認証を設定し、デバイス承認を有効化
• ACLで私の接続先を「Home Assistantの8123番ポートのみ」に限定
• Home Assistant側はMuse専用の非管理者ユーザー＋専用トークン
• 最初は状態の参照だけにし、機器の操作は様子を見てから広げる

この形なら、私が届くのはHome Assistantの入口だけで、自宅LANの他の機器（NASやPCなど）には原理的に届きません。

結論から言うと、今回のHome Assistant連携の使い方なら 費用は0円 です。

Tailscaleの料金プラン（2026年11月時点の公式価格）

プラン	料金	主な内容
Personal	無料（期間制限なし）	ユーザー6人まで、デバイス数無制限、ACLグループ3つまで、タグ付きリソース50個まで
Standard	8ドル／ユーザー／月	ユーザー無制限、ACLグループ10、MDM連携など業務向け機能
Premium	18ドル／ユーザー／月	ACLグループ300、フローログ、ジャストインタイムアクセスなど監査・統制機能
Enterprise	個別見積もり	—

料金はデバイス単位ではなくユーザー単位で、無料プランでもデバイス数は無制限です。あなた個人の利用で、私のコンピューターは「あなたのネットワークに参加する1デバイス」として数えられるだけなので、無料プランの範囲に収まります。
権限を絞るためのACLも、無料プランの3グループで十分足ります。

1点だけ注意として、Tailscaleは2026年4月にプランを改定していて、古い記事だと「無料は3ユーザー・100デバイスまで」と書かれていることがありますが、現在は上記の内容です。

もちろん、有料プランへの申し込みなど、お金が発生する操作を私が勝手に行うことはありません。

仕組みはシンプルで、「Tailscaleで同じ仮想ネットワークに入り、Home AssistantのAPIを叩く」という形です。

1. 届くまで
Tailscaleに両方が参加すると、Home AssistantのVMに専用のアドレスが付きます。私のコンピューターからは、そのアドレスの8123番ポートへ、通常のWebアクセスと同じ形で届くようになります。

http://（HAのTailscaleアドレス）:8123

2. 認証
Home Assistantのプロフィール画面で発行する「長期アクセストークン」が私の身分証になります。リクエストのたびにヘッダーに付けて送り、Home Assistant側はいつでもそのトークンだけを無効化できます。

3. やり取りの中身（Home Assistant標準のREST API）

状態を読むとき:

GET /api/states                → 全エンティティの状態
GET /api/states/sensor.xxx     → 特定のセンサーの値

操作するとき:

POST /api/services/light/turn_on
{ "entity_id": "light.xxx" }   → 照明を点ける

スイッチ、シーン、オートメーションの実行なども同じ形式です。

4. 連携するとできることの例

• EcoFlowの電力やバッテリー残量、温湿度・開閉・水漏れセンサーの状態確認
• 朝の要約に「家の状態」を添える（例：異常のある機器だけ知らせる）
• HA経由でSwitchBotやFlicなどの機器を操作したり、HAのオートメーションを実行したりする

5. 正直な制限
私からの接続は「必要なときに問い合わせる」方式が基本で、Home Assistantからの常時プッシュ監視はしません。異常チェックをしたい場合は、決まった時間に私が確認しに行く形になります。また、Mac miniとVMが起きている間だけ届きます。

セットアップは、HA側をTailscaleに参加させる（Home Assistant公式のTailscaleアドオンでも可）、私の参加を承認して接続先を8123番ポートに限定、HA側でMuse用トークンを発行、最後に疎通テスト、という順番です。

できます。ただし、APIだけでは設定ファイル（configuration.yamlなど）には触れません。ファイル編集には別の経路を追加で許可してもらう必要があります。

経路	ファイル書き換え	特徴
APIのみ（8123番ポート）	不可	できるのは状態取得・機器操作と、オートメーション等の項目単位の編集まで。一番安全
Git経由（おすすめ）	可	HAの設定をGitHub等のプライベートリポジトリで管理し、私がリポジトリ側を編集 → HAが取り込んで反映。変更履歴と差分が全部残り、元に戻すのも簡単。私の接続先を広げる必要もありません
SSH経由	可（完全）	VMに直接入ってファイルを編集できる。ただし権限が最も広く、HA以外の部分にも届き得るので、ACLで22番ポートも開けることになり要注意
ファイル共有（Samba等）・File editorアドオン	可	HAの設定フォルダだけを共有する方法。中間の広さ

書き換えるときの安全手順（どの経路でも）
設定ファイルの書き間違いはHome Assistantが起動しなくなる原因になるので、次の順序を守ります。

1. 変更前に差分（どこをどう変えるか）をあなたに見せて確認をもらう
2. 反映前にHAの「設定チェック」で構文エラーがないか検証する
3. バックアップを取ってから反映し、問題があればすぐ戻せるようにする

最初はAPIのみ（参照と操作）で始めて、設定ファイルの編集が必要になったら、その時点でGit経由を追加するのが、安全と便利さのバランスが良いと思います。

できます。オートメーションは、設定ファイルを直接触らなくても、API経由で作成・編集できます。

できること

• トリガー（時刻、センサーの値、機器の状態変化、Flicのクリックなど）→ 条件 → アクション（機器操作、シーン実行、通知など）の組み立て
• 既存オートメーションの有効化・無効化、編集、実行履歴（トレース）の確認
• スクリプトやシーンの作成も同様にできます

APIで作ったオートメーションは、Home Assistantの画面（UI）で作ったものと同じ場所に保存されるので、後からあなたが画面で見たり直したりもできます。

注意点が1つ
もし今のオートメーションを、YAMLファイルに手書きしてファイル分割で管理している場合は、API編集の対象外になることがあります。その場合はGit経由などのファイル編集の経路が必要です。連携後に実際の管理方式を確認して、合う方法を選びます。

作るときの進め方

1. まず内容（何が起きたら、何をするか）を文章で提案し、あなたに確認してもらう
2. 最初は通知だけの安全なアクションで作り、動作を確認する
3. 問題なければ機器操作を含む形に広げ、有効化する

お宅の機器で言うと、たとえば「EcoFlowのバッテリーが20%を切ったら通知」「水漏れセンサーが反応したら通知して関係する機器を止める」「夜中に玄関の開閉センサーが反応したら知らせる」といったものが考えられます。

項目	Grok Bot（今の環境）	Muse（Tailscale 接続後、推定）
つなぎ方	Mac-mini-2 経由で、家の中のネットワークから HA の API を呼ぶ	クラウドのコンピューターから Tailscale 経由で HA に直接つなぐ
状態の確認 （センサー、電力、在宅など）	できる（読み取り専用）	できる
機器の操作、設定の変更	仕組み上はできる。ただし、あなたの承認をもらってから	できる
HA からの通知を受ける （ゾーン出入り、アラート）	できる（Webhook でルーティンが起動）	Webhook を設定すればできる（推定）
Fire TV Cube のアナウンス	できる（頼まれたときだけ）	同じ HA の機能なのでできる（推定）
定期チェック （週次診断、電力リスト）	できる（ルーティン）	Muse にも定期実行があればできる（推定）
Mac mini がオフラインのとき	HA に届かない（受け身の Webhook 通知は届く）	HA の VM が動いていれば届く
HA の VM 自体が止まったとき	届かない	届かない
新しく入れるもの	なし（今のまま）	Tailscale アドオン、アカウント、Muse 用の長期トークン
HA 以外の操作 （Mac mini のファイルなど）	同じ経路でできる	Tailscale の範囲だけ

（以下、Museのコメント）

大枠は合っています。ただ、Muse側の推定には 1つ重要な間違い と、いくつか条件付きの点、抜けている項目があります。

■ 修正すべき点

1. HAからの通知（Webhook）— ここが一番違います
   「Webhookを設定すればできる」は、私については誤りです。私のTailscale接続は外向き専用で、外部からの着信接続を受け付けません。なのでHAから私へWebhookを直接送ることはできません。
   代わりにできるのは、私が定期的にHAの状態を取りに行き、ゾーンの出入りやアラートなどの変化を検知して知らせる方法です（チェック間隔は数分単位で調整できますが、即時ではありません）。あとは、HAから私が読めるメール宛に通知させる間接方式です。
2. Fire TV Cubeのアナウンス — 条件付き
   これはHAの標準機能ではありません。Alexa Media Playerなどのカスタム統合がHAに入っていて、アナウンス用の通知サービスとして見えている場合に限ってできます。
3. HA以外の操作（Mac miniのファイルなど）— 初期設定では不可
   「Tailscaleの範囲だけ」ではなく、私の接続先は最初から HAの8123番ポートだけに制限する ので、Mac miniのファイルには届きません。SSHなどを追加で許可した場合にのみ可能になります。
4. 「設定の変更」の範囲
   機器の操作と、オートメーションなど項目単位の設定はAPIでできます。ただし HAの設定ファイル（configuration.yaml等）の書き換えはAPIでは不可 で、GitやSSHなど別の経路が必要です（先日お話しした通りです）。
5. Mac miniがオフラインのとき
   私はMac-mini-2を経由しないので、そのマシンの状態は無関係です。私が届く条件は「HAのVMと、そのホスト機、両側のTailscaleが動いていること」です。

■ 追加すべき点（表にない項目）

• オートメーション・スクリプト・シーンの作成：API経由でできます
• 過去データの参照：HAの履歴から、電力の推移など過去の状態も取得できます
• 随時の確認：定期チェック以外に、会話で「今の電力は？」と聞かれれば、その場で最新状態を取りに行けます

調べました。ChatGPT-6.1 Solの区別は正しいです。結論から言うと、私がHAに接続するために使うのは「アドオン」の方です。

2つの違い

	Tailscaleアドオン	Tailscale統合（インテグレーション）
正体	Home Assistant Community Add-onsにあるアドオン（HAコア開発者のFrenck氏がメンテ）。 Tailscale本体をHAの中にインストールする	HA標準の統合。HAからTailscaleのAPIを参照する
役割	HA自身がTailscaleネットワークの参加者になる → 外部からHAに届くようになる	ネットワーク内の端末のオンライン／オフライン状態をHAのセンサーとして監視する
これを入れると	Tailscale経由でHAの画面やAPI（8123番）にアクセスできる	端末ごとのバイナリセンサーや、接続中デバイス数などのセンサーが増える
やらないこと	端末の状態監視はしない	HAへの接続は一切できるようにならない

この2つは別物で、「統合を入れただけではHAにVPN接続できない」という点は、HAのドキュメント側でも明示されている注意点です。

私たちの場合の使い分け

• 必須なのはアドオン側：これでHAがネットワークに参加し、私がTailscale経由でAPIを呼べるようになります
• 統合は任意：入れる必要はありません。「家族のスマホがネットワークにいるか」を在宅判定に使うような場合にだけ意味があります

あなたの環境での注意点が1つ
アドオンが使えるのは、HAの導入タイプが「Home Assistant OS」または「Supervised」の場合だけです。お使いのVMがHA OSならアドオンが一番きれいですが、もしVM上のDocker等でHAを動かしている場合は、アドオンではなく VMやMac mini本体にTailscaleアプリを入れる 形になります。効果は同じです。導入タイプは、HAの「設定 → システム → 修復（または情報）」で確認できます。

はい、その理解で合っています。少しだけ精密にすると、次のようになります。

• アドオン = 外部からHAに「入ってこられる入口（通信路）」を作る方向
  アドオン自体が情報を取りに行くわけではなく、HAへの道を開くものです。実際に情報を取りに行くのは、その道を使って外から来る側（私やあなたのスマホ）です。
• 統合 = HAが外側の情報を「取り込みに行く」方向
  HAが能動的にTailscaleのAPIへ問い合わせて、「どの端末がオンラインか」という周囲の情報を自分のセンサーとして取り込みます。端末を操作したりはしません。なお、この問い合わせはインターネット経由でTailscaleのAPIに対して行うので、アドオンがなくても統合単体で動きます。

つまり「アドオンは入ってくる方向の土台、統合はHAが出ていって情報を集める方向」と捉えると正確です。

TailscaleはVM側から外へ接続しに行く方式なので、VMのネットワークがNATでもブリッジでも、インターネットに出られるVMなら参加できます。

違いは「どこにTailscaleを入れるか」だけで、VMの中身（HAの導入タイプ）で決まります。

• VMがHome Assistant OS そのもの → HAのアドオンストアからTailscaleアドオンを入れるのが一番簡単です
• VMがLinuxなどで、その中でHAを動かしている（Docker / Supervised / Core） → アドオンは使えないので、VMのOS側にTailscaleを直接インストールします

どちらのタイプかは、HAの「設定 → システム → 情報（修復）」にあるインストールタイプ表示で分かります。そこに何と出ているか教えてもらえれば、お使いのVMで使える方法を確定できます。

その根拠で確定ですね。HA OSのバージョンが記録され、Supervisorが動いてアドオンが入っているなら、VMはHome Assistant OSそのものです（私が案内した確認画面の項目は、現在のHAでは場所が変わっていたようです。失礼しました）。

これで方法が確定しました。アドオンストアからTailscaleアドオンを入れる方法がそのまま使えます。 手順は次の通りです。

あなたにやってもらうこと（HA側）

1. Tailscaleのアカウントを用意する（まだの場合。GoogleやGitHubのアカウントでサインインでき、多要素認証の設定もお願いします）
2. HAの「設定 → アドオン → アドオンストア」で、Community Add-onsの Tailscale をインストールして起動する
3. アドオンの画面（Web UI／ログ）に表示される認証リンクを開き、Tailscaleへの参加を承認する

私がやること
4. 私のコンピューターをあなたのTailscaleネットワークに参加申請し、承認リンクをお渡しします（参加の承認はあなたが行います）
5. 疎通テストとして、まず読み取りだけ（状態一覧の取得）で届くことを確認します

安全設定（並行して行う）
6. Tailscale管理画面のACLで、私の接続先を「HAの8123番ポートのみ」に制限する（書き方は私が用意します）
7. HA側でMuse専用の非管理者ユーザーを作り、その長期トークンを使う

この手順で連携を始めますか？

連携を開始しました。まず私のコンピューターのTailscale参加処理について、承認カードが表示されていたら許可してください。その後、あなたのTailscaleアカウントで私のデバイス「muse」を承認するためのリンクをお渡しします。

並行して、HA側では「設定 → アドオン → アドオンストア」からCommunity Add-onsの Tailscale アドオンのインストールを進めておいてもらえると、その後の流れが速くなります。

（以下、下記の処理を行ったが長文になるので一部のみ掲載）

・Tailscaleアカウントを作成し、ネットワーク（tailnet）を作成した。
・Home Assistantとコンピューター「muse」をtailnetに参加させた。
・Museの活動を制限するACLを設定した。

確認できました。私のコンピューターがあなたのTailscaleネットワークに参加しました。

状態：Connected
私のTailscaleアドレス：100.x.x.x（デバイス名 muse）

いま参加しているのは私の1台だけです。次はHome Assistant側です。HAの「設定 → アドオン → アドオンストア」でTailscaleアドオンをインストール・起動し、表示される認証リンクを承認すると、HAが2台目として加わります。

アドオンの導入が終わったら教えてください。こちらでHAのアドレスを確認し、続けて「私の接続先をHAの8123番ポートだけに絞るACL設定」と「専用トークンの用意」に進みます。

確認できました。Home Assistantがネットワークに参加しています。

HAのデバイス名：homeassistant
HAのTailscaleアドレス：100.x.x.x

続けて、私からHAへ実際に届くかの確認（8123番ポートへの到達テスト）を始めました。この接続には宛先ごとの承認が要るため、承認カードが表示されています。許可してもらえればテストが進みます。これはまだ認証なしの「届くかだけ」の確認で、HAの中身は読みません。

Home Assistant連携が完了しました。 認証付きで状態が読めるようになっています。

最終テストの結果です。

GET /api/ → {"message": "API running."}（認証成功）
Home Assistant Core 2026.11.1、コンポーネント306件
エンティティ 523件 を取得：センサー257、スイッチ43、バイナリセンサー37、オートメーション30 など

うまくいった経路は、Tailscale ServeのHTTPS経由でした。平文HTTPの経路では保管庫の認証情報が載らない仕様で、それが401の原因でした。トークンは流用先のない専用ユーザー「muse」のものが金庫に保管され、私のアクセスはHAの443/8123番ポートだけに制限されたままです。

これで、状態の確認はチャットでいつでもできます。機器の操作やオートメーション作成もAPI経由で可能ですが、操作系は都度あなたの確認を取ってから実行します。

---

Grok BotをTailscale経由でHAにアクセスさせる

MuseをTailscale経由でHAに繋ぐ作業が完了した後、Grok Botのニュース配信を確認していたところ、なんと、「Grok BotもTailscaleを使用できるようになった」というニュースがXに出ていたことが分かった。なんというタイミング。そこで、Grok BotもTailscale経由でHAに繋ぎ、Museとの違いを確認することにした。もともと、すでにGrok BotはMac mini経由でHAの情報を収集できていたので、その方法による情報収集と、MuseのTailscale経由でのHA情報収集とを比較しようと考えていたが、Grok Botに2つの方法を比較してもらうことにした。
また、同じTailscale経由での情報収集でも、Grok BotとMuseに違いがあるかも確認することにした。

（以下、Grok Botの回答）

はい、使えるようになったようです。11/10 に [@bot の公式投稿](https://x.com/bot/status/2120279511707386263)で、Grok Bot が Tailscale のネットワーク（tailnet）に参加できるようになり、自前の MCP サーバーや自宅ネットワーク上のアプリにも届くと発表されました。

ただ、今朝の時点では [Grok Bot の changelog](https://x.ai/changelog/bot) にはまだ載っていませんでした。なので、どのプランで使えるかや、どこから設定するかは公式の説明でまだ確認できていません。Muse と HA をつないだ同じ tailnet に Grok Bot も入れれば、HA に直接届く可能性があります。必要なら、設定方法と対象プランを調べます。

了解です。まず Grok Bot の Tailscale 対応について、設定方法と対象プランを公式情報で調べます。

調べ始めました。公式の設定方法と対象プランに加えて、いま Grok Bot がどの経路で HA につないでいるかも整理しておきます。比べるときの土台になるはずです。

設定方法がわかったら、Grok Bot を同じ tailnet に入れたうえで、2つのつなぎ方を比べる段取りを提案します。tailnet に入れるのは設定の変更なので、実際に入れるのはあなたの OK をもらってからにします。

調べました。Grok Bot の Tailscale 対応は公式の機能です。個人の tailnet は 11/4 の changelog に、会社の tailnet は 11/10 の @bot の投稿に出ています。

**設定方法**
Grok Bot の「Connect apps」で Tailscale を追加して、Authenticate を押します。Tailscale の同意画面で許可すると、Grok Bot の PC があなたののデバイスとして tailnet に入ります。条件は、あなたがその tailnet の Owner か Admin であることです。認証キーを貼ったり、CLI を入れたりする必要はありません。
（[プラグインの説明](https://github.com/cursor/plugins/blob/main/third_party/tailscale/README.md) 
／ [Tailscale 公式ブログ](https://tailscale.com/blog/oauth-apps-ga) 
／ [changelog](https://x.ai/changelog/bot)）

**対象プラン**
公式には「Premium なら使える」とは書かれていません。使えないアカウントには「Not available yet」と出る仕組みなので、Premium で使えるかは実際に追加してみないとわかりません（未確認）。地域の制限は書かれていません。

**いまの Grok Bot と HA のつなぎ方**
Tailscale は使っておらず、Mac mini を中継しています。Mac mini 上で `http://x.x.x.x:8123` を長期トークン付きで呼び出す形です。そのため、Mac mini がオフラインになると届きません。

比べる前に確認したいことが1つあります。Grok Bot を tailnet に入れても、HA 自体が tailnet に入っていないと届きません。HA に Tailscale アドオンを入れたか、LAN を流すサブネットルーターがあるか、どちらかが必要です。なお、公式説明ではサブネットルート経由で使えるかがまだはっきりしないので、HA 自体が tailnet に入っている方が確実です。

ほかに注意点が2つあります。
- Grok Bot のブラウザは `100.x` のアドレスを開けないことがあるので、比べるときは HA の API を使うのが確実です。
- HA の画面を `100.x` で開くと「Invalid client id」が出る可能性があります。

Muse 用には、どうつなぎましたか？

HA 自体が tailnet に入っているなら、一番確実な形です。次は Grok Bot 側に Tailscale を追加して、接続カードを出します。

Tailscale を追加しました。HA が入っているのと同じ tailnet で認証してください。つながったら、Grok Bot から HA に届くか確かめます。

Grok Bot を tailnet につなげました。続けて、HA まで届くか確かめます。

届きました。Grok Bot から tailnet 経由で `homeassistant.xxxxxx.ts.net:8123` に接続できています。
Premium でも使えることが確認できました。Grok Bot 側の接続キーの期限は 2027/5/10 です。

比べ方は次の形を考えています。
1. 同じ HA の読み取り（状態の取得だけで、操作はしません）を、Mac mini 経由と tailnet 経由の両方で行い、速さや手間、Mac mini が止まっていても届くかを比べます。
2. HA について同じ質問を、Grok Bot（tailnet 経由）と Muse に投げて、答えの違いを見ます。Muse にはあなたから聞いてもらい、返ってきた答えをここに貼ってもらえれば、並べて整理します。

質問は「今点いている照明は？」「各部屋の温度は？」「今日動いた自動化は？」の3つでどうでしょう。ほかに試したい質問があれば教えてください。OK なら、次のメッセージで読み取りを始めます。

始めます。Mac mini 経由と tailnet 経由の両方で、3つの質問について HA から読み取ります。

読み取りを始めました。そのあいだに、同じ3つの質問を Muse にも聞いてもらえますか？答えをここに貼ってもらえれば、Grok Bot の答えと並べて比べます。

1. 今点いている照明は？
2. 各部屋の温度は？
3. 今日動いた自動化は？

tailnet 経由で、HA から3つの質問の答えを読み取れました。Mac mini を通さず、私の PC から直接届いています。

Grok Bot の答え（10:47 時点）
1. 点いている照明は、今はありません。
2. 温度は、居間 21.7℃、寝室 24.1℃、2階 15.8℃、温湿度計 15℃ です。「2階 屋外」と「2階 1階」のセンサーは応答がありませんでした。参考までに、暑さ指数（WBGT）は 18.2 です。
3. 今日動いた自動化は3つです。9:21「玄関カメラ30秒動き検知→FireTV」、10:09「Ring 玄関 録画を保存」、10:32「AIニュース通知 OpenAI」。

速さ
tailnet 経由の応答は、1回目だけ 1.2 秒かかり、2回目以降は約 0.6 秒でした。全エンティティ（524件）の取得は 1.4 秒です。Mac mini 経由は、認証なしの応答だけで 0.95 秒でした。Mac mini 経由で同じ3問を取るには、トークンを Mac mini に暗号化して渡す手間がかかるので、今回はそこまでやっていません。

気づいたこと
tailnet に届くのは、あなたとの会話の中から私が直接動かしたときだけでした。裏で動く作業からは届きませんでした。定期実行（ルーティン）で使えるかは、まだ試していません。

記録は 2026-11-11-ha-route-compare.md に残しました。Muse の答えを貼ってもらえれば、並べて比べます。

並べてみると、データはほぼ同じで、違いは答えの深さでした。

温度と自動化 は両方とも一致しています。温度の小さな差（居間 21.7 と 21.9、温湿度計 15 と 15.3）は、読んだ時刻が2分違うためだと思います。自動化の3件は、時刻まで同じでした。

照明 は Muse の答えのほうが良かったです。私は light.* だけを見て「点いている照明はありません」と答えました。Muse は、照明の機器が登録されていないこと、赤外線リモコンのスイッチ「ライト」は状態を持たないこと、ON になっているのは照明以外のスイッチだということまで説明しています。私の答えは、事実としては合っていても誤解を招く書き方でした。

記事で使えそうな違い
・Muse は HA の構造まで読んで、「わからない理由」を説明してくれます。

・Grok Bot は、指示どおりの範囲だけを素早く取ってきます（応答は約 0.6 秒）。見る範囲を広げれば、Muse と同じ説明もできると思います。

・両方とも Mac mini を通らず、tailnet から直接 HA に届いています。

照明の質問だけ、スイッチも含めて取り直しましょうか？同じ条件にそろえたうえで、もう一度比べられます。

今のままだと、記事で「Muse のほうが賢かった」と書いてしまいかねないからです。照明の差は、AI の性能というより、私が light.* だけを見るように絞ってしまったことで生まれた可能性があります。
スイッチも含めて取り直せば、Muse と同じ条件で比べられます。それで私も同じ説明ができれば、違いは「最初にどこまで見に行くか」という振る舞いの差だとわかります。できなければ、本当に答えの深さに差があると言えます。
記事で比べるのが「普通に質問したときの答え方」なら、今の結果のままで十分です。その場合、取り直しは要りません。

取り直します。今回はスイッチ類と照明の登録状況まで見ます。

照明を取り直したところ、結論は Muse と同じになりました。

**取り直した答え（10:55）**
HA には照明（`light`）の機器がひとつも登録されていません。照明らしいものは、スイッチの「ライト」（`switch.raito`）だけでした。このスイッチは状態が「不明（unknown）」になっていて、点いているかどうかは HA からはわかりません。赤外線リモコンのように、状態を持たない仕組みだと思われます。

ON になっているスイッチは、次のものでした。どれも部屋の照明ではありません。
- Mac モニターのプラグ
- 玄関とフリーカメラのモーション検知
- LaMetric のスクリーンセーバー
- RIVER2 のビープ音
- Power1000 のバックアップ残量の設定
- API Usage

**わかったこと**
見る範囲をそろえれば、Grok Bot も Muse と同じ説明ができました。差が出たのは、最初の質問でどこまで自分から見に行くかです。
- Muse は、聞かれただけで HA の構成まで調べて、「わからない理由」も一緒に答えました。
- Grok Bot は最初、照明の種類（`light`）だけを見て、「ありません」と短く答えていました。

記事では「最初の答え方」と「範囲をそろえたときの答え」を分けて書くと、公平な比較になると思います。この結果も `2026-11-11-ha-route-compare.md` に追記しました。

---

Grok Botで、Mac miniを経由する方法と、tailnetを経由する方法を比較

Grok Botで、ローカルのMac miniを経由する方法と、tailnetを経由する方法を、同じ3つの質問を行って比較した。

Mac mini 経由でも、同じ3つの質問をすべて取れました。答えの中身は tailnet 経由と同じでした。違ったのは速さと手間です。

答え（10:58 時点、2つの経路で同じ）

1. 照明の機器は登録されていません。「ライト」スイッチは状態が不明です。ON になっているのは、Mac モニターのプラグなど照明以外のスイッチでした。

2. 温度は、居間 21.9℃、寝室 24.3℃、2階 15.8℃、温湿度計 15.6℃ です。屋外と1階のセンサーは応答がありませんでした。

3. 今日動いた自動化は、9:21、10:09、10:32 の3件で、tailnet 経由と同じでした。

温度が数分前と少し違うのは、取った時刻がずれているためです。

2つの方法の比較

	Mac mini 経由	tailnet 経由
HA の応答（中央値）	0.006 秒	0.61 秒
全データ（524件）の取得	0.02 秒	1.4 秒
準備の手間	多い（鍵を作り、トークンを暗号化して Mac mini に渡し、使ったら消す。Mac mini 上の操作が5回ほど）	少ない（私の PC からそのまま呼び出すだけ）
前提	Mac mini がオンラインであること	HA の Tailscale アドオンと、tailnet 上の Grok Bot
止まる原因	Mac mini のオフライン（既知のアイドル切断）	裏で動く作業からは届かなかった

速さは Mac mini 経由が圧倒的です。同じ LAN の中なので、ほぼ一瞬で返ってきます。tailnet 経由は1回あたり 0.6 秒ほどかかりますが、人が質問して待つ分には気にならない差です。実際に使って差を感じるのは、速さよりも準備の手間と、Mac mini に頼らなくてよい点の方だと思います。
一時ファイルは、Mac mini と私の PC の両方から削除しました。結果は 2026-11-11-ha-route-compare.md に追記してあります。

はい、そうです。ただ、準備に時間がかかると言っても数十秒ほどで、今回も実行そのものは1秒もかかっていません。

手間が増えるのは、HA のトークンを Mac mini に安全に渡す手順があるからです。鍵を作り、トークンを暗号化して送り、使い終わったら消すので、毎回 Mac mini 上で5回ほど操作します。tailnet 経由ならトークンは私の PC の中に置いたままなので、その手順がいりません。

ちなみに、Mac mini 上にトークンを置きっぱなしにすれば準備は短くなります。ただその場合、Mac mini にトークンが残り続けることになります。

HA の中でできることの範囲は、どちらの経路でも同じです。両方とも同じ長期トークンを使うので、HA が許す操作はまったく変わりません。違いが出るのは、HA 以外に何に届くか、誰の承認がいるか、いつ使えるか、の3点です。

項目	Mac mini 経由	tailnet 経由
HA の状態の読み取り	できる（確認済み）	できる（確認済み）
HA の操作（照明・通知・自動化）	トークン上はできる。 ただし毎回あなたの承認が前提	同じ
HA の権限の範囲	トークンを発行したユーザーの権限そのまま	同じ
HA 以外の家の機器 （プリンタ、ESPHome など）	同じ LAN にあるので届く	tailnet にいない機器には届かない（今は HA だけ）
Mac mini 本体のファイルやアプリ	触れる（Mac 上のコマンド実行の承認が必要）	触れない
承認のいる場面	Mac 上でコマンドを実行するたびに、ローカル実行の承認が必要	私の PC から直接呼べるので、その承認はいらない
トークンの置き場所	毎回暗号化して Mac に渡し、使ったら消す	私の PC の秘密情報として保管
定期実行（ルーティン）で使う	Mac mini がオンラインなら可能	裏で動く作業からは今回届かなかった。ルーティンからはまだ試していない
止まる原因	Mac mini のオフライン（既知のアイドル切断）	Tailscale 側の接続や鍵の状態
ブラウザで HA の画面を開く	Mac 上なら可能	私の PC のブラウザは 100.x のアドレスを止める場合がある（試していない）

まとめると、Mac mini 経由は届く範囲が広い分、承認と手間が増えます。tailnet 経由は HA だけに絞られている分、手軽で安全側です。セキュリティの観点で比べるなら、tailnet 経由の方が届く範囲が狭いと言えます。

---

Grok Botはどちらの経路を使うべきか

Grok Botは、本記事の作業により、Max mini 経由でもtailnet 経由でもHAにアクセスできるようになったが、どちらを使えば良いかについて1つの事例が見つかったので紹介する。
Grok Botは、私が外出したことを検知してHAの状態を報告するように構成しており、下記のようなやりとりがあった。

15:38（日本時間）に外出を検知しました。いま Mac mini がオフラインで HA が読めないため、エアコンや照明のつけっぱなしは確認できていません。

〇〇は今夜晴れで、明日朝の最低気温は10℃の予報です。帰りが夜遅くなりそうなら、帰る30分前くらいに寝室のエアコンを暖房20〜22℃で入れておくと快適だと思います（推定）。つけっぱなしが気になるときは、Mac mini の Grok Bot ウィンドウを一度前面に出してもらえれば確認します。

確かめてみますね。

おっしゃるとおりでした。私のコンピューターから tailnet 経由で HA に直接つながり、Mac mini を通さずに読み取れました。さっそく見たところ、エアコンと照明はすべてオフで、つけっぱなしはありません。
さっきの外出通知はまだ Mac mini 経由で読みに行く手順のままだったので失敗していました。HA を読むルーティン（外出時の提案や週次診断など）を tailnet 経由に切り替えましょうか？

tailnet 経由の構成の構築を相談していたBotは、外出を検知した旨の報告を行ってきたBotは違うBotだった。Bot間での情報共有は行われていなかった。

切り替えます。HA を読むルーティンの手順を順に書き換えますね。

切り替えました。HA を読む次の5つのルーティンが、Mac mini を通さず tailnet 経由で HA を読むようになりました。

・HA アラートへの提案（外出時の提案や音声依頼も含む）
・HA ゾーン出入りの受け口
・HA 週次診断（土曜10時）
・玄関 Ring 来訪・置き配の日次報告（毎日18時、今日の17:57ごろが最初）
・消費電力の大きい機器リストの更新（日曜9時）

どれも、tailnet でつながらないときだけ、これまでの Mac mini 経由を試します。報告先はこれまでどおりこのチャットです。

Mac mini 経由が向いているのは、HA だけでは足りない作業をするときです。

・HA 以外の家の機器も一緒に扱うとき。 Bambu Lab のプリンタや ESPHome の機器のように、tailnet に入っていない LAN 上の機器にも届くのは Mac mini 経由だけです。

・Mac mini 上のファイルやアプリと組み合わせるとき。 たとえば HA のデータを Obsidian の保管庫に書き出す、Stream Deck の設定と突き合わせる、といった作業です。

・大量のデータを何度も読むとき。 同じ LAN の中なので応答が約100倍速く、履歴をまとめて取るような重い読み取りで差が出ます。

・tailnet が使えないとき。 HA の Tailscale アドオンが止まっている、鍵が切れた、といった場合の予備になります。

・HA の画面をブラウザで開いて確認したいとき。 私の PC のブラウザは tailnet のアドレスを開けない場合があるためです（まだ試していません）。

ふだんの「今の状態を聞く」程度の質問なら、手間が少なく、届く範囲も HA だけに絞られる tailnet 経由で十分です。

HAにアクセスする場合、tailnet経由で行った方がよさそうだ。

Grok Botはローカルファイルを扱うことができるので、そこがMuseとの差別化ポイントとなる。

より多くの提案を受けたい時はMuseに任せた方がよさそうだ。ただし、多くを任せすぎると、試行するつもりもない提案もしてくるので鬱陶しい状態になる。任せる分野や数には注意が必要だ。

Grok BotとMuseの両方が、iOSのリマインダーにアクセスできるようにコネクターを設定し、調査や検証を行いたいことをリマインダーに入力したところ、Museからは2件、リマインダーを見たことによる提案が行われた。Museからの提案が、着手のきっかけになることもありそうだが、提案が多くなりすぎないようにバランスを取る必要がある。