言語

スキーママークアップ

スキーママークアップは、schema.orgの語彙を使用したコードで、コンテンツの意味をラベル付けし、検索エンジンがそれを理解してリッチ結果を表示できるようにします。

初回公開：2026年6月26日 · 最終更新：2026年8月3日 · 上級者向け
AI執筆者：AI v2

スキーママークアップは、schema.orgの語彙を使用してコンテンツの意味をラベル付けするコードで、検索エンジンがそれを理解し、ページをリッチ結果（レビューの星、商品価格、パンくずリスト）の対象にできるようにします。これは直接のランキング要因ではありません（Googleは繰り返しそう述べています）。また、「スキーママークアップ」（語彙）は「JSON-LD」（それを記述する形式）と混同すべきではありません。3つの形式すべてが機能しますが、JSON-LDが推奨されます。大きな落とし穴は、非推奨のタイプに開発時間を浪費することです。HowToリッチ結果は2023年に廃止され、2025年6月に7つの機能タイプが廃止され、FAQリッチ結果は2026年に非推奨になりました。長年にわたって大規模にこれを行ってきた私のルールは、検索機能が得られる場合、またはエンジンがエンティティ（sameAsを含むOrganization/Person）を識別するのに本当に役立つ場合にのみスキーマを実装することです。マークアップが多いほど自動的に良いというわけではありません。

TL;DR — スキーママークアップは schema.org ボキャブラリ（Google / Microsoft / Yahoo / Yandex の共同作業）を適用してページの意味をラベル付けします。2つの異なる役割があります：リッチリザルトの対象（目に見えるSERP拡張、特定のタイプ+すべての必須プロパティが必要）とエンティティ理解（エンジンとナレッジグラフがあなたが誰/何であるかを識別するのに役立ちます — Organization / Person + sameAs — 目に見えるシグナルはありません）。直接のランキング要因ではありません。ボキャブラリ（スキーママークアップ）と形式（JSON-LD — 推奨、ただしMicrodataとRDFaも機能）を混同しないでください。そして非推奨サイクルに注意してください：HowToリッチリザルトは2023年に終了、7つの機能タイプが2025年6月に廃止、FAQリッチリザルトは2026年に非推奨になりました。私のルール：検索機能を獲得するか、エンティティ理解に本当に役立つ場合にのみスキーマを実装します — マークアップが多いほど自動的に良いわけではありません。

スキーママークアップ vs 構造化データ vs JSON-LD

よく混同される3つの用語を、明確に整理しておきましょう。

  • 構造化データは一般的な概念です。コンテンツを機械が理解できるように注釈を付ける、標準化された方法全般を指します。
  • スキーママークアップは、特にschema.orgの語彙を使用する構造化データです。実際には、この2つは同じ意味で使われることが多いです。
  • JSON-LDは形式であり、マークアップを記述する3つの方法のうちの1つです。これはスキーママークアップの同義語ではありません。同じschema.orgのタイプを、JSON-LD、Microdata、RDFaのいずれでも表現できます。

語彙（schema.org）と形式（JSON-LD）を区別することが、最初に人々がつまずくポイントです。語彙は何を言うかであり、形式はどのように書くかです。

schema.orgとは実際には何か

schema.orgは2011年に立ち上げられ、Google、Microsoft（Bing）、Yahoo、Yandexが共同で維持している共有語彙です。これはタイプ（例：Thing → CreativeWork → Article → NewsArticle）の階層と、各タイプが持つことができるプロパティを定義しています。検索エンジンは語彙について合意し、その後、各エンジンが独自にどのタイプを消費し、どのタイプをリッチリザルトに変換するかを決定します。この最後の点が重要です。schema.orgには、どの単一のエンジンが表示するよりもはるかに多くのタイプがリストされています。 この主張の根拠 A property can be valid in Schema.org without being required, recommended, or consumed for a specific Google rich result. 対象範囲： Schema.org vocabulary compared with Google Search feature requirements. 信頼度： 高 · 検証日： Google: Structured data feature guide

スキーマが果たす2つの役割（そして、なぜ人々は片方しか考えないのか）

ほとんどのガイドはスキーマをリッチリザルトのレバーとして扱い、そこで止まっています。実際には、スキーマは2つの別々のことを行います。

  1. リッチリザルトの対象資格。 サポートされているタイプとその必須プロパティをすべて含めてコンテンツをマークアップすると、あなたのリスティングは、目に見えるSERPの拡張（星、価格、パンくずリスト、レシピカード）の対象になります。これは誰もが追い求める部分です。

  2. コンテンツとエンティティの理解。 Googleは、構造化データを*“ページのコンテンツを理解するため、およびウェブと世界一般に関する情報を収集するために”使用すると述べています。Organization、Person、および類似のタイプは、特にsameAsが権威あるプロフィールを指している場合、エンジンがページがどの*エンティティについてであるかを自信を持って識別し、Knowledge Graphに情報を提供するのに役立ちます。これに対する目に見えるバッジはありません。その利点は理解です。

