Home AssistantでIoT機器を一元制御する方法｜設計と採用判断

小規模な IoT 案件や社内 PoC で、センサー・照明・空調・電力計といった機器を横断して扱おうとすると、機器ごとにアプリもクラウドも API も分かれているという現実に突き当たります。状態を一箇所に集めて条件で制御するだけの仕組みでも、機器の数だけコネクタを書き、認証方式の差を吸収し、状態の持ち方を決める必要が出てきます。統合レイヤーを自作するか、既存の OSS に乗るか。この判断を先に済ませないと、見積りも設計も動き出しません。

候補として挙がりやすいのが Home Assistant です。ただ、日本語で情報を探すと個人のスマートホーム DIY 手順、つまり「Raspberry Pi にインストールして手元の機器をつなぐまで」の記事が中心になります。そこで知りたいのは手順そのものではなく、内部がどういう構造で動いているのか、既存の業務システムから叩けるのか、プロジェクトとしてどれだけ手入れされているのか、といった技術判断の材料です。

そこで本記事では、公式ドキュメントと GitHub 上のメタデータから、Home Assistant Core の内部構造、インストール形態の選択軸、REST API による外部連携、カスタム integration による拡張手段、類似 OSS との差分、そしてメンテナンス健全性を順に整理します。読み終えたときに採用・不採用の判断ができる状態をゴールにしています。

なお本記事は、公式サイト・公式開発者ドキュメント・README・GitHub API から取得したメタデータに基づく整理です。動作検証やインストール検証は行っていません。数値はいずれも 2026 年 9 月 26 日時点の取得値です。

Home AssistantとはIoT機器をローカル制御するOSS

Home Assistant は、機器の状態取得・制御・自動化・ダッシュボードを 1 つのプロダクトで担うホームオートメーション基盤です。設計思想は README の冒頭 1 文に集約されています。

Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server.

（出典: home-assistant/core README）

重要なのは「local control first」という順序です。クラウドを経由して機器を操作するのではなく、ローカルネットワーク内のハブが機器を直接扱うことを前提に設計されています。インターネット接続が切れても自動化が動く、機器の状態が外部に出ないという性質は、そのまま業務用途での判断材料になります。

Home Assistant を検討するうえで最初に押さえておきたいのが、プロダクトが単一の成果物ではないという点です。公式のアーキテクチャドキュメントでは、ディストリビューションとしての階層が Operating System（Supervisor と Core を動かす最小の Linux 環境）、Supervisor、Core の 3 層で説明されています（出典: Architecture overview | Home Assistant Developer Docs）。本記事が扱う home-assistant/core リポジトリは、このうち Core に相当します。機器統合と自動化のロジック本体がここにあり、OS レイヤーやアドオン管理は別リポジトリで扱われています。

リポジトリの実測値は次のとおりです。

（出典: GitHub API /repos/home-assistant/core、2026 年 9 月 26 日取得）

アーカイブされておらず、他リポジトリのフォークでもない本家リポジトリであり、ライセンスは Apache-2.0 が明示されています。2013 年から開発が継続し、最終 push は前日という状態です。プロジェクトの生存確認という観点では、この時点で懸念材料はありません。

対応機器の広さについて、公式の integrations ページは「Home Assistant supports thousands of brands across more than a hundred categories」と記載しています（出典: Integrations | Home Assistant）。具体的な総数はページ上で確認できなかったため、本記事でも数値では断定しません。Light / Lock / Camera / Climate / Switch / Sensor といったカテゴリ単位で整理されており、機器分類ごとに扱い方が統一されている点が実装上の特徴です。プロダクト全体の入口は Home Assistant 公式サイト にまとまっています。

Home Assistant Coreのアーキテクチャと4つの構成要素

採用判断でいちばん効いてくるのは「機器が増えたときに何が起きるか」です。Home Assistant Core はこれをイベント駆動の共通基盤に押し込むことで解いています。

4つの構成要素と流れるイベント

