元記事：Skillselion の英語ガイド「Home Assistant 向け Claude Code スキルの解説ガイド」（2026-10-27 更新）をもとに、日本の開発者向けに切り口を変えて書き直した記事です。数値と引用は 2026-10-30 に取り直しました。
開示：私たちは、Claude Code・Codex・Cursor 向けのスキルと MCP サーバーを実インストール数で並べるディレクトリ Skillselion を運営しています（Skillselion のスキル一覧）。リンク先のページは英語です。
最終確認日：2026-10-30
要約
Home Assistant 用の Claude Code スキルは、「Claude に何を任せるか」で選ぶと迷いません。自動化の作成やエンティティのリネームなど設定を書く作業には、home-assistant-best-practices（8,729 インストール）を常に先に読み込ませます。照明やファンをその場で動かすなら mcp-hass（3,095）、端末から設定やバックアップを触るなら hass-builder（1,567）、ESP32 の YAML なら esphome-config-helper（136）です。home-assistant-automation（4,945）はテンプレート集なので、たたき台として使い、現行の Home Assistant との差分を確認してから反映します。
インストール数は skills.sh レジストリの累計で、Skillselion の各掲載ページに表示されている値です。
やりたいこと別に、どのスキルを入れればいい？
先に結論の表です。右端の列は、各スキルの SKILL.md が「実行前にユーザーへ確認する」と明記している操作です。
| やりたいこと | 第一候補 | 併用するとよいもの | SKILL.md が確認を求める操作 |
|---|---|---|---|
| 新しい自動化・スクリプトを書く | home-assistant-best-practices | hass-builder（--dry-run で作成） |
ブラウザ経由で保存する前に変更内容を見せる |
| エンティティ ID や表示名を変える | home-assistant-best-practices（Step 0） | hass-builder（hab search related） |
Config Entry の data に ID を持つ統合は、バックアップの回答とリネームの了承を待つ |
| 照明・ファンを今すぐ操作、状態を見る | mcp-hass | なし | 記述なし |
| ダッシュボード・ヘルパー・バックアップの管理 | hass-builder | home-assistant-best-practices | 再起動、バックアップ復元・削除など |
| 朝のルーチンや外出モードの下書き | home-assistant-automation | home-assistant-best-practices でレビュー | 記述なし |
| ESP32 の YAML 作成とコンパイルエラー | esphome-config-helper | hass-builder（hab guide esphome） |
記述なし（書き込み前の自己チェックリスト6項目のみ。hass-builder 経由の upload / run は確認あり） |
| Core / OS のアップグレード | home-assistant-best-practices | なし | 毎回、影響を伝えて回答を待つ |
1本だけ選ぶなら home-assistant-best-practices です。ほかの4本が書いた YAML や、実行しようとする操作のレビュー役も兼ねられます。
「自動化を書く」スキル同士で、方針が逆になるのはなぜ？
home-assistant-automation は YAML のテンプレート集です。morning_routine や away_mode の自動化、movie_night のシーンなどが YAML で並び、Claude がそれを手本に YAML を書く前提の作りです。
一方 home-assistant-best-practices は、アンチパターン表で「Generating YAML snippets for automations/scripts/scenes」を挙げています。代わりに推奨するのは、Home Assistant の config API で自動化やスクリプトを作ることです。API に届かない環境では、UI エディタ（Edit in YAML モード）に貼る形で設定を渡すように指示しています。理由として、API 経由なら設定が検証され、手でファイルを編集したり再起動したりする必要がない点を挙げています。
表記の差も見えます。home-assistant-automation のテンプレートは platform: time や service: light.turn_on で書かれています。hass-builder の SKILL.md にある作成例は "triggers" と "trigger":"state"、アクションは "action":"light.turn_on" です。旧表記も現行版で動きますが、2つを混ぜて使うと、同じリポジトリの中で書き方がそろいません。
テンプレート集を入れるなら best-practices も一緒に入れて、出てきた YAML をレビューさせるのが安全な組み方です。
home-assistant-best-practices は具体的に何を止めてくれる？
home-assistant-best-practices は、Claude の出力を Home Assistant の現行仕様に合わせるためのルール集です。description の1行目で、Home Assistant に関するリクエストでは「Load first, before answering or exploring」と指定しています。
中心にある原則は「テンプレートより標準の仕組み」です。SKILL.md はテンプレートについて「fail silently at runtime」と書き、Jinja2 を使う前に標準のトリガー・条件・ヘルパーを探す手順を決めています。
-
Step 0（既存設定の変更）：エンティティ ID や表示名の変更、テンプレートセンサーからヘルパーへの置き換えなどでは、先に safe-refactoring の参照ファイルを読みます。UI で作ったグループは、レジストリでリネームしても
options.entitiesが古いままになる、という落とし穴も表に載っています。 -
Step 1（トリガー）：2026.7 からは
motion.detectedやdoor.openedのような目的別トリガーが標準です。モーションセンサーにtrigger: stateを書く代わりに、target:でエンティティやエリアを指定します。 -
Step 2（ヘルパー）：合計・平均は
min_max、しきい値はthreshold、変化率はderivative、消費量はutility_meterに置き換えます。 -
Step 3（モード）：タイマー付きのモーションライトは
restart、ドアロックの順次処理はqueued、エンティティごとの独立処理はparallel、1回きりの通知はsingleです。 -
Step 4（ID）：
device_idではなくentity_idを使います。デバイスを追加し直すとdevice_idは壊れるためです。例外は Zigbee2MQTT の自動検出デバイストリガーです。
バージョン差にも気を配っています。「(2026.5+)」のようにリリース番号が付いた機能を使う前に、GET /api/config の version か UI の Settings → About でバージョンを読むよう指示しています。2026.8 より前は Developer Tools という名前だった画面を Tools と呼ぶなど、UI の名前の変化も追っています。
家を壊さないためのルールもはっきりしています。バックアップの復元・削除、Core や OS のアップグレードは「毎回」確認し、具体的な影響を伝えて回答を待つ決まりです。.storage/ 配下のファイルを直接編集することも、アンチパターンとして禁止しています。
SKILL.md の metadata は version "56" で、参照ファイルは15本、アンチパターン表は31行あります。参照ファイルはタスクに合うものだけを読む設計なので、全部を一度に読み込むことはありません。
- home-assistant-best-practices スキルの掲載ページ（8,729 インストール）
- GitHub：homeassistant-ai/skills リポジトリ（928 スター）
照明をその場で消したいだけなら mcp-hass で足りる？
足ります。mcp-hass は、Home Assistant 本体に組み込まれた MCP サーバーを mcporter 経由で呼ぶ手順を Claude に教えるスキルです。準備は2つだけです。
- Home Assistant の Settings > Devices & services で、統合の一覧から Model Context Protocol Server を追加する。SKILL.md は「Model Context Protocol」と書いていますが、その名前の統合は Home Assistant を MCP クライアントにする別物で、
/api/mcpを公開するのは Model Context Protocol Server のほうです。 -
HASS_BASE_URLとHASS_ACCESS_TOKENを環境変数に入れ、mcporterにサーバーを登録する。
npx -y mcporter config add home-assistant \
--transport http \
--url "${HASS_BASE_URL:-http://homeassistant.local:8123}/api/mcp" \
--header "Authorization=Bearer \${HASS_ACCESS_TOKEN}"
このあと Claude は GetLiveContext で現在の状態を読み、HassTurnOn・HassTurnOff・HassLightSet・HassFanSetSpeed といったインテントで機器を動かします。明るさとファンの速度は 0 から 100 のパーセントで指定します。使える引数は npx -y mcporter list home-assistant --schema --all-parameters で確認できます。
注意点は、SKILL.md に確認手順が書かれていないことです。HassTurnOff(area: "Bedroom", domain: ["light"]) のようにエリア単位の操作もそのまま呼べます。Claude Code の権限設定で npx -y mcporter call を自動許可にするかどうかは、操作対象を見てから決めるのがよいでしょう。プロトコル自体の仕組みは「MCP（Model Context Protocol）の解説記事」にまとめています。
- mcp-hass スキルの掲載ページ（3,095 インストール）
- GitHub：aahl/skills の mcp-hass ディレクトリ（164 スター、hass-builder と同じリポジトリ）
端末から設定を変えるなら、hass-builder の何が効く？
hass-builder は、Home Assistant Builder（hab）CLI の使い方を Claude に教えるスキルです。SKILL.md によると、この CLI は Home Assistant のメインメンテナーである Paulus 氏（@balloob）が作って公開しています。同梱の scripts/hab.sh が自動インストールを担うラッパーです。
効いてくるのは、変更前の5段階のゲートです。
- コマンドの guide と schema を読む。
- 読み取り専用の list / get で現在の状態を集める。
- 対応していれば
--planか--dry-runでプレビューする。 - プレビューを見せ、危険な操作は実行前にユーザーに聞く。
- 計画に含まれる検証コマンドか、追加の get / list で結果を確かめる。
確認が必要な操作も名前で列挙されています。system restart、バックアップの復元・削除、ネットワーク設定の適用、Thread データセットの変更、統合の有効化・無効化・リロード、ESPHome の upload / run / update / erase-flash、そして --force 付きの削除です。さらに「Do not add --force just to make a command non-interactive.」と書かれていて、確認を飛ばすための --force を禁じています。
出力は --json で受け、success・error.details.suggested_fix・verification_commands などのフィールドを見てから次へ進む決まりです。ESPHome の build や logs のようなストリーミング系コマンドは、最後に1つの JSON を返す代わりに NDJSON のイベントを流すことがある、と注意書きがあります。回答の冒頭で「読み取り専用・プレビューのみ・確認済みの変更」のどれなのかを宣言させる応答パターンも、運用上ありがたい部分です。
- hass-builder スキルの掲載ページ（1,567 インストール）
- GitHub：aahl/skills の hass-builder ディレクトリ
テンプレート集の home-assistant-automation は、どう使えば安全？
home-assistant-automation は、照明・空調・メディアの操作例、自動化テンプレート、シーン、音声インテント、電力監視とセキュリティの例を1枚にまとめたスキルです。インストール数は 4,945 で、掲載ページ上の最終更新は 2026年1月31日です。frontmatter の models には claude-3-opus・claude-3-sonnet・gpt-4 が並んでいます。
そのまま貼る前に確認したい点が2つあります。
1つめは色温度です。照明の例は color_temp: 350、movie_night シーンは color_temp: 500 です。home-assistant-best-practices は、mireds 単位の color_temp が 2026.3 で削除されたと書いています。さらに color_temp_kelvin は正の数なら何でも受け付けるので、mireds の値をそのまま移すと「500 mireds が 500 K として読まれる」と警告しています。換算式は Kelvin = 1,000,000 ÷ mireds なので、350 なら約 2,857 K です。
2つめは MCP の前提です。frontmatter は homeassistant-mcp というサーバーと、ha_service_call・ha_state_get などのツール名を挙げています。mcp-hass が使う Home Assistant 標準の MCP は HassTurnOn などのインテント名なので、手元のサーバーがどちらなのかを先に確かめてください。
おすすめの使い方は、朝のルーチンや外出モードの「何を自動化するか」のアイデア出しに使い、書き出しは best-practices に任せることです。
- home-assistant-automation スキルの掲載ページ（4,945 インストール）
- GitHub：claude-office-skills/skills の home-assistant ディレクトリ（550 スター）
ESP32 の YAML は esphome-config-helper と hass-builder のどちらに任せる？
YAML を書く段階は esphome-config-helper、Home Assistant 経由で書き込む段階は hass-builder、と分けるのがわかりやすいです。
esphome-config-helper には、templates/ 配下に4種類の雛形があります。最小構成の basic-device.yaml、DHT22 を GPIO4 につなぐ sensor-node.yaml、4チャンネルのリレー（GPIO23・22・21・19）を扱う relay-switch.yaml、SSD1306 の OLED を使う display-node.yaml です。「GPIO already in use」や「Could not compile」など6種類のエラーメッセージには、早見表で対処が載っています。検証は scripts/validate-config.sh が esphome config と esphome compile を順に実行する流れです。
書き込み前のチェックリストは6項目で、secrets.yaml での Wi-Fi 認証情報の管理、OTA パスワード、API 暗号化キー（2026.1.0 以降）などが含まれます。
1つ気をつけたいのが GPIO の一覧です。ESP32 の「Quick Safe Pins」に GPIO5 と GPIO12 が入っている一方で、「Avoid (strapping/boot pins)」にも同じ GPIO5 と GPIO12 が「use with caution」付きで載っています。ストラッピングピンを使う配線では、Claude の提案をそのまま採らず、references/gpio-pinouts.md まで読ませて確認したほうが安心です。
frontmatter の allowed-tools は Read・Write・Edit・Grep・Glob・WebFetch で、Bash は含まれていません。esphome compile を走らせる場面では、通常の権限確認が出る前提で考えておくとよいでしょう。ESP32-S3-BOX-3 を使う場合は、同じリポジトリの esphome-box3-builder スキルに任せるよう SKILL.md 自身が案内しています。
hass-builder 側は hab guide esphome と hab schema esphome validate --json から入り、ESPHome の upload・run・update・erase-flash はユーザーの明示的な確認を待ちます。
- esphome-config-helper スキルの掲載ページ（136 インストール）
- GitHub：nodnarbnitram/claude-code-extensions の esphome-config-helper ディレクトリ（16 スター）
組み合わせて入れるなら、どの構成がいい？
目的ごとに2本ずつ選ぶ構成が扱いやすいです。
| 目的 | 組み合わせ |
|---|---|
| 自動化やダッシュボードを Claude に作らせたい | home-assistant-best-practices + hass-builder |
| チャットから家電を動かしたい | home-assistant-best-practices + mcp-hass |
| 自作の ESP32 デバイスを増やしたい | esphome-config-helper + hass-builder |
インストールは各スキルの掲載ページにあるコマンドと同じです。
npx skills add https://github.com/homeassistant-ai/skills --skill home-assistant-best-practices
npx skills add https://github.com/aahl/skills --skill hass-builder
npx skills add https://github.com/aahl/skills --skill mcp-hass
npx skills add https://github.com/nodnarbnitram/claude-code-extensions --skill esphome-config-helper
npx skills add https://github.com/claude-office-skills/skills --skill home-assistant-automation
Home Assistant 以外のワークフロー自動化も探すなら、「自動化向けスキルのおすすめランキング」と「オートメーション カテゴリのスキル一覧」が入口になります。
よくある質問
Home Assistant の MCP サーバーと mcp-hass は何が違う？
MCP サーバーは Home Assistant 本体の Model Context Protocol Server 統合で、/api/mcp で待ち受けます。mcp-hass は、そのサーバーを mcporter で登録して呼び出す手順を Claude に教えるスキルです。サーバー側を有効にしていないと、mcp-hass だけ入れても動きません。
1本だけ入れるならどれ？
home-assistant-best-practices です。インストール数が 8,729 で5本の中で最も多く、Core や OS のアップグレード、バックアップの復元・削除のような取り返しのつかない操作では、毎回影響を伝えて回答を待つよう決めています。「home-assistant-best-practices のインストール手順ページ」に、インストールコマンドと参照ファイルの一覧があります。
既存の自動化を Claude に直させても大丈夫？
best-practices を入れていれば、リネームや構成変更の前に Step 0 の影響調査を行うよう Claude に指示されます。Config Entry の data にエンティティ ID を持つ統合（SKILL.md の例は Better Thermostat）が絡む場合は、バックアップを提案し、その回答とリネームの了承を待ってから進む決まりです。それでも、.storage/ を直接書き換える提案が出たら止めてください。SKILL.md 自身がそれをアンチパターンとしています。
数値は Skillselion のライブカタログ（skills.sh・GitHub・MCP レジストリから毎日更新し、実インストール数で順位付け）から 2026-10-30 に取得しました。英語の元記事は「Home Assistant スキルの英語版ガイド」です。Skillselion は Anthropic・OpenAI・Cursor とは提携していない独立したディレクトリです。