Grok BotのBotからの通知をHOME Assistantのダッシュボードに表示した

2026年10月7日2026年10月8日

下記の記事で、Grok Botのクラウドの仮想パソコン（boxと呼ぶらしい）のTerminalについて、ChatGPT-5.6 Solに質問したところ、「（Terminalは）Botが使っている仮想パソコンの裏側を、ユーザー自身が確認できる窓」という回答があったので、各Botの稼働状況をモニターする方法についてChatGPT-5.6 Solに相談した。
結果的に、HOME Assistanの既存ダッシュボード「AI Monitor」に、それを表示する方法ついてChatGPT-5.6 Solから、MQTT Brokerを使う方法（正確には各Botの状態を記録する「status.json」を使う方式）の提案を受け、検討を進めてもらったが、その内容を検討した結果、Macの「通知」の機能を流用する方式に変えることにした。その経緯を紹介する。

（補足）Macの「通知」の機能を流用する方式もMQTT Brokerを使うので、以前検討していた方式は、各Botの状態を記録する「status.json」を使う方式とするのが正しい。

Grok Botの状態監視――「status.json」を使う方式の検討

「status.json」を使う方式を検討した理由

Grok Botでは、各Botの作業状況を個別に確認できますが、複数Botの状態の表示をHome Assistantの既存ダッシュボード「AI Monitor」に追加する方式を検討しました。

そこで最初に検討したのが、各Botが自分の状態をJSONファイルへ書き出し、その内容をMQTT Broker経由でHome Assistantへ送る方法です。

想定した流れは次の通りです。

Grok Bot
  ↓
status.json
  ↓
Mac mini
  ↓
MQTT Broker
  ↓
Home Assistant
  ↓
AI Monitor

各Botは、たとえば次のような状態を記録します。

{
  "bot": "Home Assistant Watcher",
  "state": "working",
  "task": "Home Assistant更新情報を確認",
  "updated": "2026-10-07T01:25:12+09:00"
}

Home Assistant側では、working、waiting、done、error、idleなどの状態をセンサーとして表示する想定でした。

検討して分かったこと

「status.json」を使う方式には、Home Assistantとの相性がよく、Botごとの状態を一覧化しやすいという利点があります。updated時刻を使えば、長時間更新されていないBotを「Stale」と判定することもできます。

一方で、実装を進めるには次のような仕組みが必要でした。

各Botにstatus.jsonを更新させる
Mac mini側にMQTT送信用スクリプトを置く
MQTT TopicやSensorをBotごとに管理する
boxから自宅LANへ直接届かないため、Mac miniを中継する
Grok Botのローカル実行を「常に許可」にする
MQTT認証情報やAuto-reviewの安全設定も管理する

また、表示できる内容は基本的に、こちらであらかじめJSONに定義した項目に限られます。

「status.json」を使う方式のメリット・デメリット

メリット	デメリット
Home Assistantと連携しやすい	設定項目が多い
Botの状態を一覧表示しやすい	各Botに状態更新ルールが必要
ほぼリアルタイムで反映できる	Mac miniの中継処理が必要
Stale判定などの監視がしやすい	ローカル実行の権限管理が必要
状態を構造化して扱える	自然文の通知内容は扱いにくい

今回は採用を見送った

「status.json」を使う方式は、Botの現在状態を機械的に監視する方法としては有効です。

ただし今回の目的では、Bot構成を変更するたびにstatus.json、MQTT Topic、Home Assistant側の設定を保守する必要があり、少し大掛かりでした。

また、実際には「Botが今どんな状態か」だけでなく、Botから届いた具体的なメッセージ内容もAI Monitorで見たいと考えました。

そのため、「status.json」を使う方式はいったん見送り、もっと簡単に既存の情報を利用できる方法を検討することにしました。

「status.json」を使う方式のメリットとデメリットについて検討した詳細版を下表に示します。