公式開発者ドキュメントは、Core を 4 つの主要パーツで説明しています。

（出典: Home Assistant Core | Home Assistant Developer Docs）

この 4 つの上に、よくあるシナリオを扱うためのヘルパークラス群が載り、さらにその上に個々の機器を扱う integration が載ります。integration は hass オブジェクトを通じて状態の読み書きとサービス呼び出しを行うため、機器固有のコードが触る面は「状態を State Machine に置く」「サービスを Service Registry に登録する」の 2 点に収束します。

自作の統合レイヤーと比べたときの差はここに出ます。機器を 1 種類追加するために設計しなければならないのは、状態のスキーマ・イベントの伝搬経路・自動化のトリガー定義・UI への反映といった一式ですが、Home Assistant ではその共通部分が既製で、追加分は機器との通信と状態のマッピングに限定されます。逆に言えば、この共通基盤の設計と自社要件が合わない場合、乗ることのメリットはほとんど残りません。

device / entity / area レジストリの役割分担

もう 1 つ押さえておきたいのがレジストリの構造です。Home Assistant は物理デバイスと制御単位を分離して管理します。

• Device Registry: 物理デバイスとその制御ユニットを追跡します。公式ドキュメントは「A device is represented in Home Assistant via one or more entities」と記述しており、1 つのデバイスが複数のエンティティで表現されます
• Entity: 個々の状態・制御の単位です。1 つのセンサーデバイスが温度・湿度・バッテリー残量を公開する場合、それぞれが別エンティティになります。識別は unique_id で行います
• Area: デバイスやエンティティの物理的な場所です。integration 側は device_info の suggested_area で示し、割り当ては area_id で管理されます

（出典: Device Registry | Home Assistant Developer Docs）

デバイスの識別は (DOMAIN, identifier) のタプル、または接続情報で行われます。ここで実装上の注意になるのが、公式ドキュメントの「Identifiers and connections are unique per config entry rather than globally」という記述です。識別子はグローバルではなく config entry 単位でユニークであるため、同じ識別子が別の config entry から登録されると別デバイスとして扱われます。複数のアカウントや複数のゲートウェイを同時に登録する構成を想定する場合、この単位を理解しておかないと重複登録の原因になります。

「1 デバイス = 複数エンティティ」という分解は、業務システム側にデータを流すときの設計にも影響します。監視基盤に取り込む際の粒度はデバイスではなくエンティティになるため、メトリクス名の設計は unique_id を軸に考えることになります。

インストール形態の選び方（HA OSとContainer）

公式のインストールページでは、比較表として Home Assistant OS（HA OS）と Home Assistant Container の 2 方式が提示されています。

（出典: Installation | Home Assistant）

公式ページは「Home Assistant Operating System is the recommended installation type for most users」として HA OS を推奨しています。HA OS は組み込み向けの最小 Linux 環境で、シングルボードコンピュータや仮想マシン上で動作し、アプリ（Apps）による機能拡張とワンクリック更新に対応します。Thread や Z-Wave のようにアプリ側の仕組みに依存する機能も、この形態でサポートされます。

一方の Container は、Docker イメージとして動かす形態です。アプリに対応しないため、アプリ前提の機能（Thread・Z-Wave など）は対象外になり、ホスト OS の管理と更新は利用者の責任になります。公式ページもコマンドラインと Docker の経験がある利用者向けと位置づけています。

判断軸としては、次のように整理できます。

• HA OS を選ぶケース: 対象機器に Thread / Z-Wave が含まれる、専用機（ミニ PC・シングルボードコンピュータ・専用 VM）を割り当てられる、運用担当に Linux の常時管理を任せられない
• Container を選ぶケース: すでに Docker / Kubernetes の運用基盤があり構成管理をコードで一元化したい、他のコンテナと同じ監視・ログ・バックアップの仕組みに乗せたい、アプリ前提の機能を使わない構成で足りる

