AIOの構造化データ実装ガイド｜確認項目と改善方法を解説

監修: 菊地 将（リブランディング株式会社）

「FAQやOrganizationの構造化データを入れれば、AIに引用されやすくなる」と考えていませんか。AIO（AI検索で自社情報を理解・参照されやすくするための取り組み）を進める際、そう考えるのは早計です。

Googleは、AI Overviews（検索結果に表示されるAIによる概要）やAI Modeに表示されるための特別なschema.orgマークアップは不要で、構造化データはページ上でユーザーに見える内容と一致させることが重要だと説明しています。

構造化データとは、検索エンジンなどが「これは企業名」「これは記事の著者」「これは商品の価格」とページ内の情報を理解しやすくするための機械可読データです。重要なのは、ページ種別に合った構造化データを選び、HTML・CMS上の情報と矛盾なく実装し、公開後まで検証できる状態を作ることです。

本記事では、AIO・SEO担当者、Web担当者、開発担当者が共同で使える実装優先度と監査フローを整理します。ページ種別ごとの優先度、HTMLと値を一致させる作り方、実装前の棚卸し、公開前後の検証、エラーの直し方、よくある失敗の順に進みます。

結論｜構造化データは「AI専用施策」ではなく、ページの意味を機械的に伝える補助情報

この節では、構造化データをAIOの中でどう位置づけるかを決めます。

Googleは構造化データをページ内容の理解やリッチリザルトへの対応に使用していますが、正しく実装しても検索結果で特別な表示が保証されるわけではありません。冒頭で触れたとおり、GoogleのAI OverviewsやAI Modeについても、専用のschema.org構造化データや新しいAI向けマークアップは必要ないと公式に説明されています。

つまり、構造化データはAIに引用させるための専用の仕掛けではなく、ページに書かれている正しい情報を機械が読み取りやすくする補助情報だと考えます。

そのため、AIOのための構造化データ実装では、次の順番で進めるのが基本です。「何のページか」が決まらなければ、選ぶ構造化データも、HTMLと照らし合わせる内容も、公開後に監視する対象も決まらないためです。

1. そのページが何を扱うページかを確定する
2. ページ種別に対応する構造化データを選ぶ
3. HTML・CMS・構造化データの内容を一致させる
4. Google向け要件とschema.org上の妥当性を検証する
5. 一部ページへ先行実装して実際の取得状態を確認する
6. 本番展開後にSearch Console等でエラーを監視する
7. テンプレートやデータ更新時にも整合性を維持する

なお、この記事では、ArticleやProductのような構造化データの種類を「schema」と呼びます。「とにかくschemaを増やす」のではなく、「正しい情報を、正しいページで、継続して正しく出力する」ことが実装の中心です。

AIOの技術対策全体の前提から確認したい場合は、「AIOの技術対策とは？企業担当者が押さえるべき8領域の実務チェックリスト」を参照してください。

ページ種別ごとに、実装する構造化データの優先度を決める

この節では、どのページから構造化データを実装するかを決めます。すべてのページへ同じ構造化データを入れる必要はありません。ページの主目的と、Googleが現在サポートしている検索機能を基準に優先順位を付けます。

次の表は、ページ種別ごとの実装候補と優先度をまとめたものです。

ページ種別	主な構造化データ候補	優先度	主な目的
トップ・企業情報	Organization	高	企業名、URL、ロゴ、連絡先など企業実体の理解を補助
記事・コラム	Article / BlogPosting、BreadcrumbList	高	記事名、著者、公開・更新情報、サイト階層の明示
商品詳細	Product、Offer等	高	商品、価格、在庫、レビュー等の商品情報を明示
個別求人	JobPosting	高	職種、勤務地、雇用条件など求人情報を明示
店舗・拠点	LocalBusiness	高	所在地、営業時間など拠点情報を明示
著者・担当者ページ	ProfilePage / Person	中	人物や組織プロフィールの理解を補助
パンくずがあるページ	BreadcrumbList	中〜高	サイト内でのページ位置を明示
FAQ・手順ページ	FAQPage / HowTo等	条件付き	内容を意味的に記述する必要がある場合に検討

