店舗の構造化データで公式サイトとGoogleビジネスプロフィールを三角連携｜Schema.org LocalBusiness 自動生成ツール【2026】

なぜ三角連携が必要か — 公式サイト・GBP・検索エンジンを意図的に整合させる

Googleが行っている「triangulation（突き合わせ）」

Googleは検索結果の精度を上げるため、1つの店舗に対して複数の情報源を照合しています。

• 公式サイトの構造化データ（Schema.org LocalBusiness / JSON-LD）
• Googleビジネスプロフィールの登録情報
• 外部サイト・ポータルの掲載情報（食べログ・HOT PEPPER・業界サイト等）
• SNS / Wikipedia / Wikidata 等の公開情報
• ユーザーの口コミ・投稿・写真

これらが 一致していれば「この店舗は確かに存在し、この情報が正しい」と判断され、Knowledge Graphに安定的に登録されます。矛盾していればGoogleは「どれが正しいのか分からない」と判断し、構造化データの評価も下げます（Google公式ヘルプにも「他のソースと矛盾する場合、マークアップは discount される」と明記）。

「三角連携」でコントロール可能な3点

事業者側がコントロールできるのは、この5つの情報源のうち「公式サイト」「GBP」の2つと、それらが揃うことで強化される「Googleの理解（検索エンジン内部の entity 評価）」の合計3点です。これを 三角形で意図的に結ぶ のが三角連携の基本思想です。

三角形の頂点	コントロール手段	連携の鍵
① 公式サイト	店舗情報ページ + Schema.org 構造化データ	NAP（店名/住所/電話）・営業時間・URL の正確な記述
② Googleビジネスプロフィール	GBP管理画面で登録	カテゴリ・属性・営業時間・写真・投稿の完全入力
③ 検索エンジン（Google内部の entity 理解）	①と②の整合性により間接的に改善	sameAs・@id で外部エンティティと連結し disambiguation

この三角形のどれか1辺が弱くても、残りの2辺の信頼度に影響します。構造化データだけ整備しても、GBPが更新されていなければ効果半減です。逆もまた然り。

Schema.org 構造化データとは — メリット・デメリット完全版

Schema.org 構造化データの仕組み

公式サイトのHTMLに、<script type="application/ld+json"> タグで店舗情報を意味付きで埋め込みます。例（最小構成）:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "おもてなし亭",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "中央区三宮町1-2-3",
    "addressLocality": "神戸市",
    "addressRegion": "兵庫県",
    "postalCode": "650-0001",
    "addressCountry": "JP"
  },
  "telephone": "+81-78-123-4567",
  "url": "https://example.com/",
  "priceRange": "¥¥",
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "11:00",
    "closes": "22:00"
  }],
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 34.6913,
    "longitude": 135.1956
  }
}
</script>

このコードは 表示には影響しません。検索エンジンとAIだけが読み取るメタ情報です。ユーザーがページを見ても「何も変わっていない」ように見えますが、Googleやクローラーからは 「ここに Restaurant（レストラン）というエンティティがあって、名前はおもてなし亭で、住所は……」 と構造的に理解されます。

Schema.org 構造化データの7つのメリット

Schema.org 構造化データのデメリット・注意点

これらのデメリットは 自動化の仕組み で大幅に軽減できます。本記事§11で解説する、弊社「おもてハブ」のような統合管理ツールを使うと、GBP更新を起点に公式サイトの構造化データも自動反映させる運用が可能です。

2026年にJSON-LDが唯一推奨される理由

Schema.org の実装形式には Microdata・RDFa・JSON-LD の3つがありますが、2026年はJSON-LDのみが推奨です。

形式	状態	理由
JSON-LD	✅ 2026年Google推奨	HTMLの表示ロジックから分離・メンテナンスしやすい・エラーが表示に影響しない
Microdata	⚠️ 陳腐化傾向	HTMLタグ内にベタ書き。表示構造の変更で簡単に壊れる。Googleも非推奨
RDFa	⚠️ 陳腐化傾向	Microdataと同じ理由。新規実装は避けるべき

既存サイトでMicrodata/RDFaを使っている場合は、JSON-LDへの移行を推奨します。

業種別 Schema.org Type 早見表

