留守中の水槽見守り — 旅行・出張前にやること、遠隔で気づく仕組みの作り方

「何日空けるか」でリスクの中身が変わる

留守中の水槽対策で最初に決めるべきは、機材でもアプリでもなく「何日空けるか」です。不在が1泊なのか1週間なのかで、警戒すべきトラブルの種類がまるごと入れ替わるからです。短い不在で怖いのは突発的な停止（停電・ヒーター故障・漏水）で、長い不在で効いてくるのは、1日単位ではほとんど動かないのに日数をかけて積み上がる変化——蒸発による濃縮、生物ろ過への負荷、給餌の問題です。

短期は突発、長期はドリフト

なぜこう分かれるのかは、変化の速さの違いで説明がつきます。ヒーターや冷却が止まったときの水温変化は、室温との差・水量・断熱の条件で大きく変わりますが、ニュートンの冷却則（温度差に比例して熱が逃げる）に基づくモデル計算では「1時間あたりおよそ0.5〜2°C」というオーダーになります（実測ではなくモデル上の目安で、条件しだいでこの幅からも外れます）。1泊の不在でも危険域に届きうる速さです。一方、蒸発による水位低下は「1日あたり水量の数％」といったオーダーで、1日ではほぼ気になりません。ところが7日・14日と重ねると、水位低下とそれに伴うTDSの上昇は無視できない大きさになります。つまり短期は「速い変化」、長期は「遅い変化の累積」が主役です。

水量が多いほど変化は遅い — ただし水量には比例しない

同じ故障でも、水量が多いほど水温の変化はゆっくり進みます。水は比熱が大きく、蓄えた熱をなかなか手放さないためです。ただし「水量が2倍なら変化の速さは半分」にはなりません。逃げていく熱の量は水槽の表面積に比例するので、室温へ近づく速さを決めているのは水量そのものではなく『表面積 ÷ 水量』の比だからです。水槽を大きくすると水量と一緒に表面積も増えるため、差は水量の比ほどには開きません（60cm規格と30cmキューブを寸法から比べると、この比の差は1.3倍前後というオーダーです）。それでも向きは変わりません——小型・過密・単独ヒーターという条件が重なるほど、気づくまでの許容時間は短くなります。フタや断熱材、部屋そのものの保温が効くのは、この比を実質的に小さくして時間を稼げるからです。

読むべきは線の「曲がり方」です。どの条件でも最初の数日はほぼ横ばいに見えますが、日数が延びるほど傾きが増していきます。残った塩類が減った水に溶けている以上、水が減るほど濃縮は加速するからです。夏に冷却ファンを回していると蒸発は一段と速くなるので、長期不在では「水温が上がらないこと」だけでなく「水が減っていくこと」も同時に進むと考えておくのが安全です。ビーシュリンプのようにTDSの変化に敏感な生体では、この静かな上昇のほうが本命のリスクになりえます。

出発前チェックリスト — 日数で足していく

チェックリストは「全部やる」ではなく「日数に応じて積み増す」と考えると回ります。共通の土台（電源・機器・水位）はどんな不在でも必ず確認し、そこへ日数分の項目を足していく構造です。共通して外せない原則がひとつだけあります——出発直前に環境を大きく動かさないこと。直前の大量換水・フィルター掃除・レイアウト変更は、留守中に効いてくる水質変動を自分で仕込む行為になります。

3日以上で足すこと

1週間以上で足すこと

見守り方式の比較 — 何がわかって、何がわからないか

遠隔で見守る手段は、製品名で選ぶより「方式」で選ぶほうが失敗しません。見るべき軸は4つです——何を測っているか（水中か室内か、見た目か）／通知はしきい値か変化率か／クラウドへの依存はどこにあるか／停電と復電でどう振る舞うか。以下は各社が公開している仕様から、方式ごとの傾向を整理したものです。

通知の出方で分ける — プル型とプッシュ型

留守中に効くかどうかは、結局「向こうから知らせてくるか」で決まります。カメラやアプリの画面を自分で見に行く方式（プル型）は、見に行った瞬間の状況しか分かりません。旅行先で1日3回、均等な間隔でアプリを開けたとしても、異変に気づくまでは平均で数時間遅れる計算になります（実際は開く間隔が偏るぶん、もっと遅れます）。対してプッシュ型は、異常の条件が成立したときだけ向こうから届くので、開いていない時間もカバーできます。留守中対策の中心はプッシュ型に置き、カメラなどのプル型は「通知が来たあとで状況を確かめる」補助に回すのが現実的な組み合わせです。

