TL;DR: AI アシスタントはもっともらしいが誤った住所を生成します。チェーンホテルで約 6%、独立系バケーションレンタルでは 38% という確率です。対処すべきはモデルではありません。Schema.org の Place マークアップ、検証済み座標、正規の外部識別子を用いて一意のグラウンドトゥルースを公開し、事業が掲載されるすべてのプラットフォームで同じ情報を一貫して保ちます。
ポルトの三つ星ホテルの住所を ChatGPT に尋ねれば、通り名、番地、郵便番号をおそらく返してきます。その回答は自信ありげに聞こえます。大手チェーンなら通常は正しいでしょう。しかし、二本先の通りにある独立系ブティックホテルについては、回答が間違っている確率が無視できないレベルであります。
これはまれなエッジケースではありません。言語モデルがテキストを生成する仕組み上、予測可能な出力であり、特定の場所で見つけられることに事業が依存している人にとっては直接の影響があります。
位置ハルシネーションの仕組み
言語モデルは住所のデータベースを持っていません。持っているのはトークン上の統計分布です。住所を尋ねられると、その都市でその種類の施設にふさわしく見えるトークン列を予測します。
訓練データに実在する住所が、権威あるソース全体で、一貫して、何度も登場していれば、予測は正しい文字列に収束します。住所がまれにしか出ない、一貫性がない、あるいは全く登場しない場合、モデルは補間します。そのエリアに似合う通り、そのブロックにありそうな番地、地元のパターンに合う郵便番号を選ぶのです。
出力は文法的には正しく、地理的にはもっともらしく、そしてしばしば完全に間違っています。
サンプル監査: クエリタイプ別ハルシネーション率
2026 年 4 月、主要な AI アシスタント 3 つに対して 500 件の位置クエリを実行しました。各クエリは特定の施設の住所を尋ねるものです。回答は、MapAtlas GeoEnrich に登録された施設の検証済み住所と照合しました。
下表は、少なくとも 1 つの実質的な住所エラー（通り違い、番地違い、郵便番号違い、または都市違い）を含む回答の割合を示します。数値は方向性を示すもので、このサンプルに特有のものです。
| クエリタイプ | ChatGPT | Perplexity | Gemini |
|---|---|---|---|
| チェーンホテル | 6% | 4% | 7% |
| 独立系ブティックホテル | 19% | 14% | 22% |
| バケーションレンタル | 38% | 29% | 41% |
| 独立系レストラン | 24% | 18% | 27% |
| ランドマーク・観光地 | 9% | 5% | 8% |
出典: MapAtlas サンプル監査、2026 年 4 月、n=500 クエリ。
2 つのパターンが目立ちます。第一に、施設のウェブ上のフットプリントがまばらで一貫性がないほどハルシネーション率が上がります。独立した自社サイトを持たず、単一のリスティングプラットフォームにしか存在しないことが多いバケーションレンタルが最も影響を受けます。第二に、Perplexity は一貫してハルシネーションが少ない傾向があります。これは検索層がパラメトリックな記憶ではなくライブソースに多くの回答を基づかせているためでしょう。
具体例
2026 年 4 月に出したクエリ: 「ポルトの Casa do Vale ゲストハウスの住所は？」
主要アシスタントからのハルシネーション回答:
Casa do Vale は Rua de Santa Catarina 142, 4000-442 Porto, Portugal にあります。
物件自身の記録と MapAtlas Geocoding による検証済みの回答:
Casa do Vale, Rua do Vale 38, 4200-512 Porto, Portugal。
通りも郵便番号も、都市の逆側、すべて違います。ハルシネーションされた住所は、実際のゲストハウスから 3 キロ離れた商業地区にゲストを向かわせてしまいます。誤りはランダムではありません。Rua de Santa Catarina はポルトで最も有名な商業通りで、ポルトの宿泊に関するクエリの訓練データに頻繁に登場します。モデルはその都市に対する最も強い統計的事前分布にフォールバックしたのです。
構造化データが結果を変える理由
適切に構成された 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 つの特性があります。
- 構造化されたフィールド。 モデルは文章を解析する必要がなく、通り、郵便番号、都市、国が別々のキーになっています。
- 住所と一致する座標。 クローラは緯度経度が郵便番号のポリゴン内に収まるかを検証できます。不一致はデータを低信頼度としてフラグします。
- 安定した外部識別子。 Wikidata や Google Place ID はリスティングを正規のエンティティに紐付けます。モデルは訓練データの頻度に頼らず、権威あるソースに対して住所を照合できます。
この 3 つの条件が揃うと、生成の代わりに抽出が行われ、ハルシネーション回答の確率は大きく下がります。
NAP 整合性レイヤー
リスティングページ上の schema は必要ですが十分ではありません。AI システムは、住所を他の公開ソース、Google Business Profile、OpenStreetMap、Yelp、Tripadvisor、予約プラットフォーム、オープンウェブなどと相互にチェックします。これらが食い違うと信頼度が下がり、モデルは濁した回答をしたり生成に走ったりする可能性が高くなります。
だからこそ、プラットフォーム間の Name、Address、Phone（NAP）の整合性は、単一シグナルよりも引用の強力な予測因子になります。schema が完璧でも Google Business Profile 上の住所が矛盾していれば、引用率は低いままです。詳しくは AI 検索における 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 が生成する検証済みの近接データは、これらの主張も固定します。位置特化 FAQ はこのデータを露出させる有効なサーフェスです。
住所ハルシネーションのビジネスコスト
AI アシスタントが提示する誤った住所は、モデルを気まずくさせるだけではありません。実在のゲストを間違った場所へ送り込みます。下流の影響は積み重なります。
- キャンセル、あるいはもっと悪いノーショー。
- 誤った場所について書かれたネガティブレビュー。それが次世代モデルの訓練データになります。
- リスティング自体の将来の引用信頼度の低下。公開ウェブ上に矛盾するシグナルが存在することになるためです。
この非対称性は重要です。ハルシネーションされた住所は、リスティング自体に非がなくてもリスティングを傷つけます。解決策はモデルを直接修正する（それは不可能です）のではなく、モデルに生成する理由を与えないほどグラウンドトゥルースを曖昧さなく提供することです。
自分のエクスポージャーを確認する方法
無料の MapAtlas AEO Checker は、住所 schema、座標の有無、NAP 整合性、外部識別子を含む 29 の構造化シグナルに対してリスティングを評価します。これらをパスするリスティングは、AI の回答で誤って提示される可能性が有意に低くなります。失敗するのは、モデルが推測せざるを得ないリスティングです。
位置ハルシネーションは、どれか特定のアシスタントに特有のクセではありません。同じビジネスが数十のソースで微妙に異なる住所で現れるオープンウェブで訓練されることの、予測可能な帰結です。解決策は、AI システムが抽出できる形式で唯一のグラウンドトゥルースを公開し、そのビジネスが表現される他のすべての場所でも一貫させることです。
関連記事:
よくある質問
AI の住所ハルシネーションとは何ですか？
AI の住所ハルシネーションとは、大規模言語モデルが、もっともらしく見える具体的な番地、郵便番号、座標を返すものの、それが説明対象のビジネス、ランドマーク、物件の実際の位置とは一致しない状態を指します。小さな丸め誤差ではありません。モデルは、存在しない住所、別の施設に属する住所、あるいは実在する通り名と間違った都市を組み合わせた住所を合成しています。リスティングにとって特に有害で、ユーザーが回答が捏造だったと気付く前に間違った場所へ移動してしまう可能性があるためです。
AI アシスタントはなぜ住所をハルシネーションするのですか？
言語モデルは、事実をルックアップしているのではなく、最も確率の高い次のトークンを予測してテキストを生成します。住所がウェブ上で十分に露出していなかったり、記述が一貫していなかったり、クロールがブロックされていたりすると、モデルは統計的にもっともらしい文字列で空白を埋めます。その都市にありそうな通り名、その地域のパターンに合う郵便番号、それらしい番地といったものです。グラウンドトゥルースとなる構造化ソースがなければ、モデルには記憶された事実と生成された内容を区別する手段がありません。
位置ハルシネーションは実際どの程度の頻度で起こるのですか？
2026 年 4 月に MapAtlas が実施したサンプル監査では、ホテル、バケーションレンタル、レストラン、ランドマークを対象にした 500 件の位置クエリにおいて、住所レベルのハルシネーション率は、知名度の高いチェーンホテルで約 6%、独立系バケーションレンタルで 38% となりました。一般的なランドマーククエリは最も成績が良く、ロングテールのリスティングクエリは最も悪い結果となりました。数値は方向性を示すもので、モデル、言語、元データの鮮度によって変動しますが、傾向は一貫しています。施設が公開している構造化データが少ないほど、モデルは多く捏造します。
Schema.org の構造化データはハルシネーションを減らしますか？
はい。ただしデータが検証済みで、各ソース間で整合している場合に限ります。正確なジオ座標、検証済みの郵便住所、Wikidata や Google Place ID などの権威ある識別子への相互参照を含む Place または LodgingBusiness の JSON-LD ブロックを公開すれば、モデルが抽出して引用できるグラウンドトゥルースのアンカーを提供できます。座標と書かれた住所が食い違うような不整合な schema は、むしろ信頼度を下げる傾向があります。
自分のリスティングのハルシネーションリスクをどう監査すればよいですか？
リスティングの URL を mapatlas.eu/ai-seo-checker の無料 MapAtlas AEO Checker に通してください。このチェッカーは、AI システムが位置情報の事実を固定するために用いる 29 の構造化シグナルを評価します。ジオ座標、Place schema、プラットフォーム間の NAP 整合性、周辺コンテキストフィールドの有無などが含まれます。これらのシグナルが欠けているページは、モデルが抽出ではなく推測せざるを得ないため、ハルシネーションリスクのスコアが高くなります。
