Google Ask Maps と Gemini：位置属性がローカル可視性を決める理由

2026 年 3 月 12 日、Google は Maps の初回リリース以来、ローカル検索において最も大きな変更を公開しました。Ask Maps は Google Maps に直接組み込まれた Gemini 搭載の会話型 AI レイヤーで、米国とインドの Android および iOS でライブになりました。Google がビジネス プロフィールの静的な Q&A セクションを廃止してから 3 か月後に登場し、さらに一歩進んで、場所を列挙するだけでなく「推論する」自然言語インターフェースを提供します。

ユーザーはもう「カフェ 渋谷」と打ちません。「近くでWi-Fiが速くてテラス席があって美味しいパンがある、朝7時前に開いているカフェ」と質問します。Ask Maps は 3 億か所以上の場所に関する情報を活用し、属性とクエリを照合して、厳選されたおすすめ結果を返します。青いリンクの羅列でも、マップグリッドのスクロールでもありません。直接的で自然な回答です。

これはローカルビジネスの発見のされ方を根本から変えます。そして、豊富な位置データを持つビジネスが選ばれるようになっています。

Ask Maps の仕組み

従来の Google Maps 検索は 3 つの軸で動作していました。近接性、レビュー、キーワード関連性です。Ask Maps はここに 4 つ目の軸を加えます。属性マッチングです。これがゲームを変える次元です。

ユーザーが「モンマルトル近くの静かな中庭と地下鉄アクセスのよいブティックホテル」と質問すると、Ask Maps は単純に半径内でホテルをフィルタリングしません。クエリを構造化された意図に分解します。

• エンティティタイプ：ホテル（ブティック）
• 地理的アンカー：パリ、モンマルトル地区
• 設備要件：静かな中庭
• 交通要件：良好な地下鉄アクセス

そして各候補リスティングのデータをスキャンし、それぞれの条件を確認または否定できる検証可能なシグナルを探します。「パリ中心部に位置」としか書いていないホテルは、Ask Maps に何の手がかりも提供しません。「Abbesses 駅（12 号線）から 180 メートル、モンマルトル地区 Rue Lepic 沿い、街路騒音から遮断された中庭」と記載されたホテルは、すべてを提供します。

つまり会話型クエリでは、データの完全性がレビュー数と同じくらい重要になります。レビューが少なくても周辺情報が記載されたリスティングのほうが、よりよい一致になり得ます。

「薄い位置データ」が実際に意味すること

多くのビジネスは自分のリスティングデータに問題はないと思っています。営業時間、写真、レビューが揃った Google ビジネス プロフィールがあり、ウェブサイトのフッターに住所もある。キーワードベースの Maps 検索ではそれで十分でした。Ask Maps では不十分です。

薄い位置データとは、リスティングが「あなたは何ですか？」という問いには答えていても、「あなたの近くはどんな環境ですか？」という問いには答えていない状態です。具体的には、以下の情報が不足しています。

周辺コンテキスト。 リスティングには「バルセロナ」とあるが「ボルン地区、サンタ・マリア・デル・マルから 200 メートル」とはない。Ask Maps が「ボルン地区のレストラン」「ゴシック地区近くのホテル」といったクエリとマッチさせるには、地区レベルの粒度が必要です。

交通機関の近接性。 住所はあるが、最寄りの地下鉄駅、バス停、路面電車の路線と徒歩距離についてのデータがない。旅行者が「公共交通機関が便利なホテル」を探しても、あなたのリスティングはマッチする根拠がありません。

近隣スポットの参照。 リスティングは単独で存在していて、周囲に何があるかについての構造化データがない。ビーチ、公園、博物館、ショッピングエリア、病院、空港。Ask Maps はランドマークや周辺スポットを参照するクエリとマッチさせることができません。

具体的な設備属性。 Google ビジネス プロフィールに「Wi-Fi：あり」とあっても速度についての情報がない。スキーママークアップに「プール」とあっても、室内か屋外か、加熱式か季節限定かが不明。Ask Maps は具体性を扱えます。クエリと同じ精度でマッチするリスティングが勝ちます。

徒歩距離データ。 「ビーチの近く」は測定不能です。「Barceloneta ビーチまで 340 メートル、徒歩 6 分」は Ask Maps に検証可能な距離を提供します。

Ask Maps が最も重視する 5 つの地理属性

Google は Ask Maps が属性をどう重み付けしているかを公表していませんが、次の 5 つの位置データのカテゴリは、人が会話型の場所クエリを表現する方法にそのまま対応しています。

1. 交通機関停留所の近接性（徒歩距離付き）

交通は会話型の場所クエリに頻繁に登場します。「駅近」「交通便利」「車なしで移動しやすい」は会話型の場所クエリで最も頻繁に使われる条件のひとつです。最寄り駅名・路線・徒歩距離を構造化データとして記載したリスティングは測定可能な優位性を持ちます。

