構造化データ（schema.org）は、「このページは誰が・何を・いつ書いたのか」を、AIや検索エンジンが機械的に読み取れる形でページに添えるためのデータ仕様です。 JSON-LD形式でArticle・FAQPage・著者/監修（author／reviewedBy）まできちんと実装しておくと、生成AIがページの意味と信頼性を把握しやすくなり、引用元として選ばれる土台になります。
とはいえ、入れれば必ず引用される、という類のものではありません。構造化データはあくまで「AIにページの意味を正しく伝える補助」であって、本文の質や一次情報の有無があって初めて効いてきます。この記事では、AIに引用されることを意識したschema.orgの実装そのもの──種類の選び方、コピペできるJSON-LD例、著者/監修の書き方、現場でよく見るつまずき方まで、実装まで手がける立場から書いていきます。
扱うのは構造化データ「だけ」です。結論ファーストの文章やサイト構造といったLLMO対策の全体像は別記事に役割を分けています。先に全体像をつかみたい方はLLMOとは（基礎・全体像）、対策の進め方を知りたい方はLLMO対策のやり方をあわせてどうぞ。
TL;DR（要点）
- 構造化データは「引用される魔法」ではなく、本文の意味と信頼性をAIに正確に伝える補助レイヤー。
- 記事系で最初に入れるべきは Article（または BlogPosting／NewsArticle）＋ FAQPage ＋ BreadcrumbList の3点。
- E-E-A-Tの観点では author（著者）と reviewedBy（監修） を Person 型で明記するのが効く。
- QAPage の濫用や、章見出しをすべて Question 化する書き方は避ける（ガイドライン違反になりやすい）。
- JSON-LD形式・構文検証・本文との一致を必ず確認。構造化データと本文が食い違うと逆効果。
構造化データとは何か（AI引用の文脈で）
構造化データは、ページの内容をschema.orgという共通の語彙でマークアップし、検索エンジンや生成AIが内容を機械的に解釈できるようにするデータです。人間が読む本文（HTML）とは別に、ページの裏側に「このページはArticle、著者はこの人、監修はこの専門家、公開日はこの日」という意味づけを添えておく、と考えると分かりやすいと思います。
生成AIが引用元を選ぶときに見ているポイントは、ざっくり3つ。構造化データが効いてくるのは、このうち2番目の「機械可読性」です。
抽出しやすさ
結論が先、見出しが論理的、1段落1論点。AIが断片を抜き出しやすい本文構造。
信頼性（E-E-A-T）
一次情報・著者/監修の専門性。構造化データはこれを"宣言"する役割も持つ。
押さえておきたいのは、構造化データは「本文の内容を正確に伝える」ものであって、「無いものをあるように見せる」ものではない、という線引きです。本文に監修者が出てこないのに reviewedBy だけ書く、本文と違う日付を publishDate に書く──こうした食い違いは、むしろ信頼性を削ります。本文の質があって初めて働く増幅装置、くらいの位置づけで扱うのが正解です。
東京大学AI工学博士の見解
「構造化データは、AIに対する"自己紹介文"のようなものです。中身が伴っていれば自己紹介は正確に伝わって評価されますが、中身がなければ、自己紹介をどれだけ整えても評価は上がりません。実装に入る前に、本文に一次情報と専門性があるかをまず確かめるべきです。」
まず入れる3つ：Article／FAQPage／BreadcrumbList
記事コンテンツでAI引用を狙うなら、最初に手を付ける構造化データは次の3種類。型はたくさんありますが、あれもこれも広げる前に、まずはこの3点を本文と食い違いなく入れておけば十分です。
| タイプ | 役割 | AI引用での効き方 |
|---|---|---|
| Article BlogPosting / NewsArticle | 本文・著者・監修・公開/更新日など記事の中心情報を宣言 | 「誰がいつ書いた何の記事か」が明確になり、引用元としての素性が伝わる |
| FAQPage | 本文中の「よくある質問」Q&Aを構造化 | Q&A形式の質問に対し、回答単位で抜き出されやすくなる |
| BreadcrumbList | ホーム＞コラム＞カテゴリ＞記事の階層を宣言 | サイト内での位置づけ＝トピックの文脈をAIが把握しやすい |
FAQPage は便利な反面、誤用が目立つ型でもあります。本文に実際に置いてある「よくある質問」セクションとだけ一致させること。章見出しを無理にQ&Aへ変換するのはNG、というのが基本ルールです（後ほど詳しく触れます）。
サイト全体の構造は別レイヤーで考える
構造化データが面倒を見るのは、あくまで「1ページ単位の意味づけ」まで。複数記事をどう関連づけるか、エンティティ（自社・サービス・人物といった実体）をどう設計して内部リンクでつなぐか──このあたりは別の話で、サイト構造・エンティティ設計の領域になります。ここではschema実装に集中するので、サイト全体の情報設計はそちらに譲ります。
「JSON-LDをどこに、どう書けばいいか分からない」段階でも構いません。事前調査レポートを無料でご提供しています。実装まで手がける視点で現状を確認します。
無料で相談する著者・監修を伝える author と reviewedBy
E-E-A-T（経験・専門性・権威性・信頼性）のなかで、構造化データが直接手を貸せるのが「誰が書き、誰が監修したか」の明示です。Article の中に author（著者）と reviewedBy（監修者）を Person 型で書き込みます。
- author：記事を書いた人。Person 型で
nameを入れ、できればurl（プロフィールページ）やsameAs（外部の信頼できるプロフィール）も添える。 - reviewedBy：内容を監修・チェックした専門家。専門領域や所属がはっきりしているほど、信頼性の宣言として効く。
肝は、本文・著者ページ・構造化データの三者で情報をそろえること。監修者を reviewedBy に書くなら、本文にも監修バイラインや監修者紹介があり、できればプロフィールページ（実体ページ）も用意されている──ここまでそろっている状態が理想です。構造化データの中にだけ監修者がいる、という状態は、AI側から見ても裏が取れず、信頼の根拠になりにくいからです。
コピペできるJSON-LD実装例
構造化データの記法は何種類かありますが、いま標準なのはJSON-LD形式（<script type="application/ld+json"> の中に記述）です。本文HTMLと切り離して書けるので保守がラクで、AIや検索エンジンにとっても解釈しやすい。下は記事1ページに、Article（author＋reviewedBy）・FAQPage・BreadcrumbList をまとめて入れる最小構成の例です（値はサンプルなので、自社の実体に置き換えてください）。
注目してほしいのは3点。(1) @graph でArticle・FAQPage・BreadcrumbListを1つの <script> に束ねると管理がラク。(2) FAQPage の Question／Answer は本文の「よくある質問」と文言をそろえる。(3) 日付・著者・監修は本文や著者ページと食い違わせない。繰り返しになりますが、値は必ず自社の実体に置き換えてください。
ただし実際の実装では、CMSの出力仕様や既存の構造化データ、著者ページ・本文との整合まで確認が必要です。サンプルの置き換えだけで不安が残る場合は、公開前に専門家のチェックを挟むと手戻りを防げます。
やりがちな誤用：QAPage濫用とミスマッチ
構造化データは「入れること」より「正しく入れること」のほうがずっと大事です。型を間違えた実装は、AIや検索エンジンからの信頼をかえって落としかねません。実装の現場でよく止まるのは、だいたい次のあたりです。
- QAPage の濫用：QAPage はもともと、ユーザー同士が質問と回答を投稿するQ&A掲示板向けの型です。通常の記事や、運営側が用意した「よくある質問」には使いません。記事の質問群に当てるなら FAQPage。ここを取り違えるケースが多い。
- 章見出しをすべて Question 化する：本文の各H2を「〜とは？」という疑問形にして、まるごとFAQPageのQuestionに登録する。これはガイドラインに触れやすい使い方です。FAQPageは「実際のよくある質問」セクションだけに絞ります。
- 本文と構造化データのミスマッチ：構造化データに書いた著者・日付・FAQ内容が本文と食い違う──これは典型的な減点ポイント。「本文に無いものを構造化データだけで主張しない」を徹底してください。
| 状況 | 適切な型 | 避けるべき使い方 |
|---|---|---|
| 記事末尾の「よくある質問」 | FAQPage | QAPage を使う／章見出しを流用する |
| ユーザー投稿型のQ&A掲示板 | QAPage | 運営作成FAQに転用する |
| 解説記事の本体 | Article / BlogPosting | FAQPageで記事全体を表現する |
東京大学AI工学博士の見解
「構造化データの誤用は、たいてい『短期的にリッチリザルトを取りたい』という動機から生まれます。ただ、AIも検索エンジンも本文との整合性を見ている。型の意味に忠実に、本文に書いてあることだけを正確に宣言する——結局はこの一貫性が、いちばん引用されやすい状態を作ります。」
実装後のチェックと運用
JSON-LDは書いて終わり、ではありません。構文と内容の検証、そして本文を直したときの追従までがセットです。最低限、次を回す運用にしておきましょう。
- 構文検証：構造化データのテストツールにかけ、エラーや警告が出ていないか見る。
- 本文との一致確認：FAQの文言、著者・監修、公開/更新日が本文とそろっているか。
- 更新時の追従：本文を改稿したら
dateModifiedやFAQの中身も合わせて直す。 - 過信しない：実装したから引用される、ではない。本文の一次情報・専門性・結論ファースト構造があって初めて効く。
構造化データは、LLMO対策という大きな取り組みのうち「機械可読性」を受け持つ一パーツにすぎません。本文の書き方やサイト構造とセットになって、ようやく引用に近づきます。だからまずは全体像（LLMOとは）と進め方（LLMO対策のやり方）の中で、自社はどこの構造化データが足りていないのかを位置づけてから着手するのが、結局いちばん速い。
よくある質問
構造化データを入れればAIに引用されますか？
JSON-LDとMicrodata、どちらで書くべきですか？
記事に使うのは FAQPage と QAPage どちらですか？
reviewedBy（監修）はどう書けば信頼性が伝わりますか？
章見出しを「〜とは？」にしてFAQPageに登録してもいいですか？
構造化データの実装は自社だけでできますか？
あわせて読みたい関連記事
※本記事は、東京大学大学院 工学系研究科（博士課程）でAIを研究し、内閣府ムーンショット等の開発経験を持つ、株式会社sai X aid 代表取締役 甲斐 凜太郎の監修のもと制作しています。記載の効果・期間はケースにより変動し、成果を保証するものではありません。
「どの型を、どこに、どう書けばAIに伝わるのか分からない」段階でも問題ありません。事前調査レポートを無料でご提供。エンジニアが御社サイトに構造化データを直接実装する支援メニューもご用意しています。
詳しくはお問い合わせフォームよりご相談ください。