構造化マークアップとは？AI検索時代の書き方と4つの型

「構造化データ、入れたほうがいいですよ」。
制作会社や社内の誰かにそう言われたまま、手が止まっている。
このページにたどり着いた方の多くは、たぶんその状態だと思います。

調べれば解説記事は出てきます。
ただ、読み終わっても「うちのサイトの、どのページに、何を、どう書けばいいのか」がわからない。
コードが載っていても断片で、コピーして貼れる状態になっていない。

この記事では、まず入れる4つの型を、そのまま貼って値を差し替えられるJSON-LDのコードごと出します。
あわせて、地域ビジネスや士業が足したい型、WordPressでの実装、確認手順、やってはいけないことまで通しで書きます。
AI検索の文脈も、Googleの公式ドキュメントにあることだけを根拠に整理します。

書いているのは、京都で屋号「チャメッケ」として中小企業のAIO・SEO支援をしている竹田です。
ここに出す型は、自分のサイトでも入れて、同じ手順で確認しているものだけにしています。

構造化マークアップとは何をするものか

構造化マークアップとは、ページに書いてある情報を、機械が読み取れる決まった形式で書き添える作業です。
人間向けの見た目とは別に、機械向けの説明書きをもう一枚つけるイメージで合っています。

なぜ二度手間が要るのか。
HTMLがもともと「見た目の構造」しか表現できないからです。
ページに「2026年7月20日」と書いてあっても、それが公開日か、更新日か、イベントの開催日かは、HTMLだけでは区別がつきません。
人間は文脈から読み取りますが、機械は推測するしかない。
その推測を宣言に置き換えるのが構造化データです。

この形式の語彙を定めているのが、schema.org（スキーマドットオーグ）です。
Google、Microsoft、Yahoo!が2011年に立ち上げ、のちにYandexが加わった、共通の単語帳のようなもの。
「会社ならOrganization」「記事ならArticle」というふうに、型（タイプ）とプロパティ（属性）が定義されています。

押さえておきたいのは、schema.orgの語彙とGoogleが検索結果で使う型はイコールではない、という点です。
膨大な型のうちGoogleがリッチリザルトとして扱うのは一部だけ。
逆に言えば、表示に使われない型でも書くこと自体は自由です。

構造化データが検索とAIに読まれる仕組み

構造化データは、同じページの中に「人が読む本文」と「機械が読む宣言」を二重に持たせ、検索エンジンとAIが意味を推測せずに受け取れるようにします。
まず本文があり、その内容と一致する宣言をJSON-LDで書き添える、という順番です。

ここでAI検索の話をはっきりさせておきます。
Google検索セントラルの「AI 機能とウェブサイト」には、AI OverviewやAIモードに表示されるための追加要件はなく、特別な最適化も要らないと書かれています。
そのうえで「追加すべき特別なschema.org構造化データもありません」と明記されています（2026年7月時点）。
つまり「構造化データを入れればAIに引用される」という説明は、Googleの公式見解とは違います。

ただし同じドキュメントは、構造化データを使うならページに見えているテキストと一致させるよう求めています。
AIも検索エンジンも、ページから「誰が」「いつ」「何について」書いたのかを取り出そうとします。
それを本文の文脈だけに頼らせるか、宣言で渡すかの違いです。
引用される保証はありませんが、取り違えられる余地は減らせます。

AI検索全体の考え方はLLMO・AIO対策の教科書で整理しています。
構造化データは、そこで書いた「AIに読み取りやすい形で情報を置く」話の、いちばん機械寄りの部分です。
本文そのものの書き方は引用される記事の書き方5つのほうが近いので、あわせて読むと役割分担がはっきりします。

JSON-LDの書き方と置き場所の基本

JSON-LDは、scriptタグの中にJSON形式で書き、そのページのHTMLに置くだけで動きます。
本文のHTMLを書き換える必要がないので、あとから足すのも消すのも簡単です。

いちばん短い形はこれです。
@contextで「schema.orgの語彙を使います」と宣言し、@typeで型を選び、あとはプロパティを並べるだけ。
構造としては、この3つしかありません。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://example.com/"
}
</script>

