ローカル構造化データ
Local Structured Dataろーかる・こうぞうかでーた
ローカル構造化データとは、店舗や事業所の名称・住所・電話番号・営業時間・提供地域といった情報を、機械が読める形式で書き起こしたデータのことです。schema.orgという共通の語彙を使い、JSON-LDという形式でページに埋め込みます。人が読む文章とは別に、検索エンジンに向けて「この住所は住所です」「この時刻は営業時間です」と明示するための層だと考えると分かりやすくなります。
ページに書いてあることと、機械が読み取れていることは別
店舗ページには住所も電話番号も営業時間も書いてある。それでも検索エンジンから見れば、それはただの文字列が並んでいる状態です。「〇〇市△△町1-2-3」が所在地なのか納品先なのか、「10:00〜19:00」が営業時間なのか受付時間なのか、文章の見た目だけでは確定できません。ローカル構造化データは、この曖昧さを消すために「この値は住所である」「この時刻は営業時間である」と役割を明示します。
使う型はschema.orgのLocalBusinessが基本で、その下にRestaurant（飲食店）、Dentist（歯科）、AutoRepair（自動車整備）といった、より具体的な下位型が用意されています。当てはまる下位型があるなら、そちらを使ったほうが業種の情報まで伝わります。書き方はGoogleがJSON-LDを推奨しており、ページのHTMLに独立したスクリプトとして置けるため、デザインを崩さずに追加・修正できます。営業時間はopeningHoursSpecificationで曜日ごとに書き分けられ、年末年始のような特別営業日も別に指定できます。
ここで最初に押さえておきたいのが、地図枠に出る情報とは別物だということです。地域性のある検索で上部に表示されるローカルパックの中身は、各社が管理するGoogleビジネスプロフィールに由来します。自社サイトの構造化データを直したからといって、あの枠の営業時間が書き換わるわけではありません。構造化データが効くのは、自社サイトが正しく理解されるための土台づくりのほうです。両方を整える必要があり、どちらか一方では穴が残ると理解しておくと打ち手を間違えません。
もう一点、期待値の調整が必要です。構造化データを入れれば必ず検索結果の見え方が豪華になる、というものではありません。Googleは構造化データがあってもリッチリザルトの表示を保証しないと明記しています。また、記述内容はページ上でユーザーに見えている情報と一致していなければならず、見えていない情報や実態と異なる情報を書くのはガイドライン違反です。レビューについても、自社サイトに自社について書いたもの（いわゆる自己言及のレビュー）はレビューのリッチリザルトの対象外とされています。星の数を自分で書いて表示させることはできません。仕様は更新されるため、実装前に公式ドキュメントの最新版を確認してください。
顧客が確かめる手間を減らすための下地であって、コードを入れることが目的ではありません。
顧客心理の視点で見ると、来店や訪問を伴う商売で顧客がしていることは「行けるかどうかの確認」です。今日やっているか、そこまで何分か、電話が通じるか。この確認に手間がかかる候補は、内容を吟味される前に脱落します。構造化データは直接この画面をつくるものではありませんが、事実を機械が扱える形で置いておくことで、確認の答えが顧客に届きやすくなるという位置づけです。逆に、書いてある情報が古いまま機械にまで正しく伝わってしまうと、間違いのほうが正確に広がります。だから作業の本体はコードではなく、情報そのものを正しく保つことになります。「行ったら閉まっていた」は、技術的なエラーではなく失注として現れます。
仕組み化の視点では、3つを型にします。①情報の源を1か所に決める——名称、住所、電話、営業時間、特別営業日を、担当者が編集できる1か所（CMSのカスタムフィールドなど）に置きます。②そこから3つの出口に出力する——ページ上の表示、JSON-LD、そしてGoogleビジネスプロフィール。前2つはテンプレートで自動出力できるので、担当者が営業時間を1回直せばページも構造化データも同時に直ります。手書きのJSON-LDをHTMLに直接貼ると、更新のたびに開発者が必要になり、やがて放置されます。③更新の担当と期限を決める——特別営業時間は前月末までに翌月分を入れる、といった粒度まで落とします。この形にしておけば、人が頑張らなくても情報の鮮度が保たれる状態になります。複数店舗があるなら、1店舗1ページにして各ページに1つずつ記述するのが基本です。
AI活用の視点では、実装と保守の両方で使えます。型の選定（自社業種にLocalBusinessの下位型があるか）、JSON-LDの下書き、検証ツールが出したエラー文の読み解きは、AIに任せると調べる時間が大きく減ります。複数店舗ぶんの記述を、店舗一覧の表から生成させるのも実際的です。さらに、生成AIの回答や音声アシスタントのように機械が事実を読み取って答える経路が増えている今、機械可読な形で情報を置いておく価値は以前より上がっています。ARGASのような追跡の仕組みがあれば、店舗ページに来た人がその後どう動いて問い合わせに至ったかも追えます。ただし住所・営業時間・電話番号・料金の値そのものは、必ず人が確認してから公開してください。生成されたコードの構文が正しいことと、中身が事実であることは別の問題です。
図解：1つの事実が、3つの出口に出ていく
左が情報の源。ここを1か所に絞れるかどうかで、運用が続くかどうかが決まります。右は入れたあとに回す検証。3つの出口の値が食い違ったときに困るのは、機械ではなく顧客です。
事例で見る：国内・海外
Googleが示す考え方 ── 「見えている情報と一致していること」が前提
構造化データの扱いについて、Googleは検索セントラルのドキュメントで一貫した立場を示しています。第一に、推奨する形式はJSON-LDであること。ページの見た目に手を入れずに追加できるため、保守の観点でも扱いやすい選択です。第二に、マークアップした内容はページ上でユーザーに見えている情報と一致していなければならないこと。見えていない情報や実態と異なる情報を書く行為はスパムポリシーの対象で、構造化データが無視されるだけでなく、より広い範囲で評価に影響することもあると説明されています。第三に、構造化データを実装してもリッチリザルトの表示は保証されないこと。「入れたのに出ない」は不具合ではなく、仕様の範囲内です。レビューについても、自社サイトに自社について書かれた自己言及型のものはリッチリザルトの対象外とされており、星の数を自分で記述して表示させることはできません。検証はリッチリザルトテストで構文を確かめ、公開後はSearch Consoleの拡張レポートでエラーと警告を追う——この2段が標準的な進め方です。仕様と対応する型は更新が続いているため、実装を決める前に公式ドキュメントの最新版を必ず確認してください。
3拠点をもつ動物病院のような形 ── 「1回入れて終わり」が壊れる場所
たとえば、県内3か所に分院をもつ動物病院を考えます。制作会社に依頼して構造化データを入れてもらい、リッチリザルトテストも通った。ここまでは順調です。問題は半年後に起きます。分院の受付時間が変わり、ページの本文だけが更新された——構造化データはHTMLに直接書かれていたため、そのままです。さらに、3院の情報がトップページに1つだけまとめて記述されていたため、どの住所がどの院なのかも区別されていません。「土曜の午後に行ったら閉まっていた」という声が出て、はじめて気づく、という流れです。ここから学べる修正点は3つあります。1つ目は1拠点1ページにして、各ページに1つずつ記述すること。2つ目は受付時間や休診日をCMSの入力項目にし、本文表示と構造化データの両方をそこから出力すること。受付が入力を1回直せば、両方が同時に直ります。3つ目は特別休診日を前月末までに入れる運用を年間予定に組み込むこと。加えて、サイト側を直してもGoogleビジネスプロフィール側は別なので、そちらの営業時間も同じタイミングで更新する担当を決めておきます。これは特定の医院の実績ではなく、複数拠点をもつ小規模事業で繰り返し見られる崩れ方を、代表的なパターンとしてまとめたものです。
現場での使い方：5ステップ
- 1拠点1ページの構成にする複数店舗を1ページにまとめていると、どの情報がどの店舗のものか機械には区別できない。まずページを分けるのが順序として先。
- 業種に合う型を選ぶLocalBusinessが基本。Restaurant、Dentist、AutoRepairなど当てはまる下位型があるならそちらを使う。迷ったらLocalBusinessで始める。
- 情報の源を1か所に決めて出力する営業時間や住所をCMSの入力項目にし、本文表示とJSON-LDの両方をそこから生成する。HTMLへの直書きは更新が止まる。
- 見えている情報と一致させ、検証するページに書いていない情報は書かない。リッチリザルトテストで構文を確認し、公開後はSearch Consoleの拡張レポートでエラーを追う。
- プロフィール側と同時に更新する運用にする地図枠に出るのはGoogleビジネスプロフィールの情報。サイトを直しても連動しない。更新は必ず両方セットで担当と期限を決める。
関連用語
まとめ：正しい事実を、機械が読める場所に置いておく
ローカル構造化データは、店舗の名称・住所・電話・営業時間を、schema.orgの語彙で機械が読める形にしたものです。JSON-LDで書き、ページ上に見えている情報と一致させるのが前提で、入れたからといって検索結果の見え方が必ず変わるわけではありません。地図枠に出る情報はGoogleビジネスプロフィール側の管轄なので、サイトの記述だけでは穴が残ります。だから実務の要点は技術ではなく運用のほうにあります。情報の源を1か所に決め、ページ表示と構造化データを同じ場所から出力し、プロフィールも同じタイミングで直す。型の選定やコードの下書きはAIに任せ、住所や営業時間の値は人が確認する。事実が正しく置かれていれば、顧客は確かめる手間をかけずに次の行動へ進めます。