優先度が「高」のページ種別から着手し、FAQ・手順ページは、内容を意味的に記述する必要があるかどうかを確かめてから検討します。

FAQPageとHowToを後回しにするのは、Googleの現在の構造化データ検索ギャラリーにArticle、Breadcrumb、Job posting、Local business、Organization、Product、Profile pageなどが掲載されている一方で、2026年6月15日時点の同一覧にはFAQPageとHowToが掲載されていないためです。したがって、FAQPageやHowToを「GoogleのリッチリザルトやAI検索に効くから」という理由だけで最優先する設計は避けるべきです。

実装する場所は、種別によって異なります。Organization、JobPosting、LocalBusinessについて、Googleの説明を確認します。

• Organizationについては、Googleはホームページへの実装によって組織の管理情報や識別を理解しやすくできると説明しています。
• JobPostingは、求人一覧ページへ各求人の詳細情報を大量に記述するのではなく、基本的に個別の求人情報ページへ実装します。Googleは求人一覧ページに個々の求人の構造化データを載せることをポリシー違反例として示しています。
• LocalBusinessは、サイト内のどのページにも記述できますが、Googleは実際のビジネス情報が掲載されているページへ配置する方が自然だとしています。

関連して、AIクローラーの動きの確認方法は、「AIクローラーをアクセスログで確認する方法」で詳しく解説しています。

JSON-LDは既存HTMLと別管理せず、同じ情報源から生成する

この節では、HTMLと構造化データの値を食い違わせない作り方を決めます。構造化データの記述形式には、JSON-LD、Microdata、RDFaなどがあります。実務ではJSON-LDが管理しやすいケースが多く、Googleも一般的にJSON-LDを推奨しています。

ただし、形式より重要なのは「ユーザーが見ている情報との一致」です。

例えば、次の情報はHTMLとJSON-LDで食い違わないようにします。表では、同じ情報がHTML上の表示、CMSの元データ、JSON-LDのどの項目に対応するかを示しています。

情報	HTML上の表示	CMSの元データ	JSON-LD
記事タイトル	H1	title	headline
著者	著者欄	author	author
公開日	公開日表示	datePublished	datePublished
更新日	更新日表示	dateModified	dateModified
商品価格	商品詳細	price	offers.price
在庫状態	商品詳細	availability	offers.availability
企業名	会社概要	companyName	Organization.name

理想は、HTML用とJSON-LD用に情報を二重入力することではありません。CMSやデータベースの同じ値から、画面表示用のHTMLとJSON-LDの両方を生成します。

こうすれば、「ページ上では10,000円なのにJSON-LDには9,800円」「著者名を変更したのに構造化データだけ旧名」「求人募集を終了したのにJobPostingが残っている」といった不整合を防ぎやすくなります。Googleのガイドラインでも、構造化データはページに表示される内容を正しく表し、最新の状態を保つ必要があります。

実装前監査｜まず既存の構造化データをテンプレート単位で棚卸しする

この節では、新しいJSON-LDを追加する前に、現在どの構造化データが出力されているかを確認します。WordPressなどでは、テーマ、SEOプラグイン、ECプラグイン、独自実装、Google Tag Managerなど、複数の仕組みが同時にJSON-LDを生成している場合があります。

確認するときに重要なのは、ページ件数ではなくテンプレートです。1記事でArticleに問題がある場合、その記事だけの入力ミスかもしれません。しかし記事テンプレート自体に問題があれば、数百・数千URLへ同じエラーが展開される可能性があります。

そこで、監査では最低限、次の単位で代表URLを抽出します。

• トップページ
• 会社概要
• 記事ページ
• カテゴリページ
• 商品詳細
• 商品一覧
• 求人詳細
• 求人一覧
• 店舗・拠点
• 著者ページ
• 問い合わせ等の一般固定ページ

各代表URLについて、JSON-LDだけでなくMicrodataやRDFaの有無も確認し、「どのテンプレートから何が出力されているか」を記録します。

監査表には「URL」「ページ種別」「schemaタイプ」「出力元」「HTMLとの不一致」「検証結果」「修正担当」を残すと、SEO担当者と開発担当者の間で修正対象を共有しやすくなります。