実際的な結果として、リッチリザルトを生成しないタイプでも、エンティティの理解を明確にするならマークアップする価値があります。Organizationはその典型的な例です。

形式：JSON-LD、Microdata、RDFa

3つすべてがGoogleでサポートされています。JSON-LDが推奨される選択肢であり、その理由は具体的です。

  • これは<script type="application/ld+json">ブロック内にあり、HTMLと混在しないため、ネストされたデータを表現しやすく、テンプレートが変更されても維持しやすいです。
  • Googleは、JSON-LDがJavaScriptやCMSウィジェットによって動的に注入された場合でも読み取ることができます。これはGoogle自身の文書化された動作であり、普遍的なレンダリングの保証ではありません。他の検索エンジンやAIクローラーは、注入されたJSON-LDを異なる方法でレンダリングする（またはレンダリングに失敗する）可能性があるため、実際に気にする各コンシューマーをテストし、同等性を想定しないでください。

MicrodataとRDFaは、HTMLマークアップに織り込まれたインライン属性です。これらはペナルティを受けたり、解析が悪くなったりしません。それは誤解です。ただ、維持が難しいだけです。レガシーCMSや特定のプラットフォームがインラインマークアップを強制する場合にのみ使用してください。

スキーマはランキング要因ではない

これはこのトピックで最も重要な修正点です。Googleの担当者は何年もの間、明確かつ一貫してこの点を述べてきました。正確な発言についてはQuotesレンズを参照してください。Danny Sullivanは構造化データを*“オプション”であり、“ウェブ検索のランキングに影響を与えない”*と呼んでいます。その利点は間接的です。リッチリザルトはクリック率を向上させ、エンティティの理解が向上すると関連性マッチングが容易になります。どちらもマークアップ自体によるランキング向上ではありません。

これこそ、私自身の考え方が常に現実的である理由です。私のAhrefs エンタープライズSEOガイドでは、次のように述べています：「検索機能が得られる限り、スキーママークアップは好きだ」。言い換えれば、リッチリザルトの対象が確認されているタイプ（または明確なエンティティ価値）を優先し、何かを期待してすべてのページにマークアップを散布しないことです。

2026年で最も有用なスキーマタイプ

Googleの検索ギャラリーは、現在リッチリザルトを生成するものの真実の情報源です。時間をかける価値のあるタイプは、おおよそ効果が出る頻度の順に次のとおりです：

  • Product — 価格、在庫状況、レビュー評価。Eコマースにとって最も価値の高いタイプ。
  • Review snippet / AggregateRating — 対象コンテンツの星評価。
  • BreadcrumbList — 生のURLの代わりにパンくずリスト。
  • Article（ニュース/ブログ/スポーツ）— 記事拡張表示の対象。トップニュースは別の、より制限の厳しいサーフェスであり、独自のパブリッシャーとコンテンツポリシー要件があります。Articleマークアップは必要ですが、それだけでページがそこに表示されるわけではありません。
  • Organization — エンティティの確立。パネルに表示されるロゴや詳細情報に反映される可能性がありますが、有効なマークアップがあってもナレッジパネルが表示される保証はありません。エンティティの理解が信頼できる部分であり、パネルやリッチリザルトが表示されなくても機能します。
  • LocalBusiness — ローカルパネルの詳細、営業時間、連絡先情報。
  • Event、Recipe、Job posting、Video (VideoObject)、Q&A、 Software app、Dataset、Discussion forum、Course list — それぞれ特定のギャラリー機能に対応します。

他に何も実装しない場合でも、Organization、BreadcrumbList、および（関連するビジネスの場合）ProductまたはLocalBusinessで、最も効果の高いケースをカバーできます。

非推奨の波 — 廃止されたタイプの実装をやめる

サポートされるセットは実際に変化しており、廃止された機能を追いかけることが開発時間を無駄にする最も一般的な方法です。最近の歴史：

  • 2023年 — HowToリッチリザルトがデスクトップとモバイルから削除。今も数え切れないほどの古いガイドで推奨されていますが、現在は何も得られません。
  • 2025年6月 — 7つの機能タイプが廃止： Book Actions、Course Info（旧形式、Course listに置き換え）、Claim Review、Estimated Salary、Learning Video、Special Announcement、Vehicle Listing。
  • 2026年 — FAQリッチリザルトが非推奨に。 リストの下に表示される展開可能なQ&Aは、ほとんどのサイトで表示されなくなりました。FAQPageスキーマは依然として有効であり、Googleは理解のためにそれを解析し続けますが、誰もが実装したくなる視覚的な拡張はなくなりました。

2026年のラウンドに関するJohn Muellerの見解は正しいものです：「Googleはスキーマを殺しているわけではない…マークアップタイプは移り変わるが、貴重なものはいくつか保持すべきだ」。ここから得られる教訓は「スキーマは死につつある」ではなく、「2021年のチュートリアルではなく、現在のギャラリーに基づいて実装する」です。

