Home Assistant OS 18.0でカーネル6.18へ｜スマートホームを支えるLinux基盤の中身

2025年後半から2026年にかけて、Home Assistant OS（以下 HAOS）はメジャーバージョンアップを重ね、18.0ではLinuxカーネルを6.18系に引き上げることが明らかになりました。家庭や小規模オフィスの自動化基盤として広く使われるHAOSですが、そのベースとなるLinuxカーネルのバージョンが変わると、ハードウェアサポートや通信スタック、電力管理など多岐にわたる動作が変化します。本記事では、HAOSとLinux基盤の関係を整理したうえで、カーネル6.18への移行が現場にもたらす意味を具体的に見ていきます。

Home Assistant OS の役割とカーネル更新の背景

HAOSは、Home Assistantをもっとも手軽に運用するための専用Linuxディストリビューションです。Raspberry PiやOdroid、Intel NUC、あるいはVM環境など多様なプラットフォームで動作し、アドオン管理からバックアップ、ネットワーク設定まで、Linuxの知識をほとんど必要とせずに利用できる設計になっています。

その裏側では、Buildroot ベースの軽量 Linux がカーネルとシステムコンポーネントを提供しています。HAOSのカーネルは、アップストリームのmainlineカーネルを比較的追いかける方針をとっており、これが一般的な組み込みディストリよりも新しいカーネルを早期に採用できる理由のひとつです。バージョン18.0でのカーネル6.18採用は、この方針の延長線上にあります。

カーネル更新の直接的な動機は複数あります。USB接続のZigbeeアダプタやZ-Waveドングルのドライバ対応を最新化すること、Raspberry Pi 5など新世代SBCのサポートを強化すること、そしてセキュリティパッチの継続適用という三点が主な柱とされています。

Linux カーネル 6.18 の主な技術的変更点

カーネル 6.18 は 6.x 系の中でも比較的変更量の多いリリースです。スマートホーム運用に関係する範囲で整理すると、以下の領域に注目できます。

まず USB サブシステムの改善があります。USB ハブ経由での電力制御が細かく扱えるようになり、複数のドングルを同一ハブに集約している環境での安定性が向上しています。Zigbee や Z-Wave アダプタを USB で接続するケースが多いHAOS環境にとって、これは実運用上の意味が大きい変化です。

次に、Bluetooth スタック（BlueZ との連携部分）の更新があります。BLE（Bluetooth Low Energy）デバイスの接続管理が改善され、温度センサーや人感センサーなどのパッシブスキャンが従来より確実に動作するようになっています。HAOSのBluetoothインテグレーションは内部的にこのカーネル Bluetooth スタックに依存しているため、間接的な恩恵があります。

電力管理の面では、ARMプラットフォーム向けの cpufreq ドライバが整備され、Raspberry Pi 5を含む最近の ARM SoC でのアイドル時消費電力が抑制されています。24時間稼働が前提のスマートホームサーバーにとって、消費電力の削減はランニングコストに直結します。

また、ネットワーク周りでは、スケジューラと TCP スタックの細かいチューニングが入っており、ローカルネットワーク内での通信レイテンシが微減しています。数十台のデバイスをポーリングするHAOSのような用途では、こうした積み重ねが応答性の改善として体感されることがあります。

スマートホーム運用で体感できる変化

カーネルの変更が直接ユーザー体験に現れる場面をいくつか挙げます。

USB ドングルの認識安定性は、HAOSを長期運用する環境でもっとも頻繁に問題となるポイントのひとつです。これまで「再起動後に Zigbee コーディネーターが認識されない」「Z-Wave ドングルがたまに切断される」といった事象を経験した運用者は、カーネル6.18以降では同様の問題が減少したという報告が出ています。根本的な解決かどうかはハードウェアとドライバの組み合わせによりますが、改善傾向は確認されています。

