Googleがスラッシュコマンドを@に置き換える中、Gemini Mapツールが登場

GoogleはAndroidとiOS向けにGemini Mapツールを追加した。同時に、別のインターフェース変更ではスラッシュコマンドが@メニューに置き換えられる。

このマップにより、ユーザーは地域を言葉で説明する代わりに、地理的な範囲をプロンプトへ直接指定できる。@への変更は、Skills、接続済みサービス、その他のツールを単一の選択レイヤーにまとめるものだ。

これらのアップデートは、Geminiアプリが異なる種類のものへ変わりつつあることを示している。Googleはプロンプトボックスを、空白のテキスト入力欄から、コンテキストや機能を選ぶための操作面へと転換している。

目先の変更は控えめだ。ユーザーは視覚的な位置選択ツールと統合メニューを利用できる。より大きな賭けは、どこで作業すべきかを人が正確に示せるとき、アシスタントはより役立つものになるという考えにある。

これは従来のテキスト優先型チャットボットのインターフェースに圧力をかける。OpenAI、Anthropic、その他のアシスタント開発企業もツール利用を拡大しているが、Googleはモバイル配信と地図インフラという独自の組み合わせを持つ。

Gemini Mapツールは、この優位性がよりよいプロンプト体験へと結び付くかを試すものだ。同時に、提供状況、位置精度、データの取り扱い、そしてGeminiが選択されたコンテキストに確実に基づいて行動できるかという、よく知られた疑問も浮かび上がらせる。

Gemini Mapツールがエリアをプロンプトのコンテキストに変える

新しいマップは、ユーザーが説明するものだった位置情報を、選択できるものへと変える。

モバイル向けMapツールは、AndroidおよびiOSのGeminiアプリで添付ファイルのカルーセルに表示される。Photos、Camera、Files、Drive、Avatar、Notebooksなどの選択肢と並ぶ。

Mapを選ぶと、ユーザーの現在地周辺を中心としたライブ表示が開く。インターフェースには、Geminiが考慮すべき場所を示す円形のフォーカス領域が含まれる。

ユーザーはマップを移動し、拡大・縮小し、別の目的地を検索できる。「Explore this area」をタップすると、「Map Area」の添付ファイルがプロンプトボックスに追加される。

この添付ファイルは、文章による依頼と組み合わせられる。旅行者はホテル周辺の数ブロックを選択し、会議に適した静かなレストランを尋ねることができる。

また、ユーザーは見慣れない街区を選んで、交通機関の停留所に近いコーヒーショップを求めることもできる。用事を計画している人なら、選択した範囲内で役立つ立ち寄り先をGeminiに特定させられるかもしれない。

重要な違いは精度にある。「繁華街の近く」のような表現は、曖昧な地理的境界を指し得る。マップ上の選択は、システムに明確な視覚的参照を与える。

もちろん、それで正しい回答が保証されるわけではない。ただし、Geminiが依頼について推論を始める前に、曖昧さの一因を減らすことはできる。

このワークフローは、エリアの選択と目的地検索も分けている。ユーザーは店舗の正確な名前や住所から始める必要がない。

地理から始め、その後にプロンプトで意図を説明できる。この構造は、従来の目的地入力欄よりも探索的な質問に適している。

報じられている展開はモバイル限定だ。ウェブ版アプリは関連する応答のために位置情報を使用できるものの、Mapの選択肢は現在Geminiのウェブインターフェースでは利用できない。

この違いは、操作がタッチに依存するため重要だ。旅行中に使うスマートフォンでは、地図をパンし、対象エリアを調整する行為が自然に感じられる。

また、座標、通りの名前、リンクをアプリ間でコピーするよりも、この機能は即時性が高い。マップは画像やドキュメントのような入力オブジェクトになる。

Googleはすでに、他の場面でGeminiと地理情報を連携させている。以前のMaps groundingのリリースでは、2億5,000万を超える場所をカバーする情報へのアクセスを開発者に提供した。

