ファクトチェック（`ClaimReview`）の構造化データ

他者の主張を評価するウェブページがある場合は、そのウェブページに ClaimReview 構造化データを追加できます。ClaimReview 構造化データを使用すると、該当する主張の Google 検索結果に自分のページが表示されたときに、Google 検索結果にファクトチェックの概要版を表示できます。

このガイドでは、ClaimReview 構造化データの実装方法について詳しく説明します。手動で構造化データを追加したくない場合は、ファクトチェックマークアップツールを使用できます。詳細については、ファクトチェックマークアップツールをご覧ください。

構造化データを追加する方法

構造化データは、ページに関する情報を提供し、ページコンテンツを分類するための標準化されたデータ形式です。構造化データを初めて使用する場合は、構造化データの仕組みについてをご覧ください。

構造化データの作成、テスト、リリースの概要は次のとおりです。ウェブページに構造化データを追加するための手順ガイドについては、構造化データの Codelab をご覧ください。

必須プロパティを追加します。使用している形式に基づいて、ページ上の構造化データを挿入する場所をご確認ください。
CMS をお使いの場合は、CMS に統合されているプラグインを使用する方が簡単な場合もあります。
JavaScript をお使いの場合は、JavaScript で構造化データを生成する方法をご確認ください。
ガイドラインに従います。
リッチリザルトテストでコードを検証し、重大なエラーを修正します。ツールで報告される重大ではない問題の修正も検討してください。構造化データの品質向上に役立ちます（ただし、リッチリザルトの対象となるために必ずしも必要というわけではありません）。
構造化データが含まれているページを数ページ導入し、URL 検査ツールを使用して、Google でページがどのように表示されるかをテストします。Google がページにアクセスでき、robots.txt ファイル、noindex タグ、ログイン要件によってページがブロックされていないことを確認します。ページが正常に表示されたら、Google に URL の再クロールを依頼できます。
注: 再クロールとインデックスの再登録にかかる時間を考慮してください。ページを公開した後、Google がそのページを検出してクロールするまで数日かかる場合があることにご注意ください。
今後の変更について Google に継続して情報を提供するために、サイトマップを送信することをおすすめします。これは、Search Console Sitemap API で自動化できます。

例

「地球は平らである」という主張を評価するページがあるとします。このページに ClaimReview 要素が追加されている場合、Google 検索で「地球は平らである」を検索すると結果に次のように表示されます（実際の表示とは異なる可能性があります）。

次は、このファクトチェックをホストするページに設定した構造化データの例です。

<html>
  <head>
    <title>The world is flat</title>
    <script type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@type": "ClaimReview",
      "url": "https://example.com/news/science/worldisflat.html",
      "claimReviewed": "The world is flat",
      "itemReviewed": {
        "@type": "Claim",
        "author": {
          "@type": "Organization",
          "name": "Square World Society",
          "sameAs": "https://example.flatworlders.com/we-know-that-the-world-is-flat"
        },
        "datePublished": "2024-06-20",
        "appearance": {
          "@type": "OpinionNewsArticle",
          "url": "https://example.com/news/a122121",
          "headline": "Square Earth - Flat earthers for the Internet age",
          "datePublished": "2024-06-22",
          "author": {
            "@type": "Person",
            "name": "T. Tellar"
          },
          "image": "https://example.com/photos/1x1/photo.jpg",
          "publisher": {
            "@type": "Organization",
            "name": "Skeptical News",
            "logo": {
              "@type": "ImageObject",
              "url": "https://example.com/logo.jpg"
            }
          }
        }
      },
      "author": {
        "@type": "Organization",
        "name": "Example.com science watch"
      },
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": 1,
        "bestRating": 5,
        "worstRating": 1,
        "alternateName": "False"
      }
    }
    </script>
  </head>
  <body>
  </body>
</html>

<html>
  <head>
    <title>The world is flat</title>
    <script type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@type": "ClaimReview",
      "url": "https://example.com/news/science/worldisflat.html",
      "claimReviewed": "The world is flat",
      "itemReviewed": {
        "@type": "Claim",
        "author": {
          "@type": "Organization",
          "name": "Square World Society",
          "sameAs": "https://example.flatworlders.com/we-know-that-the-world-is-flat"
        },
        "datePublished": "2024-06-20",
        "appearance": {
          "@type": "OpinionNewsArticle",
          "url": "https://example.com/news/a122121",
          "headline": "Square Earth - Flat earthers for the Internet age",
          "datePublished": "2024-06-22",
          "author": {
            "@type": "Person",
            "name": "T. Tellar"
          },
          "image": "https://example.com/photos/1x1/photo.jpg",
          "publisher": {
            "@type": "Organization",
            "name": "Skeptical News",
            "logo": {
              "@type": "ImageObject",
              "url": "https://example.com/logo.jpg"
            }
          }
        }
      },
      "author": {
        "@type": "Organization",
        "name": "Example.com science watch"
      },
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": 1,
        "bestRating": 5,
        "worstRating": 1,
        "alternateName": "False"
      }
    }
    </script>
  </head>
  <body>
  </body>
