構造化データの実装に生成AIを活かす方法｜検索結果で目立たせる

「競合のページだけ、検索結果に質問と答えが並んで表示されている」「同じような内容を書いているのに、こちらは一行しか出ない」——検索結果を見比べた担当者が最初に気づく差です。この差は、記事の質だけで決まっているわけではありません。ページの中身が何であるかを、機械に読める形で書き添えているかどうかで分かれます。この記事では、その印の付け方を生成AIとあわせて整理します。

構造化データ（schema）とは

構造化データとは、ページの内容が何であるかを、検索エンジンが理解できる形式で明示する仕組みです。schema.orgという共通の語彙に沿って、「これは記事」「これは会社情報」「これはよくある質問」といった意味を、コードでタグづけします。人が読む本文とは別に、機械向けの説明を添えるイメージです。

これを実装すると、検索結果にリッチリザルト（リッチな表示）が出る可能性が高まります。よくある質問のアコーディオン表示、パンくずリスト、記事の公開日や著者情報などが、検索結果上で目立つ形で表示されます。クリック率の向上につながるうえ、検索エンジンがページを正確に理解する助けにもなります。

なぜ2026年に構造化データが重要なのか

構造化データの重要性は、リッチリザルトが登場した当初より、2026年の今のほうが高まっています。理由は、AIによる要約や生成AIの回答が、構造化データを手がかりにページの内容や実体を理解しているためです。GeminiやChatGPT、Perplexity、Claudeといった生成AIが答えを組み立てる際、構造化された情報は信頼できる根拠として扱われやすくなります。

つまり構造化データは、従来のリッチ表示のためだけでなく、AI検索に引用・認識されるための基盤としても機能します。ページが何について書かれ、どの企業のもので、どんな質問に答えているかを機械可読な形で示すことは、検索とAIの両方の入口で有利に働きます。手間はかかりますが、その手間をAIが肩代わりできるようになったことで、取り組む価値が明確に高まっています。

JSON-LDという形式

構造化データの記述方法にはいくつか種類がありますが、2026年時点でGoogleが推奨し、主流となっているのがJSON-LDです。JSON-LDは、本文のHTMLとは分離した形で、scriptタグの中にまとめて記述します。本文の構造をいじらずに追加・修正・削除ができるため、実装も保守も容易です。

生成AIがコードを出力する際も、JSON-LDが標準として使われます。本文の各要素に直接タグを埋め込む方式と違い、1か所にまとめて記述できるため、AIに作らせたコードをそのまま貼り付けやすいのも利点です。これから実装するなら、迷わずJSON-LD形式を選べば問題ありません。まずはこの形式で1つ作ってみることが理解の近道です。

効果が出やすいスキーマの種類

schema.orgには数百の種類がありますが、実務で効果が出やすいものは限られます。まず押さえるべきは、Article・FAQPage・Organization・Product・BreadcrumbListあたりです。自社サイトの性質に合わせて、必要なものから実装します。主なスキーマの用途を次の表にまとめます。

スキーマ	用途	向いているページ
Article/BlogPosting	記事情報を伝える	ブログ・メディア記事
FAQPage	質問と答えを伝える	よくある質問を含むページ
Organization	会社の実体を伝える	トップ・会社情報ページ
Product	商品情報を伝える	製品・料金ページ
BreadcrumbList	階層を伝える	パンくずのある全ページ

BtoBのメディアサイトなら、まずは記事にArticleとBreadcrumbList、Organizationを実装し、よくある質問を載せる記事にはFAQPageを加えるのが定石です。すべてを一度に入れる必要はなく、自社にとって効果が見込めるものから段階的に進めれば十分です。欲張らず、優先度の高いものから確実に実装しましょう。

AIでJSON-LDを生成する基本手順

生成AIを使えば、構造化データの作成はぐっと手軽になります。専門知識がなくても、ページの情報をAIに渡し、必要なスキーマを指定するだけで、JSON-LDのコードが得られます。基本の流れは次のとおりです。この手順に沿えば、初めてでも実装まで到達できます。

