AIO対策と構造化データ｜JSON-LDの実装・検証・注意点

AIO対策と構造化データとは何か

構造化データはページの内容を説明する補助情報

構造化データは、記事の見出し、著者、運営組織、画像、公開日などを、一定の語彙と形式で説明するものです。人が画面を読んで理解する内容を、機械でも関係づけやすい形にします。ページそのものの説明が不十分な場合、マークアップだけで情報不足を解消できるわけではありません。

例えば、本文に著者名もプロフィールへのリンクもないのに、JSON-LDにだけ専門家の経歴を書く方法は適切ではありません。読者が確かめられるページを整えてから、その内容に対応する情報を記述します。まず本文、次に情報の関係、その補助として構造化データという順番です。

Googleの構造化データ入門は、検索エンジンがページを理解する助けとして構造化データを説明しています。ただし、有効な記述があることと、検索結果で特定の表示になることは同じではありません。

AIOにできることと、構造化データで保証できないこと

「AIが理解しやすい状態にする」と「AIに推薦させる」は区別が必要です。前者は情報の整合性を改善する取り組みですが、後者には検索クエリ、取得された情報、回答生成の条件など複数の要素が関係します。自社で完全に制御できるものではありません。

AI検索全体の前提を確認したい場合は、AIO対策とはも参照してください。本記事の対象は、施策全体のうち技術的な情報表現と検証の部分です。

GoogleのAI機能への対応条件と提供される検証手段

AIによる概要への特別なschemaは不要

GoogleのAI機能に関する公式資料では、AIによる概要やAIモードに表示されるために追加の技術要件はなく、通常の検索での基本的な要件が重要とされています。特別な機械可読ファイルや新しい構造化データを作成する必要もないと説明されています。

したがって、「AIO専用タグを入れれば掲載される」という説明には慎重になるべきです。ベンダー独自の名称が付いている場合は、実際にはどの仕様を実装するのか、Googleなどの公式仕様とどう対応しているのかを確認します。機能の名前より、変更内容と検証方法を見てください。

• ページがクロール可能かを確認する。
• 検索に出したいページがインデックス対象になっているかを見る。
• 本文が読者に見える形で存在するかを確認する。
• スニペット表示の制御を意図せず制限していないか確認する。
• 構造化データと画面上の情報を一致させる。

Googleの対応とSchema.orgの語彙は別

Schema.orgには幅広い型やプロパティがあります。一方、Google検索のリッチリザルトで利用される種類と要件は、その一部です。Schema.orgとして文法的に正しくても、Googleの特定の検索表示の対象になるとは限りません。

この違いを知らないと、「検証に合格したのに検索結果が変わらない」という混乱が起きます。検証が意味するのは、主に構文や対応要件を満たすかどうかです。品質評価、インデックス、表示選択までを一度に保証するものではありません。

Article・Organizationなどの違いと選び方

解説記事にはArticleを検討する

Articleは、ページが記事であることを説明するための型です。GoogleのArticleガイドでは、著者、画像、日付などの指定について説明されています。ブログ記事ならBlogPostingなど、実態に合う型を選ぶこともできます。

ニュースとして公開していない通常の解説記事に、注目されたいという理由だけでNewsArticleを選ぶ必要はありません。型の名前の強さではなく、ページの内容に合うことが重要です。個別の推奨プロパティや画像条件は、実装する時点の公式資料を確認してください。

運営主体はOrganization、著者はPersonで関係を整理する

会社の公式サイトでは、実在する組織の名称、公式URL、ロゴなどを整理します。個人メディアの場合は、法人ではないものを法人のように表現しないでください。運営主体の実態に応じて、PersonとOrganizationの役割を判断します。

GoogleのOrganizationガイドが示す情報を参考にしつつ、自社に当てはまらない情報は追加しません。住所、電話番号、資格、受賞などを推測して埋めることは避けます。公開していない個人情報をマークアップだけで露出させることにも注意が必要です。

パンくずとFAQは実際のページ構成に合わせる