</html>

資格に関するガイドライン

リッチリザルトテストに従ってページを正しくマークアップしても、ファクトチェックが検索結果に表示される保証はありません。構造化データを使用して、ある機能が表示されるように設定することは可能ですが、必ず表示されるとは限りません。Google のアルゴリズムは、ファクトチェックがリッチリザルトに表示される資格を、さまざまな要因に応じてプログラムで判断します。この要因には下記のガイドラインが含まれます。

ファクトチェックのコンテンツが Google 検索にファクトチェックのリッチリザルトとして表示される資格を得るには、以下のガイドラインに従う必要があります。

サイト内に ClaimReview 構造化データでマークされたページが複数あることが必要です。
すべての構造化データのガイドラインと検索の基本事項に従っている必要があります。
構造化データとページコンテンツの間に不一致（たとえば、構造化データは主張が正しいとしており、ページ上のコンテンツでは主張は誤りであると記述している）がないようにします。不一致がある場合は、コンテンツと構造化データを一致させる必要があります（たとえば、両方で主張が正しいと示します）。
Google ニュースの一般的なガイドラインに規定されている、説明責任、透明性、読みやすさ、サイトの不実表示に関する基準を満たす必要があります。
修正ポリシーか、ユーザーが誤りを報告するための仕組みが必要です。
政治団体のウェブサイト（政治活動、政党、公選された役職者のサイトなど）は、この機能の対象外となります。
読者が記事の本文内で主張と主張の根拠を容易に区別できることが必要です。どのような根拠に基づいてどのような結論に至ったかを読者が理解できなければなりません。
特定の主張を評価する場合は、それがウェブサイト、公開声明、ソーシャルメディア、またはその他の追跡可能な出典元であるかどうかに関わらず、自身のウェブサイト以外の主張者の出典元を明確に示す必要があります。
ファクトチェック分析が情報源と方法について追跡可能性と透明性を有し、一次ソースを引用および参照していることが必要です。

技術に関するガイドライン

単一のファクトチェックのリッチリザルトの対象となるには、1 つのページに 1 つの ClaimReview 要素のみを含める必要があります。1 つのページに複数の ClaimReview 要素を追加すると、そのページは単一のファクトチェックのリッチリザルトの対象にはなりません。
ClaimReview 要素をホストするページには、少なくともファクトチェックと評価の簡単な要約を含める必要があります（全文を含めない場合）。
特定の ClaimReview をサイト上の 1 つのページのみに追加したら、同じファクトチェックを複数のページに繰り返し追加しないでください。ただし、同じページのバリエーションである場合は追加可能です（たとえば、あるページのモバイル版とパソコン版には同じ ClaimReview を追加できます）。
ファクトチェック記事を集めたウェブサイトの場合は、すべての記事が基準を満たすこと、ファクトチェックを集めた全ウェブサイトの公開リストを指定することが必要です。

構造化データタイプの定義

ファクトチェックを実装するには、次の構造化データタイプが必要です。

ClaimReview
Claim
Rating

コンテンツがリッチリザルトとして表示されるようにするには、必須プロパティを含める必要があります。また、推奨プロパティを使用することでコンテンツに関する詳細情報を追加でき、ユーザーエクスペリエンスの向上につながります。

`ClaimReview`

ClaimReview の定義の全文は schema.org/ClaimReview で確認できます。Google がサポートするプロパティは、次のとおりです。

必須プロパティ

必須プロパティ
`claimReviewed`	`Text` 評価された主張の簡単な要約。モバイルデバイスでの表示の際に折り返しを最小限に抑えるため、半角 75 文字（全角 37 文字）未満になるようにしてください。 `claimReviewed` フィールドには評価を含めないでください。代わりに、`reviewRating` フィールドに評価を含めます。
`reviewRating`	`Rating` 主張の評価。このオブジェクトでは数値とテキストの両方の評価がサポートされます。現時点では、検索結果に表示される値はテキスト値のみです。複数のファクトチェックプロジェクトで評価スキームが異なると、特に中間値に関して若干の違いが生じる場合があります。評価スキームを文書化して、数値評価の意味を明確にすることが重要です。最低でも、数値スコアを扱うすべてのファクトチェックで数値とテキストの評価が一致するシステムを作成する必要があります。 1 = 「誤り」 2 = 「概ね誤り」 3 = 「半分は真実」 4 = 「概ね真実」 5 = 「真実」詳細については、Rating をご覧ください。
`url`	`URL` ファクトチェックの記事全文をホストするページへのリンク。この URL のドメインの値は、この `ClaimReview` 要素をホストするページと同じドメインであるか、そのサブドメインである必要があります。リダイレクトや短縮 URL（g.co/searchconsole など）は解決されないため、ここでは機能しません。

