Experiment record

SwitchBotとGoogle Apps Scriptによる住宅環境の長期収集・外部気象連携・解析（改訂版）

12台のSwitchBot環境センサーをGoogle Apps Scriptから約5分周期で自動収集し、104,578件の記録から住宅内の温度・湿気・CO₂・外部気象との関係を解析した。Open-Meteoの長期運用上の問題と、外部研究機関・気象庁アメダスへの移行も記録した。

結論

SwitchBot環境センサー、SwitchBot OpenAPI v1.1、Google Apps Script、Google Sheetsを組み合わせ、住宅内外の環境データを約5分周期で継続収集するデータロガーを構築した。

最終構成では12台の環境センサーを対象とし、温度、相対湿度、計算した絶対湿度、対応機器ではCO₂、電池残量、API状態、端末情報、実行ログを保存した。

今回解析した非公開データの期間は 2026-07-28 05:28頃から2026-08-13 21:28頃までで、Measurements に 104,578件が記録されていた。API応答状態は SUCCESS が 104,564件、ERROR が 14件だった。

短い夏季データであっても、次の特徴を確認できた。

• 2F屋根裏は最高 44.3℃ まで上昇した。
• 1F床下は 23.9～26.2℃ の狭い温度範囲で推移した。
• 1F床下の平均相対湿度は約 86.9%RH と高かったが、平均絶対湿度は約 19.86 g/m³ で、外気平均約 20.08 g/m³ と近かった。
• リビングCO₂は中央値約 729 ppm、95パーセンタイル約 906 ppm、最大 2,037 ppm だった。
• 自宅外気センサーと2種類の外部気象観測の気温相関は約 r=0.924 と r=0.944 だった。

重要な解析上の知見は、相対湿度だけでは湿気の実態を判断できないことである。床下では高い%RHが観測されたが、絶対湿度は外気とほぼ同程度であった。つまり、水蒸気量の大きな増加ではなく、低温によって相対湿度が押し上げられた寄与が大きいと考えられる。

また、長期自動収集では「APIが利用できること」と「必要な連続性で運用できること」は別条件である。Open-Meteoは技術的には利用できたが、アクセス上限に起因する欠測が運用上の問題となり、最終的に主要な外部気象データ源から外した。

公開時のプライバシー境界

本記事は実験結果と実装経緯を再利用可能な形で公開するものであり、生の家庭内テレメトリそのものを公開するものではない。

公開しない情報は次のとおり。

• SwitchBot Token、Secret
• deviceId
• Spreadsheet ID、アカウント識別子
• 個人名を含む部屋名
• 外部研究機関の固有名称、観測所名、正確な所在地
• 気象庁側の具体的観測地点
• 約5分周期の生の家庭内時系列データ
• 住宅を特定し得る詳細な設置情報

匿名化しても、取得周期、解析期間、集計方法、統計値、実装構成など、再現性に必要な情報は可能な限り維持した。

1. 実験の目的

市販IoT環境センサーの現在値を確認するだけではなく、測定値を時系列として保存し、住宅の熱・湿気・換気特性を後から定量解析できる基盤を構築することを目的とした。

主な目的は以下である。

1. 住宅内の場所ごとの温度・湿度差を把握する。
2. 外気、居室、床下、屋根裏の熱的応答を比較する。
3. 相対湿度と絶対湿度を併用し、湿気の実態を評価する。
4. CO₂濃度から換気・在室状態の変化を評価する。
5. 外部気象データと住宅内環境の関係を解析する。
6. 将来的に空調・給湯・電力データと統合し、住宅環境とエネルギー消費を同一時系列で解析する。

2. システム構成

確認できたデータ経路は次のとおりである。

SwitchBot環境センサー
        ↓
SwitchBot Cloud
        ↓
SwitchBot OpenAPI v1.1
        ↓
Google Apps Script
        ↓
Google Sheets

後に外部気象データを追加し、Google Sheets内で住宅環境データと外部観測値を時刻ベースで比較できる構成とした。

2.1 Google Sheetsの構成

