HearthNet: Edge Multi-Agent Orchestration for Smart Homes

本論文は、自然言語によるスマートホーム制御の課題を解決するため、エッジ環境に永続的な役割特化型 LLM エージェントを配置し、MQTT や Git ベースの共有状態、権限付与された実行リースを通じて、計画・検証・承認・動作を明確に分離して自律的に調整する分散型オーケストレーションシステム「HearthNet」を提案しています。

要約

ハースネット（HearthNet）：スマートホームの「賢い執事チーム」の紹介

この論文は、**「HearthNet（ハースネット）」という新しいシステムについて書かれています。簡単に言うと、これは「壊れやすく、複雑になりがちなスマートホームを、複数の AI 執事チームが協力して、安全かつ確実に動かす仕組み」**です。

従来のスマートホームは「もし A なら B をする」という単純なルールで動いていましたが、家電が壊れたり、命令が衝突したりすると、人間が手動で直さなければならなくなることがありました。HearthNet は、そんな問題を解決するために考案されました。

以下に、専門用語を使わず、身近な例え話で解説します。

---

1. 従来のスマートホーム vs. 新しい「ハースネット」

• 従来のスマートホーム（一人の天才と、壊れやすいメモ帳）

  • 今までの AI は、会話が終われば記憶をリセットしてしまう「その場限りの天才」のようなものでした。
  • 家電を操作するルールは、人間が一つ一つ手作業で設定する必要があり、ルール同士が衝突したり、システムが落ちたりすると、誰が何をしたか分からなくなってしまいます。
  • 例え話： 一人の料理人が、メモ帳に「卵を割る」と書いていましたが、メモ帳が濡れて消えてしまい、次は「卵を割らずに炒める」という間違った指示を出してしまうような状態です。

• HearthNet（役割分担した執事チームと、不滅の記録簿）

  • HearthNet は、**「一人の天才」ではなく、「役割分担した複数の AI 執事チーム」**で構成されています。
  • 彼らは常に同じ場所（家のサーバー）にいて、**「不滅の記録簿（Git という技術）」**を共有しています。
  • 例え話： 大きな屋敷で働く執事たち。
    • 館長（Root Agent）： 全体の指揮をとるリーダー。
    • 家事係（Manager Agents）： 照明やエアコン、スマホアプリなどを担当する専門の執事たち。
    • 記録係（Librarian Agent）： 誰がいつ、何をしたかをすべて記録する、絶対に消えない日記係。

---

2. 3 つの重要な仕組み（魔法のルール）

このシステムがなぜ安全なのか、3 つの「魔法のルール」で説明します。

① 「記録簿」で記憶を共有する（Git ベースの共有状態）

AI 執事たちは、会話が終わっても記憶を失いません。すべては「記録簿（Git）」に書き込まれます。

• 例え話： 執事 A が「電気を消す」と言ったら、すぐに記録簿に「14:00 に A が電気を消す予定」と書き込みます。もし執事 A が倒れても、他の執事は記録簿を見て「あ、A が倒れたけど、電気を消すのは私の役目だ」と引き継ぎます。
• メリット： 誰かが倒れても、システム全体が止まらず、誰が何をしたか（誰の責任か）が明確になります。

② 「館長」からの許可証（アクチュエーション・リース）

家電を動かすには、必ず「館長（リーダー）」から発行された**「許可証（リース）」**が必要です。

• 例え話： 家事係の執事が「電気を消します！」と宣言しても、館長が「OK、今の記録簿の状態なら消していいよ」と許可証を出さない限り、実際にスイッチは入りません。
• メリット： 古い情報や、間違った命令が家電に届くのを防ぎます。「許可証」には「いつまで有効か」「誰が言ったか」が書かれているので、セキュリティが強固です。

③ 「古い情報」を弾く（鮮度チェック）

もし執事が倒れて目覚めた時、その執事が持っていた「古い記録」を使って命令を出そうとすると、システムはそれを拒否します。

• 例え話： 執事 B が倒れて 1 時間後に目覚め、「1 時間前に電気を消す命令を出した」と言っても、記録簿には「その 1 時間後に新しい命令（電気を明るくする）が出ている」ことが書かれています。
• 結果： 館長は「その命令は**古すぎる（鮮度が落ちている）**ので無効です！」と拒否します。これにより、古い命令で家電が誤作動するのを防ぎます。

---

3. 実際のデモで何を見せたのか？

このシステムは、実際に実験用のお家でテストされました。

1. 曖昧な命令への対応：
   • ユーザーが「今日は家で仕事をする」と言うと、システムは「照明を集中モードに」「音楽を静かに」「テレビを消す」と、それぞれの担当執事が勝手に判断して実行します。
