なぜAIスマートホームアシスタントは簡単な操作でつまずくのか

生成AIによって、スマートホームアシスタントの受け答えは以前より自然になりました。しかし、それだけで信頼性まで高まったわけではありません。

問題が最も目立つのは、「照明をつけて」「明るさを50％にして」「ルーティンを実行して」といった、ユーザーが説明や気の利いた返答ではなく、即座に正しい結果を求める場面です。

基本的な音声コマンドで失敗が報告されている

Alexa+について、David Pogue氏は135件のリクエストを試し、正しく処理できたのは「半分弱」だったと報告しています。これは標準化されたベンチマークではなく、個人によるテストです。それでも、照明のオン・オフや調光レベルの設定に苦戦したという結果は、家電操作を主な役割とするアシスタントにとって印象的です。

Google Homeでも、より具体的な不具合が報告されています。スマートフォンがAndroid Autoに接続されていないときはGeminiからGoogle Homeのルーティンを実行できるのに、Android Autoが有効になると同じルーティンを起動できなくなるというものです。ユーザーによっては、ランダムな返答や一般的なエラーメッセージが返ることもあるとしています。

さらに、Geminiがスマートライトを消すよう求められても、「照明やその他の物理デバイスは操作できない」と答えて拒否したというレビューもあります。 Android Authorityも、アラーム、タイマー、照明操作、応答速度の改善や、ユーザーの操作なしに照明がオン・オフになる不具合の修正を目的とするアップデートを相次いで報じています。

これらの報告から、業界全体に共通する正確な失敗率が導き出せるわけではありません。ただし、会話能力が向上する一方で、日常的な実行処理が安定しないというパターンは繰り返し確認されています。

自然言語の柔軟さが、操作では弱点になる

従来型の音声アシスタントは、理解できる表現が限られていました。その代わり、認識した発話を既知の意図に割り当て、事前に検証された操作へつなげる経路は比較的単純でした。たとえば、内部的には次のような処理です。

setBrightness(device = kitchen, level = 50)

ユーザーは決められた言い回しに近いコマンドを覚える必要がありましたが、解釈の幅が狭いぶん、音声入力から機器の状態変更までを再現性の高い形で処理できました。

一方、大規模言語モデル（LLM）を中心に据えたアシスタントは、次のような複数の判断をその場で行います。

1. ユーザーの意図を推測する
2. 「ここ」「それ」「照明」といった指示対象を特定する
3. 正しい部屋、機器、対応機能を選ぶ
4. 適切なツールやAPIを選択する
5. 有効なパラメーターを渡す
6. 機器の現在の状態を考慮する
7. 操作が成功したかを正確に報告する

どの段階で間違っても、結果は不正確になります。別の機器を選ぶ、部屋の指定を取り違える、対応していない機能を使おうとする、無効な値を送る、古い状態情報に依存する、あるいは機器が変化していないのに成功したと伝える、といった可能性があります。

LLMを使ったスマートホーム操作に関する研究でも、非決定性、推論にかかる時間とコスト、個人化の難しさが、信頼性を妨げる要因として挙げられています。また、あいまいな文脈を広く解釈する必要がある依頼よりも、明示的で構造化された依頼のほうが処理しやすいと指摘されています。

「理解すること」と「実行すること」は別の能力

AmazonとGoogleが打ち出す新機能には、実際に便利なものもあります。Alexa+は話し言葉による説明を適切な機器や機能に対応づけることを目指しており、Googleは複数の指示や、文の途中での訂正、例外を含むコマンドへの対応をアピールしています。

こうした能力は、たとえば次のような用途に向いています。

• ユーザーが望む雰囲気を説明し、シーン設定を提案する
• 複雑なアプリ操作をせず、会話だけでルーティンを作る
• 自動化の内容を説明する
• あいまいな依頼を構造化された計画に変換する

しかし、依頼の意味を解釈することと、機器を正確に動かすことは同じではありません。

「夕食に合う、居心地のよい雰囲気にして」は、ある程度の判断を伴う依頼です。対して「キッチンの照明を50％にして」は、目標となる状態が明確に決まっています。前者では柔軟なAIモデルが役立ちますが、後者では狭く、検証可能な操作経路のほうが適しています。