観点	メリット	デメリット
Home Assistantとの相性	Home Assistantとの連携がしやすく、センサー化・カード表示・自動化へつなげやすい	MQTT Broker、Topic、Sensorなど設定項目が増える（ただしMQTT Brokerは構築済み）
状態の一覧性	working / waiting / done / error / idle などを統一して一覧表示しやすい	Bot自身が正しく状態を書き出す前提になる
リアルタイム性	状態変更時にPublishすれば、ほぼ即時にAI Monitorへ反映できる	状態更新処理を各Botに組み込む必要がある
再起動への強さ	MQTTの`retain`を使えば、Home Assistant再起動後も最新状態を復元しやすい	retainされた古い状態を「現在状態」と誤認する可能性がある
異常検出	`updated`時刻を使ってStale判定ができる	Botが止まっても最後の`working`が残るため、補助ロジックが必要
拡張性	状態、作業内容、工程、時刻など項目を自由に増やせる	項目を増やすほどJSON仕様や表示側の保守が必要
Bot追加	TopicやJSON形式を統一すれば横展開しやすい	Botを追加するたびにstatusファイル、Topic、HA側設定を増やす必要がある
セキュリティ	MQTT認証情報をMac mini側だけに持たせれば、boxへ秘密情報を置かずに済む	Mac mini側の認証情報管理やBroker設定が必要
boxとの接続	Mac miniを中継にすれば、自宅LANのBrokerを利用できる	boxからBrokerへ直接届かず、中継処理が必要
Mac mini連携	専用Publishスクリプトを置けば、Bot側の処理を単純化できる	Grok Botのローカル実行を有効にする必要がある
自動実行	「常に許可」にすれば無人で状態送信できる	MQTT用スクリプトだけを限定許可できず、Mac上の他コマンドも通る可能性がある
安全対策	Auto-reviewで危険操作を止める補助ができる	Auto-reviewは完全な権限制御ではなく、設定も増える
表示内容	機械的な状態監視には非常に向いている	Botが実際に通知した自然文や詳細内容は、そのままでは表示しにくい
保守性	一度安定すれば監視基盤として使い回せる	status.json、Python、MQTT、HA設定など管理対象が多い
障害切り分け	各段階が明確なので、どこで止まったか調べやすい	経路が長く、障害ポイントも増える
全体評価	構造化されたBot状態を監視する仕組みとしては優秀	今回の「Botの通知内容を見たい」という目的にはやや大掛かり

「status.json」を使う方式は「Botの現在状態を機械的に監視する」用途には強く、すでにダッシュボード「AI Monitor」でMQTT Brokerを利用しているので、既存の仕組みを一部流用できるというメリットがあった。一方で、各Botの状態表示が、「working / waiting / done / error / idle」程度のものとなり、Botが実際に何を処理したかまでは見ることができず、あまり有用なものではないことが分かった。また、仕組みが大きくなり、保守も増え、正常動作を維持するには多くのメンテが必要であることが予想できた。

Macの「通知」を流用する方法を検討

Macには「通知」の機能があり、各Botから通知が来ていたことに気がついた。この通知により、Botが実際に何を処理したかまでは見ることができるので、この通知を「AI Monitor」に表示することを検討した。

この通知があれば、「AI Monitor」に表示する必要はないのではとも考えたが、私の場合、操作しているMac miniとは別のMac mini（旧式のIntel Macを流用）のVMにHOME Assistantを導入し、操作しているMac miniに接続したモニタとは別のモニタに「AI Monitor」を常時表示させているので、Grok Botの利用制限枠などの情報とともに、各Botの状態表示をまとめて表示できる効果は大きい。別モニタで表示しているので、急激な利用枠消費が発生していることも見つけることもできた。

また、操作しているMac miniの画面の右上に各Botからの通知バナー（Bot名と要約メッセージ）が表示されるが、通知を「持続的」にすると、その表示を消す手間がかかり、「一時的」にするとそれに気づいて内容を理解するまでに消えてしまうという状態だった。別モニタに、要約していない状態の通知を表示する仕組みにしておけば、処理内容をいつでも容易に確認することができる。また、表示要領（1つの通知を上書きしていくか、いくつの通知を表示させるか、Bot毎に通知をまとめるか、重要な通知は残るようにするかなど）を自由に構成できるようなので、実仕様で表示要領を検討する予定である。

以下、通知を流用する方式について検討した内容を紹介する。

Botが実際に何を処理したかを見るのに、Mac miniの画面の右上に表示される、各Botからの通知を流用して「AI Monitor」に表示させることはできますか