記載すべき内容： 最寄り地下鉄駅の名称、路線番号、メートルと分での徒歩距離。バス停や電車の停留所についても同様に。例：「Fontana 駅（L3）、徒歩 4 分（320m）」

2. 地区・エリアの特定

Ask Maps は地区を空間的な単位として理解します。「Kreuzberg のレストラン」「マレ地区のホテル」というクエリには、市区町村レベルの住所だけでなく、明示的な地区との関連付けが必要です。

記載すべき内容： 地区名やエリア名、有名なサブエリアとの位置関係。containedInPlace スキーマを使い、ビジネス説明にも地区名を含めてください。

3. 近くのランドマーク・スポットまでの距離

観光・宿泊系のクエリでは、ランドマークとの距離が中核的なマッチシグナルになります。「コロッセオ近くのホテル」「セントラルパーク近くのアパート」「エッフェル塔まで歩いて行けるレストラン」。主要スポットへの検証済み距離を埋め込むことで、Ask Maps は具体的な数値で照合できます。

記載すべき内容： 最も関連性の高い 5〜10 件の近隣スポットへの徒歩距離（メートルと分）。観光スポット、ビーチ、公園、ショッピングエリア、病院、空港など。

4. 設備の具体性と網羅性

Ask Maps は「プールあり」と「一年中利用できる加熱式屋外プールあり」を区別します。設備データが具体的・網羅的であるほど、マッチできるクエリが増えます。設備データは文章の説明に埋め込まずに、amenityFeature スキーマ配列として構造化してください。

記載すべき内容： 検索可能なすべての設備と具体的な詳細。「駐車場」ではなく「無料敷地内駐車場 2 台分」。「Wi-Fi」ではなく「無料 Wi-Fi、200Mbps」。「レストラン」ではなく「自営レストラン、朝食 7:00〜10:30、夕食 18:00〜22:00」。

5. 周辺エリアの密度シグナル

Ask Maps は周辺エリアの密度と特性も評価します。レストランが集積したエリアにある物件は「飲食の選択肢が多い場所」というクエリへの信頼性が上がります。閑静な住宅街にある物件は「観光客の喧騒から離れた静かな場所」にマッチします。この密度シグナルを手作業で構築するのは困難ですが、地理データ API がまさにこれを生成します。

記載すべき内容： データに裏付けられた周辺エリアの特性描写。レストラン密度、ナイトライフの集中度、緑地との近接性、商業用途・住宅用途の比率。

比較：GeoEnrich データあり・なしのホテルリスティング

具体的なシナリオを見てみましょう。リスボンの Alfama 地区にあるブティックホテルで Ask Maps 最適化を行います。

最適化前：薄いリスティングデータ

{
  "@context": "https://schema.org",
  "@type": "Hotel",
  "name": "Casa do Alfama",
  "description": "リスボンの中心に位置する魅力的なブティックホテル。",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Rua de São Miguel 15",
    "addressLocality": "Lisbon",
    "postalCode": "1100-544",
    "addressCountry": "PT"
  },
  "amenityFeature": [
    { "@type": "LocationFeatureSpecification", "name": "WiFi", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "Air Conditioning", "value": true }
  ]
}

このリスティングは「リスボンのホテル」というクエリにはマッチします。しかし「ファド博物館近く、28 番トラムが近い Alfama 地区の静かなホテル」にはマッチしません。実際にそのホテルがそのような場所にあっても関係ありません。

最適化後：GeoEnrich データで強化

{
  "@context": "https://schema.org",
  "@type": "Hotel",
  "name": "Casa do Alfama",
  "description": "リスボン最古の地区 Alfama に位置するブティックホテル。ファド博物館まで 150 メートル、28 番トラム停留所（Largo das Portas do Sol）まで 90 メートル、Santa Apolónia 駅（地下鉄・鉄道）まで徒歩 5 分。専用中庭に面した静かな内側の客室。タグス川を望む屋上テラス。",
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 38.71120,
    "longitude": -9.12870
  },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Rua de São Miguel 15",
    "addressLocality": "Lisbon",
    "postalCode": "1100-544",
    "addressCountry": "PT"
  },
  "containedInPlace": {
    "@type": "Place",
    "name": "Alfama",
    "address": {
      "@type": "PostalAddress",
      "addressLocality": "Lisbon",
      "addressCountry": "PT"
    }
  },
  "amenityFeature": [
    { "@type": "LocationFeatureSpecification", "name": "Free WiFi", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "Air Conditioning", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "Rooftop Terrace", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "River View Rooms", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "Quiet Interior Courtyard", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "Daily Breakfast", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "Luggage Storage", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "24-Hour Reception", "value": true }
  ],
  "hasMap": "https://maps.google.com/?cid=YOUR_CID"
}

