LocalBusiness schemaの実装｜店舗情報で差がつく3つの判断【図解つき】

「店舗ページに構造化データを入れておいて」と言われた。けれど公式ドキュメントを開くと、英語のプロパティ名が並んでいて、どこから手をつけるかが決まらない。

しかもLocalBusinessという型は、調べるほど話が広がっていきます。業種ごとに別の型がある。店舗が複数あるときは書き方が変わる。部門を表すプロパティまである。

この記事は、店舗ページのLocalBusiness schemaを今日はじめて触る方を想定して書きました。必須の項目から始めて、業種別サブタイプの選び方、複数店舗と部門の書き分け、公開したあとの見直しまで、順番に進みます。

この記事では、ある会社で店舗ページを見ている2人と、専門家の会話をはさみながら進めます。近い立場の人の質問から読んでいただいて構いません。

• 若葉さん（Web担当2年目）— 「そもそも、それって何ですか？」を聞く役
• 高梨課長（マーケ課長）— 「誰が、どこまでやるんですか？」を聞く役
• 鈴木さん（AIO/SEOの専門家・本誌監修）— 答える役

01そもそもLocalBusiness schemaの実装って、AI検索対策では何をするんですか？

若葉さん

若葉さんの発言

あの…そもそもなんですが、LocalBusiness schemaって、店舗ページに住所を書き足す作業なんでしょうか。

鈴木さん

鈴木さんの発言

住所そのものは、もうページに書いてありますよね。同じ内容を、機械が読み違えない形でもう一度言い直しておく作業だと思ってください。

schema.orgは、LocalBusinessを「特定の物理的なビジネス、または組織の支店」を表す型として定義しています（出典: schema.org）。レストランや美容室、クリニックのように、物理的な拠点を持つ事業者が対象です。

この型には、ほかの構造化データにはない特徴があります。Organization（組織）とPlace（場所）という2つの型を、同時に継承している点です（出典: schema.org）。正式には Thing > Organization > LocalBusiness と、Thing > Place > LocalBusiness という2本の経路をたどります。

言いかえると、会社としての顔と、場所としての顔を、1つの型でまとめて名乗れるということです。会社としての顔は名称や連絡先。場所としての顔は、住所や座標、営業時間にあたります。

02LocalBusiness schemaの実装で必須なのは、AI検索最適化として何と何ですか？

必須プロパティは、nameとaddressの2つだけです（出典: Google公式）。残りは、自社に該当するものを足していく形になります。

ただし、addressには書き方の決まりがあります。住所の文字列を1行そのまま入れる欄ではありません。PostalAddress型を入れ子にして書きます（出典: schema.org）。中身はstreetAddress・addressLocality・addressRegion・postalCode・addressCountryに分かれます。

addressCountryには、ISO 3166-1のアルファベット2文字コード（日本ならJP）が推奨されています（出典: schema.org）。

03推奨プロパティは、LocalBusiness schemaのAI検索対策でどこから埋めるんですか？

必須が少ないぶん、Google公式は推奨プロパティを挙げています。よく使うものを表にまとめます。

この表を上から順に埋めていく必要はありません。まず必須の2つ、次にどの店にも当てはまる欄、最後に業種で分かれる欄、という順に考えると迷わなくなります。menuとservesCuisineは飲食店向けのプロパティです（出典: Google公式）。

レビューまわりには、実装の前に知っておきたい前提があります。Google公式は、対象企業が自社サイト上で自らレビューを管理している場合、LocalBusinessとOrganization型を星評価の対象外としています（出典: Google公式）。自社サイトに自己申告のレビューを載せてマークアップしても、星評価としては扱われません。条件の詳細は、別記事『Review・AggregateRating schemaの実装手順』で確認してください。

04業種別サブタイプの選び方は、LocalBusiness schemaのAI対策でなぜ大事なんですか？

高梨課長

高梨課長の発言

型が業種ごとに分かれていると聞きました。うちはエステサロンですが、LocalBusinessのままではいけないのでしょうか。

鈴木さん

