Home Assistantを、色々なシステムと連携するように構成してきたが、接続するデバイスが多くなると、それらのデバイスがどのように繋がっているのか分かりにくくなったり、どのような設定を行ったかを忘れてしまって仕様変更が難しくなったりする。
そこで今回は、MCP経由でCodexにHome Assistantの実環境を読み取らせ、各種の構成図を描かせてみた。
全体構成図から、障害影響図、セキュリティ境界図のようなものまで作成した。
作成した構成図を詳細に確認すると、HOME Assistantがどのように我が家を認識しているかが明確になり、知らなかった構造がいくつも見つかった。同じアンプが2つの連携で二重登録されていたり、使っていない操作窓口がunknownのまま放置されていたり、Codexなどの、MCPを使ってHOME Assistantと連携する構成（AI連携）そのものがセキュリティ図の登場人物になっていたりすることが分かった。
また、HOME Assistantの認識とユーザーの認識のズレ及びそのズレが発生する理由を調べ、それを記録し、次回調査で、AIがその記録を参照できるように構成する方法も探った。
本記事では、実施方法・指示のコツ・各種構成図・そして知らなかった家の構造を順に紹介する。
（注）本記事の内容は正確性を保証するものではない。
（2026年7月4日 追記）YouTube動画を追加しました。 https://youtu.be/h8XgWdMSGcw
1. 実施方法：MCPでCodexをHAに接続して機器情報を取得
手順の要点は3つ。
- CodexをMCP経由でHome Assistantに接続し、Codexに各種構成図作成を指示する
- 開示すべきでない情報は、一般的な情報に置き換えて表示する
- 機器の情報は、過去に取得したものを使うのではなく、最新の取得情報に基づいて作成するように指示する
以前の取得実績は「3エリア・49デバイス・405エンティティ」だったが、今回取得し直すと、「4エリア・52デバイス・447エンティティ・37連携」に増えていた。デバイスが増えると、構成図を人力でメンテナンスするのは現実的でなく、AIに描かせる意味がある。
一行メモ：構成図の鮮度は取得日時がすべて。図の隅に「調査日時」を必ず入れさせる。
2. 指示のコツ：「何を載せないか」を先に決める
構成図が複雑になりすぎないようにするため、「何を表示しないか」を先に指示した。具体的には、下記のように指示した。
- 「状態不明エンティティ」など、表示されても何なのか分からないものは図示しない
- 実物が接続されていなくても、エンティティが残っているもの（ライトなど）は点線で表現する
- 接続が一方通行か双方向か、制御する側かされる側かを区別する
- 複雑すぎて分かりにくくならないようにする
これらの指示により、Codexは、RSS・診断センサー・内部アドオン名は図から除外し、機器を「家庭内LANで双方向」「クラウド経由」「受信中心」「点線候補」に分類して構成図を作成した。
一行メモ：AIに図を描かせる前に「載せないものリスト」を渡す。これにより、より早く、ユーザー要望に沿った構成図に近づくことができる。
3. 全体構成図：我が家はこう見えていた
下記の全体図は、操作する側（iPhone・Pixel・Mac、Stream Deck+、AIアシスタント）、制御の中心となるHome Assistant、そして通信経路と機器という3層構造で表現された。
機器側は接続方式で色分けされ、家庭内LANで双方向（Apple TV、Fire TV、Marantz、LaMetric）、クラウド経由（SwitchBot機器、Ring、Alexa機器）、受信中心（EPSONプリンター、温湿度・開閉センサー、ESPHome赤外線受信機）に分類・整理された。
そして下図に表示されているのが点線組（ライト、アンプ、レグザ、Tapoプラグ、応答していないEcho系）。
登録は残っているが、いま応答を確認できない機器であり、点線は「登録が残っているが現在応答を確認できない」構成であることを示している。
構成図が複雑にならないように、図示しないものを指定して構成図作成を依頼した。表示が重なる、文字がはみ出るなどの不具合が多く発生するのではないかと思っていたが、予想に反して整った図が1回の指示で作成できた。構成図の作成中には、「目視検査で３点修正します」というようなメッセージが表示され、レイアウトなどが整っているかを確認している様子が伺えた。A3サイズの用紙に印刷するという前提で各構成図が作成され、接続関係を示す「矢印」にも適切な説明が付加された。
4. 詳細図3種と、図に載らなかった「カメラ映像の謎」
全体図に続いて、特定の条件を指定して、その条件に関連する構成のみを抽出した構成図（詳細図）も作ってもらった。
詳細1は、SwitchBotに関連する機器の構成図、
詳細2は、映像・音響とStream Deck+の操作経路の構成図、
詳細3は、出入口・カメラ・通知の経路を示す構成図である。
詳細2の構成図を作成して分かったことだが、Stream Deck+のダイヤルは非稼働状態となっているが、ダイヤルによって音量が調整できるように修正している。HOME Assistantの認識と実体が食い違っていたので、Codexに修正を依頼した。
詳細2の図に、「ダイヤルは現在非動作」という記載や、「現行の制限」の記載で、ダイヤルは動作していない旨が表示されていますが、下記のブログ記事の記載箇所で紹介しているように、動作するように修正しています。下記の記事の内容を参照して「詳細2」の図を修正してください。
記事タイトル：「Codexの助けを借りてStream Deck+にHOME Assistantの機能を設定した」
（https://roompine.com/codex-stream-deck-home-assistant-1/）
記載箇所：「Stream Deck 設定（④ TV音量調整）」
Codexの回答
「詳細2」を修正しました。ブログ記事に基づき、以下を反映しています。
- 「ダイヤルは現在非動作」「現行の制限」を削除
- 回転：現在音量から約1%／刻み
- 上限80%
- 単押し40%・長押し20%
ticks→HAスクリプト→Marantzの経路を図示- 現在のHAスクリプトも存在・動作構成を確認済み
今調べてもらった内容をどこかに保存しておけませんか。次回調査しても分かるようにです。例えば、HAのオートメーションにはメモが追加されているということですので、そのメモのような記録場所はありませんか
Codexの回答
保存しました。HAのスクリプト「Marantz 音量調整 Stream Deck」のdescription欄に以下を記録しています。
- 回転量
ticksによる相対音量調整 - 1刻み約1%、上限80%
- 単押し40%、長押し20%
- Stream Deck側の設定方法
- 参照ブログURL
- 確認日：2026-07-03
スクリプトを再読み込みし、処理本体が変わっていないことも確認済みです。
次回はスクリプト設定を取得すれば、この説明も一緒に確認できます。
HA画面では「設定 → 自動化とシーン → スクリプト → Marantz 音量調整 Stream Deck」の説明欄で確認できます。
HA公式：Scripts
どのような修正を構成に加えたかを記録できる場所が見つかり、次回からは、Codexが参照してくれるようである。
このようにしてHOME AssistantやCodexが気づいていないことを教えていき、認識のギャップを少しでも埋める地道な作業もまだ必要なようだ。
また、詳細図3では、「FireTVでカメラ映像」という自動化はアクションが空で、カメラ映像を表示する処理はなく、「Stream Deckカメラ映像」も現在応答がないので、”動作中の経路”としては認識されておらず、未成立経路として点線表示されていることが分かった。
HA上のデータによりこのように判断されたわけだが、現実には、Fire TVリモコンの音声入力ボタンを押して「Alexa、カメラ映像を見せて」と言うと、「わかりました」の音声とともにFire TVの画面がカメラ映像に切り替わった。
つまり、HAの構成図に載らない経路が実在している可能性があったが、どの構成で設定したのか忘れてしまっていた。仮説としては、RingカメラはAlexa対応なので、Alexaアプリ側のRing連携（スキル）→ Alexa Cloud → Fire TVという、HAを一切経由しない経路で動いている可能性があったので、Codexに調べてもらった。
Codexの回答
結論：HA経路とAlexa経路が別に存在します。
確認結果：
- 「FireTVでカメラ映像」自動化：トリガー0、アクション0
- 「カメラ映像30秒動き検知→FireTV」：状態更新だけで映像表示処理なし
- RingライブビューとFire TVはHAに存在
- HAの自動化は、音声操作による映像表示に関与していない
Ring公式も、RingとAmazonアカウントを連携すると、「Alexa、カメラ映像を見せて」に相当する音声命令でFire TVへライブ映像を表示できると説明しています。Ring公式：Alexaでカメラを見る、Ring・Alexa接続方法
実際の論理経路は、ほぼ次の形です。
Fire TVリモコン音声 → Fire TVのAlexa → Alexa／Ring連携 → Ringライブビュー → Fire TV
Home Assistantは通りません。
したがって詳細3は、次の2経路を併記するのが正確です。
- 点線：HAの「FireTVでカメラ映像」自動化（空で未成立）
- 実線：Alexa音声→Ring→Fire TV（HA非経由・実動作確認済み）
Ringスキルの設定を最終確認する場合は、Ringアプリの「コントロールセンター → Amazonアカウントのリンク → リンク済みAlexaデバイス」でFire TVを確認できます。HAからこのアカウント連携状態自体は読み取れません。
詳細3の構成図を修正し、2経路を併記した。
Alexaリモコンの音声入力を使ってカメラ映像をFireTVに表示できることは覚えていたが、どこでどのような設定を行なったかはよく覚えていなかった。詳細3の構成図を確認することにより、経路を調べるきっかけができ、HAを介さない別経路で実現していたことが確認できた。また、この事情もHAに記録してもらった。
この図は「HAから見える世界」の正確な地図であり、地図と現実の食い違いが、忘れていた設定を思い出させてくれた。構成図づくりの副産物として、これはかなり実用的な活用方法だと思う。
一行メモ：図と現実がズレたら、それは「AIのミス」ではなく「HAの外にある経路」のサイン。
5. 知らなかった構造①：Marantzの二重登録
AVアンプであるMarantz NR1711がDenon AVR連携とHEOS連携の両方で登録されていることは、これまでの調査で分かっていたが、これまでに作成した構成図では、その詳細が表示されていなかったので、二重登録だけの詳細図をCodexに作成してもらった。
詳細図を作成することによって、その機能の違いをより明確に理解することができた。
また、「HA表示」や「モデル」が表示されるので、機器を区別するのにも役立つ。
さらに、小さい文字であるが、この構成図を作成した時（調査時）の機器の状態が表示されているのも気が利いていて機器の状態を正確に把握できる。MCPで実際に最新の情報を取得している強みである。
6. 知らなかった構造②：unknownのまま放置されていた「switch」
上図の赤外線エアコンについて説明すると、「物理機器」としては1つの赤外線エアコンだが、「HAデバイス」としては「SwitchBot エアコン」として登録されており、エンティティ（論理機能）として「climate」と「switch」の2つを有していることが分かる。
climateは実物ではなく、HA上の「空調機器を操作するための論理的な操作窓口」であり、
関係を1行で書くと、climate（HA上の操作窓口）→ SwitchBot Cloud → Hub 2 → 赤外線 → 実物のエアコンとなる。
もう1つのswitchは、HAがSwitchBot Cloud連携から自動生成した「単純なON/OFF操作窓口」で、これもHA上の論理的な存在であり、実存するエアコン1台に対して、詳細操作用のclimateと簡易操作用のswitchという2つの窓口がぶら下がっている構造だった。（補足）なぜ自動生成されるのかの調査は未実施。
そして現在、climateは利用可能、switchはunknownのまま放置されている。使われておらず、認識されていない状態だった。上図の注記にも、「同じ実機に複数エンティティがあっても、実物が複数あるわけではない。エンティティは用途別の窓口です。」と表示されている。unknouwn構成の具体例を調べることによって理解が深まる良い事例である。
一行メモ：entityは「機器」ではなく「窓口」。窓口の棚卸しは、機器の棚卸しとは別にやる価値がある。
物理機器とHAデバイスとエンティティの対応図は、HOME Assistantのユーザーに必須の情報ではないかと思う。
これらの関係が分からないと、HOME Assistantを使いこなせない。
また、今回の調査・構成図作成で、自動生成されるエンティティがあることが分かった。
7. Matter図：Matter対応製品は1つだけだった
Matter関連だけを抽出した構成図も作成した。ただし、所有するMatter対応製品は、Tapo Smart Wi-Fi Plug （スマートプラ図）の1台だけであり、しかも、登録は行ったが現在は使っていなので、9機能（電源操作、識別、起動時動作、電力・電圧・電流・エネルギー、更新）は、すべて応答なしの状態だった。
この構成図から下記のことが分かる。
- 実線：HA、Matter連携、Matter Server、Tapoプラグの登録関係
- 点線：TapoのWi-Fi／Thread種別、Apple TVがThread中継に使われているか
- 別レーン：iPhone／PixelのBluetoothは初期登録時だけの経路
Thread連携もApple TV 4K（第3世代）も存在するが、「現在のTapo経路に使われているとは断定できない」として推測を注記として記載されている。
（補足）上図では「AppleTVがボーダールーター対応か不明」と表示されているが、機種を調べたところ、対応機種だった。
この構成図を作成したことにより、AIへの質問の手がかりを得ることができ、それに対する回答によって、MatterやThreadに対する理解が深まった。図解することが、AIへの有効な質問、新しい知識の習得につながるのではないかと思う。
8. 構成図カタログ：目的別
ここからは、他の構成図を目的別にまとめて紹介する。構成図の案として下表の4案をCodexに提案して意見を聞き、さらに、おすすめの構成図案を回答してもらった。Codexから提案された案は後述する。
| 構成図 | AIの評価 | 採用した表現 |
|---|---|---|
| IPアドレス付き全体図 | 高 | 管理者専用の「ネットワーク運用図」 |
| バッテリー機器図 | 高 | エリア別の「バッテリー保守マップ」 |
| オートメーション構成図 | 非常に高 | きっかけ→条件→実行内容→通知・制御先の簡略表示 |
| ネット情報収集図 | 高 | 「外部情報・クラウド依存図」としてデータフロー化 |
提案した構成図に関する説明
【ネットワーク / IP構成図】
この図はIPアドレス・接続方式・使用経路（ADB、ESPHome APIなど）を含むため、外部共有しない管理者用として運用する。掲載したのは、IPアドレスを非記載とした「ブログ記事公開版」である。
【バッテリー機器 保守マップ】
残量低下通知の設定の有無なども表示され、バッテリー駆動機器の一覧表として有用だが、現在の充電状況や、現時点で保守が必要な機器が表示されているので、保守マップとして、ダッシュボードに表示させるという活用方法も有用である。
【オートメーション構成図】
全26件・稼働24件・停止2件。YAMLを全部記載せず、「きっかけ→条件→実行先」に簡略化して表示したものである。各オートメーションの稼働状態も一覧表示され、停止中の2件のオートメーションの保守を思い出させてくれる図となった。
【外部情報・クラウド依存図】
ネットから得ている情報を一覧できる構成図であり、現在、RSSニュース、天気、太陽光予測、Ring、SwitchBot Cloud、Alexa、Google翻訳などの情報を得ていることが一目で確認できる。情報元→取得方法→HA内の処理→通知先の流れも整理されており、どのオートメーションで利用されているかも表示されているので、仕様変更や保守などに有効な図である。
続いて、Codex側から提案された構成図を紹介する。
【ローカル / クラウド依存・障害影響図】
インターネット停止時・HA停止時・家庭内LAN停止時に何が残るかを分離した図。
スマートロックとエアコンはSwitchBot Cloud依存、つまり家の中の機器なのに、操作にインターネットが必須という依存の偏りが一目で分かる。
【通知ルーティング図】
通知のきっかけ（環境・健康、バッテリー、システム承認、外部ニュース）から、iPhone・Mac mini・Fire TV系・HA通知への経路を一覧化したものである。
【赤外線制御・受信 詳細図】
SwitchBotの赤外線「送信」とESPHomeの赤外線「受信」は別経路として整理されている。
「物理リモコンとHA状態のずれ」の構造もここに描かれている。
※「物理機器とエンティティ対応図」と、「複数制御経路・代替操作図」は紹介済みのため省略する。
9. 知らなかった構造③：セキュリティ境界図が突きつけてきたこと
【セキュリティ・外部公開境界図】
外部クライアント／クラウドサービス境界／家庭内ネットワークの3層で、外部から入る経路・クラウドへ出る情報・保護すべき機器を整理している。
図の下部にまとめられた「管理ポイント」がそのまま要注意ポイントになっている。
- カメラとロックは、クラウド資格情報が漏れた場合の影響がいちばん大きい
（RingもSwitchBotロックもクラウド経由なので当然の帰結だが重要な課題） - MCP Serverは、接続クライアントと公開範囲を別途確認する
- IP付き構成図は管理者専用にする
- 外部情報取得は読み取り中心だが、クラウド機器は双方向制御を含む
特に2番目のポイントは、今回構成図を描いてくれたCodexのようなMCPクライアント自身が、「経路要確認」の点線枠として図中に登場している点であり、AIにHAを読ませるという行為そのものが、セキュリティ境界図に描かれるべき新しい経路になっている。便利さの裏で、MCP Serverの公開範囲と接続クライアントの管理は、これからのスマートホームの必須項目になる。
一行メモ：AI連携を足したら、セキュリティ図にも表示する必要がある。AIも「外部クライアント」の一員である。
10. まとめ
各種構成図を描かせて分かったことを整理する。
- 構成図づくりの主導権は「何を載せないか」の指示にある。MCPの利用により、点線（登録あり・応答なし）と実線の描き分け、推測の注記表示をAIは正確に行えた。
- 図は「HAから見える世界」の地図であり、「Fire TVのカメラ映像」のように、図に載らない現実の経路との食い違いが、忘れていた設定を思い出させてくれる
- 図にして初めて詳細が見えた構造がある。
Marantzの二重登録、unknownのまま放置されたswitch窓口、そしてAI連携自身が登場するセキュリティ境界など。
構成図は「作って終わり」の文書ではなく、家の棚卸しと自問のツールだった。
一行メモ：構成図はAIに描かせる時代。人間の仕事は「何を描かせないか」を決めることと、図と現実のズレを、新しい知識を得るチャンスと捉えること。
色々な条件を指定して、所望の構成図を作成できることが分かった。「このデバイスに関連する構成・経路などを抽出して構成図を作成して」や、「この通信経路を利用している構成を全て図示して」など。