AEO スキーママークアップ完全ガイド：FAQPage・Product・Organization（2026）

AEOに必要なスキーママークアップの適用法。BlogPosting・FAQPage・BreadcrumbList・Organization・ProductのJSON-LD作成法から検証ツールまで、PIONが実務基準で整理します。

AI検索はページを丸ごと読んで要約するわけではありません。回答に使う事実の断片だけを選んで抜き出します。その抜粋が正確であるためには、ページが"これは発行機関、これは質問、これは回答、これは価格"だと機械が読めるように、自ら宣言しなければなりません。スキーママークアップこそがその宣言書です。

ページのHEADに、schema.orgの語彙で組んだJSON-LDブロックを入れます。コンテンツ記事にはBlogPosting・FAQPage・BreadcrumbListの3つを1セットで、会社サイトにはOrganization・WebSite・Service（またはProduct）をサイト全体に配置します。実装フォーマットはJSON-LD一つに整理されました。Microdata・RDFaは標準ドキュメントに残っているだけで実務では終わったので、新しく作るサイトでは目を向ける必要がありません。

なぜschemaがAEOの最低要件なのか

schemaは露出を押し上げる仕掛けではありません。引用候補群に名前を載せる入場券です。ChatGPTやPerplexityが答えを組み立てるとき、このページからどの文章を引用するかを決めますが、平文のHTMLしかなければ判断する根拠があいまいになります。このQ&Aが何の質問の答えなのか、発行主体が誰なのか、製品価格がいくらなのかが、タグで明確に定められていないからです。

Search Engine Landが2025年9月に行った統制実験では、内容がまったく同じ2つのページのうち、うまく組まれたJSON-LDが付いた方だけがGoogle AI Overviews（AI概要）に登場した事例が報告されました。実務感覚もこれと食い違いません。カテゴリの主要プロンプトで引用比率が0のページを調べてみると、schemaがそもそも無いか、あっても会社情報がページごとに食い違っている場合がほとんどです。

ただし誤解しないようにしましょう。 schemaを付けたからといって、回答に自動的に表示されるわけではありません。無ければそもそも審査対象から外れ、あって初めて候補に入ります。そこから先の露出を分けるのは、コンテンツの回答適合性と会社の信頼度という、次の段階の問題です。

コンテンツ記事：BlogPosting + FAQPage + BreadcrumbListの3つを1セットで

ブログやガイド記事の1ページには、3つのタイプをまとめて入れます。3つがそれぞれ異なるシグナルを担うため、一つだけ付けると中途半端になります。

タイプ	担当シグナル	必ず埋めるフィールド
BlogPosting	誰が・いつ・どんなテーマの記事か	headline, datePublished, dateModified, author, publisher, mainEntityOfPage
FAQPage	このページの質問・回答ペア	mainEntity[]内のQuestion → acceptedAnswer(Answer)
BreadcrumbList	サイト内でのこの記事の位置	itemListElementのposition, name, item

dateModifiedを空けておいてはいけません。 AIの回答は最新の記事に引用の優先順位を与えます。数年前の記事に見えれば、その分だけ損です。文章を大きく書き直していなくても、内容を一度ざっと見直して点検したのなら、その時点に日付を更新しておくのが正解です。

FAQPageは3つの中でAEO効果が最も直接的です。schema.orgのFAQPage定義のとおりmainEntity配列にQuestionを入れ、各QuestionにacceptedAnswerを連結すれば、質問と答えのペアが、AIがそのまま持って行って使える完成した回答の形になります。ただし、Google Search CentralのFAQPageドキュメントが明言した原則があります。本文に実際に見えるQ&Aだけをマークアップすること。画面にない質問をschemaにだけこっそり入れると、ポリシー違反です。

BreadcrumbListは目立ちませんが、外すともったいないものです。AIエンジンがサイト構造を把握し、Knowledge Panelが出典の経路を表記するときにこの値を使います。position・name・itemを順番どおりに書けば終わる、手間の割に効果が高い項目です。

ちなみにPIONの自社ブログでは、記事を公開するとこの3つが自動的に付きます。本文のFAQをclassName="faq-section"コンテナで包むと、ビルダーが質問と答えを収集してFAQPageのJSON-LDをページに注入する仕組みです。

会社サイト：Organization + WebSite + Service/Product

ホーム・会社紹介・サービス・製品といった主要ページには、会社そのものを一つのエンティティとして登録するschemaが別途必要です。個別記事のschemaとは別に、サイト全域に敷いておく層です。

Organizationの勝負どころはsameAsです。 name・url・logo・descriptionまでは誰でも埋めます。問題はsameAsです。この配列が空だと、AIは"getpion.comのその会社"と"LinkedIn・報道に出たその会社"が同じところなのかを照合する基準点がなく、引用するときに会社名の表記が揺れます。だからといって、LinkedIn・Crunchbase・記事のリンクを貼っておけばいいというものでもありません。肝心のリンク先ページで社名・ドメイン・ロゴがバラバラだと、効力が失われます。外部に同じ名前で一貫して露出しているときにだけ、このフィールドが生きてきます。