消費者向けのMapツールは、同じ大きな考え方をインターフェースのレベルで適用するものだ。Geminiに解釈を求める前に、ユーザーが地理的コンテキストを定義できるようにする。

ただし、この新しいピッカーを完全なナビゲーションと混同すべきではない。報じられているインターフェースは、ターンバイターンの案内を置き換えるのではなく、位置情報に基づくプロンプトを準備するものだ。

また、すべての依頼でリアルタイムの状況、非公開の保存済みスポット、あるいは完全な店舗情報が使われることも示していない。これらの機能は、Geminiがアクセスできるサービスに依存する。

より慎重な解釈は限定的だ。Googleは、選択したエリアをGeminiとの会話に直接添付する方法を作った。

この追加が重要なのは、地理に関するプロンプトを正確に表現することがしばしば難しいためだ。選択された範囲は、Geminiが回答する際の境界をより明確にする。

同時に、この記事の中心的な緊張関係も生み出す。Googleは非常に豊かな位置情報コンテキストを提供できる一方、ユーザーはどのデータが会話に入るのかを理解する必要がある。

Googleはツールを中心にプロンプトボックスを再構築している

プロンプトボックスは、専門的な入力、再利用可能な指示、接続済みサービスのランチャーになりつつある。

Mapの選択肢は、この移行の一部だ。初報によれば、もう一つの部分はGoogleアプリのベータ版17.63に現れている。

このベータ版では、スラッシュを入力すると、スラッシュは現在@になったというメッセージが表示される。インターフェースは、ユーザーがSkills、Connectorsなどに一か所からアクセスできるとしている。

GoogleがSkillsを呼び出す方法としてスラッシュを導入したのは、ほんの最近のことだった。この急速な変更は、Googleがそのコマンド慣習を維持することよりも、統合されたツールメニューを重要視していることを示唆する。

@記号は、多くのデジタル製品ですでに明確な意味を持つ。通常は、現在のタスクに参加すべき人物、サービス、エージェント、リソースを識別する。

このメンタルモデルはGeminiに有用だ。ユーザーは、Skillや接続済みアプリケーションを、見えないシステム設定ではなく、明示的な能力の源として扱える。

より広いインターフェースでは用語も変わりつつある。「Connected Apps」は「Connectors」へ、GemsはSkillsへと置き換えられる見込みだ。

GoogleはGemini Skillsを、繰り返し発生するタスクやワークフローのための再利用可能なカスタム指示として定義している。Geminiは関連するSkillを自動的に適用でき、ユーザーが指定することもできる。

このモデルは、一度きりのプロンプトとは異なる。Skillは、似たタスクが現れた際に再び呼び出せる反復可能な手法を保持する。

Googleは、複数のSkillsが連携できるとも述べている。一方が組織の執筆ルールを定め、もう一方が週次レポートを作成する手順を定義することも可能だ。

@メニューは、こうした再利用可能な指示に外部サービスと共通の場所を与える。プロンプトボックスを、モデル、保存済みワークフロー、接続済みデータの間を振り分けるレイヤーへ変える。

Googleの9月の接続アプリ拡張は、その構想の規模を示している。同社は、生産性、クリエイティブ、ライフスタイルの各カテゴリーにまたがる統合を発表した。

例には、プロジェクト管理、データベース整理、デザイン、ウェブサイト構築、運動計画、物件検索、信用情報のモニタリング、イベント発見が含まれた。

ユーザーは設定で対応サービスを接続できる。その後、@メンションまたは直接の依頼によって、会話にそのサービスを取り込める。

新しいインターフェースは、これらのサービスとGoogle独自の再利用可能なSkillsとの区別を縮小する。両方が同じ会話の中で呼び出せるリソースになる。

Mapはこのリソースモデルを物理空間へ拡張する。選択したエリアは、ファイル、写真、ノートブック、接続済みアプリケーションと並んでGeminiが利用できる別のオブジェクトになる。