claimReviewed

Text

評価された主張の簡単な要約。モバイルデバイスでの表示の際に折り返しを最小限に抑えるため、半角 75 文字（全角 37 文字）未満になるようにしてください。

claimReviewed フィールドには評価を含めないでください。代わりに、reviewRating フィールドに評価を含めます。

reviewRating

Rating

主張の評価。このオブジェクトでは数値とテキストの両方の評価がサポートされます。現時点では、検索結果に表示される値はテキスト値のみです。

複数のファクトチェックプロジェクトで評価スキームが異なると、特に中間値に関して若干の違いが生じる場合があります。評価スキームを文書化して、数値評価の意味を明確にすることが重要です。最低でも、数値スコアを扱うすべてのファクトチェックで数値とテキストの評価が一致するシステムを作成する必要があります。

1 = 「誤り」
2 = 「概ね誤り」
3 = 「半分は真実」
4 = 「概ね真実」
5 = 「真実」

詳細については、Rating をご覧ください。

url

URL

ファクトチェックの記事全文をホストするページへのリンク。

この URL のドメインの値は、この ClaimReview 要素をホストするページと同じドメインであるか、そのサブドメインである必要があります。リダイレクトや短縮 URL（g.co/searchconsole など）は解決されないため、ここでは機能しません。

推奨プロパティ

author

Organization または Person

ファクトチェック記事の公開元（主張の公開元ではありません）。author には組織または担当者を指定する必要があります。author に対して少なくとも次のいずれかのプロパティを指定します。

name

Text

ファクトチェックを公開する組織の名前。

url

URL

ファクトチェックの公開元の URL。ホームページ、問い合わせページなど、適切なページを指定できます。

さまざまな記事の作成者を Google ができる限り正しく認識できるように、作成者のマークアップのベストプラクティスを実践することを検討してください。

itemReviewed

Claim

該当の主張を記述するオブジェクト。詳細については、Claim をご覧ください。

下位互換性: Google 検索では、ファクトチェックの初回リリース時に CreativeWork を itemReviewed としておすすめしていました。以前のマークアップパターンは、Google 検索で引き続きサポートされます。次の例は、元のマークアップスタイルを示しています。

`Claim`

Claim の定義の全文は schema.org/Claim で確認できます。

推奨プロパティ

appearance

URL または CreativeWork

この主張が表示される CreativeWork へのリンク、またはインラインの説明。

appearance または firstAppearance のいずれかを追加することをおすすめします。両方を追加する必要はありません。

author

Organization または Person

主張者（ファクトチェックの実施者ではありません）。主張者がいない場合は、author プロパティを含めないでください。author を追加する場合は、以下のプロパティを定義してください。

name

Text（必須）

主張の公開元。公開元は個人または組織です。

sameAs

URL（推奨）

当事者が Person か Organization かにかかわらず、主張元の当事者を示します。複数の公開元が同じ主張について報告する場合は、appearance プロパティを繰り返し使用することが可能です。複数の当事者が本質的に同じ主張を行っているときは、author プロパティを繰り返し使用することが可能です。

次の URL のいずれかを使用します。

主張を行っている組織のホームページ。
個人または組織の Wikipedia または Wikidata エントリなど、主張を行っている当事者に関する情報を提供する明確な URL。

datePublished

DateTime または Date

主張を行った日付または主張が一般の話題になった日付（たとえば、ソーシャルネットワークで話題になった日付など）。

firstAppearance

URL または CreativeWork

この主張が最初に行われた CreativeWork へのリンク、またはインラインの説明。

appearance または firstAppearance のいずれかを追加することをおすすめします。両方を追加する必要はありません。

`Rating`

Rating の定義の全文は schema.org/Rating で確認できます。

必須プロパティ

必須プロパティ
`alternateName`	`Text` `ClaimReview.reviewRating` に割り当てる真実度の評価を、短い語句のテキストで読みやすいように示します。この値が検索結果内のファクトチェックに表示されます。例: 「真実」、「概ね真実」。長文を使用する場合は、文の末尾がディスプレイに合わせて切り捨てられる場合に備え、文の先頭で評価の意味を示すようにします。例: 「細部は概ね真実だが、主張全体では若干誤解を招く」

alternateName

Text

ClaimReview.reviewRating に割り当てる真実度の評価を、短い語句のテキストで読みやすいように示します。この値が検索結果内のファクトチェックに表示されます。例: 「真実」、「概ね真実」。

長文を使用する場合は、文の末尾がディスプレイに合わせて切り捨てられる場合に備え、文の先頭で評価の意味を示すようにします。例: 「細部は概ね真実だが、主張全体では若干誤解を招く」

