Home AssistantとObsidianで「機器台帳」を作る――Codexで障害記録やメンテナンス履歴まで残す仕組み

2026年9月12日

Home Assistantに登録する機器が増えてくると、少しずつ困ることが増えてきます。

「この機器は何のために置いたのか」
「前に同じ不具合が起きたとき、どう直したのか」
「電池を交換したのはいつだったか」

Home Assistantは、機器の現在の状態や履歴を確認するにはとても便利です。しかし、機器を導入した理由や、設定したときの判断、交換した部品、障害から復旧するまでに何をしたか、といった“人の経験”まで、あとから読み返しやすい形で残してくれるわけではありません。

そこで今回は、Home Assistantの機器情報とObsidianのノートを組み合わせて、「機器台帳」を作りました。

さらに、台帳を自分で毎回Markdown編集するのではなく、Codexへ普段の言葉で伝えるだけで、不具合や電池交換などを所定の欄へ記録できる運用にしています。

実際に、macOS 27へアップデートしたあと、Stream Deck+の表示とHome Assistant操作が正常に動かなくなった際にも、症状、原因の切り分け、修復内容、復旧確認までを機器台帳へ残すことができました。

この記事では、なぜHome AssistantだけではなくObsidianも使うのか、どのような機器を台帳化したのか、Codexをどう組み合わせたのか、そして実際の障害記録やメンテナンス履歴まで、順を追って紹介します。

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

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

Home AssistantとObsidianを組み合わせると何が役立つのか

今回の仕組みで大切なのは、単に「記録を増やすこと」ではありません。

あとから原因を追えること、同じトラブルが起きたときに過去の対処を再利用できること、そして機器交換やHome Assistantの更新時に判断材料として使えることに意味があります。

Home Assistantの履歴やログにも異常は残りますが、そこから「なぜその判断をしたのか」「何を試して、何が効いたのか」「同じ現象が何回目なのか」までを読み取るのは簡単ではありません。

Obsidianに人間向けの記録として残しておけば、Home Assistantのデータだけでは残りにくい“経験”をあとから使える形にできます。

障害記録は「何が起きたか」だけでなく「どう直したか」を残す

例えば、ESPHome機器が一時的にofflineになったとします。

Home Assistant側の履歴を見れば、offlineになった時間は確認できます。しかし、再起動で直ったのか、Wi-Fi環境を変更したのか、過去にも同じ症状があったのか、といった情報は別に残しておかないと分かりません。

Obsidianに次のような記録があれば、状況はかなり変わります。

2026-09-10
ESP32赤外線受信機 offline
↓
Wi-Fi RSSI -82 dBm
↓
再起動で復旧
↓
3週間で4回目

4回目になった時点で、「これは再起動で済ませ続けるより、Wi-Fi環境を見直した方がよいのではないか」と判断できます。

障害記録は、単発のトラブルを保存するためだけではありません。発生回数、時間帯、Home Assistant更新との前後関係、過去に有効だった対処などを見比べることで、再発防止に使える記録になります。

次のような使い方は、特に相性がよいと思います。

活用方法	具体例	利点
再発障害の確認	ESPHome機器が短期間に何度も`unavailable`になる	単発か慢性的な問題か判断しやすい
過去の対処を再利用	「再起動で復旧」「Wi-Fiチャンネル変更で改善」	同じ障害で一から調べ直さずに済む
更新との関連確認	Home Assistant更新の翌日から連携不調	バージョンアップとの関係を疑いやすい
発生傾向の分析	毎晩2時前後にだけ切断	時刻、ネットワーク、自動化との関係を探せる
AIによる分析	Codexに過去の障害記録を読ませる	共通原因や改善案を整理しやすい
ブログ記事の材料	発生→調査→原因→解決を記録	実機検証の記事にしやすい

機器台帳は「機器一覧」ではなく、その機器の背景まで残す

今回作った機器台帳は、Home Assistantに登録されている機器をそのまま一覧にしただけではありません。

「この機器は何のために設置したのか」「どこに置いているのか」「どの設定ファイルと関係するのか」「過去にどんな問題があったのか」までを、1台ごとのノートにまとめています。

例えば、ESP32の赤外線受信機なら、次のような内容を持たせます。

機器名：ESP32 赤外線受信機
設置場所：リビング
用途：テレビ・エアコンの赤外線コード解析
Home Assistant：sensor.ir_receiver
ESPHome：ir-listener.yaml
導入日：2026-06-14

関連ノート：
・赤外線解析方法
・ESPHome設定変更履歴
・過去の障害