この統合は、インターフェース上の摩擦を減らせる。ユーザーは、あるリソースは@を使い、別のものはスラッシュを使うことを覚える必要がなくなる。

一方で、メニューが混雑する可能性もある。単一の選択画面には、個人用Skills、職場のプロセス、Googleサービス、サードパーティーツール、メディア入力がいずれ含まれるようになるかもしれない。

したがって、発見しやすさは利用可能性と同じくらい重要になる。ユーザーがGeminiがどのリソースを選んだか予測できなければ、統合は複雑さを取り除くのではなく隠すだけになる可能性がある。

自動ルーティングは関連する懸念を生む。Geminiが適切なSkillを選択できれば時間を節約できるが、誤った選択は結果を気付かれないまま変えてしまう可能性がある。

明示的な@メンションは有用な対抗策となる。モデルがタスクを解釈する前に、ユーザーが意図したツールを指定できるからだ。

インターフェースはなお移行期にある。Mapツールは広く利用可能と説明されている一方、スラッシュコマンドの置き換えはまだ広範には展開されていない。

そのため、ユーザーはアカウント、プラットフォーム、アプリのバージョンによって異なる操作項目を見る可能性がある。ベータ版のインターフェースを、完了した世界規模の移行として扱うべきではない。

Googleの方向性は、そのスケジュールより明確だ。同社はGeminiのプロンプトボックスを、単に文章を受け付けるものではなく、ツール群を調整するものにしたいと考えている。

Gemini MapツールはGoogleの地理的優位性を際立たせる

Googleの優位性はマップピッカーそのものではなく、その背後に控える地図システムにある。

競合するアシスタントも、住所、座標、スクリーンショット、位置に関する質問を受け付けられる。一部は、現在の場所に関する情報を得るためにウェブ検索や外部サービスを呼び出すこともできる。

Googleは異なる立場からこの問題に取り組む。Google Mapsを運営し、Android全体にGeminiを配信し、有用な個人コンテキストを保持するサービスを管理している。

この組み合わせにより、位置情報は製品統合にとって自然な領域となる。またGoogleは、現在ならチャットボットと地図アプリケーションの間を移動するワークフローを短縮する機会を得る。

Googleは、新しい消費者向けピッカーが登場する前から、この戦略を開発者に示し始めていた。Gemini API向けのMapsツールは、モデルの応答を現在の地理空間情報と結び付ける。

同社によれば、その開発者向け製品は2億5,000万を超える場所から情報を引き出す。この規模は、レストラン、観光地、サービス、旅程に関する質問に対し、Geminiへ大きな基盤を与える。

GoogleはMapsそのものの中でもGeminiを拡大してきた。一つの経路はナビゲーションから始まり、移動中の会話型支援を導入する。

Gemini Mapツールは逆方向に進む。アシスタント内から始まり、選択された地理的エリアを会話に取り込む。

この二つの経路は近づき始めている。Mapsはより会話的な振る舞いを獲得し、Geminiはより明示的な地理的入力を得ている。

この収束は、AIアシスタントが別個の目的地であり続けるべきだという考えに圧力をかける。Googleは、位置に基づく意思決定の前、最中、後にGeminiを配置できる。

週末の計画タスクを考えてみよう。ユーザーはエリアを選び、複数の選択肢を求め、カレンダー上の制約と比較し、その後ナビゲーションへ進める可能性がある。

Map添付は、検索エリアを定義することで最初のステップを担う。Connectorsは最終的に、空き状況、予約、チケット、その他タスク固有の情報を提供できるかもしれない。

Skillsはユーザーの繰り返し使う好みを保持できる。保存済みの指示は、徒歩距離、静かな会場、アクセシビリティ、特定のスケジュール形式を優先するものになり得る。

この組み合わせにより、アシスタントは単なる場所検索ボックス以上のものになる。地理的コンテキストを、個人のルールや接続済みサービスと調整するようになる。