この手順の肝は、AIに渡す情報の正確さです。AIは渡された情報をコードの形に整えるのは得意ですが、事実そのものを知っているわけではありません。公開日や著者、会社名などは、正しい情報を人が用意して渡すことが、正確な構造化データの前提になります。

ChatGPT・Claude・Geminiの使い分け

構造化データの生成には、主要なチャット型AIのどれもが使えます。1つ2つのページや、変わった種類のスキーマを柔軟に作りたいときは、ChatGPTやClaudeが便利です。会話形式で情報を渡し、細かな要望に応じて調整してもらえます。1回きりの実装なら、これで十分に対応できます。

一方、商品数が数千に及ぶような大量のページに同じスキーマを実装する場合は、API連携や専用ツールで自動化するほうが効率的です。手作業で1つずつ作るのは非現実的だからです。まずはチャット型AIで型を固め、規模が大きくなったら自動化を検討する、という段階的な進め方が現実的です。用途と規模で使い分けましょう。

FAQPageスキーマをAIで作る

以前は最も効果を実感しやすいとされていたのが、FAQPageスキーマです。ただし検索結果での展開表示は2026年5月7日以降ほぼ出なくなっており、いま入れる理由は検索結果の見た目ではなく、ページの中身を機械に正しく読ませることにあります（詳しくは後述）。生成AIに記事のFAQ部分を渡し、次のように依頼すれば、コードがすぐ得られます。

次のよくある質問を、FAQPageのJSON-LD（構造化データ）にしてください。
Googleのリッチリザルトのガイドラインに沿った形式でお願いします。
Q1：{質問1} A1：{答え1}
Q2：{質問2} A2：{答え2}
Q3：{質問3} A3：{答え3}

生成されたコードは、そのまま使わず必ず検証します。質問と答えの中身が実際のページと一致しているか、ユーザーに見えている内容と食い違っていないかを確認します。ページに表示されていない内容を構造化データに書くのは規約違反になるため、この確認は欠かせません。中身の一致を人が担保する前提で使います。

Article・Organizationスキーマを作る

メディア記事には、Article（またはBlogPosting）スキーマが基本です。記事タイトル、公開日、更新日、著者、掲載メディア名などの情報をAIに渡せば、JSON-LDを組み立ててくれます。これにより、検索結果に公開日や著者情報が表示されやすくなり、記事の信頼性や新しさを伝えられます。

あわせて重要なのが、会社の実体を示すOrganizationスキーマです。会社名、ロゴ、公式サイトのURL、SNSアカウントなどを構造化データで示すと、検索エンジンやAIが「この情報の発信元はどの企業か」を正確に把握できます。発信元の実体を明示することは、AI検索での信頼獲得に直結します。トップページや会社情報ページに実装しておく価値があります。

生成後の検証は必須

AIが生成した構造化データは、必ずGoogleのリッチリザルトテストで検証してから実装します。これは省略できない工程です。AIはコードの構造を正確に組み立てますが、記述ミスや、必須項目の抜けが混じることがあります。テストにかければ、エラーや警告が具体的に示されます。

検証では、コードの文法だけでなく、中身が実際のページと一致しているかも人が確認します。AIは渡された情報の範囲で埋めるため、事実の正誤までは判断できません。エラーが出たら、その内容をAIに伝えて修正させれば、対話しながら直せます。生成はAI、検証と事実確認は人という分担を守ることが、安全な実装のカギです。

WordPressなどCMSでの実装

生成・検証した構造化データを実際に設置する方法は、使っているCMSによります。WordPressの場合、SEOプラグインが主要なスキーマを自動で出力してくれることが多く、まずはプラグインの設定で対応できないかを確認します。プラグインで足りる範囲は、手動でコードを追加する必要はありません。

プラグインで対応できない独自のスキーマは、AIで生成したJSON-LDを、テーマの設定やカスタムHTMLブロックでheadやbodyに追加します。プラグインとの二重出力にならないよう注意が必要です。実装場所や方法に迷ったら、使っているCMSとプラグイン名をAIに伝えて手順を相談すると、自社環境に合った進め方が見えてきます。

