EMAX Studio Blog
GEO向け構造化データ:2026年にAIアシスタントが実際に使う6つのスキーマタイプ
Manuel Mrosek · 2026-06-09 · — 閲覧数
GEO向け構造化データ:2026年にAIアシスタントが実際に使う6つのスキーマタイプ
ChatGPTやPerplexityのようなAIアシスタントが2026年に実際に使うschema.orgタイプは、Organization、WebSite、FAQPage、BlogPosting(またはArticle)、Product、HowTo――おおよそインパクトの順に並んでいます。それ以外はすべて冗長か、ニッチか、シグナルが弱すぎて追加してもAI回答でのビジネスの表示に何も変化しません。
この記事は「サイトで実際に何をマークアップすべきか」の実践版です。schema.orgの800超のタイプの完全なカタログでも、理論的な演習でもありません――買い手がGoogleに入力する代わりにAIアシスタントに推奨を尋ねるようになる2026年に、針を動かす6つのタイプだけです。
なぜ構造化データはGoogleよりAIにとって重要なのか
ほとんどのSEO記事が間違える部分はここです。構造化データはすでにGoogleにとって有用でした。AIアシスタントにとっては、根本的により重要であり、その理由は哲学的ではなく機械的です。
Googleはページをランクします。古典的な検索アルゴリズムは、あなたの可視コンテンツを読み、一部を無視し、事実を推論し、ページを競合に対してランクし、リストを表示します。スキーママークアップは助けますが、Googleは長年大規模に意味的推論を行っているので、スキーマなしの適切に構造化されたページでも依然としてランクします。クローラーは、あなたのH1が製品名で、近くの$49が価格で、星評価の画像がレビューの存在を意味すると理解できます。スキーマはその確認を速くしますが、Googleは厳密には必要としません。
AIアシスタントは事実を抽出します。ChatGPT、Perplexity、またはClaudeが「月50ドル未満で個人エージェント向けの最高のCRM」に答えるとき、システムはあなたのページを他の10と対比してランクするのではなく――特定のデータポイント(名前、価格、評価、カテゴリー)を抽出し、それらを文に縫い合わせるのです。それらのデータポイントがJSON-LDブロックに座っていれば、AIはほぼゼロの曖昧さで直接掴みます。マーケティング散文に埋もれていれば、AIはそれらを推論するかもしれず、間違って推論するかもしれず、または単にデータがパースしやすい競合のためにあなたのサイトをスキップするかもしれません。
構造化データはAIアシスタント向けのよく噛み砕かれた食べ物です。Googleはステーキを食べられます。ChatGPTはキューブを好みます。
これが2026年に計算を変える部分です。「Googleはどうせ理解する」という理由で2023年にスキーマを迷っていたなら、その言い訳はなくなりました。AIトラフィックのシェアは成長しており、AIトラフィックは事実が明示的で機械可読かどうかにはるかに直接依存します。より大きなシフトについてはGEO(generative engine optimization)とは何かで取り上げました――構造化データはGEOパフォーマンスを実際に動かす3つか4つのレバーの1つです。
2026年に最も重みを持つ6つのスキーマタイプ
すべてのスキーマが平等に作られているわけではありません。EMAX StudioのQuick Scanを通じて何千もの顧客サイトを監査した後、AIアシスタントが実際に表面化するものとして6つのタイプが繰り返し出てきます。これら6つを正しくすれば、あなたの業界でGEO-レディサイトの上位5パーセントに入ります。7つ目を追加するのは金メッキです。
1. Organization — あなたは誰か
OrganizationスキーマはAIアシスタントに、あなたのビジネスが何か、誰が運営しているか、いつ始まったか、ウェブ上の他の場所でどこで見つけられるかを伝えます。会社を言及するほぼすべてのAI回答がこのオブジェクトから引き出すため、GEOで最も重要な単一のスキーマタイプです。
重要なフィールド:name、legalName、url、logo、sameAs(ソーシャルプロフィールと外部での言及)、founder、foundingDate、description、email。sameAs 配列はキラーフィールドです――AIに「これはあのLinkedInプロフィール、あのXアカウント、あのCrunchbaseページと同じビジネスだ」と伝えます。それなしには、AIはソースを横断してあなたのアイデンティティを自信を持って統合できません。
Organizationスキーマはホームページに置き、理想的にはAboutページにも置いてください。すべてのページに重複させないでください――ルートドメイン上の1つの正規Organizationブロックで十分です。
2. FAQPage — AIが引用したい直接Q&A
FAQマークアップはAIアシスタントが最も直接引用するスキーマタイプです。ユーザーがPerplexityに「会社Xは返金を提供しますか」と尋ねるとき、AIは正にその質問を含むFAQを探し、答えを逐語的に引っ張ります。これについてはAIアシスタント向けFAQスキーマで詳しく取り上げましたが、短いバージョンはこれです:本物のFAQセクションを持つサイトのすべてのページにFAQPageスキーマを追加すべきです。
必須フィールド:Question オブジェクトを持つ mainEntity 配列。それぞれが name(質問)と Answer.text(答え)を持つ acceptedAnswer を含みます。質問はユーザーが実際に尋ねる方法で表現してください。答えは80語以下にしてください。
3. BlogPosting / Article — 権威と著者性
すべてのブログ記事と編集記事には、BlogPosting(またはその親Article)スキーマが必要です。これはAIにコンテンツが公開された時、誰が書いたか、見出しは何か、正規画像はどこにあるかを伝えます。AIアシスタントは匿名で日付なしのコンテンツよりも、最近の著者付きコンテンツを重く評価します――そしてあなたの投稿が最近で著者付きであることを確実に知る唯一の方法はスキーマ経由です。
決定的なフィールド:headline、author(名前と理想的にはURLを持つPersonオブジェクトとして)、datePublished、dateModified、image、publisher(あなたのOrganizationスキーマにリンク)。dateModified フィールドは過小評価されています――古い投稿をリフレッシュしたことを示せます。これはAIアシスタントが時間に敏感なクエリでますます好むものです。
4. Product — 名前、価格、評価
オンラインで何かを販売するなら、Productスキーマは交渉の余地がありません。AIアシスタントはこれを使って比較クエリ(「月10ドル未満で星4以上の瞑想アプリを見せて」)と推奨クエリ(「コーヒーサブスクリプションを推薦して」)に答えます。Productスキーマがなければ、あなたのオファーはマーケティング散文としてのみ存在し、AIはそれを正しくパースするかもしれませんし、しないかもしれません。
必須フィールド:name、description、image、brand、offers(price、priceCurrency、availability 付き)、該当する場合は aggregateRating(ratingValue と reviewCount 付き)と review 配列。評価は比較クエリで勝つ部分です――そしてほとんどのサイトがマークアップを忘れる部分です。
5. HowTo — ステップバイステップの手順
HowToスキーマは、プロセスを順に説明する任意のページ用です――「Xのセットアップ方法」「Yの組み立て方法」「Zの提出方法」。AIアシスタントはHowToコンテンツが大好きです。手続き的クエリに直接答え、構造化された step 配列が抽出を些細にするからです。
フィールド:name、description、step 配列(各ステップは name、text、オプションで image を持つ HowToStep)。あなたのビジネスがサポートドキュメンテーション、チュートリアル、オンボーディングコンテンツを持つなら、HowToスキーマは「[あなたの製品]で[動詞]するにはどうすればいい」のような答えで表面化させます。それはハイインテント・トラフィックです。
6. WebSite — サイト全体のアイデンティティと検索
WebSiteスキーマはあなたのドメインのルートに座り、AIアシスタントにあなたのサイトの名前(Organization名と異なる可能性があります)、主要URL、オプションで内部検索エンドポイントを定義する potentialAction を伝えます。内部検索フックアップはGoogleのsitelinks検索ボックスを駆動しますが、より重要なのは、AIアシスタントに「このサイト内でXを検索」と参照するクリーンな方法を与えることです。
これは小さく静かなスキーマですが、ホームページでWebSiteとOrganizationをペアリングするのが、できる最も安い2ブロックのアップグレードです。5分の作業、生涯の見返り。
10分でスキーマを追加する方法
構造化データの追加はプロジェクトではありません。コーヒーブレイクで終わらせられる5ステップのマイクロタスクです。
ステップ1:上位3つのページタイプを選ぶ。 ほとんどのビジネスではこれらです:ホームページ、ブログ投稿テンプレート、製品/サービスページ。販売するなら「サービスページ」を「製品ページ」に置き換えてください。コンテンツサイトなら「カテゴリーページ」に置き換えてください。
ステップ2:対応するスキーマを選ぶ。 ホームページはOrganization + WebSite + FAQPage(ホームFAQがある場合)を得ます。ブログ投稿テンプレートはBlogPostingを得ます。製品ページはProductを得ます。それだけです――3つのテンプレートが典型的なサイトのページの90パーセントをカバーします。
ステップ3:<head> タグ内にJSON-LDを追加。 <script type="application/ld+json"> ブロックを使ってください。スキーマをbodyに入れないでください。MicrodataやRDFaを使わないでください(これについては下記詳述)。
ステップ4:GoogleのRich Results Testで検証。 URLを search.google.com/test/rich-results に貼り付けてください。検出したスキーマタイプ、欠けているフィールド、エラーを教えてくれます。無料、即時、サインアップ不要。
ステップ5:Google Search Consoleで監視。 「Enhancements」の下に、Googleがインデックスしたスキーマタイプとエラーが表示されます。最初の1か月は毎週、その後は毎月見てください。
3つのテンプレートを持つサイトの合計時間:テンプレートが準備できれば約10分。CMSプラグイン(Yoast、RankMath、または組み込みのWordPressブロックスキーマ)を使えばさらに少ない。
JSON-LD vs Microdata vs RDFa
構造化データには3つの構文があります。1つだけを使うべきです。
JSON-LD は現代的でGoogle推奨のフォーマットです。ヘッド内の別の <script> ブロックに座り、可視HTMLから完全に分離されています。読みやすく、保守しやすく、テンプレート化しやすく、レイアウトを壊すリスクがありません。この記事のすべての例はJSON-LDです。
Microdata はスキーマをHTML属性(itemscope、itemtype、itemprop)に直接埋め込みます。動作しますが、マークアップを乱雑にし、再設計中に簡単に壊れ、デバッグが難しいです。CMSに強制される場合のみ使ってください。
RDFa はMicrodataと似ていますが、異なる属性構文を持ちます。学術的で、セマンティックウェブ純粋主義者に愛され、商業SEOではほぼ誰も使っていません。スキップしてください。
Googleの公開ガイダンスはJSON-LDを好み、私たちがテストしたAIアシスタントはそれを最も確実にパースし、保守がはるかに容易です。新しい実装でMicrodataまたはRDFaが正しい答えである2026年のシナリオはありません。
スキーマタイプ比較:どこで何を使うか
| スキーマタイプ | 最適な用途 | AI可視性ブースト | 重要なフィールド例 |
|---|---|---|---|
| Organization | ホームページ、Aboutページ | 非常に高い――ほぼすべてのAI回答が参照する | sameAs(ソーシャルプロフィールリンク) |
| FAQPage | FAQセクション、FAQを持つ製品ページ | 非常に高い――回答で逐語的に引用される | mainEntity.Question.acceptedAnswer |
| BlogPosting | ブログ投稿、ニュース記事 | 高い――新しさと著者性をシグナル | datePublished、author |
| Product | 製品ページ、価格付きサービスページ | 高い――比較と推奨クエリを駆動 | offers.price、aggregateRating |
| HowTo | チュートリアル、ガイド、ステップバイステップコンテンツ | 中-高――手続き的クエリで勝つ | step 配列 |
| WebSite | ホームページのみ | 中――sitelinksと検索ボックスをサポート | potentialAction(検索エンドポイント) |
2つだけ時間があるなら、OrganizationとFAQPageを行ってください。4つ時間があるなら、BlogPostingとProductを追加してください。他の2つはアップグレードであり、基盤ではありません。
実例:実サイトのための3つのスキーマブロック
これは、ホスト型ブログと製品ページを持つAcme Studioと呼ばれる小さなSaaS会社のスキーマセットアップがどう見えるかです。3つのJSON-LDブロック、ドロップインテンプレート。
Organization(<head> 内、すべてのページ)
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Acme Studio",
"legalName": "Acme Studio Inc.",
"url": "https://acmestudio.com",
"logo": "https://acmestudio.com/logo.png",
"description": "AI-powered design tool for small teams.",
"foundingDate": "2024-03-15",
"founder": {
"@type": "Person",
"name": "Jane Smith"
},
"email": "hello@acmestudio.com",
"sameAs": [
"https://www.linkedin.com/company/acmestudio",
"https://twitter.com/acmestudio",
"https://www.crunchbase.com/organization/acmestudio"
]
}
</script>
WebSite(ホームページのみ)
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "Acme Studio",
"url": "https://acmestudio.com",
"potentialAction": {
"@type": "SearchAction",
"target": "https://acmestudio.com/search?q={search_term_string}",
"query-input": "required name=search_term_string"
}
}
</script>
BlogPosting(すべてのブログ投稿)
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "How to Set Up Acme Studio in 5 Minutes",
"image": "https://acmestudio.com/blog/setup-guide/hero.jpg",
"datePublished": "2026-06-01",
"dateModified": "2026-06-09",
"author": {
"@type": "Person",
"name": "Jane Smith",
"url": "https://acmestudio.com/team/jane-smith"
},
"publisher": {
"@type": "Organization",
"name": "Acme Studio",
"logo": {
"@type": "ImageObject",
"url": "https://acmestudio.com/logo.png"
}
},
"description": "A step-by-step guide to setting up Acme Studio for your first project."
}
</script>
これは約40行のJSONです。出荷するより読むほうが時間がかかります。これら3つのテンプレートがコードベースに入れば、すべての新しいページと投稿が自動的に構造化データを継承します。
スキーマを殺すよくある間違い
ほとんどのスキーマ問題は風変わりではありません。何千ものサイトで繰り返される同じ5つの間違いです。
必須フィールドを忘れる。 GoogleのRich Results Testがこれらを警告します。最も一般的な省略はBlogPostingの publisher(必須)とProductの image(リッチ結果に必須)です。
スキーマと可視コンテンツの不一致。 Productスキーマが価格を$49と言い、可視ページが$79と言うなら、スパムを示唆しています。Googleはこれを罰します。AIアシスタントはデータを信頼せず、あなたのサイトを完全にスキップするかもしれません。スキーマはユーザーが見るものと一致しなければなりません。
ページをまたいだ重複Organization。 ホームページ上の1つの正規Organization、オプションで内部ページから @id 経由で参照。わずかに異なるデータを持つ新しいOrganizationブロックをすべてのページに置かないでください――クローラーとAIパーサーを混乱させます。
壊れた sameAs リンク。 sameAs の全ポイントはアイデンティティの縫合です。LinkedIn URLが404するなら、リンクは無価値で信頼シグナルを失います。sameAs URLを四半期ごとに監査してください。
無効な日付フォーマット。 Schema.orgはISO 8601日付(2026-06-09T14:30:00+00:00 または単に 2026-06-09)を期待します。他のものは黙って無視されます。"datePublished": "June 9, 2026" を出荷して何も動作しない理由を不思議に思うサイトの数は恥ずかしいです。
決して検証しない。 スキーマは静かに失敗します。プロパティ名のタイプミス(founder の代わりに founderr)は警告なしにそのフィールドを単に落とします。デプロイ前にすべてのテンプレートをRich Results Testを通してください、そして任意の再設計後に再度。5分。GEOスコアが動かない理由を不思議に思う何か月も節約します。
よくある質問
6つのスキーマタイプすべてが必要ですか?
いいえ。ほとんどのサイトには3つ必要です:Organization(ホームページ)、FAQPage(FAQが存在する場所)、BlogPosting(すべての投稿)。Productはeコマースに登場します。HowToはチュートリアル中心のサイトに。WebSiteはホームページ上の5分の追加です。印象的に見えるものではなく、実際のコンテンツに合うものを選んでください。
AIアシスタントが実際に私のスキーマを使っているかどうかどう知るか?
正直な答えは、AIプロバイダーがパースしたスキーマについて詳細な分析を公開していないということです。できること:スキーマを追加する前後にPerplexityまたはChatGPTに同じ質問をし、サイトが引用されるか、特定の事実(価格、評価、設立日)がAIの回答に正しく現れるかを観察してください。逸話的に、両方とも持たなかったサイトにOrganization + FAQPageを追加すると、AIアシスタントが再クロールするにつれて2〜6週間以内にAI引用に可視的な変化が生じます。
スキーマをやりすぎることはできますか?
2つの特定の方法でやりすぎることができます。第一に、可視ページに現れない事実でスキーマを詰め込むこと――Googleはこれを欺瞞的なマークアップとしてフラグします。第二に、関連性のないスキーマタイプを多く追加しすぎること(SaaSホームページにRecipeスキーマ、静的ブログにEventスキーマ)で、絵がノイズになります。ページに本当にあるものに対応するスキーマに固執してください。多いほど良いわけではありません。
実店舗向けのLocalBusinessスキーマはどうですか?
LocalBusiness(およびその多くのサブタイプ――Restaurant、Dentist、Bakery)は、物理的な場所を持つ任意のビジネスにとって重要な追加です。ウォークイン顧客にサービスを提供するなら、Organizationブロックを関連するLocalBusinessサブタイプに置き換えてください。フィールドは似ていますが、address、geo(緯度/経度)、openingHours、priceRange が加わります。AIアシスタントは「近くの」と地元推奨クエリにこれを大いに使います。
スキーマは従来型SEOランキングにも影響しますか?
間接的に、はい。Googleはスキーマが直接的なランキング要因ではないと述べていますが、リッチ結果(レビュー星、FAQアコーディオン、製品カード)はクリック率を増加させ、クリックスルーはランキングと相関しています。だからスキーマはランキングを直接押し上げませんが、それが可能にするリッチスニペットは、より上位ランクの競合に対してクリックを獲得できます。これについてはAI SEO vs 従来型SEOで掘り下げました――スキーマは両方の世界で良いスコアを出す数少ない戦術の1つです。
スキーマを追加してから結果を見るまでどれくらいかかりますか?
Googleリッチ結果については、Search Consoleがマークアップを拾い、検索で表示し始めるまで2〜6週間予想してください。AIアシスタントについては、PerplexityやChatGPTが頻繁にクロールするハイトラフィックサイトでは数日以内に引用が更新されることがあり、再クロールがあまり頻繁でないローネットトラフィックサイトでは最大2か月かかります。スキーマには即時満足はありません。安定した複利の見返りがあります。
正直な結論
構造化データは魅力的ではありません。ページ上で可視的なワオの瞬間を生み出しません。誰もあなたのスキーマがよく形成されているからあなたの製品を買うわけではありません。しかし2026年、AIアシスタントがあなたと顧客の間のレイヤーになりつつある中、スキーマは事実として引用されることと、パースに作業がかかりすぎてスキップされることの違いです。
上記の6つのスキーマタイプは、もはや真剣なビジネスにとってオプションではありません。SSLやモバイル対応レイアウトを持つことと同じ、基本的な衛生です。それらを出荷する企業は引用されます。出荷しない企業は、ユーザーが検索結果ページすら見ない回答で競合に置き換えられます。
良いニュース:パターンを掴めばテンプレートあたり10分かかります。サイトから現在欠けているスキーマタイプの無料チェックを求めるなら――そしてGEOスコアが全体的にどこにあるか――emax.studioはGEOサブスコアの一部として5+のスキーマタイプを横断して構造化データを監査する、無料の90秒Quick Scanを実行します。結果を見るためにサインアップ不要。
スキーマはあなたが今まで行う最も安いGEO投資です。今週それをしてください。