2. 命令の衝突解決：
   • 「仕事モード（明るい）」と「夜のリラックスモード（暗い）」が同時に発動した時、システムは「ユーザーが直前に『仕事』と言ったので、リラックスモードはキャンセル」と判断し、記録簿にその理由を残します。
3. 故障からの回復：
   • 執事の一人が倒れて再起動した際、古い命令を出そうとしましたが、システムが「それは古い情報です！」と拒否し、最新の情報を取得し直してから再挑戦させました。

---

まとめ：なぜこれがすごいのか？

HearthNet は、**「AI が家の家電を操る時、単なる魔法ではなく、責任ある『組織』として動く」**ことを実現しました。

• 安全： 古い命令や、権限のない命令はブロックされます。
• 透明： 誰が何をしたか、すべて「記録簿」に残るので、トラブルの原因がすぐに分かります。
• 回復力： 誰かが倒れても、記録簿があればすぐに復活して作業を続けられます。

これからのスマートホームは、単に「便利」なだけでなく、**「壊れにくく、信頼できる」**ものになるための重要な一歩です。まるで、完璧に連携する執事チームがあなたの家を管理しているような感覚を、AI によって実現しようとする試みなのです。

技術概要

HearthNet: スマートホーム向けエッジマルチエージェントオーケストレーションの技術的サマリー

本論文は、スマートホーム環境における自然言語制御の課題と、既存のクラウド中心のマルチエージェントフレームワークの限界を指摘し、HearthNet と呼ばれる新しいエッジ型マルチエージェントオーケストレーションシステムを提案しています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。

---

1. 問題定義 (Problem)

スマートホームユーザーは、手動でのルール設定や API 統合に代わり、自然言語による制御を望んでいます。しかし、実際の展開環境では以下の課題が存在します。

• 脆弱性: デバイスの故障、統合の破損、ネットワークの分断などが頻発し、回復には手動介入が必要になることが多い。
• 既存フレームワークのミスマッチ: Anthropic のエージェントチームや Microsoft の AutoGen、LangChain の LangGraph などの既存のオーケストレーションツールは、主に「セッション内（一時的）」の委任に最適化されています。
• スマートホームの特性との不一致: スマートホーム制御は、永続的（persistent）、イベント駆動、故障に弱い、かつ物理デバイスに直接結びついているという特性を持ちます。これらは、セッションローカルなメモリや共有コンテキストウィンドウを持たない既存のエージェントモデルでは対応が困難です。
• コンテキストの欠如: 単一のモノリス型エージェントや、セッションごとのサブエージェントでは、物理的な状態の共有、失敗からの回復、権限境界の明確化が不十分です。

2. 手法とシステムアーキテクチャ (Methodology)

HearthNet は、コモディティなエッジハードウェア上で動作する永続的なマルチエージェントシステムです。クラウド依存を最小限に抑えつつ、LLM 推論にはホスト型 API を使用しつつ、オーケストレーションと状態管理をオンプレミスで行います。

2.1 階層的役割アーキテクチャ

システムは 4 つの階層で構成され、すべて MQTT ブローカーを介して協調します。

1. Root Agent (ルートエージェント):
   • 役割：システム全体のオーケストレーター。ユーザーの自然言語コマンドを受け取り、ドメイン固有のタスクに分解してマネージャーに配信します。
   • 権限：**アクチュエーション・リース（実行許可）**を発行できる唯一のコンポーネントです。
2. Manager Agents (マネージャーエージェント):
   • 役割：特定のデバイスドメイン（例：Home Assistant 接続機器、スマホ上の UI 自動化）を管理します。
   • 動作：タスクを具体的なデバイスアクションに変換しますが、直接デバイスを操作する権限はなく、ルートエージェントからのリースが必要です。
   • 例：「Jeeves」（Home Assistant 管理）、「Darcy」（Android スマホの UI 自動化およびセンサー管理）。
3. Librarian Agent (図書館員エージェント):
   • 役割：観測者（Observer）として機能し、制御パスには参加しません。
   • 機能：MQTT トラフィックをミラーリングし、構造化されたメタデータと共にGit リポジトリに記録します。これにより、完全な監査可能性とクラッシュからの回復が可能になります。
4. Device Adapters (デバイスアダプター):
   • 役割：デバイス自体はエージェントではなく、マネージャーによって制御される決定論的なエンドポイントです。

2.2 主要な技術的メカニズム

