構造化マークアップとは?LLMO対策における重要性と書き方を解説
構造化マークアップを実装しているのに、なぜかChatGPTやGoogle AI Overviewsに自社サイトの情報が引用されない――そんなもどかしさを感じている実装担当者の方も多いのではないでしょうか。
実はその原因、構造化マークアップの「書き方」以前の部分に潜んでいるケースが少なくありません。コード自体は正しく書けていても、マークアップする情報そのものが整理されていなければ、曖昧な情報を機械にそのまま伝えるだけになってしまい、AI検索の文脈理解プロセスにうまく乗らない、という構造的な問題が起きやすいのです。
本記事では、生成AIの認識・文脈理解プロセスを専門的に研究するAIコマース研究所が、診断現場で頻出する課題パターンをもとに、JSON-LDでの具体的な書き方から、実装前に確認すべき情報整理のポイント、検証方法までを解説します。読み終える頃には、自社サイトの構造化マークアップをLLMO対策としてどこから見直すべきか、判断できる状態になっているはずです。
- 構造化マークアップは検索エンジンとAI検索の双方にコンテンツの意味を正確に伝える記述方法で、LLMO対策の土台となる。
- コードを書く前に価格や単位などの表記を整理しておかないと、曖昧な情報がそのまま機械に伝わり誤った引用のリスクが生まれる。
- 実装後はリッチリザルトテストやSearch Consoleで継続的に検証・メンテナンスすることが、LLMO対策として機能させる鍵になる。

構造化マークアップとは?SEOだけでなくLLMO対策にも重要な理由
構造化マークアップとは、Webページのコンテンツが何を意味しているかを検索エンジンやAI検索エンジンに正確に伝えるための記述方法です。SEO対策としてだけでなく、ChatGPTやPerplexity、Google AI Overviewsといった生成AI検索に自社の情報を正しく認識・引用してもらうための土台としても重要になってきています。
検索エンジンやAI検索エンジンは、ページ上のテキストを人間と同じようには理解できません。「298万円」という文字列を見ても、それが「税込価格」なのか「税抜価格」なのか、機械の側からは判断できないのです。この課題を解決するために、メタデータを付与してコンテンツの意味を機械に伝える「セマンティックWeb」という考え方が生まれ、その実装手段のひとつが構造化マークアップです。
seoマークアップ(通常のマークアップ)との違い
通常のHTMLマークアップとの違いは、テキストに「意味のラベル」を貼るかどうかにあります。通常のマークアップでは、たとえば「AIコマース研究所」という文字列はクローラーにとってただの文字の羅列にすぎません。ここに構造化マークアップを施し、「この文字列は組織名(Organization)である」というラベルを付けることで、検索エンジンはその文字列を正しく「社名」として認識できるようになります。
この「意味のラベル付け」こそが、通常のseoマークアップと構造化マークアップを分ける最大のポイントです。見た目のデザインやレイアウトを整えるための通常のマークアップに対し、構造化マークアップはあくまで「機械への説明書」としての役割を担います。
Google検索の評価とLLMからの引用の両方に効く仕組み
構造化マークアップは、Google検索とAI検索の双方に対して同じ仕組みで効果を発揮します。検索エンジンのクローラーがコンテンツの意味を正確に把握できるようになることで、検索結果でのリッチリザルト表示につながる可能性が高まる一方、AI検索エンジンが情報を要約・引用する際にも、価格・日時・在庫状況といった属性情報を誤りなく参照しやすくなる傾向があります。
AIコマース研究所では、生成AIがWebページの情報を引用・要約する際、構造化データとして明示された属性(価格・評価・更新日など)を本文中の平文よりも高い確度で参照すると分析しています。
ただし、構造化データ自体が検索順位やAI検索での引用可否を直接決定するランキング要因ではない点には注意が必要です。あくまで「機械が誤解なく情報を理解できる状態を作る」ための土台であり、コンテンツの質そのものが伴っていることが前提になります。


