最終更新日: 2026/05/29

AIO引用に効く構造化データ種類と優先度を早見表で整理

AIO引用に効く構造化データ種類と優先度を早見表で整理

「構造化データって何から始めればいいの?」——AIが検索結果に引用するサイトを見て、そう感じた方も多いのではないでしょうか。種類が多くて全部入れる必要があるのかも不明、でも放置したままでは競合に差をつけられる一方……そんなモヤモヤを解消するのがこの記事です。AIO引用に効く構造化データ7種を優先度別に整理し、サイト種別・ページ種別ごとの組み合わせ早見表も用意しました。初心者の方でもすぐ対応に着手できるよう、サンプルコードつきで解説します。

AIO引用に効く構造化データ7種と実装優先度【早見表】

AIO引用に効く構造化データ7種と実装優先度【早見表】

まずは全体像を把握しましょう。AIO引用に有効な構造化データ7種を優先度別に整理した早見表を示します。詳しい説明は後の章で行いますが、「何から手をつければよいか」だけ知りたい方はこのセクションを見ておけば大丈夫です。

優先度「高」:まず入れるべき構造化データ3種

サイト・ページの種別を問わず、最初に実装しておきたいのが以下の3種です。

スキーマ

用途

AIへの効果

Article

ブログ・コラム記事

記事の著者・公開日・テーマをAIに明示

FAQPage

Q&Aをまとめたページ

質問と回答のペアをそのまま引用されやすくする

Organization

会社・ブランド情報

サイト運営者の信頼性をAIに伝える

Articleは「この文章は誰が、いつ書いたのか」をAIに伝えるための基本スキーマです。FAQPageは質問と回答の対応関係を機械的に読み取ってもらえるため、AI回答欄に採用されやすい形式として注目されています。Organizationはサイト全体の信頼性に直結するため、どんなサイトでも設置を優先しましょう。

優先度「中」:コンテンツに合わせて追加する構造化データ3種

優先度「高」の3種を入れ終えたら、コンテンツの内容に応じて以下から選んで追加します。

スキーマ

向いているページ

AIへの効果

HowTo

手順・やり方の解説ページ

ステップをリスト形式でAIに認識させる

BreadcrumbList

すべてのページ(任意)

サイト構造を伝えてコンテンツの位置づけを明確化

Dataset

独自調査・統計を公開するページ

データの出典として引用されやすくなる

HowToは「〇〇のやり方」「〇〇の手順」のような記事に効果的です。BreadcrumbListはどのページにも汎用的に使えますが、サイト階層が整理されていることが前提です。Datasetは独自データを持つ場合に限るので、該当しなければスキップしても問題ありません。

優先度「低」:余裕があれば検討する構造化データ1種

7種のなかで最も優先度が低いのがWebPageです。

スキーマ

向いているページ

補足

WebPage

カテゴリページ・LP・汎用ページ

他スキーマが使えない「残りのページ」をカバーする

WebPageはArticleやFAQPageなど具体的なスキーマが当てはまらないページに使う汎用スキーマです。設定しておくと「このURLがWebページである」という最低限の情報をAIに伝えられますが、それだけではAI引用に大きな影響を与えるわけではありません。他のスキーマが一通り入ったあと、カテゴリページなどに追加で設置するイメージで取り組みましょう。

サイト種別・ページ種別ごとの組み合わせ早見表

「どのページに何を入れるか」をひと目でわかるよう、サイト種別・ページ種別と推奨スキーマの対応をまとめました。

ページ種別

推奨スキーマ(優先度順)

トップページ

Organization, WebPage

ブログ・記事ページ

Article, FAQPage, BreadcrumbList

FAQ・Q&Aページ

FAQPage, BreadcrumbList

ハウツー・手順解説

HowTo, Article, BreadcrumbList

サービス紹介ページ

Organization, WebPage, FAQPage

調査・統計データページ

Dataset, Article

カテゴリページ

BreadcrumbList, WebPage

この早見表はあくまで出発点です。ページの内容によって最適な組み合わせは変わるため、次章以降の詳細説明も参考にしながら自サイトに合わせて調整してみてください。

そもそもAIO引用とは?構造化データが必要な理由

そもそもAIO引用とは?構造化データが必要な理由

構造化データを実装する前に、「なぜ必要なのか」を理解しておくと取り組みの方向性がぶれません。AIOとは何か、AIがどうやってサイトを引用するのかを整理します。

AIO(AI最適化)とは何か

AIO(AI Optimization)とは、GoogleのAI Overviewや ChatGPT の検索機能など、生成AIが提供する回答欄に自分のサイトが引用・紹介されるよう最適化する取り組みです。従来のSEOが「検索結果のランキング1位を目指す」ものだとすると、AIOは「AIが生成する回答の中に自サイトの情報が含まれるようにする」ことを目指します。

AI検索が普及するにつれ、ユーザーはランキング上位のページを1件1件クリックするより、AI回答欄を読んで疑問を解決するケースが増えています。引用されたサイトにはリンクが表示されるため、AI回答欄への登場はブランド認知とアクセス獲得の両方につながります。

AIはどうやってサイトの情報を選んで引用するのか

AIが回答に使う情報を選ぶ際には、大きく2つの観点が働いています。

  1. 情報の信頼性と関連性:誰が書いたか、いつ更新されたか、テーマとの関連性はあるか
  2. 機械的な読み取りやすさ:データが構造化されていて、AIが内容を正確に解釈できるか

人間がWebページを読むときは多少文章がわかりにくくても意味を汲み取れますが、AIはページのHTMLやメタデータを解析して情報を抽出します。構造化されていないページは「何を言っているサイトなのか」の判断に時間がかかるため、より明確に情報が整理されたサイトを優先的に引用します。

構造化データがあるとAIに引用されやすくなる理由

構造化データとは、ページの内容をAIや検索エンジンが読み取りやすい形式で記述したコードです。たとえばFAQPageスキーマを使うと「この質問に対してこの回答が対応している」という関係をデータとして明示できます。AIはこのデータを読んで、回答生成に必要な情報を迷わず取り出せます。

料理のレシピに例えると、普通の文章が「材料を切って炒めて味付けして完成」なら、構造化データは「材料:玉ねぎ1個・ニンジン1本/手順:①切る②炒める③味付け」のような整理された形です。後者のほうが自動処理しやすいのは明らかですね。この「機械的な整理のしやすさ」が、AI引用率に直接影響します。

構造化データなしのサイトが引用で不利になる具体的なパターン

構造化データがない場合、どんな不利が生じるのか具体的に見てみましょう。

  • FAQの内容があってもAIがQ&Aの対応関係を誤解釈し、的外れな引用をされる
  • 著者情報や更新日がないと信頼性のスコアが下がり、他サイトに引用機会を奪われる
  • 手順説明があってもステップが認識されず、HowTo形式での引用が発生しない
  • サイト構造が不明なため、AIが「このページが何について書かれているか」を正確に判定できない

特に競合サイトが構造化データを入れている場合、AIは競合を優先的に引用します。コンテンツの質が同程度であれば、「読み取りやすいほう」が選ばれるのは当然の流れです。

構造化データの基本知識|実装前に知っておくこと

構造化データの基本知識|実装前に知っておくこと

いざ実装しようとしたとき「JSON-LDって何?」「どこに書くの?」と手が止まることがあります。ここでは実装に入る前に押さえておきたい基礎知識を確認します。

構造化データとは何か

構造化データとは、Webページの内容を機械(検索エンジン・AI)が理解しやすい形で記述したコードのことです。schema.orgという共通規格に従って、「このページは記事である」「著者は〇〇である」「手順は3ステップある」といった情報を定義します。

これを設置することで、Googleは検索結果に星評価や手順リストを表示する「リッチリザルト」を出せるようになり、AIは回答生成に必要な情報をページから確実に取り出せます。HTMLの見た目を変えるものではないため、ページデザインへの影響はありません。

JSON-LD・Microdata・RDFaの違いと初心者におすすめの形式

構造化データの記述形式は主に3種類あります。

形式

書き方の特徴

初心者向けか

JSON-LD

<script>タグにまとめて記述

◎ おすすめ

Microdata

HTMLタグの属性として記述

△ 既存コードの改変が必要

RDFa

HTMLタグの属性として記述

△ 記述が複雑

Googleも公式に推奨しているのがJSON-LDです。既存のHTMLを触らずに<script>ブロックを追加するだけで実装できるため、初心者でも挫折しにくい形式です。以降のサンプルコードもすべてJSON-LD形式で紹介します。

構造化データはどこに書けばよいか

JSON-LDの場合、<head>タグの中か<body>タグの中に記述します。Googleはどちらでも認識しますが、管理のしやすさから<head>内への配置が一般的です。

WordPressを使っている場合は、Yoast SEOやAll in One SEOなどのSEOプラグインが構造化データを自動生成してくれます。プラグインで対応できないカスタムスキーマは、テーマのfunctions.phpやカスタムフィールドを使って追加します。静的サイトやカスタム開発のサイトでは、各ページのHTMLに直接記述するのが最もシンプルな方法です。

Googleリッチリザルトテストで実装を確認する方法

構造化データを書いたら、Googleの公式ツールで正しく認識されているか確認しましょう。

  1. Googleリッチリザルトテストにアクセス
  2. 確認したいページのURLを入力(またはコードを直接貼り付け)
  3. 「テスト」を押してスキャン結果を確認

「有効なアイテムが検出されました」と表示されれば正常です。エラーや警告がある場合は、必須プロパティが不足している可能性があります。エラー内容をクリックすると不足している項目が表示されるので、サンプルコードを見ながら修正しましょう。

AIO引用に効く構造化データ7種を1つずつ解説

AIO引用に効く構造化データ7種を1つずつ解説

ここからは早見表で示した7種のスキーマを1つずつ詳しく見ていきます。「自分のサイトにどれが必要か」を判断するための情報をまとめています。

①Article(記事・コラムページの基本スキーマ)

Articleスキーマは、ブログ記事やコラム、ニュース記事など「文章コンテンツ」のページに設置します。主なプロパティは以下のとおりです。

  • headline:記事タイトル
  • author:著者名
  • datePublished:公開日
  • dateModified:最終更新日
  • image:アイキャッチ画像のURL
  • publisher:運営者情報

AIが記事を引用する際、「誰が・いつ・何について書いたか」の3点は信頼性の判断材料になります。これらを明示するArticleスキーマは、コンテンツの信頼度を高める基本中の基本です。NewsArticle(ニュース向け)やBlogPosting(ブログ向け)という派生型もありますが、迷ったらArticleで問題ありません。

②FAQPage(よくある質問をまとめたページ向け)

FAQPageスキーマは、複数の質問と回答をセットで持つページに設置します。AIが「〇〇とは?」「〇〇の方法は?」という疑問に答える際、FAQPageのデータは回答文として引用されやすい構造です。

必須プロパティはmainEntityの中にQuestionacceptedAnswerを対応させる形です。記事末尾に設置する「よくある質問」セクションだけでなく、本文の途中にQ&A形式で質問と回答を並べているページにも有効です。1ページに設置できる質問数に上限はありませんが、内容がページ本文と一致していることが条件です。ページに書かれていない回答をスキーマだけに記述しても、Googleのガイドライン違反になる場合があります。

③HowTo(手順・やり方を説明するページ向け)

HowToスキーマは、何かを達成するための手順を順番に説明するページに使います。「〇〇のやり方」「〇〇を設定する方法」「〇〇を作る手順」といった記事が典型的なケースです。

stepプロパティに各ステップのテキストを配列で記述することで、AIはどの手順が何番目にあたるかを正確に把握できます。検索結果にステップリスト付きのリッチリザルトが表示される可能性もあり、クリック率の向上も期待できます。ただし、手順が明確でないページ(概要説明のみ、結論だけの記事など)に無理やり使うと、コンテンツとスキーマの不一致でガイドライン違反になるため注意が必要です。

④Organization(会社・サービス提供者の情報を伝えるスキーマ)

Organizationスキーマは、サイトを運営している会社や個人・ブランドの情報を記述するスキーマです。主に以下の情報を含めます。

  • name:組織・ブランド名
  • url:公式サイトURL
  • logo:ロゴ画像URL
  • contactPoint:連絡先情報
  • sameAs:SNSや外部プロフィールのURL

AIは引用先のサイトが「信頼できる運営者によるものか」を評価します。Organizationスキーマがあると、運営者の実在性をデータとして示せるため、E-E-A-T(経験・専門性・権威性・信頼性)の観点からもプラスに働きます。トップページに1回設置すれば、サイト全体に効果が及ぶ点も効率的です。

⑤BreadcrumbList(パンくずリストでサイト構造を伝えるスキーマ)

BreadcrumbListスキーマは、「トップ>カテゴリ>記事名」のようなパンくずリストの構造をコードで明示するスキーマです。AIはこのデータを使って、ページがサイト全体のどの位置にあるかを把握します。

たとえば「SEO対策の方法」という記事が「Webマーケティング」カテゴリに属していることがわかれば、AIはその記事をWebマーケティングに関連した情報として適切に分類できます。直接的なAI引用への影響は他のスキーマより控えめですが、サイト構造の明確化という意味でSEO全体に好影響を与えます。Webサイトにパンくずリストが表示されていれば、対応するスキーマも合わせて設置しておきましょう。

⑥Dataset(調査データや独自統計を持つページ向け)

Datasetスキーマは、アンケート結果や市場調査データ、独自統計などを公開しているページ向けのスキーマです。データのタイトル・説明・作成者・配布ライセンスなどを記述します。

AIが根拠として引用したい場面では、「出典が明確なデータ」が優先されます。Datasetスキーマはデータの出典情報を明示するため、AI回答内で「〇〇社の調査によると」といった形で引用される可能性が高まります。独自のアンケートやユーザー調査結果を記事に含めている場合は、ぜひ追加しておきたいスキーマです。独自データを持たないサイトには必要ないため、該当する場合のみ検討してください。

⑦WebPage(カテゴリページやLP向けの汎用スキーマ)

WebPageスキーマは、特定のスキーマタイプに当てはまらないページに使う汎用スキーマです。name(ページ名)・description(概要)・url(URL)を記述するシンプルな構成です。

カテゴリページやランディングページなど、Article・FAQPage・HowToのいずれにも分類しにくいページに設置します。これ単体でのAI引用への影響は小さいですが、「このURLが有効なWebページである」という基本情報をGoogleやAIに伝える役割を果たします。7種のなかでは最後に対応する形で問題なく、まず優先度「高」の3種をしっかり整備することを優先しましょう。

実装優先度の決め方|自分のサイトはどこから始めるべきか

実装優先度の決め方|自分のサイトはどこから始めるべきか

スキーマの種類がわかったら、次は「自分のサイトはどこから始めるか」を決める段階です。サイトの目的やページ構成によって最適な優先順位は変わります。

優先度を決める3つの判断軸

どのスキーマから実装するかを決めるとき、以下の3つの軸で考えると整理しやすいです。

  1. サイトの主な目的:情報発信・集客・EC・ブランディングのどれが中心か
  2. 最も多いページ種別:記事が多いか、サービスページが多いか、FAQが多いか
  3. AIに最も引用してほしいコンテンツはどれか:サイトの核となるページから優先する

たとえば「ブログ記事でオーガニック集客を増やしたい」なら、まずArticleとFAQPageが優先度「高」になります。「自社サービスの認知を広げたい」なら、OrganizationとWebPageを先に整備します。全種類を一気に実装しようとすると挫折しやすいため、3種から始めて順番に広げていく進め方がおすすめです。

ブログ・オウンドメディアサイトの優先順位

情報発信を目的としたブログやオウンドメディアでは、次の順番で実装を進めましょう。

  1. Article(すべての記事ページ)
  2. Organization(トップページ)
  3. FAQPage(記事内Q&Aセクションまたは専用ページ)
  4. BreadcrumbList(記事ページ・カテゴリページ)
  5. HowTo(手順解説系の記事のみ)

オウンドメディアは記事数が多いため、ArticleスキーマをWordPressプラグイン等で自動適用できるか確認するのが先決です。手動で1記事ずつ設定するのは現実的でないため、プラグインや開発サポートを活用して効率よく展開しましょう。

企業サービスサイト・コーポレートサイトの優先順位

会社紹介やサービス案内が中心のサイトでは、以下の順番が効果的です。

  1. Organization(トップページ)
  2. FAQPage(サービスページやFAQページ)
  3. BreadcrumbList(全ページ)
  4. Article(ニュース・プレスリリースがあれば)
  5. WebPage(サービス詳細ページ)

コーポレートサイトでは「信頼できる会社か」という情報がAI引用の可否に大きく影響します。Organizationスキーマで連絡先・SNSリンク・ロゴを整備することが最優先です。問い合わせページへの誘導を重視するなら、ContactPageスキーマ(WebPageの派生)も合わせて検討してみましょう。

ECサイト・商品紹介サイトの優先順位

ECサイトや商品紹介サイトでは、今回の7種に加えてProductスキーマやReviewスキーマが重要になりますが、本記事のスコープ内では以下の順番を推奨します。

  1. Product(商品詳細ページ)
  2. BreadcrumbList(商品カテゴリ・商品詳細ページ、該当ページに実装)
  3. FAQPage(商品ページ内にFAQセクションがある場合に実装)
  4. Offer(商品詳細ページ、在庫・価格情報を記載)

ECサイトはAI引用よりも購買意欲に直結する構造化データ(ProductスキーマやOfferスキーマ)の優先度が高くなりがちです。今回の7種を一通り整備したあと、商品情報関連のスキーマに取り組む流れが現実的でしょう。

優先度が変わる「ページ種別」ごとの考え方

サイト種別だけでなく、ページの役割によっても最適なスキーマは変わります。

ページの役割

優先すべきスキーマ

情報収集ユーザーを集める記事

Article, FAQPage

比較検討ユーザーが見るページ

Product, Offer, Review, BreadcrumbList

手順を求めるユーザー向け記事

HowTo, Article

データ・統計を示すページ

Dataset, Article

ブランド認知を高めるトップページ

WebSite, WebPage, Organization

なお、FAQPageはページ内にQ&Aのコンテンツが実際に存在する場合、HowToは手順の説明が実際に書かれている場合にのみ使うのが正しい使い方です。スキーマの種類はユーザーの気持ちだけでなく、「このページに実際に含まれている内容は何か」を起点に考えると、設置すべきスキーマが絞り込まれます。ページの中身とスキーマの種類を一致させることが、AIに正確に内容を伝えるための最短ルートです。

構造化データの組み合わせパターン|ページ別の実装例

構造化データの組み合わせパターン|ページ別の実装例

スキーマは1つのページに複数組み合わせて使えます。どのページにどのスキーマを組み合わせるか、ページ種別ごとに具体的なパターンを見ていきましょう。

トップページに組み合わせるスキーマのパターン

トップページに設置するスキーマの基本パターンは Organization + WebPage の組み合わせです。

  • Organization:サイト運営者の基本情報(名称・URL・ロゴ・連絡先・SNSリンク)
  • WebPage:トップページ自体の説明(ページ名・概要・URL)

Organizationはサイト全体の信頼性を担う情報源なので、トップページに確実に入れておきましょう。WebPageはページの概要を補足する形で追加します。記事や商品ページとは異なり、トップページはサイト全体を代表するページなので、コンテンツを詰め込みすぎず最小限のスキーマで整理するのがポイントです。

ブログ記事ページに組み合わせるスキーマのパターン

ブログ記事ページの基本パターンは Article + BreadcrumbList で、FAQセクションがあれば FAQPage を追加します。

  • Article:記事のタイトル・著者・公開日・更新日・画像
  • BreadcrumbList:「トップ>カテゴリ>記事名」の階層情報
  • FAQPage(任意):記事内のQ&Aセクションの質問・回答ペア

3種を組み合わせることで、AIは「誰が書いた何についての記事で、どのカテゴリに属していて、どんな質問に答えているか」を一度に把握できます。手順説明が含まれる記事ならHowToも追加できますが、一つの記事にArticle・FAQPage・HowToを全部重ねると管理が複雑になるため、ページの主目的に合わせて2〜3種に絞るのが現実的です。

FAQ・Q&Aページに組み合わせるスキーマのパターン

FAQ専用ページは FAQPage + BreadcrumbList の組み合わせがシンプルで効果的です。

  • FAQPage:すべての質問と回答のペア
  • BreadcrumbList:サイト内の位置情報

FAQPageスキーマはこのページで最も重要な役割を果たします。質問文と回答文はページ本文の内容と一致させる必要があります。スキーマだけに回答を書いてページには表示しない、といった実装はGoogleのガイドライン違反になるため注意しましょう。質問数が多い場合は、特にAIに引用してほしい重要な質問を優先的にスキーマに含めるとよいです。

ハウツー・手順解説ページに組み合わせるスキーマのパターン

手順解説ページの推奨パターンは HowTo + Article + BreadcrumbList です。

  • HowTo:手順のタイトル・各ステップの説明
  • Article:記事全体の著者・公開日情報
  • BreadcrumbList:サイト内の位置

HowToスキーマを主役に据え、ArticleスキーマでE-E-A-T関連の情報を補完する形です。HowToのstepには各ステップの概要テキストだけでなく、imageプロパティで手順ごとの画像も追加できます。画像があるとリッチリザルトの表示が豊かになり、クリック率のアップも見込めます。記事内にQ&Aコーナーがある場合はFAQPageも追加可能ですが、まずHowTo+Articleの2種を確実に整備しましょう。

サービス紹介ページに組み合わせるスキーマのパターン

サービス紹介ページには Organization + FAQPage + WebPage の組み合わせが効果的です。

  • Organization:サービス提供会社の基本情報
  • FAQPage:サービスに関するよくある質問
  • WebPage:ページ自体の概要・URL

サービスページへの訪問者は「この会社は信頼できるか?」「料金は?」「他のサービスとどう違う?」といった疑問を持っています。FAQPageスキーマでこれらの疑問に答える構造を明示すると、AIが「サービスに関する回答」として引用する可能性が高まります。Organizationスキーマは複数のページに重複して記述するより、トップページに1回設置してサイト全体を代表させる方法がスタンダードです。

複数スキーマを重ねるときに起きやすいエラーと回避策

複数のスキーマを1ページに設置する際、よくあるエラーと回避策を確認しておきましょう。

  • 重複プロパティエラー:同じプロパティを複数のスキーマで矛盾した値で記述する → 各スキーマの役割を明確に分けて書く
  • スキーマとコンテンツの不一致:ページ本文にない情報をスキーマに記述する → 必ずページに表示されている内容のみを記述
  • JSON構文エラー:カンマや括弧の閉じ忘れ → バリデーターで確認してから公開
  • スキーマのネスト誤り:Article内にFAQPageをネストする(誤った構造)→ 複数スキーマは独立した<script>ブロックとして記述

複数スキーマを1ページに置く場合は、<script type="application/ld+json">ブロックを複数に分けて記述する方法が管理しやすいです。

Article・FAQPage・HowToのJSON-LD記述例|コピーして使えるサンプルコード

Article・FAQPage・HowToのJSON-LD記

ここからは優先度「高」〜「中」の代表的なスキーマのサンプルコードを紹介します。コピーして値を書き換えるだけで使えるように設計しています。

Articleスキーマのサンプルコード

ブログ記事・コラムページに設置するArticleスキーマのサンプルです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事タイトルをここに入力",
  "author": {
    "@type": "Person",
    "name": "著者名"
  },
  "publisher": {
    "@type": "Organization",
    "name": "サイト名",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2025-01-01",
  "dateModified": "2025-06-01",
  "image": "https://example.com/image.jpg",
  "url": "https://example.com/article-url/",
  "description": "記事の概要文を入力"
}
</script>

datePublisheddateModifiedはISO 8601形式(YYYY-MM-DD)で記述します。imageは600px以上の幅の画像URLを指定するとリッチリザルト対象になりやすいです。

FAQPageスキーマのサンプルコード

Q&Aセクションを含むページに設置するFAQPageスキーマのサンプルです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "質問文1",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "回答文1"
      }
    },
    {
      "@type": "Question",
      "name": "質問文2",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "回答文2"
      }
    }
  ]
}
</script>

mainEntity配列に質問と回答のペアを追加するだけで質問数を増やせます。textの回答文はHTMLタグを含めることもできますが、プレーンテキストの方がAIに引用されやすい傾向があります。

HowToスキーマのサンプルコード

手順解説ページに設置するHowToスキーマのサンプルです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "ハウツーのタイトル",
  "description": "この手順で何ができるかを説明する概要文",
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "ステップ1のタイトル",
      "text": "ステップ1の詳細説明"
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "ステップ2のタイトル",
      "text": "ステップ2の詳細説明"
    }
  ]
}
</script>

positionは手順の順番を示す数字です。ステップ数に応じて配列を増やします。imageプロパティを各ステップに追加すると、Googleの検索結果にステップ画像付きのリッチリザルトが表示される可能性があります。

Organizationスキーマのサンプルコード

トップページに設置するOrganizationスキーマのサンプルです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "会社名・ブランド名",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "description": "会社・サービスの概要説明",
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer service",
    "email": "info@example.com"
  },
  "sameAs": [
    "https://twitter.com/yourhandle",
    "https://www.facebook.com/yourpage"
  ]
}
</script>

sameAsにはX(旧Twitter)・Facebook・LinkedInなど公式SNSのURLを入れます。外部サービスとの同一性を示すことで、AIがサイト運営者の実在性をより確かなものとして認識します。

サンプルコードをそのまま使うときの注意点

サンプルコードを流用する際に確認しておきたいポイントをまとめます。

  • URLはすべて自サイトの実際のURLに書き換える(example.comのままはNG)
  • 日付は実際の公開日・更新日を入力する(架空の日付はガイドライン違反)
  • ページに表示されていない情報をスキーマだけに書かない
  • JSON形式の文法エラー(カンマ不足・括弧漏れ)がないかリッチリザルトテストで確認する
  • WordPressプラグインが同じスキーマを自動出力している場合は重複に注意する

コードを公開したら必ずGoogleリッチリザルトテストでエラーがないことを確認してから次のページへ進みましょう。焦って大量に設置するより、1ページずつ確認しながら展開する方が長期的に安全です。

構造化データだけでは不十分?AIO引用されるために合わせて対策したいこと

構造化データだけでは不十分?AIO引用されるために合わせて対

構造化データを整備するだけでAI引用が劇的に増えるわけではありません。AIが「引用に値するコンテンツ」と判断するには、構造化データ以外の要素も重要です。

記事の冒頭に結論を書く「答え先出し」の構成

AIが記事から回答を抽出するとき、冒頭部分のテキストを重視する傾向があります。「結論はページの後半に書く」という構成は、AI引用の観点からは不利です。

記事の最初の100〜150字に「この記事で何がわかるか」「結論は何か」を明示する「答え先出し」の書き方が、AIO対策として効果的です。たとえば「〇〇の方法は3ステップで完結します。①…②…③…」のように冒頭で答えを提示すると、AIはそのテキストを回答の候補として認識しやすくなります。検索ユーザーにとっても「知りたいことがすぐわかる」構成なので、直帰率の改善にもつながります。

見出し・箇条書きでAIが読み取りやすい文章構造にする

AIは長い段落文より、見出しや箇条書きで整理されたテキストを正確に解析できます。

  • H2・H3の見出しに具体的なキーワードを含める
  • 手順やポイントは番号付きリスト・箇条書きで整理する
  • 1段落に1つのトピックしか書かない(詰め込まない)
  • 専門用語には簡単な説明を付記する

これはSEO的にも正しい文章構造の作り方と一致しています。「人が読みやすい文章」と「AIが解析しやすい文章」は方向性が同じです。Markdown形式に近い明快な構造を意識して書くと、AI引用率と読者満足度の両方が上がります。

著者情報・更新日を明記してE-E-A-Tを高める

Googleが提唱するE-E-A-T(Experience・Expertise・Authoritativeness・Trustworthiness)は、AI引用の判断にも影響します。「誰が書いたのかわからない記事」より「専門家が書いた記事」が引用されやすいのは直感的にも理解できるでしょう。

具体的には以下を記事に明示しましょう。

  • 著者の名前・肩書き・プロフィールへのリンク
  • 記事の公開日と最終更新日
  • 参考文献や出典リンク

構造化データのArticleスキーマに著者情報を記述するだけでなく、ページ上でも読者が目視で確認できる形で表示することが重要です。スキーマだけに情報があってページに表示されていない状態は避けてください。

独自データや一次情報をコンテンツに盛り込む

AIが回答を生成する際、どこにでもある二次情報より「そのサイトにしかない一次情報」を引用する傾向があります。自社のアンケート結果・ユーザーインタビュー・実験データ・事例などがあれば、積極的にコンテンツに組み込みましょう。

たとえば「〇〇を導入したクライアントの改善率データ」「ユーザー100名へのアンケート結果」のような独自情報は、他のサイトで代替できないため引用価値が高まります。Datasetスキーマと組み合わせることで、AI・検索エンジンの両方に対してデータの出典が明確なサイトとして認識されます。独自データがない場合は、体験談や具体的な事例の記述だけでも差別化になります。

llms.txtの設置でAIクローラーにサイト情報を伝える

llms.txt(エルエルエムエス・テキスト)は、AIクローラー向けにサイトの概要・構成・主要ページを案内するテキストファイルです。robots.txtがSEOクローラー向けであるように、llms.txtはAIエージェント向けの案内板とイメージするとわかりやすいです。

https://yoursite.com/llms.txtのURLに設置し、以下のような情報を記述します。

  • サイトの説明と目的
  • 主要カテゴリや重要ページへのリンク
  • AIに参照してほしいコンテンツの概要

まだ必須の対応ではありませんが、AIクローラーへの対応として先行して導入しているサイトが増えています。構造化データと合わせて設置しておくと、AIに対するサイト情報の伝達がより確実になります。

実装後の確認方法|ちゃんと効いているかチェックする手順

実装後の確認方法|ちゃんと効いているかチェックする手順

構造化データを設置したら、正しく機能しているかを確認するステップが欠かせません。ツールを使った検証方法とAI引用状況の調べ方を解説します。

Googleのリッチリザルトテストで構造化データを検証する

Googleリッチリザルトテストは、構造化データが正しく記述されているかを即座に確認できる公式ツールです。URLを入力するだけで、設置されているスキーマの種類・有効なプロパティ・エラー・警告の一覧が表示されます。

「エラー」は必ず修正が必要です。「警告」は推奨プロパティが不足している場合に表示されますが、必須ではないため優先度を判断して対応しましょう。新しいページにスキーマを追加したら、公開直後にこのツールでチェックする習慣をつけると、問題を早期に発見できます。

Google Search Consoleで構造化データのエラーを確認する

Google Search Consoleの「拡張」セクションでは、サイト全体の構造化データのエラー状況を一覧で確認できます。リッチリザルトテストが1ページ単位の確認ツールであるのに対し、Search Consoleはサイト全体のスキャン結果をまとめて見られる点が便利です。

確認の手順は以下のとおりです。

  1. Search Consoleにログイン
  2. 左メニュー「拡張機能」から各スキーマの状況をクリック
  3. エラー・有効・警告の件数と該当URLを確認
  4. エラーが出ているページを優先して修正

Search Consoleのデータは数日〜1週間のタイムラグがあるため、すぐに反映されない点は覚えておきましょう。

AI検索での引用状況を手動で調べる方法

構造化データの実装後、実際にAI検索で引用されているかを手動で確認できます。

  • Google AIオーバービュー:Googleで自サイトに関連するキーワードを検索し、AI概要欄に自サイトが引用されているか確認する
  • ChatGPT検索:ChatGPTの検索機能で同様のキーワードを検索し、引用ソースを確認する
  • Perplexity AI:Perplexityで質問し、ソースリストに自サイトが表示されるかチェックする

引用されていた場合は、どのページが・どんな質問に対して引用されたかを記録しておくと、今後の改善の参考になります。引用率の変化を追跡するためにも、実装前後の状況を比較できるよう定期的にチェックしましょう。

GA4でAI検索からの流入を計測する設定方法

Google Analytics 4(GA4)では、AI検索からの流入をある程度把握できます。設定手順は以下のとおりです。

  1. GA4の「レポート」→「集客」→「トラフィック獲得」を開く
  2. セッションのデフォルトチャネルグループに「Organic Search」を選択
  3. 参照元・メディアでGoogle検索からの自然検索トラフィックを確認する(AI概要経由かどうかにかかわらず、すべてgoogle / organicとして計測され、AI概要だけをGA4上で切り出して確認することはできない)

現時点のGA4の仕様では、AI概要(AI Overview)経由と通常の検索結果(青いリンク)経由の流入を区別して表示することはできません。すべて通常の自然検索と同じgoogle / organicとして扱われます。より詳しく追跡したい場合は、Google Search Console側で一部の言語・地域を対象にAI Overview関連の指標(AI Overview経由のクリックなど)が順次ロールアウトされているため、Search Consoleの最新アップデートと、ご自身のプロパティで当該指標が利用可能かどうかを確認してみてください。

初心者がやりがちな実装ミスと対処法

初心者がやりがちな実装ミスと対処法

構造化データの実装で初心者がよくつまずくミスをまとめました。事前に把握しておくことで、よくあるエラーを回避できます。

必須プロパティの記述漏れによるエラー

スキーマには必須プロパティと推奨プロパティがあります。必須プロパティが1つでも欠けると、リッチリザルトテストでエラーが出てリッチリザルト対象外になります。

代表的な必須プロパティを確認しましょう。

スキーマ

主な必須プロパティ

Article

headline, author, datePublished, image

FAQPage

mainEntitynameacceptedAnswerを含む)

HowTo

name, steptextを含む)

Organization

name

schema.orgの公式ドキュメントとGoogleの構造化データガイドラインを見ながら、必須プロパティが全部揃っているか確認してから公開する習慣が大切です。

ページの内容と一致しないスキーマを設定してしまう

「引用されたい」という気持ちから、ページの実際の内容とずれたスキーマを設定してしまうケースがあります。たとえば手順説明がほぼないページにHowToスキーマを設置したり、FAQセクションがないページにFAQPageスキーマを書いたりする例です。

Googleはコンテンツとスキーマの整合性を確認しており、不一致が検出されるとスパムと判断されペナルティの対象になることもあります。「スキーマに書いた内容はページにも表示されていること」を鉄則として守りましょう。実装前にページの構成を見直し、スキーマに合ったコンテンツが存在するかを確認する作業が必要です。

複数のSEOプラグインが競合して二重に出力されてしまう

WordPressサイトでよくある問題が、SEOプラグインの競合による構造化データの二重出力です。Yoast SEOとAll in One SEOを同時に有効化していたり、テーマが独自にスキーマを出力していたりすると、同じスキーマが2回出力されてエラーになる場合があります。

対処法は以下のとおりです。

  1. Search Consoleまたはリッチリザルトテストで二重出力を確認
  2. 使用するSEOプラグインを1つに絞り、もう一方を無効化
  3. テーマが自動出力するスキーマを確認し、不要な場合はテーマ設定またはコードで無効化

複数プラグインを使う場合は、どのプラグインがどのスキーマを担当するかを明確に決めておくとトラブルを防げます。

実装したのにリッチリザルトが表示されないときの確認手順

スキーマを正しく実装してもリッチリザルトが表示されないことがあります。これは必ずしもミスではなく、Googleがリッチリザルトの表示を判断するためです。

確認すべき点を順番に見てみましょう。

  1. リッチリザルトテストで「有効なアイテムが検出されました」と表示されているか
  2. Search Consoleでそのスキーマの「有効」件数にページが含まれているか
  3. ページがGoogleにインデックスされているか(Search Consoleの「URL検査」で確認)
  4. ページのコンテンツ品質がGoogleの基準を満たしているか

スキーマが正常でもコンテンツの質が低いと判断された場合はリッチリザルトが出ないことがあります。構造化データは「引用を保証するもの」ではなく「引用されやすくするもの」と理解しておくと、焦らず取り組めます。

まとめ

まとめ

AIO引用に効く構造化データ7種——Article・FAQPage・HowTo・Organization・BreadcrumbList・Dataset・WebPage——を優先度別に整理しました。まずはArticle・FAQPage・Organizationの3種から始め、コンテンツに合わせて追加していくのが最もスムーズな進め方です。

構造化データはAI引用への近道ですが、それだけで全てが解決するわけではありません。答え先出しの構成・著者情報の明示・独自情報の盛り込みなど、コンテンツの質を高める取り組みと組み合わせてこそ効果が出ます。サンプルコードを活用しながら、まず1ページ試してみるところから始めてみましょう。

SEOやAIO対策についてさらに詳しいサポートが必要な場合は、cocorographのSEOコンサルティングサービスもご活用ください。

AIO引用に効く構造化データ7種|実装優先度と組み合わせ早見表についてよくある質問

AIO引用に効く構造化データ7種|実装優先度と組み合わせ早見
  • AIO引用に最も効果的な構造化データは何ですか?
    • FAQPageスキーマが最もAI引用と結びつきやすいとされています。質問と回答のペアをデータとして明示するため、AIが回答文として直接引用しやすい構造だからです。まず FAQPage と Article、Organization の3種から実装することをおすすめします。
  • 構造化データを実装したら、すぐにAI検索に引用されますか?
    • すぐに引用されるわけではありません。構造化データはAIが情報を読み取りやすくするものであり、引用の保証ではありません。Googleがページを再クロール・再インデックスするまでに数日〜数週間かかる場合もあります。コンテンツの質・E-E-A-T・ページの権威性も引用判断に影響します。
  • WordPressのSEOプラグインを使っていれば、自分でコードを書かなくてもよいですか?
    • Yoast SEOやAll in One SEOなどのプラグインは、Article・Organization・BreadcrumbListなどの主要スキーマを自動生成してくれます。ただしFAQPageやHowToは手動設定が必要な場合もあるため、プラグインが対応しているスキーマの種類を事前に確認しておくと安心です。
  • 1つのページに複数のスキーマを設置してよいですか?
    • 問題ありません。たとえばブログ記事に Article + FAQPage + BreadcrumbList を組み合わせるのは一般的な実装パターンです。ただしページ内容と一致しないスキーマを無理に追加するのはガイドライン違反になるため、コンテンツに合ったスキーマのみを選んでください。
  • 構造化データなしのサイトはAI引用で本当に不利になりますか?
    • 明確に不利になります。競合サイトが構造化データで情報を整理しているのに、自サイトに何もない場合、AIは整理されたデータを持つ競合を優先して引用する傾向があります。構造化データはAI引用の絶対条件ではありませんが、対応していないことがマイナス要因になるのは確かです。
中村 一浩

監修者紹介

中村 一浩

代表取締役CEO

株式会社ココログラフ 代表取締役CEO。1982年生まれ。高校卒業後に携帯販売業界にて、インターネットとハードウェアの急速な進化に触れた後、ウェブの面白さに惹かれ、2009年に株式会社ジオコードに入社。SEOを中心にウェブマーケティングを学び、同時にウェブ制作部門、システム開発部門のマネジメントも兼務。幅広いウェブ運用知識を有する。2018年に独立・起業し、検索エンジンだけでなく検索ユーザーにまで最適化する、SEOの上位互換サービスSUOを提供。SEO / SUOの独自レポートツール、サチコレポート開発者。著書『現場のプロが教えるSEOの最新常識』(Amazon: https://amzn.to/4wPgYEK )

■得意領域
ウェブサイト改善 / SEO対策 / コンテンツマーケティング

関連記事

600社の実績、継続率78%。
“見つかる”をつくるプロに、
まず相談。

“見つかる”をつくるその先に、お客様の成果がある。ココログラフはSEO・AIO・Web制作を通じて、その実現をお手伝いします。

03-6845-138010:00〜18:00(平日)