（以下、ChatGpt-5.6 Solの回答）

はい。しかも現在のmacOS 27なら、かなり現実的な方法があります。今回の「画面右上に出るGrok Botの通知」を利用する方式は、先ほどのstatus.json方式とは完全に独立した監視経路として成立します。

一番おすすめなのは、macOS 27で新しく追加された「通知を受信したとき」のショートカット・オートメーションを使う方法です。AppleはmacOS 27を含むOS 27で「Notifications」を新しいAutomationトリガーとして追加しており、通知元アプリに加えて、Title・Subtitle・Messageで絞り込めます。Appleサポート

構成はこうなります。

各Grok Bot
   ↓
Grok BotアプリがmacOS通知を出す
   ↓
Mac右上の通知
   ↓
macOS 27 Shortcuts
「Grok Botから通知を受信」
   ↓
通知の
・Title
・Subtitle
・Message
・時刻
を取得
   ↓
MQTT Publish
   ↓
MQTT Broker
   ↓
Home Assistant
   ↓
AI Monitor

これはかなり魅力的です。Bot側にstatus.jsonを書かせる必要がありません。Botに監視用のルールを追加する必要もありません。 普段すでにMacへ届いている通知を監視情報として再利用するからです。

今回の調査の有用な副産物は、macOS 27で新しく追加された「通知を受信したとき」のショートカット・オートメーションかもしれない。今回実現したBot通知表示が実現したのも、この機能によるところが大きい。この機能を応用するだけで、有用なオートメーションを他にも作成できそうだ。

Botごとの識別もできる可能性があります

ここで確認したいのが、現在右上に表示される実際の通知です。

例えば通知が、

Home Assistant Watcher
Home Assistant 2026.10.1 の確認が完了しました

のようになっているなら、非常に都合がいいです。

Shortcut側で、

Title = Home Assistant Watcher
Message = Home Assistant 2026.10.1 の確認が完了しました

として取得できれば、そのまま

grokbot/home-assistant-watcher/notification

へ送れます。

同様に、

Supervisor
CarPlay-Android Auto Watcher
Blog Idea Editor
Home Assistant Watcher
Automation Watchdog

などの各Botの通知を自動分類できます。

ただし、すべての通知のタイトルが単に

Grok Bot

となり、本文にもBot名がない場合は、通知だけではどのBotから来たか特定できない可能性があります。

したがってここは実物を1件確認する価値があります。

通知の実物を確認したところ、下記のように表示されていた。タイトルがBot名称、本文がそのBotからのメッセージ（要約）になっている可能性が高く、各Botの通知を自動分類できる可能性が高いことが分かった。

さらに便利なのは「通知内容そのもの」をAI Monitorに表示できることです

status.jsonを作成する従来の方式では、

Working
Waiting
Done
Error

のような状態をBot自身に申告させようとしていました。

Macの「通知」を流用する方式なら例えば、

Grok Bot 通知

Home Assistant Watcher
✅ Home Assistant更新確認が完了しました
01:24

CarPlay Watcher
⚠ 新しいCarPlay記事が見つかりました
00:58

Automation Watchdog
🔴 Routineが失敗しました
00:31

のように、実際にMacへ届いた通知をそのままAI Monitorへ再掲できます。

さらに通知本文のキーワードから、

完了 → Done
失敗 / Error → Error
確認してください → Waiting
開始しました → Working

と状態を推定することも可能です。

ただし、ここはstatus.jsonを作成する従来の方式との大きな違いがあります。

通知は「イベント」であって「現在状態」ではありません。

例えば最後の通知が、

「処理を開始しました」

だったとして、その後通知が来なければ、

Working

なのか、

途中で停止

なのか分かりません。

したがって通知を流用する方式では、

「現在状態」より「最新通知」

として表示する方が正確です。

AI Monitorには両方を並べるのが面白いです

最終的には、

┌──────────────────────────┐
│ Grok Bot Monitor         │
│                          │
│ HA Watcher    🟢 Working │
│ 作業：更新確認          　 │
│ 最終状態更新：38秒前   　　 │
│                         │
│ 最新通知                  │
│ ✅ HA 2026.10.1確認完了   │
│ 01:24                    │
└──────────────────────────┘