このような情報は、作った直後なら覚えています。しかし、1年後、2年後になると、「このESP32は何のために置いたのか」「なぜこのAutomationだけMQTTなのか」「このSwitchBot Hubは何を担当していたのか」といったことが曖昧になってきます。

機器台帳は、そうした“未来の自分が忘れる情報”を残すための資料でもあります。

活用場面	機器台帳がある利点
機器交換	旧機器の設定や用途を確認しながら移行できる
障害調査	IP、entity、ESPHome設定などをすぐ確認できる
Home Assistant再構築	何をどう接続していたかを復元しやすい
ネットワーク変更	固定IPや接続方式を確認しやすい
不要機器の整理	現在も必要な機器か判断しやすい
AIへの相談	CodexやClaude Codeへ機器構成を説明しやすい
ブログ執筆	導入時期、構成、変更履歴を参照しやすい

障害記録と機器台帳は、組み合わせると価値が上がる

機器台帳と障害記録は、別々に管理するよりも、機器ごとに結び付けた方が使いやすくなります。

例えば、ESP32赤外線受信機のノートの中に、その機器の障害履歴へのリンクを置いておきます。

ESP32 赤外線受信機
├─ 設定
├─ 導入理由
├─ ESPHome YAML
└─ 障害履歴
   ├─ 2026-07-12 offline
   ├─ 2026-08-03 offline
   └─ 2026-09-10 offline

Obsidianでは、障害履歴を別ノートとして保存し、機器ノートからリンクできます。

## 障害履歴
- [[2026-07-12 ESP32 IR offline]]
- [[2026-08-03 ESP32 IR offline]]
- [[2026-09-10 ESP32 IR offline]]

こうしておけば、機器ノートを開くだけで、その機器がどのような障害を起こしてきたかを追えます。

CodexやClaude Codeを加えると、蓄積した記録を使いやすくなる

機器台帳と障害記録が増えてくると、AIを使う意味が出てきます。

例えば、半年分のESPHome機器の障害記録がたまっていれば、CodexやClaude Codeへ次のように依頼できます。

「ESPHome機器の過去6か月の障害を調べて、故障しやすい機器と原因候補をまとめて」

すると、障害回数、共通するRSSIの傾向、発生時間帯、更新直後に集中しているか、といった情報を横断的に整理しやすくなります。

例えば記録が十分に蓄積していれば、

ESP32 赤外線受信機
障害：7回

共通点：
6回でRSSIが-75dBm以下

推定：
Wi-Fi品質が主因の可能性が高い

推奨：
・AP位置確認
・ESP32設置位置変更
・RSSI監視Automation追加

といった分析につなげられます。

ただし、ここで大切なのは、AIが出した推定をそのまま事実として扱わないことです。
今回の台帳でも、確認できないIPアドレスや導入日、エンティティIDなどは推測で埋めず、「未確認」として扱う方針にしています。

私の中では、3つの役割を次のように分けています。

Home Assistantは「現在のデータ」を持つ
Obsidianは「人の経験」を残す
CodexやClaude Codeは「経験を記録・整理・分析する」

最初からすべての機器を台帳化する必要はありません。

私は、ESPHome、SwitchBot、Ringなど、自分で設定変更したり、障害対応や交換が発生しやすかったりする機器から始めるのが実用的だと考えています。単純な温度センサーまで無差別に記録すると、台帳を維持すること自体が負担になるからです。

RSSI（Received Signal Strength Indicator）は、Wi-FiやBluetoothなどの「受信電波の強さ」を示す数値です。
通常は dBm で表示され、数値はマイナスになります。0に近いほど電波が強いという見方をします。

-30 dBm前後：非常に強い
-50〜-60 dBm：良好
-70 dBm前後：やや弱い
-80 dBm以下：通信が不安定になりやすい
-90 dBm前後：接続が切れる可能性が高い

たとえば -55 dBm は、-75 dBm より強い電波です。
Home Assistantの機器台帳では、RSSIを記録しておくと、機器が「利用不可」になった原因が、故障・電池切れなのか、電波不足なのかを切り分けやすくなります。ただし、機器や通信方式によって目安は多少異なります。

実際にObsidianへ「機器台帳」を作った

2026年9月10日、Obsidian Vault内に機器台帳を作成しました。

台帳の入口は次のMarkdownファイルです。

HomeAssistant/機器台帳/機器台帳.md

確認時点では、Devicesフォルダに17件の機器ノートがあります。

対象はすべての機器ではなく、設定変更、障害対応、交換時の確認が必要になりやすいESPHome、SwitchBot、Ring、Claude Monitorなどを中心にしました。

また、Home Assistant操作に使っているStream Deck +は、Home Assistantが自動取得した機器とは別に、「Home Assistant関連機器」として登録しました。