置き場所はheadでもbodyでもかまいません。
一括管理しやすいのはheadなので、迷ったらそちらで問題ありません。
1ページに複数のブロックを置くこともできます。
記事ページなら、パンくずと記事を別々に置いて構いません。
まとめたい場合は@graphという配列に複数の型を並べる書き方もあります。

中小企業がそろえたい構造化データ4つ

中小企業のサイトでそろえるのはOrganization、BreadcrumbList、Article、FAQPageの4つ。
この順に優先度が下がります。
この4つは「誰が出しているサイトか」「このページはどこか」「誰がいつ書いたか」「どの質問にどう答えているか」という、別々の問いに答えています。
役割がかぶらないので、少ない手数で説明できる範囲が広がります。

1. Organization：サイトの発行者を宣言する

Organizationは、そのサイトを出しているのが誰かを宣言する型です。
Google検索セントラルによれば必須プロパティはなく、当てはまる推奨プロパティをできるだけ入れる形。
置き場所も全ページではなく、トップページか会社概要のような1ページで足りるとされています。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "alternateName": "サンプル",
  "url": "https://example.com/",
  "logo": "https://example.com/images/logo.png",
  "description": "京都で業務用機器の設計と修理を行う会社です。",
  "email": "info@example.com",
  "telephone": "+81-75-000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "中京1-2-3",
    "addressLocality": "京都市中京区",
    "addressRegion": "京都府",
    "postalCode": "604-0000",
    "addressCountry": "JP"
  },
  "sameAs": [
    "https://www.instagram.com/example/",
    "https://www.youtube.com/@example"
  ]
}
</script>

効いてくるのはsameAsです。
InstagramやYouTubeなど、同じ主体を指す別のURLを並べます。
散らばっている情報が同じ会社のものだと機械に伝わるので、ここは飛ばさずに埋めておきたいところです。

2. BreadcrumbList：ページの位置を宣言する

BreadcrumbListは、そのページがサイトのどの階層にあるかを宣言する型です。
必須プロパティはitemListElementで、中身はListItemの配列。
各ListItemにposition（順番）とname（表示名）とitem（URL）を入れます。
最後の階層はそのページ自身なのでitemを省略できます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "ホーム",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "お役立ち記事",
      "item": "https://example.com/column/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "構造化マークアップとは"
    }
  ]
}
</script>

4つのうち、いちばん変化が目に見えやすいのがこれです。
実装も定型なので、テンプレート側で自動生成すれば以後は手がかかりません。

3. Article：記事の属性を宣言する

Articleは、記事ページに著者・公開日・更新日などを宣言する型です。
Googleが対応しているのはArticle、NewsArticle、BlogPostingの3つ。
ここも必須プロパティはなく、公式ドキュメントは、必須のプロパティはないので自分のコンテンツに当てはまるプロパティを追加してほしいと説明しています。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "構造化マークアップとは何か",
  "image": [
    "https://example.com/images/cover-16x9.jpg",
    "https://example.com/images/cover-1x1.jpg"
  ],
  "datePublished": "2026-07-25T09:00:00+09:00",
  "dateModified": "2026-07-25T09:00:00+09:00",
  "author": {
    "@type": "Person",
    "name": "山田太郎",
    "url": "https://example.com/author/yamada/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/images/logo.png"
    }
  }
}
</script>

手を抜かないほうがいいのがauthorです。
名前を文字列で書くだけでも通りますが、Person型にしてurlで著者ページを指すと、書き手を一意にたどれる状態になります。
誰が書いたかわからない記事が増えている状況で、ここを埋める価値は上がっていると考えています。
dateModifiedは、中身を実際に触ったときだけ動かします。

4. FAQPage：質問と答えの対応を宣言する

FAQPageは、そのページに載っている質問と答えの対応を宣言する型です。
必須はmainEntityで、中身はQuestionの配列。
各Questionにname（質問文の全文）とacceptedAnswer（Answer型でtextに回答全文）を入れます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "見積もりは無料ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "無料です。図面をお送りいただければ3営業日以内にお返しします。"
      }
    },
    {
      "@type": "Question",
      "name": "対応エリアはどこまでですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "京都府と滋賀県を中心に、近畿一円へ訪問しています。"
      }
    }
  ]
}
</script>