構造化データマークアップの主な種類(JSON-LD・Microdata・RDFa)とLLMO対策での推奨形式
構造化データマークアップには、記述する「ボキャブラリー」と、それをHTMLに書き込む「シンタックス」という2つの要素があります。ボキャブラリーの代表格はGoogle・Microsoft・Yahoo!が共同で策定した「schema.org」で、シンタックス(記述形式)としてはJSON-LD・Microdata・RDFaの3種類がGoogleにサポートされています。
| シンタックス | 記述場所 | 主な特徴 |
|---|---|---|
| JSON-LD | HTML内どこでも可 | Google推奨。既存ページへの後付け実装がしやすい |
| Microdata | HTML該当箇所付近 | HTML構造と一致しやすいが、コードが煩雑になりやすい |
| RDFa | HTML該当箇所付近 | XML等の幅広い言語に対応するが管理コストが高い |
なぜLLMO対策の観点でもJSON-LDが推奨されるのか
現在、新規で構造化マークアップを導入する場合はJSON-LDを選ぶのが基本方針です。MicrodataやRDFaはHTMLの該当箇所に直接タグを埋め込む必要があり、既存サイトへの後付けには手間がかかります。一方JSON-LDは、<script>タグとしてページ内のどこにでも配置できるため、既存のCMSやテンプレートを大きく改修せずに導入しやすいという利点があります。
LLMO対策の観点でも、この「実装のしやすさ」は重要です。AI検索エンジンへの露出を狙う場合、記事の追加・更新に合わせて構造化データも継続的にメンテナンスする必要がありますが、JSON-LDであればHTML本文の構造に手を加えずに更新できるため、運用コストを抑えながら情報の鮮度を保ちやすくなります。
構造化マークアップの書き方|LLMOで成果を出すにはコードを書く前の整理が重要
構造化マークアップの書き方というと、多くの方がJSON-LDのコードを書く作業そのものを思い浮かべます。しかし、AIコマース研究所が支援現場で繰り返し見てきたのは、コードを書く前の「情報整理」の段階でつまずいているケースの多さです。
たとえば、中古車販売サイトに次のようなページがあったとします。
- 「298万円」
- 「2024年式」
- 「走行距離1.8万km」
- 「在庫あり」
このとき、構造化マークアップを行う前に、以下のような点を整理しておく必要があります。
- 価格は税込表示なのか、税抜表示なのか
- 「年式」は初度登録年なのか、製造年なのか
- 走行距離の単位はサイト内で統一されているか(km表記の揺れはないか)
- 「在庫あり」という情報はリアルタイムで更新される仕組みになっているか
情報が曖昧なままだとAI検索にも誤った情報が伝わるリスクがある
この整理を飛ばしたまま構造化マークアップを行うと、曖昧な情報をそのまま機械に伝えるだけの作業になってしまいます。たとえば税込・税抜が明確でない価格情報をpriceプロパティとしてマークアップしてしまうと、検索結果やAI検索の回答上で実際の価格と異なる金額が表示・引用されるリスクが生まれます。
これはGoogle検索のリッチリザルト表示においても、AI検索エンジンによる要約・引用においても同様に起こり得る問題です。生成AIは構造化データとして明示された値を比較的高い確度で参照する傾向があるからこそ、その値自体が不正確であれば、誤った情報がそのまま拡散されるリスクがむしろ高まるとも言えます。
LLMOを意識した実装前チェックポイント
コードを書く前に、次のような観点を確認しておくことをおすすめします。
- 表記の統一:価格・日時・単位などの表記がサイト内・ページ内で統一されているか
- 更新の仕組み:在庫状況や価格など変動する情報が、どのタイミングで・誰が更新するのか運用ルールが決まっているか
- 一次情報の所在:マークアップする値が、どのデータベースやCMSのどの項目に由来するものか追跡できるか
- 表記ゆれの洗い出し:同じ意味を指す言葉が複数の表記で使われていないか(例:「送料無料」と「配送料0円」の混在)
こうした整理は地味な作業に見えますが、AIコマース研究所の支援現場では、構造化マークアップのエラーや、AI検索での引用のされ方に関する相談の多くが、実はこの「書く前の整理不足」に起因しているケースが目立ちます。
書き方を覚える前に、まず「ページ上の情報はすでに整理されているか」を確認することが、LLMO対策としての構造化マークアップを機能させる第一歩です。
【実践】構造化マークアップの書き方(JSON-LDのコード例つき)
情報整理が済んだら、実際にJSON-LDでコードを記述していきます。基本の骨格は「@contextでボキャブラリーを宣言し、@typeでタイプを指定し、プロパティで詳細を記述する」という構成です。
パンくずリスト・FAQ・記事(Article)の記述例
パンくずリストの記述例
<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/seo/"
}
]
}
</script>
FAQの記述例
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "構造化マークアップとは何ですか?",
"acceptedAnswer": {
"@type": "Answer",
"text": "検索エンジンにページの内容を正しく理解させるための記述方法です。"
}
}
]
}
</script>
記事(Article)の記述例
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "構造化マークアップとは?LLMO対策における重要性と書き方",
"datePublished": "2026-08-01",
"author": {
"@type": "Organization",
"name": "AIコマース研究所"
}
}
</script>
いずれの場合も、@typeで指定したタイプごとに必須プロパティ・推奨プロパティが定められています。必須プロパティが欠けていると構造化データとして認識されないため、まずは各タイプの必須項目から漏れなく記述することが基本です。
WordPressで構造化マークアップを設定する方法
WordPressでサイトを運用している場合、コードを直接書かなくても、プラグインを使って構造化マークアップを設定する方法があります。代表的なものとして「Schema & Structured Data for WP & AMP」のようなプラグインがあり、管理画面上の入力項目を埋めるだけでJSON-LDが自動生成される仕組みになっています。
コードの知識に不安がある実装担当者の方は、まずプラグインで基本的な構造化マークアップを設定し、必要に応じて出力されたコードを確認・調整していくアプローチがおすすめです。
構造化マークアップテストのやり方|LLMO対策として見るべき検証ポイント
構造化マークアップは実装して終わりではなく、正しく認識されているかを検証する工程が欠かせません。検証には主に「リッチリザルトテスト」「Google Search Console」「Schema Markup Validator(旧・構造化データテストツール)」の3つのツールを使い分けます。
リッチリザルトテストでの確認手順
リッチリザルトテストはGoogleが提供する検証ツールで、対象ページのURLまたはコードを入力するだけで、リッチリザルトの表示対象になっているかを確認できます。
- リッチリザルトテストにアクセスする
- 検証したいURL、またはコードを直接貼り付ける
- 「テストを実行」をクリックする
正しく認識されていれば「このページはリッチリザルトの対象です」と表示されます。認識されていない場合はエラー内容が表示されるため、指摘箇所を修正します。
コードを直接貼り付けて検証できるため、公開前の最終チェックや、修正しながらのデバッグ作業にも活用しやすいツールです。
Search Consoleでのエラー確認方法
リッチリザルトテストが1URLずつの検証であるのに対し、Google Search Consoleでは、サイト全体の構造化データを一覧でモニタリングできます。「検索での見え方」から構造化データの項目を確認することで、どのページでどのようなエラーが出ているかをまとめて把握できます。
サイト全体で構造化マークアップを運用している場合は、新しいページを追加・更新したタイミングでSearch Consoleを確認する習慣をつけておくと、エラーの早期発見につながります。なお、旧・構造化データテストツールは後継としてschema.org運営による「Schema Markup Validator」に統合されており、シンタックスの構文チェックに特化した検証を行いたい場合はこちらも活用できます。
構造化マークアップとLLMO対策でよくあるミスと注意点
構造化マークアップの実装・検証において、支援現場で頻出するミスには一定の傾向があります。
- 必須プロパティの記載漏れ:タイプごとに定められた必須プロパティが欠けており、構造化データとして認識されない
- 表示内容と構造化データの不一致:ページ上の表示価格と、構造化データ内の
priceの値が一致していない - 更新の反映漏れ:在庫状況やイベント日時など変動する情報が、ページ更新時に構造化データ側へ反映されていない
- 推奨プロパティの記載不足:必須プロパティのみで済ませており、Googleがページ内容をより深く理解するための推奨プロパティが埋められていない
これらのミスは、Google検索でのリッチリザルト非表示だけでなく、AI検索エンジンが情報を要約・引用する際の精度にも影響し得ると考えられます。特に価格や日時など変動する属性については、運用フローの中に構造化データの更新チェックを組み込んでおくことが重要です。
AI検索に引用されるサイトと引用されないサイトの構造化マークアップの違い
AIコマース研究所では、支援先サイトのLLMO診断を通じて、AI検索エンジンからの引用が得やすいサイトと得にくいサイトの構造化データの実装状況を比較分析しています。診断現場で見えてきた傾向として、引用されやすいサイトほど、構造化データ内の値と本文中の記載内容に矛盾がなく、かつ価格・更新日といった変動情報の反映が仕組み化されているという共通点が見られます。
一方で、引用されにくい傾向があるサイトでは、構造化マークアップ自体は実装されているものの、必須プロパティのみの最小限の記述にとどまっていたり、ページ更新時に構造化データが古いまま放置されていたりするケースが目立ちます。構造化マークアップは「一度実装すれば終わり」ではなく、コンテンツの追加・更新に合わせて継続的にメンテナンスすることで、はじめてLLMO対策としての効果を発揮しやすくなると考えています。
こうした運用面の課題は、社内のリソースだけで気づくのが難しい部分でもあります。実装担当者が自力でチェックできる範囲には限界があるため、定期的に第三者の視点で構造化データの実装状況を棚卸しする機会を設けることも、有効な選択肢のひとつです。
LLMO対策として構造化マークアップ支援ツールを選ぶ際のチェックリスト
構造化マークアップの実装・検証を効率化するツールを選ぶ際は、次の観点をチェックしておくと判断がしやすくなります。
- 対応シンタックス:JSON-LD形式での出力に対応しているか(Microdata形式のみの出力は後で変換の手間がかかる)
- 検証機能の有無:マークアップ後にエラーチェックまで一気通貫でできるか
- 更新のしやすさ:CMSと連携し、コンテンツ更新に合わせて構造化データも自動更新されるか
- 対応スキーマの幅:自社が必要とするタイプ(記事・FAQ・商品・パンくず等)を網羅しているか
これらの観点で自社サイトの現状を棚卸しすると、どこから着手すべきかが見えてきます。AIコマース研究所でも、こうした構造化マークアップの実装状況の棚卸しから、AI検索での引用状況の分析までを含めたLLMO無料診断を提供しています。自社での判断に迷う場合は、専門的な視点でのチェックを活用するのも一つの方法です。
構造化マークアップに関するよくある質問
- 構造化マークアップはWordPressでどう設定すればいいですか?
-
WordPressではプラグインを使うとコードを書かずに設定できます。「Schema & Structured Data for WP & AMP」などのプラグインを使えば、管理画面の入力項目を埋めるだけでJSON-LDが自動生成される仕組みが一般的です。コードの知識に不安がある場合は、まずプラグインから試すのがおすすめです。
- パンくずリストの構造化マークアップにはどんな効果がありますか?
-
検索結果にサイト階層を示すパンくずリストが表示されやすくなる効果があります。ユーザーがページの位置づけを把握しやすくなり、サイト構造が明確なコーポレートサイトやメディアサイトでは特に設定が推奨されます。BreadcrumbListというタイプで記述します。
- FAQの構造化マークアップはどう書けばいいですか?
-
FAQPageというタイプを使い、質問と回答のペアをmainEntity内に列挙する形式で記述します。1つのページに複数のQ&Aがある場合、それぞれをQuestionとAcceptedAnswerのセットとして書くのが基本です。記事末尾のFAQセクションとの相性が良い形式です。
- 構造化マークアップのチェックツールにはどんな種類がありますか?
-
主にリッチリザルトテスト、Google Search Console、Schema Markup Validatorの3種類を使い分けます。リッチリザルトテストは1URLずつの表示可否確認、Search Consoleはサイト全体のエラー一覧確認、Schema Markup Validatorは構文自体のチェックに向いています(2026年時点)。
- 構造化マークアップはAIで自動生成できますか?
-
一部はAIツールやプラグインによる自動生成が可能ですが、実装前の情報整理まではAIに任せきりにできない部分です。価格の税込・税抜表記や単位の統一など、自社データの正確性を確認する工程は人による確認が欠かせないと、診断現場では見られる傾向があります。
- Googleの構造化データマークアップ支援ツールは今も使えますか?
-
Google公式の構造化データマークアップ支援ツールは提供されていますが、生成されるコードがMicrodata形式である点に注意が必要です。現在はJSON-LDが推奨されているため、生成後にJSON-LD形式へ変換して利用することをおすすめします。
- 構造化マークアップは検索順位に直接影響しますか?
-
構造化データ自体は検索順位を決定するランキング要因には含まれていません。ただし、リッチリザルト表示によるクリック率の向上や、AI検索での情報認識の精度向上にはつながる可能性があると考えられています。
- 構造化マークアップの設定を依頼する場合、費用相場はどれくらいですか?
-
依頼範囲やページ数によって費用は大きく変動するため、一概な相場を示すことは難しいのが実情です。ページ単価での見積もりか、サイト全体の一括対応かで金額は変わるため、複数社に自社サイトの現状を伝えた上で見積もりを取ることをおすすめします。
- LLMOとSEOの構造化マークアップへの取り組み方に違いはありますか?
-
LLMOとは生成AI検索での引用・推奨を狙う対策のことで、基本的な構造化マークアップの書き方自体はSEOと共通しています。異なるのは、価格や更新日などの属性情報の正確性と鮮度をより重視する点で、AI検索エンジンが情報を要約・引用する際の参照精度に影響し得ると考えられています。
- 構造化データがエラーになる主な原因は何ですか?
-
各タイプに定められた必須プロパティの記載漏れが、エラーの主な原因です。加えて、ページ上の表示内容と構造化データ内の値が一致していないケースや、情報更新時に構造化データ側の反映が漏れているケースも頻出します。
構造化マークアップはLLMO対策の土台。書く前の整理から始めよう
構造化マークアップは、Google検索でのリッチリザルト表示だけでなく、ChatGPTやGoogle AI Overviewsといった生成AI検索からの引用にもつながり得る、LLMO対策の土台となる施策です。JSON-LDでのコードの書き方を押さえることはもちろん重要ですが、それ以上に、マークアップする情報そのものが整理されているかどうかが、実装の質を大きく左右します。
まずは自社サイトの主要ページで、価格・日時・在庫といった変動情報の表記が統一されているかを確認するところから始めてみてください。実装後は、リッチリザルトテストやSearch Consoleでの検証を運用フローに組み込み、継続的にメンテナンスしていくことが、LLMO対策として構造化マークアップを機能させる鍵になります。