一覧はDataviewで確認でき、機器名、分類、統合、エリア、メーカー、モデル、状態、Home Assistant確認日などを見られるようにしています。

一方で、秘密情報は記録しません。確認できないIPアドレス、導入日、エンティティIDなども、AIに推測させず空欄または未確認として扱います。

各機器ノートは、基本的に次の構成です。

基本情報
Home Assistantから取得した現在情報
保守メモ
メンテナンス履歴
障害記録
関連ノート、詳細な障害記録へのリンク

機器台帳は、ユーザーが毎回Markdownを編集するためのものではない

今回の運用で重視したのは、「記録するたびにObsidianを開いて、決められた場所へユーザーが自分で追記する」方式にしなかったことです。

基本的には、私がCodexへ普段の言葉で出来事を伝えます。

例えば電池交換なら、次のように依頼します。

「SwitchBot温湿度計の単4電池2本を今日交換しました。交換前は残量10%で、交換後に表示とHome Assistant連携が正常なことを確認しました。メンテナンス履歴へ記録してください。」

不具合なら、次のように伝えます。

「Stream Deck +でキー表示が崩れ、Home Assistant操作ができません。直前にmacOSを更新しました。原因を調べ、修正内容と確認結果を障害記録へ残してください。」

Codexは対象機器を探し、内容がメンテナンスなのか障害なのかを判断し、所定の欄へ追記します。

ユーザー側で最後に確認するのは、対象機器、日付、作業内容、実機での確認結果です。

最低限必要なのは、「機器名」「日付」「出来事または作業」の3つです。型番、電池残量、使用部品などが分かる場合は追加します。分からないことは推測で埋めず、「未確認」とします。

トラブル事例1：macOS 27更新後のStream Deck不具合を、実際に記録した

機器台帳を作った直後、実際に役立つ事例が発生しました。トラブル事例1として紹介します。

2026年9月10日、Mac miniをmacOS 27.0へ更新したあと、Stream Deck +のHome Assistant関連キーで動的表示が更新されず、操作も正常に実行されない状態になりました。

当時の環境は次のとおりです。

項目	内容
発生日	2026年9月10日
Mac	Mac mini（Apple M1）
OS	macOS 27.0（ビルド26A428）
対象	Stream Deck +
Stream Deckアプリ	7.5.1（22901）
ファームウェア	2.0.3.7

ただし、Stream Deck全体が使えなくなったわけではありませんでした。

一部の天気、CPU、RAM表示は残っており、Stream Deck本体2台（Stream DeckとStream Deck+）もログ上では接続済みでした。プロファイル9ページとキー割り当ても残っていました。

一方で、Home Assistant、MQTT、OBS、IFTTT、Webhooksなど20プラグインは、接続タイムアウト後に無効化されていました。

この情報から、少なくともUSB接続そのものやプロファイル消失が主な障害ではなく、OS更新後のStream Deckプラグイン実行環境の初期化・接続部分に問題が起きていたことまでは切り分けられました。

修復では、事前にバックアップを取ったうえで、Apple公証済みのElgato公式Stream Deck 7.5.1を上書き再インストールしました。

その後、2台のUSB接続、51プラグイン、Home Assistant、Weather、CPU、RAM、MQTT、OBS、動的表示、アプリ再起動後の再接続を確認し、既存プロファイルとアクションも保持されていることを確認しました。

ここで注意したいのは、「macOS 27がStream Deckを壊した」とまでは断定できないことです。

今回確認できたのは、OS更新後に症状が発生し、障害箇所がプラグイン実行環境の初期化・接続部分にあり、上書き再インストールで復旧したところまでです。macOS内部のどの変更が直接影響したのかまでは確定していません。

このように、機器台帳へ残すのは「壊れた」という結果だけではありません。

どこまで正常だったのか、何を切り分けたのか、修復前に何をバックアップしたのか、そしてどの状態まで戻れば「復旧」と判断したのかまで残します。

それが次回、同じ機器や同じOS更新で問題が起きたときの確認手順になります。

トラブル事例2：macOS 27更新後のStream Deck不具合を、実際に記録した

トラブル事例2を紹介します。

下図のように、HOME Assistantのダッシュボード「Claude Monitor」で、Codexの制限表示が正常に表示されなくなりました。Codexのデスクトップアプリで確認すると、5時間枠と7日枠の数値が確認できるのに、下図のダッシュボードではその数値が表示されていませんでした。

ChatGPTに原因解明・修復を依頼したところ、下記の回答がありました。

原因と修復内容

修復が完了しました。