• Git ベースの共有状態 (Shared State):
  • 全エージェントは、Git リポジトリを「単一の真実（Single Source of Truth）」として参照します。
  • メッセージには、送信者が参照している現在の Git 状態（base_commit）のハッシュが含まれます。
• アクチュエーション・リース (Actuation Leases):
  • 状態変更コマンドを実行する前に、ルートエージェントが短寿命の「リース」を発行します。
  • リースには、対象デバイス、許可された操作、パラメータ、承認時の base_commit、ポリシー、有効期限などが含まれます。
  • デバイスアダプターは、リースの有効性、スコープ、および状態の鮮度（Freshness）を検証し、無効な場合は実行を拒否します。
• 実行プロトコル (4 ステージ):
  1. Ground: 現在の Git 状態とポリシーをロード。
  2. Propose: マネージャーが具体的なアクションを提案（実行はせず）。
  3. Verify & Grant: ルートが鮮度とポリシーを検証し、リースを発行。
  4. Execute & Record: マネージャーが実行し、結果を Git に記録。

2.3 故障回復 (Failure Handling)

• エージェントがクラッシュして再起動した場合、メモリ内の会話履歴ではなく、Git リポジトリから現在の状態をプルして再同期します。
• 古い base_commit や失効したリースを参照するコマンドは、ルートエージェントによって即座に拒否され、エージェントは新しい状態とリースを取得し直す必要があります。

3. 主要な貢献 (Key Contributions)

1. Git ベースの鮮度メカニズム:
   • base_commit 検証により、エージェントがデバイス操作前に古いまたは競合するコマンドを検知・拒否する仕組みを提供。
2. ポリシー境界付きアクチュエーション・リース:
   • 状態変更コマンドを、アイデンティティ、デバイススコープ、パラメータ、承認時の状態バージョンに紐付けることで、安全な実行境界を確立。
3. 図書館員（Librarian）としての観測者パターン:
   • 制御パスに関与しない専用エージェントが協調トラフィックをバージョン管理されたリポジトリにミラーリングし、クラッシュ回復、帰属、完全な監査可能性を実現。
4. 実機デプロイされたエッジプロトタイプ:
   • ARM64 Mac mini、x64 NUC、Android スマホという 3 種類のハードウェアで動作し、自然言語による意図理解、競合解決、安全性検証の 3 つのライブシナリオを実証。

4. 結果と評価 (Results)

実機デプロイされたプロトタイプを用いた評価結果は以下の通りです。

• シナリオ 1（意図駆動協調）: 曖昧な自然言語（「在宅勤務モード」）から、複数のデバイス（照明、スピーカー、テレビ）を連動させるタスクを成功裏に実行。
  • 完了率：4/5（1 つはモバイルエージェントの視覚認識エラーによるもの）。
  • 平均エンドツーエンド遅延：8 秒（LLM 推論がボトルネック）。
• シナリオ 2（競合解決）: 事前設定された「夜間モード」とユーザーの明示的な「在宅勤務モード」が競合した際、タイムライン履歴に基づき、ユーザーの明示的な意図を優先して競合を解決。
  • 競合検出・解決率：5/5。
• シナリオ 3（鮮度と認証検証）: エージェントを再起動させ、クラッシュ前の古いコマンド（失効したリース・古いコミット）を送信させたところ、システムがこれを正常に拒否。
  • 古いコマンドの拒否率：5/5。
  • 誤って拒否されたケース：0。
• パフォーマンス:
  • リース検証のオーバーヘッド（p95）は <0.01 ms と極めて軽微。
  • 全体の遅延は主に LLM 推論時間に依存しており、オーケストレーションインフラ自体のオーバーヘッドは無視できるレベル。

5. 意義と結論 (Significance & Conclusion)

HearthNet は、スマートホームのような永続的で物理的な環境におけるマルチエージェント協調の新しいパラダイムを示しています。

• セッションから永続性へ: 既存のフレームワークが「セッション内」の文脈に依存するのに対し、HearthNet は Git による外部化された状態管理を通じて、エージェントの再起動や故障後も一貫した動作を可能にします。
• 安全性と監査可能性: 「リース」と「鮮度チェック」を導入することで、意図しないデバイス操作や競合を防止し、すべての決定プロセスを監査可能な形で記録します。
• 実用性: 既存のクラウド LLM API を利用しつつも、制御平面と状態管理をエッジ（オンプレミス）に保持することで、プライバシーと信頼性を確保しつつ、実用的なシステムを構築できることを実証しました。

将来的には、ホスト型 API に依存しないローカル LLM モデルへの移行や、より強力なランタイム信頼保証（SENTINEL 型プロベナンスなど）の統合が今後の課題として挙げられています。