業種	推奨 Schema.org Type
飲食店	Restaurant / BarOrPub / CafeOrCoffeeShop / FastFoodRestaurant / IceCreamShop
美容・エステ・サロン	BeautySalon / HairSalon / DaySpa / NailSalon / TattooParlor
医療・歯科	Dentist / MedicalClinic / Hospital / Physician / Optician / Pharmacy
宿泊業	Hotel / Resort / BedAndBreakfast / Hostel / Motel
フィットネス・スポーツ	HealthClub / GymOrFitnessCenter / SportsActivityLocation / YogaStudio
小売店	Store / ClothingStore / ShoeStore / BookStore / HardwareStore / JewelryStore
介護・福祉	ChildCare / HomeAndConstructionBusiness
教育・学校	School / EducationalOrganization / Preschool / CollegeOrUniversity
公共施設・文化	GovernmentOffice / Library / Museum / PerformingArtsTheater
金融・不動産	BankOrCreditUnion / RealEstateAgent / InsuranceAgency
自動車関連	AutoRepair / GasStation / AutoDealer / AutomotiveBusiness
該当がない場合	LocalBusiness（最後の手段）

完全な Schema.org 階層は schema.org/LocalBusiness で確認できます。本ツールは GBPのメインカテゴリ に応じて、できるだけ業態に近い Schema.org Type を自動推定します。

構造化データ自動生成ツール（GBP検索）

WordPress設置の流れ（3ステップ）

1）店舗を検索してGBP情報を表示

§4の検索フォームに店舗名を入力し、該当するGBPの情報を表示します。店名・住所・電話番号・営業時間が正しいか確認してください。不正確な情報がGBPにある場合、まずGBPを直してから再検索することをおすすめします。

2）構造化データをコピー

表示された構造化データ（JSON-LD）をコピーします。生成されたコードは <script type="application/ld+json"> から </script> まで全てがひとまとまりです。

3）公式サイトに貼り付ける

公式サイトの 店舗詳細ページ（住所・営業時間・電話番号が表示されているページ）に貼り付けます。

WordPressでの貼り付け方法

貼り付け位置のおすすめ

• 本文の一番下（末尾）に「カスタムHTML」ブロックを追加して貼る（管理しやすい）
• もしくは、店舗情報セクション（住所・電話・営業時間の近く）の直後に貼る

どのページに貼ればいい？

• 1店舗だけ：トップページ、または店舗紹介ページ
• 複数店舗：原則、各店舗の詳細ページごとに、その店舗のデータを貼る（§8のhierarchical schemaも参照）

貼り付けで気をつけること

• ページに書いていない情報を、構造化データだけに入れない（ペナルティ対象）
• ページ上の店舗情報（営業時間など）と、構造化データの内容を一致させる
• JSONの文法エラーに注意（カンマ・括弧を完璧に）

Googleの構造化データ一般ガイドライン（Google公式）もご確認ください。

構造化データ設置後の検証

設置後は必ずGoogle公式ツールで検証してください。文法エラーや必須プロパティ欠落があると、全く機能しない状態のまま残ってしまいます。

リッチリザルトテスト（Rich Results Test）

Google公式のリッチリザルトテストで、公開後のページURLを入力してテストします。以下を確認してください:

• エラー（赤）がないか — エラーがあると機能しない
• 警告（黄）の内容 — 推奨プロパティの欠落を示唆
• 住所・営業時間・電話番号等が正しく読み取られているか
• Google が認識した schema type が意図通りか

Google Search Console の「拡張」レポート

Search Console の「拡張」→「LocalBusiness」等のレポートで、サイト全体の構造化データの状態を一覧できます。定期的に確認することで、エラーが発生した際に早期に気付けます。

【技術深化】@id と sameAs で Entity Disambiguation

@id プロパティ — エンティティに一意のURLを与える

@id は構造化データ内で エンティティに一意のID（URL形式） を割り当てるプロパティです。同じIDを複数のページで使うことで、「これは同一のエンティティ」であることを明示できます。

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.com/#store-kobe-sannomiya",
  "name": "おもてなし亭 三宮店",
  ...
}

「おもてなし亭 三宮店」について、公式サイトトップ・店舗詳細ページ・採用情報ページなど複数の場所で構造化データを書く場合、全て同じ @id を使えば Googleは「同じエンティティの別面」として認識できます。

sameAs プロパティ — 外部プロフィールとの連結

sameAs は、そのエンティティを表す他のURL（Wikipedia・Wikidata・公式SNS等）を列挙するプロパティです。

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.com/#store-kobe-sannomiya",
  "name": "おもてなし亭 三宮店",
  "sameAs": [
    "https://www.facebook.com/omotenashi-sannomiya",
    "https://www.instagram.com/omotenashi_sannomiya/",
    "https://twitter.com/omotenashi_jp",
    "https://www.wikidata.org/wiki/Q12345",
    "https://ja.wikipedia.org/wiki/おもてなし亭"
  ],
  ...
}

Googleはこれらの外部プロフィールを辿って「公式サイト × GBP × SNS × Wikipedia」が全て同じエンティティを指していることを確認します。これが Entity Authority（エンティティとしての権威）を押し上げる主要因です。