1ページに複数のschemaがあっても問題ない｜重要なのは主題との整合

この節では、1ページに複数のschemaを置いてよいか、どんな基準で判断するかを決めます。「1ページにはschemaを1つだけ入れる」と考える必要はありません。Googleは、同じページに複数種類の構造化データが存在する場合でも、それぞれを個別に記述する方法と、関連するデータをネストする方法の両方を理解できると説明しています。

例えば記事ページなら、次のようなschemaが同時に関係する場合があります。

• BlogPosting
• BreadcrumbList
• 著者を表すPerson

商品ページでもProductだけでなく、Offerなど関連するデータが組み合わされます。

問題になるのは「複数あること」そのものではなく、次のような矛盾です。

• 同じ企業名が別々の値で出ている
• 価格がschemaごとに違う
• ページに存在しない商品やFAQを記述している
• 主題と関係のないschemaを大量に追加している

数ではなく、主題との整合を基準にします。Googleも、ページの主目的を表す構造化データを含めることを推奨しています。

公開前はSchema Markup ValidatorとRich Results Testを使い分ける

この節では、公開前の検証にどのツールを何のために使うかを決めます。構造化データの検証では、1つのツールだけを見て「正常」と判断しないことが重要です。Googleは、用途の異なる2つの検証方法を案内しています。

Schema Markup Validator

schema.orgの語彙や構文として正しく記述されているかを確認するために使います。Googleの検索機能でサポートされているかどうかとは別に、schema.orgベースの構造化データを広く確認できます。

Rich Results Test

Google検索のリッチリザルト対象として、Googleが認識できる構造化データやエラーを確認するために使います。

つまり、「schema.orgとして有効か」と「Google検索の特定機能で利用できるか」は別の確認です。この違いを理解しておくと、「Validatorでは正常なのにRich Results Testで対象にならない」という状態を誤ってエラー扱いすることを避けられます。

構造化データは実装して終わりではありません。棚卸し、HTMLとの照合、検証、本番確認、継続監視までを一連の工程として管理します。

公開時は代表ページだけ先行実装し、Googleが取得したHTMLまで確認する

この節では、公開時に何をどの順で確認するかを決めます。構造化データを新規実装するときは、いきなり全URLへ展開するよりも、代表ページへ先行実装して確認する方が安全です。Googleの構造化データ実装ガイドでも、検証後に一部ページへ展開し、URL検査でGoogleがページをどのように認識しているか確認する手順が案内されています。

特にJavaScriptやGoogle Tag ManagerでJSON-LDを生成している場合は、ブラウザで見えるソースだけではなく、レンダリング後に構造化データが生成されているかを確認します。GoogleはJavaScriptで生成された構造化データも処理できますが、動的生成時には実装方式や更新頻度に注意が必要です。

公開前後は、次の3段階で確認します。

1. コード確認：Schema Markup ValidatorとRich Results Testで構文やGoogle向け要件を確認します。
2. 実ページ確認：本番URLをURL検査で確認し、Googleが取得・レンダリングしたページに意図したJSON-LDが存在するか確認します。
3. サイト全体確認：Search Consoleの構造化データ関連レポートで、同じエラーが複数URLへ広がっていないか確認します。

公開直後にSearch ConsoleへすべてのURLが反映されるとは限りません。そのため、実装直後の確認と、再クロール後の確認を分けて行います。

構造化データのエラーは「重大度×影響URL数×ページ価値」で直す

この節では、見つかったエラーを直す順番を決めます。エラーが多数見つかった場合、警告件数だけで優先順位を決めると重要な問題を後回しにする可能性があります。

実務では、重大度・影響URL数・ページ価値の3軸で判断すると整理しやすくなります。次の表は、この考え方で状態ごとの優先度と対応をまとめたものです。

優先度	主な状態	対応
最優先	JSON-LDを解析できない、主要情報が本文と矛盾、必須項目不足、求人・価格・在庫など重要情報が古い	直ちに原因特定・修正
高	テンプレート起因で多数URLにエラー、複数の出力元で値が衝突	テンプレート・出力元を修正
中	推奨プロパティ不足、情報充実の余地	主要ページから改善
低	検索機能への影響が限定的な任意項目	他施策との優先度を比較