つまり「検索結果に大きく出すため」にFAQPageを入れる理由は、もうありません。
ただ、schema.orgの語彙としては引き続き有効で、質問と答えの対応を機械可読な形で残す役割は変わっていません。
私は、リッチリザルト目当てではなく「このページはこの質問に答えている」という整理として書くもの、と位置づけを変えました。
優先するなら先にOrganizationとBreadcrumbListです。

• トップページか会社概要にOrganizationを1つ置いたか
• 下層ページ全体にBreadcrumbListが自動で入る状態にしたか
• 記事ページのArticleに著者と公開日・更新日が入っているか
• FAQPageの質問と答えが、本文にそのまま表示されているか
• JSON-LDに書いた値が、ページの表示内容と食い違っていないか

地域ビジネスと士業が足したい型

店舗や事業所があるならLocalBusiness、形のないサービスを売っているならServiceを足します。
4つの基本型が「サイトと記事の説明」だったのに対して、この2つは「事業そのものの説明」にあたります。

LocalBusinessは、Googleが必須としているプロパティがnameとaddressの2つ。
そのうえで、当てはまるプロパティをできるだけ多く含めるほど結果の品質が高くなると案内しています。
もう1つ大事なのが、できるだけ具体的なサブタイプを使うこと。
飲食店ならRestaurant、小売ならStore、電気工事ならElectricianというように、細かい下位の型が用意されています。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Store",
  "name": "サンプル金物店",
  "url": "https://example.com/",
  "telephone": "+81-75-000-0000",
  "image": "https://example.com/images/shop.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "中京1-2-3",
    "addressLocality": "京都市中京区",
    "addressRegion": "京都府",
    "postalCode": "604-0000",
    "addressCountry": "JP"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 35.01234,
    "longitude": 135.76543
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "18:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "10:00",
      "closes": "16:00"
    }
  ]
}
</script>

geoを書くなら、緯度経度は小数点以下5桁以上にする決まりです。
地図アプリで自分の店舗を表示すれば取得できます。
営業時間はopeningHoursSpecificationで曜日ごとに書けます。
深夜0時をまたぐ営業や、期間限定の営業時間も表現できます。

士業やコンサル、制作会社のように形のない商品を扱う場合はServiceが使えます。
Serviceは2026年7月時点でGoogleがリッチリザルトとして表示する型ではありませんが、「これは何のサービスで、誰が提供し、どこを対象にしているのか」を宣言として残せる価値はあります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "AIO・SEO伴走支援",
  "serviceType": "検索エンジン最適化の支援",
  "description": "中小企業のサイトに対して、構造化データの実装と記事設計を伴走で支援します。",
  "url": "https://example.com/service/aio/",
  "provider": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "url": "https://example.com/"
  },
  "areaServed": {
    "@type": "AdministrativeArea",
    "name": "京都府"
  }
}
</script>

WordPressでの実装と確認の手順

WordPressなら、定型的な部分はプラグインに任せ、自分で決める値がある部分だけ手で書くのが現実的です。
全部を手書きすると更新のたびに作業が発生し、全部をプラグイン任せにすると事業に固有の情報が抜け落ちます。

観点	プラグインに任せる	手で書く
向いている型	BreadcrumbList／Article／Organizationの基本項目	Service／LocalBusinessの詳細／sameAs
更新のたびの手間	かからない（自動生成）	ページを触るたびに見直す
表示とのずれ	起きにくい（表示と同じ値を拾う）	食い違いやすい
自由度	設定できる項目の範囲内	必要なプロパティを好きに足せる

SEO系のプラグインは、たいてい記事とパンくずと発行者情報のJSON-LDを自動で出力します。
まずは自分のサイトのソースを見て、すでに何が出ているかを確認してください。
すでにArticleが出ているのに手でもう1つ足すと、同じページに矛盾する宣言が2つ並びます。
足りない型だけを足すのが基本です。

