LLMとエージェントの側は、もう十分に賢い。コードを書き、Webを調べ、複数ステップの判断をこなす。一方で、部屋の照明ひとつ消せない。問題は知能ではなく出力口だ。本稿は、AIから物理デバイスへつながる「接続の口」を類型化し、どれを選ぶべきかを整理する。当サイト全体の見取り図でもある。
なぜ今か — 両側は成熟し、配線だけが残った
デバイス側は実のところ何年も前から成熟している。スマートプラグ、ネットワークカメラ、温湿度センサー、ロボット掃除機——APIやプロトコルを持つ機器は家電量販店で普通に買える。足りなかったのは「その口がAIから使えるか」という視点の情報で、これはメーカー資料・フォーラム・GitHubのREADMEに散在したままだ。
AI側の接続層は、この2年で一気に標準化が進んだ。起点は2024年11月25日、AnthropicがModel Context Protocol(MCP)をオープンソースで公開したことだ。2025年にはOpenAIがChatGPTと開発者プラットフォームに、Google CloudがGeminiに、MicrosoftがFoundryに採用し、公開1周年時点でMCP Registryには約2,000のサーバーが登録されていた。さらに2025年12月、AnthropicはMCPをLinux Foundation傘下のAgentic AI Foundationへ寄贈した。この時点で月間SDKダウンロードは9,700万件、アクティブなサーバーは約1万。「どのAIからでも同じ口につなげる」前提が、仕様としてもガバナンスとしても固まったことになる。
デバイス側の標準も動いている。スマートホーム共通規格のMatterは、2025年11月20日発表の1.5でカメラ(WebRTCによる映像・音声ストリーミング)、電動シェードやガレージドア等のclosures、土壌センサーまで対象を広げた。対応製品の普及はこれからだが、方向は明確だ。両側が揃った今、残っているのは「自分の目的にどの配線を選ぶか」だけである。
接続の口は6類型
AIからデバイスへ至る経路は、実質的に次の6つに分類できる。
| 類型 | レイテンシ | クラウド依存 | 保守リスク | 保証・サポート |
|---|---|---|---|---|
| 公式クラウドAPI | 中〜大(往復数百ms〜数秒) | あり | 低(ただしサ終リスク) | あり |
| ローカルAPI (REST/MQTT/WebSocket) | 小(LAN内完結) | なし | 中(ファーム更新で変化) | 機種による |
| 公式SDK | 下層の経路に準ずる | 下層の経路に準ずる | 低〜中 | あり |
| MCPサーバー | 下層の経路に準ずる | 実装による | 公式=低 / コミュニティ=高 | 公式のみ |
| 業界標準 (ONVIF/RTSP/Matter) | 小 | なし | 低(規格寿命が長い) | 規格準拠の範囲 |
| 非公式ハック | 小 | なし | 高 | なし |
公式クラウドAPI
メーカーのクラウドを経由するREST API。認証が整備され、ドキュメントと後方互換の配慮がある。弱点は往復レイテンシとレート制限、そしてメーカーのクラウドが落ちれば全部止まること。長期ではサービス終了リスクも織り込む必要がある。
ローカルAPI (REST/MQTT/WebSocket)
LAN内で完結する口。低レイテンシで、インターネットが切れても動く。自律運用に近づくほどこの性質が効く。ただし有効化の手順やドキュメントの質は機種差が大きく、ファームウェア更新で挙動が変わることもある。
公式SDK
PythonやJavaScriptのライブラリ。中身はクラウド/ローカルAPIのラッパーであることが多く、性質は下層の経路に準ずる。コード実行できるエージェント(Claude Code等)からは実質そのまま叩ける。
MCPサーバー
デバイスの機能をAI向けのツール定義に整形した口。エージェント側の実装がほぼ不要になるのが利点で、公式提供があるなら第一候補になる。一方コミュニティ実装は「作者が更新をやめたら終わり」という保守リスクを抱えるため、コードと権限スコープを確認してから使うべきだ。
業界標準プロトコル (ONVIF/RTSP/Matter)
メーカーに依存しない規格。RTSPは映像ストリーム、ONVIFはカメラの制御・発見、Matterはスマートホーム機器全般をカバーする。規格の寿命が長く、対応機器が安い。AIが直接話す規格ではないので、間にライブラリかハブを1枚挟むことになる。
非公式ハック
解析された非公開API、Tasmota等のカスタムファームウェア。できることは最大で、保証はゼロ。ファームウェア更新一発で壊れる前提で、代替経路のある機器に限って使うのが妥当と考える。
迷ったら「公式の口が2系統以上ある機器(クラウドAPI+ローカルAPIなど)を選ぶ」が当サイトの推奨だ。片方が塞がれても移行先が残る。
「単発コマンド」と「フィードバックループ」は別物
「AIで照明をつける」だけなら、音声アシスタントで10年前から実現している。AIエージェントを持ち込む価値は、状態を読んで判断し、操作し、結果を再度読んで検証する——このループが回ることにある。
- 書き込みの口だけの場合: 「エアコンをつけて」まで。結果の確認は人間の仕事のままだ。
- 読み出しの口があると: 室温・外気温・消費電力を読んで「冷房か、換気か、何もしないか」をAIが判断できる。カメラ映像を読めれば「宅配が来たか」「鍋が吹きこぼれていないか」を判断できる。
段階としては、①人間がトリガーする単発実行 → ②ワークフロー(n8n等)にAI判断を挟んだ条件付き自動化 → ③常駐エージェントによる状態監視と自律運用、と進む。購入前に見るべきは操作の口だけでなく状態読み出しの口があるかどうかで、ここを見落とすと①から先に進めない。
最初の1台: ハブ → カメラ → 専用機
失敗リスクの小ささ・実生活での価値・学びの大きさで並べると、この順を提案する。
1台目: スマートホームハブ
ハブは「1つの口の背後に多数の機器がぶら下がる」構造なので、接続の学習が1回で済み、機器を買い足すたびに配線をやり直さなくていい。
- Home Assistant — ローカル完結、数千の機器統合、REST/WebSocket APIに加えMCPサーバー統合も公式に用意されている。セットアップの手間はかかるが到達点が最も高い。
- SwitchBot ハブ2 — 公式クラウドAPIで手軽に始められ、赤外線リモコン家電まで口の中に取り込める。Matterにも対応する。
2台目: カメラ — AIの目
映像はマルチモーダルLLMにそのまま渡せる、最も情報量の大きい「状態読み出し」だ。
- Tapo C200 — RTSP対応で数千円。LAN内でフレームを取得してLLMに渡すだけで「見えるAI」の実験が始められる。
3台目以降: 専用機
ロボット掃除機、3Dプリンタ、給餌器、ロボットアーム。目的がはっきりしてから選べばいい。最初の2段で「口の見極め方」は身についているので、専用機選びで大きく外すことは少なくなる。
AI接続性レーティングの使い方
当サイトでは全デバイスにAI接続性レーティング(AI-0〜AI-5)と自律度(1〜3)を付けている。AI-0は「AIからの口がない」、数字が上がるほど接続の手間が小さく公式度が高い。自律度は本稿で述べたループの深さ——単発操作止まりか、状態が読めるか、フィードバックループの常用に耐えるか——の目安だ。判定基準の詳細はレーティングについてを、実機の比較はデバイス一覧をレーティングで絞り込んで確認してほしい。
参考情報
- Anthropic「Introducing the Model Context Protocol」(2024年11月25日) — https://www.anthropic.com/news/model-context-protocol
- MCP公式ブログ「One Year of MCP: November 2025 Spec Release」(2025年11月25日) — https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/
- MCP公式ブログ「MCP joins the Agentic AI Foundation」(2025年12月9日) — https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/
- Connectivity Standards Alliance「Matter 1.5 Introduces Cameras, Closures, and Enhanced Energy Management Capabilities」(2025年11月20日) — https://csa-iot.org/newsroom/matter-1-5-introduces-cameras-closures-and-enhanced-energy-management-capabilities/
(参考情報のURLはすべて2026年8月9日に実アクセスして内容を確認した。)