これはGoogle公式のスコアではなく、サイト運用のための実務上の判断フレームです。

例えば同じエラーでも、「アクセスの少ない1ページの任意プロパティ不足」と「全商品ページで価格が誤っている状態」は同じ優先度ではありません。表に当てはめると、前者は「低」、後者は「最優先」に当たり、先に直すのは後者です。また、テンプレート起因のエラーを先に直すことで、多数のURLをまとめて改善できる場合もあります。

構造化データ監査でよくある5つの失敗

ここまでの内容を踏まえ、監査で起こりやすい失敗を5つ挙げます。自社の運用に当てはまるものがないか、確認しながら読み進めてください。

1．AIO対策としてFAQPageを大量追加する

GoogleはAI OverviewsやAI Mode向けの特別なschema.orgマークアップは不要と明記しています。FAQが実際にページの主要内容として存在するなら意味的なマークアップを検討できますが、「AIに拾わせるため」だけに追加するのは優先順位が逆です。

2．1ページ1schemaに限定する

Googleは複数の構造化データ項目を同じページで扱えます。数を減らすことより、各データがページの実態と一致しているかを確認します。

3．プラグインを入れた時点で実装完了とする

プラグインを入れただけでは、実装が終わったとは言えません。プラグインが出力する値と、テーマや独自コードが出力する値が重複・矛盾していないかまで確認します。

4．初回実装後に更新しない

価格、在庫、求人期限、担当者、住所、記事更新日などは変化します。HTMLだけ更新してJSON-LDが古いまま残る設計では、時間の経過とともに品質が下がります。

5．構造化データだけを直し、クロール可能性を確認しない

構造化データが正しくても、ページ自体がnoindex、robots.txt、ログイン制限などによってGoogleから取得できなければ検索機能には利用されません。GoogleのAI検索機能についても、通常のGoogle検索でインデックスされ、検索結果に表示可能であることが前提です。

構造化データは「実装率」ではなく、正確性と維持できる仕組みを監査する

この節では、実装後に何を指標として見続けるかを決めます。AIO・SEO担当者が管理すべき指標は、「何種類のschemaを入れたか」だけではありません。少なくとも次の状態を定期監査します。

• ページ種別に適したschemaが使われている
• ページの主題と構造化データが一致している
• HTMLとJSON-LDの値が一致している
• 古い価格、求人、人物、住所などが残っていない
• 出力元が明確になっている
• テンプレート変更後もJSON-LDが維持されている
• ValidatorとGoogle向け検証の両方を通している
• Search Consoleで新しい重大エラーが増えていない

構造化データは一度追加して終わるコードではありません。Webサイト上の情報を機械向けにも正しく同期するためのデータ設計として管理する必要があります。

まとめ｜AI向けに足す前に、ページの情報を正しく出力できているかを確かめる

AIO向けの構造化データ実装で最初に考えるべきことは、「AI向けに何を追加するか」ではありません。ページ種別を確定し、そのページの内容を表すschemaを選び、HTML・CMS・JSON-LDを同じ情報源から整合させることが基本です。

特に重要なのは、次の4つです。

• 実装前の棚卸し
• 代表ページでの先行検証
• 公開後のSearch Console確認
• テンプレート変更やデータ更新後の再監査

構造化データを「AIに引用させるためのタグ」ではなく、「検索エンジンなどがページ上の正しい情報を機械的に理解しやすくする仕組み」と捉えることで、SEOとAIOの双方で再利用できる技術基盤になります。

最初の一歩は、代表URLをテンプレート単位で棚卸しし、どの仕組みがどの構造化データを出力しているかを記録することです。

参考文献・データ元

‹ 親記事: AIOの技術対策とは？企業担当者が押さえるべき8領域の実務チェックリスト

関連記事

• › AIクローラーをアクセスログで確認する方法｜主要ボットの識別とクロール阻害の診断
• › 多言語サイトのAIO実装｜翻訳・言語地域指定・企業情報を整理
• › PDFのAIO確認方法｜AI検索で本文・出典・更新情報を読めるか

関連テーマ

SEO MEO 口コミ・風評対策 採用改善 オウンドメディア集客