パンくずはサイト内での位置を伝えるものです。検索順位を狙うためだけに、存在しないカテゴリ階層をJSON-LD内に作るのは避けてください。読者がたどれる構造と、記述している階層が対応する状態にします。

FAQは実際にページ内にある質問と回答を対象にします。ただし、Googleの公式更新履歴によると、FAQリッチリザルトは2026年5月7日から検索結果に表示されなくなり、6月15日に関連ドキュメントも削除されました。過去の「政府機関や医療関連サイトに限定」という説明を、現在の提供条件として使わないでください。FAQ本文は読者のために有用ですが、Google検索の表示拡張を目的とする施策とは分けます。

JSON-LDの書き方と導入手順

最初に本文の情報を確定する

最初からコードを書き始めず、公開画面に出す情報を一覧にします。タイトル、正規URL、著者、著者ページ、公開日、実際に更新した日、画像などです。CMSから自動取得できる情報と、人が管理する情報を分けると更新漏れを減らせます。

記事タイトルを変更したのにheadlineだけ古いまま、という状態は典型的な不整合です。手入力箇所が多いほど確認負担は増えます。原則としてCMS側の正しい値を出力し、例外だけを明示的に管理する設計を検討してください。

1. 対象ページの正規URLを確定する。
2. 公開画面の見出しと著者表示を整える。
3. 日付と画像の実在を確認する。
4. 既存のJSON-LD出力を調べる。
5. 不足している情報だけを実装する。
6. テスト環境または限定したページで検証する。
7. 公開後の取得結果と表示を確認する。

架空の最小サンプルで構造を理解する

以下は説明用の架空例です。example.com、著者名、日付は実績ではなくダミーです。そのまま本番に貼るための完成コードではありません。対象ページの実際の値へ置き換え、必要な要件を公式資料で確認してください。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/example-article/#article",
  "headline": "構造化データの説明用サンプル",
  "mainEntityOfPage": "https://example.com/example-article/",
  "datePublished": "2026-09-18T09:00:00+09:00",
  "dateModified": "2026-09-18T09:00:00+09:00",
  "author": {
    "@type": "Person",
    "name": "サンプル著者",
    "url": "https://example.com/authors/sample/"
  }
}

この例で重要なのは、項目を多くすることではなく、同じ記事について同じ情報を指すことです。@idは同じ実体を参照するための識別子として使います。複数の出力が同じ対象を別名で扱っていないかを見る際にも役立ちます。

実際の画像URLやpublisherなどを追加する場合も、存在する情報を使います。リンク先の画像が404になっていないか、別サイトのロゴを誤って指定していないか確認してください。コード例の情報をそのまま残すミスは、公開前に文字列検索すると見つけやすくなります。

JSON-LDをページへ入れる場所を決める

JSON-LDは通常、適切なscript要素としてHTMLに配置します。ただし、CMSの編集画面に貼ると、権限やエディタの処理によってscriptが除去される場合があります。保存前のコードではなく、公開ページのHTMLで出力されているかを確かめます。

テーマ、SEOプラグイン、独自実装のどこで管理するかを決め、同じ型を複数箇所から出さないようにします。独自実装では文字列を手作業で連結するより、適切なJSONエンコードを使う方が引用符などによる破損を避けやすくなります。実装者はCMSの安全な出力方法にも従ってください。

WordPressでの実装と二重出力の注意点

プラグインを追加する前に現在の出力を調べる

WordPressでは、テーマやSEOプラグインがすでに構造化データを出していることがあります。新しいプラグインを入れる前に、公開ソースでapplication/ld+jsonを検索し、何がいくつ出ているかを調べます。JSON-LDブロックが複数あること自体が即座に問題なのではなく、情報が矛盾しているかが重要です。

例えば、テーマのArticleとプラグインのArticleで著者や更新日が異なる場合、どちらが正しいのか分かりにくくなります。出力元を一つにまとめるか、同じ実体を整合的に扱う設計へ見直します。YoastのSchema開発資料など、使用中の製品の仕様を先に確認してください。