大量ページはツール・APIで自動化

記事や商品が数十・数百と増えてくると、1つずつ手作業でスキーマを作るのは現実的ではありません。この規模になったら、テンプレート化と自動化を考えます。ページの共通項目をテンプレートにし、個別情報を差し込む形にすれば、AIやスクリプトで一括生成できます。

SEOプラグインの自動出力を活用したり、AIのAPIと連携して生成を自動化したりする方法もあります。まずはチャット型AIで1つの完成形（テンプレート）を作り、それを横展開する発想が効率的です。手作業とツール・自動化の境目は、ページ数と更新頻度で判断します。小規模なら手作業＋AI、大規模なら自動化、と切り替えていきます。

AI生成で注意すべき点

構造化データをAIで作る際に、必ず意識しておきたい注意点があります。最も重要なのは、AIは事実を知らず、渡された情報を形にするだけという点です。以下の落とし穴を避けることで、安全に活用できます。

• 事実確認せずに公開する：AIが埋めた公開日や著者が実際と違うまま出てしまう
• ページにない内容を書く：表示されていない情報の構造化はガイドライン違反になる
• 検証を省く：リッチリザルトテストを通さず、エラーのあるコードを設置してしまう
• プラグインと二重に出力する：同じスキーマが重複し、かえって混乱を招く
• 不要なスキーマを乱用する：効果の薄い種類まで詰め込み、保守が煩雑になる

• 構造化データは正しく実装しても、リッチ表示が必ず出るとは限りません（表示可否はGoogleが判断します）。
• ガイドライン違反のマークアップは、手動対策の対象になることがあります。中身とマークアップの一致を必ず守ります。

リッチ表示が出る型と、出なくなった型を分ける

実装の優先順位は、この一年で変わりました。よくある質問を示す型のリッチ表示は、2023年8月の時点ですでに対象が政府や医療の権威あるサイトへ絞られていましたが、グーグルは2026年5月8日にこの機能そのものの終了を告知し、2026年5月7日以降は検索結果に表示されなくなりました。つまり、よくある質問の型を足せば検索結果が展開表示になる、という前提はもう成り立ちません。2023年の縮小を知らないまま実装を続けてきた現場もあり、その場合は三年ぶんの作業が表示という成果には結びついていません。これから実装する型を選ぶときは、この事実から逆算します。

終了は段階を踏んで進みます。2026年6月には、サーチコンソールの検索での見え方の絞り込みとリッチリザルトのレポート、そしてリッチリザルトテストから、よくある質問の型への対応が外れる予定です。続く2026年8月には、サーチコンソールのAPIからも対応が外れるとされています。ここが実務に効きます。この型のエラー件数をゼロに保つことを運用の指標にしている現場は、指標そのものが取得できなくなります。APIで月次の数値を自動で集めている場合は、その処理が空の値を返すようになり、報告書の表だけが静かに欠けます。月次の報告書の項目と、集計の仕組みの両方を、先に組み替えておきます。置き換えの候補としては、記事の型の必須項目が埋まっているかの確認に振り向けるのが手堅いところです。

では既に入れたものを消すべきかというと、消す必要はないと案内されています。他の検索エンジンが引き続き読み取る可能性があるためです。判断としては、既存のページからは外さず、新しく作る記事でこの型を足す作業の優先度を下げ、空いた工数を記事の型、階層を示すパンくずの型、会社情報の型へ回すのが現実的です。作業を止めるのではなく、同じ時間をどの型に使うかを移す、という置き換えで考えます。あわせて、記事の制作手順書に残っている、よくある質問の型を必ず入れるという一行も直しておきます。手順書を直さないと、担当者は指示どおりに作業を続けてしまいます。なお、よくある質問そのものを記事から消す必要はありません。読者が探している問いに答える部分なので、本文としての価値は変わりません。変わったのは、機械向けの記述を足す作業の見返りだけです。

