AI検索に構造化データは必要か｜最初に入れる3つと確認手順

AIによる概要やAIモードに表示されるために、特別な構造化データを入れる必要はありません。Googleが生成AI検索の最適化ガイドで、はっきりそう書いています。構造化データは、ページの内容を検索エンジンに伝えることと、対象の種類のリッチリザルトのために入れるものです。優先して入れるのは、Organization・Article・パンくずリストの3つです。

自社サイトを社内で運用していて、「AI検索対策として構造化データを入れるべきか」「何から入れるか」を決めたい広報・Web担当者に向けた記事です。読み終わる頃には、3つのJSON-LDを自社の値に書き換えてページに入れ、正しく出ているかを確かめられる状態を目指します。

AIの回答に自社の情報が出てこない原因から調べたい場合は、先に生成AIの回答に自社の情報が出てこないときのGoogleの要件と確認手順をご覧ください。

Contents / 目次

1. AI検索に構造化データは必要か。Googleの説明と入れる順番
2. 最初に入れる3つ。JSON-LDの書き方
3. 入れたあとの確認手順。リッチリザルト テストとSearch Console
4. AI検索対策のつもりで起きる失敗と防ぎ方
5. AI検索と構造化データのよくある質問

AI検索に構造化データは必要か。Googleの説明と入れる順番

生成AI検索のためだけなら、構造化データは必要ありません。ただし、通常のSEOの一部としては引き続き使うよう、Google自身が勧めています。

Googleの生成 AI 検索の最適化ガイドには、次の一文があります。

Googleの説明。「生成 AI 検索に構造化データは必要ありません。追加する必要がある特別な schema.org マークアップもありません。」

同じガイドは、生成AI検索向けの書き方をする必要も、コンテンツを細かく分割する必要もないと説明しています。GoogleのAI 機能とウェブサイトのページでも、AIによる概要とAIモードに表示されるための追加の要件は無く、SEOの基本がそのまま有効だとしています。

そのため、「AIは段落単位で引用元を選ぶので構造化データで区切る」「AI向けのschemaを足す」といった提案は、Googleの説明とは逆向きです。構造化データに期待してよいのは、次の2つです。

• 内容を伝える：社名・ロゴ・記事の公開日・著者などを、決まった形で検索エンジンに伝える
• リッチリザルト：対象の種類だけ、検索結果に通常と違う表示が出ることがある

この2つを基準にすると、入れる順番は次の表のとおりです。FAQのリッチリザルトは2026年5月7日から検索結果に表示されなくなり（Google検索セントラルのドキュメント更新履歴）、HowToは2023年9月に表示が終わっています（Google検索セントラル ブログ）。

順番	種類	入れるページ	入れる理由
1	Organization	トップページか会社概要の1ページ	社名・ロゴ・連絡先などの会社の情報を伝える
2	Article	コラム・お知らせの各記事	見出し・画像・公開日・更新日・著者を伝える
3	BreadcrumbList（パンくずリスト）	トップ以外の各ページ	パソコンの検索結果でパンくずとして表示されることがある（モバイルは2025年1月からドメインだけの表示。Googleの発表）
来店型なら2番目	LocalBusiness	来客を受ける店舗・事業所のページ	必須は name と address。電話番号は国番号と市外局番から（Googleのドキュメント）
後回し	FAQPage	―	2026年5月7日から検索結果に表示されない
入れない	HowTo	―	2023年9月に表示が終了

通販で商品ページを持っている会社なら、Product も候補に入ります。ただ、会社案内とコラムが中心のBtoBサイトでは、Organization・Article・パンくずリストの3つで足ります。

社内にWebの施策を判断する担当者がいない場合は、毎月の数字を見て優先順位を決め、合意した作業を行う定額制マーケティング支援（マーケの右腕）という進め方もあります。

この章で押さえるのは、構造化データは「AI検索のため」ではなく「内容を伝えるため」に入れるもので、最初は表の順番1〜3の3つに絞ってよい、という判断です。

最初に入れる3つ。JSON-LDの書き方

3つとも、Googleが推奨するJSON-LD形式で書き、script タグごとページのHTMLに入れます。新しく書く前に、今どんな構造化データが出ているかを調べるところから始めます。

ステップ1。今出ている構造化データを調べる

トップページと記事ページを1つずつブラウザで開き、ページのソースを表示します（Chromeなら Windows は Ctrl＋U、Mac は Command＋Option＋U）。ソースの中で「application/ld+json」を検索し、見つかった数と @type の値を書き出します。

WordPressでは、テーマやSEOプラグインがすでに構造化データを出していることがあります。出ている種類は足さずに中身の値を確かめ、無い種類だけを足すのが基本です。JavaScriptで後から入れている構造化データはソースに出ないため、次の章のリッチリザルト テストで確かめます。

ステップ2。Organizationをトップページか会社概要に入れる

Organizationは、すべてのページに入れる必要はありません。トップページか、会社を説明する1ページに入れます。［ ］の部分を自社の値に書き換えてください。JSONにはコメントを書けないので、説明はコードの後の箇条書きにまとめました。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "［サイト名と同じ社名］",
  "legalName": "［登記上の正式名称］",
  "url": "https://example.co.jp/",
  "logo": "https://example.co.jp/images/logo.png",
  "telephone": "+81-［市外局番の0を除いた番号］",
  "email": "info@example.co.jp",
  "address": {
    "@type": "PostalAddress",
    "postalCode": "［郵便番号］",
    "addressRegion": "［都道府県］",
    "addressLocality": "［市区町村］",
    "streetAddress": "［町名・番地・建物名］",
    "addressCountry": "JP"
  },
  "sameAs": [
    "https://www.instagram.com/［アカウント名］/",
    "https://www.facebook.com/［ページ名］"
  ]
}
</script>

• name：サイト名と同じ名前にする。「株式会社」まで含めた正式名称は legalName に書く
• logo：112×112ピクセル以上の画像のURL
• sameAs：会社が運営しているSNSなどの公式ページだけを並べる
• 住所・電話番号：会社概要の本文に表示している表記と同じ値にする

ロゴの大きさなどの決まりは、Googleの組織（Organization）の構造化データのページで確かめられます。

会社概要のページそのものに何を書くかは、会社概要に載せる必須項目と構造化データの雛形で詳しく解説しています。

ステップ3。Articleを各記事に入れる

Articleは、コラムやお知らせの記事ごとに入れます。値は、その記事のページに表示しているタイトル・画像・日付・著者名から写します。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "［記事のタイトル］",
  "image": ["https://example.co.jp/images/［記事の画像］.jpg"],
  "datePublished": "2026-10-11T09:00:00+09:00",
  "dateModified": "2026-10-11T09:00:00+09:00",
  "author": [{
    "@type": "Person",
    "name": "［著者の名前］",
    "url": "https://example.co.jp/author/［著者ページ］/"
  }]
}
</script>

• 日付：末尾に「+09:00」のようなタイムゾーンを付ける
• author.name：名前だけを書く。肩書や会社名は入れない
• author.url：著者を紹介しているページのURL。Googleは、著者を区別するために url か sameAs を使うよう勧めている
• dateModified：内容を実際に変えたときだけ更新する

著者名とタイムゾーンの書き方は、Googleの記事（Article）の構造化データのページに載っています。

ステップ4。パンくずリストを各ページに入れる

パンくずリストは、トップ以外のページに入れます。Googleは、URLの構造をそのまま写すのではなく、読者がたどる一般的な経路を示すよう勧めています。項目は2つ以上で、最後の項目の item は省略できます（パンくずリストの構造化データ）。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://example.co.jp/" },
    { "@type": "ListItem", "position": 2, "name": "コラム", "item": "https://example.co.jp/column/" },
    { "@type": "ListItem", "position": 3, "name": "［このページのタイトル］" }
  ]
}
</script>

WordPressで記事ごとにArticleとパンくずリストを書き換えるのは現実的ではありません。記事が数十本を超えるなら、SEOプラグインかテーマの機能で自動で出し、Organizationだけを設定で確かめる形が負担の少ない進め方です。

この章で押さえるのは、先に今出ているものを調べ、無い種類だけを、本文と同じ値で足すという順番です。

入れたあとの確認手順。リッチリザルト テストとSearch Console

確認は、1ページずつ見るリッチリザルト テストと、サイト全体を見るSearch Consoleの2段階で行います。

リッチリザルト テストで1ページずつ確かめる

1. Googleのリッチリザルト テストを開き、構造化データを入れたページのURLを入力してテストする
2. 検出された項目の一覧で、入れた種類（パンくずリストなど）が出ているかを確かめる
3. 無効な項目があれば、表示される理由（例 項目「image」がありません）を読み、該当する値を修正する
4. 公開し直してから、もう一度テストする

リッチリザルト テストが調べるのは、Googleのリッチリザルトの対象の種類です。schema.orgの書き方として正しいかを全体で確かめたいときは、Schema Markup Validator にも同じURLを入れます。

Search Consoleのレポートで全体を見る

Search Consoleのリッチリザルト レポートでは、サイト全体の状態を種類ごとに見られます。レポートの見方は、このSearch Consoleヘルプのページで確かめられます。

注意したいのは、Organization・Article・LocalBusiness がこのレポートの対象に入っていない点です。対象の種類の一覧も、同じヘルプのページに載っています。

3つのうちここで見られるのはパンくずリストだけなので、OrganizationとArticleはリッチリザルト テストで確かめます。

公開前のチェックリスト

• 本文との一致：社名・住所・日付・著者名が、ページに表示している値と同じか
• 二重の出力：同じ種類の構造化データが、テーマ・プラグイン・手書きから重ねて出ていないか
• Organizationの name：サイト名と同じ名前か
• ロゴ：112×112ピクセル以上か
• 日付：タイムゾーンが付いているか
• author.name：名前だけになっているか
• FAQPage・HowTo：検索結果での表示を期待して新しく足していないか

AI検索での表示回数の確かめ方

Search Consoleの生成 AI パフォーマンス レポート（検索）では、AIによる概要とAIモードでの表示回数を見られます。Googleのヘルプによると、2026年8月31日に世界中のすべてのサイトへ提供されました。

• 見られる項目：表示回数（ページ・国・日付・デバイスごと）
• 見られない項目：クリック数と検索語句（2026年10月11日時点）

手順はSearch ConsoleでAI検索の表示回数を確認する手順で解説しています。

構造化データを入れたページの表示回数を、入れる前の月と比べて記録しておくことはできます。ただし表示回数は検索の需要や本文の変更でも動くので、変化を構造化データだけの効果と読まないようにします。

この章で押さえるのは、OrganizationとArticleはSearch Consoleのレポートに出ないので、リッチリザルト テストで1ページずつ確かめる必要がある、という点です。

AI検索対策のつもりで起きる失敗と防ぎ方

構造化データを「AIに読ませるためのもの」と考えて作業しても、生成AI検索での扱いは変わりません。冒頭で見たとおり、Googleは生成AI検索に特別なマークアップは要らないと説明しています。本文と違う値を書くと、リッチリザルトに表示されなくなる場合もあります。このテーマで起きやすい失敗を4つ挙げます。

本文に無い情報をJSON-LDだけに書く

AIに伝えたい強みや実績、営業時間などを、本文には書かずJSON-LDにだけ書くと、表示内容と違うマークアップになります。Googleは構造化データに関する一般的なガイドラインで、読者に見えない内容をマークアップしないよう求めています。

違反して手動による対策を受けると、そのページはリッチリザルトに表示されなくなります（ウェブ検索の掲載順位には影響しないと同じページに書かれています）。

伝えたい情報は先に本文に書き、JSON-LDの値はその本文から写します。

AI向けにFAQPageやDefinedTermを量産する

「AIに拾われやすい」という理由で、全記事にFAQPageを足したり、用語集にDefinedTermを入れたりする提案があります。

FAQのリッチリザルトは2026年5月7日から表示されません（Googleのドキュメント更新履歴）。DefinedTermは、Googleがリッチリザルトの対象の種類をまとめた構造化データの検索ギャラリーに載っていません。

生成AI検索に特別なマークアップが要らないことは、冒頭の章で見たとおりです。本文のFAQは読者のために残し、JSON-LDの追加は後回しにします。

テーマとプラグインでOrganizationが二重に出る

SEOプラグインを入れたあとに、テーマの機能や手書きのコードでもOrganizationを出すと、同じ会社について社名やロゴの違う構造化データが2つ出ることがあります。SEOプラグインを使っている場合は、設定画面の社名とロゴの欄に、意図した値が入っているかも確かめます。ステップ1で調べた結果をもとに、どこから出すかを1つに決め、ほかは止めます。

著者名に肩書を入れ、日付にタイムゾーンを付けない

専門性を伝えたくて、author.name に「代表取締役 山田太郎（Webマーケター）」のように肩書を入れると、Googleの説明と合わなくなります。name は名前だけにし、肩書は jobTitle プロパティに、経歴は author.url で示す著者ページの本文に書きます。日付も「2026-10-11」だけでなく、時刻とタイムゾーンまで書きます。

この章で押さえるのは、AI向けに何かを足しても生成AI検索での扱いは変わらず、リッチリザルトの対象になるには本文と同じ値を正しく出す必要がある、という点です。

AI検索と構造化データのよくある質問

まずは自社のトップページのURLをリッチリザルト テストに入れ、構造化データが何も出ていないのか、プラグインが何かを出しているのかだけ確かめてください。著者の情報まで詳しく入れたい場合は、著者の構造化データの書き方とJSON-LDの例文に進むと、次の作業が決まります。

構造化データより先に、どのページの本文を書き足せばAI検索でも自社の説明が正しく伝わるかを決めたい場合は、コレットラボのGEO（LLMO）対策・AI検索対策にご相談ください。会社の説明・判断の根拠・記事の3つを診断し、修正する順番を決めます。