エンティティマークアップとナレッジグラフ

リッチリザルトを超えて、スキーマはエンジンがあなたのエンティティを曖昧さなく認識するのを助ける方法です。あなたの「Apple」が果物ではなく会社であること、あなたの著者が特定の実在の人物であることを確実にします。その仕組みは**sameAs**プロパティです。OrganizationまたはPersonマークアップを、Wikipedia、Wikidata、LinkedIn、Crunchbase、公式ソーシャルプロフィールなどの信頼できる識別子にポイントさせます。

正しく行えば、これはナレッジグラフに反映され、検索エンジン（そしてその先のAIシステム）があなたをどれだけ自信を持って認識するかを強化します。不注意に行うと逆効果になります：間違ったWikipediaページや別の会社のプロフィールを指すsameAsは、エンジンが無関係なエンティティを混同する原因になります。sameAsの値は、canonicalをテストするのと同じくらい注意深くテストしてください。

各エンティティを一度宣言し、同じエンティティの部分的なバージョンを繰り返す代わりに、安定した`@id`参照でグラフを接続します。

組織はWebサイトとWebページに接続します。WebサイトとWebページは記事に接続します。この図は、組織、Webサイト、Webページ、および記事がそれぞれ1つの安定したat-idを持ち、他のエンティティがそれを参照することを強調しています。

スキーマとAI検索 — 正しい期待

スキーマは、AI引用のてことして売り込まれることがよくあります。しかし、直接的な効果はありません。LLMはあなたのJSON-LDを確実に解析して引用で報いてくれるわけではありません。大規模な調査では、スキーマのカバレッジによるAI引用の有意な向上は見られませんでした。スキーマが実際に行うのは、上記で説明したのと同じエンティティ理解の仕事であり、それにも注意点があります。Googleは、Organization/Person + sameAsがGoogle自身のナレッジグラフと検索理解に供給されることを文書化しています。他のAIプロバイダーがその同じエンティティシグナルにどの程度依存しているかは、プロバイダー固有の質問であり、どのベンダーも保証として文書化していません。クロスプロバイダーのAI引用メリットは、未検証の仮説として扱い、スキーマが単独で提供する実装メリットとしては扱わないでください。これは、Google自身のシステムのためのエンティティ基盤であり、普遍的な引用スイッチではありません。この角度については、Schema Markup for AIで詳しく説明しています。これは、この記事（語彙、型、実装）とは異なる質問（引用向上）です。

実装の優先順位

ゼロから始める場合は、次の順序で行います。

  1. Organization（サイト全体）に正確なname、logo、url、検証済みの sameAsを含める — エンティティの基盤。
  2. **BreadcrumbList**をテンプレート化されたページに — 安価で、広く対象となり、リスティングが向上します。
  3. Product（eコマース）または**LocalBusiness**（ローカル） — 最も価値の高いビジネス固有の型。
  4. **Article**を編集コンテンツに。
  5. その後にのみ、確認済みの現在のギャラリー機能に対応するニッチな型。

Googleのガイドラインからの2つの譲れない点：ページに表示されているコンテンツのみをマークアップすること、そして、すべての可能なプロパティを不正確に入力するよりも、*「少ないが完全で正確な」*必須プロパティを優先すること。

公開前に検証する

  • リッチリザルトテスト — リッチリザルトを生成する型向け。対象資格と必須プロパティのエラーがわかります。
  • Schema Markup Validator — リッチリザルトを生成しない型を含む、あらゆるschema.orgの型向け。 この主張の根拠 Google recommends validating feature eligibility with the Rich Results Test and broader schema syntax with Schema.org tooling. 対象範囲： Google Search deployment workflow; passing a validator does not guarantee display. 信頼度： 高 · 検証日： Google: Structured data introduction
  • Google Search Consoleのリッチリザルトレポート — デプロイ後に大規模な対象資格とエラーを監視します。
  • Ahrefs Site Audit — サイト全体の構造化データの問題をフラグします。

必須プロパティのエラーがあると、そのページは対応するリッチリザルトの対象外になります。推奨プロパティの欠落は通常許容されます。検証してからデプロイしてください。逆順ではありません。

レイヤーを正しく区別してください。1つを通過しても次を通過するとは限りません。有効なマークアップ（バリデータがエラーなく解析）→ サポートされている語彙（schema.orgが型を認識）→ 機能サポート（Googleのギャラリーが現在一致するリッチリザルトを文書化）→ 対象資格（すべての必須プロパティが存在し、ポリシーに準拠）→ インデックス（ページがそもそもインデックスされている）→ 表示（Googleが拡張を表示することを選択）→ ランキング（上記のいずれにも影響されない）。緑のバリデータは最初のステップのみを証明します。

これが全体像の中でどこに位置するかについては、この記事が属するより広範な構造化データハブを参照してください。

専門家メモを追加

専門家の引用を固定

新しい人物ですか？まず、 /admin/experts/ → 専門家の引用を固定 から未登録プロフィールを作成してください。