人が外部から受け取る情報のうち、視覚が占める割合は80％から90％と言われています。スマホのUIも画面表示優先で、利用者もそれを見て操作していました。

今週、GoogleマップのGemini機能のアップデートが行われて、徒歩・自転車ナビへの完全対応をしています。これでは、目的地にたどり着くために地図を凝視する必要はなく、音声操作と文脈理解のもとに結果が示されています。この動きは、操作のあり方やUXのあり方に変化を及ぼす可能性があるので掘り下げてみます。

Navigate with Gemini in Google Maps while walking or biking

Googleマップを下支えする「Gemini Nano」と「AICore」

GoogleマップのUXを支えているのは、クラウド上の巨大なAIモデルだけではなく、Android OSに統合されたAICoreと、オンデバイスLLMであるGemini Nanoの存在です。

AIとの対話で数秒のレイテンシは致命的になるケースがあります。

たとえば、徒歩や自転車での移動中、「⁠次の角を曲がるのか？」という問いにクラウドの応答を待っていれは交差点を通り過ぎます。Android 15以降で最適化が進んだAICoreは、デバイス内のNPUを直接叩くことで、ネットワークに左右されずリアルタイムな応答を可能にします。

アップデートされたGoogleマップが「途中でトイレのあるコンビニを探して」という指示を理解できるのは、ユーザの現在地、進行方向、過去の対話履歴といったマルチモーダルなコンテキストをローカルで保持するからです。

これらをクラウドに送信し続けることは、ネットワーク帯域消費だけでなくプライバシの観点からもハードルが高くなります。しかし、Gemini Nanoによるオンデバイス処理であれば、機微な情報を端末外に出さず高度な推論ができます。

ポイントは、こうした機能がシステムレベルで用意されているところです。

Android 16では、ML Kit GenAI APIsを通じて、サードパーティアプリからもGemini Nanoの推論能力にアクセスできます。 今回のマップの進化は、Google純正アプリによる「ショーケース」で、今後あらゆるアプリが画面操作をすることなく、音声による指示で複雑な要求に応答できる土壌が整ったことになります。

AI前提のUI/UXとはなんだろうか？

これまでのアプリUIの設計は、視覚的にわかりやすくユーザに訴求できるかの観点を持って設計が進められていました。しかし、Gemini NanoのようにオンデバイスAIがOSに深く浸透する流れの中では、画面操作をせず、状況に応じて情報密度を変化させるUIを検討しても良いかもしれません。

たとえば、フィードバックを考えるときも、画面に状況を表示して終わりにするのではなく、ハプティクスや音声を状況に応じて使い分ける必要があるかもしれません。ハプティクスであれば、VibratorManagerを活用して、重要度に応じて振動パターンを使い分けることも考えられます。

また、App Intentsフレームワークを使い、アプリの主要機能をAIエージェントから呼び出しを可能にします。音声指示に対して、アプリを開かずにバックグラウンドで処理を完結できる実装が、差別化要因となる可能性もあります。

ほか、ユーザの状況に応じて情報密度を変化させることも必要かもしれません。

Activity Recognition APIを使い、ユーザが移動中であれば、画面が見られないことを想定して音声のみでフィードバックして、停止したら画面と音声を組み合わせて、音声は最低限にとどめるといったことも考えられます。

将来はアンビエントコンピューティングが主流になる？

Googleマップが示したのは、「⁠地図アプリのアップデート」ではなく、OSが一定の知性を持つエージェントへと昇華するキッカケを示した可能性があります。

これまでのように端末の画面を見て必要な情報を入力をするのではなく、状況やニーズに基づいて、必要な時に最良の結果が得られるアンビエントコンピューティングが主流になるかもしれません。

GUIは50年間ほど使われており、ユーザーとコンピュータの接点に大きな変化はありませんでした。しかし、その関係にも大きな変化が訪れる可能性が考えられます。アプリを機能の集合体として見るのではなく、ユーザにとってストレスなく自然に使える状況、そこにアプリがどう関係するだろうか？と考えても良いのかもしれません。

今週はこのあたりで、また来週。