WebSiteはドメインそのもののメタデータです。SearchActionを一緒に置けば、Knowledge Panelにサイト内検索窓が表示されることがあり、publisherの連結で個別記事のBlogPostingと結び付きます。

ServiceかProductかは事業モデルが決めます。PIONのようなマーケティング代行会社はService、物を売るeコマースブランドはProductです。この選択をいい加減にすると損が大きいです。たとえば" クリームの価格はいくら"のようなプロンプトに引用されるには、Productのsku・brand・offers・aggregateRatingまですべて埋めなければなりません。Serviceなら、provider（Organization参照）・areaServed・serviceType・hasOfferCatalogを置きます。

どこに、どんな形で入れるか

JSON-LDはページのHEADに置くのが標準です。BODYの末尾に置いても動作はしますが、HEADにあってこそクローラーが文書の前半部でメタデータを先に捉えます。1ページに複数のschemaを置くときは、グラフでまとめるか、それぞれ<script type="application/ld+json">ブロックで並べて置きます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "AEOのためのスキーママークアップはどう適用しますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "ページのHEADにJSON-LDブロックを挿入し ..."
      }
    }
  ]
}
</script>

運用しながら破ってはならないことが2つあります。

schema内のテキスト＝画面本文のテキスト。 本文にない文章をschemaにだけ埋めた瞬間にGoogleのポリシー違反となり、よくしようとしたことがペナルティとなって返ってきます。
@idでエンティティ同士をつなぐ。 Organization・WebSite・BlogPosting・Personが@idで互いを参照すれば、AIエンジンはサイト全体を一つに連結されたエンティティのまとまりとして認識します。参照がなければ、同じサイトをバラバラに散らばったページとして認識します。

検証：2つのツールを両方通過させた後にデプロイ

schemaを組んだら、デプロイ前に2つのツールによる検証を必ず通過させます。性格が異なるので、一つだけを見てはいけません。

Google Rich Results Testは、URLやコードスニペットを入れると、Googleが認識するrich resultのタイプとエラー・警告を表示します。Googleの表示ポリシー基準です。
Schema.org Markup Validatorは、標準語彙そのものの文法を検査します。Rich Results Testが捉えられない語彙エラーをここで捉えます。

ここで実務の現実を一つ押さえておかなければなりません。2つのツールを通過したからといって、AIの回答に表示されるわけではありません。 検証の通過は文法が合っているという意味にすぎず、実際の引用はその次の問題です。ですから代行会社であるPIONがクライアントのサイトを修正するときは、2つのツールで一度点検した後、実際のAIエンジン（ChatGPT・Perplexity・Gemini（ジェミニ））にカテゴリの主要プロンプトを投げて、引用比率がどう動くかを後続測定で確認します。schemaは結果がすぐには捉えられず、次のインデックスサイクルに反映されるため、2〜4週間間隔の再測定を標準手順としています。

よくある質問

AEOのためのスキーママークアップはどう適用しますか？

ページのHEADに、schema.orgの語彙で組んだJSON-LDブロックを入れます。コンテンツ記事にはBlogPosting + FAQPage + BreadcrumbListの3つをセットで、サイト全域にはOrganization + WebSite + Service（またはProduct）を置きます。schema内のテキストと画面本文のテキストが正確に一致しなければならず、Google Rich Results TestとSchema.org Validatorの両方を通過させた後にデプロイします。

FAQPage・Product・Organizationのスキーマはどう作成しますか？

FAQPageは、mainEntity配列にQuestionを入れ、各QuestionにacceptedAnswer(Answer)を連結します。Productはsku・brand・offers・aggregateRatingまで埋めてこそ、価格・評点の引用資格が生まれます。Organizationはname・url・logo・description・sameAs・founder・foundingDateを埋めますが、sameAsでLinkedIn・Crunchbase・報道といった外部情報と結び付けて、会社エンティティの同一性を確認させます。

JSON-LDだけでスキーママークアップを作成しなければなりませんか？

2026年の新規サイトはJSON-LD一つだけを使います。Microdata・RDFaはschema.org標準に残っていますが、GoogleがJSON-LDを推奨フォーマットと明言し、これらの旧形式は実務では事実上使われなくなりました。JSON-LDはHTML本文と分離されたscriptブロックなので、コンテンツを修正してもschemaが壊れる危険が最も低いという長所もあります。

スキーママークアップを適用すればAIの回答にすぐ露出しますか？

すぐには表示されません。schemaは引用資格を開くゲートにすぎず、実際の露出はコンテンツの回答適合性・会社エンティティの信頼度・サイトの権威が決めます。AIエンジンのインデックス更新周期が2〜4週間なので、schemaのデプロイ後、1か月ほどの時点で再測定してこそ変化が捉えられます。

スキーママークアップの検証はどこで行いますか？

Google Rich Results TestとSchema.org Markup Validatorの2つのツールを両方使います。前者はGoogleの表示ポリシー基準、後者はschema.org標準語彙の文法基準なので、性格が異なります。2つのツールのエラー・警告をすべて解消した後にデプロイし、schema内のテキストと画面本文のテキストが正確に一致しているかを再度確認します。

AEOのためのスキーママークアップ完全ガイド：FAQPage・Product・Organization