AI・マーケトレンド
Writer /
この記事の著者
「構造化データを入れたほうがいいと聞いたが、エンジニアではないので手が出ない」。BtoBサイトの担当者からよく聞く悩みです。専門用語だらけの解説を読んで閉じてしまった、という方も多いのではないでしょうか。
この記事では、構造化データ（JSON-LD）の役割を最短で理解し、BtoBサイトが優先して入れるべき5つのスキーマを、コピペで使えるテンプレート付きで解説します。2026年5月のFAQリッチリザルト終了や、AI検索と構造化データの関係についてのGoogleの公式見解も踏まえて、非エンジニアでも実装まで到達できる内容にしました。
30秒で分かる結論
構造化データとは、ページの内容を検索エンジンとAIに「誤解なく」伝えるためのラベル。JSON-LD形式で書くのが標準
BtoBサイトの優先順位は Organization → FAQPage → Article → BreadcrumbList → Product／Service の順（FAQPageはリッチリザルト終了後、優先度を下げてもよい）
リッチリザルトの対象になり、ページの意図を検索エンジンに正確に伝えられる。ただしGoogleは「生成AI検索に構造化データは必要ない」と明言している
実装はHTMLのhead内かbody閉じタグ直前にscriptタグを貼るだけ。CMSでも入れられる
書いたら必ずGoogleの「リッチリザルトテスト」で検証する。書きっぱなしが一番多い失敗
構造化データとは？AI検索時代の正しい位置づけ
構造化データとは、「このページは会社概要です」「この数字は料金です」「この文章は質問と回答です」といったページの意味を、機械が読める形式で記述したものです。Googleが推奨する書き方がJSON-LD（JavaScript Object Notation for Linked Data）で、HTMLにscriptタグとして埋め込みます。
従来、構造化データの目的は主にリッチリザルトでした。検索結果にFAQが展開表示されたり、パンくずリストや評価の星が出たりする、あの表示です。クリック率の改善には効きますが、「余裕があればやる施策」という位置づけの会社が多かったのが実情です。
2026年のいま、位置づけが変わりました。ChatGPT、Gemini、PerplexityといったAI検索、そしてGoogleのAI Overviewが、回答を組み立てる際にWebページを読みに来ます。ただしGoogleは、生成AI検索に構造化データは必要なく、追加すべき特別なschema.orgマークアップもないと公式に説明しています（詳しくは後の節で紹介します）。構造化データは、AIに引用されるための近道ではなく、ページの内容を検索エンジンに誤解なく伝えるための基本整備と位置づけるのが正確です。
言い換えると、構造化データは「検索結果の見た目の施策」だけでなく、「ページの意図を正確に伝えるための基本整備」として捉え直す必要があります。LLMO対策の基本のなかでも、自社でコントロールできる数少ない技術施策です。AI向けのサイト情報整備という意味では、llms.txtの書き方と並ぶ二本柱だと考えてください。
Googleの公式見解で確認する2026年の2つの変化
構造化データの解説記事には、数年前の前提のまま書かれているものが少なくありません。実装の優先順位を決める前に、Google検索セントラルの公式ドキュメントで確認できる2つの変化を押さえておきます（2026年10月時点で編集部が確認した内容です）。
変化1：FAQのリッチリザルトは2026年5月に表示終了
Googleは2023年8月、FAQのリッチリザルトを「よく知られた信頼できる政府・保健関連のウェブサイト」に限って表示する方針を発表しました（Google検索セントラルブログ：Changes to HowTo and FAQ rich results）。さらに検索セントラルの更新履歴によると、FAQのリッチリザルトは2026年5月7日以降Google検索に表示されなくなり、同年6月には機能のドキュメント自体が削除されました（Google検索セントラル：ドキュメントの最新の更新内容）。
つまり現在は、政府・医療サイトを含めて、FAQPageを入れても検索結果にFAQが展開表示されることはありません。本記事で紹介しているFAQPageは、検索結果の見た目を変える目的ではなく、ページ内の質問と回答の対応関係を機械可読にしておく目的で使うもの、と読み替えてください。2023年の発表時点でGoogleは、使われなくなった構造化データは検索に問題を起こさないため、積極的に削除する必要はないと説明しています。
変化2：Googleは「生成AI検索に構造化データは必要ない」と明言
GoogleのAI最適化ガイドには、次の記述があります。
生成 AI 検索に構造化データは必要ありません。追加する必要がある特別な schema.org マークアップもありません。ただし、Google 検索のリッチリザルトの対象となる助けとなるため、SEO 戦略全体の一部として引き続き使用することをおすすめします。
AI機能とウェブサイトに関するドキュメントでも、AIによる概要やAIモードに表示されるための追加の要件はなく、特別なschema.orgの構造化データを追加する必要もないとされています。少なくともGoogleのAI機能については、「構造化データを入れればAIに引用される」という関係を公式は認めていません。ChatGPTやPerplexityなど他社のAIが構造化データをどう扱うかについては、編集部は各社の公式ドキュメントで明示的な説明を確認できていません。
それでも構造化データを入れる理由
公式ドキュメントの範囲で言える価値は次の3つです。
リッチリザルトの対象になる：記事、パンくずリスト、組織、商品、ソフトウェアアプリなどは、Googleがサポートする機能として構造化データの機能一覧に掲載されています
ページの意図が正確に伝わる：Googleは構造化データの概要で「構造化データを使用してページの意図を伝えると、Google はそのページをより正確に理解できるようになります」と説明しています
会社を正しく識別してもらう：ホームページの組織（Organization）の構造化データは、Googleが組織の詳細を把握し、検索結果で組織を明確化するために使われます
AI検索での見え方を確かめたい場合は、構造化データの有無から推測するのではなく、実際の表示を測ってください。Google検索の生成AI機能については、Search Consoleの生成AIパフォーマンスレポートで確認できるとAI最適化ガイドに記載があります。AIによる概要に引用される記事の条件はGoogleのAI Overview対策｜引用される記事の条件で詳しく解説しています。
BtoBサイトが優先すべき構造化データ5種類
スキーマ（構造化データの型）は数百種類ありますが、全部入れる必要はありません。BtoBの企業サイトなら次の5つで十分です。
優先度1：Organization（トップページ）—会社情報をAI・Googleに正しく認識させる
優先度2：FAQPage（FAQ・よくある質問ページ）—質問と回答の対応を機械可読にする（FAQリッチリザルトは2026年5月に表示終了）
優先度3：Article（ブログ・オウンドメディア記事）—著者・更新日を明示しE-E-A-Tを補強
優先度4：BreadcrumbList（全下層ページ）—サイト構造の理解を助ける
優先度5：Product／Service（サービス・料金ページ）—サービス内容と価格の認識精度を上げる
1. Organization：会社の「名刺」を機械可読にする
最優先はOrganizationです。会社名・URL・ロゴ・所在地・SNSアカウントを宣言します。AIが「この会社は何者か」を判断する起点になるため、ここが空だと他の施策の効きも悪くなります。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "株式会社スリスタ",
"url": "https://example.com/",
"logo": "https://example.com/logo.png",
"description": "BtoB向けAIマーケティングツールを提供する会社",
"address": {
"@type": "PostalAddress",
"addressCountry": "JP",
"addressLocality": "東京都"
},
"sameAs": [
"https://x.com/アカウント名",
"https://www.youtube.com/@チャンネル名"
]
}
</script>ポイントはsameAsです。X（Twitter）やYouTube、Wikipediaなど「同一主体である」公式アカウントを列挙すると、AIとナレッジグラフが会社情報を突合しやすくなります。
2. FAQPage：質問と回答の対応を伝える形式
FAQPageは質問と回答のペアを宣言するスキーマです。AI検索の回答は「質問に答える」形式なので、最初から質問回答形式で構造化されたコンテンツはAIにとって扱いやすい素材です。
ここで正確に押さえておきたい変化があります。GoogleはFAQのリッチリザルト（検索結果でのFAQ展開表示）を、2023年に政府・医療などごく一部のサイトに限定し、2026年5月にはGoogle検索での表示自体を終了しました。つまり現在は、FAQPageを入れても検索結果にFAQが展開表示されることはありません。それでもFAQPageを使う場合の目的は、見た目のリッチリザルトではなく、ページ内の質問と回答の対応関係を機械可読にしておくことです。なおGoogleは、生成AI検索に構造化データは必要ないと説明しており、FAQPageでAIに引用されやすくなるとは公式には示していません。競合の多くが「FAQを入れればリッチリザルトが出る」と古い前提のまま書いているぶん、正確に理解して使うだけで差が付く領域です。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "導入までの期間はどのくらいですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "お申し込みから最短3営業日でご利用開始いただけます。初期設定はオンラインで30分程度です。"
}
},
{
"@type": "Question",
"name": "無料トライアルはありますか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "14日間の無料トライアルをご用意しています。クレジットカードの登録は不要です。"
}
}
]
}
</script>注意点が1つあります。構造化データの回答文（text）と、ページに表示されている回答文は一致させてください。表示内容と異なるデータを入れるとガイドライン違反になります。
3. Article：誰が書いたかを明示してE-E-A-Tを補強する
ブログ記事にはArticle（またはBlogPosting）を入れ、著者・公開日・更新日を宣言します。「誰が書いたか分からない記事」と「専門家が書いたと明示された記事」では、GoogleとAIの扱いが変わります。著者名はauthorプロパティに実名で入れ、可能なら著者プロフィールページのURLも紐づけます。
4と5. BreadcrumbListとService
BreadcrumbList（パンくず）は多くのCMSやテーマが自動出力しています。まず自社サイトのソースを確認し、なければ追加する程度で構いません。Service／Productはサービス紹介ページに入れ、サービス名・提供者・説明を宣言します。BtoB SaaSなら価格帯（offers）まで入れると、AIが料金に言及する際の精度が上がります。
三森の実務メモ：私が構造化データで一番効果を実感したのはFAQPageです。ただし検索結果の見た目が派手になったからではありません。FAQのリッチリザルトが一般サイトで出なくなった今でも、自社メディアでAI経由の流入（ChatGPTやPerplexityの参照元）が付く記事は、ほぼ例外なくFAQセクションと構造化データをセットで入れた記事でした。この相関だけは崩れていません。逆にOrganizationを入れた瞬間に何かが跳ねる、ということはありません。あれは即効薬ではなく「AIに会社を誤認されない保険」だと思って淡々と入れるものです。
JSON-LDの書き方：エラーを出さない文法ルール6つ
JSON-LDはJSONという書式のルールに従って書きます。リッチリザルトテストで出るエラーの多くは、構造化データの知識ではなくJSONの文法ミスが原因です。次の6つを守れば、手書きでもAI生成でも大半のエラーは防げます。
キーと文字列は半角のダブルクォート（"）で囲む。シングルクォートや全角の引用符は使えません
最後の項目の後ろにカンマを付けない。JSONは末尾のカンマを許さないため、項目を削除したときに残りがちです
コメントは書けない。メモを残したい場合は、scriptタグの外にHTMLコメントで書きます
@typeの綴りは大文字小文字まで正確に書く。schema.orgの型名は「BlogPosting」「BreadcrumbList」のように決まった表記です
日時はISO 8601形式で、タイムゾーンも付ける。日本時間なら「2026-10-01T10:30:00+09:00」の形です。Googleの記事の構造化データのドキュメントでも、タイムゾーン情報の提供が推奨されています
URLは「https://」から始まる絶対URLで書く。値の中にダブルクォートを含める場合は「\"」とエスケープします
よくある間違いを1つのコードにまとめると次のようになります（説明のための誤った例です。このままでは動きません）。
{
"@type": "BlogPosting",
"headline": 'タイトル', ← シングルクォートは不可
“author”: "山田 太郎", ← 全角の引用符は不可
"dateModified": "2026/10/01", ← ISO 8601形式ではない
"image": "/images/a.jpg", ← 相対パスより絶対URLで
// 更新日を追記 ← JSONにコメントは書けない
"description": "AIで"時短"する方法", ← 値の中の " は \" にする
} ← 直前の行末のカンマが余分型別JSON-LDテンプレート：Article・BreadcrumbList・Product
前出のOrganizationとFAQPageに続き、残りの優先スキーマのテンプレートです。各テンプレートの会社名・商品名・URL・金額は、編集部が作成した架空の例です。自社の値に置き換え、ページに表示されている内容と必ず一致させてください。必須・推奨プロパティはGoogle検索セントラルの各ドキュメント（2026年9月更新版）で確認した内容です。
Article（BlogPosting）：記事ページ用
Googleの記事の構造化データには必須プロパティがなく、headline、image、datePublished、dateModified、author などの推奨プロパティを、ページに当てはまる範囲で入れます。著者のurlには、プロフィールページやSNSなど著者を一意に識別できるページを指定します。ブログ記事なら@typeはBlogPosting、ニュース記事ならNewsArticleを使います。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "営業資料の作り方｜受注率を上げる構成テンプレート",
"image": [
"https://example.com/images/sales-deck-16x9.jpg"
],
"datePublished": "2026-09-01T09:00:00+09:00",
"dateModified": "2026-10-01T10:30:00+09:00",
"author": [{
"@type": "Person",
"name": "山田 太郎",
"url": "https://example.com/authors/yamada"
}],
"publisher": {
"@type": "Organization",
"name": "株式会社サンプル",
"url": "https://example.com/"
}
}
</script>BreadcrumbList：パンくずリスト用
パンくずリストの構造化データでは、itemListElementの各ListItemに position（1から始まる順番）、name（表示名）、item（URL）が必須です。ただし最後の項目（いま表示しているページ）はitemを省略でき、その場合はGoogleがそのページのURLを使います。ページ上に実際に表示しているパンくずと同じ階層・同じ名前にそろえてください。
<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/blog/"
},{
"@type": "ListItem",
"position": 3,
"name": "営業資料の作り方"
}]
}
</script>Product：料金を掲載している商品・サービスページ用
商品スニペットの構造化データは name が必須で、加えて review、aggregateRating、offers のいずれか1つが必要です。offersだけを指定した場合、リッチリザルトテストで商品スニペットに関する警告が出ることも公式に明記されています。警告を消すために、実在しない評価やレビューを追加しないでください。レビューのガイドラインでは、組織が自社サイト上で自社のレビューを管理している場合、OrganizationやLocalBusinessの構造化データを使うページはスターレビューの対象外になるとされています（クチコミ抜粋のガイドライン）。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "サンプル勤怠クラウド スタンダードプラン",
"description": "従業員50名までの企業向けの勤怠管理サービス",
"image": "https://example.com/images/standard-plan.png",
"brand": {
"@type": "Brand",
"name": "サンプル勤怠クラウド"
},
"offers": {
"@type": "Offer",
"price": 9800,
"priceCurrency": "JPY",
"availability": "https://schema.org/InStock",
"url": "https://example.com/pricing"
}
}
</script>SaaSのようなソフトウェアの場合は、ソフトウェアアプリの構造化データ（SoftwareApplication）も候補になります。ただしこちらは name、offers.price に加えて、aggregateRating か review のいずれかが必須です。実際のユーザー評価を集めていない段階では、リッチリザルトの要件を満たせない点に注意してください。また、既存の節で触れたServiceはschema.orgの型としては使えますが、Googleの構造化データの機能一覧には含まれていないため、リッチリザルトの対象にはなりません。
@graphと@idで1ページの構造化データをまとめる
記事ページには、Organization・BlogPosting・BreadcrumbListのように複数の型が載ります。scriptタグを型ごとに分けても構いませんが、@graphで1つにまとめ、@idで相互に参照させると、どの記事がどの会社のものかを1か所で表現できます。下の例では、BlogPostingのpublisherが「https://example.com/#organization」というIDでOrganizationを参照しています。@idには、同じ主体を指すなら全ページで同じ値を使ってください。会社と代表者を@idで結ぶテンプレートはエンティティSEOとは？ナレッジグラフに載る会社情報の整え方で紹介しています。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "株式会社サンプル",
"url": "https://example.com/",
"logo": "https://example.com/logo.png"
},
{
"@type": "BlogPosting",
"@id": "https://example.com/blog/sales-deck/#article",
"headline": "営業資料の作り方｜受注率を上げる構成テンプレート",
"datePublished": "2026-09-01T09:00:00+09:00",
"dateModified": "2026-10-01T10:30:00+09:00",
"author": {
"@type": "Person",
"name": "山田 太郎",
"url": "https://example.com/authors/yamada"
},
"publisher": { "@id": "https://example.com/#organization" }
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://example.com/" },
{ "@type": "ListItem", "position": 2, "name": "ブログ", "item": "https://example.com/blog/" },
{ "@type": "ListItem", "position": 3, "name": "営業資料の作り方" }
]
}
]
}
</script>構造化データの入れ方3パターン
実装方法はサイト環境で決まります。
CMSプラグイン（WordPress等）：Yoast SEOやRank Mathなどが主要スキーマを自動出力します。まず既に出力されていないか確認してから手動追加を検討してください。二重出力は混乱のもとです
HTML直接編集：head内かbody閉じタグ直前にscriptブロックを貼ります。静的サイトやノーコードツール（カスタムコード欄があるもの）はこの方式です
タグマネージャー（GTM）：HTMLを触れない場合の代替手段です。カスタムHTMLタグで注入できますが、レンダリング後の挿入になるため、可能ならHTML直接編集を優先してください
どの方式でも、実装後は必ずGoogleの「リッチリザルトテスト」（search.google.com/test/rich-results）にURLを入れて検証します。エラーが出たら、ほとんどはカンマの欠落・全角文字の混入・URLの間違いです。
実装から監視までの検証手順5ステップ
Googleは各構造化データのドキュメントで、作成・テスト・リリースの流れを示しています。これを非エンジニアでも実行できる順番に並べると、次の5ステップになります。
ステップ1：公開前に「コード」でリッチリザルトテストにかける
リッチリザルトテストは、URLだけでなくコードを貼り付けてもテストできます。本番に反映する前に、作成したscriptブロックを含むHTMLを「コード」タブに貼って確認すれば、公開後に慌てて直す必要がなくなります。
ステップ2：「重大な問題」は必ず直し、「重大ではない問題」は可能な範囲で直す
Googleは、ツールが報告する重大なエラーを修正し、重大ではない問題も修正を検討するよう案内しています。重大ではない問題は、リッチリザルトの対象になるために必ずしも修正が必要なわけではありませんが、構造化データの品質向上に役立つとされています。
ステップ3：Googleの対象外の型はSchema Markup Validatorで確認する
リッチリザルトテストが判定するのは、Googleのリッチリザルトに対応した型です。Serviceなど対象外の型や、schema.orgの文法として正しいかを確かめたい場合は、Schema Markup Validatorにコードを貼って確認します。
ステップ4：公開後にURL検査ツールでGoogleから見えるか確認する
公開したら、まず数ページだけでSearch ConsoleのURL検査ツールを使い、Googleがページにアクセスできるか、robots.txt、noindexタグ、ログイン要件でブロックされていないかを確認します。問題がなければ再クロールをリクエストできます。Googleによると、公開後にページが検出・クロールされるまで数日かかる場合があります。
ステップ5：テンプレートやコードを変えたらSearch Consoleで再確認する
Googleは、構造化データを初めてデプロイした後に加えて、新しいテンプレートをリリースした後やコードを更新した後にもSearch Consoleを確認するよう推奨しています。サイトのデザイン変更やCMSのテーマ更新で構造化データが消える・二重になる事故は珍しくないため、リニューアルの検収項目に「リッチリザルトのレポート確認」を入れておくと安全です。
あわせて、構造化データに関する一般的なガイドラインにあるとおり、正しくマークアップしてもリッチリザルトが表示されるとは限りません。テストで有効と判定されたのに表示されない場合は、ページの主要な内容を表しているか、ユーザーに表示されていない内容をマークアップしていないかを見直してください。
AIに構造化データを書かせる手順（プロンプト例つき）
JSON-LDを手書きする必要はありません。2026年のいま、実務ではAIに書かせて人が検証するのが最速です。
あなたは構造化データ（schema.org / JSON-LD）の専門家です。
以下のページ情報から、Googleのガイドラインに準拠したJSON-LDを作成してください。
・スキーマタイプ：FAQPage
・出力は<script type="application/ld+json">ブロック1個のみ
・ページに存在しない情報を推測で補わない（不明な項目は省略する）
・回答文はページの表示テキストと一字一句同じにする
【ページURL】
（URLを貼る）
【ページに表示されているFAQの全文】
（質問と回答をそのまま貼り付け）重要なのは「推測で補わない」という制約行です。AIは空欄を嫌って、ページにない住所や評価点数を作り出すことがあります。存在しない評価（AggregateRating）を入れると手動対策（ペナルティ）の対象になり得るため、出力されたJSON-LDは必ずページの実物と突き合わせてください。
生成したら、リッチリザルトテストに貼って検証→問題なければ本番に反映、という流れです。1ページ10分もかかりません。
三森の実務メモ：AIにJSON-LDを書かせると、9割は一発で通りますが、残り1割で「ページにない情報」をもっともらしく入れてきます。私が実際に見たのは、FAQの回答文を勝手に要約して短くするパターンです。一見親切ですが、表示テキストと構造化データの不一致はガイドライン違反です。プロンプトに「一字一句同じ」と書いてもズレることがあるので、私は生成後にdiffツールで表示文と比較しています。この一手間だけで事故はゼロにできます。
効果測定：構造化データは「入れて終わり」が9割
構造化データは入れた後の観測までがセットです。見る場所は3つあります。
Google Search Console：「拡張」レポートでスキーマの認識状況とエラーを確認。実装の翌週には反映されます
検索結果の実物：狙ったページを実際に検索し、パンくず表示などが出ているか目視確認
AI検索での引用：自社名やサービス名をChatGPT・Perplexityで聞き、自社ページが引用元に出るかを確認
3つ目のAI引用の定点観測は手動では続きません。GA4でのAI経由流入の計測と併せて、ツールで自動化するのが現実的です。ドヤAIのドヤAIOを使うと、ChatGPT・Gemini・Claude・Perplexityの4エンジンで自社がどう言及・引用されているかを定点観測できるため、構造化データやLLMO施策の前後比較ができます。
おすすめの無料ドヤAIサービス！
ドヤ記事作成
SEO・LLMOを意識した構成作成から長文記事の執筆、整合性チェックまでを効率化します。
ドヤAIO
ChatGPTなどのAI回答上でのブランド言及や競合比較を可視化し、AIに選ばれるための改善を支援します。
よくある質問（FAQ）
Q. 構造化データを入れると順位は上がりますか？
構造化データ自体は直接のランキング要因ではない、というのがGoogleの公式見解です。ただしリッチリザルトによるクリック率改善、ページ内容の正確な理解、E-E-A-Tシグナルの補強という間接効果があります。なお、Googleは生成AI検索に構造化データは必要ないと明言しています。順位を上げる魔法ではなく、コンテンツの価値を機械に正しく伝える配線工事だと考えてください。
Q. 非エンジニアでも本当に実装できますか？
できます。この記事のテンプレートをAIに渡して自社情報で書き換えさせ、リッチリザルトテストで検証すれば、HTMLに貼る作業だけです。WordPressならプラグインの設定画面で完結する場合も多いです。唯一エンジニアに頼むべきなのは、サイト全体のテンプレートに組み込んで自動出力させたい場合です。
Q. どのページから入れるべきですか？
トップページのOrganizationが最初です。次に、検索流入が多い記事上位10本にArticleとFAQPageを入れてください。全ページ一括対応は労力の割に効果が薄いので、流入と商談貢献が大きいページから順に広げるのが実務的です。
Q. 構造化データのエラーは放置するとまずいですか？
「エラー」はリッチリザルト表示の対象外になるため直すべきですが、ペナルティになるわけではありません。危険なのはエラーではなく「虚偽」です。ページに存在しないレビュー評価や、表示内容と異なるFAQを入れると手動対策の対象になります。エラーは減点、虚偽は退場と覚えてください。
Q. 入れてあるFAQPageの構造化データは削除したほうがいいですか？
削除しなくても問題はありません。FAQのリッチリザルトは2026年5月7日以降Google検索に表示されなくなりましたが、2023年に表示を制限した際、Googleは使われなくなった構造化データは検索に問題を起こさず、積極的に削除する必要はないと説明しています。ただし回答文を更新したときに構造化データだけ古いまま残ると、表示内容との不一致になります。更新の手間をかけられないページでは、削除してしまうのも一つの判断です。
Q. 1ページに複数のJSON-LDを書いても大丈夫ですか？
書けます。型ごとにscriptタグを分ける方法と、@graphで1つにまとめる方法のどちらでも構いません。注意したいのは、CMSのプラグインと手書きで同じ型が二重に出力されるケースです。リッチリザルトテストで、意図した型が意図した数だけ検出されているかを確認してください。
Q. 構造化データを入れればAIに引用されやすくなりますか？
Googleについては、AI最適化ガイドで「生成 AI 検索に構造化データは必要ありません」と明言されており、構造化データがAIによる概要やAIモードへの掲載条件になるわけではありません。ChatGPTやPerplexityなど他社のAIの扱いは、公式の明示的な説明を編集部は確認できていません。構造化データはページ内容を正確に伝える土台として整え、AIでの見え方は実際の回答や引用元を観測して判断するのが確実です。
まとめ：構造化データは「AIへの自己紹介文」
構造化データは、検索エンジンとAIに向けた機械可読の自己紹介文です。Organizationで会社を名乗り、FAQPageで質問に答え、Articleで書き手を示す。この3つだけでも、AIがあなたの会社を誤解するリスクは大きく減ります。実装はAIに書かせて人が検証すれば、1ページ10分です。
入れた後は、AIが実際に自社をどう紹介しているかの観測まで仕組み化しましょう。ドヤAIOなら、4つのAIエンジンでの自社言及率・引用元を自動で定点観測できます。構造化データの効果をAI検索側から確かめたい方は、無料でお試しください。編集部の補足調査データ（2026年最新・n=400）
構造化データの重要性が2026年に増したのは、ユーザーがGoogleだけでなく生成AIでも情報を探すようになったからです。株式会社スリスタが全国の会社員400名に実施した『企業の生成AI活用実態調査2026』では、業務での生成AIツール利用率はChatGPT 60.8％・Google Gemini 49.7％・Microsoft Copilot 41.8％・Claude 7.8％で、AI利用者の49.0％が複数ツールを併用（平均1.82ツール）。複数のAIがページを解釈する今、JSON-LDで「何のページか」を明示しておくことが引用されやすさにつながります。
出典：株式会社スリスタ『企業の生成AI活用実態調査2026』（n=400）。全クロス集計は職場の生成AIツールシェア実態2026、プレスリリースはPR TIMESで公開中。
▶ 動画で学ぶ：ドヤマーケAIチャンネル（マーケティング×AIの実践）