• テーマが出力する型と値を確認する。
• SEOプラグインが出力する型と値を確認する。
• 記事本文に手動コードが残っていないかを見る。
• 同じ著者が複数の表記で登録されていないかを見る。
• キャッシュを含め、公開側にどの値が出ているかを確認する。

自動化する情報と確認が必要な情報を分ける

タイトルや正規URLはCMSから取得しやすい一方、著者の役割や会社情報は管理ルールが必要です。編集者アカウント名をそのまま著者名として出すと、公開プロフィールと合わないことがあります。管理画面のユーザーと、読者に示す著者を混同しないでください。

更新日は、本文の実質的な修正と対応させます。単なる定期処理のたびにdateModifiedを新しくしても、記事内容が新しいことの証明にはなりません。変更履歴を残し、何を更新したか説明できる状態にする方が、編集の品質管理として有用です。

サイト全体の設定と記事固有の修正を分ける

すべての記事で著者が誤っているなら、個別の記事にコードを貼るよりテンプレート側を直す方が適切です。一つの記事だけの画像URLが誤っているなら、その記事のデータを修正します。影響範囲に合わせて変更箇所を選んでください。

変更前には設定やコードのバックアップを取り、戻し方を決めます。複数の設定を同時に変えると、何が改善・悪化の原因だったか追いにくくなります。WordPress全体の点検は、構造化データと内部リンクの改善も参考になります。

費用と運用負担をどう見積もるか

初期設定だけでなく更新確認を含める

無料の検証ツールを使っても、実装と確認の工数は発生します。既存の出力を調べる時間、テンプレートを変更する時間、公開後のチェック、エラーの調査を分けて見積もると、外注の比較もしやすくなります。

「構造化データ一式」という見積書だけでは、何が含まれるか分かりません。対象の型、ページの種類、実装方法、検証URL、修正回数、運用説明の有無まで確認してください。金額を比較する前に、成果物と保守範囲をそろえることが必要です。

工数試算は自社の条件で作る

例えば、担当者の計画用単価を1時間4,000円、調査2時間、実装3時間、検証2時間、手順整理1時間と置くなら、8時間で32,000円の社内工数です。これは本記事の仮定による計算で、市場相場でも受託価格でもありません。大規模サイトや独自CMSでは条件が大きく変わります。

この試算に、必要な有料製品の費用や外注費を加えます。導入前後で引用が増えたとしても、同時に記事更新を行っていれば構造化データだけの効果とは判断できません。費用対効果は、作業の完了と検索・事業の変化を分けて報告してください。

活用事例を測定するときの設計

自社メディアの検証は変更と観測を分ける

当メディアでは、記事、内部リンク、著者情報、インデックス、AI引用などを点検する運用を行っています。ただし、複数の施策を並行しているため、構造化データだけが引用増加の原因だと証明することはできません。実測値を扱うときには、この限界を明示します。

GEO・LLMO・AIOの引用と計測の実測記事では、異なる管理画面の指標を混同しない考え方を整理しています。過去の観測期間の数値を、現在の成果として転記することも避けるべきです。

記録する単位は「変更したページ」「変更した項目」「実施日」「確認方法」です。単に対策済みと書くのではなく、著者URLの修正なのか、重複Articleの整理なのか、更新日の整合性確認なのかを残します。その上でクロールや表示の変化を追います。

検索とAI引用とコンバージョンを別々に見る

検索表示回数は訪問数ではなく、AI引用数もサイトへの流入数ではありません。指標を一つの成果数に足し合わせると意味が変わってしまいます。Search Console、アクセス解析、AI引用の観測で、それぞれ何を数えているか確認します。

より詳しい指標設計は、LLMOの効果測定とKPIで扱っています。技術設定の合否と、事業成果への寄与を別の欄で管理するのが基本です。

Googleの専用レポートについては、生成AIパフォーマンスの公式ヘルプで対象と指標を確認できます。表示回数をAI経由の購入や受注の件数として扱わないでください。

よくある失敗と公開前チェックリスト

見えない情報や評価を追加してしまう

本文にない実績、実際に集めていない星評価、確認していない資格を構造化データへ追加してはいけません。画面に表示されないから問題ないという考え方は誤りです。読者に説明できない情報は、機械向けの記述にも載せないでください。