強化されたこのリスティングは、「Alfama の静かなホテル」「ファド博物館近くのホテル」「28 番トラム近くのホテル」「川の見えるリスボンのブティックホテル」「Santa Apolónia 駅近くのホテル」など、数十種類の自然言語クエリにマッチするようになりました。カバーできるクエリ数が 1 件から数百件へと広がりました。

今日リスティングデータを診断する方法

新しいデータを追加する前に、現状を把握しましょう。リスティング URL を MapAtlas AEO Checker にかけてください。AI システム（Ask Maps を含む）が実際に参照する構造化データシグナルを評価します。多くのビジネスで共通して発見される課題は次の通りです。

1. 座標情報がない。 スキーマに geo ブロックがないか、GBP のピン位置と座標が一致していない。
2. 地区の関連付けがない。 市区町村レベルの住所のみで、containedInPlace や地区参照がない。
3. 設備配列が空か最低限。 具体的なリストではなく、2〜3 件の汎用的な設備しか記載されていない。
4. 距離データがない。 近隣 POI・交通機関停留所・ランドマークへの構造化参照がゼロ。
5. 説明文とスキーマの不一致。 ウェブサイトの文章には近隣スポットが書かれているが、Ask Maps が解析できる構造化マークアップには反映されていない。

AEO Checker はこれらのギャップをひとつひとつフラグ立てし、リスティングの AI 対応度を 0〜100 でスコアリングします。これで、変更の効果を測るためのベースラインが得られます。

MapAtlas API を使った実装手順

データギャップを埋めるための具体的なワークフローを紹介します。

ステップ 1：GeoEnrich で位置コンテキストを生成する

GeoEnrich API は座標ペアを受け取り、構造化された位置コンテキストを返します。地区名、カテゴリと徒歩距離付きの近隣 POI、路線情報付きの交通機関停留所、エリア密度の特性、ランドマークとの距離です。1 回のリクエストで、手作業なら数時間かかるデータが、Schema.org マークアップに対応付けられる構造化オブジェクトとして返ってきます。

ステップ 2：スキーママークアップを構築する

GeoEnrich の出力を使って、完全な LocalBusiness・Hotel・Restaurant・VacationRental スキーマブロックを構築します。含めるべき内容：

• geo：小数点以下 5 桁以上の精密な座標
• containedInPlace：GeoEnrich から取得した地区名
• 完全な amenityFeature 配列（具体的な属性付き）
• description：検証済みの距離とランドマーク参照を盛り込んだもの
• sameAs：GBP・SNS プロフィール・ディレクトリへのリンク
• hasMap：Google Maps のリスティングへのリンク

ステップ 3：Google ビジネス プロフィールを更新する

GBP でも構造化データを反映します。

• カテゴリで利用可能であれば、具体的な設備属性を追加する
• 同じ近接距離データをビジネス説明文に反映する
• ピン位置がスキーマの座標と完全に一致していることを確認する
• あなたの市場で Google が許可していれば、住所に地区名を追加する

ステップ 4：モニタリングと継続改善

Ask Maps は生きているシステムです。Google は定期的に基盤モデルを更新しており、他のビジネスが最適化を進めることで競合環境も変化します。毎月 AEO Checker でスコアを追跡してください。近隣に新しいスポットが登場した際（新駅、新ランドマーク、新しい人気スポット）は GeoEnrich を再実行してスキーマを更新しましょう。

ステップ 5：ポートフォリオ全体に展開する

複数のリスティングを管理している場合（ホテルチェーン、飲食グループ、不動産ポートフォリオ）、GeoEnrich API は座標をバッチ処理できます。ロケーションデータベース全体を API に通し、1 回のパスですべてのリスティングの強化スキーマを生成してください。Ask Maps での可視性向上が最も速いビジネスは、旗艦店 1 件だけでなくポートフォリオ全体を強化したビジネスです。

機会の窓は閉じつつある

Ask Maps は 2026 年 3 月に公開され、8 月には 150 以上の国に広がりました。Google はこれまでのところ広告を入れていません。ランキングは完全にオーガニックでデータ駆動です。今リスティングデータを強化するビジネスは、時間とともに複利的に蓄積されるマッチ履歴を構築しています。Ask Maps があなたのリスティングをクエリに成功裏にマッチさせるたびに、そのクエリパターンとあなたのリスティングの関連性が強化されます。

6 ヶ月後、競合他社が追いつこうとする頃には、先行者はすでに数千件の成功マッチ実績を積み上げています。このギャップを埋めるには相当な時間と労力が必要です。

GeoEnrich API がデータを生成します。AEO Checker がベースラインを測定します。実作業はリスティングごとに一度のスキーマ更新です。それが生み出す競争優位性は継続します。

Ask Maps は稼働中です。クエリは今この瞬間も発生しています。唯一の問いかけは、あなたのリスティングが選ばれるためのデータを持っているかどうかです。

関連記事：

• ローカルビジネスの AI 引用に使う JSON-LD スキーマ
• AI 可視性スコアを無料でチェックする