現在のリリースは、その完全なワークフローが確実に機能することを示してはいない。構築に必要なインターフェース要素のいくつかを提供するにとどまる。

この区別は重要だ。視覚的に選択したエリアが、ハルシネーション、古い掲載情報、営業時間の欠落、疑わしい推奨をなくすわけではない。

位置に基づく推奨には、多くの隠れた要件がある。システムは境界を解釈し、関連する場所を取得し、順位付けし、それらが適合する理由を説明しなければならない。

どの段階でのミスであっても、回答の質を弱めかねません。美しく選択された地図エリアも、Geminiがプロンプト内の重要な制約を見落とせば、ほとんど価値がありません。

Google独自の地図情報の深さは、依然として競争の構図を変えています。競合他社も地図プロバイダーを統合できますが、Googleはアシスタントと主要な地理プラットフォームの両方を掌握しています。

同社は、AndroidほどのOSレベルの制御を持たないiOSでも、自社アプリを通じてユーザーにリーチしています。両モバイルプラットフォームでMap toolが登場したことで、テストの対象は広がります。

Webで利用できないことは依然として目立つ空白です。旅行先やビジネス拠点を調べるデスクトップユーザーは、より大きな画面とキーボードを好むかもしれません。

Googleはいずれ、この選択機能をWebにも拡張する可能性がありますが、報じられたローンチはそれを約束していません。その不在により、現時点の機能はモバイル利用に焦点を絞っています。

そのため、競合にかかる圧力は具体的です。基盤となる地図を所有していなくても、位置情報の文脈を同じように簡単に提供できるようにしなければなりません。

Googleにかかる圧力も同様に現実的です。同社は、統合によって既存サービスへの導線が増えるだけでなく、より良い成果が生まれることを示す必要があります。

より良い位置情報プロンプトには、より大きなプライバシー負担が伴う

Map toolはリクエストの曖昧さを取り除きますが、その分、データの境界がより重要になります。

Geminiはすでに、複数の方法で位置情報を利用しています。Googleによれば、同社のアプリは、許可が得られている場合、概略的な位置情報またはデバイスの正確な位置情報を使用することがあります。

モバイルでは、こうした権限の一部はGeminiのアシスタント機能をホストするGoogleアプリに依存します。そのため、プラットフォームの設定がGeminiに渡る文脈へ影響する可能性があります。

新しいMapインターフェースは、より意図的なシグナルを導入します。ユーザーはエリアを積極的に選び、それをプロンプトに添付します。

この操作は、見えないバックグラウンド推論よりも理解しやすいものです。選択された地図は、共有される位置情報を視覚的に表現します。

ただし、添付時に可視化されていても、すべての疑問に答えられるわけではありません。ユーザーは依然として、プロンプトがどのように保存、処理され、他の情報と組み合わされるのかを知りたいかもしれません。

GoogleのGemini privacy controlsでは、Geminiの情報にプロンプト、アップロードされたコンテンツ、接続アプリのデータ、デバイス情報、位置情報が含まれ得ると説明されています。

このドキュメントは、概略的な位置情報と正確な位置情報も区別しています。機微な地理的文脈を共有する前に、ユーザーはアプリの権限とGeminiのアクティビティ設定を確認すべきです。

地図上の選択は、目的地以上の情報を明かす場合があります。自宅周辺、職場、医療施設、学校、または繰り返される移動パターンを特定する可能性があります。

位置情報がメール、カレンダー、ファイル、写真、連絡先、あるいはサードパーティーサービスの情報と結び付くと、このリスクは高まります。接続が増えるごとに、回答はより有用になる一方で、より個人的なものになります。

Googleは、対応アプリの接続は引き続きユーザーの管理下にあるとしています。しかし、アシスタントが複数の情報源を自動的に組み合わせるようになるほど、その管理を評価することは難しくなります。