Googleの一般ガイドラインでは、ページ内容との関連性や表示情報との一致などが求められています。SEOのためという理由で、事実関係を強めたり作ったりすることは避けます。

• 表示していない受賞歴を追加しない。
• 未確認の専門資格を著者情報に含めない。
• 取得していないレビューを評価として作らない。
• 期限切れ価格や在庫を放置しない。
• 他社を自社の関連組織として誤って記述しない。

警告をすべて重大エラーとして扱う

検証結果の警告とエラーは区別します。推奨項目の不足なのか、必要な項目の欠落なのか、そもそも対象の検索機能を使うのかを確認します。警告を消すためだけに存在しない情報を入力してはいけません。

修正の優先順位は、事実との不一致、壊れたJSON、重要なURLの誤り、必要項目の問題、推奨項目の改善というように整理できます。ただし、最終的には対象機能の公式要件を見て判断します。問題の数だけでサイト品質を評価しないことが大切です。

公開後に確認する項目

公開した直後と、テンプレートやプラグインを更新した後には、代表ページを再確認します。トップ、記事、会社情報、商品など、ページ種類ごとに一つずつ選ぶと、サイト全体の問題を見つけやすくなります。

1. 公開ページのHTMLに意図したJSON-LDがある。
2. 本文、タイトル、著者、日付と値が一致する。
3. コード例のexample.comやサンプル名が本番データに残っていない。
4. キャッシュを含めて最新の内容が取得できる。
5. 正規URLと参照先が実在し、意図しない転送がない。
6. モバイルでも本文や著者情報を確認できる。
7. 検証結果と変更履歴を担当者が確認できる場所に残した。

最初の1ページから始める実践プラン

サイト全体を一度に変えるより、まず代表的な1ページで実装と検証の手順を固める方法がおすすめです。特に過去に独自コードを何度も追加しているサイトでは、現状の把握に時間を使う方が手戻りを減らせます。

最初の日は、公開画面とHTMLを照らし合わせて出力元を記録します。次に、誤った値と不足している情報を分けます。設定を直した後は、同じURLで変更前後の差分を確認します。正常になったら、同じテンプレートを使う別の記事でも確認してください。

• 担当者を一人決め、設定の変更窓口をそろえる。
• 変更前のHTMLまたは設定を保存する。
• 対象ページと合格条件を先に決める。
• 修正と記事内容の大幅変更を同時に行いすぎない。
• 公開後の確認日と再点検のきっかけを決める。

記事自体の情報不足が見つかった場合は、構造化データの項目を増やす前に本文を改善します。AIO対策の記事構成と、既存記事のリライト手順を合わせて確認すると、技術と内容の役割を分けやすくなります。

不具合を見つけたときの修正判断表

検証結果に問題が出たときは、原因を推測して一括変更するのではなく、どの出力元のどの値が問題なのかを絞り込みます。記事本文、CMSの登録値、テーマの処理、プラグイン、キャッシュを順に見ます。同じ症状でも原因が異なるため、変更前の記録を残してください。

日付の問題はタイムゾーンも見る

WordPressの表示日時とサーバー内部の日時は、タイムゾーンの扱いによって表記が異なる場合があります。文字列が違うだけで即座に誤りとは判断せず、同じ時刻を指しているかを確認します。時差の情報を落として出力していないかも点検します。

予約記事では、公開前から公開済みであるかのような情報を出さないことが基本です。また、公開後の修正で元の公開日を毎回書き換えると、記事の履歴が分かりにくくなります。公開日と更新日を分け、読者向けの表示とも一致させてください。

個別ページで直すか、共通設定で直すか

一つのページだけの問題なら、そのページの入力値を修正します。すべての記事で同じ問題が起きる場合は、テンプレートや共通設定が原因かもしれません。共通部分を変えるなら、異なるカテゴリやページ種類でも確認し、意図していた出力まで消さないようにします。

修正依頼には、対象URL、検証結果、期待する値、変更前の状態を添えます。「構造化データが壊れている」という表現だけでは、担当者が原因を再現できません。確認したツールと日時を残すことで、キャッシュやクロール時点の違いも調べやすくなります。