つまり「機器側のプロトコル要件」と「既存インフラ運用への合わせ込み」のどちらを優先するかが分かれ目です。なお、公式インストールページの比較表には Supervised 方式や Core（Python 仮想環境への直接インストール）方式は含まれていません。この 2 方式を前提にした情報を参照するときは、公式の比較表の範囲外であることを踏まえて扱う必要があります。

REST APIで外部システムとHome Assistantを連携する

既存の業務システムや監視基盤と接続できるかは、業務用途での採用可否に直結します。Home Assistant Core は REST API を公開しており、認証は Authorization: Bearer TOKEN ヘッダで行います。トークンは Web フロントエンドのプロフィールページで発行する Long-Lived Access Token を使います。

主要なエンドポイントは次のとおりです。

（出典: REST API | Home Assistant Developer Docs）

状態を取得する側の例として、公式ドキュメントには次の curl 例が掲載されています。

curl \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  http://localhost:8123/api/states/sensor.kitchen_temperature

（出典: REST API | Home Assistant Developer Docs）

制御する側、つまりサービスアクションを呼び出す例は次のとおりです。

curl \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"entity_id": "switch.christmas_lights"}' \
  http://localhost:8123/api/services/switch/turn_on

（出典: REST API | Home Assistant Developer Docs）

この 2 方向がそろっている点が実務上の要点です。/api/states 系で状態を引き出せるため、既存の監視基盤や社内ダッシュボードに機器の状態を取り込む構成が成立します。/api/services/<domain>/<service> で外部からアクションを呼べるため、業務システム側のイベントをトリガーに機器を操作する構成も成立します。さらに /api/events/<event_type> でイベント自体を投げられるため、Home Assistant 側の自動化を外部起点で駆動させる設計も取れます。

つまり Home Assistant を「機器との接続と状態管理を引き受けるレイヤー」として下に置き、業務ロジックは既存システムに残す構成が可能です。機器統合の資産だけを借りて自動化の主体は自社側に持つという切り分けは、採用の敷居を下げる現実的な選択肢になります。

一方で注意すべき点もあります。認証が長期有効なトークンのみである以上、トークンの保管と失効運用は利用側の設計事項です。API を業務システムから叩く構成を取る場合、トークンの配置場所・ローテーション方針・到達経路の制限（ネットワーク分離やリバースプロキシでの制御）を事前に決めておく必要があります。

カスタムintegrationで対応機器を増やす

採用を検討するときに気になるのが「対応していない機器が出てきたらどうするか」です。Home Assistant では、コアに同梱されていない integration をカスタム integration として追加できます。

配置先は設定ディレクトリ配下の custom_components で、コア同梱の integration は homeassistant/components に置かれます。カスタム integration は manifest ファイルに version キーを含めることが必須で、コア同梱では不要という違いがあります（出典: Integration Basics | Home Assistant Developer Docs）。

manifest.json の最小構成は次のとおりです。

{
  "domain": "hello_state",
  "name": "Hello, state!"
}

（出典: Integration Basics | Home Assistant Developer Docs）

セットアップ処理の最小例は次のとおりです。

from homeassistant.core import HomeAssistant
from homeassistant.helpers.typing import ConfigType

DOMAIN = "hello_state"

async def async_setup(hass: HomeAssistant, config: ConfigType) -> bool:
    hass.states.async_set("hello_state.world", "Paulus")
    return True

（出典: Integration Basics | Home Assistant Developer Docs）

ここで見えるのが、先ほど触れた「integration は hass を通じて状態を置くだけ」という構造です。hass.states.async_set で状態を登録し、セットアップの成否を bool で返すだけで、最小の integration が成立します。Python が書けるチームであれば、未対応機器への対応は「機器との通信処理を書き、その結果を状態として置く」という範囲の作業に収まります。

公式ドキュメントはさらに、スキャフォルド機能によって UI 経由のセットアップ（config flow）・テスト・国際化のインフラを含む構成を自動生成できることを示しています。最小実装から始めて、必要になった段階で設定 UI やテストを足していく段階的な拡張が想定された設計です。

