cat ./posts/jarvis-home-agent-real-world-design.ja.md
# 予定の読み上げ、音声、家電APIをつなぐJarvisを題材に、命令の送信、ソフトウェア上の状態、物理的な確認を分けるホームエージェント設計を、実運用の記録から整理します。
grep -R tag ./posts
まだコメントはありません。
家の中で声をかけると、予定を読み、家電を動かし、必要なら通知する。
それがJarvisで目指している体験だ。
それだけ聞くと、ホームエージェントは会話モデルの性能で決まるように見える。
実際に作って分かったのは逆だった。
難しいのは、命令を送ったあとに「どこまで確認できたか」を嘘なく伝えることだ。
この記事は2026年7月24日に、設定、当日ジョブの終了状態、稼働中APIの応答を照合して更新した。
接続先、認証値、個人情報は掲載していない。
*写真: 稼働確認に使った実物の制御基板と配線。画面はマスク済み。露出した基板と配線を含む試作状態で、筐体、配線の引っ張り対策、無人常設の安全性は未確認である。この写真だけでは接続先や物理動作を確認できない。*
ここでいうJarvisは、特定のスマートスピーカー製品ではない。
Hermes エージェントを中心に、会話、スケジュール、音声、家の機器をつなぐホームエージェントの呼び名だ。
役割は大きく四つある。
毎朝8時JSTのジョブは、Google Calendarから当日の予定を取得し、読み上げ文をPOST /alarmsで登録する。
登録内容は1秒後の実行指定、読み上げ文、output: announcementであり、ジョブのスクリプトはレスポンスにアラームIDがある場合だけ正常終了する。
home-workerは実行時刻を過ぎた項目を再生処理へ渡し、その処理が成功を返した後にだけ項目を削除する。
2026年7月24日のスケジューラー記録では、ジョブは08:02 JSTに正常終了した。
その後のアラーム一覧に朝の実行済み項目は残っていなかったため、予定取得、API登録、API上の項目消費までは確認できた。
ただし、物理スピーカーから実際に音が出たかは独立に確認していない。
「予定読み上げが設定済み」と「今朝スピーカーで再生された」は別の事実である。
この区別が、シリーズ全体の土台になる。
家電操作を一語で「成功」と呼ぶと、状態を誤解しやすい。
そこでJarvisでは、結果を次の段階に分けて考える。
| 段階 | 分かること | まだ分からないこと |
|---|---|---|
| 要求を受けた | 会話やボタン入力を解釈した | 実行経路へ届いたか |
| 命令を送った | APIや赤外線送信処理が応答した | 機器が受信したか |
| 既知状態が変わった | ソフトウェア上の状態を更新した | 部屋や機器が物理的に変化したか |
| 物理確認できた | センサーや独立した観測で変化を確認した | 長時間安定して動くか |
この分解をすると、「送信しました。物理状態は未確認です」という返答が正しい場面が見えてくる。
会話としては少し不格好でも、生活の中ではその方が安全だ。
音声には、音声認識と読み上げを組み合わせる経路と、音声を直接やり取りするリアルタイム経路がある。
二つを同時に動かすと、返答の二重再生や、別の音声エンジンが割り込む原因になる。
そのため、通常の音声会話とリアルタイム音声は経路を分ける。
アラームや予定通知も、テキストをDiscordへ送るだけでは完了にしない。
「スピーカーで鳴らす」ことが要件なら、音声再生までが仕事である。
インターホンでは、実際には鳴っていないのに通知が届いたとの報告が1件あった。
原因はまだ特定できていない。
ここで最も危険なのは、推測した原因を確定事項として直すことだ。
センサーのチャタリング、通信の再送、古い状態の再利用など候補は複数あるが、記録がなければ選べない。
必要なのは、次回の一回を詳しく残すことだ。
検知時刻、入力値、判定理由、通知ID、再送回数を同じ相関IDで追えるようにする。
そして誤検知が続く間は、インターホン通知を「来客確定」ではなく「信号を検知」と表現する。
Jarvisの配下には、テレビやスピーカーの音量操作、エアコンの赤外線送信、散水ポンプ、風呂スイッチなど、影響の大きさが異なる機能が並ぶ。
すべてを同じ権限と成功判定で扱うべきではない。
自動化は、動かす機能より停止条件の方が重要になる。
止められない自動化は、便利な機能ではなく新しい故障点だ。
2026年7月24日時点で、毎朝8時JSTのGoogle Calendar取得ジョブと当日実行、POST /alarmsによる読み上げ登録、実行後の項目消費を確認できた。
同じ確認では、2台の家庭菜園コントローラーがそれぞれ/statusへ応答し、エアコンのソフトウェア既知状態はcool_18だった。
風呂にはPOST /bath/switch/toggleがある一方、現在状態を返す状態取得APIはない。
物理スピーカー再生、赤外線の受信と室温変化、風呂スイッチの接触と湯張り開始・完了、実際の散水、長期運用は確認できていない。
この差を埋める次の作業は、AIを賢くすることではない。
機器ごとに独立した観測を追加し、命令と結果を同じ記録で結び、未確認なら未確認と答えることである。
流暢に「完了しました」と言うJarvisより、「命令は送信済みです。現物はまだ確認できません」と言えるJarvisの方が、家の司令塔として信頼できる。