測定データ本体、デバイス管理、実行ログ、設定を分離することで、長期無人運用で問題が発生しても原因を追跡しやすくした。

3. SwitchBotデータ収集の実装

3.1 OpenAPI認証

SwitchBot OpenAPI v1.1を利用した。

APIリクエストでは、Token、現在時刻、nonceを連結した文字列に対してSecretを鍵としてHMAC-SHA256署名を生成し、Base64化した署名をHTTPヘッダーへ設定した。

実装上の主要ヘッダーは以下である。

Authorization: <SwitchBot Token>
sign: <HMAC-SHA256 signature>
t: <Unix time in milliseconds>
nonce: <UUID>

TokenとSecretはソースコードやスプレッドシートへ直接書かず、Apps Scriptの Script Properties に保存した。

3.2 対象端末の自動検出

APIの /devices からアカウントに登録された機器一覧を取得し、環境センサーのみを抽出した。

最終的に確認された環境センサー系のdeviceTypeには、少なくとも次が含まれていた。

• Meter
• MeterPlus
• MeterPro(CO2)
• WoIOSensor

初期実装では環境センサー候補が9台だったが、その後の機種判定修正により12台を取得対象として認識できるようになった。

この経験から、deviceType判定は製品名の想定だけで固定せず、実際の /devices 応答で確認する必要がある。

3.3 5分周期の収集

メイン処理は collectMeasurements() で、Apps Scriptの時間主導型トリガーから約5分ごとに実行した。

1回の処理では概ね以下を行う。

1. 必要ならデバイス一覧を更新する。
2. Devices から有効な対象端末を読み込む。
3. 各端末について /devices/{deviceId}/status を取得する。
4. deviceTypeによる応答フィールド差を正規化する。
5. 温度と相対湿度から絶対湿度を計算する。
6. Measurements に1端末1行を追記する。
7. 成否を Logs に記録する。
8. 成功端末の最終取得成功日時を更新する。

3.4 多重実行防止

約5分周期で起動するため、処理時間が延びると前回処理と次回処理が重複する可能性がある。

そのため LockService を用いて多重実行を防止した。すでに別処理がロックを保持している場合は、新しい処理を競合実行せずスキップさせる設計とした。

3.5 端末単位の例外処理

1台の取得失敗によって全端末の収集を停止しないよう、端末ごとに例外処理を分離した。

失敗した端末はERRORとして記録する一方、残りの端末の取得を継続する。

長期間の無人運転では、1台の一時障害をシステム全体の欠測へ拡大させないことが重要だった。

3.6 デバイス一覧のキャッシュ

/devices を5分ごとに取得する必要はないため、デバイス一覧は約24時間キャッシュした。

これにより不要なAPIアクセスを削減した。

4. 絶対湿度の計算

相対湿度は温度に強く依存する。

そのため、温度と相対湿度から絶対湿度を計算し、各測定値と一緒に Measurements へ保存した。

実装では飽和水蒸気圧を概ね次式で求めた。

e_s = 6.112 × exp((17.67 × T) / (T + 243.5))

続いて絶対湿度を計算した。

AH = (2.1674 × e_s × RH) / (273.15 + T)

ここで、

• T：温度 [℃]
• RH：相対湿度 [%]
• AH：絶対湿度 [g/m³]

である。

実装時の検算では、20℃・50%RHで約8.64 g/m³ となることを確認した。

後述する床下解析では、この絶対湿度を保存していたことが重要な意味を持った。

5. CO₂濃度の取得

CO₂対応センサーでは、温度・相対湿度・電池残量に加えてCO₂濃度を保存した。

これにより温熱・湿気環境だけでなく、換気や在室状態に関係する変化も同じ時系列基盤で扱えるようになった。

6. 外部気象データ取得の試行

6.1 Open-Meteoの導入

住宅内の測定値を外部気象条件と比較するため、当初はOpen-Meteo APIを導入した。

取得した1時間値を観測時刻をキーとして保存し、重複時刻を追記しない構成とした。

6.2 アクセス上限の問題

