Google Homeに、
外部AIの入口ができた。

Google Homeを捨てずに、外部エージェントを「もう1つの操作窓口」としてつなげられるようになりました。

Googleは2026年9月16日付のリリースノートで、Home MCPの早期公開を案内しました。家の一覧、機器の構造、現在の状態、過去のイベント、機器への操作を、MCP対応クライアントから利用する仕組みです。接続先はGoogleが運営するリモートサーバーです。[1][3]

本ページはGoogleの発表日を基準に「9月16日号」としています。情報の確認日は2026年9月17日です。日本向けの開始日を示すものではありません。

同じ家に対して、音声とチャットという2つの入口が並ぶ、と考えると誤解しません。

例えば、「昨日の夕方、外で何が起きた？」という依頼は、エージェントが必要な履歴を取得し、自分の会話画面で説明する使い方です。スピーカーへの音声通知は発表時の利用例として紹介されていますが、これはスピーカーの常駐アシスタントを差し替えることとは別です。[17][18]

上表は構成を理解するための整理です。「MCP対応」だけで、どのクライアントでも同じ手順・同じ機能が保証されるわけではありません。公式に個別設定手順があるのはAntigravity、Claude Cowork、OpenClawです。[2][9][14]

Google自身が、Google Homeの実データと操作をMCPへ開いた点を評価すべきです。

既存のGoogle Home APIsには第三者アプリ向けの公式アクセスがあり、NestにもSDM APIがありました。さらにHome Assistantは2025年2月、Homeyは同年11月にMCP対応を公表しています。「これまでは非公式手段しかなかった」「今回、AIが初めて物理デバイスへ出た」という説明は広すぎます。[10][11][12][22]

比較の根拠：GoogleのMCP分類・Home APIs・Nest資料と、各製品の公式発表。[9][10][11][12][21][22][23]

「家を探す → 機器を知る → 状態・履歴を見る → 操作する」という分担です。

traitとは、機器の「できること・持っている状態」の単位です。例えばオン／オフなどを表します。機器の名前を見て「これは照明だから、この命令が通るはず」と決めつけるのではなく、返された機能と引数の定義を確認して呼び出す設計になっています。[5][8]

名前ではなくIDを使い、取得範囲と操作許可範囲を別々に管理します。

設計上の例 「庭のライトのID」と「照明の種類」を同時指定したとき、両方に一致する1台だけを期待してしまうかもしれません。しかし探索仕様が示す条件の結び方では、想定より広い候補が返る可能性があります。取得結果をそのまま一括操作の対象に流さず、許可したホームID・機器IDの集合と再照合します。

上記のOR条件は、確認したlist_home_resourcesの記述に基づきます。すべてのツールへ同じ検索仕様を推測で適用するのではなく、各スキーマと実応答を確認する必要があります。

APIには、低遅延を優先する読み方と、新しい情報を取りに行く読み方があります。

公式API仕様より。状態には時刻と接続状態があり、UNKNOWN、OFFLINE、PARTIAL_ONLINEも定義されています。[6]

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "list_home_states",
    "arguments": {
      "structureId": "YOUR_TEST_HOME_ID",
      "filter": {
        "resourceIds": [
          "device@YOUR_TEST_DEVICE_ID"
        ]
      },
      "freshness": "MOST_FRESH"
    }
  }
}

「その時刻に状態を見つけた」と「その時刻に状態が変わった」を区別します。

履歴にはobservationTypeがあります。REPORTEDは機器・連携先からの報告、QUERIEDはGoogleが問い合わせて観測した状態です。後者について公式仕様は、変化がその記録時刻に起きたとは限らないと説明しています。[7]

したがって、「洗濯を何回したか」「何分つけっぱなしだったか」は、ログを数えれば終わりではありません。何を1回と定義するか、同じイベントの重複を除いたか、開始だけ・終了だけの記録がないかを確認してから集計します。LLMは説明担当、回数や時間は検証可能なコードで計算、という分担が扱いやすい設計です。

履歴がゼロでも、「出来事がなかった」とは限りません。機器の対応、記録期間、通信断、取得漏れも候補です。保持期間・最大検索範囲・機器別網羅性は、今回確認したMCP資料だけで一律には確定できません。

カメラのイベントを横断することと、人の行動を完全に理解することは違います。

発表時には、カメラをまたいだ出来事の要約や関連クリップの提示が利用例として紹介されています。APIには、カメライベントにメディアURLを含めるincludeMediaUrlsがあります。一方、この仕様だけから、外部エージェントが全カメラのライブ映像や全録画を無制限に受信できるとはいえません。[7][17]

