0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@AI-SKILL-LAB(AI ISO)

「部屋を快適にして」の一言で家が自動化できた話：Vibe Coding × AIエージェント × AIoT が2026年に全部つながった

0
Posted at

「部屋を快適にして」の一言で家が自動化できた話：Vibe Coding × AIエージェント × AIoT が2026年に全部つながった

はじめに

ちょっと前まで、こういうのって SF 映画の話だと思っていました。

「部屋を快適にして」

そう一言つぶやいただけで、エアコンが動き、照明が落ち着いた明るさに変わり、扇風機がゆっくり回り始める。人間がやったことは、言葉にしただけ。

2026年の今、それが自宅で動いています。

驚いたのは「AIがすごかった」というより、 「3つの技術が全部つながったから実現できた」 という部分なんです。その3つとは、 AIエージェント 、 Vibe Coding 、そして AIoT 。

それぞれ単体でも十分おもしろいんですが、この3つが重なった瞬間に、「あ、時代が変わった」という感覚がありました。

この記事では、その体験をそのまま書いてみようかなと思います。技術的な話もしますが、できるだけ「自分もやってみたい」と思える形で。

この記事で登場する主な用語（一言解説）

  • AIエージェント: ツールを使いながら自律的に行動するAI（チャットAIの進化版）
  • Vibe Coding: 自然言語でAIと対話しながらシステムを作る開発スタイル
  • MCP（Model Context Protocol）: AIと外部ツール・デバイスをつなぐ共通規格
  • AIoT / Edge AI: AIを組み込んだIoTデバイス。デバイス自体がAI処理を行う

第1章：2026年のエンジニアリングを変えた3つのキーワード

正直、半年前まではこの3つをバラバラに追っていました。「AIエージェントはおもしろいな」「Vibe Codingってどういう感じ？」「IoTにAI入れるとどうなるんやろ」という感じで。それが3月に入って、突然「あ、全部つながってる」と気づいた。

2026年現在、AI・プログラミング・IoTの世界では、大きく3つの流れが同時進行しています。

1. AIエージェント

LLM（大規模言語モデル）が「回答するだけ」の存在から、 「自分でツールを使って行動する」存在 になってきました。

具体的には、AIが「検索して → 結果を読んで → 次の行動を決めて → 実行して → 確認する」というループを自律的にこなします。人間が一つ一つ指示を出さなくていい。

以前のチャットAIとの一番の違いは、 外部ツールやAPIを自分で呼び出せる という点です。ただ答えを返すのではなく、実際に何かを動かせる。

2. Vibe Coding

「Vibe Coding（バイブコーディング）」という言葉、最近よく聞くようになりました。

元々はY Combinatorの共同創業者アンドレイ・カルパシーが提唱した概念で、 「細かいコードの実装をAIに任せて、人間はシステムの"雰囲気"（vibe）を指示する」 開発スタイルのことです。

Cursor や Claude Code、GitHub Copilot といったAIコーディングツールが進化した結果、「こういうものが欲しい」を自然言語で伝えると、ほぼ動くコードが出てくる時代になりました。

注意したいのは、 「コードを書かなくていい」という話ではない ということ。AIが生成したコードを理解・検証・修正する力は依然として必要です。ただ、「書く量」と「詰まる時間」が大幅に変わった感じがする。

3. AIoT / Edge AI

IoT（Internet of Things）にAIが組み込まれたのが AIoT です。さらに、クラウドにデータを送らずデバイス自体でAI処理を行うのが Edge AI です。

これまでのIoTは「センサーの値が閾値を超えたらメールを送る」のような、人間が事前に決めたルールに従うだけでした。でも Edge AI は、AIがローカルで判断を下せる。ネットが切れても動く。プライバシーも守れる。

Raspberry Pi 4 や NVIDIA Jetson Orin Nano といったデバイスで、日常的な Edge AI 推論が手の届く価格で実現できるようになっています。

第2章：MCPとは何か——AIと物理世界をつなぐ"共通言語"

MCPって最初聞いたとき、正直「また新しい略語か」と思いました。でも理解してみたら、なるほど、これは確かに重要な仕組みやなと。

3つのトレンドをつなぐキーパーツが MCP（Model Context Protocol） です。