原因は、利用制限を持たない新しい活動イベントによって、過去の有効な token_count が除外され、5時間・7日枠だけ空になる時刻判定の不具合でした。

対応内容：

[usage_summary.py (line 280)](/Users/〇〇/claude-monitor/aggregator/usage_summary.py:280) の判定を修正
利用制限とトークン情報を専用の時刻で管理
制限情報のないイベントでも、直近の有効値を消さないよう改善
2種類の再現・回帰テストに合格
集約サーバーを再起動し、online を確認
本番バックアップを保存

実画面では現在、正常に表示されています。

5時間枠：15.0%／リセット 09/12 01:43
7日枠：68.0%／リセット 09/15 13:38
バー表示も復旧

バックアップ：[usage_summary.py.bak-20260911-2050-rate-limit-event-order](/Users/〇〇/claude-monitor/aggregator/usage_summary.py.bak-20260911-2050-rate-limit-event-order)

「機器台帳」のどのファイルを修正したか

保管庫内で追記したのは、次の1ファイルだけです。

保管庫：/Volumes/TEKQPHYE748/obsidian/ssd_vault
フォルダ：HomeAssistant/機器台帳/Devices
ファイル：[Claude Monitor.md (line 96)](/Volumes/TEKQPHYE748/obsidian/ssd_vault/HomeAssistant/機器台帳/Devices/Claude Monitor.md:96)
追記位置：## 障害記録 セクションの先頭
見出し：### 2026-09-11 Codex利用制限が表示されない（復旧済み）

追記した内容は以下です。

症状
コンテキスト使用量は表示されるのに、5時間枠・7日枠の使用率、バー、リセット時刻がすべて - になる。
原因
usage_summary.py が全イベント共通の最終活動時刻を使っていたため、新しいセッションに利用制限付きの token_count がないと、別ファイルに残っている有効な制限値を古いものとして除外していた。
対応
トークン情報と利用制限にそれぞれ専用の最新時刻を設け、ファイルの更新順に左右されず、直近の有効な制限値を保持するよう修正。集約サーバーも再起動した。
修正ファイル
/Users/〇〇/claude-monitor/aggregator/usage_summary.py
復旧確認
再現テストと回帰テストに合格。MQTTの claude/jobs に制限値が配信され、実画面で5時間枠・7日枠・バー・リセット時刻と、集約サーバーの online を確認した。
再発防止
利用制限を持たない活動イベントや token_count が発生しても、直近の有効値を消さないテストを保持する。
バックアップ
/Users/〇〇/claude-monitor/aggregator/usage_summary.py.bak-20260911-2050-rate-limit-event-order

修復後は、外部SSD上のObsidian保管庫にある「HomeAssistant／機器台帳／Devices／Claude Monitor.md」の障害記録へ、発生日、症状、原因、修正内容、修正ファイル、復旧確認、再発防止策、バックアップ先を追記した。
これにより、ダッシュボードの復旧だけでなく、同じ症状が再発した際に原因と対処方法を機器単位で確認できるようにした。

メンテ事例：「メンテナンス履歴」を追加し、電池交換も残せるようにした

障害だけでなく、日常の保守作業も残せるように、各機器ノートへ「メンテナンス履歴」の欄を追加しました。

対象は、電池交換、清掃、部品やケーブル交換、再設定、ファームウェアやアプリの更新、設置場所変更、定期点検などです。

記録するのは、実施日、作業の種類、作業内容、使用した部品や消耗品、作業前の状態、作業後の確認、備考です。

ここでは、「障害記録」と「メンテナンス履歴」を分けています。

動かなかった事実や原因は障害記録へ、実際に交換・清掃・更新した作業はメンテナンス履歴へ残します。

例えば電池切れで機器が停止した場合は、

障害記録には「電池切れで停止したこと」
メンテナンス履歴には「いつ、どの電池へ交換し、交換後に正常動作を確認したか」

というように、役割を分けて両方に残せます。

履歴が何回分か蓄積すれば、前回交換日からの使用日数や、機器ごとの平均・最短・最長の交換間隔を比較できます。

さらに、電池メーカー、使用頻度、季節、通信状態などとの関係を見たり、次回交換時期や予備電池の購入時期を考えたりする材料にもなります。

ただし、交換記録が1回しかない段階では、電池寿命の傾向までは判断できません。予測に使うには複数回の実績が必要であり、将来の交換時期はあくまで目安として扱う必要があります。

機器追加・不具合・メンテナンスで、記録先に迷わない運用にした

仕組みを作っても、「これはどこへ書けばよいのか」で迷うと続きません。

そこで、出来事ごとに基本の記録先を決めました。

