住所の表記ゆれ一つで、AIから「別の会社」に見られます

AIO（AI Optimization／AIに正しく理解・引用されるための最適化）やLLMO（LLM Optimization／大規模言語モデルに情報を正しく参照させるための最適化）の観点で会社概要ページを見ると、「住所や電話番号を書いているかどうか」より先に、「AIが機械的に読み取れる形で書いているかどうか」が問われます。この記事では、schema.org（検索エンジンやAI企業が共同で策定している構造化データの語彙規格）が定めるLocalBusiness（実店舗や事務所を持つ事業者を表すスキーマの型）を軸に、NAP（Name・Address・Phone＝会社名・住所・電話番号の略称）の表記ゆれがなぜ問題になるのかを、Before/After形式で診断します。

1. なぜ「住所を書いている」だけでは足りないのか

AIがWebページの情報を扱う際は、RAG（Retrieval-Augmented Generation／検索拡張生成。AIが回答を作る前に外部の情報を検索・参照する仕組み）という方法がよく使われます。このときページ全体をそのまま読むのではなく、いったんチャンク（文章をいくつかの塊に分割したもの）に区切ってから、必要な部分だけを取り出して参照します。

自然文（人間向けにそのまま書かれた文章）の住所表記は、全角と半角の混在、「丁目」「番」「号」の書き方の違い、ビル名を入れる・入れないなど、表記のゆれが起きやすい形式です。チャンクに区切られる過程でこのゆれがそのまま残ってしまうと、AIにとって「これは会社の住所である」という認識精度が下がります。一方、JSON-LD（構造化データをHTML内に埋め込むための記述形式の一つ）で会社名・住所・電話番号を明示しておけば、自然文側の表記が多少ゆれていても、AIはJSON-LD側の値を機械的に正確な情報として優先的に参照しやすくなります。

2. Googleが求める必須プロパティは、たった2つ

Google Search Central（Google検索の公式ドキュメントサイト）のLocalBusinessに関するガイドでは、必須（Required）とされているプロパティはname（会社名）とaddress（住所）の2つのみです。telephone（電話番号）、openingHoursSpecification（営業時間）、priceRange（価格帯）、geo（緯度経度）、url（サイトURL）などは推奨（Recommended）プロパティという位置づけになっています。

必須項目がたった2つというのは、裏を返せば実装のハードルは決して高くないということでもあります。にもかかわらず、この2つすら構造化データとしては実装せず、ヘッダーやフッターの装飾テキストとしてしか書いていないサイトが多く見られます。

3. ページごとの表記ゆれが「同じ会社」の認識を狂わせる

フッターでは「福岡市中央区○○1-2-3」、お問い合わせページでは「福岡市中央区○○一丁目2番3号」というように、同じサイトの中でも住所の書き方がページごとに微妙に違っているケースは珍しくありません。電話番号のハイフンの有無、会社名の「株式会社」を前に付けるか後ろに付けるかといった違いも同様です。

人間であれば「どちらも同じ会社の情報だろう」と自然に判断できますが、AIやGoogleがエンティティ（人物・組織・場所など、固有の実体として認識される情報の単位）を同定する際には、表記が揺れているほど「同一のエンティティである」という確信度が下がるリスクがあります。サイト内で表記が割れていること自体が、AIにとっての判断材料を曖昧にしてしまうということです。

4. geo（緯度経度）まで入れている会社はまだ少ない

schema.orgのLocalBusinessには、GeoCoordinates（緯度・経度を表すデータ型）を使ったgeoプロパティも用意されています。Googleのガイドでは、geoを含める場合は小数点以下5桁以上の精度が必要と明記されています。位置情報を伴う質問（例えば「福岡でAIO対策の会社」といった検索や問いかけ）にAIが答える際、この精度が参照の正確さに影響する可能性があります。

geoは必須ではなく推奨プロパティですが、実際に緯度経度まで構造化データに入れている企業サイトはまだ多くありません。name・addressという必須の2項目を満たしたうえで、telephone・url・geoといった推奨プロパティへと段階的に広げていくのが現実的な進め方です。

5. NAP表記ゆれチェックリスト

6. よくある質問