AIの住所ハルシネーション：発生する理由とジオ検証データによる解決策

要点： AIアシスタントは、もっともらしいのに間違った住所を答えることがあります。特に影響を受けるのは、Web上の情報が少なく、書き方もばらばらな個人経営の施設です。対策は、Schema.orgのPlaceマークアップ、検証済みの座標、正規の外部識別子を使って、紛れのない正解を1つ公開することです。そのうえで、その施設が載っているすべてのプラットフォームで同じ情報に揃えてください。

ポルトにある三つ星ホテルの住所をChatGPTに聞けば、おそらく通りの名前、番地、郵便番号が返ってきます。答え方は自信たっぷりです。大手チェーンなら、たいていは正しい住所です。ところが、2本先の通りにある個人経営のブティックホテルについては、間違っている可能性が無視できないほどあります。

これはまれな例外ではありません。言語モデルが文章を作る仕組みから当然起きる結果で、特定の場所で見つけてもらうことが商売の前提になっている事業者には直接の影響があります。

住所のハルシネーションが起きる仕組み

言語モデルは住所のデータベースを持っていません。持っているのは、トークンの統計的な分布です。住所を聞かれると、その都市のその種類の施設の住所らしく見えるトークンの並びを予測します。

学習データの中で、本当の住所が信頼できる情報源に何度も同じ形で出てきていれば、予測は正しい文字列に落ち着きます。住所がめったに出てこない、書き方がばらばら、あるいはまったく出てこない場合、モデルは推測で補います。その地区にありそうな通り、その区画に合いそうな番地、地元の形式に合う郵便番号を選びます。

出てくる答えは文法的に正しく、地理的にもありそうで、しかも完全に間違っていることがよくあります。

リスクが最も高いのは、Web上の情報が少ない、または食い違っている施設です。1つの予約サイトにしか載っていない貸別荘は、数百の情報源に同じ住所で載っているチェーンホテルに比べて、モデルが頼れる情報がはるかに少なくなります。

具体例

説明のための質問です（物件名と住所は架空のものです）。「ポルトのゲストハウスCasa do Valeの住所は？」

よくあるハルシネーションの答え：

Casa do Valeの住所は、Rua de Santa Catarina 142, 4000-442 Porto, Portugalです。

この例での正しい住所：

Casa do Vale, Rua do Vale 38, 4200-512 Porto, Portugal.

通りも郵便番号も違い、場所は市内の反対側です。この答えを信じた宿泊客は、実際のゲストハウスから3 km離れた商業地区に向かうことになります。この間違いは偶然ではありません。Rua de Santa Catarinaはポルトで最も有名な商店街で、ポルトの宿泊に関する学習データに何度も登場します。モデルは、その都市で統計的に最も強い候補をそのまま選んでいます。

構造化データで結果が変わる理由

Schema.orgのPlaceやLodgingBusinessのJSON-LDブロックを正しく記述した掲載ページがあれば、モデルは住所を作り出さずに、そこから取り出せます。

{
  "@context": "https://schema.org",
  "@type": "LodgingBusiness",
  "name": "Casa do Vale",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Rua do Vale 38",
    "postalCode": "4200-512",
    "addressLocality": "Porto",
    "addressCountry": "PT"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 41.1621,
    "longitude": -8.5937
  },
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "wikidata",
    "value": "Q00000000"
  }
}

このブロックには、ハルシネーションを減らすうえで大事な点が3つあります。

1. 構造化されたフィールド。 モデルが文章を解析する必要はありません。通り、郵便番号、都市、国がそれぞれ別のキーになっています。
2. 住所と一致する座標。 クローラーは、緯度と経度が郵便番号のエリア内に収まっているかを確認できます。食い違っていれば、データの信頼度は低いと判断されます。
3. 変わらない外部識別子。 WikidataやGoogle Place IDが、掲載情報を正規のエンティティに結び付けます。モデルは学習データでの出現頻度に頼らず、信頼できる情報源と住所を照合できます。

この3つが揃うと、モデルは答えを作り出すのではなく、データから取り出すようになります。間違った住所を答える確率は大きく下がります。

NAPの一致

掲載ページのschemaは必要ですが、それだけでは足りません。AIシステムは、住所をほかの公開情報と照らし合わせます。Google Business Profile、OpenStreetMap、Yelp、Tripadvisor、予約サイト、そしてWeb全体です。これらが食い違うと信頼度が下がり、モデルははっきりしない答えを返したり、住所を作り出したりしやすくなります。

そのため、プラットフォーム間で名称、住所、電話番号（NAP）が一致しているかどうかは、どのシグナル単体よりも、引用されるかどうかを強く左右します。schemaが完璧でも、Google Business Profileの住所が違っていれば、結果は悪いままです。仕組みについては、地域ビジネスのためのGoogle AI OverviewsガイドのNAPの章で説明しています。

ハルシネーションのリスクを下げる方法

特に効果が大きいのは次の4つです。

1. 住所と一緒に検証済みの座標を公開する。 書かれた住所はただの文字列ですが、座標は確かめられる事実です。MapAtlasのGeocodingは、住所を大量に正確な緯度経度へ変換し、うまく特定できない入力には印を付けます。

2. 場所の情報をJSON-LDで記述する。 Place、LodgingBusiness、Hotel、Restaurant、LocalBusinessの各タイプは、どれもaddress、geo、identifierのフィールドを持てます。フィールドが欠けているところから、モデルの推測が始まります。

3. 正規の識別子に結び付ける。 掲載情報をWikidataのQIDやGoogle Place IDにリンクしてください。AIシステムが重複を見分けるための主キーになります。

4. 周辺情報を加える。 ハルシネーションは住所だけでは終わりません。モデルは近くのランドマーク、駅やバス停、徒歩での所要時間も作り出します。MapAtlasのGeoEnrichが作る検証済みの周辺データがあれば、こうした情報にも根拠ができます。AI Overviewsガイドで説明しているように、FAQPage schemaでマークアップした場所ごとのFAQは、このデータを見せる場として効果的です。

住所を間違えられることのビジネス上の損失

AIアシスタントが間違った住所を示すと、モデルが恥をかくだけでは済みません。実際の宿泊客を違う場所へ向かわせてしまいます。その影響は次々に重なります。

• 予約のキャンセル、さらに悪ければ連絡なしの不泊。
• 間違った場所について書かれた低評価のレビュー。それが次の世代のモデルの学習データになります。
• その施設が今後引用されるときの信頼度の低下。公開Webに矛盾した情報が残るためです。

ここで大事なのは、損をするのが施設の側だという点です。施設に落ち度がなくても、間違った住所は施設を傷つけます。モデルを直接直すことはできません。できるのは、モデルが住所を作り出す理由がなくなるほど、正解をはっきり示すことです。

自分の施設のリスクを確認する

無料のMapAtlas AEO Checkerは、住所のschema、座標の有無、NAPの一致、外部識別子など、29の構造化シグナルで掲載ページを評価します。これらのチェックを通る掲載情報は、AIの回答で間違って紹介される可能性がはっきり低くなります。通らない掲載情報では、モデルが推測するしかありません。

住所のハルシネーションは、特定のアシスタントだけの癖ではありません。同じ施設が数十の情報源に少しずつ違う住所で載っている、そんなオープンなWebで学習していることから当然起きる結果です。対策は、AIシステムが取り出せる形式で正解を1つ公開し、その施設が載っているほかのすべての場所でも同じ情報に揃えることです。

関連記事：

• 地域ビジネスのためのGoogle AI Overviews
• AI可視性スコアを無料でチェック