SEOにおけるエンティティは、生成AIやAIによる概要が広がる検索で重要性を増しています。キーワードとの違いから、自社で実行できる対策と確認方法までを解説します。
エンティティとは
エンティティとは、文字列そのものではなく、人・場所・組織・概念のように一意に識別できる意味を持つ実体です。Googleは検索エンジンの中で各エンティティを固有のIDで管理し、その属性や他のエンティティとの関係性とあわせて理解しています。検索のクエリやWebページに含まれる単語を、単なる文字の並びではなく意味のある実体として結びつけることで、検索結果の精度を高めています。
キーワードとエンティティの違い
キーワードSEOは、検索クエリと同じ文字列をページ内に一致させる発想です。これに対してエンティティを軸にしたSEOは、文字列の一致ではなく、意味と文脈からそのページが何者を扱っているのかを検索エンジンに理解させる発想です。同じ綴りでも文脈によって対象が変わる同名異人や多義語のケースで、エンティティは対象の曖昧さを解消する役割を担います。両者の違いを整理すると次のとおりです。
| 観点 | キーワードSEO | エンティティを軸にしたSEO |
|---|---|---|
| 狙い | 文字列の一致 | 意味と文脈による理解 |
| 評価の単位 | 文字列 | 意味を持つ実体 |
| 曖昧さへの対応 | 区別しにくい | 同名異人や多義語を区別できる |
IT・データベース分野のエンティティとの違い
エンティティという語は、データベースやプログラミングの分野でも、管理する対象を表す用語として使われます。検索で関連語を見るとIT分野やデータベース分野の語が多く混在するため、調べる目的を取り違えやすい語です。本記事で扱うエンティティは、あくまで検索エンジンが扱う意味を持つ実体を指し、データベース設計の用語とは別物として読み進めてください。
Googleがエンティティを認識する仕組み
検索エンジンがエンティティをどう認識しているかを押さえておくと、どの対策が自社の評価に効くのかを判断しやすくなります。ここでは認識の仕組みの全体像を解説します。
ナレッジグラフとエンティティの関係
ナレッジグラフは、エンティティ同士を属性や関係でつないだ知識のデータベースです。Googleはエンティティと、その属性や他のエンティティとの関係を蓄積し、検索結果やナレッジパネルに表示する情報の根拠として用いています。あるサイトやその運営者がナレッジグラフ上のエンティティとして結びつくほど、検索エンジンは対象を正確に把握しやすくなります。
エンティティの抽出と認識のプロセス
Googleは、クロールしたページの文章から人や組織などの実体を抽出して認識します。このとき構造化データで実体を明示しておくと、検索エンジンはマークアップに含まれる人物や会社などの情報を、エンティティとして直接収集できます。文章からの抽出に頼るだけでなく、構造化データで主体を明示しておくことが、認識の精度を高める手がかりです。
文脈による意味のつながりの理解
検索エンジンが重視するのは、単語の羅列ではなく、情報同士の意味のつながりです。誰が何を提供し、それがどのエンティティと関係するのかを、関係性のある文章で示すことが、文脈を正しく伝える鍵になります。固有名詞と関連情報を結びつけて書くことで、ページの主題が検索エンジンに伝わりやすくなります。
エンティティがSEO評価につながる理由
エンティティとして認識されることは、検索での評価や見え方にいくつかの面で関係します。ここでは主なメリットを整理します。
E-E-A-Tの評価に結びつく
運営者や著者が何者であるかを明確にすることは、経験・専門性・権威性・信頼性(E-E-A-T)を評価する材料になり得ます。E-E-A-Tは、主体がエンティティとして認識されてはじめて、その実体に結びついて評価されるものです。著者情報や運営組織を曖昧にせず示すことが、コンテンツの信頼性を伝える土台になります。
ナレッジパネルに表示されやすくなる
ナレッジパネルは、検索結果に表示されるエンティティの概要情報をまとめたパネルです。対象がエンティティとして認識されると、その情報がナレッジパネルに表示されやすくなります。表示は検索エンジンの判断によるため必ず表示されるとは限らず、この点は後述の注意点で扱います。
AIによる概要や生成AIに引用されやすくなる
誰が何を提供しているかが明確なエンティティ情報は、AIによる概要や生成AIの回答で参照されやすくなる傾向があります。出典や主体がはっきりした情報源は、主要な生成AIに共通して参照の対象になりやすいといえるでしょう。確実な引用を保証するものではありませんが、実体を明確に示しておくことが参照される可能性を広げます。
エンティティを最適化する具体的な対策
ここからは、自社の情報をどうマークアップして検索エンジンに渡すかという具体策を扱います。構造化データの種類の一覧は次章でまとめるため、本章では実装の考え方に絞ります。
構造化データでエンティティ情報を伝える
構造化データは、ページの情報を標準化して検索エンジンに伝え、内容の理解を助ける形式です。形式はJSON-LD(推奨)・microdata・RDFaの3つがあり、Googleが解釈できる形でエンティティ情報を渡せます。PersonやOrganization、Articleなどをマークアップすることで、運営者や著者、コンテンツの実体を検索エンジンに直接伝えられます。
PersonとOrganizationで運営者と著者を示す
運営者や著者をPersonまたはOrganizationでマークアップすると、誰が運営し誰が執筆しているかというエンティティの核を明確にできます。プロフィールページの構造化データでも、ページの主対象となる実体としてPersonまたはOrganizationを指定します。こうして主体を構造化データで示すことが、エンティティ最適化の出発点です。
sameAsで外部の公式情報と関連付ける
sameAsプロパティに列挙するのは、公式サイトや公式SNSなど、外部にあるプロフィールのURLです。これにより、それらが同一のエンティティを指していることを検索エンジンに示せます。複数の外部情報源と結びつけることで、主体の実在性や同一性が伝わりやすくなります。
固有名詞で誰が何をしているかを明確にする
固有名詞や専門用語を曖昧なまま使わず、誰が何を提供しているのかを具体的に書きます。関連するエンティティ同士の関係を文章で明示することで、検索エンジンはページの主題を取り違えにくくなります。代名詞や省略に頼らず、主体と対象を言い切る書き方が有効です。
サイテーションと被リンクで外部からの言及を増やす
公式SNSや外部メディア、Googleビジネスプロフィールなどと連携し、信頼できる外部からの言及や被リンクを増やすことは、主体の認知を広げる施策です。サイテーションを増やす手段としては、プレスリリースや寄稿、登壇、受賞などの機会が挙げられます。これらは外部からの言及を生むきっかけであり、広報の進め方そのものは本記事の範囲外として扱います。
内部リンクでサイト内の関係性を示す
関連するページ同士を内部リンクでつなぐと、サイト内のエンティティの関係構造を検索エンジンに伝えられます。著者ページとその執筆記事、サービスページと関連事例をリンクで結ぶことで、主題と関連情報の結びつきが明確になります。内部リンクは、サイト全体で扱うエンティティの文脈を補強する手段です。
WikipediaやWikidataと情報を整合させる
WikipediaやWikidataは、エンティティの参照源として扱われることがある外部の情報源です。ただし掲載には基準があり、誰でも載るわけではありません。掲載が難しい場合は、公式サイトや外部メディアなど他の信頼できる外部からの言及で情報を整合させる方針が現実的です。なお、掲載を狙った働きかけは各サービスの方針に反するため行いません。
エンティティを示すのに使える構造化データの種類
エンティティを検索エンジンに示すために使えるリッチリザルトには、いくつかの種類があります。なかでもプロフィールページのmainEntityはPersonやOrganizationそのものであり、前章で触れた主体のマークアップと役割が重なります。自社で実行しやすいProfilePageやPerson、Organizationを中心に、主な種類と要件を次の表に整理しました。
| 種類 | 対象エンティティ | 押さえるポイント |
|---|---|---|
| プロフィールページ(ProfilePage) | Person/Organization | 必須プロパティmainEntityに主体を指定。著者ページや会社紹介ページ向け |
| クチコミ抜粋(Review・AggregateRating) | Product・Bookなど | ユーザーから直接入手した評価が対象。自社・自店そのものの自己管理レビューは対象外 |
| カルーセル | 各種エンティティ | ベータ提供で、対象地域が限定 |
| バリエーション商品 | ProductGroup・Product | hasVariantでバリエーションを表現 |
| 書籍アクション(Book) | Book | 利用できる提供者が限定 |
プロフィールページ
プロフィールページの構造化データは、個人または組織のプロフィールを示すマークアップです。必須プロパティのmainEntityにPersonまたはOrganizationを指定し、そのページの主対象がそのエンティティに関する情報であることを示します。著者ページや会社の紹介ページで、主体を明確に示したい場合に適しています。
クチコミ抜粋
クチコミ抜粋の構造化データは、評価をエンティティに紐づけ、星付きのリッチリザルトとして表示できる種類です。対象となる評価は、ユーザーから直接入手したものに限られます。ProductやBookなどのエンティティなら、自社サイトで集めたレビューでも星の対象になります。一方、LocalBusinessやOrganizationのように自社や自店そのものを対象とし、その評価を自ら管理しているページは対象外です。
カルーセルや商品、書籍などその他の構造化データ
このほかにも、扱う対象に応じた種類があります。いずれも対象地域や利用できる提供者などの条件が限定されるため、上の表で要件を確認し、自社で実行できる範囲から取り入れてください。
業種・サイト規模別に優先したいエンティティ対策
対策は一律ではなく、サイトの種類によって取り組みやすさや優先度が変わります。最初に着手しやすい施策を対象別に整理すると、次のとおりです。
| サイトの種類 | 優先したい対策 |
|---|---|
| BtoB・コーポレートサイト | OrganizationとPersonで運営組織と著者を明示 |
| ECサイト | ProductGroup・Product・Reviewなど商品・レビュー系を整備 |
| ローカルビジネス | LocalBusinessの整備と外部プロフィールの表記統一 |
| 個人サイト・専門ブログ | 著者個人のProfilePageとsameAsを整備 |
BtoB・コーポレートサイトはOrganizationと著者情報を優先する
BtoBやコーポレートサイトでは、運営組織と著者をOrganizationとPersonで明示することを優先します。会社という主体を構造化データで示し、指名検索やサイテーションの土台を整えることが、エンティティとしての認知につながります。
ECサイトは商品・レビュー系の構造化データを優先する
ECサイトでは、扱う商材のエンティティ表現に直結するProductGroupやProduct、Reviewなどから着手します。商品単位の実体と評価を検索エンジンに伝えることが、検索結果での見え方の改善につながります。
ローカルビジネスはLocalBusinessと外部プロフィールの一貫性を優先する
店舗や地域密着の事業では、LocalBusinessの整備と、Googleビジネスプロフィールなど外部情報との表記の一貫性を優先します。名称や住所などの情報をそろえることで、検索エンジンが同一の実体と判断しやすくなります。
個人サイト・専門ブログはProfilePageとsameAsを優先する
個人サイトや専門ブログでは、著者個人のProfilePageとsameAsを優先します。誰が書いているかを明確にし、外部の公式プロフィールと結びつけることが、著者というエンティティの信頼性を支えます。
自社ツールでエンティティ対策の実装と効果を確認する
構造化データは実装して終わりではなく、正しく入っているかの確認と、その後の変化の観察まで行うと精度が高まります。公開前のチェックにはkunugi SEO Checkerが使え、変化の観察を補助するツールもあります。
kunugi SEO Checkerで構造化データの実装を確認する
kunugi SEO Checkerは、閲覧中のWebページの情報を、サイドパネルに集約して表示できるChrome拡張機能です。
構造化データタブでJSON-LD・microdata・RDFaの個数を確認でき、URLを入力済みのリンクからリッチリザルトテストへ移動して検証できます。あわせてtitle・H1・canonicalなどの基礎項目も一画面で確認できるため、エンティティ情報の実装漏れに気づけます。
kunugi GSC Controllerで指名検索の確認を効率化する
kunugi GSC Controllerは、Google Search Consoleの検索パフォーマンス画面を、サイドパネルから素早く操作できるChrome拡張機能です。
ブランド名や固有名詞のクエリと、前年比較や曜日を合わせた比較期間を設定し、検索パフォーマンス画面をワンクリックで開けます。
kunugi SERP CacheでSERPの変化とAIによる概要の有無を定点観測する
kunugi SERP Cacheは、Googleの検索結果画面(SERP)のうち、上位10件を手動でキャッシュ保存し、日付の異なるデータを表形式で並べて比較できるChrome拡張機能です。
保存できるのは順位・URL・タイトル・ディスクリプションで、メモ機能を使えばAIによる概要の有無などを手動で記録できます。AIによる概要やナレッジパネルの内容そのものを自動で取得するものではないため、手動メモと組み合わせて定点観測の補助として使います。
エンティティ対策で陥りやすい失敗と注意点
エンティティ対策では、公式情報の前提を取り違えると手戻りが生じます。ここでは陥りやすい失敗を、正しい前提とあわせて整理します。
構造化データを実装しても表示が保証されるわけではない
構造化データを正しく実装しても、リッチリザルトやナレッジパネルの表示が保証されるわけではありません。検索エンジンは検索履歴や位置情報などの要因に応じて表示を調整するため、テストに合格しても表示されないことがあります。また、公開後の再クロールや再インデックスには時間がかかり、ガイドライン違反や手動による対策があると表示の対象外になり得ます。
自社・自店そのものへの自己管理レビューはスター表示の対象外
対象外になるのは、LocalBusinessやOrganizationのように自社や自店そのものを対象とし、その評価を自ら管理しているレビューです。ProductやBookなどのエンティティは、自社サイトで集めたレビューでも星の対象になります。自社レビューが一律で対象外になるわけではない点を区別して扱います。
schema.orgにあってもGoogleが未対応のプロパティは反映されない
Googleはschema.orgのボキャブラリーをベースに構造化データを解釈しますが、schema.orgに定義があってもGoogleがサポートしていないプロパティは、リッチリザルトなどの検索結果には反映されません。まずGoogle検索セントラルのドキュメントを確認し、Googleが提示する必須プロパティを漏れなく実装することが、エンティティを正しく伝える手段になります。競合記事の記述をそのまま採用せず、公式の対応範囲を基準にします。
ナレッジパネルの表示を促し情報の誤りを修正する手順
ナレッジパネルは表示を促すだけでなく、表示後に情報の誤りを修正する手順まで押さえておくと運用しやすくなります。ここでは発信側でできる準備と、誤りがある場合の対応を扱います。
名称や肩書を一貫して発信する
公式サイトやSNS、外部メディアでは、名称や肩書、説明を表記ゆれなく一貫して発信します。同じ情報をそろえて発信することで、検索エンジンが同一のエンティティと判断しやすい状態をつくれます。逆に表記の不一致は、別の実体と認識される一因です。
ナレッジパネルの情報に誤りがある場合の修正を提案する
ナレッジパネルに誤った情報がある場合は、対象者本人または正式な代表者として変更を提案できます。手順としては、Googleアカウントで本人確認(認証)を行ったうえで、ナレッジパネル上の情報の修正を提案します。提案後の対応は審査を経るため、公式ヘルプで最新の手順を確認して進めましょう。
← 記事一覧へ戻る