2024年末にAnthropicが公開したこのプロトコルは、一言で言うと「 AIと外部ツールをつなぐための共通規格 」です。

USBポートのアナロジー

USB が登場する前、周辺機器をつなぐための規格はメーカーごとにバラバラでした。マウスはメーカー専用ドライバが必要で、キーボードも同様...という時代があった。 USBが「共通のつなぎ方」を定めたことで、どんな機器もとりあえず差せば動くようになった。

MCP はその USB ポートにあたります。

以前は、AIが「天気APIを使う」「カレンダーを見る」「デバイスを操作する」ためには、それぞれ個別の実装が必要でした。でも MCP があれば、 MCPサーバーとして公開さえしてしまえば、どのAIエージェントからも共通の方法でアクセスできる 。

MCPの構造

[AIエージェント（Claude / GPT 等）]
        ↕（MCP プロトコル）
[MCPサーバー]
├── get_room_status()    → 温湿度センサー
├── get_calendar()       → Google カレンダー API
├── set_aircon()         → スマートエアコン
└── set_lights()         → スマート照明

このような MCPサーバーを作っておくと、AIエージェントが「部屋の状態を確認して、今日のスケジュールを見て、最適な環境にする」という判断を自律的にこなせるようになります。

2026年現在のMCPエコシステム

  • 公式MCP SDKs: Python, TypeScript, Kotlin, Java に対応
  • FastMCP: Pythonで最短3行でMCPサーバーを定義できるライブラリ（ pip install fastmcp ）
  • コミュニティ製MCPサーバー: GitHub で数百以上公開中（天気、Slack、GitHub、ファイルシステム等）
  • 主要AIが対応: Claude（ネイティブ対応）、各社AIも追随

MCPサーバーを一度作ってしまえば、AIエージェントを乗り換えてもほぼそのまま使える。これが地味に大きいなと思っています。

第3章：Vibe Codingという新しい開発体験

「AIにコードを書いてもらう」のは今に始まった話ではないですが、2025〜2026年にかけてその体験が質的に変わった気がします。特に、「何を伝えればいいか」がだいぶ自分の中で整理されてきた感じ。

以前と何が変わったか

以前の AI コード補完は「今書いている行の続きを提案してくれる」くらいでした。でも今は違う。

「Raspberry Pi で温湿度センサー（DHT22）を読んで、MCPサーバーとして公開するPythonコードを書いて」と伝えると、 環境設定のコマンドからエラーハンドリング、ログ出力まで含めた実装 が数十秒で出てきます。

コードを読んで「ここはこういう処理にしたい」と伝えると修正してくれる。テストを書いてと頼むと書いてくれる。READMEを書いてと言えば書いてくれる。

「コードを書く」という行為が、「意図を言語化して、AIとすり合わせるプロセス」に変わってきた 感じがします。

Vibe Codingの実際：今回の自宅オートメーション

具体的に、今回のシステムを作った際の流れを書いてみます。

Claude Code に対して最初にこう伝えました。

Raspberry Pi 4 で動く FastMCP サーバーを作りたい。
以下のツールを持たせる:
- get_temperature() : DHT22 センサーから温湿度を取得
- get_schedule()    : Google Calendar API から今日の予定を取得
- set_aircon(temp)  : IR ブラスター経由でエアコンを制御
- set_lights(level) : Zigbee 経由でフィリップスヒューを制御

Python 3.11 で書いて。FastMCP を使って。エラーは全部ログに残して。

これで、動くベースコードがほぼ出てきました。あとは細部のデバッグをAIと対話しながら進めるだけ。全行を自分で書いた場合と比べて、 実装時間が体感でかなり短縮されました 。「体感で」という断りは大事で、正確な計測はしていないんですが、詰まる回数が減った感覚は確かにあります。

Vibe Codingで変わること・変わらないこと

変わること 変わらないこと
コードを書く量 要件を定義する力
実装にかかる時間 コードを読んで理解する力
詰まる頻度 セキュリティ・パフォーマンスの判断力
一人でできる規模 テストと検証の重要性

「コードを書けなくなる」ではなく、 「何を作りたいかを考えて言語化できるエンジニアの価値が上がる」 時代になってきた。そういう感じがします。

第4章：AIoT——デバイスが「考える」ようになった

