構造化データ(JSON-LD)の書き方 お店・会社のコピペ例と、AI検索対策での使いどころ

まず結論 構造化データは、AI検索対策の「必須」ではなく「土台」
最初に、大事な前提をお伝えします。
構造化データを入れたからといって、ChatGPTやGeminiなどのAIに紹介される、検索順位が上がる、といったことは、保証されません。
AIがどの情報を、どう使うかは、各社が決めていて、外からは分からないからです。
それでも入れる価値があるのは、「基本情報を、誤解なく伝える」手段になるからです。
店名の表記ゆれ、住所の書き方の違い、営業時間の読み間違いは、AIの誤った回答の原因になりやすい部分です。ここを、機械が読める形で、はっきり書いておく。
これが、構造化データの役割です。
効果の保証はありません。基本情報を正確に伝えるための土台づくりです。

構造化データとは 「ラベル付きの名札」
ホームページの文章は、人が読めば意味が分かります。
しかし機械は、「082-000-0000」が電話番号なのか、郵便番号なのか、注文番号なのかを、前後の文脈から推測するしかありません。
構造化データは、その推測をなくすために、「これは電話番号です」というラベルを付けた、機械向けの名札です。
文章だけの場合(機械が推測)
- 「営業は9時から6時、日曜はお休み」と、文章で書いてある
- 電話番号が、画像の中にだけある
- 店名が「ナビカフェ」「NAVI CAFE」と、ページごとに違う
構造化データがある場合(機械が確認)
- 営業時間が、曜日・開始・終了の形で書いてある
- 電話番号が、telephoneという項目に書いてある
- 店名が、nameという項目に、1つだけ書いてある
形式はいくつかありますが、Googleが推奨しているのは、JSON-LD(ジェイソン・エルディー)という書き方です。
ページの見た目の部分とは別に、コードの塊を1か所入れるだけなので、あとから直しやすいのが利点です。この記事でも、JSON-LDで説明します。
入れるとよい場合・期待しすぎない方がよい場合
| こんなとき | 構造化データの役割 |
|---|---|
| 公式サイトの店名・住所・営業時間が、他の場所と食い違っている | 食い違いを正す作業の「あとで」入れる。先に、元の情報をそろえる |
| サイトの情報が、画像だけで、文章が少ない | 文章を書くのが先。構造化データは、文章の代わりにはならない |
| 訪問型・出張型で、対応エリアを正しく伝えたい | areaServed(対応エリア)で、はっきり書ける |
| 検索結果で、見た目をリッチにしたい | 種類によって、表示の対象が限られる。期待しすぎない |
| AIに、自社を正しく紹介してほしい | 基本情報を誤解なく伝える土台。紹介の保証はない |
ページに見えている内容と、構造化データの内容は、必ず一致させます。
構造化データは「書いてあることを、機械が読める形で書き直したもの」です。ページに書いていないことを、構造化データにだけ書いてはいけません。
この約束は、Googleのガイドラインにも書かれています。
ページ上で見えない内容や、実態と異なる内容を、構造化データだけに書くのは、ガイドライン違反とされています。
入れる前に、ページの文章と見比べて、同じ内容になっているかを確認してください。
型(タイプ)の選び方 業種ごとの目安
構造化データには、「型」があります。お店なら店舗の型、会社なら組織の型、というように、何について書くかで選びます。
迷ったら、細かい型よりも、LocalBusiness(地域のお店・事業所)か、Organization(組織)を選べば、基本は足ります。
| 業種 | 使いやすい型 | ひとこと |
|---|---|---|
| 飲食店・カフェ | Restaurant / CafeOrCoffeeShop | メニューのURLも入れられる |
| 美容室・サロン | HairSalon / BeautySalon | 予約ページのURLがあると親切 |
| 小売店・雑貨店 | Store | 業種を絞りにくいときはLocalBusinessでもよい |
| 税理士・司法書士などの士業 | ProfessionalService / LegalService / AccountingService | 対応エリアを書くと伝わりやすい |
| 歯科・クリニック | Dentist / MedicalClinic | 診療科や診療時間は、実際と必ず一致させる |
| 会社全般(店舗なし) | Organization | 所在地・連絡先・SNSなどを書く |
| 訪問・出張型のサービス | LocalBusiness + areaServed | 来店がない場合も、対応エリアで書ける |
型の名前は、schema.orgという公開の辞書に載っています。上の表は一般的な選び方の目安です。
LocalBusiness(お店・事業所)のコード例
次のコードは、架空のカフェを例にした、LocalBusinessの基本形です。店名・住所・電話・URLなどを、ご自身の内容に置き換えて使います。
「例」「0000」「example.com」などと書いてある部分が、書き換える場所です。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "CafeOrCoffeeShop",
"@id": "https://example.com/#store",
"name": "ナビカフェ 広島店",
"url": "https://example.com/",
"image": "https://example.com/images/store.jpg",
"telephone": "+81-82-000-0000",
"priceRange": "¥¥",
"address": {
"@type": "PostalAddress",
"postalCode": "730-0000",
"addressRegion": "広島県",
"addressLocality": "広島市中区",
"streetAddress": "例町1-2-3",
"addressCountry": "JP"
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "18:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Saturday"],
"opens": "10:00",
"closes": "17:00"
}
],
"sameAs": [
"https://www.instagram.com/example"
]
}
</script>店名・住所・電話番号・URLは、すべて架空の例です。ご自身の情報に置き換えてください。
| 項目 | 意味 | 注意 |
|---|---|---|
| @type | お店の種類 | 合う型がなければ LocalBusiness にする |
| @id | このお店を指す目印のURL | 同じサイト内で、同じお店は同じ@idにそろえる |
| name | 店名 | マップ・看板・サイトと同じ表記にする |
| url | 公式サイトのURL | https:// から始まる、完全なURL |
| image | 代表的な画像 | 相対パスではなく、https:// から始まるURL |
| telephone | 電話番号 | +81-82-… のように、国番号つきの形が確実 |
| priceRange | 価格帯の目安 | 省略してもよい。「¥¥」や「1000-2000円」など |
| address | 住所 | 都道府県・市区町村・番地を分けて書く |
| openingHoursSpecification | 営業時間 | 次の章で、書き方を詳しく説明 |
| sameAs | 同じ事業者の、他のページ | SNS・マップのページなど。他人のページは入れない |
営業時間の書き方 いちばん間違えやすい所
構造化データの中で、いちばん書き間違いが多いのが、営業時間です。曜日の名前は英語、時刻は24時間表記の「09:00」の形、というルールがあるためです。
よくあるパターンを、整理しておきます。
| お店の営業 | 書き方のポイント |
|---|---|
| 月〜金 9:00〜18:00 | dayOfWeek に5つの曜日をまとめて書ける |
| 土曜だけ時間が違う | openingHoursSpecification を、もう1つ追加する |
| 昼休みがある(12:00〜13:00) | 午前と午後の、2つの枠に分けて書く |
| 日曜・祝日は休み | 書かない(休みの日は、枠を作らない) |
| 深夜0時をまたぐ(〜26:00の感覚) | closes は「02:00」のように書く。曜日の扱いに注意 |
| 完全予約制・不定休 | 時間を無理に書かず、ページの文章で説明する |
「いつも通り」と思い込まず、実際の営業時間を、見直してから書きます。
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "12:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "13:00",
"closes": "18:00"
}
]午前と午後で、同じ曜日の枠を2つ書く形です。
祝日や年末年始、臨時休業は、構造化データに細かく書き込むよりも、ページの文章と、Googleビジネスプロフィールの「特別営業時間」で伝える方が、現実的です。
構造化データには、通常の営業時間だけを書き、変わったときは、すぐ直します。
訪問型・出張型は「対応エリア」で書く
店舗を持たずに、お客様のところへ訪問する仕事(出張カメラマン・訪問介護・出張修理など)は、住所を載せない場合があります。
その場合は、areaServed(対応エリア)を使って、どの地域に対応しているかを書きます。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "ナビフォト 出張撮影",
"url": "https://example.com/",
"telephone": "+81-90-0000-0000",
"areaServed": [
{ "@type": "City", "name": "広島市" },
{ "@type": "City", "name": "東広島市" },
{ "@type": "City", "name": "呉市" }
],
"description": "広島県内へ出張して、七五三やお宮参りなどの家族写真を撮影します。"
}
</script>住所を公開しない場合でも、対応エリアと連絡先は書けます。
なお、Googleマップでは、訪問型のお店は住所を非表示にして、サービス提供地域を設定できます。
マップ側の設定と、構造化データの対応エリアは、同じ内容にそろえておくと、食い違いが起きません。
会社全体を伝える Organization と sameAs
店舗がある場合のLocalBusinessに加えて、会社そのものを説明するのが、Organizationです。
会社の名前・ロゴ・連絡先・SNSを、1つにまとめて書きます。
とくに「sameAs」は、公式サイトと、SNSやマップのページが、同じ事業者のものだと、はっきり伝える役目があります。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "株式会社ナビ商店",
"alternateName": ["ナビ商店", "NAVI SHOTEN"],
"url": "https://example.com/",
"logo": "https://example.com/images/logo.png",
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+81-82-000-0000",
"contactType": "customer support",
"availableLanguage": "ja"
},
"sameAs": [
"https://www.instagram.com/example",
"https://x.com/example"
]
}
</script>会社名の表記ゆれ(略称など)は、alternateNameにまとめられます。
- 入れてよい: 自社のInstagram・X・Facebook・YouTubeなどの公式ページ
- 入れてよい: 自社のGoogleマップ・Appleマップ・Bingマップの、お店のページ
- 入れない: 他社のページ、関係のない記事、口コミサイトの個別のページ
- 入れない: すでに閉鎖した、古いアカウントのURL
FAQPage(よくある質問)の書き方と、注意点
質問と答えの形で書かれた情報は、AIが回答の材料にしやすいと考えられています。
FAQの構造化データでは、ページに書いてある質問と答えを、そのままコードに写します。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "予約は必要ですか?",
"acceptedAnswer": {
"@type": "Answer",
"text": "ランチは予約なしでご利用いただけます。土日の夜は混み合うため、予約をおすすめします。"
}
},
{
"@type": "Question",
"name": "駐車場はありますか?",
"acceptedAnswer": {
"@type": "Answer",
"text": "店舗前に5台分ご用意しています。満車の際は、近隣のコインパーキングをご利用ください。"
}
}
]
}
</script>ページに見えている質問・答えと、同じ文章にします。
ひとつ注意があります。Googleは、FAQの構造化データによる、検索結果でのリッチな表示を、公的機関や健康に関するサイトなど、一部に限っています。
一般のお店や会社では、見た目の変化は、期待しにくくなりました。
それでも、質問と答えをはっきり書いておくこと自体は、AIや人にとって、分かりやすい情報になります。
どこに貼る? サイトの種類別の入れ方
- 1貼り付け用のコードを用意するこの記事の例を書き換えるか、無料ツールで作る。
- 2ページの内容と、見比べる店名・住所・電話・営業時間が、ページと同じか確認する。
- 3サイトに貼り付ける<head>の中、または<body>の中に、コードの塊を1か所入れる。
- 4公開して、検証ツールで確認するエラーや警告が出ていないかを見る。
- 5内容が変わったら、一緒に直す営業時間や電話番号を変えたら、構造化データも更新する。
| サイトの種類 | 貼る方法の目安 |
|---|---|
| WordPress | テーマの「headに追加」機能や、構造化データ用のプラグインを使う。固定ページのHTMLブロックに貼る方法もある |
| Wix・Jimdo・ペライチなど | 「カスタムコード」「HTML埋め込み」の機能があれば使える。無料プランでは使えないことがある |
| 手書き・制作会社のサイト | head内に、コードの塊を追加する。制作会社に、このコードを渡して依頼してもよい |
| ブログ(アメブロ等) | コードを貼れないことが多い。無理に探さず、文章で情報を整える |
サービスによって、使える機能は違います。各サービスの案内で、確認してください。
1つのページに、複数の種類(お店・FAQ・会社など)を入れても構いません。コードの塊を種類ごとに分けて貼るか、配列にまとめて書きます。
ただし、同じ種類を重複して入れないようにします。
貼ったあとの確認 無料の検証ツール
コードは、カンマ1つ、かっこ1つの間違いで、正しく読まれなくなります。貼ったあとは、必ず、検証ツールで確認します。無料で、登録も要りません。
| ツール | できること |
|---|---|
| リッチリザルトテスト(Google) | URLやコードを入れて、Googleが読み取れる構造化データがあるか、エラーがないかを確認 |
| Schema Markup Validator(schema.org) | 型や項目の書き方が、schema.orgの決まりに合っているかを確認 |
| Search Console(Googleの無料ツール) | サイト全体の構造化データの状況を、継続的に確認できる |
ツールの名前や画面は、変わることがあります。
エラー(直す)
- 必須の項目が、抜けている
- コードの書き方が、間違っている(かっこ・カンマ)
- 値の形式が違う(営業時間が「9時」など)
警告(余裕があれば直す)
- 推奨の項目が、まだ入っていない
- 画像のサイズなどに、提案がある
- 機能の表示対象外、という案内
エラーが出たら、まず直します。警告は、すべて消さなくても構いません。「入れた方がよい項目」の提案なので、実際のお店に当てはまる分だけ、足せば十分です。
よくある間違いと、直し方
- ページに書いてある店名・住所・電話・営業時間と、コードの内容が同じ
- 営業時間は、「09:00」の形(24時間表記・コロンつき)で書いた
- 曜日は、Monday〜Sundayの英語で書いた
- URLは、https:// から始まる完全な形で書いた(画像も)
- 電話番号は、+81-82-… のように、国番号つきの形にした
- 日本語の文字や記号が、文字化けしていない
- 同じ種類のコードが、ページ内に重複していない
- 貼ったあと、検証ツールでエラーが出ていない
| 間違い | どうなるか | 直し方 |
|---|---|---|
| 実際にない口コミ評価(星の数)を書く | ガイドライン違反になるおそれ。信頼も失う | 自分で作った評価は書かない。実在の口コミは、マップ上のものを見てもらう |
| ページにない営業時間を、コードにだけ書く | 食い違い。ガイドライン違反 | ページの文章にも、同じ内容を書く |
| 古い住所・電話番号のまま | AIが古い情報を答える原因になる | 移転・変更のたびに、コードも直す |
| コードの途中に、全角の記号が混ざる | コード全体が、読まれなくなる | ダブルクォートなどは、半角にそろえる |
| 複数の店舗を、1つのコードにまとめる | 店舗ごとの情報が混ざる | 店舗ごとに、別のコードの塊にする |
評価の星(aggregateRating)は、とくに注意が必要です。自分のお店の評価を、自分で書いて載せることは、Googleが認めていません。
口コミの評価は、Googleマップなど、第三者のサービス上にあるものを、そのまま見てもらうのが、正しい形です。
ケース別の例(架空のお店・事務所)
ケースA 営業時間を直したのに、AIが古い時間を答えたカフェ
夜の営業をやめて、18時閉店にしたカフェです。マップとサイトの文章は直しましたが、サイトに貼ってあった構造化データだけが、「21時まで」のままでした。
AIに聞くと、古い時間を答えることがありました。構造化データを直し、検証ツールで確認したところ、しばらくして、答えが正しい内容に変わっていきました。
変更のたびに、見直す場所に、構造化データを加えたのが、再発防止になりました。
ケースB 住所を載せない出張型のカメラマン
自宅で仕事をしていて、住所を公開したくない出張カメラマンです。店舗型の書き方ができず、悩んでいました。
LocalBusinessに、対応エリア(広島市・東広島市・呉市)と、連絡先だけを書き、Googleマップのサービス提供地域も同じ内容にしました。
住所を出さずに、対応エリアだけを、はっきり伝えられるようになりました。
ケースC 会社名の表記がバラバラだった税理士事務所
事務所名が、ページによって「ナビ税理士事務所」「ナビ会計」「NAVI」と、違って書かれていた事務所です。
まず、正式名称を1つに決め、サイト・マップ・名刺の表記をそろえました。
そのうえで、Organizationのnameに正式名称、alternateNameに通称を書き、sameAsに公式のSNSとマップのページを入れました。
表記がそろったことで、同じ事務所だと、伝わりやすくなりました。
構造化データを入れる前に、先にやること
構造化データは、土台の上に乗せる、最後の仕上げです。
その前に、マップ・サイト・SNSで、店名・住所・電話番号・営業時間が、同じ内容にそろっていることが大切です。
元の情報が食い違ったまま、構造化データだけを入れても、効果は期待できません。
- 1基本情報(NAP)を、1つの基準表にまとめる店名・住所・電話番号・営業時間・URLを、正しい形で1か所に書く。
- 2Google・Apple・Bingのマップを、基準表に合わせる無料で、自分で登録・修正できる。
- 3公式サイトに、文章で情報を書く画像ではなく、テキストで。FAQも書く。
- 4構造化データを入れる基準表と、同じ内容で書く。
- 5月に1回、見直す営業時間・電話番号などを変えたら、すべての場所を同時に直す。
店名・住所・営業時間を入力するだけで、貼り付け用の構造化データ(JSON-LD)を作れます。無料・登録不要です。
構造化データを無料で作る各マップの店名・住所・電話・営業時間が揃っているか、まとめて比べられます。
店舗情報の統一チェックへGoogle・Apple・Bing・AIで自分のお店が見つかるか、無料で確認できます(登録不要)。
無料で掲載状況をチェック自分でやる時間がない・不安な方へ。登録や情報整備のサポートも行っています。
登録・修正のサポートを見る