あわせて、型を二つの群に分けて台帳に書いておきます。片方は検索結果の見た目が変わる型で、こちらは表示回数とクリック率の前後比較で効果を語れます。もう片方は見た目が変わらない型で、発信元の実体や階層を機械に伝えることが目的です。後者は数字で効果を示しにくいため、台帳の目的の欄に何のために出しているかを書いておかないと、翌年の予算の見直しで真っ先に削られます。書き方は一行で足ります。誰に何を伝えるために出しているか、それだけです。この一行は実装した本人が書くのが早く、後から第三者が想像で埋めると目的がぼやけます。測れる型と測れない型を混ぜたまま報告すると、測れない側に引きずられて全体の評価まで下がります。

入れた後に壊れる。公開後の見張り方

構造化データは、設置した時点で完成しません。テーマの更新、プラグインの入れ替え、記事テンプレートの手直しのたびに、出力される中身は変わります。壊れたことに気づく入口になるのがサーチコンソールで、解析できない構造化データというレポートには、構文の誤りでどの型としても判定できなかったページが並びます。ここに件数が出ているあいだ、そのページの記述は無かったことと同じ扱いです。型ごとのレポートとあわせて、月に一度は開きます。件数だけでなく、前月から増えた分がどのテンプレートから出たページかまで見ると、原因にすぐ近づけます。ここに出るのは検索側が巡回できたページだけなので、公開したばかりの記事は数日から数週間おくれて反映されます。

壊れ方には型があります。多いのは、人が見る画面だけを直して機械向けの記述を直し忘れる形です。記事を更新したのに書き添えた日付が初回の公開日のまま、著者の表示名を変えたのに旧い名前のまま、カテゴリの階層を組み替えたのにパンくずの型は旧い階層のまま。どれも画面では正しく見えるので、気づくきっかけがありません。とくに階層の組み替えは一度に数百ページへ及ぶため、気づかれないまま長く残りがちです。更新の手順書に、本文を直したら機械向けの記述も見るという一行を足しておくと、この取り残しはかなり減ります。点検の起点は、その月に更新した記事の一覧です。日付や著者や階層を触ったものだけを抜き出せば、全件を開かずに済みます。

もう一つが二重出力です。プラグインが自動で出している型と、後から手で足したJSON-LDが、同じページに両方載ってしまう状態です。同じ型が二つあると、どちらが読まれるかは分かりませんし、中身が食い違っていれば信頼できない情報として扱われる恐れもあります。確認は簡単で、公開中のページのソースを開き、該当する記述がいくつあるかを数えるだけです。起きやすいのは、プラグインを入れ替えた直後と、担当者が替わった直後です。前の担当が手で足したことを知らずに、新しいプラグインの自動出力を有効にしてしまうためです。テンプレートを変えた月は、種類の違う記事を三本ほど抜き取って同じ確認をします。

点検は、回す仕組みにしないと続きません。月初にサーチコンソールでエラーと警告の件数を前月と並べる、型を追加または変更した月は代表的なページをリッチリザルトテストにかける、テーマやプラグインを更新した日を記録に残す。この三つを担当者の名前つきで決めておきます。記録は更新の履歴を残す画面ではなく、点検の台帳に自分で書き写します。あとで数字の動きと突き合わせるとき、同じ一枚に並んでいるほうが早いからです。更新した日とその月のエラー件数が同じ表に並んでいれば、原因の当たりをつけるのに数分しかかかりません。担当が空欄のまま運用に入ると、誰も見ないまま半年が過ぎ、気づいたときには数百ページ分の記述が無効になっていた、という事態が起きます。

工数と担当をどう割り当てるか