長期自動運用中に、Open-MeteoのAPIアクセス上限に関連する取得エラーが発生した。

API呼び出し数を減らすため、取得頻度を低下させ、最終的には 約6時間ごとにAPIへアクセスし、1時間値をまとめて取得する方式 へ変更した。

しかし、呼び出し頻度を下げても継続取得には欠測が残った。

SwitchBot側は約5分間隔で高密度な時系列が蓄積されるため、外部気象側に継続的な欠測が存在すると、長期比較の基準データとして扱いにくい。

6.3 Open-Meteoを主要データ源から除外

Open-Meteoは単発解析や補助的利用には利用可能だったが、今回必要とした長期間の無人連続観測の主要データ源としては採用しないこととした。

この試行から、

APIが技術的に利用できることと、長期運用上必要な連続性を持って利用できることは別の要件である

という知見を得た。

6.4 外部研究機関・気象庁アメダスへの移行

その後、外部気象比較には次の2系統を利用した。

• 外部研究機関が公開している地域気象観測値
• 気象庁アメダス観測値

公開版では所在地推定を避けるため、具体的な研究機関名、観測所名、観測地点は記載しない。

7. 解析対象データ

今回の解析対象は次のとおり。

API応答状態のみを見ると高い成功率だったが、後述するように SUCCESS でも物理的に不自然な測定値が存在した。

したがって、

1. 通信・API処理が正常だったか
2. 測定値自体が物理的に妥当か

は別々に検証する必要がある。

8. 解析1：住宅内外の温度推移

図1. 住宅内外の温度推移。
解析期間：2026-07-28 05:28頃～2026-08-13 21:28頃。約5分周期の測定値を1時間平均化した。解析対象は外気、リビング、1F床下、2F屋根裏。リビングの物理的に不自然な0.0℃値は、温度時系列の描画から除外した。

代表的な統計値は次のとおり。

2F屋根裏は最も大きな温度変動を示し、最高44.3℃に達した。

一方、1F床下は23.9～26.2℃の狭い範囲で推移した。

この差から、屋根裏は外気温と屋根面の日射加熱の影響を強く受け、床下は地盤・建物熱容量・日射から遮蔽された位置によって温度変化が平滑化されていると考えられる。

ただし、これは温度時系列からの解釈であり、熱流束を直接測定した結果ではない。

9. 解析2：床下の相対湿度と絶対湿度

9.1 相対湿度

図2. 外気と1F床下の相対湿度の平均日内変動。
解析期間全体について、各時刻0～23時の測定値を時刻別に平均した。横軸は時刻、縦軸は相対湿度[%RH]。

床下の相対湿度は一日を通して高く、平均約 86.9%RH だった。

外気は日中に温度が上昇すると相対湿度が大きく低下する一方、床下は温度変動が小さいため、相対湿度も高い状態で比較的安定していた。

9.2 絶対湿度

図3. 外気と1F床下の絶対湿度の平均日内変動。
解析期間全体について、各時刻0～23時の測定値を時刻別に平均した。横軸は時刻、縦軸は絶対湿度[g/m³]。

期間平均は次のとおり。

床下の相対湿度は外気より高いが、絶対湿度はほぼ同程度だった。

したがって、床下の高い相対湿度をそのまま「床下に外気より大量の水分が存在する」と解釈することは適切ではない。

床下温度が外気より低いため、同程度の水蒸気量でも%RHが高くなっている寄与が大きいと考えられる。

ただし、この結果だけから結露・カビリスクがないとは判断できない。今後は露点、表面温度、降雨履歴、換気、材料含水率等を組み合わせて評価する必要がある。

10. 解析3：リビングCO₂

図4. リビングCO₂濃度の推移。
解析期間：2026-07-28 05:28頃～2026-08-13 21:28頃。約5分周期のCO₂測定値を1時間平均化した。1000 ppm、1500 ppmの水平線はデータの読み取りを補助する参照線である。

統計値は次のとおり。

通常時は比較的低いCO₂濃度で推移したが、一時的に明瞭なピークが確認された。