Raspberry Pi 5 上での動作もより安定しています。Pi 5 は RP1 チップセットを通じてUSBやGPIOを管理する新しいアーキテクチャを採用しており、カーネルのサポートが成熟するほど周辺デバイスの互換性が向上します。HAOS 18.0 と カーネル 6.18 の組み合わせは、Pi 5 を HAOSの主力ハードウェアとして使う環境での信頼性を一段高めたと評価されています。

一方、VM 環境（Proxmox や VMware 上で HAOS を動かしているケース）では、カーネル更新による体感差は小さい傾向があります。仮想化レイヤーがハードウェアを抽象化しているため、USB や GPIO 周りのカーネル改善は直接反映されにくいためです。VM 環境でのメリットは主にセキュリティパッチの適用と、ネットワークスタックの細かい改善に限られます。

更新前後の確認事項と注意点

HAOS の更新は通常、設定画面の「コア」セクションから1クリックで実行できますが、カーネルが変わるメジャーアップデートの前後には以下の点を確認しておくことを勧めます。

• バックアップの取得：HAOS の「バックアップ」機能でフルバックアップを作成し、更新前の状態を保存しておく。
• カスタムドライバの確認：コミュニティが提供する非公式ドライバや、HASSio のアドオンとして動作している USB デバイス向けカスタムモジュールがある場合、カーネルバージョン変更で互換性が切れる可能性がある。
• デバイスパスの固定：USB デバイスは /dev/ttyUSBx のような動的パスではなく、/dev/serial/by-id/ 配下の固定シンボリックリンクで指定しておくと、カーネル更新後もパスが変わらず安定する。
• 更新後のログ確認：更新直後はシステムログ（ログビューア、またはSSH経由で journalctl）を確認し、デバイス認識エラーや警告が出ていないかチェックする。

切り戻しが必要になった場合、HAOSには公式のバージョン固定（特定バージョンへのダウングレード）機能はないため、バックアップからの復元が実質的な唯一の手段です。カーネル更新を伴うメジャーバージョンアップの前にバックアップを取る習慣は、スマートホーム運用の基本として定着させておくべきです。

2026年現行環境における HAOS の位置づけ

2026年時点で、Home Assistant を運用する方法は大きく三つに分かれています。HAOS（専用OS）、Docker/Compose によるコンテナ運用、そして Supervised インストール（既存Linux上に管理レイヤーを乗せる方式）です。このうち公式が最も推奨し、長期的なサポートを明示しているのは HAOS です。

カーネルの継続的な更新という観点でも、HAOSはコミュニティとメンテナが集中してテストを行うため、新しいハードウェアへの対応が他の運用方式より早い傾向があります。逆に言えば、DockerやSupervised環境でホストOSのカーネルを自分で管理している運用者は、HAOSのカーネル更新に追随するためには自分でホストOSを更新する必要があり、これはある程度のLinux運用知識を前提とします。

カーネル 6.18 という数字は、2026年の時点ではまだ最新LTSカーネル（6.12系）よりも新しい非LTS系列です。HAOSがLTSではなく最新mainlineを追う方針をとることには理由があり、Raspberry PiなどのSBCドライバ改善が非LTSカーネルに先行して取り込まれるケースが多いためです。この判断はスマートホーム用途に特化したトレードオフとして理解できます。

一方、エンタープライズLinuxやサーバーOSの文脈では、非LTSカーネルを本番環境に採用することは避けられる傾向があります。HAOSがこの慣例に沿わない選択をしているのは、スマートホームデバイスの多様性と更新速度に対応するための意図的な設計です。運用者としては、この背景を理解したうえでバックアップ戦略と更新サイクルを決めると、トラブル時の判断がしやすくなります。

HAOS 18.0 とカーネル 6.18 の組み合わせは、スマートホームの信頼性基盤として一定の成熟を示すリリースです。技術的な変化の内容を理解したうえで更新を適用することで、予期しないトラブルを最小限に抑えながら、新しいハードウェアサポートと安定性の恩恵を受けられます。