自宅オートメーションを作って一番驚いたのは、 IoTデバイス側の賢さ でした。センサーが「測る」だけだった時代から、「判断する」時代に変わってきている。

従来のIoTとの違い

以前のスマートホームは「ルール型」でした。

# 従来のIoT: 人間がルールをコードに書く
if temperature > 28:
    turn_on_aircon(target_temp=26)
elif temperature < 23:
    turn_off_aircon()

これはこれで便利ですが、硬直しています。「今日は急に寒い」「外出してたから帰宅直前に準備してほしい」「会議中はエアコン強めに」といった 文脈に応じた判断 ができない。

AIoT の世界では、センサーデータに加えて カレンダー・天気予報・過去のパターン・ユーザーの行動ログ を組み合わせて、AIが「今どんな状態が最適か」を自律的に判断します。

Edge AIが解決すること

クラウドに送らずデバイス側で AI 処理を行う Edge AI には、実用的なメリットがあります。

メリット 具体的な内容
低レイテンシ クラウドに問い合わせ不要。応答が数ms〜数十msで返る
オフライン動作 ネットが切れてもローカルで判断できる
プライバシー保護 家の中のデータがクラウドに行かない
コスト削減 毎回のAPI呼び出しコストがかからない

今回の構成では、センサーのデータ収集と簡単な判断はローカル（Raspberry Pi）で行い、複雑な自然言語処理や判断が必要なときだけ Claude のAPIを呼び出す、というハイブリッド構成にしました。

第5章：3つが全部つながった——実装の話

では実際どうやって動かしたか、構成と主要なコードを紹介します。

必要なもの（ざっくりの費用感）

  • Raspberry Pi 4 Model B（4GB）: 約8,000〜10,000円
  • DHT22 温湿度センサー: 約500〜1,000円
  • Zigbee ハブ + スマート電球（Philips Hue 等）: 既存品があれば追加コストゼロ
  • IRブラスター: 市販品（例：SwitchBot Hub Mini）で代用可能。約4,000〜5,000円
  • Claude API 料金: 実験用途なら月数百〜数千円程度

システム全体構成

[スマートフォン / PC]
  「部屋を快適にして」
        ↓
[Claude API（AIエージェント）]
        ↓（MCP プロトコル）
[MCPサーバー on Raspberry Pi 4]
  ├── get_temperature()     → DHT22センサー
  ├── get_schedule()        → Google Calendar API（OAuth2認証が必要）
  ├── set_aircon(temp)      → IRブラスター（市販品/自作）
  └── set_lights(level)     → Zigbeeハブ → スマート電球

人間がやることは、Claudeに「部屋を快適にして」と伝えるだけ。あとはAIエージェントが自律的にツールを選んで実行します。

FastMCPサーバーのコード例

FastMCP を使うと、Pythonの関数に @mcp.tool() デコレータを付けるだけで MCP ツールとして公開できます。型ヒントと docstring からスキーマを自動生成してくれるので、実装コストがとても低い。

from fastmcp import FastMCP
import adafruit_dht
import board

mcp = FastMCP("home-automation")
dht_sensor = adafruit_dht.DHT22(board.D4)

@mcp.tool()
def get_temperature() -> dict:
    """現在の室温と湿度を取得する"""
    return {
        "temperature": round(dht_sensor.temperature, 1),
        "humidity": round(dht_sensor.humidity, 1),
        "unit": "celsius"
    }

@mcp.tool()
def set_aircon(target_temp: float, mode: str = "cool") -> dict:
    """エアコンの設定温度を変更する（18〜30℃）"""
    # 入力バリデーション（重要）
    if not (18.0 <= target_temp <= 30.0):
        raise ValueError(f"温度は18〜30℃の範囲で指定してください: {target_temp}")
    # IRブラスター経由での制御（市販SDKを利用）
    # ... 実装は使用するデバイスに依存 ...
    return {"status": "ok", "target_temp": target_temp, "mode": mode}

if __name__ == "__main__":
    mcp.run(transport="stdio")

AIエージェントの実際の動き

「部屋を快適にして」という一言に対して、Claudeは以下のように自律的に行動しました。

1. get_temperature() を呼び出し
   → 室温 29.2℃、湿度 68% を確認

2. get_schedule() を呼び出し
   → 「今日はリモートワーク、終日在宅」を確認