費用の見積もりでつまずくのは、コードを作る時間を工数だと思ってしまうときです。チャット型のAIに情報を渡してJSON-LDを組ませる作業自体は短く済みます。実際に時間を取るのは、渡す前の事実の確認と、設置してからの回し方です。公開日と更新日はどちらを正とするか、著者名はどの表記に統一するか、会社名と所在地はどの資料を出典にするか。この決めごとが済んでいれば、二本目からの作業は大きく短くなります。逆に、決めないまま一本ずつ進めると、記事ごとに表記が揺れた記述が積み上がり、後からまとめて直す作業が発生します。最初の一本に時間をかける理由はここにあります。決めた内容は一枚にまとめ、記事を書く人と設置する人の両方が同じ場所から見られるようにしておきます。

担当の分け方も先に決めます。何を書くかはマーケティング側、どのテンプレートからどう出すかは情報システム側か制作の担当、という分け方が扱いやすい形です。境目が曖昧なまま進めると、テーマの更新で出力が消えても、どちらも自分の持ち場だと思っていないので気づきません。台帳には、どの型を、どのテンプレートから、誰の責任で出しているかを一行ずつ書きます。あわせて、その型を止めたいときに誰へ言えばよいかも同じ行に書いておくと、判断が早くなります。外部の制作会社に任せている型があるなら、その会社名と契約の区切りも同じ行に残します。人が入れ替わったときに読み返せる形にしておくことが、この台帳のいちばんの価値です。

外に出す場合は、見積もりの単位に注意します。テンプレートを作るところまでを頼む場合と、記事ごとの埋め込みまで含める場合では、必要な作業がまったく違います。前者は一度きりですが、後者は記事が増えるたびに積み上がる費用です。テンプレート化までを外に出し、個々の記事の埋め込みは自社で回す形にすると、本数が増えても費用が比例しません。発注の前に、対象の型と対象のテンプレートの数を数えて渡すと、見積もりの差が読みやすくなります。検収の条件も先に書きます。リッチリザルトテストで警告が出ない状態までを納品とすると決めておけば、後の押し問答が減ります。プラグインの自動出力で足りる範囲には追加の費用をかけない、という線引きも最初に引いておきます。

そして、足すだけでなく止める判断を年に一度入れます。型は増やすほど保守が重くなり、テンプレートの修正のたびに確認する箇所が増えていきます。年に一度、出力している型を一覧にして、レポートに件数が出ていない型、参照されている形跡のない型、対応が終了した型を洗い出し、止めるか残すかを決めます。判断の材料は、サーチコンソールの該当レポート、その型を出している記事の本数、関わっているテンプレートの数の三つで足ります。止めると決めた型も、すぐ消さずに一か月は様子を見ると安全です。止めた後に検索結果の見え方が変わっていないかは、代表的なページを数本だけ確かめれば分かります。棚卸しをした日付と、止めた型、残した理由も台帳に残します。

よくある質問

構造化データを入れれば必ず検索結果が豪華になりますか？

必ずではありません。正しく実装しても、リッチ表示を出すかどうかは最終的にGoogleが判断します。ただし、実装しなければ表示の候補にすらならないため、リッチ表示やAI引用のチャンスを得るための前提条件と考えるのが適切です。

プログラミングの知識がなくても実装できますか？

できます。生成AIにページ情報を渡せばJSON-LDのコードが得られ、WordPressならSEOプラグインで主要なスキーマを自動出力できます。コードを自分で書く場面は減っています。ただし、検証と事実確認は人が行う必要があります。

どのスキーマから始めればよいですか？

メディアサイトなら、記事のArticle、パンくずのBreadcrumbList、会社のOrganizationから始めるのが定石です。よくある質問を載せる記事には、FAQPageを加えます。すべてを一度に入れず、効果が見込めるものから段階的に実装するのがおすすめです。

まとめ

構造化データの実装に生成AIを活かす要点は、正確な情報をAIに渡してJSON-LDを生成させ、リッチリザルトテストで検証してから実装することです。JSON-LD形式を選び、Article・FAQPage・Organizationなど効果の出やすいスキーマから着手する。生成はAI、検証と事実確認は人という分担を守り、大量ページはテンプレート化と自動化に進む。専門知識がなくても、AIを使えば実装のハードルは大きく下がっています。まずは1本の記事に、FAQPageかArticleを1つ実装するところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。