出来事	主な記録先	基本動作
新しいHome Assistant機器	機器ノート	dry-runで差分を確認してから登録
Home Assistant外の関連機器	機器ノート	重複を確認して手動登録
動かない・表示異常	障害記録	症状と証拠を先に残し、原因は確認後に確定
電池交換・清掃	メンテナンス履歴	実施日、部品、作業前後を記録
機器交換・退役	旧機器と新機器の各ノート	旧履歴は消さず、新機器を別ノートで相互リンク

新しい機器を追加するときは、いきなり本更新せず、先にdry-runで差分を確認します。

また、Home Assistantで一時的にunavailableになっただけで障害と断定しないようにしています。
短時間の通信切れや再起動の途中でも一時的にそう見えることがあるためです。

機器交換時も、旧ノートは削除しません。状態を「交換済み」「退役」などに変更し、新しい機器のノートからリンクします。

もう一つ重要なのが、自動更新する領域と、人が残す領域を分けることです。

Home Assistantから取得した現在情報は更新されても、導入理由、保守メモ、障害記録、メンテナンス履歴などの人の記録は消えない構造にします。

ユーザー用の図解マニュアルもPDFにした

ChatGPTに「機器台帳」のマニュアル作成を依頼したところ、PDF形式のマニュアルを作成してくれるものと思っていたのですが、予想に反して、Obsidian内に文章のマニュアルが作成されました。これはこれでいいのですが、手許に紙のマニュアルが欲しかったので、PDF形式のマニュアルを依頼しまたが、相変わらず、PDF形式での図作成は苦手なようでした。

今度はimagesのツールを使って作成してと依頼したところ、背景画像にトークンを浪費するだけで、所望のマニュアルは作成されませんでした。

そこで今度は、Gemini Notebookに資料を渡してスライドで作成してもらったところ、下図のスライド形式のマニュアル（抜粋）が作成されたので、このファイルをCodexに見せて、このような資料を作成するのは、どのような指示を出せば良いかを確認したところ、「インフォグラフィックとして作成」というキーワードが出てきた。

ただし、インフォグラフィックというキーワードを使用する方法の他に、一旦、文章のマニュアルを作成して、「この文章に入れる説明図を作成して」と依頼する方法も有効だと思われる。本記事の説明図もそうして作成している。
これまでの経験から、「PDFで」と指定すると、文字が枠に収まらないような描画手段が選択され、「スライド」というキーワードを入れると、パワーポイント用の画像（背景が実写画像になるなど）が作成されてしまうことがある。Astraなら、見た目を実際に確認してインフォグラフィックにような画像を作成してくれるのかもしれない。

使って分かったこと――機器台帳は「家の記憶」になる

今回作った機器台帳の価値は、Home Assistantの機器一覧をObsidianへコピーしたことではありません。

本当に役立ったのは、macOS更新後のStream Deck不具合で、何が起きたのか、どこまで正常だったのか、何を直したのか、そしてどう復旧を確認したのかを、一つの機器に結び付けて残せたことです。

Home Assistantのログだけでは、時系列のデータは残っても、そのとき自分が何を考えて、どんな作業をして、どの時点で「直った」と判断したかまでは残りません。

そこをObsidianで補い、Codexに記録作業を手伝わせることで、台帳は単なる一覧表ではなくなります。

また、電池交換や清掃、ファームウェア更新の履歴が増えてくれば、交換周期や故障傾向を考える材料にもなります。

最初から家中のすべての機器を登録する必要はありません。

まずは、障害対応、設定変更、交換が発生しやすい機器から始め、必要に応じて増やしていく方が続けやすいと思います。

Home Assistantが「今の状態」を持ち、Obsidianが「なぜそうしたのか」を残し、CodexやClaude Codeが「記録と分析」を手伝う。

この3つを組み合わせることで、機器台帳は少しずつ「家の記憶」に近づいていきます。

このような機器台帳を作成しておくことによって、HOME AssistantやMacOSのバージョンアップが合った際、私のHOME Assistantに与える（与えた）影響を調べてとか、これまでできなかった質問をAIに行うことができる。
また、長期的なデータが蓄積されると、長期的な傾向に関する質問も行うことができる。

機器台帳を作成しても、トラブルはそう頻繁に起こるものではなく、あまり有効なデータはなかなか蓄積されないのではないかと考えていたが、本記事執筆前後でも、MacOSバージョンアップに起因するStream Deck表示不具合とか、HOME Assistantのダッシュボード「Claude Monitor」の不具合など、結構、トラブル情報は集まりそうである。HOME Assistantのバージョンアップも月1回行われるので、その都度、CodexにHOME Assistantの健康診断をさせるというのも有効かもしれない。