3. 判断:
   在宅で長時間いるなら快適な温度（26℃）に設定するのが適切

4. set_aircon(26.0, mode="cool") を実行

5. set_lights(60) を実行
   （日中のリラックスモード: 60% の明るさ）

6. 報告:
   「室温29.2℃だったので、エアコンを26℃冷房に設定し、
    照明も落ち着いた明るさにしました」

人間が何もしていない。これを初めて動かしたとき、正直ちょっと感動しました。

第6章：セキュリティと現実的な注意点

ここは正直に書かないといけない部分です。AIエージェントにIoTデバイスを操作させる構成は、 設計を間違えると深刻なリスクになる 可能性があります。

気をつけたい4つのポイント

1. MCPツールのスコープを最小限に

AIエージェントに渡す権限は、本当に必要なものだけにする。「家中の全デバイスをフルコントロールできるMCPサーバー」は作らない方が無難です。ツール単位で操作範囲を制限する設計を心がける。

上のコード例にある 18.0 <= target_temp <= 30.0 のバリデーションはその一例です。「AIが極端な温度を設定しようとしても、物理的な制限で弾く」という発想が大事。

2. MCPサーバーはローカルネットワーク内に閉じる

今回の構成では、MCPサーバーは自宅のLAN内でのみ動作させています。外部からアクセスできる構成にするとリスクが大幅に上がります。外部公開が必要な場合は、認証・認可の設計を別途しっかりやる必要がある。

3. 重要なアクションには確認ステップを

ガスや施錠といった安全に関わる操作は、AIが直接実行するのではなく「提案して人間が確認する」ステップを挟む方が安全です。現時点では「便利さより安全さ」を優先する設計が無難だと思っています。

4. AIの判断をログに残す

AIエージェントが何を判断して、どのツールを呼び出したかを全てログに残すようにしています。「なぜそうしたのか」があとから追えることが大事です。

現時点での正直な評価

観点 評価
趣味・実験用途 ✅ 十分実用的で楽しい
家族が使う生活インフラ ⚠️ エラーハンドリングをしっかり設計してから
業務・安全関連 ❌ 今の段階では慎重に。検証・設計コストが高い

「おもしろいからとりあえず試してみる」という姿勢は大事にしたい一方で、何を動かしているかの理解は手放さないようにしたい。そう思っています。

まとめ：未来は、試した人のそばに来る

「AIが物理世界を動かす」という話を最初に聞いたとき、「なんか大げさやな」と思っていました。

でも実際に Vibe Coding でシステムを作り、MCP でIoTデバイスをつなぎ、AIエージェントに「部屋を快適にして」と言ったら本当に動いた。そのとき、「あ、これは本当に変わったんやな」と感じました。

3つの技術の話を整理すると、こんな感じです。

技術 一言で言うと 今できること
AIエージェント 考えて動くAI ツールを自律的に使って複数ステップのタスクを実行
Vibe Coding 雰囲気から作るコーディング 自然言語でシステムをほぼ実装できる
AIoT / Edge AI 考えるデバイス センサー+AI+外部情報でコンテキストを読んだ判断

それぞれを単体で見ると「便利になったな」という感想ですが、全部つながったとき、何か質的に違うものが生まれる気がします。

これは「エンジニアが不要になる」話ではないと思っています。むしろ、 「何を作りたいかを考えて言語化できるエンジニアの価値が上がる」 話なんじゃないかと。

まだ実験的な部分も多いし、セキュリティやエラーハンドリングの設計は慎重にやる必要があります。でも、試してみると「あ、時代が動いてる」という感覚が確かにある。

最初の一歩としては、 pip install fastmcp を叩いて、シンプルなMCPサーバーを動かしてみるだけでいいと思います。 思ったよりずっとハードルは低いです。

興味があれば、ぜひ試してみてください。

参考リンク・環境

動作環境

  • Raspberry Pi 4 Model B (4GB)
  • Python 3.11
  • FastMCP 0.9.x
  • Claude API（claude-sonnet-4 系）
  • DHT22 温湿度センサー
  • Zigbee ハブ（Philips Hue Bridge）
  • IRブラスター（SwitchBot Hub Mini で代用可能）

このシステムは個人の実験用途で構築したものです。業務・安全に関わる用途への適用は、別途十分な設計・検証をしてください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?