統合された@メニューは、選択したリソースを可視化することで役立つかもしれません。ユーザーが明示的にコネクタを呼び出せば、それがタスクに加わることをより明確に把握できます。

自動的なSkill選択は、それほど明白ではありません。保存済みのワークフローは、ユーザーが直接呼び出さなくても回答に影響を与えることがあります。

Skillsはデータソースではなく指示ですが、Geminiが何をリクエストするか、または接続された情報をどう使うかを形作る可能性があります。そのため、透明性が重要になります。

信頼できるインターフェースは、どのSkill、コネクタ、または添付ファイルが回答に影響したかを示すべきです。また、送信前にそれらを容易に削除できるようにすべきです。

Map添付は、プロンプトボックス内でそのような明示的なオブジェクトを提供しているように見えます。最終的なインターフェースが下流でのデータ利用を説明するかどうかは、別の問題として残ります。

正確性も、このリスクに関する議論に含まれます。選択されたエリアは画面上で正確に見えても、基礎となる解釈は不完全なままである可能性があります。

境界は、近隣地域、行政区、キャンパス、または事業エリアをまたぐことがあります。Geminiが大まかな円を厳密な検索半径として扱う場合もあれば、単なる一般的なヒントとして扱う場合もあります。

この機能名は、完全な地図検索を実行するという期待を生むかもしれません。ユーザーは重要な詳細をGoogle Mapsまたは店舗・施設へ直接確認すべきです。

これは、営業時間、アクセシビリティ、予約、道路状況、移動時間において特に重要です。これらの詳細は、Geminiが回答を生成した後に変わることがあります。

アシスタントはまた、現在のMaps情報に基づくおすすめと、より広範なWeb資料に基づく提案を区別すべきです。インターフェースがその出所を常に明確にするとは限りません。

第2の不確実性は、ロールアウトの一貫性に関するものです。Map toolはAndroidとiOSで広く表示されていると報じられていますが、機能の提供状況はアカウントごとに異なる可能性があります。

@への置き換えは、展開のより初期段階にあります。安定版を利用するユーザーはスラッシュメニューを引き続き目にする一方、ベータ版ユーザーには統合セレクターが提供される可能性があります。

この段階的な状態は、オンラインや組織内で共有される手順を複雑にする場合があります。あるバージョン向けに記録されたワークフローが、別の人の画面と一致しない可能性があります。

GemsからSkillsへの移行も、もう一つの変化を加えます。既存のカスタムアシスタントは再利用可能なSkillsになりつつあり、互換性や維持される動作についての疑問が生じています。

Googleは、使い慣れたワークフローを不安定に感じさせずに、こうした変更を管理しなければなりません。機能名の変更や呼び出し記号の変更は、小さいながらも継続的な学習コストを課す可能性があります。

同社は、一貫した@エントリーポイントがそのコストを上回ると見込んでいます。その成否は、予測可能なルーティングと明確なフィードバックにかかっています。

中心的な課題は、GoogleがGemini内により多くのツールを配置できるかどうかではありません。ユーザーが、どのツールが動作し、どのデータを使用し、どのように修正すればよいかを理解できるかどうかです。

Googleのインターフェース戦略が機能するかを示す3つのシグナル

次の試金石は、より整理されたツールメニューが、より信頼でき理解しやすい操作を生むかどうかです。

最初のシグナルは、@セレクターの完全なロールアウトです。Googleは、Android、iOS、Webで挙動を分断することなく、限定的なベータ提供の段階を超えて展開する必要があります。

ロールアウトが完了すれば、@がGeminiの恒久的なツール呼び出し言語であるとの見方が強まります。不一致が続けば、統合インターフェースという主張は弱まります。

重要なのは記号だけではありません。ユーザーは、対応デバイス全体でSkills、Connectors、その他のリソースについて同じ基本的な構成を目にするべきです。