これは「宿題を始めました」と流暢に断言するより、使える回答です。何が起きたかの要約に、何が分からないかも含めることが重要になります。顔認識の利用には、ホーム管理者による別途の同意が必要です。ただし、同意項目があることをもって、顔の生体テンプレートそのものが外部へ渡ると断定はしません。[2]

一括操作の部分失敗と、タイムアウト後の二重実行に備えます。

run_home_actionsは複数の機器への操作を受け取り、機器ごとに応答またはエラーを返す構造です。ツールのヒントは「読み取り専用ではない」「破壊的な操作の可能性がある」「冪等ではない」とされています。つまり、同じ要求をもう一度送っても無害とは、一律に仮定できません。[8]

設計例 庭の照明3台を消す依頼で、2台が消灯、1台はオフラインだったなら、「すべて消しました」ではなく「2台の消灯を確認。1台は確認できません」と返します。複数操作を1リクエストにまとめられることと、全台が同時に成功・失敗するトランザクション保証があることも別です。

APIには追加確認用のフィールドもありますが、それを使えば禁止されている解錠を許可できるという意味ではありません。コマンドの定義、現在の公開制限、ユーザーの承認を、それぞれ独立して満たす必要があります。[2][8]

スキーマに名前があっても、製品として利用可能とは限りません。

製品の初期制約は公式ガイド、音声UIの境界は発表報道で確認。[2][18]

接続を許可すること、操作を許可すること、データを残すことを分けます。

②〜④の具体的な構成は本ページの推奨設計です。Google Home MCPに機器別の読み取り専用スコープが提供されていると確認した、という意味ではありません。公式にはHomeアプリまたはGoogleアカウントから取り消せると説明されています。[2]

操作の禁止条件は自然文だけでなくコード化し、家族や別エージェントとの操作競合も扱います。例えば「夜間はこの照明を消さない」「確認不能なら実行しない」「同じ機器の同時操作を抑える」といったルールです。ユーザーが操作を認識・同意できることは、Googleの開発者ポリシーでも重要視されています。[20]

地域・プラン・早期アクセスの対象確認が先。その後にCloudとOAuthを設定します。

公式ガイドは、Google Cloudプロジェクト、アクセス承認、Home APIの有効化、OAuth認証情報を必要としています。共通の流れは、Cloud側でWebアプリ用OAuthクライアントを準備し、利用するクライアントのコールバックURLを登録し、エージェントからユーザー同意を行うものです。[2]

日本のサブスクリプションと、Home MCPの早期公開条件は別です。

日本向けのHome MCP開始日は、確認した公式公開資料・発表報道では見つかりませんでした。米国アカウントを持っているだけで条件を満たすとも限りません。地域や言語、早期アクセスの承認・展開状況を含め、対象条件を確認する必要があります。[1][2][17]

費用式は比較のための整理です。Google Cloudのプロジェクトを作ること自体を、別の固定月額が必ず発生することと同一視しません。追加のサーバーやログ保管を使う場合は、その利用条件で評価します。Home MCP固有のAPI従量課金の有無・単価は、今回確認した資料では確定できません。

魅力的な事例ほど、「誰が・どの環境で・何を実証したか」を確認します。

公式コミュニティ投稿はリンクの存在を確認しましたが、本文の取得に制限がありました。取得できない本文を読めたことにはせず、公開API仕様と公式ガイドで確認できる内容を優先しています。

ただし、家庭向けの早期公開を、そのまま業務用の自動制御に持ち込む話ではありません。

本ページの考察 単発のオン／オフは、従来のアプリでもできます。エージェントに意味が出るのは、複数の機器・時刻・出来事をまたいで、「何が起きたか」「何を確認すべきか」「操作後に目的を達成したか」をまとめる部分です。連携の中心が、ボタンを増やすことから、状況を説明し行動を支援することへ広がります。

店舗や設備管理へ応用するなら、参考にすべきなのは「構造・状態・履歴・操作を分けた接続設計」です。しかしGoogle Home MCPが、そのまま産業設備や医療・緊急対応に適したサービスだという根拠は、今回確認した資料にはありません。

「動いた」だけではなく、「間違ったときに止まる」を確認します。

提案する受入確認 以下はGoogleの合格基準ではなく、検証用ホームでの試験観点です。目標値は用途とリスクに応じて決めます。実測値は本調査にはありません。