この違いが、複雑な文章には感心するほど対応できるのに、短い照明コマンドで失敗する理由を説明します。言語上の複雑さと、実行上の複雑さは別物です。複数の機器を操作する依頼でも、モデルが適切なツールとパラメーターを選べば成功します。一方、短い依頼でも、機器の特定や対応機能の確認に失敗すれば実行できません。

遅さも「信頼できない」という印象につながる

信頼できる操作に必要なのは、正確さだけではありません。応答時間が大きくぶれないことも重要です。照明がつくまで長く待たされたり、同じ指示を言い直した後にようやく反応したりすれば、最終的に正しい状態になっても、ユーザーはシステムを不安定だと感じます。

Alexa+のレビューでは、応答に最長15秒かかるケースがあったとされています。ただし、照明やサーモスタットの基本操作は、状況によってはより速く実行できたとも報じられています。 Gemini for Homeについても、日常的なコマンドへの応答を高速化し、返答を短くするアップデートが取り上げられており、遅延が現在も開発上の課題であることがうかがえます。

クラウドでの処理、モデルの選択、機器の検出、外部ツールの呼び出しは、いずれも遅延の要因になります。その結果、理論上は高機能でも、実際の生活の場面では反応が予測しにくいシステムになり得ます。

初期ユーザーがテスト参加者になる問題

ソフトウェアを継続的に更新すること自体は、現在では一般的です。会話機能の改善であれば、実際の利用データを集めながら反復する方法も合理的でしょう。

しかし、スマートホームの操作は、単なるチャットとは異なります。アップデートによって照明、アラーム、家電、ルーティンの挙動が変われば、ユーザーは抽象的な画面の中ではなく、自宅でその影響を受けます。

不具合の報告に続いて修正や信頼性向上のアップデートが繰り返されているからといって、メーカーが意図的に未完成の製品を出荷したと断定することはできません。一方で、システムが調整されている途中に、顧客が問題に直面していることは確かです。自動化が実行されない、ルーティンが壊れる、返答が一貫しないといった報告が続くなかで、「まずリリースし、データを集めて改善する」という方式は、日常の機器操作に適用すると負担が大きく感じられます。

より安全な導入方法は、定型的な操作については信頼できる決定論的な経路を残し、その周辺に生成AIの柔軟性を加えることです。そうすれば、自然な会話を利用しながら、ホームオートメーションの基本的な約束――既知のコマンドを出したら、意図した機器が意図した状態に変わる――も守れます。

現実的な答えはハイブリッド構成

解決策は、スマートホームからLLMを排除することではありません。失敗の影響が大きい箇所で、LLMの役割を限定することです。

堅牢なシステムでは、LLMを言語理解や計画作成に使い、その結果を次の機能を備えた制御層に渡す設計が考えられます。

• 機器とパラメーターをスキーマに基づいて検証する
• セキュリティや安全性に関わる操作に明示的な権限を求める
• 実行前後に機器の現在状態を確認する
• 再試行と明確なエラー処理を行う
• 実行予定の操作と、実際に完了した操作を区別して伝える

関連する研究分野では、LLMがコンパイル段階で実行可能な成果物を生成し、実行時にはワークフロー管理が分岐、ツール選択、再試行、エラー処理を決定論的に担うアプローチも提案されています。

スマートホームに当てはめれば、モデルはユーザーの意図を表現する手助けはできても、毎回の物理操作を単独で決める唯一の権限者になるべきではありません。固定的な機器操作に近いコマンドほど、実行経路は制約され、テスト可能であるべきです。

結論：会話が上手いことと、家を動かせることは違う

Alexa+とGemini for Homeが示しているのは、生成AIに関するより大きな教訓です。話す能力が高まったからといって、操作能力まで自動的に向上するわけではありません。

レビュー、ユーザーの報告、テクノロジー系メディアの取材からは、より豊かな文脈を理解し、複雑な依頼を組み立てられる一方で、照明、調光、アラーム、ルーティンといった基本操作でつまずくアシスタントの姿が浮かび上がります。

長く使えるスマートホームアシスタントは、おそらく両方の方式を組み合わせたものになるでしょう。生成AIは自然な会話や自動化の作成を柔軟にし、決定論的なソフトウェアは最終的な操作を正確かつ高速に、そして検証可能な形で実行する。その境界が適切に設計されるまでは、会話がより賢くなったアシスタントが、家の最も基本的な仕事では以前より頼りなく感じられる可能性があります。