CO₂は温度や湿度とは異なり、在室、換気、窓開け、調理等の影響を反映する可能性がある。

今後、実際の生活イベントと対応付けることで、換気状態の評価へ利用できる。

補助解析：CO₂の平均日内変動

補助図4b. リビングCO₂濃度の平均日内変動。
解析期間全体について各時刻0～23時の平均値と95パーセンタイルを算出した。個別日の生活時刻をそのまま公開せず、時間帯ごとの傾向を確認するための集計図である。

11. 解析4：自宅外気センサーと外部気象観測

図5. 自宅外気センサーと外部気象観測の気温比較。
SwitchBot外気、外部研究機関公開観測値、気象庁アメダス観測値を1時間平均で比較した。具体的な外部観測地点名は匿名化している。

比較結果は次のとおり。

SwitchBot外気センサーは外部観測値と高い相関を示した。

したがって、住宅周辺の外気温変動は地域気象の変化をよく追従している。

一方、平均温度には一定の差がある。

この差は直ちにセンサー校正誤差とは判断できない。

候補としては、

• 観測地点の違い
• 設置高さ
• 壁面・舗装面からの輻射
• 日射遮蔽
• 風通し
• 住宅周辺の局所微気象

等がある。

外部観測値は地域を代表する気象条件、自宅外気センサーは住宅が実際に曝されている局所環境を表すものとして、相補的に利用できる。

12. データ品質：SUCCESSでも値が正しいとは限らない

解析中、リビング温度に 0.0℃ という物理的に不自然な値が存在した。

しかし、その記録のAPI応答状態は SUCCESS だった。

これは重要なデータ品質上の知見である。

API処理では今後、少なくとも以下を分離して評価する必要がある。

通信・API品質

• HTTPリクエストが成功したか
• SwitchBot APIステータスが正常だったか
• JSONが期待した形式で返ったか

測定値品質

• 温度が対象環境で物理的に妥当か
• 湿度が0～100%RH内か
• CO₂値が機器仕様・利用環境から見て妥当か
• 前後の時系列から見て急激すぎる変化でないか

生データは監査用として保持し、解析時には品質フラグを付与したデータセットを別途作る構成が望ましい。

13. 考察

13.1 多点測定の意義

住宅内環境を単一の室温だけで評価すると、屋根裏、床下、居室の異なる熱応答を把握できない。

今回の多点測定では、

• 屋根裏：日射・外気の影響が大きい
• 床下：温度変動が小さい
• 居室：比較的安定
• 外気：地域気象に追従しながら住宅周辺の微気象を含む

という異なる応答が確認できた。

13.2 相対湿度だけでは湿気を判断できない

床下の約86.9%RHという値だけを見ると、非常に湿った空間に見える。

しかし絶対湿度は外気とほぼ同等だった。

この比較によって、

高い相対湿度 = 大量の水蒸気

とは限らないことが明確になった。

住宅の湿気解析では、少なくとも温度、相対湿度、絶対湿度または露点を併用する必要がある。

13.3 自宅外気センサーの価値

外部気象観測との相関が高いことから、自宅外気センサーは地域気象の変化を追従している。

同時に、外部観測との一定の温度差は、住宅周辺の局所微気象を測っている可能性を示す。

住宅の熱負荷解析では、地域代表値だけでなく、実際の住宅周辺環境を測定することにも意味がある。

13.4 外部APIの運用評価

Open-Meteoの経験から、長期自動収集ではAPIの機能だけでなく、次も評価対象になる。

• 呼び出し上限
• 再取得可能性
• 欠測率
• サービス継続性
• 無人運用での安定性

長期データロガーにおいては、API仕様はセンサー仕様と同様に実験条件の一部である。

14. 制限事項

今回の解析には以下の制限がある。

1. 観測期間は約2週間の夏季データであり、年間挙動を代表しない。
2. センサーをトレーサブルな基準器と比較した校正試験は行っていない。
3. 屋根裏の高温は日射影響が強いと推定しているが、屋根表面温度や熱流束を直接測定していない。
4. 床下の湿気評価では表面温度、材料含水率、地盤水分を測定していない。
5. CO₂ピークを具体的な在室・換気イベントと対応付けていない。
6. 外部観測との平均差について、センサー固有誤差と局所微気象の寄与を分離できていない。
7. 生の家庭内時系列はプライバシー保護のため公開していない。

