「不在」は観測結果ではなく、解釈かもしれない
在宅判定を使って照明や空調を自動制御していると、「端末が見えない」ことを「人がいない」と読み替えたくなる。しかし、この二つは同じではない。端末を検出する仕組みそのものが壊れていても、判定ロジックから見ると結果は単なる不在に見えるからだ。
今回、家庭内LANの在宅判定で、実際には在宅しているにもかかわらず照明が消える事象が起きた。調査の結果、端末が不在だったのではなく、検出経路が二重に機能しなくなっていた。ここでは、個別環境の情報を伏せたうえで、原因の切り分けとフェイルセーフの考え方を記録する。
原因は「検出器の消失」と「端末識別子の変化」
最初の手掛かりは、在宅判定のログだった。一定期間を境に、端末が見つからないという記録が続いている。しかし、判定結果は一貫して method=none、confidence=low だった。これは「LAN上に端末がいない」という積極的な証拠ではなく、「どの検出方法も答えを返していない」という観測に近い。
さらに調べると、mDNSを扱うための常駐プログラムとユーティリティが、環境移行後のホストに導入されていなかった。移行前には存在していた検出経路が、新環境では静かに欠落していたのである。ARPとpingだけに頼る構成では、スマートフォンがWi‑Fiスリープに入ったとき、端末が存在していても見えなくなる。
それだけではなかった。mDNSによる名前解決を復旧すると端末は応答したが、ARPから得たMACアドレスは、設定に保存されていた古い値と一致しなかった。iOSのプライベートWi‑FiアドレスによるMACローテーションが、もう一つの検出経路を無効にしていた。
つまり今回の「不在」は、次の二段構えで作られていた。
- 環境移行時にmDNSの検出基盤が欠落し、名前解決ができなくなった
- 端末側のプライベートWi‑Fiアドレス変更により、MAC照合も古い情報のまま失敗した
実機で確認して分かったmDNSの癖
検出経路を復元するため、外部デーモンに依存しないmDNS問い合わせを小さな実装で検証した。ここで、実機に対する問い合わせ方法によって応答が変わることが分かった。
この端末では、mDNS標準ポートから通常の問い合わせを送った場合には応答しなかった一方、エフェメラルポートからQU（ユニキャスト応答要求）を付けて問い合わせると応答した。これは「mDNSならどのように送っても同じ」と考えてはいけない例である。仕様だけでなく、実際の端末とネットワークでA/Bテストを行う必要がある。
最終的には、一つのソケットにすべてを担わせるのではなく、役割を分けた。
- エフェメラルポート＋QUの問い合わせで、端末名の解決結果を得る
- mDNSマルチキャストグループに参加したソケットで、ネットワークセグメントが生きているかを観測する
前者は端末の存在確認、後者は検出装置が応答を受け取れる状態かの確認である。検出対象と検出器の健全性を同じ結果に押し込めないことが、今回の重要な設計ポイントになった。
「見えない」ときは、不在カウントを進めない
判定ロジックにもフェイルセーフを追加した。confidence=low の非検出は、不在の連続回数に加算しない。照明を消す、空調を止めるといった破壊的な自動操作には、ネットワークが生きていて、対象の名前に応答がないという積極的な不在証拠を要求する。
これは「端末が見つからないなら、ずっと在宅扱いにする」という意味ではない。検出器の状態が不明な間は安全側に倒し、セグメントが生きていることを確認できた後にだけ、不在の確度を上げる。真正な不在が続けば、従来の連続回数や時間のルールで通常どおり制御できる。
自動化では、ONにする処理よりOFFにする処理のほうが慎重であるべきだと思う。誤って照明を点けることより、在宅中に照明を消したり、必要な空調を止めたりするほうが、利用者にとって「自動化が壊れた」と感じやすい。不可逆性の高い操作ほど、観測の確度を要求する設計が自然だ。
移行時と運用時のチェックリスト
今回のような事故を防ぐため、ネットワーク検出を含む自動化を移行するときは、サービスが起動するかだけでなく、次の点まで確認したい。
- 旧環境にあった検出デーモン、名前解決設定、パッケージを棚卸しする
- 端末識別にMACアドレスだけを使わず、名前解決や複数の観測手段を組み合わせる
- 「検出結果」と「検出器の健全性」を別の状態として記録する
- low confidenceを不在の連続カウントに入れない
- 実機をスリープさせた状態、MACが変わった状態、検出器を止めた状態をそれぞれテストする
- 自動操作が実際に抑制されたことまで、実cronまたは実運用で確認する
観測できないことを、観測結果にしない
今回の修正では、実機に対するmDNS応答、シナリオテスト、そして実際の定期実行での照明維持まで確認できた。復旧の決め手は、検出方法を増やしたことだけではない。「答えがない」ことを、そのまま「不在」と解釈しないようにしたことだった。
自動化は、センサーが正しいときには簡単に見える。難しいのは、センサーが沈黙したときだ。沈黙を不在と呼ぶのか、観測不能と呼ぶのか。その境界を設計しておかないと、便利な仕組みが生活を乱す仕組みに変わる。