Googleはまた、明示的な選択が自動ルーティングとどのように相互作用するかを説明しなければなりません。GeminiがSkillを選んだのはいつか、そしてユーザーの@メンションがその選択をいつ上書きしたのかを、人々は知る必要があります。

第2のシグナルは、Gemini Map toolのより広範な提供です。Web対応は、Googleが地理的選択をモバイル上の実験ではなく、主要な入力手段と見なしていることを示すでしょう。

デスクトップ利用は、旅行の調査、不動産比較、物流、イベント計画、位置情報に基づくビジネス分析に役立つ可能性があります。こうしたタスクは、大きな地図の恩恵を受けることが多いためです。

さらに重要なのは、Googleが選択した境界が実際に何を制御するのかを明らかにすることです。ユーザーは、Geminiがそのエリアを漠然とした提案として扱うのではなく、尊重するという確信を必要とします。

また、現在のGoogle Maps情報がおすすめを支えている場合、そのことを結果で開示すべきです。明確な根拠表示により、このツールは信頼・検証しやすくなります。

第3のシグナルは、SkillsとConnectorsのより深い連携です。これらのリソースが隠れた挙動を生まずに協働するとき、Googleのインターフェースはより価値を持つようになります。

ユーザーは、計画用Skillを呼び出し、Map Areaを添付し、予約用コネクタを呼び出すかもしれません。その際Geminiは、ワークフロー全体であらゆる制約を維持する必要があります。

これは厳しいテストです。システムは文脈を維持し、正しいサービスを呼び出し、復旧可能なエラーを提示し、意図しない行動を避けなければなりません。

Googleがこれまで接続サービスを拡大してきたことは、Geminiにこうしたワークフローをさらに多く担わせたいという意図を示しています。@メニューは、その拡大するカタログに共通の入口を与えます。

この変化は、チャットボットからツールを使うアシスタントへの、より広い移行も反映しています。モデルは引き続き中心的ですが、有用な作業は選択された文脈と外部システムを通じて行われる割合が高まっています。

この移行は、旅行以外のナレッジワーカーにも恩恵をもたらし得ます。優れたアシスタントは、各リクエストに関連する情報源、ワークフロー、境界を人々が指定できるようにすべきです。

同じ原則は、文書や個人情報を扱う場合にも当てはまります。personal knowledge baseは、どの文脈をタスクに取り込むかをユーザーが制御できるとき、より有用になります。

Googleの地図選択機能は、この考え方を具体化しています。アシスタントが適切な場所を推論してくれることを期待する代わりに、ユーザーが意図したエリアを指定します。

@メニューは、この原則を機能にも広げます。自動選択だけに完全に依存するのではなく、ユーザーは特定のSkillやコネクタを呼び出せます。

どちらの変更も、判断の必要性をなくすものではありません。ユーザーは引き続き重要なおすすめを検証し、権限を監視し、どのサービスが参加したかを確認する必要があります。

したがって、Gemini Map toolの重要性は、単独の地図ウィジェットとしてよりも、変化するインターフェースモデルの証拠として大きいと言えます。

Googleは、何もないプロンプトを構造化された選択肢へと置き換えています。ファイル、写真、場所、保存済みの指示、外部サービスのすべてが、可視化された要素になり得ます。

それらの要素が理解しやすいままであれば、Geminiはより長いプロンプトを必要とせず、より正確に感じられるようになります。不透明になれば、インターフェースはさらなる複雑さを隠すだけになるでしょう。

今後数か月は、@のロールアウト、Webでの地図対応、複数ツール利用時の透明性に注目してください。これらは、Googleが一貫性のあるアシスタントインターフェースを構築したかどうかを示すでしょう。

現時点では、モバイルユーザーが中心的な前提を直接試すことができます。境界が明確なエリアを選び、制約のある質問をし、その回答をGoogle Mapsと比較してください。

この比較は、新しいボタンの存在以上のことを明らかにします。Geminiが選択された地理的文脈を、有用で検証可能な結果へと変換できるかを示すものです。