15. 今後可能な解析

15.1 熱応答・時間遅れ

外気温と各空間の温度を相互相関解析し、どの程度の時間遅れで住宅内部が応答するかを推定する。

15.2 屋根の日射影響

日射量、外気温、屋根裏温度を組み合わせ、屋根からの熱負荷をモデル化する。

15.3 床下の結露リスク

温度と絶対湿度から露点を算出し、基礎・床・配管等の表面温度と比較する。

15.4 換気解析

CO₂上昇・減衰と実際の換気イベントを対応付け、条件が整えば有効換気回数を推定する。

15.5 部屋間比較

各居室の温湿度を比較し、季節・時間帯ごとに暑い、寒い、湿りやすい場所を定量化する。

15.6 季節解析

1年間以上データを蓄積し、梅雨、夏季、冬季乾燥期、中間期で住宅の応答を比較する。

15.7 異常検知

正常な日内・季節パターンを学習し、センサー異常、空調停止、異常換気等を検出する。

16. エネルギーデータとの統合

今後、設備別消費電力を同一時系列へ追加すると、次の関係を解析できる。

外部気象
  ↓
住宅内温度・湿度・CO₂
  ↓
空調・給湯・その他設備の運転
  ↓
消費電力量

これにより、

「何kWh使用したか」

だけではなく、

「ある外気条件で一定の室内環境を維持するために、何kWh必要だったか」

という住宅性能評価へ発展できる。

17. この実験で得られた実装上の知見

1. 絶対湿度を初期段階から保存しておくと、湿気解析の解釈が大きく改善する。
2. deviceTypeは想定だけで判定せず、実API応答から確認する。
3. 1台のAPI失敗で全体を止めない端末単位例外処理が長期無人運転に有効である。
4. LockService による多重実行防止が必要である。
5. デバイス一覧の24時間キャッシュは不要なAPIアクセス削減に有効である。
6. SUCCESS と測定値の物理的妥当性は別に検証する。
7. 外部APIは「取得可能か」ではなく「必要な期間・頻度で安定運用可能か」で評価する。
8. 自宅外気センサーと地域代表気象は競合するデータではなく、異なる空間スケールを表す相補的データである。
9. 生の家庭内時系列を公開しなくても、集計条件・統計量・解析図を適切に公開すれば、技術的な再利用価値を維持できる。

18. 再現性の境界

同様の収集システムは、以下を用意すれば再現可能である。

• 所有するSwitchBot環境センサー
• SwitchBot OpenAPI v1.1認証情報
• Google Apps Script
• HMAC-SHA256認証処理
• 約5分周期の時間主導型トリガー
• Measurements / Devices / Logs / Settings の分離
• 温度・相対湿度からの絶対湿度計算
• 端末単位の例外処理
• LockService による多重実行防止
• 外部気象データ源
• 異常値・欠測を考慮した解析処理

ただし、認証情報、デバイス識別子、個人宅固有名称、生の家庭内テレメトリ、具体的な外部観測地点は再現性のために必要ではないため公開しない。

19. まとめ

SwitchBotの環境センサーを単なる現在値表示装置として利用するのではなく、APIから約5分周期で時系列保存することで、住宅の熱・湿気・換気特性を解析できるデータ基盤を構築できた。

今回の短期間解析だけでも、屋根裏の大きな熱応答、床下の高相対湿度と外気に近い絶対湿度、リビングCO₂の一時ピーク、自宅外気と外部観測の高い相関が確認された。

また、Open-Meteoの運用失敗、初期センサー検出漏れ、API SUCCESS 中の異常値など、実装・運用上の失敗も重要な実験結果だった。

AI Experiment Logとしては、成功した最終構成だけでなく、何を試し、何が失敗し、どのように修正し、どのデータから何を判断したかを残すことに価値がある。