検索の話題で「エンティティ」という言葉を見かける機会が増えました。ただ、この語はSEOだけのものではなく、データベース設計でも会計でもプログラミングでも使われます。分野をまたいで使い回される言葉なので、調べても文脈がかみ合わず、結局よくわからないまま終わってしまうことが少なくありません。
そもそもエンティティとは何を指す言葉なのか
エンティティ（entity）は、英語では「実体」「存在するもの」を意味する一般名詞です。抽象的な語なので、どの分野で使われているかによって指すものが変わります。SEOの文脈だけを見て理解しようとすると、他分野の説明に出くわしたときに混乱します。先に全体の見取り図を持っておくほうが早いので、まず主な使われ方を押さえておきます。
エンティティとキーワードは何が違うのか
SEOにおけるエンティティは、文字列としての単語ではなく、その単語が指している実体のほうを指します。キーワードが「文字の並び」だとすれば、エンティティは「その文字が指し示している、世の中に一つだけ存在する何か」です。
たとえば「アップル」という文字列は、果物のりんごを指すこともあれば、米国の電機メーカーを指すこともあります。文字列としては同じでも、指している実体は別物です。逆に「Apple」「アップル社」「Apple Inc.」は文字列としてはばらばらですが、指している実体は同じです。文字列と実体は一対一で対応していません。この食い違いを、文字列の一致で処理していた時代の検索エンジンは扱えませんでした。エンティティという考え方は、この食い違いを埋めるために持ち込まれたものです。
WEB担当者にとって実務的に効いてくるのは、後者のほうです。自社を指す表記が社内外でばらばらになっていると、検索エンジンから見て「同じ実体を指している」と判断されにくくなります。逆に表記が揃っていれば、別々のページや別々のサイトに散らばった情報を、一つの実体の情報としてまとめて扱ってもらえる可能性が高まります。
データベースやプログラミングで使われるエンティティ
情報システムの分野では、エンティティはもっと古くから使われている用語です。データベース設計では、管理したい対象のまとまりをエンティティと呼びます。顧客、商品、注文といった単位がそれにあたり、それぞれが属性（顧客なら氏名や住所）を持ち、エンティティ同士が関係を持ちます。この関係を図にしたものがER図（Entity Relationship Diagram）で、システム開発の設計工程では標準的な道具です。
プログラミング、とくにオブジェクト指向の設計でも、識別子を持って同一性が保たれるオブジェクトをエンティティと呼び分けることがあります。属性の値が同じかどうかで等しさを判断する「値オブジェクト」と対比される概念です。氏名や住所が変わっても、顧客IDが同じなら同じ顧客として扱う。この「識別子によって同一性を保つ」という考え方は、実はSEOにおけるエンティティとも通じています。
社内にシステム部門があるなら、エンティティという語はそちらで先に使われている可能性が高いです。会話が噛み合わないときは、データベースの話をしているのか検索の話をしているのかを確認すると、行き違いを避けられます。
ビジネスや会計の分野で使われるエンティティ
会計や法務の分野では、エンティティは「事業体」「法人格を持つ主体」といった意味で使われます。連結会計で子会社を数えるときの単位、あるいは契約の当事者としての法人を指す言い方です。リーガルエンティティ（legal entity）という表現なら見覚えがある方も多いのではないでしょうか。金融の分野では、取引主体を国際的に識別するための番号としてLEI（Legal Entity Identifier）が使われています。
この用法は、SEOのエンティティと無関係に見えて、実は接点があります。後述するGoogleの構造化データには、法人番号や納税者番号にあたる識別子を記述する項目が用意されているためです。会計上の「どの法人か」と検索上の「どの実体か」は、突き詰めると同じ問いを扱っています。
ゲームや映像作品、HTMLエンティティなど他分野での使われ方
ゲーム開発の分野では、画面上に存在するキャラクターやオブジェクトの一つひとつをエンティティと呼ぶ設計手法があります。映像作品やフィクションの世界では、正体不明の存在を指す語として使われることもあります。
WEB制作の実務でよく出てくるのはHTMLエンティティです。これは、そのまま書くとタグとして解釈されてしまう記号を、別の文字列に置き換える書き方を指します。不等号やアンパサンドを本文中に表示したいときに使うもので、これまで挙げてきた「実体」の意味とは系統が違います。同じカタカナ語でも、こちらは文字参照の話です。「エンティティ化」という言い方で出てきた場合は、ほぼこの意味だと考えて構いません。
分野ごとの意味を並べてみると、共通しているのは「区別して扱いたい一つの単位」という点です。
| 分野 | エンティティが指すもの | 具体例 |
|---|---|---|
| 検索・SEO | 世の中に一つだけ存在する実体 | 企業、人物、商品、地名 |
| データベース設計 | 管理したい対象のまとまり | 顧客、商品、注文 |
| プログラミング | 識別子によって同一性が保たれるオブジェクト | 顧客IDで区別される顧客 |
| 会計・法務 | 法人格を持つ事業主体 | 連結対象の子会社、契約当事者 |
| WEB制作 | タグと解釈される記号の代替表記 | 不等号やアンパサンドの文字参照 |
この記事で以降扱うのは、そのうち検索エンジンが世の中の実体を識別するために使っているエンティティです。
Googleが理解するエンティティとSEOにおける位置づけ
言葉の整理ができたところで、Googleがエンティティをどう扱っているのかを見ていきます。ここは推測が出回りやすい領域なので、Google自身が公開している説明を軸に確認していきます。
ナレッジグラフがエンティティをどう扱っているのか
Googleがエンティティを本格的に扱い始めたことを公にしたのは、2012年5月16日に発表されたナレッジグラフです。この発表でGoogleは、ナレッジグラフを「現実世界のエンティティと、それらの相互の関係を理解する知的なモデル」と説明し、「things, not strings（文字列ではなく、実体を）」という言い方でその狙いを示しました。
重要なのは、この発表がナレッジグラフを「もののカタログではない」と明確に述べている点です。Googleは、単に対象を集めた目録ではなく、対象同士の関係までモデル化していること、そしてその関係性こそが鍵であると説明しています。発表時点で5億を超える対象と、それらについての35億を超える事実や関係を保持しているとされていました。
図のように、ナレッジグラフは実体を一つずつ登録するだけでなく、実体と実体のあいだの関係もあわせて保持しています。対象そのものの数より、それらについて蓄えられた事実や関係の数のほうがはるかに多いことからも、関係を扱う比重の大きさがうかがえます。
Googleが2012年5月16日に公開したナレッジグラフの発表そのものです。現実世界のエンティティとその相互の関係を理解する知的なモデルであること、単なる対象の目録ではなく相互の関係までモデル化しており、その関係性こそが鍵であることが述べられています。ランドマーク、著名人、都市、スポーツチーム、建造物、地理的な地形、映画、天体、芸術作品といったものが対象として挙げられています。
検索結果の右側や上部に表示される情報のまとまりは、ナレッジパネルと呼ばれます。Googleの公式ヘルプでは、ナレッジパネルを「人物、場所、組織、ものといったエンティティを検索したときにGoogle上に表示される情報ボックス」と説明しています。情報の出どころは複数あり、オープンなウェブ上の様々な情報源、映画や音楽といった分野の認定データパートナー、そして自身のパネルに直接編集を申請した認証済みのエンティティから集められています。
ここでWEB担当者が押さえておきたいのは、ナレッジパネルが自動的に生成されるものであり、サイト運営者が自分で作成する手段は用意されていない、という点です。パネルに描かれているエンティティの本人または公式な代表者であれば、そのパネルの所有権を申請して変更を提案できる、という設計になっています。作るのではなく、認識された結果として表示される。この順序を取り違えると、対策の方向を誤ります。
Googleのナレッジパネルに関する公式ヘルプです。ナレッジパネルが人物・場所・組織・ものといったエンティティを検索したときに表示される情報ボックスであること、情報がオープンなウェブ上の情報源や認定データパートナー、認証済みのエンティティ本人から集められていること、そして本人または公式な代表者であればパネルの所有権を申請して変更を提案できることが説明されています。
キーワード中心の対策からエンティティ中心の対策へ変わってきた背景
かつての検索エンジンは、ページに書かれた文字列と、検索窓に入力された文字列の一致度を主な手がかりにしていました。この仕組みのもとでは、狙ったキーワードを本文にどれだけ含めるかという発想が成立してしまいます。同義語や表記ゆれのぶんだけページを作り分ける、という手法が横行したのもこの時期です。
ナレッジグラフのように実体とその関係を扱う仕組みが加わると、前提が変わります。文字列が違っても同じ実体を指していれば同じものとして扱え、逆に文字列が同じでも指す実体が違えば区別できるからです。表記を機械的に散らす作業の意味は薄れ、代わりに「このページは何について書かれていて、その何とは世の中のどの実体なのか」を伝えられているかが問われるようになりました。
| 観点 | キーワード中心の考え方 | エンティティ中心の考え方 |
|---|---|---|
| 対象 | 検索窓に入力される文字列 | その文字列が指している実体 |
| 表記ゆれの扱い | 表記ごとにページを作り分ける | 同じ実体として一つにまとめる |
| 主な作業 | 出現回数や語の配置の調整 | 名称の統一と関係の明示 |
| 効果の現れ方 | 特定の語での順位 | 名前で検索されたときの扱われ方 |
| 成果の測り方 | 検索順位 | 認識のされ方と指名検索の傾向 |
私たちが実務で感じているのは、この変化が作業の中身をかなり大きく変えたということです。キーワードの出現回数を調整する時間は減り、代わりに、社名や商品名の表記を全ページで揃える、会社概要ページの記述を実態と一致させる、外部のプロフィール欄と自社サイトの記述を突き合わせる、といった地味な作業の比重が増えました。派手さはありませんが、こちらのほうが後から効いてきます。
AI検索の広がりでエンティティの重要度が高まっている理由
生成AIが検索結果に組み込まれるようになって、この傾向はさらに強まっています。AIが回答を組み立てるとき、参照した情報が「どの組織の、いつ時点の、どういう性質の情報なのか」を取り違えると、回答そのものが誤ります。逆に言えば、実体がはっきりしている情報源のほうが、扱いやすい素材になります。
似た名前の会社が複数あるとき、あるいは社名を変更した直後のとき、AIは古い情報と新しい情報を混ぜて答えることがあります。これは意地悪をしているのではなく、どちらが現在の実体を指しているのかを判断する材料が足りていないだけです。材料をこちらから揃えておくという発想が、エンティティを意識した対策の出発点になります。
順位を何位上げるという話とは、少し性質が違います。自社が何者であるかを機械が誤解なく読み取れる状態にしておく。そのうえで検索やAIに正しく扱ってもらう。目的が変わっているぶん、成果の測り方も変わってきます。この点は後の章であらためて扱います。
エンティティSEOとは何かとE-E-A-Tとのつながり
ここまでを踏まえて、エンティティを意識したSEOが具体的に何を指すのかを整理します。あわせて、E-E-A-Tとの関係も見ておきます。両者は別々の取り組みのように語られがちですが、扱っている問題はかなり近いところにあります。
エンティティSEOで何が変わるのか
エンティティSEOとは、個々のキーワードで上位を取ることではなく、自社や自社の商品を一つの実体として検索エンジンに認識させ、その実体についての情報を正確に持ってもらうことを狙う取り組みです。狙う結果が違うため、施策の中身も変わります。
効果の出方にも違いがあります。特定のキーワードで順位が上がるという形ではなく、社名で検索したときの表示のされ方が整う、関連する検索でも候補として扱われるようになる、AIに説明させたときの内容が実態に近づく、といった形で現れます。すぐに数字が動く施策ではないぶん、一度整うと崩れにくいという性質もあります。
取り組む価値がとくに高いのは、次のような状況にある組織です。
- 同名または類似名の組織が他に存在する
- 社名やサービス名を変更したことがある
- 複数のブランドや事業を並行して運営している
- 合併や分社によって組織の形が変わった
いずれも、機械の側から見て実体の切り分けが難しい状況にあたります。逆に、名前が十分に独自で情報も一貫している組織であれば、すでにある程度は認識されているはずです。
もっとも、自社がどちらにあたるのかは、社内から見ているだけでは判断がつきにくいものです。腰を据えて取り組むかどうかを決める前に、いまどう認識されているのかを確かめておくと、必要な手間の見当がつきます。
E-E-A-Tの透明性とエンティティは同じ問題を扱っている
E-E-A-T（経験・専門性・権威性・信頼性）の各要素そのものをここで一つずつ解説することはしませんが、エンティティとの関係で一点だけ触れておきたいことがあります。それは透明性の扱いです。
誰が発信しているのかを明らかにする。運営者の情報を隠さない。書いた人の経歴や立場をページ上で示す。これらはE-E-A-Tの文脈で語られる話ですが、機械の側から見ると、いずれも「発信主体という実体を特定できる状態にする」ことにほかなりません。透明性を高める作業と、エンティティを認識させる作業は、出口が同じところに向かっています。
逆から見ると、透明性が低いサイトはエンティティとしても認識されにくい、ということになります。運営者情報が最小限しか書かれていない、著者名がない、問い合わせ先が不明瞭といった状態では、そもそも紐づけるべき実体が定まりません。E-E-A-Tの観点で「示したほうがよい」とされてきた情報の多くは、エンティティの観点では「示さないと識別できない」情報でもあります。同じ作業に二つの意味がある、と捉えておくと優先順位をつけやすくなります。
指名検索がエンティティ認識の手がかりになる
もう一つ、エンティティと結びつけて見ておきたいのが指名検索です。指名検索とは、一般的な語ではなく、社名やサービス名そのもので検索される動きを指します。
指名検索が増えている状態は、その名前が一定数の人にとって「特定の何かを指す言葉」として通用していることを意味します。名前を覚えられているからこそ、その名前で検索されます。実体として認識されている度合いが、そのまま検索行動に表れているとも言えます。
この点は、私たちが月次のレポートでも繰り返し触れてきたところです。ブランド力が高まれば再訪問が増え、指名検索が増え、外からの言及も自然と増えていく。そうなればGoogleやAIの側から見ても、どこが人気を集めているのか、誰が適切なデータを持っているのかの輪郭がはっきりしてくる、という見方です。小手先の順位対策ではなく、名前が覚えられていく状態をつくることのほうが、遠回りに見えて確かな道だと考えています。
注意しておきたいのは、指名検索の数を直接的に増やそうとする施策には無理があるという点です。指名検索は結果として増えるものであって、それ自体を操作しにいくものではありません。実務では、施策の目標ではなく、認識の度合いを測るための指標として扱うのが妥当です。
エンティティを認識させるために実践すべき具体的な施策
ここからは、実際に手を動かす部分に入ります。順序としては、自社サイトの中を整えることから始めて、外部との関係づくりへ広げていくのが無理がありません。
名称の表記を統一し関連するエンティティを本文に置く
最初にやるべきは、自社を指す表記を揃えることです。株式会社を前に置くのか後ろに置くのか、英語表記を併記するのか、サービス名にスペースや中黒を入れるのか。こうした揺れが社内資料とサイトとSNSで食い違っていることは珍しくありません。正式名称を一つ決め、どこでも同じ形で書く。地味ですが、ここが崩れているとその先の施策が効きにくくなります。
そのうえで、本文に関連する実体の名前を自然に入れておくことも有効です。自社が扱っている技術の名称、業界の団体名、対応している規格名、拠点のある地名などが該当します。これらは、自社という実体が他のどの実体とつながっているかを示す手がかりになります。ただし、関連語を機械的に並べる書き方は逆効果です。文脈の中で必要だから出てくる、という形を保ってください。読んで不自然に感じる時点で、入れすぎだと考えたほうがよいです。
内部リンクとトピッククラスターで関係を示す
サイト内の構造も、実体同士の関係を伝える材料になります。ある話題について網羅的に扱う中心のページを置き、そこから個別の論点を扱うページへリンクを張り、個別のページからも中心のページへ戻す。この組み立てはトピッククラスターと呼ばれ、サイト内でどの話題が中心なのかを示す効果があります。
エンティティの観点で言えば、リンクは「このページで扱っている実体と、あのページで扱っている実体には関係がある」という宣言です。だからこそ、アンカーテキストが「こちら」「詳しくはこちら」ばかりになっていると、関係の中身が伝わりません。リンク先が何を扱っているのかがわかる語をアンカーに置く。これだけでも、関係の読み取りやすさは変わります。
内部リンクの難しさは、記事を書くたびに「どこから張るべきか」を人が思い出さなければならない点にあります。Kashiwazaki SEO Auto Tag Linkerは、本文中にタグ名と一致する語が出てきたときに、それを自動でタグアーカイブへのリンクに変えます。着目したいのは、リンクの起点が編集者の記憶ではなく、あらかじめ決めたタグ体系になることです。タグは扱う話題の一覧そのものなので、どの語をタグにするかを決める作業が、そのまま関連する実体の設計になります。アンカーテキストがタグ名で揃うため、関係の中身が伝わりにくくなる問題も起きにくくなります。
構造化データでエンティティの同一性を明示する
構造化データは、ページの内容を機械が読み取れる形で補足するための記述です。エンティティの文脈では、とくにOrganizationという型が中心になります。Googleの公式ドキュメントでは、この型で次のような項目が扱えるとされています。
- name
組織の名称 - url
組織の公式サイトのURL - logo
ロゴ画像のURL - sameAs
自組織に関する追加情報が載っている、別サイト上のページのURL - alternateName
実際に使われている別名や略称 - legalName
登記上の正式名称
Organizationは、特殊な型ではありません。HTTP ArchiveのWeb Almanacが2024年に公開した調査では、モバイルページのうちJSON-LDで記述されている型の割合は、WebSiteが12.73%、Organizationが7.16%、BreadcrumbListが5.66%、LocalBusinessが3.97%、ItemListが2.44%、WebPageが1.49%でした。サイト全体を示すWebSiteに次いで、組織を示すOrganizationが多く使われていることになります。
このうち、名寄せの観点で効いてくるのがalternateNameとlegalNameです。正式名称と、実際に使われている別名や略称を、それぞれ別の項目として書き分けられます。表記が複数あることを隠すのではなく、正式名称はこれで、別名としてこれも使われている、と申告しておくという考え方です。
sameAsは、Googleの説明では「自組織に関する追加情報が載っている、別サイト上のページのURL」とされ、SNSやレビューサイトのプロフィールページが例に挙げられています。自社サイトの外にある自社の情報を、自社サイトの側から指し示すための項目です。
ここまでの項目をまとめると、会社概要ページに置く記述は次のような形になります。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "株式会社エグザンプル",
"legalName": "株式会社エグザンプル",
"alternateName": ["エグザンプル", "Example Inc.", "旧エグザンプル商事"],
"url": "https://example.co.jp/",
"logo": "https://example.co.jp/images/logo.png",
"sameAs": [
"https://x.com/example",
"https://www.youtube.com/@example",
"https://www.linkedin.com/company/example"
]
}
</script>法人としての識別子を記述する項目も用意されています。公式ドキュメントには次の項目が挙げられています。
- duns（Dun & Bradstreetの企業識別番号）
- iso6523Code（ICD接頭辞つきのISO 6523識別子）
- leiCode（ISO 17442の取引主体識別子）
- naics（北米産業分類システムのコード）
- globalLocationNumber（GS1の事業所識別番号）
- vatID（付加価値税の番号）
- taxID（納税者番号）
会計や法務の文脈で使われる番号がここで登場するのは、先に触れたとおり「どの法人か」と「どの実体か」が地続きだからです。
記述する場所についても指定があります。Googleは、この情報はホームページか、会社概要ページのように組織を説明する単一のページに置くことを推奨しています。全ページに散らすものではありません。必須項目はなく、自組織に当てはまる項目を追加すればよい、とも書かれています。
そのうえで押さえておきたいのは、Google自身が「構造化データを利用する機能が検索結果に表示されることを保証するものではない」と明記していることです。書けば必ずナレッジパネルが出る、という性質のものではありません。機械が読み取りやすい形で情報を渡しておく作業であって、表示を約束する仕掛けではない、と理解しておくのが正確です。
Google検索セントラルのOrganization構造化データのドキュメントです。対応するプロパティとして name・url・logo・sameAs・alternateName・legalName が挙げられ、法人の識別子として duns・iso6523Code・leiCode・naics・globalLocationNumber・vatID・taxID が示されています。この情報はホームページか組織を説明する単一のページに置くことが推奨され、必須のプロパティはないこと、そして構造化データを利用する機能が検索結果に表示されることを保証しないことも明記されています。
どの項目をどこまで書くかは、組織の実態によって変わります。判断に迷う場合は、書ける項目を増やすことよりも、書いた内容が実態と一致していることを優先してください。
プロパティの一覧と説明は公式ドキュメントで随時更新されるため、実装の前に最新の記述を確認しておくと確実です。自社にどの項目が当てはまるかは事業の形によって変わるので、書き出す前に整理しておくと迷いません。
第三者からの言及と相互参照を積み上げる
ここまでは自社から発信する側の話でした。ただ、それだけでは足りません。自社サイトに書いてある情報も、自社で入れた構造化データも、突き詰めれば自己申告です。書いた本人が「これは自分のものです」と主張しているだけ、という性質がどうしても残ります。
だからこそ、外側からの裏づけが要ります。イベントへの登壇や出展、業界団体での活動、地域の取り組みへの参加、独自に調べたデータの公表。こうした活動は、自社サイトで告知するだけでは片側しか埋まりません。主催者側のページに登壇者として名前が載る、メディアに取り上げられる、参加した団体のサイトから自社が参照される。この相互参照が加わってはじめて、その活動は外形的に確かめられる事実になります。
私たちSEO Note! Teamは、この点を「自分で語る言葉より、誰かに語ってもらった言葉のほうが遠くまで届く」と表現してきました。取り上げてもらうためには素材が要ります。新しいサービスを始めた、拠点を増やした、独自のデータがまとまった、地域の取り組みに関わった。こうした出来事を自社サイトで告知して終わりにせず、外のページに載る形まで持っていけるかどうかが分かれ目になります。
順序として大切なのは、実態を整えてから紐づけることです。運用していないSNSアカウントを構造化データで自社のものとして宣言する、実体のない活動を告知する、といったやり方は、いずれ食い違いとして表面化します。整えるのが先で、紐づけるのは後です。
自社がエンティティとして認識されているかを確認する方法
施策を進める前後で、いま自社がどう認識されているのかを確かめておくと、やるべきことの優先順位が見えてきます。特別なツールがなくても、ある程度までは確認できます。
ナレッジパネルの表示状況から確認する
もっとも直接的なのは、社名で検索してナレッジパネルが表示されるかどうかを見ることです。表示されていれば、Googleが自社を一つのエンティティとして保持していることになります。表示されない場合でも、認識されていないと断定はできません。パネルの表示は認識の有無をそのまま反映するものではないためです。
パネルが表示されている場合は、記載されている内容が実態と合っているかを確認します。設立年、所在地、事業内容、関連する人物といった項目に、古い情報や誤った情報が混ざっていないかを見ます。誤りがあった場合、パネルに描かれているエンティティの本人または公式な代表者であれば、そのパネルの所有権を申請して変更を提案できます。申請すると、掲載する画像を選んだり、事実にあたる情報の修正を提案してGoogleの確認を受けたりできるようになります。代表者でない場合でも、パネル右下のフィードバックリンクから修正の意見を送ることはできます。
先に触れたとおり、申請してできるのは、すでに存在するパネルに対する提案までです。表示されていない段階でやるべきなのは、申請ではなく、認識される材料を揃える側の作業になります。
指名検索と画像検索、関連する語から確認する
ナレッジパネル以外にも、手がかりはいくつかあります。社名で検索したときに、自社サイトのほかにどのようなページが並ぶかを見てください。公式サイト、SNSアカウント、採用媒体、ニュース記事といったものが自社に関するもので占められていれば、その名前が自社と結びついて扱われている状態です。同名の別組織や無関係なページが混ざっている場合は、切り分けができていない可能性があります。
画像検索で社名を入れてみるのも簡単な確認方法です。自社のロゴや自社に関係する画像が並ぶかどうかで、名前と視覚的な情報が結びついているかを大まかに見られます。
検索窓に社名を入れたときのサジェスト、検索結果下部の関連する検索キーワードも参考になります。ここに並ぶ語は、その名前と一緒に検索されている語です。自社の事業と関係のない語ばかりが並んでいる場合は、意図しない文脈で名前が扱われていることになります。
指名検索の量そのものは、Search Consoleの検索クエリで社名を含む語を絞り込めば把握できます。Googleトレンドで社名を入れて推移を見る方法もあります。いずれも認識の度合いを測るための材料であって、順位のように上げにいく数字ではありません。施策の前後で傾向を見る、という使い方が現実的です。
ここまで挙げた確認の手順を並べると、次のようになります。
- 社名で検索してナレッジパネルが表示されるか、記載内容が実態と合っているかを見る
- 検索結果の1ページ目が自社に関するページで占められているかを見る
- 画像検索で自社のロゴや関係する画像が並ぶかを見る
- サジェストと関連する検索キーワードに、事業と結びつく語が出るかを見る
- Search Consoleの検索クエリで社名を含む語を絞り込み、指名検索の量を把握する
- Googleトレンドで社名を入れ、推移の傾向を追う
これと並行して、自社と紐づくアカウントの棚卸しも行っておきたいところです。昔つくったまま放置しているアカウント、担当者が個人で開設したまま引き継がれていないアカウントが残っていないか。実際に運用しているものだけを、サイト側のプロフィールや会社概要ページ、構造化データの記述とそろえておく。確認と整備は、同じ作業の表と裏だと考えてください。
エンティティを扱ううえで注意すべきポイント
最後に、実際に取り組む際につまずきやすい点を挙げておきます。いずれも、やってしまってから戻すのに手間がかかる類のものです。
表記ゆれや旧社名の放置による名寄せ失敗に注意する
もっとも多いのが、名前が揃っていないことによる取りこぼしです。社名変更やサービス名の変更を行った場合、変更後の名称に切り替えて終わりにしてしまうと、旧名称で蓄積されてきた情報との結びつきが切れてしまうことがあります。
対処としては、旧名称を消し去るのではなく、旧名称と新名称が同じ実体を指していることが読み取れる状態にしておくことです。会社概要ページに沿革として変更の事実と時期を書いておく、構造化データのalternateNameに旧名称を残しておく、旧ドメインを使っていたなら適切に転送を設定しておく、といった対応が該当します。
支店名や部門名の扱いにも注意が要ります。組織の下部単位まで独立した組織として記述してしまうと、実体が分裂して認識されることがあります。どこまでを一つの実体として扱うかを先に決めて、その方針をサイト全体で通してください。
Wikipediaへの自作自演的な登録は避ける
ナレッジパネルの情報がウェブ上のさまざまな情報源から集められているとGoogleが説明していることから、WikipediaやWikidataに自社の項目を作れば認識されるのではないか、と考える方がいます。ただ、この発想での登録は勧められません。
日本語版Wikipediaには自分自身の記事をつくらないというガイドラインがあり、自分や自社のように個人的に関わっていることがらについて書くときは、いつも以上に注意を払うか、控えなければならないとされています。理由として挙げられているのは、自分について書いた情報には主観が入り込みやすく、自分に都合のよいものごとの捉え方になりがちだという点です。百科事典的でないと判断された記事は削除の対象になります。手間をかけて登録し、削除され、その経緯が記録として残る。これでは目的と逆の結果になります。
日本語版Wikipediaのガイドラインです。自分自身や自分が深く関わっている対象について記事を書くことは推奨されないという方針が、その理由とともに説明されています。中立的な観点を保つことが難しくなること、独立した情報源による裏づけが必要であることが述べられています。
そもそも、これらの外部データベースへの掲載は、第三者から見て記載する価値があると判断された結果として起きるものです。順序を逆にしても長続きしません。取り上げられる材料を作り、外部から言及される状態を積み上げていく。回り道に見えますが、こちらのほうが確実です。
本文の内容と矛盾する構造化データをマークアップしない
構造化データは機械向けの記述なので、画面に表示されないぶん、実態と違う内容を書けてしまいます。これは避けてください。ページに書かれていない情報を構造化データにだけ記述する、実際とは異なる名称や所在地を書く、運用していないアカウントをsameAsに並べる。いずれも、読み取る側から見れば食い違いとして現れます。
チーム名義で発信しているのに著者を個人として記述する、といった食い違いにも注意が必要です。画面上の表記と構造化データがずれていると、発信主体を人物と組織のどちらのエンティティとして扱えばよいのかが定まらなくなります。
この食い違いが起きやすいのは、画面に出す著者表示と、裏側のJSON-LDを別々の場所で管理しているときです。Kashiwazaki SEO Author Schema Displayは、著者情報カードの表示と Schema.org の JSON-LD 出力を同じ設定から行うため、画面の表記と構造化データがずれません。とくに効いてくるのは、著者タイプを Person・Organization・Corporation から選べる点です。チーム名義で発信しているなら Organization を選べばよく、本文で述べた「人物と組織のどちらの実体として扱えばよいのかが定まらない」状態を、設定の段階で避けられます。
考え方としては単純です。構造化データは、ページに書いてあることを機械が読み取りやすい形に整えるためのものであって、ページに書いていないことを追加で主張するためのものではありません。
実装したあとは、schema.orgが提供している検証ツールで記述に誤りがないかを確かめ、あわせて画面の表示内容と突き合わせて食い違いがないかを目で確認する。この二段構えにしておくと、事故を防げます。
ここまでの内容は、どれも特別な技術を必要としません。むしろ手を動かす前に決めておくことのほうが、あとの手戻りを左右します。
エンティティは自社を一つの実体として認識させるための考え方である
ここまで見てきたとおり、エンティティという言葉は分野によって指すものが変わりますが、検索の文脈では「世の中に一つだけ存在する実体」を指しています。Googleは2012年のナレッジグラフの発表以来、文字列ではなく実体とその関係を扱う方向へ進んできました。文字列を並べる作業から、実体を正しく伝える作業へ。エンティティを意識するというのは、この移り変わりに対応することにほかなりません。
企業のWEB担当者が取り組むこととして、内容は決して特殊なものではありません。名称の表記を揃える、運営者情報を隠さず書く、サイト内の関係を内部リンクで示す、構造化データで正式名称と別名と外部プロフィールを申告する。どれも新しい技術を必要とせず、今日から着手できます。派手さがないぶん後回しにされがちですが、名寄せに失敗している状態を放置すると、そのうえに積み上げた施策の効果も目減りします。
同時に、自社から発信するだけでは片側しか埋まらないことも押さえておいてください。自社サイトの記述も構造化データも、突き詰めれば自己申告です。イベントや取り組みを外に届け、第三者のページから参照される。この相互参照が加わってはじめて、外形的に確かめられる事実になります。E-E-A-Tで求められる透明性と、エンティティとして認識されるための条件は、ここで重なります。
確認の方法も難しくありません。社名で検索してナレッジパネルの有無と記載内容を見る、検索結果や画像検索に自社に関するものが並ぶかを見る、Search ConsoleやGoogleトレンドで指名検索の傾向を追う。この程度でも現在地はつかめます。ナレッジパネルは自分で作れるものではなく、認識された結果として表示されるという順序を忘れないでください。
避けるべきことも明確です。旧社名を切り捨てて結びつきを断つ、外部データベースへ当事者が自ら登録しにいく、画面の内容と食い違う構造化データを書く。いずれも近道に見えて、後から手戻りを生みます。実態を整えてから紐づける。この順番さえ守れば、大きく外すことはありません。
この作業は、一度整えて終わりにはなりません。組織やサービスが変われば、そのたびに合わせ直す必要があるためです。自社が何者であるかを機械が誤解なく読み取れる状態を保つこと。地味な作業の積み重ねですが、AIが情報を要約して答える場面が増えるほど、その差は表に出てくるようになります。まずは社名で検索してみるところから、始めてみてはいかがでしょうか。
よくある質問
SEO Note! Team (SEO施策スタッフ)
SEOエンジニア、マーケター、ライター、編集担当からなる専門チームです。技術的なサイト最適化からコンテンツ戦略の立案、記事の執筆・編集まで、SEO施策を一気通貫で対応できる体制を整えています。10万パターン以上のキーワード対策と3万を超えるドメインの運用で培った実践的なノウハウをもとに、机上の理論だけでは得られない現場視点のSEO支援を提供しています。
関連記事