通知の届き先も同じくらい重要です。日本では、普段から何度も開くアプリ（LINEが代表格）に届くほうが、めったに開かない専用アプリのプッシュより発見が早くなりがちです。メールしか経路がない製品は、旅行中の受信箱に埋もれる前提で考えたほうがいいでしょう。経路を2つ持つ（LINE＋メール等）と、片方が届かない状況でももう片方が残ります。

なぜ2.4GHz帯なのか — 留守前に潰しておく接続の落とし穴

Wi-Fi水温計やスマートプラグを買って「5GHzのSSIDに繋がらない」と戸惑った経験がある方は多いはずです。これは不具合ではなく仕様で、各社の公開仕様を見るかぎり、家庭向けIoT機器の多くは2.4GHz帯のみに対応しています。理由を知っておくと、出発直前に慌てずに済みます。

2.4GHz帯が選ばれる理由

• 搭載SoCの仕様 — 家庭向けIoT機器で広く採用されている無線SoC（ESP32系など）は2.4GHz帯専用で、そもそも5GHz帯の回路を持たない
• コストと消費電力 — 2バンド対応にするとチップとアンテナが高くなり、消費電力も増える。数千円の機器では割に合わない
• 電波の届きやすさ — 波長が長い2.4GHz帯のほうが、壁や水槽台といった障害物を回り込みやすく、家の隅でも届きやすい
• 必要な帯域が小さい — 温度の数値を数分おきに送るだけなら、5GHz帯の速度は要らない

2.4 GHz Wi-Fi (802.11b/g/n)

裏返せば、2.4GHz帯は電子レンジ・Bluetooth機器・近隣の無線LANと共有する混雑帯でもあります。「届きやすいが混みやすい」というトレードオフの上に、家庭用IoT機器の接続は成り立っています。測る側から言うと、この帯域選択は「安定して届くこと」を優先した結果であり、速度を捨てた代わりに到達性を取った設計です。

出発前に潰しておく「つながらない」の典型

• 2.4GHzと5GHzで同じSSID名を使っている — スマホが5GHzに繋がっていると、セットアップ時に機器へ渡すSSIDが噛み合わないことがある
• バンドステアリングが有効 — ルータが自動で5GHz側へ寄せる機能。セットアップ中だけ一時的に切ると通りやすい
• ゲストネットワークに繋いでしまった — 端末間の通信が遮断され、スマホから機器を見つけられない
• ステルスSSID（SSID非通知） — 機器側の検索に出てこない。セットアップ中だけ通知に戻す
• パスワードに機器が扱えない文字が含まれている — 記号や長さの制限は機器ごとに違う
• ルータのDHCPアドレス数が上限に達している — 使っていない古い端末のリースを整理する
• 電子レンジ・コードレス電話の近くに置いている — 2.4GHz帯の干渉源。設置場所を数十cm動かすだけで安定することがある

最大の失敗モード — 通知経路そのものが落ちる

留守中の見守りで最も見落とされているのは、センサーの精度でも通知のしきい値でもありません。「通知を運ぶ経路そのものが、トラブルと一緒に落ちる」ことです。停電は水槽の機材を止めると同時に、ルータもハブも止めます。つまり、いちばん通知が必要な瞬間に、通知を送る手段が失われる——これが留守中対策の構造的な弱点です。

沈黙は「異常なし」と見分けがつかない

プッシュ通知は、センサー → 家のネットワーク → 回線 → クラウド → スマホ、という直列のチェーンで届きます。直列である以上、どこか1か所が切れれば通知はゼロになります。そして受け取る側から見ると、「異常が無いから通知が来ない」と「経路が切れているから通知が来ない」は、まったく同じ見え方をします。旅行中にスマホが静かなことを安心材料にしてしまうのは、この見分けがつかないからです。

沈黙に気づく仕組み — 無応答検知

対処法はシンプルで、判定をクラウド側に置くことです。センサーが定期的に「生きています」という信号（ハートビート）を送り、クラウド側は一定時間その信号が途絶えたら通知を出す。この仕組みがあると、機器が沈黙したこと自体が通知になります。原因が停電なのかWi-Fi断なのか機器故障なのかまでは断定できませんが、「今、見えていない」ことには最短で気づけます。監視設計の観点で言えば、留守中の実力を分けるのはしきい値の細かさではなく、この「沈黙を検知できるか」の一点だと考えています。

冗長化の現実解

