雑記帳

徒然なるままに「科学」であろうとなかろうと書き留める雑記帳です。

  • 温湿度データロガーを使ってみたら、エアコンの制御まで見えてきた

    今年の夏も、昨年に負けないくらい暑い日が続いています。

    暑い日には「今日は暑いなぁ」、寒い日には「なんだか冷えるなぁ」と感じますが、そのとき実際の室温や湿度がどれくらいなのかを意識することは意外と少ないものです。

    皆さんは普段、部屋の温度や湿度をどのように管理しているでしょうか?

    時計に付いている温度計をちらっと見る程度という方もいれば、エアコン任せという方もいるかもしれません。

    実際、「暑い」「寒い」という感覚には個人差があります。

    職場でも、

    「今日は暑いね」

    と言う人がいる一方で、

    「えっ、27℃もあるの?もっと低いと思った」

    という人もいます。

    同じ空間にいても、人によって感じ方は大きく異なるのです。

    環境省では、省エネルギーを意識しながら快適性を保つ目安として、

    夏季:室温28℃
    冬季:室温20℃

    を推奨しています。

    しかし本当に部屋の温度はそのように推移しているのでしょうか。

    以前から、

    室内の温度変化
    車内温度の変化
    エアコンによる温湿度制御

    に興味があった私は、実際に測定してみることにしました。


    2千円で買える温湿度データロガー

    そこで購入したのが温湿度データロガーです。

    昔はデータロガーといえば研究用途や産業用途が中心で、数万円から数十万円する機器でした。

    ところが現在では、2千円で購入できる製品も珍しくありません。

    Amazonで探した結果、今回購入したのは JJWS23というモデルです。

    液晶表示はありませんが、

    ・温度・湿度を同時測定
    ・最短1分間隔で記録
    ・BlueToothによるデータ回収
    ・CSV出力対応
    ・低価格

    という条件を満たしていました。

    特にBluetooth対応なのが魅力です。

    測定場所へ行って本体を回収しなくても、その場でスマートフォンからデータを取得できます。


    まずは3日間、どこへ行くにもJJWS23を持ち歩いてみた

    せっかく購入したので、まずは徹底的に使ってみることにしました。

    購入後の3日間、 JJWS23を常に携帯し、自分が滞在する環境の温度と湿度を記録してみました。

    言ってみれば、自分自身が実験台です。

    この期間は平日だったので

    ・06:00~18:00頃:職場
    ・18:00~06:00頃:自宅

    という生活パターンになります。

    その結果をグラフ化してみると、温度と湿度が時間帯によって実に面白い変化を見せてくれました。

    8/3から8/7の筆者I-sattoの滞在した環境の温湿度のトレンド

    赤が湿度(humidity)黒が気温(Temperature)です。

    また、グラフはグレーでハッチングしてあるところが職場での測定値になります。ちなみに、この三日間は比較的涼しく、以下のような気温でした。

    平均気温(℃)最高気温(℃)最低気温(℃)平均湿度(%)
    8月4日23.827.820.076
    8月5日24.428.919.375
    8月6日26.230.822.389

    データからエアコンの制御が見えてくる

    最も興味深かったのは職場での測定結果です。

    朝、出勤してエアコンを入れると室温が下がり始めます。

    しかし、設定温度付近に達すると冷房能力が弱まり、再び温度が上昇します。

    すると今度は冷房が強くなり、また温度が下がる。

    この繰り返しがグラフ上にはっきり現れていました。

    以下のグラフは8月5日の6時から18時の職場にいる時間帯を拡大表示したものです。

    2026年8月5日の筆者I-sattoの滞在した職場の温湿度の時間変化

    波打つような温度変化を確認すると、

    エアコンが約20分周期で室温を制御している

    ことが見えてきます。

    普段は意識することのない空調制御の動きが、温湿度データとして可視化された瞬間でした。

    さらに室温はおおむね27℃前後で維持されていることも確認できます。


    西日がエアコンに勝つ瞬間

    さらに興味深いのが午後の変化です。

    昼過ぎまでは安定していた室温が、14時半頃から急激に上昇します。

    職場は西日の影響を受けやすい部屋です。

    そのため午後になると窓から侵入する熱量が増加し、エアコン能力だけでは室温上昇を抑えきれなくなります。

    結果として、

    26℃
    27℃
    28℃
    一時的に29℃

    まで上昇する様子がグラフに記録されていました。

    まさに、

    「西日との戦い」

    がデータから読み取れたわけです。


    誰もいない職場は夜どうなるのか?

    さらに実験を続けました。

    8月5日はJJWS23を持ち帰らず、職場に置いたまま帰宅してみました。

    つまり、8月5日18時から翌日8月6日の6時までは

    無人・空調なしのオフィス

    の温湿度変化を測定したのです。

    結果は予想以上に興味深いものでした。

    夕方に29℃近くあった室温は、夜を通してゆっくりと低下していきます。

    一方、湿度は徐々に上昇します。

    そして日の出前後まで温度は下がり続け、朝になると再び上昇へ転じます。

    人がいない空間でも、建物全体が外気や日射の影響を受けながら呼吸するように温度を変化させていることがよく分かりました。


    実は意外と高機能だった専用アプリ

    このJJWS23にはスマートフォン用アプリが用意されています。

    単なる温湿度表示だけでなく、

    ・カビのリスク

    ・測定ログの最高温度/最低温度とその日時

    ・現在温度、現在湿度

    ・VPD(飽差)

     VPD(Vapor Pressure Deficit)は、空気がどれだけ水蒸気を保持できるかを示す指標で、植物の蒸散や水分管理に大きな影響を与え、「飽差」と呼ばれます。
    この値(VPD)は飽和蒸気圧(VPes)と相対湿度(RH)から、以下のテテンス(Tetens)の式で計算が可能です。

    VPD=VPes(T) (1-RH/100)
    VPes(T)= 0.61078 exp( 17.27 T )/ (T + 237.3) )

    ここで、飽和蒸気圧(VPes)は温度(T)から求めることができるので、実質的にはVPD(飽差)は温度(T)と相対湿度(RH)が判れば計算できるので、ここで示されている値は計算値になるはずです。
     で、実際に計算すると
    28.5℃、52.4%時のVPDは1.85kPaとなり表示値と一致します。
    29.5℃、72.3%時には1.14kPaとなり、こちらも表示値と一致します。

    ・露点

    露点は結露する温度で、室内やビニールハウスなど閉じた環境で、そのまま温度を下げると、この露点まで下がったときに結露してしまいます。この露点(Td)も温度(T)と相対湿度(RH)から以下の式で計算が可能です。

    Td = 237.3 × γ / (17.27 − γ)
    γ(RH,T) = ln(RH/100) + 17.27 T / (T + 237.3)

    で、実際に計算すると
    28.5℃、52.4%時の露点は17.80℃となり表示値とほぼ一致します。
    29.5℃、72.3%時には23.98℃となり、こちらは表示値と一致します。

    ・暑さ指数

    なども表示できます。

    農業用途を意識しているためか、植物栽培で重要となるVPDまで表示されるのは少し驚きでした。


    「暑さ指数」の正体を調べてみた

    ところが、アプリの表示を見ていて気になる点を発見しました。

    表示される「暑さ指数」が、どう計算してもWBGT(湿球黒球温度):Wet Bulb Globe Temperatureと一致しないのです。

    そこで計算式を調べてみましたが、どうしても値が合いません。

    通常、黒球温度が判らないと推定が難しいのですが、室内用として簡易推定式(気温(T)と湿度(RH)のみで近似)が決められています。

    簡易推定式(気温と湿度のみで近似)

    WBGT = 0.7 ×Tw+ 0.3 ×T
    Tw(RH,T)= T atan(0.151977 (RH + 8.313659)^0.5) + atan(T + RH) – atan(RH – 1.676331) + 0.00391838 RH^1.5 atan(0.023101 RH) – 4.686035

    なお、上の湿球温度Tw(RH,T)はStull近似式といわれる計算式を用いて温度(T)と湿度(RH)から算出しています。

    で、実際に計算すると
    28.5℃、52.4%時のWBGTは26.37℃となり表示の「暑さ指数」値29.29℃と一致しません。また、 29.5℃、72.3%時には28.30℃となり、こちらも表示値34.35℃と全く一致しません。

    いったいどういうことでしょう?

    もしかして翻訳の問題ではないか?

    そう考えて英語表記を確認すると、表示されていたのは

    Heat Index

    でした。

    つまり日本語版では「暑さ指数」と表示されていますが、実際にはWBGTではなく「熱指数」を示していたのです。

    ということで、「熱指数」で計算してみます。熱指数(Heat Index:HI)気温(T)湿度(RH)のみで以下の式で熱指数を定義しているステッドマン表を近似できます。

    HI=c1 + c2 T + c3 RH + c4 T RH + c5 T^2 + cg RH^2
    + c7 T^2 RH + c8 T RH^2 + C9 T^2 RH^2
      c1 = -8.784694756  c2 = 1.61139411     c3 = 2.338548839
      c4 = -0.14611605   c5 = -0.012308094   c6 = -0.016424828
      c7 = 0.002211732   c8 = 0.00072546   c9 = -0.000003582  

    で、実際に計算すると
    28.5℃、52.4%時のHeat Indexは29.29℃となり表示値と一致します。
    29.5℃、72.3%時には34.35℃となり、こちらも表示値と一致します。

    ということで、このアプリでいう暑さ指数とはHeat Indexすなわち、熱指数を表していることが判りました。いわゆる熱中症の判断材料とするWBGTとは異なりますので、注意してください。


    使ってみて分かったデータロガーの面白さ

    今回、温湿度データロガーを使ってみて感じたのは、

    「測るだけで世界の見え方が変わる」

    ということです。

    何となく暑いと思っていた環境も、

    エアコンがどのように制御しているのか
    建物がどのように熱を蓄えているのか
    湿度がどのように変動しているのか

    をデータとして確認できます。

    さらに、普段は意識しないVPDや露点、Heat Indexといった指標の意味を理解するきっかけにもなりました。

    2千円で購入できる小さな機器ですが、その中には思いのほか多くの「科学のつまみ食い」が詰まっています。

    温度や湿度の変化に興味がある方なら、一度試してみる価値は十分にあるのではないでしょうか。

    投稿日:

    更新日:

  • リモート接続中にUbuntu 26.04へアップグレードしたら、RDPが切れた ― ChatGPTと一緒に復旧した顛末記 ―

    はじめに

    以前から使用していたUbuntuサーバーを、Ubuntu 26.04 LTSへアップグレードすることにしました。

    今回は、普段使用しているWindows PCからRDP(リモートデスクトップ)でUbuntuに接続した状態のまま、リリースアップグレードを実行しました。

    アップグレードは順調に進んでいるように見えましたが、途中で突然RDP接続が切断されました。

    「アップグレードによって再起動したのだろう」と考え、その後あらためてRDP接続を試みました。

    ところが、思ったように接続できません。

    結果的には、アップグレード自体はかなり進んでいたものの、多数のパッケージがまだ設定されていない状態になっていました。

    この後、ChatGPTに状況を相談しながら状態を一つずつ確認し、最終的にUbuntu 26.04.1 LTSを正常な状態まで復旧することができました。

    今回は、その顛末を記録しておきます。


    1.リモートデスクトップからUbuntuをアップグレード

    今回の環境は、

    • Ubuntu 25.10系からUbuntu 26.04 LTSへアップグレード
    • GNOMEデスクトップ環境
    • Wayland
    • GNOME Remote DesktopによるRDP接続
    • Windows PCからリモート操作

    という構成です。

    UbuntuはノートPCにインストールし、直接ノートPCのモニターとキーボードを使用するのではなく、Windows PCからRDPで接続して使用しています。

    そこで今回も、リモート接続した状態でUbuntuのリリースアップグレードを開始しました。


    2.アップグレード途中でRDPが切断

    アップグレード処理は大量のパッケージを更新するため、かなり時間がかかります。

    しばらくすると、突然RDP接続が切れました。

    ここで、

    「アップグレードが終了して再起動したのだろう」

    と考えてしまいました。

    しかし、これは少し早い判断でした。

    アップグレードでは、GNOME、GDM、Wayland、ネットワーク関連など、現在のリモートデスクトップ環境そのものに関係するパッケージも更新されます。

    そのため、アップグレード途中でGUIやRDPのセッションが切断されることがあります。

    問題は、

    「RDPが切れたこと」と「アップグレードが完了したこと」は同じではない

    ということでした。


    3.再接続できず、アップグレードの状態を確認

    RDP接続を再度試みましたが、思ったように接続できませんでした。

    そこでChatGPTに状況を説明し、まずシステムのパッケージ状態を確認することにしました。

    実行したのが、

    sudo dpkg --audit
    

    です。

    すると、

    展開されましたが、まだ設定されていません

    というパッケージが大量に表示されました。

    GNOME関連のパッケージをはじめ、デスクトップ環境を構成する多数のパッケージが未設定の状態になっていました。

    つまり、

    Ubuntuのアップグレードは途中まで進んでいたものの、完全には終了していなかった

    ことが分かりました。


    4.apt-get -f installで未設定パッケージを処理

    次にChatGPTの助言に従い、

    sudo apt-get -f install
    

    を実行しました。

    すると、大量のパッケージについて、

    ○○○ を設定しています ...
    

    という処理が始まりました。

    GNOME、GDM、polkit、ibus、Remmina、Nautilusなど、デスクトップ環境に関係するパッケージが次々と設定されていきます。

    また、カーネルについても、

    linux-image-7.0.0-30-generic
    

    が処理され、initramfsの生成やGRUBの更新も行われました。

    最終的には、未設定だったパッケージの処理が完了しました。


    5.dpkg --auditで状態を確認

    修復できたかどうかを確認するため、再度、

    sudo dpkg --audit
    

    を実行しました。

    今度は何も表示されません。

    これは、dpkgから見て未設定のパッケージが残っていないことを意味します。

    ひとまずパッケージ管理上は正常な状態に戻ったと判断しました。


    6.再起動

    その後、システムを再起動しました。

    sudo reboot
    

    再起動後、Ubuntuのバージョンを確認すると、

    uname -r
    

    の結果は、

    7.0.0-30-generic
    

    となっていました。

    さらに、

    lsb_release -a
    

    では、

    Distributor ID: Ubuntu
    Description:    Ubuntu 26.04.1 LTS
    Release:        26.04
    Codename:       resolute
    

    と表示されました。

    これで、Ubuntu 26.04.1 LTSへのアップグレードが正常に完了していることを確認できました。


    7.ところが、RDPにはもう一つ問題があった

    OSのアップグレードは完了しましたが、ここで別の問題が出てきました。

    今回の目的は、

    Ubuntu本体側でログインしていなくても、Windows PCからRDP接続してUbuntuにログインしたい

    というものです。

    ところが、通常のユーザーセッション用RDPでは、本体側ですでにUbuntuへログインしていないと、思ったように接続できませんでした。

    そこでChatGPTと一緒にGNOME Remote Desktopの状態を確認しました。

    grdctl status
    

    と、

    sudo grdctl --system status
    

    を比較すると、通常ユーザー用とsystem-wideのRDPが別々に存在していることが分かりました。


    8.system-wideのRDPを有効化

    そこで、system-wideのGNOME Remote Desktopを有効にしました。

    sudo grdctl --system rdp enable
    

    状態を確認すると、

    RDP:
        Status: enabled
        Port: 3389
    

    となりました。

    一方、通常ユーザー側のRDPについては、

    gsettings set org.gnome.desktop.remote-desktop.rdp enable false
    

    として無効化しました。

    これは、通常ユーザー用とsystem-wideのRDPが二重に動作して混乱することを避けるためです。


    9.ログイン前のRDP接続に成功

    ここまで設定したところ、期待していた動作が実現しました。

    Ubuntu本体ではログインしていない状態で、

    Windows PCからRDP接続。

    すると、リモート側からUbuntuへログインできました。

    つまり、

    Ubuntu本体
        ↓
    ログインしていない
        ↓
    Windows PCからRDP
        ↓
    Ubuntuのログイン
        ↓
    GNOMEデスクトップ
    

    という使い方が可能になりました。


    10.しかもリモート側は大画面で使用できた

    当初は、RDP接続すると本体画面が表示されたままになり、リモート側が「拡張デスクトップ」のようになってしまう問題もありました。

    現在の設定を確認すると、

    gsettings get org.gnome.desktop.remote-desktop.rdp screen-share-mode
    

    は、

    'extend'
    

    となっています。

    ところが、system-wideのRDPからログインした場合には、以前とは異なり、リモート側の大きな画面を使って通常のUbuntuデスクトップを操作できるようになりました。

    また、

    echo $XDG_SESSION_TYPE
    

    は、

    wayland
    
    echo $WAYLAND_DISPLAY
    

    は、

    wayland-0
    

    となっていました。

    結果として、現在はリモート側で快適にUbuntuを操作できています。


    11.今回分かったこと

    今回のトラブルを通して、いくつか重要なことが分かりました。

    ① RDPが切断されたからといって、アップグレードが終了したとは限らない

    アップグレード中は、GNOMEやGDMなどの更新によってGUIセッションが切断されることがあります。

    そのため、

    RDPが切れた → アップグレード完了

    と判断するのは危険です。


    dpkg --auditは非常に有効だった

    今回、アップグレードが正常に終了しているかどうかを確認するために、

    sudo dpkg --audit
    

    を使用しました。

    大量の未設定パッケージが表示されたことで、アップグレードが完全には終了していないことが分かりました。

    復旧後に再度実行して何も表示されないことを確認することで、パッケージ管理上の状態を確認できました。


    apt-get -f installで未完了の処理を継続できた

    今回の復旧では、

    sudo apt-get -f install
    

    によって、未設定だった大量のパッケージが順次設定されました。

    結果として、GNOMEを含むデスクトップ環境を正常な状態まで戻すことができました。


    ④ リモート環境では「接続が切れること」を前提にした方がよい

    今回もっとも勉強になったのは、この点です。

    OSのアップグレードをRDPだけに頼って実行すると、アップグレードによってRDPそのものが切断される可能性があります。

    今後、同じような作業を行う場合には、SSHやtmuxなど、GUIとは独立した方法でアップグレードの状態を確認できるようにしておく方が安全だと思います。


    12.今回のまとめ

    今回のトラブルは、

    「リモートデスクトップでUbuntuをアップグレードしていたところ、途中でRDPが切断され、アップグレードが完全に終了していない状態になっていた」

    ことから始まりました。

    その後、

    dpkg --audit
          ↓
    未設定パッケージを確認
          ↓
    apt-get -f install
          ↓
    パッケージ設定を完了
          ↓
    dpkg --audit
          ↓
    問題なし
          ↓
    再起動
          ↓
    Ubuntu 26.04.1 LTSを確認
          ↓
    system-wide RDPを有効化
          ↓
    ログイン前のRDP接続に成功
    

    という手順で復旧しました。

    今回の復旧では、ChatGPTに実際のターミナル画面の結果を一つずつ提示しながら、原因を切り分けていきました。

    「何となく操作して直す」のではなく、コマンドの結果を確認しながら次の操作を決めることが、今回の復旧につながったと思います。

    最終的には、Ubuntu 26.04.1 LTSへのアップグレードを完了し、さらに、

    「本体側でログインしていなくても、Windows PCからRDP接続してUbuntuへログインし、大画面で操作する」

    という当初の目的も達成することができました。


    おわりに

    今回の経験から、リモート環境でOSの大きなアップグレードを行う場合には、

    「リモート接続が切れる可能性をあらかじめ想定しておく」

    ことが重要だと感じました。

    また、トラブルが発生したときには、いきなり設定を変更するのではなく、

    sudo dpkg --audit
    

    などで現在の状態を確認し、その結果をもとに復旧作業を進めることが大切です。

    今回はChatGPTにも協力してもらいながら、最終的に無事復旧することができました。

    同じようにリモート環境からUbuntuをアップグレードする方の参考になればと思い、今回の顛末を記録として残しておきます。

    投稿日:

    更新日:

  • ChatGPTと一緒にWebサイトをSSL化してみた

    先日、Ubuntu + Apache2 + WordPress環境で運用している当サイト「科学のつまみ食い(kagaku.info)」を、HTTPからHTTPSへ移行しました。

    最近ではHTTPS化は当たり前になっていますが、自宅サーバーで運用していると「そのうちやろう」と後回しにしがちです。私もまさにその一人でした。

    しかし、せっかく公開しているサイトですから、安全性や信頼性を高めるためにもSSL化しておきたいところです。

    そこで今回は、Let’s Encryptによる無料SSL証明書を利用し、サイト全体のHTTPS化に挑戦してみました。


    今回も頼りになったChatGPT

    実は少し前、WordPressをサブディレクトリで運用していた際に発生したトラブルを、ChatGPTの助けを借りながら解決したことがあります。

    ▶ 関連記事
    WordPressサブディレクトリ運用時のトラブルと解決方法

    今回のSSL化はトラブル対応というわけではありませんでしたが、一度その便利さを知ってしまうと、つい頼りたくなってしまいます。

    作業中に表示される警告メッセージや設定内容をChatGPTに確認しながら、

    • 現在の設定は正しいのか
    • 次に何を確認すべきか
    • エラーの原因はどこにありそうか

    を一つずつ整理し、問題を切り分けながら進めることができました。

    まるで隣に詳しいシステム管理者がいて相談しながら作業しているような感覚です。


    SSL化のために実施した作業

    今回実施した主な作業は以下のとおりです。

    1. Apacheの ServerName を設定し、AH00558警告を解消
    2. mod_ssl および mod_rewrite を有効化
    3. Certbot と Let’s Encrypt を導入
    4. DNS設定とApacheのVirtualHost構成を確認
    5. ルーターのポートフォワーディング設定(TCP 80/443)を確認
    6. Let’s EncryptからSSL証明書を取得
    7. Apacheへ証明書を自動設定
    8. HTTPからHTTPSへの自動リダイレクトを設定
    9. WordPressのURL設定をHTTPSへ変更
    10. Microsoft Edgeおよびスマートフォンから接続確認
    11. certbot renew --dry-run による自動更新テストを実施

    実際には、それぞれの設定項目が正しいか確認しながら進める必要があり、「SSL証明書を取得して終わり」というほど単純な作業ではありませんでした。

    特に、自宅サーバー環境ではDNS設定やルーター設定が関係するため、ネットワーク全体を見ながら確認する必要があります。


    結果は大成功

    無事に設定が完了し、現在のサイトは以下の状態で安定運用できています。

    • HTTPSによる暗号化通信
    • HTTPアクセス時のHTTPSへの自動転送
    • Let’s Encrypt証明書の自動更新

    ブラウザのアドレスバーにも鍵マークが表示されるようになり、サイトとしての安心感も大きく向上しました。

    利用者側から見れば小さな変化かもしれませんが、運営者としては達成感のある作業です。


    AIを活用したサーバー運用の可能性

    今回改めて感じたのは、ChatGPTがサーバー運用やシステム設定の強力なサポート役になるということです。

    もちろん最終的な判断や作業は自分で行う必要があります。しかし、

    • エラーメッセージの意味を調べる
    • 設定項目を確認する
    • トラブルの切り分けを行う
    • 作業手順を整理する

    といった場面では非常に心強い存在でした。

    以前のWordPressトラブル解決に続き、今回のSSL化もChatGPTの支援を受けながら無事完了できました。

    自宅サーバーを運用していると、思いもよらない問題に遭遇することがあります。しかし、そのたびに知識を積み重ねながら環境を改善していくのも、自宅サーバー運用の楽しみの一つではないでしょうか。

    今回のSSL化も、その良い経験となりました。もしこれからHTTPS化を検討している方がおられれば、本記事が少しでも参考になれば幸いです。

    投稿日:

    更新日:

  • ZR-V e:HEV Zの燃費を1年間追い続けてみた

    2025年8月、Honda ZR-V e:HEV Zが我が家にやってきました。

    実は私、筋金入りのHonda党です。
    初めてHonda車を購入したのは1984年のPRELUDE XZ。それ以来、INSPIRE、ODYSSEY、ELYSION、GRACE、CIVICと乗り継ぎ、今回のZR-Vはなんと7台目のホンダになります。

    購入年月日メーカー車種グレード年式型式タイプ
    1981年4月SUBARUR-2 Light VanK12VシルバーVan
    1982年8月ToyotaSprinter Coupe1200DXKE55オレンジCoupe
    1984年6月HondaPRELUDEXZ1984E-ABドミニカンレッドCoupe
    1990年4月HondaINSPIREAZ-i1990E-CB5ジュネーブグリーン・パールSedan
    1994年10月HondaODYSSEYB1994ER-A1セブリングシルバー・メタリックMini-Van
    2004年6月HondaELYSIONG2004DBA-RR1デザートミスト・メタリックMini-Van
    2014年12月HondaGRACEHYBRID EX 2014DAA-GM4ゴールドブラウン・メタリックSedan
    2018年1月HondaCIVIC SEDAN2018DBA-FC1コスミックブルー・メタリックSedan
    2025年7月HondaZR-Ve:HEV Z20256AA-RZ4スーパープラチナグレー・メタリックSUV

    40年以上にわたるカーライフを振り返ると、クーペ、セダン、ミニバン、そしてSUVと、その時々のライフスタイルに合わせて車を選んできました。しかし、気がつけばHonda車が中心。そう考えると、今回のZR-Vとの出会いにも少し特別な感慨があります。


    1年間、あえてECONモードだけで走ってみた

    ZR-Vには4つのドライブモードが用意されています。

    ・SPORTモード:レスポンスを重視したスポーティな走り
    ・NORMALモード:快適性と操作性のバランスを重視
    ・ECONモード:燃費性能を優先
    ・SNOWモード:雪道での安定性を重視

    購入当初から、「このクルマはどこまで燃費を伸ばせるのか?」という興味がありました。

    そこで納車から約1年間、ほぼ徹底してECONモードで走行。もちろんスポーティな走りを楽しみたい気持ちもありましたが、その誘惑をぐっと我慢しながらデータを蓄積してきました。

    その結果を燃費トレンドグラフにまとめました。

    X軸:日付
    Y軸:燃費

    :日々燃費(車両の示す燃費)
    :日々燃費の30ポイント移動平均(車両の示す燃費)
    :月々平均燃費(車両の示す燃費)
    :給油時実燃費(満タン法)

    WLTC郊外/WLTC/WLTC市街地:カタログ燃費


    日々の燃費は驚くほど変動する

    グラフを見ると、まず目につくのが日々燃費の大きなばらつきです。

    同じ通勤ルートを走っていても、

    • 交通量
    • 天候
    • 路面状況
    • バッテリー残量

    といった条件によって燃費は大きく変化します。

    特に雨の日は路面抵抗が増えるため燃費が悪化しやすく、また、ハイブリッド車ならではのバッテリー状態も影響しているようです。

    日々のデータだけでは傾向が見えにくいため、30ポイント移動平均で平滑化したデータを見ると、季節による変化がはっきりと浮かび上がってきます。


    ZR-Vの燃費が最も苦手なのは冬だった

    カタログ上のWLTCモード燃費22.0km/Lを基準に見ていくと、最も燃費が落ち込むのは11月から3月にかけての寒い季節です。

    特に1月には平均燃費が18km/L前後まで低下しました。

    冬場はエアコンを停止していても暖房を使用するため、室内を温める目的でエンジンが始動する機会が増えます。

    ZR-Vにはシートヒーターやステアリングヒーターが装備されているため、できるだけ暖房の使用を控えていました。しかし、それでも冬場の燃費低下は避けられません。

    改めてデータを見ると、ハイブリッド車にとって寒さは大敵だということがよく分かります。


    ベストシーズンは春から初夏

    一方で燃費が最も伸びたのは、4月から7月、そして9月から10月にかけての過ごしやすい季節でした。

    特に7月上旬には、30ポイント移動平均で27km/Lに迫る勢いを記録しています。

    この時期は、

    • 暖房を使わない
    • エンジン暖機の必要が少ない
    • バッテリー効率が良い

    といった好条件が重なります。

    e:HEVシステムの実力が最も発揮される季節と言えるかもしれません。


    真夏のエアコン使用は意外と影響が少ない?

    「エアコンを使う夏は燃費が大幅に悪化する」と思われがちですが、実際のデータを見る限り、その影響は意外と限定的でした。

    確かに8月から9月にかけて燃費はやや落ち込みます。

    しかし冬場の低下幅と比較すると、その差は小さいものです。

    個人的には、

    『ハイブリッド車は夏よりも冬の方が燃費への影響が大きい』

    という点が、この1年間で得られた最も興味深い発見でした。


    実燃費はカタログ値のどれくらいなのか?

    燃費記録だけでなく、給油のたびに満タン法による実燃費も計測しています。

    その結果、実燃費は車両が表示する燃費値よりも、

    約0.5~2.5km/L程度低い

    傾向がありました。

    割合にすると約2.5~13%程度低い数値になります。

    ちなみに2026年7月15日時点では、

    • 積算燃費表示:22.4km/L
    • 満タン法実燃費:20.9km/L

    となり、差は約1.5km/Lでした。

    率にするとおよそ7%。

    多くの車で車載表示の方がやや高めに出ることを考えると、比較的実態に近い優秀な結果ではないかと思います。


    次はNORMALモードで検証してみたい

    こうして1年間、燃費最優先のECONモードで走り続けてきました。

    しかし、ZR-V本来の持ち味である快適な走りや自然なレスポンスも試してみたくなりました。

    そこで今後はしばらくNORMALモードをメインに使用し、その燃費変化を追跡してみる予定です。

    果たして、

    • ECONモードは本当に燃費に有利なのか?
    • NORMALモードとの差はどの程度あるのか?
    • 体感上の走りの違いは燃費差に見合うのか?

    次回は、そんな「ECONモード vs NORMALモード」の比較結果をご紹介したいと思います。

    1年間蓄積したデータをもとに、ZR-Vオーナーの皆さんの参考になる検証ができれば幸いです。

    投稿日:

    更新日:

  • WordPressサブディレクトリ運用時のトラブルと解決方法

    -ChatGTPの助けを借りて-


    自宅サーバー立ち上げで立ち上げたはずのサーバーがうまく動作しない。具体的には、WordPressインストールディレクトリを公開URLに表示させないようにしたところ、ディレクトリは公開されない設定には成功した。しかし、wordpressの標準でついてるブロックエディタ(Gutenberg)で編集した投稿内容が保存ができない。保存ボタンを押すと保存中のまま進行しない。

    という状況に陥ってしまいました。いくらやっても解決しないので、困ったときのChatGTPだのみです。ChatGPT(GPT-5.5)に調査を依頼し、一緒に原因を一つずつ切り分けていくことにしました。

    数時間にわたり、WordPress・Apache2の設定について順番に確認した結果、原因は、幾つかの設定ミスであったことが判りました。

    同じ症状で困っている方の参考になればと思い、ChatGTPと一緒に解決した方法をまとめました。

    構成

    • OS:Ubuntu 24
    • Webサーバー:Apache2
    • WordPress本体:/var/www/html/****
    • 公開URL:https://kagaku.info
    • WordPressアドレス:https://kagaku.info/****
    • サイトアドレス:https://kagaku.info

    発生した問題

    WordPressのインストールディレクトリを公開URLに表示しない設定後、次の現象が発生しました。

    • ブロックエディタ(Gutenberg)で保存すると「保存中」のまま終了しない
    • https://kagaku.info/wp-json/Not Found
    • パーマリンクを「基本」以外に設定すると記事が Not Found になる

    原因

    1. Apacheの mod_rewrite が無効だったため、WordPressのリライトルールが機能していなかった。
    2. 000-default.confwordpress.conf の2つのVirtualHostが同時に有効になっており、DocumentRoot が競合していた。
    3. 000-default.confAllowOverride All の設定がなく、.htaccess のリライトルールが適用されていなかった。

    解決方法

    1. mod_rewrite を有効化

    sudo a2enmod rewrite
    sudo systemctl restart apache2
    

    2. 000-default.conf を修正

    DocumentRoot/var/www/html とし、次の設定を追加。

    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
    

    3. wordpress.conf を無効化

    sudo a2dissite wordpress.conf
    sudo systemctl reload apache2
    

    これにより、VirtualHostの競合を解消されました。

    動作確認

    以下を確認し、すべて正常に動作しました。

    • /wp-json/ がJSONを返す
    • パーマリンクが正常に表示される
    • ブロックエディタで保存できる
    • サイトが https://kagaku.info で正常に表示される

    現在の構成

    • 有効なVirtualHost:000-default.conf のみ
    • DocumentRoot/var/www/html
    • WordPress本体:/var/www/html/****
    • ルートの index.php から wordpress/wp-blog-header.php を読み込む構成

    今回のトラブルは複数の要因が重なっていましたが、ChatGTPの力を借りて、一つずつ切り分けて原因を特定できたため、根本的な解決に至りました。今後同様の構成を構築する際にも役立つ手順になると思います。

    投稿日:

    更新日:

  • 24時間血圧測定

    血圧計の測定値の違い」でご紹介したスマートウォッチ型の手首式ウェアラブル血圧計(HUAWEI WATCH D2)を用いて2025年10月から24時間血圧を測定しています。

    そもそも、なぜ24時間血圧の測定を始めたか?というと、「血圧計の測定値の違い」でも少し書きましたが、ここ何年もの間、健康診断で高血圧ぎみと出ていたのです。少し気になっていたのですが、2023年4月には職場の同期が肺がんで、2025年7月には職場の同僚が胃がんで亡くなり、本気で健康について考えるようになったのが大きなきっかけです。

    そこでまず、健康診断でいつも「血圧が高め」と出ていたので、まずは血圧から測定することにしました。

    ちなみに父は高血圧、弓部大動脈解離等を患い、ワーファリンを服用していましたが脳溢血で2007年に、母は父が他界する前から脳卒中で入院し、父の他界後、後を追うように2010年に亡くなっています
    いずれも血管に関する病を患っての他界なので、私も血管やそれに由来する血圧が気になっていたところではあります。

    当初は「血圧の測定値」でご紹介した上腕式血圧計(OMRON HCR-7206T2)で測定していたのですが、どうも血圧がいつも高い。収縮期血圧が140mmHg を超えていて、拡張期血圧は90mmHgを超えている。
    本当に一日中高いのかしら?
    でスマートウォッチ型の手首式ウェアラブル血圧計(HUAWEI WATCH D2)を購入し、24時間血圧を測ることにしたのです。

    そこでその24時間の血圧グラフを下に示します。

    HUAWEI WATCH D2で測定した2025年10月~2026年6月の一日の血圧の変化

    このグラフは2025年10月から2026年6月までの9か月間の24時間の血圧の変化を月毎に平均化したグラフです。平均化の方法の細かい説明は避けますが、一か月の血圧の時刻変化全体を時刻でソートして30ポイントの隣接平均を取ったものです。従って、ほぼその月の一日の時間変化をあらわしていると考えてよいと思います。

    ・X軸:時刻(0時から24時)
    ・左Y軸:血圧(mmHg)、
    ・右Y軸:心拍数(bps)

    グラフ
    ・上部が収縮期血圧(mmHg)
    ・中部が拡張期血圧(mmHg)
    ・下部が心拍数(bpm)

    で、太線赤で示しているのが、生活習慣改善直後の10月、黒太線が最近6月の一日の血圧の変化のトレンドになります。
    比べると一目瞭然です!!
    どの時刻でも収縮期血圧で10mmHgほど、拡張期血圧で5mmHgほど下がっているのが判ります。

    さて、このグラフの時系列を追ってみます。
    ・ 3:30~ 4:30 起床(起床後血圧が上がり始めます)
    ・ 4:30~ 6:30 朝食、支度
    ・ 6:30~ 7:30 出勤(自家用車)
    ・ 7:30~12:00 仕事(血圧はほぼピークです)
    ・12:00~13:00 昼休み(昼食後、5.5㎞のウオーキング:6㎞/h)
    ・13:00~17:00 仕事(ウォーキングのおかげか血圧は午前中より若干低い)
    ・17:00~18:00 退勤(自家用車)
    ・18:00~18:30 入浴(帰宅後は血圧は下がります)
    ・18:30~20:30 夕食、その他
    ・20:30~21:30 就寝(就寝後は血圧が一段下がります)

    このトレンドを見ると、職場にいる時間帯は総じて血圧が高い!!午後血圧が下がるのは昼休みのウォーキングによるものと思われます。12:00~13:00の心拍数が急激に上がっているのはそのためです。また、19時頃にも心拍の上昇がみられますが、これは入浴によるものだと思われます。

    9か月の生活改善で血圧も改善されてきたようです。
    ではどのような生活改善をしてきたのでしょうか?

    ~2025/9:過去数年間
    飲酒:ほぼ毎日(日本酒、焼酎、ウィスキー等、量にして日本酒2合相当
    筋トレ:週末2時間約1000kcal
    2025/10
    飲酒:週1日の休刊日(日本酒、焼酎、ウィスキー等、量にして日本酒2合相当
    筋トレ:毎週土曜 2時間 約1000kcal
    ウォーキング:平日昼 5.5㎞(6.0km/h)
    2025/11~現在
    飲酒:週末1日のみ(日本酒、焼酎、ウィスキー等、量にして日本酒1合相当
    筋トレ:毎週土曜 2時間 約1000kcal
    ウォーキング:平日昼 5.5㎞(6.0km/h)

    こうやって見ると飲酒は血圧上昇の大きな要因のような気がします。
    10月には週1日の休刊日とウォーキングで少しは改善したと思うが、11月からは飲酒を週1日にし、飲酒量も基本的に一回一合に抑えている。これが大きいような気がします。
    もちろん、毎日のウォーキングの効果も少なからず影響していると思うのですが・・

    をっと、もう一つあった!
    コーヒーの飲む量を減らしたことだ。特に平日職場では5~6杯飲んでいたのを2杯に削減し、飲みたくなったら白湯にしている。これも関係あるかな?

    飲酒量を減らした影響は血圧が下がった以外にもあって、それは、酔いやすくなった気がすること…

    お医者さんで、この血圧のトレンドや生活習慣の改善について御意見があれば、御寄せくださると嬉しいです。
    今後の参考にさせていただきます。

    投稿日:

    更新日:

  • 自宅サーバー立ち上げ

    「科学のつまみ食い」のサーバーの歴史

    本自宅サーバを再構築しましたので、その経緯についてちょっと書いておきます。
    「科学のつまみ食い」について」に本ホームページの歴史について記載してありますが、時系列のみ繰り返すと、以下の表のような変遷をたどってきました。

    1999年5月外部サーバー(nifty)にて「科学のつまみ食い」を開始
    2002年7月独自ドメインkagaku.infoを取得
    2002年8月自宅サーバー構築:DELL Latitude XP / VineLinux / HTMLエディタ
    外部サーバーから自宅サーバーに移行
    本ドメイン https://kagaku.info/で運用開始 
    2005年7月自宅サーバー入替:同機種/VineLinux/ HomePageBuilder+SiteMan
    2014年9月自宅サーバー入替:Loox P70XN / Vine Linux6.3 / WordPress
    リニューアル移設
    2017年5月自宅サーバー入替:Let’sNote CF-S8 / Vine Linux6.5 / WordPress
    2026年7月自宅サーバー入替:HP ProBook 430 G3 / ubuntu 24 / WordPress
    リニューアル移設

    ここでは今回 2026年の最新の自宅サーバーの入れ替えについて書きとどめておきます。

    もともとWindows11で運用していたHP ProBook 430 G3ですがWindows11ではかなり重くなってきたので、「科学のつまみ食い」で運用することとしました。これまでサーバーとして運用してきたLet’sNote CF-S8 とスペックを比較すると以下のようになります。

    項目Let’s note CF-S8HP ProBook 430 G3
    発売時期2009年2015年
    CPUCore 2 Duo P8700 2.53GHz
    (2コア)
    Core i3-6100U 2.3GHz
    (最大2.8GHz、2コア4スレッド)
    世代差Core 2世代 第6世代 Skylake
    メモリ4GB DDR28GB DDR3L
    ストレージHDDSSD
    画面サイズ12.1インチ WXGA 13.3インチ HD
    解像度1280×800 1366×768
    グラフィックスIntel GM45内蔵GPU Intel HD Graphics 520

    という感じで大幅にスペックアップしています。まぁ、HP ProBook 430 G3も10年前の機種なので最近の機種から見ると劣りますが、サーバーとして使うのには十分だと思ってます。



    サーバー構築

    ということで、ここからサーバー構築のメモです。

    ubuntuのインストール

    まず、準備したHP ProBook 430 G3にubuntuのインストールです。

    Ubuntuを入手する | Ubuntu | Ubuntu から最新版のUbuntuを ダウンロードし、起動メディアをUSB等で作成してインストールします。
    参考になるホームページがネットにあふれているので問題ないと思います。

    ユーザーやルートの設定など一通りします。


    リモートデスクトップ(RDT)

    次に、いちいちノートPCのHP ProBook 430 G3を広げてubuntu等サーバーのメンテをするのは面倒なので、通常のPCからリモートデスクトップ(RDT)で接続できるようにします。以下のホームページが参考になります。

    Ubuntu 24.04 LTSで新しい標準RDP接続を試してみる – treedown’s Report
    第819回 Ubuntu 24.04 LTSのリモートデスクトップを深掘りする | gihyo.jp

    RDTでubuntuサーバーに接続してみると、画面サイズが接続元の画面サイズまで大きくならない。最大でもHP ProBook 430 G3のスペックの1366×768 です。これは寂しい。デスクトップPCでは4Kディスプレイを使用しているので、そこまで画面を広げたい。ということで、以下のホームページを参考にして設定しました。

    Hyper-VでUbuntuを動かす際の解像度設定 #ubuntu20.04 – Qiita
    Hyper-Vで動いているUbuntuの解像度設定|たらかた


    サスペンドさせたくない

    さて、RDTが可能になったら、ノートPCを開く必要はありません。そこで、ノートPCの蓋を閉じてもサスペンドしないようにします。こちらは、以下のホームページを参考にしました。

    【Ubuntu】蓋を閉じてもノートPCをスリープにしない方法 | 機械学習ナビ

    これでサーバーとしての運用準備は整いました。



    WordPress環境の構築

    では次にWordpress環境の構築です。

    WordPressは、投稿、ページ、コメント、カテゴリ、タグ、カスタムフィールド、ユーザー、その他のWordPress設定など、多くの情報をMySQL等のデータベースに保存し、そのデータベースでデータを保存、検索、取得、更新、削除などの操作をPHPからのSQLクエリを通じて実行し、Apache2等のWebサーバーソフトウェアを通してホームページとして公開します。

    従って、これら、WordPressMySQLPHPApache2等をインストールして設定する必要があります。ここでは、それらを含めて順に概要を説明していきます。

    主に以下のホームページを参考にしました。

    Ubuntu 22.04にWordPressをインストールして稼働させるための手順 #Ubuntu22.04 – Qiita
    Ubuntu 22.04 LTS に WordPress 7.4 をインストール #mariadb – Qiita
    【備忘録】Ubuntu22.04 で WordPress導入 – おりそ.doc
    Ubuntu で WordPress のインストール|金子邦彦研究室
    自宅サーバでWordPressを動かそう。インストール | じじぃの引出し

    探せばまだまだ出てきますので、各自わかりやすいのを参考にするのが良いと思います。


    Apache2のインストール

    まず、Apache2をインストールします。

    Apache2のインストール手順 #Ubuntu – Qiita


    PHPのインストール

    次にPHPをインストールします。

    【備忘録】Ubuntu22.04 で WordPress導入 – おりそ.doc

    次にphpの設定内容を確認するために以下のページを参考にphp.iniを編集しphpinfo.phpを作成します。

    php.ini完全ガイド|設定ファイルの場所から編集方法まで徹底解説 | ちょげぶろぐ
    PHP | php.iniファイルの作成と初期設定

    一応、このサーバーでは、以下のように設定しています。

    memory_limit = 128M    → memory_limit = 256M
    post_max_size = 8M    → post_max_size = 64M
    upload_max_filesize = 2M → upload_max_filesize = 32M
    allow_url_fopen = On    → allow_url_fopen = Off
                  → date.timezone = “Asia/Tokyo”


    MySQLのインストール

    ではデータベースの以下のホームページを参考に
    MySQLをインストールします。

    【備忘録】Ubuntu22.04 で WordPress導入 – おりそ.doc

    次に以下を参考に
    mysql_secure_installationコマンドを利用してMySQLの初期設定を行います。

    MySQL 8.0 インストール後に必ず設定する 3の項目 | りんか ネット

    初期設定が終わったら、以下を参考に
    WordPress用のデータベースとユーザーを作成します。

    Ubuntu 22.04にWordPressをインストールして稼働させるための手順 #Ubuntu22.04 – Qiita

    これで、MySQLのインストールと設定が終わりました。


    WordPressのインストール

    さて、ようやくWordPressのインストールです。
    WordPressのインストール方法は、冒頭に示した以下のホームページが参考になると思いますので再掲しておきます。。

    Ubuntu 22.04にWordPressをインストールして稼働させるための手順 #Ubuntu22.04 – Qiita
    Ubuntu 22.04 LTS に WordPress 7.4 をインストール #mariadb – Qiita
    【備忘録】Ubuntu22.04 で WordPress導入 – おりそ.doc
    Ubuntu で WordPress のインストール|金子邦彦研究室
    自宅サーバでWordPressを動かそう。インストール | じじぃの引出し

    ここでちょっと…
    WordPressをインストールしたディレクトリにはwww-dataというユーザー名とグループ名のディレクトリやファイルができます。で、これ何?って思って調べてみると以下の通りでした。

    www-data とは何か? – tech-hint

    で次に以下のホームページを参考にして
    WordPressの初期設定をします。

    【備忘録】Ubuntu22.04 で WordPress導入 – おりそ.doc

    これで一応、設定完了


    サブディレクトリをURLに表示しない

    WordPressをhtml/以下のサブディレクトリ(例えば、****)に設置すると、そのサブディレクトリ名がURL上に表示されます。例えば、この「科学のつまみ食い」だと https://kagaku.info/****/ 等と表示されてしまいます。これはちょっといただけないので、以下のホームページを参考に https://kagaku.info/ と表示させます。

    【WordPress】サブディレクトリをURLに表示しない方法

    さてこれで出来上がり!!

    参考になったでしょうか?

    で、実はここで問題が発生しました。
    ChatGTPの力を借りて、解決しました。
    解決方法は、WordPressサブディレクトリ運用時のトラブルと解決方法を参考にしてください。



    先人たちの多くの記録が今回のサーバー立ち上げに大変役に立ちました。ここで引用した多くのホームページを参考にさせていただきました。ありがとうございました。

    投稿日:

    更新日:

  • 血圧計の測定値の違い

    OMRON HCR-7206T2 vs. HUAWEI WATCH D2

    最初の投稿が「血圧計」というのもなんですが、昨年の健康診断で高血圧を疑われ、血圧計(OMRON HCR-7206T2)を購入しました。これは上腕式のいわゆる普通の家庭用血圧計です。これで、しばらく計測したところ、どうも血圧が高い。

    そこで、新たに24時間血圧の測定できるスマートウォッチ型の手首式ウェアラブル血圧計(HUAWEI WATCH D2)を購入しました。

    朝と晩は両方の血圧計で測定しています。
    HUAWEI WATCH D2は24時間自動計測しているので、これで朝5:30、夜20:30頃に測定(自動測定値)した直後にOMRON HCR-7206T2で測定し、更にHUAWEI WATCH D2で手動測定(手動測定値)をするという方法でほぼ同時刻の両方の血圧値を測定できます。

    これにより、HUAWEI WATCH D2OMRON HCR-7206T2の測定値の違いを概算できると考えています。

    ここでようやく科学らしくなってきた。
    その結果が下のグラフです。

    横軸(X軸)がOMRON HCR-7206T2で測定した血圧
    縦軸(Y軸)がHUAWEI WATCH D2で測定した血圧

    で、これらの線形近似が原点を通る傾き1の直線に載れば、HUAWEI WATCH D2OMRON HCR-7206T2の測定値が一致するということになります。

    ■がHUAWEI WATCH D2の自動測定値
    ―がその線形近似
    HUAWEI WATCH D2の手動測定値
    がその線形近似

    結果はそれぞれ
    傾き:0.937、切片:12.7
    傾き:0.930、切片:12.8
    となりました。

    これの意味するところは、
    OMRON HCR-7206T2(上腕式)に比べHUAWEI WATCH D2(手首式)は60mmHgの際には10mmHgほど、160mmHgの際には5mmHgほど高く血圧を表示するということです。

    これは、比較的良い結果ではないでしょうか?
    どちらが正しいということではなく、だいたい同じ結果が得られるが、手首式のほうが若干高く出る傾向にあるということだと思います。

    ちなみに、先のグラフの
    60~100mmHgの塊は拡張期血圧
    100mmHg~160mmHgの塊は収縮期血圧
    になります。
    後程、実際の血圧等についてはご報告しますが、
    拡張期80±10mmHg、収縮期130±30mmHg程度で若干高血圧ということでしょうか?

    投稿日:

    更新日: