構造化データとは？AI引用との関係とJSON-LD・FAQPageの書き方

最終更新：2026年10月18日

構造化データとは、ページの中身を検索エンジンやAIが読み違えないように、schema.orgという共通の語彙で書き添える機械向けの説明書きのことです。この記事で扱うのはSEOとウェブ制作の言葉で、行と列で整理された表形式のデータを指すデータ工学の「構造化データ（非構造化データの反対）」とは別のものです。先に結論を書くと、構造化データを入れればAIに引用されるわけではありません。Googleは生成AI検索に構造化データは必要ないと明言しています。それでも、Article・Person・Organization・FAQPageの4つを、本文と食い違わない形で入れておく価値はあります。この記事では、その4点セットの表、Googleの公式見解、JSON-LDの最小例、FAQPageのいまの扱いまでを書いていきます。

構造化データとは？SEOの意味とデータ工学の意味の違い

SEOでいう構造化データは、ページに書いてある内容を「これは記事の見出し」「これは著者の名前」「これは公開日」と、機械が迷わず受け取れる形に書き直したものです。人が読む本文はそのままで、同じ情報をもう一度、決まった書式で添える作業だと考えると分かりやすいと思います。

「構造化データ」で検索すると、データベースや分析の話が多く出てきます。同じ言葉が二つの分野で別の意味を持っているので、最初に分けておきます。

SEOの構造化データの書き方は3種類あり、Googleはどれにも対応しています。Google検索セントラルの「構造化データの仕組みについて」は、JSON-LD・microdata・RDFaの3つに対応したうえで、JSON-LDを推奨しています。JSON-LDは本文のHTMLとは別のかたまりとして書けるので、本文を壊さずに足したり直したりできます。この記事の例も、すべてJSON-LDで書きます。

同じページには、大事な断り書きもあります。構造化データを入れても、検索結果での見え方が変わるとは限りません。Googleの構造化データに関する一般的なガイドラインは、構造化データが検索結果に表示されるとは限らないと明記し、読者に見えない内容をマークアップしないよう求めています。構造化データは、本文に書いたことを言い直すものであって、本文にないことを付け足す場所ではありません。

AI引用のための基本4点セット──Article・Person・Organization・FAQPage

AI引用を意識したサイトで入れておく構造化データは、Article・Person・Organization・FAQPageの4つで足ります。ぼくが自分のサイトの型として決めている正本も、この4点セット以上の投資は不要という立場で、それぞれ「何を機械に伝えるか」が違います。

表の右の列は、Google検索セントラルの記事（Article）と組織（Organization）のドキュメント、ドキュメントの更新履歴で確かめた内容です。Articleの著者については、名前だけを入れる、複数の著者は一人ずつ分けて書く、PersonかOrganizationの型を付ける、といった細かい指定もあります。

4つのうち、AI時代にいちばん意味が増したのはPersonだと思っています。AIの回答では、「誰が言っているか」で信用の重みが変わると考えているからです。記事の著者が、SNSやnoteで同じ名前で発信している人と同一人物だと機械に伝えられるのは、sameAsくらいしかありません。一次体験を書く記事ほど、その体験が誰のものかを結んでおく意味があります。

構造化データはAIの引用に効くのか──Googleの公式見解と「特別なスキーマ」商材

Googleの公式見解は、生成AI検索に構造化データは必要なく、AI向けの特別なschema.orgのマークアップも存在しない、というものです。構造化データは、AIに引用されるための鍵ではなく、検索の基本を整える道具のひとつという位置づけです。

Google検索セントラルが2026年5月に公開した「生成 AI 機能向けに最適化する」（2026年10月9日更新）は、AEOやGEOと呼ばれる対策の誤解を正す節で、構造化データに力を入れすぎることを挙げています。そこでは、生成AI検索に構造化データは必要なく、追加すべき特別なマークアップもないと書いたうえで、リッチリザルトの対象になるのに役立つので、SEO全体の一部として使い続けることを勧めています。「AI 機能とウェブサイト」のページも同じ立場で、ベストプラクティスとして挙げているのは、構造化データをページに表示されるテキストと一致させることです。

AIの回答に載るかどうかを決めているのは、構造化データより、普通の検索での評価です。調査会社シーオークラリティ（seoClarity）が2025年10月に米国の36万2,000キーワードで調べた結果では、AIによる概要の94%が、検索の上位20位以内のページを少なくとも一つ引用していました。SEOの土台の考え方はSEOとは？何の略かとSEO対策の3種類、AI検索との関係に書いたとおりで、構造化データはその中の「テクニカルSEO」の一項目にすぎません。

Google以外のAI、たとえばChatGPT・Claude・Perplexity・Copilotが構造化データをどう使っているかは、各社の公式ドキュメントで確かめられる説明が、ぼくが探した範囲では見つかりませんでした。講演での発言が業界メディアで報じられることはありますが、仕様として約束されたものではありません。

ここで気をつけたいのが、「AI専用のスキーマ」「LLMに読ませる特別なマークアップ」を入れれば引用されると売る商材です。Googleは特別なマークアップは不要と書いていて、効果を示した一次データも見当たりません。業者に相談するなら、次の3つを確かめると判断を誤りにくくなります。

JSON-LDの書き方──架空のサイトで作る最小例

JSON-LDの書き方は、ページの中に<script type="application/ld+json">のかたまりを置き、その中に「型」と「プロパティ」を書くだけです。ここでは架空の料理ブログ「ひとさら日記」（example.com）の1記事を例に、ArticleとFAQPageの最小形を書きます。

まず、記事の型（BlogPosting）と、著者（Person）、運営者（Organization）をひとつにまとめた例です。著者のsameAsには、本人が同じ名前で発信しているページのURLを並べます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "冷蔵庫の残り野菜で作る、10分のスープ",
  "datePublished": "2026-10-01T09:00:00+09:00",
  "dateModified": "2026-10-15T09:00:00+09:00",
  "image": ["https://example.com/img/soup-16x9.jpg"],
  "author": {
    "@type": "Person",
    "name": "佐藤みどり",
    "url": "https://example.com/profile/",
    "sameAs": [
      "https://x.com/example_midori",
      "https://note.com/example_midori"
    ]
  },
  "publisher": {
    "@type": "Organization",
    "name": "ひとさら日記",
    "url": "https://example.com/"
  }
}
</script>

次に、記事の末尾に「よくある質問」がある場合のFAQPageです。質問（Question）と答え（Answer）の組を、本文に書いたとおりの文章で入れます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "スープは冷凍できますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "できます。粗熱を取ってから保存袋に入れ、2週間を目安に使い切ります。"
      }
    }
  ]
}
</script>

書くときに外しやすいのは3点です。日付はタイムゾーン付きのISO 8601形式（例の「+09:00」）にすること。author.nameには名前だけを入れ、肩書や「監修」などの言葉を混ぜないこと。FAQPageの文章を本文と一字一句そろえ、本文にない質問を足さないこと。WordPressなら、テーマやSEOプラグインがArticleを自動で出していることが多いので、手で足す前に、公開ページのソースで同じ型が二重に出ていないかを確かめてください。

実装と点検の手順──FAQPageのいまの扱いとこのブログの監査

実装の手順は「ソースで確かめる→テストツールで検証する→サーチコンソールで見張る」の3段で、FAQPageだけは、Googleでの見た目の効果がなくなった前提で扱います。FAQPageは、ここ3年で扱いが大きく変わりました。

つまり、いまFAQPageを入れても、Googleの検索結果に質問が折りたたみで並ぶことはありません。それでもぼくのサイトの型で4点セットに残しているのは、置いていても害がないとGoogle自身が説明していることと、検索結果の見た目のためではなく「答えの単位」を示すために置く、と決め直したからです。記事の末尾に読者の残りの疑問を質問の形で並べ、それぞれ2〜4文で答え切る。FAQPageは、その答えの区切りを機械にも同じ形で渡すための書式です。Google以外の検索やAIで効くかどうかは、先に書いたとおり公式には確かめられません。

このブログでも、2026年7月に自分で実地監査をしたとき、構造化データの穴が見つかりました。記事にはBlogPostingと著者のPersonが出ていましたが、トップページにはJSON-LDがひとつもなく、FAQPageも全ページでゼロでした。62記事のうち、本文にFAQのセクションがあった記事は2本だけです。構造化データ以前に、マークアップする中身がなかったことになります。いまの記事は末尾にFAQを置き、公開ページのソースではBlogPostingとFAQPageの両方が出ています。

点検の手順は次のとおりです。

ぼくのサイトの型では、AIはページ全体ではなく見出しごとのまとまりで引用する、という前提で記事を書くことにしています。そのまとまりが引用元に選ばれるかどうかは、構造化データより、見出しの直後で答えを言い切っているか、数字に出典があるか、実際にやった人にしか書けないことが入っているかで決まります。AIがクリックを奪う流れの全体像はゼロクリック検索とは？割合の出典とAI時代の対策にまとめました。

構造化データとAI引用に関するよくある質問

構造化データを入れると、AIによる概要に引用されやすくなりますか？

Googleは、生成AI検索に構造化データは必要なく、AI向けの特別なマークアップもないと説明しています。AIによる概要の94%は検索の上位20位以内のページを引用しているという調査（シーオークラリティ）もあり、引用を左右するのは普通の検索での評価です。構造化データは、その土台を整える一項目として入れるものです。

FAQPageの構造化データはもう削除したほうがいいですか？

削除する必要はありません。よくある質問のリッチリザルトは2026年5月7日以降Google検索に表示されなくなりましたが、Googleは2023年の発表で、使われていない構造化データが検索で問題を起こすことはないと説明しています。本文のQ&Aと内容がそろっていれば、残しておいて構いません。

JSON-LD・microdata・RDFaのどれで書けばいいですか？

JSON-LDで書くのが無難です。Googleは3つとも対応していますが、JSON-LDを推奨しています。本文のHTMLと切り離して書けるので、あとから直すときに本文を壊す心配がありません。

「AI専用のスキーマ」を入れるサービスは効果がありますか？

効果を示した一次データは見当たりません。Googleは、AI機能に表示されるために特別なschema.orgのマークアップを追加する必要はないと明言しています。使う型が公開ドキュメントにあるものか、本文にない情報を足していないかを確かめ、確認できないものにお金を払わないのが安全です。

おわりに──構造化データは、引用の鍵ではなく名札

構造化データの話をしていると、「何を入れたらAIに選ばれるのか」という問いに引っ張られがちです。でも、Googleのドキュメントを読み直すと、答えはかなり地味でした。特別なマークアップはない。本文と一致させる。見えないものは書かない。書いてあるのは、偽らずに名乗れということだけです。

構造化データは、引用の鍵ではない。引用されたあとに「これは誰の言葉か」を伝える名札です。

中身のない記事に名札を付けても、誰の記憶にも残りません。名札が生きるのは、その名前で書かれた一次体験が本文にあるときだけだと思っています。マークアップを足す前に、まず本文に、自分にしか書けない一段落があるかを確かめてほしいと思います。