• ルータ・ハブとセンサー機器をUPS（無停電電源装置）や大容量モバイルバッテリーに載せる — ヒーターやポンプまで賄うのは非現実的でも、消費電力の小さい通知経路とセンサーだけなら比較的小さな投資で延命でき、停電中も水温の推移を見続けられる（ルータだけを載せても、センサーが止まればデータは送られない）
• 通知先を2経路にする（例: LINE＋メール、自分＋家族の端末） — 片方が届かない状況を吸収できる
• モバイル回線を1つ持つ — 固定回線の障害に効く。停電にも効かせたいなら、バッテリー内蔵のモバイルルータのように電源が落ちても動く構成にする
• 近所の人・家族に物理的な確認を頼む — 経路が全部落ちたときの最後の手段は、結局これになる
• 「無音だったこと」を確認材料にしない — 出先から一度アプリを開き、最新データの時刻を見る習慣をつける

留守中に見るべき指標 — 絶対値ではなく変化の速さ

最後に、留守中に何を見張るかです。結論から言うと、留守中に効くのは「今何度か」という絶対値より「どれだけ速く動いているか」という変化の速さ（Δ）です。理由は2つあります。ひとつは、しきい値に届く頃には既に事態が進んでいること。もうひとつは、センサーの絶対値には個体差とドリフトがあり、校正しない限りズレが残るからです。同じセンサーが出した値どうしの差分（＝Δ）なら、その固定的なズレは打ち消し合います。

水温Δ — 機器停止のいちばん速いサイン

平常時の水槽の水温は、日内変動があってもほぼ横ばいです。そこへ「1時間で+1°C」「1時間で-1°C」といった普段にない傾きが出たら、ヒーターの故障・冷却の停止・停電など、熱の出入りが変わった可能性が高いと考えられます。絶対値の上限・下限は最後の防衛線として残しつつ、立ち上がりはΔで捉える——この二段構えが、留守中には特に効きます。

EC(TDS)のじわじわ — 長期不在で効く

EC（電気伝導度）は、水に溶けているイオンの量を電気の通しやすさとして測る指標で、換算するとTDSになります。留守中にこれが上がっていく典型が、この記事の前半で図にした蒸発による濃縮です。水だけが出ていき、溶けていたものは残るので、水位が下がるほどECは上がります。1日では動いたように見えなくても、7日・14日と積み上がると意味のある差になります。測る側の注意点として、ECは水温で変わる（一般に水温が上がるとECも上がる）ため、温度補償された値どうしで比べる必要があります。

無応答 — 「見えていない」ことに気づく

3つ目は、値ではなく「値が来ないこと」です。前のセクションで見たとおり、留守中の最悪のケースは通知経路ごと沈黙することなので、沈黙そのものを検知対象にしておく必要があります。水温Δ・EC・漏水という「起きたことを知らせる指標」と、無応答という「見えなくなったことを知らせる指標」。この2種類を揃えて初めて、留守中の見守りは穴のない形になります。

• 水槽の遠隔監視デバイス — 方式別の選び方 — 見守り機器を方式で選ぶための、もう一段詳しい整理
• Wi-Fi水温計の比較 — 公開仕様で見る選び方 — しきい値通知・対応帯・アプリの違いを仕様ベースで
• スマートプラグで水槽を見守る — できること・できないこと — 通電の可視化でどこまで分かるか。水中の値との違い
• 停電時の水槽対策（飼育ガイド） — 通知経路が落ちる原因の筆頭。復電までの時間をどう凌ぐか
• 水槽ヒーターの故障対策（飼育ガイド） — 留守中に多い機器トラブル。水温の傾きで捉える
• フィッシュルームの管理（飼育ガイド） — 水槽が増えるほど、見て回るコストは通知設計で決まる
• 魚まもりの料金 — 1本目はずっと無料。台数が増えたときの費用

よくある質問

参考文献

1. Espressif Systems: ESP32-C3 Datasheet（家庭向けIoT機器で広く採用されている無線SoCの公開仕様。対応帯が2.4GHz Wi-Fi（802.11b/g/n）のみであることの一次資料（他社SoC全般の傾向まで示すものではない））
2. Wi-Fi Alliance: Discover Wi-Fi（Wi-Fiの周波数帯と規格に関する業界団体の一般解説（2.4GHz/5GHzの位置づけ））
3. USGS Water Science School: Conductivity (Electrical Conductance) and Water（EC（電気伝導度）が溶存イオン量の指標になる原理、および値が水温で変わることの参照元）
4. LINE Developers: Messaging API 概要（LINEへの通知が「送信元サーバー → Messaging API → LINEプラットフォーム → 端末」という経路で配信されることを示す公開ドキュメント）
5. 不在日数別のリスク配分・蒸発率の想定（本記事のモデル計算の前提）（図中の蒸発1〜3%/日は環境条件から置いた仮定値であり、特定の一次出典に基づく実測ではない。濃縮の関係式は質量保存から導いたもの）