推奨プロパティ
`bestRating`	`Number` 数値による評価で、最低から最高までの範囲で選択可能な最大値。`worstRating` より大きい値を入力してください。数値として評価できる必要があります。例: 4
`name`	`Text` `alternateName` と同じで、`alternateName` が指定されていないときに使用されます。ただし、`name` より `alternateName` を使用することをおすすめします。
`ratingValue`	`Number` この主張の数値による評価で、`worstRating`～`bestRating` の範囲。整数値が推奨されますが、必須ではありません。この数値が `bestRating` に近いほど真実度が高く、`worstRating` に近いほど誤りである可能性が高くなります。数値による評価は、数値として評価できる必要があります。例: 4
`worstRating`	`Number` 数値による評価で、最低から最高までの範囲で選択可能な最小値。`bestRating` 未満で指定してください。数値として評価できる必要があります。最小値は 1 である必要があります。例: 1

Search Console でリッチリザルトを監視する

Search Console は、Google 検索におけるページのパフォーマンスを監視できるツールです。Search Console に登録していなくても Google 検索結果に表示されますが、登録することにより、Google がサイトをどのように認識しているかを把握して改善できるようになります。次の場合は Search Console を確認することをおすすめします。

構造化データを初めてデプロイした後
新しいテンプレートをリリースした後やコードを更新した後
トラフィックを定期的に分析する場合

構造化データを初めてデプロイした後

ページがインデックスに登録されたら、関連するリッチリザルトのステータスレポートを使用して、問題がないかどうかを確認します。有効な項目が増え、無効な項目が増えていない状態が理想的です。構造化データに問題が見つかった場合の手順は次のとおりです。

無効な項目を修正します。
一般公開 URL の検査を行い、問題が解決したかどうかを確認します。
ステータスレポートを使用して検証をリクエストします。

新しいテンプレートをリリースした後やコードを更新した後

ウェブサイトに大幅な変更を加えた場合は、構造化データの無効な項目が増加しないかどうか監視します。

無効な項目が増加した場合は、新しく公開したテンプレートが正常に機能していないか、既存のテンプレートの新しい操作方法に問題があると考えられます。
有効な項目が減少している（無効な項目の増加と一致しない）場合は、ページに構造化データが埋め込まれていない可能性があります。URL 検査ツールを使用して問題の原因を特定します。

トラフィックを定期的に分析する場合

パフォーマンスレポートを使用して Google 検索のトラフィックを分析します。このデータから、検索でページがリッチリザルトとして表示される頻度、ユーザーがページをクリックする頻度、検索結果におけるページの平均掲載順位がわかります。この結果は、Search Console API を使用して自動的に取得することもできます。

トラブルシューティング

構造化データの実装またはデバッグで問題が発生した場合は、以下のリソースが参考になります。

コンテンツ管理システム（CMS）を使用している場合や、サイトが他者によって管理されている場合は、それに応じて支援を依頼してください。その際は、問題の詳細を含む Search Console のメッセージを必ず転送してください。
構造化データを使用するコンテンツが必ず検索結果に表示されるとは限りません。コンテンツがリッチリザルトに表示されないときのよくある原因については、構造化データに関する一般的なガイドラインをご覧ください。
構造化データにエラーがある可能性があります。構造化データエラーの一覧を確認してください。
構造化データへの手動による対策をページに対して実施すると、ページ上の構造化データが無視されるようになります（ただし、Google 検索結果にはページは引き続き表示されます）。構造化データの問題を修正するには、手動による対策レポートを使用します。
ガイドラインを再度確認し、コンテンツがガイドラインを遵守していないことを確認します。スパムコンテンツまたはスパムマークアップの使用が原因で、問題が発生する場合がありますが、これは構文の問題ではない可能性があり、リッチリザルトテストでは特定できません。
リッチリザルトが見つからない場合またはリッチリザルトの合計数が不足している場合のトラブルシューティングをご覧ください。
再クロールとインデックスの再登録に要する時間を考慮してください。ページを公開した後、Google が対象のページを検出してクロールするまでに数日を要する場合があることに留意してください。クロールとインデックス登録に関する一般的な質問については、Google 検索のクロールとインデックス登録に関するよくある質問をご覧ください。
Google 検索セントラルフォーラムでもご質問をお受けしています。

ファクト チェック（ClaimReview）の構造化データ

構造化データを追加する方法

例

資格に関するガイドライン

技術に関するガイドライン

構造化データタイプの定義

ClaimReview

Claim

Rating

Search Console でリッチリザルトを監視する

構造化データを初めてデプロイした後

新しいテンプレートをリリースした後やコードを更新した後

トラフィックを定期的に分析する場合

トラブルシューティング

ファクトチェック（`ClaimReview`）の構造化データ

`ClaimReview`

`Claim`

`Rating`