鈴木さんの発言

動くことは動きます。ただGoogle公式ドキュメントは、当てはまるいちばん具体的な型を使ってほしいと書いています。挙げられている例は、Restaurant・DaySpa・HealthClubです。

Google公式ドキュメントには「Use the most specific LocalBusiness sub-type possible」とあります（出典: Google公式）。LocalBusinessをそのまま使うのは、当てはまる型が見つからないときの選択肢だと考えてください。

schema.orgは、LocalBusinessの下に30以上のサブタイプを定義しています（出典: schema.org）。代表的なものを業種別に並べます。

型を具体にするほど、何屋なのかが説明なしで伝わります。お客さまに自己紹介するときの言い方に、いちばん近い型を選ぶ。それが目安になります。

1つの事業者が複数の業態を兼ねることもあります。その場合は、@typeを配列で指定します。Google公式ドキュメントは、電気工事士・配管工・鍵屋を兼業する例を示しています（出典: Google公式）。["Electrician", "Plumber", "Locksmith"] という書き方です。エステと物販を兼ねる店舗なら、["DaySpa", "Store"] と書けます。

05AI検索対策で使える、LocalBusiness schemaの実装テンプレートはありますか？

エステサロンを想定した基本形です。自社の情報に置き換えれば、そのまま利用できます。

{
  "@context": "https://schema.org",
  "@type": "DaySpa",
  "name": "サンプルエステサロン 渋谷店",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "サンプル2-3-4",
    "addressLocality": "渋谷区",
    "addressRegion": "東京都",
    "postalCode": "150-0000",
    "addressCountry": "JP"
  },
  "telephone": "+81-3-0000-0001",
  "url": "https://sample-spa.example.com/shibuya/",
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 35.65858,
    "longitude": 139.70157
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "10:00",
      "closes": "20:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Saturday", "Sunday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ],
  "priceRange": "¥¥"
}

@typeには、LocalBusinessではなくDaySpaという具体的なサブタイプを指定しています。addressとgeoは、それぞれPostalAddress型・GeoCoordinates型を入れ子にします。平日と土日で営業時間が違うときは、openingHoursSpecificationを配列にして分けて書きます。

JSON-LDそのものの文法（@contextや@typeの意味）は、別記事『JSON-LDの書き方入門｜3つのコピペ例で今日から書ける』で解説しています。

06店舗が複数あるとき、LocalBusiness schemaの実装はAI検索最適化としてどう分けるんですか？

高梨課長

高梨課長の発言

店舗が増えてきました。店舗一覧のページに、まとめて書いてしまってもいいものでしょうか。

鈴木さん

鈴木さんの発言

そこは分けるほうが安全です。urlプロパティの説明が「その拠点自体の完全なURL」となっているので、1つの名乗りは1つの拠点に対応する設計なんです。

Google公式ドキュメントは、urlプロパティを「その拠点自体の完全なURL」と説明しています（出典: Google公式）。1つのLocalBusinessは1つの拠点に対応する設計です。複数店舗を展開しているなら、拠点ごとに別ページ・別マークアップにするのが基本になります。

ここで起きやすいのが、住所だけ差し替えて紹介文を使い回してしまうことです。駐車場があるかどうか、対応できる時間帯、扱っているメニュー。拠点ごとに違うはずの情報が消えると、AIも検索エンジンも拠点を選び分ける材料を失います。この落とし穴は、別記事『ローカルビジネスのAIO事例』でも扱っています。

07部門(department)は、LocalBusiness schemaのAI検索対策でいつ使うんですか？

departmentは、同じ拠点の中にある独立した部門を表すプロパティです。Google公式ドキュメントは、小売店（Store）の中にある調剤薬局（Pharmacy）部門を例に挙げています（出典: Google公式）。

{
  "@context": "https://schema.org",
  "@type": "Store",
  "name": "サンプルストア 渋谷店",
  "department": [
    {
      "@type": "Pharmacy",
      "name": "サンプルストア 渋谷店 調剤薬局",
      "telephone": "+81-3-0000-0002"
    }
  ]
}

