台湾でLocalBusinessスキーマを実装したのに、AIエンジンの回答に取り上げられない。その原因は、プログラムコードではなく、データの不一致にあるかもしれません。ユーザーがPerplexityやChatGPTに「台北市信義区でおすすめの歯科医院はありますか」と尋ねると、AIはまず、公式サイトに掲載された名称・住所・電話番号を、Google ビジネス プロフィール、地図、業界ディレクトリの情報と照合します。そこで3つの異なる表記が見つかれば、どれが正しいかを推測するより、回答に含めない判断をしやすくなります。つまり、引用されるかどうかを実質的に左右するのは、NAP（名称・住所・電話番号）の整合性です。スキーマ構文は、その事実を機械が読める形式にまとめる手段にすぎません。本記事では、タイプの選択、住所の入力、営業時間の記述、各プラットフォームのNAP統一という順に、実装方法を解説します。
AIエンジンがLocalBusinessの情報を重視する理由
AIエンジンが地域に関する質問へ回答するには、「店舗はどこにあるのか」「現在営業しているのか」「電話番号は何番か」といった、明確に抽出できる事実が必要です。中国語の住所表記は、機械にとって必ずしも扱いやすくありません。「台北市信義路5段7号」と「台北市信義区信義路5段7号」は、人には同じ場所だと分かっても、抽出モデルには別のエンティティとして認識される可能性があります。LocalBusinessスキーマでは、こうした情報を固定フィールドに分けて明示できます。いわば、推測や照合の手間を省き、エンジンへ直接答えを渡す仕組みです。推測すべき点が少ないほど、AIはその事業者を回答に含めやすくなります。
ステップ1：@typeを正しく選び、すべてをLocalBusinessで済ませない
schema.orgでは、LocalBusinessの下に数十種類のサブタイプが用意されています。タイプが具体的であるほど、エンジンは事業内容を正確に理解できます。たとえば会計事務所を汎用的なLocalBusinessとして指定する場合と、AccountingServiceとして指定する場合では、「探している専門サービスに該当するか」というAIの判断に大きな差が生じます。まずは自社の事業に最も近いサブタイプを探し、どうしても見つからない場合に限り、上位の汎用タイプを使いましょう。
- レストラン、カフェ：Restaurant、CafeOrCoffeeShop
- 歯科医院、クリニック：Dentist、MedicalClinic
- 弁護士、土地登記代理業者：Attorney、LegalService
- 会計・記帳代行事務所：AccountingService
- 小売店：Store。ClothingStore、HardwareStoreなど、さらに細分化できます
- 美容サロン、ヘアサロン：BeautySalon、HairSalon
- 該当するタイプが本当にない場合に限り、汎用のLocalBusinessを使用します
住所フィールド：台湾の行政区分をPostalAddressへ割り当てる
住所は、特に記述ミスが起きやすい項目です。PostalAddressには所定のフィールドがあるため、台湾の行政区分を一つずつ対応させる必要があります。住所全体をstreetAddressへ詰め込むと、エンジンが県・市や行政区を正しく抽出できません。
- addressCountry：国名ではなく、国コード「TW」を入力します
- addressRegion：直轄市または県を入力します。例：「台北市」「新北市」
- addressLocality：区または郷鎮市を入力します。例：「信義区」
- streetAddress：道路名、段、巷、号を入力します。例：「信義路5段7号」
- postalCode：3+3桁の郵便番号を入力します。例：「110011」
- geo：緯度・経度を入力します。座標はGoogle マップ上のピン位置と一致させてください
営業時間：openingHoursSpecificationを正しく記述する方法
営業時間にはOpeningHoursSpecificationを使い、dayOfWeekで曜日ごとの時間帯を指定します。opensとclosesは24時間表記のHH:MMで記述してください。昼休みのある店舗であれば、09:00から21:00までと連続して書かず、11:00–14:00と17:00–21:00のように2つの時間帯へ分けます。そうしないと、AIが午後3時も営業中だと案内してしまいます。祝日が休業日なら、その日は記載しません。24時間営業の場合は、opensとclosesの両方に00:00を入力します。旧正月や国民の祝日などに伴う一時的な変更には、通常の営業時間を直接書き換えるのではなく、specialOpeningHoursSpecificationで対象日を指定するほうが安全です。変更後は、Google ビジネス プロフィールの特別営業時間にも必ず反映し、双方の情報を一致させてください。
NAPの整合性：スキーマは情報網を構成する一つの接点にすぎない
どれほど丁寧にスキーマを記述しても、ほかの掲載情報と一致していなければ効果は損なわれます。名称・住所・電話番号は、句読点や書式も含め、各プラットフォームで同じ表記に揃えてください。特に混乱しやすいのが電話番号です。公式サイトでは「02-1234-5678」、Google ビジネス プロフィールでは「(02)12345678」、スキーマでは「+886-2-1234-5678」と記載されている場合、人には同じ番号でも、機械には3つの異なる情報に見えることがあります。構造化データでは、E.164形式の「+886212345678」に統一することをおすすめします。人が見る画面では読みやすい形式に整えても構いませんが、スキーマ内の表記は1種類に限定してください。
- Google ビジネス プロフィール
- 公式サイトのスキーマ、フッター、お問い合わせページ
- Facebook、Instagramのビジネスページ
- Apple マップおよび各種ナビゲーションプラットフォーム
- 業界ディレクトリおよび地域別イエローページ
クライアントのローカル事業者サイトを監査すると、最も多く見つかる問題はスキーマの欠如ではありません。同じ電話番号が、4つのプラットフォームで4通りに記載されていることです。AIエンジンから見れば、それは1店舗ではなく、よく似た4店舗に映ります。— Tenten GEO audit notes
公開前の確認チェックリスト
- Google リッチリザルト テストを使い、スキーマを解析でき、エラーがないことを確認する
- Schema Markup Validatorで各フィールドの構文を確認する
- スキーマ内のNAPとGoogle ビジネス プロフィールのNAPをそのまま並べ、表記の不一致がないか照合する
- AIエンジンへ実際に地域に関する質問を行い、回答された住所と営業時間が正しいか確認する
- 公開後も定期的に再確認する。住所や電話番号を変更した場合は、すべてのプラットフォームへ同期する
LocalBusinessスキーマの難しさは、JSON-LDそのものではありません。十数ものプラットフォームに分散した事実を、長期にわたって一致させ続けることにあります。自社のNAPと構造化データがAIエンジンから何店舗分の情報に見えているのか分からない場合は、Tenten GEOの30日間GEO監査で不一致をまとめて洗い出せます。まずは方向性を短時間で確認したい方には、30分間のGEO診断もご用意しています。実際のWebサイトのURLを使い、ローカル検索を実施します。
