みなさん、こんにちは。
1年前、「GitHub CopilotとAIが変えるIoT開発〜エアコン制御で快適な夏の夜を〜」 という記事で、GitHub Copilotと一緒に作った「sleep_condition_controller」というPythonスクリプトを紹介しました。室温が設定した閾値を超えたらエアコンを30分だけ起動する、というシンプルな仕組みです。昨年、我が家で運用し、まあまあ満足していました。
先週あたりから今年の夏も本番に入り、就寝中のエアコン制御が必須になってきました。「今年も活躍してもらおう」と設定をオンにして再度動かしてみたところ、ふと「本当にこれがベストな制御なのだろうか」という疑問が湧いてきました。
今回はその改善を、Claude Codeと対話しながら進めてみた記録です。
シンプルな閾値制御の限界
前回作ったプログラムは、次のようなロジックでした。
- 室温が閾値（例：34℃）を超えたらエアコンをON
- ONにしてから30分経ったら、室温に関係なく強制的にOFF
今年、改めて動かしてみると、これがなかなか荒っぽい制御であることに気づきます。エアコンをつけてすぐ室温が下がっても30分間律儀に回り続けてしまい、電気代の無駄になります。逆に、蒸し暑い夜はなかなか室温が下がらないのに、タイマーが切れると容赦なく止まってしまう。
「省エネ型」を謳っていたはずが、実際には温度をほとんど見ていない「タイマー任せ」の制御だったわけです。
そこでClaude Codeに、コードを読んでもらった上でこう聞いてみました。
sleep_condition_controller.pyは温度を監視してエアコンのオンオフをするプログラムだけれど、もう少しスマートな制御はできない？
AIと対話しながら設計を詰める
面白かったのは、Claude Codeがすぐにコードを書き始めるのではなく、まず現状の問題点を整理し、改善案とトレードオフを提示してくれたことです。
今の実装は室温が下がってても30分間律儀に回り続ける（＝無駄な電力消費）か、逆に下がりが遅いのに強制OFFされる、というズレが起きやすいので、ONにした後も毎回温度を取得して下限閾値を下回ったら即OFF、という「ヒステリシス制御」にするのが一番効果的だと思います。
ここで自分から「不快指数で判定したい」とリクエストしました。室温だけでなく湿度も加味したほうが、実際の体感に近い制御になると考えたからです。実際、今年の夏は昨年より湿度が高いようで、温度だけの制御には限界を感じていました。
合わせて、「オンとオフを同じ閾値にすると、止まった直後にまたすぐ点いてしまう（チャタリングのような現象）のでは」という懸念も伝えたところ、一般的なヒステリシス幅の考え方を教えてくれました。
温度のみで制御する場合は1〜2℃差が一般的ですが、不快指数（DI）は温度と湿度の合成値なので、実用上は3〜5ポイント差が目安になります。
- ON： DI >= 80 （暑くてたまらないレベル）
- OFF： DI <= 75 （やや暑い程度まで下がったら止める）
くらいが妥当だと思います。
数値だけでなく「なぜその幅が必要か」という理屈も一緒に説明してくれるので、納得しながら仕様を決められました。
実装 ― 不快指数によるヒステリシス制御
我が家では、M5AtomS3に環境センサーを接続して、Ambientに温度（d1）に加えて湿度（d2）を送信しています。
そこで、湿度も使って不快指数を計算するように変更しました。
計算式は以下の通りです。
DI = 0.81T + 0.01H(0.99T – 14.3) + 46.3
( T: 温度（℃） , H: 湿度（%） )
不快指数（DI）と体感の目安
| DI（不快指数） | 体感 |
| 75未満 | やや暑い程度 |
| 75 〜 80 | 暑くて汗が出る |
| 80 〜 85 | 暑くてたまらない |
| 85以上 | 暑くて危険 |
これに合わせて、settings.ini もこのように書き換えました。
[discomfort_index]
on_threshold = 80.0
off_threshold = 75.0
[safety]
max_runtime = 1800
新しい制御ロジック
- 停止中
不快指数がON閾値（80.0）以上になったらエアコンを起動 - 稼働中
不快指数がOFF閾値（75.0）まで下がったら停止 - 安全装置
湿度が高くて不快指数がなかなか下がらない場合でも、max_runtime（デフォルト30分）を超えたら強制停止
前回の「固定タイマーで止める」という仕組みを完全に捨てるのではなく、「本来の停止条件（不快指数低下）に加えて、最悪ケースの安全装置として残す」という形にしたのがポイントです。実際の室温変化に応じて賢く動きつつ、万一のセンサー異常時などにも回り続けないよう配慮しました。
プルリクエストまで一気通貫
コードの修正が終わったら、そのまま「PRを作成して」とお願いしました。ブランチの作成、コミット、プッシュ、そして gh pr create によるプルリクエストの作成まで、一連の流れを自動でやってくれます。
git checkout -b feature/discomfort-index-control
git commit -m "不快指数によるヒステリシス制御に変更"
git push -u origin feature/discomfort-index-control
gh pr create ...
PRの本文には変更概要とテスト内容（構文チェック、不快指数計算の検証、設定値読み込みの確認など）もロジカルにまとめて記載されており、実機での最終確認さえすればそのままレビューに出せる状態になっていました。
AIと議論しながら開発する
前回はGitHub Copilotで「動くものを素早く作る」体験でしたが、今回はClaude Codeと対話しながら「なぜその設計が良いのか」を一緒に詰めていく体験でした。
ヒステリシス幅の目安のような、いわば「制御工学の常識」を都度教えてもらいながら実装できたのは、一人で仕様を黙々と決めるよりも確実に良い結果につながったと感じます。技術は手段であり、人間の快適さや課題解決という「目的」にどうアプローチするかをAIと議論できるのは非常に面白いですね。
シンプルな温度閾値制御から、湿度も加味した不快指数によるスマートな制御へ。次はセンサーデータを蓄積して、時間帯ごとの室温変化の傾向から先回りして制御する、といった発展も試してみたいと思っています。AIと一緒に手を動かしながら育てていくIoT開発、しばらく続けてみようと思います。
今回修正したコードはGitHubで公開しています。よかったら使ってみてください。
本日も最後までお読みいただきありがとうございました。
それでは、よいIoT制御と快適な夏を！