採用判断としては、この拡張コストをどう見るかが分かれ目になります。対応機器が公式 integration でカバーされているなら追加実装は不要ですし、カバーされていなくても Python での拡張手段が明確に用意されている点は、行き止まりになりにくいという意味でプラスに評価できます。

類似OSSとの違い（openHAB・Homebridge・Domoticz・Node-RED）

ホームオートメーション基盤には他にも選択肢があります。以下は各リポジトリの実測メタデータです（いずれも 2026 年 9 月 26 日に GitHub API で取得）。

この表から読み取れる差分を、判断に使える形で整理します。

openHAB はスター数で比較しないこと。 openhab-core の 1,142 という数値は、プロジェクト全体の規模ではなくコアフレームワークのリポジトリ単体の数値です。openHAB はアドオンやディストリビューションを別リポジトリに分けたマルチリポジトリ構成であるため、単一リポジトリで完結する Home Assistant とスター数を並べても意味がありません（出典: openhab/openhab-core）。比較軸として有効なのは言語とライセンスです。JVM 運用の知見が社内にあるか、EPL-2.0 と Apache-2.0 のどちらが自社の配布・組み込み要件に合うかで判断します。

Homebridge は用途が異なります。 非 HomeKit 機器を Apple HomeKit に見せるための橋渡しに特化しており、自動化エンジンやダッシュボードを包含しません（出典: homebridge/homebridge）。要件が「iOS 側の標準アプリから機器を操作したい」で完結するなら軽量な選択になりますが、条件分岐を伴う自動化や独自 UI が必要なら役割が足りません。

Domoticz はライセンスが判断軸になります。 GPL-3.0 であるため、Apache-2.0 の Home Assistant とは配布・組み込み時の条件が異なります（出典: domoticz/domoticz）。自社製品に組み込んで再配布する構想がある場合、ここは先に確認すべき項目です。

Node-RED は競合ではなく併用対象です。 ホームオートメーション専用ではなくイベント駆動アプリ向けのローコードフロー基盤であり、担うのは自動化ロジックの層です（出典: node-red/node-red）。機器 integration の資産を持つわけではないため、Home Assistant で機器を束ね、複雑なフローを Node-RED で書くという組み合わせが成立します。

定性的な評価としては、Home Assistant は integration の数と UI の扱いやすさが強みで自動化定義は YAML 主体、openHAB は成熟度と安定性を重視し設定のカスタマイズ性が高い一方で学習コストが高い、という比較が二次情報では語られています（参考: WunderTech、openHAB Community）。これらは公式仕様ではなく第三者の評価であるため、判断の主軸には言語・ライセンス・スコープ・リポジトリ構成という上表の事実を置くことをおすすめします。

Home Assistantの採用判断チェックポイント

メンテナンス健全性とリリースサイクル

リリースの状況は次のとおりです。

（出典: GitHub API /repos/home-assistant/core/releases、2026 年 9 月 26 日取得）

YYYY.M.PATCH 形式のカレンダーバージョニングが使われ、月初にマイナーリリース、その後に週次ペースでパッチリリースが出る運用が見て取れます。リリース前にはベータ（2026.9.0b9 など）が複数公開されています。最終 push は 2026-09-25 で、リポジトリはアーカイブされていません。開発が止まったプロジェクトを引き受けるリスクは、この時点では見当たりません。

逆にこのペースは運用負荷として跳ね返ります。月次でマイナーバージョンが上がり、その間にパッチが入る前提であれば、更新の追随方針（どのタイミングで上げるか、破壊的変更をどう検知するか、更新前のバックアップをどう取るか）を運用設計に組み込む必要があります。ワンクリック更新に対応する HA OS を推奨形態としている背景もここにあります。

open issues は 3,624 件です。この数字は単体では評価できません。スター 91,148・フォーク 38,756 という規模、対応機器の広さ（公式表記で thousands of brands across more than a hundred categories）を踏まえれば、機器固有の不具合や要望が積み上がるのは構造的な帰結です。欠点と断定するより、「自社が使う予定の integration について個別に issue を確認する」という具体的な確認作業に落とし込むほうが判断に役立ちます。