のように、

状態監視 = status.json → MQTT

と

実際の通知 = macOS通知 → Shortcuts → MQTT

を別系統で持つこともできます。

これはかなり強い構成です。

一方が止まっても、もう一方から状況を判断できます。

今回採用する方式では、status.jsonを作成しないので、1系統となる。

macOS 27のShortcutsを使う方式には大きな安全上の利点があります

以前なら、MacのNotification Centerデータベース（通知センターのデータベース）を直接読む方法が有力でした。

現在のmacOSでは通知履歴が概ね、

~/Library/Group Containers/
group.com.apple.usernoted/db2/db

のSQLiteデータベースに保存されています。macOS 15以降、この領域の読み取りにはFull Disk Accessが必要になる場合があります。Mac Forensics

Pythonでここを数秒ごとに監視すれば、

Grok Botの新規通知発見
     ↓
MQTT
     ↓
Home Assistant

も可能です。

ただし私は、最初からこの方法は選びません。

理由は、

Full Disk Accessが必要
Appleの公開APIではない
macOS更新でDB構造が変わる可能性がある
Grok Bot以外の通知にもメール本文や認証コードなどが含まれ得る

からです。

macOS 27にはApple自身が通知Automationを追加したので、今回はまずShortcutsを使うべきです。

ただし、1点だけ実機検証が必要です

OS 27のNotification Automationでは、通知元アプリだけでなくTitle・Subtitle・Messageを条件にできます。Appleの仕様上、通知内容を扱う仕組みが用意されています。Appleサポート

一方で、実際にどこまで通知データがShortcutへ渡るかは通知元アプリの実装にも左右されるようです。OS 27の利用例でも、アプリによって通知のTitle・Subtitle・Bodyが取得できるものと、うまく渡らないものが報告されています。Moneko

ですから最初の実験は非常に簡単です。

Grok Botの通知を1件受信 → Shortcutsでその通知を捕捉 → Title / Subtitle / Messageが取得できるか表示する

これだけです。

結果によって、

A. Bot名＋本文まで取れる
   → そのままMQTT方式へ

B. 通知は検出するが本文が取れない
   → Notification Center DB方式を検討

C. Bot名だけ取れない
   → 本文解析でBot判定できるか確認

と進めればよいでしょう。

実機検証として、HOME Assistantのダッシュボード「AI Monitor」にテスト表示させたところ、下図のように表示され、Bot名＋本文が取れるだけでなく、要約された「通知バナー」には表示されていなかった情報（受信日時）も表示されていることが分かった。ただし、どの段階で付与されたかは未調査。

現時点では、こちらを先に試す価値が高いです

今回まで検討した方法を比べると、

方法	Bot側変更	Mac側権限	得られる情報	評価
status.json＋MQTT	必要	ローカル実行許可	現在状態	◎
macOS通知＋Shortcuts＋MQTT	不要	比較的少ない	実際の通知	◎
Notification DB＋Python	不要	Full Disk Access	通知履歴	○
画面右上をAccessibilityで読む	不要	Accessibility	表示中通知	△

したがって、「AI Monitorに各BotからMacへ届いた通知を表示する」だけなら、まずmacOS 27の通知Automationを試すのが最も自然です。

ショートカット（Shortcuts）の設定

下図に現時点のショートカットの設定内容を示す。
・「トリガーを通知」のアクションを設定し、「Grok Bot」からの通知を受け取った場合のアクションを設定する
・「URLの内容を取得」を追加し、Codexが作成したHOME AssistantのWebhook URLを入力する（一部表示を省略）
・キーとして、「source_name」に変数「タイトル」を入力し、「message」に変数「本文」を入力する。
　「本文」と表示されていないが、確かに変数「本文」が設定できていた。

ここまでの設定により、下図のようにHOME Assistantのダッシュボード「AI Monitor」に、Grok Botの通知を表示することができた。現在は、表示される通知は1つで、新しい通知で上書きされるように構成されている。

今後、実使用において、表示要領（いくつの通知を表示させるか、Bot毎に通知をまとめるか、重要な通知は残るようにするかなど）をいろいろ変えて、表示を最適化していく。