修正の完了を効果の発生と混同しない

構文エラーがなくなった、本文と著者情報が一致した、二重出力を整理した、という状態は技術的な修正の完了です。その後に検索表示やAI引用がどう変わったかは、別の確認です。修正のたびに順位上昇を要求すると、実装の品質と検索の変動を混同してしまいます。

運用報告には「修正済み」「再取得待ち」「観測中」などの状態を分けて記載します。担当者が何を完了させ、何がまだ外部の処理や観測に依存しているかを明確にすると、不要な再修正を避けられます。事業成果への影響は、他の施策や観測期間も含めて検討してください。

よくある質問

構造化データを入れればAIに引用されますか？

保証されません。構造化データは内容と関係を伝える補助です。クロール、インデックス、本文の有用性などの前提も必要で、AIの回答や引用の選択は自社で完全には制御できません。

AIO専用のJSON-LDは必要ですか？

GoogleはAI機能への掲載に特別な構造化データは必要ないと説明しています。独自名称のサービスを検討する場合は、実際にどの型と項目を実装するのか、公式仕様との対応を確認してください。

FAQPageを入れれば検索結果が広がりますか？

Googleの公式更新履歴では、FAQリッチリザルトは2026年5月7日から表示されなくなったと説明されています。FAQ本文は読者の疑問を解決するために用意し、Schema.orgの記述とGoogle検索での表示対応を分けて考えてください。

無料のプラグインだけでも対策できますか？

必要な出力を既存のテーマや無料機能で用意できる場合はあります。ただし、製品や設定で対応範囲が異なります。プラグインの数を増やす前に、現在の出力と不足箇所を確認してください。

更新日を毎日変えると有利ですか？

実質的な更新がないのに日付だけを変える運用はおすすめしません。本文の変更と更新日を対応させ、何を修正したかを記録してください。日付変更だけによる効果は保証できません。

検証で合格したのに表示されないのはなぜですか？

検証合格は構文や対応要件の確認であり、表示の保証ではないためです。Googleによる再取得、インデックス、品質や表示選択など別の条件も関係します。エラーがないことと成果が出ることを分けて見てください。

まとめと参考資料

構造化データで優先するのは、項目の多さではなく、公開情報との一致と継続して管理できる仕組みです。AIO対策のために特別なコードを探すより、まず本文、著者、運営主体、URL、日付の整合性を確認してください。

• ページの種類に合う型を選ぶ。
• 本文で確認できる事実だけを記述する。
• 出力元を把握し、矛盾した二重出力を避ける。
• 検証結果と検索・事業成果を分けて管理する。
• テーマ変更や更新後も再点検する。

参考資料は本文中のGoogle公式ガイドに加え、Schema.orgのArticle定義、Schema Markup Validator、Googleリッチリザルトテストです。型の定義、検索機能の要件、実際のページ検証をそれぞれの資料で確認してください。

公式情報の最終確認日：2026年9月18日。コードと費用計算は説明用の例であり、実装結果やAI引用の増加を保証するものではありません。

監修者プロフィール

魚見幸司

1994年4月28日生まれ（32歳）

メディア運営：魚見幸司

✓ 保有資格：Google AI プロフェッショナル認定証

SEO、Web広告、SNS・LINE運用、LP制作・改善、アクセス解析、コンテンツマーケティング、生成AI導入を横断するデジタルマーケティングの専門家。広告代理店で最年少マーケティング事業部長を務め、グローバルマーケティング会社のCMOを経験しています。

成果指標から施策を逆算し、小規模検証から標準化へ進める方法と、人の確認を残した半自動化を重視。SEO・広告・SNS・LP・問い合わせを分断せず、事業成果までつなげる実務検証を行っています。

• SEO・AIO・LLMO
• Web広告
• SNS・LINE運用
• LP・アクセス解析
• 生成AI導入

編集方針：公式情報と設計例を区別し、実行していない例を実測結果として扱わないことを重視しています。 プロフィールと専門分野を見る