departmentの中では、親と同じプロパティを部門ごとに個別に定義できます（出典: Google公式）。電話番号や営業時間が部門によって違うときに効いてきます。

見分ける手がかりは住所です。住所が違えば別の拠点なので、ページごと分けます。住所が同じで、電話や営業時間だけが独立しているなら、departmentの出番です。

08公開したあと、LocalBusiness schemaのAI対策として何がずれていくんですか？

若葉さん

若葉さんの発言

公開したら、いったん終わりでいいんですよね…？

鈴木さん

鈴木さんの発言

実は、負荷がかかるのはここからなんです。お店の情報は変わっていきますが、schemaは書いたときのまま残ります。 この差が、そのままずれになります。

Google公式の構造化データガイドラインは、マークアップの内容を実際の表示情報と一致させることを求めています（出典: Google公式）。時間が経つほどずれやすいのは、次の3か所です。

openingHoursSpecificationには、validFrom・validThroughで期間を区切る書き方があります（出典: schema.org）。年末年始や夏季休業のように、通常と違う営業時間を指定するためのプロパティです。通常の営業時間だけを置いたままにすると、休業日なのにschema側では営業中、という状態が起こりえます。

住所と電話番号は、Googleビジネスプロフィールの表記と揃えます。運用の考え方は、別記事『ローカルビジネスのAIO事例』もご覧ください。

09LocalBusiness schemaを実装すれば、AI検索やナレッジパネルに表示されるんですか？

高梨課長

高梨課長の発言

上に説明する立場として、いちばん聞かれそうなのがここです。入れれば、地図やナレッジパネルに出るようになるんでしょうか。

鈴木さん

鈴木さんの発言

そこは正直にお伝えします。Google公式ドキュメントは、構造化データを利用する機能が検索結果に表示されることを保証しないと明記しています。

期待の置きどころを間違えると、実装そのものが目的になってしまいます。表示されるかどうかは、こちらで決められる話ではありません。

つまり実装は、表示を確約する施策ではありません。AIやGoogleに、店舗の正確な情報を渡すための土台です。この位置づけで見ると、埋めた欄の数より、書いた内容が実態と合っているかのほうが大事になります。

10実装したLocalBusiness schemaは、AI検索対策としてどう確認するんですか？

書き終えたら、公開する前に確認します。Rich Results Testにコードかページを入れると、エラーと警告の有無を確かめられます。検証ツールの使い分けは、別記事『構造化データのテストツール入門』で解説しています。

ただし、ツールが通ることと、名乗りとして正しいことは別の話です。ツールは、priceRangeが古いままかどうかまでは教えてくれません。実際のページの表示、そしてGoogleビジネスプロフィールと見比べるところまでが確認です。

11LocalBusiness schemaの実装で、AI検索最適化としてやりがちな失敗は何ですか？

最後に、実務でよく見かける失敗を3つ挙げます。どれも「よかれと思って」起きるものです。

1. LocalBusiness型のまま公開してしまう

Google公式ドキュメントは、いちばん具体的なサブタイプを使うよう明記しています。LocalBusinessのままにするのは、当てはまる型が見つからないときだけです。

2. 複数店舗のページで、住所だけ差し替えて紹介文を使い回してしまう

拠点ごとの違いが消えて、AIが拠点を選び分ける材料を失います。ページを分けたなら、中身も分けます。

3. 季節営業や臨時休業が、schema側に反映されないまま残ってしまう

営業時間を変えたら、schema側も見直す。この往復を運用に組み込んでおくと、ずれが溜まらなくなります。

12よくある質問

13まとめ｜今日やる3つのこと

LocalBusiness schemaの必須は、nameとaddressだけです。書くこと自体の負荷は高くありません。差がつくのは、サブタイプの選び方・拠点と部門の分け方・公開後も表示と一致させ続けられるかです。

まず着手するのは、本店1拠点への実装です。複数店舗への展開は、拠点ごとのページ分割と紹介文の作り分けができてから広げると安全です。