重要なポイント
- ホームオートメーションの幻覚＝間違ったデバイスの作動、誤って読み取られた状態、または存在しないエンティティの参照であり、作り話の一般的な事実ではない
- 主な対策：モデルの関数呼び出しスキーマを実際の現在のエンティティリストのみに制約する
- 会話の以前の内容からモデルに推測・記憶させるのではなく、現在のセンサー/デバイス状態を直接プロンプトに渡す
- 小規模で適切にスコープされたモデル（小規模言語モデルのガイドを参照）は、広く制約のないツールセットを持つ汎用モデルよりも本質的にこの問題が起きにくい
- 無人で信頼する前に、エッジケース（名前変更されたエンティティ、オフラインのデバイス）に対して自動化をテストする
ホームオートメーションにおける幻覚の実例
3つの一般的な失敗モードは、似た名前だが間違ったデバイスを作動させること、実際ではなく想定されたセンサー状態に基づいて動作すること、そしてセットアップにまったく存在しないエンティティを参照することです。
- 間違ったデバイスの作動：複数のランプがある状態で「ランプ」を消すように頼むと、モデルは確認やコンテキストの正しい利用ではなく、推測に基づいて1つを選んでしまいます。
- 想定された状態：自動化が、実際の現在のセンサー読み取り値を確認する代わりに、一般的なケースであるという理由で窓が閉まっているかのように動作します。
- 存在しないエンティティ：モデルは（学習データによく登場するため）もっともらしく聞こえるデバイス名を参照しますが、実際にはHome Assistantインスタンスに一度も設定されたことがありません。
グラウンディング：実在するエンティティに制約する
主な対策は、モデルに常に実際の現在のエンティティリストのみを公開する関数呼び出しスキーマです — モデルは実際に存在するデバイスに対してのみ関数を呼び出すことができ、「作り出されたエンティティ」という失敗モードを構造的に排除します。
- デバイスの追加/削除に伴ってずれてしまう可能性のある手書きや古いリストではなく、Home Assistantの実際の現在のエンティティレジストリから関数呼び出しスキーマ（またはモデルに渡すエンティティリスト）を動的に生成してください。
- セットアップに曖昧なエンティティ名がある場合（複数の「ライト」エンティティなど）、モデルが正しく曖昧さを解消することに頼るのではなく、より区別しやすい名前に変更してください — これはプロンプトの修正ではなく設定の修正であり、より信頼性が高くなります。
- Home-Assistant-Ollama統合ガイドでは、この多くのスキーマ生成を自動的に処理するHome Assistantの会話エージェントにOllamaを接続する実際のセットアップを扱っています。
想定状態ではなく現在の状態を渡す
センサー状態に依存する自動化は、以前の会話ターンに関するモデルの記憶や典型的な状態についての想定に頼るのではなく、実行時に実際の現在の読み取り値を照会するべきです。
- 「窓が開いているか」や「ライトは既に点いているか」が判断にとって重要な自動化では、会話全体を通してモデルが正しく追跡していたことを信頼するのではなく、その状態を自動化ロジックの一部として直接取得してください。
- これは、プロンプトの脆弱性低減に関する一般原則（このトピックに関するクラスター横断ガイドを参照）を、センサーに基づくスマートホームの状態に特化して適用したものです。
- 行動を起こす前に複数のセンサー読み取り値を組み合わせること（センサーフュージョン）も、単一センサーの誤読が判断に影響することを減らせます — スマートホームガイドのセンサーフュージョンを参照してください。
テストとエラーの検出
他の自動化ロジックをテストするのと同じように、無人での実行を信頼する前に、名前が変更されたエンティティ、一時的にオフラインのデバイス、曖昧なコマンドといったエッジケースに対して自動化をテストしてください。
- 最近名前が変更または削除されたエンティティを参照するコマンドを意図的にテストし、似た名前のデバイスを推測するのではなく、自動化が安全に失敗する（確認を求める、または何もしない）ことを確認してください。
- 初期の試用期間中に自動化によってトリガーされたアクションをログに記録し、モデルが実際に行ったことと意図したことを比較できるようにして、静かな誤作動が日常化する前に検出してください。
- 新しいLLM駆動の自動化は、間違ったアクションの影響が大きい重要度の高いデバイス（鍵、セキュリティシステム）に拡張する前に、まず重要度の低いデバイス（照明）で始めてください。
よくある質問
これは一般的なAI幻覚のアドバイスとどう違いますか？
一般的な幻覚低減のアドバイス（AI幻覚ガイドを参照）は、自由形式のテキスト生成における作り話の事実を扱います。この記事は、LLMがコマンドをデバイスアクションにマッピングする際に発生する関数呼び出し特有の失敗モードに特化しています。
この文脈では、小さいモデルの方が幻覚が多い、または少ないですか？
特定の関数呼び出しスキーマに制約された、適切にスコープされた小規模モデルは、広く制約のないツールセットを持つ汎用モデルよりも、多くの場合この問題が起きにくいです — その理由については小規模言語モデルのガイドを参照してください。
間違ったデバイスの作動を完全になくすことはできますか？
完全にはなくせませんが、関数呼び出しスキーマを実際の現在のエンティティリストに制約し、区別しやすいエンティティ名を使用し、エッジケースをテストすることで、失敗率を大幅に減らせます — これは保証ではなくリスク低減として捉えてください。
LLMに鍵やセキュリティシステムを制御させるべきですか？
鍵のような重要度の高いデバイスにLLM制御を拡張する前に、まず重要度の低いデバイス（照明）から始めて、自分の環境の信頼性への確信を築いてください — これは技術的な要件ではなくリスク管理上の選択です。
Home AssistantのOllama統合はエンティティのグラウンディングを自動的に処理しますか？
会話エージェント向けに、現在のセットアップから利用可能なエンティティリストを動的に生成し、ここで説明されているグラウンディングの多くを処理します — セットアップの詳細についてはHome Assistant + Ollama統合ガイドを参照してください。
正しいエンティティを自信を持って特定できない場合、自動化はどうすべきですか？
似た名前のエンティティを推測するのではなく、安全に失敗する — 確認を求める、または何もしない — べきです。これは自動化の関数呼び出しロジックをどう構成するかというデザイン上の選択です。