手で書く場合、投稿ごとに違う内容ならカスタムHTMLブロックに直接貼るのが早いです。
サイト共通の内容は、テーマのヘッダーかコードスニペット系のプラグインで出力します。
テーマ本体を直接編集すると更新で消えることがあるので、子テーマかスニペット管理が安全です。

1. 下書きの段階でJSONを検証するJSONとして壊れていないかを先に見ます。
   カンマや波かっこのミスはここでほぼ潰せます。
2. リッチリザルトテストにかける公開したページのURLをリッチリザルトテストに入れると、その構造化データからどのリッチリザルトが生成できるかが表示されます。
   コードを直接貼って試すこともできます。
3. Schema Markup Validatorで語彙を見るschema.orgの書き方として正しいかを確認します。
   Serviceのように表示対象外の型は、こちらでしか検証できません。
4. Search Consoleの拡張レポートを見る公開後は「拡張」セクションに型ごとのレポートが出ます。
   実際にGoogleが読み取った結果なので、テストツールと違うことがあります。
5. 1〜2週間後にもう一度見る拡張レポートは即時反映ではありません。
   反映を待ってから、エラーと警告の件数を確認します。

構造化データでやってはいけないこと

やってはいけないことの中心は1つで、ページに表示されていない内容をマークアップしないことです。
Google検索セントラルの一般的なガイドラインには「ページの読者に表示されないコンテンツをマークアップしないでください」と書かれています。
ここを外すと、技術的に正しく書けていても違反になります。

実務でよく見るのは、本文にFAQを載せていないのにJSON-LDにだけ質問と答えを詰め込む、扱っていないサービス名をServiceに書く、ページに出していない住所や営業時間をLocalBusinessに書く、といったケースです。
どれも「機械にだけ見せる情報を増やす」発想で、Googleがはっきり禁じている方向です。
前の担当者が入れたJSON-LDに、いまは提供していないサービス名が残っていたのも見たことがあります。
悪意ではなく消し忘れですが、結果は同じです。

もう1つ重いのがレビューです。
ガイドラインは、実際の利用者によるものではないレビューや評価は手動による対策の対象になり得る、としています。
自分で書いた星5つをaggregateRatingとして出すやり方は、短期的に見栄えがしても割に合いません。
手動対策を受けると、そのページはリッチリザルトとして表示される資格を失います。
加えて「偽のレビューや、ページの主題と無関係なコンテンツをマークアップしないでください」ともしています。

逆に言えば、書いてあることをそのまま宣言している限り、事故は起きにくいです。
この「実態と表示と宣言をそろえる」考え方は、一次情報よりも大切なこととも重なります。
AIOとSEOの違いを踏まえると、機械に見せる情報と人に見せる情報を分けること自体がもう成立しなくなってきています。

まとめ：構造化データは意味の翻訳

構造化マークアップは、ページに書いてある意味を、機械が読める言葉に翻訳する作業です。
新しい情報を作るのではなく、すでにあるものを言い直す。
だから本文が薄いサイトに構造化データだけを足しても状況は変わりませんし、しっかり書いてあるページほど翻訳する価値があります。

順番としては、Organizationを1ページ、BreadcrumbListを全下層ページ、Articleを記事ページ。
ここまででサイトの骨格は説明できます。
店舗や事業所があるならLocalBusiness、形のないサービスならServiceを足す。
FAQPageは表示が終わった以上、優先順位を下げて意味の整理として書けば十分です。
そして書いたら確認する。
リッチリザルトテストで文法を見て、拡張レポートで読み取られ方を見る。
この2つを固定すれば、放置されることはなくなります。

最後にもう一度書いておきます。
構造化データを入れれば順位が上がる、AIに引用される、という話ではありません。
できるのは、取り違えられる余地を減らすことまでです。
AIも人間も、渡された情報の範囲でしか判断できません。
だからこそ、渡す情報を整えておく。
手を入れる順番に迷ったら、AI Overview対策のやり方7手順や無料AIO診断から入ってみてください。