運営体制についても確認できます。Home Assistant は Open Home Foundation が所有・運営するプロジェクトの 1 つで、同財団はプライバシー・選択肢・持続可能性を原則に掲げ、250 以上の OSS プロジェクトや標準・ドライバ・ライブラリを傘下に持ちます。資金源は Home Assistant Cloud のサブスクリプションおよび原則に沿った貢献で、商業パートナーの支援も受けています（出典: Open Home Foundation）。個人メンテナ 1 名に依存する体制ではなく、財団と有償クラウド事業で資金が回る構造である点は、長期利用を前提にする場合の安心材料になります。

向くケースと慎重に判断すべきケース

ここまでの材料を、採用判断の形に整理します。

向くケース

• 複数メーカーの機器を横断して状態取得・制御したいが、機器ごとのコネクタを自作する工数は割けない
• ローカル完結で動くことが要件になっている（ネットワーク分離環境、機器の状態を外部に出せない案件）
• Python での拡張が可能なチーム構成で、未対応機器が出た場合に自力で integration を書く余地がある
• Apache-2.0 の条件で問題がなく、既存の業務システムから REST API 経由で使う構成を取れる
• 専用機や仮想マシンを 1 台割り当てられる（HA OS 形態を選べる）

慎重に判断すべきケース

• 月次マイナー + パッチという更新ペースに追随する運用体制を組めない
• Docker 基盤に載せたいが対象機器に Thread / Z-Wave が含まれる（Container 形態では対象外となるため形態選択が競合する）
• 自社製品への組み込み・再配布を前提にしており、依存ライブラリまで含めたライセンス確認の工数を確保できない
• 要件が「iOS の標準アプリから操作するだけ」など限定的で、統合ハブの機能が過剰になる（Homebridge 等の軽量な選択肢のほうが合う）
• 使用予定の機器が公式 integration でカバーされておらず、拡張実装の工数を見積もれていない

判断を分けるのは、機能の豊富さよりも「更新への追随体制」と「インストール形態が自社インフラ方針と衝突しないか」の 2 点です。ここが通れば、機器統合レイヤーを自作する工数と比較したときの優位は大きくなります。

まとめ

home-assistant/core は、Python 実装・Apache-2.0 の統合ハブで、Event Bus / State Machine / Service Registry / Timer という 4 つの構成要素の上に integration が載る構造を取っています。この共通基盤があるため、機器を追加する作業は「通信処理を書いて状態を置く」範囲に収まります。

インストール形態は HA OS と Container の 2 方式が公式に比較されており、Thread / Z-Wave などアプリ前提の機能を使うなら HA OS、既存の Docker 基盤に合わせるなら Container という分岐になります。外部システムとの接続は REST API で双方向にでき、機器統合レイヤーだけを借りて業務ロジックは自社側に残す構成も取れます。

類似 OSS との差分は、言語・ライセンス・スコープ・リポジトリ構成という公式情報から確定できる軸で判断するのが確実です。openHAB はスター数の単純比較が成立せず、Homebridge は HomeKit 連携特化、Domoticz は GPL-3.0、Node-RED は併用対象という整理になります。

メンテナンス面では、月次マイナー + パッチのカレンダーバージョニングが回り、最終 push も直近、運営は Open Home Foundation という体制です。残る判断材料は自社側の条件、すなわち更新追随の運用体制と、使用予定の機器が公式 integration でカバーされているかの確認です。次のステップとしては、Integrations | Home Assistant で対象機器の対応状況を確認し、Installation | Home Assistant で自社インフラ方針に合う形態を選ぶところから始めると、検討が具体化します。

IoT 機器の統合レイヤーや既存システムとの連携について、要件整理の段階からご相談を承っています。自社案件に OSS を採用すべきかの判断を含めてご検討中の場合は、お問い合わせフォーム からお声がけください。