【技術深化】多店舗の Hierarchical Schema 設計

親子関係の基本構造

親サイト（本社・ブランドサイト）には Organization schema、各店舗詳細ページには LocalBusiness schema を配置し、parentOrganization / subOrganization プロパティで繋ぎます。

// 本社・ブランドサイトのトップページ
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#org",
  "name": "株式会社おもてなし",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.facebook.com/omotenashi",
    "https://www.wikidata.org/wiki/Q12345"
  ]
}

// 店舗詳細ページ（各店舗ごとに別々の @id）
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.com/stores/sannomiya/#store",
  "name": "おもてなし亭 三宮店",
  "parentOrganization": {
    "@id": "https://example.com/#org"
  },
  "address": { ... },
  ...
}

こうすることで Google は「おもてなし亭という組織があり、その配下に複数店舗がある」構造を正確に理解できます。単独ブランド店のEntity Authority が全店舗に波及するため、新規出店の店舗でも初期から一定の信頼度を得られるメリットがあります。

多店舗運用の現実的な負担

AI Overviews / ChatGPT / Perplexity に参照される構造化データ

なぜAIは構造化データを重視するのか

生成AIは膨大なWebページから情報を抽出して回答を生成しますが、自然文から情報を抽出するのはコストが高くエラーも起きやすいため、構造化データがあるページを優先的に参照します。Schema.org は「検索エンジンとAIの共通言語」として機能しています。

GEO時代の構造化データ対策

• 必須プロパティを完璧に：name / address / telephone / openingHoursSpecification / geo / priceRange
• 推奨プロパティも可能な限り：image / menu / servesCuisine / acceptsReservations / paymentAccepted
• sameAs で外部エンティティ連結：AIが「この店は確かに存在する」と確信する根拠に
• GBPと同じ情報を同じ形で：三角連携が AI にも効く
• 継続的な更新：AI は「新鮮な情報」を優先する傾向がある

つまり 三角連携を正しく維持すること自体が、最も効果的なGEO対策 になります。AI検索の時代でも、やるべきことは「三角形の3辺を常に整合させる」でシンプルです。

情報が変わったら更新が必要 — 手動運用の限界

手動運用で起きる典型的な問題

• GBPだけ更新して公式サイトを忘れる：営業時間変更時によく起きる。構造化データが古いまま残り、情報の食い違いが常態化
• 担当者が複数で更新漏れが発生：誰が何を更新したのか分からなくなる
• 構造化データの書き換えミス：手書きでJSON-LDを編集すると、括弧の閉じ忘れ等で全体が無効になりがち
• 季節限定営業・臨時休業の反映が追いつかない：ゴールデンウィーク・年末年始の更新が間に合わない
• 多店舗では指数的に増大：店舗数×変更頻度の更新作業が必要になる

手動運用の限界 — 50店舗で破綻

弊社の現場感覚では、1店舗あたり月1回程度の情報変更が発生します。10店舗なら月10回、50店舗なら月50回の構造化データ貼り替え作業が必要です。GBPだけ更新して公式サイトを後回しにする運用では、三角連携が常に崩れた状態になり、構造化データのメリットが失われます。

この問題を根本解決するのが、次の§11で紹介するおもてハブの自動連携機能です。

おもてハブで三角連携を自動化する（手動運用の限界を解消）

おもてハブが解決する4つの課題

手動運用の課題	おもてハブの解決
GBP更新→公式サイト貼り替え作業が毎回発生	GBPを更新すると、公式サイト側の構造化データも自動反映
多店舗で作業工数が爆発（50店舗で破綻）	店舗数に関係なく一元管理・コストは店舗単価で積み上げ
更新漏れで三角連携が崩壊	常に整合性が保たれる仕組みで、漏れ・ミスが発生しない
JSON文法エラーでデータ無効化	自動生成なので文法エラーはゼロ

おもてハブの料金体系（業界最低水準）

• 初期費用 無料
• 月額 2,100円〜（企業単位）
• 1,000店舗なら 1店舗あたり 150円/月 の業界最低水準
• 8年以上の多店舗運用実績・無料お試し可

おもてハブが最も効果を発揮するケース

• 多店舗運営（3店舗以上）：店舗数が多いほど自動化のメリットが大きい
• チェーン本部・FC運営：本部が全店舗の情報を一元管理できる
• 1店舗でも変更頻度が高い業種：営業時間・臨時休業・季節メニューが多い業態
• 公式サイトとGBPの整合性を真剣に管理したい方：三角連携を長期維持したい方

よくある質問（FAQ）

あわせて読みたい関連記事